On Sun, 22 Oct 2006 09:19:36 -0700, Edward Jaffe <[EMAIL PROTECTED]> wrote: > > I've never understood why the CsvRentSp252 DIAG trap is necessary. What > is the rationale for ignoring the RENT attribute for unauthorized > programs? Authorized or not, a RENT program that modifies itself in an > unserialized way has a bug that could have serious ramifications for the > application. IMHO, by ignoring the RENT option for unauthorized > programs, the operating system does their owners a great disservice. > I feel that way about various z/OS features.
I assume it was a "dusty deck" collateral damage. By the time that someone recognized how it should be done right, there was a sufficient residue of self-modifying customer code (mis-)marked RENT that it was too late to change. But that could be fixed by re-linking. In the worst case, NE load modules with the source lost, a utility could be supplied to reset the RENT bit. > Currently, there is a "refreshable" attribute that the binder > understands. That attribute is completely ignored by the operating > system. If the distinction between RENT and REFR were surfaced in > contents supervisor control blocks (there is a CDRENT flag bit in the > CDE but no CDREFR flag bit), then it's conceivable IBM could, without > too much effort, make REFR imply page protection. With that, we would > not need the CsvRentProtect DIAG trap and its associated exception > table! Our platform could do away with module overlays once and for all! > It would be tremendous RAS improvement! > My understanding is that the design motivation was to be able to re-fetch a REFR load module in case of detected physical damage to a page. Either lost in a redesign, or never fully implemented. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
