We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources.
Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of A. Harry Williams Sent: Tuesday, August 18, 2009 7:08 PM To: [email protected] Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: >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. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T <compress the file> COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw > >-----Original Message----- >From: The IBM z/VM Operating System [mailto:[email protected]] On >Behalf Of Dale R. Smith >Sent: Monday, August 17, 2009 2:55 PM >To: [email protected] >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 <[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 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. >>======================== 3D= >========================= 3D= >=======================
