Re: Processes after CRTSRVPGM

Hello,

recreate, not recompile. That is a big difference in that you can
use UPDPGM and UPDSRVPGM, with module(*NONE) and SRVPGM limited to
the single service program which you have changed the exports of.

Yes, I meant "re-bind" instead of "re-compile". (I have a bad habit of
using the two terms interchangeably even though they're not
interchangeable.) I meant to say you have to re-bind everything.

I suppose if you're only using your software in-house and you have a
good change management tool, re-binding may not seem like a big deal.
But it's still an (IMHO) unnecessary step. The way I do things, it's
completely unnecessary to re-bind the callers. In a circumstance where
your tools are distributed to other companies and called by other
developers, you can't possibly re-bind all of the callers, so my method
becomes more important.

There are two reasons I dont like adding new procedures to the end
of the binding source. The first is cosmetic. I use the binding
source as a document for finding the procedure I am looking for.

Err... why not use documentation for that? Or the actual program
source? Or write a program that retrieves the exports via the QBNLSPGM
API, and then sorts them? What's the advantage to using binder language
source code as documentation? (Especially if it makes maintenance more
difficult!)

The 2nd is practical. Most as400 programmers dont understand ILE and service programs. In a shop where more than a single person adds procedures to a srvpgm, there is no protection that someone with a little knowledge will place the new export in its logical, alphabetical location in the binding source and CRTSRVPGM.

That's true, but using *CURRENT/*PRV doesn't solve that problem. If you
code a *PRV block with the old signature, it'll still have the same problem.

If you want to force the service program to be re-bound every time you
change the exports, you may as well use EXPORT(*ALL) -- you don't need
to use binder source at all in that case, it's not providing any benefit.

In the end, difficult tradeoffs have to be made.

I don't find the tradeoffs to be difficult at all. Don't use binder source as documentation. Make it a part of your shop standards that programmers always add exports to the bottom. Problem solved.

Weigh that against potential hours of extra analysis and development effort, as well as longer upgrade windows... I don't think it's a difficult choice.