Browse Prior Art Database

Support multiple AMODE (31 and 64) callers in a single module.

IP.com Disclosure Number: IPCOM000014098D
Original Publication Date: 2000-Apr-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 4 page(s) / 48K

Publishing Venue

IBM

Abstract

Disclosed is a parameter pre-processor that allows callers of different AMODE (e.g. 31 and 64-bit addressing) to call a single module. This pre-processor makes every caller appear to be of the same AMODE and same KEY as the called module.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 4

Support multiple AMODE (31 and 64) callers in a single module.

Disclosed is a parameter pre-processor that allows callers of different AMODE (e.g. 31 and 64-bit addressing) to call a single module. This pre-processor makes every caller appear to be of the same AMODE and same KEY as the called module.

Background:

In the OS/390 operating system, unauthorized applications call system services, which process the caller's parameters while running in an authorized state. In order to maintain the integrity of the system, these authorized services first copy the caller's parameters into protected storage, so that they can be used without interference from the application. After the parameters are copied, they are validated and then used.

Different approaches are employed to copy the caller's parameters by different services. Some services simply copy the parameters one by one. Other services employ a structured means of copying the parameters. The OS/390 UNIX kernel employs a macro called BPXXPARM to copy parameters. BPXXPARM currently generates 2 blocks of code (RSECTS).

Copy input parameters for an AMODE 31 caller

Copy output parameters for an AMODE 31 caller


1.


2.

On entry to a service, the service routine invokes the block of code to copy the input parameters. On exit from the service, the service routine invokes the block of code to copy the output parameters. In the current support, both the application and the service are always running AMODE 31.

Supporting AMODE 31 and 64 callers in the same service routine:

As discussed earlier, there are multiple ways for a service routine to copy parameters. With the introduction of AMODE 64, the logic to copy the caller's parameters for both AMODE 31 and AMODE 64 callers, has grown. The service routine which processed each parameter individually, must add the following logic for each parameter processed:

If caller was AMODE 31 then

    Copy parameter in AMODE 31 Else caller was AMODE 64

    Switch to AMODE 64 Copy parameter in AMODE 64 Switch back to AMODE 31 Repeat above for each parameter.

This sort of logic must be repeated for each input and output parameter. This extra code can introduce errors as well as extra path length

The BPXXPARM approach is to now generate 4 blocks of code:

1

Page 2 of 4


1.


2.


3.


4.

On input to the service routine, the following logic is employed:

If caller was AMODE 31 then

    Invoke block of code to copy all input parameters in AMODE 31 Else caller was AMODE 64

Switch to AMODE 64 Invoke block of code to copy all input parameters in AMODE 64 Switch back to AMODE 31

On output, similar logic is employed. The assumption here is that the service will run in AMODE 31 and only run in AMODE 64 while touching user data. With this methodology, the coding of the BPXXPARM macro provides a consistent way for the service developer to define the input and output parameters. The macro takes care of generating the most efficient code to handle the copying of the parameters. The test of the...