Re: commitment control scope

[Joep Beckeringh <joep@xxxxxxxxxxxxxxxxxxx>]

Well, it makes sense, doen't it? You started commitment control for the whole 
job and then you want commitment control just for one activation group. If you 
want your service program to have its own commitment control, you will have to 
limit the commitment control of the driver program to its own activation group. 
But that might have other ramifications.

Another problem with your plan: how do you plan to do the commits? I think they 
will have to be done from within the activation group for which it is scoped. In 
your case that would mean moving the commits from the calling programs to the 
service program.

I think you'd better change PGMA. Apparently you call this program because it 
contains the calculations you want to perform, the business logic.  You don't 
really want it to update the AR/AP file; you just (ab)use it to get the 
information back to the caller. So, give PGMA an option to write to a work file 
instead of the AR/AP file. If you make it an optional parameter, you won't have 
to change other calling programs.

Joep Beckeringh


Lim Hock-Chai wrote:
> Having the following problem and need some suggestions to get around it:
>  
> **Back Ground info
> There is a pgm, I'll call it PGMA, in our system that do a lot of calculation, update some files and write records to our AR/AP file.  All update and write to files in this program are under commitment control.  However, this program does not do commit or rolbk.  Instead, the caller uses the return error code field to determine if commit or rolbk is needed.
>  
> I've a project that required me to get the AR/AP amount that generated by this program and display it on the screen without committing any record.  I created a service program that basically call PGMA.  After it return back to this service program, it read the AR/AP file to get the total then do a ROLBK.
>  
> **Everything is working fine, except, this service program has a side effect the I don't really like:
> In our system, the driver program, that takes user to the main menu, starts the commitment control with CMTSCOPE(*JOB).  That means, if a program update some files with commitment control and call the above service program.  The files that it updated will also be rolbk by the service program.
>  
> My plan was to create this service program in a different actgrp and strcmtctl within the service program with the scope of actgrp.  However, I get a error saying that the commitment control already started (started by the driver program using *job scope).
>  
> any suggestion on how to get rid of this side effect for this service program?
>  
> thanks