I'm not sure I noticed the original append in this thread, but just to re-iterate what has been stated by those who responded, and often in the archives:
It is likely NEVER safe to delete a data set that is within an in-use LNKLST set, The (SETPROG, PROGxx) LNKLST UNALLOCATE function is provided so that you can work with an uncataloged data set of the same name as a data set that is in the LNKLST, since otherwise the ENQ that is held would preclude this. I believe that it is for exactly the same reason that you can tell LLA not to get its ENQs. In neither case is it so that you can do something with the data set for which the system obtained the ENQ, as the ENQ was obtained precisely to help avoid system problems due to such things as deletions. Soap Box: I wish we had a customer-settable system option so that COMPRESS would be rejected if the data set was not allocated DISP=OLD (maybe limited to certain classes of data sets, in case such a restriction would be too unpalatable for user data sets). The system cannot get its data set ENQs exclusive, as that would break those who rightly need to read them. But when it gets the ENQ shared, it cannot stop a COMPRESS that (incorrectly, at least in my opinion) requested DISP=SHR. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
