On Wed, 25 Jun 2014 15:59:11 +0000, Rob Scott <[email protected]> wrote:
>> I'm fuzzy on this, but it seems like that *might* not be the case, since it >> was DB2 that called > >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). > >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. Using PASSCHK=NO implies using RACROUTE REQUEST=VERIFY to create an ACEE. However, in a space-switching PC routine you can't use RACROUTE REQUEST=VERIFY. If he needs an ACEE he either needs to point to the original copy, or obtain a copy using methods that will work in cross-memory mode, such as RACROUTE REQUEST=EXTRACT,TYPE=ENVRXTR. However, as Phil pointed out in an email, ENVRXTR in cross-memory mode requires that the ACEE be in Home. And, of course, if the ACEE were in Home he wouldn't need to get a copy, he could just use an ALET of 2 :) Generally DB2 will either have the client ACEE in its own address space, or will have a valid cross-memory environment between itself and its client. Whenever DB2 is calling RACF to perform a security check DB2 will pass the ACEE to FASTAUTH, and thus the ACEE will either bein DB2 (P=H=S) or in the client (P<>H=S). I don't remember what ALET DB2 passes to RACF for the latter case, but it seems likely it would pass the ALET for Home, rather than acquiring another one. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
