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


Batch Modernization Redefines Application Development

Batch Window

Unlike a picture window that provides a nice view of a wooded area or secluded beach, the batch window has become progressively less tolerable as the demand for real-time access to most data has grown. Automated, timed processes remain important, but they often introduce challenges for interactive access to current data. The three main approaches to “closing” the batch window are:

  • Removing the need for certain scheduled activities
  • Making the window shorter
  • Teaching batch and interactive processes to work and play well together

Removing the need for certain scheduled activities eliminates the need to reserve resources to perform them. For example, Virtual Storage Access Method (VSAM) CA Reclaim, introduced in z/OS V1.12, eliminated the need for almost all of the application outages once needed to reorganize VSAM key-sequenced data sets and catalogs.

Making the window shorter is the focus of things like elapsed-time performance improvements to system utilities such as IEBCOPY and DFSORT. Batch also benefits from systemwide improvements such as High-Performance FICON* for System z* (zHPF), faster processors, HiperDispatch, and better memory management. Additionally, the capability to more quickly release locked resources for shared access helps shorten batch update cycles.

Teaching batch and online systems to play well together is a bit more challenging. The capability to hold resources for smaller increments of time, when appropriate, can allow mass-mode updates to proceed in stages with acceptably low impact to online response. For example, suppose a batch job needs to update 80 million rows of DB2 data. Committing a large number of them—say, 10,000 rows—at the same time is fastest, but this blocks database access for too long of a period. In z/OS V2.1 with DB2 9 and DB2 10, IBM plans to make it possible for Java programs to determine whether they’re causing contention and dynamically reduce their commit frequencies within the batch runtime environment. For example, a program used in batch could decide to commit every 10 rows to release its locks often enough to remove impacts to other processing where there was contention and commit more rows when no contention exists.

Peaceful Coexistence

Providing more programming models—those common across z/OS and other platforms—and providing ways to help close the batch window are approaches intended to extend the advantages of z/OS batch capabilities.

This can be done across an enterprise while making it easier to implement them, even as IBM strives to provide an environment wherein interactive and batch processes—once at war—can peacefully coexist. All of this new functionality vastly modernizes z/OS batch without sacrificing investments in existing applications or other z/OS qualities of service.

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