Endevor concurrent processing job abends with a s213

Products

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

Issue/Introduction

Running CAP (Concurrent Action Processing) and sporatically getting a S213-74.  If the job abends it is usually just resubmitted and it will run to completion.  There are times when the restart does not work.  

Recently followed the instruction in the article on How to avoid and S213-74 whehn using a PDS/e in a processor but CAP is stil abending.  Is there anything that can be done to resolve this problem. 

 

Resolution

The CAP task should be running on one LPAR not on multiple LPARS.  

The following is the analysis that was done by Support:

• XCF structures found in the dump as well as the S213-74 abend itself suggested that the use of extended PDS/E between two systems  SYSAA and SYSBB is being done.
• As per the output provided, the processors involved contain a single CONWRITE step that copies  the element into a common library with FOOTPRNT=CREATE.  That library raises the S213-74 after CONWRITE has completed (that is, while we are creating the footrpint).
• the outputs provided shows that the process is sometimes executed in SYSAA and sometimes in SYSBB

Altogether this is problematic because:

    -  We need to open (connect to) the member in update mode in order to replace it's directory entry when
       footprinting the member.  That's what the IBM documentation calls - update in-place.

    -  PDS/E extended sharing at member level is good when several processes are creating members.  It is very
       restrictive for update in-place.  The IBM documentation seems to suggest that when update in-place is done
       from one system, opens from the other systems in the plex will get the S213-74.

    -  Due to a simple processor running, we are updating in-place may members per second which increases the chances
       of the abend.

Remember, when PDS/e EXTENDED SHARING encounters a second open request for the same dataset with DISP=SHR, and the first request is an update-in-place, instead of putting the 2nd request in a wait state, it will issue a S213-74 to abend the second OPEN.

By coding a DISP=OLD on all PDS/e datasets in the processor, we will allocate the files with a DISP=SHR and issue and issue exclusive enqueues for EACH request. So using DISP=OLD in a processor for proper enqueue handling will ensure that Endevor updates to the PDS/E datasets are serialized, thus avoiding S213-74 errors.

If after coding DISP=OLD and still encounter problems, contact your Broadcom Endevor Support for assistance.