search cancel

Why CA OPS/MVS AOF GLV rules are not firing when a Sysplex Variable is created, updated or deleted via the OPSVASRV function, after a dynamic change to turn on the GLVNOTIFYRULES parameter is implemented?

book

Article ID: 41675

calendar_today

Updated On:

Products

OPS/MVS Event Management & Automation

Issue/Introduction

Question:

Why CA OPS/MVS AOF GLV rules are not firing when a Sysplex Variable is created, updated or deleted via the OPSVASRV function, after a dynamic change to turn on the GLVNOTIFYRULES parameter is implemented?

Answer:

When parameter GLVNOTIFYRULES is not set at initialization time via the OPSSPAxx parameter deck we do not implant the exit OPSVASREX.

To determine if this is the case proceed to issue the following z/OS display command:

/D PROG,EXIT,EXITNAME=CA_VARDATA_CHG,DIAG

If the exit was not implanted then you should see the following message as a result:

CSV463I NO MODULES ARE ASSOCIATED WITH EXIT CA_VARDATA_CHG

To dynamically implant the exit consider using the following z/OS modify command against the CA OPS/MVS subsystem:

/F OPSS,RELOAD(OPVASREX)

A message similar to this should be posted by the OPSMAIN Address Space:

OPS3257I Module name (OPVASREX) reloaded at X'yyyyyyyy'

Also as a result of all above the z/OS display command should now show this:

D PROG,EXIT,EXITNAME=CA_VARDATA_CHG,DIAG
CSV464I hh.mm.ss PROG,EXIT DISPLAY nnn
EXIT CA_VARDATA_CHG
MODULE STATE EPADDR LOADPT LENGTH JOBNAME PARAM
OPVASREX A yyyyyyyy 00000000 00000000 *

AOF GLV rules should now start firing on the designated system upon CREATE, UPDATE, and DELETE functions are performed against Sysplex Variables via the OPSVASRV command. Keep in mind that when using multiple CA OPS/MVS systems only the instances using the same SUBSYS id will see the updates to the Sysplex Variables.

Additional Information:

You can find additional information at our website: CA Technologies Documentation

Environment

Release: PVLA2.00200-12.2-OPS/MVS-Event Management & Automation-for JES2
Component: