Re: How to get called program to write records to physical file member.

Howdy Bryce,

I have a program, in that program I use QCMDEXC to create a new member on
a physical file. Then I do an OVRDBF to that member. I then call another
program - yes program, not a module or service program, to write some
records to that file.

Did the called program already have the file open before the ovrdbf ran? If not, is the called program running in the same activation group, or a different one? If it's a different one, did you set the ovrscope parameter to include other activation groups?

Have you considered passing a parameter with the member name, and using the EXTMBR keyword in the called program? IMHO, that would be a lot cleaner than OVRDBF.

Then I call a procedure from a module that is bound to my program to
do some stuff and read from that member I just created and populated.

Which program is it bound to? The first one? Or the called one that writes the records?

If it's the first one, then the problem seems to be the override scope/activation group. If it's the second one, the problem seems to be the file being open before the OVRDBF is issued.

Can someone explain why the called program doesn't retain the OVRDBF to
the proper member and what I can do to fix this?

OVRDBF only applies to a file when the file is opened. It has no impact any other time.

The default value for the OVRSCOPE parameter of OVRDBF is *ACTGRPDFN meaning that the behavior is "activation group defined" (i.e. it depends on which activation group the OVRDBF was issued from.)

When issued from the *DFTACTGRP (the OPM activation group) the OVRSCOPE parameter will be *CALLLVL, meaning that it affects programs called from the one that does OVRDBF as well as any programs called by that called program, and so forth, recursively.

When issued from an ILE activation group, it only affects opens that occur in that activation group.

Changing the OVRSCOPE parameter to OVRSCOPE(*CALLLVL) makes it work in ILE the same way it did in OPM.

Is the only way to do it
by passing the member name to the called program so it can do its own
OVRDBF?

I would eliminate OVRDBF which I've always thought was a yucky kludge. Pass the member name as a parameter, and use EXTMBR on the F-spec to control which member is accessed. Much cleaner.

But, no... the OVRDBF from the caller will also work, if coded correctly.