> 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 a ppears 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.
When you do 10,000 operations with REQUEST=ALL in 3 minutes, does each operation take around the same time as the others? Or are some fast, and some really slow? How fast and how slow are they? 10,000 requests in 3 minutes would be an average of 18 milliseconds per request. If each request results in several I/O operations to the RACF database, that could add up to 18 milliseconds. I don't know enough RACF to know how many (if any) I/O operations would be typical for your REQUEST=AUTH. If I was trying to understand why a REQUEST=AUTH was taking longer than the amount CPU time consumed, the first thing I would do is set a SLIP IF,A=SYNCSVCD on the instruction following the return from REQUEST=AUTH, and look at SYSTRACE to see which events cause the issuing workunit to get undispatched. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
