On Wed, 21 Nov 2007 09:41:06 EST, IBM Mainframe Discussion List <[EMAIL PROTECTED]> wrote:
>There must be more to it than that. ...snipped... >Another clue is that in the PSA DSECT the comment on the PSASYMSK byte > says "This field will be used in conjunction with the STNSM instruction to >place IOS channel scheduler into a disabled state ..." If you scan this >whole DSECT for "STNSM" you will find several such fields that are used to hold >the system mask upon doing a STNSM and even more STOSM instructions > whose operands are the PSA bytes where various STNSMs saved the mask. > >Translation: IBM's use of the STNSM to disable interrupts explicitly within >the nucleus is rife, so why do they externally document that it should not >be done? Perhaps our usage is appropriately coordinated (e.g., you've pointed out those areas that -we- use for STNSM and STOSM), with results being saved and restored properly, and with due consideration given to what else might be going on at the same time. But we doubt that other programmers will know enough about what else is going on to use it safely, so we document that you should not do so. Much like the other system control instructions that exist in the architecture but that z/OS "reserves" for its own usage, that I've seen discussed here before. >From a later message of yours: > Of course the nucleus is designed not to page-fault while disabled. One way > that is guaranteed is by being sure that every byte ever touched by disabled > code is fixed before doing the disabling operation. Which is what I have > done in all the code I have written that explicitly disables via STNSM. And I > have learned that if I want to do a GETMAIN for a system subpool while > disabled and without holding a system lock, that I need to turn on a super bit > to tell GETMAIN that the CPU is "officially" disabled. And when I get a disabled > page fault ABEND dump, I know what to do to fix my bug. STARTIO, I'm sure, > has an FRR that knows what to do if it fails after it gets the UCB lock and > something is "in the middle". > > I still do not understand the necessity for the warning about MVS-guaranteed > disablement's requiring a system lock's being held. One result of acquiring > a system lock is the turning on of a super bit. But you can also turn it on > with an OI instruction. I have no doubt that you -can- turn on a super bit, but I doubt that it's an intended way of doing things, and if you do it wrong or are unlucky you may bring down the system, and system outages are seldom appreciated by our customers. Also, as you note, getting a super bit is -one- result of getting a system lock. I don't think it's the only result, though. Looking at everything you said you needed to figure out (page fixing, setting super bits, ...) I think it's fairly clear why IBM documents some of what you (generic you, not you specifically) shouldn't mess around with. -- Walt ---------------------------------------------------------------------- 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
