Hi Emily,
RPGPGM1 is a never ending program that runs in SBS Qbatch. It calls
RPGPGM2 a few times throughout the day right now, but the number of
calls to RPGPGM2 is going to increase significantly.
It takes about 1/10 second to create an activation group. At first
breath, that sounds like a small amount of time -- but depending on how
quick you expect this program to be, it might not be a small number at
all! For example, if you call this program 1 million times (such as
once for each record in a large database) that's an extra 100,000
seconds (more than a day!) of extra time just for creating the
activation group.
So give some thought to how often you plan to call this program. Think
about how significant this time will be.
Should I compile each program with their own activation group, or
should I compile RPGPGM1 with its own activation group and then
RPGPGM2 with *NEW as its activation group.
As far as the overrides are concerned, it doesn't matter. As long as
the two programs are in different activation groups, and the overrides
use OVRSCOPE(*ACTGRPDFN) (which is the default value), then the
overrides won't interfere with each other.
In that case, RPGPGM1 might be compiled with ACTGRP('RPGPGM1') and
RPGPGM2 might be compiled with ACTGRP('RPGPGM2'). The first time
RPGPGM1 is invoked within a given job, the RPGPGM1 actgrp will be
created, and it'll remain in memory until the job ends or you run the
RCLACTGRP command (which I advise that you DON'T do).
Likewise, the RPGPGM2 actgrp would be created as soon as you invoke the
RPGPGM2 program, and would remain active til the end of the job (unless
you run the RCLACTGRP command, which again, I don't advise.)
The idea is, they run in different activation groups, and each
activation group is only created once (and therefore performance is a
non-issue)
This will keep the overrides separate. Overrides issued in one
activation group won't affect overrides in the other activation group.
Keep in mind that this is a mixed blessing. If you call an old (OPM) CL
program that issues an OVRDBF, then it calls an RPG program in
ACTGRP('RPGPGM') that OVRDBF will have no effect on the RPG program
because it was issued in a different activation group. (Since OPM
programs always run in the *DFTACTGRP, which is a special activation
group that can't be reclaimed.) This is probably why you started using
*CALLER in the first place. However, if the override is issued from an
ILE program (in any language, CL, RPG, Cobol, C, or C++) that's running
in the same activation group as RPGPGM, the override WILL have an effect.
In your scenario (assuming that I understood it correctly) the overrides
for RPGPGM1 are issued directly from the RPGPGM1 program, and the ones
for RPGPGM2 and likewise issued directly from RPGPGM2. So this won't be
a problem for you, since the overrides are always issued from the same
activation group as the program. (they HAVE to be, since they're in the
same program!)
But the overrides from RPGPGM1 won't affect the ones from RPGPGM2
because that program runs in a differnt activation group.
Hope I explained that well enough.
I had thought that if RPGPGM2 was compiled with it's own activation
group that I would have to add code to RCLACTGRP in RPGPGM1 to
destroy that activation group when RPGPGM2 ended, and that if I used
*new the activation group would be destroyed automatically. Am I
correctly understanding the concept?
Yes, you are correctly understanding ACTGRP(*NEW). *NEW means the
activation group will be created with a random (numeric) name when you
call the program, and when the program ends it'll be destroyed
automatically.
It's equivalent to using a named actgrp, and running RCLACTGRP after
each time.
The performance gain for a named activation group comes from the fact
that you don't HAVE to reclaim it. You can leave it active -- and in
your scenario, I can't see why you wouldn't want to leave it active.
However, in a more modular scenario, where you have dozens or hundreds
or programs and service programs that all work together to accomplish a
common goal, and you want them all to be affected bythe same overrides,
same memory allocations, etc... then it makes sense to put them all in
the same activation group, and unload them all from memory at once by
reclaiming that activation group.
In your scenario, you have only two programs, and one of them never
ends. It's easy enough to end the second one by setting on LR, since
ther's only one program that do that for. That way, the activation
group can remain active, which speeds up subsequent calls.
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.
Reclaiming the activation group would pick up the changes, but at the
cost of creating and destroying the activation group... that 1/10 second
penalty I mentioned before.
midrange.com
