This is a head-up so no one else spends a lot of time needlessly: This check tripped on all systems in the production sysplex (together with the RACF sensitive resources one). Then both conditions cleared themselves magically on all systems all by themselves, and since we didn't have the history log stream, it took three sysprogs all day NOT to find anything wrong with any linklist dataset.
Finally I found a RACF apar that says whenever there is an exclusive enq on any dataset so that the checks cannot get at it, then the exception is triggered. For RACF, this is fixed in oa21267. Note that the apar text makes it sound (to me) like the ENQ must be actually held. Well, it doesn't, and the newextents check does the same thing: Just submitting an iefbr14 batch job with a dd statement with disp=old on any lnklst dataset (that batch job goes into a wait and doesn't get the ENQ) and then refreshing the check triggers the check that says that the linklist went into extents. Actually, what SDSF shows is this: TOTAL EXTENTS ORIG: 75 CURR: 74 So from the orginal 75 extents we're down to 74 (accessible) extents, and of course that means that the linklist went into extents! The CK panel correctly states "information could not be obtained for data set", but that doesn't prevent the high severity exception. Regards, Barbara ps: The batch job that erroneously had the disp=old doesn't normally run.... -- Super-Aktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden: http://flat.games.gmx.de ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
