How to find programs that call the Endevor API

Products

• Endevor

Issue/Introduction

In some situations, the need may arise to determine what programs in the installation call the Endevor API. For example:

• The holddata for a fix being applied instructs to recompile programs calling the API
• Recompiling the API programs during an Endevor release upgrade

If there is no internal documentation onsite specifying what these programs are, they must be found in some other way.

How to do that?

Resolution

There are different possible approaches to obtain this information

1 - Exploring the source programs

Each and every call to the Endevor API passes the 'API control structure' block (AACTL) as the first parameter. This block is mapped by copybooks ECHAACTL (for COBOL programs) and ENHAACTL (for assembler programs). Therefore, scanning the source programs for the respective copybook name will identify programs that may invoke the Endevor API

If the programs are managed by Endevor, there are some tools available to assist with this task:

• The batch Search and Replace Utility
• The new Text Search enhancement introduced at release 19.0 allows to perform text searches from the Quickedit element lists, as well as it introduces text search functionality to the Endevor API, the CSV utility and the REST API

For programs not managed by Endevor, it is possible to use the ISPF SRCHFOR utility , either in the member list of a particular library or in a data set list display.

Notes:

• Programs calling the Endevor API need to include the copybook. However, there might be programs that include the copybook but don't call the API
• If the programs have been generated by Endevor, the ACM (Automated Configuration Manger) option is active and SYSLIB DD in the compilation step specified MONITOR=COMPONENTS, Endevor captured the names of the copybooks in the component list during compilation. In this case, the component lists may be searched to locate candidate programs
• If the definition of the Endevor type specifies DELTA FORMAT=R and  COMPRESS/ENCRYPT=N, The ISPF search functions may be used on the base library for the type, as it contains the unencrypted and current version of each element. The same consideration applies to Endevor source output libraries

2 - Exploring the load modules

Programs invoke the Endevor API by calling the stub program ENA$NDVR. The call may be static (with the stub linked within the program load module) or dynamic (with the stub loaded at run time.

In both cases, the string ENA$NDVR will be present within the load module. It may be either:

• The coremark of ENA$NDVR stub which is linked within the load module
• The name of the module that will be called at runtime

Therefore, it is possible to use the ISPF search functions looking for string ENA$NDVR in the load libraries to identify load modules that may potentially call the endevor API.

If the load modules have been generated by Endevor and contain endevor footprints, they lead to the elements which originated the load modules. The View Footprint Information function of the Endevor dialog and the CONRPT80 Report (Library Member Footprint Report Details) may be used for this task

For load modules that have the ENA$NDVR stub linked within, the CAMODID utility may be used to identify load modules containing this stub. This utility is normally used to report the fix level of product modules and will react to the ENA$NDVR stub found within the load module. The command would be:

CAMODID DETAIL DSN(load.library.name)