Re: framework question

Lloyd,

How would OS/400 commitment control procedures help when the power goes off?
If a standard file update is interrupted by a power failure, couldn't a
journaling or commit operation also be interrupted?  

Nathan.




from: Loyd Goodbar <loyd@xxxxxxxxxxxxxx>
subject: Re: framework question

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/