I get very frustrated when I continue to read posts about deleting libraries from the LNKLST. Anything that intends to delete a library from the LNKLST should be prepared for unpredictable errors and immediate re-IPL. This should be done as a last resort only.
The LNKLST UNALLOCATE command is NOT intended to allow you to do that. It is intended to let you deal with uncataloged data sets of the same name as one in the LNKLST. If you tell the system to remove its ENQs and then do something like deleting a data set that is still being used you are subverting your own system and all bets are off. It is true that you cannot delete PDSEs that are in the IPL-time LNKLST. And you might have trouble with PDSEs that are in a LNKLST created after IPL. We hope to address both of those situations (alleviate, perhaps even remedy) in z/OS V1 R8. You must not delete a data set (PDS or PDSE) from a LNKLST that someone is using under any circumstance (and re-allocating to be larger size includes initially deleting). That means that if for some reason you feel you need to delete the data set, your first responsibility is to make sure that no job or address space has that data set in the LNKLST that it is using. As was posted, you would start by creating a new LNKLST set, without the "bad" data set, and LNKLST ACTIVATE it. New jobs and address spaces will automatically use that one. But you still have the problem of old jobs. The only way that you can do that is via the LNKLST UPDATE statement of PROGxx (or SETPROG LNKLST UPDATE). And that statement is to be issued at your risk. If you use it, you must be prepared to re-IPL. SETPROG LNKLST UPDATE JOB(*), for example, will get everyone off of old LNKLSTs, and may cause unpredictable problems for those address spaces. Once you have done that, and once you have gotten LLA no longer to be managing the particular data set (perhaps by stopping LLA and restarting it; perhaps by removing that data set from LLA management -- an LLA refresh will not do it), then the system will not have the data set ENQ'd and (aside from the "PDSE in the IPL-time LNKLST" case) you would be able to delete the data set. The approach of allocating a new larger data set and creating a LNKLST set with that data set instead of the old data set and then activating that LNKLST set is perfectly safe and will, at least, let new jobs use whatever is in the larger data set. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
