How can one use the TSO ISRDDN tool/dialog to confirm if a fix is implemented in a system run time environment?

Products

ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC PanApt PanAudit

Issue/Introduction

Environment

Release: ACF2..001AO-16-ACF2
Component:

Resolution

Often times it may be necessary to confirm that a CA provided fix is implemented in the running system. It may not be enough to know if the fix was installed in an SMP/E environment, although that is a good starting point. Best practices dictate that you do not run executable programs directly from the SMP/E target libraries. The SMP/E target libraries are usually copied to system runtime libraries which may also be defined to be included in the system LPA list concatenation or the system link list concatenation.

The TSO ISRDDN command is a useful tool that lets you browse/view your active TSO session libraries. It also has the capability to add the system LINKLIST libraries and LPA libraries to the list of libraries that you can view. This is useful to confirm if a CA provided fix is implemented in the system run time environment.

To begin, you will need to have (security) authorization to browse/view system libraries. You will need to know the load module name and module/CSECT. This may be given to you by CA Support to have you confirm a fix, or this can be obtained by using the SMP/E Dialog (ISPF Panels).

Enter TSO ISRDDN on any ISPF command line. This displays the Current Data Set Allocations for your TSO session.
Enter the command LINK or LPA. Either command will add both the system LINKLIST and LPA libraries to the display. The LINK command will scroll to LINKLIST while LPA scrolls to LPALIB.
Enter the command: member load_module linklist (where "load_module" is the load module name (program name) you want to view, and "linklist" means to search the LINKLIST libraries, or specify "LPALIB" to search the LPA libraries).
There will be a security warning pop-up window regarding potential security violations when accessing any of these libraries. Type in "yes" to continue.
You will either see the load module name (member) in the message area before the library dataset name, or another window will pop up identifying the module as being PLPA or CSA resident. In this case move the cursor into the pop-up window box and hit enter to see the load module in memory. If there is no pop-up window, scroll to the library dataset name containing the load module and select it to browse/view the load module. If there are multiple lines (datasets) that contain the member (load module) browse/view the first one as that is what the system run time environment uses.
Now you are looking at the load module. Issue the command: find module_name where "module_name" is the name of the MOD/CSECT. Look for the CA eye catcher area that identifies this as a CA module. You may need to repeat the find to find the module eye catcher area. For current CA mainframe products you should see #MID near the beginning of the eye catcher area. Then look for RMID to see the last fix that replaced the module, like RMID(RO56789). This confirms that that fix is in use on the running system. If the RMID is different than what you were looking for, then you need to identify if the RMID fix superseded what you were looking for. If it does supersede what you were looking for then it is confirmed that the fix you were checking is implemented in your run time environment, and you are in fact at a higher level. If the fix (RMID) shown is not superseded then you do not have the fix you were checking implemented in your system. If it shows RMID(RESERVE) then there has been no replacement fix for this module.

This technique can be used to verify a fix for most current CA Mainframe products.

If the product is not current, or if there is no #MID or RMID value, you can still check/verify a module with Date and Time stamp information seen in the eye catcher area. CA Support can match this up with a specific fix to verify that a particular fix is on.