Learning to use the ILE binder language is essential to managing all but the simplest service programs. True, you...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
can create service programs without using the binder language, but when you start modifying and updating existing service programs, careful use of the binder language can save you hours of work recreating programs that use those service programs.
Understanding service program signatures
Before discussing the binder language, it is important to understand the role of service program signatures and how they affect ILE applications. When you create a service program, the binder (a.k.a. the linker) creates one or more signatures for the service program -- one current signature and zero or more previous signatures (more on this later). The signatures are stored with/in the service program object.
When an ILE program that uses a service program is created, the service program's current-level signature (or current signature) is stored in the ILE program. When the ILE program is subsequently executed, the signature in the ILE program is checked against all the signatures (current and previous) stored in the service program. If the copy of the signature stored in the program does not match any of the signatures in the service program, the program will receive an error.
This signature matching is the functional equivalent to the level checking that takes place for files and, in fact, is called level checking. It allows the system to ensure that the ILE program and the service programs it uses are still compatible before the ILE program starts running.
Current-level vs. previous-level signatures
When a service program is first created, it has one signature -- a current signature. If, for example, you later add a new procedure to the service program and do not use the binder language, the current signature will be replaced with a new, but different, current signature and any existing programs that were linked using the original version of the service program will generate level-check errors when run.
This can be avoided by using the binder language to save the original current signature as a previous-level signature (or previous signature) -- along with the new current signature -- in the modified service program. The service program will then have two signatures. This way any existing programs that were linked using the original service program -- those programs that have the original current signature stored in them -- will run without error because the signature will match one of the service program's two signatures. They will match the previous level signature.
Service program signatures are used to verify service program compatibility. Similar to file and record level IDs, and file and record level-checking.
Service programs can contain many signatures, one current signature and zero or more previous signatures. This allows the designer to maintain a number of different compatibility levels for a single service program.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.