> I understand, diachronically, why REFRPROT was made an option: > to maintain compatibility with existing "dusty deck" load modules. > Where the source no longer existed. And the modules were linked > NE. > > But why, in the beginning, as soon as the REFR attribute was > available, were not all load modules, even from non-APF authorized > libraries, loaded into write-protected storage?
We have gotten to the point where Mr. Relson and myself are among the remaining old-timers in MVS development in Poughkeepsie, and we have only been here since around 1979. "in the beginning, as soon as the REFR attribute was available" is considerably before that time. My understanding from folklore is that the REFR attribute predates MVS, and its purpose was to designate modules for which a new copy of the module could be safely loaded (refreshing) after a storage related machine check. So if you are asking why the designers at that time did not choose to also use the REFR attribute for write protection purposes, I can only speculate. Since that predated address spaces, the only choice for write protection would be using storage key 0. I don't know whether or not there was any means at that time for providing key 0 storage within a region. But to allow the code to be fetched while executing in the region's key, key 0 storage would have to be non-fetch protected. That would allow the code to be viewed by programs running in other regions, and that may have been considered to be undesirable for security purposes. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
