It looks like you need to reinstall the drivers for the new drives.
Your OS is seeing the drives, but TSM needs specific drivers for them to
be associated as LTO class devices.  If they are IBM drives, you can go
the IBM ftp site and download the latest drivers
(ftp://service.boulder.ibm.com/storage/devdrvr/Windows/Win2000/Latest/).
Once you have updated the drivers, redefine the drives (delete paths,
drives first), and it should show up as LTO.


Mel Dennis
Systems Engineer II
 
Siemens IT Solutions and Services, Inc.
Energy Data Center Operations
4400 Alafaya Trail
MC Q1-108
Orlando, FL 32826
Tel.: 407-736-2360
Mob: 321-356-9366
Fax: 407-243-0260
mailto:melburn.dennis AT siemens DOT com
www.usa.siemens.com/it-solutions
 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Alexander Lazarevich
Sent: Thursday, March 26, 2009 12:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] define path problems

I'm having another problem and could use more help.

I've got lots of tapes in the library with lots of data on them, and
they
do seem to be defined and ready to go:

tsm: ITG-TSM>q libv

Library Name  Volume Name  Status     Owner      Last Use   Home
Device
                                                             Element
Type
------------  -----------  ---------- ---------  ---------  -------
-----
LB6.0.0.5     ITG002L2     Private    ITG-TSM    Data       45
LB6.0.0.5     ITG003L2     Private    ITG-TSM    Data       48
LB6.0.0.5     ITG004L2     Private    ITG-TSM    Data       53

but for some reason they are just unavailable to the server and I can't
figure out why.

One clue is that since I replaced the drives (delete drives, update
library path, define drives, define drive paths) the new drives are
showing up as a new device type GENERICTAPE1:

tsm: ITG-TSM>q drive

Library Name     Drive Name       Device Type     On-Line
------------     ------------     -----------     -------------------
LB6.0.0.5        MT1.0.0.4        GENERICTAPE     Yes
LB6.0.0.5        MT2.0.0.4        GENERICTAPE     Yes

Before the drives were replaced, these showed up as LTOCLASS1 device
types. Here's the device type I have:

tsm: ITG-TSM>q dev

Device    Device        Storage  Device    Format    Est/Max   Mount
Class     Access           Pool  Type                Capacity  Limit
Name      Strategy        Count                      (MB)
--------- ----------    -------  --------- ------    --------  ------
DISK      Random              3
LTOCLASS1 Sequential          1    LTO     DRIVE               DRIVES


So my guess is I need to reassociate those tapes with device type
LTO1CLASS, but I don't see any way to do this. Any idea if I'm on the
right track?

I appreciate the help,

Alex

On Thu, 26 Mar 2009, Alexander Lazarevich wrote:

> Thank you Mel.
>
> Alex
>
> On Thu, 26 Mar 2009, Dennis, Melburn (IT Solutions US) wrote:
>
>> ANR8466E  command: Invalid update request for drive drive name in
>>      library library name.
>>
>> Explanation: An invalid update request has been made for the given
>> drive. This can occur if a new device name is given and the
>> characteristics of the device do not match the characteristics of the
>> original device.
>>
>> System action: The server does not process the command.
>>
>> User response: If a different type of drive has been installed, the
old
>> drive definition must be deleted with a DELETE DRIVE operation, and a
>> new drive must be defined. The UPDATE DRIVE command cannot be used in
>> this case.
>>
>>
>> As it says in the error description, you must not only delete the
drive
>> paths, but the drive definitions themselves. Deleting the drive path
>> does not remove the previous drives information, and when you try to
>> redifine the path, its expecting to connect to that old drive, which
>> obviously no longer exists.
>>
>>
>> Mel Dennis
>> Systems Engineer II
>>
>> Siemens IT Solutions and Services, Inc.
>> Energy Data Center Operations
>> 4400 Alafaya Trail
>> MC Q1-108
>> Orlando, FL 32826
>> Tel.: 407-736-2360
>> Mob: 321-356-9366
>> Fax: 407-243-0260
>> mailto:melburn.dennis AT siemens DOT com
>> www.usa.siemens.com/it-solutions
>>
>>
>>
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
Of
>> Alexander Lazarevich
>> Sent: Thursday, March 26, 2009 10:42 AM
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: [ADSM-L] define path problems
>>
>> TSM server 5.3.4 on windows 2K server.
>>
>> Overland Neo 4100 LTO2 library with 2 x LTO2 drives conected via SCSI
>> 320.
>>
>> We recently replaced both LTO2 drives in the library, as well as the
>> SCSI
>> HBA. The drives and library are fine in windows when running the HP
>> StorageWorks libray and tape tools.
>>
>> Instead of updating the paths in TSM, I just deleted them. The
devices
>> were NOT deleted, just the paths:
>>
>> tsm: ITG-TSM>q drive
>>
>> Library Name     Drive Name       Device Type     On-Line
>> ------------     ------------     -----------     -------------------
>> LB6.0.0.5        MT1.0.0.4        LTO             Yes
>> LB6.0.0.5        MT2.0.0.4        LTO             Yes
>>
>> So first I create the new path for the library and that works:
>>
>> tsm: ITG-TSM>define path itg-tsm lb6.0.0.5 srctype=server
>> desttype=library
>>              device=lb6.0.0.4 online=yes
>> ANR1720I A path from ITG-TSM to LB6.0.0.5 has been defined.
>> tsm: ITG-TSM>q path
>> Source Name     Source Type     Destination     Destination
On-Line
>>                                 Name            Type
>> -----------     -----------     -----------     -----------
-------
>> ITG-TSM         SERVER          LB6.0.0.5       LIBRARY         Yes
>>
>>
>> But when I try to add the drives paths, I get an error:
>>
>> tsm: ITG-TSM>define path itg-tsm mt1.0.0.4 srctype=server
desttype=drive
>>              library=lb6.0.0.5 device=mt1.0.0.4 online=yes
>> ANR8466E DEFINE PATH: Invalid update request for drive MT1.0.0.4 in
>> library
>> LB6.0.0.5.
>> ANS8001I Return code 15.
>>
>>
>> Any ideas? I'm kinda at a loss of what to try next, especially
because I
>> had done this update path a while ago and it worked just fine.
>>
>> Thanks,
>>
>> Alex
>>
>