Re: ovrdbf SHARE parameter

Dennis Lovelady wrote:

Dennis Lovelady wrote:

You said (paraphrasing since I don't have the original here) that CLP (which I hope is actually CLLE) does: OPNQRYF followed by CALL TESTPGM... and TESTPGM uses the same
filename.

David Foxwell wrote:

Here's what I wrote originally:

CLP OPNQRYF (myfile) with kfld changed from 5 to 3 kflds.
call testpgm

testpgm calls mypgm which also uses myfile and the 5 original
kflds.

Obviously, the opnqryf must be changed, but how should we have
done it?
<<<<<<<

CLP, (not CLLE!) does the OPNQRYF and calls testpgm(the program
my coworker was testing) as it has done for several years. A
subprocedure called by testpgm now calls mypgm.

You failed to answer questions about OVRSCOPE and OVRDBF but
I'll assume that, one way or another, the OVRSCOPE(*JOB) was
used, and that SHARE(*YES) has been specified.

The OPNQRYF and OPNDBF have an OPNSCOPE parameter. The OVRxxxF commands have an OVRSCOPE parameter.

In mypgm, the file used in the opnqryf is declared. Thus, as I
have learned from the experts during this thread, mypgm will
not open a new data path, but share that of the opnqryf.

We have addressed the fact that ODP will not be implicitly
shared.

If a member was added with the share attribute established as SHARE(*YES), then the first open will be activated with sharing enabled unless requested otherwise; i.e. the default for an open, possibly to be described as /implicit/, may\can result in a shared ODP against which future opens will attempt to share. So it is the SHARE(*NO) [either as an open specification, or by an override] that must be explicitly requested to prevent accidental sharing. Albeit the member attribute SHARE() defaults to *NO on both the CRTxF commands and the ADDxFM commands.

However, a subprocedure in mypgm issues a chain to myfile,
using 5 keyfields. The opnqryf specified 3 kflds and the
program crashes with the message that I'm using too many fields
to access the file.

One solution to this would be to use a different filename (and different OPENID) for the OPNQRYF. That would involve a change to
MYPGM and to the OPNQRYF command. Another would be to use
consistent number of keys (5). If the three keys you are using in
MYPGM are not the same as the first three keys used by TESTPGM,
you are asking for trouble unless you use different names. If
they ARE the same, however, then a change to 5 keys in OPNQRYF sounds like a right solution.

The OPNID for the OPNQRYF or OPNDBF is pretty much unrelated to if\how a file.mbr is shared, as its name is only used in effecting CLOF & POSDBF. The open identifier merely declares the storage location for maintaining the ODP, since there is no program static or automatic storage to do so. What directs an open to an existing ODP for possible sharing [irrespective of possible open identifier], is the override.

Having said that, you know (and we don't) how these files must be
accessed. We can make recommendations until the stars all fall,
and still be dead wrong since the only thing we know about your
goal is that you want to understand override scopes.

Or simply that the OP needs to know that MYPGM needs to be aware that the subprocedure requires an open without sharing, so would need to effect a secured-as non-shared open.?

Regards, Chuck