home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / bit / listserv / ibmmain / 2062 < prev    next >
Encoding:
Text File  |  1992-08-29  |  1.4 KB  |  30 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBM-MAIN%92082904365224@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Sat, 29 Aug 1992 02:35:00 PDT
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: PLPA and COMMON on the same volume
  9. Lines: 19
  10.  
  11. I've had PLPA and COMMON on the same volume for many years -- since
  12. the 64M 3090 at my previous employer.  I looked at the paging rates
  13. for PLPA and for common, and they were something like 2/min and 0/min,
  14. so I figured it was reasonable to put them on the same volume.  I
  15. sized them normally, i.e., no overflow from PLPA to COMMON.  I have
  16. some vague recollection of a negative performance implication from the
  17. overflow.  Maybe the init and tuning mentions this.  Unless your
  18. paging rate to both datasets is noticably different from zero, I
  19. wouldn't bother with the overflow business.  For one thing, you get an
  20. ugly message at IPL time, and for another, you need to turn off the
  21. Omegamon warning about that event.  I just make sure that PLPA and
  22. COMMON are next to each other and to the VTOC.
  23.  
  24. /Leonard
  25.  
  26. P.S.  The first time I ever saw the IPL-time complaint about overflow
  27. was a couple months ago when I brought up my new CBIPO 3.1.3 system
  28. (which replaced an older 3.1.3 CBIPO system.)  The upleveled products
  29. in PLPA must have grown by quite a bit.
  30.