Having splits is rarely a performance hit, but taking one is. If you know the data, you can specify the FREESPACE so as to take the splits at allocation when the application is not impacted.
VSAM Reorgs are often a stop-gap measure to avoid spending time and energy to perform tuning. Good allocation attribute choices and tuning are key to avoid and reclaim 'dead' CAs and 'dead' CIs should they become too numerous. Meaning the file may need to be better tuned to avoid run away growth. Volume Defrags are also mostly a waste of valuable resources. We haven't run a defrag in over 10 years in a shop with over 150TB. Only the Systems, programming staff will on a vary rare occasion run defrag against an IPL volume being prepared for roll out. Space abends are nearly a thing of the past with carefully defined and assigned dataclasses that take advantage of (Space Constraint Relief) SCR, DVC (Dynamic Volume Count) or the standard volume count, and ECR (extent constraint removal). Also, strategic use of Extended Format, Extended Addressability, and General and Tailored Compaction will be of huge benefit in this arena. Separating data into separate storage groups based on data type and how the data should be managed will also contribute greatly in the reduction of space related abends. For instance, you would not want DB2 linear files in the same storage group with Datacom databases because Datacom needs large extents, but DBAs would have difficulty finding large enough chunks of space because the DB2 linear files would have extents all over the pool. Running interval migration on a storage that has only has archive logs directed to it will also help prevent space abends. Of course, management has a key roll to play if strategically defined and assigned. But you have to be willing to drive these changes and overcome the hurdles; very few are willing. There is no shortage of folks out there needing a little education, sometimes this means me. It took 6 years for me, a lowly MVS Storage Technical, to convince and push to finally get our development environment merged into a single sysplex from what was a mult-sysplex environment with 3 sysplexes sharing the same DASD. Finally, we can take advantage of the sysplex exploiters. So, don't give up. Now, my next challenge is to preach ILFs under z/10. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kelman, Tom Sent: Thursday, May 22, 2008 12:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 80-Column Minds (Was: SMP/E question) > Posted by Ted MacNEIL > > My point is, that today's application programmers still don't know the > simple things, such as: > o extents are not a bad thing any more o CA/CI splits (especially CI > splits) don't have as big an impact as they > used to. > o allocating on Cylinder vs Track boundaries don't have a major impact > anymore, due to define extent o they still don't understand block > sizes > Ted, It's not only the application programmers. My storage admiins get all hot and bothered if datasets go into extents or VSAM datasets have the least number of CA/CI splits. I've tried to convince them that it's not big deal but they don't believe me. Tom Kelman ************************************************************************ ***** If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. ************************************************************************ ***** ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
