5 Quick Ways to Speed up Your z/OS Batch Without Application Changes

z/OS users understand that batch is still important. However, with pressure to reduce downtime and offer 24-7 online services, it seems we always need to reduce our batch window. Or in other words, make our batch jobs run faster.

The good news is that z/OS has a lot of features that may speed up batch, without needing any application changes. Let’s look at some of the features that are easier to implement, and see what they can do.

1. Less Time Waiting for HSM

If you’re using DFSMShsm (HSM) to archive unused datasets, then your batch jobs may spend time waiting for these datasets to be recalled. An easy way to resolve this is to modify DFSMS management class settings so datasets aren’t archived, but not everyone has this luxury.

A quick way to reduce HSM delays sounds trivial: ensure you actually need the archived datasets. HSM recalls all migrated datasets in JCL DD statements; even if they are never opened.

If you’re deleting an archived dataset, you don’t need to wait for it to be recalled. Most sites will have set the IEFBR14_DELMIGDS parameter of the z/OS ALLOCxx parmlib member to NORECALL. So, if you have a DD card that looks like this:

//DD1  DD  DSN=MY.DSET.TO.DELETE,DISP=(MOD,DELETE),SPACE=(TRK,1)

Then the dataset will be deleted immediately by HSM: no recall. The trick is that this only works if using IEFBR14. It won’t work if the job step calls another program, or if you use something like IDCAMS to delete the dataset.

By default, HSM recalls datasets one at a time as they are opened. So, if you have a job step that recalls five datasets, it would be nice to recall them all at the same time. Setting the z/OS BATCH_RCLMIGDS parameter of the ALLOCxx parmlib member to PARALLEL does exactly that.

Those with more than one z/OS system in a sysplex will want to consider HSM common recall queues. Enabling this feature allows other z/OS systems to recall your dataset if the local HSM is too busy.

2. VIO

Virtual I/O (VIO) has been a favorite way of speeding up batch for decades, and it remains an easy option to speed up temporary, non-VSAM datasets.

Many use VIO datasets in a single job step. However, VIO datasets remain active for the entire job. So, you could put data in a VIO dataset in one step, and then use that VIO dataset in another.

If you have a permanent dataset that is read by multiple batch steps, you may improve performance by first copying that dataset into VIO:

//INTOVIO  EXEC PGM=ICEGENER
//SYSUT1   DD   DISP=SHR,DSN=MY.PERM.DSET
//SYSUT2   DD   DISP=(NEW,PASS),DSN=&&TEMP1,UNIT=VIO
//SYSPRINT DD   SYSOUT=*
//SYSIN    DD   SYSOUT=*

This could then be accessed (faster) in later steps:

//DD1      DD   DSN=*.INTOVIO.SYSUT1,DISP=SHR

You may have noticed that this example is using a program called ICEGENER to copy our data. I’ll explain why shortly.

If you’re using z/OS UNIX datasets, a similar option to VIO is the /tmp directory. Most systems will have mounted the /tmp directory as a temporary filesystem (TFS). In other words, it remains in memory.

3. Less Waits or ENQs

If another job (or user) has exclusive access to a dataset, your job must wait: an ENQ wait. So, what can you do about this?

An easy solution is to speed up the job (or user) that has exclusive access to the dataset. The ERV parameters of the z/OS IEAOPTxx parmlib member can be set to allow tasks holding ENQs that are needed by other tasks to briefly get a higher priority.

Suppose you have a job that creates a dataset:

//STEP1    EXEC PGM=PGM1
//SYSUT1   DD   DISP=(,CATLG),DSN=MY.DSET,UNIT=SYSDA

Normally, the entire job will hold an exclusive ENQ on this dataset—even if all later steps only read the dataset, or don’t use it at all. We could speed things up by splitting the job into two. So, the first job includes the step to create the dataset and ends, releasing the exclusive ENQ). The second job has steps that read it: allowing other jobs and users to read the dataset at the same time.

An alternative is to use the z/OS features that allows this ENQ to be “downgraded” to SHR if subsequent steps don’t allocate it as exclusive. This can be enabled using the DSENQSHR parameter of the JOB statement. For example:

//JOB1  JOB  (ACCT),CLASS=1,MSGCLASS=X,DSENQSHR=ALLOW

Sites can also enable this for JES job classes by setting DSENQSHR on the JOBCLASS definition statement in the JES2 parameters.

4. Faster Dataset Copies

Batch jobs often copy datasets to create a backup, or a second copy that they can work on or process. If you’re using IEBGENER or IDCAMS REPRO to copy datasets, please stop.

For many years, DFSORT and SYNCSORT MFX have offered a much faster IEBGENER replacement that uses I/O features used when sorting: ICEGENER and BETRGENR respectively. Many sites have gone as far as creating an IEBGENER alias pointing to these better options, so you may be using them without knowing.

ICEGENER and BETRGENR can also copy VSAM datasets—usually faster than most other options, including IDCAMS REPRO.

An even faster option is DFSMSdss. It can copy compressed or encrypted datasets without decompressing/decrypting them first, and can use DASD subsystem features to create copies almost instantly using concurrent copy.

5. Faster Tape

Batch jobs often use tape. Many sites don’t use the z/OS Large Block Interface (LBI) that can increase the maximum blocksize from the 32kByte maximum for disk to values as high as 256kBytes. Many utilities now support LBI, including DFSMSdss and IDCAMS.

Tape mount delays can also slow down a batch job. There is a limit to the number of tape drives that can be used, so reducing the number of drives used may help. Suppose we are searching through three tape volumes. If we code:

//DD1  DD  DISP=SHR,DSN=TAPE1.DSET
//     DD  DISP=SHR,DSN=TAPE2.DSET
//     DD  DISP=SHR,DSN=TAPE3.DSET

Then z/OS will mount all tapes on separate drives, and then continue. We use three tape devices (waiting if three are not available), and hold them for the entire job. A better way would be to code:

//DD1  DD  DISP=SHR,DSN=TAPE1.DSET
//     DD  DISP=SHR,DSN=TAPE2.DSET,UNIT=AFF=DD1
//     DD  DISP=SHR,DSN=TAPE3.DSET,UNIT=AFF=DD1

Now, z/OS will only mount the first tape when the job step starts. It will mount the second tape on the same drive as the first when the first is no longer used. Similarly for the third drive. The big benefit is that we only use one tape drive: we only need to wait for one drive, and others are available for other batch jobs.

Ways to Faster Batch

These are a few easier features that z/OS provides to speed up your batch: none require application changes.
However, simply using these features may not necessarily improve your batch performance. If looking at speeding up batch, a first step is to analyze the performance, and find out what makes up its total elapsed time (i.e. time waiting for an initiator, waiting for dataset recall, or other reasons). Then, you can start tackling those bottlenecks, possibly using some of the features mentioned here.

---