If you are manually including libraries for management (that is, if you specified EXCLAUTO=* in your parameter data set), you tune CA PMO in the following way:
Note: In a production environment, CA PMO should resolve 90% of private library searches. In a testing environment, it should resolve 80% of the searches.
Your main goal at this time is to reduce the number of I/O directory searches of private libraries. I/O directory searches happen for all members of private libraries that do not have hash tables. This kind of problem is particularly undesirable when libraries with hash tables are listed before libraries without hash tables in a concatenation.
When CA PMO searches the hash tables but the sought-for member belongs to a library that does not have a hash table, the search is particularly inefficient. This is because the search must continue on DASD, starting with the first library in the concatenation. The DASD I/O search occurs against all libraries in the concatenation up to the library that contains the sought-for member. The directories of all of the libraries in the concatenation are searched if the member does not belong to any of the libraries in the concatenation.
The following example illustrates this problem and explains how to solve it. Assume that the concatenation shown in the following example has three libraries:
//PDSDD DD DSN=HASHTAB.LIB1 // DD DSN=HASHTAB.LIB2 // DD DSN=NO.HASHTAB.LIB
Suppose that a sought-for member resides in NO.HASHTAB.LIB. NO.HASHTAB.LIB is not managed in a hash table. Also suppose that HASHTAB.LIB1 and HASHTAB.LIB2 are managed in hash tables. In this situation, CA PMO first looks in the hash table for HASHTAB.LIB1, then it looks in the hash table for HASHTAB.LIB2. Finally, since the sought-for member will not have an entry in the hash tables, CA PMO initiates an I/O directory search of NOHASHTAB.LIB. Due to the way that library directories are searched on DASD, this search must begin with the directory of HASHTAB.LIB1, continue with HASHTAB.LIB2, and conclude with NOHASHTAB.LIB. This is wasteful, since HASHTAB.LIB1 and HASHTAB.LIB2 are each searched twice. The same situation occurs when a sought-for member is not in any of the libraries in this concatenation.
If NO.HASHTAB.LIB is managed in a hash table, the problem is eliminated.
Important! If you allow CA PMO to manage your private libraries automatically, it would manage NO.HASHTAB.LIB if directory search activity warrants it.
If you want to prevent CA PMO from managing your libraries automatically, follow this procedure to locate the libraries that are causing these I/O searches:
Examine the PMOMON D9 display and include up to 30 more libraries for management in hash tables. This will probably resolve the problem, but if it persists, try the next step.
Issue the following command to obtain an offline report for each library with a hash table:
F PMO,PRVTRPT=ALL,NM
Look in the first section of the report for libraries with high counts under DUE TO CONCATENATED LIB. These libraries are not the problem, but they are concatenated to the libraries that are the problem. Examine system tasks, batch jobs, and online systems and ask users to identify jobs that issue BLDL/FIND requests against the libraries in the reports. The problematic libraries occur after the managed libraries in the concatenation. For instance, in this example you would ask your users which libraries are concatenated with HASHTAB.LIB1 and HASHTAB.LIB2. Once you find the nuisance libraries, (in this case, NO.HASHTAB.LIB), ensure that CA PMO manages them in hash tables.
|
Copyright © 2011 CA.
All rights reserved.
|
|