Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: big, fast, etc, was is Vax addressing sane today
Date: Fri, 13 Sep 2024 10:38:40 -1000
Organization: Wheeler&Wheeler
Lines: 49
Message-ID: <87h6aj9tm7.fsf@localhost>
References: <vbd6b9$g147$1@dont-email.me>
	<2024Sep11.113204@mips.complang.tuwien.ac.at>
	<vbsh3q$3n09p$1@dont-email.me> <vbtqib$2sce$2@dont-email.me>
	<vbvhs3$2std$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 13 Sep 2024 22:38:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="36df20fd6dc3f01fb509adda04146b61";
	logging-data="1058058"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Nl05rrZ0jtqnwrynYsdHV+kBvDiEysPQ="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:7NuCPvIWqswtlZ97/w77DodzyFw=
	sha1:ivS/QLa9OuiXVPMzBiCaXvBHLcA=
Bytes: 3670

John Levine <johnl@taugh.com> writes:
> That's fine for workloads that work that way.
>
> Airline reservation systems historically ran on mainframes because when they were invented
> that's all there was (original SABRE ran on two 7090s) and they are business critical so
> they need to be very reliable.
>
> About 30 years ago some guys at MIT realized that route and fare search, which are some of
> the most demanding things that CRS do, are easy to parallelize and don't have to be
> particularly reliable -- if your search system crashes and restarts and reruns the search
> and the result is a couple of seconds late, that's OK. So they started ITA software which
> used racks of PC servers running parallel applications written in Lisp (they were from
> MIT) and blew away the competition.
>
> However, that's just the search part. Actually booking the seats and selling tickets stays
> on a mainframe or an Oracle system because double booking or giving away free tickets would
> be really bad.
>
> There's also a rule of thumb about databases that says one system of performance 100 is
> much better than 100 systems of performance 1 because those 100 systems will spend all
> their time contending for database locks.

after leaving IBM was brought into largest airline res system to look
ten impossible things they can't do. Got started with "ROUTES" (about
25% of the mainframe workload), they gave me a full softcopy of OAG (all
scheduled commercial flt segments in the world) ... couple weeks later
came back with ROUTES that implemented their impossible things.
Mainframe had tech trade-offs from the 60s and started from scratch
could make totally different tech trade-offs, initially ran 100 times
faster, then implementing the impossible stuff and still ran ten times
faster (than their mainframe systems). Showed that ten rs6000/990 could
handle workload for every flt and every airline in the world.

Part of the issue was that they extensively massaged the data on a
mainframe MVS/IMS system and then in sunday night, rebuilt the mainframe
"TPF" (limited datamanagement services) system from the MVS/IMS
system. That was all eliminated.

Fare search was harder because it started being "tuned" by some real
time factors.

Could move all to RS/6000 - HA/CMP. Then some very non-technical issues
kicked-in (like large staff involved in the data massaging).  trivia: I
had done a bunch of slight of hand for HA/CMP RDBMS distributed lock
manager scaleup for 128-processor clusters.


-- 
virtualization experience starting Jan1968, online at home since Mar1970