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



Raymond,

You have responses from Jerry Adams, Charles Wilt, and Rob Berendt. I
cannot disagree with anything they have written. Still, I shall take
the liberty of rambling on.

I think our advice could be more nuanced if you told us more about where
you are now and what you want to get from the conversion.

If you just want to use a new compiler, the conversion can be really
simple. And the resulting code will be as undertandable and as
maintainable as what you started with.

( Jerry and Charles: How smart is the Linoma tool? Is it smart enough
to eliminate some indicators? When it converts a bunch of arithmetic
operation to EVAL, does it recognize and eliminate otherwise-unused
intermediate variables? )

The first big potential benefit that this conversion makes available is
the use of so-called externally described files in the RPG. This had
better be easy. (If your current programs do not agree about file
contents, your problems are much deeper than choice of programming
language <grin attitude="wry" prescription="rye" />.) I find it hard to
imagine that you would not find this change well worth the effort.

Some effort can be put off until you actually have a need for the
benefit. Actually, sometimes simple-minded local improvements can pay
for themselves the first time you need them: evaluating conditions
within flow-of-control statements instead of using indicators, named
variables instead of numbered indicators, and so forth. Still, you
probably do not want to invest much here before you are ready the reap
the (local) benefit.

Some changes provide a benefit only when they are done throughout the
system. The prototypical example here is the replacement of a
copied-and-pasted subroutine with a call to an external program or
procedure. Oh yeah, be prepared to find some instances that are
pasted-and-then-tweaked for a local purpose. Or--more bothersome--be
prepared for some external use of what should be a local variable.
Again, if you find versions of an important calculation which are
*really* different, your problems go beyond choice of language.

The cases may not be exhaused, but you probably are. Certainly, I am.

I hope this helps a little bit. Feel free to tell us more.

Cheers,
Terry.


On Wed, 2008-07-09 at 12:01 -0700, Raymond Meade wrote:
Re: IBM Sys/36 (Advanced 36) and RPG-II migration.
A question for all ye IBM RPG-II lovers (current and former),
To convert from IBM RPG-II to IBM RPG-ILE



Over several years I have read many sources which have been revealing with respect to IBM’s continued phasing out of all “versions” of the Sys/36 and IBM RPG-II code. Here is a situation and a proposal for which I would appreciate receipt of your ideas and comments that may provide information as to our quest of RPG migration.

We currently have installed an IBM 9402-436 Processor which is used only to run multiple M36 machines for production purposes. The processor is at release V4R2. This old IBM processor can also function as any regular as400. I have converted and compiled several of the RPG-II programs to RPG-ILE and they seem to compile and run okay in the 400 environment on this old processor.

I am considering converting all of the RPG-II code to RPG-ILE which would be done on this same old processor. Do you think that it could then be feasible to move this RPG-ILE source code to a later model processor (for example one that was currently running on V5R3) and then recompile it on the newer model processor? Our old processor has a 6390 IBM 8mm tape drive which could possibly be read by an IBM 8mm tape drive on the newer processor, which could then provide a method for moving the source code. If this 8mm method of transfer would not work, hopefully there would be available another method.

I am concerned if the above steps could be ignored or stopped if the proposed V5R3 release level on the newer model processor were unable to recognize or otherwise compile the ported RPG-ILE source from the old processor. These thoughts crossed my mind while I was reading two IBM Redpapers, one of which dealt with conversion to V6R1 and another Redpaper which dealt with conversion to V5R3.

Among the same general concerns pertaining to the recognition and compatibility of ported RPG-ILE source to the proposed new processor is that of license keys. Would the presence of license keys on the new processor pose a problem not dealt with in the above steps?

Please keep in mind that for current (ongoing) production purposes, the RPG-II code would execute on our old processor only, and the RPG-ILE code once completed and moved would execute on the new V5R3 processor only. At the stage when the move to the V5R3 processor is complete, it would become the sole CPU in use.

Another concern about this proposal is the amount of elapsed time that would occur until all of the RPG-ILE source code could actually be moved to the target new processor. Obviously it would be necessary to at least confirm that several of the RPG-ILE sources from the old processor would actually compile on the target newer processor, and that such confirmations should occur at least every few months. The elapsed time also brings to mind concerns if the target new processor would be available in the future at the target version level along with the other “corresponding” supporting software that exists on the old processor such as Advanced Function Printing (IPDS), to name just one.

The total amount of elapsed time would be several years in that the old RPG-II sources on the old processor will have to be converted to RPG-ILE before any porting, either partial or complete, should begin.

If you can, please let me know what you think. If this is not feasible than I am leaning toward a non IBM option for our RPG migration. Your consideration is most appreciated.




Sincerely,

Raymond Meade

E-Mail: paulwmeadeagency@xxxxxxxxx
Telephone: (405)-524-1541
Fax: (405)-524-6156



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.