Long retry count (LONGRTY)

This attribute specifies the maximum number of times that the channel is to try allocating a session to its partner.

If the initial allocation attempt fails, the short retry count number is decremented and the channel retries the remaining number of times. If it still fails, it retries a long retry count number of times with an interval of long retry interval between each try. If it is still unsuccessful, the channel closes down. The channel must then be restarted with a command (it is not started automatically by the channel initiator).

(Retry is not attempted if the cause of failure is such that a retry is not likely to be successful.)

If the channel initiator (on z/OS®) or the channel (on distributed platforms) is stopped while the channel is retrying, the short retry count and long retry count are reset when the channel initiator or the channel is restarted, or when a message is successfully put at the sender channel. However, if the channel initiator (on z/OS) or queue manager (on distributed platforms) is shut down and restarted, the short retry count and long retry count are not reset. The channel retains the retry count values it had before the queue manager restart or the message being put.

Note: For IBM i, UNIX systems, and Windows systems:
  1. When a channel goes from RETRYING state to RUNNING state, the short retry count and long retry count are not reset immediately. They are reset only once the first message flows across the channel successfully after the channel went into RUNNING state, that is; once the local channel confirms the number of messages sent to the other end.
  2. The short retry count and long retry count are reset when the channel is restarted.

The long retry count attribute can be set from zero through 999 999 999.

This attribute is valid for channel types of:
  • Sender
  • Server
  • Cluster sender
  • Cluster receiver
Note: For UNIX systems, and Windows systems, in order for retry to be attempted a channel initiator must be running. The channel initiator must be monitoring the initiation queue specified in the definition of the transmission queue that the channel is using.