more shared segment archeology

[Anne & Lynn Wheeler]

One of the reasons the vm development group picked up so much from the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

to ship in the (vm370 product) release 3/4 time-frame was a lot of
the resources had been diverted to FS ... similar to the reference in
this post
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
in this old email
http://www.garlic.com/~lynn/2007f.html#email800117

and some followup to the above
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

and lots of past posts mentioning future system project
http://www.garlic.com/~lynn/subtopic.html#futuresys

and then there was a relatively short window between the demise of FS
(and return of the diverted resources) and when POK convinced
corporate to completely shutdown VM and move all the people to POK to
support MVS/XA development ... as part of trying to get MVS/XA out the
door (everybody was scrambling to make up for lost time because of
FS). The reference in this post to POK convincing corporate about VM
shutdown and all the people diverted to MVS/XA (and Endicott salvaging
some of the VM mission) ... glosses over the period with lots of
resources diverted to work on FS
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history

In addition to development group having to play catch-up (by picking
up stuff from the science center for product ship; because of period
when a lot of resources were diverted to FS), there were also some
amount of stuff that had been dropped in the morph from cp67 to
vm370. I continued to work on cp67 during this period and then when
the science center got a 370/155-II ... ported a bunch of stuff to
vm370. Old communication from 1973 about porting/enhancing a bunch of
science center stuff from cp67 to vm370
http://www.garlic.com/~lynn/2006v.html#email731212
in this post
http://www.garlic.com/~lynn/2006v.html#36 Why these original FORTRAN quirks?

and related email from 1975 ... creating an "enhanced" vm rel2 system
for shipment to internal accounts:
http://www.garlic.com/~lynn/2006w.html#email750102
in this post
http://www.garlic.com/~lynn/2006w.html#7 Why these original FORTRAN quirks?
and
http://www.garlic.com/~lynn/2006w.html#email750430
in this post
http://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

One of the items was whole restructuring for what I called virtual
memory management ... which included a bunch of bells and whistles
related to virtual memory segments as well as being integrated with
page mapped filesystem changes for CMS.

Much of the internal restructuring for handling virtual memory
segments was picked up as part of release 3 DCSS ... however only a
small subset of the function that utilized that restructuring was
actually shipped as part of release 3 DCSS.

I had also gotten roped into doing a lot of the ECPS work for Endicott,
old reference here
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#27 370 ECPS VM microcode assist
http://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist

and at the same time various SMP work ... old "VAMPS" email from 1975
http://www.garlic.com/~lynn/2006w.html#email750827
in this post
http://www.garlic.com/~lynn/2006w.html#10 long ago and far away, vm370 from early/mid 70s

lots of other posts mentioning VAMPS (5-way SMP project)
http://www.garlic.com/~lynn/subtopic.html#bounce

and lots of posts making general mention of SMP and/or compare&swap instruction
http://www.garlic.com/~lynn/subtopic.html#smp

Another shared segment "feature" was a line item called DWSS that was
part of system/r technology transfer from SJR to Encidott for SQL/DS
product ... which allowed for shared segments that were "writable"
(i.e. not r/o protected). A big issue with DWSS was what to do about
ECPS microcode already in the field that supported "r/o protection"
games for all segments identified as shared.

This was another downstream fall-outs of letting the 165 hardware
engineers gain six months in the vritual memory hardware change
schedule for 165-ii ... by letting them drop various features from the
370 virtual memory architecture. recent references
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history

One of the features dropped was the hardware segment table
"protection" bit ... which allowed specification of hardware r/o
protection for virtual memory segments on a virtual address space
basis (i.e. some address spaces could be allowed r/w segment storage
operation while other address spaces were not allowed to change the
same shared segment). This also caused a big retrofit hit to vm370
since cp&cms had already been re-organized to take advantage of the
feature ... when it was dropped ... a real cludge was created ... also
referenced here
http://www.garlic.com/~lynn/2007d.html#32 Running OS/390 on z9 BC

effectively the original basis leading to the conflict with ECPS
and DWSS ... work referenced in this old email (also above)
http://www.garlic.com/~lynn/2007f.html#email800117

