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!


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:
IOW, what /specifically/ was the generated statement?

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.

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 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].