Binder Language

Midware Ltd.

We've seen up to this point that by using bind-by-reference rather than bind-by-copy we have a much simpler maintenance task. When simple changes are made to the procedures (for example, to fix bugs), only the service program needs to be updated. The programs that are bound to the service program will automatically use the new procedure the next time they are called.

The problem is when we make a less superficial change to a module. If, for example, we add a new procedure to a module, or add optional parameters to an existing procedure, a different signature will get generated when we create the service program. All programs that are bound to that service program will need to be rebound, or they will get a signature violation error when called.

At first, this seems like a pretty major oversight. The reason signature checks were added to ILE was to prevent a program from calling a module with unknown changes, possible causing serious application errors. This is very similar in concept to level checks on database files.

Also like level checks, there is a way around the problem. By using binder language you can explicitly assign a signature to a service program which will override the system generated one.

Note: The secondary (and perhaps main) functionality of binder source is to specify procedure exports. This allows you to externally specify which procedures will be exported from a module. There are some advantages of this, but in my opinion, the most useful function of binder source for most shops will be the ability to explicitly specify a signature.

Writing binder source is actually pretty simple. Create a new source member of type BND. There is normally one binder source per module. The structure of binder source is as follows:

STRPGMEXP PGMVAL(*CURRENT) SIGNATURE('...')
   EXPORT SYMBOL('...')
   :
   EXPORT SYMBOL('...')
ENDPGMEXP

STRPGMEXP PGMVAL(*PRV)
   EXPORT SYMBOL('...')
   :
   EXPORT SYMBOL('...')
ENDPGMEXP

Lets assume we have a source member called PROC1 that has three procedures in it - DayOfWeek, Uppercase, and Lowercase. In our example, this source member will get compiled into a module, and a service program will get created from the module.

The binder source for the service program will look like this:

STRPGMEXP PGMVAL(*CURRENT) SIGNATURE('PROC1a')
   EXPORT SYMBOL('DayOfWeek')
   EXPORT SYMBOL('Uppercase')
   EXPORT SYMBOL('Lowercase')
ENDPGMEXP

When we create the service program with the following command:

CRTSRVPGM SRVPGM(library/PROC1) MODULE(PROC1)
EXPORT(*SRCFILE) SRCFILE(library/sourcefile)
SRCMBR(binder-source)

The service program will then be given a signature of "PROC1a" rather than a system generated one. If we make changes to the PROC1 module, we can determine ourselves if all programs using it need to be changed.

If we made simple changes, added procedures, or added optional parms to the end of a procedure interface, we could retain the existing signature.

If we made changes that we know will require modifications to the calling procedures, we can assign a new signature of "PROC1b". This will force us to change and re-bind our programs.

Binder language has many applications aside from just providing a signature. Click here to see some examples from IBM of other applications of binder source.

Back to Variable Size Strings

Next to Summary

Last Modified: September 11, 2000