Re: RPG II to RPG/400 conversion -- MIDRANGE-L



Marc Zylka wrote:

> Are there any tools available that can help with the conversion
> of RPG II to RPG/400?  As I remember, it's not really a big
> deal to convert it manually.  Anything in particular to watch out
> for?

Don't know how far you are into any transitional phases, but I assume you are
running pure RPGII/OCL in a S/36EE or you're still running a real S/36 with a 
400
on the way in the door.A couple of things jump up right away: (in no particular
order)

1) naming: files, records, fields, subroutine, except output all have to be
different.
   Externally describe your files (remember one format per physical file) using 
a
new rational standard and use the old S/36 file name as the record name.  This
will help in your CHAIN/SETLL/READ operations.
IMHO we prefer a sequential physical and create any indexes through logicals
instead of any keyed physical....pros and cons for both approaches. I'll let
others explain why.
We used a /COPY for each files key field data structure and just added a KLST
specs at the end, also used a /COPY for a standard routine to chain which only
required changing xxKEY CHAIN xxxxxx to read xxKLST CHAIN xxxxxx. (I guess that
how easy can depend on the standards in your shop and how rigidly they were
enforced)

2) some cleanup may be required where programs did not initialize numeric fields
properly for additions and this will cause data decimal errors in native
applications.  S/36EE CRT assumes ignore dec errors=yes where native CRT have 
fix
dec errors=no (although you can change the CRTRPGGM/CRTRPTPGM command defaults,
decimal errors cause unnecessary overhead) In our case we also had /COPY member
to initialize a record so that was a no brainer.

BTW I might add that we started from scratch on our S/36 application product
AFTER having performed some custom development for the S/38.  (S/3 beget S/32
beget S/34, then came S/38, then came S/36) We dumped our existing 500k+ S/34
product once we saw the writing on the wall and made our S/36 product S/38
friendly.

3) As a transitional phase, once you externally describe your physical files,
(you will have a single data dictionary and have all file DDS use the REFFLD
keyword won't you?) create a logical that matches the S/36 OCL requirements.  In
our case we already had every file cross labeled in the OCL (for reasons that
aren't important for this discussion), but in any event if your OCL reads: //
FILE NAME-yyyyyy,LABEL-xxxxxx,DISP-SHR,STORINDX-YES create a logical xxxxxx.

4) In your S/36 configuration: (CHGS36) say yes to search library list, say no 
to
share file opens.  We had a lot of problems with shared opens if you try to 
clear
a physical file after it's been used.

5) Since S/36 screen S/D specs can automatically be converted to DDS, compile
them all and get rid of the S/36 source and use DDS for all screens right from
the get go.  Be careful with zero suppressed numeric output to a screen, you'll
have to remove the 'Z' from the RPG program and use the DDS editing
instead...also any numeric output can not be blanks to the screen...causes nasty
errors.  During the transition your RPGII programs can still use program
described workstn files.  We wrote a simple program which took the DDS created
workstn file DSPFFD output and created RPGII I/O specs to help keep things in
sync until the RPG programs went native.

6) If your shop has good standards, remember program source IS data so you can
write programs to manipulate your RPG and OCL.  We wrote a simple OCL 
replacement
program where as in #3 above we would type a find string of: // FILE
NAME-INPUT,LABEL-xxxxxx,DISP-SHR,STORINDEX-YES and type a replacement string of:
// FILE NAME-INPUT,LABEL-zzzzKEY,DISP-SHR and blast through all procedures then
delete the logicals created solely to satisfy existing OCL requirements.

7)If you aren't already on a AS/400, replace any assembler routines you may have
(like SUBRCP to determine cursor position) with native implementations using the
same name and your EXIT/RLABL will work without modification,  You can then 
later
change the calls to native CALL/PARM.

8) Redbook GG24-3304-xx (Converting S/36EE applications to native AS/400) has
tables for showing OCL to CL equivalents. Also Redbook GG24-3250-xx (S/36 to
AS/400 application migration) has examples for doing printer file open/close,
workstn cursor position, etc.

I'm sure I'll wake up in the middle of the night thinking, "Gee, I should have
mentioned yadda yadda yadda." but when you get to a particular point in the
process, you're in a crowd on this list that just lives to help and show off a
bit...... ;-)

P.S. To really take advantage of the AS/400, you may need to go beyond RPGII to
RPG/400 syntax conversion and retool the particular function ..lousy RPGII which
goes through no more than a syntax change will still be a lousy RPG program.

P.P.S Some quotes from the Redbook:

"There is usually not a significant performance pay back from converting MRTs to
native AS/400 programs.  In some cases, such a conversion will make performance
worse."

"We recommend that before the start of conversion, you take the time to
understand the idea of normalization, and reduce your files to at least second
(and preferably third) normal form."

"Because you are moving code from one architecture to another, applications
highly optimized for System/36 architecture may not perform as well in the 
AS/400
system."




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---