Re: Modules, Srv progrqms, binding directories

David,

I'd add a couple more cases:

3. For stand-alone utilities (where you want to ship a single program object
which won't need to rely on other objects). For many people, this isn't an
issue, but for those of us who work for software houses, this situation
often comes up. It can also be an issue if *SRVPGM signatures are liable to
change - sometuimes you want to know that no matter what release of your
software a customer is using, a particular utility will always work.

4 (kinda related to 3). For CGI programs and similar programs where the
service program might not be in the same library as the program. I've had
problems where a CGI program is called, but because the HTTP server library
list is minimal, it fails immediately, because the library where the service
program exists isn't in the *LIBL.

There are ways to get round #4, but sometimes it's easier to have a
self-contained multi-module *PGM (or a 'wrapper' program which does its own
library list handling before calling any program which accesses *SRVPGM's.

Rory


On Thu, Mar 25, 2010 at 7:54 AM, David Gibbs <david@xxxxxxxxxxxx> wrote:

There are only two situations where I would consider binding a module
directly into a program ...

1. Security concerns ... avoiding the risk that some kind of security
program might get overridden by someone by putting the service program it's
bound into higher on the library list.

2. Necessary mixed languages ... where I need to call a C, CL, or Cobol
routine in a program that would never be used anywhere else.

FWIW: I also think that there's no real reason to create multi-module
programs where all the modules are the same language. If you have procedure
that's private to a program (and would never be used in another program),
there's no need to put it in a separate module ... just put the procedure in
the main program. Less to manage that way.

david