Re: Migration from S/36 to AS/400 -- RPG400-L

And lest we forget...
Stop deleting/rebuilding files.  In other words, where you see the DELETE
followed by BLDFILE do one of two things.
1)  If it is a permanent file then switch these two lines of code to one -
CLRPFM.
2)  If it is truly a work file then put it in the library QTEMP.

Rob Berendt

==================
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "James W.
                    Kilgore"                To:     rpg400-l@midrange.com
                    <qappdsn@attgloba       cc:
                    l.net>                  Fax to:
                    Sent by:                Subject:     Re: Migration from 
S/36 to AS/400
                    rpg400-l-admin@mi
                    drange.com


                    11/09/2001 09:08
                    AM
                    Please respond to
                    rpg400-l






Ammayappan,

IBM published a Redbook GG24-3304-xx titled "Converting System/36
Environment
Applications to Native AS/400"  in 1988.  You still may be able to get a
copy
of it.

I'm sure that there are tools being sold.  They have questionable worth.
IMHO, converting OCL to CL is not worth the exercise.  Unfortunately to
truly
go "native" one must rethink the process being performed and create a new
solution.

Back in the old days, we converted from S/36 to native in a multiple phased
approach:

1) Normalize your data base to at least 2nd (and preferably 3rd) normal
form.

We already had this on our S/36 apps so we were sitting pretty.  (BTW, the
reason we did this was because in 1982 we had some S/38 work and could see
where the future was going)

2) Externally define all files.

There are tools that will help with this.  You can still run your RPGII
programs against these files, but once they are externally defined you can
start to replace your RPGII code with RPG/400 code.  Also, since RPGII
allows
you to put blanks into a numeric field, you will want to write a trigger
program that ensures that you avoid data decimal errors.

What we did was this:  When externally defining our files we created the
file
under a NEW name, but used the old S/36 name as our RECORD name.  Then we
created a logical file with the name that the S/36 procedure was used to
using. So, if in your RPGII program you have IMKEY CHAIN ITEMMAS you would
change it to IMKLST CHAIN ITEMMAS and change your "F" spec from FITEMMAS IC
F
to something like FITEMMSTRIF  E and a READ ITEMMAS didn't need any change
at
all.  With ITEMMSTR having a LF named ITEMMAS the OCL didn't need any
changes.

3) When you compile RPGII screen S/D specs there is an option to have those
automatically converted to DDS specs.  RPGII and OCL programs can work with
these DDS specs.  Convert all you screens.  This is included with the base
OS/compilers.

4) Start with your batch type jobs.  Even OCL can call a native RPG
program.

5) Realize that their is no "magic" way to go full native.  It's a matter
of
converting each and every program and procedure and screen format one at a
time.

6) Put on a fresh pot of coffee.  It's going to be a long night. <g>


Ammayappan_M wrote:

> Hi,
>
>    I would like to know if there is any tool for migrating S/36 system
> to AS/400 environment. If there is a book which describes the strategy
> and process for the same, let me know the name of the book.

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