On a HP 9000/800 server running HP-UX 11.11, I have a tape autochanger
identified in SAM thusly:

Hardware Path: 0/3/1/0/4/1.0.0
Driver: schgr
Description: HP MSL6000 Series (Autochanger)
Device File: /dev/rac/c5t0d0

I have compiled mtx 1.3.9 on the box; it gives me this output:

# ./mtx -f /dev/rac/c5t0d0 status
cannot open SCSI device '/dev/rac/c5t0d0' - No such device

However, the file exists:

# ls -l /dev/rac
total 0
crw------- 1 bin sys 231 0x050000 May 24 2006 c5t0d0


So apparently, mtx in its unaltered state, cannot deal with the device.

I've not been able to find any useful information on the web. What
options _do_ I have for dealing with this device?

Thanks,
Steve

In article <JCA7Hw.MrH@news.boeing.com>,
allen@doobie.itdl.ds.boeing.com (Steve Allen) writes:
> On a HP 9000/800 server running HP-UX 11.11, I have a tape autochanger
> identified in SAM thusly:
>
> Hardware Path: 0/3/1/0/4/1.0.0
> Driver: schgr
> Description: HP MSL6000 Series (Autochanger)
> Device File: /dev/rac/c5t0d0
>
> I have compiled mtx 1.3.9 on the box; it gives me this output:
>
> # ./mtx -f /dev/rac/c5t0d0 status
> cannot open SCSI device '/dev/rac/c5t0d0' - No such device
>
> However, the file exists:
>
> # ls -l /dev/rac
> total 0
> crw------- 1 bin sys 231 0x050000 May 24 2006 c5t0d0
>
>
> So apparently, mtx in its unaltered state, cannot deal with the device.
>
> I've not been able to find any useful information on the web. What
> options _do_ I have for dealing with this device?

More info:

The tree goes like this:

0/3 lba Local PCI-X Bus Adapter (783)
0/3/1/0 PCItoPCI PCI to PCI Bridge
0/3/1/0/4/0 mpt HP AB290-60001 PCI/PCI U320 SCSI 2-port 1000B-T Combo Adapter
(at /dev/mpt4)
0/3/1/0/4/0.2.0 stape HP Ultrium 3-SCSI (Tape Drive)
(at /dev/rmt/c4t2d0BEST)
0/3/1/0/4/0.7.0 sctl Initiator
(at /dev/rscsi/c4t7d0)
0/3/1/0/4/1 mpt HP AB290-60001 PCI/PCI U320 SCSI 2-port 1000B-T Combo Adapter
(at /dev/mpt5)
0/3/1/0/4/1/0.0 schgr HP MSL6000 Series (Autochanger)
(at /dev/rac/c5t0d0)
0/3/1/0/4/1.1.0 stape HP Ultrium 3-SCSI (Tape Drive)
(at /dev/rmt/c5t1d0BEST)
0/3/1/0/4/1.7.0 sctl Initiator
(at /dev/rscsi/c5t7s0)


I can access both tapes using the `mt` command, I just need to know how
to talk to the changer.

Thanks,
Steve

Steve,

I had similar problems using a Scalar tape library. It is fibre, but it
operates the same... I ended up having to get atdd drivers for it from
IBM... Not too much support came from scalar , was sort of a self
research from HP and myself.



Atdd is a driver for tape libraries, and schgr is the scsi changer
device drivers, both are needed.

In article <1169502611.095622.79340@l53g2000cwa.googlegroups. com>,
"thesoulcrusher" <TheSoulCrusher@gmail.com> writes:
> Steve,
>
> I had similar problems using a Scalar tape library. It is fibre, but it
> operates the same... I ended up having to get atdd drivers for it from
> IBM... Not too much support came from scalar , was sort of a self
> research from HP and myself.
>
> Atdd is a driver for tape libraries, and schgr is the scsi changer
> device drivers, both are needed.

Huh. Thanks for the info. I'll look into it.

Steve

