My 2 cents worth, at the risk of repeating items often said already, with the hope it's useful for the purpose.
WHY SUBPROCEDURES AND SERVICE PROGRAMS
Note: Subprocedures can be used in a program. (Perhaps the developers at this shop are already using this, but that would surprise me because soon one could see the advantage of offloading them to a service program).
#1 Sub-procedures have EVERY BENEFIT that a subroutine contributes to a program, plus many benefits (some of which listed below).
#2 Sub-procedures have EVERY BENEFIT that ANY called program can provide to a caller program, plus many benefits (some of which listed below).
#3 Almost all mature shops (before they began using service programs) use a set of routines that they /COPY into the source for various routines. Before the built-in date functions (bif's) for example, many of them had one or more subroutines for manipulating date formats. But it's much more than date routines, it's much more. Dating time, validating new customer records, generating a new name or the next invoice number, ad infinitum.
Pre-service program, you go read the data area that has the last generated invoice number (with an update lock), increment, update the data area and release the lock. Wrap that up into your own home-built bif!
#4 This is the way IBM creates a program every time you run the CRTBNDRPG program. Go look at the program stack while one of them is running.
#5 Any shop has code that programmers have copied for various generic AND not so generic routines. Wrap them up into service programs and call them like a function.
#6 Wrap IFS functions into a function call that is really easy to use. I did this with one big project, that needed about a dozen directories and a dozen files input and output. I had to come up with a way to read a Godzilla-sized XML file with the help of this list, and was able to offload the repeated input of XML elements to a service program in the way I had to read them
So now others could use those routines and have the confidence they work as intended and as tested.
#7 Service programs can be introduced without much disruption, done right, and the first successful coders will produce routines that can help the others with skeletons to use for both new routines and to call them.
..a.. First step is subprocedures within the program itself, at the bottom.
..b.. This increases the confidence to test out the advantage of the next step, putting them in service programs.
..c.. Research how to create and use the service programs.
Basically, the main obstacle for adopting the great advance in RPG that RPGLE represents, is education and training. The learning curve is short compared to the advantages. Encapsulation is a big word in how-to-code articles on the Net, and one of the bragging points for object-oriented programming, but we have encapsulation with service programs.
#8 An example. In a distribution shop, you have various inputs for determining whether a certain user has access to certain menu options or certain functions. (user-ID, functional user groups, menus, options, locations, divisions, departments, and so on). Return a yes-no flag. All of the access functions and related routines can go into a procedure in a service program along with other repeatable functions. Code it once, put it through testing once, it's ready to go for every program that needs it. DONE! :)
DRAWBACKS?
Basically, the main obstacle for adopting the great advance in RPG that RPGLE represents, is education and training.
The learning curve is short compared to the advantages. Encapsulation is a big word in how-to-code articles on the Net, and one of the bragging points for object-oriented programming, but we have encapsulation with service programs.
The only drawback is the initial learning curve and it's not bad. The selling point to developers is not just career enhancement, but a way to keep from falling behind in marketability. For the company, it's incorporating a major enhancement in application development productivity. Money is a big deal to company ownership and top executives and directors.
-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
Sent: Tuesday, August 18, 2015 2:56 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Challenges using service programs, binding directories, etc.
Thanks, everyone, for your replies!
Some quick hits:
I don't actually know if they use EXPORT(*ALL) here. I didn't mean to imply that from the command sample I provided.
I just now registered on Turnover's website; waiting for approval.
Thanks for those links, John. Good info!
The question I know I'm going to be asked: What are the pros/cons of service programs vs. non-service programs?
Or...
What is the advantage of ...
d WrapText2 pr 12288 Varying RtnParm
d UnfText 8192 Varying Const Options(*VarSize)
d LineLen 5 0 Const
d LineBreak1 10 Varying Const Options(*NoPass)
d LineBreak2 10 Varying Const Options(*NoPass)
NotesArrayDS = WrapText2( %trimr( c_SPdetl) : 80 : '~' : '|' ); vs.
C call 'WRAPTEXT2'
C parm LongString 12288
C parm LineLength 5 0
C parm Tilde 1
C parm Vbar 1
C parm ReturnArray
On Tue, Aug 18, 2015 at 2:17 PM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:
On Tue, Aug 18, 2015 at 1:06 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 8/18/2015 12:00 PM, Dan wrote:
My
supervisor did not give details on what the issues were, as they
rarely need to touch the affected applications anymore, so I don't
know what
the
exact issues were. But, obviously, the battle scars are still kinda raw.
Before Buck gets into potential technical issues, I would like to take
a side trip to another thing he wrote. It was regarding a thread on
this list titled
Need some ammunition (Procedures vs. Sub-routines)
The particular post is
http://archive.midrange.com/rpg400-l/201312/msg00348.html
It has to do with recognizing when the challenges are emotional rather
than rational (which is probably most of the time; and in my
experience, it never hurts to assume there's at least a significant
emotional component).
I may be asked to present my case to the "group of 3" development
leaders
here, and it would be nice if I can present how to overcome the
typical challenges. If anyone is aware of articles that discuss
this and, as
well,
the benefits to using service programs, I would appreciate links.
Can't say I know of a 'fan page' for service programs but [...]
I guess this list in part serves the role of fan page. But it's not
like there's one link. It's more of a recurring topic of discussion.
Two threads that I think are worth reading are the one I mentioned
above, which started in Dec 2013 and continued into Jan 2014. Another
is from Jan 2015, titled
Service programs, procedures, not sure what to do
(I give the subject lines and the months because it may work better to
just go to the relevant monthly pages in the archives rather than
using the search feature.)
This list has pretty much reached consensus on best practices for
newcomers to follow.
Has it? I know you have a pretty good idea what to recommend
newcomers, based on your own experience, but my impression is that
there are always disagreements on the approach to take. Mainly,
there's a camp which seems to advocate trying to push "expert
practices" as early as possible, so that newcomers have the most
direct path possible toward expertise, and have the least chance to
settle into "initially easier but ultimately suboptimal" habits.
The other camp (which I perceive you to be in, but I'm speaking as
someone with almost no service program experience myself) emphasizes
making things as easy and undaunting as possible, so that there's at
least *some* movement. Of course, there's an attempt not to promote
actively bad practices, but "good enough" is good enough, especially
if it's already significantly better than the status quo.
Not all the disagreements fall neatly into that dichotomy either. For
example, when you describe binding directories, you make it sound very
newbie-friendly. But when Alan or others talk about Make tools (and
the futility and frustration of binding directories), that certainly
sounds newbie-friendly as well.
In any event, I just wanted to share a couple more links, again to
Buck's "mini-tutorials" (you seem to write one at the beginning of
each year). These are both from the threads I mentioned above:
http://archive.midrange.com/rpg400-l/201401/msg00076.html
http://archive.midrange.com/rpg400-l/201501/msg00025.html
The one from Jan 2014 in particular seems almost ready-made for a wiki
on the subject.
John Y.
--
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.
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
