Re: Procedure names vs. production support

> I have never understood the idea of one procedure = one module =
(often) one
> service program.
>
> Just because I change a procedure in a module I am not forced to
retest every
> procedure in every module in the SP. Apart from anything else I can
always
> bind the module into a test harness and test it in isolation.  If it
works OK
> - glue it into the SP and it will still work.

Many people convert a subroutine into a subprocedure, the EXSR into
CALLP and don't change any of the code.  Slap an 'h nomain' on it and
Bob's your uncle - a service program!  The end result is that the
'procedure' is using as many global variables as the subroutine did.
This makes interactions inevitable, requiring a full-up test in situ -
no test jig possible.

Another oft-mentioned reason for this behaviour is due to some
(possibly only perceived) limitation in the source change control
software.  Something like: programmer Jack can't check out the STRING
member and work on leftJustify while programmer Jill tries to check
out source member STRING to work on centreString.  Only one programmer
per source member.
  --buck