• Please review our updated Terms and Rules here

PDP10, PDP11 magnetic media

P

PJMills

New Member
Joined
Mar 14, 2012
Messages
6
Location
Manitoba Canada
This is my first post to any Forum ever- therefore I do not know how this all works, but I do have a need and thought I would ask for input to solving my problem.

I have three different magnetic media types I would like to read. Two were written by the same machine during the early 1980's - a digital PDP10 on a TOPS-10 System 701A (24214): 1) 1600 density, 9-track (10-inch) real mountable Magnetic Tape and 2) 4-inch Dec tape 3) a PDP11(running RT11 I think) removable disk. The removable disk is enclosed in a hard plastic jacket and is about 15-inches in diameter (the bag says rko5).

I realize it would be a miracle to find hardware to read these media directly! I have access to a VAX and the 10-inch magtapes will mount as foreign but won't read. I did issue a "dump" and have a hexadecimal file of the data on each tape.

My questions are:
1) Do miracles happen - are there any leads on someone having old hardware to read any of these media?
2) Are there other VAX commands (system or otherwise) that I could use on the VAX to produce a more usable file of the data. When the PDP10 was replaced with the VAX there actually was a program used to do transfers between the machines.
3) If I know the order, type and value (of some of the data) written on the tape is there any hope of me decoding the hexadecimal file and how?

Thank you
PJ Mills
 

Attachments

  • 10-inch PDP10 MagTape.jpg
    10-inch PDP10 MagTape.jpg
    92.6 KB · Views: 1
  • digital Dectape.jpg
    digital Dectape.jpg
    88.4 KB · Views: 1
  • decpack1.jpg
    decpack1.jpg
    91.6 KB · Views: 1
I think you probably could find a 1600 -6250 desktop tape drive on ebay or some of the other listings, do not remember the manufacture who made them, NCR, Burroughs, IBM and HP all seemed to have them. I think IBM's feature number was 5170, one of the old IBMer's here should be able to tell you the correct IBM feature number to look for. They should connect to a SCSI card, NovaXChange had a set of utilities that would read the tapes and write to disk. I am not sure if it is still in business or available for purchase, if not I still have Dos and Windows 95/NT versions, if you cannot find it elsewhere. It will make the EBCDIC to ASCII conversion if necessary, it will convert variable length records to fixed lenght and should read the EOF markers. It should handle endianness if necessary. Let me know if you cannot purchase a copy of NovaXchange. That should take care of the tapes.

I have no idea how you are going to read that disk carthridge, the last time I saw one of them was in the 70's on a Burroughs B-700.

Good luck,

Jimmy
 
A pdp-8 can read pdp-10 dectape. There are a number of people with pdp-8s with TU55 or TU56 tape transports and OS/8 has a utility for handling the -10 files.

Your RK05 disk pack can certainly be read by folks out there who also still have RK05 drives on their pdp-11s.

There is no miracle involved. There a number of people who have the real, original dec hardware to read these media under filesystems that can bring useable files to a PC for you. You may want to explain the nature of the files though to increase interest. Consider also posting your request on alt.sys.pdp10 and alt.sys.pdp11.

Unfortunately, I can't help you with any of your media. (But for the record - I have a working TU60 and can recover TU60 media on an -8 and on an -11.)

Lou
 
Last edited:
do not remember the manufacture who made them, NCR, Burroughs, IBM and HP all seemed to have them.
Click to expand...
Cipher and Qualstar mad a lot of the desktop and rackmount 9-track drives out there that had a SCSI or pertec interface. Everyone normally rebadged them and IBM added an anhanced front panel but otherwise the drives are mostly the same.
 
Qualstar, thanks Next, in my old age, I could not remember who made the drives for IBM and others. We used NovaXchange from years to read 1600 and 6250 bpi tapes from numerous systems and various formats. I looked at eBay after my first post and a tape drive can be had for around $350.00 plus shipping, which you may have to make a loan for, if I remember right even the desktop tape drives weight a ton.

Jimmy
 
I use an Anritsu 1600-6250 bpi CCT drive connected to an XIO SCSI controller on an SGI Octane running IRIX 6.5

