You don't need to concern yourself with *how* the user is (or is not) given access to the resource. You don't need to concern yourself with which RACF profile protects the resource either. You just pass the necessary information about the user, the access level being requested and the resource name to the RACROUTE call and RACF determines the answer for you. This answer might be because the user is permitted directly on the access list of the profile covering the resource, or one (or more) of the groups they are a member of is on the access list, or the resource might grant access via the Universal Access attribute, or the user might have some other ability such as Operations, or even a RACF exit might get into the equation and contribute to the answer your RACROUTE call gets back. It's all 'under the covers'. In general, it's a bad idea to try and second guess RACF by assuming that some named Group or other structure is used specifically to make access decisions - poor design choice (made all too often by folks who don't really understand RACF).
One important difference you might need to be aware of is between a normal RACROUTE call that executes under the authority of the current user associated with the running address space (a First Party call - i.e. checking your own current access rights), and the special case known as Third Party RACROUTE call where you also give the userid on the call and it's not necessarily the same userid as you are executing under at the time. For this, you need first to create a new RACF ACEE and pass this to the RACROUTE call - IIRC this *requires* you to have APF Authorisation (actually, Supervisor State, however you get that, but most commonly this means you are APF'd), IOW you won't be doing this from a normal user address space. HTH - Cheers - Mike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
