The reentrant interface

GDDM-GKS V1R1 Programming Guide and Reference

The reentrant interface

GDDM-GKS V1R1 Programming Guide and Reference
SC33-0334-00

Application programs requiring reentrancy can use another form:


        CALL ffffff (AAB, parameter, ... )

where ffffff and the parameters are as described for the nonreentrant interface, and AAB (application anchor block) is an application-provided, word-aligned control block of the following format:

Offset Length Name Description

0 8 AAB Application anchor block 0 4 AABFC GDDM feedback code 0 2 AABSC GDDM severity code 2 2 AABEC GDDM error code 4 4 AABAP GDDM anchor pointer

When using this interface, the application program must provide the storage for the AAB (at least 8 bytes for GDDM's use). The program is free to extend the AAB for other uses (typically, to provide for passing information to an application-defined error-handling procedure).

The GDDM anchor pointer (AABAP) is set by the GDDM application interface component at initialization, and identifies the GDDM instance being addressed. It is reset to zero on termination. This pointer is used by GDDM to retain storage across activations.

The severity code (AABSC) is set to the error severity code on return to the application:

0

Normal

4

Warning

8

Error

12

Severe error

16

Unrecoverable errors.

The error code (AABEC) is the related GDDM-GKS error message number; this is not the same as the GKS error number.

Reentrancy of the GDDM invocation is determined by the reentrant properties of the AAB. If the AAB is in reentrant storage, GDDM is reentrant.

If the application program is modular, and reentrant use of GDDM from several modules is required, each such module must have access to the AAB. For example, the program can pass the AAB as a parameter across its module calls. If an application-defined error-handling procedure is used, this procedure must accept the AAB as the first parameter.

Notices | Terms of use | Support | Contact z/OS