file spanning multiple tapes

From: Karl Liliestedt <osfmgt_at_msdc.com>
Date: Fri, 16 Aug 96 11:22 EDT

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.

Thanks in advance.

        Karl E. Liliestedt karl_at_msdc.com
        Medical Systems Development Corporation
        Atlanta, Georgia
Received on Fri Aug 16 1996 - 18:40:19 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT