Re: Service programs and QSRVSRC

Mark

If you are rolling your own service programs, I might go along with you. As a vendor of a product that IS a service program or two, we do NOT want to force customers to have to recompile whenever we come up with a new function or two. That means that I have to be very careful - and I am - to keep the order of things exactly the same and add new procedures at the end.

Whether this has a version number is not of great moment here - if we DID have to force customers to recompile with a new version of our product, I'd change the signature, perhaps adding a version number. In the case I'm thinking of, even with a version number, it'd be the same number now that it was 2 years ago. I think this would mostly be if the parameters for an existing procedure change. I'm trying to think of other reasons for forcing recompiles - file changes in our product (there are none in this case) would not require this, methinks.

I said earlier that IBM basically follows this method - many of their service programs have a signature that is the name of the service program. This gives adequate uniqueness, so long as you are in the same library.

So even IBM do not necessarily use the *PRV technique. This is a matter of backward compatibility for us - or is the term forward compatibility? You know what I mean, I think!!

Vern

M. Lazarus wrote:

Scott,

What I'm saying is that unless there is a really good reason to roll your own *and* a solid way to ensure that the signature gets changed when the exports change, let the system generate the unique value for you.

I don't think that many people like the way that service program signatures have been implemented, but specifying your own removes what little protection it does give. It's way too easy to overlook changing the signature when a service program is regenerated.

-mark


At 10/13/09 12:39 AM, you wrote:

M. Lazarus wrote:

Isn't managing your own signature (almost) the equivalent of doing
LVLCHK(*NO)?

Kind of, yes. Except that there isn't anything similar to using
LVLCHK(*YES).

If you change the export sequence or add/delete one in
the middle, there's no protection from using an version, if you
forget to manually change the signature!

Okay...? Are you saying that hard-coding the signature *without* a
version solves this problem? If so, how?!?!

Or... are you saying that you know of an alternative that would catch
the problem for you if you add/delete one in the middle? If so, please
expand on that.

To read more about my position on the subject, please see the following
article (this is the same article Matt Lavinder posted the link to
earlier in this thread)
http://systeminetwork.com/article/binder-language-and-signature-debate