The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
ma...@resa.net (Warner Mach) writes: > I believe that I have identified an interesting phenomenon > in the ongoing mainframe vs distributed servers debate. I > call this the 'small server mob advantage.' there are numerous situations (not just servers) were there can be smaller upfront/initial costs ... but scale less well. an earlier version of this was huge proliferation in 4341s (actually mid-range, dec/vax experienced something similar in the same market). cluster of six 4341s were cheaper than 3033, had more aggregate mips, more aggregate storage, and more aggregate channels and more aggregate i/o capacity. some of the big customers would order 4341s in multiples of a hundred at a time (something that dec/vax didn't really see). misc. old 4341 related email http://www.garlic.com/~lynn/lhwemail.html#4341 going into mid-80s ... there was some anticipation that 4381s would see similar success ... however, by that time, the mid-range market was starting to shift to workstations & large PCs. SHARE had some statements that 4341s would have seen even larger penetration (at expense of dec/vax) ... but dec/vax had lower entry care&feeding costs (i.e. less effort and lower skill level). At the time, some internal locations were bursting at the seams in terms of raised floor and 4341s were solution to installing additional computing power ... out in department areas (at some locations, conference rooms became a very scarce resource ... because so many were being taken over for 4341s). The other big (distributed 4341) innovation was much easier/faster to roll-out new feature/function ... compared to datacenter. Moving more of the virtual machine function into the hardware ... for LPARs ... was partially response to Amdahl's hypervisor .... but it also provided some capability to helping testing new feature/function in (single) large consolidated mainframe resource environment (that had enormous barriers to change/adapting). A relatively "funny" joke from the period ... was that JES2 networking tables effectively was part of large system change control. The internal network had significantly more nodes than could be defined in JES2 ... and so most MVS systems were restricted to edge nodes. Internal users that actually tried to do things from MVS systems were constantly attempting to deal with those network nodes that were currently defined in that particular system (and just getting change to the JES2 network table frequently would take a month or two ... as part of the next MVS system load/test) ... this was aggrevated by JES2 tossing traffic if it didn't have the destination node defined (in case the traffic might have to go someplace else) ... but also would toss traffic if it didn't have the originating node defined. This was in an environment when not only were there much large number of network nodes ... than could be defined in JES2 ... but one or more new network nodes might be coming online everyday (someplace in the world) ... old reference to list of internal locations that had one or more new networking nodes in 1983 (internal network had more nodes than arpanet/internet from just about the beginning until possibly late '85 or early '86) http://www.garlic.com/~lynn/2006k.html#8 misc. past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
