bruce@opus.objy.com (Bruce Reed) (02/15/91)
I would appreciate some help from anyone who has experience using the
HP DDS drive with standard UNIX backup utilities, e.g. tar and cpio.
I can't seem to write CPIO files to the drive no matter what I do. Here
is a scenario:
find . -name "foo*" -print | cpio -oB > /dev/rmt/0hn
mt -t /dev/rmt/0hn rewind
cpio -it < /dev/rmt/0hn
produces:
foo1
End of volume
If you want to go on, type device/file name when ready
.
.
After typing a null name to quit, the device is locked and cannot be
used until the tape is removed and loaded again. Any access displays
the message: "/dev/rmt/0hn: I/O error".
I suspect there may be a hardware problem here, but I'm new to the HP
world and perhaps I'm not using the device correctly. I know that cpio
file contains 5 files, yet the volume seems to be truncated after the
first. This operation works fine on all other tape drives on my
non-HP systems, including 1/4 inch and 8mm.
Also, aside from this, I would appreciate a response from those who have
successfully written consecutive files to these drives. I would like
to do this in my backup operations.
--
Bruce Reed
Objectivity Inc. bruce@objy.com | Duck em' if they can't
Menlo Park, CA sun!objy!bruce | take a joke!edwin@cs.ruu.nl (Edwin Kremer) (02/18/91)
In <1991Feb14.233141.10571@objy.com> bruce@opus.objy.com (Bruce Reed) writes: | I would appreciate some help from anyone who has experience using the | HP DDS drive with standard UNIX backup utilities, e.g. tar and cpio. I'm sorry to see that you didn't include any information on how your DAT is connected (SCSI or HPIB) nor any information on how you've setup the device files (major/minor device numbers). This information would have helped much in answering your question. However, you might be very interested in a document written by Paul Perlmutter (@ Hp.Com) called the "DDS Application Note". It is available from our anonymous FTP archive server as well as our mail-server. How-to-use details below, look for the file: "HP-UX/dat-install.txt". hope this helps, --[ Edwin ]-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ **> This is my ``standard-answer'' to requests for free software that I **> think our archive-service can fulfil. Usually, I mail this message **> directly to the person who queried, but since people keep on asking, **> I've decided to post this message as a follow-up on these kind of **> queries in the relevant newsgroup(s) every once a month or so... We, Computer Science department, Utrecht University, are running an anonymous FTP server on one of our systems. I should say that we're NOT archiving all of "comp.sources.*". Instead, we're putting a lot of effort in trying to keep the archive up-to-date. Here are the details on anonymous FTP: ====================================== Site: archive.cs.ruu.nl [131.211.80.5] Login: "anonymous" or "ftp" Password: your email address (you@your_domain) Usage: see the ftp(1) manual on your system Hot topics: TeX stuff, Atari-ST software, Elm 2.3, NN 6.4, UNIX software, sundry documentation, ... Important: to get a description of what exactly is in the archive get the file "pub/ls-lR.Z". Also, in each sub-directory there is a file named "INDEX" that describes the software in that directory (what version, what else you need, who wrote it, etc.). Although anonymous FTP is our main goal, we're also running a mail server, because we *know* how you feel when there's plenty of beautiful software around that you can't reach. We've been in that situation for a long long time... All we ask from you is that you at least *try* to keep big requests out of the prime-time hours (nights and weekends are fine). Okay, now for how to access our mail server: ============================================ 1) The mail server can be reached at the address mail-server@cs.ruu.nl or the old-fashioned path alternative ...!uunet!mcsun!hp4nl!ruuinf!mail-server 2) The mail server understands a couple of commands, all commands must be in the message body. The first thing you might want to do is ask it for help: send HELP 3) A complete "ls-lR" listing of the archive is kept in the top-level directory, it will be updated every night. To get it, say: send ls-lR.Z Note that compressed files will be sent UUEncoded by default; we use the UUE that was posted to the net some time ago. In every subdirectory you'll find a "INDEX" file, describing the contents of that directory. So, e.g. to find out what's in the NN-6.4 directory, say: send NN-6.4/INDEX 4) Last, assume you want to get the UUE/UUD package mentioned above: send UNIX/uudecode.shar 5) If your mailer appends your fancy signature file, you might want to mark the end of the mail-server commands-list by putting an end command above the signature file. This will prevent "unknown command" messages from the mail-server program. That's all for now. If you encounter problems using the FTP service and/or the mail-server, feel free to drop me a line (by e-mail, please). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Edwin Kremer (SysAdm), Dept. of Computer Science, Utrecht University Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-534104 | UUCP: ...!uunet!mcsun!hp4nl!ruuinf!edwin Telefax : +31-30-513791 | Email: edwin@cs.ruu.nl [131.211.80.5]
franks@hpuamsa.neth.hp.com (Frank Slootweg CRC) (02/20/91)
As Edwin Kremer said, there is probably little we can suggest without further information. However if you did *exactly* what you said you did, then the solution is probably simple : > find . -name "foo*" -print | cpio -oB > /dev/rmt/0hn > mt -t /dev/rmt/0hn rewind > cpio -it < /dev/rmt/0hn If you use the "B" option in the output operation ("cpio -o") then you must also use it on the input operation ("cpio -i"), so the last line should be : cpio -iBt < /dev/rmt/0hn Hope this helps. B.T.W. the same is true for the "c" option. Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center.
rjn@hpfcso.FC.HP.COM (Bob Niland) (02/22/91)
re: > I would appreciate some help from anyone who has experience using the > HP DDS drive with standard UNIX backup utilities, e.g. tar and cpio. > I can't seem to write CPIO files to the drive no matter what I do. Working example: #SCSI Device File: crw-rw-rw- 2 root other 54 0x0d0403 Feb 18 03:17 /dev/rdat #Fragments of /etc/backup. Changes/additions are > flagged. #(/etc/datdest contains "/dev/rdat") ... destfile="/etc/datdest" # file containing backup destination ... ... # Do the backup: if [ "${aflag:-yes}" = "yes" ] # doing an archive then # remember the date/time backup started touch ${archive}.x fi echo "s `date` `uname -r` $aecho" >>$backuplog cd / > mt -t $dest rew { find $backupdirs $aflag -hidden -print | > cpio -ocBx > $dest } 2>>$backuplog # log stderr only. echo "f `date`" >>$backuplog if [ -f ${archive}.x ] # did an archive then mv ${archive}.x $archive # save the new archive time fi # Finish up after backup: echo "\007Backup complete at `date`" > mt -t $dest eof 2 > mt -t $dest offl & touch $remind # make reminder file. Comments: * Device file is BSD personaility w/no-rewind-on-close. * Script therefore starts with a rewind to be on the safe side. * Two EOFs written after archive to prevent reading old junk on restore from used tape. * Final rewind-offline to eject tape (SCSI only). Regards, Hewlett-Packard Bob Niland Internet: rjn@FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599
chance@hpfcso.FC.HP.COM (Chance Brohm) (03/01/91)
/ cochran@hpcupt1.cup.hp.com (Bob Cochran) / > This may or may not be your problem but it is a common mistake to attempt > to use the mt(1) utility (whose man page specifies that the device file > must be Berkeley-style) with the /dev/rmt/* device files which are shipped > (with AT&T-style specified). If the minor number associated with > the device file has been ORed with 0x100000, then Berkeley-style is specified Note that this (specific minor-bit) is architecture-dependent. On PA-RISC (9000/[68]xx) systems with HP-UX 7.0, this information is correct. A safer approach on these systems for making device files is the mksf(1m) command (/etc/mksf). Using mksf (instead of mknod), you can specify "-d tape1 -u" on the commandline to make a Berkeley-style tape device special-file. Read the manpage (especially the TAPE1 section) for the whole truth. See also the lssf(1m) manpage for the (useful!) ability to decipher the minor-bits of existing device special-files. On 300s, the situation is both easier and harder. The easier part is that 300s don't really have the concept of "LUN"s (Logical Unit Number) per se; instead the minor bits of the device special-file indicate the select code and bus address directly - you choose (without having to reconfigure/reboot) how/if to assign LUNs. The harder part is that the mksf command does not exist for MC68K (9000/[34]xx) systems (reason: no kernel-wired LUNs => no /etc/devices file => no mksf); you need to obtain (& read) the HP-UX System Admin Manual (for S300/400) to decipher the driver-specific minor bits. My (sorry, ancient! but still valid) copy of the HP-UX SA manual (HP Part # 98597-90059 10/87) has this information on pages 178-181 (9-track magtape). In case you don't have the manual handy (bad! bad! ;-), here's (some of) the bits for the 9000/[34]xx HP-UX 7.x tape drivers (character-major 5 and 9): Minor number mask SET (=1) RESET (=0) 0x000001 NoRewind RewindOnClose 0x000002 Berkeley AT&T 0x00FF00 Put the bus address here (MinorNum |= HPIBaddr << 8) 0xFF0000 Put the select code here (MinorNum |= SelectCode << 16) So for example, if you had an HPIB DDS drive set to 7978-compatibility mode at HPIB address 0 and connected to the internal 300 HPIB (select code 7), you could use the following commands to create Berkeley-style rewind and no-rewind device special-files respectively: /etc/mknod /dev/dds0 c 9 0x070002 # make a BSD rewind-on-close special-file /etc/mknod /dev/dds0n c 9 0x070003 # make a BSD no-rewind special-file Enjoy! -Chance This message must not be considered to be an official statement of any kind; the information is presented as-is with no warranty of correctness or fitness for any purpose.
bruceh@hpcvca.CV.HP.COM (Bruce Hauge) (03/04/91)
/ hpcvca:comp.sys.hp / chance@hpfcso.FC.HP.COM (Chance Brohm) / 7:00 pm Feb 28, 1991 / / cochran@hpcupt1.cup.hp.com (Bob Cochran) / > This may or may not be your problem but it is a common mistake to attempt > to use the mt(1) utility (whose man page specifies that the device file > must be Berkeley-style) with the /dev/rmt/* device files which are shipped > (with AT&T-style specified). If the minor number associated with > the device file has been ORed with 0x100000, then Berkeley-style is specified Note that this (specific minor-bit) is architecture-dependent. On PA-RISC (9000/[68]xx) systems with HP-UX 7.0, this information is correct. A safer approach on these systems for making device files is the mksf(1m) command (/etc/mksf). Using mksf (instead of mknod), you can specify "-d tape1 -u" on the commandline to make a Berkeley-style tape device special-file. Read the manpage (especially the TAPE1 section) for the whole truth. See also the lssf(1m) manpage for the (useful!) ability to decipher the minor-bits of existing device special-files. On 300s, the situation is both easier and harder. The easier part is that 300s don't really have the concept of "LUN"s (Logical Unit Number) per se; instead the minor bits of the device special-file indicate the select code and bus address directly - you choose (without having to reconfigure/reboot) how/if to assign LUNs. The harder part is that the mksf command does not exist for MC68K (9000/[34]xx) systems (reason: no kernel-wired LUNs => no /etc/devices file => no mksf); you need to obtain (& read) the HP-UX System Admin Manual (for S300/400) to decipher the driver-specific minor bits. My (sorry, ancient! but still valid) copy of the HP-UX SA manual (HP Part # 98597-90059 10/87) has this information on pages 178-181 (9-track magtape). In case you don't have the manual handy (bad! bad! ;-), here's (some of) the bits for the 9000/[34]xx HP-UX 7.x tape drivers (character-major 5 and 9): Minor number mask SET (=1) RESET (=0) 0x000001 NoRewind RewindOnClose 0x000002 Berkeley AT&T 0x00FF00 Put the bus address here (MinorNum |= HPIBaddr << 8) 0xFF0000 Put the select code here (MinorNum |= SelectCode << 16) So for example, if you had an HPIB DDS drive set to 7978-compatibility mode at HPIB address 0 and connected to the internal 300 HPIB (select code 7), you could use the following commands to create Berkeley-style rewind and no-rewind device special-files respectively: /etc/mknod /dev/dds0 c 9 0x070002 # make a BSD rewind-on-close special-file /etc/mknod /dev/dds0n c 9 0x070003 # make a BSD no-rewind special-file Enjoy! -Chance This message must not be considered to be an official statement of any kind; the information is presented as-is with no warranty of correctness or fitness for any purpose. ----------
graham@hparc0.HP.COM (Graham Eddy) (03/19/91)
#include <std/disclaimer.h> as i understand it, the magic is to pretend it is 1600 bpi i.e. only use /dev/rmt/?m* variations