GDDM V3R2 Base Application Programming Reference
Previous topic | Next topic | Contents | Index | Contact z/OS | Library | PDF | BOOK


The reentrant interface

GDDM V3R2 Base Application Programming Reference
SC33-0868-02
Application programs requiring reentrancy can use another form of the CALL statement: 



     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 this 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 application anchor block (at least 8 bytes for the use of GDDM). The program is free to extend the application anchor block for other uses (typically, to provide for passing information to an error exit routine).
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 helps GDDM's reentrancy, and is used by GDDM to retain storage across activations.
The severity code (AABSC) is set to the error severity code (see above) on return to the application, and the error code (AABEC) identifies the particular response. As for the nonreentrant interface, more error information can be obtained by using the FSQERR and FSEXIT calls.
Reentrancy of the GDDM invocation is determined by the reentrant properties of the application anchor block. If the application anchor block is in reentrant storage, GDDM is reentrant. If the application anchor block is in quasi-reentrant storage, GDDM is quasi-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 application anchor block. For example, the program can pass the application anchor block as a parameter across its module calls. Alternatively, under a subsystem such as CICS, quasi-reentrancy can be achieved by locating the application anchor block in the application program's transaction work area (TWA).

Go to the previous page Go to the next page
Notices | Terms of use | Support | Contact z/OS



Copyright IBM Corporation 1990, 2012