On Wed, 20 Apr 2016 10:57:13 -0500, John McKown wrote: >On Wed, Apr 20, 2016 at 10:28 AM, Jake Anderson wrote: > >> I have got a product running with few Libraries who are in In different >> storage Group.To Move this Datasets to a different Storage Group. Without >> removing the datasets from Linklist and APF is it possible to accomplish ?
No, it isn't. >> Or Just Shutdown the address space, then move the dataset, then Refresh the >> LLA and start up the Address space again would be correct thing to do ? Do not try to do this. >> > >Just to put some names on things I way that you have a data set, such as >SYS1.PRODUCT.LINKLIB on volume BUBBA1 in storage group SGBUBBA. You want to >move it from BUBBA1 to volume FREDDY >in SGFREDY. It is on the LNKLIST and APF list. > >Bottom line: you can't _really_ do that safely. Why? Because the data sets >on the LINKLIST are OPEN and so the DEBs describing them are created. There >is not a way to really change that. But there is a way to "fake it". > >1) unallocate the LINKLIST from XCF using the z/OS command: SETPROG >LNKLST,UNALLOCATE >2) stop the LLA address space: P LLA >3) rename SYS1.PRODUCT.LINKLIB to SYS1.PRODUCT.LINKLIB.DEL.LATER !! DO >NOT DELETE THIS DATA SET YET !! >4) allocate a new SYS1.PRODUCT.LINKLIB on the proper volume (hopefully you >know how to force it) >5) copy members from SYS1.PRODUCT.LINKLIB.DEL.LATER to SYS1.PRODUCT.LINKLIB >6) do a SET PROG=nn to activate a _new_ LINKLIST concatenation. > This can contain the same data set names, but must have a new linklist >name. I would not do this. The reason is that LLA only works with cataloged data sets. You cannot have two different data sets with the same DSNAME managed by LLA. >7) start LLA back up: S LLA When you start LLA back up, what will be cached for SYS1.PRODUCT.LINKLIB? When a program using the old LNKLST accesses a member from that data set, what will happen? >8) I don't remember if you need to do a: SETPROG LNKLST,ALLOCATE > >After you IPL all the z/OS system which used the old version of >SYS1.PRODUCT.LINKLIB, you can delete the data set >SYS1.PRODUCT.LINKLIB.DEL.LATER . The above commands _do not_ cause any >running address spaces to use the new version of the linklist! You can do >that using the SETPROG command: SETPROG LNKLST,UPDATE,JOB=* __but__ IBM >strongly discourages this! > >The reason for all the "fiddling around" is that the DEBs built at IPL >cannot be updated to point to the new version of the data set. So if you >actually reuse the tracks where it used to exist, you can get VERY BAD >results. Jake, You didn't say what kind of product this is or how many address spaces might be using it, which might affect the way that I would go about doing this, but here is one way: Copy current.dsname to new.dsname SETPROG LNKLST,DEFINE,NAME=newlnklistname,COPYFROM=oldlnklstname SETPROG LNKLST,ADD,NAME=newlnklistname,DSNAME=new,dsname,AFTER=current.dsname SETPROG LNKLST,DELETE,NAME=newlnklistname,DSNAME-current.dsname SETPROG LNKLST,ACTIVATE,NAME=newlnklistname Now you can stop the product and restart it. It will use the new LNKLST set. All existing address spaces will use the original LNKLST set. You will need to update PARMLIB to pick up the new data set for the next IPL. You might consider using symbolic aliases to avoid this issue in the future. For example, rather than name your data set SYS1.PRODUCT.LINKLIB, you could call it SYS1.PRODUCT.V2.LINKLIB with a data set alias of SYS1.PRODUCT.PROD.LINKLIB. It would be cataloged with SYMBOLICRELATE to SYS1.PRODUCT.&PRODSYM..LINKLIB. &PRODSYM would be a system symbol defined by you to be equal to V2. The entry in PROGxx would reference SYS1.PRODUCT.&PRODSYM..LINKLIB. The next time you have to do something like this, you would update the symbol from V2 to V3 (for example) for the next IPL. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
