Re: 5.3.2.2 volume question

2006-02-16 Thread Bill Kelly
This sounds like APAR IC47950.  If so, then until a fix is available,
you can just update the volumes in question to scratch status via 'upd
libv'.

Regards,
Bill

Bill Kelly
Auburn University OIT
334-844-9917

>>> [EMAIL PROTECTED] 02/16/06 7:52 AM >>>
I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I
have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5
frames 60 drives.  tsm1 is the library manager. We have been noticing
lately that when we run a report to show private, scratches, dbb vols,
we have a column of private tapes that increases everyday that are
really supposed to be scratch tapes. What I have found is, when
reclamation runs on tsm2 for primary tape pools, it marks the tape as
deleted and ready for scratch like it should, but on tsm1, it still
shows the tape as private, if you "q  vol" on either tsm server, they
know nothing about the tape, but again "q libvol" shows the tape as
private like below:

TSMLIB1  T01779  PrivateTSMCORP1
1,054   LTO

I can check the tape out and recheck it in as scratch and it will be
used as scratch from there out. I went back and checked our reports,
and
before the upgrade, we had 3-5 tapes in the status, now we have 140,
If
I look at the daily reports each day, it grows each day from the day
we
did the upgrade. So, has anybody else seen this with 5.3.2.2 or any
other ideas on what might be causing this.


This email and any files transmitted with it are confidential and
intended solely for the use of the addressee. If you are not the
intended addressee, then you have received this email in error and any
use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited. Please notify us immediately of your unintended
receipt by reply and then delete this email and your reply. Tyson Foods,
Inc. and its subsidiaries and affiliates will not be held liable to any
person resulting from the unintended or unauthorized use of any
information contained in this email or as a result of any additions or
deletions of information originally contained in this email.


Re: 5.3.2.2 volume question

2006-02-16 Thread Park, Rod
Sorrythat was a typo on previous message, we have a 3584, not a
3589.

> _
> From: Park, Rod
> Sent: Thursday, February 16, 2006 7:53 AM
> To:   'ADSM-L@VM.MARIST.EDU'
> Subject:  5.3.2.2 volume question
>
> I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I
> have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5
> frames 60 drives.  tsm1 is the library manager. We have been noticing
> lately that when we run a report to show private, scratches, dbb vols,
> we have a column of private tapes that increases everyday that are
> really supposed to be scratch tapes. What I have found is, when
> reclamation runs on tsm2 for primary tape pools, it marks the tape as
> deleted and ready for scratch like it should, but on tsm1, it still
> shows the tape as private, if you "q  vol" on either tsm server, they
> know nothing about the tape, but again "q libvol" shows the tape as
> private like below:
>
> TSMLIB1  T01779  PrivateTSMCORP1
> 1,054   LTO
>
> I can check the tape out and recheck it in as scratch and it will be
> used as scratch from there out. I went back and checked our reports,
> and before the upgrade, we had 3-5 tapes in the status, now we have
> 140, If I look at the daily reports each day, it grows each day from
> the day we did the upgrade. So, has anybody else seen this with
> 5.3.2.2 or any other ideas on what might be causing this.


This email and any files transmitted with it are confidential and intended 
solely for the use of the addressee. If you are not the intended addressee, 
then you have received this email in error and any use, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited. Please 
notify us immediately of your unintended receipt by reply and then delete this 
email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates 
will not be held liable to any person resulting from the unintended or 
unauthorized use of any information contained in this email or as a result of 
any additions or deletions of information originally contained in this email.


5.3.2.2 volume question

2006-02-16 Thread Park, Rod
I recently upgraded to 5.3.2.2 server level, about 2 1/2 weeks ago. I
have 2 tsm servers, tsm1 and tsm2, each share a 3589 library with 5
frames 60 drives.  tsm1 is the library manager. We have been noticing
lately that when we run a report to show private, scratches, dbb vols,
we have a column of private tapes that increases everyday that are
really supposed to be scratch tapes. What I have found is, when
reclamation runs on tsm2 for primary tape pools, it marks the tape as
deleted and ready for scratch like it should, but on tsm1, it still
shows the tape as private, if you "q  vol" on either tsm server, they
know nothing about the tape, but again "q libvol" shows the tape as
private like below:

TSMLIB1  T01779  PrivateTSMCORP1
1,054   LTO

I can check the tape out and recheck it in as scratch and it will be
used as scratch from there out. I went back and checked our reports, and
before the upgrade, we had 3-5 tapes in the status, now we have 140, If
I look at the daily reports each day, it grows each day from the day we
did the upgrade. So, has anybody else seen this with 5.3.2.2 or any
other ideas on what might be causing this.


This email and any files transmitted with it are confidential and intended 
solely for the use of the addressee. If you are not the intended addressee, 
then you have received this email in error and any use, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited. Please 
notify us immediately of your unintended receipt by reply and then delete this 
email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates 
will not be held liable to any person resulting from the unintended or 
unauthorized use of any information contained in this email or as a result of 
any additions or deletions of information originally contained in this email.