Charles,
I first call my CLP with a file, a library and a member name. My CLP
does the correct OVRDBF. Then my CLP calls my RPG/ILE program.
In order for that to work, do the following:
a) Change the CL program to ILE CL instead of OPM CL.
b) Change the CL program to ACTGRP(*NEW).
c) Change the RPG program to ACTGRP(*CALLER)
Make sure the OVRSCOPE in the OVRDBF is set to *ACTGRPDFN (which is the
default, but I'd make sure...)
If I understand your explanations correctly, I must not use my file
as a primary file. I must do a loop in my program to read it manually
until the end of file after opening it with an OPEN opcode.
No. Not true. It doesn't matter at all whether the file is primary or
not. Your problem is a combination of the way overrides work and the
way activation groups work.
The default value for OVRSCOPE on the OVRDBF command is *ACTGRPDFN. I'm
assuming that you've kept that default. *ACTGRPDFN means that if the
override was given in an OPM program (or an ILE program
w/DFTACTGRP(*YES)) then the override is by call-level. If it was given
in an ILE program, then it's done by activation group.
Since you say "CLP" when referring to your CL, I assume it's an OPM CL.
So, it's call-level.
The way a call-level override works is that the level closest to the
user takes precedence. For example, let's say I had the following CL
program:
PGM
OVRDBF FILE(CUSTMAS) TOFILE(TEST1)
CALL SOMEPGM
ENDPGM
If I call that CL program, it'll run SOMEPGM and use a file named TEST1,
right? Maybe. It's true that if there are no other overrides in
affect, it will. But, what if I override the override? In other words,
before calling the above CL program, I type this:
OVRDBF FILE(CUSTMAS) TOFILE(TEST2)
CALL ABOVE-CL
When "SOMEPGM" runs in this case, it'll actually reference TEST2 instead
of TEST1. Because the override at the command line takes precedence
over the one in the CL program. I've overridden an override!
During the call, the stack looks something like this:
OVRDBF
CALL ABOVE-CL
OVRDBF
CALL SOMEPGM
Since the first OVRDBF is the "outer-most" (i.e. the highest level, and
closest to the user) it takes precedence over the second one.
Now let's consider your scenario:
Your first CL program does an override, then calls the RPG. The RPG
calls the CLP again, which issues a new override. So you have this:
OVRDBF
CALL RPG
CALL CLP
OVRDBF
CALL RPG
CALL CLP
OVRDBF
CALL RPG
So your override on the first call to your CLP takes precedence over all
of the other ones. It's at a higher-level and therefore has the highest
precedence. You could solve this problem by adding SECURE(*YES) to the
override.
OVRDBF SECURE(*YES) means that it'll ignore any higher-level overrides...
However, I find the whole scenario confusing... nesting overrides is a
messy business, you never know what will happen! So I try to avoid it.
It's especially silly here becuase you're using ACTGRP(*NEW). Each copy
of the program runs in a different activation group, so why not make the
overrides only affect that activation group? That way you won't have
any conflicts.
But now you have a problem. The new ACTGRP isn't created by the CLP,
since it's an OPM program, and can't participate in activation groups.
That's why I suggest changing the OPM CL to an ILE CL. ILE CL can use
activation groups, and since it's syntax is identical to OPM CL, there's
really no disadvantage. Just change the source member type to CLLE
instead of CLP. If you compile from the command line or from WDSC, use
the CRTBNDCL command instead of CRTCLPGM. If you compile from PDM,
it'll automatically switch to CRTBNDCL when you change the member type.
When you compile the CLP, use ACTGRP(*NEW) so that the activation group
is created when the CL program begins. Then change the RPG program to
ACTGRP(*CALLER). This will make the CLLE and RPGLE programs run in the
same activation group. That way, if you issue an override that's scoped
to the activation group, it'll affect only those two programs.
Make sense?
midrange.com
