gtpm3m0lMulti-Processor Interconnect Facility Reference

Sequence Number Control

MPIF operates in and supports a highly parallel environment. Users of MPIF can issue functions such as SEND almost simultaneously in uniprocessor machines. MPIF is designed to deliver messages in the same sequence that they were provided to MPIF, but the highly parallel environment can cause the illusion that messages are delivered out of sequence. If a single ECB issues two SEND requests, the first data block will be scheduled for the user at the other end of the specified connection before the second data block. That first data block might not get processed first. For example, an E-type data received exit might invoke some TPF macro which has enforced an implied wait. The second data block, in the meantime, could be passed to the same Exit under a different ECB and the execution of the same TPF macro might not enforce an implied wait this time; therefore, processing of the second data block could progress ahead of that for the first data block--it could very well get processed out-of-sequence.

Another example of a sequence that can occur is the invocation of a connect complete or error or data receive exit associated with a connection after the user has issued DISCONNECT. This can occur because the user had not quiesced SEND activity or because the exit was scheduled before the DISCONNECT was processed.

The MPIF SEND function will assign a connection sequence number. This number is passed to the issuer of SEND and to the user data receive exit. This connection sequence number is a 32-bit unsigned number associated with a specific connection that begins with 1 and wraps to zero. When multiple SENDs are issued for the same connection (that is, the user at the other end of the connection), the sequence numbers will be unique and increase by one. Any discrepancy might be indicative of an out-of-sequence condition or a failure relating to the connection.