Re: framework question

Nathan,

one elementar operation (record update or journal operation) per processer 
might be lost. But again: thats not the point for CC. The difference between 
record level access and CC is, that CC has the ability to hold record locks 
until the complete transaction is done and then to release all locks with 
Commit or Rollback. So you can get all records locked you need and then make 
your updates and at end of your transaction release your locks.

Dieter Bender
 
On Mittwoch, 7. Juli 2004 02:03, Nathan Andelin wrote:
> 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/
>
>
>
> --
> This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
> mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.

-- 
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de
eMail dieter.bender@xxxxxxxxxxxx