On 22-Oct-2015 08:04 -0500, Justin Dearing wrote:
So I get the whole sys_column_name versus column_name thing as
compatibility with things that were built for 10 character columns.
However, the shop I'm in is quite adamant about using LABEL FOR to
add column labels and column text to them. Is this just meta data
that could be referenced through the system catalog views, or does
RPG intrinsically use this somehow when labeling fields on screens
bound to physical files.
Yes, there is tie-back to green screen from the string-constant that
can be specified for both a TEXT IS string-constant and an IS
string-constant clause of the LABEL statement for a column-name; the
LABEL ON statement provides the equivalent of either the field TEXT() or
the field COLHDG() [Column Heading] capabilities of the DDS. Many
5250-based utilities depend heavily on the ability of the user to access
that specific metadata, the TEXT and COLHDG, for usability.
Yet, the reasons for adding the labels is typically just as useful
[and towards the same ends] for client\GUI [reporting] features as for
the various green-screen features\utilities. So probably best always to
add them irrespective the possibility for references being made to the
files via the green-screen.
FWiW:
Those entities are just decorative metadata rather than functional
metadata, and AFaIK the RPG has no formal means of communicating those
specific attributes from the file to into the program; i.e. unlike with
the column definitional attributes of both the data-type and the
length\size, as details that are automatically included per an F-Spec
[or similar, like EXTNAME], those additional metadata must be extracted
by a means other than simply /declaring/ the file in the program. The
Retrieve Database File Description (QDBRTVFD) API, the Display File
Field Descriptions (DSPFFD) command, and the List Fields (QUSLFLD) API
are three [at least the first two] methods to directly retrieve\extract
the /external/ [to the program] definition of a Record Format (RCDFMT)
from the *FILE object, to obtain the TEXT and the COLHDG information.
However the usefulness at the green-screen is really no different
than for a client interface that might best have access to, the
COLUMN_TEXT or COLUMN_HEADING as obtained from an sqlColumns() API
invocation or query of SYSCOLUMNS, for presentation of a list of
columns; i.e. providing more than just the COLUMN_NAME values, typically
in a list, presented to the user. And a client interface is similarly
just as likely to use the COLUMN_HEADING meta-data when formatting a
report, as a 5250-based report-writer would. Similar LABEL information
is available and utilized from having given the descriptive text to the
/file objects/, and for similar reasons. Note: the LABEL is noted to be
restricted to TABLE and VIEW via SQL, as implied by the clause syntax,
though I do not recall how thoroughly the SQL enforces the restriction;
on v5r3 the msg SQL7011 second level text suggests that the support is
available for any of "a table, view, single format logical file, or
physical file", but I just tried labeling a column of a simple
one-format LF without success, contradicting my memory of being able to
do so.
One such green screen utility, the Query/400 feature, also enables
access to the COMMENT ON information [LONG_COMMENT] for columns and
files; which oddly [though perhaps not so odd, for those aware of the
origins for that capability] the STRQM and STRSQL none of the file-list
and column-list presentations still did not, the last time I checked;
they do show the TEXT. With the Query for IBM i feature, the F23="Long
Comment" will present the commentary, which if established, can be very
valuable information to a user; e.g. enumeration of the allowed values
for a column, or for a file what are parent files or what files have
related-data and what type of relationship. The query feature even has
access to a COMMENT for a Record Format, but that is something not
directly [is only conceptually] available to the SQL.
midrange.com
