There are lots of parts to this The x'37' record is the QMGR sync point record. I am assuming your Fastpath work is not Fastpath exclusive ... that is you do not use EMH (Expedited Message Handler)
>From the database stand point is your work exclusivly Fastpath or mixed (Fathpath and full function). Both Fastpath and full function log prior to sync point completion, but Fastpath may defer phyisical database updates until after Syncpoint. This is one of the things that makes Fastpath 'fast' the dependent region is available to process the next unit of work, prior to the previous unit of work being externalized ... but this assumes you are running in a Fastpath exclusive region and have not gone into the overflow buffers. The x'5937' record is a fastpath sync point. A x'37' can occur after a x'5937' because a x'31' (DLI Get Unique) marks the begining of a unit of work. At x'31' time IMS does not know if there will be updates or not ... crystal ball technology has never been built into the the product. IMS assumes the x'31' marks a period of time it might have to back out to dynamicly in the case of an application failure or as part of restart in the case of an IMS crash. The time of the x'31' is recorded in IMS' restart table / dataset until such time as it is removed. What removes it? A sync point ie x'37'. Even non updateing batch work in IMS should take checkpoints for this reason. Now to complicate things even more within a fast path DEDB there is a special type of segment for Batch Sequencial Dependent Processing. Externalization of this data is processed diffrently than usual fastpath management as both logging and writing might be defered. The idea is a operator may be entering a batch of documents ... the data base record represents the batch, each occurance in the Sequencial Dependent Segment is a document (member of the batch) To handle this common bank back office condition with improved performance IMS Fastpath provides special support for this segment type. What is not clear to me is why your replication process is dependent on the sync point records at all. I would guess you should be obtaining the changed information from the x'5x' records full function or the x'595x' records fastpath. In the rare instance where the work does not reach syncpoint because of an abend or roll back but the updates have been logged there will be corresponding records recording the backout. You should contact the IMS-L listserver about this or you can talk to me off line. The IMS-L group has about 500 members and only a fraction of them know much about log record types and processing. I am somewhat out of practice my self but in the early 80's I designed the log analysis methods used by the Candle (now IBM) family of Omegamon IMS products. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html