Re: RPG III (RPG/400)

I agree that the source conversion using CVTRPGSRC is straightforward, and
the biggest concern are the differences in the two compilers. But, again,
20+ years of experience, I think, is a good record.

How about when we changed from CISC to RISC? All programs had to be
"recreated". Did anyone test every single application when that conversion
happened?

- Dan

On Mon, Nov 2, 2015 at 5:15 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 11/2/2015 2:56 PM, Dan wrote:

We're using an old ERP package written in RPG-III. I have always been of
the mindset to convert any RPG-III source to RPG-IV before I modify it.
Especially now with RDi, where the outline view doesn't work with RPG-III
and hoop-jumping necessary to debug OPM programs. Unfortunately, I'm new
here and I'm getting pushback when I need to modify an RPG-III program.
The "standard" here is to convert only when it's a major rewrite or
something that needs to be done can't be done in RPG-III. The argument

is

that any such application must be completely retested, so, while the

effort

to convert is minimal, the big cost is in the effort to QA the app.

So that you understand my frame of mind, my eyes can't easily get past
'completely retested'. As opposed to 'not completely tested' which
sounds like the current practise. I'm no ivoury tower purist: I totally
get that time is money and finite. Yes, the goal should be to always
completely retest for every change but someone is already making a
judgement call at your shop as to what needs to be tested and what does
not.

To my mind, the heart of the question is this: CVTRPGSRC does not change
the source code any more than changing it all to lower case does.

CVTRPGSRC is a mechanical algorithm which simply reformats RPG III into
RPG IV. If you wanted to, you could take that RPG IV source code and
mechanically re-create the original RPG III source code and it would be
byte for byte identical after it's round trip transformation.

What has changed is the compiler. There are two different compilers
working on the same source code. Are there subtle differences between
them? Maybe. Probably. Are those differences enough to keep me awake
at night? Nope. Why not?

Imagine me, writing an RPG III program on my System/38, CPF release 2.
Time passes, and we upgrade to release 3, 4, and 5. I now change my
source and re-compile it. The RPG III compiler is different now than
when I first compiled that program. Are there subtle differences
between the two compilers? Maybe. Probably. Did those differences
keep me up at night? Nope.

Could I have got burnt by the differences between those compilers? Yes,
in theory, I could have been. There was one compiler bug which had a
problem with %found or %eof, I can't remember now, but one version
worked one way and another had a bug which caused INCORROUT. A
difference which was quickly fixed, but still, a difference.

There are various levels of comfort that may trigger the desire for a
complete retest. I'll put them in the order I personally,
unscientifically rank them based on a sample size of n=1:

Hardware upgrade (save+restore same OS/user libs)
CVTRPGSRC (source code formatting)
PTFs (they are intended to change something!)
TRs (SQL behaviour has changed)
OS releases (all sort of stuff changes all at the same time)

Your group are already deciding what things are important enough to
trigger a test. It shouldn't be a huge lift to add CVTRPGSRC to the list.

--
--buck