From: Vincent Zocca (
Date: Thu Jul 15 1993 - 05:34:09 CDT

Ok folks, here it is! The HP354XXA summary.

I have had quite a few reaction on the question I posted last week
about an HP drive I have.

Today, two weeks after having consulted my dealer about the drive,
I received a fax from him of HP documents about this matter. I
typed the fax over and included it in this posting.
Also I will include the mail I got from (Dave Guidry) which summarises mails
he got from (in order of appearance) (Ron
Nash), (Mark Holcomb) and
(Jochen Bern).

Apologies to the people I donUt mention!!!

(I have to remark that I did what Ron Nash wrote which works fine)


| Vincent Zocca | University of Amsterdam, Fac. of Med. |
| | Acad. Med. Centre, Room D01-411 |
| | Meibergdreef 9, 1015 AZ Amsterdam |
| | The Netherlands, (+31) (0)20 5662010 |

HP fax on


3. SUN Workstations

Hewlett PackardUs HP35470/80A DDS drives are easy to configure for
use in the SUN Unix workstations environment. The simple switch
settings defined in the table below allow HPUs drives to Tplug and
playU with SunUs workstation products that have internal SCSI

In this mode, the drive ignores the Mode Select command that turns
off the driveUs buffer when using the default driver (invoked
because the drive is not listed in the Sun O/s lookup table), and
performance is not impacted. This will work in all Sun $.X O/s

The following table lists the switch settings required to operate
the HP35470/80A in the Sun environment. Note that the position of
switches 1 and 2 are only valid for the HP35480A, control the
compression capabilities of the drive only, and do not affect the
configuration of the drive with respect to the Sun or any other

MRS Disabled
Switch Settings System Changes ReqUd Comments
6,7,8=0 0,1,2,3,4,5=1 None Ignores Mode Select and Non-Immed FM

MRS Enabled
Switch Settings System Changes ReqUd Comments
6,7=0 0,1,2,3,4,5,8=1 None Ignores Mode Select and Non-Immed FM

Other Hints for SUN

SUN requires that the SCSI address of Tape devices be either 4 or
5. If the address is set to 4, the Trst0U or Tnrst0U drivers are
used. If the address is 5, Trst1U or Tnrst1U is used.

When using the TcpioU command, be sure to get the tape size option
(-B) so that you use the block size of 5120 or grater. This will
improve performance significantly.

When using the TdumpU command, set the tape size (-s) and density
(-d) parameters to 15000. This will allow you to fill a 90m tape.
The defaults for the TdumpU command are setup for QIC drives, and
will result only about 600 Mbytes.



3. Appendix C - Optimising SUN Systems for the HP354XXA

It is now possible to modify the device definition files in the SUN
workstations to optimise the performance of the HP35470/80A in Plug
and Play applications.

The following changes should be made to the files listed below.

1. In the file /user/sys/scsi/taergets/stdef.h add the following
line after the entry defining an Exabyte device:
#define ST_TYPE_EXABYTE 0x28 /*Exabyte*/
#define ST_TYPE_HP1 0x29

2. In the file /user/sys/scsi/taergets/st_conf.c add the following
paragraph after the Exabyte entry:

/* Exabyte 8mm cartridge */
        RExabyte 8mm Helical ScanS, 7, RExabyteS,
        5000, 5000,
        { 0x00, 0x00, 0x00, 0x00 }
        ( 0, 0, 0, 0 }
(New Paragraph Starts Here)
/* HP 4mm Helical Scan */
        RHP-354XXA 4mm DATS, 2, RHPS,
        6000, 6000,
        { 0x00, 0x00, 0x00, 0x00 }
        ( 0, 0, 0, 0 }

3. Recompile your kernel, and then you are ready to start backing
up files to the HP354XXA tape drive. These changes should result in
a transfer rate on the order of 6-11 MBytes/minute, depending on
the UNIX command used.

HP fax off

In article <> you write:
>I seam to have a little problem writing to an HP DAT tape drive
>I run SunOS 4.1.3 on a SPARCStation 10.
>To run a test I try to dump an almost empty partition of a disk
>(sd1g) to the tape.
>When I try to dump to it I type the following line:
>root@amcnol:/> dump 0dsf 61000 57440 /dev/rst0 /dev/rsd1g
>The system then says:
> DUMP: Date of this level 0 dump: Wed Jul 7 12:33:18 1993
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rsd1g (/var4) to /dev/rst0
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 96 blocks (48KB) on 0.00 tape(s).
> DUMP: NEEDS ATTENTION: Cannot open volume. Do you want to retry the
>open?: ("yes" or "no") no
> DUMP: The ENTIRE dump is aborted.
>It doesnUt matter if I type TyesU at the ATTENTION prompt. If I do
>the same question prompts again and again.
>dmesg says:
>esp0 at SBus slot f 0x800000 pri 4 (onboard)
>st0 at esp0 target 4 lun 0
>st0: <Vendor 'HP ' Product 'HP35470A '>
>st0: Generic Drive, Vendor=<HP >
> 3.81mm helical scan cartridge
> Variable record length I/O
>What am I doing wrong? Is it the device? Or, something else?
>Btw, the tape I loaded is NOT write protected. I checked that
>one al right.


     I recently installed an HP35470A on a 4.1.1 system. I beleive
part of your problem is related to the settings of the DIP switches.
I am including the correspondence I have which is related to this.
There are 3 variants of the 35470A, and from your description, you
would seem to have the same version that we have (since I got the
same error on one of the following configurations). I will include
THAT information first.

3 messages follow, two are from nash, one is from bern. I got the
same error you did when following bern's instructions, nash's worked

>From: (Ron Nash)

Be sure you have the following set up in your kernel and on the dip
switches on the bottom of the DAT drive:

Add the following line to /sys/scsi/targets/stdef.h:
ST_TYPE_HPDCDAT 0x2a /* HP Data-Compression 4mm DAT */

Then add the following to the st_conf.c after ST_TYPE_EXB8500
paragraph and recompile your kernel:

/* HP 4mm DAT cartridge */
        "HP-35480A 4mm data-compression DAT", 9, "HP 35480A",
        ST_TYPE_HPDCDAT, 10240,
        { 0x00, 0x00, 0x00, 0x00},
        { 0, 0, 0, 0 }

These parameters are defined in stdef.h as:
struct st_drivetype {
        char *name; /* Name, for debug */
        char length; /* Length of vendor id */
        char vid[24]; /* Vendor id and model (product) id
        char type; /* Drive type for driver */
        short bsize; /* Block size */
        int options; /* Drive options */
        int max_rretries; /* Max read retries */
        int max_wretries; /* Max write retries */
        u_char densities[NDENSITIES]; /* density codes, low->hi
        u_char speeds[NSPEEDS]; /* speed codes, low->hi */

Change the switch settings to (1,2 On - 3 Off - 4,5 On - 6,7,8 Off)

And when doing a dump the following command line gives about 1.7GB.
Change the first number (1500) to 3000 for 3.5GB. I would not go much
beyond 3.5GB unless you know your files compress well. A 60 meter DAT
should hold 5GB compressed according to HP, but I feel they are very
optimistic in how compressible our files are.

dump 0ucsdf 1500 15000 /dev/rst0 /home |& tee home.log

             ,--, | Ron Nash      San Diego State University
       _ ___/ /\| |
   ,;`( )__, )  ~ |  
  //  //   '--;   | Gin-N-Tonic   Learning to be an endurance horse
  '   \     |     | Luv on Fire   trusty trail horse

--------8<----------------8<----------------8<----------------8<-------- >From: (Ron Nash)

> > Thanks! > > ->/* HP 4mm DAT cartridge */ > ->{ > -> "HP-35480A 4mm data-compression DAT", 9, "HP 35480A", > -> ST_TYPE_HPDCDAT, 10240, > -> (ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE), > -> 6000,6000, > -> { 0x00, 0x00, 0x00, 0x00}, > -> { 0, 0, 0, 0 } > ->}, > > Are you sure that the block size is 10240? Or is that a typo and > it should be 1024? > > I await your reply: I'm not keen on rebuilding kernels more than > I have to again. :)

Yes - that is what I am using and what Western Scientific recommended. We bought the drives thru Western Scientific.


--------8<----------------8<----------------8<----------------8<-------- >From: (Mark Holcomb)

I have the same configuration (sparc2 running 4.1.2 with DAT) as you have and my HP 35480A has problems as well dumping filesystems over about 200 Mb (like /home).

As I am sure you are aware, HP doesn't talk to mere mortals and if your vendor is like mine they are clueless.

The first thing to realize is that there are about 3 versions of the 35480A out there. I have personally used what appears to be the earliest version hanging off of a SparcServer 670/MP (scsi card in a VME bus) and it works fine.

The DAT I have problems with appears to be the latest model available and it is hanging off the sparc2 (with a hole cut in the bottom of the drive case giving access to the dip switch block). Some people I have talked to have to disassemble their drives to get at the dip switches.

The HP product sheet says to set the dip switches to 1-5 on and 6-8 off. This makes the drive ignore write/thru commands and buffer data that is sent to it (so you don't have to reconfigure your kernel). Also fixes the DOA behavior where a mt -f /dev/rst? status returns *No tape loaded or drive offline*

However, when I try to dump large partitons, the tape drive still causes the scsi bus to be reset (thus aborting my dump).

I have of course tried adding the patches below and rebuilding the kernel add to st_conf.c:

{ "HP DAT", 24, "HP HP35480A ", ST_TYPE_HPDAT, 10240, (ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE), 5000, 5000, { 0x00, 0x00, 0x00, 0x00 }, { 0, 0, 0, 0 } },

add to stdef.h:

#define ST_TYPE_HPDAT 0x31 /* HP DAT */

that have been suggested in various news groups but these do not appear to fix the problem either (though they do make the sun recognize the drive as being a buffered scsi device, ie you can leave DIP switch 6=on and not take a data transfer rate hit).

I am able to dump smaller filesystems to the tape drive and tar large ones like home. I don't think the dumps are terribly reliable, but I can do a level 0 of everything on the system every night so I don't worry about loosing files. Per the sheet from HP the dump paramaters I use are:

dump 0fds /dev/rst? 15000 15000 /filesystem

However, the dump paramaters do not appear to affect how the tape drive operates. I have used d=56000 s=6000 b=126, s=200000, and many other variations with the same results.

I also hung the tape drive off a remote IPC and tried to do dumps to it over the network. The only reason I mention this is that the dump caused the LOCAL machine's scsi bus to be RESET!!! This tends to indicate that the problem is not caused by the tape drive so much as by the commands that are being issued to the scsi bus while a dump is being performed to the DAT. I have talked to other people that have suggested that the problem may be that the new HP drives operate as sync scsi devices when hanging off a scsi bus where there are other sync scsi devices and the chip-set used by sun in the older sparcs broke easily doing sync scsi. If you happen to have a newer Sbus SCSI card, try hanging the DAT off the new SCSI card instead of the built in scsi connector. Hmm, other stuff. I have tried loading several versions of the firmware onto the tape drive without effect either (the HP drive will load another version of the firmware from a special DAT tape that comes from HP).

I have been brief here because I expect you have tried many of the things in the list here as well and will recognize them. Also, if you would like more details about anything I have alluded to above, let me know and I will be happy to give you all the gory details.

If you have tried things not on this list I would appreciate knowing about them so I can put them on my growing list of things that DON'T fix the problem.

-- ----------------------------------------------------------------------------- Mark Holcomb (706)542-0865 office Driftmire Engineering Center, (404)722-6803 pager Athens, GA 30602-4435 -----------------------------------------------------------------------------

--------8<----------------8<----------------8<----------------8<-------- >From: (Jochen Bern)

In comp.sys.sun.admin you write: >I've hooked up an HP DAT drive to a Sparc 2 running SunOS 4.1.2, > and I can't seem to get it to dump correctly. Can someone help me out >and give me the right dump params for a 60 minute DAT tape?

This is *definitely* a FAQ ... here I send it for the sixth Time in four Weeks! Regards, J. Bern


Seeing all these Posts about "How to connect DATs", I conclude that us Krauts are just lucky since HP gives us a good, usable How-To Sheet.

Here's my That's_About_It (tm) Translation; I put "<!>" wherever the Info could be subject to a Housing supplied / Assembly done by your Vendor.


HP 35480A =========

Jumper Switch Settings ----------------------

<Jumpers are numbered 1-5 from the Middle of the Rear View to the Side> 1: term power 2: SCSI Id Bit 0 (1) 3: 1 (2) 4: 2 (4) 5: DC on/off using ext. Cable

<!> Assembled Subsystems will have Switches on the Back to set the SCSI Id. <!> We deliver the Drive with Id 4 (/dev/rst0).

Further Configuration can be done with the Dip Switches on the Bottom of the Device. Set the Switches to 1, 2 on, 3 off, 4, 5 on, 6, 7, 8 off normally.

Termination -----------

<!> We deliver the Drive with Terminators pulled out.

LED Status Codes ----------------

Green - Blink.Green: Caution, Media Wear. Amber - Amber: Termination / high Humidity Blink.Amber - Blink.Amber: Self Test in Progress Blink.Amber - off: Self Test failed

Configuration -------------

1. In /sys/scsi/targets/st_conf.c, add: <Note that this seems to mean only SunOS 4.1.x, or am I wrong?> /* HP DAT HP35480A */ { "HP35480A", 2, "HP", ST_TYPE_EXABYTE, 1024, ( ST_VARIABLE | ST_BSF | ST_BSR ), 5000, 5000, { 0x00, 0x00, 0x00, 0x00 }, { 0, 0, 0, 0 } }

2. cd /sys/sun4c/conf <Note that this assumes you use config GENERIC a sun4c Machine and a GENERIC cd ../GENERIC Kernel, and that you're currently make logged into THAT Machine, AND mv /vmunix /vmunix.old that it is where you build Kernels, mv ./vmunix /vmunix too>

3. Reboot

4. Dump with:

dump 0ubdsf 126 27000 <Size> /dev/rst0 /dev/sdXX

where /dev/sdXX is the Drive you want to dump, and Size is: 60 m Tapes: 24000 compressed, 6000 non-compressed 90 : 36000 9000

<and where you should replace /dev/rst0 with the Device Name you REALLY used for the DAT Drive :-)>

Remark ------

Compression can't be software controlled on SUNs; You have to manipulate the first two Dip Switches. If both are on, Compression is on. <!> We deliver the Device with Compression turned on. J. Bern -- / \ I hate NN rejecting .sigs >4 lines. Even though *I* set up this one. /\ / J. \ EMail: bern@[TI.]Uni-Trier.DE / ham: DD0KZ / More Infos on me from / \ \Bern/ X.400 Mail: S=BERN;P=Uni-Trier;A=dbp;C=de / X.400 Directory, see \ / \ / Zurmaiener Str. 98-100, D-W-5500 Trier / X.29 # 45050230303. \/

-- David A. Guidry | We must be devious, cunning, inventive... Distributed Systems Services | ... too bad we're us. -- Raw Toonage Academic Computing and Network Services|<><dawidge@nuacvm.bitnet>

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:00 CDT