On 02-Apr-2015 16:07 -0500, Dan wrote:
One the CL programs I'm updating has a CRTPF that references a
specific member in *LIBL/QDDSSRC. Since the library that has the
source for this member is far down the job's LIBL and there are
multiple libraries higher in the LIBL with QDDSSRC in them, I was
surprised that CRTPF "found" the member. I would have expected the
behavior to be "not found" in the first QDDSSRC, according to the
LIBL.
Besides CRTPF, how many other commands exhibit this behavior? And,
how long has this feature been around?
There are two typical paths, two methods essentially, for
resolving\finding a member by name. One could be called the /open/ path
which is what a Data Management Open will effect. The other could be
called the non-open path; effectively, what might be thought of as
perhaps more logical processing, for which after the file name is
resolved, if the member is not found in that file, then processing stops
with a "member not found" condition. The find-for-open path keeps
looking for a file of the same name with that member name. FWiW the
internal object name used for a member (*MEM) object makes that
search-path for name resolution conspicuously more logical; i.e. the
ten-byte prefix of the member name is the file name, so looking for a
member named THE_MEMBER in *LIBL/QDDSSRC searches for a list of members
named as:
'QDDSSRC THE_MEMBER'
Interfaces that provide essentially purely /open/ interfaces will
utilize the Common Data Management Open path to find the member; e.g.
Open Database File (OPNDBF). Like Create Physical File (CRTPF), likely
most commands with a Source File (SRCFILE) and Source Member (SRCMBR)
parameter for which they directly effect an Open by the specified name
will exhibit the same behaviour; i.e. the open-path. Some features that
want to perform more validity checking for their open processing, such
as the query and copy utilities, are more likely to use the non-open
path and thus report a "member not found". If the open path did not
find the member, then the error is likely msg CPF4102 which has a number
of reason codes.
See the doc in the following API which allows one to find the member
in the either manner:
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qusrmbrd.htm>
_Retrieve Member Description (QUSRMBRD) API_
"...
The Retrieve Member Description (QUSRMBRD) API retrieves specific
information about a single database file member and returns the
information to the calling program in a receiver variable. The length of
the receiver variable determines the amount of data returned. You can
only use the QUSRMBRD API with database file types *PF, *LF, and *DDMF.
...
Optional Parameter Group 2
Find member processing
INPUT; CHAR(1)
The method to use to find the member. There are two ways to find
the member for which information is to be retrieved. The possible values
are:
0 Find the file first and then look for the member in that file.
This is the default value if this parameter is not specified.
1 Find the specified member directly. This method is more
efficient when *LIBL is used for the library name and a specific member
name is specified.
If a specific library is used to find the member, or if the member name
specified is *FIRST or *LAST, the two ways will always find the same
member. If *LIBL is used for the library name and a specific member name
is specified (not *FIRST or *LAST), then the two ways can produce
different results. See _Find Member Example_
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qusrmbrd.htm?lang=en-us#FIGFNDMEX>.
..."
FWiW The REXX feature had originally [incorrectly] coded to use the
non-open path for either or both Start Rexx Procedure (STRREXPRC) and
procedure\function invocations, and IIRC there is a Data Area
Implementation or something similar to change the behavior of that
feature. Hmm, knowing I had mentioned that here in the past, a search
yielded the following archived message [for which the issue of the OP
was the REXX interface for the Command definition Rexx; Source Member
(REXSRCMBR) and Rexx Source File (REXSRCFILE) specifications]:
<
http://archive.midrange.com/midrange-l/200804/msg01542.html>
"the STRREXPRC (Start REXX Procedure) command code has been changed to
look for QIBM_REX_FIND_SRCMBR environment variable, which might contain
one of the following values:
*BYMBRNAME - REXX would find the source member by looking for the
source file that contains a source member by the name specified for the
SRCMBR parameter.
*BYFILENAME - REXX would find the source file specified and, if the
file is found, look for the source member in that source file. This same
behavior is followed if the environment variable exists and contains any
other value, or if the environment variable does not exist."
midrange.com
