Re: accessing QS3F data by utilities and 4GLs - where do they see thefield layout ?

It all depends of the quality of the system and the quality of the data.

I don't know if it isn't easy, but I sure know that it is a boring job
because
you have to more or less manually build FI-members for each file and typical
have to insert fillers and remove overlapping field descriptions.

And afterwards you have to test all programs where records are written and
updated because the typical error are that new records are written with
blanks in numeric zoned fields.

There are also the problems about files having several records formats that
has to be devided into several PF's and then join in a LF or where program
logic has to be changed.

Another way is to build a Field Reference File (Data Dictionary) and then
build the PF/DDS based on reference. This is probably a complete manual
task where you have to redescribe your files unless you already have some
documentation it can be harvested from. On the other hand you get great
documentation (if you use DDS) because you can automatically cross
reference field entities (where a field is used) in the database.

The bottom line is that it is hard to tell what method to use without seeing
the source/documentation available and without knowing how many files/
fields there are in the system. What can be harvested and what has to be
done manually.

IMO this is a necessary task simply because most modern tools and modern
RPGLE rely on the DB2 definitions and even if you found a tool that didn't,
you
still have to describe the fields and their position in your files just
like you do in
your RPG36 = doing the same job/definitions over and over again instead of
doing
the job/definitions once.


@nathan I think you also need the F-spec because in most 36 files the
record length is actually defined greater than the fields used.





On Sat, Mar 17, 2012 at 6:38 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

Having done this sort of thing in the past, I have to warn that it's not
as easy as it looks. RPG II programs in particular are notorious for
subfields, superfields, field redefinitions and so on. For example, one
RPG II member might define a whole date, while another might define only
the year. One program might show a field as zoned numeric while another
shows it as alpha. And in many installations, each program only defines
the fields it cares about, so you have to run through all the programs
to find all the field definitions.

Yes, it's doable, but it's not exactly simple. I spent several years
one summer writing a tool to do just that: convert an internally
described S/36 accounting system to S/38 externally described files.

Joe

If you think about it, most of what you need to externally define your

files is in the "I" specs. Record name, field name, field type, field
length can be derived from starting and ending positions, and decimals.

http://www.radile.com/rdweb/temp/gl100.txt


It would be pretty easy to write a program to harvest "I" specs from RPG

II source members and import them into a data dictionary. Then you could
then generate DDS or SQL DDL. You'd still need to enter column headings and
any other meta data you'd want.

----- Original Message -----
From: Jim Franz<jfranz@xxxxxxxxxxxx>
To: RPG programming on the IBM i / System i<rpg400-l@xxxxxxxxxxxx>
Cc:
Sent: Friday, March 16, 2012 7:21 PM
Subject: Re: accessing QS3F data by utilities and 4GLs - where do they

see thefield layout ?

there are several s36 to native conversion tools that work with RPGII

F&I.

Google "s36 to native conversion" for a list. From there you have native

dds

files
accessible from sql tools (have to work around multi record format
and multi member files). And there are services that do this for a fee.
Jim Franz

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.