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 might not require R/W access, but if the PPF specifies a link mode of MR, that would do it. I have seen a PPF for another product that had an unnecessary MR link to the S-disk. It was corrected by the vendor. Dennis O'Brien "If man does find the solution for world peace it will be the most revolutionary reversal of his record we have ever known." -- General George C. Marshall -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
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
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
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" > > Sent by: "The IBM z/VM Operating System" > 05/26/2011 03:13 PM > Please respond to > "The IBM z/VM Operating System" > > > > 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 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 > > Sent by: "The IBM z/VM Operating System" > 05/26/2011 01:26 PM > Please respond to > "The IBM z/VM Operating System" > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > Re: service all status ptf > > > > > > > That helped, thanks. > > I still have the problem if the PTF I
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" Sent by: "The IBM z/VM Operating System" 05/26/2011 03:13 PM Please respond to "The IBM z/VM Operating System" 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 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 Sent by: "The IBM z/VM Operating System" 05/26/2011 01:26 PM Please respond to "The IBM z/VM Operating System" 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 SERV
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 > 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 > > Sent by: "The IBM z/VM Operating System" > 05/26/2011 01:26 PM > Please respond to > "The IBM z/VM Operating System" > > > > 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
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 Sent by: "The IBM z/VM Operating System" 05/26/2011 01:26 PM Please respond to "The IBM z/VM Operating System" 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 me
Re: service all status ptf
On Thursday, 05/26/2011 at 02:27 EDT, Steve Harman 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 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
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
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 Sent by: "The IBM z/VM Operating System" 05/26/2011 12:29 PM Please respond to "The IBM z/VM Operating System" 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.
service all status ptf
I've noticed lately that if I use MAINT to query the status of a PTF usin g 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
