Re: service all status ptf
That is excellent information, many thanks for the education. I am still seeing the problem even though maint has both 190 and 19E linked RO. I took Alan's advice and opened a ticket. It's not yet resolved, but the y think it involves a product DMS/CMS. I don't know what the fix will be b ut I will update this thread with the outcome.
Re: service all status ptf
That sounds a tad odd to me. There's nothing (after installation) in DMS/CMS that requires R/W access to any of the CMS system disks. DMS/CMS is/was a great little lightweight 3270 panel application builder/manager that was 'way easier to use than ISPF, especially with Rexx. I think it would be fun to reverse-engineer it to use XEDIT macros and eliminating its binaries, but there are so many things like that on my bucket-list... :-/ -Chip- On 6/1/11 10:38 Steve Harman said: That is excellent information, many thanks for the education. I am still seeing the problem even though maint has both 190 and 19E linked RO. I took Alan's advice and opened a ticket. It's not yet resolved, but the y think it involves a product DMS/CMS. I don't know what the fix will be b ut I will update this thread with the outcome.
Re: service all status ptf
Steve, Update MAINT's directory entry so that the MAINT 0190, and MAINT 019E mdisk links are changed to: RR (you probably have them as MR right now). Unless maintenance is being applied, there is no reason (and many disadvantages, one which you just experienced) to anyone having a write link to MAINT's 190 and 19E disks, even MAINT itself. 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 12:29 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject service all status ptf I've noticed lately that if I use MAINT to query the status of a PTF using the SERVICE ALL STATUS UMx command that it causes this problem for users who then logon: DMSACC724I 19E replaces Y (19E) DMSACP723I Y (19E) R/O z/VM V5.4.02011-05-26 08:00 DMSWSP100W Shared S-STAT not available DMSWSP100W Shared Y-STAT not available Rebuilding the CMS NSS fixes the error, but if I then use maint to query another PTF status, it breaks again. Nearly all of the USER DIRECT entries are set up to IPL CMS (instead of IPL 190). Have I gotten something out of whack? I've applied RSU and PTF's with no problem, PUT2PROD no problem. It's more of an annoyance than anything and I'm sure it's something I've inadvertently done or not done but I don't know what. Thanks for any suggestions 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.
Re: service all status ptf
That helped, thanks. I still have the problem if the PTF I query is not found. I only lose th e 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: VMFSRV1226IRECEIVED 05/26/11 11:55:07 VMFSRV1226IAPPLIED 05/26/11 11:55:09 VMFSRV1226IBUILT 05/26/11 11:55:57 VMFSRV1226IPUT2PROD 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 BL K TOTAL MNT191 191 A R/W 175 3390 4096 125940-03 30560 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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 BY11 USERS DASD 0492 LINKED R/W; R/O BY11 USERS DASD 05E7 LINKED R/W; R/O BY30 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 BL K TOTAL MNT191 191 A R/W 175 3390 4096 125941-03 30559 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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.02011-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
Re: service all status ptf
On Thursday, 05/26/2011 at 02:27 EDT, Steve Harman steve.har...@mutualofomaha.com wrote: That helped, thanks. I still have the problem if the PTF I query is not found. I only lose th e Y-Stat (19E). If the PTF is found, there is no problem. You need to open a PMR. SERVICE does not (is not supposed to) touch your production disks (190, 19E). And when the STATUS keyword is specified, it doesn't actually service anything. The ALL or compname simply affects the scope of the search. It is possible that you have an exec laying around that is named the same as some VMSES/E sub-program which is getting control and messing with those disks. In any case, call it in and let the Support Center help you figure it out. That's what you pay them for. :-) Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: service all status ptf
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: VMFSRV1226IRECEIVED 05/26/11 11:55:07 VMFSRV1226IAPPLIED 05/26/11 11:55:09 VMFSRV1226IBUILT 05/26/11 11:55:57 VMFSRV1226IPUT2PROD 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 125940-03 30560 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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 BY11 USERS DASD 0492 LINKED R/W; R/O BY11 USERS DASD 05E7 LINKED R/W; R/O BY30 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 125941-03 30559 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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.02011-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
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 rc0 then say 'Could not check status of HELP saved segment' else do 'ACCESS 19D Z (SAVEONLY' if rc0 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: VMFSRV1226IRECEIVED 05/26/11 11:55:07 VMFSRV1226IAPPLIED 05/26/11 11:55:09 VMFSRV1226IBUILT 05/26/11 11:55:57 VMFSRV1226IPUT2PROD 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 125940-03 30560 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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 BY11 USERS DASD 0492 LINKED R/W; R/O BY11 USERS DASD 05E7 LINKED R/W; R/O BY30 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 125941-03 30559 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 3390 4096 407 2008-43 2672 4680 MNT190 190 S R/O 100 3390 4096 699
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 rc0 then say 'Could not check status of HELP saved segment' else do 'ACCESS 19D Z (SAVEONLY' if rc0 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: VMFSRV1226IRECEIVED 05/26/11 11:55:07 VMFSRV1226IAPPLIED 05/26/11 11:55:09 VMFSRV1226IBUILT 05/26/11 11:55:57 VMFSRV1226IPUT2PROD 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 125940-03 30560 31500 MNT5E5 5E5 B R/W 9 3390 4096 132 1294-80 326 1620 MNT2CC 2CC C R/W 5 3390 4096 89656-73 244900 MNT51D 51D D R/W26 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 BY11 USERS
Re: service all status ptf
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 rc0 then say 'Could not check status of HELP saved segment' else do 'ACCESS 19D Z (SAVEONLY' if rc0 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: VMFSRV1226IRECEIVED 05/26/11 11:55:07 VMFSRV1226IAPPLIED 05/26/11 11:55:09 VMFSRV1226IBUILT 05/26/11 11:55:57 VMFSRV1226IPUT2PROD 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