A 1958 UNIVAC airline reservation system | Hacker News Reader

A 1958 UNIVAC airline reservation system

philip.greenspun.com

119 pointsfinite_jest56 comments

https://sci-hub.se/10.1145/1458043.1458075

Mods: this is a better link than the OP.

I’m a co-founder of ITA Software (now Google Flights), and people often assume that we at ITA thought Sabre and predecessors like the one mentioned here were crap. On the contrary: I, at least, think they were among the greatest software achievements of their era.

What was less impressive was airlines still relying on the same code 40+ years later: the challenge we set for ourselves was to bring the power engendered by all those years of hardware improvement (and Linux boxes vs mainframes) to bear on the travel industry. And we did that successfully for fare search!

We then tried and failed to do the same for the much larger challenge of the reservation system (think airline operating system).

I distinctly remember philg (OP) visiting ITA’s crappy office in Kendall Square circa 1998, telling us we were all wasting our time trying to improve airline IT. In retrospect it’s “a cautionary tale” (quoting Phil’s post): knowledgeable people often overstate the advantages of the incumbents and underplay the value of luck and timing to startups.

As someone who worked on timetabling databases and pricing services at Skyscanner, I appreciate just what a phenomenal achievement ITA is. Very well done sir.

There is still so, so much innovation that the flights travel industry is ripe for.

Did you ever consider starting a small airline as customer #0 for the reservation system?

You don't make money in the airline industry by being an airline.

I don't know if it's still true. Probably not. But at one point in the past 10 or 15 years I heard the (what seemed to me credible) claim that, taken as a whole, the commercial airline industry had never made money.

The worst sort of business is one that grows rapidly, requires significant capital to engender the growth, and then earns little or no money. Think airlines. Here a durable competitive advantage has proven elusive ever since the days of the Wright Brothers. Indeed, if a farsighted capitalist had been present at Kitty Hawk, he would have done his successors a huge favor by shooting Orville down.

-- Warren Buffett, in the 2007 Berkshire Hathaway shareholder letter

COVID was easily the worst thing that has happened to the airline industry bar none. ICAO estimates that 2020 resulted in $371B in losses.

I used to joke Ryanair makes money by selling tickets, vapes and (soon) condoms.

TBH still kinda good airline for short flights. It's the clientele that makes it less palatable.

Didn’t the CEO of Ryanair say he was going to make tickets free at some point?

I mean the fare would be super basic, no luggage, only what can go under the seat. No water, food. Print your own ticket, etc.

Basically all your margin is on the extras which many people are willing to pay (as long as you’re upfront about it).

I remember flying Ryanair and if you’re prepared to follow directions, it can be very cheap.

The best way to become a millionaire through airlines is to start as a billionaire

...or selling a live feed of airline KPI estimates to quantitative hedge funds and market research companies?

Evil genius. You should work for Google.

ITA Matrix is a great tool for a power user to search for flights, and the time bar view is brilliant. Google's done a pretty good job with Google Flights, but there are still crazy things you can build in ITA Matrix that it's tough to find anywhere else (unless you are/know a travel agent and/or have a GDS). I've said for a while that if Google ever kills off matrix.itasoftware.com I would build a replica.

If Google does ever kills off matrix.itasoftware.com, and you build a replica, I would pay for it and/or help you to the extent possible.

Do you have an example of what ITA Matrix can do?

"Give me a list of all flights originating at LAX, SFO, SEA and terminating at JFK or MIA, with at least one connection in either SLC or MSP with a minimum connection time of 3 hours and include every airline except Delta and Spirit. Do not include results if they require more stops than the minimum possible stops"

Origin: "LAX, SFO, SEA" Destination: "JFK, MIA" Outbound routing codes: "SLC,MSP ~DL,F9+" Outbound extension codes: "MINCONNECT 3:00" Extra stops -> No Extra Stops.

You can also use extension codes to find flights based on duration or number of miles flown.

