Padlock representing security

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=Y to 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=Y to 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 ISIS and 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 ISIS and/or 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.

Padlock with heavy chain

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!

Join The Discussion

Your email address will not be published. Required fields are marked *