On Thu, 26 Jan 2006 11:19:30 -0600 "Craddock, Chris" <[EMAIL PROTECTED]> wrote:
:>Walt Farrell and I agree that this sounds like a bad idea. :>> >> There is a need, as the AX (via AXSET) is a global address space :>> >> value. There is no way (that I can find) to "legally" change the :>> >> AX for a single unit of work. :>There is a good reason for that. The AX is irrelevant unless you are :>trying to set up primary or secondary addressability to another address :>space. Which is what I want to do. :>There are mechanisms for doing that which do not violate integrity. Define what you mean by "integrity". I see integrity as preventing a problem state routine from doing something malicious or outside it's box, and preventing a supervisor state routine from accidentally doing something unexpected. I don't think that supervisor state should allow access outside its storage key, but on the other hand the supervisor state routine can set its key to what it wants. Same with low storage. I agree that there is a need to provide a means so that a supervisor state routine does not unknowingly PT somewhere where integrity might be violated, but I do see the need for the supervisor state routine to say even though this PT appears to violate integrity - it does not - so let me do it anyway. :>Doing it yourself, while probably appealing in an "I made it myself" :>kind of way, violates design integrity even if you go to great lengths :>to be careful. That is not the appeal. :>> I would like a particular unit of work in an address space to un with :>an :>> AX of one. That way I can PT rather than schedule an SRB. :>PT/PTI is the WRONG way to get primary addressability to another space. That is an opinion. I hope you can accept that reasonable people can disagree. :>You have only two legal choices. Your can set up space-switch PC :>services in the target address space and use a PC to get there, or you :>can schedule an SRB. Yes, I am aware of the legal choices. The first one involves screwing around with the client address space so that it might have bad effects, and the second is out of line. :>Anything else is going to fail. The bad news is that your PT approach :>may well appear to work most of the time. Unfortunately you're going to :>astonish the OS' cross memory management code from time to time and :>unless you're especially careful you can end up with a supervisor state :>PSW pointing to the ozone. I tend to write supervisor state code carefully. It would take real bad planning to end up with "a supervisor state PSW pointing to the ozone". :>> Using AXSET will affect all units of work with that current primary. :>Yeah. It is designed that way. Yes, I am quite aware. Going back to your integrity issue above. The supervisor state routine has the ability to change it's AX to one (via AXSET) and thus would have the ability to do the PT. Unfortunately, using AXSET will open an exposure by allowing other units of work using that primary the same access. A unit-of-work qualified AXSET would remove that exposure. :>> >> As far as integrity - this is a supervisor state routine and thus :>all :>> bets are off. :>The opposite is true. Supervisor state programs have a responsibility to :>ensure that they do NOT violate integrity, or allow their non-privileged :>callers to violate integrity. And they should be making the decision whether a particular act is an exposure. To some routines, updating a memory block outside the non-privileged callers authority may be an exposure while to others it is not. The supervisor state routine should be able to make the call. :>> My point exactly, which is that there is no reason to block a :>supervisor :>> state routine from issuing a PT even when not authorized via the AX :>since :>> it can manipulate the environment to allow it anyway. There should be :>a :>> version of PT which skips that check. Or a way to set the AX :>> for a particular work unit. :>I think you're missing the point. A problem state program can issue PT :>now. I thought that it always could (I wrote DAS routines back when SP3 meant SP1.3). The problem state routine could not do PCLINK. The restriction on PT in problem mode is that it cannot cause a switch to supervisor state. :> The AX is what authorizes the transfer. The integrity issue arises :>because address spaces can come and go. If you assume that an :>O(infinite) number of other instructions can be executed in between any :>two of your instructions, then you begin to see that the universe can :>change while you're watching and you can find yourself somewhere :>completely different than you expected. Same issue with SRB's. One plans code carefully. :>If you use the officially supported mechanisms, then the OS makes sure :>you don't end up in the ozone. What's so hard about following the rules? As above. Think outside the box. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
