Why not use FASTAUTH after building the ACEE? You could also contact IBM and see if they have any RACF trace tools to help find your bottleneck with AUTH.
> On 27 Jun 2014, at 17:48, "Phil Smith" <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
