Scott, In a message dated 97-09-19 10:23:06 EDT, you write: > In a message dated 97-09-16 22:38:35 EDT, > Dean writes: > > <<No, it's not apparent. But that's how > _I_ learned embedded SQL -- someone > else started writing in it. Commitment > control can be reduced to a list of > less than 10 rules that someone starting > out needs to know, with emphasis on > how to handle it in an ABEND situation>> > > ---------- > > At least you had some sample code to learn > embedded SQL from ;) > > However, for my own information, I'd be > very interested in seeing Dean's "Top Ten > rules for commitment control." I'll do what I can, although I don't seem to be able to read the documents that I wrote on commitment control on my NT machine (I wrote them over three years ago on a 3.1 machine). Note that rules may have changed since I was last involved, V3R0M05. First, a primer. Commitment control ensures data integrity by allowing the user to "undo" any changes that they have made to ALL files if I/O should fail on any ONE file. Commitment control requires that the affected files be journaled. 1. The commitment environment must be established for the job using the CL command STRCMTCTL. LOTS of new parameters here, so make your own evaluation. Use a CL to call the program, or modify your menuing system to handle. 2. You must specify, using a K extender, which files in your RPG are to be affected by commitment control (ehhh, we HAD no ILE back then, anyone with ideas on CC under ILE?). 3. CAREFULLY consider whether or not embedded SQL statements within your program should be under commitment control, and compile the program with the appropriate COMMIT keyword. 4. Establish a "commitment block" prior to writing to or updating any files. Place a COMIT statment up front, and another after, all writes/updates are successful. 5. Create a sub-routine to "undo" the changes using ROLBK. 6. I know most of us don't do it, but monitor for failures on your write and update routines (hey, the disk sector COULD go bad), and call your ROLBK routine if an error is detected. 7. Include your own "execution error handler" (*PSSR) routine in all programs using commitment control that calls your ROLBK routine. If a user ends their job, even through the system error handler, successful changes are automatically COMITed. 8. Do not waste the resources journaling *BOTH images for commitment control. Any program opening a file under CC automatically changes the journaling to *BOTH. 9. Pay attention to programs upstream (such as in-house API's) within a given jobstream that may be performing changes that are NOT under commitment control! 10. I DID say that there were less than 10, didn't I? Seriously, these should give you a good start. But it HAS been three years since I had a project using commitment control. Others feel free to append, especially as it relates to ILE... Regards, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@AOL.COM "Everywhere is walking distance if you have the time." -- Steven Wright +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MAJORDOMO@midrange.com | and specify 'unsubscribe MIDRANGE-L' in the body of your message. | Questions should be directed to the list owner/operator: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.