RE: framework question

I respectfully disagree; while I do not have the experience on any platform
that many on this list possess; commitment control is a powerful tool that
is needed for most applications.

"Castors up" issues don't happen very often but they do happen; usually
because someone screwed up.

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

Corrupting that database is easy - 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. 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.

Jay Himes




-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Joe Pluta
Sent: Monday, July 05, 2004 4:59 PM
To: 'Java Programming on and around the iSeries / AS400'
Subject: RE: framework question

> From: Raikov, Leonid
> 
> But if you're a true retail shop, some of the transactions will fail 
> from time to time. Why? Because in the ever changing SW environment 
> things are bound to go wrong.

They may fail, but they won't halt the system or corrupt the database,
unless you have really bad programs.  And if you're using commitment control
to filter programming errors, you're playing with fire, because the vast
majority of errors don't cause halts, they cause loss of database integrity.


> Generally, in this discussion I'm on your side, but it looks like
you're
> overdoing it, if only a little. More importantly, however, you have
not
> really answered my question; you just offered your opinion.

Which question?  Do most iSeries shops not use commitment control?  I can
only offer my opinion, since I don't have statistics.  The last time I
checked, most iSeries shops do not use commitment control - and frankly,
most iSeries shops don't need it.

We don't write our architectures to add overhead in case a programmer screws
up.  We instead expect our programmers to unit and system test their
applications prior to putting them into production.  If a halt occurs due to
programmer error, this is a SERIOUS flaw, and must be immediately addressed.

So with the exception of high availability environments (I'll happily plead
ignorance there - luckily most of my clients still do things like weekend
processing and regular IPLs), I don't find that commitment control really
adds anything to your system.

Joe

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