Re: Service Programs and Naming Conventions

Marvin Radding wrote:
> 
> Yes, the could exist two different programs callig two different
> versions of MyProc.  The copy file that provides the PR interface will
> dictate which version of MyProc is actually called.
> 

Marvin, what kind of changes do you envison making this way?  I can
imagine a few kinds of changes:

1. Simple bug fix in the internal code.  For this, you only need to
change the one version of My_Proc.  There's little point in having old
programs call the buggy version.

2. Add a parameter to provide new function.  If you create a new
procedure for this, old programs will continue to call the old version
of the procedure, but as soon as they are recompiled, the compile will
fail because you don't have enough parameters.  If you make the new
parameter *nopass to get around this, you don't really need a new
procedure after all.

3. Change the length of a CONST or VALUE parameter.  This is the case
where you do need a new procedure if you want old programs to continue
to work.  But as Scott said, the need to do this comes up quite rarely. 
If this case did come up, I would probably do what you are planning to
do, adding the new procedure at the end of the binder source, and
changing the prototype.  But careful design of the prototypes in the
first place can reduce the incidence of this type of change.

4. Change a data structure parameter to use a new format.  If you have a
procedure that might have this type of change, using IBM's style of
having two extra parameters giving the parameterLength and
parameterFormat is probably a good way to design the procedure in the
first place.

5. Change the procedure to have new side effects that should not happen
for old callers.  Just the idea of making this type of change gives me
the shivers.  Evaluating all the combinations of what possible procedure
versions your programs are calling could be an endless task.