Re: Looking for file structure details

Hi John

I took a quick stab - what about using a couple options of DSPFD to *OUTFILE, along with DSPFFD to *OUTFILE?

You can use the *ACCPTH option of DSPFD and get all the key field information, if any.

You can use the *JOIN option of DSPFD to get all that information.

You can use the *BASATR to an *OUTFILE for all file type.

You can use *ATR to an *OUTFILE when you specify the file type - each has its own layout.

Finally, DSPFFD has an *OUTFILE option that gives you all the field information.

Once you have all that, you can build something to do what you need, I think.

HTH
Vern

On 6/25/2015 3:36 PM, John R. Smith, Jr. wrote:

Thanks for the heads up on what SYSCOLUMNS is missing. It probably would
have bitten me eventually. :(

The task is to create a "cloned" file that is not a true clone. The
original files were created via SQL and we currently have that but I have
been requested to provide DDS without things like field aliases and colhdgs
and to change the key fields. Even if I convince them to use an SQL
version, I still have to edit the SQL remove the stuff they don't want and
also change the key structure.

To further enhance my pain, it looks like I am stuck with the APIs because I
am not authorized to the files that you listed that contain the information.

Thanks to all for the input.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Thursday, June 25, 2015 3:35 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Looking for file structure details

On 25-Jun-2015 12:57 -0600, John R. Smith, Jr. wrote:

I need to generate DDS for a BUNCH of PFs. I have tried several
versions of programs that retrieve DDS and all of them seem to have
bugs that are making this task even more difficult. To add more
difficulty, some of the specific in them (record format name, keys,
etc.) has to be modified slightly from the original.

I have given up on the freebie products and I am working on writing
something that will do exactly what I need. To do this, I am trying to
avoid APIs and DSPFFDs to an outfile. Instead I am trying to obtain
the details using SQL. I found SYSCOLUMNS which provides all of the
field level information.

Unless things have changed beyond what I recall, /all/ is too generous a
term both for the SYSCOLUMNS and even the underlying table QADBIFLD; numeric
editing surely remains unavailable, and possibly still the VARLEN(vlen)
vlen-specification is not included.

The tracking of the file\field information is available mostly to supply
data for the SQL Catalog VIEWs [and for the IDDU], so avoiding the APIs
[e.g. QDBRTVFD] or avoiding both of the Display File Field Description
(DSPFFD) and Display File Description (DSPFD) to get the
field/reference/key/format information is not realistic for the sake of
completeness; and files in QTEMP are not [yet] tracked in the *DBXREF
[System Database Cross Reference] files, so testing would be limited to
test-files created in permanent libraries.

I have not been able to find anything that tells me the record formats
or keys.

The record format is in the underlying data; column DBIFMT of QADBIFLD
(use QADBIATR as an authorized LF to get the same data).

Key field information is in SYSKEYS and QADBKFLD (use QADBKATR as an
authorized LF to get the same data).

Also, if the file has multiple record formats, how
do I know which fields in SYSCOLUMNS belongs to which format?

Each Record Format (RCDFMT) is maintained in the underlying file and
the column DBIFMP of QADBIFLD is the relative format to distinguish
between same-named formats in a Multiple Format Logical File (MFLF); an
MFLF precludes tracking by the SQL Catalogs as the file is considered
non-relational, and thus DBIREL='N', but an effective predicate in the
SYSCOLUMNS is DBIREL='Y'.

We are running 6.1.

Can anyone help point me in the right direction?

Perhaps use the "Generate SQL" Generate Data Definition Language
(QSQGNDDL) API instead? The TABLE sources will not be limited to only
the DDS-supported data types.