Output Message Summary

Following is a summary of output messaging process:

  1. The output message will start with a URBH DSECT. The URBH:

    1. Identifies the message as one sent by the Event Replicator for Adabas (URBHEYE).

    2. Identifies the version of DSECTs sent in the message (URBHVERS).

    3. Identifies the Event Replicator Server sending the message (URBHRPID and URBHRPNI).

    4. Gives the length of the entire message (URBHLENT).

    5. Includes a message sequence number by destination (URBHMSNR). This value identifies the sequence of messages sent to a destination.

    6. Indicates the time that the Event Replicator Server passed the message to the messaging system (URBHTIME).

    7. Indicates whether or not more data for the transaction will follow in the next message (URBTCONT).

  2. A URBT identifies the start of a transaction’s worth of replicated data. The URBT:

    1. Identifies the database in which the transaction was executed (URBTDBID).

    2. Identifies the related subscription (URBTSNAM).

    3. Identifies the transaction sequence number within a subscription (URBTTSNR).

    4. Identifies the number of records (URBRs) in the transaction (URBTRCNT).

    5. Indicates the time that Adabas processed the ET commit (URBTTIM).

    6. Indicates the time that the Event Replicator Server completed subscription processing for the transaction (URBTPTIM)

  3. A URBR identifies a record within a transaction. The URBR:

    1. Identifies the record that was updated (URBRFNR and URBRISN).

    2. Identifies the record sequence number within a transaction (URBRRSNR).

    3. Identifies the number of data elements (URBDs) related to this record (URBRDCNT).

  4. A URBD identifies and contains a before or after image of replicated data for one record. The URBD:

    1. Identifies the data element sequence number for within a record (URBDDSNR).

    2. Identifies the type of data (URBDTYP).

  5. A URBE identifies the end of a transaction’s worth of replicated data. Note: The end of a transaction’s worth of replicated data may also be identified by:

    1. Determining that the number of records (URBRs) received is equal to the number of records (URBTRCNT) in the transaction, and

    2. Determining that all data elements (URBDs) have been received for each record (URBRDCNT).

  6. A URBT will be sent prior to a URBR for the same transaction.

  7. A URBR will be sent prior to a URBD for the same record.

  8. A URBR will NOT always be followed by a URBD for the record. For example, if an error occurs that prevents decompression of the after image and there is no before image, a URBR will be sent with no URBD.

  9. The replicated data for one transaction may be sent in one or more messages.

  10. When the output message contains subsequent data for a transaction (i.e. the related URBT was in a previous message), the output message will start with a URBH followed by a URBC.

  11. Replicated data for different transactions may be sent in the same message.

  12. Replicated data for different transactions will NOT be interleaved. That is, all of the data for a transaction will be sent before any of the data is sent for a different transaction.

  13. Replicated data for different subscriptions will not be sent in the same message.

  14. A control message (URBS) will be sent during initialization of an Event Replicator Server.

  15. A control message (URBS) will be sent during normal termination of an Event Replicator Server.

  16. Sequence numbering (message sequence number, transaction sequence number) restarts at one after the restart of an Event Replicator Server.

  17. A second or subsequent transaction’s worth of data will only be put in the output message if the entire data related to that transaction fits in the remaining portion of the output message.

About Output Message Time Stamps

All timestamps given (URBHTIME, URBTTTIM, etc.) are in STCK format. The timestamps represent the machine time. Depending on the time zone settings in the operating system, this may or may not be the local time where the machine is located.

Note:
See IBM's z/Architecture Principles of Operation (SA22-7832-02), Chapter 4, Section "Time-of-Day Clock", and Chapter 7, "STORE CLOCK" for information on the STCK format. At the time of this documentation's publication, this IBM manual can be found at http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf.

The timestamps for the last update of a data record (URBRTIME) and the transaction commit (URBTTTIM) are generated by Adabas. The timestamps for the end of subscription processing for a transaction (URBTPTIM) and the send of a message (URBHTIME) are generated by the Event Replicator Server. If Adabas and the Event Replicator Server reside on different machines, then it depends on the configuration of these machines whether these timestamps are comparable or by how much they may out of sync.

Provided these timestamps are comparable, they can be used to determine at which points during replication processing delays occurred: between the commit of a transaction in Adabas and the subscription processing in the Event Replicator Server, or between the subscription processing and the sending of the message, or between the sending of the message and its arrival at the target application.