Re: RPG-III to -IV conversion rehash worries -- RPG400-L

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

My experience has been that a few new and relatively small applicationswill replace 80% of what the monolith is now doing. Once those are inplace 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.