10 ms·
A 1958 UNIVAC airline reservation system
- wolfgang42 5y agoMy 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.
- Animats 5y agoWhat 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-computer.1951.102646303.pdf http://s3data.computerhistory.org/brochures/univac.file-comp...
- YeGoblynQueenne 5y ago>> 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
- Animats 5y agoThat 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.
- monocasa 5y agoIt's a core part of the classic story of Mel too. https://web.archive.org/web/20170309215507/http://www.pbm.com/~lindahl/mel.html 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.
- dmbaggett 5y agoI’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.
- 3dbrows 5y agoAs 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.
- ahefner 5y agoDid you ever consider starting a small airline as customer #0 for the reservation system?
- Marazan 5y agoYou don't make money in the airline industry by being an airline.
- ghaff 5y agoI 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.
- pinewurst 5y agohttps://sci-hub.se/10.1145/1458043.1458075 https://sci-hub.se/10.1145/1458043.1458075
- pinko 5y agoMods: this is a better link than the OP.
- pstuart 5y agoTangential, but Greenspun seems to have gone into full on crank mode.
- nradov 5y agoIn what way is he a crank?
- pstuart 5y ago[flagged]
- nradov 5y agoWhat do you mean specifically? I don't see anything hard core right wing.
- pstuart 5y agoHis takes on Trump, #metoo, LGBTQ, etc are consistently framed in a manner that would appeal to the Scott Adams crowd. I'm sure it appeals to a fair portion of the audience here but I found it unpalatable.
- nradov 5y agoSo you're just making vague and unsupported allegations based on your own political prejudices. Got it.
- pstuart 5y agoFine, you want crank? Have some crank: https://philip.greenspun.com/blog/2021/11/05/stoking-coronapanic-is-a-good-way-to-destroy-traditional-religion/ https://philip.greenspun.com/blog/2021/11/05/stoking-coronap...
- 5y ago
- MichaelZuo 5y agoI wonder how many transactions per second the same amount of money, inflation adjusted, can buy nowadays?
- jeroenhd 5y agoI 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 https://en.wikipedia.org/wiki/UNIVAC_1105 [1]: https://www.in2013dollars.com/us/inflation/1958?amount=33060 https://www.in2013dollars.com/us/inflation/1958?amount=33060 [2]: https://books.google.com/books?id=KFAUAQAAMAAJ&lpg=PA87&ots=P5P9L6bAR6&dq=UNIVAC%201105%20operations%20per%20second&pg=PA87#v=onepage&q=UNIVAC%201105%20operations%20per%20second&f=false https://books.google.com/books?id=KFAUAQAAMAAJ&lpg=PA87&ots=... [3]: https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7402&id=3713&cpuCount=2 https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+7402&id=37...
- chiph 5y agoRent 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.
- netaustin 5y agoA 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.
- sushsjsuauahab 5y agoThat 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.
- sgt 5y agoI actually really enjoyed reading this, as posted by phk (the BSD guru): https://www.e-pages.dk/ingarkiv/7738/?page=1 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.
- pjmlp 5y ago> 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) https://en.wikipedia.org/wiki/Sabre_(computer_system)