Our company has many ILE programs that may or may not be created by using a binding directory. When I have changed...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
a module within a program, how can I find out if there is a binding directory available to rebind (CRTPGM) for this program? Some of our binding director names do not match the program name preventing me from looking the binding directory up by using the program name. What do you suggest?
The first thing is that you should not create a separate binding directory for each program. And especially, if you do, you should not then use different names for some of them. That leads to confusion only.
All a binding directory does is to provide a list of bindable modules and service programs that can be used by the HLL compiler. This list means that you do not have to specify each module or service program a program will use on the CRTPGM command, or in the H-specs of an ILE program source. A PROGRAM, in this case, is a piece of RPG source which does NOT specify *NOMAIN, so it has a mainline and a single entry point and a proper exit. A MODULE is a piece of source that has *NOMAIN specified, and has exported procedures which return control using the RETURN operation code.
So you create a program that uses other modules (and perhaps service programs), and when you create the program you want those modules and service programs to be found and bound to it. To do that, you can specify each module on the MODULE parameter of the CRTPGM command, and each service program on the BNDSRVPGM parameter, and specify which module is the entry procedure module. In RPG, only modules which did NOT specify *NOMAIN can be specified here, and usually that module is the one which has the same name as the program.
What happens if you specify modules or service programs that are not used by the entry procedure module, or by modules which are used by it? Well, they are not bound, because the procedure calls are checked and linked to the exports of the modules. If no exports are used from a particular module or service program, that module or service program is not linked.
Now if you specify a binding directory instead of the list of specific modules and service programs, your CRTPGM command gets a lot simpler, so you can use a binding directory just as a list of all the USEFUL sets of procedures you have. Anything that is NOT used is not bound.
There is really no need to have more than one binding directory, especially if all the objects in it have a library entry of *LIBL. Of course, there are times when it may be useful to have a specialized binding directory, but within a single set of application programs. I have not found a case for more than two binding directories to be created.
In your case, though, you seem to use binding directories as if they were specific to each program. This makes it very difficult for you to maintain anything, since the name of the binding directory is not kept as part of the program object.
You could specify the binding directory name in the source of the program entry procedure module (H-spec BNDDIR keyword). This at least means you can find it easily. But as it is, you will have to work with all your binding directories and display their entries until you find the one you want.
Dig Deeper on iSeries application development tools
Related Q&A from John Blenkinsop
When an error occurs on an IBM command, the diagnostic messages are sent first, then an escape message, which you can monitor. On AS/400 you see the ...continue reading
Learn how to 'append data to the file' with the FTP DIR command, and eliminate the hassle of having to end the FTP session and restart to view ...continue reading
RPGIV will 'think of' incoming integer fields as binary, and then will redefine them in the program structures as PACKED. So, when you chain a record...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.