Because we use FILE as device for ADSM we run into the following problem:
We let ADSM create DASD-files which are archived by our DASD management system 
at the end of the night. These datasets are managed like SMS tape mount 
management datasets, so the are allocated on disk, filled and an immediate 
space release is done after the dataset is retained. On the same day the 
dataset is archived to level 2 archive (tape).
Because the volume status is 'filling' for ADSM, it wants to remount the volume 
to fill it. So this causes a (unwanted) recall and when ADSM tries to write 
data at the end of the file it runs into a D37 abend (of course, because the 
idle space has been released by SMS).
To prevent this, we issue an UPDATE VOLUME * WHERESTATUS=FILLING 
WHERESTATUS=FILLING ACCESS=READONLY just before the backup window starts. 
However, this is a scheduled command and datasets created by the reclamation 
process afterwards still have the FILLING status. So when these datasets are 
used during a backup cycle a D37 abend is caused.
We would like to see an option to prevent ADSM from using earlier created 
volumes. So we would like ADSM to use scratch volumes (datasets)  for every new 
backup or reclamation process.
Is there already a requirement for this?
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines