Seems to me there are a number of approaches each with its own set of
advantages and disadvantages:
1) List modules and service programs on each CRTPGM.
Simplest approach but onerous and likely to result in errors because
humans have poor recall and poor attention to detail.
2) Use BNDDIR (containing modules and/or service programs) on
CRTBNDxxx command.
Fairly simple but inconsistent command definitions (note1) make it
difficult to implement.
3) Use naming conventions to group related modules. Logic goes in
XXXXX01, display goes in XXXXX02, database I/O goes in XXXXX03. Then
a simple CRTPGM XXXXX MODULE(XXXXX*) will get them all. Service
programs are picked up from a single common *BNDDIR.
Easy to remember but possibly hard to retrofit.
4) Use one *BNDDIR per program object. This lists ONLY the modules
used by the program. Have another *BNDDIR containing ALL service
programs. Reference both *BNDDIR objects when creating the program.
Easy to remember and takes advantage of the built-in compiler
support for H-spec directives in RPG. Does result in a plethora of
unnecessary *BNDDIR objects.
5) Use build scripts or a build tool to list the modules. Again, a
single common *BNDDIR contains all service programs.
Reasonably easy. Not limited to RPG H-spec support. Do need to learn
another tool/script or remember to compile CL scripts (unless you use
them as job streams).
6) Use a change management system. A good one can either determine
the needed modules or will support build scripts.
More complex but is the best and proper solution.
There are other mixtures of CRTBNDxxx commands, modules, service
programs, and binding directories but they become rather artificial
so I'm ignoring them.
For me I would use option 6. If I did not have access to a change
management system (although I probably would refuse to work for such
a company) then I would use option 3 but could, perhaps, be persuaded
to consider option 4.
Note1: The inconsistencies in the various CRTBNDxxx commands
seriously irritates me.
BNDDIR ACTGRP DFTACTGRP
CRTBNDC N N N
CRTBNDCBL Y Y N
CRTBNDCL N Y Y
CRTBNDCPP N N N
CRTBNDRPG Y Y Y
I'm not surprised by the lack of support on the C and C++ commands
because they are obviously written by people with NO understanding of
OS/400 (witness the blindingly stupid use of the OUTPUT parameter as
a case in point) but I would expect System DCG (if it still exists)
to ensure consistency. All these commands should support all three
keywords even if DFTACTGRP is a bad idea (and don't get me started on
STGMDL).
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
