Hi

I have 2 Alpha servers, each with SCSI connected tape drive(s)

I want to move the drives from one server to another, and install a new one.

QUESTION: Can I do this live ?

My experience (on VAX) is that I can disconnect / reconnect the same drive 
on the VAX and it will not notice, as long as I DO NOT attempt to use the 
drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so 
would crash the VAX.

On Alpha it may be different, the HP tech says it should work just fine. I 
just want to double check here.

Details :
On the AS4100 I have a standalone DLT4 drive MKB600
On the ES40 I have a TL891 mini-library with 2 DLT4 drives MKA400 and MKA500

I want to disconnect the standalone DLT4 drive from the AS4100 and connect 
the TL891 and its drives in replacement.
On the ES40 in replacement of the TL891 I want to install a new LTO4 drive.

So... the AS4100 will get 2 drives instead of 1, and the ES40 will loose one 
drive and the replacement one will be of a different model.

QUESTIONS:
- Should I care about the new drives SCSI addresses ?
- VMS on the ES40 will continue to see the old device (let's say MKA500 if 
the new one replaces MKA400) which is disconnected. If by mistake some 
process tries to access it, will it cause VMS to crash ?
- If I keep the same SCSI address, does it matter if suddenly (as far as VMS 
sees it) the drive model is different ?
- The speed of the drive is also different. Without a reboot will VMS make 
the best use of the new unit (the speed of the devices on the bus have 
changed) ?

This is NOT something I've done before so I just don't know.
My guess is that I should shutdown the servers to do this, but I'd rather 
not if it's not required (24/365 shop)

Merci
Syltrem

Syltrem wrote:

> QUESTION: Can I do this live ?

   Perhaps.

> My experience (on VAX) is that I can disconnect / reconnect the same drive
> on the VAX and it will not notice, as long as I DO NOT attempt to use the
> drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so
> would crash the VAX.

   I'd make sure that the whole SCSI bus was idle, not only
the one tape drive.

> QUESTIONS:
> - Should I care about the new drives SCSI addresses ?

   When are you allowed _not_ to care about SCSI IDs?

> - VMS on the ES40 will continue to see the old device (let's say MKA500 if
> the new one replaces MKA400) which is disconnected. If by mistake some
> process tries to access it, will it cause VMS to crash ?

   I believe so.  I doubt it.

> - If I keep the same SCSI address, does it matter if suddenly (as far as VMS
> sees it) the drive model is different ?

   I believe that it will notice the new identity (device
type) when you try to access the new device.  SHOW DEVI /FULL
should provide a clue.

> - The speed of the drive is also different. Without a reboot will VMS make
> the best use of the new unit (the speed of the devices on the bus have
> changed) ?

   Which speed?  SCSI bus speed?  General I/O speed?  What
does VMS know about the speed of the device?

> This is NOT something I've done before so I just don't know.

   Only one way to find out.

In article <ZF16n.101149$dl4.56657@en-nntp-03.dc1.easynews.com>, "Syltrem" <syltremzulu@videotron.ca> writes:

>I have 2 Alpha servers, each with SCSI connected tape drive(s)
>
>I want to move the drives from one server to another, and install a new one.
>
>QUESTION: Can I do this live ?

It depends ;-)

>My experience (on VAX) is that I can disconnect / reconnect the same drive 
>on the VAX and it will not notice, as long as I DO NOT attempt to use the 
>drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so 
>would crash the VAX.
>
>On Alpha it may be different, the HP tech says it should work just fine. I 
>just want to double check here.

As long as you take care of the SCSI bus, that is, try to prevent any activity
on the bus while connecting/disconnecting, you should be fine.

[...]
>So... the AS4100 will get 2 drives instead of 1, and the ES40 will loose one 
>drive and the replacement one will be of a different model.
>
>QUESTIONS:
>- Should I care about the new drives SCSI addresses ?

Of course, the general SCSI-ID rules apply (different IDs, don't use the ID
of the controller,...)

>- VMS on the ES40 will continue to see the old device (let's say MKA500 if 
>the new one replaces MKA400) which is disconnected. If by mistake some 
>process tries to access it, will it cause VMS to crash ?

No, the process might just hang.

>- If I keep the same SCSI address, does it matter if suddenly (as far as VMS 
>sees it) the drive model is different ?

Do a "MC SYSMAN IO AUTOCONFIGURE" afterwards and you should be fine.

>- The speed of the drive is also different. Without a reboot will VMS make 
>the best use of the new unit (the speed of the devices on the bus have 
>changed) ?

