Upgrading to a new OPS/MVS release with OPUSEX user exit in use from a prior release
Article ID: 44901
Updated On:
Products
Issue/Introduction
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?
Environment
OPS/MVS-Event Management & Automation-for JES2
Resolution
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.
Feedback
