On Nov 25, 2008, at 19:45 , Kelly Lipp wrote:

I don't think that's true. The purpose of the new code was to
eliminate the problem with sequential volumes.

I have to side with Kelly on this, recent TSM levels can have
concurrent RO access to FILE type volumes (no tape though, for obvious
reasons),

As for exports, they do seem to lock down a tape for longer than
strictly necessary, at least from what I recall from ancient TSM
levels, but I haven't done an export for ages.

Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
www.storserver.com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of Petrullo, Michael G.
Sent: Tuesday, November 25, 2008 11:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] "Waiting for access to input volume"

Kelly,

The multi-access read only applies to random access volumes, ie. Disk.

Shawn,

This is a flaw of TSM. If a process is using/holding a volume another
process will not be able to use it until it completes. I have ran into
this issue when running an export that was using a volume and then a
migration tried to access the same volume. The migration wasn't able
to
get access to the volume until the export finished. I've even gone to
the extent of calling IBM about this issue and they informed me that
it
is not even "in the works" for future versions of TSM. Hope this
clears
things up a little.

Regards,
Mike

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of
Kelly Lipp
Sent: Wednesday, November 19, 2008 5:46 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] "Waiting for access to input volume"

I haven't been following the entire thread, but multi-access read is
now
available on certain TSM volumes.  It's a V5.5 feature.  May be time
to
upgrade...  May be time to read the release notes at any rate to see
if
your problem is addressed by this new feature.

Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
www.storserver.com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf Of
Shawn Drew
Sent: Wednesday, November 19, 2008 3:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] "Waiting for access to input volume"

It's intermittent slow backups that can sometimes occupy the virtual
tape like this.
I would like to make sure that a single slow backup doesn't hold up
the
whole "Life Cycle".   I would prefer to have the single Backup Storage
pool process fail and move to the next step in the housekeeping script
than having to cancel the backup manually when I happen to notice this
happening.  If I can't find a time-out, then I will setup a monitor
script to cancel if the wait time gets too large)

Any ideas?

Regards,
Shawn
________________________________________________
Shawn Drew





Internet
zforray AT VCU DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
11/19/2008 04:01 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] "Waiting for access to input volume"





Perhaps a stuck restore has the volume?   Check "Q RESTORE"....




Shawn Drew <shawn.drew AT AMERICAS.BNPPARIBAS DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
11/19/2008 03:45 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
[ADSM-L] "Waiting for access to input volume"






Does anyone know how to set the time-out for this?  The device class
"Mount Wait" doesn't seem to apply


14     Backup Storage Pool      Primary Pool VTL_C1, Copy Pool VTL_C2,
Files
Backed Up: 7, Bytes Backed Up:
17,871,357,954,
Unreadable Files: 0, Unreadable Bytes: 0.

Current Physical File (bytes): 10,866,872

Waiting for access to input volume
K00459L3
(27271 seconds). Current output volume:
W00472L3.


Regards,
Shawn
________________________________________________
Shawn Drew


This message and any attachments (the "message") is intended solely
for
the addressees and is confidential. If you receive this message in
error, please delete it and immediately notify the sender. Any use not
in accord with its purpose, any dissemination or disclosure, either
whole or partial, is prohibited except formal approval. The internet
can
not guarantee the integrity of this message. BNP PARIBAS (and its
subsidiaries) shall (will) not therefore be liable for the message if
modified. Please note that certain functions and services for BNP
Paribas may be performed by BNP Paribas RCC, Inc.

IMPORTANT: E-mail sent through the Internet is not secure and timely
delivery of Internet mail is not guaranteed. Legg Mason therefore,
recommends that you do not send any  action-oriented or time-
sensitive information to us via electronic mail, or any confidential
or sensitive information including:  social security numbers,
account numbers, or personal identification numbers.

This message is intended for the addressee only and may contain
privileged or confidential information. Unless you are the intended
recipient, you may not use, copy or disclose to anyone any
information contained in this message. If you have received this
message in error, please notify the author by replying to this
message and then kindly delete the message. Thank you.

--
Met vriendelijke groeten,

Remco Post
remco AT pipsworld DOT nl