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



Linoma's RPG Toolbox converts 3 to 4, but you can set it to not convert
arithmetic operations to Eval if the result could cause an overflow. It does
this by compiling the source and looking at the list file to find the field
definitions. Without that kind of tool you have to just look at the field
sizes and convert to Eval as required.

(Of course, sometimes you need to get things to overflow and cause a
run-time error - that's when you discover a database field is too small.
About 10 years ago, I found one of those when a user discovered a $100,000
discrepancy - the DB field was 7,2 but the report work field was 9,2 - this
for total sales!). I figure that getting a run-time error for an overflow is
better than not knowing that a MOVE, ADD, SUB, Z-ADD, etc., chopped off the
most significant digits, and then the bean counters scream bloody murder.

As for the date stuff, way back for the Y2K crunch I wrote several callable
programs (written in RPG4, but not ILE) that did all the date calculations
we needed to do. And we replaced all the in the-program calculations with
calls to those programs. Now that we're slowly going to ILE, we ported those
date routines into service programs and are using the service programs
whenever a program gets converted to ILE. (We generally don't do date calcs
in the programs unless it's a date format that is nonstandard to our system
- our database has numeric dates in CYYMMDD format).

Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre@xxxxxxxx 



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