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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.