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?
midrange.com
