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-

This thread ...

Follow-Ups:
Replies:

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