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