Difference between revisions of "Service Program"
DaveLClarkI (talk | contribs) |
DaveLClarkI (talk | contribs) |
||
| Line 7: | Line 7: | ||
The primary advantage of a service program is that it is shareable code that is not hard-bound to another program. Thus, when a service program is changed, the calling programs do not necessarily all have to be recompiled in order for them to gain access to the updated code. | The primary advantage of a service program is that it is shareable code that is not hard-bound to another program. Thus, when a service program is changed, the calling programs do not necessarily all have to be recompiled in order for them to gain access to the updated code. | ||
| − | Instead, the operating system automatically | + | Instead, the operating system automatically performs a one-time load of all referenced service programs into memory and dynamically binds them to the calling program(s) at execution time. This automatic loading and dynamic binding can be immediate, at calling program load time, or deferred until one of the service program's [[:Category:Service_Procedures|service procedures]] are actually called. The service program remains in memory as long as the job is active. |
Further, once the operating system has loaded a service program into memory, calling any of its [[:Category:Service_Procedures|service procedures]] requires no more overhead than calling an internal subprocedure within your own program. | Further, once the operating system has loaded a service program into memory, calling any of its [[:Category:Service_Procedures|service procedures]] requires no more overhead than calling an internal subprocedure within your own program. | ||
Revision as of 18:46, 13 December 2018
A service program is a collection of ILE modules that are bound into a single object of type *SRVPGM.
A service program itself is not executable, but it can be called by many other ILE programs to execute the service procedures contained within.
The primary advantage of a service program is that it is shareable code that is not hard-bound to another program. Thus, when a service program is changed, the calling programs do not necessarily all have to be recompiled in order for them to gain access to the updated code.
Instead, the operating system automatically performs a one-time load of all referenced service programs into memory and dynamically binds them to the calling program(s) at execution time. This automatic loading and dynamic binding can be immediate, at calling program load time, or deferred until one of the service program's service procedures are actually called. The service program remains in memory as long as the job is active.
Further, once the operating system has loaded a service program into memory, calling any of its service procedures requires no more overhead than calling an internal subprocedure within your own program.
Note that service program objects have Signatures (that are similar to file format level identifiers, which are the source of Level Check errors) that are controlled by Binder Source. If the signatures between a *PGM and *SRVPGM (or even between one *SRVPGM and another) do not agree, you end up with a signature violation.
This article is a stub. You can help by editing it.
