Re: Issue with Override in sub procedure / RPGLE

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)