Ted I went three years without running defrag on a development system that usually ran 3-15% free space. I just got really good at SMS and ACC/SRS and employed similar rules in production.
We had applications using symbolics to specify small/medium/large/huge for space in JCL and ACC would change that to an appropriate DATACLAS. Nothing in production got an allocation larger than (CYL,(500,250)) and the same JCL in development allocated files 90% smaller ~ (CYL,(50,3)). Fragmentation indexes were through the roof, and x37 abends were rare as hen's teeth. I agree with aggressive migration policies, backed up with thrash detection. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ted MacNEIL > Sent: Thursday, March 04, 2010 11:51 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] Defrag > > >I hate defrag. Hate it with a passion. Scheduled defrags usually mean the > Storage Admin needs a little help and guidance... > > I disagree. > It could be lack of DASD. > As I've said, use of fragmentation indeces reduces the impact. > After awhile, defrags are in, out, and done. > > It's an insurance policy, especially in tight storage groups. > And, it's not your only tool. > Aggressive migration policies can mitigate a lot. > Especially with test data. > - > Too busy driving to stop for gas! > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