To read old tapes I use a program that simply reads everything on the tape and stores it in a simple format on file, in a way which records the original record/file information which would otherwise be lost if I just dumped the tape to file. The on-disk file format I use is as follows:

- 4 bytes (big endian) integer: Record size of following data. 0 indicates an EOF (end-of-file) mark.
- Then follows N bytes as indicated by the value of the previous record size indicator.
And so on:
- 4 byte record size indicator for the next record.
- Data (record)
etc.

And so on. Couldn't be simpler. So, the tool reads records off the tape one by one and notices its size, then writes the record to file with a preceeding 4-byte integer value which encodes the record size. And if the tool detected an EOF mark that record size would be laid down as zero. This also keeps track of formats where e.g. two EOF marks in a row indicates end-of-volume (for multi-volume tapes) and suchlike.

So I just copy all the tapes that I have to disk files. Then I use, or write as needed, tools to interpret the original data formats, e.g. ANSI or something else. Those tools can be written almost as if they were handling the tapes directly, I just use a wrapper which works like an MT (magtape) library against the disk files. Which means I can often start from existing old tape-reading tools, or just documentation, for those old formats. What I can't interpret now I can at least write to disk and be able to read in the future.

If I hadn't recorded the record size information in my disk files it would be difficult, sometimes impossible (or nearly so) to restore the original data in an automatic way.

-Tor
 
Jimmy said:
I think you probably could find a 1600 -6250 desktop tape drive on ebay or some of the other listings, do not remember the manufacture who made them, NCR, Burroughs, IBM and HP all seemed to have them. I think IBM's feature number was 5170, one of the old IBMer's here should be able to tell you the correct IBM feature number to look for.
Jimmy
Click to expand...

The IBM 9-track w/SCSI option is 9348-012. An HP 88780B would be equivalent.
 
PJMills said:
This is my first post to any Forum ever- therefore I do not know how this all works, but I do have a need and thought I would ask for input to solving my problem.

I have three different magnetic media types I would like to read. Two were written by the same machine during the early 1980's - a digital PDP10 on a TOPS-10 System 701A (24214): 1) 1600 density, 9-track (10-inch) real mountable Magnetic Tape and 2) 4-inch Dec tape 3) a PDP11(running RT11 I think) removable disk. The removable disk is enclosed in a hard plastic jacket and is about 15-inches in diameter (the bag says rko5).

I realize it would be a miracle to find hardware to read these media directly! I have access to a VAX and the 10-inch magtapes will mount as foreign but won't read. I did issue a "dump" and have a hexadecimal file of the data on each tape.

My questions are:
1) Do miracles happen - are there any leads on someone having old hardware to read any of these media?
2) Are there other VAX commands (system or otherwise) that I could use on the VAX to produce a more usable file of the data. When the PDP10 was replaced with the VAX there actually was a program used to do transfers between the machines.
3) If I know the order, type and value (of some of the data) written on the tape is there any hope of me decoding the hexadecimal file and how?

Thank you
PJ Mills
Click to expand...

Hello and Welcome!




Answers and comments in no particular order...

Everything can be still be accessed and read. Your task will be to decide the way that's best for you. As someone else already suggested, there might be other venues with more "ready at hand" help for you, particularly if they're active PDP-10 groupies. I say that in order to assist you, with no intention to rebuff your request.


Of course, you could assemble systems to read these yourself, but most people aren't usually willing to go to this extreme only for help accessing their DATA. There are PDP simulation environments that can help with this. However, the easiest thing would be to find someone geographically close to you, who has the equipment to read them for you, and give you at least data dumps. [Maybe you'd be up for a little road trip?]

I'm going to take it that this tape isn't a PDP-10 core dump, or anything we'd recognize. If you've dumped the 10" tape at the correct bit density and track format, it seems likely you can make something of that data already with some additional processing of that output. A simple PC based program ought to do the trick [can you program?], assuming the data is now in a file.

However, I must question your certainty of the tape's format. Was this tape actually written on a PDP-10 back in the day [Seems unlikely based on the Tape Manufacturer's label - vintage 1985 isn't it?] or was it written on the VAX you mentioned much later in time?? For example, the TU20 and 30 originally available on PDP-10s by the early 70's could write data at 200, 256, and 800bpi in 7 or 9 track format.

