Oppolzer - Informatik / Blog

From: Bernd Oppolzer
Sent: Sunday, 17 February 2013 3:03 AM

> Just to make it clear:

It was clear already.

> the "old" procedure call without the new parameter remains at the same name,
> so that existing callers need not change their programs. The old
> procedure changes in such a way that the logic is migrated to the new procedure and the
> old procedure simply calls the new procedure, specifying default values for the new
> parameters.

> "New" callers which need the new parameter have to use the new procedure
> name.

> The callers of the old procedure are informed and asked to switch to the
> new procedure, but they need not do it now (with great celerity,

with no great celerity

> as J.G. writes), but they can it do at any time - for example, when they change
> their module the next time anyway.

> When, some months later, all callers have switched to the new proc, I
> can get rid of the old one.

Two seriously fatal airplane crashes occurred because the pilots overlooked the
obvious. Namely, they forgot to set the flaps for take-off. Without the flaps
down for take-off, the planes could not get uplift when the time came to lift
off the runway.

Changing the name of a procedure for the sake of changing it when other avenues
are available without the forced changing of other procedures that call it, is a
good way to have a run-time failure. (Sooner or later, someone overlook changing
one procedure call.)

In point of fact, it generates unnecessary work for everybody.

> BTW: all calls are dynamic calls, using MVS LOAD and ASSEMBLER interfaces,
> although the modules are PL/1, ASSEMBLER or C modules - the language
> doesn't matter. There is no static linkage of modules.