- z/OS file structures
- DFSMS on z/OS
- Data Class
- Management Class
- Storage Class
- Storage Group
- ACS routines
- z/OS file utilities
- z/OS SMF statistics
- z/OS RMF reporting
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 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 are unavailable. It was essential that this batch work completes as soon as possible, so the online services can 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 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