HSM should correctly calculate tape utilization by taking zEDC compression into account.

As more customers are expected to adopt zEDC compression in the future, HSM should evolve to handle it appropriately.
The following two are examples of defects.

1. Unnecessary RECYCLE triggered by a miscalculation of the PCT VALID value caused by zEDC compression.

Datasets compressed with zEDC cannot be further compressed by VTS. Since the size of the dataset on VTS is almost the same as its size on disk, when the REUSE CAPACITY value is four times the actual tape volume capacity, even if the tape is physically 100% used, the PCT VALID will be 25%. If the RECYCLE threshold is set to 25%, the tape in this state will be subject to RECYCLE. Whether immediately after MIGRATE or RECYCLE, the tape will be targeted for RECYCLE, and this process will repeat.

In one of our environments, the number of RECYCLE operations increased from approximately 1,000 volumes per day to 8,000 volumes, then decreased to 2,000 volumes per day after three months.
In another environment, the number of RECYCLE operations rose from around 100 volumes per day to 1,800 volumes, and this elevated level has persisted.

Because tapes are being recycled even when the number of stored datasets has not decreased, the number of datasets being moved increases. As the number of ARC messages output also increases, the time until the HSM address space encounters a 722 abend becomes shorter.

2. zEDC compression triggers the occurrence of unexpected spans.

When migrating a 128MB dataset, HSM assumes a compression ratio of 1:2.5 and estimates the size on tape to be 51.2MB. If there is 60MB of free space on the tape, it is expected to fit on the existing tape.
However, in reality, since VTS cannot compress the data, the full 128MB does not fit in the available space and ends up spanning to the next tape. (Unexpected span)
This phenomenon occurred with approximately a 10% probability in our environment.