Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help reading an old MCP formatted Exabyte tape

382 views
Skip to first unread message

Nigel Williams

unread,
Dec 22, 2010, 8:35:16 PM12/22/10
to
I am assisting with an attempt to recover the contents of an MCP
formatted 8mm Exabyte tape (112m) written by an A-series machine in
1996.

I have two models of Exabyte (model 8500 and model 8505) connected to
a PC running Linux and the usual collection of SCSI tools (sg3). Both
tape drives can read and write their own tapes without error.

Anything we try to do with this Exabyte tape on either drive results
in a read error. We have two copies of the tape and both exhibit the
same problem. Both tapes have been carefully stored and look to be in
excellent as-new condition.

One concern is this comment found in Appendix D Unisys A Series Notes,
D-1, from the manual HS8505 Cartridge Tape Subsystem, Installation and
Operations Guide, 3498 0763-101

"To eliminate potential synchronization problems, HS8505 tape
subsystems used on Unisys A7 systems should first be downloaded with
the special A7 firmware."

My initial thought was this related to the SCSI bus, given that the A7
had early versions of various Adaptec controllers (AIC7770 etc), but I
also wonder if generally the A-series and Exabyte had firmware updates
related to the compression hardware or interoperability? But it could
be a red-herring too.

Various options appear to be available, one or more of:

1. Find someone who has an Exabyte connected to A-series machine
2. Acquire a Unisys-branded Exabyte tape drive
3. Get a copy of the firmware for a Unisys branded Exabyte and flash
my drive with it
4. Flash my drives with the latest Exabyte firmware (still available
on the Tandberg website)
5. ?

Anyone suggest from their experience with Exabyte what option(s) we
should try next?

HVlems

unread,
Dec 23, 2010, 3:06:10 AM12/23/10
to

If both the tapedrive and the cartridges are in good shape then the
tape label is readable.
Now I do not know how linux deals with volume labels. If you have
access to a VMS system
then you could learn a bit more about the technical status of the
hardware and the tapes.

I wouldn't upgrade firmware on the drives untill everything else was
tried.
Were the tapes written on that drive? If not, are the tapes about the
same age as the drive or is the hardware more recent?
If the hardware is recent, firmware downgrading might prove more
succesful than upgrading.

The last time I tried something vaguely similar to this was in 1984,
with 9 track tape reels.
IIRC a tape label consists of three header records (HDR1..HDR3); the
HDR records are in ASCII.
The tape was mounted on a VMS system. The tape label could be read.
VMS has an option to
mount a device as "foreign". For a tape this means HDR1 is read and
the drive stops there.
A program must find HDR2 and HDR3 records and can then proceed reading
data off the tape blocks until
an end-of-tape marker is found. The program had to convert data from
EBCDIC to ASCII of course.
Hans

Scott Lurndal

unread,
Dec 24, 2010, 4:06:24 PM12/24/10
to
Nigel Williams <nigel.d....@gmail.com> writes:
>I am assisting with an attempt to recover the contents of an MCP
>formatted 8mm Exabyte tape (112m) written by an A-series machine in
>1996.
>
>I have two models of Exabyte (model 8500 and model 8505) connected to
>a PC running Linux and the usual collection of SCSI tools (sg3). Both
>tape drives can read and write their own tapes without error.
>
>Anything we try to do with this Exabyte tape on either drive results
>in a read error. We have two copies of the tape and both exhibit the
>same problem. Both tapes have been carefully stored and look to be in
>excellent as-new condition.

Most MCP tapes are variable length records. I've read v-series 4mm
on a linux system.

Try setting the blocksize on the tape device to 0, if it defaults to 512.

man mt

(there are different versions of mt out there, mine had a 'setblk' command:

mt -f/dev/st0 setblk 0


scott

SteveT

unread,
Dec 27, 2010, 2:59:52 PM12/27/10
to
"Nigel Williams" <nigel.d....@gmail.com> wrote in message
news:5e2d06c0-25f3-47c9...@q8g2000prm.googlegroups.com...

>I am assisting with an attempt to recover the contents of an MCP
> formatted 8mm Exabyte tape (112m) written by an A-series machine in
> 1996.
>
> <snip>

Hi, Nigel,
Information that would help the knowledgeable (I am not one) would be: do
you know whether the data are the result of:
* type of output to tape:
o direct program I-O to the tape?
o a CANDE or WFL COPY of data to the tape?
* format of output:
o standard data?
o DMS II?
o KEYEDIO or KEYEDIO II?
o Printer Backup?


Nigel Williams

unread,
Jan 5, 2011, 1:59:07 AM1/5/11
to
On Dec 25 2010, 8:06 am, sc...@slp53.sl.home (Scott Lurndal) wrote:
> (there are different versions of mt out there, mine had a 'setblk' command:
>
>    mt -f/dev/st0 setblk 0

Thanks Scott for this tip. I found that some of the current Linux
implementations don't offer the setblk command and certainly don't
seem to be as extensive as the Solaris MT driver which also offers
several additional capabilities such as adjusting timeouts for really
slow devices, and device-specific density support etc.

Nigel Williams

unread,
Jan 5, 2011, 2:22:03 AM1/5/11
to
Thanks to enthusiastic help from Andrew Lesh of Metalogic and his
excellent tape utilities we were able to recover an image of the tape
and then browse the directory and view the files.

Thanks to everyone for their helpful suggestions, they all helped
steer us to a successful outcome.

It has been an excellent learning experience for me, filling in many
gaps in my understanding of tape formats, old tape drives (like
Exabyte) and dealing with MCP tapes.

A few notes:

- Advansys SCSI controllers and Exabyte 8500 tape drives together
seemed problematic

- You are meant to clean an Exabyte Mammoth (EXB-8900) drive every
time following an encounter with a non-AME tape (AME tapes are used by
Mammoth to get the higher density).

- wide SCSI ubiquity is a nuisance when you want to talk to an older
50-pin narrow SE style device

- out-of-the-box Linux MT driver seemingly gets confused by MCP
Exabyte tapes, perfectly fine with DDS 4mm MCP tapes, but either the
tape drive or the way the device driver is implemented makes for an
unhappy combination.

- there are many types of Exabyte: http://www.jetcafe.org/~npc/articles/exabyte-tape-drives.html

Nigel Williams

unread,
Jan 5, 2011, 4:33:45 AM1/5/11
to
I should add that the key to my success specifically was the free
TapeDiagnostics utility from the CopyWrite for NT suite from
metalogic.eu.com that Andrew directed me to:

http://www.metalogic.eu.com/Main/products/copywritent.htm
http://www.metalogic.eu.com/Main/products/copywrite.htm

they have two versions, one which operates on Windows NT and the
second is specific to Windows 2000 and above (contact
sup...@metalogic.eu.com)

Much like the SIMH .TAP format, the TapeDiagnostics utility can
capture the structure of a tape (including tapemarks) into a .MTI file
and then another step allows this to be converted to an .MCP CDROM LIB/
MAINT format which can then be cataloged/browsed/extracted/burned as
needed.

thanks guys! very useful utility.

0 new messages