replacement for RCLRSC

[Guest.Visitor]

Greetings everyone! In converting some of our OPM programs into ILE, we ran into a problem using RCLRSC. Here is some simple CL code that represents the problem: PGM ADDPFM FILE(TESTLIB/TESTFILE) MBR(M000000001) TEXT('Test member') OVRDBF FILE(TESTFILE) TOFILE(TESTLIB/TESTFILE) MBR(M000000001) SHARE(*YES) CALL PGM(##TESTOVRR) RCLRSC DLTOVR FILE(TESTFILE) RMVM FILE(TESTLIB/TESTFILE) MBR(M000000001) ENDPGM Note that the program ##TESTOVRR is an RPGLE program that returns with *INLR *OFF. If compiled into the default activation group (DAG), this program works fine. However, when compiled into a named activation group (we are using QILE), the RMVM command fails (CPF7310) because TESTFILE is not closed (RCLRSC was removed, but we already knew it wouldn't work anyway). So, we added a CLOF TESTFILE to replace the RCLRSC. It failed (CPF4520) because no file was opened with that identifier. Finally, we added an explicit OPNDBF TESTFILE OPTION(*ALL) between the OVRDBF and the CALL. Now, the RMVM command fails again (CPF7310) because TESTFILE is not closed. The question is this: What can replace RCLRSC in the code above? I know some options, but I don't really like them for various reasons. 1) We could move *ON *INLR in the RPG program (this works). 2) We could call a different CL in a separate named activation group to do file cleanup with RCLACTGRP(QILE) after this CL ends (this works). Any suggestions? Am I missing something really obvious here? Are we running into some type of scoping problem here? Is it not possible to do this sequence of events in a single CL running in a named activation group? It seems to us that RCLRSC performs a function in the DAG that has no counterpart in a named activation group. We would greatly appreciate any help or guidance on this issue. Thank you and have a great day! Brian

[Guest.Visitor]

CLOSE the file in RPGLE before the RETURN.

[Guest.Visitor]

Brian I am not clear on your comment: Is it not possible to do this sequence of events in a single CL running in a named activation group? I know you compiled the RPG program into QILE. Did you compile the CL into QILE? JHicks@SUZ.com

[Guest.Visitor]

On Wednesday, March 17, 1999, 01:02 PM, Gene Gaunt wrote: CLOSE the file in RPGLE before the RETURN. Sorry, but I disagree. Don't close the files, let the system do it for you. Thats what activation groups do, they allow the system to know when to reclaim resources. In modular programming a calling program does not know what resources were allocated by all of the modules and service programs that it called. I have seen code where the calling programs keeps track of what it called so it could recall every module with a close flag. Its not necessary, exit the program and have the system reclaim resources. JHicks@SUZ.com

[Guest.Visitor]

Jim, Yes, both the CLLE and RPGLE programs are compiled into QILE. Thanks, Brian

[Guest.Visitor]

On Wednesday, March 17, 1999, 02:29 PM, Brian Edmond wrote: Jim, Yes, both the CLLE and RPGLE programs are compiled into QILE. Thanks, Brian The RCLRSC command can run in a CL that is in the DAG and it will reclaim any resources in the DAG. The RCLACTGRP will only reclaim resources of an inactive activation group. So, a CL compiled into QILE can not reclaim QILE. In that respect the two commands are not the same. The way I usually use RCLACTGRP is in jobs that have a CL call a program over and over. The CLLE program is compiled into the DAG. It calls an RPG/COBOL program that is in a named activation. The program in the named activation group is written to be called over and over so it leaves itself active on exit. It is the CL that decides it no longer wants to call the program in the named activation group and it then exectues a RCLACTRSC command. Because the CL program is in the DAG this works. JHicks@SUZ.com

[Guest.Visitor]

Jim, Thanks for your suggestions. We considered this as a strategy, but we will still have a member in the file that is not cleaned up. Here is your strategy (as I understand it): CL Pgm A (DAG) calls CL Pgm B CL Pgm B (QILE) creates member, ovrdbf to that member, calls RPG Pgm C RPG Pgm C (QILE) processes the file member and returns to CL Pgm B CL Pgm B (QILE) returns to CL Pgm A CL Pgm A (DAG) does a RCLACTGRP(QILE) However, the created member still exists in the file. I would have to setup a parameter between CL Pgm A and CL Pgm B to allow CL Pgm A to know the correct member name and remove it from the file. Do you understand our problem? I think the original program flow (outlined in my first post) is a much more elegant and "natural" way to peform this sequence of events. Granted, in such a simple case, we can simply close the file in the RPG program (since it is only called once), but I suspect this problem will be found in other places under different circumstances. Here's a scenario that would preserve the logic flow of the OPM CL program with a RCLACTGRP instead of a RCLRSC, but it involves making some scoping decisions. CL Pgm A (DAG) calls CL Pgm B CL Pgm B (QILE) creates member, ovrdbf to that member, calls RPG Pgm C RPG Pgm C (PGMCAG) processes the file member and returns to CL Pgm B CL Pgm B (QILE) does a RCLACTGRP(PGMCAG), removes member, returns to CL Pgm A In this case, the OVRDBF would have to scope to *JOB or *CALLLVL or something else? Is this a better way of handling this? Or should I stick to trying to figure out why my CLOF will not work? Thanks again for your input. Any comments or suggestions you may have will be much appreciated! Brian

[Guest.Visitor]

On Thursday, March 18, 1999, 09:59 AM, Brian Edmond wrote: Jim, In this case, the OVRDBF would have to scope to *JOB or *CALLLVL or something else? Is this a better way of handling this? Or should I stick to trying to figure out why my CLOF will not work? Are you aware that the default scope for OVRDBF is different if the CL is in a named activation group than in the DAG. If OVRDBF is executed in the DAG the default is *CALLLVL. If it is in a named activation group it is the activation group. I know when I started with ILE I did not know this and it caused me some trouble. In your example, you had a CL in a named activation group do a OVRDBF then call a RPG program in a different activation group. Since the OVRDBF was in a CL that was in a named activation group, it must have a scope parameter to affect the RPG program. JHicks@SUZ.com