I empathize with you on this one, Mike. Whenever I am asked a question that is 
answered in the HELP files, my usual answer is the HELP command to enter.  

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter
> Sent: Thursday, May 26, 2011 2:05 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: service all status ptf
> 
> Entirely true, Kris.
> 
> But with our dearth of CMS users (no more than 25 at any 
> point in time), I just deleted the HELP saved segment and 
> stopped saving it.  There's not much in FST memory savings 
> for so few users of the HELP disk, and so few that ever even 
> enter the HELP command.  I do track monthly use of the HELP 
> command, and 98% if its use is us two VM sysprogs.  We can 
> suffer the incredible delay to read the MAINT 19D FST into 
> our memory.  (tongue firmly in cheek)
> 
> Mike
> 
> 
> 
> "Kris Buelens" <kris.buel...@gmail.com> 
> 
> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
> 05/26/2011 03:13 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
> 
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 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. 
> 

Reply via email to