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.
