VIO cannot map two different ddnames to the same data set when that data set is VIO allocated. This double mapping is the method PCL uses to implement the passed data set facility. So you should not use VIO for data sets that are passed from one PCL step to another (using the DISP=(,PASS) parameter) or data sets that are passed between Alchemist and PCL, most notably &&SOURCE.
To prevent problems, the esoteric unit names used in the UNIT parameter for passed data sets and the unit name specified in the Alchemist workunit system-configuration parameter must not be VIO eligible.
In addition, to switch off VIO for Alchemist programs, you can add in a new VIO bypass command within SMS to exclude the following V3 programs:
If you find that allocation to VIO is still being attempted, it's possible that you may need additional coding within an ACS routine to specify a storage class or group based upon your site's temproary data set name (DSN) format. For temporary datasets identified as belonging to Alchemist, force the storage class (or group) to one that is non-VIO ineligible.
Another option, although less desirable, is to edit the PCL where the PCL creates the temporary data sets, and increase the space allocation to greater than 15 tracks in size. Many shops force any temporary, passed data set that has a size of less than 15 tracks to be defined to VIO. By increasing the size, it forces the data set to bypass VIO but then larger files are being created than may be required.
This Frequently Asked Question applies to all supported releases of ESP Alchemist beginning with 3.3.2.