>So the only functionally-equivalent, officially-sanctioned way to >accomplish this goal is still to >(1) create a new dataset with a different name and copy the data to it, >(2) modify PARMLIB LNKLST defs to replace the old library in linklist >with the new at next IPL, >(3) IPL. >And if for some reason you really must have the original dataset name, >repeat the process to get back to the old name.
If the data set was in the IPL-time LNKLST set, yes. If the data set was not in the IPL-time LNKLST set, then it depends on whether or not you are able to recycle any spaces that were started after you activated the post-IPL LNKLST set. If push came to shove, most are likely aware of the LNKLST UPDATE function. It's there if you're willing to risk it, and not complain if something bad happens. Regardless, you should expect to have to remove the data set to be compressed from the active LNKLST (by activating a new LNKLST set without the data set), making sure that no one is using that data set within their LNKLST set (by recycling, terminating, or using UPDATE), and making sure that LLA is not managing that data set (by informing LLA not to manage this data set, or terminating LLA). Then you can compress the data set. >techniques whose >success depends on SysProg competence and judgement If it were a question of competence and judgment, we would happily tell you what to do. It is not. >I have seen the compression on the fly for years, no damage no harm. And others have seen harm. The system is yours, you can do what you want. You just shouldn't expect a ton of sympathy. 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
