Rob Scott wrote, in part:
> 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.
Yes, we do handle that, and I think we'd be OK in this case, if I got the
addressing right.
>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.
So now we're REALLY back to where I started. Recall that this all works fine
(FSVO "fine", notwithstanding the caveats about "if the client manages to
vanish at JUST the right time"); at least it's worked so far, in many many
millions of operations done at a lot of customer sites. So I'm by no means
disputing the risk there, just saying that it's relatively low (and we're just
doing a FASTAUTH, so it may be OK--we've copied the input data; I'm
guessing/assuming that when we get back to the PC handler to return to the
caller, we'll find it's not there and be OK, but I'm not sure--must test).
Anyway. When the DB2 issue surfaced (new function), one of my first attempts
was to do a REQUEST=AUTH:
RACROUTE REQUEST=AUTH,APPL=APPLNM,CLASS=CLASSNML, X
USERID=SRQEAUSR, X
DECOUPL=YES,REQSTOR=MODNAME,SUBSYS=0, X
ENTITY=ENTNAME, X
ATTR=READ, X
LOG=ASIS, X
WORKA=WK512, X
RELEASE=2.4, X
MF=(E,RAUTHMFL
This works fine--but it's dog-slow. And I'm not sure why. If I do 10,000
operations with FASTAUTH, it takes ~2 seconds elapsed. If I do it with AUTH, it
takes ~3 MINUTES elapsed. Yet during that 3 minutes, overall CPU is a couple of
percent, and neither the STC nor (of course) the client program shows any
significant CPU usage. Nor does anything else in an SDSF;DA display.
So it appears that it's waiting somewhere on something. I had an off-list
conversation with Walt Farrell, who suggested contention for the ACEE, but
there's nothing else *running* -- on a test system I've IPLed and run it with
nothing else started (well, DB2 and like that, but nothing else related to the
client user) and it's still slow. So unless it's waiting on something that
times out and then continues, I don't see how this can be happening. But what
is it waiting on?? I'd love to use REQUEST=AUTH in all cases--it's simpler --
but not when it takes a couple of orders of magnitude longer.
Any ideas?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
