home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / folklore / computer / 16471 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.9 KB  |  54 lines
  1. Newsgroups: alt.folklore.computers
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!rpi!news.columbia.edu!watsun.cc.columbia.edu!lasner
  3. From: lasner@watsun.cc.columbia.edu (Charles Lasner)
  4. Subject: Re: ASSEMBLY LANGUAGE IBM
  5. Message-ID: <1992Nov20.045846.18835@news.columbia.edu>
  6. Sender: usenet@news.columbia.edu (The Network News)
  7. Nntp-Posting-Host: watsun.cc.columbia.edu
  8. Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
  9. Organization: Columbia University
  10. References: <BxtpIv.AMD@mentor.cc.purdue.edu> <STEVEV.92Nov17104240@miser.uoregon.edu> <1992Nov18.134855.28580@geovision.gvc.com>
  11. Date: Fri, 20 Nov 1992 04:58:46 GMT
  12. Lines: 40
  13.  
  14. In article <1992Nov18.134855.28580@geovision.gvc.com> pt@geovision.gvc.com writes:
  15. >stevev@miser.uoregon.edu (Steve VanDevender) writes:
  16. >
  17. >>I suspect that the questions apply to IBM's most famous series of
  18. >>machines, the 360/370 series.  If you thought them placing
  19. >>increasingly souped-up versions of the 8088 in IBM PCs was bad,
  20. >>note that the 360/370 series has been using the same instruction
  21. >>set and processor architecture for nearly _30 years_.  IBM's
  22. >>top-end mainframes (like the 3090) still run IBM 360 programs in
  23. >>binary form.
  24. >
  25. >From this I infer that you consider it a ``bad thing'' that an IBM mainframe
  26. >(or PC) user can upgrade his hardware without buying new versions of commercial
  27. >software?
  28.  
  29. All that was stated is that the binary object modules of older programs can
  30. be made to run on the new machine.  In practice, this may be inadequate
  31. depending on what the newer model actually has available on it.  Moreover,
  32. IBM has tended to proliferate excessive versions of their O/S on these
  33. machines, as if they actually were separate and incompatible.  Those of
  34. us used to either a relatively limited number of say VMS or unix variants
  35. don't appreciate the extraneous nature of artifically distinct O/S variants
  36. sold as separate entities.  This tends to make one rethink the worth of
  37. staying with a family of machines where you actually do have to keep buying
  38. what is substantially the same software again and again without the means
  39. to recycle it.
  40.  
  41. In the early 370 days, IBM had a campaign to extraneously introduce 370-only
  42. instructions into major components of O/S, so that they couldn't run on
  43. 360's.  Various users distributed patches to remove the extraneous
  44. dependancies, so that purchased versions of O/S 370 could run on high-end
  45. 360's that were otherwise viable.  IBM wanted them plowed under and then
  46. make the customer buy the latest and the greatest.  But companies such
  47. as ITEL were refurbishing 360's and making them have new buss peripherals,
  48. so it was necessary to keep the software compatible in spite of IBM's
  49. attempts at planned obsolescence, and what effective amounts to restraint of
  50. trade in this situation (by making ITEL's product less attractive since it
  51. was claimed to only run obsolete versions of the software, etc.).
  52.  
  53. cjl
  54.