David FOXWELL | 7 Sep 16:05 2010

program won't let go of file

Hi all,

 
Our RPG OPM's always had a parameter ReturnType so that we could instruct them to return with either RT or LR
on. At the end of processing, the caller would use a cleanup routine to call all the programs that had been
activated. The called programs would then just set on LR and end. 

For some reason unbeknown to me, this method was not used with RPGIV programs. 

Now, this (simplified)situation has "evolved" :

PGM1(CLP)
	PGM2(RPGIII)
		PGM3(RPGIII)
			PGM4(RPGIV)
				PGM5(RPGIV Converted from RPGIII)

Everything is running in DFTACTGRP.

When PGM2 is finished, it will call PGM3 with ReturnType to tell it to switch on LR and return. PGM4 does not
have this facility and always returns with LR off. As it does not know what PGM3 is doing, it never calls PGM5
to tell it to set on its LR indicator and its files stay open. 

On returning to PGM1, I need PGM5 to be freed up. A file it uses is staying open. The boss says to issue a call
from PGM2 or PGM3 to PGM5 to get it to switch on LR. I don't know if that would even work, would it? Even if it
did, there are other RPGIV called by PGM5 that would probably give the same problem. How do I get out of this
mess? 

TIA.
--

-- 
(Continue reading)

Birgitta Hauser | 7 Sep 16:27 2010
Picon

AW: program won't let go of file

LR in RPGIII is not the same as LR in RPGIV.

In RPGIV it depends on the activation group if the program is completely
removed or not.
As long as the activation group in which the program runs is active, your
program is in the memory.
A RPGIV program running in the default activation group cannot be removed,
because it is not possible to reclaim the default activation group.

Instead of moving LR on, you need to run your RPGIV program in a named
activation group and reclaim this activation group instead of executing LR. 

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@...
[mailto:rpg400-l-bounces@...] Im
Auftrag von David FOXWELL
Gesendet: Tuesday, 07. September 2010 16:06
An: RPG programming on the IBM i / System i
Betreff: program won't let go of file

(Continue reading)

Mark S. Waterbury | 7 Sep 16:54 2010
Picon

Re: AW: program won't let go of file

  Hi, Birgitta:

What you describe for the behavior of LR in RPG IV is true when the 
RPGLE program was *not* compiled with:

     CRTBNDRPG ... ACTGRP(*DFTACTGRP)

ACTGRP(*DFTACTGRP) is only available on CRTBNDCL and CRTBNDRPG, and 
causes extra code to be generated into the *PGMs so that those programs 
will behave as if they are OPM programs running in the default 
activation group.  They can be reclaimed with RCLRSC.

That is why I like to say that ACTGRP(*DFTACTGRP) specifies the program 
is to run "in OPM compatibility mode."

All the best,

Mark S. Waterbury

 > On 9/7/2010 10:27 AM, Birgitta Hauser wrote:
> LR in RPGIII is not the same as LR in RPGIV.
>
> In RPGIV it depends on the activation group if the program is completely
> removed or not.
> As long as the activation group in which the program runs is active, your
> program is in the memory.
> A RPGIV program running in the default activation group cannot be removed,
> because it is not possible to reclaim the default activation group.
>
> Instead of moving LR on, you need to run your RPGIV program in a named
(Continue reading)

David FOXWELL | 7 Sep 17:12 2010

RE: AW: program won't let go of file


> -----Message d'origine-----
> De : rpg400-l-bounces@... 
> [mailto:rpg400-l-bounces@...] De la part de Mark S. Waterbury
> Envoyé : mardi 7 septembre 2010 16:55
> À : RPG programming on the IBM i / System i
> Objet : Re: AW: program won't let go of file
> 
>   Hi, Birgitta:
> 
> What you describe for the behavior of LR in RPG IV is true 
> when the RPGLE program was *not* compiled with:
> 
>      CRTBNDRPG ... ACTGRP(*DFTACTGRP)
> 

I was just going to reply to Birgitta. I've tried coding PGM5 so it always returns with LR on and then I no
longer have the file open.
Now I am confused. 

We use crtpgm actgrp(*caller) with the first caller always in *dftactgrp. Could that make it behave
differently? I will try CRTBNDRPG PGM5 ACTGRP(*DFTACTGRP)
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
(Continue reading)

Mark S. Waterbury | 7 Sep 17:28 2010
Picon

Re: AW: program won't let go of file

  Hi, David:

Compiling an ILE *PGM with ACTGRP(*CALLER) when you know it will be 
called from an OPM *PGM (e.g. your CLP *PGM) means it will end up 
running in the *DFTACTGRP -- IBM recommends against doing that precisely 
because it cannot be reclaimed with RCLRSC in that case. (Search the 
archives; there are many discussions of this to be found.)

A big reason for ACTGRP(*DFTACTGRP) was to provide a way that customers 
could begin using RPG IV to upgrade their existing RPG III programs, and 
to start taking advantage of many features and improvements in RPG IV, 
without having to convert everything into "pure" ILE first.

Hope that helps,

Mark S. Waterbury

 > On 9/7/2010 11:12 AM, David FOXWELL wrote:
>> -----Message d'origine-----
>> De : rpg400-l-bounces@...
>> [mailto:rpg400-l-bounces@...] De la part de Mark S. Waterbury
>> Envoyé : mardi 7 septembre 2010 16:55
>> À : RPG programming on the IBM i / System i
>> Objet : Re: AW: program won't let go of file
>>
>>    Hi, Birgitta:
>>
>> What you describe for the behavior of LR in RPG IV is true
>> when the RPGLE program was *not* compiled with:
>>
(Continue reading)

Mark S. Waterbury | 7 Sep 18:01 2010
Picon

Re: AW: program won't let go of file

  Minor correction:

Instead of ACTGRP(*DFTACTGRP), I meant to show:    DFTACTGRP(*YES) on 
the CRTBNDCL and CRTBNDRPG commands.

Sorry for any confusion this may have caused.

Mark
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Birgitta Hauser | 7 Sep 18:25 2010
Picon

AW: AW: program won't let go of file

When running ILE Programs in the default activation group with *LR=ON, the
files get closed, but the program itself will be not removed from the
storage until the job ends (i.e. the default activation group gets closed).
RCLRSC will not remove the ILE programs either, it will only reinitialize
allocated storage for ILE programs while it reclaims OPM programs!

The next time the ILE program gets called within the same job, the files
will be opened again and the already allocated storage get initialized.

Even worse when running service programs with I/O operations within the
default activation group and executing RCLRSC.
The files get closed, but the service program still thinks they are opened
... and there is no way to trap the error, neither with %OPEN, nor with
%ERROR the service program will fail with MCH3601.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@...
[mailto:rpg400-l-bounces@...] Im
Auftrag von David FOXWELL
Gesendet: Tuesday, 07. September 2010 17:13
(Continue reading)

Scott Klement | 7 Sep 19:05 2010

Re: AW: AW: program won't let go of file

Birgitta,

> When running ILE Programs in the default activation group with *LR=ON, the
> files get closed, but the program itself will be not removed from the
> storage until the job ends (i.e. the default activation group gets closed).

What you say here is true *ONLY* if DFTACTGRP(*NO) is specified.    If 
you specify DFTACTGRP(*YES), the program will act like an OPM program, 
and the activation will indeed be removed from memory with LR=*ON or RCLRSC.

When you specify DFTACTGRP(*NO) ACTGRP(*CALLER) and call from the 
default activation group, then LR will leave the program in memory. 
DFTACTGRP(*NO) makes a program act like an ILE program -- so it stays in 
memory until the activation group is reclaimed.  (In the case of the 
default activation group -- that means it stays in memory til the job ends.)

This has all been said and explained several times before on this 
mailing list.  Please check the archives for a more in-depth discussion.
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

David FOXWELL | 8 Sep 15:46 2010

RE: AW: AW: program won't let go of file

> -----Message d'origine-----
> [mailto:rpg400-l-bounces@...] De la part de Scott Klement

>     If 
> you specify DFTACTGRP(*YES), the program will act like an OPM 
> program, and the activation will indeed be removed from 
> memory with LR=*ON or RCLRSC.
> 

We have converted a number of OPM that were needed by an application that runs in a named ACTGRP. Obviously,
we have recompiled with ACTGRP(*CALLER).
If I understand correctly, we can expect that unpredictable results may occur in the applications where
previously the programs were OPM?

--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

DeLong, Eric | 8 Sep 17:00 2010

RE: AW: AW: program won't let go of file

"Unpredictable results" is a rather broad statement...  It mostly
depends on the design of your OPM applications.  Typically, if you end a
program with LR on, you won't have too many issues, but programming OPM
for performance typically involved exiting a program without LR and
leaving files open.  It is these performance enhancing techniques that
don't work the same in ILE.

ILE activation groups circumvent some of the need to code for
performance, since many of these elements are implemented by default in
an ILE module.

My opinion is that trying to maintain a hybrid (part OPM, part ILE)
application is much more difficult in the long run.  I see issues with
overrides all the time, and it leads toward stupid standards like
"Always use OVRSCOPE(*JOB)".  A simple alternative would be to convert
the rest of your OPM to ILE, and run them all in a single named AG.  Any
service programs would use ACTGRP(*CALLER), so that you could refine
your AG strategy later as needed.  

Jmo,
-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@...
[mailto:rpg400-l-bounces@...] On Behalf Of David FOXWELL
Sent: Wednesday, September 08, 2010 8:46 AM
To: RPG programming on the IBM i / System i
Subject: RE: AW: AW: program won't let go of file

> -----Message d'origine-----
(Continue reading)

Scott Klement | 8 Sep 16:52 2010

Re: AW: AW: program won't let go of file

Hi David,

On 9/8/2010 8:46 AM, David FOXWELL wrote:
> We have converted a number of OPM that were needed by an application
> that runs in a named ACTGRP. Obviously, we have recompiled with
> ACTGRP(*CALLER).

I don't understand what you mean.  You say "named ACTGRP", then 
immediately say "obviously, ACTGRP(*CALLER)".  Huh?  How is this 
obvious?  Is it a named actgrp, or is it *caller?!   Or is it *CALLER 
and being called from a named actgrp?

> If I understand correctly, we can expect that unpredictable results
> may occur in the applications where previously the programs were
> OPM?

No, I don't agree with this at all.

If (?!) your programs are indeed running in a named actgrp, then they 
are ILE programs and will behave like ILE programs.

If your programs are running in OPM compatibility mode, i.e. 
DFTACTGRP(*YES), then they should behave like OPM programs.

If your programs are compiled with DFTACTGRP(*NO) and ACTGRP(*CALLER) 
and are called from the default activation group, you won't be able to 
remove them from memory without ending the job -- but they'll still work 
fine.

All of these are completely predictable.  None of them are 
(Continue reading)

David FOXWELL | 8 Sep 17:24 2010

RE: AW: AW: program won't let go of file

> -----Message d'origine-----
> [mailto:rpg400-l-bounces@...] De la part de Scott Klement
> 

> > We have converted a number of OPM that were needed by an 
> application 
> > that runs in a named ACTGRP. Obviously, we have recompiled with 
> > ACTGRP(*CALLER).
> 
> I don't understand what you mean.  You say "named ACTGRP", 
> then immediately say "obviously, ACTGRP(*CALLER)".  Huh?  How is this 
> obvious?  Is it a named actgrp, or is it *caller?!   Or is it *CALLER 
> and being called from a named actgrp?

Scott, Eric, thanks.

I meant that as the programs were needed by an application already using a named group, the converted
programs were compiled with ACTGRP(*CALLER) so that they would run in said group.

> If your programs are running in OPM compatibility mode, i.e. 
> DFTACTGRP(*YES), then they should behave like OPM programs.
> 
> If your programs are compiled with DFTACTGRP(*NO) and ACTGRP(*CALLER) 
> and are called from the default activation group, you won't 
> be able to 
> remove them from memory without ending the job -- but they'll 
> still work 
> fine.
> 
> All of these are completely predictable.  None of them are 
(Continue reading)

Scott Klement | 8 Sep 18:44 2010

Re: AW: AW: program won't let go of file

True, RCLRSC only affects the default activation group.  If your 
programs are running in a named activation group, RCLRSC will have no 
effect.  (But you can use RCLACTGRP to reclaim them -- it's pretty much 
the same thing as RCLRSC, aside from the fact that it works by actgrp 
instead of call-level.)

On 9/8/2010 10:24 AM, David FOXWELL wrote:
>
> The CLP that called the OPM's use RCLRSC. As the converted OPM's had to be compiled to run in an ACTGRP, I
thought that RCLRSC would no longer work in the same manner.
>

--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

David FOXWELL | 9 Sep 09:35 2010

RE: AW: AW: program won't let go of file


I seem to be having trouble expressing my concern, I'll try and be more clear.

Here's the situation before conversion to ILE :

CLP1
	OVRDBF FILEA FILEB
	PGM
	CALL OPM1
		CALL OPM2
			CALL OPM3

 				etc, etc, with further calls to OPM's
	RCLRSC
	ENDPGM

The programs may or may not be terminated with LR on.

