How to prevent S213-30 abends with DBRMLIB allocated as a shared (DISP=SHR) PDS within an Endevor processor.
Article ID: 26316
Updated On:
Products
Issue/Introduction
The DBRMLIB which contains DBRM's written by the DSNHPC DB2 precompiler, can exhibit S213-30 abends during
high concurrency, when implemented as a shared PDS library.
Cause
The current release of DB2 Installation and migration manual, like in previous Versions, states that the DBRMLIB must be allocated exclusively if it is a PDS.
If the PDS is allocated with a SHARED DISPOSITION, S213-30 abends are possible, due to concurrency conflicts. The same applies to DB2
preprocessor steps under Endevor Software Change Manger. Endevor will not synchronize access to the DBRMLIB as long as DISP=SHR is used on it's DD.
Resolution
To guard against concurrent access on non-Endevor datasets, one has the possibility to use the 'DISP=OLD' processor feature.
ENDEVOR, if it detects this DISPOSITION in a processor, will dynamically allocate the Dataset with DISP=SHR, but will also
issue an exclusive ENQ with major CTLIPROC , minor 'the dsn' , to single thread access to the dataset within the processor
STEP with other similar ENDEVOR STEP instances.
This as opposed to a true DISP=OLD, which can only be effectuated within an Endevor processor via the ENHOPTDD option,
with the inherent longer exclusive access, and possible negative effect on throughput.
Feedback
