× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I have a puzzle that bothered me for at least 7 years. Thank you in advance for an explanation.

I have this puzzle for several years and I really want to get an answer.

I have a CLLE program created by CRTBNDCL where the DFTACTGRP is *YES.

This CL will have two overrides first before it calls a RPGLR program.

The RPFLE program is created by CRTBNDCL where the DFTACTGRP is *NO and the ACTGRP is QILE which is the named activated group defaulted by the system.


The activation group of the CL should then be the OPM default activation group *DFTACTGRP (is that correct?) while the activation group of the RPG is QILE. Why the override is still working properly? (Since the CL has a activation group different from that of the RPG, I don’t expect the override work. But it does work.)

Below is a simple description of the source code and the command to compile the programs as well as a prove that that override does work as expected. Why it works?



? CRTBNDCL ??PGM(MIS20/#ECM803C)
?*SRCFILE(MIS20/QCLLESRC)
?*SRCMBR(#ECM803C)
DFTACTGRP(*YES)
??REPLACE(*YES)

I have a CLLE program named #ECM803C which call RPGLE #ECM803R.
Inside #ECM803C, I have an override before I call #ECM803R as shown below.


IF COND(&CTLQAL *EQ &CMENV) THEN(DO)  THIS WILL USE LIBRARY MM4R6DVL
OVRDBF FILE(@ECMDETL1) TOFILE(@ECMDETL2)
ENDDO

IF COND(&CTLQAL *EQ &ROCENV) THEN(DO)  THIS WILL USE LIBRRY MM4R6RVL
OVRDBF FILE(@ECMDETL1) TOFILE(@ECMDETL3)
ENDDO


CALL PGM(#ECM803R)


#ECM803C is created by the following:
? CRTBNDCL ??PGM(MIS20/#ECM803C)
?*SRCFILE(MIS20/QCLLESRC)
?*SRCMBR(#ECM803C)
DFTACTGRP(*YES)
??REPLACE(*YES)


#ECM803R is created by the following:

? CRTBNDRPG ??PGM(MIS20/#ECM803R)
?*SRCFILE(MIS20/QRPGLESRC)
?*SRCMBR(#ECM803R)
DFTACTGRP(*NO)
ACTGRP(QILE)
??REPLACE(*YES)

Member/
File Library Device Scope Activation Group
@ECMDETL2 MM4R6DVL @ECMDETL2 *ACTGRPDFN QILE 0000000000000026 

The file @ECMDETL1 is properly overridden to MM4R6DVL/@ECMDETL2

Member/
File Library Device Scope Activation Group
@ECMDETL3 MM4R6RVL @ECMDETL3 *ACTGRPDFN QILE 0000000000000026
The file @ECMDETL1 is properly overridden to MM4R6RVL/@ECMDETL3.


Regards
Wai Mok
System Analyst


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Deon A von Blerk
Sent: Tuesday, September 11, 2007 11:21 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Issue with ovrprtf/dltovr (is this an activation group issue)


Hi Scott

date: Tue, 11 Sep 2007 15:10:39 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: Tell me more about activation groups (was Re: Issue with
ovrprtf/dltovr (is this an activation group issue))

It might be worth noting that your program is never removed from memory
if the activation group is never reclaimed. (This is true with
ACTGRP(*CALLER) as well -- except in that case, the programs are running
in *DFTACTGRP which Cannot be reclaimed, and therefore they always stay
in memory until the job ends.) This speeds up subsequent calls, but
also means that if you recompile the program, your batch job will
continue to re-run the old copy, and won't pick up the changes.

Thanks for the good explanation.
So why then do batch & interactive jobs behave differently?
With a batch job, the program is in memory and is released when the job
ends.
With an interactive job, it is in memory until the program ends. If one
compiles the program and then calls the program, the changed program is
called, not the one in memory - even though the activation group is still
active.

Hmmmm... I'm gonna have to test this... submit CL pgm, call pgma, delay 1
min, compile pgma meanwhile and see what happens.

Regards

Kit
(Still learning, after all these years)







As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.