Rules for Binding to Service Programs
Rules for Binding to Service Programs
Rules for Binding to Service Programs
The following table shows the rules for binding programs to target service programs.
| Service program binding rules: Can the calling program or service program bind to a target service program? | Target service program storage model | |||
|---|---|---|---|---|
| Teraspace | Inherit | Single-level storage | ||
| Storage model of the calling program or service program | Teraspace | Yes | Yes | Yes1 |
| Inherit1 | Yes2 | Yes | Yes2 | |
| Single-level storage | Yes1 | Yes | Yes |
Note:
- The target service program must run in a distinct activation group. For example, the target service program cannot have the ACTGRP(*CALLER) attribute. It is not possible to mix storage models within a single activation group.
- If the calling program or service program uses the inherit storage model and the target service program uses single-level storage or the teraspace storage model, then you must ensure that the activation group that the target service program is activated into has the same storage model as the target service program. Here is an example: service program A is created with the inherit storage model. Service program B is created with teraspace storage model and has the *CALLER activation group attribute. Service program A is bound to service program B. In this case, service program A should always activate into an activation group with the teraspace storage model.