Hi
I have setup what I believe is a working shared library environment between one library manager and one library client. I can do all the usual querying from either side, the shared library is defined to the library client, the drive paths to the library client on the shared library are defined on the library manager.
The reason for a shared library is to use the simultaneous write function on a stgpool on the library client to send client data, during the disk pool migration, to a local tape pool and simultaneously to a tape pool on the shared library.
When the data starts to migrate from the disk pool the library successfully contacts the library manager and requests a mount of a scratch tape. On the library client I can see that there is a request for a mount point (DRLTO is the devclass);
Then a moment later I see;
On the library manager I get;
The library manager mount/dismount messages happen 3 times, (the library manager must try to mount 3 scratch volumes and then give up). One each occasion, the volume is a scratch volume checked in to the shared library.
Oddly, for each of the times the volume is mounted I can see that the volume status changes temporarily from scratch to private and containing data, according to 'q libv' and then reverts back to scratch;
Once the library manager messages are logged, on the library client there are the following messages saying that scratch volumes mount request denied and the autocopy fails;
Hence my simultaneous write function does not complete.
I ran an audit library from the library client to the shared library, this logged as successful, however the time taken to complete the process, according to the activity log was less than a second. Perhaps TSM just registers the fact that the request was a success rather than the actual audit process completing successfully.
Thanks for your help.
Cheers, JP.
I have setup what I believe is a working shared library environment between one library manager and one library client. I can do all the usual querying from either side, the shared library is defined to the library client, the drive paths to the library client on the shared library are defined on the library manager.
The reason for a shared library is to use the simultaneous write function on a stgpool on the library client to send client data, during the disk pool migration, to a local tape pool and simultaneously to a tape pool on the shared library.
When the data starts to migrate from the disk pool the library successfully contacts the library manager and requests a mount of a scratch tape. On the library client I can see that there is a request for a mount point (DRLTO is the devclass);
Code:
tsm: TSM01>q mo
ANR8379I Mount point in device class DRLTO is waiting for the volume mount to
complete, status: WAITING FOR VOLUME.Then a moment later I see;
Code:
tsm: TSM01>q mo
ANR8376I Mount point reserved in device class DRLTO, status: RESERVED.On the library manager I get;
Code:
08/27/2014 12:57:27 ANR8379I Mount point in device class DRLTO is waiting for
the volume mount to complete, status: WAITING FOR VOLUME.
(SESSION: 72)
08/27/2014 12:57:27 ANR8334I 1 matches found. (SESSION: 72)
08/27/2014 12:58:04 ANR8337I LTO volume 100172L4 mounted in drive DRV1
(mt0.0.0.3). (SESSION: 74)
08/27/2014 12:58:04 ANR9791I Volume 100172L4 in library DR-LIB ownership is
changing from DRTSM01 to TSM01. (SESSION: 74)
08/27/2014 12:58:04 ANR8336I Verifying label of LTO volume 100172L4 in drive
DRV1 (mt0.0.0.3). (SESSION: 74)
08/27/2014 12:58:48 ANR8468I LTO volume 100172L4 dismounted from drive DRV1
(mt0.0.0.3) in library DR-LIB. (SESSION: 74)
08/27/2014 12:58:48 ANR0409I Session 74 ended for server TSM01 (Windows).
(SESSION: 74)The library manager mount/dismount messages happen 3 times, (the library manager must try to mount 3 scratch volumes and then give up). One each occasion, the volume is a scratch volume checked in to the shared library.
Oddly, for each of the times the volume is mounted I can see that the volume status changes temporarily from scratch to private and containing data, according to 'q libv' and then reverts back to scratch;
Code:
tsm: DRTSM01>q libv
Library Name Volume Name Status Owner Last Use Home Device
Element Type
------------ ----------- ---------------- ---------- --------- ------- ------
DR-LIB 100172L4 Scratch 4,104
DR-LIB 100175L4 Scratch 4,113
DR-LIB 100176L4 Private TSM01 Data 4,109Once the library manager messages are logged, on the library client there are the following messages saying that scratch volumes mount request denied and the autocopy fails;
Code:
08/27/2014 13:03:16 ANR1404W Scratch volume mount request denied - mount
failed. (SESSION: 7475, PROCESS: 833)
08/27/2014 13:18:14 ANR1917E Autocopy process 833 failed for storage poolHence my simultaneous write function does not complete.
I ran an audit library from the library client to the shared library, this logged as successful, however the time taken to complete the process, according to the activity log was less than a second. Perhaps TSM just registers the fact that the request was a success rather than the actual audit process completing successfully.
Thanks for your help.
Cheers, JP.