Back to first principles:
1) Can you replicate the *failure* so you'll know whether you've fixed
it or made it worse?
2) It's important to understand how the guests detect updates. If it's
via a handshake, can you simulate that?
I like Harry's almost-atomic update via COPY then RENAME. It wouldn
is week
with a bogus userid.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Alan Altmark
Sent: Wednesday, August 19, 2009 12:46 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
On Wednesday, 08/19/20
On Wednesday, 08/19/2009 at 02:36 EDT, "Llewellyn, Mark"
wrote:
> 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
> the
Any reason you can't change the LINK mode from MW to RR? As extra
insurance delete the Write and Multi-write passwords from the MDISK.
Less secure, but perhaps sufficient, would be changing the ACCESS command
to access the disk as an extention of another disk, thus making it R/O.
Even less el
sible via these local ISPF/PDF routines.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of A. Harry Williams
Sent: Tuesday, August 18, 2009 7:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
On Tue, 18 Au
k.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.
On Tue, Aug 18, 2009 at 1:24 PM, Llewellyn, Mark wrote:
> 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 MACLI
stem [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
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.
alf Of Les Koehler
Sent: Friday, August 14, 2009 8:34 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
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 IS
K.EDU
> Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
>
> 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 ta
A straw at which I cannot grasp.
Regards,
Richard Schuh
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of P S
> Sent: Friday, August 14, 2009 6:40 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: I
ject: Re: ISPF/PDF CMS MACLIB - Maintenance
>
> Schuh, Richard wrote:
> > The developers of the application chose to have the data
> maintained in a single, ever-increasing, highly used,
> frequently updated ISPF library, with no maintenance
> routines, and no goo
something else), would also be vulnerable.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of P S
Sent: Friday, August 14, 2009 3:50 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF/PDF CMS MACLIB - Maintenan
On Fri, Aug 14, 2009 at 7:20 PM, 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
> knowled
Schuh, Richard wrote:
The developers of the application chose to have the data maintained in a
single, ever-increasing, highly used, frequently updated ISPF library, with no
maintenance routines, and no good way to identify obsolete members. The
application was already firmly entrenched when M
hard Schuh
> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of P S
> Sent: Friday, August 14, 2009 3:50 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
>
> On Fri, Aug 14, 2
On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Mark 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
achine, which runs mysterious "ISPF Services."
---Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of P S
Sent: Friday, August 14, 2009 12:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri,
M z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of P S
> Sent: Friday, August 14, 2009 12:32 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
>
> On Fri, Aug 14, 2009 at 2:52 PM, Schuh,
> Richard wrote:
> > Unfortun
On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richard wrote:
> 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 applicati
age-
> From: The IBM z/VM Operating System
> [mailto:ib...@listserv.uark.edu] On Behalf Of P S
> Sent: Friday, August 14, 2009 10:48 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: ISPF/PDF CMS MACLIB - Maintenance
>
> On Fri, Aug 14, 2009 at 1:32 PM, Mark
> Llewellyn wrot
On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellyn 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.
>
>
Any veteran ISPF/PDF SMEs out there?
We have an ancient and soon-to-be decommissioned ISPF/PDF application tha
t
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 he
24 matches
Mail list logo
