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


  • Subject: RE: Move S/36 to AS/400
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Thu, 1 Jul 1999 11:30:16 -0400

Al,
This made me smile.  We tried to convert our S/3 OCL into S/38 CL via some
"automatic" tool whose name escapes me.  Stupid thing wanted to put in an
OVRDBF for every // FILE statement.  When we used the migration tool on the
RPG, it had a bit of a problem with the MFCM and stacker select <g>.

More to the point of the thread, when we changed platforms we decided to let
the automated tool convert the batch RPG programs, but we wrote all the CL
and interactive programs by hand.  It was really the only way to "go
native."  There are architectural differences that made it worth our while;
especially the "Load a work file/Sort/Update-Print" type of applications.
RETAIN-J/S files that get scratched after the job should now be put into
QTEMP to keep the same functionality.  If your conversion utility is smart
enough to do that for you, then think about using it for the OCL-CL
conversion.  In any event, be prepared to physically look at each converted
CL program...

Buck Calabro

> -----Original Message-----
> From: Al Barsa, Jr. 
> Sent: Thursday, July 01, 1999 12:36 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Move S/36 to AS/400
> 
> At 09:27 PM 6/30/99 -0500, you wrote:
> >At 12:11 06/30/1999 , Al Barsa 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.
> >
> >Well, like I said, each job is different, and I've had more practice than
> >most with 36-400 conversions, having done in excess of 50 of the buggers.
> >You apparently had OCL that was written for the S/34 or maybe even
> earlier.
> >It can vary a lot. Generally, the OCL is the hard part, especially if you
> >want to make it run reasonably efficiently and end up with coherent data
> >definitions. Occasionally you do get lucky, but only occasionally.
> 
> I go back to my TARGET/400 experience, where a programmatic conversion 
> occurred.  Getting the program correct for all types of OCL proved to be 
> easier than all of the funky stuff that you could have done in RPG 
> II.  Most of the stuff in RPG II that was difficult was stuff that was 
> primarily designed for S/3 and S/32.
> 
> 
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.