> > PT uses an ASN. You have no clue <<>> 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. Technically no it isn't. A CML is just the local lock of an address space other than your HASN. The design intent of a CML is to allow a cross memory caller access to resources serialized by the local lock in an address space the caller legitimately has access to. Those would be PASN, SASN and HASN. The architecture assumes that the only way PASN<>HASN or SASN<>HASN is that you got that way via a space switch PC. If you got into cross memory mode via a PC like "God" intended, then both PASN and HASN are properly established and can't go away (or be swapped) in an untimely fashion. Otherwise all bets are off. Yes, you can SSA(I)R or PT(I) to any space you want if you have an AX that lets you do it - hence Binyamin's deep desire for a task level AX. The core of that desire rests on wanting to just reach out and touch another address space without being bothered by cumbersome details like establishment and maintenance of addressability. The hardware will cheerfully let you do it, but the cross memory services software architecture (wisely) doesn't allow it. > 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? They exist for all cases where you access an address space via anything other than the formally defined mechanisms. Hence the documented requirement that a PC service provider must be non-swappable. > 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? Yeah it does. What Binyamin is explicitly asking for is the ability to branch into another address space. There are intractable problems with that idea. The only reason we're talking about the AX is that he has found that he needs to set an AX value (temporarily at least) that will allow PT to the address space he wants to be in. Messing with the AX via CR4 was the crux of his original question. But to address your point, in a purely academic sense it may well make sense to allow a specify task to establish a cross-memory bind to some server space that legitimately provides space switching functions. But wait, oh darn, that is what an EAX is for on a stacking PC. So no I don't believe there is any legitimate usage case for altering the AX of a single task as a general service interface. 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
