On 09/02/2010 06:24 PM, Rick Fochtman wrote: > ---------------------------------<snip>----------------------------------: > >>> One of my coworkers ran a compress against a production file during >>> prime >> time >> >> I've always found it curious that so many times compress is done >> without using DISP=OLD. >> That seems "nasty" to me (at least if you like your data sets to >> continue working). >> >> Peter Relson >> z/OS Core Technology Design >> >> > --------------------------------<unsnip>--------------------------- > Peter, I suspect it's a carry-over from the days when DISP=OLD did > reserves on shared DASD. I may be wrong. > > Rick
Use of shared compress in our environment has little to do with shared DASD reserve issue. Murphy's law pretty well guarantees in real life that a signficant number of PDSs that fill up and need a critical update will have shared enqueues held by long running address spaces (CICS, long batch, TSO users, STCs, LLA, etc.). In many cases where you can restrict other update activity to the dataset (limited update authority and you know others will keep hands off) and know something about the read activity, it is possible to make a reasoned judgement about whether the risk of a shared compress is worse than failure to compress and install an update. The possibility of a few address spaces getting blown away during the transition is even acceptable if the odds are low enough, and if there are ways to work around any failures that might occur, and if the failure to install an update puts many more users at risk. Some LNKLST libraries with high usage or critical usage, like SYS1.LINKLIB, would never be safe to treat in this way. Other LNKLST libraries may only affect a rarely used, non-critical application, and a Shared compress on one of these followed ASAP by an LLA refresh has very low risk. An of course, if you know the dataset is only updated using ISPF-style enqueueing rules, then there are even supported ways in ISPF of doing a shared compress that tolerates update attempts and guarantees that updates that conflict are delayed until the compress is done. If you have no idea what you are doing and just indiscriminately use canned JCL that does a shared compress you will eventually get burned; but, ignorance mixed with authority to update critical datasets is always dangerous. -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
