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