Phil,
I am guessing that this is down to the difference between HASID and SASID in
your two quoted environments.
When your PC-ss code is working OK, HASID and SASID both are the same value
(with PASID being your server address space - ie H=S<>P), however if your PC-ss
can be invoked from an environment where there has already been a PC-ss issued
by another software product, the HASID and SASID could be different (H<>S<>P).
Your client ACEE will be the in HASID storage - so you will have to retrieve it
from there instead of the SASID.
One further point, as you already have a valid cross-memory bind between your
client and your server by the nature of the PC-ss, why are you attempting to
perform an extra ALESERV add for the client address space? Have you tried using
the special ALET value of "2" (for HOME) in the RACROUTE FASTAUTH ACEEALET
parameter?
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: 25 June 2014 14:17
To: [email protected]
Subject: Address space puzzle
I'm hoping someone can see what I'm doing wrong/have misunderstood here. I only
wrote some of the following code, which doesn't help (OK, I wrote most of the
snippet, but not the rest of it).
Here's the scenario: this is running in a stacking, space-switching PC routine.
We're trying to get an STOKEN to the address space containing the caller's
ACEE, so that later we can do an ALESERV ADD and then a RACROUTE
REQUEST=FASTAUTH with ACEE= and ACEEALET=.
For batch and CICS, this works fine (yes, we're finding the other ACEE that
CICS creates for CICS users); we're using the STOKEN passed on the PC, of
course. For DB2 user exits, there's a second (well, third) address space
involved: instead of just ours and the client program's, there's ours, the
client program's, and DB2's.
The first two lines of code work, in that they allow us to correctly address
the ACEE in R2 in code just after the snippet. The LOCASCB and the rest of the
code seems to work, too.
What doesn't work is that later on, in the bowels of the STC, when we're trying
to do the RACROUTE, the ALESERV ADD works--it doesn't return an error--but the
FASTAUTH fails. Running with NOTIFY on the resource shows:
ICH70004I USER( ) GROUP() NAME(???)
...so that makes me conclude that somehow the STOKEN we're getting isn't the
right one. I've looked at the results and in the "good" (batch) case the STOKEN
is 0000006C 00000002 and in the "bad" (DB2) case it's 00000114 00000001. So
those both LOOK like STOKENs, at least.
Am I missing something basic here about how ALESERV works? My impression is
that since we're a key 0, APF-authorized task with EAX authority to all address
spaces, this *should* work. It doesn't, so obviously I have a misunderstanding
or something dumb in the code.
LA R1,2 Secondary space address number
SAR AR2,R1 Make AR2 secondary space
ESAR R4 Get secondary ASID
LOCASCB ASID=(4) Get ASCB for that ASID
LTR R1,R1 Did that work??
BZ ABENDIT No, ABEND
USING ASCB,R1 Address ASCB briefly
L R1,ASCBASSB Get ASSB address
DROP R1 Done with ASCB already
USING ASSB,R1 Address ASSB briefly
CLC ASSBASSB(4),=CL4'ASSB' ASSB eyecatcher there??
BNE ABENDIT No, ABEND
MVC SRQESTKN(8),ASSBSTKN Copy the STOKEN
I will owe someone a beer at SCIDS (I hope!)...
...phsiii
----------------------------------------------------------------------
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
