Re: Calling a remote program

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].