On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellyn<mllew...@visa.com> wrote: > Any veteran ISPF/PDF SMEs out there? > > We have an ancient and soon-to-be decommissioned ISPF/PDF application that > 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 activity > 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?
Could the machine doing the compress LINK the disk eXclusive during the update?
