jwgli...@gmail.com (John Gilmore) writes: > I think that IBM long ago concluded that it could not do everything, > and thus that the existence of other centers of development, the ISVs, > was and is in its best interests. > > The problem with the separate, individual consideration of the > business cases for extension A, extension B, extension C, . . . is > that there may be, often are important synergies among them. Their > one-at-a-time evaluation is simplistic. De minimis is doubtless a > good doctrine for appelate courts; in the IT industry it is a recipe > for obsolescence and with it progressive irrelevance. > > Worse, economic significance is only easy to evaluate in retrospect. > (I am old enough to remember when there was vigorous argument within > IBM about the merits, if any, of relational data base managers like > DB2.)
back before OCO (object code only) enormous amounts of innovation and new stuff was done by customers and/or ibm support people onsite at customer accounts ... which then morphs into IBM products ... CICS, IMS, HASP, ASP, etc. The joke was that products were *developed* at customer sites and then turned over to development groups for maintenance and support. Only focusing on the next quarter basically orientates to static environment with little innovation or change. some of the discord/argument between IMS group in STL and the System/R (original relation/sql) in bldg. 28 (a couple miles away) was that System/R doubled the disk space (for implicit indexes) and significantly increased disk i/o (processing the indexes). IMS directly exposed record pointers for use by application ... significantly improving machine efficiencies ... but significantly increasing administration & human management (for anything other than purely static environment). Going into the 80s, disk space costs drastically came down (mitigating the index disk space costs) and processor memory significantly increased allowing for index caching, reducing index i/o. At the same time, general dataprocessing costs came down drastically ... significantly increasing uses ... w/o corresponding increase in expertise for detailed care and feading. STL was focused on doing "EAGLE" followon for IMS ... allowing SJR to do System/R technology transfer to Endicott for release as SQL/DS. When EAGLE implodes, requests are made for how fast could System/R be ported to MVS ... where it is eventually released as DB2 ... originally for analytics and decision support *ONLY*. misc. past posts mentioning System/R http://www.garlic.com/~lynn/submain.html#systemr misc. past posts mentioning hasp, jes, jes2 networking, etc http://www.garlic.com/~lynn/submain.html#hasp msic. past posts mentioning cics, bdam http://www.garlic.com/~lynn/submain.html#cics note that 23Jun1969 unbundling announced included starting to charge for (application) software ... but managed to make the case that kernel/system software should still be free. some past posts http://www.garlic.com/~lynn/submain.html#unbundle then largely motivated by rise of clone controllers, Future System was started in the early 70s ... to completely replace 370 and be totally different ... a major objective was very tight integration of processors and controllers significantly raising the bar for clone controllers. some past posts mentioning clone controllers http://www.garlic.com/~lynn/subtopic.html#360pcm some past future system posts http://www.garlic.com/~lynn/submain.html#futuresys during the future system period 370 efforts were being suspended and/or killed off. The lack of 370 products during this period is credited with giving the clone processors market foothold. after future system implodes there is mad rush to get products back into the 370 pipelines. the rise of the clone processors also contributes to changing the decision to start charging for kernel software followed by OCO (cutting of lots of customer based innovation). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