More specifics about the source machine or write method would be of help to you. This holds true for your recent attempts to read it as well, which needed to be set compatibly.

Reading the handwritten tape label, I don't recognize "TFILE7" or "RETREV" programs mentioned. Were they for VAX or PDP-10?

Normally, tape data is written in "records" which would have a distinct and verifiable pattern if correctly interpreted upon read. Was your dump drive able to see these structures, [and remove them] or was this framing ignored?

Of course, the more you know of the data written on the tape, the more likely you can eventually decipher it, once it's dumped in the correct manner.

Perhaps you could elaborate a little more about what you know of how the tape was originally created to help us, help you.






At least the other media isn't as variable.

The DECtape could have come from the PDP-10 as well. It will be important to know if it really was from a PDP-8 as the writing would seem to indicate.


Many members here have RK05's in operating condition. I'll leave it to them to comment on these.


Keep posting if you're not getting anywhere... we love a challenge around here.
 
Thank You for you positive reply.
Trying to reply in order of your post; I would prefer just to mount the tape and retrieve the data – but after two months of searching (using Canada411 instead of the Forums) I have gotten nowhere. Now time is running out so I thought I would post.
The data on the tapes were obtained between 1973 and 1985, and initially written on eight-inch 7-track drives on a PDP10 (We still have all those tapes). At some point the PDP10 was upgraded (probably late 70’s) to the TOPS-10 System 701A (24214) and it wrote on the 9-track 10-inch tapes I have. All the data was periodically re-written on the tapes to keep them “fresh”. My guess is the tapes I want to read now were last written between 1983 and 1986 on the 9-track 1600 drive. The program names hand written on the tapes were locally written Fortran programs (one to write the data and one to read it) that wrote the scan data on the tapes in sequential binary. The open statement reads (…DENSITY='1600',BLOCKSIZE=315,DEVICE='MTA',FORM='UNFORMATTED')” (although a different listing had something like Blocksize=1537/) I have listings of both Fortran programs as well as printed versions of the scan data that was written on the magtapes (some 83 volumes of 11”x17” computer line printer output each volume being a minimum of 6” high). Last January I mounted one tape on a 9-track drive, at my worksite, that is on a VAX system. (I most certainly could find out details of that drive and VAX). The VAX system recognized the mount (using /foreign I think) but would not respond to any of the other commands the operator tried (at that time we were trying to read the tape with a Fortran code I wrote to read the tape). More recently she simply typed “dump MUB0: “ . She then had to use FTP to transfer the data from the VAX to a PC to write the DVD. There were three options using FTP “auto”, “ascii” and “binary”. She used them all so I have three files of each Magtape on a DVD. The first lines of the ascii dump read “ Dump of device MUB0: on 9-MAR-2012 14:05:09.14, Block number 1 (00000001), 2720 (0AA0) bytes ”
The ideal situation for me would be to be able to interpret one of these transferred dump files. I believe the “auto” transfer of the dump file on the VAX and the “binary” transfer of the dump file are probably the same. I was a FORTRAN programmer and lately have done some again. I do know people around me that can probably program in newer languages.
Incidentally sometime early 90’s the PDP10 was replace by a VAX and all 20 years of Scan Data were written by the VAX on 1600 9-track tapes but someone in charge later decided on a clean up they were not useful and had them burnt – he is certainly off my Christmas list.
I think I have described the “dumped” files to the best of my knowledge so if there is more than one way (switches) I could easily mount the tapes again and dump again using a better method. Please advise how you think the dump and transfer should be done.
Thank you for your response.
PJMills
 
