Re: Change commitment control after compilation

On 12/18/2013 1:46 PM, Jeff Young wrote:

To use commitment control without causing major potential issues, requires
that the entire application be designed for commitment control.
sadly, most applications are a mix of legacy which does not use commitment
control and new code which may use it, but *very* carefully,.

THIS!!!

I have batch processes I inherited from before the dinosaurs became oil.
These processes follow a familiar pattern: several programs run
sequentially loading, sorting and finally reading work files to update
transaction files, master files and the inevitable monthly accumulator
files. In this... model (for lack of a better word) a 'transaction'
happens across multiple programs and sometimes these programs are run on
separate days. Database level commitment control is useless with this
sort of design.

I would LOVE to restructure this sort of thing to be more modern but
there are several practical barriers.
1) My vendors insist on sending me batches of data. There's no web
service I can call, no API, nothing that I can do to convert this batch
paradigm to a transactional paradigm.
2) My management insists on paying me to do new things. They really
don't want me to spend a couple of weeks per application to make it
modern in name only. They want to see some business benefit. The
reason these batch processes haven't been altered in 30 years is that
they have not needed to be altered. The business processes fulfilled by
these applications are generating revenue as-is.
3) New applications are rare. That is, we don't scrap our existing
database and start from scratch. We grow, bit by bit, adding,
refactoring, revamping.

It can be very difficult to add commitment control to a mostly batch
system, but believe it or not, there really are crusty old RPG
programmers who are doing it. It is probably true that most midrange
shops avoid commitment control. I cannot speak for anyone else on the
list, but for me, I am very glad to hear about new techniques here.

Rather than curse the darkness (most shops don't...) why not write an
article, a tutorial, a wiki page, a blog entry, a letter to the editor,
an IMHO submission or a very long post right here showing how commitment
control can be useful to those of us who aren't aware of the benefits?

--buck

On Wed, Dec 18, 2013 at 1:00 PM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:

*NC by Nature.


On Wed, Dec 18, 2013 at 12:56 PM, Gary Thompson <gthompson@xxxxxxxxxxx

wrote:

Hmm, two valid and informed point of view.

D*B challenges us to take advantage of technology;
Henrik points to a fact of human nature.

I think we are headed in the direction suggested by D*B;
some will get there sooner, some will not make it.



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:

rpg400-l-bounces@xxxxxxxxxxxx]

On Behalf Of Henrik Rützou
Sent: Wednesday, December 18, 2013 10:43 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Change commitment control after compilation

Dieter,

what is wrong is that most IBM I shops and most IBM I software dosn't use
commitment control and so you are fighting against windmills


On Wed, Dec 18, 2013 at 6:26 PM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

... and I would suggest to make usage of commitment controll to the
standard of your shop!!!
Or, what's wrong with commitment controll???

D*B