Article View: comp.arch
Article #22934Re: virtual memory
From: blmblm
Date: Tue, 23 May 2006 21:03
Date: Tue, 23 May 2006 21:03
58 lines
3076 bytes
3076 bytes
In article <m3zmh83608.fsf@lhwlinux.garlic.com>, Anne & Lynn Wheeler <lynn@garlic.com> wrote: >blmblm@myrealbox.com <blmblm@myrealbox.com> writes: >> Was there an acronym/initialism for this COMMON area? My memory of >> doing junior-level systems work on MVS systems is telling me that >> there was one, but not what. ? > >"common segment" ... having started out as a 1mbyte "shared" segment >in every address space. > >the hardware table look-aside buffers (TLBs) were STO (virtual address >space) associative. the result was that there were unique entries for >the same common segment entries from different virtual address spaces. > >in the early 80s, some of the high-end hardware started adding special >TLB treatment for the MVS "common segment" ... so that there would >only be one set of TLB entries for MVS common segment areas across all common segment area, common segment area .... Aha! "CSA" is the acronym/initialism I was trying to remember. (A quick Google search turns up several other alleged expansions -- "common system area", "common storage area", "common service area" -- but maybe we shouldn't worry about that.) Thanks. >MVS address spaces. However, this references a "bug" when MVS was >running as a virtual guest ... and a temporary fix ... pending >availability of MVS APAR. > >Date: 18 February 1983, 12:30:13 EST >From: xxxx > >Hi - the 'official' fix to the STBVR 0Cx abend problem is MVS APAR/ >PTF OZ67587. I don't know if it's available yet. In the meantime, >the zap works just fine. > >I'll send the zap following this note. > >//xxxxx JOB (6007,X003),xxxxxxxx,MSGLEVEL=1,MSGCLASS=O,CLASS=B, >// REGION=1024K,NOTIFY=PREISM >//ZAP EXEC PGM=AMASPZAP >//SYSPRINT DD SYSOUT=* >//SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR,UNIT=3330,VOL=SER=D00126 >** >** FOR VM MVS GUEST, STBVR, TURN OFF USE OF COMMON SEGMENTS >** > NAME IEAVNPX1 IEAVNPX1 > VER 0DA2 96026003 OI SGTCB=1 > REP 0DA2 47000000 NOP > VER 0DCE 96026003 OI SGTCB=1 > REP 0DCE 47000000 NOP >// -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor.
Technical Details
Message-ID:
<4dhbkaF1aj5dmU1@individual.net>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mailReferences:
<1147168912.656721.71000@j33g2000cwa.googlegroups.com> <m3y7x6j3wj.fsf@lhwlinux.garlic.com> <4dh2kcF1aar1vU3@individual.net> <m3zmh83608.fsf@lhwlinux.garlic.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 102b75,1231859970eae518 X-Google-Thread: fd705,2622651c2dd46327 X-Google-Thread: 103c88,b76213622410bb41 X-Google-Attributes: gid102b75,gidfd705,gid103c88,public X-Google-Language: ENGLISH,ASCII-7-bit Path: arc1-ca.pugleaf.net!g2news2.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: blmblm@myrealbox.com <blmblm@myrealbox.com> Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l Subject: Re: virtual memory Date: 23 May 2006 21:03:06 GMT Organization: None Lines: 58 Message-ID: <4dhbkaF1aj5dmU1@individual.net> References: <1147168912.656721.71000@j33g2000cwa.googlegroups.com> <m3y7x6j3wj.fsf@lhwlinux.garlic.com> <4dh2kcF1aar1vU3@individual.net> <m3zmh83608.fsf@lhwlinux.garlic.com> X-Trace: individual.net E0HCeN83xeL/y9GFSNbrIwxYQJJj7IgP9Ez7KbJ2RX+ZKk3HCd X-Orig-Path: not-for-mail X-Newsreader: trn 4.0-test76 (Apr 2, 2001)