Re: commitment control scope -- RPG400-L

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

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.