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
