Greg, Most of what I have done in the past centred on aggressive use of space recovery software. I used ACC/SRS, but the same or similar can be achieved with Stop-X37 (whatever it is called now) and SMS. I've run development systems with average 4% free space this way.
1) Fewer and Larger Storage Groups - I generally work with five core storage groups. I worked in shops with 80+ STORGRUPs, (128 is my record) and consolidating these down to 5 was the single largest change that reduced X37 abends 2) Everything is multivolume. Combined with large Storage Groups, allocation is encouraged to overflow on many volumes. I set the default for all allocations to 5 volumes in the DATACLAS and with ACC, and used the ADDVOL rules in SRS to automatically add volumes as a file grew. Files in 20-30 extents across 10-20 volumes are normal. This also helped reduce IOSQ for large datasets. 3) Smallish primary allocation sizes. If everything can be multivolume and multi-extent then why try and allocate everything in one extent. I used ACC and Datclasses to reduce primary allocation sizes - the largest was 500 Cyls. 4) Primary Space reduction in SRS (Stop-x37, whatever). If you can't get it the first time, try again. Reduction percentage should not be too small or you spend a lot of MIPS redriving the allocation - I like 25%. 5) Secondary extents for everything and make them bigger. If I reduce the primary then I also increase the secondary. Large datasets are allocated as CYLS(500 500). 6) Secondary space reduction. So you can use all those little pieces of free space that DEFRAG cleans up 7) Increase secondary allocation. This is an SRS (and STOP-X37) rule that increases the secondary request as the file grows. If the dataset is growing as it is used then ask for more space for each extent, and then trim it with secondary space reduction if you can't get it. Helps stop datasets from running out of extents. 8) In SMS use the secondary space value for allocation on subsequent volumes. 9) Enforce SDB. I used ACC to add DSORG=PS and BLKSIZE=0 in all eligible allocations. 10) Enable Space release on Management Classes. 11) Use extended format for VSAM so that space release works. 12) Convert CYL to track allocations. I used ACC to do this. 13) Use DFHSM MAXEXTENTS to consolidate PDS. This helps stop ordinary PDS from blowing the 16 extent limit as they grow. Only single volume non-EF non-VSAM datasets are selected. 14) Monitor dataset extents. Look for files exceeding 50 extents as some tweaking of rules or JCL may be required. Many of these cases work together - you just can't do Primary space reduction without add volume processing. One thing that became obvious as I designed this is that fragmentation will persist, and with tools like space release it would probably get worse. Rather than fight it, I looked at ways to make sure free space could be used. The site that drove this plan went from two X37 abends a night to 2 per month with no additional DASD. The Production system was running at about 15-20% free space and development was at 4% free space. The only problems in development system were occasional DFHSM recall failures, but this was 3 or 4 per month. YMMV but this worked for me. And yes there were exceptions and special cases, but only a few. Ron PS we stopped doing DEFRAGS the day I started consolidating the Storage Groups > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Greg Shirey > Sent: Tuesday, 1 May 2007 3:53 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: FW: Do we have to defrag MVS volumes on newer generation disk > arrays? > > Ron, I'd be curious what some (or all) of those dozen are, if you have > the time. We're still running DEFRAGs, but if there's something more > effective we could be doing, I'd like to hear about it. > > TIA, > Greg Shirey > Ben E. Keith Company > ---------------------------------------------------------------------- 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
