USE_ALTID=P not taking effect for Endevor exits
search cancel

USE_ALTID=P not taking effect for Endevor exits

book

Article ID: 411306

calendar_today

Updated On:

Products

Endevor

Issue/Introduction

An user exit defined in the C1UEXITS table with USE_ALTID=P which calls the Endevor API is expected to have the API actions executed under the security scope of the Endevor alternate ID

Depending on the situation, this might not happen so the API action is executed under the security scope of the user's ID

In the support case that originated this article, the situation was:

  • Site used approver disqualification so that the user casting a package could not approve it
  • An AFTER-CAST exit called the API to approve the package depending on the case
  • The exit was defined with USE_ALTID=P so that the package was approved by the alternate ID
  • This worked fine in batch and foreground
  • Under Web Services, the API APPROVE was run under the user's ID which failed due to approver disqualification

Cause

USE_ALTID=P parameter causes the user exit to be executed under the security scope of the Endevor alternate ID which is propagated to any new TCBs attached by the exit (for example, a new TCB is normally attached when calling the Endevor API)

This is done by manipulating the TCB for the task that runs the exit

  • The security scope is set to the Endevor alternate ID
  • A switch is set to instruct MVS to propagate the security scope to any new TCBs attached by the task

This works fine when the API call done by the exit causes the API to attach a new TCB as, in this case, the new TCB will receive the security scope of the alternate ID

However, if the API TCB was already started when the exit is called (for example, if a previous exit called the API without shutting it down), the security scope will not be changed and the API action will be executed under whatever security scope was in the TCB (normally the user's ID)

Resolution

Ensure that the API is shut down when the exit running with USE_ALTID=P calls it

  • Ensure that previous user exits calling the API shutdown it properly
  • In case of need, the exit may shutdown the API before issuing the call that needs to run under the alternate ID

NOTE: There is no problem if the exit tries to shut down the API while it is not up. The API front-end (which runs in the same task as the caller) will simply return to the caller with RC 0 when it finds that there is no API task around to shutdown.