Originally when I saw that STOKEN could be used on both SCHEDULE and IEAMSCHD to ensure that the address space you are shooting the SRB into was indeed the one that was intended, I thought "great - that's really handy".
And it is - as long as the SRB is officially invited into the address space. If you are an uninvited "snooper" there is a bit of a catch-22 situation in getting hold of the STOKEN for a foreign ASID as the IBM recommended way of getting the STOKEN is to perform ALESERV EXTRACTH - and if you are *uninvited* that means running an SRB (or the like) in the foreign ASID to get the STOKEN.... Of course, the STOKEN is dangling right in front of your eyes in the ASSB in E-SQA - but it is only supported by IBM for the *MASTER* address space - but it is very tempting fruit. Of course, address spaces that hand out invitations to snoopers can EXTRACTH their own STOKEN and store it somewhere that the snoopers can see it and Bob's yer uncle. I have often wondered why ASSBSTKN is not GUPI as the values are guaranteed to be unique between IPLs. I remember asking IBM many years ago and was told that "it just wasn't, OK". Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi_g2 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: 25 January 2007 12:28 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Cross Memory and AR ASC Mode > For a space-switching PC routine (PC-ss), I am aware of the requirement > for the service providers' address space to be non-swappable. However, > when in AR ASC mode and accessing data via an AR, is there any requirement > for the target address space to be non-swappable? I have looked through > the z/OS Extended Addressability Guide but I can't see any (obvious) > reference to this. The issue surrounding swapability is that the PC functions themselves obviously have to be in memory, or at a minimum, fetchable via a page fault when the PC instruction is issued. If the address space containing the code is swapped out, then there's no hope. Of course, if the code is in common "no harm no foul". In any case, the rule for PC providers is to be non swappable, so just don't fight it. Now if you are talking about peering into some other address space in AR mode, then of course that address space has to be "in" or translation isn't going to work. It may appear to work for some areas some of the time, but in general it won't and page-fault resolution will fail. The technique of using SSA(I)R to some random address space and snooping around is relatively common, but not actually legal from z/OS' point of view. At a minimum you would have to hold the LOCAL lock of the target as a CML, but the catch-22 is you can't legally obtain that CML without a legal cross-memory bind. Even though the code may appear to work some of the time. The officially supported approach is to schedule an SRB into the target address space (hopefully using an STOKEN to guarantee you're in the right one) and be prepared to deal with the S075? abend from the schedule macro if the address space is gone, or in the process of going away. Once dispatched, your SRB can communicate with your originating address space any way you choose. Most people who do this sort of thing choose to pass data via a dataspace, or via common storage of some sort - perhaps 64-bit shared. However ALL of that deals heavily with asynchronous units of work and in practice either side can go away at any time. If you want to minimize the chances of problems you would have your SRB space-switch back to the originating address space and move data (or whatever nefarious thing you were doing) in access register mode, referring to the "target" address space via ALET=1. Under those circumstances the SRB acts as a bridge between the address spaces and normal system housekeeping (and your own recovery and RMTR routines) deals effectively with all of the addressability and cleanup issues. But (surprise!) that's a TON of work to get right in any sort of consistent fashion, so if you don't have an infrastructure that handles it for you, you're probably never going to go to that trouble yourself. Which is why many products just ignore the niceties and fly close to the deck and occasionally find the deck is closer than they thought. "Oh well". (Can you tell I just love this stuff?) 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 ---------------------------------------------------------------------- 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
