home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmmain / 2880 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.8 KB  |  60 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!europa.asd.contel.com!paladin.american.edu!auvm!IS.RICE.EDU!DBOYES
  3. X-Mailer: ELM [version 2.3 PL11]
  4. Message-ID: <9212240539.AA21787@is.rice.edu>
  5. Newsgroups: bit.listserv.ibm-main
  6. Date:         Wed, 23 Dec 1992 23:39:17 CST
  7. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  8. From:         David E Boyes <dboyes@IS.RICE.EDU>
  9. Subject:      Re: Logical Partitions/Physical Partitions
  10. Comments: To: IBM-MAIN@ricevm1.rice.edu
  11. In-Reply-To:  <9212232053.AA17620@is.rice.edu>; from "Michael Stein" at Dec 23,
  12.               92 12:51 pm
  13. Lines: 45
  14.  
  15. >  - support of new hardware
  16. >    VM tends to have later support for new hardware, thus
  17. >    restricting you from installing new hardware (and selling the
  18. >    old while it's still worth something).
  19.  
  20. I've never had trouble defining new whiz-bang devices to VM as
  21. unsupported devices. Yes, VM can't use them, but if the object is
  22. to supply them to a guest MVS, who cares? Let MVS deal with them
  23. -- 3390 and 3490 support started this way, and it's been
  24. succesful in our environment with non-blue gear.
  25.  
  26. >  - complexity
  27. >    VM is much more complex than LPAR.  Besides taking system
  28. >    programmer time to support/maintain it, there are more things
  29. >    which can go wrong (I/O support, CMS which is at least needed
  30. >    to maintain VM).
  31.  
  32. I'm not sure I buy this at all. By the time you keep track of the
  33. microcode in the redundant controllers you need for good LPAR
  34. support and tune the LPAR configuration to get the right CPU caps
  35. and allocations, you've spent about as much time as you would
  36. have installing VM once and been done with it. If you are using
  37. VM for nothing but running guest MVS machines, you don't have to
  38. do diddly to VM -- you set up really big V=R/V=F areas and VM
  39. pretty much stays out of the way and lets MVS do it's thing.
  40.  
  41. There's also a pretty considerable hardware expense involved in
  42. LPAR operations -- duplicate controllers & devices aren't cheap.
  43. The cost of a used 3880/3380K on the used market is small and
  44. VM runs OK in 1 3380 box, compared to duplicating a complete
  45. system configuration for each LPAR to maintain separation of
  46. devices.
  47.  
  48. >    It's easy to say that VM and LPAR should have the same
  49. >    overhead, however it may not be.  It's probably easy to start
  50. >    using some VM services which have a large impact on the
  51. >    performance.  And if you can't use the VM services why pay for
  52. >    VM?  (reliability, $, maintenance, support etc).
  53.  
  54. LPARs are a lot easier to tune, I'll admit. I dearly wish for an
  55. absolute CPU cap in VM. Most MVS-intensive shops with VM that I know of
  56. use VM to replace real CTCA or 3088 hardware and not much else.
  57. The maintenance on one real CTCA makes up a significant portion of
  58. the cost of VM, especially for academic sites eligible for the
  59. HESC discounts.
  60.