These may not be directly related, but I have had similar issues, and got
these responses from Support:
==============================================
Hello Richard,
In regards to PMR 06788 and your question about the "wait" time for
a drive allocation from an external library manager, I have dug into
the code and it does not appear that the TSM server has an explicit
timeout. From a timeout perspective on the allocation request it looks
like the server relies on the underlying system calls (TSM server to
external library manager) then what ever calls/commands the library
manager may use to allocate the drives and assumes the timeout values
associated with these activities. In other words if the call to the
external library manager times out we will end up with a failure and the
appropriate errno.
=============================================
Richard,
Final answer is that it's (the storage agent drive reserve timeout)
hard-coded 20 minutes. Hopefully, your storage agent doesn't die very
often,
so it shouldn't be too much of an issue.
If this is not the case, or if you need anything further, please let us
know.
Thank you for using Tivoli support.
=============================================
-----Original Message-----
From: Lisa Cabanas [mailto:cabanl AT MODOT DOT NET]
Sent: Thursday, May 22, 2003 7:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: more to mountwait than devclass definition??
If that's the case, is there a way to define this on a 3590 drive or on the
3494 library itself?
Bill Boyer
<bill.boyer@VERIZ
ON.NET> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: more to mountwait than devclass
definition??
05/21/2003 02:59
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
I thought the MOUNWAIT time was for when a tape mount was needed that
couldn't be performed by a library robotics. Like in a MANUAL library,
stand-alone tape drive. Or if you have a tape as READWRITE/READONLY, but
not
in the library. Then I see the request (QUERY REQUEST) counting down from
MOUNTWAIT to zero by 1 minute intervals. I've seen sessions in MediaW and
processes waiting for mount points for a lot longer than my devclass
MOUNTWAIT time.
Bill Boyer
DSS, Inc.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Prather, Wanda
Sent: Wednesday, May 21, 2003 10:56 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: more to mountwait than devclass definition??
Lisa,
FWIW, I haven't seen this behavior on my 5.1 server yet, but I have seen it
frequently on my 4.2 server.
Just from observation (I know it's not what the doc says), the mountwait
will cancel the process if it is waiting for a mount POINT OK, but doesn't
when the mount is needed in the middle of a process that already has the
drive.
When I have seen this, it's always been a problem with the tape robot.
-----Original Message-----
From: Lisa Cabanas [mailto:cabanl AT MODOT DOT NET]
Sent: Wednesday, May 21, 2003 8:36 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: more to mountwait than devclass definition??
I am wondering if I missed something in the upgrade to 5.1, but is there
somewhere else other than the devclass definition where I would define the
mountwait?
I ask because 140340 seconds is a lot more than 5 minutes!
thanks
lisa
Process Process Description Status
Number
-------- --------------------
-------------------------------------------------
13 Space Reclamation Offsite Volume(s) (storage pool BACKUPCOPY),
Moved Files: 117371, Moved Bytes:
101,969,883,939, Unreadable Files: 0,
Unreadable
Bytes: 0. Current Physical File (bytes):
606,188~Waiting for mount of input volume
771191
(140340 seconds).~Current output volume:
831191.\
Device Class Name: 3590TAPE
Device Access Strategy: Sequential
Storage Pool Count: 4
Device Type: 3590
Format: DRIVE
Est/Max Capacity (MB):
Mount Limit: DRIVES
Mount Wait (min): 5
Mount Retention (min): 0
Label Prefix: ADSM
Library: MODOT3494B
Directory:
Server Name:
Retry Period:
Retry Interval:
Shared:
Last Update by (administrator): CABANL
|