As long as there is no slower device on the bus, yes, it will.

Good luck
   Christoph Gartmann

-- 
 Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -80464
 Immunbiologie
 Postfach 1169                 Internet: gartmann@immunbio dot mpg dot de
 D-79011  Freiburg, Germany
               http://www.immunbio.mpg.de/home/menue.html

On 21.1.2010 21:11, Syltrem wrote:
> Hi
>
> I have 2 Alpha servers, each with SCSI connected tape drive(s)
>
> I want to move the drives from one server to another, and install a new one.
>
> QUESTION: Can I do this live ?
>
> My experience (on VAX) is that I can disconnect / reconnect the same drive
> on the VAX and it will not notice, as long as I DO NOT attempt to use the
> drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so
> would crash the VAX.
>
> On Alpha it may be different, the HP tech says it should work just fine. I
> just want to double check here.
>
> Details :
> On the AS4100 I have a standalone DLT4 drive MKB600
> On the ES40 I have a TL891 mini-library with 2 DLT4 drives MKA400 and MKA500
>
> I want to disconnect the standalone DLT4 drive from the AS4100 and connect
> the TL891 and its drives in replacement.
> On the ES40 in replacement of the TL891 I want to install a new LTO4 drive.
>
> So... the AS4100 will get 2 drives instead of 1, and the ES40 will loose one
> drive and the replacement one will be of a different model.
>
> QUESTIONS:
> - Should I care about the new drives SCSI addresses ?
> - VMS on the ES40 will continue to see the old device (let's say MKA500 if
> the new one replaces MKA400) which is disconnected. If by mistake some
> process tries to access it, will it cause VMS to crash ?
> - If I keep the same SCSI address, does it matter if suddenly (as far as VMS
> sees it) the drive model is different ?
> - The speed of the drive is also different. Without a reboot will VMS make
> the best use of the new unit (the speed of the devices on the bus have
> changed) ?
>
> This is NOT something I've done before so I just don't know.
> My guess is that I should shutdown the servers to do this, but I'd rather
> not if it's not required (24/365 shop)
>
> Merci
> Syltrem
>
>

Yes, you can do it live, when you keep in mind some basic, but very 
important things.
First, do not connect or disconnect peripherals when they are switched 
on. Do always switch them off before making any changes. Preferably 
disconnect the power cord also.
Second, you have to mind about the SCSI addresses to be sure you don't 
have two devices with same address. That will really produce 
unpredictable behaviour.
Third, it is good to update the I/O structures when you have 
disconnected the old peripherals and connected the new ones, but before 
you switch the new ones on, by issuing the command
$ MC SYSMAN IO AUTO /LOG
The old peripherals should turn from online to offline.
Then switch the new ones on and do once more
$ MC SYSMAN IO AUTO /LOG
Now the new peripherals should appear in the device list.
The speed of the drive should be correct at once if your version of 
OpenVMS recognizes it correctly (i.e. the VMS version is new enough).
There might be a faint possibility that someone would have fiddled with 
the SCSI adapter settings which would cause the bus not to work with 
full speed. But you'll find that out when you test the drive.
One thing you probably need to do is to generate the robotics control 
device on the machine where you connect the tape library.
You can do that live also. You need th know the bus ID and the SCSI ID 
of the robotics controller. Lets say it is SCSI ID 1 on the third SCSI 
bus (C)
$ MC SYSMAN IO CONNECT GKC100: /NOADAPTER /DRIVER=SYS$GKDRIVER
Then you should have a device named GKC100: which is the one you need to 
access the robotics. Most probably you need to update your backup 
application or procedure to include the robotics device name.
If you have the MRU utility installed, you can test the robotics 
functions manually
(e.g. $ robot show robot)


Good luck!

Kari

On Thu, 21 Jan 2010 at 14:11 -0500, Syltrem wrote:

> I have 2 Alpha servers, each with SCSI connected tape drive(s)
>
> I want to move the drives from one server to another, and install a 
> new one.
>
> QUESTION: Can I do this live ?

Back when I had a working tape drive, I used to move it among my two 
vaxes and my alpha (DEC 3000-400).  The tape drive had a terminator on 
it.  I always installed a terminator on the machines that did not have 
the tape drive.  I noticed on the alpha that if there was disk 
activity on the unterminated bus, that the disk or bus would log 
errors.  I don't think I ever had a system crash.

The advice to make sure that the SCSI bus is idle is good advice.  I 
agree with the other advice given by Steven and Christoph, as well.


-- 

