Joel, > > If those 20 minutes of stats show enough CI splits to justify a > reorganize of the file, it doesn't matter that this only represents 20 > minutes of activity. If the CI-split count is above your reorg > threshold, it also doesn't matter if you lost 15 hours of CI-split > counts because of a CICS crash, a reorg is still justified. You may be > late with a decision to reorganize, but better late than never. With no > stats at all, an automated process has no basis for choosing whether to > reorganize or not, and arbitrarily choosing to reorganize could be a bad > choice for a large, rarely-updated VSAM file - especially if doing an > unnecessary reorganize delays the availability of a critical online > application. > > > I come from the Ron F. school of VSAM tuning... Highly likely that the high split count in that last 20 minutes of batch has happened because the dataset was reorged (by the restore). Refer to Ron's posts and books for more info.
> LISTCAT stats have been around for at least several decades, maybe since > the beginnings of OS/360. Automated maintenance procedures and > heuristic guidelines have been developed based on LISTCAT statistics and > we have become dependent on them, because you build tools based on what > is available, even if not perfect. Without LISTCAT stats, we would have > to expend resources to rethink and redesign a number of automated batch > processes that have been working reasonable well up to now (z/OS 1.4). > I've used LISTCAT to tune VSAM CI and freespace, but I put the listcat in a step before and after the updates step. It is really much easier to use type 64 SMF records. > ... > > -- > Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED] > ---------------------------------------------------------------------- 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
