We are planning to upgrade to a new OPS/MVS release with a prior version of the OPUSEX user exit currently in use. What considerations are there?
OPS/MVS-Event Management & Automation-for JES2
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:
/MODIFY ssid,RELOAD(OPUSEX)
/F ssid,RELOAD(OPUSEX)
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:
/MODIFY ssid,RESTART(SECURITY)
/F ssid,RESTART(SECURITY)
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.