> BTW, one list member, Larry Crilley, mention "creeping key" and I was wondering if anyone else has heard about this.
George, The "Creeping key" - phenomenon comes up in a catalog when you have an application that constantly creates new dataset names containing either a sequence number or a date/timestamp (such as your application seems to do). As a new dataset gets cataloged, using a key higher than the previous ones, the record is written at the end of the chain of existing dataset names. Old datasets eventually expire and get deleted, leaving a deleted record somewhere in the catalog. What that means is that the catalog constantly grows, because each new dataset entry occupies new space within the catalog. "Holes" left within the catalog from previously deleted records hardly ever get reused. So, even if you have only a limited number of these datasets, the catalog grows and grows, using ever more space. A brief history lesson: This creepy phenomenon was first detected many years ago, when IBM introduced VSAM Usercatalogs. The VSAM usercatalog structure for GDGs (generation datasets) consisted of a GDG-base record and one physical GDG-entry record for each generation dataset (e.g.: ABC.DEF.G0001V00, ABC.DEF.G0002V00, etc.). As a '+1'-generation dataset was created, it was added after the '0'-generation record. The oldest generation record was deleted, if the GDG-limit was exceeded. Physically, within the catalog, the records looked like this (assuming a 2-generation limit): GDG-base-record, G0001V00, G0002V00 Adding a +1-generation: GDG-base-record, -deleted, G0002V00, G0003V00 Adding another +1-generation: GDG-base-record, -deleted, -deleted, G0003V00, G0004V00 And that's where the creepy part begins. Eventually, the CI used by these catalog records fills up, a CI-split is required and perhaps even a CA-split (and you know, what that means ...). These old VSAM Usercatalogs containing GDGs required constant care and frequent reorgs. (Well, IBM eventually solved this problem by inventing ICF Usercatalogs. Here GDG record structures are formatted differently and occupy a fixed amount of space that does not usually creep as each successive generation is added). Back to your application ... if it creates discreet dataset names containing timestamps or other constantly incremented sequence numbers, then you will encounter this problem and you will need to monitor and regularly reorg your catalog. The rate at which new datasets get created per day will determine the growth rate of your catalog and how frequent you will need to reorg. As far as I can see, the only way to minimize the impact of this application's behavior on other applications or users or even the entire system is to keep this application's datasets in a separate catalog. This allows a catalog reorg to be scheduled when it's convenient for the application, with little to no impact on others. HTH Regards, Ulrich Krueger ---------------------------------------------------------------------- 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
