LongEx Mainframe Quarterly - November 2013
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? LanguageYes, 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 OutputIf 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. Controlz/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. ConclusionIn 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. |
