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.


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.

This thread ...


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

This mailing list archive is Copyright 1997-2019 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].