On Wed, May 12, 2010 at 12:28 PM, Rick Fochtman <rfocht...@ync.net> wrote:
> -----------------------------<snip>--------------------------------- > >> Notice that I said "Legal". Nothing else is supported by the z/OS software >> architecture - regardless of whether something else is possible under the >> hardware architecture. Any grinning idiot with an APF library can study >> PoPs >> and contrive ways of gaining addressability to some other address space, >> but >> since z/OS doesn't know (or allow!) what you would be doing, the results >> are >> most kindly described as "unpredictable". >> >> > > --------------------------------------------<unsnip>--------------------------------- > Chris, I don't think the various z/OS routines invoked by PC are scheduling > SRB's just to fetch their parameter lists. I'm sure there are other > mechanisms, perhaps using MVCS/MVCP, that are more efficient than just > scheduling a Global SRB. Perhaps some of our friends at IBM can provide some > enlightenment. > > I notice that in some areas, PC is replacing SVC to invoke a service; about > time!. SVC's are incredibly slow, because of the interrupt processing > overhead, both software and hardware. > > I've even seen systems that use a BAL to a specific low storage address > that ran MUCH faster than equivalent SVC functions. While I agree that > coding technique have MUCH to do with efficiency, in this particular > instance, hardware functions much also play a significant role. Space-switching PC routines don't need to invoke SRBs to access parameter data in their caller's address space because addressability to the primary (PC-server) address space is established by the PC instruction and addressability to SASN and HASN are automatically available. The mechanisms needed to manage that cross-memory environment are formally established and managed by z/OS cross-memory services, so it is all legal. What ISN'T legal is any variation of the common techniques for bypassing formal xmem interfaces and snooping into another address space by doing SSAR or ALESERV ADD,CHECKEAX=NO. (Aside: the fact that the CHECKEAX option is documented does not mean you're supposed to use it. It was intended for internal use and it "escaped".) As I said already, the only legal way to poke around in another address space (without going to cross memory services) is to schedule an SRB into the desired address space. It is true that people have exploited the hardware architecture to avoid doing the right thing, but that isn't supported by z/OS and the results of doing that are (believe it or not) very likely to be dangerous. -- 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
