LINKLST datasets that occupy secondary extents at IPL time do not suffer from this problem. It only arises if the dataset grows into a NEW extent after the IPL. The problem arises then because the LINKLST DEB was built when the LINKLST was defined and any attempt by LLA to access the new extent is flagged as outside the DASD area specified in the DEB.
Whether a LINKLST dataset should not have secondary extents (thus causing SMPE to fail if the current allocation is insufficient) or should (possibly resulting in the need for appropriate post-SMPE adjustments) is an administrative decision, not a technical one. It's not part of LINKLST but the only dataset I know of that never tolerates a secondary extent is SYS1.NUCLEUS. :>: -----Original Message----- :>: From: IBM Mainframe Discussion List [mailto:[email protected]] On :>: Behalf Of Lizette Koehler :>: Sent: Sunday, January 12, 2014 3:41 AM :>: To: [email protected] :>: Subject: Re: z/OS 1.13 PTF apply Issue :>: :>: Some searches on the internet for IBM S106 0F :>: brings up :>: :>: These messages and the ABENDS106-0F indicate that a link list ( LNKLST ) :>: library has gone into additional extents. This could occur if SMP/E :>: maintenance was being applied to the library :>: :>: So, if your LINKLST library is in EXTENTS (and LINKLST datasets should :>: not :>: be coded with Secondary Extents) then you will need to IPL. You can use :>: the :>: TSO function ISRDDN to see if the LINKLST is in extents. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
