Steve, Peter is (of course) right. You're struggling with cases where most people generally miss the distinction between the hardware architecture and the software architecture implemented by any given "control program". The hardware knows nothing at all about what you would think of as "authorization" from a z/OS point of view, or any of the internal mechanisms that z/OS uses to make those semi-privileged instructions do something useful.
The hardware architecture has three states that control whether or not an instruction can be executed; non-privileged, semi-privileged and privileged. You can assume for all practical purposes that as far as the hardware is concerned, supervisor state and "privileged" mean the same thing and that you can execute any machine instruction you want any time you want. Whether or not it does something sensible or desirable is irrelevant at this point. In the problem state you can execute any non-privileged machine instruction any time you want *AND* any semi-privileged instruction "the control program" (in this case z/OS) has enabled. As Peter mentioned earlier, z/OS always allows problem state programs to issue semi-privileged instructions. Additional *SOFTWARE* architectural conditions may have to be satisfied in order for the instruction to complete, or to do something useful. Some of those are done all the time (for all units of work) and others need to go through some software mediation first. For example; From the software point of view the linkage stack is just always there. Under the covers z/OS is manipulating the stack to balance its storage resource utilization, so if you were to look at the stack in a dump it would not necessarily look the way you might expect from reading PoPs. For the most part, the instructions just appear to work and they are useful, or not, depending on what you're trying to accomplish. Other semiprivileged instructions can have more of an "in your face" nature. For example, SPKA can be issued in problem state any time, but will give a privileged operation exception if there isn't a 1 bit in the PKM for the target key. The PKM (a hardware construct) is setup by z/OS when the unit of work is dispatched but the mechanisms z/OS uses to decide which keys are available at any given time are part of the software architecture. In other cases a given hardware feature might be made available to software in a different way than implied in PoPs, or perhaps not made available to software at all. The often cited example is that the TRAP instructions are not supported by z/OS at all. So in theory, you could write a supervisor state program that would set up the required linkage mechanisms for the TRAP instructions to work, but various z/OS internal components would likely be surprised and disappointed. And that's never a good thing. On Fri, Dec 30, 2011 at 8:01 AM, Steve Comstock <st...@trainersfriend.com>wrote: > On 12/30/2011 5:52 AM, Peter Relson wrote: > >> I have noted a couple of omissions in the PoPs that I will submit >>> a Readers Comment for >>> >> <snip> > > > The wording in the PoOp tends to be extremely precise (not 100% correct, >> but pretty darn close). I caution against assuming that terms mean what >> they do not say they mean. >> > > I understand, and I believe you. But, there are times (perhaps when > separate chapters are written or updated by different people) when > the consistency is not what I, personally, would like. > > Consider > > the Preface description of Chapter 10 says that chapter: > > "contains detailed descriptions of all of the semiprivileged > and privileged instructions except for the I/O instructions." > that's just a long winded way of saying "the I/O instructions aren't described here". > Chapter 3 mentions a "semiprivileged program" - what is that? > (Chapter 5 also uses this term without > defining it) > A literal interpretation of a "semiprivileged program" is one in which the control program has established the conditions necessary for the program to issue those instructions. > Chapter 4 says "Another group of instructions, called semiprivileged > instructions, are executed by a CPU in the problem > state only if specific authority tests are met; > otherwise, a privileged-operation exception or a > special-operation exception is recognized." > Yep. Should all be clear now right? With one or two exceptions, it isn't terribly interesting (at least in z/OS) to be drawing distinctions between non-privileged and semi-privileged. The only meaningful distinction is that you need some assistance from the control program in order to be able to use (some of) the semi-privileged instructions. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
