Q. I work in a shop where service programs and binding directories traditionally have a one-to-one relationship (that is, there is a binding directory for each service program). My preferred approach is service programs with functions related to a business area in a binding directory, then maybe two or three binding directories that cross business areas.
From this scheme it appears we would reduce the amount of time we spend managing our objects. Remembering that we try to keep the functions small, we should not create a lot of “code bloat”; should be able to avoid loading a lot of functionality that is not useful.
A. The advantages of a one-to-one relationship between a program and a binding directory:
- All the pieces needed for the program are listed in one place.
- Relatively easy to automate the binding process, especially if the binding directory is named the same as the program.
- Accelerates binding process by eliminating unused binding entries.
Personally, I prefer the approach of having two or three binding directories:
- A general cross reference binding directory for those entries that cross applications
- An application-specific binding directory, for those entries that are reused only within an application
- An optional program-specific binding directory for those entries applicable only to a single program
Then on the binding command (CRTPGM or CRTSRVPGM) or in the RPG H-specs, I
specify the binding directories, starting with the most specific:
BNDDIR('program-bnddir':'application-bnddir':'xapp-bnddir')
Advantages:
- Eliminates duplication among binding directory entries.
- Common, well known, naming conventions can be used across many programs.
- Relatively easy to manage and automate, especially if naming conventions are consistent.
- Avoids need to create a binding directory for every program; program-specific directory is used only as necessary.
- Avoids error of forgetting to list entries for a program.
The “code bloat” issue is really a non-issue. Remember that unused binding directory entries are never bound into a program or service program; the binder will simply skip the entry.