> 1. Assuming I want to connect only selected address spaces to the service > address space (via > non-system LX): > > a. to execute the ATSET and ETCON macros in the user's > address space (assuming the user runs in problem > state) I will have to create an additional PC routine > to check authorization and issue those macros on behalf of > the user.
No, but the service provider does have to provide a mechanism by which the association can be made and managed. There are many ways, but they typically boil down to; caller makes a request to the server in some preordained manner that is available to a non-privileged caller. Server schedules an SRB to the caller's space, which then schedules an IRB, which (in supervisor state) issues the necessary macros to connect to the PC entry table. > > b. that additional PC routine will have to be based on a > system LX, otherwise I will enter a logical endless loop > c. in other words: I will need to reserve two LX's - one > system, one non-system No. If you needed a system LX there wouldn't be any point in a non-system LX. You would just use system LX's all the time. > My question is: is this worth it? Clearly not as you described it. > Is this the customary way of doing things? No. See above. > Or for economy's sake do people end up using a single system LX > even for connection to selected address spaces (unless > those selected address spaces are in supervisor mode)? Here's the rub. Most people use a single system LX no matter whether the requesters are privileged or not. Bottom line, its so much simpler to set up and manage a system LX and, at the end of the day, it completely solves the problem you're facing, so most people just use a system LX. > 2. When I getmain a global area in common storage to save the cross- > memory info (PC numbers, > (dormant) system LX, etc.), in what key should I getmain it? What are > the "safe" keys that people > are accustomed to using? (I gather from earlier discussions on this list > that key 8 is a no-no.) You can put the information in any system key (0-7) - provided its not fetch protected. > 3. The notion and purpose of an "EAX" (as opposed to a simple "AX") is not > clearly elucidated in either of the above papers > -- both more or less assume one already pretty much knows what it is and > give it short shrift. Can anyone point me to a more precise presentation of the EAX, or, alternatively, briefly explain in > this forum when and for what reason one would opt to reserve an EAX and > specify it in the ETDEF macro? The use of the authority table is described in PoPs. Basically it's a two column table. One column controls SSAR and the other PT/PC. You can't SSAR or PT/PC to a particular space unless your AT has a one in the "row" corresponding to the authorization index. The authorization index (AX) is present in left half of the low order half of control register 4 and it is used during address space translation and authorization. The EAX is associated with space-switching PC entries. The EAX gets loaded along with the new PASN into cr4 by the PC instruction and this potentially gives the PC function access to different address spaces than the caller had access to. It's a spiffy feature, but IMO very rarely used. Since you're trying to do the right thing and use a non-system LX, I would encourage you to continue. But it's a good deal more complex. Most slobs like us just use AX=1 and a system LX and call it a day. 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
