Channel message sequence numbering

The channel uses sequence numbers to check that messages are delivered in the same order as they are taken from the transmission queue.

Channel sequence numbers are checked when a channel is started and should a mismatch occur, it implies that persistent synchronization data has been lost on either side of the channel; for example, a disaster recovery (DR) configuration, or that end of batch processing was interrupted when the channel was in-doubt.

Resetting or ignoring sequence number mismatches, see IgnoreSeqNumberMismatch in Channels stanza of the qm.ini file, does not risk losing or duplicating a batch of messages, and it does not reset the in-doubt status of a channel.

This information can be displayed using DISPLAY CHSTATUS. The sequence number and an identifier called the LUWID are stored in persistent storage for the last message transferred in a batch. These values are used during channel start-up to ensure that both ends of the link agree on which messages have been transferred successfully.

Sequential retrieval of messages

If an application puts a sequence of messages to the same destination queue, those messages can be retrieved in sequence by a single application with a sequence of MQGET operations, if the following conditions are met:

  • All the put requests were done from the same application.
  • All the put requests were either from the same unit of work, or all the put requests were made outside of a unit of work.
  • The messages all have the same priority.
  • The messages all have the same persistence.
  • For remote queuing, the configuration is such that there can only be one path from the application making the put request, through its queue manager, through intercommunication, to the destination queue manager and the target queue.
  • The messages are not put to a dead-letter queue (for example, if a queue is temporarily full).
  • The application getting the message does not deliberately change the order of retrieval, for example by specifying a particular MsgId or CorrelId or by using message priorities.
  • Only one application is doing get operations to retrieve the messages from the destination queue. If there is more than one application, these applications must be designed to get all the messages in each sequence put by a sending application.
Note: Messages from other tasks and units of work might be interspersed with the sequence, even where the sequence was put from within a single unit of work.

If these conditions cannot be met, and the order of messages on the target queue is important, then the application can be coded to use its own message sequence number as part of the message to assure the order of the messages.

Sequence of retrieval of fast, nonpersistent messages

Nonpersistent messages on a fast channel might overtake persistent messages on the same channel and so arrive out of sequence. The receiving MCA puts the nonpersistent messages on the destination queue immediately and makes them visible. Persistent messages are not made visible until the next sync point.