Difference between revisions of "Service Program"
DaveLClarkI (talk | contribs) |
DaveLClarkI (talk | contribs) |
||
| Line 5: | Line 5: | ||
A service program itself is not executable, but it can be called by many other ILE programs to execute the [[:Category:Service_Procedures|service procedures]] contained within. | A service program itself is not executable, but it can be called by many other ILE programs to execute the [[:Category:Service_Procedures|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 service program loaded into memory and is dynamically (and automatically) bound by the operating system to the calling program at execution time. This 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. | |
| + | |||
| + | 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]]. | ||
{{stub}} | {{stub}} | ||
Revision as of 18:36, 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 service program loaded into memory and is dynamically (and automatically) bound by the operating system to the calling program at execution time. This dynamic binding can be immediate at calling program load time or deferred until one of the service program's service procedures are actually called.
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.
