• Please review our updated Terms and Rules here

Source foir HP-UX v 9

Tapes are not straight forward to image. The tape formats (e.g. ANSI tapes, and derivates) often rely on headers and records of different record lengths, and sometimes the record length is part of the tape format definition itself and thus important. Then there are EOF (end-of-file) marks, and sometimes other markers but EOF and EOT (end-of-tape) is what's important. Sometimes EOT is just arbitrarily defined as two EOFs in a row, and sometimes, for multi-volume tapes, all but the last tape in the volume will define EOT as two EOFs and the last tape will use three EOFs. Sometimes EOT is just EOD (end of data, where nothing is written).

If you use the 'dd' command you lose all of that information. When imaging floppies this almost never matters, because the record size is usually fixed - it's the sector size, and there's no physical EOF (sometimes floppies may be written to as tape volumes and then things are slightly different).

When I image tapes I use a simple program I once wrote. When it reads from tape and writes to a file it will write a 4-byte word with the record size, then the record itself. Then another 4 bytes with the size of the next record, and so on. I encode EOF as a 4-byte word with zero. The program can write such files back to tape again, there's enough information in this simple file format to re-create the correct record sizes on the tape, including e.g. the tape label. When it reads from one tape and writes to another it'll handle all of that implicitly, it's a great way of making exact copies of tapes. These days I mostly use it to make images of my old precious tapes.

Then I have additional programs to read these tape copy files and extract content, these programs will of course have to know what format was used on the tape, e.g. ANSI tape, or disk copy or whatever. These tools typically started as tools that could read the tapes themselves, then I just added a part which could use those files as input instead - they contain all the necessary record information after all.

-Tor
 
Tor,

Would you be willing to share the program(s) that you developed to make and read the tape copies - it would be easier (and far quicker) to adapt your code to this situation, than writing it from scratch. I was able to get my workstation running today, but I have not checked/tested the tape drive yet. One of my HD's appears to be offline (out of 3 330MB disks). I don't know if this is temporary or not.

- Juror22
 
What kind of C compiler do you have on your system? I assume your tape drive is connected to the HP-UX 7.1 system? Or can it be connected to something newer? It's been years since I did anything on HP-UX but I remember it as extremely painful in every respect.. so I would think its C compiler is as quirky as well.
With my tape copy program there are two issues:
1) It's written for ANSI C (think GCC or SGI MIPSPro. Hm, I think I added AIX support too.)
2) It needs to know about a few details of the tape drive interface on the system (because 'mt' I/O calls etc. aren't universally standardized).
The tape drive must also support variable sized records. Of course, if it doesn't, then that means that every tape written must be fixed-size records and then it's safe to use 'dd' to read the tape. But ANSI tape formats and derivates all relied on the tape drive to support variable size records.

-Tor
 
I have a std (hp) c compiler and you are correct that the tape drive is connected to this (HPUX 7) system. I don't have anything else with an HP-IB interface, although it appears that you can connect it to other devices (there are PCI cards for this connection type, but I don't have them).
1) I used to write, maintain and port c pgms on HP_UX (ANSI, std (hp) c and ProC) so I hope that won't be an issue.
2) I don't know the details yet, but I have found some interesting reading that seems to indicate that they are fixed sized records -> http://www.access-one.com/rjn/computer/hcdvsqic.txt
"16- and 32-track tapes are preformatted by 3M or a 3M
licensee. A full-track factory write head lays down fixed
physical records on the tape. No 16- or 32-track end-user
drive ever writes on these record headers (called "keys");
only in between them. HP "format" and/or "mediainit" user
processes merely "certify", performing read/write tests,
sparing bad blocks and updating logs."

...which would mean that a dd would be able to capture the tape information correctly?
I checked the tape drive today and found that the pinch roller appears to be ok - it felt a little tacky, but not gooey, I will try it with some backup and other tapes that I have, before I attempt anything with the HPUX install tapes.
 
