Storage Techniques for tuning a z/OS Batch Run

Before we start,
What is a 'Batch job', what is a 'Started Task', what is a 'TSO user'?

A batch job is a piece of code that defines a program and all its input and output files. A batch job runs in the background, independently of the user or process that started it; in technical terms, it runs in its own address space. When a batch job completes it terminates and finishes.

A TSO (Time Sharing Option) user is a task that runs in the foreground and provides an interactive session between a user and the mainframe. A TSO user runs in his or her own address space too. 'Raw TSO' is a command line based facility that is rarely used these days. Most TSO people use ISPF, a panel driven interactive facility for processing files. You can use ISPF option 3.3 to copy data between two files, but as this is interactive you will lock out your TSO session until the copy completes. If you are processing a lot of data it would be better to copy the data with a batch job that calls an IEBGENER program or similar.

A started task is similar to a batch job, except that it does not terminate by itself, it runs on forever until it is stopped manually or when the operating system closes down. Started tasks are typically system or applications like CICS (a TP processor) DB2 (a database utility) VTAM (a network utility) or SMF (a system statistics gathering tool)

Online Transaction Processing (OLTP) is ideal for single transactions, processing data in real time, but batch jobs are best for running lots of repetitive processing, like the monthly salary run. Large IT systems used to have an overnight 'Batch Window', during which the online systems were unavailable. It was essential that this batch work completed as soon as possible, so the online services could be restarted. These days most shops run 24*7 systems but batch work will still be scheduled when the user workload is lightest. There are always deadlines to be met, for example, getting batch complete before the online day workload starts, or getting the bills out in the first mail run.

It is possible to make improvements to a batch run by changing programs, CICS settings, DB2 coding and other application programming techniques, especially as new features have appeared in recent versions of z/OS, but this section concentrates on operational areas.

When tuning a batch run, there are three basic operational areas to investigate:

Viewed from the Storage angle, most work is usually concentrated in the performance area, but a lot of simple improvements can be made in reliability and parallelism, and these are usually cheaper too! This article looks at the first two items fairly briefly, before going into performance tuning in some detail.

back to top

z/OS Storage and Datasets

Lascon updTES

I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has not been updated since July 2021, and probably will not get updated very much again. The site hosting is paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed to find something useful in there.
All the best