On 09/11/2014 09:39 AM, Jousma, David wrote: > I'm thinking that since you specified your library as part of the SYSLIB > statement that is the reason you cannot change it. We put a library in there > that is normally empty for "situations". > > > SYSLIB LINKLIB(SYS1.PDP.&SYSNAME..FIXLIB) > /*---------------------------------------------- > LNKLST DEFINE NAME(LNKLST00) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.LINKLIB) > LNKLST ADD NAME(LNKLST00) DSN(SYS1.MIGLIB) > > > As far as I can tell, there is no way to dynamically change datasets > specified in the SYSLIB statement. While Lizette mentioned the error you > received, you are not technically delete SYS1.LINKLIB, but because your site > custom dataset is in SYSLIB, I believe that to be the reason why. > > Sounds like IPL time to me to fix. > _________________________________________________________________ > Dave Jousma > Assistant Vice President, Mainframe Engineering > david.jou...@53.com > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H > p 616.653.8429 > f 616.653.2717 > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mark Jacobs > Sent: Thursday, September 11, 2014 10:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: CSV513I Issued for SYSLIB LINKLIB(xxxx) dataset > > AFAIK, this is the first time I've tried it. We're at zOS 1.13. > > I was just hoping that there was an option available on the command that > would allow a wise, or bold, systems programmer to override this restriction. > > Mark Jacobs > > On 09/11/14 10:19, Lizette Koehler wrote: >> Mark, >> Not all datasets can be deleted from a Linklst. This message >> indicated your dataset are in that category >> >> CANNOT DELETE SYSTEM DATA SET >> You cannot delete system data sets SYS1.LINKLIB, SYS1.MIGLIB, >> SYS1.CSSLIB SYS1.SIEALNKE, and SYS1.SIEAMIGE from a LNKLST set. >> >> >> Were you able to do this in the past? >> Is this the first time you are doing this dataset? >> What version of z/OS? >> >> >> Lizette >> >> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>> On Behalf Of Mark Jacobs >>> Sent: Thursday, September 11, 2014 5:40 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: CSV513I Issued for SYSLIB LINKLIB(xxxx) dataset >>> >>> Here's our SYSLIB statements; >>> >>> SYSLIB LINKLIB(SYS1.&SYSNAME..LINKLIB) SYSLIB >>> LPALIB(SYS1.&SYSNAME..LPALIB) >>> >>> My commands were; >>> >>> SETPROG LNKLST,DEFINE,NAME=TEMP,COPYFROM=TCS2 >>> CSV500I LNKLST SET TEMP HAS BEEN DEFINED >>> >>> SETPROG >>> LNKLST,ADD,NAME=TEMP,DSN=SYS1.TCS2.LINKLIB.TEMP,ATTOP >>> CSV501I DATA SET SYS1.TCS2.LINKLIB.TEMP HAS BEEN ADDED TO LNKLST SET >>> TEMP >>> >>> SETPROG LNKLST,DELETE,NAME=TEMP,DSN=SYS1.TCS2.LINKLIB >>> CSV513I DATA SET SYS1.TCS2.LINKLIB 136 WAS NOT DELETED FROM LNKLST >>> SET TEMP. >>> CANNOT DELETE SYSTEM DATA SET >>> >>> Mark Jacobs >>> >>> On 09/11/14 08:29, Elardus Engelbrecht wrote: >>>> Mark Jacobs wrote: >>>> >>>>> I tried to replace the SYSLIB LINKLIB dataset in the linklist, but >> SETPROG >>> wouldn't let me delete the in use one from the newly defined linklist set. >>>> Please show us your command attempt(s) and/or PROGxx member and the >>> resulting message(s). >>>>> IMHO, it either should be allowed for any of the SYSLIB datasets in >> PROGxx, or >>> at the least have an option on the SETPROG command that tells it that >>> you understand the risks, but full speed ahead. >>>> There is such command, but just tell us what did you do? >>>> >>>>> UNIX was not designed to stop its users from doing stupid things, >>>>> as >> that would >>> also stop them from doing clever things. >>>> A fool is better than foolproof software... <grin> >>>> >>>> Groete / Greetings >>>> Elardus Engelbrecht >>>> >>> -- >>> Mark Jacobs >>> Time Customer Service >>> Tampa, FL >>> ---- >>> >> >> > > -- > Mark Jacobs > Time Customer Service > Tampa, FL > ---- > > The standard you walk past is the standard you accept. > Lt. Gen. David Morrison, Australian Army Chief > My recollection is that we used several references to a one-track empty data set as a stand-in for the "special" data sets in LNKLST and then defined SYS1.LINKLIST as an ordinary LNKLST data set, which avoids this issue if one really needs to dynamically replace the standard SYS1.LINKLIB for new address spaces. The primary reason we did it was to concatenate another data set in front of SYS1.LINKLIB so we could use SyncSort BetterGener to replace IEBGENR without allowing any SyncSort maintenance to dicker with libraries and SMP/E zones owned by IBM products.
Other than historical reasons, there's really no reason why any library in LNKLST should require a special, unique definition technique; understanding of course that certain critical system libraries like SYS1.LINKLIB need to be very early in the game and any preceding libraries should be reserved for unusual cases where there is a legitimate need and deliberate intent to override some standard IBM load module. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
