Customizing IBM Tivoli Workload Scheduler for z/OS V8.2 to Improve Performance

114 Customizing IBM Tivoli Workload Scheduler for z/OS V8.2 to Improve Performance

Table 5-3 Results with faster DASD with a very large cache

One additional test was done using a facility provided by the EQQUX002 code

we were using (Table 5-4). This enabled us to define some model JCL that was

loaded into storage when the Tivoli Workload Scheduler for z/OS controller was

started. When JCL was fetched, it was fetched from this storage version. The exit

inserted the correct jobname and other elements required by the model from

data within the operations record (CPOP) in the current plan.

Table 5-4 Results using the EQQUX002 code shipped with this book

As can been seen from these results, the quickest retrievals were possible when

using PDSE files with the EQQUX000/002 exits, using PDS files with their

directories in LLA with the EQQUX00/02 exits, or using the instorage model JCL

facility.

5.4.3 Pre-staging JCL conclusions

In the following sections, we discuss our pre-staging JCL conclusions.

Using PDSE files for JCL

From the information previously described, the obvious course of action would be

to move all the JCL files into PDSE files. However, if your JCL is small, this is

wasteful of space. In a PDSE, a single member takes up one 4096 byte page at a

minimum. A page cannot be shared by more than a single member. This makes

this a relatively costly option when considering disk usage. We also found that

accessing a PDSE library through our TSO sessions for edit or browse took

considerably longer than accessing the PDS files.

EXCP CPU SRB CLOCK SERV

4 x PDS 457k 25.68 0.08 176.00 66497k

4 x PDSE 463k 25.20 0.08 129.81 65254k

4 x PDS + EXITS 455k 25.21 0.08 111.98 65358k

4 x PDS + LLA 455k 25.07 0.08 101.47 64915k

4 x PDS + LLA + EXITS 456k 24.98 0.08 95.12 64761k

4 x PDSE + EXITS 455k 25.02 0.08 94.99 64871k

EXCP CPU SRB CLOCK SERV

EQQUX002 455k 25.37 0.08 95.49 65759k

Chapter 5. Using Tivoli Workload Scheduler for z/OS effectively 115

For example, our JCL consisted of four records: A jobcard that continued over

two lines, an exec card, and a steplib. For approximately 25,000 members, that

equated to 3330 tracks for a PDSE and only 750 tracks for a PDS.

Obviously from a space perspective, the cheapest option was the model JCL,

because all our jobs followed the same model, so only one 4-line member was

needed. More information about the JCL fetch exits used, how to use them, and

where to obtain a copy can be found in Appendix A, “Using the EQQUX000 and

EQQUX002 exits” on page 177.

The use of LLA for the PDS directories

Some of the fetch time is attributable to the directory search. By placing the JCL

libraries under LLA, the directory search times are greatly improved.

The issue with doing this is the maintenance of the JCL libraries. Because these

libraries are allocated to a long running task, it is advisable to stop the controller

prior to doing an LLA refresh (alternatively, you can use the LLA UPDATE

command, as shown in the following note).

One alternative is to have a very small override library, that is not in LLA, placed

in the top of the EQQJBLIB concatenation for changes to JCL. This way, the

need for a refresh at every JCL change is avoided. The LLA refresh could then

be scheduled once a day or once a week, depending on the rate of JCL change.

The use of EQQUX000 and EQQUX002

The use of the exits saves the directory search from potentially running down all

the libraries in the EQQJCLIB concatenation by directing the fetch to a specific

library. In our tests, these libraries were all quite large, but had we used many

more libraries with fewer members in each, we would have recovered more time.

The use of model JCL is also one of the fastest methods of populating the JS file.

This has an additional benefit. If you can, as we did, have a single model of JCL

Note: An LLA refresh will allow changes made to the source libraries to be

picked up, but you can also use an LLA update command:

F LLA,UPDATE=xx

Where the CSVLLAxx member contains a NOFREEZE statement for the PDS

that needs to be updated.

Then another LLA update command, F LLA,UPDATE=yy, can be issued,

where CSVLLAyy contains a FREEZE statement for the source PDS library.

By doing the NOFREEZE and then the FREEZE commands, the need for an

LLA refresh is avoided