Re: Move S/36 to AS/400

Debbie,

I take it from your request that you already have a S/36 app running on
the AS/400 and are looking to take it "native".  Well, it depends.  How
clean are the shop rules and how rigidly were they enforced.  Old (S/36)
code that has a consistent and predicable pattern lends itself well to
conversion programming.

My company had 70+ S/36 installs when the AS/400 came out and we tried a
variety of conversion programs and although they had a moderate degree
of success (most had their roots in S/34 to S/38), we decided that
skilled interpretation of intent, some elbow grease, and a good tool
library was the only way to get from here to there.  The AS/400 did such
a good job of S/36 environment the early migrations never moved on. 
Till recently!

As others have pointed out, literal command substitution can create a
sick and twisted CL program that you don't even -want- to use as a start
point!  As has been pointed out IF ACTIVE or even IF MRTMAX do "work"
although they introduce a response delay that will create false feedback
conditions.  Even trying to create a program to perform the equivalent
function has the inherent flaw of time delay.  One -must- approach the
problem anew.

AFAIK, dynamic substitution for sorts (// IFF ?1?/   IAC...) were in
common practice and are not adaptable to FMTDTA.  IMHO, FMTDTA is a
throwback to the S/3.  Even the S/32 allowed for the OCL processor to
filter/build sort specs.  The last time I looked at FMTDTA (the Earth's
crust was just cooling..) it couldn't do dynamic build.

Alas, that leaves you with making the decision to build or buy. 
Especially if you have a gazillion RPG/II S/36EE programs to get Y2K
ready and some dolt designed the files to contain dates in MMDDYY
format. =:-o

To do the job in-house you could go through a S/36EE readiness phase or
just jump in and start procedure by procedure to go native.  Figure 2
hours per command/screen/program.  You win on some, you lose on others.

If you need to go program-by-program or want to jump to native, these
are my transitional suggestions:

1) For EVERY file create an external definition, both PF and LF.

Start with creating a data dictionary and make good use of REFFLD
keywords when building the PF.  In otherwords standardize. Get
consistent.  Resist the urge to make data format changes at this point.
(like dates)
My preference is to make every PF nonkeyed and create a unique keyed
logical.
BTW, make the record name the same as the S/36 file name and create a
new (native) file name.  Create a logical that is the same as the S/36
file name sharing a new native logical.
This allows an existing OCL to use a logical as either FILE or LABEL and
a native CHAIN to use the same field2 value.
This may be difficult depending on how many cooks have been in the pot
and exercised their "artistic" abilities.

2) Mimic the PF DDS with a /COPY (in S/36 mode) for EVERY file (Both
input and output).

Also create a /COPY for each file to initialize a record to avoid
potential data decimal errors.  While you are at it, create another
/COPY to handle date conversions and compound key fields.  If the file
has 'HIRE36' as MMDDYY use that field in a subfield in a data structure
that allows you to easily convert to at least CYYMMDD. (z-add YR36
YR400; if YR400 lt 40; add 100 YR400 where YR36 is yy and YR400 is cyy)

The data structure looks like this:

        I                       1       70HIRE
        I                       4       90HIRE36
        I                       1       30YR400
        I                       4       50HIREMO
        I                       6       70HIREDY
        I                       8       90YR36

3) Start gutting the RPG/II program I/O specs and replace with the /COPY
to hunt down the inconsistency in naming conventions.  Make them work in
a S/36EE before you try to make them work "native".

4) This really isn't step 4, I just didn't want make step 1 go on and
on.  Create tools.

If you create external definitions for the PF, use DSPFFD to an outfile
and write a program to create the /COPY members.  Therefore if you must
revisit the DDS you can regen the /COPY without manual intervention.

When you originally compiled the S/36 S/D display specs new "native" DDS
specs were placed in QS36DDSSRC (I think)  Use them.  Create your
program described WORKSTN file specs from them.

In order to create your dictionary, write a tool to scan your source
members and get to a starting point.  Get the ducks in a row.  The tool
should build the DDS and highlight position/name inconsistencies so that
you know where the elbow grease will be needed.  BTW, this is one of the
benefits of a fixed format language.  No string parsing/interpretation
required. An "I" spec has a record name or it doesn't.  If it doesn't,
it better have a field start position or a "DS" designation.

5) Make routines like "days old" into a /COPY member. Again clean up
your S/36 code.

The reason I stress making these members into /COPY is that when you
change the source member of RPG36 to RPG they system will look into a
file instead of a library and you can make the subtle differences in a
single place.

A S/36EE /COPY COPYSRC,FILECHN looks in library/file/member:
COPYSRC/QS36SRC/FILECHN where a native equivalent will be
*LIBL/COPYSRC/FILECHN. This allows for coexistence of transitional /COPY
members.

If the purpose of going "native" is for Y2K readiness, IMO, unless you
have a small library, it's too late to also go native.  You can make it
work in S/36EE.  Just don't even dream of being able to take a New Years
vacation! ;-}

In otherwords, you can get there, but it won't be quick.  If it was, it
won't be good or cheap.
Way back when, I was taught the good/fast/cheap triangle.  In any
scenario you get to pick two.  If it's fast/cheap (McDonald's) "good"
does not come to mind.  If you want it fast/good, don't even entertain
the idea of cheap.  If you want good/cheap, that takes some shopping
time.  So "fast" just isn't there.

Good luck.

James W. Kilgore
email@James-W-Kilgore.com


"Gallagher, Debbie" 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?
> 
>      TIA, Debbie Gallagher
>
+---
| 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
+---