Having seen many of these sort of problems before, as far back as 1980, long before ALLOWUSERKEYCSA, or even DIAGxx was invented, I was curious as to whether it would be easy to correct it.
I went to www.cbttape.org and took a peek at LOOK. (I could only find it by taking a guess at the file name there, I'm not sure if that is how that site is supposed to work.) The offending GETMAIN is coded as GETMAIN R,LV=(0), where 241 has been put in the high byte of R0 to indicate subpool 241. This format of GETMAIN will default to allocating the storage in the key that the calling program is running in at the time the GETMAIN is issued. The GETMAIN is preceded by a MODESET to supervisor state, but that MODESET does not change the key it is executing in. In absence of a PPT (SCHEDxx) entry for LOOK specifying some other key (and the right circumstances for that entry to take effect), it will be executing in key 8, and hence the CSA ends up in key 8. Quite likely the original author did not even realize that this was happening. The code then goes on to put various things into the CSA, including code for an SRB routine which may be used later to access storage in another address space. That is a really bad thing to do, because it results in the SRB (code that runs in supervisor state, key 0) residing in storage that can be updated by all and sundry. That is exactly the kind of thing that the change to the ALLOWUSERKEYCSA default is trying to highlight and prevent. Could the LOOK code be fixed? Of course. Anything is possible. Some of the LOOK code, including the SRB routine, already executes in key 0, and the code could be changed so that more of it runs in key 0, by simply adding KEY=ZERO to the MODESET prior to the CSA GETMAIN, (and avoiding changing back to key 8 later in the code). The CSA would then be in key 0, unable to be altered by unauthorised code, and there would be no problem with ALLOWUSERKEYCSA. The downside to that solution is that the more of the code that runs in key 0, the greater the chance that some bug could cause the overlay of something important. To minimise the possibility of something vital getting clobbered, it would be better if the CSA could be allocated in a non-zero, seldom used, system key. Doing that can be a bit more tricky than you might think though. Those who use it will have to decide if it is worth fixing. ---------------------------------------------------------------------- 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
