Re: RPGLE I/O opcodes with commit/rollback

Commitment control may be more popular with SQL because:
1 - The precompiler defaults to using commitment control. It at least got
people thinking about it, even if their only goal was to figure out how to
use SET OPTION to turn it off.
2 - Certain SQL operations, like CREATE SCHEMA, default to creating
journals and receivers so it just is a start.
3 - It's newer and you don't initially worry about 25 year old code and
the problems with integrating with that.

Journal receivers can consume disk space if not properly managed, or if
you start to get so enthralled by the auditing capability that you keep
them around for as long as we do. (Not saying it's bad, but the disk
salespeople love us.)
Receivers can add some overhead. There's way to code for this but we
chose to just purchase "HA Journal Performance" and that made a huge
impact!

I wanted to journal for years but it was always put off. Purchasing Mimix
opened the floodgates.

I suspect that many vendors do not implement journalling into their
packages to not be considered a "resource hog".

You kind of have to do this right. Ever do a bunch of interactive SQL and
signoff without doing the commit? Losing your work does not put me into
my happy place.


Rob Berendt