In article <1169502611.095622.79340@l53g2000cwa.googlegroups. com>,
"thesoulcrusher" <TheSoulCrusher@gmail.com> writes:
> I had similar problems using a Scalar tape library. It is fibre, but it
> operates the same... I ended up having to get atdd drivers for it from
> IBM... Not too much support came from scalar , was sort of a self
> research from HP and myself.
>
> Atdd is a driver for tape libraries, and schgr is the scsi changer
> device drivers, both are needed.

So, I've installed atdd and the tapeutil programs. Still isn't helping me.
I'm talking to the tapes OK with the normal OS utilities; what I need is to
talk to the changer. I've tried making the atdd utility claim the changer
with:

/opt/atdd/bin/atdd_claim -c

And that gives me these device files in /dev/rmt:

crw-rw-rw- 1 bin bin 118 0xfffffc Jan 23 08:36 acdd.cfg
crw-rw-rw- 1 bin bin 118 0xfffffa Jan 23 08:36 acdd.ctrl
crw-rw-rw- 1 bin bin 118 0xfffffd Jan 23 08:36 acdd.dbg

But those are not usable with either mtx nor mc. And when I try to list
the device files for the changer with sam, it tells me there are none.

Anything else I can try?

Thanks,
Steve

Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
[deleted]

> But those are not usable with either mtx nor mc.

[Earlier:]

> 0/3/1/0/4/1 mpt HP AB290-60001 PCI/PCI U320 SCSI 2-port 1000B-T ComboAdapter
> (at /dev/mpt5)
> 0/3/1/0/4/1/0.0 schgr HP MSL6000 Series (Autochanger)
> (at /dev/rac/c5t0d0)
> 0/3/1/0/4/1.1.0 stape HP Ultrium 3-SCSI (Tape Drive)
> (at /dev/rmt/c5t1d0BEST)
> 0/3/1/0/4/1.7.0 sctl Initiator
> (at /dev/rscsi/c5t7s0)

Have you tried mc(1) with the /dev/rscsi/c5t7s0 device file?

mc(1) is the only (HP) supported utility for a changer, and mc(1)
requires the SCSI pass through driver (sctl) device file.

--
Frank "Hoping that he still got this right after (nearly) 4 years." Slootweg

In article <45b662a4$0$75077$dbd43001@news.wanadoo.nl>,
Frank Slootweg <this@ddress.is.invalid> writes:
> Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
> [deleted]
>
>> But those are not usable with either mtx nor mc.
>
> [Earlier:]
>
>> 0/3/1/0/4/1 mpt HP AB290-60001 PCI/PCI U320 SCSI 2-port 1000B-T ComboAdapter
>> (at /dev/mpt5)
>> 0/3/1/0/4/1/0.0 schgr HP MSL6000 Series (Autochanger)
>> (at /dev/rac/c5t0d0)
>> 0/3/1/0/4/1.1.0 stape HP Ultrium 3-SCSI (Tape Drive)
>> (at /dev/rmt/c5t1d0BEST)
>> 0/3/1/0/4/1.7.0 sctl Initiator
>> (at /dev/rscsi/c5t7s0)
>
> Have you tried mc(1) with the /dev/rscsi/c5t7s0 device file?
>
> mc(1) is the only (HP) supported utility for a changer, and mc(1)
> requires the SCSI pass through driver (sctl) device file.

Yes, I did. It says: ERROR: I/O error
c5t7d0 would be the device ID for the bus controller.
I don't see how that would translate into being the library controller...

But (consulting the scsi_ctl man page) I made the
device /dev/rscsi/c5t0d0 as follows:
# cd /dev/rscsi
# /usr/sbin/mknod c5t0d0 c 203 0x050000

