IMS Program Restart Facility features

Automatic job restart

Automatic job restart is the central feature of the product IMS Program Restart Facility. This feature provides automatic assistance when an IMS batch job is resubmitted after an abend or job failure. IMS Program Restart Facility automatically determines the proper checkpoint for restarting the BMP or DLI batch job, dynamically allocates the required log data sets to enable restart to occur, and passes the restart checkpoint ID to IMS. IMS then performs a restart from the checkpoint ID provided by IMS Program Restart Facility.

IMS Program Restart Facility requires that your IMS batch job already have checkpoint and restart logic coded in your application program. IMS Program Restart Facility automates the manual process of allocating the appropriate IMS logs and specifying the proper checkpoint ID required to restart the job.

IMS Program Restart Facility enhances restart processing by saving restart checkpoint data in small DASD data sets called checkpoint tracking data sets (CTDSs). Saving the restart checkpoint data allows job restart to occur without the need to mount old IMS logs, or manually code IMS log data set names and volume serial numbers in the JCL of a restarted job.

Checkpoint tracking data sets contain all the data necessary to restart a job, so you can restart a BMP on either the same IMS system it was connected to when the abend occurred, or on a different IMS system in the IMSplex. IMS Program Restart Facility IMS group definitions can enable IMS Program Restart Facility to automatically select an active IMS system from the IMSplex, changing the IMS system that the BMP connects to automatically.

IMS Program Restart Facility also enables a BMP or DLI batch job to be restarted under a different IMS version that it abended under. Because the IMS base product does not support restarting a batch job under a different release of IMS, this IMS Program Restart Facility capability enables an easier migration path when upgrading to a new version of IMS. You can abend any BMPs or batch jobs that are running, upgrade IMS to a new version, and then restart the batch job without any complications because of the change in IMS release. You can also abend IMS batch jobs, switch from a new version of IMS to an old version, and then restart the batch jobs. This capability, however, is only available for IMS Version 10 and later.

Abend retry tables

You can use abend retry tables to define which abend codes represent transitory errors, and have the IMS batch job automatically recover from the abend and automatically restart. You do not need to resubmit the job.

For example, suppose that a job ends abnormally because of a U0775 abend. This abend occurs for an IMS BMP when the PI pool space is exhausted. Normally, the BMP would abend, the job would terminate, and manual intervention would be required to set up the job for restart and resubmit the job.

For this example, you can specify that IMS Program Restart Facility should detect and automatically retry U0775 abends. In this case, IMS Program Restart Facility would intercept the U0775 abend and retry the abend. IMS Program Restart Facility will automatically reattach to IMS, perform a restart of the BMP, and the BMP will continue processing. This process would occur with no intervention from any production job control personnel.

There are other abends that can be automatically retried, such as database record deadlock conditions. You can specify any system or user abend code that you want IMS Program Restart Facility to automatically retry.

IMS groups

You can define IMS groups to IMS Program Restart Facility. IMS groups allow IMS Program Restart Facility to automatically select an active IMS system under which a BMP runs.

For example, suppose that IMS1 is coded as the IMSID in a BMP job. However, you have three IMS systems that share the databases that are used by IMS1. If IMS1 is not available on the system that JES selects to run the job, IMS Program Restart Facility uses IMS group definitions to select any of the three IMS systems where the job could successfully run.

IMS groups reduce the amount of manual intervention that is required to change the IMSID parameter that is coded in the JCL of the job. IMS group selection can be used when a job is initially submitted, or when a job has ended abnormally and is being restarted.

An IMS group should include only IMS systems that are at the same IMS release level because the IMS RESLIB in the JCL of the job must match the release of IMS that is associated with the IMS ID used by the BMP. If IMS Program Restart Facility chooses an IMS ID at a different release level than the IMS RESLIB data set in the JCL of the BMP, an abend occurs during IMS initialization.

Bypass checkpoint processing

IMS checkpoints are the basis of recovery for IMS batch jobs. Application programs must initiate IMS checkpoint calls at unit of work boundaries so that proper backout can occur. Unfortunately, IMS checkpoints can be resource-intensive operations, possibly requiring significant machine resources and processing time. If application programs do not implement easy ways to control how often checkpoints are taken, altering how often checkpoints are taken can require application program coding changes.

IMS Program Restart Facility provides the capability to skip checkpoint calls that are issued too frequently, reducing processor usage and improving job elapsed time and system performance. You enable bypass checkpoint processing by enabling the BYPCHKP option and setting a bypass checkpoint interval in the BCDINTVL option. The bypass checkpoint interval specifies a minimum time interval that the IMS Program Restart Facility allows between checkpoints. If an application program makes a checkpoint call twenty times per second, and you specify a bypass checkpoint interval of one second, IMS Program Restart Facility causes nineteen of the checkpoints to be bypassed.

