Barbara Nitz wrote:
>>So my current fundamental question is: what identifies an address space
>>besides the ASID?
>The STOKEN is the only thing that uniquely identifies an address space for the
>life of the IPL.
>>That is, I would have thought that ASID X'1234' meant the same address space,
>>whoever referred to it. An address space might be refused access to it, but
>>would always mean the same one no matter who referred to it. Is this
>>incorrect?
>I recently encountered a situation where one tcb in a server had started an
>address space with asid 1234, which immediately terminated with a JCL error.
>Another tcb in the same server had also started an address space in the
>correct timeframe to *also* get asid 1234. This STC actually started up and
>stayed up. Both TCBs later believed to be talking each to its own address
>space, when in essence both TCBs were talking to the same one that had the
>asid sequentially after the first terminated.
>So asid is not a unique criterium to identify an address space, but STOKEN is.
>You get the STOKEN either from the ASCRE invocation or by using LOCASCB to
>translate asid into STOKEN. In the latter case, beware that until LOCASCB
>returns, the asid may already be the wrong one due to the slot in the ASVT
>getting reused by the next request.
I was aware of ASID reuse, but while ASID may not be a unique criterion over
time, for the duration of this exercise, it is. If the client manages to go
away during the operation and the ASID gets reused, we'll detect that when we
go to return the results. In any case, in my testing environment, the client
definitely isn't going away during the operation.
So my supposition/belief is that ESAR followed by using that ASID should get me
"back" to the correct address space.
* In the first module, soon after the PC:
ESAR R1 Get secondary ASID
STH R1,SRQESASN And remember that
MVI SRQERSVA+8,X'37' Set a magic value
STH R1,SRQERSVA+9 Remember the SASN
MVI SRQERSVA+11,X'73' And another magic value
SAC 512 Begin AR-mode execution
LAM R2,R2,=F'2' Home space
USING ACEE,R2
CLC ACEEACEE(4),=CL4'ACEE' Does it look like an ACEE??
BE *+8 Yes, great, continue
EX *-*,* Ouch, ABEND time
ST R2,SRQERSVA+0 Remember the ACEE address
MVC SRQERSVA+4(4),SRQEACEE Remember saved ACEE address
* So:
* 1) We know that the ACEE in R2 looks like an ACEE
* 2) We have saved both it and SRQEACEE in SRQERSVA
---------
* Later on, in the other module:
SAC 512 Begin AR-mode execution
L R4,SRQEACEE Get ACEE address in caller's home space
LH R1,SRQESASN Get caller's SASN
SAR R4,R1 Set that in AR4
LA R3,SRQERSVA Point to our saved stuff
DC X'00'
* In the dump, at 0(R3):
* 007FC6F0 007FC6F0 37004573 (and R1 = 0045 as expected)
* So SRQEACEE is still what we expect (and I've done various checks
* to be sure something ELSE isn't stepping on that storage), and
* SRQESASN is correct (that is, matches what we got from the ESAR
* back in the first module)
*
* BUT R4 is pointing to all zeroes!
*
* Shouldn't the SAC/SAR mean that R4 is now pointing to the ACEE?
Binyamin Dissen wrote:
>Sounds like you are trying to access the storage when you no longer have a
>bind to the client address space. While you "could" ALESERV every single
>client address space, you cannot guarantee safe access from the server side
>(without a lot of work).
How do we "lose" the bind to the client address space? Note that we're only
referencing the ACEE here, not doing anything (in this part of the exercise)
with anything else in the client address space, so I don't think "safe access"
is an issue. Is it?
>You have to explain why you feel the need to cache the security information in
>your server.
Cache? Not sure what you mean. We're asking SAF whether the requestor has
access to a resource. I'm not aware that I'm caching anything, but surely I'm
just not understanding what you mean.
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
