Oppolzer - Informatik / Blog

Just to make it clear:

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, as John Gilmore
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.

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.

We have other possibilities to deal with interface changes - for example, if
there is no new parameter but only a change to the structure layout of one of
the parameter structures, this can be handled by the interface and a method
which we call "dynamic address list macro". The version of the interfaces of the
caller and the called module are compared, and if they don't match, they are
transformed to the matching version by the ASSEMBLER interface. This works for
all 3 languages, of course.

This is just one of the methods we developped over the years when we had to
support a system which allowed no downtime at all, so all changes, including
database structure changes, had to be done in a compatible way, that is, without
ever interrupting the running system.

Kind regards

Bernd



Am 16.02.2013 14:08, schrieb R.V.:
>
>> The drawback of not using GENERIC: I have to inform the callers that
>> they
>> have to use DIFFERENT names, depending on their need regarding the
>> parameters. But I do it this way: the variant with the maximum parameter
>> count is the only one which will be supported in the future, and the
>> others
>> are only supported for a limited time frame for convenience of the
>> existing
>> callers. So every resonable developer will switch to the variant that I
>> want to support in the long term.
>
> That defeats and contradicts your stated aim above, namely,
> (a) that you didn't want users to have to change their code.
> You are forcing them to do exactly that.
>