MVS™ operator commands

Similar to the IMS /STOP REGION command for BMPs, IMS Program Restart Facility commands can be used to stop DLI and DBB type batch jobs, as well as BMP jobs, at the next checkpoint call.

You can also pause a BMP. This can be useful if you must create a sync point for a database recovery or the IMS Program Restart Facility HOLD command causes the job to abend, although the job does not end. When the HOLD command is issued, IMS Program Restart Facility waits for an XRST command, IMS Program Restart Facility reattaches to IMS and allows the job to restart and continue processing. This process occurs without any user intervention other than the issuing of the HOLD and XRST commands.

Program testing options

Application programmers can use IMS Program Restart Facility to test restart logic. IMS Program Restart Facility provides the capability to force an abend after a specified checkpoint number is taken. After the abend occurs, application programmers can use the next execution of the job to test the restart processing logic of the program.

Application programmers can use the CHKPCNT, CHKPCMP, and FABXRST options to control when an abend occurs, the abend code that is issued, and whether a restarted program ends abnormally again.

//IRT$CNTL DD  *
CHKPCMP=3619
CHKPCNT=12
FABXRST=NO
/*

In this example, the statements will cause the program to abend with a U3619 abend code after the 12th checkpoint call completes. After the program restarts, it will complete without abending.

IMS PROC overrides

IMS Program Restart Facility can automatically override IMS PROC parameters that are used to pass options to IMS. For example, you can set parameters such as DBRC, IRLM, and IRLMNM on a job or global level, and the values that are entered in the IMS Program Restart Facility options will automatically override the values that are set in the JCL of the job. This feature can be useful if DBRC or IRLM is being implemented for the first time in your environment.

You can use IMS Program Restart Facility to override 16 different IMS PROC values without changing the JCL of any job.

Automated batch backout

When a DLI or DBB type batch job ends abnormally, timely batch backout is critical to releasing locks that are held on any database records that were updated since the last checkpoint. IMS Program Restart Facility enhances IMS DLI and DBB batch processing by intercepting any abends, and automatically closing the abended IMS log and performing an IMS batch backout. This capability not only improves database availability, but reduces the manual intervention that is required to code JCL to perform the batch backout and run the backout.

If a system fails while a DLI or DBB batch job is running, IMS Program Restart Facility initiates batch backout processing when the job is resubmitted.

IMS batch log data sets

IMS Program Restart Facility provides the capability to automatically change the IMS log data sets that are coded in the JCL of the job by altering the IEFRDER and IEFRDER2 DD statements.

IMS Program Restart Facility can automatically deallocate the logs that are specified in the JCL of a job, and specify different data set names, space allocations, retention periods, or SMS management classes, among other options. You can enforce data set naming conventions, convert to new SMS storage or management classes, or change the unit name that is allocated to the IMS logs. You can make these changes by updating IMS Program Restart Facility options, which can be done globally or for selected jobs, and without updating any application JCL.

IMS Program Restart Facility message output

By using IMS Program Restart Facility 2.2, you can set the SHOWOPTS option to PRINT. When this value is set, IMS Program Restart Facility dynamically allocates DD name IRTPRINT (if the DD is not already present in the JCL of the job) to the SYSOUT class that is specified in the SYSOUT option.

When SHOWOPTS=PRINT is specified, IMS Program Restart Facility writes more option information and status messages to the SYSOUT file. When SHOWOPTS is set to other values, IMS Program Restart Facility writes selected messages to the JESLOG of the job. All error messages are always written to the JESLOG of the job, but the IRTPRINT output provides more option and status information when SHOWOPTS=PRINT is enabled.

Checkpoint insertion

In a 24x7 operating environment, most of the databases in the production environment must be operable 24 hours a day for 365 days a year. Therefore, many users find it necessary to migrate their DLIBATCH programs, which are run during the maintenance period, to BMP programs, which run in IMS online systems. To release the database resources to other programs, batch programs in data-sharing environments and BMP programs that run in IMS online systems need to issue checkpoint calls more frequently than regular batch programs.

However, many DLIBATCH programs that do not assume to be run in those environments are not coded that way; they do not have any or enough processes to issue checkpoint calls. So, if you want to migrate DLIBATCH programs to BMP programs, you might need to modify those programs to add more commit points.

By using the checkpoint insertion feature of IMS Program Restart Facility, you can add checkpoint calls dynamically without having to change the programs. This feature supports applications that do or do not currently issue checkpoint calls, so you can use it on various applications, such as the programs that are to be migrated from DLIBATCH to BMP or those that require more checkpoint calls.

For more information about the procedures and considerations on this feature, see Inserting checkpoint calls dynamically.