RE: binding directories

[bmorris@xxxxxxxxxx]

>Date: Sat, 20 Oct 2001 20:28:51 -0400
>From: "M. Lazarus" <mlazarus@ttec.com>
>
>At 10/19/01 11:29 AM -0400, you wrote:
>>I would never put service programs and modules into the same binding
>>directory.  The risk in combining them is that you accidentally bind
>>the same module into more than one program.  Shudder.
>
>  How?  I'm assuming that you mean that the module is contained in the
>*SRVPGM and that the *MODULE exists on its own and that the *MODULE is an
>earlier entry in the binding directory.

mark, I was thinking about the case where a program is created from
multiple program-specific modules, possibly also using service
programs.  Those program-specific modules wouldn't be also in service
programs, since they would only be needed by one program.

In a perfect world, those program-specific modules would never have any
functions useful for other programs, so the danger I was talking about
would never arise.  But you'd still need perfect testing, so that one
program couldn't say by accident reference by name an exception handler
intended for another program, with the error never found until long after
it goes into production.  For example, say programA has an exception
handler called file_not_found, and programB needs such an exception handler
too, but needs it to do something else.  Programmer B writes his program
to use a handler called file_not_found but forgets to write it and
forgets to write a testcase for it; the binder finds it, and the program
compiles and everything seems fine.

I realize that some people create service programs even for program-
specific sub-modules, but that has never made sense to me.  The danger
of putting program-specific code into a service program, especially
one put into a common binding directory, is the same problem I just
talked about: that programA picks up a procedure meant only for programB.
Requiring every submodule to be generic so this situation could never
arise seems unnecessarily harsh.

Barbara Morris