|
On 02-Apr-2015 16:07 -0500, Dan wrote:
One the CL programs I'm updating has a CRTPF that references aThere are two typical paths, two methods essentially, for
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?
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."
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
