I couldn't let the implicit recommendation pass without some challenge.
Based on our many-years experience with VSAM (starting back in 1977 and still on-going), I would disagree with that 'smarter' person for some types of situations. We have several large files that, because of their key structure and multi-year contents, do get relatively uniform updates. We have routinely used non-zero freespace values on these files quite successfully (starting back in the late '70s). If we had adopted this person's (0 0) recommendation, the files would have at least doubled in total cylinders within a few months, and we often have been able to run over a year without reorg and with less total space. Proper choices require some knowledge of the structure and update-pattern for a file, not a blindly stated "one size fits all" ROT. David Mueller | Systems Programmer | DMS/EITS Phone: 850-414-9134 (Rm 107 SRC) | Fax: 850-921-8343 E-mail: [EMAIL PROTECTED] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas H Puddicombe Sent: Tuesday, January 10, 2006 10:44 AM To: [email protected] Subject: Re: VSAM freespace 0 A long while ago, someone much smarter than I said that specifying freespace as anything other than (0 0) was a waste of otherwise good DASD space along with the time required to format it, back it up, restore it, reorg it, etc. Leaving freespace evenly distributed through the dataset implies that inserts will be evenly distributed through the dataset. I did some looking and discovered that keys tend to force inserts to cluster. Specifying FREESPACE(0 0) meant that initial inserts (after dataset load and/or reorg) resulted in some split activity, but the act of splitting caused VSAM to put freespace right in the neighborhood of where freespace was needed. ---------------------------------------------------------------------- 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
