NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/bit/listserv/lvmctr/321

Text File | 1992-12-15 | 1.8 KB | 37 lines

Newsgroups: bit.listserv.l-vmctr
Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu!uwm.edu!psuvax1!uxa.ecn.bgu.edu!xmas
From: [e-mail] (Mark A. Stevens)
Subject: Re: Running A Merge/Purge
Message-ID: <[e-mail]>
Organization: Educational Computing Network
References: <[e-mail]>
Date: Tue, 15 Dec 1992 16:18:41 GMT
Lines: 26

In article <[e-mail]> Ron Wigmore <[e-mail]> 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:    [phone]
Systems Programmer                        Internet: [e-mail]
Educational Computing Network             BITNET:   [e-mail]
Board of Governors Universities           VMSHARE:  ECE/MARK