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



In 1990 I wrote, and News 3x/400 published, RTVDDSSRC as the Program of the
Month (of the Year). My very small contribution to the IBM programming
space. I still have the source code and it will still work, I believe, but
I haven't used it in years (decades?).
It uses the DSPFD outfile data as described by Vern below.
It does PFs, LFs, and Join Files.

I can send it to you if you are interested.

There is at least one other version of RTVDDSSRC by another author on the
internet.

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Vernon Hamberg
Sent: Thursday, June 25, 2015 5:00 PM
To: Midrange Systems Technical Discussion
Subject: 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.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.