Try running the audit library <lib name> checklabel=barcode to refresh the
library inventory in TSM from the library itself.
Check the help for the specifics associated with your library.
_____________________________
Ian Smith
SAN/TSM Specialist
IT Infrastructure
Rabobank International
Thames Court, One Queenhithe
London EC4V 3RL
t: +44 (0)20 7809 3046
f: +44 (0)20 7809 3599
m: +44 (0)7843 689914
Mailto: ian.smith AT rabobank DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Farren Minns
Sent: 27 March 2006 11:37
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Update - Tape problem after moving TSM to new server
Hi Ian
I only deleted and recreated the library, drives and paths, but I did not touch
the 3590 Device Class. Do I need to remove and recreate that too? If I do this,
how will it effect the tapepool & copypool that this device class specified?
I actually printed screen dumps of the drives etc before removing and
recreating to make sure that they were the same (apart from the /dev/rmt/????
entry of course). As far as I know, no special declarations of device class are
made during the addition of drives/libs/paths etc anyway.
I did not do a manual audit of the library? But i figured that as it could use
scratch tapes and audit volumes that were full or filling (readonly), things
were already OK. I could be wrong.
Thanks
Farren
|-----------------------------+-------------------------------------------|
| "Smith, I (Ian)" | |
| <Ian.Smith AT RABOBANK DOT COM> |
|
| Sent by: "ADSM: Dist Stor | To|
| Manager" | ADSM-L AT VM.MARIST DOT EDU
|
| <ADSM-L AT VM.MARIST DOT EDU> |
cc|
| | |
| 27/03/2006 11:00 | Subject|
| | Re: [ADSM-L] Update - |
| Please respond to | Tape problem after moving|
| "ADSM: Dist Stor | TSM to new server |
| Manager" | |
| <ADSM-L AT VM.MARIST DOT EDU> |
|
| | |
| | |
| | |
| | |
|-----------------------------+-------------------------------------------|
Did you make any changes to mountlimit or format on the device classes?
When you recreated the drives and paths after the migration did you bind them
to the correct device class/device type?
After the migration did you audit the library?
_____________________________
Ian Smith
SAN/TSM Specialist
IT Infrastructure
Rabobank International
Thames Court, One Queenhithe
London EC4V 3RL
t: +44 (0)20 7809 3046
f: +44 (0)20 7809 3599
m: +44 (0)7843 689914
Mailto: ian.smith AT rabobank DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Farren Minns
Sent: 27 March 2006 10:48
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Update - Tape problem after moving TSM to new server
Good morning Roger
Thank you so much for that information. Backing out wasn't a big problem for me
as the old server was still left as it was so all I had to do was connect the
drives and lib again and bring it back up (phew).
This is a very annoying problem though. Surely TSM should be able to see that
even though the /dev/rmt/???? entry has changed, it's still the exact same
device type and that it should still be able to write to the volume/s in
question. Is this something that is 'working as designed' or a bug/fault?
Also. It's odd that I could not even audit any of the filling volumes until I
changed the state to readonly. BUT, TSM could happily write to scratch tapes
that had been labelled on the old server.
I really don't know why this should be? I have certainly not seen this in any
documentation.
Thanks again
Farren
|-----------------------------+-------------------------------------------|
| Roger Deschner |
| |
| <rogerd AT UIC DOT EDU> |
| |
| Sent by: "ADSM: Dist Stor |
| To|
| Manager" | ADSM-L AT VM.MARIST DOT EDU
| |
| <ADSM-L AT VM.MARIST DOT EDU> |
| cc|
| |
| |
| 26/03/2006 18:54 |
| Subject|
| | Re: [ADSM-L] Update -
| |
| Please respond to | Tape problem after
| moving|
| "ADSM: Dist Stor | TSM to new server
| |
| Manager" |
| |
| <ADSM-L AT VM.MARIST DOT EDU> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|-----------------------------+-------------------------------------------|
This happened to me too, when doing a similar migration. I looked up my notes
from the time.
The problem is that your Filling tapes were started on a different drive type
than you have now, and so it won't append any more data onto them.
(Even if they are the very same drives, this can still happen.)
How to deal with it:
1. Get some extra tapes, to use while you do the following steps. Before you do
anything else after the big change, LABEL LIBVOL these new tapes so there will
be something for migration and DB backup to use.
2. Mark all your Filling and Full tapes Readonly. You will still be able to
restore from them OK. If you don't already have it, set a REUSEDELAY of a day
or two.
3. The Full tapes should reclaim themselves normally. However, reclamation will
not select any tape that is still marked as Filling, so you've got to reclaim
them manually yourself with MOVE DATA. Might take a while, which is OK as long
as you don't run out of tapes.
4. As tapes are cleared, whether they had been Filling (via MOVE DATA) or Full
(via reclamation), you may need to do CHECKOUT LIBVOL on them followed by a
LABEL LIBVOL OVERWRITE=YES before it will reuse them as scratch tapes.
When you get a mixture of Pending tapes from before and after the big change,
then you can easily tell which ones you need to relabel - they will be the ones
that are both Pending and Readonly.
When this happened to me, it was a hassle, but I found that it was a manageable
hassle. I did not have to do anything as drastic as the backout you did. Sorry
to hear about that - because you are having to do
3 times the work with a migrate-backout-migrate cycle.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
On Sat, 25 Mar 2006, Farren Minns wrote:
>OK, this is what I have now found out but had no idea what's going on.
>After completely removing and redefining the lib,drives and paths I
>still get the same errors as below. So, for example I can't audit
>volume 000700 without the error below.
>
>BUT..., if I change the state of the volume from read/write to
>readonly, I can. What's that all about? I can also audit volumes that
>have an access
of
>read/write but that are 'full' and not 'filling'. This is very strange.
Has
>anyone else ever seen this behaviour before ?
>
>Many thanks again
>
>Farren Minns
>
>
>>Hi All
>
>>I have just moved my TSM Server 5.1.6.2 from a Solaris 7 server to a
>>new
>Solaris 9 box. Now, everything so far has gone fine and I have tested
>a couple of >backups and also a backup of the database.
>
>>When I look at the contents of the tapepool, copypool, q libv etc I
>>see
>what I would expect.
>
>>BUT, when I try to run migration from disk to tape there is a problem.
>>In
>this example tape 000700 which is in a filling state is required but I
>see the following error :-
>
>>ANR1000I Migration process 4 started for storage pool BACKUPPOOL.
>>ANR8447E No drives are currently available in library 3494A.
>>ANR1401W Mount request denied for volume 000700 - mount failed.
>
>>Instead, TSM loads a new scratch tape and then continues fine. What is
>going on here? Has any body seen this before?
>
>>Thanks in advance
>
>>Farren Minns
>
>
>######################################################################
>The information contained in this e-mail and any subsequent
>correspondence is private and confidential and intended solely for the
>named recipient(s). If you are not a named recipient, you must not
>copy, distribute, or disseminate the information, open any attachment,
>or take any action in reliance on it. If you have received the e-mail
>in error, please notify the sender and delete the e-mail.
>
>Any views or opinions expressed in this e-mail are those of the
>individual sender, unless otherwise stated. Although this e-mail has
>been scanned for viruses you should rely on your own virus check, as
>the sender accepts no liability for any damage arising out of any bug
>or virus infection.
>######################################################################
>
######################################################################
The information contained in this e-mail and any subsequent correspondence is
private and confidential and intended solely for the named recipient(s). If
you are not a named recipient, you must not copy, distribute, or disseminate
the information, open any attachment, or take any action in reliance on it. If
you have received the e-mail in error, please notify the sender and delete the
e-mail.
Any views or opinions expressed in this e-mail are those of the individual
sender, unless otherwise stated. Although this e-mail has been scanned for
viruses you should rely on your own virus check, as the sender accepts no
liability for any damage arising out of any bug or virus infection.
######################################################################
_____________________________________________________________
This email (including any attachments to it) is confidential, legally
privileged, subject to copyright and is sent for the personal attention of the
intended recipient only. If you have received this email in error, please
advise us immediately and delete it. You are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited. Although we have taken reasonable
precautions to ensure no viruses are present in this email, we cannot accept
responsibility for any loss or damage arising from the viruses in this email or
attachments. We exclude any liability for the content of this email, or for the
consequences of any actions taken on the basis of the information provided in
this email or its attachments, unless that information is subsequently
confirmed in writing. If this email contains an offer, that should be
considered as an invitation to treat.
_____________________________________________________________
######################################################################
The information contained in this e-mail and any subsequent correspondence is
private and confidential and intended solely for the named recipient(s). If
you are not a named recipient, you must not copy, distribute, or disseminate
the information, open any attachment, or take any action in reliance on it. If
you have received the e-mail in error, please notify the sender and delete the
e-mail.
Any views or opinions expressed in this e-mail are those of the individual
sender, unless otherwise stated. Although this e-mail has been scanned for
viruses you should rely on your own virus check, as the sender accepts no
liability for any damage arising out of any bug or virus infection.
######################################################################
|