Now, the OPM are converted to ILE compiled with CRTPGM ACTGRP(*CALLER), so their behaviour is different
with RCLRSC :

CLP1
	OVRDBF FILEA FILEB
	PGM
	CALL ILE1
		CALL ILE2
			CALL ILE3

 				etc, etc, with further calls to OPM's
	RCLRSC
(Continue reading)

Joep Beckeringh | 9 Sep 10:03 2010
Picon

Re: AW: AW: program won't let go of file

  David,

I think your best bet for now is to change CLP1 to ILE, with 
ACTGRP(*NEW). Leave the RCLRSC (until you get rid of your OPMs). This 
way, when CLP1 (or CLLE1, as would be more appropriate) ends, the OPMs 
are ended by RCLRSC and the ILEs are ended because the activation group 
ends.

Joep Beckeringh

Op 09-09-10 09:35, David FOXWELL schreef:
> I seem to be having trouble expressing my concern, I'll try and be more clear.
>
> Here's the situation before conversion to ILE :
>
> CLP1
> 	OVRDBF FILEA FILEB
> 	PGM
> 	CALL OPM1
> 		CALL OPM2
> 			CALL OPM3
>
>   				etc, etc, with further calls to OPM's
> 	RCLRSC
> 	ENDPGM
>
> The programs may or may not be terminated with LR on.
>
>
> Now, the OPM are converted to ILE compiled with CRTPGM ACTGRP(*CALLER), so their behaviour is different
(Continue reading)

David FOXWELL | 9 Sep 11:13 2010

RE: AW: AW: program won't let go of file


> -----Message d'origine-----
> De : rpg400-l-bounces@... 
> [mailto:rpg400-l-bounces@...] De la part de Joep Beckeringh
> I think your best bet for now is to change CLP1 to ILE, with 
> ACTGRP(*NEW). Leave the RCLRSC (until you get rid of your 
> OPMs). This way, when CLP1 (or CLLE1, as would be more 
> appropriate) ends, the OPMs are ended by RCLRSC and the ILEs 
> are ended because the activation group ends.

Joep, I already tried that. The OVRDBF issued by the CLLE1 was no longer active for the first OPM which
bombed. 
We've fixed the problem by stopping the program in question from attempting to use the file.
However, I've learned on this thread that we should have used DFTACTGRP(*YES) on the converted programs
and then the program would have been disactivated after RCLRSC. The fact that these converted programs
are widely used ( with RCLRSC, ie, expected to act like OPM's) means that other errors of the same kind are probable.
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Joep Beckeringh | 9 Sep 11:42 2010
Picon

Re: AW: AW: program won't let go of file

  David,

Overrides are always the biggest hurdle when moving from OPM to ILE, and 
even more when combining the two. The problem is that the default scope 
for overrides changes: in the default activation group (OPM) it is the 
call level, in other activation groups it is the activation group.

In your example:

CLP1
	OVRDBF FILEA FILEB
	PGM
	CALL ILE1
		CALL ILE2
			CALL ILE3

  				etc, etc, with further calls to OPM's
	RCLRSC
	ENDPGM

the override is visible to all programs, as long as CLP1 is in the call stack. When you change CLP1 to CLLE1
with ACTGRP(*NEW), the override is visible for all programs that use ACTGRP(*CALLER), but not for the OPM
programs. However, that can be change by changing the override to:
OVRDBF FILE(FILEA) TOFILE(FILEB) OVRSCOPE(*CALLLVL). That changes the behaviour of OVRDBF back to the
way it worked in OPM.

So, if you change CLPs to CLLEs, add OVRSCOP(*CALLLVL) to all your overrides, and you should be fine.

Joep Beckeringh

(Continue reading)

David FOXWELL | 9 Sep 12:45 2010

RE: AW: AW: program won't let go of file

> -----Message d'origine-----
> [mailto:rpg400-l-bounces@...] De la part de Joep Beckeringh
> In your example:
> 
> CLP1
> 	OVRDBF FILEA FILEB
> 	PGM
> 	CALL ILE1
> 		CALL ILE2
> 			CALL ILE3
> 
>   				etc, etc, with further calls to OPM's
> 	RCLRSC
> 	ENDPGM
> 
> the override is visible to all programs, as long as CLP1 is 
> in the call stack. When you change CLP1 to CLLE1 with 
> ACTGRP(*NEW), the override is visible for all programs that 
> use ACTGRP(*CALLER), but not for the OPM programs. However, 
> that can be change by changing the override to:
> OVRDBF FILE(FILEA) TOFILE(FILEB) OVRSCOPE(*CALLLVL). That 
> changes the behaviour of OVRDBF back to the way it worked in OPM.
> 
> So, if you change CLPs to CLLEs, add OVRSCOP(*CALLLVL) to all 
> your overrides, and you should be fine.

I saw that too, Joep, but there would have been a lot of others to check out and I was unsure of the result.
Thanks for the confirmation, I will know next time I have such a bug and only 5 minutes to fix it :-) 
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
(Continue reading)