Sincere thanks to all who replied.
I’ve just replied to RSX11M+ with respect to the magnetic tape dumps. This response addresses my understanding of the responses before his with respect to creating my own system to read my mag tapes. I've spent most of my free time since my post trying to understand the replies. I know I'm out of my field but my surfing has revealed: I need a drive, cable to connect to a SCSI card, a SCSI card that fits in a PC and Lord knows how many drivers. I could not locate the IBM 9348-012 on ebay but did find a HP88780B. There are shops that probably have them both. Apparently the 9348 uses non-standard drivers and many could not find the appropriate driver, whereas the HP used “standard” SCSI language and any SCSI driver will work?? It seems to be a given that both these tape drives will work irrespective of the 36-bit word size on the PDP10 and 32 bit word size on everything else (I see that as Good). I also was able to download a HP88780B user’s manual – all point to get the HP model if any. One thread stated (and no one refuted) the HP is hard on tapes. That’s OK for me – it’s a one-time retrieval. I did not see SCSI boards for sale or how many versions there are of those. Also none advertised being able to operate on Windows-7 but Windows-7 has an XP emulator so hopefully that will work. I can download NovaXchange free and it works on tapes that are not “backup savesets”. I only have one of those. The others were written with a Fortran code in sequential binary. Will NovaXchange read this type of file? The thread suggested other software Hercules etc. but I haven’t had time to research it all yet.
So if someone would please confirm/comment on the following plan: buy the HP88780B, a windows driver for the HP, find a HP-to-SCSI cable, a SCSI card that fits into my PC and SCSI driver then download NovaXchange, install NovaXchange using the XP emulator in Windows-7 then run NovaXchange. Would there be any hope NovaXchange would read the binary written data on the tape and give me an ASCII file on my hard drive???
I’m quite expecting it more complicated than this. I do have a technician in mind who would help but he maybe hasn’t worked on dinosaurs lately, so I’d like to have some understanding.
Again Thank You all.
Still in the dark,
PJMills
 
Thank you PJ, your responses have given me some understanding now.

Since you're up against a time limit, perhaps you'll want to pursue more than one simultaneous solution. However, the hardware road seems somewhat redundant to me. With the Fortran code having been updated to run on VMS, there's no need to go all the way back to the original PDP-10 Scan Data, unless there's something missing.

I gather from your story then, that the "Data" on your tapes was transferred from one generation to another as formatted Binary, by custom written programs. The only step which may have added extraneous bytes would have been the last two, namely the DUMP and FTP transfer processes themselves.

Your system operator sounds like she has some experience with this, given she provided you with multiple FTP transfers. I believe if you focus your efforts on the files as transferred in BINARY, you'll get the most consistent results.

If I've understood all this correctly, the DUMP command has read the tapes in a manner which has dealt with the lower level tape details mostly, but probably left your familiar data in an unfamiliar numeric base. Your most important step will be to determine how it's been treated by the DUMP, and devising a way to put it back into a form you'll easily recognize and can use.


I would suggest the following experiment.


  • Ignore obtaining new hardware for the moment, and focus on manually reading and interpreting the DUMP output files you've been provided.
  • Select a single DUMP file for a tape which you can correlate to an original PRINTED version of your SCAN DATA.
  • Print out a few pages of the DUMP data.
  • Then, having the actual original data in the format of interest to compare with the DUMP version, you should quickly [less than a day I should think] be able to tell if you can recover what you need from these DUMPs.
  • Once you are convinced of the voracity of this direction, you can commit the resources to writing a program to re-translate these data sets back into a form which you can access from then on.

Here is some OpenVMS documentation on the DUMP command to get you started. I suspect it won't be necessary to re-run the DUMP to use other option switches unless one happens to correlate directly to a form you can use.

If the data is not confidential, you could post bits of the DUMP and original printouts here, and perhaps get help if necessary. Otherwise we'll have to help you as we're able.
 
I gather from your story then, that the "Data" on your tapes was transferred from one generation to another as formatted Binary, by custom written programs. The only step which may have added extraneous bytes would have been the last two, namely the DUMP and FTP transfer processes themselves.
[/QUOTE]

Your statement may be correct or I may have not described the sequence quite right. My knowledge still sees one 'gap' that maybe does not exist. The tapes clearly were written in binary on a PDP10 (36-bit word size). We now dumped the tape using a VAX with a 32-bit word size. Or maybe my question should be is the 36-bit-PDP10 binary word written the same as the 32-bit-VAX binary word being read? Is the binary dump still valid? This is sort of the same question I posed in the other post. Is the 1600 6250 drive the right drive to read my tapes irrespective of what machine I am currently reading with? Clearly the 'gap' may be in my engineers brain!! If I lay out 100 36-mm dominos in sequence and the dots on those dominos are orgainzed in the floating point description of the day, then 30 years later look at that same sequence of dots thinking they are only 32-mm long and those dots should be interpreted using a totally different floating point description whats the chance that 100.123 will still be 100.123? If magically the structure somehow allows for those numbers to be the same PTL.

