Hello, Darrell:
Please consider the following suggested methodology (or set of "rules")
for working with ILE modules and service programs:
#1. if a *MODULE is used by (bound into) only one *PGM, then just go
ahead and directly bind it into that program with the CRTPGM command,
naming any modules needed on the MODULE parameter of CRTPGM. (No need to
create a binding directory for this simple case.)
#2. as soon as any *MODULE is to be used in more than one *PGM, then it
is time to put that module into a *SRVPGM. If several modules are all
bound into a single program, and now you want to use some or all of
those modules in another program, perhaps all of those modules could be
bound into a single *SRVPGM. Then, you go back and re-bind the original
*PGM that used those modules, re-issuing the CRTPGM, and this time, you
specify the SRVPGM parameter, rather than naming the modules, so you
"bind by reference" rather than "bind by copy."
#3. you can also create a single "binding directory" for each
application, and add only the *SRVPGMs to the binding directory. Then,
when you create programs that use procedures in modules in your service
programs, you have only to name this binding directory on the BNDDIR
parameter of the CRTPGM command.
#4. I advise you to definitely take a look at Alan Campin's excellent
COMPILE tool, available here:
http://www.think400.dk/downloads.htm
This tool will enable you to embed create commands, such as CRTPGM, and
specify what *MODULEs to bind into the *PGM, in the source code for the
main program itself.
The primary consequence of using the above rules is that each *MODULE is
used (bound) in only one place, a single *PGM or a single *SRVPGM. This
will greatly simplify program maintenance, when a module is changed (due
to fixes or enhancements). Otherwise, you must create some tools, or
find some "open source" tools, or use some vendor tools, to find out
everywhere that *MODULE is bound, and then take action to replace it
everywhere it is used, whenever changes are made to that module.
You can use the above suggested methodology ("rules") and Alan Campin's
COMPILE tool, whether or not you are using a "home-grown" or an ISV
supported "change management" tool.
_ACTIVATION GROUPS_
Once your shop starts using *SRVPGMs, you will need to become aware of
"activation groups" and the differences between running in the "default
activation group" (aka. "OPM compatibility mode") and ILE activation
groups (named or *NEW). It might be a good idea to consider
establishing a shop standard "rule" that states that each *SRVPGM will
always run in its own named activation group, where the name of that
activation group is the same as the name of the *SRVPGM. This way, you
will never have to worry about a *SRVPGM accidentally getting activated
into the *DFTACTGRP, which can have unintended consequences. Basically,
once a *SRVPGM gets activated in the *DFTACTGRP, you cannot easily
reclaim it ... (RCLRSC will not touch it). It will only ever get shut
down and cleaned up automatically at "end of job". If your *SRVPGMs
always run in their own named activation group, you can then reclaim any
*SRVPGMs individually, by issuing:
RCLACTGRP ACTGRP(srvpgmname)
You can issue this from a command line, for example, when recompiling
and debugging in a development and testing environment, or you might
occasionally find a need to issue this from within your application,
similar to cases where you would issue RCLRSC to close files and
deactivate programs in an OPM environment.
All the best,
Mark S. Waterbury
> DLee@xxxxxxxx wrote:
Morning;
Our management has finally decided to climb out of the cave and begin
allowing us to use modules, service programs and binding directories.
Hooray (I think).!!
We think we know service programs should be added to binding directories,
but have questions about the reason if any to add modules to binding
directories since they can be bound at CRTPGM time.
So I'm kind of looking for the conventional wizdom on binding directories.
Appreciate any help you can provide.
Regards,
Darrell
SWBC
9311 San Pedro Ave., Suite 600
San Antonio, TX 78216
Visit our website at www.swbc.com
midrange.com
