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



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.