Adding a non-HP SCSI tape drive

[Michael D. Zorn]

We have an old server (HP-UX 10.01 - in the process of retiring it) that has two 7980 tape drives. Both have failed. We decided to save a lot of money last year by not renewing hardware maintenance (3rd party).

Suddenly there's a need to read 9-track tapes - to get the data off tape onto a file server.

There's an Overland Data desktop tape drive that was hooked to a Sun (with SCSI-1/Centronics 50-pin) that I brought over here.

I connected it, and ran ioscan -fn.

Output shows that it found an HP 88780, at 10/4/4.5.0, class tape, driver tape2, with dev files
/dev/rmt/5m, 5mb, 5mn, 5mnb, snd
/dev/rmt/c1t5d0BEST, ...b, ...nb

(Evidently it's some sort of HP 88780 equivalent (I found some on Google), and a search here shows a post for "7980 (88780)" drive, so maybe theyre sorta equivalent.

The drive has been working in a Sun/Solaris system.

When I try to access it (it's OnLine, BOT), I get

#mt -t /dev/rmt/5m rewind
/dev/rmt/5m: I/O error

(same for all the atlternate /dev/rmt/5* addresses)

One odd thing is that the drive that used to be at that SCSI plug (it was /dev/rmt/0h) came up in the ioscan as

10/4/4.0.0, class tape,
driver tape2, /dev/rmt/0h

One question is, if a device is SCSI, and the cables connect, and ioscan sees it (and the driver is in there), shouldn't it just work without further ado?

Since the driver is there, I shouldn't need to run insf, and because the /dev/rmt files are there, I shouldn't need to run mksf.

The other question is, why does the old tape show up at 10/4/4.0.0, and the new one at 10/4/4.5.0? They're connectd to the same SCSI port on the HP. And there was nothing in the old ioscan at 10/4/4.5.0
Does part of the hardware address come from inside the device?

[skt_skt]

could u paste the ioscan output for the tape drive

mt -t /dev/rmt/5m(n) status

target selection can be done from the tape drive itself(there is selection switch on the rear side which can be set 0-7)

[A. Clay Stephenson]

The difference in the HW paths is due to the SCSI (target) ID set on the tape drive itself. This may be set via a dip switch, jumpers, or more commonly a rotor swith with '+' and 'i' buttons to push and a visual indicator indicating the current ID. In rare cases, the ID might be set via a firmware-based control program but something this old generally has switches or jumpers.

There is a good change that you can get this guy to work as this seems to be SE-SCSI (all there was back then). You now need to check that the bus is terminated in EXACTLY two place -- on the physical ends of the cable. You also need to make certain that at least one device on the bus supplies termination power, that there are no duplicate ID's on the bus, and that maximum SE SCSI bus length is not exceeded.

[tkc]

this is a SE-SCSI tape device. Scsi address are from 0-6. SCSI address selection is via the front panel of the 7980 tape drive.

[Steven Schweda]

> [...] tape drive that was hooked to a Sun
> [...]

Historically (back at least as far as SunOS
4.x), a tape drive on a Sun system is likely
to be at SCSI ID 5.

> We decided to save a lot of money last year
> by not renewing hardware maintenance (3rd
> party).

If you're shuffling hardware around without
checking the SCSI ID values, this may not
have been a wise move. It's not unusual to
lose data on a disk when there's an ID
conflict on a SCSI bus.

What else is on that SCSI bus (at which IDs)?
(If there is an ID conflict, a physical
inventory may be more trustworthy than an
ioscan probe.)

[Bill Hassell]

> One question is, if a device is SCSI, and the cables connect, and ioscan sees it (and the driver is in there), shouldn't it just work without further ado?

Not at all. Really old tape drives had almost nothing in common with their SCSI command language. Standardization for tape drives began around the time that 8mm Exabyte drives started shipping but it was a mess for years. DDS drives did a lot to define common communication commands.

Whether it works on the Sun box is irrelevant -- you need to change the tape drive to emulate the 7980 (88780) if possible. The ioscan device ID may indicate that at least one of the required switches is set but you'll need a tech ref manual for the drive to set it to HP-UX compatibility mode.

[Michael D. Zorn]

Thanks to everyone for the replies.

Santhosh: Our old version of mt doesn't recognize 'mt ... status'. The ioscan lines are below, in the reply to Steven.

There aren't any selection switches on the drive - there aren't any on any of our SCSI peripherals - at least, not outside the chassis.

Clay: Yes, it is SE SCSI. The cable starts from the HP (the same slot as the old (non-working) drive), goes to the new drive (the same plug as it was connected on the Solaris system), and the terminator is in place in the adjacent slot.

There may be a setting switch inside the new drive, but I hesitate to take it apart, as it's somebody else's. However, if that's what it takes.....

What's termination power? It's probably there, since it's the port that fed the old tape drive.

That's the only thing on that line. It goes HP - new tape - terminator. It's the only ioscan item in 10/4/4.

tkc: I have the front-panel rocker switches on the 7980. These are what failed the last two times. The switches don't make contact, or the sensing circuit doesn't work.

There's no equivalent on the new drive (an Overland Data desktop drive).

Steven: "Historically, ... ID 5 ...". That might explain the ioscan seeing [rats - that somehow dropped out of my original post - here it is]

tape 5 10/4/4.5.0 tape2 CLAIMED DEVICE HP 88780

then a list of /dev files:
/dev/diag/rmt/c1t5d0
/dev/rmt/5m
... and so on

"...not a wise move ..."

Ooops. The previous ioscan shows
ext_bus 2 10/4/5 lpr2 ... HP 28655A
and
ext_bus 5 10/4/12 scsi1 ... HP 28655A

Those would be printers we don't have any more. (I've done quite a few reboots along the way. They all report all FS OK.)

Bill: "... HP-UX compatibility mode." That seem to be the show-stopper. But Clay seems optomistic.

So the next question is, suppose the new drive is really set to ID 5, and the ioscan sees something at 5, and there are dev files at 5, ..., shouldn't it work?

[A. Clay Stephenson · Accepted solution]

I would be tempted to run rmsf and then insf on these device nodes. On the newer HP-UX releases there are more data encoded in the minor device number (e.g. blocksize, compression, density) than there bits to encode them. Instead, the reserved minor device number bits serve as an index into a table that contains additional data. This means that identical tape device nodes with the same major/minor device tuples can behave differently on different boxes. I don't know if this applies to 10.01. You need to study the section 7 man pages for that.

In any event, using mt is a little too much to expect for this old gal. I would confine my operations to dd, tar, and/or cpio. You can use dd to specify blocksizes that are multiples of the native blocksize to improve performance. You can also use dd combined with the no-rewind devices to position the tape. Simple dd to /dev/null. This was the standard procedure for all flavors of UNIX.

[Michael D. Zorn]

rmsf &c is probably more surgery than we want to do here. Management has decided that the situation is hopeless, abandon ship, &c. The computer is slated for shutdown as soon as we get the files off and the programs checked - probably by year-end.

So I'll be seneding back the Overland.

(PS: dd didn't work either. Got an i/o error.)

[TwoProc]

It's been a long time, but I remember there being companies out there that will take your pile of tapes and give you pack a set of CD's DVD's, etc for the tapes. Charges back then were pretty nominal, about $150 per tape. Of course, that was over 10 years ago, and we didn't have but 40 tapes or so to convert.

The point is, if needed there are companies out there that do this.