You haven’t specified if you are using native I/O or SQL but the concepts are the same
1. Files must be journalled
2. Commitment control must be started prior to opening the files
Native – STRCMTCTL
3. Native each file to be updated must include COMMIT on the F spec
4. In your case an SQL or RPG Commit is issued after all four files are successfully updated
Your program should issue a rollback
Hope this helps – phil
Right – the commit determines where the updates are committed and become irevoable. For your example that is after field 4 If you capture an error on any file issue the rollback and do not proceed to the other files in the set.
No.. no trigger on commit or rollback
- I recommend capture each event through trigger
- capture commit / rollback event through direct write to Log file.
Wilson — that’s cool
Remember the trigger(s) will fire anytime that event occurs to the file(s) — other programs, sql, dfu or dbu.
If I remember correctly, this is one of those ugly flashbacks, you have to end the trigger before you can change the trigger program and they are all locked when the file is locked… and in my experience that was .. of course locked except during the maintenance window.
Wilson if there’s a mix of SQL and native … how does commitment control get started and commits/rollbacks get issued ???
First, the trigger “problem”…. The COMMIT keyword may have a parameter to activate it or not. You can change your trigger to activate the COMMIT only if it’s called by a program (there is many way to detect it) and that way when you use DFU, DBU, etc, no COMMIT will be done or controlled (remember that it’s necessary to activate commit control with the CL command). And you are right, to change a trigger program you must have exclusive access over the file.
Second, the SQL mixing… I’m not a SQL user but what I can remember is that it will work fine (we are talking about a mix in the same program right?). But as I said, I’m not an expert…