Re: Challenges using service programs, binding directories, etc.

On 8/18/2015 12:00 PM, Dan wrote:

So, I had a bit more discussion with my supervisor about the utility I
packaged up in a service program, and the major qualms appear to be related
with maintaining either a) the service program, and/or b) the programs that
use them.

Apparently, there was a highly regarded, talented developer who is no
longer with the company and who packaged a bunch of procedures in a service
program. The service program is used fairly extensively here, but anytime
anyone needs to modify something in the service program, or modify
something in the programs that use the service program, there is a
"gnashing of teeth" because of a history of gotchas that prolonged what
should have been a simple modification/compile into "WTH isn't this
working?" trial of chasing down things related to the service program. 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.

In my experience, the classic service program 'issue' is due to
EXPORT(*ALL) vs using binder source. This has the extremely unfortunate
but deliberate effect that an change in the exports results in the
service program signature changing which in turn throws signature
violations in all of the *PGM objects trying to use the *SRVPGM. This
is simple to rectify: use binder source. There's a corollary to this:
Use one signature. I've changed my mind since I started this so long
ago but now I'm convinced that signature management (ie *CURRENT and
*PRV) has virtually no benefit to ordinary programmers.

Another thing that sometimes trips up new players is binding
directories. I use bonding directories to create *PGM objects. With an
h-spec for BNDDIR() and ACTGRP() every *PGM can be created with PDM
option 14 or a simple CRTBNDRPG. There's nothing to remember in order
to recreate *PGM objects which consume subprocedures exported by *SRVPGM
objects. Which is to say, the vast majority of the maintenance on my
system, and probably yours too.

I simplify my service programs as much as possible too. One source
member gets compiled into one *MODULE which gets CRTPGM'd into one
*SRVPGM. If there is some reason that a more complex arrangement needs
to be made, I write a CLP to re-create the service program.

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 can put you
to sleep talking about how much better my programming has become since I
started using them, oh, more than 15 years ago now. The biggest benefit
for me has been the liberation of my thinking. I can now write small,
easy to debug functions and package them in a way that makes them easy
to use and to reuse. That thinking has moved me from monolithic
beasties to small, lightweight functions that can (and are!) developed
with testing in mind. I use RPGUnit to help with Test Driven
Development and my code base is far more robust than it was years ago,
because changes tend to be isolated to individual functions which can be
completely tested. This gives me tremendous confidence that the change
I'm making now won't break something unexpected.

Other factors:
1) To my knowledge, no one here is an "expert" on service programs, binding
directories, etc.

This list has pretty much reached consensus on best practices for
newcomers to follow.

2) We use Turnover here, and, so, there is a specific way to set up a
service program and related objects, but I haven't been able to find any
documentation that shows the details on this. I have the user guide, but
searching for guidance on their TCRTSRVPGM command was fruitless (no help
on the command itself), and I'll need to understand parameters like EXPORT:
Create command for RPGSRV type code: SOFTTURNE/TCRTSRVPGM
SRVPGM("&LI"/"&OB") EXPORT(*SRCFILE) SRCFILE(*LIBL/QSRVSRC) ACTGRP(*CALLER)
OPTION(*DUPPROC *DUPVAR) USRPRF(*OWNER)

Call Turnover! You pay for maintenance, by all means take advantage of it.

3) We are very tight on developer resources, and have been for a long
time. There's nothing to indicate that the "group of 3" is reluctant to
move forward on doing things better, but at the end of the day, there's
work to be done, and a huge backlog waiting for them. I think if I were
able to provide a documented, proven process to handle service programs, it
might go a long way in gaining wider acceptance.

Everything I do is intended to help me, working in a small group. I
don't have a dedicated librarian, DB2 admin, QA department or even
change management at my disposal, so I need to follow processes which
make it simpler to make and deploy changes.