On 26-Aug-2014 07:09 -0500, rob@xxxxxxxxx wrote:
Every table created with SQL or with DDS should appear. The only
ones which will not appear are tables created with no external
description. Which are tables created like

To avoid confusion, non-SQL [physical] database files might best *not* be referred to as "tables".?

Every SQL TABLE should appear in SYSTABLES. Any Physical Files (PF) that are *not* Externally-Described will *not* appear in SYSTABLES; i.e. for a file for which the description [record format] must be Program-Described [aka being a flat-file], the logical condition (DBXREL='N') is true, and the logical condition (DBXREL='Y') is false.

Note: DBXREL is a column name of the system database cross-reference file QADBXREF that represents the database-file attribute that answers the question "Is Relational?" whereby the answer is either 'Y' for Yes or 'N' for No.

Now if you create your physicals like that and then do all your
logical files with substringing and whatnot to get individual columns
that way I suppose that you could get the scenario you've described.

A DDS LF will always be externally described, and thus _potentially_ eligible for appearance in the catalogs; an LF defined over a database flat-file is not inherently program-described. Only if the LF is considered to be a file that is _not relational_ will that file be excluded from the catalog VIEW; e.g. any Multi-Format Logical File (MFLF) will be omitted, because that is deemed to be "not relational", which equates with the logical (DBXREL='N'). Note that there may exist non-DDS LF that are classified as being /program-described/; I do not recall the effect for DBXREL attribute when BLDINDEX creates a logical file.

Was this crap migrated from S/36?

Even that would not explain a condition properly described by a claim that "SYSTABLES only show LF and no other files". Not having any of the system-supplied DDS PF and SQL TABLE database files being tracked among that data, would be a very improbable outcome. If the claim is accurate, then if the[ir] *DBXREF is functional [i.e. system job QDBSRVXR is not crying-out for help], their system may require a Reclaim Storage (RCLSTG) that includes a refresh of the *DBXREF data.

Note to Infor users: If you're wondering where IIML01 is you will

My guess... That is an LF that has multiple record formats defined, thus is _properly excluded_ from those SQL catalog VIEWs. That file however, if a database file, should be tracked in the QADBXREF data, irrespective any reason that file might be properly excluded in the SQL Catalog VIEW of that physical data.

Return to Archive home page | Return to MIDRANGE.COM home page