David FOXWELL | 8 Sep 09:51 2010

RE: AW: program won't let go of file

> -----Message d'origine-----
> [mailto:rpg400-l-bounces@...] De la part de Birgitta Hauser
> Envoyé : mardi 7 septembre 2010 18:26
> À : 'RPG programming on the IBM i / System i'
> Objet : AW: AW: program won't let go of file
> 
> When running ILE Programs in the default activation group 
> with *LR=ON, the files get closed, but the program itself 
> will be not removed from the storage until the job ends (i.e. 
> the default activation group gets closed).
> RCLRSC will not remove the ILE programs either, it will only 
> reinitialize allocated storage for ILE programs while it 
> reclaims OPM programs!
> 
> The next time the ILE program gets called within the same 
> job, the files will be opened again and the already allocated 
> storage get initialized.
> 
> Even worse when running service programs with I/O operations 
> within the default activation group and executing RCLRSC.
> The files get closed, but the service program still thinks 
> they are opened ... and there is no way to trap the error, 
> neither with %OPEN, nor with %ERROR the service program will 
> fail with MCH3601.

Hi, Birgitta,

Having read Barbara's post, I am wondering if leaving the ILE programs active is a problem? In our case there
are no service programs to worry about.
--

-- 
(Continue reading)

Mark S. Waterbury | 7 Sep 16:37 2010
Picon

Re: program won't let go of file

  Hi, David:

DFTACTGRP solution
=================
Assuming all of these *PGMs are in fact running in the *DFTACTGRP, then 
you can just issue:

     RCLRSC    LVL(*)

in PGM1(CLP), right after the CALL to PGM2 returns to PGM1.  This will 
close all open files and end all active programs below the current level 
in the call stack.

NOTE: if somehow PGM4 or PGM5 were not compiled with CRTBNDRPG ... 
ACTGRP(*DFTACTGRP) then this will not work. :-o

Named Activation Group solution
=========================
Another alternative would be to convert all of the called OPM programs 
to ILE -- CLP to CLLE, and RPGIII to RPGLE, and create PGM2 with a named 
activation group, e.g. ACTGRP(PGM2) ... and create all the programs it 
calls with ACTGRP(*CALLER).  Then, when PGM2 returns to PGM1, PGM1 issues:

     RCLACTGRP ACTGRP(PGM2)

This is one of the main benefits of using ILE with named activation 
groups -- you can control termination of a named activation group far 
more easily than with RCLRSC in "OPM compatibility mode" (in the 
*DFTACTGRP).

(Continue reading)

dmosley | 7 Sep 16:50 2010

Re: program won't let go of file

