IMS online cloning procedures
This section provides procedures for cloning IMS subsystems under alternative scenarios while IMS is online.
An online IMS subsystem clone is created by suspending the source IMS subsystem to achieve your point-in-time copy. By suspending the source IMS subsystem, pending database writes are forced to disk, update activity is suspended, and the log buffers are flushed to disk.
Status of transactions In Flight
An online cloning solution often results in transactions in flight. These in-flight transactions, which are cloned to the target subsystem, result in the same target subsystem action that would happen on the source system if it were shut down at that same time and then restarted. When you use online cloning, the target restart is essentially an emergency restart of a failed system.
The OVERRIDE option must be specified to the /ERESTART command. Also, the COLDCOMM option is required because IMS Cloning Tool does not support cloning message queues. When you do not clone the archive log data sets by specifying UPDATE-SLDS(N), you must ensure that system checkpoint exists in OLDS for the source IMS subsystem so that the target IMS subsystem can be emergency-restarted without needing to reference the archive log data sets.
unit of workor transaction can be in one of the following states:
- In flight : A transaction is in flight most of the time. The transaction on the target subsystem is backed out to the last commit point. Read-only transactions have nothing to back out.
- Commit: The transaction is in the process of taking a commit. The transaction updates on the target subsystem should be committed.
- Abort: The transaction is in the process of aborting. The transaction on the target subsystem is backed out to the last commit point.
- In-doubt: The transaction was committing and was between phase 1 and phase 2 commit processing. IMS does not know if the transaction should be backed out or committed. Manual intervention is required to either back out or commit the transaction.
Log data that is needed to back out a transaction should be contained in the active logs. It is possible that a back-out needs log data that no longer resides in an active log. In this case, archive logs are needed to successfully complete the back-out. Whether the archive logs are necessary for restart of the subsystem, and which logs are needed, depends on how large the active logs are. Running IMSSETLOG at a quiet time is recommended.