Re: dfsflgx0 COMMIT problem
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
Re: dfsflgx0 COMMIT problem
Hi Arie, This a pretty deep IMS question and you might get a better response on the IMS-L mailing list which does get good activity and is widely subscribed by a number of the IMS guru's. https://po.missouri.edu/archives/ims-l.html Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Arie Kremer Sent: Tuesday, April 04, 2006 6:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: dfsflgx0 COMMIT problem Hi all, we have our own dfsflgx0 IMS exit for IMS updates capture. We have a problem with an understanding of a commit process. We used x'37' record as a COMMIT. Sometimes, we did not received this record after UPDATE transaction in DEDB. We begun to use x'5937' solving the problem, but sometimes this record follows x'37', and occurs also when no updates having been done in a transaction (no x'99' in the log). What is the correct usage of these records? Please help Arie Kremer P.S. We tried to use SYNCPTYP flag in SYNCDCAP byte, but with no success. -- 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 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
