Re: service all status ptf

2011-06-01 Thread Steve Harman
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

2011-06-01 Thread Chip Davis
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

2011-05-26 Thread Mike Walter
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

2011-05-26 Thread Steve Harman
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

2011-05-26 Thread Alan Altmark
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

2011-05-26 Thread 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 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

2011-05-26 Thread Kris Buelens
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

2011-05-26 Thread Mike Walter
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

2011-05-26 Thread Schuh, Richard
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