Difference between revisions of "Service Program"
DaveLClarkI (talk | contribs) |
DaveLClarkI (talk | contribs) |
||
| (12 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
The primary advantage of a service program is that it is shareable code that is not hard-bound to the calling 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 the calling 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 | + | Instead, at execution time of a referencing [[*PGM]] object the operating system automatically performs a one-time load of all referenced [[*SRVPGM]] objects into memory and dynamically binds them to the calling program(s). This automatic loading and dynamic binding can be immediate, at referencing program load time, or deferred until one of the service program's [[:Category:Service_Procedures|service procedures]] are actually called. Any loaded [[*SRVPGM]] objects remain in shared memory (i.e., not bound to only a single call level) as long as the job is active. |
| − | Further, once the operating system has loaded a | + | Further, once the operating system has loaded a [[*SRVPGM]] object into memory, calling any of its [[:Category:Service_Procedures|service procedures]] requires no more overhead than calling an internal subprocedure within your own program. Thus, from this standpoint, the use of service programs should not be considered a performance issue. Any other load-time performance considerations should be measured against the strategic advantage of having such easily shareable code. |
| − | Note that | + | Note that [[*SRVPGM]] 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 (for cross-service-program calls) do not agree, you end up with what is termed a [[Service Program Signature Violations|signature violation]]. |
{{stub}} | {{stub}} | ||
Latest revision as of 17:52, 17 December 2018
A service program is a collection of one or more 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 the calling 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, at execution time of a referencing *PGM object the operating system automatically performs a one-time load of all referenced *SRVPGM objects into memory and dynamically binds them to the calling program(s). This automatic loading and dynamic binding can be immediate, at referencing program load time, or deferred until one of the service program's service procedures are actually called. Any loaded *SRVPGM objects remain in shared memory (i.e., not bound to only a single call level) as long as the job is active.
Further, once the operating system has loaded a *SRVPGM object into memory, calling any of its service procedures requires no more overhead than calling an internal subprocedure within your own program. Thus, from this standpoint, the use of service programs should not be considered a performance issue. Any other load-time performance considerations should be measured against the strategic advantage of having such easily shareable code.
Note that *SRVPGM 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 (for cross-service-program calls) do not agree, you end up with what is termed a signature violation.
This article is a stub. You can help by editing it.