And that works:
# mc -p /dev/rscsi/c5t0d0 -r IDSM
MT_slot_1 EMPTY
IE_slot_1 EMPTY
DT_slot_1 EMPTY
DT_slot_2 EMPTY
ST_slot_1 FULL
ST_slot_2 FULL
ST_slot_3 FULL
ST_slot_4 FULL
ST_slot_5 FULL
ST_slot_6 FULL
ST_slot_7 FULL
ST_slot_8 FULL
ST_slot_9 FULL
ST_slot_10 FULL
ST_slot_11 FULL
ST_slot_12 FULL
ST_slot_13 FULL
ST_slot_14 FULL
ST_slot_15 FULL
ST_slot_16 FULL
ST_slot_17 FULL
ST_slot_18 FULL
ST_slot_19 FULL
ST_slot_20 FULL
ST_slot_21 EMPTY
ST_slot_22 EMPTY
ST_slot_23 EMPTY
ST_slot_24 EMPTY
ST_slot_25 EMPTY
ST_slot_26 EMPTY
ST_slot_27 EMPTY
ST_slot_28 EMPTY
ST_slot_29 EMPTY

How do I make that be a permanent thing?


Thanks,
Steve

Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
> In article <45b662a4$0$75077$dbd43001@news.wanadoo.nl>,
> Frank Slootweg <this@ddress.is.invalid> writes:
> > Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
> > [deleted]
> >
> >> But those are not usable with either mtx nor mc.
> >
> > [Earlier:]
> >
> >> 0/3/1/0/4/1 mpt HP AB290-60001 PCI/PCI U320 SCSI 2-port 1000B-T ComboAdapter
> >> (at /dev/mpt5)
> >> 0/3/1/0/4/1/0.0 schgr HP MSL6000 Series (Autochanger)
> >> (at /dev/rac/c5t0d0)
> >> 0/3/1/0/4/1.1.0 stape HP Ultrium 3-SCSI (Tape Drive)
> >> (at /dev/rmt/c5t1d0BEST)
> >> 0/3/1/0/4/1.7.0 sctl Initiator
> >> (at /dev/rscsi/c5t7s0)
> >
> > Have you tried mc(1) with the /dev/rscsi/c5t7s0 device file?
> >
> > mc(1) is the only (HP) supported utility for a changer, and mc(1)
> > requires the SCSI pass through driver (sctl) device file.
>
> Yes, I did. It says: ERROR: I/O error
> c5t7d0 would be the device ID for the bus controller.
> I don't see how that would translate into being the library controller...
>
> But (consulting the scsi_ctl man page) I made the
> device /dev/rscsi/c5t0d0 as follows:

Good! Most people don't find their way to the scsi_ctl(7) manual page.
You can be proud of yourself!

> # cd /dev/rscsi
> # /usr/sbin/mknod c5t0d0 c 203 0x050000
>
> And that works:

Good!

> # mc -p /dev/rscsi/c5t0d0 -r IDSM
> MT_slot_1 EMPTY
> IE_slot_1 EMPTY
> DT_slot_1 EMPTY
> DT_slot_2 EMPTY
> ST_slot_1 FULL
> ST_slot_2 FULL
> ST_slot_3 FULL
> ST_slot_4 FULL
> ST_slot_5 FULL
> ST_slot_6 FULL
> ST_slot_7 FULL
> ST_slot_8 FULL
> ST_slot_9 FULL
> ST_slot_10 FULL
> ST_slot_11 FULL
> ST_slot_12 FULL
> ST_slot_13 FULL
> ST_slot_14 FULL
> ST_slot_15 FULL
> ST_slot_16 FULL
> ST_slot_17 FULL
> ST_slot_18 FULL
> ST_slot_19 FULL
> ST_slot_20 FULL
> ST_slot_21 EMPTY
> ST_slot_22 EMPTY
> ST_slot_23 EMPTY
> ST_slot_24 EMPTY
> ST_slot_25 EMPTY
> ST_slot_26 EMPTY
> ST_slot_27 EMPTY
> ST_slot_28 EMPTY
> ST_slot_29 EMPTY
>
> How do I make that be a permanent thing?

How do you make *what* a permanent thing? The device file? That will
stick, i.e. also after a reboot.

