Re: Defrag
--snip-- AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. unsnip-- I can't speak for Extended Format, but for non-Extended Format datasets, you can only have one FORMAT-3 DSCB per dataset (Except for the special case of ISAM, now long dead.) Rick -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, March 05, 2010 12:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag --snip -- AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. unsnip -- I can't speak for Extended Format, but for non-Extended Format datasets, you can only have one FORMAT-3 DSCB per dataset (Except for the special case of ISAM, now long dead.) Rick SNIP Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB can only have 4 extents, but a simple PS data set is limited to 16 Extents on a volume, then we have a problem. It has been 14+ years since I've had to do DSCB handling (OBS/ACS WYLBUR would try to get a PDS to a single extent...). So I don't recall the actual layouts and only went by what IBM's doc says. And I could very well have misread or misinterpreted DFP/DFSMS's verbiage. But the point was recovering space in a VTOC... Regards, Steve Thompson -- 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
Re: Defrag
Steve, Why not just allocate a bigger VTOC. The argument is that the regular shuffling of thousands of CYls into contiguous extents to save one or two cyls on a VTOC is valuable exercise. I don't see it. I would give the Storage Admin help and guidance on sizing a VTOC, and how to reallocate a larger one. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Friday, March 05, 2010 10:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, March 05, 2010 12:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag --snip -- AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. unsnip -- I can't speak for Extended Format, but for non-Extended Format datasets, you can only have one FORMAT-3 DSCB per dataset (Except for the special case of ISAM, now long dead.) Rick SNIP Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB can only have 4 extents, but a simple PS data set is limited to 16 Extents on a volume, then we have a problem. It has been 14+ years since I've had to do DSCB handling (OBS/ACS WYLBUR would try to get a PDS to a single extent...). So I don't recall the actual layouts and only went by what IBM's doc says. And I could very well have misread or misinterpreted DFP/DFSMS's verbiage. But the point was recovering space in a VTOC... Regards, Steve Thompson -- 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
Re: Defrag
---snip-- Steve, Why not just allocate a bigger VTOC. The argument is that the regular shuffling of thousands of CYls into contiguous extents to save one or two cyls on a VTOC is valuable exercise. I don't see it. I would give the Storage Admin help and guidance on sizing a VTOC, and how to reallocate a larger one. Ron -unsnip--- Or how to extend an existing VTOC... Rick -- 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
Re: Defrag
Because that's not our problem. I thought I was answering the original poster's question and extended it out to the VTOC and repercussions there, along with possibly running out of space in the VTOC, which is why you might want to do DEFRAG. Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Friday, March 05, 2010 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Steve, Why not just allocate a bigger VTOC. The argument is that the regular shuffling of thousands of CYls into contiguous extents to save one or two cyls on a VTOC is valuable exercise. I don't see it. I would give the Storage Admin help and guidance on sizing a VTOC, and how to reallocate a larger one. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Friday, March 05, 2010 10:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Friday, March 05, 2010 12:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag --snip -- AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. unsnip -- I can't speak for Extended Format, but for non-Extended Format datasets, you can only have one FORMAT-3 DSCB per dataset (Except for the special case of ISAM, now long dead.) Rick SNIP Based on the doc, if an F1DSCB can only have 3 extents, and an F4DSCB can only have 4 extents, but a simple PS data set is limited to 16 Extents on a volume, then we have a problem. It has been 14+ years since I've had to do DSCB handling (OBS/ACS WYLBUR would try to get a PDS to a single extent...). So I don't recall the actual layouts and only went by what IBM's doc says. And I could very well have misread or misinterpreted DFP/DFSMS's verbiage. But the point was recovering space in a VTOC... Regards, Steve Thompson -- 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 -- 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
Re: Defrag
Mark, The OP never mentioned the VTOC. It's not his problem. Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? It has already been suggested that this can be dealt with automatically using DFSMShsm Extent Reduction which is controlled by MAXEXTENTS. It could also be resolved manually by moving datasets off the volume. Recovering the space in the VTOC was a digression introduced later in the thread. If a VTOC fills you can: 1) Run a defrag holding an exclusive reserve on the VTOC for the duration of the Defrag. This is not guaranteed to work and may be disruptive. 2) Run a REFVTOC with EXTVTOC or NEWVTOC. If there is space on the volume then this is guaranteed to work. And if the VTOC is full and not the volume, then there's going to be free space for the new VTOC. What case would there be for choosing option 1 over option 2? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Friday, March 05, 2010 1:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag Because that's not our problem. I thought I was answering the original poster's question and extended it out to the VTOC and repercussions there, along with possibly running out of space in the VTOC, which is why you might want to do DEFRAG. Regards, Steve Thompson -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Thursday, March 04, 2010 12:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. SNIP But how does this solve problems for NON-VSAM / non-EXTENDED data sets? 16 extents and you are done (on a volume). How does this reclaim space in the VTOC (I don't really care, but I can see why one might, even with indexed VTOC). I had asked a related question some time ago and I don't recall any one addressing it. I know that we are all [probably all] running with RAID. But since a real device is being emulated, we wind up with the problems that the VTOC recognizes (even though, virtually, the data may be side by side in an actual single extent). Regards, Steve Thompson -- 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
Re: Defrag
Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. On Thu, Mar 4, 2010 at 1:30 PM, McKown, John john.mck...@healthmarkets.comwrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Defrag
Some might argue that fragmentation breeds fragmentation. Perhaps your root problem is that there needs to be more space. If new allocations can be satisfied with fewer extents in the first place. Plus, you are paying quite a performance price with all of that file shuffling. DASD is cheap. Just a thought. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. In our shop, the 16 extent limit only applies to PDSes because all other dataset types can be (and are forced to be) multivolume. We often have sequential files which are spread over 12 volumes with 80 extents. If you cannot have that many volumes in a storage group, then you are forced to defrag. Or be very aggressive with HSM migrations. At one time, we had a product in house called Real Time Defrag which was an STC which would monitor volumes and do dataset moves to reduce fragmentation. My personal opinion was that it was a stupid idea as it drove the I/O and CPU rates up for no real business benefit. It was cheaper to just have enough free space to avoid the problem. This is not always possible, unfortunately. BMC's Mainview/SRM (old Stop/X37) and DTS's ACC and SRS can be used to address the Sx37 type space abends as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. DASD performance is NOT the only reason for defrags, not that it's one to worry about anymore. What about files restricted to single volumes (PDS[E])? Small storage groups? Volumes with such small free extents that nothing can be allocated? If you're fortunate to not have any of these, then I guess there is no reason for defrag, at all. But, ... - 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
Re: Defrag
You might want to consider getting somewhat more aggressive with dfHSM migration. This will free up space, reduce extents required,. Also consider DVC in the SMS STORCLAS. The historical pattern of DSN access (in most shops) is write/read once and fageddaboudit. HTH, snip Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. /snip On Thu, Mar 4, 2010 at 1:30 PM, McKown, John john.mck...@healthmarkets.comwrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Defrag
Everything is cheap when you can afford it. On Thu, Mar 4, 2010 at 1:48 PM, Hal Merritt hmerr...@jackhenry.com wrote: Plus, you are paying quite a performance price with all of that file shuffling. DASD is cheap. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Defrag
I'll research DVC. Thanks. On Thu, Mar 4, 2010 at 1:59 PM, Staller, Allan allan.stal...@kbm1.comwrote: You might want to consider getting somewhat more aggressive with dfHSM migration. This will free up space, reduce extents required,. Also consider DVC in the SMS STORCLAS. The historical pattern of DSN access (in most shops) is write/read once and fageddaboudit. HTH, snip Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. /snip On Thu, Mar 4, 2010 at 1:30 PM, McKown, John john.mck...@healthmarkets.comwrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. DASD performance is NOT the only reason for defrags, not that it's one to worry about anymore. What about files restricted to single volumes (PDS[E])? Small storage groups? Volumes with such small free extents that nothing can be allocated? If you're fortunate to not have any of these, then I guess there is no reason for defrag, at all. But, ... - Too busy driving to stop for gas! I mentioned PDS type datasets in my original post, but didn't say much else. We have a separate storage group for them. But we don't create and delete large numbers of PDSes as a rule, so we can manage their storage by hand. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
Steve, That's not exactly correct. It's 16 extents for 59 volumes and then you're done. John's answer is the solution for your problem. ACC and STOP-X37 users have known this for 30 years. I have no idea what reclaiming space in the VTOC is. Ron But how does this solve problems for NON-VSAM / non-EXTENDED data sets? 16 extents and you are done (on a volume). How does this reclaim space in the VTOC (I don't really care, but I can see why one might, even with indexed VTOC). -- 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 1:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Everything is cheap when you can afford it. On Thu, Mar 4, 2010 at 1:48 PM, Hal Merritt hmerr...@jackhenry.com wrote: Plus, you are paying quite a performance price with all of that file shuffling. DASD is cheap. -- Mark Pace But how much is your time worth? And how much is the CPU and I/O overhead for defragging worth? If you have plenty of time to do the work and lots of excess CPU and I/O, then I guess defragging is cheaper. But I don't know an easy, automated, reliable way to get it done. Run DFDSS defrags hourly, every 8 hours, every day, ... ? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
In that case, Mark, it appears to me that your storage group must be running rather full and could probably benefit from adding a few more volumes, specifically 3390-9 or larger volumes. Or perhaps you should review your DFHSM ML1/ML2 migration criteria and migrate old datasets to reclaim some space. On the other hand, the suggestion to allow a dataset to grow to multi-volume sounds like a good idea (as it would eliminate space-related abends), albeit perhaps just a stop-gap measure. Another thing you could do to make contiguous space available is that you could free up one volume by moving all (or most of) the datasets off to other volumes within that storage group. Just pick the one that looks the worst and clean it up. That gives you contiguous free space within the group to satisfy large allocation requests and should take less time and resources to run than all the defrags together. HTH. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 10:40 To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. snipped -- 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
Re: Defrag
I mentioned PDS type datasets in my original post, but didn't say much else. We have a separate storage group for them. But we don't create and delete large numbers of PDSes as a rule, so we can manage their storage by hand. What about developer libraries? You don't leave them in their general storage group (with/without the 'E')? And, imo, managing any data by hand defeats the automated function(s) of SMS, by definition. - 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
Re: Defrag
Mark, For most datasets the Dynamic Volume count solves your problem by allowing the dataset to dynamically extend to additional volumes. Of course your users could always do something obvious like allocate larger Primary and Secondary space so they don't need 16 extents... Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. -- 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
Re: Defrag
But I don't know an easy, automated, reliable way to get it done. Run DFDSS defrags hourly, every 8 hours, every day, ... ? We used to run it frequently, daily, half-daily, and by shift. But, with a fragmentation index. The first time was slow, but each subsequent run sped up. Also, we would defrag test volume at night, and Production (batch) during the day. Online rarely needed it. - 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, March 04, 2010 1:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Steve, That's not exactly correct. It's 16 extents for 59 volumes and then you're done. John's answer is the solution for your problem. ACC and STOP-X37 users have known this for 30 years. I have no idea what reclaiming space in the VTOC is. Ron Actually, one thing that I've done in selected cases is go to extended format sequential datasets. Magic! You can have more than 16 extents per volume. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D450/3.6.10.1 quote Extended-format sequential data sets have a maximum of 123 extents on each volume. (Sequential data sets have a maximum of 16 extents on each volume.) /quote -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
On the other hand, the suggestion to allow a dataset to grow to multi-volume sounds like a good idea (as it would eliminate space-related abends), albeit perhaps just a stop-gap measure. It's not a stop-gap, imo. I consider it a best practice, especially in production. - 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 1:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag I mentioned PDS type datasets in my original post, but didn't say much else. We have a separate storage group for them. But we don't create and delete large numbers of PDSes as a rule, so we can manage their storage by hand. What about developer libraries? You don't leave them in their general storage group (with/without the 'E')? And, imo, managing any data by hand defeats the automated function(s) of SMS, by definition. - Sorry, my bad, the by hand is doing defrags. And we simply don't do many PDS allocations. Not even for developers. Perhaps we are very different from most shops in that. Here, developers generally have their ISPF datasets, a few source and executable libraries. But that's about it. And all developer libraries are in a special storage group. One that we back up daily for DR purposes. So they are in a separate STORGRUP from all other types of datasets. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
Ted, DFSMShsm should be set up to migrate/recall these PDS/PDS-E when they exceed some extent threshold I used to use eight extents. This compresses the dataset and consolidates all the extents to single, sometimes larger primary extent. I used to use the General Pool for all TSO related datasets and with DSMS consolidating PDS like this they were never problem, or cause of a problem. I've also seen this working in a Development environment with a single Storage Group for everything. 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:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag I mentioned PDS type datasets in my original post, but didn't say much else. We have a separate storage group for them. But we don't create and delete large numbers of PDSes as a rule, so we can manage their storage by hand. What about developer libraries? You don't leave them in their general storage group (with/without the 'E')? And, imo, managing any data by hand defeats the automated function(s) of SMS, by definition. - 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
Re: Defrag
I hate defrag. Hate it with a passion. Scheduled defrags usually mean the Storage Admin needs a little help and guidance... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 11:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag But I don't know an easy, automated, reliable way to get it done. Run DFDSS defrags hourly, every 8 hours, every day, ... ? We used to run it frequently, daily, half-daily, and by shift. But, with a fragmentation index. The first time was slow, but each subsequent run sped up. Also, we would defrag test volume at night, and Production (batch) during the day. Online rarely needed it. - 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
Re: Defrag
DFSMShsm should be set up to migrate/recall these PDS/PDS-E when they exceed some extent threshold I used to use eight extents. This compresses the dataset and consolidates all the extents to single, sometimes larger primary extent. I used to use the General Pool for all TSO related datasets and with DSMS consolidating PDS like this they were never problem, or cause of a problem. I've also seen this working in a Development environment with a single Storage Group for everything. I've done the same thing! I was the one asking about it. Not the one with the manage by hand, in a separate storage group. I've been involved in storage management pre-SMS, and I have always tried to put all test/development data in one storage group (or pool, as we used to say) regardless of access type (Batch, TSO, or Online). And, I've also been aggressive (some say draconian) on migration, retention, and performance issues. - 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
Re: 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, March 04, 2010 1:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag I hate defrag. Hate it with a passion. Scheduled defrags usually mean the Storage Admin needs a little help and guidance... In the past, in my case, the Storage Admin needed a high level manager with a brain (or a backbone). I literally would get calls in the early morning about space abends in production (Production!). My only recourse was to logon to TSO, go into ISMF, find all datasets older than 3 days, sort them by space allocated and HSM migrate some to TAPE! I could not get any more DASD because the array was full. We did not have the money to get another or newer array. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Defrag
I agree wholeheartedly! Out of the 78TB I have, I have only one volume that ever needs to be defragged (every couple months). It's got tens of thousands of tiny datasets being constantly being created/archived/recalled/deleted. Ron Hawkins ron.hawkins1...@sbcglobal.net 3/4/2010 2:36 PM I hate defrag. Hate it with a passion. Scheduled defrags usually mean the Storage Admin needs a little help and guidance... CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: Defrag
I agree wholeheartedly! I don't. It's a tool. Use it when necessary. Out of the 78TB I have, I have only one volume that ever needs to be defragged (every couple months). You're fortunate. Not all of us have the luxury. Don't get me wrong. Defrag, as evil as it may be, is still a valid tool. Don't do unnatural acts just to avoid it. And, ad nauseum, as I said before, don't just defrag for its own sake. That's what the fragmentation index is for. Again, think of it as an insurance policy. - 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
Re: Defrag
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, March 04, 2010 1:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Steve, That's not exactly correct. It's 16 extents for 59 volumes and then you're done. John's answer is the solution for your problem. ACC and STOP-X37 users have known this for 30 years. I have no idea what reclaiming space in the VTOC is. SNIP AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. Regards, Steve Thompson -- 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
Re: Defrag
Allowing growth to span volumes may be a good thing, but don't forget that that may fry your backup/recovery/DR strategy. Many use full volume dump/restore as a foundation. Unless -all- of the volumes are dumped at a single point of consistency (POC), then you'll have corrupted datasets. With the size of today's DASD farms, getting a window wide enough to get that POC is quite the challenge. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ulrich Krueger Sent: Thursday, March 04, 2010 1:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag In that case, Mark, it appears to me that your storage group must be running rather full and could probably benefit from adding a few more volumes, specifically 3390-9 or larger volumes. Or perhaps you should review your DFHSM ML1/ML2 migration criteria and migrate old datasets to reclaim some space. On the other hand, the suggestion to allow a dataset to grow to multi-volume sounds like a good idea (as it would eliminate space-related abends), albeit perhaps just a stop-gap measure. Another thing you could do to make contiguous space available is that you could free up one volume by moving all (or most of) the datasets off to other volumes within that storage group. Just pick the one that looks the worst and clean it up. That gives you contiguous free space within the group to satisfy large allocation requests and should take less time and resources to run than all the defrags together. HTH. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 10:40 To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. snipped -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Defrag
If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. As long as the dataset (non-extended) is 64K (binary) or less in tracks. Whichever limit you reach wins (or loses -- depends on your perspective). - 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
Re: Defrag
Easy, use FlashCopy (or equivalent). Hal Merritt hmerr...@jackhenry.com 3/4/2010 3:39 PM Allowing growth to span volumes may be a good thing, but don't forget that that may fry your backup/recovery/DR strategy. Many use full volume dump/restore as a foundation. Unless -all- of the volumes are dumped at a single point of consistency (POC), then you'll have corrupted datasets. With the size of today's DASD farms, getting a window wide enough to get that POC is quite the challenge. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: Defrag
No, actually, Flashcopy is still a PIT volume copy unless you are using consistency groups. True, the window for corruption may be somewhat smaller, it still exists. BTDT. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Thursday, March 04, 2010 3:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Easy, use FlashCopy (or equivalent). Hal Merritt hmerr...@jackhenry.com 3/4/2010 3:39 PM Allowing growth to span volumes may be a good thing, but don't forget that that may fry your backup/recovery/DR strategy. Many use full volume dump/restore as a foundation. Unless -all- of the volumes are dumped at a single point of consistency (POC), then you'll have corrupted datasets. With the size of today's DASD farms, getting a window wide enough to get that POC is quite the challenge. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Defrag
Hi Mark, We rarely defrag anything and until recently we had very little DASD. Most of our batch processes allocate to a single work pool. All allow multi-file allocations. Every night, a CA-Disk process runs to pick up the previous day's datasets from the workpool and mov e them to a hold pool. Datasets are trimmed to allocated size and, if less than 1 cyl. converted to track. The HOLDxx packs are filled. After 4 days of non-use, datasets are archived. The disk acrhive/tape archive line i s adjusted based on how much di sk was available vs. the slower restore times from tape. HTH, Linda Mooney - Original Message - From: Mark Pace mpac...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Thursday, March 4, 2010 11:01:15 AM GMT -08:00 US/Canada Pacific Subject: Re: Defrag I'll research DVC. Thanks. On Thu, Mar 4, 2010 at 1:59 PM, Staller, Allan allan.stal...@kbm1.comwrote: You might want to consider getting somewhat more aggressive with dfHSM migration. This will free up space, reduce extents required,. Also consider DVC in the SMS STORCLAS. The historical pattern of DSN access (in most shops) is write/read once and fageddaboudit. HTH, snip Well it's not a performance issue I'm trying to resolve. It's simply having the volumes so fragmented that users sometimes have a hard time finding the amount of space they need in 16 extents. /snip On Thu, Mar 4, 2010 at 1:30 PM, McKown, John john.mck...@healthmarkets.comwrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: Thursday, March 04, 2010 12:23 PM To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Hum, we don't even bother. We have set things up so that almost all our datasets are multivolume, via the DATACLAS. And by using DVC (Dynamic Volume Count) and so on. The DASD is so fast any more that we don't think it is worth the time to do defrags on volumes. Oh, and we try to keep a fairly good amount of head room in the Storage Groups as well. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: Defrag
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, March 04, 2010 1:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Steve, That's not exactly correct. It's 16 extents for 59 volumes and then you're done. John's answer is the solution for your problem. ACC and STOP-X37 users have known this for 30 years. From Using Data Sets: Many types of data sets are limited to 65535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail. Data sets that are not limited to 65535 total tracks allocated on any one volume are: * Large format sequential * Extended-format sequential * UNIX files * PDSE * VSAM Maximum Number of Volumes PDS and PDSE data sets are limited to one volume. All other DASD data sets are limited to 59 volumes. A data set on a VIO simulated device is limited to 65 535 tracks and is limited to one volume. Tape data sets are limited to 255 volumes. A multivolume direct (BDAM) data set is limited to 255 extents across all volumes. The system does not enforce this limit when creating the data set but does enforce it when you open the data set by using the BDAM. Maximum VSAM Data Set Size A VSAM data set is limited to 4 GB across all volumes unless Extended Addressability is specified in the SMS data class definition. System requirements restrict the number of volumes that can be used for one data set to 59. Using extended addressability, the size limit for a VSAM data set is determined by either: * Control interval size multiplied by 4 GB * The volume size multiplied by 59. Primary and Secondary Space Allocation without the Guaranteed Space Attribute . . . * A sequential data set can have 16 extents on each volume. * An extended-format sequential data set can have 123 extents per volume. * A PDS can have 16 extents. * A direct data set can have 16 extents on each volume. * A non-system-managed VSAM data set can have up to 255 extents per component. System-managed VSAM data sets can have this limit removed if the associated data class has extent constraint removal specified. * A system-managed VSAM data set can have up to 255 extents per stripe. This limit can be removed if the associated data class has extent constraint removal specified. * A PDSE can have 123 extents. * An HFS data set can have 123 extents on each volume. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * z/OS application programmer training + Instructor-led on-site classroom based classes + Course materials licensing + Remote contact training + Roadshows + Course development -- 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
Re: Defrag
Allowing growth to span volumes may be a good thing, but don't forget that that may fry your backup/recovery/DR strategy. Not if you are aware of spanned datasets and do your homework. We've done it for years. - 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
Re: Defrag
True, the window for corruption may be somewhat smaller, it still exists. So, what you're saying is that you'd better be able to handle the kind of datasets you're allowing to be allocated. - 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
Re: Defrag
Right. Not only be ready, but include extra testing at your next DR exercise just to be sure. I suppose there are various ways to deal with the issue, but first step is awareness. Striping and multi volume extents can make a full volume dump worse than a waste of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 4:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag True, the window for corruption may be somewhat smaller, it still exists. So, what you're saying is that you'd better be able to handle the kind of datasets you're allowing to be allocated. - Too busy driving to stop for gas! NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Defrag
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
Re: Defrag
Ted, Did you miss the word scheduled. Your having a different conversation. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 12:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag I agree wholeheartedly! I don't. It's a tool. Use it when necessary. Out of the 78TB I have, I have only one volume that ever needs to be defragged (every couple months). You're fortunate. Not all of us have the luxury. Don't get me wrong. Defrag, as evil as it may be, is still a valid tool. Don't do unnatural acts just to avoid it. And, ad nauseum, as I said before, don't just defrag for its own sake. That's what the fragmentation index is for. Again, think of it as an insurance policy. - 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
Re: Defrag
Did you miss the word scheduled. No, I didn't. Your having a different conversation. What you missed, or so it seems, is frag index. Besides, I can't do test during non-test times and prod during non-prod times without scheduling. What I said was that the index reduces the impact. I never said ad hoc. Or, is somebody putting words in my mouth, again? - 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
Re: Defrag
Then use consistency groups. You don't need them for DB2 though - with FRBACKUP, and since DB2 is 99% of my data, I'm good. I backup 20TB of production data every night to tape, no big deal. The point is there are plenty of tools available - multi-volume datasets are no big deal, you have similar problems even if the datasets aren't multi-volume. Hal Merritt hmerr...@jackhenry.com 03/04/10 4:17 PM No, actually, Flashcopy is still a PIT volume copy unless you are using consistency groups. True, the window for corruption may be somewhat smaller, it still exists. BTDT. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Thursday, March 04, 2010 3:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Defrag Easy, use FlashCopy (or equivalent). Hal Merritt hmerr...@jackhenry.com 3/4/2010 3:39 PM Allowing growth to span volumes may be a good thing, but don't forget that that may fry your backup/recovery/DR strategy. Many use full volume dump/restore as a foundation. Unless -all- of the volumes are dumped at a single point of consistency (POC), then you'll have corrupted datasets. With the size of today's DASD farms, getting a window wide enough to get that POC is quite the challenge. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: Defrag
Ted, No mate, you put your own words in your own mouth. Ron: I hate scheduled Defrags Scott: I agree wholeheartedly Ted: I don't. It's a tool. Use it when necessary. So you agree with scheduled defrags, but only when necessary. Ted: (Later) Don't do unnatural acts just to avoid it. Who mentioned unnatural acts? Not me. Ted: (much later) What I said was that the index reduces the impact Reduced impact is still impact. Defragging to avoid space problems is like walking everywhere in a zig zag pattern in case someone decides to shoot at you. Zig Zaggers will tell you they haven't been shot so it must work. I'll take primary space reduced to zero, followed by secondary extents reduced to fit free space extents, followed by an advol, followed by increasing the secondary space request after 16 extents, followed by more secondary space reduction, followed by more addvol, etc etc etc over a hope and pray defrag any day. Ron Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, March 04, 2010 5:02 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Defrag Did you miss the word scheduled. No, I didn't. Your having a different conversation. What you missed, or so it seems, is frag index. Besides, I can't do test during non-test times and prod during non-prod times without scheduling. What I said was that the index reduces the impact. I never said ad hoc. Or, is somebody putting words in my mouth, again? - 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
Re: Defrag
So you agree with scheduled defrags, but only when necessary. Schedule always. Defrag when necessary. In other words, if the frag index doesn't require a defrag, don't do it. But, let the programme figure it out. I see no problem with running a defrag every half-hour, as extreme as that may sound, if the index says DON'T. That's all that I meant. Nothing more, nothing less. The jobs are scheduled. The action depends. As I said, the first couple of times may be I/O intense,. The rest, probably not. There is a difference between scheduling a job, and the job actually doing something. If that wasn't clear, I'm sorry. As I've said, it's an insurance policy, especially when you're tight on space. - 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
Re: Defrag
-- From: Thompson, Steve Subject: Re: Defrag AFAIK, you are limited to 16 extents on a volume (NON-VSAM, PDS, DAM, etc.). If you are allowed (or can) do multi-volume, then yes, you get 16 [max] per volume for 59 volumes. Reclaiming space in the VTOC: If I can get all my space consolidated to just the DSCB #1, then all the other DSCBs (model 3s) become available, giving space for more allocations in the VTOC. If I remember correctly, there can be up to 4 Model 3 DSCBs to get you to 16 extents (for a data set) -- (non-VSAM, PDS, DAM, PS, etc.). Otherwise, once you have used up all the DSCBs in the VTOC, you can't allocate anything more, or even get a secondary extent on that volume. So defragging does recover space for a VTOC. Regards, Steve Thompson Am I showing my age? Is there still a restriction that the primary allocation must be within 5 extents? If the volumes are so fragmented that the primary allocation will not fit into 5 (or less) extents then the allocation used to fail. Has this changed with SMS? DanD -- 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
Re: Defrag
From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Thu, March 4, 2010 2:14:52 PM Subject: Re: Defrag I agree wholeheartedly! I don't. It's a tool. Use it when necessary. Out of the 78TB I have, I have only one volume that ever needs to be defragged (every couple months). You're fortunate. Not all of us have the luxury. Don't get me wrong. Defrag, as evil as it may be, is still a valid tool. Don't do unnatural acts just to avoid it. --SNIP-- A couple of places I worked were doing defrag's because we have always done it. Personally I think its move of a case of what kind of work the place does than anything. After doing research on a couple of companies I figured out that it really wasn't needed and stopped the defrags (which were being done on a weekly basis). Some small tuning of volumes and some ACS routines the defrags ended and were never run again as I took away the RACF privileges to the STC's. I think over the following year we had 1 space issue and it was a temporary condition. No more extra OT for the operators that was a benny that made the operators happy as we had to have two on at all times when the computer was powered up. Ed -- 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
Re: Defrag
Oh dear - I feel a bit guilty just trying to answer the original question, but anyway here's how we do it. We use the tools System Automation and MXI in the process, and what we do is at every JES2 shutdown (i.e. pre-IPL shutdown as far as intent goes, and our IPLs are monthly), we run an SA REXX exec which builds and issues a string of start commands for a defrag proc sub=mstr (by parsing MXI output, which includes storage group). The started proc builds the Defrag input stream per instance (more REXX) (in particular excludes a few datasets (TWS and JES2 related)). As these jobs run at the end of the shutdown process, most subsystems are down, so fewer datasets are in use, and a more through effect. Within a sysplex, of course the effect would be diluted - we have code to focus on image-specific volumes where we can. We have a number of images that are not in a sysplex (at least as volume sharing goes) which is where the process was originally implemented, and is most effective. It adds a little to shutdown time, but for us that is OK. The output is saved in datasets, although we have never had a problem with this process yet. The process is home-grown and REXX heavy I'm afraid. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Fax:(31)115-67-1762 Dow Benelux B.V.Mailto:dt...@dow.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Pace Sent: 04 March 2010 19:23 To: IBM-MAIN@bama.ua.edu Subject: Defrag Each day I run a Compress, Release, and Defrag on each volume in my SMS DASD Storage group. Some of the volumes still remain pretty fragmented. Is there a way to defrag the Storage Group? -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
Re: DEFRAG CONSOLIDATE not working?
On Wed, 8 Aug 2007 11:53:39 -0400, Pinnacle [EMAIL PROTECTED] wrote: Running z/OS V1R8. I've found that when I use CONSOLIDATE on my DEFRAGs, the DEFRAG doesn't work. I had a run this morning where CONSOLIDATE actually increased the frag index, and then a subsequent DEFRAG without CONSOLIDATE dropped it considerably. From the DFDSS Administration Guide: Notes: 1. The process of combining data set extents can cause the freespace to be more fragmented than it was before the operation began. 2. Despite the fact that DFSMSdss performs freespace defragmentation following the consolidation of data set extents, there is a possibility that the fragmentation index may be higher following a defrag operation with CONSOLIDATE specified than before the operation began. Source: (Watch wrap) http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/dgt2u250/9.2? -- 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
