• Please review our updated Terms and Rules here

Preservation of Software that was distributed on Tape

A

audiocrush

Member
Joined
Jul 21, 2023
Messages
30
Hi,

I'm looking for some other opinions than just mine on how to preserve Software that was delivered in its original form to the customer using Tape like DAT for instance.
Apparently from what I understood, that was a common-ish method of delivering operating systems and larger applications to customers in the Mini-Computer/Mainframe segment and maybe also High-End workstations?

Anyways... It appears that I received such tapes and from what I was told on another thread here they are essentially irreplacable and even if someone has them they might not be willing to give them to anyone for installing a new system.
So I want to create an image of these so that anyone can download it and make their own tape.

The operating system in question is MPE/iX 6.0
It was apparently delivered on DDS DAT tape and I don't want to wreck the tape.
I have a box of 5 surplus DAT Tapes on order so I can check the DAT drive I have before using it.
But the question remains:

How do I do a backup of these tapes?
Just DD the tape device raw as it is into an image file on my disk?
Do I have to take care of/know about the block sizes, is there

I never worked with linux and tape drives before...
I built pentium 3 rig with ubuntu 5.04 and an LTO1 drive to get a feel for it but there still is a few things I have to wrap my head around. (Using the old stuff because I don't have more modern machines where my PCI SCSI hardware would work on, plus it's kind of fun)
The tape I inserted should have had data on it but dd just wouldnt read from it... No errors, just as if it was empty
I could write to it just fine... So I have no clue what is going on here

I'm glad about any advice on that topic from someone who did this before...
I'm just super scared to ruin these tapes...
 
You do NOT want to use dd to archive any magnetic tape with variable length records!

Eric Smith's tapecopy under Linux will at least preserve the blocking information as a .tap file.
github.com

GitHub - brouhaha/tapeutils

Contribute to brouhaha/tapeutils development by creating an account on GitHub.
github.com github.com
The current container formats for magnetic tape data really do not preserve adequate descriptions
of the media, though.

SIMH .tap is an abomination that should have been replaced decades ago.
It, for example, is completely inadequate to describe a tape that was read with a bad block.
 
And be aware that there are flavors of DDS (DDS1...5), so you need the correct drive to image them.

And if you're using Linux of any recent stripe, be sure to install the mt-st package, which supports variable physical block size using SCSI.

However, in general, for many applications, the DDS physical block size is irrelevant in that data is written in streaming mode, separating data sets using file marks. In many devices, it's fixed at 512 bytes.

FWIW
 
Oh how good I feel about asking now :D
Well thanks to Al Kossow and ajacocks for the tip about the tools, I will check them out and try them on some scrap tapes when they arrive.
But I also strongly suspect that the SLT is a DDS1 Tape but I only have a DAT40 drive which is DDS4 I think?
So until I get either a DDS1/2/3 Drive I can't do anything...
Hopefully something not too pricy will pop up on ebay or something.
And also thanks chuck about the info on the block sizes. I didn't even know there is scsi devices that don't work with blocks :D
Good to keep that in mind.
 
Yeah, DDS is almost as bad as LTO. DAT40 will handle DDS2,3,4 but not 1. And don't get me started on QIC/Travan... Personally, I don't much care for HP DDS drives--they're descended from Colorado drives, which were the low-cost leader in QIC.
 
LTO is bad?
Why do you think so?
I never had any bad experiences with them professionally. I mean sure my customers are usually in the SMB segment and they don't go through a lot of tapes but I never heared a single one say that a tape failed on them.
But yea the DAT seems a little flimsy.
I played around with QIC just a few days ago together with one of those floppy connected colorado drives :D
I like the sound when they're seeking :D
 
You don't understand the context of my statement. Got an LTO2 tape and want to read it on your LTO7 drive? Ferget it. DDS can be the same way, but not nearly as bad. The big problem is that LTO revisions came fast and furious and starting with LTO7 got to be really messy. LTO7 type M on an LTO7 drive? Hah!

My own work deals with digital resurrection, so even stuff written in 2000 is recent history. I draw the line at LTO-4--anything after that gets sent elsewhere.

Maybe I'm just too old to appreciate the newer stuff.
 
Ah ok, thanks for clarifying.
Yes this is really annoying.
I don't see any technical reason for missing backward compatibility, except the different magnetic pigment used after LTO-6...
But they also had a solution for that with audio cassettes, so I don't know why this suddenly is a problem for them now.
But I guess at least is is not as bad and convoluted as USB these days :D
 
