RE: framework question

> From: Himes, Jay
> 
> "Castors up" issues don't happen very often but they do happen;
usually
> because someone screwed up.

But not the database.  Only the program will go casters up.  When that
happens, you fix it.  If it happens more than a couple of times, you
find a new programmer.  There are reasons for getting rid of stupid
programmers as opposed to trying to use commitment control as a bad code
filter... see below.


> Other reasons for needing commitment control include things like
record
> contention and  fat fingered operators which are far more likely.

I guess I'm slow here.  Can you provide some real-world examples of
where commitment control helps in either of these instances?


> Corrupting that database is easy

Not if you have any skills whatsoever as a programmer.


> - take a typical simple accounting package;
> for a finical transaction you need to write 2 records; one for each
half
> of
> the transaction and update a summary balance; a complex system would
have
> more files to update. If you don't finish all 3 you don't want to
leave
> the
> system in an inconsistent state no matter what the reason.

And exactly how would the state get inconsistent short of programmer
error?  And if there is a programmer error, how does commitment control
fix that?  This is why you fire programmers who don't program properly.
If this same bad programmer simply forgets to write the record or writes
bad data, then commitment control buys you nothing.  In fact, it's much
more likely that this is what will happen as opposed to an abend.

Let's be clear: PROGRAMMER ERROR IS NOT A VALID REASON FOR COMMITMENT
CONTROL.  If anything, it becomes a crutch that lazy programmers rely on
as opposed to actually testing their code.


> Certainly in this
> situation the fix would not be too difficult; but it grows more
complex as
> the application does; and it does not confidence inspire to have a
system
> whose data must be "fixed" when someone hits 4 instead of 5 on
wrkusrjob.

Okay, let's be serious here.  There is a reason that the default on
ENDJOB is 30 seconds, not *IMMED.  Please find me a single instance in
your career where your database update required 30 seconds to complete.
So, IF you are in a shop where users are given the authority to cancel
their jobs AND your users are dumb enough to cancel jobs on a regular
basis AND they decide to override the default AND this is on mission
critical programs, just stick in a test for shutdown and you're done.

Is it worth doubling or tripling your disk requirements and slowing down
your system as opposed to training an operator or fixing a program?

Joe