Once more into the breach. All of this has been covered multiple times, but searching archives is no one's favorite thing to do and often it's too hard to find what you want.
Use of LNKLST ALLOCATE/UNALLOCATE is solely provided so that you can access uncataloged datasets of the same name as a LNKLST dataset. It has no effect on an active LNKLST. Stopping VLF is not of any help. The right approach, as was mentioned, is to define a new LNKLST set (and activate it). For things to work, there needs to be a DCB with a new DEB that tracks to the new dataset. Only LNKLST ACTIVATE will do that. For example, LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST ACTIVATE NAME(xx) This approach works too if you have a LNKLST dataset that was allocated in such a way that it could extend into secondary extents and then, because of your actions, did. If you want to get rid of the old dataset, you need to get everyone from using the current (and any old) LNKLST sets. This is unpredictably dangerous and can result in absolutely anything, from "no problem" to "wait state". But if you must (such as if the alternative is "IPL anyway"), then SETPROG LNKLST UPDATE JOB(*). The safe approach is to leave the old dataset and use the new name. LNKLST DEFINE NAME(xx) COPYFROM(CURRENT) LNKLST DELETE NAME(xx) DSN(yyy) LNKLST ADD NAME(xx) DSN(yyy) LNKLST ACTIVATE NAME(xx) And then decide if you have existing jobs that actually need the new dataset. If you don't, then no LNKLST UPDATE is needed, and no problems will occur. LLA does not need to be stopped or refreshed. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
