This thread has SCEELKED in the title. But aside from the question of "why is this data set in the LNKLST" the data set name is not relevant. The LNKLST data sets are ENQ'd (SHR) precisely to try to keep you from doing things to those data sets that can crash your system (RESTORE, COMPRESS come to mind, at least if you properly use DISP=OLD when doing them; if you use DISP=SHR you're on your own).
<snip> I think you can do this by: 1) remove the LLA enqueue by shutting down LLA on all system in the sysplex (and wear the performance hit for a while) 2) remove the XCFAS enqueue by issuing command SETPROG LNKLST,UNALLOCATE on all systems Restore your dataset. Maybe to an alternate residence volume which should probably be staged into the sysplex by appropriate IPL's <end-snip> !!!!DO NOT DO THIS. !!! (unless it truly is to an uncataloged copy of the data set) The reason that LNKST,UNALLOCATE is provided is so that you can deal with an uncataloged data set of the same name as a data set in the LNKLST. It is not provided so that you can muck around with a data set in the LNKLST. Doing such mucking around to a data set in the LNKLST is "system abuse". If you ABSOLUTELY must compress, restore, delete (or whatever other harmful thing comes to mind) a data set that is in the LNKLST, the best thing to try (and even this uses the unpredictably dangerous, can result in your system dying, though often has no harmful effects, so don't complain if you have to re-IPL, LNKLST UPDATE) is: -- create a new LNKLST set that does not have your data set (it could have a copy of it) -- activate it -- stop LLA (or remove that data set from LLA management) -- LNKLST UPDATE JOB(*) so that everyone is using the new LNKLST set -- NOW neither LLA nor XCFAS will have the ENQ -- do whatever you want with the data set -- do analogous things to bring things back the way they were (though this time you might choose not to bother with the LNKLST UPDATE if you don't mind having old address spaces still use that previous LNKLST) And by "absolutely must" I generally mean "or else I'd have to IPL anyway, so it's worth trying" In general, it is a bad idea to put any data set (or module) in the LNKLST unless the owner has indicated that it is OK to do so. Otherwise you could be introducing a system integrity problem. The system rule is that authorized programs must load things only from authorized concatenations, and that (by default) the LNKLST is treated as an authorized concatenation even if the individual data sets are not APF-authorized (this is the LNKAUTH=LNKLST system parameter, as contrasted with the LNKAUTH=APFTAB system parameter). Not every program is written to be safe if invoked in an authorized state. Stronger, it seems likely that a huge percentage of programs that were not specifically intended for authorized environments are indeed not safe if invoked in an authorized environment. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
