Thanks for the input everyone, we'll be trying either a web service or DDM.
To be continued....


On Thu, Aug 27, 2015 at 12:56 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

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

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



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].