Shutting down IMS by using the /CHECKPOINT commands

The way that IMS shuts down depends on which form of the /CHECKPOINT command you use. You can choose to specify the FREEZE, DUMPQ, or PURGE keyword, and each keyword shuts down IMS differently.

The forms of the /CHECKPOINT command are:

Subsections:

Shutting down IMS by using /CHECKPOINT FREEZE

The fastest way to terminate IMS in an orderly way is to use the /CHECKPOINT FREEZE command. Using the /CHECKPOINT FREEZE command, you allow IMS to complete input and output messages that are in transit. Then IMS:

  • Stops each communication line
  • Terminates VTAM® sessions
  • Terminates message regions as soon as the messages currently being processed have completed
  • Returns status code XD to batch message regions when they next issue a DL/I checkpoint call

In a DBCTL environment, IMS notifies the CCTL of the /CHECKPOINT FREEZE command so the CCTL can disconnect from its connected resource managers. The CCTL controls how long its CCTL threads can continue processing before the disconnect occurs. For example, the CCTL might let all its threads reach a sync point.

During shutdown, IMS also closes message queue data sets and databases, and writes checkpoint data to the OLDS, just as for a simple checkpoint. IMS issues message DFS994, which contains the last checkpoint ID, and closes the OLDS. IMS updates the checkpoint ID table to reflect the shutdown, and writes it to the restart data set (RDS). Then IMS closes the RDS and terminates the IMS control region.

During normal shutdown, IMS tells CQS to shut down. If you do not want CQS to shut down, specify the NOCQSSHUT keyword on the /CHECKPOINT command. If you are shutting down a single IMS subsystem in a sysplex in order to activate a system definition, change a parameter specification, or for reasons that are not related to the CQS subsystem, you do not need to shut down the CQS address space. By leaving the CQS address space active after IMS has shut down, CQS can continue to participate in structure checkpoint, overflow, and rebuild events.

Recommendations:
  • Ensure that the CQS address space is active during structure checkpoint processing. During a structure checkpoint, z/OS® deletes log records that are no longer needed for structure recovery, thus reclaiming log space. If CQS is not active during the structure checkpoint, it is possible that the CQS restart log records will be deleted. In this case, the next restart for the CQS address space must be a cold start. You must respond COLD to WTOR message CQS0032A. If you choose to leave CQS up, you can reduce the number of times that CQS needs to cold start due to log record deletion.

    If CQS is active when IMS is started, IMS reconnects to the existing CQS and does not need to wait for CQS initialization and restart to complete.

  • Although using the /CHECKPOINT FREEZE command is the fastest way to accomplish an orderly shutdown, you should not use it regularly for normal system termination. When you use the /CHECKPOINT FREEZE command, end users might not receive responses for extended periods of time (until you restart IMS). IMS also rejects Fast Path input messages during shutdown. If during restart, IMS must load the message queues from the log to the message queue data sets (a BUILDQ), you might need to access previously archived OLDSs (to isolate the last DUMPQ or SNAPQ checkpoint).

Shutting down IMS by using /CHECKPOINT DUMPQ

The /CHECKPOINT DUMPQ command requests an immediate shutdown. Using the /CHECKPOINT DUMPQ command, you allow IMS DB/DC or IMS DCCTL to complete input and output messages that are in transit. Then IMS:

  • Stops each communication line
  • Terminates VTAM sessions
  • Terminates message regions as soon as the messages currently being processed have completed
  • Allows Fast Path message-driven regions to process all received messages before terminating
  • Returns status code XD to batch message regions when they next issue a DL/I checkpoint call

In a non-shared-queues environment, IMS writes the contents of the message queues to the system log along with checkpoint data. In a shared-queues environment, IMS does not dump the shared queues during shutdown.

The cost of executing a /CHECKPOINT DUMPQ command over a /CHECKPOINT FREEZE command is the time it takes to dump the queues; this time varies depending on the system design, transaction volumes, and activity at a specific time of day.

Shutting down IMS by using /CHECKPOINT PURGE

Using the /CHECKPOINT PURGE command is the most time-consuming method of terminating IMS. As the result of the /CHECKPOINT PURGE command, IMS stops each input communication line as soon as it receives any messages that are in transit. IMS then:

  • Processes all messages in the input queue, if possible (if the transaction and program are not stopped)
  • Transmits all output, if possible (if the line and terminal are not stopped)
  • Stops output communication lines after it has terminated all active regions and has sent all possible output messages
  • Terminates VTAM sessions

IMS writes any unprocessed input messages and any untransmitted output messages to the system log along with checkpoint data.

For an IMS DBCTL environment, the /CHECKPOINT PURGE command operates exactly like the /CHECKPOINT FREEZE command, except that the IMS DBCTL system waits for BMPs to complete their processing.

Forcing an acceleration of the shutdown process

All three variations of full shutdown (/CHECKPOINT FREEZE | DUMPQ | PURGE) allow transactions that had already been started to complete, and allow BMP programs to run to their next checkpoint. These commands might also allow CCTL threads that had already been started to complete. In some cases, you might have to wait a long time before IMS finally shuts down. For example, a conversational transaction or CCTL might be waiting for an end user to enter a response; or a long BMP program might not take any checkpoints.

If necessary, you can force shutdown (although some work might be lost). You can use various forms of the /DISPLAY or QUERY command to discover what work is still running. Then, you can use other commands to force shutdown (for example, the /EXIT, /IDLE LINE, or /STOP REGION commands).

If all else fails, you can bring down IMS by issuing a z/OS MODIFY IMS,DUMP command or MODIFY IMS,STOP command.

Attention: Only use the z/OS MODIFY IMS commands as a last resort, because you must immediately enter an emergency restart (/ERESTART) command and shut down again before you can run batch jobs.

IMS shutdown considerations

If automatic export to the IMSRSC repository during IMS shutdown fails, IMS is not allowed to shut down. A DFS4391E message is issued to indicate that IMS cannot shut down because automatic export failed. The error must be resolved and shutdown reissued so that automatic export can complete and IMS can shut down. Or, you can issue the UPDATE IMS command to set AUTOEXPORT(N) and retry the shutdown to allow IMS to shut down. If you need to cold start IMS when automatic export has not been done, see the procedures for retrieving the resources to be exported from the IMS log by using the Create RDDS from Log Records utility (DFSURCL0) and the EXPORTNEEDED parameter.

When an IMS shutdown command is issued in an IMS that has autoexport to repository enabled, the DFS4370I message is issued before the autoexport to the IMSRSC repository is started by IMS. The DFS4370I message indicates that IMS shutdown is checking for resource and descriptor definitions that have been created or updated and should be autoexported to the repository. The message indicates that IMS shutdown processing has not yet started.