Rob Brown                        b r o w n a t g m c l d o t c o m
G. Michaels Consulting Ltd.      (780)438-9343 (voice)
Edmonton                         (780)437-3367 (FAX)
                                  http://gmcl.com/

"Kari Uusim�ki" <uusimaki@exdecWITHOUTTHISfinland.org> wrote in message 
news:4b58aff3$0$26371$9b536df3@news.fv.fi...
> On 21.1.2010 21:11, Syltrem wrote:
>
> Yes, you can do it live, when you keep in mind some basic, but very 
> important things.
> First, do not connect or disconnect peripherals when they are switched on. 
> Do always switch them off before making any changes. Preferably disconnect 
> the power cord also.
> Second, you have to mind about the SCSI addresses to be sure you don't 
> have two devices with same address. That will really produce unpredictable 
> behaviour.
> Third, it is good to update the I/O structures when you have disconnected 
> the old peripherals and connected the new ones, but before you switch the 
> new ones on, by issuing the command
> $ MC SYSMAN IO AUTO /LOG
> The old peripherals should turn from online to offline.
> Then switch the new ones on and do once more
> $ MC SYSMAN IO AUTO /LOG
> Now the new peripherals should appear in the device list.

I I used the same SCSI ID, I would just see the device going from online to 
offline, then to online again. Riight ?
And it's safe to keep the same SCSI address (if I can do that then I won't 
be left with a non-existing device showing up on VMS)

> The speed of the drive should be correct at once if your version of 
> OpenVMS recognizes it correctly (i.e. the VMS version is new enough).
> There might be a faint possibility that someone would have fiddled with 
> the SCSI adapter settings which would cause the bus not to work with full 
> speed. But you'll find that out when you test the drive.
> One thing you probably need to do is to generate the robotics control 
> device on the machine where you connect the tape library.

The GKxu device will not get created automatically with the SYSMAN IO AUTO ?

> You can do that live also. You need th know the bus ID and the SCSI ID of 
> the robotics controller. Lets say it is SCSI ID 1 on the third SCSI bus 
> (C)

Right now the robot is GKA0 and the drives are MKA400 and MKA500:
Isn't the robot always 0 ? I thought this was how it worked. Or maybe it's 
just because it was assigned SCSI id 0 at install time. I have 2 and both 
are on ID 0, but on different buses (GKA0 and GKB0)

> $ MC SYSMAN IO CONNECT GKC100: /NOADAPTER /DRIVER=SYS$GKDRIVER
> Then you should have a device named GKC100: which is the one you need to 
> access the robotics. Most probably you need to update your backup 
> application or procedure to include the robotics device name.
> If you have the MRU utility installed, you can test the robotics functions 
> manually
> (e.g. $ robot show robot)
>
>
> Good luck!
>
> Kari
>

Thanks for all the details.
This will help a lot !
Syltrem 

In article <SJ26n.104025$H15.40195@en-nntp-02.dc1.easynews.com>, "Syltrem" <syltremzulu@videotron.ca> writes:
>
>I I used the same SCSI ID, I would just see the device going from online to 
>offline, then to online again. Riight ?

Correct.

>And it's safe to keep the same SCSI address (if I can do that then I won't 
>be left with a non-existing device showing up on VMS)

Correct.

Nevertheless you should perform the "MC SYSMAN IO AUTOCONFIGURE" before using
the replaced device for the first time.

>The GKxu device will not get created automatically with the SYSMAN IO AUTO ?

Most likely not.

>Right now the robot is GKA0 and the drives are MKA400 and MKA500:
>Isn't the robot always 0 ? I thought this was how it worked. Or maybe it's 
>just because it was assigned SCSI id 0 at install time. I have 2 and both 
>are on ID 0, but on different buses (GKA0 and GKB0)

The ID of the robot depends on the device. Some devices use a fixed ID, others
allow you to configure it and some use LUNs instead of a separate ID.

Regards,
   Christoph Gartmann

-- 
 Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -80464
 Immunbiologie
 Postfach 1169                 Internet: gartmann@immunbio dot mpg dot de
 D-79011  Freiburg, Germany
               http://www.immunbio.mpg.de/home/menue.html

