SRVPGM LVLCHK(*No), was: Changing a service program

<Jon>
The solution is first of all to STOP using LVLCHK(*NO).

Then you can decide - do you want to use *GEN for the signature - in which case you will need to re-bind all programs that use an SP if you ever add a procedure
</Jon>

That would be my recommendation too! Following this, Binder language is not needed for most SRVPGMs, CRTSRVPGM export(*all) would be sufficlent.

<Jon>
Use Binder Language to establish a fixed signature and manually control the slot associations by ALWAYS adding new procedures to the end of the list.
</Jon>

Using a fixed signature fakes the LVLCHK mechanism, the one and only diffrence to LVLCHK(*NO) is: you could controll the sequence of exports. In case of lousy programming LVLCHK won't assist, the programm will abort in an uncontrolled manner. (BTW, you could controll sequence without binder language by prefixing your exports too).

If you have some versioning tools (and you should!!!) the first strategy - with system signatures and LVLCHK is much more stable than the second. Furthermore it's more simple, you don't need binder language.

Binder language would be needed, if you are providing public SRVPGMs as a package. In this case the strategy with a fixed signature would not be sufficient. Here I would recommend that every release has a signature of its own and the previous export lists and signatures of previous releases too. additional every release has it's Binding, if there are other components as prerequisite.

D*B