Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Examples of how to establish a cross memory environment z/OS MVS Programming: Extended Addressability Guide SA23-1394-00 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This topic contains examples that show three ways to establish
services that a user can access by issuing a PC instruction. The tasks
that the service provider must perform are grouped into the following
categories:
Example 1 - Making services available to selected address spaces shows how a service provider can supply services to users in selected address spaces. (The example shows only one user, but the extra steps for adding users are pointed out.) Example 2 - Making services available to all address spaces shows how a service provider can make services available to users in all address spaces. Example 3 - Providing non-space switch services explains how a service provider can provide non-space switch services. For each example, assume that the service provider has obtained common storage that the user can access through name/token callable services. The service provider could use the area pointed to by the token returned by name/token callable services to store the PC numbers corresponding to its services. It could also store some of the lists it needs to invoke PC/AUTH services, and the lists that must be available to different address spaces. Assume also that SERVBLK, shown in Table 1, describes the common storage area. All examples use the declared storage areas shown in Table 1. For information on using name/token callable services, see z/OS MVS Programming: Authorized Assembler Services Guide.
|
Copyright IBM Corporation 1990, 2014
|