The CAP 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 processrs 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).
Also, 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.
Coding DISP=OLD in the processor DD (together with correct GRS setting for CTLIPROC major name) as
suggested in TEC481968 will also clear the abends (unless any non-Endevor process is updating the library)
as Endevor will single-thread updating the library.