Rob Scott again: > You need to capture the cross-memory environment when you get called from DB2 (you can extract the HASN, SASN and PASN from control registers if you desire).
Control registers 7 and 13 are NOT the same. >If DB2 is both HASN and SASN, then your PC-ss code is going to have to change >to perform third-party verification based on userid by building a "dummy" ACEE >with PASSCHK=NO. By "is both HASN and SASN", I take it to mean "HASN <> SASN". Which is true. So maybe I'm back to where I was before I started this odyssey, which is, as you suggest, building an ACEE. I had been discussing that approach with Walt Farrell. I'm currently doing just RACROUTE AUTH in that case, but it's hella slow. Oddly, it's slow *and doesn't use much CPU* -- as in, if I do 10,000 operations (each of which has to do a check), CPU is ticking along at 2%, but it takes several minutes to do the operations. With no I/O. Whereas the same 10,000 operations using FASTAUTH (yeah, I hacked it to always do AUTH so I could get the ACEE right, from a batch job) takes under a second. But both show about the same amount of CPU in both client and STC. Walt had suggested that instead, I could: "Since the user's ACEE already exists, make a copy of it and pass the copy to RACROUTE. You can do that using RACROUTE with an ENVRXTR request, after which you can pass the ENVR object to FASTAUTH." One problem here is that we have to support all of RACF, ACF2, and TSS. And TSS at least is NOT at all happy with a dummy ACEE. So I don't know whether this approach will work, but it sounds like I need to try it! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
