Ahh, OK.
Q VOL does NOT show tapes that are used for DB Backups (or Backup Sets) -
so DONT rely on Q VOL telling you every volume that TSM is using.
Q VOL will tell you what tapes are being used by TSM to store Backups and
Archives (by the BA client and the API client). It will also tell you what
tapes are being used by Virtual Volumes (Backups from other TSM servers,
that are storing data on the server in question).
My statement about re-labeling still applies - if a tape is in use by TSM
for backup, archive, backupset, dbbackup, etc... tsm will NOT let you
relabel it - it knows it is in use, and you must empty the tape (by the
appropriate means) before you can relabel it.
...deon
---
Have you looked at the A/NZ Tivoli User Group website?
http://www.tuganz.org
Deon George, IBM Tivoli Software Engineer, IBM Australia
Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816,
IVPN +70 66058
mailto:dgeorge AT au1.ibm DOT com, http://www.ibm.com/tivoli
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 24/10/2003
05:14:13 PM:
> Hi Deon,
>
> Q vol gpc027 f=d gives me nothing, however if i do q volhist type=dbb
> then it shows
>
> Date/Time: 10/21/2003 09:45:43
> Volume Type: BACKUPFULL
> Backup Series: 214
> Backup Operation: 0
> Volume Seq: 1
> Device Class: LTOCLASS
> Volume Name: GPC027
> Volume Location:
> Command:
>
>
>
> Regards
>
> Dat
>
>
> -----Original Message-----
> From: Deon George [mailto:dgeorge AT AU1.IBM DOT COM]
> Sent: Friday, 24 October 2003 3:32 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: tape status
>
>
> Dat,
>
> No, TSM will NEVER let you (re)label a tape, if the tape is already
known
> to the current TSM server (ie: it is defined in Q VOLHIST or Q VOL).
> If you try, in your activity log you'll see a label libv failure and the
> reason why (and the existing label)...
>
> If the tape was previously defined (you saw it in Q VOL), and now you
cant
> see it in Q VOL, then it is one of two things:
>
> * It was a SCRATCH volume, that became empty and TSM deleted it.
> * It was not a scratch volume, but a defined volume (DEF VOL command)
and
> somebody deleted it.
>
> (You will know if volumes are scratch when you do a Q VOL F=D and look
at
> the "Scratch:" line.
>
> ...deon
> ---
> Have you looked at the A/NZ Tivoli User Group website?
> http://www.tuganz.org
>
> Deon George, IBM Tivoli Software Engineer, IBM Australia
> Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366 816,
> IVPN +70 66058
> mailto:dgeorge AT au1.ibm DOT com, http://www.ibm.com/tivoli
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 24/10/2003
> 02:10:47 PM:
>
> > Deon,
> >
> > Sorry if i was a bit vague, the question i am asking is does relable
> destroy
> > existing known tsm tapes or does tsm smart enough to know and prevent
> you
> > from doing it.
> > Secondly the tape was already define to tsm previous, why now does it
> give
> > me this error (we havent use it elsewhere)
> >
> > > ANR2034E QUERY VOLUME: No match found using this criteria.
> > > ANS8001I Return code 11
> >
> >
> > I've also tried q libvol , but the tape isnt there either.
> >
> >
> > Regards
> >
> > Dat
> >
> >
> > -----Original Message-----
> > From: Deon George [mailto:dgeorge AT AU1.IBM DOT COM]
> > Sent: Friday, 24 October 2003 1:36 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: tape status
> >
> >
> > Dat,
> >
> > Q VOL will only show SCRATCH tapes that have data on them, or DEFINED
> > tapes (when you use the define vol command), or sometimes (as you've
> > captured below), you will also see SCRATCH tapes that are EMPTY - this
> > will be because:
> >
> > * They recently became empty and TSM hasnt yet deleted them (returning
> > them to the "scratch pool") - very rare,
> > * They are empty and offsite (as your example is below),
> >
> > (Offsite SCRATCH volumes that are empty, remain in Q VOL so that you
can
> > bring them back onsite - as soon as you mark them as onsite, they will
> be
> > deleted from Q VOL).
> >
> > Now, if your tapes are empty and in your library and you CANT see them
> > with q VOL, then you will be able to see the with Q LIBV.
> >
> > If you do a HELP UPDATE VOL - it'll tell you when TSM will delete
> SCRATCH
> > volumes from Q VOL.
> >
> > To answer your question, do you need to relabel them - no. (You would
> only
> > need to relabel tapes if they were used by something outside of TSM -
> > which overwrote the TSM label.)
> >
> > ...deon
> > ---
> > Have you looked at the A/NZ Tivoli User Group website?
> > http://www.tuganz.org
> >
> > Deon George, IBM Tivoli Software Engineer, IBM Australia
> > Office: +61 3 9626 6058, Fax: +61 3 9626 6622, Mobile: +61 412 366
816,
> > IVPN +70 66058
> > mailto:dgeorge AT au1.ibm DOT com, http://www.ibm.com/tivoli
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 24/10/2003
> > 10:34:24 AM:
> >
> > > Hi,
> > >
> > > I got LTO tapes that that was labelled into a 3583 library some
months
> > back,
> > > now when i do a query volume, ie
> > >
> > > q vol gpc027 f=d
> > >
> > > I get a message:
> > >
> > > ANR2034E QUERY VOLUME: No match found using this criteria.
> > > ANS8001I Return code 11.
> > >
> > >
> > > If the tape has expired as tape as part of the system policy,
wouldnt
> i
> > get
> > > a message like below, eg Volume Status: Empty:
> > >
> > > Volume Name: GPC093
> > > Storage Pool Name: COPYSAP_LOG1
> > > Device Class Name: LTOCLASS
> > > Estimated Capacity (MB): 0.0
> > > Pct Util: 0.0
> > > Volume Status: Empty
> > > Access: Offsite
> > > Pct. Reclaimable Space: 0.0
> > > Scratch Volume?: Yes
> > > In Error State?: No
> > > Number of Writable Sides: 1
> > > Number of Times Mounted: 3
> > > Write Pass Number: 1
> > > Approx. Date Last Written: 08/04/2003 03:33:02
> > > Approx. Date Last Read: 08/02/2003 15:04:23
> > > Date Became Pending:
> > > Number of Write Errors: 0
> > > Number of Read Errors: 0
> > > Volume Location:
> > > Last Update by (administrator): SCRIPT
> > > Last Update Date/Time: 08/04/2003 11:31:55
> > >
> > >
> > >
> > > Can someone confirm if at this stage i will need to to relabel the
> tape
> > into
> > > the library.
> > >
> > > Thank you
> > >
> > > Dat Vo
> > > System Administrator
> > >
> > > #################################################
> > >
> > >
> > > ***** CONFIDENTIAL *****
> > >
> > > We apologise if this message has been sent to you in error. We are
> > > committed to protecting the confidential information of our
> > > customers, our vendors and GPC Electronics. If you have received
> > > this message in error, we would appreciate you removing it from your
> > > system and informing us of the error, so that we may continue to
> > > improve our processes.
> > >
> > > Please note that whilst we check our outgoing mail, you should also
> > > check any attachments for viruses and defects before opening them or
> > > sending them on.
> > >
> > >
> > > Thank you.
> > >
> > >
> > > #################################################
> >
> > Scanned by PeNiCillin http://safe-t-net.pnc.com.au/
> > #################################################
> >
> >
> > ***** CONFIDENTIAL *****
> >
> > We apologise if this message has been sent to you in error. We are
> > committed to protecting the confidential information of our
> > customers, our vendors and GPC Electronics. If you have received
> > this message in error, we would appreciate you removing it from your
> > system and informing us of the error, so that we may continue to
> > improve our processes.
> >
> > Please note that whilst we check our outgoing mail, you should also
> > check any attachments for viruses and defects before opening them or
> > sending them on.
> >
> >
> > Thank you.
> >
> >
> > #################################################
>
> Scanned by PeNiCillin http://safe-t-net.pnc.com.au/
> #################################################
>
>
> ***** CONFIDENTIAL *****
>
> We apologise if this message has been sent to you in error. We are
> committed to protecting the confidential information of our
> customers, our vendors and GPC Electronics. If you have received
> this message in error, we would appreciate you removing it from your
> system and informing us of the error, so that we may continue to
> improve our processes.
>
> Please note that whilst we check our outgoing mail, you should also
> check any attachments for viruses and defects before opening them or
> sending them on.
>
>
> Thank you.
>
>
> #################################################
|
