How are PDSE load libraries handled by PMO?

Products

• PMO Runtime Performance Optimizer

Issue/Introduction

How are PDSE load libraries handled by  PMO?

Environment

Release: 4.4

Resolution

 PMO (Program Management Optimizer) optimizes library searches in private concatenations and/or the linklist libraries by keeping the directory entries of the modules in storage and thus avoiding I/O to read the directories of the partitioned datasets during execution of the "Build Library Directory List"- SVC invoked by the BLDL Macro. Given a considerably long list of concatenated libraries in LINKLIST or STEPLIB DD, many I/Os can be saved this way. This holds true even when

1. Not all libraries in this concatenation are managed by  PMO
   
   
2. Some of the libraries are PDSE (program object libraries)

 

Solution

PMO will optimize STEPLIB searches even if there are some unmanaged libraries or PDSE libraries.

PMO retains the directory entries of the libraries, that it manages in hash tables or the managed list, and first searches these in-storage areas before it reissues the BLDL macro using trimming of the BLDL request (stating the starting and ending concatenation number of the libraries that will be searched by the system).

The benefit of using  PMO depends on the concatenation. If for example the first lib in the STEPLIB is a PDS and the member that is BLDLed is in this PDS, PMO returns the desired information promptly, no matter what the rest of the concatenation is.

In some cases, PDSEs in the STEPLIB concatenation can cause that the whole STEPLIB will be searched by the system (e.g. consider the following STEPLIB: PDSE, PDS, PDS, PDSE). In this case, PMO has to reissue the BLDL for all the four libraries (as the first and the last is a PDSE and the trimming is limited only to setting a range).

There are two main search types that PMO addresses

1. link list activity. ? Here PMO monitors link list searches and keeps the most active member directory information in memory. This allows for link list directory searches to be minimized.
   
   
2. 'private' library activity. ? These are PDS s that are accessed via STEPLIB or other non-link list activity. As mentioned, if the STEPLIB includes one or more PDSE s,  PMO may need to reissue a BLDL specifying a subset of the STEPLIB data sets.

 

To give another example, let s say that the STEPLIB has 5 data sets, where the 2nd and 4th are PDSEs, with the remainder being PDSs. Also, let s state that PMO is managing the PDSs, and that a BLDL is issued for a member that only resides in PDS5.

 

    //STEPLIB  DD  PDS1 
               DD  PDSE2 
               DD  PDS3 
               DD  PDSE4 
               DD  PDS5 

 

PMO performs the following actions:

1. PMO scans its hash table to discover that the module does not exist in PDS1.
   
   
2. PMO determines that PDSE s are present, and issues a BLDL for the 2nd, 3rd, and 4th data sets (trimming the first and fifth data sets from the list).
   
   
3. If not found, PMO then scans the hash table for PDS5 and locates the module.

 

In the above example, PMO has saved I/O for PDS1 and PDS5 data sets.

Per design, in our sample PMO cannot avoid BLDL activity for PDS3.

Conclusion:

So, we may sum up that you would benefit from using PMO even, when you have PDSE in your concatenations. We never may be able to eliminate 100% of I/O, but a fair amount of requests will be served directly from Storage avoiding real I/Os, that need to go to disc. PMO offers statistics, that give close insight of the saved I/Os and the number of calls per library or per member.

PMO has advantages as compared to IBM's LLA:

1. Automatically adds PDS Datasets to the managed list, i.e. Directories are managed starting with an adjustable I/O threshold value.
   
   
2. Automatic "LLA"-Refresh.

Statistics that allow additional tuning to make best use of the resources allocated to PMO.