Edit: Actually a better example to show the power of ITA would be something like "~DL,AA,UA SLC,MSP AA" for the outbound routing code, which says "don't use Delta, American or United for the first segment (to SLC/MSP) and do use American for the second segment (from SLC/MSP)"

This kind of software is what I lump into the category of "just give me regular expressions". There's so many interfaces that would be simplified by (hard!) standardizing textual abbreviations and providing something powerful like regular expressions.

I'm currently shopping for expansion PEX (a.k.a. F1960) fittings and it drives me up a wall when all you want is sizeA: 1", sizeB: 1", typeA: F1960, typeB: MNPT and all you can use is a free text query. Search for '1" F1960 MNPT' or equivalent and you get back all kinds of things that have nothing to do with what you searched for. That's par for the course when businesses don't have what you want and they're trying to give you anything to not have zero results -- but in this case they do have the parts, their crap search just doesn't return them. Try searching for PEX-A vs PEX-B at Home Depot and it's clear many people will accidentally buy the wrong thing.

Airline searches (for me, at least) were very similar. 99% of engines would not give you results spanning across two tickets (no codeshare agreement) or take into account human factors. More recently, search results started to show "pain factor" mostly as an amount of connection time or overall trip time. That (again, for me) is not pain -- pain is connecting in LHR or CDG when you could connect in VIE or WAW. Or worse, getting some flight pushed in your face on a single ticket that has a LHR/LGW transfer vs. two separate tickets in a much smaller airport further east. Similarly, why not offer a plane type filter on every search? Pain is flying on some 20-30 year old airframe on a big airline instead of a Dreamliner on a smaller one. (LOT, if you're interested... :))

I'd argue ITA Matrix serves folks that know airports and aircraft well enough to figure the human factors in their heads (e.g. if you can fly Delta and connect in either AMS or CDG, choose AMS), and just want to find a valid solution set at the lowest price for a query. The lack of split ticketing means you will be protected in the case of a misconnect.

I'd say this is a good case for a declarative language like SQL or Prolog: "just give me X that satisfies Y and Z, I don't care how you get it." Existing search engines either have a painful number of dropdown menus or are free-text only with limited power user features.

I would say network graphic operational research code more. May be the interface is like regular expression. But wonder underlying code is not.

Google Flights routinely serves me economy class seats as business or flight prices suddenly change on last screen or you have to call a phone to book...

Since I'm getting downvoted, here's some examples:

Economy class seats at business class fare:

https://www.google.com/travel/flights/booking?tfs=CBwQAhpfag...

This one changes from 5k to 9k to a whopping 26k:

https://www.google.com/flights?tfs=CBoQAho-EgoyMDIyLTAzLTI5I...

ITA did do a nice job of kicking companies like Sabre and Amadeus into action. I don't know if Sabre ever got there, but Amadeus does now have customers with no transactions flowing through a TPF mainframe, including the reservations part.

A little oral airline history — I was a student at Washington University in St. Louis in 2002 and 2003, studying EE and CS. I struggled, not with the material, but with my own personal issues and the fact that my girlfriend was 600 miles away in Minnesota. I dropped out of school and took a job at US Airways as a baggage handler so that I could fly for free. I learned SABRE fast, and wrote a little web app in PHP to help me memorize airport codes. (AVP = Scranton Wilkes Barre. Fifty years from now, this might be my dying thought.)

A year and two promotions later, I had dropped out and transferred "upstairs" to a generalist customer service job. I moved to Minneapolis, just an hour from my girlfriend, and worked as a ticket agent, gate agent, and baggage service agent. At that point I knew five distinct SABRE subsystems very well. Ticketing, gate, baggage, ramp (DECS), and flight operations (also DECS) are all handled differently in SABRE. I learned intuitively how VCRs work and could "pull" them out of defunct reservations and "push" them onto new ones, which made me the fastest re-booker at the station. I could sell a Zed fare in 30 seconds, and almost never needed to hand over a paper ticket to a customer, which meant that my end of day report was usually clean. In retrospect, SABREs green screen commands formed kind of a functional language in a real-time Vim-like environment.

I was laid off from US Airways in the wake of its America West reverse merger. I took a job with Carlson Wagonlit as a corporate travel agent. Carlson used a complicated mid-2000s web app instead of SABRE or Amadeus, and ultimately I was able to automate a large part of my job with an HTA application (JavaScript with system privileges on Windows NT). After I showed my work to our IT department at the insistence of my supervisor, who thought I was breaking the rules, a mid-career developer took me aside and gave me stern advice to leave Carlson immediately and seek employment as a programmer. I had no idea that software skills were worth anything, and quintupled my income overnight.

Fifteen years later, I remember the feeling of throwing bags onto conveyor belts like it was yesterday. I loved that job, and I loved SABRE.

That developer really did you a favor! Something similar happened to me-- I didn't realize I could get a job without a comp sci degree, and now I'm a senior engineer/"tech lead", whatever that all means.

All I know is my users are happy and my test cases are passing.

My favorite early airline reservation system (mainly because of the name) is the 1952 “Magnetronic Reservisor”, which was (IIRC, I read a paper about this a few years ago but can’t seem to find it now) an electromechanical system built around a magnetic drum, but with special-purpose control circuitry rather than a general-purpose computer. Reading about the design made me very grateful that I can just use a SQL database rather than having to design my schema in hardware.

What we call a computer today is a stored program, general purpose, electronic digital computer. This was a known goal before WWII, at least within IBM. But each of those hardware features had to be developed. So, along the way, there were things like this reservation system which checked only some of the boxes on that list.

That was the heyday of special-purpose systems. Reservisor, Plan 55-A (Western Union's Sendmail made with paper tape and relays), Teleregister (stock market quotations), American Totalizator (racetrack systems), special systems for railroads, mechanically programmable Teletype "stunt boxes", plugboard-wired fire dispatching systems...

IBM had electronic arithmetic in test before WWII. But memory was hard. You needed something to store each bit, and that meant building a huge number of somethings. General purpose stored program computing had to wait until someone developed something cheap enough, large enough, and fast enough to store the program. Early electronic memory devices were the Williams tube (too expensive, not big enough), delay lines (too slow), and magnetic drums (too slow). Magnetic core finally got computing moving, but core was a million dollars a megabyte as late as 1970.

Here's an introduction to the UNIVAC File Computer.[1] The program was on a magnetic drum, so you only got maybe one or two instructions per rev. To speed things up, they had a plugboard, so you could wire up small subroutines to be triggered from a single instruction from the drum. Again, you see the struggle against memory cost and slow memory speed.

UNIVAC later hired Gen. Leslie Groves from the Manhattan Project. He thought big. The result was the UNIVAC 1103, the largest vacuum tube computer ever built as a commercial product. That monster came out in 1953. Stored programs in random access memory at last. The 1103 had everything you needed in a computer except affordability. Williams tube random access memory (1024 words of 36 bits each), large numbers of tape drives, peripherals, etc. They didn't sell many, but the successors (1103A, core memory, 1105, some transistors, 1107, all transistors) became more useful.

So, as I've mentioned before, it's not the lack of a theoretical concept of stored program computing that held back early computing. It was developing something in which to store the program and data.

[1] http://s3data.computerhistory.org/brochures/univac.file-comp...

>> Early electronic memory devices were the Williams tube (too expensive, not big enough), delay lines (too slow), and magnetic drums (too slow).

Drum memory was slow but you could time things so that one instruction finished processing just as the next one reached the head. Can't do that with core :P

That was Knuth's high school project - an angular-optimizing assembler for the IBM 650, which executed its programs from drum memory.

The IBM 650 is notable for being the first time "stored program digital computer" and "affordable" got anywhere near close.

It's a core part of the classic story of Mel too.

https://web.archive.org/web/20170309215507/http://www.pbm.co...

> Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GO TO! Put that in Pascal's pipe and smoke it.

> Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it.

> "You never know where it's going to put things", he explained, "so you'd have to use separate constants".

> It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.

> I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.

Yeah, I was alluding to The Story of Mel, a Real Programmer :)

Funny thing though, about the story. Neither the RPC-4000 [1], nor the LGP-30 [2] had an index resiter and the RPC-4000 didn't have an unconditional jump instruction (since "every single instruction was followed by a GO TO!"). The LGP-30 instruction word had two bits between opcode and operand, but the RPC 4000 had none. So Ed Nather's retelling of the hack wouldn't have been possible exactly as he describes it on either computer.

It turns out that Royal McBee had someone design an emulator for the LGP-30 to run on he RPC 4000, that could have ran Mel Kaye's blackjack program [3]. My guess is that Ed Nather is mixing up the two architectures in his mind because of that. Perhaps he was asked to modify Mel Kaye's program to run on the _emulated_ LGP-30 and the details of the two architectures got fudged in his memory. He's writing the story 23 years later so he's entitled to forget some details, I guess.

_______________________

[1] http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-400...

[2] http://ed-thelen.org/comp-hist/lgp-30-man.html

[3] http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Note...

See the following comment:

My name is James William (Bill) Bryner ... In 1960 I was hired by Royal-McBee to write the assembler for the replacement to the LGP-30, the RPC-4000.

Mel Kaye designed the RPC-4000 assembler. It was titled ROAR (Royal-McBee Optimizing Assembler Routine). Edward W. Dubbs and I programmed that assembler. Following that, I wrote an LGP-30 simulator to run on the RPC-4000. This was meant to allow all programs written for the LGP-30 to be executed on the RPC-4000 without further programming. A drum computer simulating a drum computer is agonizingly slow!

Yeah but could you program in rust?

Leslie Groves wasn’t the origin of the Univac 1103. Rather it was the NSA (or its immediate predecessor, AFSA). The 1103 was the commercialized version of the Atlas II built for the spooks.

Thank you for that bit of trivia. This looks like a fun rabbit home to spend some time going down:

https://www.nsa.gov/portals/75/documents/news-features/decla...

http://web.mit.edu/STS.035/www/PDFs/flamm.pdf

I'm off to figure out what instructions were removed from Atlas II when AFSA granted approval for it to be sold commercially. (I feel like I've read about this before and they were to-do with bit population but I can't rightly recall...)

NSA: "General Canine then forcibly expressed his exasperation by exploding: 'Build me a thousand megacycle machine! I'll get the money!'" Finally, a cite for that line.

Some good came out of that, but there was a long detour into cryogenic computing. They found a way to make gigahertz components, cryotrons. The trouble was, they couldn't make them small, or cheap, or integrated. So it was a dead end. What's come out of NSA over the years indicates that a full cyrotron computer was never built, but some "analytic tools", probably key-testers of some sort, were made. (The WWII Bombe and Colossus machines were key-testers, like Bitcoin miners, not general purpose computers.)

This is too cool. Thank you so much for that rabbit hole! I had no idea there was ever such a development program. Some simple searches on "cryotron computing" are returning some really promising-looking articles.

Don't forget https://www.amazon.com/Cryotron-Files-Computer-Scientist-Mic...

The rabbit hole is deeper. That's a really compelling-lookin book. I'm going to get my hands on it. Thanks for the recommendation.

Not the DoD buy side. The UNIVAC sell side. After the war, Groves became a VP at Remington Rand / Sperry Rand / Sperry Univac.

I actually really enjoyed reading this, as posted by phk (the BSD guru):

https://www.e-pages.dk/ingarkiv/7738/?page=1

About the SAS system in Scandinavia implemented in 1958. More like a telephone switch. Less complex maybe?

Note that you will need to read Danish.

> With SABRE up and running, IBM offered its expertise to other airlines, and soon developed Deltamatic for Delta Air Lines on the IBM 7074, and PANAMAC for Pan American World Airways using an IBM 7080. In 1968, they generalized their work into the PARS (Programmed Airline Reservation System), which ran on any member of the IBM System/360 family and thus could support any sized airline. The operating system component of PARS evolved into ACP (Airlines Control Program), and later to TPF (Transaction Processing Facility). Application programs were originally written in assembly language, later in SabreTalk, a proprietary dialect of PL/I, and now in C and C++.

https://en.wikipedia.org/wiki/Sabre_(computer_system)

I wonder how many transactions per second the same amount of money, inflation adjusted, can buy nowadays?

I can't find exact pricing info, but here's some guesstimations:

According to [0], the most recent UNIVAC cost about $1,932,000 for the base model (for purchase) or $33,060 for rent. In today's money, that's $18,337,955.71 or $313,795.45 respectively according to [1]. That's not really the UNIVAC used today (it was 7 years old by then) but I can't find pricing for the UNIVAC File Computer in 1958 so this will have to do.

Assuming the system was rented (much cheaper) and going by OVH pricing (the first hoster I could find, usually much cheaper than the big lads like Google or Amazon), this will get you about $313,795.45/$994.50 = 315 dual AMD Epyc 7402 dedicated servers.

According to [3], the UNIVAC 1105 ran about 20k operations per second. Assuming the system doesn't use floats, each AMD chip can run about 296,704 million operations per second. Ignoring overhead, that means the entire network would be able to run roughly 186.8 billion integer ops/sec.

With the expected performance of 1 to 1.5 transaction per second (let's use 1 here, for ease) for the 20k number, that would mean a similar system running on our AMD super cluster would be able to run about 9.340.000 transactions per second.

This is all rough guesswork ignoring a lot of real-life factors (like overhead, bulk pricing, price overhead of not running the servers in your own DC, network/storage latency, modern mainframes, vector instructions, etc.) but I think it shows how far general computing has come (at least 9 million times as fast for about the same price!).

[0]: https://en.wikipedia.org/wiki/UNIVAC_1105 [1]: https://www.in2013dollars.com/us/inflation/1958?amount=33060 [2]: https://books.google.com/books?id=KFAUAQAAMAAJ&lpg=PA87&ots=... [3]: https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7402&id=37...

Rent vs. buy back then is a lot tougher decision than it is now - If you turned your old rental unit in for the latest model because it was significantly faster, chances were you would have to rewrite all your software.

Which was the big advantage of the IBM System 360 - the same software would run (+/-) on all the models of the line.

Tangential, but Greenspun seems to have gone into full on crank mode.

In what way is he a crank?

Having subscribed to his blog for years, eh. He's very skeptical about US government policy re: coronavirus, but mostly in an evidence-based way: for example, he's vaccinated, but thinks lockdowns and masks are ineffective in the long run. He also has a politically incorrect sideline in poking fun at the absurdities of university wokeness and gender fluidity, but this too mostly takes the form of calling out various self-contradictions and exploitable loopholes.

Just enjoy his content that doesn't bother you. Nothing wrong with being right wing or skeptical to wokeness.

> skeptical to wokeness

The fact that awareness and concern over the abuses of fellow human beings is a pejorative is wrong.

The excesses of same are indeed excesses, e.g., the hostility to opposing of any conservative speech is wrong. But as someone who now might be identified as woke, let me just share this:

Racism is deeply embedded in this country and my "wokeness" was about realizing how fucking deep and pervasive it is. There's millions of Americans who believe that Black people are literally beneath them, e.g., not worthy of the rights of White people.

That's fucked up. Do you disagree with the passage:

    "We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness."

Wokeness is believing that statement and realizing that it not being held to.

Reply on news.ycombinator.com