On Jan 21, 2:11=A0pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> Hi
>
> I have 2 Alpha servers, each with SCSI connected tape drive(s)
>
> I want to move the drives from one server to another, and install a new o=
ne.
>
> QUESTION: Can I do this live ?
>
> My experience (on VAX) is that I can disconnect / reconnect the same driv=
e
> on the VAX and it will not notice, as long as I DO NOT attempt to use the
> drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so
> would crash the VAX.
>
> On Alpha it may be different, the HP tech says it should work just fine. =
I
> just want to double check here.
>
> Details :
> On the AS4100 I have a standalone DLT4 drive MKB600
> On the ES40 I have a TL891 mini-library with 2 DLT4 drives MKA400 and MKA=
500
>
> I want to disconnect the standalone DLT4 drive from the AS4100 and connec=
t
> the TL891 and its drives in replacement.
> On the ES40 in replacement of the TL891 I want to install a new LTO4 driv=
e.
>
> So... the AS4100 will get 2 drives instead of 1, and the ES40 will loose =
one
> drive and the replacement one will be of a different model.
>
> QUESTIONS:
> - Should I care about the new drives SCSI addresses ?
> - VMS on the ES40 will continue to see the old device (let's say MKA500 i=
f
> the new one replaces MKA400) which is disconnected. If by mistake some
> process tries to access it, will it cause VMS to crash ?
> - If I keep the same SCSI address, does it matter if suddenly (as far as =
VMS
> sees it) the drive model is different ?
> - The speed of the drive is also different. Without a reboot will VMS mak=
e
> the best use of the new unit (the speed of the devices on the bus have
> changed) ?
>
> This is NOT something I've done before so I just don't know.
> My guess is that I should shutdown the servers to do this, but I'd rather
> not if it's not required (24/365 shop)
>
> Merci
> Syltrem

a) I would double check that the interface is the same across all the
drives.  That is, are they all using LVD or HVD SCSI?

I suspect the TL891 is HVD, and the LTO will be LVD.  This may
sidetrack your plans.

b) I'm in the habit of using the following:

$ MC SYSMAN
SYSMAN> IO SCSI
SYSMAN> IO AUTO

www.noesys.com

In article <ZF16n.101149$dl4.56657@en-nntp-03.dc1.easynews.com>, "Syltrem" <syltremzulu@videotron.ca> writes:
> Hi
> 
> I have 2 Alpha servers, each with SCSI connected tape drive(s)
> 
> I want to move the drives from one server to another, and install a new one.
> 
> QUESTION: Can I do this live ?
> 
> My experience (on VAX) is that I can disconnect / reconnect the same drive 
> on the VAX and it will not notice, as long as I DO NOT attempt to use the 
> drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so 
> would crash the VAX.
> 
> On Alpha it may be different, the HP tech says it should work just fine. I 
> just want to double check here.
> 

   I think the most important thing is to make sure the SCSI bus is
   absolutely quiet when your doing this.

> QUESTIONS:
> - Should I care about the new drives SCSI addresses ?

   Yes.  You'll need an address that is not already in use.

> - VMS on the ES40 will continue to see the old device (let's say MKA500 if 
> the new one replaces MKA400) which is disconnected. If by mistake some 
> process tries to access it, will it cause VMS to crash ?

   I would not be the least surprised.  You off into an unsupported
   hardware configuration here.
   
> - If I keep the same SCSI address, does it matter if suddenly (as far as VMS 
> sees it) the drive model is different ?

   Very good chance that that won't work.  Try it on a non-operational
   system first, and then make sure you're not betting the business.

> - The speed of the drive is also different. Without a reboot will VMS make 
> the best use of the new unit (the speed of the devices on the bus have 
> changed) ?

   You should be OK, if you don't use the same SCSI address.  If you do
   and VMS can talk to the drive, then it will assume that it's the old
   drive.
 
   If at all possible, I would schedule a few minutes of power-off time
   in oder to do this.  If you have a high availability cluster setup,
   you should be able to keep your applications available.

