home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!utcsri!torn!nott!dgbt!netfs!ub!zaphod.mps.ohio-state.edu!darwin.sura.net!europa.asd.contel.com!paladin.american.edu!auvm!VCCSCENT.BITNET!SOMITCW
- From: SOMITCW@VCCSCENT.BITNET
- Newsgroups: bit.listserv.ibm-main
- Subject: Re: STORAGE BELOW 16M LINE
- Message-ID: <IBM-MAIN%92111209583070@RICEVM1.RICE.EDU>
- Date: 12 Nov 92 15:05:07 GMT
- Sender: IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
- Lines: 27
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
-
-
- On Thu, 12 Nov 1992 01:36:00 PST, LDW@USCMVSA wrote:
- >Right. Except that on a uniprocessor, I thought that MVS doesn't
- >bother with prefixing because there's no need.
-
- When we ran MVS/SP 1.3.6 on a uniprocessor, it still did
- PREFIXing. It may have been because we coded the ACR CODE YES
- in the stage 1 to be compatible with DUAL processors.
- I believe VM/SP works the same way.
-
- >But when I was running MVS/SP 1.3 under VM/SP R3 (or was it HPO R3?)
- >in a 4M V=R area, LRA on page 0 returned an address outside of what
- >MVS saw as it's real storage. - - -
-
- Yes, VM is sneaky. When you have a V=R area, VM has to define
- the lowest address in the machine to the V=R area. You couldn't
- expect MVS to have what it sees as real storage to start somewhere
- in the middle of memory. Your 4 meg V=R area took the first 4 meg
- of real memory. VM must have the real ( and also the absolute )
- page zero. The real OLD/NEW PSWs and interrupts are in real page
- zero, the VM trace table pointers are in the absolute page zero.
- The way VM resolves the conflict is to keep absolute page zero
- and map the V=R page zero to be immediately after the 4 meg V=R
- area. V=R page 1 through 4 meg are really V=R. V=R page zero
- is not really V=R. This causes at least one restriction when
- using V=R, MVS or any other operating systems running V=R cannot
- do any I/O to page zero after you SET NOTRANS ON.
-