Re: Move S/36 to AS/400

At 10:23 PM 6/29/99 -0500, you wrote:

If I could interject, I disagree.  You can get a very clean conversion from 
OCL to CL.  But there's a ton of flukey stuff in RPG II that RPG III/IV 
doesn't support.  Many (very many) years ago, I used a product called 
Target 400, which converted S/36 applications to native, and it did a very 
good job.  At that time, we assumed that OCL to CL would be the hardest, 
and were surprised to see that RPG was harder based on all the funky stuff.

If you want to convert, I recommend it highly.  Keep in mind that when 
you're through, you get a native application that is designed like a S/36 
application.

Al

>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
>+---



+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:  914-251-1234
Fax:    914-251-9406
http://www.barsaconsulting.com
http://www.taatool.com

+---
| 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
+---