My brain may be old but it certainly can still be molded.

Thanks
again.

PJ
 
In original 7-track format, the 36-bit data [if indeed it was written that way] would be written in 6 consecutive bytes of 6 bits each.

If the original format was 9-track, this would be written in 5 bytes, 8 bits each. The final byte using only 4 of the 8 bits available.


The VAX system, would likely read 9-track tapes as 8-bit bytes. Your question about the resolution of 36-bit vs 32-bit word size is a good one, but not one I can answer at this time. I would need to see the actual Fortran I/O statements of both the original PDP-10 and VAX versions to have any possibility of predicting how it would turn out. Even then, I would want to test my thinking against the actual data.

I think it would be safe to assume (for the moment) that 9-track tapes would be written in a VAX compatible manner, as anyone who wrote a VAX program to treat this data in the past would have had to wrestle with the 36 bit data size conversion. [hence the admonition on the tape label to use a particular program to read them]

The "new" tapes, would be written in 8-bit bytes consistent with the Fortran version for the VAX system.

All this could be verified by comparing the Printed original scan data, with the Fortran code which wrote the tape, and the actual tape dump. Use the original printed data as your "Rosetta Stone" to comprehend the dump.


Once you can follow it all manually, then you can write a program to accomplish it using that understanding.


I understand your analogy of the "Dominos" and all, but until you look at what you actually have, you're wrestling with too many phantoms at once.
 
PJMills:

I am the one who originally suggested using a SCSI tape drive and the NovaXchange utilities, I checked NovaStore is still in business and still selling the product. I do not know what your budget is, but the new version is over $1,200.00 with all the options. It may be worth a call to them, just to see if they have a solution that will fit your needs and budget.

The company I run provides data processing services for community banks and we used their product for years to handle the data from the various vendors whether it was NCR, IBM, HP, etc. We had several cases of where we had to read 9 track tapes that were often created by inhouse programmers at these small banks. If time is critical, they may be able to help, it is basically all they do.
 
Hi All,

Unfortunately this is the last week of my current contract and I will be very busy cleaning up loose ends. I am OK with reporting media reading remains unresolved with a recommendation to continue on a subsequent contract. My interest will remain high even if it doesn't result in a new contract.

I have a road trip planned starting immediately after the contract and will be out of the country until April 24. After that I will be back in the saddle with a new hobby.

Thanks for all the suggestions and insight. I truly regret not getting involved earlier.

I will keep an eye on 1ajs (my neighbor it looks like) and his two rk05 drives.
Thanks Jimmy. In my searching I thought I saw numerous sites offering free downloads of NovaXchange - would there be something wrong with those?
Thanks RSX11M+ for providing hope with reading the dumps.
It's all very interesting and will be resuming in a month. I will not be relaxing while away but may be able to watch.

PJMills
 
The most probable format for the tape is a "backup" format tape. Use the unix utility "dd" or equivalent to capture a disk
image of the tape from the real tape drive. A command like dd if=/dev/rmt0 of=data ibs=2720 obs=2720 conv=block work
for a backup format tape.

The dec-10 simulators and tools you find at http://simh.trailing-edge.com/ use variations on this format.
Among the things you can find from trailing edge is a packaged dec-10 simulator and mountable disk to run tops-10 or tops-20.
Run the simulator, run backup, read your tape image.
Alternatively, there is a unix/windows program that can read disk images of backup tapes and extract files, make contents listings etc.
 
I recall that when I ported Adventure (about 1974-75) to the CDC 6000 series, I was given a tape from a DECSystem 10 by a DEC CE friend. The format was pretty odd--5 ASCII characters packed into one bit word, with two 36-bit words occupying 9 frames. To get the whole thing from that to 6-bit display code took quite a bit of bit twiddling. A fair amount of modification of the source, (figuring out how to do a "save" of the current state was a big problem) followed by re-interpreting the travel tables followed. What resulted was one of the biggest CPU cycle wasters of the decade. It's a wonder I wasn't fired for propagating it.
 
You must log in or register to reply here.
Back
Top