home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / bit / listserv / ibmmain / 2622 < prev    next >
Encoding:
Text File  |  1992-11-11  |  1.5 KB  |  35 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%92111203373856@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Thu, 12 Nov 1992 01:36:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: STORAGE BELOW 16M LINE
  9. Lines: 24
  10.  
  11. On Wed, 11 Nov 1992 11:18:42 IST,
  12.    Doron Shikmoni <P85025@BARILVM.BITNET> said:
  13. > I may be missing something (I joined this thread in the middle). However:
  14.  
  15. The discussion started on JES2-L, and I suggested that it belonged here
  16. instead.
  17.  
  18. > Of course page 0 is prefixed. Even on native MVS (non VM) machines, page 0
  19. > is prefixed (prefix register, remember). This is over and above DAT, as the
  20.  
  21. Right.  Except that on a uniprocessor, I thought that MVS doesn't
  22. bother with prefixing because there's no need.
  23.  
  24. But when I was running MVS/SP 1.3 under VM/SP R3 (or was it HPO R3?)
  25. in a 4M V=R area, LRA on page 0 returned an address outside of what
  26. MVS saw as it's real storage.  So VM (that version, anyway) may not
  27. have done virtual prefixing in a nice manner.  Did VM/SP R3 support
  28. multiprocessors?  If not, then it may not have had any code to do
  29. prefixing, and used this trick when dispatching the V=R guest to allow
  30. it to store into it's PSA.  I don't really understand what was going
  31. on, and I presented it more as a counter-example to a claim that LRA
  32. would never return an address greater than the real storage size.
  33.  
  34. /Leonard
  35.