NASA dusts off FORTRAN manual, revives 20-year-old data on Ganymede NASA scientists have made some new discoveries about Jupiter's giant moon Ganymede, thanks to a dedicated team, an elderly VAX machine and 20-year-old data from the long-defunct Galileo probe. Fifteen years after Galileo (no, not that one) ended its days with a plunge into the atmosphere of Jupiter, NASA scientists have …
but probably more the hardware to read the data of disk or tape.
I mean Fortran is a well defined language with widespread compiler support. You could probably just run it on any modern computer with minor changes, but then again if you have the hardware lying around and you need it anyhow to read the medium, why bother porting the software.
Almost certainly not the software although the software migration could be non trivial if the code relied on long deprecated low level run time functions.
The other factor to consider with the hardware is not just reading the stuff but being able to write it to something your more modern hardware can handle.
"Almost certainly not the software although the software migration could be non trivial if the code relied on long deprecated low level run time functions."
Yes, that's why experienced programmers see any kind of dependency as a potential problem. Perhaps it can be hoped for that NASA only employed experienced ones.
"The other factor to consider with the hardware is not just reading the stuff but being able to write it to something your more modern hardware can handle."
Well in that case, that's probably not a problem. VAXes have serial interfaces and even have power of 2 word sizes. Since it can't possibly be a lot of data (probes have very slow links) it should be trivial to just convert it to text, set your terminal program to log the incoming text and just pipe it over that way. It might take a couple of hours, but then again that data obviously was worth that.
The way VAX/VMS worked was that the languages such as FORTRAN and BASIC were all wrappers around the RTL, run-time library. This made interoperability between languages very, very easy because they were all the same under the hood. But it also meant that you needed more to run the code on another system than just merely the source code, particularly if you were manipulating files e.g. with RMS.
> Fortran is a well defined language with widespread compiler support.
Not really. FORTRAN written in 1989 is likely a sludgy mixture of what the F77 Standard said it should be plus a collection of vendor-specific FORTRAN extensions that are unportable from one FORTRAN compiler vendor to another.
Back then, the notion of code portability between compilers wasn't on anyone's mind. Vendor-specific non-portable extensions were considered cool.
FORTRAN in all caps because that's the correct spelling of the official name of the language.
Since 1991, the official name of the language is Fortran, mixed-case.
A 1980s-era VAX FORTRAN (it was uppercase at the time) program would likely run, unchanged, on at least one if not more current compilers and systems. Intel Fortran, in particular, supports pretty much everything from VAX FORTRAN except for RADIX-50 routines. (I was on the VAX FORTRAN (and Compaq Fortran and Intel Fortran) team for most of my career, and was the VAX FORTRAN project lead for many years.)
I agree with others that the language was not the biggest hurdle. Heck, you don't even need a VAX to run VAX FORTRAN itself, there is a freeware VAX emulator for x86.
Fortran is still a very active language. Fortran 2018 is in the final stages of standardization and plans are being drawn up for the next revision. (I am now the "Convenor" for the international Fortran standards committee.) Learn more at wg5-fortran.org
Cross compilation had been around before 1989. So code portability had a thought.
As others have pointed out... it could have been due to the hardware as well as the specific libraries to analyze the data. There's no reason why they couldn't migrate the data to another system once they've pulled it off the older hardware, although you will have to recreate/port the old very specific libraries used to work on the data.
That could prove to be a bit more problematic.
We don't have enough information on the quality of the code.
> [ ... ] although you will have to recreate/port the old very specific libraries used to work on the data
Yeah. There's that. Porting N number of old FORTRAN libaries from DEC FORTRAN to ... Intel X86_64 I guess? How long would that take?
Then there's validation. Making sure that the numbers coming out of the VAX libraries are exactly the same as the numbers coming out of Intel. Which, at a minimum, means running the libraries' test harness both on the VAX and on Intel, and then comparing the results.
Chances are the numbers won't match 100%. IEEE rounding, flush-to-zero, denormals.
Next step: if the test harness result numbers don't match, now what? Where's the error? Do you debug on the VAX or do you debug on Intel? Probably on both if you really want to track down the error.
Some people here make it sound like it's just a matter of ftp'ing the data sets, then just a simple recompile, then everything just works. Speaking from experience: it never works that way in real life.
Have you ever seen DEC FORTRAN code from the late '80's? I have, 20 years ago. I'm still trying to unsee it.
>Yeah. There's that. Porting N number of old FORTRAN libaries from DEC FORTRAN to ... Intel X86_64 I guess? How long would that take?
I'd go the other route. A VAX isn't a very large machine by modern standards so it would be easier to just emulate it on a generic platform (apparently even a Raspberry Pi will do the job). Its much easier to verify the correct operation of an emulation than verify ports of system code.
Like many others I suspect the real reason for cranking the old machine into life would be that the data was stored on magnetic tape. I'd also guess that the data on the tape was structured by the software so just reading the tape wouldn't be much use without understanding how the program used that data.
There would probably be data problems.
The VAX format for floating point numbers, both single and double precision, differs from the now customary IEEE standard. SUN wrote a software library with a name resembling "external data representation" or something like that, to ease data transfers from old Vax computers to new Sun ones. It also converted between big-end and little-end binary integers, 16-bit or 32-bit.
If suitable data records are defined, Vax data can be transferred over networks to Sun or Intel machines.
"The VAX format for floating point numbers, both single and double precision, differs from the now customary IEEE standard."
The VAX architecture was pretty well defined + documented in the manuals (including the FP formats) - and those documents still exist (in my bookshelf and likely bitsavers.org) - so I reckon that wouldn't be a barrier to someone who can bash bits around.
The VAX architecture was pretty well defined + documented in the manuals (including the FP formats) - and those documents still exist (in my bookshelf and likely bitsavers.org)
Just yesterday I was scanning a couple of PDP11 FORTRAN (1975, so upper case) manuals, which will be uploaded to archive.org in a couple of days. And here is a VAX FORTRAN manual we did earlier.
Enjoy.
(And we really deserve that cobwebs icon. It came out of the crawlspace under a flat on the Twente University campus. Icon as replacement for dust mask)
it might be time to back all of that stuff up onto more modern media, as well as a RAID someplace with images that can be loaded (and run) by something *like* simvh
I've got a few simvh-compatible images for PDPs and I know the VAX images exist as well... so we can avoid the problems of ancient hardware [though it's still fun to play with it] and potential data loss.
NASA may be a little weak on the I.T. front...
post-edit (after reading a few more replies in this topic)
simvh would solve nearly all of the language and hardware format compatibility problems identified, from the FORTRASH lingo itself, to the non-IEEE floating point format
Where I work, there's a team who keep one of every type of tape drive they've ever come across. People sometimes laugh at their collection. The people who come along with some ancient tape archive only ever leave with a smile on their face. (And their beer fund severely reduced)
I worked with VAXen and FORTRAN at CERN. I was wondering why they would have to use real VAX hardware, and not an emulator. I guess reading the tapes explains it.
I have a TK50 tape somewhere, which has my PhD thesis on it. Anyone got a drive which can read it? The document itself is in a variant of TeX called Scitex (not Latex)
"I have a TK50 tape somewhere, which has my PhD thesis on it. Anyone got a drive which can read it? The document itself is in a variant of TeX called Scitex (not Latex)"
Ahh the wonderful world of properly designed systems where hardware is the main problem. As soon as you get the file, you will probably be able to read it as all of its text is just ASCII text, and even the formulas will probably be easy to recover somehow.
I worked for a tape drive company back in the late 80's (and the 3 companies that subsequently bought each other, as an I.T. consultant). They made 'conventional' drives for UNISYS, as well as the more "modern" front-loaders that accepted a tape reel in a manner similar to a VCR cassette. Not for HP though. HP made their own, as I recall. Funny, because the company used an HP3000.
I don't recall even an old DG Eclipse 'self loader' conventional-style tape drive (in 1979) making that kind of noise, though.
I can still feed a tape leader on VAX machine in my sleep. I remember I never felt happy with the self loading tapes unless I did the finger dance as the machine made the noise of an asthmatic inhaling an orange.
That's a fair description of the TU/TA77/78 (Pertec) drives, indeed. To get them loading reliably they needed vacuum and pressure settings juuuuust right. There's a Kennedy 9100 in our collection that's even more hairy.
The later TSV05 was an front-loading auto-loader that was much less fussy. We've got one that was stored for at least 15 years, probably more like 20. Powered on, slid a tape in and it loaded without a hitch.
One of every drive?
Sure, that will work if it's old Tandberg SLR drives, but what if it's DAT or 8mm video tapes?
(Yes, both of those have been used for backup purposes. DAT tends to stretch the tape in such a way that a tape will only ever be reliably read on the original drive, and 8mm... the less said... )
DLT and SDLT...
There are some that thinks the S stands for 'super'... Yeah...
I have half a dozen of those stashed away. One with a tape still stuck in it.
Odds are that none of them works any more.
I have Zip drives(still more reliable than DLT... ), Jaz, Clik! (or whatever it was named. )...
I could use a Bernoully drive, though.
At CERN my experiment, ALEPH, made heavy use of VAXen.
We used 730s and 780s for data acquisition at beam lines.
Down in the experimental cavern the DAQ was FASTBUS but there were VAXen down there too.
For analysis as I remember VAXen clustered together really easily, with a maximum limit of 128 machines. So we had at least two clusters in the CERN server hall.
In the latter days there were Alpha servers in the mix too.
I was like a dog with two tails when I got my very own FALCO terminal. This did amber screen DEC VT220 emulation, but then with a hotkey did Tektronix emulation. So you could develop colour graphics programs and see the results on the same terminal!
I was rather an expert at GKS if there is any call for those skills!
Do you think NASA will give me a job then?
Hopefully the content of those tapes is now stored in some more easiliy retrieved medium.
If you think about it, all the space missions we've done are likely to have data we didn't know to analyse.
Going back through the archives must be like re-reading a Douglas Adams novel - no matter how often you've read it previously, you will pick up something new.
Ask librarians & archivists about this. It's something they worry about all the time. Just look at the BBC Domesday project. After just a short period of time they were unable to read the discs.
Talking about paper tape... at FOSDEM this year there was a fascinating talk from the team who are re-implementing EDSAC for schools projects.
https://fosdem.org/2018/schedule/event/edsac/
Their paper tape reader uses till rolls for shop till printers, which are cheap and readily available.
They implemen tdelay lines using plastic pipes and air, with microphones.
They referred to a paper where Turing works out thta gin is in fact the best medium for delay lines.
Sadly you can't give schoolchildren neat gin to play with!
If you can setup the mechanical side of things (reels and a motor), you could read in punched paper tape using a webcam and some software. Or perhaps you could dismantle a scanner and mate the parts to an Arduino.
A friend of mine has a Player Piano, which still plays back 'software' laid down in the 1930s (Fats Waller songs). If you visit a steam fair, you may see a steam orchestra playing even older punched card music.
During WWII, Hollywood star Hedy Lamar invented a frequency-hopping mechanism for controlling torpedos (so the signal couldn't be jammed by the enemy) based on a minuturised Player Piano mechanism.
https://en.m.wikipedia.org/wiki/Hedy_Lamarr
The Northleach mechanical musical instrument museum, sadly a bit dodgy due to Keith Harding, IIRC, being found out for historical kiddy-fiddling, has a wonderful piano which could play and record using inks onto a roll and mercury baths and moving copper contacts etc. The rendition of Rhapsody in Blue recorded by Gershwin himself on that very piano is utterly transporting.
The simplest way way back in the day was to use a photo transistor array and a uart. (Serial) or buffer (parallel port).
The tape was pulled through by hand through a simple set of guides to align the tape with the sensor. From memory illumination was room lighting. Might be improved with a desk lamp.
Clocking was by use of the sprocket hole which is smaller than the data holes and allowed some data skew/ set up time before data was transferred. You may have had to use your thumb to keep the tape in place.
Whole affair fitted into a small plastic/ diecast box.
Worked best with opaque black paper tape and possible variable results with white paper tape and possibly not good with oiled tape.
From memory "Pickles & Trout" made them.
Way back in the day when you bought software for your microcomputer (8080/6800) on paper tape and the thought of an ASR33 was well beyond the thought of possibility.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
