Re: Need some ammunition (Procedures vs. Sub-routines)

Others have made many good points.

I believe that a procedure in place of a subroutine can be a great way to start. And the procedure has the advantage of protecting you from side effects - changing the value of some variable in the subroutine that will be used after the EXSR and should not have been changed.

And so long as all this is internal to a given code unit, the impact on an entire application is nothing - absolutely nothing - unless you change the value of some variable used elsewhere - but that's the same risk, even more so, when using subroutines.

I suggest starting with some kind of utility procedure - like building a string from multiple values, say. The values can be made parameters (CONST) so they can't be changed, and have a return value for the string.

Or a calculation based on some input parameters, especially if these concatenations or calculations are performed in several places. The big deal here is maintenance - how often has the same code required updating and at least one instance was missed? With a procedure, IF it is necessary to change how a calculation is done, then a procedure is REALLY safe - code is changed in one place - this even goes to the matter of testing - fewer places to actually test things - that's for down the road, when you may get into separate modules and service programs.

This can also simplify code - with a subroutine, often we have to set a number of variables that will be used in the SR (global variables). With a procedure with CONST input parameters, you can use expressions instead of variables for the parameters - this can result in cleaner code - you don't have all those "set" EVALs for global variables.

HTH
Vern

On 12/27/2013 10:06 AM, RPGLIST wrote:

It was a decision or policy that was put in place by mgt long since gone
but its still there and enforced. So, I won't argue the point I just need
as much evidence in making the case to start using them on a regular
basis.

Internal for the most part, Service programs are a major no no right now,
yea I know - another policy that makes no sense other than someone tried
it in the past and it didn't work so they got scared and thus the policy.

External procedure or internal procedure? I can't see why either would any
more testing than a new subroutine.




From:
"RPGLIST" <rpglist@xxxxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx,
Date:
12/27/2013 10:51 AM
Subject:
Need some ammunition (Procedures vs. Sub-routines)
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx



I won't go into the entire lengthy and boring conversation I just had with
upper management, but I was basically told that under no circumstances am
I to add procedures to certain applications. The justification is that
by doing so, we will be required to re-test the entire system, payroll,
dispatch, load balancing, AP, AR, etc.

I however was provided an opportunity to make my case, and I have a list
of reasons, but I need every bit of ammunition I can come up, so any help
from ya'll would be cool.

Dutch


--
This is the RPG programming on the IBM i (AS/400 and 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.



--
This is the RPG programming on the IBM i (AS/400 and 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.