Re: Legacy code -Reply -- MIDRANGE-L

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: david@midrange.com
+---