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?
Article ID: 41675
Updated On:
Products
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
Component:
Feedback
