Re: zvm directions
On Thu, May 26, 2011 at 5:06 AM, Philip Tully tull...@optonline.net wrote: With all do respect: Contacting our IBM rep under NDA does not fit public road map I think the customers are letting IBM know, that they are not ready to relinquish control of this asset. It may not be the story IBM mgmt wants to hear but it is the one that is being told. I may no longer go onsite to customers on a regular basis, but when I was, I often needed access to the HMC and it was pretty consistent that there was significant access control for the HMC. Neither may be parts of IBM. At least two installations told me that IBM requires that the original HMC user/pw combinations remain in place for the (different) IBM support person to be able to support them. I suppose that when the customer was more persuasive they could convince their support person of something else. Some Large shops have a separate LAN for delicate stuff and implement access control with RSA gear. That includes a process to expire access when people change roles, etc. This is where you find their HMC as well the local consoles for the LPARs. You can't seriously tell them to move some of that back into the public LAN and do local password management again. Rob
Re: zvm directions
On Wednesday, 05/25/2011 at 11:07 EDT, Philip Tully tull...@optonline.net wrote: With all do respect: Contacting our IBM rep under NDA does not fit publc road map. I'm not trying to be contrary or anything, Phil, just practical. If your or anyone else feels they need more information about IBM's plans for the future than is publicly available (on pretty much any subject), there's a way to deal with that. I think the customers are letting IBM know, that they are not ready to relinquish control of this asset. It may not be the story IBM mgmt wants to hear but it is the one that is being told. I may no longer go onsite to customers on a regular basis, but when I was, I often needed access to the HMC and it was pretty consistent that there was significant access control for the HMC. No one disputes that there should be significant access control for the HMC. Hence my statements about improvements to HMC security management and the recommendation to put a firewall in front of it. You may even require some form of authentication at the firewall. And you certainly do NOT allow remote access into the HMC-SE LAN itself except when you have a remote HMC. And for those I would seriously consider a VPN-style connection into the HMC-SE LAN, even though: - All communication between an HMC and an SE is encrypted. This is managed via Domain Security. - All communication between a browser and the HMC is via HTTPS Over time, expect to see the HMC continue to expand its role as a management endpoint in your System z world. Naturally, this is an evolving story, so keep your 3270 emulator handy. 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
SHARE in Orlando and Golf at Disney
Hello All, This is an invitation to play golf for all the golfers on this list that are going to SHARE in Orlando. I am making a tee time for Sunday afternoon on one of the Disney courses. Let me know if you would like to play. My flight is scheduled to land in Orlando at 11:55am on Sunday and I need something to do. It will be August in Florida so it will be HOT. I'm from Texas so I'm use to the heat... just a warning. Also, I am a hacker. I have all the golf shots in my bag but sometimes I can't tell you which one I'm going to hit. I am planning on playing one afternoon during the week as well depending on my schedule at SHARE. All are welcome to join me. I have never played a Disney course so any suggestions are welcomed. I have posted this message on the CICS and z/VM lists. Thanks, Nick Harris, FLMI, CLU Lead Systems Programmer - Information Systems Texas Farm Bureau Insurance Companies P. O. Box 2689 Waco, TX. 76702-2689 Phone 254.751.2259 nhar...@txfb-ins.com CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.
Re: HMC security (was: zvm directions)
On Thursday, 05/26/2011 at 03:12 EDT, Rob van der Heij rvdh...@gmail.com wrote: Neither may be parts of IBM. At least two installations told me that IBM requires that the original HMC user/pw combinations remain in place for the (different) IBM support person to be able to support them. I suppose that when the customer was more persuasive they could convince their support person of something else. The bogosity index is extremeloy high on this one. Each person who accesses the HMC should be given their own ID. No sharing. Multiple CEs? Multiple IDs. Best Practice is to change all of the passwords to the default user IDs or delete them. Kind of like when you install RACF, the instructions tell you to remove authority from IBMUSER and REVOKE it. In fact, PCI requires you to change all vendor-supplied/default security-related settings, including passwords, encryption keys, and SNMP community strings. Some Large shops have a separate LAN for delicate stuff and implement access control with RSA gear. That includes a process to expire access when people change roles, etc. This is where you find their HMC as well the local consoles for the LPARs. You can't seriously tell them to move some of that back into the public LAN and do local password management again. Local password management? I'm not following you on this. My client has all 'normal' HMC IDs authenticated with the corporate directory server (Active Directory). Leave the HMC behind the RSA gear. It's not like general users of the operating systems are going to need HMC IDs. 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
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
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
VM Workshop Update
If you are part of the VM community or just a wanna-be VMer, you should visit the _www.vmworkshop.org_ (http://www.vmworkshop.org) web site and get registered for the upcoming VM Workshop. Several of your VM friends have been working hard to put this event together. This year's rendezvous will be at Ohio State University's Union in Columbus Ohio. For those of you new to the VM Workshops, all the funds coming into the event go towards the event ! ! We are currently pulling together topics for sessions and the interest level has been great. Register now and miss the rush ! ! That also goes for any organization wishing to sponsor the event. There are only 5 sponsorship slots left and there is only one(1) sponsorship level. Check the web site or send an email to _WorkshopVM@aol.com_ (mailto:worksho...@aol.com) .
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
Re: HMC security (was: zvm directions)
The bogosity index is extremeloy high on this one. But it's certainly a common one. I can think of at least a dozen sites that have heard this requirement from IBMers. I've always thought the proper solution to this was to add a badge reader to the HMC to allow IBMers to enable these ids only when they are physically present (and responsible for them). Each person who accesses the HMC should be given their own ID. No sharing. Multiple CEs? Multiple IDs. Best Practice is to change all of the passwords to the default user IDs or delete them. Kind of like when you install RACF, the instructions tell you to remove authority from IBMUSER and REVOKE it. And herein lies some of the resistance. Agreed, this is the Right and Proper Way. If I am to operate in this way, I need to engineer Yet Another identity management system (at best a plugin to an existing one, at worst an entire new system). There is not a single commercially available identity management system (including Tivoli products) that would know what a HMC is if it bit them in the rear. None of them understand any of the roles you describe, and none of the IT security weenies who run this stuff day to day have any grasp of this. It doesn't show up in their point-to-click-to-manage world -- you're dealing with people who think AD is the be-all, end-all, not RACF. After all, it's just a PC, right? (*snort*) -- doesn't work with *their* tool, doesn't happen. I concede the point that that will change over time, since this is more likely to impact z/OS sites and thus actually cause money to be spent, but you're moving too fast for the real world here. (I made this point in the design discussions about ensembles in Research; clearly I didn't have a big enough tantrum to crack the light of reality over this horizon). Local password management? I'm not following you on this. My client has all 'normal' HMC IDs authenticated with the corporate directory server (Active Directory). See above. AD integration for an HMC requires modifying the default AD schema to allow somewhere to store all those nifty new attributes, which is a one-way street. You can't go back. Windows admins (unless they are very very good) flee screaming from this, as it's an irrevocable step and it changes the support posture for a lot of other products, including some ones that have nothing to do with System Z (try calling Microsoft with a Exchange problem if you have a modified AD schema. You won't like it. Trust me.) Leave the HMC behind the RSA gear. It's not like general users of the operating systems are going to need HMC IDs. They may not need them, but setting up a separate provisioning process with all the attendant auditing, etc to manage them in a responsible way (let alone letting a non-human agent do anything to configurations without having exits for MY change management system (whatever that may be), as some of the ensemble code proposes to require in the near future) is pretty much a non-starter. Separation of powers, if nothing else -- if I can change the hardware configuration, I'm not allowed to change the user authorizations, and otherwise, WYSIWG wrt HMC management, and that doesn't include letting automation tinker with it. I guess the message we're trying to convey is that if this thing is to become the management endpoint for the System Z, a lot more thought needs to be put into deployment integration with other parts of the environment before people are going to be comfortable with the level of power that this thing has over the crown jewels. If it's treated as the control point, it's got to play nice with OUR control points. IBM can't revoke support for it when we install the stuff that makes it work for our businesses. The current message from IBM is a little too blue-centric for that to be realistic. -- db PS - jfrye: I *told* you so. dude. Nyah. 8-)
