The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Edward Jaffe) writes: > Write-protected subpools?! No such thing! > > I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What > that does is put RENT code into subpool 252, which is key zero > storage. Therefore, programs running in PSW key zero can modify SP 252 > storage. > > To get complete protection of all RENT modules, you must use the > CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the > modules once they're loaded. I don't recommend that setting on systems > older than z/OS V1R8 because there are several popular IBM programs, > residing in SP 252, that "legitimately" update themselves and whose > module names don't appear in the exception table until that release. > > [Disclaimer: DIAG traps are not intended for use on production systems.] the inverse of this is sort of one of the problems left over from 370/165 falling behind schedule with 370 virtual memory hardware ... and picking up six months by dropping a bunch of stuff that was in the original 370 virtual memory architecture (and the "mainstream" pok operating system people stating they couldn't really see any use for it anyway). this then met that the other 370 models (many that had already had finished 370 virtual memory architecture implementation) had to be retrofitted to conform to what 370/165 was implementing. one of the things that got dropped out of this (read-only) segment protect. one of the nice things about having read-only protection at the segment table level ... was that some address spaces could have protection turned on and other address spaces w/o protection ... for the same area. in cp67, shared pages was offered for cms (and other) virtual address spaces by playing games with the storage protect keys ... and making sure that no virtual address space PSW was really dispatched with key zero. with the appearance of segment protect with 370 virtual memory architecture, cms was restructured (along with appropriate vm370 changes) to align r/o protected areas on segment boundaries. then came the 370/165 bomb shell for 370 virtual memory architecture ... and the whole vm370/cms strategy had to refitted to implement the cp67 storage protect key scheme. I had done a cms paged mapped filesystem originally on cp67 ... and ported it to vm370 ... http://www.garlic.com/~lynn/subtopic.html#mmap i introduced a lot of segment-based operations that could be done across different address spaces. one was that disk resident executables could be mapped directly to segment protected execution shared across multiple different address spaces ... and the segments could appear at arbitrary different virtual addresses in different address spaces. since a lot of cms application code was done based on os/360 derived compilers ... it was heavily loaded with os/360 relocatable address constant convention. now, this is one of the things that tss/360 had done right ... so that execution images on disk could be treated as strictly read-only (the image on disk and the executing image was exact) and still execute at an arbitrary virtual address (executable images contained no embedded address constants that had to be swizzled as part of loading for execution) http://www.garlic.com/~lynn/subtopic.html#adcon this also caused some perturbation in the original relational/sql implementation (all done as a vm370-based implementation). http://www.garlic.com/~lynn/subtopic.html#systemr where there was going to be some (virtual address space/)processes that had r/w access to the data ... but there was design that had application with access to some of the same data ... only unable to change that data. it was ideally designed to take advantage of the original 370 virtual memory architecture segment protection. however, the implemention then required some amount of fiddling for release as sql/ds. for some trivia ... one of the people in the following meeting claimed to have been primary person handling sql/ds technology transfer from endictt back to stl for db2 http://www.garlic.com/~lynn/95.html#13 misc. past posts mentioning 370/165 hardware schedule problems implementing 370 virtual memory http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2006.html#13 VM maclib reference http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? http://www.garlic.com/~lynn/2006j.html#5 virtual memory http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
