You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Batch Modernization Redefines Application Development

Batch is boring, right? Wrong! Look at it this way: Interactive is manual. Batch is automatic.

Let’s examine it further, starting with the definition of batch. Batch processing is usually another way to say, “automatic processing.” This need is met differently on various computing platforms. UNIX* has cron daemons, Microsoft* Windows* has scheduled tasks, and so on. Although ad hoc initiation of these processes is possible, this discussion will focus on automatic, scheduled processing.

It might seem like there’s nothing new or valuable about batch. But in recent years, with the emergence of new application frameworks such as J2EE and increased focus on online interactive work, application architects have developed a new appreciation for batch across the IT landscape.

Many years ago, architects designed data-processing systems based on batch and added online access later. Today, interactive access takes precedence, and batch has almost fallen out of favor. The time spent on batch was progressively reduced to provide less disruption for online access, leaving typically short batch windows for activities that couldn’t be overlapped as application architects focused more on how customers interact directly with their systems.

User experience is an important aspect of system design but equally important is focus on the system’s efficiency and scalability. This is where due consideration for batch programming is really needed.

Built on Batch

z/OS* technology has been built from the ground up with extensive support for batch, as any z/OS programmer knows. It supports a wide range of functions, including ways to reserve resources, manage capacity, prioritize work, provide accounting and auditing information, and synchronize data. This happens in coordination with online processing, for the most part. As the need to keep interactive data evermore current has grown, three major areas of focus became central to improving z/OS batch processing and making it more transparent:

  1. Improving the APIs for automated processing
  2. Creating cross-platform interfaces so automated processing can be cooperative across hybrid and multiplatform implementations
  3. Closing the batch window

Developing new means for customer interaction brings about many important and interesting problems and decisions related to the handling of mobile technology and securing data. The span of considerations can be nearly overwhelming from an application architecture standpoint. The process of developing new interaction models often carries implications for back-end processes. Many projects fail when the heavy lifting that can be done on a periodic basis by automated processing is ignored in favor of trying to do everything in real time. Frequently, the initial view is that these activities can be done by driving an interactive action iteratively. In some cases, this might work, but more often than not it leads to inefficient and costly operations that don’t scale well. For example, generating monthly bills, investment balances or end-of-day processing for a variety of industries are best left to automated, timed processes.

z/OS Application Programming Interfaces for Batch

The predominant API for z/OS batch programming is Job Control Language (JCL). Several JCL extensions were made in the past few releases to address a number of usability and availability issues with batch. For application programmers, the following commonplace capabilities have proven popular:

  • In-stream data in JCL procedures and include statements
  • Enhanced symbol substitution
  • Access to system symbols using JCL
  • Passing symbols between JCL and programs
  • Support for longer parameter strings

These aren’t exactly revolutionary, but they do help—as do job-level return codes, support for more job classes with longer names, increasing the amount of JCL common to JES2 and JES3, and being able to off-load more output data as both batch and interactive processes run.

Changes were made to allow more parallelism, both between batch and interactive work and across batch jobs. The capability to share completely processed volumes for multivolume data sets, share data sets once exclusive use is no longer required for them, and recall migrated data sets used in batch, in parallel, can simultaneously shorten batch windows and decrease contention for current data resources.

Gary Puchkoff is a senior technical staff member for IBM Z Strategy and Architecture.

John Eells is a former MVS and OS/390 system programmer who also worked in ServerPac design. Now a senior software engineer in IBM Systems, his current assignments include z/OS technical marketing, future release planning and strategy.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.


3 Points to Consider When Modernizing IBM Z


Making Sense of APIs and the API Economy

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters