View Full Version : "Interesting" possible activation group issue...
07-02-2007, 06:15 AM
This may have a bearing on the problem.
07-02-2007, 09:17 PM
We also had similar issues with even RPG programs, we were running them under the QILE activation groups and after the programs ended the ODP's would still be open. We changed the programs to make them run under a named activation group and that helped our situation. May you can do something similar with your application and run the programs in a named activation group rather than QILE. Hope this helps... :-)
07-04-2007, 03:25 PM
The cause is almost certainly the COBOL run unit and (perhaps) the software vendors lack of understanding of same. The other possibility is that they didn't explain the ramifications of mixing it with RPG IV to your company. The run unit has some conceptual similarities to ILE Activation Groups (AGs) and is implemented via the AG mechanism. I am assuming here that the COBOL programs use the QILE AG (or possibly *CALLER). If the run unit is the cause, then the "fix" (assuming you can't change the vendor's source code) is to either: Create a small COBOL program which does nothing but call your RPG program. Make sure it runs in the same AG as the other COBOL programs. This should have the effect of preserving the run unit when the main COBOL returns to the RPG and therefore any internal flags that the COBOL program is using to determine if it needs to open files or not will be preserved. Second option of course is to continue to compile your RPG program with DFTACTGRP(*YES) - which precludes you from using subprocedures or C functions, or ... Frankly if I have guessed correctly, this is really the software vendor's problem. They should have anticipated the problem and/or at least documented the restrictions.
07-04-2007, 03:28 PM
"May you can do something similar ... and run the programs in a named activation group rather than QILE." Ummm - QILE _is_ a named Activation Group. There is nothing special about it - it is simply the default name used by IBM for a named group. Don't confuse QILE (which is IBM's default name for an AG) with the Default AG - which doesn't have a name and is where all your OPM programs run.
07-13-2007, 05:44 AM
What I meant by that is since the QILE is the default on the create command other programs may also be running under the QILE "named activation group" and since there may be other programs running under the QILE activation group the resources allocated don't always get reclaimed. By running your programs under a named AG other than QILE you have better control over when the resources allocated to the AG will be deallocated.
07-18-2007, 07:21 AM
Has anyone had a similar issue? What we have is a Taxware package that has some COBOL ILE programs in it and one of them is returning a file status of 41 (and the vendor told us this) that it's a VSAM code meaning file already open. It seems this COBOL pgm leaves some files open- when we compile the ILE RPG that calls the COBOL with default activation group *YES, we're OK, but if we use *NO (QILE act grp) we have the issue. I've read the ILE concepts guide on INFOCENTER but I still don't see what the issue is here or I don't understand it. For the default activation group I know that the open data paths are scoped to the call level, and for the non-default, "QILE" in this case act grp ODP's are scoped to the activation group. Could the problem be that if the user runs program which opens the file explicitly (interactive pgm) that for the next call running it, it tries to open the file again since for the activation group it's already open? P.S. the COBOL program has not been compiled since 1998 and with DSPPGM it shows "module created for" V3R2M0" ! I would greatly appreciate any help on this, Thanks, Christian Eidsmoe
07-18-2007, 07:21 AM
We call this the COBOL wrap. Not only does it allow file usage to proceed smoothly, but it has the big advantage of turning a four hour run time into a few minutes. We caught onto this when using a third party COBOL package. The outer RPG program would blow up so badly that the dump was unreadable. By adding a higher level COBOL wrap to call the RPG program, the job ran, and a lot quicker.
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.