In general, IMS System Programmers would agree that the process of altering business applications without impacting related components can be a rather complex task.
To get a better idea of why that may be, letâ€™s look at the following scenario.
Jim is an IMS System Programmer for a company that is looking to stop using Resources Recovery Services (RRS) while keeping all other parameters the same. RRS is the z/OS syncpoint manager that controls how and when the update and recovery of protected resources occurs across multiple resource managers like IMS and Db2 for z/OS. Jimâ€™s system currently has ODBM threads RACF-authorized using the
ODBASE parameter; any security settings using the
ISIS parameter are not currently defined in the system.
At first glance, changing from
RRS=N might seem like a straightforward task, but there is a catch: changing to
RRS=N would mean that Jimâ€™s app would no longer use the IMS RACF class, AIMS, and will instead use the IIMS class. Although using the IIMS path itself does not cause disruptions, it means that he can no longer use the
ODBASE parameter to enable RACF authorization for ODBM. Can Jim switch from
RRS=N and keep everything else the same? Unfortunately, no; and his only option would be to use the
ISIS parameter. However, that option also requires him to rework all other IMS components and workloads to be compatible with ISIS.
What is a System Programmer to do?
With the new
ODBMSECURE parameter, Jim can now keep RACF authorization for ODBM without worrying about disruptions to other IMS components, turning what could have been a large work effort into the addition of one single parameter.
So how does
ODBMSECURE actually work?
ODBMSECURE allows Jim and other IMS System Programmers to enable PSB authorization to ODBM without impacting how other existing IMS procedure parameters are defined. In short,
ODBMSECURE has â€śthe final sayâ€ť when it comes time to determining the level of security to be used. Itâ€™s actually pretty simple.
All Jim has to do is add the new
ODBMSECURE parameter to the
IMS PROCLIB member, and ODBM uses the security value defined with
ODBMSECURE during IMS gen. Even if
ODBASE are set to
N (meaning no RACF authorization), if
ODBMSECURE is set to
R (use RACF authorization), ODBM will use RACF authorization, and existing components that required
ODBASE to be set to
N are unaffected. Without
ODBMSECURE, Jim could change
ISIS to use RACF (setting it to
Y), which would achieve the goal of setting security for ODBM, but he would then be required to rework existing IMS workload components.
ODBMSECURE gives Jim greater flexibility in managing security, and likewise gives your IMS System Programmer an asset to add to their repertoire for adding and maintaining security to ODBM threads.
For IMS 15, you can find the APAR for this enhancement here.
For IMS 14, you can find the APAR for this enhancement here.
Let us know what you think â€“ leave a comment below!