The checkpoint handling in Replicat is more straightforward as it includes logic to pick which one out of the two checkpoint information is of higher priority. The logic is as follows:

• If the Java Delivery is started after user manually performed an ADD or ALTER REPLICAT, then the checkpoint information held by Replicat process will be used as the starting position.

• If the Java Delivery is started without prior manual intervention to alter checkpoint (for example, upon graceful stop or an abend), then the checkpoint information held by Java module will be used as the starting position.

  For example, restarting a Java Delivery using Replicat at the beginning of a trail looks like the following:

  1. Reset the Replicat to the beginning of the trail data:

     GGSCI> ALTER REPLICAT JAVAREP, EXTSEQNO 0, EXTRBA 0

  2. Reset the Replicat

     GGSCI> START JAVAREP
     GGSCI> INFO JAVAREP
     REPLICAT   JAVAREP    Last Started 2015-09-10 17:25   Status RUNNING
     Checkpoint Lag       00:00:00 (updated 00:00:00 ago)
     Log Read Checkpoint  File ./dirdat/aa000000
     2015-09-10 17:50:41.000000  RBA 2702
     

     It may take a few seconds for the Replicat process status to report itself as running. Check the report file to see if it abended or is still in the process of starting:

     GGSCI> VIEW REPORT JAVAREP

     In the case where the Java Delivery is restarted after a crash or an abend, the last position kept by the Java module will be used when the application restarts.