Charles Mills wrote: > Pet peeve. Saying mainframes versus servers is like saying Fords versus > cars. A mainframe typically IS a server (often among other roles). The first > definition Google comes up with for server is "A computer that delivers > information and software to other computers linked by a network." I would > quibble with that definition (server is also used to describe software) but > it certainly fits most mainframes. IBM lists "System Z" under Servers on > their home page so I think IBM agrees with this theory. > > If we mean "**ix and Windows boxes" or "non-mainframe boxes" then let's say > that. > > I'm not just quibbling over semantics. When I read "vendors are promoting > server solutions" I get a totally different image in my mind versus that > which I get when I read "vendors are promoting **ix and Windows solutions." > > While I'm here, I don't think non-mainframe platforms are inherently more > profitable for software vendors. Indeed, the traditional mainframe software > vendors have struggled trying to achieve the same profitability with their > "other box" offerings. Non-mainframe platforms are attractive and profitable > for software vendors because that is where BOD and CIO focus is.
this was long struggle/battle with the communication group. my wife constantly ran into it, first when she co-authored AWP39, peer-to-peer networking in the same timeframe as SNA was getting started. recent posting referring to that period http://www.garlic.com/~lynn/2006x.html#8 vmshare ... then later when she was con'ed into going to POK to be in charge of loosely-coupled architecture and authored peer-coupled shared data architecture http://www.garlic.com/~lynn/subtopic.html#shareddata which didn't see a lot of uptake, except for IMS hot-standby, until sysplex. however, there was also constant battles with the communication group ... pushing master/slave, dumb terminal paradigm. there was eventually some truce where peer-to-peer could be used within glass house walls ... but dumb terminal paradigm had exclusive control over crossing glasshouse boundary. along came PCs ... and dumb terminal emulation helped see PCs have quite a bit of uptake early on. however, later when the PCs started to move into client/server ... it started to really impact the dumb terminal emulation install base. http://www.garlic.com/~lynn/subnetwork.html#emulation About the time we had come up with 3-tier architecture and was out pushing it in customer executive presentations, the communication group had come up with SAA. SAA could somewhat be construed as attempts to put the client/server guinee back into the bottle ... and were were taking lots of hits from SAA and the communication group out pushing 3-tier http://www.garlic.com/~lynn/subnetwork.html#3tier in that same time-frame ... the disk division had come up with a number of products that would have allowed extremely high-bandwidth between the distributed environment and potential glasshouse servers. The communication organization consistently managed to have such products shot down (based on communication group "owning" everything crossing the boundary with the glasshouse). Finally, one of the high-level senior disk engineers managed to get a talk scheduled for the annual, world-wide communication group's internal conference. However, it didn't quite start out as advertised, since he opened the talk by stating that the communication group was going to be responsible for the demise of the disk division (because the strangle hold that the communication group had on the glasshouse was resulting it huge leakage/replication of glasshouse data out into the distributed environment, there were hard numbers about the annual migration/leakage percentage over a number of years). past posts mentioning the talk claiming demise of the disk division. http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0 http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is) http://www.garlic.com/~lynn/2003p.html#39 Mainframe Emulation Solutions http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2006k.html#25 Can anythink kill x86-64? http://www.garlic.com/~lynn/2006l.html#4 Google Architecture http://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later http://www.garlic.com/~lynn/2006r.html#4 Was FORTRAN buggy? http://www.garlic.com/~lynn/2006r.html#20 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006x.html#7 vmshare some somewhat related activity with regard to NSFNET http://www.garlic.com/~lynn/2006w.html#21 SNA/VTAM for NSFNET http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning) http://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
