To add to Gary's points below, just swapping all our subroutines to internal subprocedures was the way we got our foot into the door so to speak as far as updating our code to a more modern method of coding. We used Linoma's tool to convert all of our programs in place. The only things we had to check were compile time tables, the location of *INSR's, and the biggie, returns from within subroutines. We converted, modified, and tested about 700 programs over the course of two weeks, and at the end of the process, had maybe two or three bugs introduced due to the conversion. A year later, we had slowly pulled all redundant routines into service programs, and found a lot more places where small snippets of main line code could be refactored into functions reducing the number of lines of code across the board. Now, five years later, we have a fairly modern code base. It's easier to maintain. It's even easier to make enhancements because we have a solid foundation of service programs that contain all but specific to a work flow logic. It's also allowed us to expose some of our business logic as web services and sql functions, which would have been a nightmare if we would have kept to a monolithic programming style.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Monnier, Gary
Sent: Friday, December 27, 2013 11:20 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Need some ammunition (Procedures vs. Sub-routines)
Replacing a subroutine with an internal procedure does not require any more testing than any other change. This isn't necessarily the "correct" way to utilize sub-procedures, and to some this is sacrilege, but you can exclusively use global variables in a sub-procedure essentially making it a subroutine.
Any change to a program can trigger a full system test. You test for your change and you test all components the change may impact. For example, if you change order entry's method of calculating net sales price you 1) test to ensure the new calculation is correct and 2) test everything on down the line through G/L posting to ensure the new value is handled correctly. Such a change can be to a subroutine or sub-procedure.
If you start using external sub-procedures (also known as functions) you will have a bit more testing to perform: ensuring the correct service program(s) is/are bound in, that it/they cannot be replaced (updated) on the fly, all the stuff that goes along with ensuring the function calls work as advertised, unit testing and system testing.
HTH,
Gary
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of RPGLIST
Sent: Friday, December 27, 2013 8:07 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Need some ammunition (Procedures vs. Sub-routines)
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.
--
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.
Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550
midrange.com
