From: Wilt, Charles
I don't disagree that you don't absolutely need commitment control.
Particularly in an all RPG environment.
However, it would seem to me, that whatever workaround you come up with
comes pretty close to duplicating what commitment control provides.
Okay, I'm just going to put my thinking here. This isn't in any way meant
to "contradict" your points, Charles, but rather to try and give you a sense
of where I see things. Personally, I think we over-engineer things these
days and sometimes we use techniques that aren't worth the cost of
implementing them. And in fact, I think we sometimes implement short-term
fixes that hide long term problems.
Lets say that your process is updating a half dozen files, even if you get
a lock on each record you
need before hand, you should still check for errors after each UPDAT, or
have a monitor, or *PSSR to
handle unexpected errors right?
Um. No, not necessarily. I mean, what errors are you checking for? Let's
see what they might be.
Record locks? If you are regularly locking records for extended periods of
time, then you have a systemic problem. There is no way you should have a
lengthy record lock, and thus no reason to code for it.
Missing master file records? Again, an indication of a systemic problem.
You ought not be able to enter an order that has missing item master
records, nor should you be able to delete master records for items that have
orders. Now, if you're deleting item master records while you're entering
orders, you have a different problem. Typically, in this case an item
master wouldn't be deleted, it would be "deactivated" to prevent further
orders while still processing the existing orders.
Constraint problems? That would be a programming problem. Let's find them
and fix them, not program around them. I'd rather see something halt the
job and force an immediate fix then have some sort of suspense file. I try
to avoid putting programs with bugs into production, and on the rare
occasion when it happens, a hard halt is as good a way as any to show it.
I/O errors? If you have an I/O error, what makes you think that you're
going to be able to fix any other data? A hard I/O error ought to have
beepers beeping and jobs stopping and subsystems terminating, baby. In
fact, at this point, you need a complete check of all your database
integrity.
Honestly, I understand your point about not half-updating the database, but
it seems to me that almost anything that would break an update is either a
serious hardware problem or a serious programming error, and either one
should cause a hard halt; that's what they're there for.
One big issue, is that RPG can only maintain one record lock per file.
What happens if you're updating multiple records in the same file?
Well, I don't hold them, which is part of the reason I don't like commitment
control. But I will allow that the more complex a transaction, the more
there are conceivable circumstances during which in the middle of posting
something could happen that forces a transaction that previously passed
validation to now fail. And for that specific situation, I can see using
some measure of defensive programming, either using commitment control or
some other similar technique.
This is a VERY specific situation and quite rare, in my mind. For example,
can you point to a specific situation in your business where this can
happen? Can you point to a dozen?
The other problem, is nobody is 100% RPG anymore. Thus, the likelihood of
"unexpected" has gone up I think.
This I don't buy. If you have people doing "unexpected" things to your
database that could cause transactions to fail, then you have completely
lost control of your database. And at that point, no amount of commitment
control will save you; it will in fact be a false sense of security.
I think I have to say that nowadays, if you're dealing with transactions,
you should probably be using commitment control.
I think that, if you have a situation where a transaction can be invalidated
during the window between when it is validated and when it is posted, then
you should consider some sort of COMMIT/ROLLBACK technique. It is my
contention, though, that the vast majority of your operations do not fall
into this category, and I ask that you give some real world examples as to
when this might occur.
Frankly, the only one I can think of off the top of my head is if somebody
manually moves allocated inventory prior to an order being posted.
Obviously, you can't move inventory that's already moved. However, this
points to a much larger business issue, because if you can't move the
inventory you can't fulfill the order, and you're going to have some serious
screaming going on. And in a good system, you're going to have to
unallocated the inventory before you can move it anyway, so the posting
should have never passed the validation stage anyway.
But seriously, let's try to fashion a scenario where one normal business
process could somehow cause another business process to fail. The idea that
someone comes in with DFU or SQL and changes the database is not an
acceptable argument, because again if you have people doing that, you have
already lost control of your database.
Joe
midrange.com
