Midware Ltd.

Sign-up for e-mail notifications

Take our weekly poll

Service programs are a very powerful component of the ILE environment.  A service program allows a program to reference a module dynamically rather that statically.

A service program is created with the command CRTSRVPGM.  One or more modules are used to create a service program.  In our example, we're going to create a service program using our one procedure module.  We'll give the service program the same name as the module (which has the same name as the source member).

The service program will have an object type *SRVPGM.  A service program can kind of be thought as a collection of modules, which in turn has a collection of procedures.

Like a module, a service program is not executable from the command line.

In our previous example, we used CRTPGM to create a new program by binding together the two modules.  Now, we're going to create the program using the mainline module and the service program.

CRTPGM PGM(prog1) MODULE(prog1) BNDSRVPGM(procs1)

The entry module defaults to the first (and only) module. The program will be created with a reference to the service program, rather than an actual copy of it.  Sometimes this is called bind by reference vs. bind by copy.

Because of the bind by reference, the program object is smaller than if it were bind by copy.  Each time the program is called, all references to service programs will be resolved and the current version of the service program, modules and procedures will be copied into memory.

Obviously, the main advantage this provides is that when the modules need to be changed and re-compiled, only the service program needs to be changed.  The next time the program object runs, the new version of the service program will be retrieved.  In this sense, a service program is very similar to an externally called program, while retaining the benefits of ILE procedures.

The only significant disadvantage dynamic binding has over static binding, is that service programs do take some extra resources to resolve references at run time vs. compile time for modules.  This extra overhead should be irrelevant however compared to the maintenance benefits provided.  The only exception to this is if a program that uses a service program is called several hundred times online of thousands of times in batch.

For example, lets say PGM1 calls PGM2 1,000,000 times, which calls service program SRV1.  Each time PGM2 is called (unless it is returned with *INLR off) it will have to resolve the reference to SRV1.  If this is the case however, you could make a strong case for moving PGM2 to a procedure and including it in a service program as well.

It is up to your discretion whether you use bind-by-reference or bind-by-copy.  However, my opinion is that bind-by-reference should always be used.

Signatures

When a service program is created, it is assigned a unique signature based on the procedure sequence and exports.  When a program is bound to a service program, it is bound to the signature as well.  If new procedures are added to the service program, or exports are re-arranged, a different signature will be generated.  If the program is run against the new version of the service program without being re-bound, a run-time error will generate.

A signature in this sense is very similar to a record format level identifier.  If a record format changes and the program is not re-compiled, you will get a level check error which is very similar to a signature violation.

By using a binder language you can explicity specify a signature and eliminate signature violations.  This has both positives and negatives which we'll cover later.

Back to Static Binding

Next to Organization

Send mail to midware@midwareservices.com with questions or comments about this web site.
Copyright © 2000 Midware, Ltd.

Last Modified:  September 05, 2000