"FrankS" <sapienza@noesys.com> a �crit dans le message de news: 
108fbd62-f1e2-40f4-b994-6489ac129c3f@d14g2000vbb.googlegroups.com...
On Jan 21, 2:11 pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> Hi
>
> I have 2 Alpha servers, each with SCSI connected tape drive(s)
>
> I want to move the drives from one server to another, and install a new 
> one.
>
> QUESTION: Can I do this live ?
>
> My experience (on VAX) is that I can disconnect / reconnect the same drive
> on the VAX and it will not notice, as long as I DO NOT attempt to use the
> drive (do a MOUNT or INIT etc) on it while it is disconnected. Doing so
> would crash the VAX.
>
> On Alpha it may be different, the HP tech says it should work just fine. I
> just want to double check here.
>
> Details :
> On the AS4100 I have a standalone DLT4 drive MKB600
> On the ES40 I have a TL891 mini-library with 2 DLT4 drives MKA400 and 
> MKA500
>
> I want to disconnect the standalone DLT4 drive from the AS4100 and connect
> the TL891 and its drives in replacement.
> On the ES40 in replacement of the TL891 I want to install a new LTO4 
> drive.
>
> So... the AS4100 will get 2 drives instead of 1, and the ES40 will loose 
> one
> drive and the replacement one will be of a different model.
>
> QUESTIONS:
> - Should I care about the new drives SCSI addresses ?
> - VMS on the ES40 will continue to see the old device (let's say MKA500 if
> the new one replaces MKA400) which is disconnected. If by mistake some
> process tries to access it, will it cause VMS to crash ?
> - If I keep the same SCSI address, does it matter if suddenly (as far as 
> VMS
> sees it) the drive model is different ?
> - The speed of the drive is also different. Without a reboot will VMS make
> the best use of the new unit (the speed of the devices on the bus have
> changed) ?
>
> This is NOT something I've done before so I just don't know.
> My guess is that I should shutdown the servers to do this, but I'd rather
> not if it's not required (24/365 shop)
>
> Merci
> Syltrem

> a) I would double check that the interface is the same across all the
> drives.  That is, are they all using LVD or HVD SCSI?
>
> I suspect the TL891 is HVD, and the LTO will be LVD.  This may
> sidetrack your plans.
>
> b) I'm in the habit of using the following:
>
> $ MC SYSMAN
> SYSMAN> IO SCSI
> SYSMAN> IO AUTO
>


Thanks for the hint on
SYSMAN> IO SCSI

I will do this as well. I'm writing my scenario right now.

I will do my disaster recovery server first before I try that in production 
!
Thanks to all who provided guidance on this config change !
Syltrem

On 21.1.2010 22:24, Syltrem wrote:
> "Kari Uusim�ki"<uusimaki@exdecWITHOUTTHISfinland.org>  wrote in message
> news:4b58aff3$0$26371$9b536df3@news.fv.fi...
>> On 21.1.2010 21:11, Syltrem wrote:
>>
>> Yes, you can do it live, when you keep in mind some basic, but very
>> important things.
>> First, do not connect or disconnect peripherals when they are switched on.
>> Do always switch them off before making any changes. Preferably disconnect
>> the power cord also.
>> Second, you have to mind about the SCSI addresses to be sure you don't
>> have two devices with same address. That will really produce unpredictable
>> behaviour.
>> Third, it is good to update the I/O structures when you have disconnected
>> the old peripherals and connected the new ones, but before you switch the
>> new ones on, by issuing the command
>> $ MC SYSMAN IO AUTO /LOG
>> The old peripherals should turn from online to offline.
>> Then switch the new ones on and do once more
>> $ MC SYSMAN IO AUTO /LOG
>> Now the new peripherals should appear in the device list.
>
> I I used the same SCSI ID, I would just see the device going from online to
> offline, then to online again. Riight ?
> And it's safe to keep the same SCSI address (if I can do that then I won't
> be left with a non-existing device showing up on VMS)

It would be better to choose another address, because VMS expects to 
find the same device at the same address when it comes online again.

>
>> The speed of the drive should be correct at once if your version of
>> OpenVMS recognizes it correctly (i.e. the VMS version is new enough).
>> There might be a faint possibility that someone would have fiddled with
>> the SCSI adapter settings which would cause the bus not to work with full
>> speed. But you'll find that out when you test the drive.
>> One thing you probably need to do is to generate the robotics control
>> device on the machine where you connect the tape library.
>
> The GKxu device will not get created automatically with the SYSMAN IO AUTO ?

Absolutely not. The GKDRIVER is not loaded automatically unless someone 
has configured somewhere in the startup procedures.


>
>> You can do that live also. You need th know the bus ID and the SCSI ID of
>> the robotics controller. Lets say it is SCSI ID 1 on the third SCSI bus
>> (C)
>
> Right now the robot is GKA0 and the drives are MKA400 and MKA500:
> Isn't the robot always 0 ? I thought this was how it worked. Or maybe it's
> just because it was assigned SCSI id 0 at install time. I have 2 and both
> are on ID 0, but on different buses (GKA0 and GKB0)

The robotics SCSI ID is settable from the library control panel. The ID 
doesn't matter much. Choose whatever you like, but remember not to have 
two different peripherals on the same SCSI bus with the same ID.

