ADSM-L

Unlabeled Tape Causing Problems with ADSM Server

1997-05-30 17:04:17
Subject: Unlabeled Tape Causing Problems with ADSM Server
From: Linnea Nichols <lnicho AT DIT.CO.FAIRFAX.VA DOT US>
Date: Fri, 30 May 1997 16:04:17 EST
To: [email protected] <adsm-l AT vm.marist DOT edu>

FROM: Linnea T. Nichols                           (703)324-2708
    Systems Programming Mgr., NCS     LNICHO AT co.fairfax.va DOT us
    Fairfax County Department of Information Technology
Subject: Unlabeled Tape Causing Problems with ADSM Server
I put the following ETR out to IBM yesterday, but as of yet, they
haven't even opened it (must be really busy at level 2!!!!). Is anyone
on the list able to answer my two questions?

Abstract: Copy STGPOOL pblms w/ UNL tape
ADSM MVS Server at Version 2, Release 1, Level 0.12/0.12

While doing a "ba stg backtape drpool", ADSM added a tape that
came out of our CA1 (TMS) scratch pool to DRPOOL. When ADSM
tried to write to the tape, it kept getting a message that the
tape was UNL - I tried to CANCEL the PROCESS to get ADSM to
quit trying to use the bad tape, but it wouldn't cancel - I
finally tried to bring ADSM down with a HALT, but that wouldn't
work either. After 3 MVS CANCEL commands (which wouldn't bring
it down either), I finally did a CANCEL,FORCE which did bring
ADSM down.

(1) Are there any fixes to ADSM hanging like this?

ADSM did not mark the UNL tape as a damaged or bad tape -- it
appears that ADSM still thought it was fine, and every time
I tried another copy storagepool to DRPOOL it would try to mount
the bad tape and write on it. (I was able to cancel the process
a couple of times when it did this)

I did a "del vol 058935" and the response was that it still
had data on it

Doing a "q content 058935" showed that ADSM thought he had put
several files on the tape (which I don't understand how ANYTHING
could have gotten written to the tape since it was unlabeled,
and a FATS/FATAR showed it UNLABELED as well -- although CA1
thought it was a tape belonging to ADSM)

I tried a "move data 058935" which would not work because it
couldn't read the tape, and I had to cancel that process.

I ended up doing a "del vol 058935 discarddata=yes" to get rid
of tape from ADSM control.

(2) Have I lost the copies of the data that ADSM had on the tape??
Or when I did the discarddata=yes (since it was a COPYPOOL tape)
did ADSM mark the files so that they were recopied on a
subsequent backup storagepool command?? (I looked in the manual,
and it's really not clear in this situation, since my destroyed
tape was a COPYPOOL tape, and ADSM thought it was a good tape
and would not mark it as damaged or destroyed.)

Linnea Nichols                          lnicho AT co.fairfax.va DOT us
Fairfax Co. Govt., Fairfax, VA                     703-324-2708
***************************************************************
"Discontent is the first necessity of progress" - Thomas Edison
<Prev in Thread] Current Thread [Next in Thread>