Rational Developer for System z
Enterprise PL/I for z/OS, Version 3.8, Programming Guide

Fetching Enterprise PL/I routines

Almost all the restrictions imposed by the older PL/I compilers on fetched modules have been removed. So a FETCHed module can now:

There are, however, a few restrictions on a Enterprise PL/I module that is to be fetched. These restrictions are:

  1. OPTIONS(FETCHABLE) must be specified on the PROCEDURE statement of the routine that provides the entry point into the module to be fetched - or the DLLINIT compiler option must be used to apply OPTIONS(FETCHABLE) to that procedure.
  2. The ENTRY card should specify the name of that PL/I entry point
  3. If the RENT compiler option was used to compile any of the fetched code, then the module must be linked as a DLL.
  4. If the NORENT compiler option was used to compile the fetching code, then any fetched module must consist only of NORENT code.
  5. If the RENT compiler option was used to compile the fetching code, then the ENTRY that is fetched must not be declared in the fetching module as OPTIONS(COBOL) or OPTIONS(ASM). If you want to avoid passing descriptors in this situation, you should specify the OPTIONS(NODESCRIPTOR) attribute on the ENTRY declare.

NORENT WRITABLE code is serially usable, and for that reason, the pointer that is used to represent a FFETCHABLE constant is zeroed out in the prologue code of any NORENT WRITABLE routine. While this insures that the code is serially reusable while also providing the correct PL/I semantics, it does impose a restriction on the use of FETCH with TITLE in NORENT WRITABLE code: if a routine that did a FETCH A TITLE('B') is exited and reentered, then it must re-execute the FETCH A TITLE('B'), before executing any CALL A statements (otherwise it would do an implicit FETCH of A (but without any TITLE) before making the CALL).

As an illustration of these restrictions, consider the compiler user exit. If you specify the EXIT compile-time option, the compiler will fetch and call a Enterprise PL/I module named IBMUEXIT.

First note that the compiler user exit must be compiled with the RENT option since the compiler expects it to be a DLL.

In accordance with Item 1 above, the PROCEDURE statement for this routine looks like:

ibmuexit:
  proc ( addr_Userexit_Interface_Block,
         addr_Request_Area )
  options( fetchable  );

  dcl addr_Userexit_Interface_Block  pointer byvalue;

  dcl addr_Request_Area              pointer byvalue;

In accordance with Item 3 above, the linker option DYNAM=DLL must be specified when linking the user exit into a DLL. The DLL must be linked either into a PDSE or into a temporary dataset (in which case DSNTYPE=LIBRARY must be specified on the SYSLMOD DD statement).

All the JCL to compile, link, and invoke the user exit is given in the JCL below in Figure 16. The one significant difference between the sample below and the code excerpts above is that, in the code below, the fetched user exit does not receive two BYVALUE pointers to structures, but instead it receives the two structures BYADDR. In order to make this change work, the code specifies OPTIONS(NODESCRIPTOR) on each of its PROCEDURE statements.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)