Service Program

A service program is a collection of runnable procedures and available data items easily and directly accessible by other ILE programs or service programs. In many respects, a service program is similar to a subroutine library or procedure library.

Service programs provide common services that other ILE objects might need; hence the name service program. An example of a set of service programs provided by the operating system are the runtime procedures for a language. These runtime procedures often include such items as mathematical procedures and common input and output procedures.

The public interface of a service program consists of the names of the exported procedures and data items accessible by other ILE objects. Only those items that are exported from the module objects making up a service program are eligible to be exported from a service program.

The programmer can specify which procedures or data items can be known to other ILE objects. Therefore, a service program can have hidden or private procedures and data that are not available to any other ILE object.

It is possible to update a service program without having to re-create the other ILE programs or service programs that use the updated service program. The programmer making the changes to the service program controls whether the change is compatible with the existing support.

The way that ILE provides for you to control compatible changes is by using the binder language. The binder language allows you to define the list of procedure names and data item names that can be exported. A signature is generated from the names of procedures and data items and from the order in which they are specified in the binder language. To make compatible changes to a service program, new procedure or data item names should be added to the end of the export list. For more information on signatures, the binder language, and protecting your customers’ investment in your service programs, see Binder Language.

Figure 1 shows a conceptual view of a service program. Notice that the modules that make up that service program are the same set of modules that make up ILE program object PGMEXAMP in Figure 1. The previous signature, Sigyy, for service program SPGMEXAMP contains the names of procedures P3 and P4. After an upward-compatible change is made to the service program, the current signature, Sigxx, contains not only the names of procedures P3 and P4; it also contains the name of data item D. Other ILE programs or service programs that use procedures P3 or P4 do not have to be re-created.

Although the modules in a service program may have PEPs, these PEPs are ignored. The service program itself does not have a PEP. Therefore, unlike a program object, a service program cannot be the target of a dynamic program call.

Figure 1. Conceptual View of an ILE Service Program
Characteristics of an ILE *SRVPGM object:
  • One or more modules from any ILE language are copied to make the *SRVPGM object.
  • No PEP is associated with the service program. Because there is no PEP, a dynamic program call to a service program is not valid. A module’s PEP is ignored.
  • Other ILE programs or service programs can use the exports of this service program identified by the public interface.
  • Signatures are generated from the procedure and data item names that are exported from the service program.
  • Service programs can be replaced without affecting the ILE programs or service programs that use them, as long as previous signatures are still supported.
  • Modules can have debug data.
  • A service program is a collection of data items and runnable procedures.
  • Weak data can be exported only to an activation group. It cannot be made part of the public interface that is exported from the service program. For information about weak data, see Export in Import and Export Concepts.