Message IEC143I RC 213-74 indicates error occurred during OPEN;
RSN 74 is OPEN detected a MEMBER share conflict for the PDSE.
Message IEC143I RC 213-74 indicates error occurred during OPEN; RSN 74 is OPEN detected a MEMBER share conflict for the PDSE
Message IEC143I RC 213-74 is issued for an error that has occurred during OPEN processing for a data set on DASD; RSN 74 indicates that the OPEN has detected a MEMBER share conflict for a partitioned data set extended (PDSE) data set.
The purpose of IEC143I 213-74 is to preserve integrity of a PDSE such that simultaneous updates are not performed to the same PDSE member. This error message indicates that a sharing violation has occurred for a PDSE member.
In a PDSE Extended Sharing Multi-System environment when system A is executing an update-in-place of a PDSE member, access to the PDSE data set itself is denied to other systems who try to OPEN the PDSE data set regardless of the processing intent associated with the OPEN.
The 'PDSE Usage Guide Redbook' Section 8.5.1 'Scenarios for PDSE Extended Sharing Across Systems' states:
|A sharer of a PDSE can read existing members and create new members (or copies of existing members) concurrently with other sharers on the same or other systems. But shared access to a PDSE, when update-in-place of a member is being done, is restricted to a single system. The update-in-place access restriction exists from the time the update program is positioned to the member (for example, by means of FIND or POINT macro) to the time the update program positions the directory or closes the PDSE.|
Table 8.7 titled 'PDSE SYSPLEX Level Sharing' from the same manual supports this statement.
Circumvention by holding a PDSE data set EXCLUSIVE is possible, however; it is not recommended. Specifying DCB=OLD in the JCL allows the data set specified in the DD statement to be held exclusive. As this would circumvent the possibility of receiving IEC143I 213-74, for a given job, this would also effectively 'invalidate' sharing of this PDSE with others, and the benefits PDSE sharing has to offer.
In most processing scenarios, multiple batch jobs and/or multiple TSO users require simultaneous access to a given PDSE, for example:
- The need for shared access to PDSEs that function as program libraries, by batch jobs.
- Multiple TSO users requiring shared access to source code stored as PDSE members ..and so forth.
For UPDATE where...
- A PDSE member IS.... positioned to,
Then that system has exclusive access at the data set level
- A PDSE member is NOT positioned to, by ALL jobs on ALL systems that are accessing a given PDSE,
Then update of that PDSE will succeed
Until APAR OW53098, one could not determine who else (TCB, ASID) on what other system had the PDSE opened. However, APAR OW53098 addresses the issue by providing diagnostic enhancement in the LOGREC entry cut for the ABEND213.
The primary symptom string for the Software Symptom LOGREC entry that is recorded after OW53098 is implemented includes the following data:
SYMPTOM SYMPTOM DATA EXPLANATION
PIDS/5695DF115 5695DF115 COMPONENT IDENTIFIER
RIDS/IGWLGLCN IGWLGLCN ROUTINE IDENTIFIER
PRCS/00000008 00000008 RETURN CODE
PRCS/00003FFF 00003FFF RETURN CODE
The IGWLGLCN RC8 RSN3FFF software symptom record is written on the LPAR that holds the connection that results in the sharing conflict. Therefore it may be necessary to review LOGREC data from all LPARs within the SYSPLEX to identify the holding job and the LPAR.