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.
>========================
=========================
=======================
