Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application tha t makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS.
This maclib can grow by millions of records per day, due to heavy activit y and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc.
