If a PCL process is missing a DD statement and z/OS is set up to dynamically allocate datasets, Alchemist may not be able to deallocate the dataset properly at the end of the workunit. This can cause a subsequent workunit that is processing in a different PX task to fail with a DDNAME UNAVAILABLE message. The failing workunit may be in the same request or a completely different request.
The permanent solution is to add the required DD statement to PCL so that dynamic allocation is not necessary. Then Alchemist will manage the allocation and will be able to deallocate the files as required.
Here is a specific example with Abend-aid, but this situation could arise for any third-party product that requires a DDNAME not specified in the PCL being executed.
When calling the Abendaid precompiler through Alchemist some entities fail with the following messages:
ZDE1919I: 2/ALCABAID; PCL ERROR. TYPE 0919 DURING EXECUTION OF STEP ABENDAID
ZDE1000I: ERROR DESCRIPTION:
ZDE1000I: DDNAME(CWPERRM) SPECIFIED DDNAME IS UNAVAILABLE (0410 0000)
In this situation, recent changes to Abend-aid required use of a new DD CWPERRM. z/OS had the option to allocate missing DDs turned on, so this client's system dynamically allocated the data set to the PX task where the workunit was executing. Because of the dynamic allocation was not done by Alchemist, Alchemist was unable to deallocate the dataset when the original request finished. The reported error occurred when a subsequent request requires the same DD in another PX task.
The allocated DDNAME can been seen if you use the ? option in SDSF or SYSVIEW for the PX started task.
Once the error has occurred, the only way to free the allocated DD is to recycle the PX engine where the DD is allocated.