Are you planning to upgrade to a new CA OPS/MVS release and a prior version of the OPUSEX user exit is currently in use?
To prevent unexpected security related problems, like a return code 36 when you try to use a product feature you have access but is now denied by your OPUSEX user exit, we are recommending to complete the following steps:
1.- Rework any existing changes made in the past to the latest OPUSEX user exit provided in the CCLXASM library.
2.- Use a JCL to invoke the ASMA90 and IEWL programs to produce a new load module. You could use a copy of the sample JCL JES2ASM that is located in the CCLXCNTL library. Just make sure you tailor it to use and produce the OPUSEX module. Also include a reference to the CCLXASM library in the SYSLIB concatenation.
3.- Once the new module has been successfully produced make sure you deploy it so a recycle of the OPSMAIN task uses it during the next product restart.
4.- In case you can not recycle OPSMAIN then issue a z/OS MODIFY command, in one of the following two forms, to reload the module:
As a result, a message similar to this is posted with the new address location of the module:
OPS3257I Module name (OPUSEX) reloaded at X'8_bytes_address'
Next issue a z/OS MODIFY command, again in one of the following two forms, to restart the security interface:
Make sure this message is posted: OPS0135H Security interface restarted
5.- You can optionally visit the OPSVIEW option 4.1.5 to locate the OPUSEX module. Confirm the Date/Time values shows current dates.
4.- Continue with your testing of the new release and make sure access is granted or denied based on your originally setup and how you prior release used to do it.
You can find additional information at our website: CA Technologies Documentation