ILE: Decisions, Decisions, Part 1
June 8, 2011 Susan Gantner
|
I’ve been working with and teaching people about ILE for many years. There are a few questions that come up again and again. So I thought I’d cover my responses in some tips. In this tip, the subject is binding directories. I’m often asked about the best way to use binding directories and/or how many binding directories I recommend. My philosophy is to keep things as simple as possible for the developers. I believe that ILE’s value is in making development more efficient by making it easy to develop and use your own application functions that you can use as easily and as naturally as you use RPG’s built-in functions. Binding directories are a key part of that. You don’t have to think about what specific functions are to be used in a particular program or which service programs contain those functions. Just include a binding directory (or several of them) in the H spec and use whatever you like. The binder will find the right service programs and/or modules needed to supply that functionality via the binding directories. For a refresher on the basics of binding directories, check out this article on Customizing Your Development with Extensible RPG. As to the specific question of how many binding directories to use, I’d use a few as is practical for your applications. For some shops that may mean that most of their programs can be created with only one binding directory. For other shops, it may be easier to manage binding directories by having one per application and, because some functions will not be specific to a particular application, perhaps another, more generic utility binding directory. In addition, you will almost certainly need to use some special purpose binding directories occasionally, such as QC2LE when calling C functions or when using utilities or tools such as CGIDEV2. The reason I prefer to keep the number of binding directories to a minimum is that it seems simpler to manage fewer objects than to manage many objects. I want the use of a shop’s own reusable functions to become so automatic that developers don’t need to think about where that function is before they can use it. Having only one or two binding directories used for most programs reduces the amount of attention to the application structure required on the developer “users” of those functions. And for the developers creating the reusable functions, there is less thought required about what binding directory to put their new service program into. I have heard from shops that create a binding directory for every program. To me, this seems like way too much trouble and I haven’t found any advantage to the practice. In talking with people from shops that do this, there seem to be two primary reasons for it. First, they like that the binding directory provides documentation about what the program uses. Second, they sometimes think they are creating more efficient programs this way because they can’t introduce any extra modules or service programs into the program; only the ones needed for this program are in the binding directory. As to the documentation point, I think the program object documents itself quite well. Using the Display Program (DSPPGM) command, I can see a list of the modules copied into the program. From there I can drill into each module to get details, such as what source member was used to compile the module and when the source was last changed. I can also see a list of any service programs referenced by the program, including the signature value the program is looking for in the service program, and I can drill down to get a wealth of information about the service program. All that information pales in comparison to the documentation provided by a binding directory. As to the efficiency point, the binder (the part of the system that creates ILE programs) only pulls things from the binding directory that a particular program needs. So to create a specific program, it will be no bigger if you use a binding directory that has 50 service programs and 20 modules in it versus using one with only the three service programs it uses. The binder will not use the extra objects that are not needed when it creates the program. In case you wonder how the binder can possibly know what modules and/or service programs it needs to pull into an ILE program from the binding directory, take a look at a module with the Display Module (DSPMOD) command. Press Enter until you see Detail *IMPORT or the title “Imported (unresolved) Symbols.” That’s the list of things–usually called functions or procedures–that this module uses. That’s how the binder knows what it needs to look for in your binding directories. You’ll probably notice a lot of procedures that begin with Q or _Q. Those are system runtime functions that your module needs. The compiler generated code that calls these routines. Of course, your binding directory is not going to help the binder find those “Q… . .” routines, but if you keep pressing Enter on the DSPMOD command, you’ll also see a “Reference system objects for bind time” display that shows the binding directories that will be used to help the binder locate those routines, as well as any binding directories you may have included for your own routines. So far we’ve seen how the binder knows what it’s looking for and how it knows the binding directories to use to find those things. However, the binding directories don’t contain the actual procedure/function names in them–they only have service program or module names. So how does the binder find out which objects from the binding directory to use? It drills into each object listed in the binding directories to find what exported procedures and/or data items are in each one. You can also see this information using the DSPMOD and the Display Service Program (DSPSRVPGM) commands. Look for the “Exported Defined Symbols” screen of the DSPMOD command output or the “Procedure Exports” screen of DSPSRVPGM to find the procedures available to be bound to a program or service program. So there you have my philosophy of using binding directories–keep it simple by keeping the number of them to a minimum. Of course, not everyone agrees with my philosophy of “fewer is better” on binding directories. You can read about another approach here and make a decision for your shop. One last thought on binding directories: No matter how many you use, it’s a good practice to create one (or more if necessary) /COPY members with your standard H spec keywords to include in all your source members. One of the things in that standard H spec should be your binding directory name(s). In the future, I’ll explore a few additional ILE questions that I hear frequently. Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page. RELATED ARTICLES Customizing Your Development with Extensible RPG
|
