Re: RPG-III to -IV conversion rehash worries

[Booth Martin <booth@xxxxxxxxxxxx>]

An overlying concern I have with these monolith programs is that they 
deal with many many issues and have grown like Topsy through the years. 
 Conversions are putting lipstick on a pig.  My own preference is to 
review the application with an idea to how it now serves the 
organization.  Is it possible that a redesign will provide a new base 
for the future?

My experience has been that a few new and  relatively small applications 
will replace 80% of what the monolith is now doing.  Once those are in 
place then the monolith can be slabbed, sliced, and cut down.

dr2@xxxxxxxx wrote:
> Have you considered looking at the Linoma tool for this?  I've not looked
> at it for a long time but it used to be a really decent first pass to do
> this with...
>
> Don in DC
>
> ------------------------------------------------
>
>
> > It's been *many* years since I've converted RPG-III to -IV.
> >
> > We have a *ton* of legacy RPG-III apps, many of them monoliths, including
> > this one that I'm enhancing that is 13000+ lines long.
> >
> > (BTW, please no lectures here.  All new apps are written in ILE, and any
> > -III apps are converted as is possible within the constraints of the
> > project
> > specs.  When I see a mod that involves a date calculation of some sort, my
> > RPG-IV brain says "no sweat, let's do..., oh crud, it's RPG-III!", but
> > most
> > times I am unable to justify a conversion when a modification, by itself,
> > is
> > essentially a 15-minute project.  We get a lot of those here.)
> >
> > In this particular case, the RPG-III app in question has some fairly major
> > modifications in store.  I am trying to use this project as a
> > learning/teaching case to convert other apps in the future.  The first
> > thing
> > I want to do is to move the bulk of the code into modules, and test the
> > resulting app to ensure that it functions the same as the legacy app.
> > Once
> > that's assured (?), I would make my modifications.
> >
> > I converted the source to this particular app to -IV via CVTRPGSRC, and
> > then
> > tried Brad Stone's CVTILEFMT.  It compiles fine, but I am dreading having
> > to
> > test this monster to determine that the conversion doesn't introduce
> > errors
> > or functional differences from its RPG-III counterpart.
> >
> > The first thing I looked for was the potential for numeric overflow.
> > IBM's
> > conversion keeps all the opcodes the same, so no real issues there.
> > Brad's
> > conversion allows you to convert the IBM conversion to more readable
> > stuff,
> > including converting math opcodes to Eval's.  Now, I wanted to check for
> > numeric overflow warnings from the compiler.  Amazingly, the only messages
> > issued by the compiler were the standard "field not referenced", "record
> > format not used", and "RPG handles blocking" messages.  C'mon, I thought,
> > a
> > 13000 line app so well designed that there are no "potential overflow"
> > warnings???
> >
> > As a sanity check, I wrote this Q&D app to test the compiler (chopped the
> > first 20 or so columns):
> >     z-add     5             Five              5 0
> >     z-add     6             Six               6 0
> >     z-add     Six           Five
> >     eval      Five = Six
> >     Eval      *inLR = *On
> >
> > I would have expected that the compiler would have flagged the EVAL
> > statement since the potential for numeric overflow during runtime would
> > stop
> > the program.  Didn't the compiler used to do this?  I could'a sworn I'd
> > seen
> > this before.
> >
> > Anybody have a cheat sheet for 3-to-4 conversions?
> >
> > TIA,
> > Dan
> > --
> > 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.