×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I still think a competent programmer can handle this stuff, just like
we did
for YEARS before commitment control even existed.
You can't code for everything... really! I don't know of a single
opcode, ILE construct, job attribute, or anything else that will provide
me with an indication that the system-bus just died and the machine is
going casters-up because the CPU can't communicate with any disk
platters, but before it dies, I get a chance to delete the order-detail
row I just wrote. And don't say that doesn't happen on System I, I've
seen it several times. Commitment control in that case would undo that
update when the machine does come back up.
However, I would agree that just because commitment control would solve
the problem, it doesn't mean the problem is worth solving. It may be
better to just have invalid data, or run some sort of cleanup program
that resynchronizes your detail rows with your master row.
However, I do have to disagree with your performance comment. Does
journaling add overhead? Sure. Does it add significant overhead? Not
really. Are there statistical outlayers? Sure, by the vast majority of
installations will see no significant difference between journaled and
non-journaled updates.
-Walden
midrange.com
