Longpela Expertise logo
Longpela Expertise Consulting
Longpela Expertise
Home | Press Room | Contact Us | Site Map

LongEx Mainframe Quarterly - November 2013

opinion: Why I Love Batch

Batch has to be the most under-rated feature of z/OS. Sure, z/OS is reliable, fast, stable and secure. Yes, it certainly does have the best performance, accounting and security statistics recorded, and amazing tools for diagnosis and analysis - all with the base product. But batch rarely makes the list. And batch is magnificent.

The basic concept behind batch is simple: perform multiple tasks in the background while online users are sleeping or doing something else. Think backups, housekeeping, end-of-day processing, or report and statement production. Most finance and insurance companies have a huge amount of processing that must be performed regularly, and without someone sitting at a desk hitting keys.

Now z/OS isnít alone with batch. Most other operating systems will have something similar. Windows has BAT files that can be scheduled to run, and UNIX can execute scripts at set times or frequencies with the AT and EVERY commands. So why is z/OS so good?


Yes, Iím talking about JCL. Sure, Windows has BAT files, and UNIX has script. But JCL just kills them, and we all take it for granted. Think about it.

JCL is simple. Really simple. An execute statement, and a few DD cards with input and output destinations. Look at a JCL job, and you can quickly see whatís happening. If youíve every wandered through BAT or script files, this often isnít the case. But that doesnít mean that JCL isnít powerful. JCL today has IF THEN statements and conditional processing depending on the return code of previous steps. You can include other JCL, and even have commonly used procedures included.

UNIX users love to tell how great pipes are. And theyíre right. But JCL has had pipes for decades Ė they just look different. Output from one step can easily be supplied to another step. With Virtual I/O (VIO), this can be kept in memory for better performance. BatchPipes adds a layer where one batch job can start processing output before the job creating the output has finished.

And I love DD statements. Stay with me here. With Windows BAT and UNIX scripts, it isnít obvious what external references there are. Take a UNIX script file that is 200 lines long, and tell me quickly what files it uses. Itís not easy because the file names are embedded in the code. JCL Ė theyíre in DD statements. Itís easy to see whatís being used. Yes, I know what youíre about to say: what about dynamic allocation. Well look at the JES job output, and you can see details on these as well. Which brings me to Ö

Job Output

If you want to see what happened to a BAT or Script, youíll hope that the programmer tells you, and writes something to a file that you can find. z/OS batch Ė itís all there waiting in the JES spool. Return codes, performance statistics (depending on the IEFACTRT exit installed by the Systems Programmer), datasets used, and even the original JCL. And itís waiting on spool Ė a central point. No need to trawl through BAT/Script files, or go wandering around directories looking for that output file. Just look at the Spool. And this makes archiving any output just so easy. There are many products that will automatically take this output and store it, removing old versions when no longer needed. Try doing that on Unix/Windows for every batch task.

Output sent to printers is also easy to track, thanks to that JCL output on the spool. Never wonder where your batch output has gone.

But thereís even another layer here. Look in the z/OS console Ė you can see every job that started and ended, including who submitted it, what time, and what happened. Canít do that on Windows/UNIX.


z/OS just kills Windows/UNIX when it comes to controlling batch. You can limit how many jobs can run at one time, determine who can and cannot submit batch, and how long the job is allowed to run. You can limit the CPU and memory a job can consume, and set the dispatching priority lower than online. Ok, UNIX has the Ďniceí command to put batch behind online, but z/OS still wins. You can manage priorities of groups of jobs, so important ones get more, less important ones get less. With WLM, there are so many ways you can control batch priorities.

But you donít need to be a systems administrator to control your batch. Have a few batch jobs that you want to run one after the other? Call them the same name. Want to submit batch to confirm that all is OK, but not run them until youíre ready. No problem, hold the job. Want a job to run after something else has finished with a dataset. Just allocate it DISP=OLD in your JCL. Simple, but powerful.

A lot of this functionality is provided by JES (JES2 or JES3). And their features are impressive. One of the best are the APIs for other software to see jobs submitted, the results of these jobs, and the output produced. For example, automated job schedulers have clear APIs to automatically submit jobs based on criteria like time, results of previous jobs, whether other systems are up or down, or day of week. These can also see the results of jobs submitted, and process accordingly. Similarly software can automatically manage output from jobs based on JES criteria like class and destination. So you can print it, archive it, or remove it. Automatically. Sure, thereís some software that tries to do the same on Windows or UNIX, but it doesnít have half the functionality of z/OS based software.

And JES goes further. Want the job to run on another system? JES can do that automatically. Want to load balance, running the job on the system with the most spare capacity. JES and z/OS WLM can do that. Want to automatically route output to the appropriate system? JES can do that.

And letís talk about SDSF. Brilliant software to see the batch jobs running, waiting to run, and already run. Not to mention view and manage job output. A couple of clicks, and you can delete the output, send it to a printer, or save it to a dataset. Just fantastic.


In many ways z/OS was designed from the ground-up for batch. In the early days punched cards were the norm, and online access was secondary. So itís no surprise that z/OS batch is strong. But it goes much further than that. Iíve seen sites that transfer files from other operating systems to z/OS to take advantage of the batch facilities. Iíve often wondered what large UNIX and Windows sites do for their batch processing. Most seem to rely on database or application environment features for batch-style processing, or possibly use other software products. But all these fill operating system gaps that can't be found in z/OS.

Yes, I like z/OS batch. I like it a lot.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.

Inside This Month

Printer Friendly Version

Read Previous Articles

Longpela Expertise know about mainframes and the mainframe market. We can help managers, journalists and architects with their mainframe questions, projects and problems. Contact us to get your own independent mainframe expert.
© Copyright 2013 Longpela Expertise  |  ABN 55 072 652 147
Legal Disclaimer | Privacy Policy Australia
Website Design: Hecate Jay