RE: RPG-III to -IV conversion rehash worries

Dan,

Your field is 5 bytes long and 6 bytes long respectively and will handle values 
along the lines of 99,999, and 999,999.  You would need to try and set Five = 
100,000 or greater to achieve what you want.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Dan
Sent: Thursday, December 15, 2005 12:33 PM
To: RPG400-L@xxxxxxxxxxxx
Subject: RPG-III to -IV conversion rehash worries


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

Privileged and Confidential.  This e-mail, and any attachments there to, is 
intended only for use by the addressee(s) named herein and may contain 
privileged or confidential information.  If you have received this e-mail in 
error, please notify me immediately by a return e-mail and delete this e-mail.  
You are hereby notified that any dissemination, distribution or copying of this 
e-mail and/or any attachments thereto, is strictly prohibited.