Execution environment for an Endevor processor step

Products

• Endevor

Issue/Introduction

Endevor actions may execute Endevor processors which in turn may execute whatever program.

Even though an Endevor processor is written using the same syntax as MVS JCL, a program executed by an Endevor processor runs in a slightly different environment than a program executed by JCL.

This article explains the differences.

Cause

 

Resolution

Task environment

A program being executed by an Endevor processor runs as a subtask within the job step that is running the Endevor action. This is different from a program executed by JCL which runs in the so called 'job step TCB'. It's uncommon, but depending on the program logic, this might affect the program.

Technically speaking, the job step TCB is pointed to by field TCBJSTCB in the current TCB, so that:

• A program executed from JCL runs in a TCB with field TCBJSTCB pointing to itself
• A program executed by a processor runs in a TCB with field TCBJSTCB pointing to the TCB that runs the Endevor batch program (normally NDVRC1) or, when running in foreground, the TSO terminal monitor program (normally IKJEFT01)

Storage

The program will have less storage available when running in an Endevor processor. this is because it is running in an address space where Endevor is already running and has already built all its control blocks.

Therefore, if the program is very demanding in terms of storage, it could experience 'out of storage' errors or abends (like S878 or S80A) which could not arise when the program is executed via JCL. That would happen simply before there is more storage available when the program runs under JCL.

Storage and resource cleanup

When a program runs under JCL, the termination of the program implies the termination of the JCL step, which causes MVS to automatically clean up resources used by the job step. For example:

• Release of storage left acquired in some subpools
• Automatic close of files left open
• Automatic free of datasets dynamically allocated by the program
• Automatic release of enqueued resources

This cleanup does NOT take place at the end of an Endevor processor step since it does not cause the termination of any MVS job step. If the program being executed does not clean up its resources itself before termination, this may cause subsequent problems.

For example, if the program acquires storage in a subpool that is automatically freed by the system at the end of the job step and neglects to free it at termination hoping that MVS will free it, the storage will remain acquired until the end of the Endevor jobstep. If multiple actions are run during the job step which cause the program to run multiple times, Endevor will sooner or later run out of storage after many actions are executed.

SVC intercepts

Endevor establishes a mechanism known as 'SVC screening' for the TCB where the processor program runs, by setting flag TCBSVCS and pointer TCBSVCA2 in the TCB. This allows Endevor to gain control when the program issues certain SVC calls in order to insert its own preprocessing and post-processing to the logic of the SVC.

Using this technique, Endevor may, for example, temporarily swap the security environment to that of the Endevor alternate ID during OPEN processing, or take note of the members read and written by the program in order to collect component list information

The screened SVCs are:

•  SVC 18 - x'12' - FIND/BLDL (Locate a PDS member)
• SVC 19 - x'13' -  OPEN
• SVC 20 - x'14' - CLOSE
• SVC 21 - x'15' - STOW  (update PDS directory)
• SVC 22 - x'16' - OPEN TYPE J
• SVC 23 - x'17' - CLOSE TYPE T

APF authorization

The processor program runs without APF authorization (even though it loads from an APF library and is linked with AC(1). If a processor program needs to be attached with APF authorization, its name needs to be added to the customizable Endevor authorized programs table (C1GTAPGM)