Re: QMQRY: Does this query tool support long field names (DDS Alias names) on iseries?

On 13-Nov-2015 14:11 -0600, Stone, Joel wrote:

If yes, how?

FWiW: QMQRY is an object type. As available /query tools/ associated with that object type, there are both the DB2 for IBM i Query Manager interactive utility [via the Start Query Manager (STRQM) command], and the IBM i Query Management run-time (also QM; though in program naming, is the /component/ QX). The Start Query Management Query (STRQMQRY) is the means to effect the same as the RUN QUERY of the QM interactive utility, but without actually starting the interactive utility. There are other commands with the QMQRY object type reference as mnemonic, and there is the command ANZQRY without that mnemonic, and additionally those with the QMFORM object type reference as mnemonic, that are all part of Query Management feature available as a run-time rather than as part of the Query Manager interactive utility which has its own procedural statements to effect the same... and thus for which there is the additional run-time command Start Query Management Procedure (STRQMPRC).

So anyhow... Yes. Both the run-time and the interactive utility do "support long field names (DDS ALIAS names)" on IBM i [and IBM System i, and iSeries and AS/400]. The support is there, irrespective of the names having been defined as column names using the SQL DDL or defined as field names via the DDS ALIAS() specification.

That is to suggest, that both the run-time and the interactive utility of the QM _accept_ the long names for column specifications. And, the interactive utility provides the long name in lists [though the full name may not be completely available without using a function key such as F20="Display entire name"]. IIRC some interfaces in the interactive QM feature may not even show the short names; e.g. the "Select Column" within the 11=Display Data or 8=Display Definition with the 3="Work With Query Manager Tables" interface under STRQM? When a _field list_ is presented, there may be a function key available either "F19=Display system field names" or "F19=Display field names" to toggle which are displayed; the "F24=More keys" may need to be pressed to reveal the F19 functionality available, if not conspicuous to infer from the list presented.

However, if the perspective of "this query tool" is narrowly limited in scope to, for example, what the Retrieve QM Query (RTVQMQRY) feature can effect when that command request is directed against a QRYDFN object type [e.g. perhaps per the ALWQRYDFN(*ONLY) specification], then the answer would be instead:

No, that specific feature does not give any ability to generate the long name, because the Query/400 feature does not refer-to nor store the alternative name. Only the short-name of the field is available to that Query/400 [aka IBM i Query] utility, so the long-name is not there to be retrieved. For any table-references in a QRYDFN for which exists the file of that qualified name at the time of the retrieve request, the retrieve feature should be able to correlate the short name to a long name and write the long name to the source. But I doubt such a change-request would be accepted because the proper resolution would be to store the names in the QRYDFN object rather than limiting the retrieve feature to being functional for that effect only when the named file can be located at run-time; though if that is an issue or the issue of concern, then my doubts should not be taken as an attempt to discourage anyone from asking.

If no, how do you make sense of longer queries with cryptic 6 or 10
character names?