Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[email protected]] On Behalf Of P S > Sent: Friday, August 14, 2009 10:48 AM > To: [email protected] > Subject: Re: ISPF/PDF CMS MACLIB - Maintenance > > On Fri, Aug 14, 2009 at 1:32 PM, Mark > Llewellyn<[email protected]> 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? >
