HPC1533A DAT on SunOS 4.1.3_U1
2007-12-25 8:48:00
Summary.
1. Setting the DIP switches.
2. Modifying the kernel (is this optional ?).
3. Activating compression ... unresolved question.
4. Parameters for dump
5. Contacting HP.
1. Setting the DIP switches.
On the underside of the HPC1533A is a row of 8 dipswitches, let us number
them as:
12345678
When I got mine setup for the mac they were:
12345678
11011111
and the driver couldn't access the tape.
I am told by HP technical support, that the Mac setup should be:
12345678
11111111
and the SunOS setup:
12345678
11111000
which is what I am using right now and it works, without touching the
kernel.
I am told that one can use:
12345678
11011001
also without touching the kernel, or:
12345678
00111001
... this suggestion pointed out that switches 1 and 2 control compression,
and that by having them both off enabled hardware compression and the
host has no control.
Which raises the question of how the host could have control ?
2. Modifying the kernel (is this optional ?).
Using the 11111000 dip switch setting the drive works ... it reads a DAT
from another type of system without problems, and seems to handle writing
about 1.5 to 2 GB or already compressed (gzipped) data before giving an
unexpected EOF (on a 90m tape). This is without modifying the kernel.
The following suggestions were offered for stdef.h and st_conf.c:
#define ST_TYPE_HPC1533A 0xnn /* HP C1533A DDS-2 DAT */
and extended the st_drivetypes array in st_conf.c with:
{
"HP C1533A 4mm DAT", 14, "HP C1533A", /* NB. spaces */
ST_TYPE_HPC1533A, 10240,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE),
6000, 6000,
{ 0x00, 0x00, 0x00, 0x00 },
{ 0, 0, 0, 0 }
}
What does putting this in achieve ? Maybe setting the default record size
to 10240 ... what is the significance of this number and does it make
much difference to how much one can fit on the tape or how efficient the
transfer is ? I don't know.
3. Activating compression ... unresolved question.
It is my understanding that the
{ 0x00, 0x00, 0x00, 0x00 },
{ 0, 0, 0, 0 }
are used as density settings sent to the drive depending on whether one
accesses /dev/rst0 or rst8 or rst16 or rst24 and that using zeroes doesn't
make use of this mechanism. What the ST_AUTODEN_OVERRIDE flag does I also
don't know.
Presumably, when writing to a tape, it is possible to send density
requests to set the type of write and compression, to either maximize
storage or portability to those with other drives. I suspect that setup
as I have it now, hardware compression is turned off by default (dip
switches 1 and 2 on), and the driver makes no attempt to activate it.
When I find out what density values to send to the drive I will fill this
space.
4. Parameters for dump
One suggestion for an Archive Python DAT was:
dump 0uctbsdf 1 126 5000 61000 /dev/nrst0 /dev/sd0a
this is a blocking factor of 126 by 512 byte blocks in a single write (ie.
64512 bytes), a density of 61000 BPI (cf. QIC of 1000 or Exabyte 54,000) and
a length of 5000 feet (1515 metres, cf. 6000 for an Exabyte), and 1 track.
How these parameters are derived, and for what tape length, I have no
idea, nor have I tried them.
5. Contacting HP.
East coast technical support phone 617-221-5101.
Document orders 800-227-8184.
HP C1533A user's manual part number C1533-90900.
(I haven't got mine yet, but I will fill this space when I do.)
Hope this helps ... and thanks for yours ... david
---
David A. Clunie (dclunie@flash.us.com)
In sunny Riyadh, Saudi Arabia.
"I have actually seen your DICOM 3 conformance statement ...
... but now I can't afford to buy (price of oil is too low)."
Comments
Got something to say?
You must be logged in to post a comment.
