How to get the list of binding directory attached to a rpgle program

Question

Suppose I have a program RPG1, I have attached binding directory DIR1, DIR2 and DIR3 to it during compilation. These are not specified in the HSpec of the program.

The program is now compiled.

Now how do I get the complete list of binding directory attached to this program.

Answer 1

It seems to me that it doesn't. BNDDIR is just an indication to the compiler where to look for those procedures that are not directly in the program text (external procedures). No more. There is no need to keep a list of them after compilation. Strictly speaking, BNDDIR stores only an indication of where this or that external procedure is located. And instead of BNDDIR, the compiler can be explicitly told to use SRVPGM to search for such procedures. So in the program it is rather necessary to look for which SRVPGMs are used there. This can be done with the DSPPGMREF command

Answer 2

Binding directories, object type BNDDIR, are a compile time (technically bind time) convenience object for the developer.

Unless listed in the h-spec, there's no record of rather or not a binding directory was used in the creation of a *PGM or *SRVPGM.

Which is fine, since there is zero difference between objects created with the use of a binding directory vs. explicitly specifying the modules (via the MODULE parm) and service programs (via BNDSRVPGM parm) of the CRTPGM and CRTSRVPGM commands.

Answer 3

After reading the excellent answers from Charles and Victor, you may be wondering why only the compiler cares about the binding directory. After all, service programs are like a Windows dll aren't they?

Not exactly. Procedures are statically bound into the executable after the compile step. CRTBNDRPG hides this, but if you were to compile your source into modules, you would not need the binding directory for the compile step. It is the CRTPGM (the binding step) that requires it. Since procedures are statically bound, there is no need for the binding directory once the program objects are built.

TL;DR There is that thing about using *LIBL to find a service program, and you can use this to find the service program in your library list at run time, but the location of the procedure within the service program is written in stone during the binding process. If you explicitly specify a library for the service program in the binding directory, The service program must be found there at run time. The program won't even use the library list to find it at run time. You can use this fact to use third party service programs without putting their libraries in your library list.