🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22934

Re: virtual memory

#22934
From: blmblm
Date: Tue, 23 May 2006 21:03
58 lines
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-mail
References: <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)