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

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

5.3 Job streams in an end-to-end environment

The usual good scheduling practices apply equally in an end-to-end

environment. However, there is an additional constraint in that you should avoid

as much as possible references to other FTWs, and especially to the controller

on the mainframe. This has a significant impact on both performance and fault

tolerance. Two techniques for reducing this are:

 Do not use mainframe dummy jobs as placeholders at the beginning and end

of distributed job streams. Use jobs issuing a simple distributed command (for

example, echo) instead.

 Avoid having many jobs testing for a file or special resource. Instead, have

one “anchor job” dependent on the file or special resource, and make the

other jobs successors to it.

Keeping the Symphony file as small as possible is good for performance, not only

in terms of building and distributing it, but also in referencing it on the distributed

agent. In an end-to-end environment, the Symphony file contains:

 Jobs to be executed on the distributed agents

 Mainframe jobs that are predecessors to distributed jobs

Job streams that have at least one job in the Symphony file

Consequently, we can see that having many job streams, containing a mix of

both mainframe and distributed jobs, will have a significant impact on the

Symphony file.

5.4 Moving JCL into the JS VSAM files

This section defines the best methods for improving the rate at which Tivoli

Workload Scheduler for z/OS is able to move the JCL into the JCL VSAM

repository (JS files).

The JCL is fetched from the JS VSAM files when a job is being submitted. If it is

not found in the VSAM file, it is either fetched by EQQUX002 (user-written exit) or

from the EQQJBLIB data set concatenation.

Normally, the JCL is moved into the VSAM files immediately prior to submission;

however, this means that any delays in fetching the JCL are imbedded into the

batch window. To avoid this delay, the JCL could be moved into the VSAM file

earlier in the day, ready for submission. To be able to do this, you do need to

know which jobs cannot be pre-staged, for example, any JCL that is built

dynamically by some external process. You also need a PIF program that can do

this selective pre-staging for you.