When building a new system or adding maintenance I go back through all LNK, LPA and APF libraries making sure they all have at least 20% free space. If for no other reason getting setup for the next maintenance cycle. When I'm bored, which is almost never, I'll check every data set on the RES volume for free space.
;-D an -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Tuesday, October 02, 2018 2:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S106 abends after copying into LINKLIST You can also avoid both by allocating it large enough: calculate what you need during the life of the IPL, double, triple or whatever it and you can sleep quietly. What do a few 1000 cyls cost these days? Kees. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: 02 October, 2018 8:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: S106 abends after copying into LINKLIST > > On 10/1/2018 1:34 PM, Jesse 1 Robinson wrote: > > There are two separate problems here. (1) A link list library taking a > new extent after IPL. (2) An LLA-managed library having contents moved > by either compress or reload. > > > > (1) Can be avoided by simply not defining any secondary extent, i.e. > specifying a secondary of zero. Getting more than one extent to satisfy > the original allocation is not a problem as long as no additional extent > is allowed afterward. If a new extent is truly needed to hold enlarged > content, then link list update can be used. > > > > (2) Seems to be OP's issue. LLA REFRESH can handle the consequences of > dynamic update within the original (IPL time) extent(s). Note that > REFRESH is needed on all sharing systems. > > I never liked defining secondary of zero. I realize it's IBM's > recommendation, but it all but ensures a compress will be performed when > the library fills up. I've had systems crash either during or after such > a compress -- sometimes with disastrous consequences! > > I would much rather take a new extent for one relinked module than risk > corrupting the *ENTIRE LIBRARY* with a "live" compress using DISP=SHR. > Of course, periodic compress of LNKLST PDS libraries is not a bad idea > when done under controlled circumstances: i.e., "quiet" time and LLA on > all sharing systems has been shut DOWN. Also, I like to STEPLIB any > IEBCOPY job to a recent *copy* of SYS1.LINKLIB to ensure IEBCOPY program > parts are not moved during the compress... BTDTGTS!! > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > ------------------------------------------------------------------------ > -------- > This e-mail message, including any attachments, appended messages and > the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, > distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all > copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although > this > email message and any attachments or appended messages are believed to > be > free of any virus or other defect that might affect any computer system > into > which it is received and opened, it is the responsibility of the > recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or > use. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