One more thing as was pointed out in another post; the TL891 is a HVD 
SCSI peripheral and the LTO4 is LVD. These aren't compatible. The HVD 
bus and the LVD bus operate at different voltages. That means in 
practise that you need a HVD bus for the TL891 and a LVD bus for the 
LTO4. It's not anything magical - you just have to use different 
adapters. E.g. a KZPBA-CY is good for the TL891 and a KZPEA-DB would be 
a good adapter for the LTO4.

>
>> $ MC SYSMAN IO CONNECT GKC100: /NOADAPTER /DRIVER=SYS$GKDRIVER
>> Then you should have a device named GKC100: which is the one you need to
>> access the robotics. Most probably you need to update your backup
>> application or procedure to include the robotics device name.
>> If you have the MRU utility installed, you can test the robotics functions
>> manually
>> (e.g. $ robot show robot)
>>
>>
>> Good luck!
>>
>> Kari
>>
>
> Thanks for all the details.
> This will help a lot !
> Syltrem
>
>

Regards,

Kari

"Kari Uusim�ki" <uusimaki@exdecWITHOUTTHISfinland.org> wrote in message 
news:4b5a24a0$0$3856$9b536df3@news.fv.fi...
> On 21.1.2010 22:24, Syltrem wrote:
>> "Kari Uusim�ki"<uusimaki@exdecWITHOUTTHISfinland.org>  wrote in message
>> news:4b58aff3$0$26371$9b536df3@news.fv.fi...
>>> On 21.1.2010 21:11, Syltrem wrote:
>>>
>>> Yes, you can do it live, when you keep in mind some basic, but very
>>> important things.
>>> First, do not connect or disconnect peripherals when they are switched 
>>> on.
>>> Do always switch them off before making any changes. Preferably 
>>> disconnect
>>> the power cord also.
>>> Second, you have to mind about the SCSI addresses to be sure you don't
>>> have two devices with same address. That will really produce 
>>> unpredictable
>>> behaviour.
>>> Third, it is good to update the I/O structures when you have 
>>> disconnected
>>> the old peripherals and connected the new ones, but before you switch 
>>> the
>>> new ones on, by issuing the command
>>> $ MC SYSMAN IO AUTO /LOG
>>> The old peripherals should turn from online to offline.
>>> Then switch the new ones on and do once more
>>> $ MC SYSMAN IO AUTO /LOG
>>> Now the new peripherals should appear in the device list.
>>
>> I I used the same SCSI ID, I would just see the device going from online 
>> to
>> offline, then to online again. Riight ?
>> And it's safe to keep the same SCSI address (if I can do that then I 
>> won't
>> be left with a non-existing device showing up on VMS)
>
> It would be better to choose another address, because VMS expects to find 
> the same device at the same address when it comes online again.
>
>>
>>> The speed of the drive should be correct at once if your version of
>>> OpenVMS recognizes it correctly (i.e. the VMS version is new enough).
>>> There might be a faint possibility that someone would have fiddled with
>>> the SCSI adapter settings which would cause the bus not to work with 
>>> full
>>> speed. But you'll find that out when you test the drive.
>>> One thing you probably need to do is to generate the robotics control
>>> device on the machine where you connect the tape library.
>>
>> The GKxu device will not get created automatically with the SYSMAN IO 
>> AUTO ?
>
> Absolutely not. The GKDRIVER is not loaded automatically unless someone 
> has configured somewhere in the startup procedures.
>
>

Well it did !
But the one I made work was the one connected to the SAN (fibre)
I did IO FIND_WWID then IO AUTO and there it was, along with the tape drive.
No need for an IO CONNECT, it works just as it is.


>>
>>> You can do that live also. You need th know the bus ID and the SCSI ID 
>>> of
>>> the robotics controller. Lets say it is SCSI ID 1 on the third SCSI bus
>>> (C)
>>
>> Right now the robot is GKA0 and the drives are MKA400 and MKA500:
>> Isn't the robot always 0 ? I thought this was how it worked. Or maybe 
>> it's
>> just because it was assigned SCSI id 0 at install time. I have 2 and both
>> are on ID 0, but on different buses (GKA0 and GKB0)
>
> The robotics SCSI ID is settable from the library control panel. The ID 
> doesn't matter much. Choose whatever you like, but remember not to have 
> two different peripherals on the same SCSI bus with the same ID.
>
> One more thing as was pointed out in another post; the TL891 is a HVD SCSI 
> peripheral and the LTO4 is LVD. These aren't compatible. The HVD bus and 
> the LVD bus operate at different voltages. That means in practise that you 
> need a HVD bus for the TL891 and a LVD bus for the LTO4. It's not anything 
> magical - you just have to use different adapters. E.g. a KZPBA-CY is good 
> for the TL891 and a KZPEA-DB would be a good adapter for the LTO4.
>

