Re: Query and DDM

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