On 27-Aug-2015 00:22 -0600, John Yeung wrote:
On Wed, Aug 26, 2015 at 8:18 PM, CRPence wrote:
On 26-Aug-2015 16:36 -0600, John Yeung wrote:
<<SNIP>> I can't just treat the unadorned DDMF as though it were
a PF or table. Now *that* would be simple. <<SNIP>>
Recalling my experience, the use of a DDMFile was quite seamless;
both the RPG compile and the RPG run-time acted on the DDMF the
same as if acting on a local version of the Physical File or the
Logical File [aside from some extra messaging about DDM
conversations IIRC], and neither of Open Database File (OPNDBF) nor
Override With Database File (OVRDBF) were required
I have very little reason to doubt you, but I'm equally confident I
didn't just imagine the error messages I got. I'll check again when
I'm able.
If the error is anything to do with the member name, try using the
nonstandard file name (*NONSTD) to specify a member name. The format of
the naming is 'LIBRARY/FILE(MEMBER)'.
Also, I tried other things besides RPG to access the DDMF directly,
such as RUNQRY. Nothing worked.
All of the Copy File (CPYF), Open Database File (OPNDBF), and Display
Physical File Member (DSPPFM) utilize /native/ Open capabilities just as
does the RPG Open, so they all are capable of effecting [a near
seamless] open of the DDMF as if a database Physical File (PF) [or
Logical File (LF) for the former two, as the latter verifies the opened
file refers or redirects only to a physical dataspace]. For commands
such as Display File Description (DSPFD) and Display File Field
Description (DSPFFD), there is a System (SYSTEM) parameter on which the
default is to refer to the Local (*LCL) file, so the explicit
specification of SYSTEM(*RMT) may be required\desired to see redirect
the request to the remote\target system [which is of course, less
seamless than /open/ for which the redirect is implicit].
A Classic Query Engine (CQE) request can operate on a DDMF [or
multiple, but only if the data all resides on the same target]. Thus
the QQQQRY API and Open Query File (OPNQRYF) can both query a database
file on a remote system by opening a DDMF on the local system.
However with the Query/400 feature [RUNQRY RCDSLT(*NO) being one of
the run-time interfaces] we decided upon explicitly prohibiting the use
of DDM Files due to the confusing nature of messaging for communicating
the true effects of a request; more serious contemplation was given to
allowing the use of DDMF solely in run-time, despite the indirection;
i.e. continuing to disallow them in definition-time. The intention of
the Query/400 was to direct\design the utility to the end-user,
mimicking the Query/36, unlike the Query/38 which was directed more
toward programmers [and for which either implementation, optimized or
non-optimized queries, allows access to DDMF, but with the same CQE
restriction at least for the /optimized/ path per the /optimizer/ being
that of the CQE].
midrange.com