That has proven to be a problem. The ES40 does not have a suitable SCSI 
adapter.
I ordered 2 KZPEA-DB to get them connected.

So all the rest I was trying to do live, will require a shutdown to install 
the new adapter.
The MSL2024 Fibre installation worked like a charm though.

Thanks for the help on all that, to everyone who contributed.
Syltrem

>>
>>> $ MC SYSMAN IO CONNECT GKC100: /NOADAPTER /DRIVER=SYS$GKDRIVER
>>> Then you should have a device named GKC100: which is the one you need to
>>> access the robotics. Most probably you need to update your backup
>>> application or procedure to include the robotics device name.
>>> If you have the MRU utility installed, you can test the robotics 
>>> functions
>>> manually
>>> (e.g. $ robot show robot)
>>>
>>>
>>> Good luck!
>>>
>>> Kari
>>>
>>
>> Thanks for all the details.
>> This will help a lot !
>> Syltrem
>>
>>
>
> Regards,
>
> Kari
> 

On Jan 28, 1:49=A0pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> That has proven to be a problem. The ES40 does not have a suitable SCSI
> adapter.  I ordered 2 KZPEA-DB to get them connected.
>
> So all the rest I was trying to do live, will require a shutdown to insta=
ll
> the new adapter.  The MSL2024 Fibre installation worked like a charm thou=
gh.
>

Silly question:  If you're going to shut down the ES40 to install an
adapter, then why not install a fiber HBA and connect the ES40 to the
same SAN?

Of course, if the ES40 is already part of the same SAN then just share
the tape drive.  I'm assuming the LTO is the one you put on the SAN
via either an NSR or MDR device.  You could also just add an HVD
interface to your NSR/MDR and get all the tapes on the SAN.  That
would preclude the need for a reboot.

Just idle thoughts on my part.


www.noesys.com

> "FrankS" <sapienza@noesys.com> wrote in message 
> news:fe169981-b0a0-4a02-a0a7-85cf8e1c91f7@r10g2000vbn.googlegroups.com...
> On Jan 28, 1:49 pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> > That has proven to be a problem. The ES40 does not have a suitable SCSI
> > adapter.  I ordered 2 KZPEA-DB to get them connected.
> >
> > So all the rest I was trying to do live, will require a shutdown to 
> > install
> > the new adapter.  The MSL2024 Fibre installation worked like a charm 
> > though.
> >
>
> Silly question:  If you're going to shut down the ES40 to install an
> adapter, then why not install a fiber HBA and connect the ES40 to the
>  same SAN?
>
> Of course, if the ES40 is already part of the same SAN then just share
> the tape drive.  I'm assuming the LTO is the one you put on the SAN
> via either an NSR or MDR device.  You could also just add an HVD
> interface to your NSR/MDR and get all the tapes on the SAN.  That
> would preclude the need for a reboot.
>
> Just idle thoughts on my part.
>
>
> www.noesys.com


The ES40 is connected to the SAN and can use the MSL2024 that I connected 
the other day. My other servers can use it, too
But since it has only 1 drive, I bought an extra drive just in case I need 
it while (eventually) waiting for the technician to repair the MSL2024.

