home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmmain / 2878 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.4 KB  |  58 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!UCLAMVS.BITNET!CSYSMAS
  3. Message-ID: <IBM-MAIN%92122314530248@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Wed, 23 Dec 1992 12:51:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
  8. Subject:      Re: Logical Partitions/Physical Partitions
  9. Lines: 47
  10.  
  11. > With all of the "maybe"s and "there is a possibility"s, it
  12. > sounds like you should be running VM/ESA on the bare metal
  13. > (unpartitioned).  Given identical configurations (all-dedicated
  14. > everything, idential main store, identical ESTORE), the
  15. > performance of a production guest under LPAR and under VM/ESA
  16. > should be about the same (after all, VM and LPAR are both using
  17. > the same machine facilities to do their job).  VM gives you the
  18. > option of running your test systems V=V, so that you don't tie
  19. > up valuable system resources (core, channel paths) for
  20. > partitions that you aren't using very much.  Besides, it comes
  21. > with CMS!
  22.  
  23. VM is nice for testing systems (running test systems), however
  24. there are some problems in running production MVS systems
  25. under it.
  26.  
  27.  - reliability
  28.    VM adds yet another point of failure to your MVS system.  Also
  29.    in my experience VM isn't as good at recovering from errors as
  30.    MVS -- thus it's not just another point of failure, it's worse
  31.    than just twice as bad as MVS alone.
  32.  
  33.  - support of new hardware
  34.    VM tends to have later support for new hardware, thus
  35.    restricting you from installing new hardware (and selling the
  36.    old while it's still worth something).
  37.  
  38.  - complexity
  39.    VM is much more complex than LPAR.  Besides taking system
  40.    programmer time to support/maintain it, there are more things
  41.    which can go wrong (I/O support, CMS which is at least needed
  42.    to maintain VM).
  43.  
  44.  - performance (?)
  45.    It's easy to say that VM and LPAR should have the same
  46.    overhead, however it may not be.  It's probably easy to start
  47.    using some VM services which have a large impact on the
  48.    performance.  And if you can't use the VM services why pay for
  49.    VM?  (reliability, $, maintenance, support etc).
  50.  
  51. We run an ES/9000-600 shared between academic and administrative
  52. computing.  There are 4 LPARs, divided as follows:
  53.  
  54.  -  academic MVS production
  55.  -  academic VM (test MVS, AIX, test AIX, test VM)
  56.  -  administrative MVS production
  57.  -  administrative test MVS
  58.