I would like to clarify a item or two that I mis-stated in a previous email, Haven't used PDSE, most PDS and they were in the linklist, The only time I have seen them compressed is during system time, during a maintenance Window with qualified folks, secondly if they are paying the bucks, well what can I say, I usually was just a hired gun. Especially working for IBM as a consult, which I have numerous times.
Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 22, 2012, at 8:34 PM, John Gilmore <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
