Bryan's RPG IV Journal
Binding Directory Organization
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:
specify the binding directories, starting with the most specific:
Advantages:
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.
- 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
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.
Log of Journal Entries |
|
Use this scrollable blog map to view other journal entries: |
|
| It is your responsibility to ensure procedures, techniques, and code used from this website are accurate and appropriate for your installation. No warranty or support is implied or expressed. |
![]() |
| Privacy and Email Policy |
| AS/400®, eServer, i5/OS, IBM i, Integrated Language Environment®, iSeries, OS/400®, RPG/400®, System i5, VisualAge®, and WebSphere® are trademarks of IBM Corporation. Note: IBM® System i is the latest member of the family of eServer iSeries. This site might refer to System i as System i5, iSeries, or AS/400. |
|
If you are having trouble navigating the menu at the top of this page, you may use the following scrollable site map instead: |
|
|











International visitors: