Joel, Why do you wait to the next day - when I want SMF data in a hurry I just read the SYS1.MANx directly. Waiting until the next day to read 1 million plus SMF records is a procedure problem and not a technical issue.
As far as the accuracy of VSAM statistics go, I concede that using SMF is no more accurate than using LISTCAT. The same job that abends without updating the statistics will also fail produce a type 64 records. I just happen to think it is simpler to read a type 64 record than it is to insert a LISTCAT before and after every job step that access a VSAM file. YMMV. There are two basic problems with VSAM statistics. One is that you may be missing frequency counts for inserts, splits, deletions, EXCP and whatever for anything that has a VSAM file open when the power fails, the system crashes, or the address itself fails for whatever reason. The counts for those jobs are gone forever. I really don't see how a verify could possibly correct that. How important these counters are to you really depends on what you are doing with them, but where I have worked it is common practice to start out any LISTC based analysis with a freshly reorged file, and discard anything that has been touched by a failure. The second problem is that there are counts such as number of records that can become invalid. For example, if I have a KSDS with 1000 records, and I have inserted 1500 more records when my CICS region abends, then my LISTCAT will still show 1000 records. If subsequent processing then deletes 1001 records then my LISTCAT will be negative 1 record, while the actual count is 1499. If Verify is to rectify this statistic then it is going to have to read the whole KSDS from front to back and count the records. And the logic to actually figure out how the number of CI and CA splits that have occurred in prior Opens really escapes me. Calculating the difference for various statistics from a LISTCAT before and after a job step is a perfectly valid and simple way to measure VSAM activity for that open. Comparing before and after statistics in this way is unaffected by the accuracy of the statistics, because it is the difference between the two that you are measuring. But if you want to take a LISTCAT of a VSAM dataset that was defined 18 months ago and use those statistics for some sort meaningful tuning or capacity planning - well I for one fail to see how it would be useful whether the statistics were in error or not. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Joel C. Ewing > Sent: Saturday, 2 July 2005 3:50 PM > To: [email protected] > Subject: Re: IBM VSAM Statistics are often Bogus > > Ask yourself which is easier and faster in a case where one has reason > to suspect a VSAM usage problem: > (1) running LISTCAT, running program, running LISTCAT; > or > (2) running program, waiting until following day when offloaded SMF > records become generally available, running or requesting a run of a > batch program to read through 1M+ SMF records to possibly locate > relevant statistics? > > The "simplest" approach is frequently "better". > > The fallacy of John's casino analogy is that the underreporting of VSAM > statistics is not caused by unpredictable and unknown actions of > individuals, but by specific understood system events which are mostly > observable (ABEND or cancellation of address spaces) or associated with > the running of specific programs. You may not know exactly what was > lost, but generally can determine when the losses occurred. There are > many useful cases where one can be 100% sure that you have an interval > in which no statistics have been lost, and can therefore accurately > assess the number of additional EXCP's, CI/CA splits, records > fetched/added/deleted, etc. resulting from applications run in that > interval. > > As with many statistics related to MVS, one has to understand what they > mean and their limitations in order to use them intelligently. I don't > accept that it makes sense to eliminate LISTCAT VSAM statistics just > because some users don't understand the limitations. Flagging the > statistics as incomplete or questionable ought to be sufficient to warn > neophyte users that there may be something about the values they don't > understand - hopefully prompting them to research and understand the > limitations. > > > ---------------------------------------------------------------------- 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
