745-6850 phone/vmail
-Original Message-
From: Kent J. Monthei [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
We also use ADSM 3.1.2.20 (for Solaris) with IBM 3494 Libraries and have
observed
man [EMAIL PROTECTED] on 02/05/2001 08:17:44 PM
Please respond to "ADSM: Dist Stor Manager" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: tape mount retention behaviour
I'm using ACSLS (STK). When I'm doing something like a s
...the tape that "dismount may be delayed" due to rebuilding the VCR
on the tape.
Priorities can't bypass this - I think it is more a tape media/drive
issue than *SM...
Good thought, David. As you say, the Activity Log should reflect
such a problem. If a Volume Control Region problem, be
bject: Re: tape mount retention behaviour
I also have a 3575 and most of thsi "dismounting" may be due to rebuilding the
VCR on the tape header. (This is something used by Magstar tapes). If you
check actlog during this time you will propbably see an entry for the tape that
"dis
there was an APAR but I do
think I observerd this at early 3.7 versions.
Regards, Sheelagh
--
MIME-Version: 1.0
Date: Tue, 6 Feb 2001 14:13:13 -0800
From: Joe Faracchio [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
To: [EMAIL PROTECTED]
... snipped...
Now with 3.7.2 I'm
, 2001 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
We also use ADSM 3.1.2.20 (for Solaris) with IBM 3494 Libraries and have
observed behavior consistent with that described by Joseph in the original
email
- an idle mount will be immediately dismounted
-2001 19:57
Please respond to [EMAIL PROTECTED]
To: ADSM-L
cc:(bcc: Kent J Monthei/CIS/PHRD/SB_PLC)
Subject: Re: tape mount retention behaviour
I thought it always worked this way. At one time I was going to put in a
request to have two mount retention times. One for when
trator
Freightliner, LLC
(503) 745-6850 phone/vmail
-Original Message-
From: Kent J. Monthei [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
We also use ADSM 3.1.2.20 (for Solaris) with IBM 349
Steffan , Joek,
no, not really.
As I stated originally, previously in 3.1.2.20 I observed the tapes
being dismounted as soon as another request of any kind was pending
regardless of their retention period. And I've observed tapes staying
mounted for the full retention period when
We are on 3.7.2 and we see the same "ugly" behavior.
Does anyone know if TSM 4.1 acts the same way?
Kind regards
Thomas Rupp
Vorarlberger Illwerke AG
MAIL: [EMAIL PROTECTED]
TEL:++43/5574/4991-251
FAX:++43/5574/4991-820-8251
I recently upgraded from 3.1.2.20 to 3.7.2.0
and notice a very annoying behaviour.
The system keeps an idle tape mounted for the full retention period
specified despite the pending mounts that are waiting.
when / where will this be fixed???
thanks ... joe.f.
Joseph A Faracchio, Systems
I thought it always worked this way. At one time I was going to put in a
request to have two mount retention times. One for when there are no
pending request for a drive and the other for when there are pending
request.
On Mon, 5 Feb 2001, Joe Faracchio wrote:
I recently upgraded from
Please respond to [EMAIL PROTECTED]
To: ADSM-L
cc:(bcc: Kent J Monthei/CIS/PHRD/SB_PLC)
Subject: Re: tape mount retention behaviour
I thought it always worked this way. At one time I was going to put in a
request to have two mount retention times. One for when there are no
pending
. Monthei [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
We also use ADSM 3.1.2.20 (for Solaris) with IBM 3494 Libraries and have
observed behavior consistent with that described by Joseph in the original
email
: Kent J. Monthei [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 5:20 PM
To: [EMAIL PROTECTED]
Subject: Re: tape mount retention behaviour
We also use ADSM 3.1.2.20 (for Solaris) with IBM 3494 Libraries and have
observed behavior consistent with that described by Joseph
15 matches
Mail list logo
