Re: Sys/36 re-engineering

I've seen no one mention in this thread regarding the CRTS36DSPF command.
When this command runs it creates DDS in order to create the screen
formats.  There are additional parms on this command that will put DDS
created from S & D specs to whatever source file and member that you want.
Normally it gets created in QS36DDSSRC in the same library as your QS36SRC
file.
To DDS source file . . . . . . . TOFILE         QDDSSRC
  Library  . . . . . . . . . . .                  *LIBL
To DDS source member . . . . . . TOMBR          *NONE

This is how we converted 99% of our S36 screen specs to DDS.  Of course
they still need some cleanup.  There are keywords which are used to minic
how S36 screens work that can be thrown out for native screens.

Regarding RPG36:  we used the method of changing the source type to RPG and
running the program through the CVTRPGSRC command.  We then used a utility
that we got from either ISeries Network or Midrange Computing magazine
called CVTRPGEXP to convert to use extended factor 2.  We cleaned up the
programs at this point.

I have to agree with the observeration regarding converting OCL to CL.
There is no one to one conversion.  I've converted using a tool and
converted from scratch.  I much prefer rewriting using native methods, such
as using OPNQRYF in place of #GSORT.  A lot of OCL techniques are no longer
needed in CL.

Of course all of this is much easier if your data files are clean as far as
numeric fields and your field naming techniques are consistent throughout
your database.  Before writing our current system way back when on a S36,
some of us had been exposed to S38 database and designed our database as
consistently as possible knowing that eventually we might have opportunity
to migrate to AS400, which we eventually did.

Just my .02.


Valene M. Williamson
IBM Certified Specialist
vwilliamson@glazers.com
972-448-8018