Re: framework question

On Mon, 5 Jul 2004 16:33:59 -0500, "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
wrote:

>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.

Hi Joe,

I'll have to really disagree here. I have a real world example of what happens
without transactional integrity.

Our data center is backed by a UPS, sized for about 10 minutes (more than long
enough to switch to generator power). The UPS is backed by a natural gas
generator. The generator's power runs directly to the data center. We do
weekly checks to ensure the UPS/generator failover works properly.

On the early morning of June 25th, we had a transformer blow outside the
building and lost power in the plant. The UPS kicked in then the generator
started. Since the UPS thought it was back on line power, it switched back to
line power. (All this is normal.) However, shortly after the switchback, we
had two seperate breakers trip in the plant: one in the data center, one on
the main electrical bus. The UPS came back on and ran itself dry because the
generator's power had no way to get to the room. All the equipment went down.
Our 810 abended.

IT is not staffed for 24x7, so everyone was just starting to get to work. I
got the call on my way in to work of the problem, and we had line power
restored by the time I got in. Power on the 810, let it do database recovery
during IPL and we're off to the races.

Then the wierdness started. Some inventory moves were half posted. Some were
lost entirely. BTW, our vendor's manufacturing app is a traditional RPG
application, no journaling, RI, or CC (written in the early 90s in Synon). We
didn't realize we had inventory problems until Monday. Our bucket inventory
levels appeared in balance, but standard cost rollup didn't balance the
inventory. Lots of month-end adjustments needed to be made.

Another vendor application, which is thick client/server backed by an AS/400
database, does make support of RI, CC and transactions. We didn't have a
single data-related problem from that application.

The point of the above? Without a UPS cable we went down hard; that's been
fixed. But then, the UPS and generator were supposed to supply the room
indefinitely. You just can't totally control your environment. If our
manufacturing app utilized RI, CC, and true atomic transactions, our inventory
would not be skewed. At worst, our receiving people and foreman would have
needed to only key in data at the time the power died. Instead, we had to
chase inventory in the files because the files were in an inconsistent state.
No programmer to blame here. If you build in the transactional control outside
the database, you're almost certainly doing more work than letting the
database take care of itself.

... And that's my philosophy: let the database take care of itself. RI, CC,
atomic transactions, cascading updates, all these things are designed to let
the application programmers be more productive. And you can do it inside RPG,
if you can tolerate SQL transactions.

I have to ask: what happens if we pull the power on your AS/400? Does your
program test for that? <grin>

A small jab just to say, CC/RI isn't a programmer crutch; it's a database
protection mechanism designed to MAINTAIN DATABASE CONSISTENCY. The programmer
still has to code the transactions correctly, but let the database do its job.

Loyd
--  
"Don't need therpay, all better now!" --Jaye, Wonderfalls
loyd@xxxxxxxxxxxxxx  ICQ#504581  http://www.blackrobes.net/