The MSL2024 is the cheapest you can get from HP to connect to a SAN. I 
wanted 2 drives in it, but that could not be done (only in SCSI mode) so the 
other option was to get an MSL4048 instead. Too costly. That`s why I have 
this extra drive, SCSI connected.

The other site has an 1/8 G2 autoloader, also SCSI. There is no fibre option 
on this one.

HP doesn't have small autoloaders that connect to the SAN.

Syltrem

On Jan 28, 3:21=A0pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> HP doesn't have small autoloaders that connect to the SAN.
>

On the contrary.  They can all be connected to the SAN.

You need to look at either a Modular Data Router (MDR) or a Network
Storage Router (NSR).  These are both devices that allow (just about)
any SCSI device to attach to a SAN.  Both are fully supported in
OpenVMS.  The MDR has interfaces available for both HVD and LVD SCSI
buses.  The NSR has LVD interfaces (I don't remember if it supports an
HVD bus, even though I have one sitting in the other room).

Both are available on the used market (eBay, Island, PSDS, and
others).  I believe the NSR is still available new from HP.

I have one client using an MDR to connect both a TZ877 DLT loader and
an HP LTO 1 Autoloader to their SAN.  Another clients uses an MDR to
connect a TL891 and IBM LTO drive to their SAN.  Works like a charm.
Fully supported in a cluster too.  If you have multiple, non-clustered
systems attached to the same SAN then you would have to manually
prevent simultaneous access to the drives from multiple systems.  Just
like any other non-clustered systems.


www.noesys.com

FrankS wrote:
> On Jan 28, 3:21 pm, "Syltrem" <syltremz...@videotron.ca> wrote:
>> HP doesn't have small autoloaders that connect to the SAN.
>>
> 
> On the contrary.  They can all be connected to the SAN.
> 
> You need to look at either a Modular Data Router (MDR) or a Network
> Storage Router (NSR).  These are both devices that allow (just about)
> any SCSI device to attach to a SAN.

What is the difference between the two (other than the type
of SCSI connection, as you mentioned)?   Why should I choose
one over the other?

Thanks,
Alan

On Jan 28, 7:59=A0pm, Alan Frisbie <Frisbie_REM...@Flying-Disk.com>
wrote:
> What is the difference between the two (other than the type
> of SCSI connection, as you mentioned)? =A0 Why should I choose
> one over the other?

The older Compaq Modular Data Router (MDR) has a 1gb fiber interface,
using SC connectors.  The later Compaq/HP Network Storage Router (NSR)
has a 1/2//4gb fiber interface, using LC connectors.  If you need
current support then you'd pick a recent vintage NSR, as the MDR has
long since been end-of-lifed.  You can still find the Quickspecs for
both devices online, so I suggest you do so if you need more details.

I took a quick look earlier, and saw that there is a variant of the
NSR which can provide both HVD and LVD bus interfaces.  So that is no
longer a decision point between the two devices.  You'll likely spend
more for the NSR (although I bought a new, open box unit on eBay for
$50 a year+ ago).


www.noesys.com

"FrankS" <sapienza@noesys.com> a �crit dans le message de news: 
366bcb02-7fba-4daf-858b-e48cc73939e2@a32g2000yqm.googlegroups.com...
On Jan 28, 3:21 pm, "Syltrem" <syltremz...@videotron.ca> wrote:
> HP doesn't have small autoloaders that connect to the SAN.
>
>
>
> On the contrary.  They can all be connected to the SAN.
>
> You need to look at either a Modular Data Router (MDR) or a Network
> Storage Router (NSR).  These are both devices that allow (just about)
> any SCSI device to attach to a SAN.  Both are fully supported in
> OpenVMS.  The MDR has interfaces available for both HVD and LVD SCSI
> buses.  The NSR has LVD interfaces (I don't remember if it supports an
> HVD bus, even though I have one sitting in the other room).
>
> Both are available on the used market (eBay, Island, PSDS, and
> others).  I believe the NSR is still available new from HP.
>
> I have one client using an MDR to connect both a TZ877 DLT loader and
> an HP LTO 1 Autoloader to their SAN.  Another clients uses an MDR to
> connect a TL891 and IBM LTO drive to their SAN.  Works like a charm.
> Fully supported in a cluster too.  If you have multiple, non-clustered
> systems attached to the same SAN then you would have to manually
> prevent simultaneous access to the drives from multiple systems.  Just
> like any other non-clustered systems.

But the transfer rate will be that of a SCSI device, not that of a fibre 
connected device, right ?
That's what I was told, and it does make sense as the unit is really a SCSI 
device.

In order to get the speed, you have to get a device that really supports 
fiber, not through an adapter.

Syltrem

On Jan 29, 11:58=A0am, "Syltrem" <syltremz...@videotron.ca> wrote:
> But the transfer rate will be that of a SCSI device, not that of a fibre
> connected device, right ?  That's what I was told, and it does make sense=
 as the unit is really a SCSI
> device.
>

Ultimately yes.  You can't make a SCSI device go faster than it's
capable.  However, since the SCSI transfers are being offloaded from
the host, and there's additional caching in the NSR/MDR device, you
end up with some other benefits.  I know from experience that I can
stream data to a SCSI tape drive that's connected to an MDR, which
would not stream while directly connected to a host-based SCSI
adapter.

The other obvious advantage is shared devices.  You don't have to go
through connecting and reconnecting tape drives, or buying one drive
per system.

And, lastly, cost becomes a factor.  You already mentioned that the
MSL4048 (or whatever it was) was too expensive an option.  A used NSR
or MDR plus one or more less expensive LTO libraries could possibly be
had for less total outlay than that one fiber tape library.

www.noesys.com