Scheduling transactions using the suspend queue

Messages can be placed on or removed from the suspend queue based on conditions that you describe. An example of these conditions can be user abend U3303, which occurs when a message attempts to access unavailable data, and USTOPPED transactions, which is when a transaction is stopped because most messages being processed are failing because they are encountering unavailable data.

When scheduling transactions using the suspend queue, you must describe the following:

When messages are placed in the suspend queue

If the program processing the message attempts to access data in a database that is unavailable, and the program has not issued the INIT call indicating that it can accept a status code that data is not available, the program is pseudoabended with abend U3303. The disposition of the message in process at the time of abend U3303 depends on whether the transaction type being processed requires serial processing. If the transaction type does not require serial processing, the failed message is placed in the suspend queue. If the transaction requires serial processing, the message is returned to the normal queue and the transaction is USTOPPED.

Data might be unavailable for any of the following reasons:

  • The database is stopped, locked, or not available for update.

    Programs are scheduled even when full-function databases are not available, or when they are available as read only. If a program issues a DL/I call that requires access to one of these databases, the program encounters unavailable data.

  • A lock on the data cannot be obtained because it is held in retained state.

    In a block-level data sharing environment, it might not be possible to communicate with the sharing system because the sharing IMS has failed, the sharing IRLM has failed, or communication with the sharing IRLM has failed. The IRLM being used by the surviving IMS system retains knowledge of the locks that were held by the IMS system with which communication is temporarily unavailable. These locks are held in retained state. A similar condition can exist in a DBCTL environment when a thread failure occurs.

  • In an XRF and block-level data sharing environment, the takeover system initiates new work before the data sharing configuration is revalidated.

    At the time of an XRF takeover, databases that can be shared at the block level are temporarily made unavailable until the data sharing configuration has been revalidated. If programs attempt to access these databases before the revalidation completes, they encounter unavailable data.

When messages are removed from the suspend queue

A separate suspend queue exists for each transaction type. Messages are never scheduled for processing from the suspend queue. To be scheduled, the message must be transferred to its normal queue. Some conditions cause the messages on suspend queues for all transaction types to be transferred to their normal queues. Other conditions cause the messages for specific transaction types to be transferred to their normal queue.

The conditions that trigger the transfer of all messages from the suspend queues, and the rationale for transferring the messages when that condition occurs, are:

  • The /DEQ SUSPEND command is issued.

    The operator requested it.

  • IMS emergency restart is completed.

    While the IMS system is down, a sharing IMS might notify the system to drain its suspend queues.

  • A sharing IMS system notifies the system that the sharing IMS system has completed an emergency restart or a batch backout.

    Messages are transferred for the same reason as when these conditions occur on the local system.

  • IRLM is reconnected.

    When the IRLM failed, messages that were in process at the time of failure were abended with abend U3303. Attempts to access data that the failing IRLM locked also result in abend U3303. When the IRLM is reconnected, these messages are scheduled again.

  • XRF takeover has completed.

    While the takeover is in process, a notification from a sharing IMS might have been missed, and databases that can be shared at the block level are temporarily unavailable until the reverification to DBRC has completed.

The following conditions trigger the transfer of messages for specific transactions to the normal queue:

  • A /START TRAN command is issued. This causes the messages for the started transaction to be transferred to the normal queue from the suspend queue.
  • A /START DATABASE command is issued. This causes the transfer of messages for transactions in which the program processing the transaction has access to the started database.