× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 2/18/11 5:29 AM, Michael Ryan wrote:
Anyone heard of anything about being able to use DDM files in a
Query/400 type query? I was just asked about it, and AFAIK, it can't
be done. I think it can be done with QM, and I know you can use SQL
to remotely connect.

Any ideas? Something new in V6R1 or V7R1?


That goes way back. No support for DDM Files was included in the Query/400 due to the "confusing nature" of messaging in the interactive definition-time; the WRKQRY was meant for "users" versus programmers. Although considered as additional support just for run-time via either an OVRDBF or by use of the QRYFILE() parameter specifications, that idea just fell by the wayside; esp. since the generic file processing already had added explicit exclusion of any device files. The Query/38 and OPNQRYF [and so too I would infer, the QQQQRY API] each have support for query over DDMF that all point to the same [remote] system; the CQE performs the query on the target system and creates the query ODP from which the supported shared openers [RPG, CPYFRMQRYF, Qry38 query application report writer] can access the data just as if performed locally [with exception of messaging which often refers to the DDM File names versus the actual files].

The QM facility is [effectively] purely SQL, and there is no support for query [no DML] on DDMFiles in SQL. SQL does allow a CONNECT over DRDA to access a remote database. The report writer for QMQRY I recall has the ability by RDB() parameter of STRQMQRY to direct its query and FETCH activity to that remote database and present the data locally in its report [FORM]; I do not recall if for output to the display if that might bring all result set data local, using its SAVE DATA AS statement, or fetches to reports only what has already been retrieved or what must be retrieved according to positioning within the data.

Assuming nothing has changed from what I recall, the easiest might be... If the target library and file names match those named in the *QRYDFN [query definition object] on the source system, maybe just the request STRQMQRY TheQryName RDB(theRDBname) ALWQRYDFN(*ONLY) will suffice both as a test and as solution; being sure to consider ANZQRY output for noted impacts, then replacing with a true SQL query and a desired QMFORM.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

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.