I think the type of use talked about here is very reasonable at the hardware architecture level. z/os is limited for historical reasons. - paul hanrahan
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe Sent: Sunday, January 29, 2006 2:14 PM To: [email protected] Subject: Re: What happens if CR's are directly changed? Craddock, Chris wrote: [snip] > Consider this. If you are running in an SRB, then the mere fact your > SRB is dispatched means you are in the right address space and - > assuming you wisely used the STOKEN parm to get there - the address > space you were interested in has not gone away and another with the > same ASID appeared in its place in the mean time. > > If you use STOKEN and the address space is no longer valid, the > schedule will fail. If the address space terminates before the SRB is > scheduled, the SRB will be purged by the system. If the address space > terminates after the SRB is dispatched, the system will purge it. No > muss no fuss. You have mechanisms available for dealing with address > spaces via software tokens rather than address space numbers. > > ASN/ASID numbers are reused, STOKENs aren't. > > PT uses an ASN. You have no clue and the hardware has no way of > knowing, in between the time you developed the ASID you are interested > in and the time when you issue the PT, whether that address space is > still valid, or even whether it is in memory. > Isn't that why "God" invented the CML lock? You must SSAR/SSAIR to the space for which you want to obtain that lock and the space needs to be non-swappable. Once the CML lock is held, the address space won't disappear and you can access it any way you want. > If it is in memory things will appear to work ok, as long as you don't > take any page faults. You will be able to access private storage pages > that are in memory. If the address space is swapped it is > unpredictable whether you will be able to access anything at all. You > can probably get LSQA pages provided it's not a physical swap. > Anything else is a crap shoot. > > Trust me on this. If the address space you've branched into isn't > designated as valid for cross memory access and the system catches you > at it, you're going to be abended. And on systems with ASN reuse > active, if the target of your PT is a reusable ASID, your PT will > simply fail. > > You're a smart dude. Figure it out. > I must be missing something. Why do you assume the "other" address space he wants to access is not non-swappable? I re-read this entire thread and Binyamin _never_ said he wanted to access a swappable address space (though that might be the case). As I see it, this digression is at best tangential to the core discussion at hand. The cross-memory access considerations you've detailed are true and exist today even when AX=1 for the entire address space. Right? Getting back to basics: What Binyamin has asked for is the ability to have the AX for one TCB/RB in an address space be different than the AX of another TCB/RB in the same address space. On the surface, that seems like a reasonable "wish list" item to me. We've established that this function doesn't exist given the current cross-memory architecture, developed decades ago -- even before XA/370, but that doesn't invalidate the merits of the idea. Does it? -- .-----------------------------------------------------------------. | Edward E. Jaffe | | | Mgr, Research & Development | [EMAIL PROTECTED] | | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801 | | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | '-----------------------------------------------------------------' ---------------------------------------------------------------------- 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