mentions shared segment extensions done initially at SJR in the
mid-70s for support of system/r (DWSS) ... original relational/sql ...
various posts mentioning system/r
http://www.garlic.com/~lynn/subtopic.html#systemr

This post (also mentioned above)
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

references a san jose research report from May '75 ... about shared
segment and inter-processor communication for vm370 in support of
system/r effort. also mentioned in this SQL reunion item:
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Vera.htm

something similar also mentioned being shipped in this internal
release2 plc15 system (besides the virtual memory management stuff)
was also the (POK) SPM (which had originally been implemented by the
Pisa Science Center on cp67 and later converted to vm370)
http://www.garlic.com/~lynn/2006w.html#mail750430

other posts mentioning DWSS:
http://www.garlic.com/~lynn/2000.html#18 Computer of the century
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2002g.html#59 Amiga Rexx
http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004f.html#26 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006w.html#11 long ago and far away, vm370 from early/mid 70s
http://www.garlic.com/~lynn/2006y.html#26 moving on

[j***@aol.com]

Post by Anne & Lynn Wheeler
One of the reasons the vm development group picked up so much from the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech

<snip>

Post by Anne & Lynn Wheeler
One of the features dropped was the hardware segment table
"protection" bit ... which allowed specification of hardware r/o
protection for virtual memory segments on a virtual address space
basis (i.e. some address spaces could be allowed r/w segment storage
operation while other address spaces were not allowed to change the
same shared segment).

Without doing any of my homework, and just reacting with my gut,
this sounds like a very stupid decision to have made. Now,
this is based on our OS philosophy about security. Part of
security was to be able to not allow any writing, especially by
the bugs.

Also note that our file protection scheme included execute-only
and was settable by the owner of the file.


<snip>

/BAH

[Anne & Lynn Wheeler]

Post by j***@aol.com
Without doing any of my homework, and just reacting with my gut,
this sounds like a very stupid decision to have made. Now,
this is based on our OS philosophy about security. Part of
security was to be able to not allow any writing, especially by
the bugs.
Also note that our file protection scheme included execute-only
and was settable by the owner of the file.

re:
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology

370 virtual memory had/has two level tables for virtual memory
... each address space had a segment table with segment table entries
pointing to individual page tables (for each segment). Shared segments
was achieved by having different segment tables entiries point at the
same page table.

the original 370 virtual memory architecture had a flag in the segment
table entry indicating whether there was r/w or r/o access (by a
virtual address space) to a segment. this got dropped from 370 virtual
memory architecutre (before ever shipping to customers) as part of
improving schedule for 165-11 virtual memory by six months.

as a result, vm had to go back and create a cludge for supporting
protection of shared segments (actually a couple generations of
cludges). a flavor of this protection involved some amount of kernel
code ... which also got copied into the ECPS microcode assist (a 10:1
performance improvement in code that was moved from kernel 370
instructions into machine microcode ... or at least 10:1 improvement
for some heavily microcoded machines). lots of past post mentioning
machine microcoding
http://www.garlic.com/~lynn/subtopic.html#mcode

system/r effectively had semi-privilged "shadow" processes for doing
database work (running in their separate virtual address space
... slightly analogous ... but different to setuid root process).
these "shadow" processes needed to be able to have r/w access to
common shared memory (across all processes operating on the same
database). lots of past post mentioning original relational/sql
http://www.garlic.com/~lynn/subtopic.html#systemr

this requirement for shared r/w access to common shared memory created
a product ship issue conflicting with standard kernel support. If it
was just software kernel ... then just ship new kernel with the
necessary changes ... however there were already quite a number of of
machines in customer shops where parts of the kernel were now part of
the machine microcode. The ECPS microcode created a (significant)
"service" expense issue to make sure that a field engineer updated the
machine microcode at the same time the new kernel for system/r
operation was installed. For instance who was to absorb the expense of
this field engineer microcode update coordination ... even the expense
to sending all possible field engineers to update class ... or even
developing the field engineer documentiation.

for other topic drift ... system/r related post in comp.database.theory
http://www.garlic.com/~lynn/2007f.html#15 Designing database tables for performance