Re: Move S/36 to AS/400

At 18:48 06/29/1999 , Debbie Gallagher wrote:
>     Can anyone tell me what is involved in converting an application that 
>     runs in the System/36 on AS/400 application to a regular AS/400 
>     application? Not to make it take advantage of the extra advantages of 
>     AS/400 but just to run. Is this dead simple, or extremely complicated 
>     or something in between? What would some of the issues be?

As usual, it depends...

The hardest part is the OCL. It needs to be converted to CL. This can be
time consuming, but is not difficult, except that there are some functions
that cannot be directly duplicated. IF ACTIVE, BLDINDEX, RETAIN-J and
pretty much all OCL parameter processing come immediately to mind. With the
exception of IF ACTIVE, you can come pretty close with a few lines of CL.,
but re-engineering will produce better (more maintainable and more
efficient) code. Things to watch out for: Use of undocumented features like
indicator values returned from displays. Shared displays, special device
processing. Issues: converting sorts to FMTDTA, IF-ACTIVE, file override
scoping, work file usage (creating files on the fly is very inefficient).

RPG SRT programs are usually fairly straight forward. Things to watch out
for: CP and/or shared display files, dummy display file reads,
uninitialized data structure subfields, numeric storage format (S/36
defaults to zoned, RPG3 defaults to packed), special device processing,
uninitialized output fields, inconsistent field usage.

General issues: Will you also create DDS for some/all of your database
files? Inconsistent field usage may be a problem. If you will use external
file descriptions in your RPG programs, field naming and inconsistent usage
will be a problem, as will  composite/complex index keys (you will need to
use key lists instead of data structures). Data decimal errors may plague
you if the RPG2 code didn't always initialize output data. 

Recommendations: Don't externally describe your RPG display files. There is
little benefit, and it will make a LOT of work for you. Use externally
described displays going forward, but don't retrofit old code. Replace SORT
with OPNQRYF or logical views where it makes sense to do so, but don't be
afraid to use FMTDTA. It works well, and is very similar to  S/36 SORT.
Just be aware the adrout fields are 4 bytes long on the AS/400.

The problems you will run into depend on the code you are converting. Each
job is different, but once you have identified the problems (and solutions)
for a particular job, they will be consistent throughout. I haven't done
one of these for about 5 years now, so I've probably forgotten some of the
little nits, but hopefully this will give you a pretty good idea. Give me a
shout if you have specific "opportunities". I've probably seen something
similar.
Pete Hall
pbhall@execpc.com
http://www.execpc.com/~pbhall
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---