Globalization has presented many challenges to the IT community, not least of which is providing continuous system availability. Where once an East Coast-based information center only needed to adjust for a West Coast transactional processing window, it now must deal with transactional windows half way around the world. Still, viable legacy systems were rarely designed for this, yet accommodations must be made, since many of those systems aren’t easy to replace.
IBM’s Information Management System (IMS) started out as Information Control System (ICS) in 1966 to manage data generated by the Apollo space project. ICS was renamed IMS 360 V1 in 1969 and was made available to the business community. Many changes have been made to IMS since, yet the basics of being both a transaction and (hierarchical) database manager remain. The system design can support continuous availability for IMS transactional applications while handling existing batch processing requirements.
IMS is a complex software family. This article examines how to convert batch jobs that access IMS databases to run as Batch Message Programs (BMPs). It’s not an IMS tutorial, so other aspects of IMS will be covered only to the extent they relate to this conversion process. The examples will refer to the z/OS (vs. z/VSE) operating system with COBOL as the primary mainframe language.
Basic IMS Further Simplified
An IMS subsystem consists of multiple address spaces running as jobs or started tasks on a mainframe operating system. There are two primary products, the database, known as IMS/Database Manager (IMS/DB), and the transaction processor, IMS/Transaction Manager (IMS/TM). These can be implemented together or separately. Here, we assume both components are available in the subsystem. All IMS address spaces, or regions, operating under an IMS control region are known as “dependent regions.” The IMS control region provides the interface of IMS to the operating system, network and other subsystems, schedules and dispatches programs running in the dependent regions, and supports logging and recovery functions.
Three types of batch jobs can access IMS databases:
- Regular batch jobs running as either a DLI or DBB using standard Job Control Language (JCL)
- A Batch Message Program (BMP) job.
This article will spotlight the more common DLIBATCH jobs, but most of the information will also apply to DBBBATCH jobs. What’s the difference between DLI/DBB and BMP jobs? The most striking is with IMS database access. IMS requires exclusive control of updatable databases to assure integrity. An IMS database must be taken offline—removing it from control of the IMS/TM—for a DLI job to add, delete, and update entries. Batch jobs that execute as BMPs run under the control region, which coordinates access, including locking, to the databases. This lets them remain available to the online IMS transactions. The control region will also manage logging and back out in case of an abend, removing that requirement from the batch jobs.
Our strongest reason for moving away from DLIBATCH jobs was the projected need for continuous availability of the IMS databases. Shutting down databases for six to 10 hours each night was becoming less acceptable as Web application access increased. We had complex scripts to automate stopping and starting of databases and disabling and enabling IMS transactions. Converting eliminated tracking, maintaining and scheduling of those scripts, and simplified recovery and restart. There were no execution time changes when the DLI jobs became BMP jobs.
What’s Needed to Convert