Jim Mulder said; > It means that if you do a SETLOCK RELEASE for the CPU lock > or a spin lock, or invoke some other function which does a > SETLOCK RELEASE for the CPU lock or a spin lock, that may cause > SETLOCK RELEASE to enable. SETLOCK RELEASE for the CPU lock > or a spin lock will enable if the release results in a state where > the CPU lcok is not held, no spin locks are held, and no super bits > are on, and DISABLED is not specified on SETLOCK RELEASE.
Or in English; if you got disabled by doing a STNSM or LPSW(E) and then you called some system function that obtained and then released a spin lock, the SETLOCK RELEASE logic, believing that lock to be only remaining spin lock, would re-enable for interrupts, even though the calling function had already been disabled on entry. Unless he thinks you're an interrupt handler or some other part of the supervisor, or you use the DISABLED keyword. I have actually seen a dump where exactly this had happened and the result was ugly. Did I mention it was a SAD? PSA overlays... circular FRR chains, ugly ugly ugly! Holding the CPU lock might have avoided that problem, or not, because as an "oh by the way" SETLOCK RELEASE only supports the DISABLED keyword for a subset of the (spin) locks - NOT including (annoyingly) the CPU lock itself. If you are providing code that gets control in all kinds of weird and unpredictable circumstances, the lack of that keyword makes it difficult to always do the right thing. I would still advocate using the CPU lock like the books say, but that alone isn't always going to keep you out of boot hill if you're the callee instead of the caller. CC ---------------------------------------------------------------------- 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
