|
Hello Wayne, Since no-one else has responded and I detect a note of panic in the second append ... There should be no difference in the behaviour. When QCMDEXC is used to run RCLRSC and any of the OVRxxx commands it does special processing to make the command behave AS IF it were run from within the program which called QCMDEXC. Now, assuming that the RCLRSC command is doing what it is supposed to there must be something else at work. I am assuming that you used your menuing system's maintenance facility to change the 'RCLRSC' option to 'CALL CLEANUP'. Is that correct? Or does your menuing system make a distinction between commands and programs? By that I mean is it clever enough to use QCMDEXC for commands but call programs directly? If it is 'clever' then I do not have an answer -- more investigation is needed. But (and here is the good news!) I doubt it is that clever. I suspect it behaves according to my first assumption and that you enter the complete command (in this case 'CALL CLEANUP'). This fails because you now have an extra program in the invocation stack and you are instructing the system to reclaim resources from that level, not your original level. Perhaps a picture would make this clearer: Original situation: Menu option 24 Clean up ----> CALL QCMDEXC PARM('RCLRSC' 6) Invocation stack: MenuPgm <--------------------------| QcmdExc | RclRscCPP // Affects the caller | Current situation: Menu option 24 Clean up ----> CALL QCMDEXC PARM('CALL CLEANUP' 12) ----> RCLRSC *CALLER ----> RCLACTGRP APPACTGRP Invocation stack: MenuPgm QcmdExc <--------------------------| CleanUp | RclRscCPP // Affects the caller | Clear as mud? Fix the menuing system. What you are trying to achieve will work if you can call CLEANUP directly from the menu program. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
-Mailer: Microsoft Outlook Express 5.00.2014.211 Date: Thu, 29 Apr 99 17:34:27 -0400 From: "Wayne Achenbaum" <wache@slomins.com> To: MIDRANGE-L@midrange.com Reply-To: MIDRANGE-L@midrange.com Subject: RCLRSC scoping
n anyone help? My company has a menuing system that can call programs and run commands from entries in a file. We currently call programs that are both ILE and OPM. All ILE programs run in a specific named activation group. We used to be able to take an option that was a RCLRSC and it worked just fine. Since I have to clean up both ILE and OPM pgms that left files open, I cretaed a CL that did a RCLRSC anfd then a RCLACTGRP ACTGRPNAME. The problem is that the rclrsc does not work anymore. I tried the LVL scoping on the rclrsc to no avail. Does anybody out there have a clue as to why the Cl program doing a rclrsc with lvl(*caller) would be any different than a rclrsc processed by the same pgm that call qcmdexec to do a rclrsc. TIA, Wayne Achenbaum
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Can anyone help? My company has a menuing system that can
call programs and run commands from entries in a file. We currently call
programs that are both ILE and OPM. All ILE programs run in a specific
named activation group. We used to be able to take an option that was a RCLRSC
and it worked just fine. Since I have to clean up both ILE and OPM pgms that
left files open, I cretaed a CL that did a RCLRSC anfd then a RCLACTGRP
ACTGRPNAME. The problem is that the rclrsc does not work anymore. I tried the
LVL scoping on the rclrsc to no avail. Does anybody out there have a clue as to
why the Cl program doing a rclrsc with lvl(*caller) would be any different than
a rclrsc processed by the same pgm that call qcmdexec to do a rclrsc. TIA, Wayne
Achenbaum
|
As an Amazon Associate we earn from qualifying purchases.
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.