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



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.