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
|