Programming considerations for using the DYNALLOC macro

Before deciding to use any of the dynamic allocation functions, consider the environment of the program that invokes the DYNALLOC macro. Your program interacts with the job entry subsystem, with data management functions, and with system components that control the jobs, in addition to dynamic allocation itself.

The following list contains more specific programming considerations for using the DYNALLOC macro. Other considerations are included with the topics to which they apply.

Serialization of Resources
Your program might serialize the same resources as DYNALLOC. Dynamic allocation can serialize the following resources, depending on the path taken in processing.
Major Name

Minor Name

SYSDSN

data set name

SYSIEFSD

CHNGDEVS

SYSIEFSD

DDRDA

SYSIEFSD

DDRTPUR

SYSIEFSD

Q4

SYSZOPEN

data set name

SYSZPCCB

PCCB

SYSZTIOT

address of the DSAB QDB.asid

SYSZVMV

ucbaddr

SYSZVOLS

volume serial number
Other system routines and dynamic allocation
System routines invoked by various paths of dynamic allocation processing also might serialize a system resource. Some of the system functions invoked by dynamic allocation processing are LOCATE, OBTAIN, CATALOG, SCRATCH, and DADSM Allocate.

For the same reason, installation exits for OPEN/CLOSE/EOV, or for any other routines that enqueue on SYSZTIOT, should not issue dynamic allocation requests.
AMODE and RMODE considerations
There are no AMODE or RMODE restrictions for the caller of DYNALLOC. However, all addresses in the parameter list must be in 31-bit addressing mode format. 24-bit addresses must be 4 bytes long, with the high-order byte set to zero.
Avoiding 05C abends
NOT Programming Interface information Note:
Programs that issue DYNALLOC should not receive control during START (initialization) processing for LOGONs, MOUNTs, or started tasks.

Programs that get control during START processing (installation exits, for example) should not issue LOCATE, OPEN, OBTAIN, CATALOG, SCRATCH, or DADSM Allocate for data sets that have not been preallocated to the program; to do so will cause an 05C abend.
End of NOT Programming Interface information

Subsystems that receive control during step allocation as a result of the JCL SUBSYS parameter should not issue DYNALLOC; to do so might cause an 05C abend.
Changes to the TIOT
Dynamic allocation might cause changes to the task input/output table (TIOT). Depending on the function requested through the DYNALLOC macro, an entry could be added, deleted, or reordered; you cannot assume a fixed order for TIOT entries.

You should make sure your program can handle changes to the TIOT. This is especially important when the EXTRACT macro is being used in your program, or in the program that will gain control when dynamic allocation processing is finished,

If you need to reference TIOT entries after DYNALLOC is invoked, use the GETDSAB macro.
NOT Programming Interface information
NOT Programming Interface information Accessing ICF CATALOGS
Programs that get control during ‘START’ (installation exits, for example) should not issue LOCATE, OPEN, OBTAIN, CATALOG, SCRATCH, or DADSM allocate for data sets that have not been preallocated to the program; to do so could cause the system to issue message IEC331I with return code X'4' and reason code X'84'.
End of NOT Programming Interface information
End of NOT Programming Interface information