Re: File Read in Subprocedure WAS(Re: More on RPG style)

It all depends on your design. If I have multiple files that need to be
updated for a transaction, they are all handled within the UpdateXxxx()
routine. Let's say I have an AddPickticketLine() procedure that adds a
record to the pickticket detail file. If my business rules require that I
increment the quantities in the Pickticket Header file, as well as reduce
the unallocated quantity in the Order Header, and reduce allocatable
inventory quantities in the inventory files, all of those intricacies
should be within the AddPickticketLine() procedure. With them all in that
one procedure, the procedure is quite capable of dealing with the commit.

I generally always create a commit and rollback procedure in the service
program in case I hit a situation that is so nasty that it can't be
encasulated (I can think of only one off the top of my head in the last
several years).

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi



Joep Beckeringh <joep.beckeringh@xxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
03/01/2010 02:41 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: File Read in Subprocedure WAS(Re: More on RPG style)






Op 01-03-10 17:34, BMay@xxxxxxxxx schreef:

Let's say your original application did not use commitment control

(don't

know why anyone would do that, but that's another topic). Your boss

tells

you to implement commitment control on the application. Guess how many
places you need to deal with it? One.

That is a very optimistic view; it assumes that every database update is
committed immediately. As soon as you have a transaction that consists
of more than one update (isn't that what commitment control is for?) you
cannot do the commit from within the subprocedure. Ergo, the caller of
the subprocedures has to do the commit.

Joep Beckeringh