Re: Commitment Control

[DAsmussen@xxxxxxx]

Brian,

In a message dated 98-11-01 17:30:54 EST, you write:

<<snip>>
> Can anyone give me a brief overview of commitment control?  
>  
>  Our files are already journaled, I just need to know how to code this
>  in my RPG program.

Be glad to oblige, just be aware that my practical CC experience dates back to
V3R0M05, so changes may have occurred in its' behavior and/or requirements
since.    First, (since you already have journaling in place) you must
establish the commitment environment for a job with the the STRCMTCTL command.
Parameters for the latter depend upon what you're trying the achieve.  Be
aware that, regardless of the type of journaling you have in place, it is
automatically changed to *BOTH for all affected files once you start a program
using commitment control.

There is a column in the RPG F-spec (can't remember off the top of my head,
RTM), that must be set to indicate that a given file should be opened under
commitment control in the program -- annoying to me, as I feel that _EVERY_
file open for update or output should _AUTOMATICALLY_ be open under commitment
control if STRCMTCTL has been run, and I just can't stand redundancy (unless
it's the "Department of Redundancy Department" of Monty Python fame).
Besides, if this requirement wasn't there commitment control could be
implemented on existing systems without program changes by "wrapping" COMIT
and ROLBK programs around old code.

Within your RPG code, you must establish a "commitment block".  This is done
by issueing a COMIT command prior to performing any updates of data.  Perform
all updates and/or writes, being sure to monitor for failure of any of them
(most legacy RPG programs fail to check for this).  If all updates and/or
writes complete successfully, issue a second COMIT to close the "block" and
update all records permanently.  If any update or write should fail, issue a
ROLBK to back out the changes.

BEWARE UNMONITORED FAILURES!!!  You _MUST_ include *PSSR routines in your CC
programs that will perform a ROLBK for unmonitored failures.  Otherwise, a
user taking a "C" will automatically COMIT your changes.  You should also be
aware that uncomitted changes will automatically be comitted upon the user
signing off the session.

Lots to look at and, as I said, the behavior could have changed since the last
time I used it.  Experiment where needed, and be proud to be writing a system
with higher data integrity than most AS/400 vendors provide!

HTH,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"Jimi Hendrix was the first rocker on the Internet, his modem was a purple
Hayes." -- Unknown
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *