On Wed, Jun 12, 2019 at 7:49 AM Peter Relson <rel...@us.ibm.com> wrote:
> >I never apply maintenance to a running system. > > If true, then it sounds like your case is the exact one for which LNKLST > UNALLOCATE and LNKLST ALLOCATE were created. > You are (I hope) enlarging an uncataloged-on-this-system SYS1.MIGLIB data > set. > And the only problem would have been the running system's ENQ on the > running system's SYS1.MIGLIB data set. > So you use LNKLST UNALLOCATE. > Then you do whatever you want with your uncataloged data set. > > There would have been no reason to stop LLA. > Curious. I have a "WHOHAS" which shows SYSDSN enqueues on a DSN. On both a z/OS 1.12 and 2.3 system, it shows: sys1.miglib, OWNERS= 2 ,WAIT EXCLUSIVE= ,WAIT SHARED=, JOBNAME=XCFAS ,TYPE=OWNER ,USE=SHARED, JOBNAME=LLA ,TYPE=OWNER ,USE=SHARED, ENTER DSNAME WITHOUT QUOTES - NO LEADING BLANKS, > > But if you are playing with LNKLST SETs then either you shouldn't be or > your initial statement is not true. > > There is no way to remove SYS1.MIGLIB from a LNKLST set. You would have > had to IPL with a SYSLIB MIGLIB statement. > > And while you appear to have lucked out in whatever you did, you put your > system at risk while you were doing it. > > Peter Relson > z/OS Core Technology Design > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
