×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
CRTPF FILE(ROB/BLARNEY) RCDLEN(20)
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
not find it in SYSTABLES, SYSPSTAT, SYSVIEWS or SYSINDEXES.
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.
midrange.com
