Explain the problem to management and let them decide if
they want to Bet The Business on the current exposure. If
not, let them announce to everyone when ISPF will be
unavailable and FORCE all the users and take the ISPF disk
away by whatever means are available (I'm retired and was
not a SysProg, just a developer!)
Les
Schuh, Richard wrote:
Considering that it is ISPF, I would be worried that taking down the SVM would simply
kill all of the protective mechanisms that ISPF employs to keep the users from trashing
the file because of the MW links. In the absence of knowledge about its purpose, I would
not suggest blindly taking it down. I really do not like to play the game of "My
gun. My bullet. My body part." I might be able to get along ok if I only hit a
little toe, but with my hands, parts higher up, such as a knee (bet you thought I was
referring to something else), would also be vulnerable.
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 3:50 PM
To: [email protected]
Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn,
Mark<[email protected]> wrote:
The MACLIB is updated via PDF dialog table services, driven
by a number of older REXX EXECs. It contains hundreds of
members, which can be updated at any time, and new members
are added every day.
I'm unsure if ISPF/PDF "locks" a member, or a table row,
each time it's updated. Nevertheless, in order to compress
the maclib we'd like to completely halt any possible update
activity. Some sort of global ISPF command that I haven't
found yet, perhaps.
The application runs ISPF in the users' individual virtual
machines. ISPF does have a service machine, which runs
mysterious "ISPF Services."
Take down the ISPF machine?
