When FASTCOPY loads a new PDSE, it is allocated in multiple extents, unless the file is a NON-SMS file without RLSE coded. This issue even occurs with CONTIG coded.
The same allocation parameters when used with IBM's IEBCOPY creates a PDSE in a single extent.
FastCopy processing may cause a new PDSE to use multiple extents under the following conditions:
Before the COPY (or MOVE) operation, FastCopy does an OPEN for Output followed by a CLOSE to force the VTOC to be updated with DCB information.
This CLOSE causes space to be released before the COPY operation which means the new PDSE may start with a small primary allocation and require secondary extents.
There are a couple of circumventions: