On 21-Nov-2014 13:50 -0600, RPGLIST wrote:
I haven't run into this specifically before today, but I'm wondering
what a suitable solution would be.
I have an override on a multi-member file. In a sub-procedure I have
the same file declared locally that is adding and deleting some
records, but I've noticed that the file in the procedure is ignoring
the override.
So the sub-procedure is opening and thus performing I\O against the
*FIRST member, rather than against the overridden-to member? Yet the
mainline program is opening and thus performing I\O against the
overridden-to member as expected?
Is there a reason for this? I would have thought that since the
OVRDBF is at the program level (CLLE that calls the program) it would
hold it for the secondary declaration in the procedure.
My perfunctory thought is to agree; that with just one override and
the same file name declared\opened at both the program-level and the
procedure-level, I would expect each Open Data Path (ODP) to have
accessed\addressed the same file.member; or that the second would have
been a shared open\ODP, but either way, the same member being opened for
both. That is to suggest, if the Override Scope (OVRSCOPE) is properly
in effect for the open in the program, then the same should hold true
for the open in the sub-procedure, irrespective the actual choice for
that parameter specification.
But without actual specifics about the declarative, the override, and
compiles, I would not give much more thought on what might be the issue,
as that requires too much speculation of the environment; I would think
a CL job stream with the //DATA source-members of a representative CL
and RPG should be possible to generate a full re-create scenario
allowing for a thorough review by anyone.
Suggestions, in this particular case I need BOTH the mainline and
the procedure to use a specific member.
The EXTMBR specification for the file declarations would seem the
most obvious choice to circumvent the issue with the override; I would
still try to figure out the issue with the attempt to use OVRDBF, either
to avoid a similar [apparent] misunderstanding\caveat in a future
attempt to use an override or to ferret out an apparent defect.
Also a possibility is using a logical file that has just one member
addressing the data from the specific physical file data member; like
EXTMBR, that should avoid any dependence on the Override With Database
File (OVRDBF).
I typically have had to make two distinct opens, each to a different
member within one program [none was procedure-scoped declaration], and
for that I would use two overrides; override each specific member name
to the same file [name] but each to the respective member:
ovrdbf memberX tofile(the_file) mbr(memberX) ovrscope(as-rqd)
ovrdbf memberY tofile(the_file) mbr(memberY) ovrscope(as-rqd)
midrange.com
