>I think I mentioned that I believe in "least privilege." I don't want to run >an entire LE/C++ started task in supervisor state.
When "belief" gets into the way of "function", it could be time to re-examine. Perhaps you should look for a way that does not require you to be doing key 0 stuff (or conversely does not require you to intermix changing between key 0 and key 8 while in problem state) The prevailing opinion is that avoiding running in key 0 when you can is a good thing. But there is very little concern about running in supervisor state when you don't need to (if it makes life easier) If you want efficiency for your case, then you must use supervisor state. >After it showed up on a customer's STROBE report, we switched over to >using LPSW instead... If you're unlucky enough to hit the edge case, you will lose the PER bit by doing so. There might be other things that could similarly be lost. System services are provided for a reason. You bypass them at the customer's risk. >Principle of astonishment The only thing at all surprising should be, as Charles found, that he could not switch back to his "original key". But to accomplish that in general would require the system to keep a chain of keys so that you could backtrack step by step. We would never do that when the user has a simple alternative -- supervisor state. "Least privilege" is a nice guideline, but it's not a rule, particularly when you care about performance. If you're interested enough to run in key 0, running in supervisor state is a small step, not even a leap. What would have been surprising would be if you switched to key 0 problem state and then could not switch between there and key 9 and back since you are always supposed to be able to switch to and from key 9. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
