I'd like to try to clarify the relationship between endevor alternate ID and program pathing.
The security identity of an MVS address space (Job, started task, TSO session ...) is represented by an ACEE control block (Accessor Control Execution Environment) pointed to by ASXBSENV field in the ASXB block (Address Space eXtension Block) that represents the address space.
A subtask that runs within an address space may inherit the identity of the address space or have its own identity represented by an ACEE pointed to by field TCBSENV in the TCB (Task Control Block) that represents the subtask.The endevor alternate ID mechanism works by temporarily swapping the original ACEE associated with the subtask or the address space to an ACEE that represents the endevor alternate ID. If this is done, for example, before letting MVS process an OPEN request, it results in all effects in the OPEN being performed under the security scope of the alternate ID while in fact endevor is being executed under the security scope of the user.
During processing of the OPEN, MVS asks the security product whether the OPEN has to be allowed. Obviously, the security product decision is based on the identity associated with the task, but it MAY also consider other factors, like for example, any program pathing rules in effect for the combination of the dataset, program and user (in this case, the endevor alternate ID).
In a few words, the alternate ID is totally under control of endevor, who decides when to swap the security scope to that of the alternate ID. However, the use of program pathing rules is totally up to the security product and is not requested by endevor by any means.Regards - Eduard