Dale, The MACLIB is maintained by a service machine which copies it to a large TEMP disk, compresses it, then copies it back to the prod disk.
The copy FROM the prod disk always seems to be ok. The copy of the compressed MACLIB back to the prod disk seems to be where it can get hit. Users can access this old app anytime they want - we can break the links, which would cause them some grief, but a link could be established during this process. A related question is whether an ISPF/PDF-based application can be placed in a "read-only" mode. When this old app is retired, users are still going to want to reference it for historical reasons. We don't want them to be able to update it in any way at that point. If a read-only mode is possible, that could solve the compress issue as well. -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how "dead" things like to= stick around, like mainframes, VM, COBOL, etc. :-)> ). -- Dale R. Smith "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance." = - Kurt Vonnegut = = On Fri, 14 Aug 2009 12:32:49 -0500, 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 >ou= r >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 >o= n >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. >========================= ========================== =======================
