>> ...can lead to confusion as eye-catcher validation can be correct with you >> looking at the correct one
Should be "...can lead to confusion as eye-catcher validation can be correct with you looking at the incorrect one" Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: 27 June 2014 09:36 To: [email protected] Subject: Re: Address space puzzle Phil First of all, the following PC-ss code : L R5,ASCBASXB ascb extension USING ASXB,R5 MVC SRQEACEE,ASXBSENV addr of ACEE in secondary space Will *NOT* work as you expect if AR5 is not primed with the correct ALET for the SASN (regardless of the fact you really need the HASN anyway). If AR5 is zero, you will get the address if the ACEE from the ASXB of the PRIMARY address space - ie your server. If AR5 is one - you would get the ACEE of the SASN and if AR5 is two then the HASN. Due to the similar memory structure and boundaries when the address spaces were built, it is very possible that the ASXB and ACEE addresses are the same value and this can lead to confusion as eye-catcher validation can be correct with you looking at the correct one. Overall, I think your design here is fatally flawed. (1) Throwing a request onto another async server task from the PC-ss means that that task cannot use special ALET values 1 and 2 as it is not running with the same cross-memory bind (most likely the task is running where H=P=S) (2) Catering for above by ALESERV ADDing the client caller address space to your server access list is a *really* bad idea because : (i) Access lists have a finite number of entries (ii) Accessing private storage in an ALESERV ADDed address space requires it to be non-swappable (iii) Any error in your server task could leave the ALESERV DELETE portion of your code to be bypassed and then sometime later you will exhaust the server access list (iv) ALESERV ADDing random address spaces to another address space (most likely using CHKEAX=NO) is not really supported (v) As far as I can tell, there is no mention of any method for your server to be notified if an address space has terminated whilst a request for it is still in your queue. So, how do you go about fixing this situation? I think you have the following choices (there may be more) : (A1) Perform the security checking in the PC-ss routine using ALET value of 2 as described in previous posts. (A2) Convert the code to TWO PC routines, an initial PC-cp routine that does the RACROUTE and then it will issue the PC-ss if successful to communicate with your server (PC-cp = "Current Primary" - ie no space switching occurs). (A3) Change the existing PC-ss to extract the callers's userid from the *HOME* ACEE and populate the server request block with that data. When your async request handler get control (in H=P=S), it can build the ACEE and perform the RACROUTE check in a "normal" way. I recommend (A3) based on your posts so far. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Phil Smith Sent: 27 June 2014 00:18 To: [email protected] Subject: Re: Address space puzzle Walt Farrell wrote: >I don't think you've proven that SRQEACEE is still what you expect. You've >shown us SRQERSVA, where you saved a copy of SRQEACEE, and a copy of the ACEE >address. And SRQERSVA is apparently still good. But you haven't actually shown >us SRQEACEE (unless it is defined as being at SRQERSVA, which seems unlikely), >and when you loaded SRQEACEE you got 0 (as shown by what's in R4). >So it seems like something _has_ stepped on SRQEACEE. I meant that R4 was *pointing* at zeroes. The contents of R4 == SRQEACEE. >(It is also not clear where you got the ACEE address from in the first >place; that is also important, and often done incorrectly in >cross-memory code, and it would be good to see that code.) Good question. I'm convinced because I've verified that the ACEE eyecatcher is visible back in the PC handler when I can "see" the HASN, and here's the code that gets the ACEE, also from that module: L R4,PSAAOLD callers ascb USING ASCB,R4 short term addressability L R5,ASCBASXB ascb extension USING ASXB,R5 MVC SRQEACEE,ASXBSENV addr of ACEE in secondary space ICM R1,15,TCBSENV ACEE this task BZ *+8 usually there ST R1,SRQEACEE retain ESM preference >(And, as another list member pointed out, an ASN is not the same as an >ALET, so your usage of SRQESASN seems suspect.) Yeah, that part is clearly wrong; see below, where I reply to Rob. Rob Scott wrote: >Your code has : >LH R1,SRQESASN Get caller's SASN >SAR R4,R1 Set that in AR4 >Access registers should contain ALET values - not a hex ASID value. >"ESAR" returns the ASID value (copied from CR3) - it does NOT contain the ALET >value for the SASN. That's clearly part of my confusion. Makes sense; seemed too simple. So I'm sort of going in circles here: I need an ALET, ok...so I can find the STOKEN from the ASSB and use ALESERV to get the ALET? That's where I started. Is ASID ==> STOKEN (via LOCASID/ASSBSTKN) ==> ALESERV expected to always work, modulo permissions (not an issue here, we have EAX authority to all address spaces)? That's what I thought I was doing. >You also state that "another module" tries to reference data in the SASN - how >and where is that module called and what is the cross-memory environment when >it executes? It's a lower-level module in the same STC. There's the code that handles the PC (on the "STC side" of the PC), which creates and queues the request. Later on, the request block gets pulled off the stack and the RACROUTE is done then. So by then, we're long past having the same HASN (I finally understand!). I do feel like I'm making (very slow!) progress, thanks to all the helpful folks here. I think tomorrow I will try to back up and sort of start over from the "OK, it works fine for batch" point. Now that I understand a bit more about what I'm doing, hopefully I'll get past my mistakes. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
