Sorry this has taken so long to produce a summary. The original posting was:
Background:
Once a month we receive an unlabeled 9-track tape 1600-bpi from a
vendor. This tape contains 25 different files of different record
lengths and block sizes.
Normally all the files fit onto 1 tape but occasionally it may span
onto 2. When the complete set of files is generated, the
information currently spans 8 tapes. A full dump of 1 of the files
uses 5 tapes.
Problem:
We have a script that uses 'dd' to read the tapes and update our
databases. This worked fine on our Ultrix systems. If a file
spanned a tape, 'dd' was smart enough to know that another tape
needed to be mounted to obtain more of the file.
With the migration to DU 3.2C, it seems that the 'dd' command has
changed. It appears that you need to know before starting the 'dd'
command how many tapes the file is contained on and specify the
"files=number" option so all of the files will be concatenated into
just 1 file. According to the 'dd' man page:
The dd command does not support floppy disk multi-volumes, but
it does support tape multi-volumes. This means that when ENOSPC
is returned while reading or writing a tape, dd will prompt the
user for a new tape. In order to make use of tape
multi-volumes, the files option must be used.
Does anybody have any idea how I can continue to have this function
automated without knowing know which file (if any) may span
multiple tapes? This script is run by a computer operator who has
only the ability select when to run pre-defined scripts and to
mount tapes.
The vendor can provide the data on 9-track tape, a 3480 cartridge,
and CD. In the future I might be able to start receiving the data
on CD (which would solve the problem) but currently 2 of the
computers running Ultrix which need to process the data do not have
CD drives. These computers are scheduled to be replaced over the
next few months so the solution I am seeking will be temporary.
-------------------------------------------------------------------
Many thanks for prompt responses from:
Kent Poots (KPOOTS_at_gects.ge.com)
Dr. Tom Blinn (tpb_at_zk3.dec.com)
Kent suggested that the vendor encrypt/compress the data
and send it on the Internet.
For security reasons, our current Internet access consists of a PC with a
uucp connection using a 28.8 modem. Even when compressed,
downloading multiple files of this size would take a prohibitively
long time.
Dr. Tom Blinn pointed out that the current ULTRIX version works the
same way as the DU version for SCSI tape drives. There is a "mv="
parameter for dealing with multi-volume data sets. He also suggested
writing a program that is similar to "dd" in function that knows to
expect multiple tapes, and when it gets to the end of a reel it could
rewind and dismount the tape, make sure the output file is fully up to
date, and prompt for another input tape. But, without a tape label, you
can't tell whether you're at the end of the last volume or at the end
of an intermediate volume.
Apologies for neglecting to mention that our systems are not on the
current version of ULTRIX. My original posting about how "dd" works
is correct for the version I'm running. The ULTRIX "dd" command was
modified in later revisions to work the same way that DU 3.2C is
implemented. Using the suggestion about writing a program similar to
"dd" still requires human intervention to determine if any files
actually span tapes and then handle the combination of 2 partial
files if necessary.
BTW - Dr. Blinn also mentioned:
The Digital UNIX "dd" reference page is misleading when it says
that you can get an ENOSPC error on input; that will never happen.
It can only happen on output, which is the case that it can handle
by asking for a new tape.
Since a primary requirement is to keep this function as automated as
possible, it appears that the best alternative is to receive the data
on CD and use "sudo" to mount/unmount the CD.
Thanks again for the responses.
Karl E. Liliestedt karl_at_msdc.com
Medical Systems Development Corporation
Atlanta, Georgia
Received on Fri Aug 30 1996 - 14:42:01 NZST