Re: Displaying the contents of QSYS2.SYSTABLES.TABLE_TEXT

To Justin through Chuck's reply!!

Justin, Chuck mentions the OIR of an object - I believe that means Object Information Record.

You can see what it is by using the DMPOBJ command - this will create a spooled file that has the contents of the object in hex and character (where displayable) representations.

This can be quite instructive - BTW, for *FILE objects, the actual data is not included in the spooled file.

Everything on an IBM i is an object - and each kind of object (*PGM, *FILE, DTAARA, etc.) inherits several attributes from the basic OBJECT. Most commands for creating things have a TEXT parameter, which applies to the object level and appears in the OIR. Other attributes specific to the "subclass" that is a *FILE will appear elsewhere, either as some coded value or actual text - an example would be the TEXT description of each column of a table.

Just to digress - and I found this interesting, and thanks to you for making me dig into it - the COMMENT ON statement of SQL actually puts those long strings into the respective parts of the object - the COMMENT on a table appears in the OIR, and those for columns are in the main body (wrong name, but OK) of the *FILE object.

Hope this gives you a little entertainment! And maybe a touch more insight into things IBM-i-ish!

Cheers
Vern

On 12/17/2015 2:35 PM, CRPence wrote:

On 17-Dec-2015 13:48 -0600, Justin Dearing wrote:

On Thu, Dec 17, 2015 at 12:41 PM CRPence wrote:

On 17-Dec-2015 10:14 -0600, Justin Dearing wrote:

<<SNIP>>

IOW, what /specifically/ was the generated statement?

LABEL ON TABLE SCHEMANAME.VIEWNAME
IS 'A long string of human readable english' ;

GENERATE_SQL generates 3 label statement, at least when I invoke it
the way I do. The one above, and two large ones that ad the label and
text values for the columns

What am I doing wrong?

Possibly nothing.

In this case I think you're right.

The data, in fact, may not _be_ in the catalogs.<snip/>

So to summarize, QSYS2.GENERATE_SQL() is looking in multiple places
for the label statement, And QSYS2.SYSTABLES.TABLE_TEXT does not.

Likely both features look the same place for the text; i.e. within the *FILE object. The latter however, *looked* [past-tense emphasize] sometime in the past when the file was created or changed or when the DBXREF catalog data was last refreshed, such that the data was stored in the row; the data is not retrieved from the object dynamically when the catalog is queried. The former would look at the *FILE on disk, thus dynamically retrieving the data from the object.

I tried to allude to the possibility that the TABLE_TEXT not being visible in the catalogs may have an origin in a defect; that the correction was to re-apply the label [I suggested using LABEL ON TABLE, but CHGPF TEXT() should effect the same, and what is the effect of CHGOBJD TEXT() I do not recall, but IIRC the /Librarian/ feature [that maintains the OIR of the generic object-types] invokes the Database [as object handler] when the OBJTYPE(*FILE) Object Type is of the Database File (DBF) specific variety of *FILE in order that the Database can do any /extra/ processing such as notify the DBXREF that the file TEXT attribute has changed. Thus the effect of each should be similarly reflected in the catalogs.

-snip-