Re: Removing or replacing *inzsr with Dspecs

On 6/10/2014 12:56 PM, Vernon Hamberg wrote:

To add to that, Alan, Craig Rutledge has a tool that converts
subroutines to procedures - once Wilson has tried a few of his own, he
could use that FREE tool to see what Craig does - it's interesting, as I
recall.

These tools can be excellent teaching devices - for example, IBM's
CVTRPGSRC can help to see the basic differences between RPG III and RPG
IV. Linoma's or Craig's tools can take things just that much farther -
sometimes how much "farther" is under the programmer's control.

Vern

On 6/10/2014 9:54 AM, Alan Cassidy wrote:

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Michael Schutte
Subject: Re: Removing or replacing *inzsr with Dspecs

But that's about as far as I would go with sub procedures in a main
line program. If there's other code that I feel like should be in a
sub-procedure that's imported through a module or service program.
Judging by the comment you made about being out of the game for a
while, this might be a little too for this thread

...

If Wilson is in learning mode, converting subroutines to subprocedures
can be a good exercise for him for getting used to them. Such
conversions are good for that.

I like the idea for general maintenance where it doesn't detract from
your timelines. Some subroutines use variables defined only for their
purpose, or re-use work fields defined globally. To practice at first,
do it with a few of them.

Alan

Thinking in general about /educational/ value, I find myself taking the
contrarian view when it comes to automated conversions. I don't believe
that there is much educational value in seeing EXSR CHECKCUST converted
to CALLP CHECKCUST. The D...PR and D...PI specs aren't really
complicated enough that a raw beginner should skip over them until his
education is farther along. I know I'm saying it badly but I think that
the infrastructure of subprocedures (P...B and D...PI) isn't the hard
part, or even the useful part of using subprocedures.

Thinking in subprocedures [1] is where the educational value is.

What value do subprocedures offer us? In no particular order:
1) The ability to write user defined functions
2) Local variables
3) Service programs and the ability to easily share
4) Low coupling via parameterised interface
5) Easily understandable abstraction via decent naming
6) Ability to test independent of production code

Basically none of these can be found in an automated conversion from
subroutines.

If I were teaching subprocedures from subroutines, I'd ask the student to
1) Identify the various functions the subr implements - it's probably
monolithic
2) Sketch out the function calls and parameter lists needed - think in
business functions, not proximity to I/O operations
3) Imagine (or write!) tests that will prove each function works (pass +
fail)
4) Implement the functions one at a time, tested independently of the
program they will eventually be placed into - reduce coupling to a
minimum, learn service programs / exports, use local variables
5) When one function is done, replace the block within the SUBR with the
new function call - find the hidden interactions that the global
variables enabled
6) Continue implementing until the SUBR is a wrapper of CALLP statements
mixed with some decision-making (IF, SELECT) - mainline code is undisturbed

--buck
[1] Apologies to Bruce Eckel and his marvelous 'Thinking in C++' series.