Peter Relson wrote: <begin snippet> If it were a question of competence and judgment, we would happily tell you what to do. It is not. </end snippet>
It is a question of karma or luck too, and that can run out. --jg On 1/22/12, Peter Relson <[email protected]> wrote: >>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 > -- John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
