tol
Newcomer
hi,
i am encountering problems with old .BFS. which do not expire from a copy storage pool.
this results in ANR1221E "Process process id terminated - insufficient
space in target copy storage pool." for BACKUP STGPOOL.
Q STGPOOL <VIRTUALPOOL> says the storage pool is 99.7 percent utilized.
i have decreased the reclamation threshold from 100 to 85 percent which had NO effect at all. TSM started a space reclamation and finished it - apparently without reclaiming anything.
the maximum no. of scratch tapes for the copy pool is set to 2,000 and increasing that number is not a solution for me.
i have run EXPIRE INVENTORY now manually and a SELECT COUNT(*) FROM ADSM.VOLUMES WHERE STGPOOL_NAME='<VIRTUALPOOL>' now says 1,997 instead of 2,000 - wow. the storage pool still remains 99.7 percent utilized.
a Q VOL STGP=<VIRTUALPOOL> F=D says for any of the BFS volumes:
"Pct Util = 100", "Scratch Volume? = Yes", "Volume Status = FULL", "Access = Read/Write".
then i did some selects with the following results:
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' and scratch='Yes' results in 1,997
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' and status='FULL' also results in 1,997
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' results in 1,997 anyway.
meanwhile i gave RECONCILE VOLUMES <DEVCLASS_VIRTVOL> a try. according to the output it gave it must have deleted a lot of old BFSs but i have still 1,997 volumes in my copy storage pool.
(The TSM release is 5.1.5.4 on AIX w/3494 Libraries attached via SCSI.)
----> What the ---- is going on there?
----> Why do these BFS Files stay there forever (as it seems) ???
----> Can I manually delete those files or is it safe to delete and re-create the whole copy storage pool since the volumes in it are virtual volumes (server-to-server connection) anyway...?
Thanks for your help.
i am encountering problems with old .BFS. which do not expire from a copy storage pool.
this results in ANR1221E "Process process id terminated - insufficient
space in target copy storage pool." for BACKUP STGPOOL.
Q STGPOOL <VIRTUALPOOL> says the storage pool is 99.7 percent utilized.
i have decreased the reclamation threshold from 100 to 85 percent which had NO effect at all. TSM started a space reclamation and finished it - apparently without reclaiming anything.
the maximum no. of scratch tapes for the copy pool is set to 2,000 and increasing that number is not a solution for me.
i have run EXPIRE INVENTORY now manually and a SELECT COUNT(*) FROM ADSM.VOLUMES WHERE STGPOOL_NAME='<VIRTUALPOOL>' now says 1,997 instead of 2,000 - wow. the storage pool still remains 99.7 percent utilized.
a Q VOL STGP=<VIRTUALPOOL> F=D says for any of the BFS volumes:
"Pct Util = 100", "Scratch Volume? = Yes", "Volume Status = FULL", "Access = Read/Write".
then i did some selects with the following results:
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' and scratch='Yes' results in 1,997
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' and status='FULL' also results in 1,997
select count(*) from volumes where stgpool_name='<VIRTUALPOOL>' results in 1,997 anyway.
meanwhile i gave RECONCILE VOLUMES <DEVCLASS_VIRTVOL> a try. according to the output it gave it must have deleted a lot of old BFSs but i have still 1,997 volumes in my copy storage pool.
(The TSM release is 5.1.5.4 on AIX w/3494 Libraries attached via SCSI.)
----> What the ---- is going on there?
----> Why do these BFS Files stay there forever (as it seems) ???
----> Can I manually delete those files or is it safe to delete and re-create the whole copy storage pool since the volumes in it are virtual volumes (server-to-server connection) anyway...?
Thanks for your help.
