Requesting Ordered Delivery

Ordered delivery (IXCMSGOX DELIVERMSG=ORDERED) can be used to send messages between a particular pair of members in independently ordered streams. Both the sending and the receiving member must reside on systems that support ordered message delivery. If a message is sent to a member on a system not at the required level, the message is delivered as an unordered message. To avoid sending messages to a downlevel target member, the sender can issue IXCQUERY and examine the QUAMPROORDEREDDELIVERY field to determine if the target member resides on a system that supports ordered message delivery.

The sender can define multiple streams of ordered messages. Identify the stream to which a message belongs with the IXCMSGOX STREAMID parameter. The messages in any given stream are delivered in the order in which they were accepted for delivery; the messages in each stream are delivered independently from those in another stream.

To process ordered messages, XCF passes control to the message user routine. The routine must either receive the message or indicate that XCF is to save the message in XCF-managed storage. If the routine does neither, XCF discards the message when the message user routine gives up control. Once the message user routine gives up control, the next ordered message is eligible for delivery (regardless of whether the previous message was received, saved, or discarded). Note that the message user routine needs to process the message and return to XCF as quickly as possible. If the message user routine is suspended for any reason while processing an ordered message, the routine will delay the delivery of subsequent messages in the ordered delivery stream. Such delays could allow a large backlog of messages to accumulate. This, in turn, might cause XCF to reject message-out requests (local or on remote systems) that are targetted to this member.

Note that each stream is processed as a separate entity, so that a delay in processing messages in one stream does not affect the processing of messages in another stream nor of unordered messages.

Within the sequence of ordered messages to be delivered, “gaps” in the sequence might occur. These gaps could be the result of either XCF or application processing. In both cases, the multisystem application must be able to recognize that a gap has occurred. Two examples are:

XCF processing
A member sends messages A1, A2, A3 in order. Suppose that messages A1 and A3 are successfully transferred to the target system. XCF delivers message A1, but delays delivery of message A3 because message A2 has not yet arrived at the target system. In the meantime, suppose that the sending member decided to cancel message A2 before XCF was able to initiate the send or that the sending system failed before the transfer of message A2 was completed. XCF recognizes that message A2 cannot be delivered to the target system and so delivers message A3.
Application processing
A member sends messages A1, A2, A3 in order and all messages are transferred successfully to the target system. XCF delivers message A1, which is processed successfully by the receiving member. XCF then delivers message A2, but the receiving member fails to process the message correctly. XCF then delivers message A3. From XCF's perspective, message A2 had already been delivered, but from the application's perspective, message A2 is missing.

If the presence of gaps in the sequence is not tolerable, the application must provide its own protocols to react to a gap's occurrence. For example, the application might need to discard incoming ordered messages until the target member resynchronizes with the sender.

There could be multiple instances of a message user routine running, each under a different unit of work. It is not predictable which instance of the message user routine or which work unit will be given control to process the next ordered message in the stream.