Re: Reasons for using RPGIV

On 4/12/2011 5:54 PM, sjl wrote:

I am involved in a philosophical argument with one of the lead developers in
the JDE/Oracle V5R4 shop where I have been working as a consultant for the
last five years.

If I understand her correctly, her argument is that as a JDE shop that we
should NOT be using RPGIV at all, and that we should be writing /all/ code
in RPG/400. I don't necessarily disagree, in the case of simple mods to an
existing JDE program, but I would argue that /all/ new development should be
done in free-form RPGIV.

Background:
We currently have a mixture of OPM and RPGIV code.

Some of the RPGIV is programs that have simply been run through CVTRPGSRC to
convert them to fixed-form ILE source, other RPGIV code includes several
including entire sub-systems which have been written entirely in free-form
RPGIV utilizing service programs and binding source.

Other than hitting the RPG/400 compiler limits on the number of arrays,
tables, and files (which necessitates converting the program to RPGIV in
order for it to compile successfully), she wants me to present five
compelling reasons to justify the use of RPGIV, particularly free-form RPGIV
code.

Any thoughts? I need ammunition!

I have strong feelings about this situation. I was once given an Edict

From On High (say ten years ago) that no RPG IV would be used. My

personal feelings at the time ran along the lines that any programming
lead who advocated such a position ought to retire. My feelings haven't
changed much. What sort of company would even consider setting a
technical standard back two decades? For my own part, I simply ignored
that edict. The advantages of RPG IV are too great to pass up.

Sadly, we (the midrange industry outside this list) are still fighting
this battle. From a technical perspective, RPG IV is superior to
RPG/400 even without adding ILE to the mix. The addition of local
storage - subprocedures - enables an RPG programmer to make changes that
are much more testable than making changes to global variables inside a
global mainline.

My current job has me maintaining a matching record program. The very
first time I needed to make a change to it, I converted it to RPG IV and
the change I made went into a subprocedure. My change to the mainline
looked something like

C/free
if (*in02 and *inmr);
if payCodeIsChanging(cust#: some: other: parms);
except printPayCodeException;
do some other stuff;
endif;
endif;

That subprocedure uses arrays and thus array indexes, work fields,
concatenation and a bunch of crazy exceptions to a long set of rules
that used to be embodied in an indicator-heavy set of COMP and
MOVE/MOVEL operations. By moving that into a subprocedure, I don't
worry at all that I need to save the contents of this or that work
field, or that someone else (or me!) will come along and reuse X and
inadvertently disrupt my logic.

More importantly, I can quickly put together a test jig that uses a file
of all the interesting (and boundary!!) conditions I need, as well as a
quick RPG program using simple input primary cycle logic to call the
procedure for each condition and print any errors. This test jig
becomes a permanent part of the software, getting run after every
subsequent change to verify that I didn't break existing logic when
making a new change.

That's almost impossible to do with mainline code.

And that one capability alone - the ability to test a function in
isolation - demands leaving RPG/400 behind and adopting RPG IV. All the
rest of the RPG IV wonderfulness is gravy compared to this. And there
is much wonderfulness indeed.

My strong opinion,
--buck