ADSM-L

Re: problem with 3494 library after TSM upgrade from 3.7.4 to 4. .2.1.7

2002-01-21 12:37:26
Subject: Re: problem with 3494 library after TSM upgrade from 3.7.4 to 4. .2.1.7
From: Dennis Glover <dglover1 AT BELLSOUTH DOT NET>
Date: Mon, 21 Jan 2002 11:17:10 -0600
Hello,

We had some problems after upgrading to TSM 4.2.1.7
and subsequently TSM 4.2.1.9, and although the problems
were 3not precisely the same as yours, I might offer some insight.

Our problem turned out to be that TSM 4.2.x.y could not
append to tapes which had originally been written by ADSM
3.1.2.90 running on Solaris 7 on a Sun UE450.  We also have
3590-E1A drives in our library.  These tapes, which were marked
with a status of "FILLING", had to be updated to "ACCESS" of
"READONLY" so that the server would refuse to attempt to
append to them.  There were 73 volumes that fit this description.
After marking them "READONLY", we had to perform a "MOVE
DATA" operation on each of them; we could have moved them to
any available sequential access storage pool's scratch volumes
but chose to keep them within the same storage pool.  You should
choose the time to do this wisely, should you decide to try it, as
you cannot perform restore/retrieve operations while these processes
are running.  There is also an option to RECONSTRUCT, which,
according to the Administrator's Guide, "Specifies whether to reconstruct
file aggregates during data movement. Reconstruction removes empty
space that has accumulated during deletion of logical files from an
aggregate."  I would suggest you choose this option, as it will ensure
a more efficient "new tape" usage.  A recommended command would
be:
MOVE DATA READONLYVOLUME STGPOOLNAME RECONSTRUCT=
YES WAIT=YES

I chose "WAIT=YES" because this forces the process to the foreground,
presumably allowing it to run faster.  If you have other needs, you can
always run it in the background with "WAIT=NO".

Note that, as each volume's data is moved to a "new" tape, the
original volume is returned to the scratch tape pool and the READONLY
attribute becomes irrelevant, as the scratch volume should be marked
READWRITE if it is returned to the storage pool.

This might not be the answer to your problem, but you could try it,
probably without any ill effect.

I hope this helps,

Dennis Glover
<Prev in Thread] Current Thread [Next in Thread>