Hello people!
So finally the DDS3 tape drive arrived, I cleaned it mechanically and with a cleaning tape.
Then I tested writing and reading back from a known good tape that someone sold me as working ok. That seemed to work.
Then I inserted a MPE/iX Factory Preload tape and tried to pull an image
dd stopped after a bit less than 40MB. Does that sound right?
I also tried to image a MPE/iX 6.0 FOS and a Prod/Subsys Tape...
For the Prod/Subsys it stopped after 192kB and theFOS stopped after 17kB...
Does anyone know what I could be doing wrong?
I'm getting these results with dd running with a blocksize of 1M
If I go smaller than that I always get an error that it can't allocate memory.
 
Did you install the mt-st package? How's your SCSI setup? Did you remember to terminate the drive end? Did you try "mt setblk 0" for variable-length blocks?

I've had situations where dd just didn't work and I had to resort to using the scsitape utilities. "bs" in dd doesn't mean what people seem to think it does. I tend to think of it as "buffer size".
 
Hi chuck,
yes I did.
Well the controller is an adaptec 2940 HBA, 50-Pin cable directly attached to an HP C1537 DDS3 drive. Well unfortunately I don't have a terminator that I can mix and match with adapters to work in that scenario.I assumed the termination power jumper on the drive set to enable will fix that for me. Apparently I was mistaken...
But in my defense: I was able to write a 700 debian netinst iso image to a tape using that setup and read it back giving the same checksum.
So I think it is fine.
Thanks for the tip with the setblk 0, but unfortunately I got the same result using that as well.
I also tried the scsitape read command because I saw it writes everything that is on the tape to stdout and I thought I could pipe that to dd or something, but unfortunately I got the error message:
Cannot open SCSI device /dev/st0 - Read-Only filesystem
I don't know in which universe that would make any sense if I want to read? :D

*edit*
Same results using /dev/nst0
*edit2*
@Al Kossow
Thank you for that info
Well unfortunately I don't know any tools that respect these parameters.
It is very hard to search for those things. I mean it took me about a week to get here :D
 
Last edited:
Ok, so now I downloaded and compiled this application:
github.com

GitHub - brouhaha/tapeutils

Contribute to brouhaha/tapeutils development by creating an account on GitHub.
github.com github.com
and i used the taperead application from this toolset
on some tapes I only get 28500 bytes (MPEiX6.0 Prod/Subsys) before the application returns end of tape marker, and on some tapes like for instance MPEiX5.0 FOS General Release I even instantly get end of tape returned.
Is there maybe some weird magic, that the HP3000 bootrom does like skip the first end of tape marker, which I can't?
 
Note that the scsitape package doesn't use the kernel driver for tape--it goes directly to the generic SCSI device; i.e. /dev/sgx. So use "lsscsi -g" to figure out what the correspondence is.
Yes, I know this is complicated, but it's often the only thing that works. For lsscsi, see here: https://sg.danny.cz/scsi/lsscsi.html

If you use /dev/stx, you're bound by the limitations of the kernel tape device driver, which can be limiting in many cases.
 
Hi,
so apparently a guy called Keven on the MPE Forever discord pointed me to a tool called tapecopy
In ubuntu it is part of the hercules package (whoever thought of that name...)
Anyways it works perfectly now
It creates an image file and while doing so it tells me the files, the amount of blocks, how many bytes, the blocksize and also if it stumbled across a tape mark.
It is absolutely exactly what I was looking for.
So remember people of the forum:
tapecopy from the hercules package seems to be the solution for tape archival :D
 
Depends on the interface, but a lot of it is DOS, where I can get close to the hardware. And I do a lot of tapes, not just the SCSI stuff. I do use a lot of my own designs for hardware and software, but when you've got a stack of 7-track open-reel tapes from the 1960s, you don't go to Newegg and buy a solution. Pertec, QIC-02, etc. don't have any support in any remotely recent operating system.

Linux is useful in many cases, but is hardly a panacea. The trouble with WIndows, Linux, etc. is that you're isolated from the hardware by one or more layers. If said layers can get you where you need to be, fine. But sometimes not.

For example, see my Pertec-interface controller design on GitHub. Produces SIMH-format image files directly and does streaming at 75 ips at 6250 fci.

But I'm old, and I was there when this stuff was current. :(
 
You must log in or register to reply here.
Back
Top