Re: Hashing for DISTINCT or GROUP BY in SQL
Date: Fri, 15 Oct 2010 18:38:19 -0400
paul c <anonymous_at_not-for-mail.invalid> writes:
> In the 1970's IBM brought out a system called the S/38. It was really
> radical, having a linear addressing scheme that merged memory and
> whatever devices were attached, so the fixation on individual devices
> was ignored. Apparently internal politics at IBM limited the size of
> the S/38 so that it wouldn't compete with the big mainframes.
> Customer operations staff used to need to go to IBM courses to learn
> what operating system options needed to be toggled to enable the
> addition of peripherals. Some other companies like Burroughs had
> machines even before then that required no software changes to attach
> a new disk drive, in some cases not even down time so Burroughs didn't
> make any money charging for courses to learn how to do that. Wasn't
> Burroughs stupid!
folklore is that with the failure of FS ... some of the people retreated to rochester and came out with an extremely scaled-back subset.
One of the issues that helped kill FS was study that claimed that if an FS machine was built from fastest 370 technology then available (370/195), applications running on that machine would have thruput of 370/145 (about 30 times slower machine). s/38 wasn't limited ... it just was selling into market that didn't notice a possible 30 times slow down.
s/38 larger linear space motivated it to be original disk RAID adopter. there was folklore about taking days to restore a s/38 after a single disk failure ... since all disks were treated as single pool with possible scatter allocation occuring across all disks (you didn't back up a single disk ... you backed up the whole system as an single unit). up until then there needed to some attention paid to disk operation since it was a common failure/recovery scenario.
besides letting me play DBMS in bldg. 28 ... they also let me play disk disk engineer in bldgs. 14&15 ... one of the engineers there has patent from the 70s on RAID technology originally deployed by s/38.
independent of that there has been this whole CKD DASD vis-a-vis FBA discussion. CKD DASD was something of sensible trade-off in the 60s ... but the balance was already starting to shift by the mid-70s ... with the disk division came out with FBA disks. All the platforms except the favorite son, mainstream MVS operating system, added support for FBA512 (where it was no longer necessary to change software for new disks with different sizes and/or geometries).
All devices are now FBA512 ... even those that are supposedly CKD DASD ... which is actually a hardware emulation on top of underlying FBA512 device.
There is now some drive to move to FBA4096 implementation (because of various factors like error correction efficiencies) and there are recent discussions about various platforms which may or may not be able to handle FBA4096 transparently.
-- virtualization experience starting Jan1968, online at home since Mar1970Received on Fri Oct 15 2010 - 17:38:19 CDT