Re Removing a procedure from a service program

what's happening it all depends on how you are managing your signatures and what you are exporting!
you are using binder language, so there are two possible cases:
- 1.) the procedure is not exported with the binder source: => CRTMOD and UPDSRVPGM and nobody outsite will recognize this.
- 2.) the procedure to remove is exported via the binder source: now we have again two possibilities:
- 2.1.) system generated signatures: => CRTMOD and UPDSRVPGM (BTW: CRTSRVPGM would be easier to understand how the SRVPGM has to be created compared to CRTSRVPGM, first UPDTSRVPGM, second UPDSRVPGM...)
the signature will change, all programms using this SRVPGM have to be rebound (CRTPGM and (CRTSRVPGM or UPDSRVPGM)). some effort, but very stable! this step will refresh all dependencies, if something doesn't fit, the rebind fails and if you've forgotten one object, this PGM/SRVPGM is not callable anymore and will fail, without having a chance to do any harm and you will see the cause of the problem in every joblog without any problem to reproduce the problem. Solving the problem would be very easy => just do the forgotten rebind.
- 2.2,) faking the signature, pretending nothing has changed: no we have again some possibilities:
- 2.2.1) removing an export and adding another export to the end: this won't work as expected anymore without rebind: all components using the removed export, or an export after this, will fail at the moment one of the exports is called, you won't see the real cause in the joblog, the programms are just doing funny things, failing with unresolved pointers or similar problems. If you don't see the real problem, every change in the failing programm will cure the problem, because recreate and rebind will solve the problem without the need to know the real problem behind!!! components trying to use the removed export could not be bound anymore.
- 2.2.2) replacing an export with another export (regardless if you only change the name of the export from foo to foo_deprecated, or the export foo with foo_new) only those components are affected from this, trying to use the original version, those components will react funny (similar to 2.2.1), but you will pay another price for this: the rebind for components created with the old version will not work (unresolvable reference).
There is another szenario coming up with the discussion:
- 3: removing the export (foo) adding foo_new to the end pretending with a constant signature nothing has changed (very similar to 2.2.2). changing the programm needing the new (changed) procedure will work as expected. the first failure (2.2.1) is happening maybe some months later and you have had some exports added to the end of the list (shit happens)...
There are two possible ways to handle this:
- never break the compability of a signature (don't remove or rename an export, or change the type or parameters of an export). This way you would have to go, if you deliver SRVPGMs and you don't know who is using them.
- use generated signatures and rebind all dependent components (its very easy to find dependent components! and even the rebind of a whole application is no real problem today!). This is the easiest solution, if your apllication is the one and only application using your SRVPGMs. And if you don't use bind by copy (multiple modules in one SRVPGM), you would have no need to deal with binder language at all - and it's foolproof and fools might be at any place...

D*B