This brings up a problem that I have had for a while (and have just worked 
around it).  (Insert 'that's what she said' joke here, hahaha)....

But on CGI/RPG programs, if I HAVE to directly call the RPG program via 
the web, and that RPG program opens Service Programs, etc.
How does the service programs (and any open files within) get closed, when 
there is no CLP wrapper.

I know the proper answer would be to manually open/close the files, within 
service programs, but let's jsut say that's not an option.

David L. Mosley, Jr.
Technical Solutions Architect
Dancik International, Ltd.
2000 CentreGreen Way, Suite 250
Cary, NC 27513

www.dancik.com 

"Mark S. Waterbury" <mark.s.waterbury@...> 
Sent by: rpg400-l-bounces@...
09/07/2010 10:37 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@...>

To
RPG programming on the IBM i / System i <rpg400-l@...>
cc

Subject
(Continue reading)

Dennis Lovelady | 7 Sep 18:33 2010

RE: program won't let go of file

Not sure why open/close is not an option (performance?  Something else?)  If
it's a performance concern, one option would be to create a callback
function that would be executed xx seconds after use.  Such a procedure
might close the file if it hasn't been used in 120 seconds, for example.
You'd need to set an alarm that would cause the procedure to activate.  It's
usually best to trigger the alarm at the start of processing.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Better to remain silent and be thought a fool than to speak out and remove
all doubt."
        -- Abraham Lincoln 
> -----Original Message-----
> From: rpg400-l-bounces@... [mailto:rpg400-l-
> bounces@...] On Behalf Of dmosley@...
> Sent: Tuesday, September 07, 2010 10:50 AM
> To: RPG programming on the IBM i / System i
> Subject: Re: program won't let go of file
> 
> This brings up a problem that I have had for a while (and have just
> worked
> around it).  (Insert 'that's what she said' joke here, hahaha)....
> 
> But on CGI/RPG programs, if I HAVE to directly call the RPG program via
> the web, and that RPG program opens Service Programs, etc.
> How does the service programs (and any open files within) get closed,
> when
> there is no CLP wrapper.
> 
(Continue reading)

Mark S. Waterbury | 7 Sep 18:46 2010
Picon

Re: program won't let go of file

  Hi, David:

There is a good discussion of this in this IBM RedBook:

     http://www.redbooks.ibm.com/abstracts/sg244935.html?Open

HTH,

Mark

 > On 9/7/2010 10:50 AM, dmosley@... wrote:
> This brings up a problem that I have had for a while (and have just worked
> around it).  (Insert 'that's what she said' joke here, hahaha)....
>
> But on CGI/RPG programs, if I HAVE to directly call the RPG program via
> the web, and that RPG program opens Service Programs, etc.
> How does the service programs (and any open files within) get closed, when
> there is no CLP wrapper.
>
> I know the proper answer would be to manually open/close the files, within
> service programs, but let's jsut say that's not an option.
>
>
> David L. Mosley, Jr.
> Technical Solutions Architect
> Dancik International, Ltd.
> 2000 CentreGreen Way, Suite 250
> Cary, NC 27513
>
> www.dancik.com  
(Continue reading)

David FOXWELL | 7 Sep 17:04 2010

RE: program won't let go of file

> -----Message d'origine-----
> [mailto:rpg400-l-bounces@...] De la part de Mark S. Waterbury
> 
> DFTACTGRP solution
> =================
> Assuming all of these *PGMs are in fact running in the 
> *DFTACTGRP, then you can just issue:
> 
>      RCLRSC    LVL(*)
> 
> in PGM1(CLP), right after the CALL to PGM2 returns to PGM1.  
> This will close all open files and end all active programs 
> below the current level in the call stack.
> 
> NOTE: if somehow PGM4 or PGM5 were not compiled with CRTBNDRPG ... 
> ACTGRP(*DFTACTGRP) then this will not work. :-o

Thanks Mark. Pgms 4 and 5 are compiled to run in ACTGRP(*CALLER). PGM1 issues a RCLRSC at the end. I tried
adding this after the call to PGM2 but it didn't work.

PGM1 does an OVRDBF CLIENTFILE to qtemp/clientfile, then returns to a menu. Another menu option will take
me to PGM1b which will also call PGM5 along the line. At this point, although the OVRDBF CLIENTFILE is no
longer active, qtemp/clientfile remains open and PGM5 continues to use it instead of CLIENTFILE which is
in the *CURLIB.

Any thoughts?

 
> Named Activation Group solution
> =========================
(Continue reading)

Birgitta Hauser | 7 Sep 17:09 2010
Picon

AW: program won't let go of file

>>Assuming all of these *PGMs are in fact running in the *DFTACTGRP, then
you can just issue:
>>     RCLRSC    LVL(*)

This works only for RPGIII programs but NOT RPGIV programs!

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@...
[mailto:rpg400-l-bounces@...] Im
Auftrag von Mark S. Waterbury
Gesendet: Tuesday, 07. September 2010 16:37
An: RPG programming on the IBM i / System i
Betreff: Re: program won't let go of file

  Hi, David:

DFTACTGRP solution
=================
Assuming all of these *PGMs are in fact running in the *DFTACTGRP, then 
you can just issue:
(Continue reading)

Scott Klement | 7 Sep 18:26 2010

Re: AW: program won't let go of file

It'll work fine with RPG IV programs _if_ they are compiled with 
DFTACTGRP(*YES).  Otherwise, you need to use RCLACTGRP.

On 9/7/2010 10:09 AM, Birgitta Hauser wrote:
>>> Assuming all of these *PGMs are in fact running in the *DFTACTGRP, then
> you can just issue:
>>>      RCLRSC    LVL(*)
>
> This works only for RPGIII programs but NOT RPGIV programs!
>
--

-- 
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@...
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


Gmane