Also the 19D disk has a shared segment for the FSTs.  But, unlike fro 190
and 19E, there is no message telling you the saved segment is no longer used
as the FST's have been updated.
So, beside changing MAINT's directory to get 19D linked in RR, I had
something like this in my and MAINT's PROFILE EXEC:
'SEGMENT RESERVE HELP'
if rc<>0 then say 'Could not check status of HELP saved segment'
else do
   'ACCESS 19D Z (SAVEONLY'
   if rc<>0 then say 'You should rebuild the HELP segment'
end

2011/5/26 Mike Walter <mike.wal...@aonhewitt.com>

> Steve,
>
> When you: ipl 190 parm savesys cms
> the active CMS FSTs (File Status Table) for the 190 and 19E disks are
> saved (for the 190 disk) as the S-STAT, and (for the 19E disk) as the
> Y-STAT.
> The FST contains a pointers to the location of every file on that minidisk
> (if you're from z/OS, think a minidisk's FST as a VTOC).  When you
> SAVECMS, the FST is saved into the S-STAT and Y-STAT, which are included
> in the CMS "Named Saved System" (NSS).
>
> Subsequently, any user executing IPL CMS benefits by having access to the
> SHARED saved FSTs for the 190 disk (S-STAT) and 19E (Y-STATS) files
> without having to load those FSTs into their virtual machine's memory. The
> overall z/VM system benefits by all users sharing the same memory
> containing those two FSTs (instead of every user having their own copy);
> that savings used to be more important in days of yore when a typical VM
> system had hundreds or thousands of CMS users (and lower system physical
> max memory sizes).
>
> Key point (finally!):
> If the FST on the 190 or 19E disk is altered in any way, it will no longer
> match the one saved by SAVESYS.  Hence the messages you received are
> issued when "CMS" is IPLed.  So... what alters the FST?  Well... anything
> that writes to the disk.  When you have a disk LINKED R/W, and ACCESS it,
> its FST is loaded into your VM's memory.  When the CMS command 'RELEASE'
> is issued against that minidisk, the FST is re-written to disk (even if no
> files were changed; the last-accessed date is updated on the disk
> regardless).  Care to bet on whether one or more of the VMSES/E commands
> ACCESSes and RELEASEs the 190 and/or 19E disks (even if not as filemode S
> or Y) in the process of executing your command?    :-)   The mdisk FST
> update cannot happen when the disk is accessed R/O.
>
>
> So.. before you re-save CMS again:
> - Change MAINT's directory entry for 190 and 19E to "RR" links
>  (changing the directory has no effect on MAINT current LINK modes until
> MAINT is logged off/logged on again).
> - From MAINT, issue 'CP LINK * 190 190 RR' and 'CP LINK * 19E 19E RR'
> (thus eliminating the need to logoff/logon)
> - repeat your process to re-save CMS.
>
> Mike Walter
> Aon Corporation
> The opinions expressed herein are mine alone, not my employer's.
>
>
>
> Steve Harman <steve.har...@mutualofomaha.com>
>
> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
> 05/26/2011 01:26 PM
> Please respond to
> "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
>
>
>
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
>
> Subject
> Re: service all status ptf
>
>
>
>
>
>
> That helped, thanks.
>
> I still have the problem if the PTF I query is not found.  I only lose the
>
> Y-Stat (19E).  If the PTF is found, there is no problem.
>
> service all status UM33290VMFSRV2760I SERVICE processing started
> VMFSRV1226I CP (5VMCPR40%CP) PTF UM33290
> status:
> VMFSRV1226I    RECEIVED  05/26/11
> 11:55:07
> VMFSRV1226I    APPLIED   05/26/11
> 11:55:09
> VMFSRV1226I    BUILT     05/26/11
> 11:55:57
> VMFSRV1226I    PUT2PROD  05/26/11
> 11:58:04
> VMFSRV2760I SERVICE processing completed
> successfully
> Ready; T=0.81/0.86
> 13:16:24
> q disk
> LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT  BLK
>
> TOTAL
> MNT191 191  A   R/W   175 3390 4096      125        940-03      30560
> 31500
> MNT5E5 5E5  B   R/W     9 3390 4096      132       1294-80
> 326       1620
> MNT2CC 2CC  C   R/W     5 3390 4096       89        656-73
> 244        900
> MNT51D 51D  D   R/W    26 3390 4096      407       2008-43
> 2672       4680
> MNT190 190  S   R/O   100 3390 4096      699      15274-85       2726
> 18000
> MNT19E 19E  Y/S R/O   250 3390 4096     1839      41428-92       3572
> 4500
>
> User logs 0n - no problems.  But,
>
> service all status um32995
> VMFSRV2760I SERVICE processing
> started
> DASD 0491 LINKED R/W; R/O BY    11
> USERS
> DASD 0492 LINKED R/W; R/O BY    11
> USERS
> DASD 05E7 LINKED R/W; R/O BY    30
> USERS
> VMFSRV1227I UM32995 is not received or
> applied
> VMFSRV2760I SERVICE processing completed
> successfully
> Ready; T=6.17/6.56
> 13:17:52
> q
> disk
>
> LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) BLKS LEFT  BLK
>
> TOTAL
> MNT191 191  A   R/W   175 3390 4096      125        941-03      30559
> 31500
> MNT5E5 5E5  B   R/W     9 3390 4096      132       1294-80
> 326       1620
> MNT2CC 2CC  C   R/W     5 3390 4096       89        656-73
> 244        900
> MNT51D 51D  D   R/W    26 3390 4096      407       2008-43
> 2672       4680
> MNT190 190  S   R/O   100 3390 4096      699      15274-85       2726
> 18000
>
> Maint has lost the Y disk, and a subsequent user logon gets this error:
>
> DMSACC724I 19E replaces Y (19E)
> DMSACP723I Y (19E) R/O
> z/VM V5.4.0    2011-05-26 08:00
> DMSWSP100W Shared Y-STAT not available
>
> I use this to rebuild CMS:
> acc 193 r
> sampnss cms
> ipl 190 parm savesys cms
>
>
>
>
>
>
> The information contained in this e-mail and any accompanying documents may
> contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents of
> this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by e-mail.
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to