Mike Baker wrote:
Hi Ron,
Thanks for your excellent explanation. (PS: I attended one of your VSAM
courses in Wellington, New Zealand, back in the early 90s).
Just to elaborate on the "lots of redundant datasets" and HLQ's... for
example, we have a HLQ called "BUS", and approx 9000 BUS.* datasets of
which about 95% of them have been migrated to tape. The remaining 5% which
are still being used are because people have been to lazy(?) to change a
few remaining jobs to use a different HLQ. We could safely change these 5%
remaining jobs, and then delete all BUS.* datasets.
However, seeing as this has not been done, would this have much of an
overhead performance impact on the Catalog / CAS??
Could you please elaborate on this finer detail?
Thanks very much.
...
That the datasets have migrated to tape doesn't mean they are either
obsolete or "redundant", just that they haven't been accessed recently.
This is still true even if all your "BUS.**" datasets are migrated to
tape. They may still be needed for some types of recovery, as part of a
historical archive, or possibly to satisfy legal requirements for
retention of corporate data. Someone with knowledge of the application
area will have to judge whether these considerations apply and what is
eligible for permanent deletion and when.
If you can get the application people to agree that datasets not
accessed since date "x" may be deleted, then there is no reason those
datasets couldn't be deleted today - no need to wait on the remaining
datasets. ISMF can be used to generate a list of datasets with a
last-referenced date prior to "x", and then that list could be massaged
by various methods into a sequence of DELete commands for those datasets
and executed. Better yet, if possible make all future datasets
SMS-managed and assign an appropriate SMS management class so future
deletions occur automatically after an agreed-upon interval of non
reference. I would be primarily motivated by the general principal that
leaving truly useless things around is bad idea, but cleaning things up
might also save on some resources, such as the number of migration tapes
in use.
Catalog overhead would not be that much of an issue, unless people
frequently display and hunt through lists of all BUS.** datasets rather
than specifying a specific-enough search argument to restrict
consideration to the actual datasets of interest.
Another possible issue is that these migrated datasets may be mixed
among datasets that do get scratched on your migration tapes. If that
is the case, you could be wasting resources copying these migrated BUS
datasets repeatedly as migration tapes are consolidated through recycle
activity.
That having been said, I have seen cases where it was judged that the
overhead costs of keeping possibly-useless migrated datasets around was
less than the cost of diverting scarce resources to accurately determine
whether the datasets were really needed.
--
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