I usually call those tapes "Iotamat" (3M's name for them). They were used by a number of vendors (Adic being one). No lights sensing BOT/EOT holes; it's all done with the (pre-recorded) format. The drive interface itself is something primitive, like QIC36.

I keep an Iotamat drive around just in case. The curious thing is that it uses a 6502 microprocessor with a 3M-copyrighted EPROM. I don't know if all Iotamat drives are this way, but it wouldn't surprise me.

If you put a plain old DC600A tape in, the tape will spin for a bit, then error out.

The good news is that you can still find the tapes NOS if you look hard enough. The bad news is that if they're too old, the polyurethane tension band in the cartridge is probably shot.

The pinch roller size isn't terribly critical because the data format is self-clocking. And there are people who will rebuild the roller as good as new if you've a mind to let someone else do it.
 
...which would mean that a dd would be able to capture the tape information correctly?
I checked the tape drive today and found that the pinch roller appears to be ok - it felt a little tacky, but not gooey, I will try it with some backup and other tapes that I have, before I attempt anything with the HPUX install tapes.
You can try this with 'dd':

dd if=/dev/tape bs=65536 count=1 of=t.1

with /dev/tape substituted with your real drive. What the above does is to attempt reading one record off the tape. If the tape drive supports variable sized records (on most systems this mode can be set with an 'mt' command. An 'mt status' command is usually how you check the current mode) then the file 't.1' will have a size equal to 65536, as long as the actual record size is equal to or smaller than what's specified (you could also use e.g. 32768). If the drive doesn't support variable sized records then the 'dd' command will fail, until you specify the exact right record size with 'bs'.

If I repeat the above command (and use a /dev/ device which is set up to not rewind at close) then I can read out the tape record by record (I just change of=t.1 to of=t.2 of=t.3 and so on). For an ANSI tape I would typically end up with files like this:
t.1 (80 bytes)
t.2 (2048 bytes)
t.3 (2048 bytes)
and so on, until t.n of 0 bytes, which would be EOF. Then another 80-byte record, for the next file.

-Tor
 
Hello,

I have cds of 9.04 for series 800. Can make images if anyone needs it.
 
I just noticed I made an error in my posting - and it's after the time limit for edits! So here's the corrected version (changed section in bold):
--
You can try this with 'dd':

dd if=/dev/tape bs=65536 count=1 of=t.1

with /dev/tape substituted with your real drive. What the above does is to attempt reading one record off the tape. If the tape drive supports variable sized records (on most systems this mode can be set with an 'mt' command. An 'mt status' command is usually how you check the current mode) then the file 't.1' will have a size equal to the actual record size (anything up to, but not above, in this case, 65536), as long as the actual record size is equal to or smaller than what's specified (you could also use e.g. 32768). If the drive doesn't support variable sized records then the 'dd' command will fail, until you specify the exact right record size with 'bs'.

If I repeat the above command (and use a /dev/ device which is set up to not rewind at close) then I can read out the tape record by record (I just change of=t.1 to of=t.2 of=t.3 and so on). For an ANSI tape I would typically end up with files like this:
t.1 (80 bytes)
t.2 (2048 bytes)
t.3 (2048 bytes)
and so on, until t.n of 0 bytes, which would be EOF. Then another 80-byte record, for the next file.
--
-Tor
 
Does anyone know of a source for HP-UX version 9? Version 10 and 11 can easily be found, but none of the earlier versions.

I have a couple of HP Series 300 and Series 200 computers I would like to install HP-UX on and can't find resources anywhere.

Chuck

May be a bit late, but I do have the images for HP-UX 9.10 for the series 300/400.
If you want them let me know.

-Rik
 
Rik,

I need images for HP-UX 9.10. I recently came across an HP382...it has missing SCSI hard disk, i would like to get the machine working. I have external SCSI CD drive from a sun station, will that work for CD install?

Hutch
 
I use an old apple external SCSI CD drive for an HP360 that I have. I have also had very good luck using old Sun equipment (no CD drives though) with my HP's so I'm pretty sure that it would work.

Juror22
 
Back
Top