🚀 go-pugleaf

In article <921215.081533.EST.SYST8103@RyeVm.Ryerson.Ca> Ron Wigmore <SYST8103@RYEVM.RYERSON.CA> writes:
>...
>Some tapes are 'bad' because of incorrect dataset counts, etc., but most
>simply get I/O errors when VMBACKUP trys to read the tape.  I know what
>some of the volsers are, but there are probably many others among the
>700 tapes that will be Merge/Purged.

If you *KNOW* they are bad, do you have twins so you can mark the bad
ones in the VMARCHIVE database?

>Does anyone have any tips on how to minimize the length of time it will
>take to do the Merge/Purge?  Given that when VMAMPU hits a bad tape, the
>run will abend, will using the "FORCE" option enable the rest of the tape(s)
>to be processed or are all of the files after that tape be lost?

VMBACKUP has a tape scanning utility that looks at the tapes and builds a
report of what it finds (I've forgotten the name of it of course.)  You
could use it to scan all tapes to identify the bad ones (tape errors) and
the reports would help with identifying those which are missing DSS's
when compared with VMARCHIVE's report on DSS's and volsers (again I
forgot the name, lot of good I am.)  
-- 
Mark A. Stevens                           Phone:    708-534-0200
Systems Programmer                        Internet: xmas@uxa.ecn.bgu.edu
Educational Computing Network             BITNET:   XMAS@ECNUXA.BITNET
Board of Governors Universities           VMSHARE:  ECE/MARK