Re: Service program signatures, and how to avoid unnecessarily recompiling programs that call service programs

There is a subtle difference between a constant signature and the
*CURRENT/*PREV method:

Say you have a service program, version 1, with 3 exports. You create
version 2 by adding a new procedure, so there are now 4 exports. You have
a program that uses the new procedure.

Now, if you run the program in an environment that only has version 1 of
the service program present:
- If you used *CURRENT/*PREV you would get a signature error, because the
service program does not have the new signature
- If you used a constant signature you would get an 'export not found'
error
Both are rather nasty, hard errors, so it is choosing between a rock and a
hard place, but there is a difference.

BTW: Found this out when I moved a program to a different system and got
the 'export not found' error on an IBM service program. On the source
system a PTF had added a procedure to a service program; on the target
system that PTF had not been applied. IBM had not used the *CURRENT/*PREV
method for that service program.

Joep Beckeringh
Systeemontwerper
Pantheon Automatisering B.V.
Heerenveen

"Mark Murphy/STAR BASE Consulting Inc." <mmurphy@xxxxxxxxxxxxxxx>

14-09-2017 01:56

Re: Service program signatures, and how to avoid unnecessarily
recompiling programs that call service programs

Whether you use a constant signature, or use the *CURRENT/*PREV
method, you can only add new procedures to the end of the current
binder source group. You cannot reorder procedures in either case.
This is because only one version of the service program procedures
are maintained, and they are bound by relative location in the
service program. So if procedureC is in position 3 of the binder
source when it is initially created, it must be in position3 in
every export group in the binder source, and the groups that do not
have procedureC must not have 3 or more procedures defined. This is
why the *CURRENT/*PREV method of writing binder source is mostly
busy work. It gives you nothing, takes more work, and the rules for
changing and recompiling procedures stay the same.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx