How to quickly confirm which user exits are used by Endevor.
search cancel

How to quickly confirm which user exits are used by Endevor.

book

Article ID: 30512

calendar_today

Updated On:

Products

Endevor Endevor Natural Integration Endevor - ECLIPSE Plugin Endevor - Enterprise Workbench

Issue/Introduction

You may face a situation where you need to check what user exits are defined in endevor and whether it is using the expected version of each user exit. This might happen, for example, when:

  • Setting up a new instance of endevor
  • Moving an instance of endevor to a new LPAR
  • Testing a new release

How to do that?

Environment

Release:
Component: ENDBAS

Resolution

You can use the endevor exits trace for this purpose.

The quickest and easiest way would be to run an Endevor batch job performing any Endevor action. It doesn't matter which one. Even a job with an empty BSTIPT DD would suffice. You only need Endevor initialization to be performed so that it writes the start of the exit trace

In the JCL, you need to add the following DD statement, which will enable the exit trace.

//EN$TRXIT   DD   SYSOUT=*      this will turn on the exit trace

If you need to take the trace in a foreground run, then the steps would be:

  1. Logoff/logon. Not really needed, but will ensure that the TSO session does not contain any previous trace
  2. TSO ALLOC FI(EN$TRXIT) SYSOUT(X) - This is equivalent to adding EN$TRXIT DD to a JCL
  3. Get into endevor or quickedit. Get out
  4. Use your site procedures (normally using IBM product SDSF) to view the JES2 output from your TSO session.

One way or the other, the exit trace should be present under ddname EN$TRXIT, and it should look like this:

CA Endevor SCM Version 18.1.00        Copyright (C) 1986-2019 Broadcom. All Rights Reserved.      02/03/22  08:25:55
Northeast Region                                      CA Endevor SCM           
                                        C1I0003I USER EXIT PARAMETER TRACE LOG 
                                                                               
08.25.55  EXIT TRACE HAS BEEN INITIALIZED.                                     
08.25.55  USER EXITS TABLE C1UEXITS LOADED FROM STEPLIB                        
08.25.55                                                                       
08.25.55   EXIT#=01 NAME=C1UEXT01 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND
08.25.55   EXIT#=02 NAME=C1UEXT02 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         ADDRESS=0032F000
08.25.55   EXIT#=03 NAME=C1UEXT03 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND
08.25.55   EXIT#=04 NAME=C1UEXT04 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND
08.25.55   EXIT#=05 NAME=C1UEXT05 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND
08.25.55   EXIT#=06 NAME=C1UEXT06 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND                            
08.25.55   EXIT#=07 NAME=C1UEXT07 AUTH=Y CALLAPF=N ALTID=Y LIB=STEPLIB         NOT FOUND                            

In the trace, you need to check the following:

  • Is the name of the exits table (C1UEXITS in this case) the expected one? If not, maybe you are using the wrong C1DEFLTS table which leads to the wrong exits table name.
  • Does the table contain the expected entries with the expected values for AUTH=, ALTID= and CALLAPF=? If not, you are loading a wrong version of the exits table module
  • Does each entry show a load point in the form ADDRESS=xxxxxxxx? If not, endevor initialization could not load the exit module

Additionally, you can take a dump from the batch job, or examine storage in your TSO session, you may use the load point displayed in the trace to browse the user exit(s) in storage and compare them with the load module in the library. This will verify that endevor has loaded the expected version of each exit.