Re: Controlling values for Automatic STRCMTCTL

<jon>
By the way - I don't understand your comment "... changing this to *job, would limit commit to OPM possibilities ... " because that is _exactly_ what the current setting is imposing on them.
</jon>

Jon, I will try to clearify:

In a well modularized environment you will need more than one commit scope. Logging entries must not disappear, max values in a keystore would need one, business transactions would need another, or maybe more than one (rather seldom). The commit master will run in a named activation group, the slaves (data access modules) would run in * caller.

In your old school environment are OPM programms (bad news) and they are using commit (good news). Introducing data access modules (a good idea) there are two problems:
1.) calling ile from OPM with *caller isn't a good idea
2.) commit scope *ACTGRP

@1: I would make the data acces modules running in *caller and a mediator programm to run them in some named ACTGRP (for instance: OPMCOMMIT)
@2: I would let the commit scope by *actgrp and call Api QTNADDCR from DFTACTGRP to add a commit exit program (for instance CCEXIT). This programm will be called by the database engine after each commit operation and could do the commit or rollback for ACTGRP OPMCOMMIT (simply let it run in ACTGRP OPMCOMMIT).

regards

Dieter

PS: you will find some example used by ArdGate in JDBCGATE.RPGLE (adding a commit ressource) and CCEXIT.RPGLE (a commit exit). Feel free to contact me via this list or my wellknown eMail adress.