If you mean that you had to do it manually and would like it to be
done automatically, it can't. That's the nature of the beast. The SCSI
Pass-Thru driver is exactly that, pass-thru. I.e. the driver has no
knowledge at all about what device it is talking to (in this case the
robot of the Autochanger) and hence *cannot* configure automatically
(like for example the stape driver can), so you have to do it manually.

Sorry for not pointing you directly to the scsi_ctl(7) manual page. I
could (should? :-)) have realized that you probably would not be aware
of it, because you didn't say that you had created a device file
yourself. My excuse is that I haven't touched an HP-UX system nor this
subject matter in nearly four years! :-)

In article <45b68a4c$0$70117$dbd45001@news.wanadoo.nl>,
Frank Slootweg <this@ddress.is.invalid> writes:
> Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
>> But (consulting the scsi_ctl man page) I made the
>> device /dev/rscsi/c5t0d0 as follows:
>> # cd /dev/rscsi
>> # /usr/sbin/mknod c5t0d0 c 203 0x050000
>>
>> How do I make that be a permanent thing?
>
> How do you make *what* a permanent thing? The device file? That will
> stick, i.e. also after a reboot.

Well, I figured that since it was able to automatically create all the other
device files, that there was probably some mechanism that one could invoke
to have the autochanger device file automatically created as well. So if
the changer were to be switched around to another SCSI port, or if some
system upgrade required all the device files to be rebuilt, etc.

> If you mean that you had to do it manually and would like it to be
> done automatically, it can't. That's the nature of the beast. The SCSI
> Pass-Thru driver is exactly that, pass-thru. I.e. the driver has no
> knowledge at all about what device it is talking to (in this case the
> robot of the Autochanger) and hence *cannot* configure automatically
> (like for example the stape driver can), so you have to do it manually.

OK. I'm going to have to read more about this Pass-Thru thing, as I fail
to see how the system can recognize a device but fail to create a device
file that is useable by the system's own utilities...

> Sorry for not pointing you directly to the scsi_ctl(7) manual page. I
> could (should? :-)) have realized that you probably would not be aware
> of it, because you didn't say that you had created a device file
> yourself. My excuse is that I haven't touched an HP-UX system nor this
> subject matter in nearly four years! :-)

I've been a SGI admin for many years, and can usually find what I need if
given sufficient clue. But I'm new to HP admin. SGI IRIX also finds and
configures tape libraries, and the device files it creates are usable with
programs like mtx. This is the first time I've encountered a situation
where I had to manually create the device file. It doesn't help that I'm
becoming an Old Man, and it's taking longer for info to sink in. ;-)
(And actually, I hadn't created the working device file until immediately
prior to the previous post... And guess what -- it works with mtx, too! :-)

Thanks,
Steve

Steve Allen <allen@doobie.itdl.ds.boeing.com> wrote:
> In article <45b68a4c$0$70117$dbd45001@news.wanadoo.nl>,
> Frank Slootweg <this@ddress.is.invalid> writes:
[deleted]

> > If you mean that you had to do it manually and would like it to be
> > done automatically, it can't. That's the nature of the beast. The SCSI
> > Pass-Thru driver is exactly that, pass-thru. I.e. the driver has no
> > knowledge at all about what device it is talking to (in this case the
> > robot of the Autochanger) and hence *cannot* configure automatically
> > (like for example the stape driver can), so you have to do it manually.
>
> OK. I'm going to have to read more about this Pass-Thru thing, as I fail
> to see how the system can recognize a device but fail to create a device
> file that is useable by the system's own utilities...

The point is that the pass-thru driver does *not* "recognize a
device". I.e. it doesn't know what a robot is, or any other device for
that matter. That's why you need to manually create the device file and
tell it (the driver) all it needs to know.

[deleted]

> (And actually, I hadn't created the working device file until immediately
> prior to the previous post... And guess what -- it works with mtx, too! :-)

Great!

> Thanks,

You're welcome. I'm glad that my comment helped you solving the
problem.