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 thing with paper tape is it is pretty easy to knock-up homebrew equipment which will read it; mechanical, optical, or even electrostatic. Same too for punch cards.
An old ASR33 reader can be interfaced to any microcontroller reasonably easily and there are quite a few around. It's more advanced tech which is harder; especially where the protocol and/or interface is not so obvious just from looking at it.
If the data is on a 'VAX tape' it makes sense to read that on a VAX drive and use a VAX to connect to that running VAX software which can access it. No need to reinvent the wheel.
"I wonder how many paper tape readers still exist?"
Papertape readers actually are simple enough to produce. Take a PCB, put on a row of phototransistors (either 6 or 9 depending on the number of bits per character), have a second, smaller PCB with holes and "upside down" SMT LEDs which has its edges filed down to be as smooth as possible. And place both PCBs on top of each other, with some small gap in between. You just pull though your paper tape and there you go. One phototransistor will give you the clock, the others will give you the data. Since papertypes have a dedicated row of perforation you have a clock, therefore you don't need a motor to maintain constant speed.
I wonder how many paper tape readers still exist?
At least five. One standalone, serial interface, three Fridens, and one ASR33. The standalone one is incredibly useful; one of the museum team wrote a utility to write a couple of common formats with it.
Some time ago someone I know wondered how much space 1.4PB 'printed out' on vellum would take. Couldn't help there, but as paper tape it would fill about 11.5 Albert Halls.
Mankind is not only contemplating a landing, but is aiming to smash/drill/melt through the ice to place a probe in Europa's oceans.
It's one of the missions being used to justify the SLS. Only yesterday Boeing put a website comparing their yet-non existent rocket to Musk's demonstrated Falcon Heavy. For some reason aren't comparing their SLS to Musk's similarly not-yet existent Big Falcon Rocket.
7756 6014 5023...
Forty years plus later those octal numbers entered on the front panel switches of a PDP 8E to enter the boot loader are still etched on ones memory.
And the rat-tat-tat of the ASR 33's as they fired up after the paper tape loaded.
was that a 'unibus' address? I am only familiar with doing things like that no a PDP11 and DG Eclipse. PDP11/34 had a console-based boot though [but the paddle switches were still on the front panel]. As I recall you'd press the boot switch, then enter the device name at the 'boot?' prompt, and it would boot from that device. or you'd toggle the address in with the paddle switches before hitting 'boot'
Yeah, I remember the days - but you lived in high-tech land, we had a PDP-8S (w/internal Serial data bus). Now, that might sound primitive, but I'd cut my teeth 10 years earlier entering FORTRAN programs on IBM punch cards (for overnight processing) on one of the relatively few university UNIVAC 1107 mainframes as an undergrad. So, we thought that mini-computers, ASR 33's, paper-tape readers, magnetic tape program storage etc were the cat's meow for data acquisition and control. (we used terminal access to U mainframe for data analysis). Actually, mastering that machine was an excellent preparation for understanding and exploiting microcomputers as fast as they came on line in the '70s and '80s.
VAX FORTRAN may have been standard, but the VAX floating-point representation was decidedly strange. There were four different formats and all of them had the exponent in the middle of the word with the mantissa wrapped around it. I believe the aim was some level of compatibility with earlier generations of DEC hardware.
https://nssdc.gsfc.nasa.gov/nssdc/formats/VAXFloatingPoint.htm for the gory details.
unless you're playing with raw data from COMMON blocks, shouldn't be a problem. However, this was a common practice for storing databases, using COMMON blocks and EQUIVALENCE for the record as an array of bytes/words/whatever
Yeah I spoke FORTRASH for a while, as recent as the early 90's, working with ASK products like MANMAN [on HP and a bit on VAX]. Yes, that's it's name. They also had other things with 'MAN' at the end of the name. I may even have a few hard copy tech MANuals [pun intended] someplace in the dead tree archive...
yes, because money. it's always that, along with the political prioritization of the day.
And until recently, that money was prioritized in projects that were "of a political nature". But not any more.
Maybe NASA needs a specific 'data archiving budget'? It would go very well with education if it all goes into a public accessible database. [and keep it in native format, too, and document the format for posterity - no filtering, no cooking, JUST the raw, unfiltered data, and a valid schema for it]
The first response to your question would be, - yes what a shame, but there is the budget, the people, the project of the day first.
As has pointed out, the first problems seems to be to find the way (hardware, new or old) to read the media, tape or what ever. The next problem is to understand, find out, what those bits, the record, actually represents.
The rest like the language is probably less difficult.
There is an immense amount of data lying around from space exploration, from several countries, that will never be used.
Is that a problem, probably not, as there is an immense amount of new data created all the time.
It's the same in many other fields too, there is more stuff in museums about what not, that will never be studied in detail.
It's a bit like having a bunch of people, and a budget, to watch each new video on YouTube, they will never catch up.
And my point, FORTRAN, summer 1967, Helsinki University, free of charge, how smart we felt about it, and it was all IBM, of course.
"for most astronomers a 'metal' is anything with atomic number greater than 2. E.g. nitrogen, chlorine, etc."
If that is the case then astronomers need to head back to school and learn some chemistry. Metals are electron donors which can share valence electrons between other metallic atoms in a mobile electron cloud which is why they can conduct electricity. Neither nitrogen nor chlorine is a metal.
Referring to Jupiter's hydrogen core as a metal is not jargon. The pressure at Jupiter's core is *extremely* high, and under high enough pressures the hydrogen behaves as a metal by the usual chemistry standards. I can assure you astronomers don't consider hydrogen to be a metal, only high-pressure metallic hydrogen.
jupiter most likely has some kind of core which consists of heavier-than-atmosphere materials, perhaps all squished up into a high pressure ball, and the pressure might cause 'molten core' kinds of activity. Iron and Nickel (because of the lowest binding energy per nucleon) is common in the universe, and probably exists on every planet and celestial object in at least some amount. That being said, it might also be the same reason why the sun has a magnetic field
https://en.wikipedia.org/wiki/Stellar_magnetic_field
Jupiter emits radio frequencies and as such could have some level of plasma activity (like the sun) that could be the source of its magnetic field.
Or it could be a combination of factors like these [and other things not considered yet]
/me expects Jupter's core to have a lot of diamond crystals in it, like Uranus.
What research organizations should do is make
a) The raw data from the experiment
b) The data acquisition model (IE what those numbers are from, what resolution, sample rate they are from)
c) The instrument specs.
On accessible servers. The data should be secure from being changed but not downloaded.
As others have noted the datasets are (by modern standards) not that big and as the story notes it seems some of them have never had a detailed review.
IOW Fresh meat to the army of Asto/fusion/geo physics PhD's candidates out there looking for a topic, glory and possibly a shot at a Nobel.
I bet there's a lot more to be mined from those data sets.
John, I believe the current British Research Concils mandate that experimental data is kept.
For software reproducibility of course containerisation has a big role to play - hopefully the analysis chain and required packages are being captured in Docker (etc) containers which are being preserved beside the data.
c) The instrument specs.
Damn good point. There is no point in having the raw data if you don't have the calibrations.
Look at the hundreds of years worth of weather station temperature data. I believe meteorlogists (sp?) have to be damn careful when the type of termomenter changes at a weather station so there is a true continuation of the measurements which can be trusted back to the old style instrument.
I'd like to think all research organizations have some sort of archiving and retention policy on the experimental data they collect.
"Damn good point. There is no point in having the raw data if you don't have the calibrations."
Exactly. I was gobsmacked to see a NASA NIAC presentation (IIRC) that said upgraded calibration targets on weather satellites had made significant changes to the interpretation of climate change data, but I can't recall if it was for better or worse.
IOW the readings you thought you were reading were not what you thought.
Which is kind of important. I'll also note with regard to land weather stations you see the "heat island" effect as what was a site in the middle of a field is now a site in the middle of an industrial park. Again, have you allowed for this?
Of course, one might try using a Raspberry Pi for the computing, as it has close to the same power as an original VAX.
The prices for computing power have come down a bit over the years.....
As for data, good old nine track tape in 2400 foot reels works on just about any reader that can mount the tape.
Of course, one might try using a Raspberry Pi for the computing, as it has close to the same power as an original VAX.
Eh, I don't think so. The 11/780 had a clock speed of 5MHz (actually 'cycle speed', 200ns). The slowest RasPi still has a clock speed at least 100 times faster, and while the VAX is a CISC machine, with some of those single instructions doing *a lot* that a RISC processor like ARM needs several tens of instructions for to perform the same action, those VAX instructions weren't just a single cycle either.
Even a RasPi running SIMH is way faster than the same code run on one of the early VAXen.
This just shows how data has value years after the fact something I wish my bosses would understand. They seem to interpret (despite protestation) that all data should be deleted under GDPR yet it still has a value to our business no matter how old it is, if only they would agree to anonymisation instead.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
