Re: RMSMASTR and shutdowns
Doesn't look like it. It's config files and work files currently reside by default in vmsysu:dfsms. Vmsys:dfsms. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Schuh, Richard Sent: Friday, June 24, 2011 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns Is there something in RMSMASTR that requires a R/W 191? There does not appear to be on our system. The most recently written file on the disk is dated 12 Nov 2010. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark > Sent: Friday, June 24, 2011 2:24 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RMSMASTR and shutdowns > > On Friday, 06/24/2011 at 04:31 EDT, Marcy Cortes > wrote: > > Bleah.. and Yuck. > > > > NO NO NO. > > > > What's the point of putting 1 file in a SFS if you can't share it > anyway??? > > Put it on a minidisk. 1 cyl is fine. > > And maybe when I have SSI , I can actually share it. > > > > It's 7 4k blocks of config data. Maybe IBM was trying to > save me the > other 96% > > of a cylinder by putting it in SFS? The rest of the component is on > minidisk... > > But you CAN update it while RMSMASTER is up, can you not? I > am guessing > that there was a requirement to be able to update the config > file without > bringing the server down. > > Alan Altmark > > Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
Is there something in RMSMASTR that requires a R/W 191? There does not appear to be on our system. The most recently written file on the disk is dated 12 Nov 2010. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark > Sent: Friday, June 24, 2011 2:24 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RMSMASTR and shutdowns > > On Friday, 06/24/2011 at 04:31 EDT, Marcy Cortes > wrote: > > Bleah.. and Yuck. > > > > NO NO NO. > > > > What's the point of putting 1 file in a SFS if you can't share it > anyway??? > > Put it on a minidisk. 1 cyl is fine. > > And maybe when I have SSI , I can actually share it. > > > > It's 7 4k blocks of config data. Maybe IBM was trying to > save me the > other 96% > > of a cylinder by putting it in SFS? The rest of the component is on > minidisk... > > But you CAN update it while RMSMASTER is up, can you not? I > am guessing > that there was a requirement to be able to update the config > file without > bringing the server down. > > Alan Altmark > > Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
>Didn't we agree not to publicly reveal the location of the "VM Expert >Assisted Living Facility, Retirement Community, and Sanitarium"?!? But it >won't help; the IBM phones will be forwarded there anyway. ;-) D'oh - so sorry! But my phone will be at the bottom of the bottomless blue blue blue pool :) Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, June 24, 2011 3:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns On Friday, 06/24/2011 at 05:46 EDT, Marcy Cortes wrote: > Look at it this way. I don't want to have to have some VM guy with 30 years of > experience needed to figure out where I put the config file for a product. :-) If was easy, ANYONE could do it. > Ooo, look, there's the file that takes your request and sends it off magically > to ... Oh wait, you lost that file you didn't know about in the migration from > 6.8 to 6.9? and now you can't mount tapes. You mean you want to be able to register your own files on your own disks with the Migration Tool? Wow. Cool idea. If only :-) > Uh oh, back off the upgrade since > its going to take more than your 2 hour change window to get IBM on the phone > to figure out why since I didn't answer my phone after winning the Lotto and > running off to Bora Bora. Didn't we agree not to publicly reveal the location of the "VM Expert Assisted Living Facility, Retirement Community, and Sanitarium"?!? But it won't help; the IBM phones will be forwarded there anyway. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
On Friday, 06/24/2011 at 05:46 EDT, Marcy Cortes wrote: > Look at it this way. I don't want to have to have some VM guy with 30 years of > experience needed to figure out where I put the config file for a product. :-) If was easy, ANYONE could do it. > Ooo, look, there's the file that takes your request and sends it off magically > to ... Oh wait, you lost that file you didn't know about in the migration from > 6.8 to 6.9? and now you can't mount tapes. You mean you want to be able to register your own files on your own disks with the Migration Tool? Wow. Cool idea. If only :-) > Uh oh, back off the upgrade since > its going to take more than your 2 hour change window to get IBM on the phone > to figure out why since I didn't answer my phone after winning the Lotto and > running off to Bora Bora. Didn't we agree not to publicly reveal the location of the "VM Expert Assisted Living Facility, Retirement Community, and Sanitarium"?!? But it won't help; the IBM phones will be forwarded there anyway. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
>"Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS >manages APPC the way it does. FIlepool references in CMS are, by design, >symbolic destination names. If you don't have a COMDIR entry, you get the >defaults (e.g. TPN = symbolic name). Look at it this way. I don't want to have to have some VM guy with 30 years of experience needed to figure out where I put the config file for a product. Ooo, look, there's the file that takes your request and sends it off magically to ... Oh wait, you lost that file you didn't know about in the migration from 6.8 to 6.9? and now you can't mount tapes. Uh oh, back off the upgrade since its going to take more than your 2 hour change window to get IBM on the phone to figure out why since I didn't answer my phone after winning the Lotto and running off to Bora Bora. :P) Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, June 24, 2011 1:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns On Friday, 06/24/2011 at 03:48 EDT, David Boyes wrote: > > As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to > > redirect RMSMASTER to another server. > Ugh. What a hack. Works, but ... ick. "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS manages APPC the way it does. FIlepool references in CMS are, by design, symbolic destination names. If you don't have a COMDIR entry, you get the defaults (e.g. TPN = symbolic name). True, it's unusual, undesirable, annoying and a violation of all we hold sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
They have updated it to allow it to not die when it finds a device that doesn't exist on the system it was IPL'd on. We now just put all of the Dr and failover systems's VTS addresses in the config and need only one file now. Marcy Cortes Operating Systems Engineer, z/VM and Linux on System z Enterprise Hosting Services, Mainframe/Midrange Services Wells Fargo Bank | 201 Third Street | San Francisco, CA 94103 MAC A0187-050 Tel 415-477-6343 | Cell 415-517-0895 marcy.d.cor...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alain Benvéniste Sent: Friday, June 24, 2011 2:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns Because my same VM can run on different CPU I created five MACLIBs where the filename is the CPUID : 12342097 MACLIB. Each time I xautolog RMSMASTR the profile exec extracts the files related to the correponding CPU. That way my source files are secured in to my maclibs. I did that for TCPIP, VMTAPE, RSCS and some others... Just back from DR test. Worked as desired... Alain Benveniste Le 24/06/11 22:56, « Mike Walter » a écrit : > YES YES YES. (Yes in that I agree with Marcy). > > When I installed RMSMASTR I was concerned about what might happen to my config > statements when the next z/VM release, or even maintenance, rolled around. > Would IBM alter the config file because an RMS developer wanted to include a > new feature (yeah... right), would my file be lost/overlooked during the > migration (a significant chance)? > > So while wondering what possessed RMS development to put the config file into > SFS in the first place, I created a new SFS server named something entirely > unlike anything IBM ships, placed the config file there, and pointed RMSMASTR > to that one. Since the server was "one of our own", it never got changed when > IBM applied service, and was never left behind during an upgrade. > > Marcy is 100% correct (especially with the SSI SOI). Put it on a minidisk. > Remember... KISS. > > Mike Walter > Aon Corporation > The opinions expressed herein are mine alone, not my employer's. > > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf > Of Marcy Cortes > Sent: Friday, June 24, 2011 3:30 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RMSMASTR and shutdowns > > Bleah.. and Yuck. > > NO NO NO. > > What's the point of putting 1 file in a SFS if you can't share it anyway??? > Put it on a minidisk. 1 cyl is fine. > And maybe when I have SSI , I can actually share it. > > It's 7 4k blocks of config data. Maybe IBM was trying to save me the other > 96% of a cylinder by putting it in SFS? The rest of the component is on > minidisk... > > > > > Marcy > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf > Of Alan Altmark > Sent: Friday, June 24, 2011 1:18 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: [IBMVM] RMSMASTR and shutdowns > > On Friday, 06/24/2011 at 03:48 EDT, David Boyes > wrote: >>> As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES > to >>> redirect RMSMASTER to another server. > >> Ugh. What a hack. Works, but ... ick. > > "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS > manages APPC the way it does. FIlepool references in CMS are, by design, > symbolic destination names. If you don't have a COMDIR entry, you get the > defaults (e.g. TPN = symbolic name). > > True, it's unusual, undesirable, annoying and a violation of all we hold > sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) > > Alan Altmark > > Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
You can. I guess that is an advantage... very minimally though. Authorization to mount comes out of our tape product and its ESM rather than the config file so it changes very, very rarely (wait, shouldn't auth come from the ESM anyway and not its own private auth file :) . The device files update require you to recycle RMSMASTR anyway, so give him and r/o link and I can update it before the recyle anyway. So the pain outweighs the advantage. Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, June 24, 2011 2:24 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns On Friday, 06/24/2011 at 04:31 EDT, Marcy Cortes wrote: > Bleah.. and Yuck. > > NO NO NO. > > What's the point of putting 1 file in a SFS if you can't share it anyway??? > Put it on a minidisk. 1 cyl is fine. > And maybe when I have SSI , I can actually share it. > > It's 7 4k blocks of config data. Maybe IBM was trying to save me the other 96% > of a cylinder by putting it in SFS? The rest of the component is on minidisk... But you CAN update it while RMSMASTER is up, can you not? I am guessing that there was a requirement to be able to update the config file without bringing the server down. Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
On Friday, 06/24/2011 at 04:31 EDT, Marcy Cortes wrote: > Bleah.. and Yuck. > > NO NO NO. > > What's the point of putting 1 file in a SFS if you can't share it anyway??? > Put it on a minidisk. 1 cyl is fine. > And maybe when I have SSI , I can actually share it. > > It's 7 4k blocks of config data. Maybe IBM was trying to save me the other 96% > of a cylinder by putting it in SFS? The rest of the component is on minidisk... But you CAN update it while RMSMASTER is up, can you not? I am guessing that there was a requirement to be able to update the config file without bringing the server down. Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
Because my same VM can run on different CPU I created five MACLIBs where the filename is the CPUID : 12342097 MACLIB. Each time I xautolog RMSMASTR the profile exec extracts the files related to the correponding CPU. That way my source files are secured in to my maclibs. I did that for TCPIP, VMTAPE, RSCS and some others... Just back from DR test. Worked as desired... Alain Benveniste Le 24/06/11 22:56, « Mike Walter » a écrit : > YES YES YES. (Yes in that I agree with Marcy). > > When I installed RMSMASTR I was concerned about what might happen to my config > statements when the next z/VM release, or even maintenance, rolled around. > Would IBM alter the config file because an RMS developer wanted to include a > new feature (yeah... right), would my file be lost/overlooked during the > migration (a significant chance)? > > So while wondering what possessed RMS development to put the config file into > SFS in the first place, I created a new SFS server named something entirely > unlike anything IBM ships, placed the config file there, and pointed RMSMASTR > to that one. Since the server was "one of our own", it never got changed when > IBM applied service, and was never left behind during an upgrade. > > Marcy is 100% correct (especially with the SSI SOI). Put it on a minidisk. > Remember... KISS. > > Mike Walter > Aon Corporation > The opinions expressed herein are mine alone, not my employer's. > > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf > Of Marcy Cortes > Sent: Friday, June 24, 2011 3:30 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: RMSMASTR and shutdowns > > Bleah.. and Yuck. > > NO NO NO. > > What's the point of putting 1 file in a SFS if you can't share it anyway??? > Put it on a minidisk. 1 cyl is fine. > And maybe when I have SSI , I can actually share it. > > It's 7 4k blocks of config data. Maybe IBM was trying to save me the other > 96% of a cylinder by putting it in SFS? The rest of the component is on > minidisk... > > > > > Marcy > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf > Of Alan Altmark > Sent: Friday, June 24, 2011 1:18 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: [IBMVM] RMSMASTR and shutdowns > > On Friday, 06/24/2011 at 03:48 EDT, David Boyes > wrote: >>> As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES > to >>> redirect RMSMASTER to another server. > >> Ugh. What a hack. Works, but ... ick. > > "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS > manages APPC the way it does. FIlepool references in CMS are, by design, > symbolic destination names. If you don't have a COMDIR entry, you get the > defaults (e.g. TPN = symbolic name). > > True, it's unusual, undesirable, annoying and a violation of all we hold > sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) > > Alan Altmark > > Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
YES YES YES. (Yes in that I agree with Marcy). When I installed RMSMASTR I was concerned about what might happen to my config statements when the next z/VM release, or even maintenance, rolled around. Would IBM alter the config file because an RMS developer wanted to include a new feature (yeah... right), would my file be lost/overlooked during the migration (a significant chance)? So while wondering what possessed RMS development to put the config file into SFS in the first place, I created a new SFS server named something entirely unlike anything IBM ships, placed the config file there, and pointed RMSMASTR to that one. Since the server was "one of our own", it never got changed when IBM applied service, and was never left behind during an upgrade. Marcy is 100% correct (especially with the SSI SOI). Put it on a minidisk. Remember... KISS. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes Sent: Friday, June 24, 2011 3:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RMSMASTR and shutdowns Bleah.. and Yuck. NO NO NO. What's the point of putting 1 file in a SFS if you can't share it anyway??? Put it on a minidisk. 1 cyl is fine. And maybe when I have SSI , I can actually share it. It's 7 4k blocks of config data. Maybe IBM was trying to save me the other 96% of a cylinder by putting it in SFS? The rest of the component is on minidisk... Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, June 24, 2011 1:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns On Friday, 06/24/2011 at 03:48 EDT, David Boyes wrote: > > As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to > > redirect RMSMASTER to another server. > Ugh. What a hack. Works, but ... ick. "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS manages APPC the way it does. FIlepool references in CMS are, by design, symbolic destination names. If you don't have a COMDIR entry, you get the defaults (e.g. TPN = symbolic name). True, it's unusual, undesirable, annoying and a violation of all we hold sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
Bleah.. and Yuck. NO NO NO. What's the point of putting 1 file in a SFS if you can't share it anyway??? Put it on a minidisk. 1 cyl is fine. And maybe when I have SSI , I can actually share it. It's 7 4k blocks of config data. Maybe IBM was trying to save me the other 96% of a cylinder by putting it in SFS? The rest of the component is on minidisk... Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Friday, June 24, 2011 1:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] RMSMASTR and shutdowns On Friday, 06/24/2011 at 03:48 EDT, David Boyes wrote: > > As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to > > redirect RMSMASTER to another server. > Ugh. What a hack. Works, but ... ick. "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS manages APPC the way it does. FIlepool references in CMS are, by design, symbolic destination names. If you don't have a COMDIR entry, you get the defaults (e.g. TPN = symbolic name). True, it's unusual, undesirable, annoying and a violation of all we hold sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
On Friday, 06/24/2011 at 03:48 EDT, David Boyes wrote: > > As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to > > redirect RMSMASTER to another server. > Ugh. What a hack. Works, but ... ick. "Hack"?!? That's what UCOMDIR/SCOMDIR were designed for and why CMS manages APPC the way it does. FIlepool references in CMS are, by design, symbolic destination names. If you don't have a COMDIR entry, you get the defaults (e.g. TPN = symbolic name). True, it's unusual, undesirable, annoying and a violation of all we hold sacred in computing (WYSI*N*WYG!), but . OK. it's a hack. ;-) Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
> > Does anyone else think this should be considered a defect? > I do! I do! Sadly, that doesn't mean much. Me too. No program product should be permitted to interfere with a clean shutdown of the system as a whole. > As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to > redirect RMSMASTER to another server. That private little SFS server, solely > to hold the configuration file, would be configured with > NOSHUTDOWNSIGNAL. After CA:Operator shuts down RMSMASTER, it can > then shut down the SFS. If it doesn't get shutdown normally, no biggie, since > you would match this with a change to RMSMASTER's PROFILE EXEC to copy > the REAL config file from a minidisk of your choosing into SFS before > initializing the server. Then, if you should have to rebuild Private Little > SFS > from scratch, it doesn't matter - the config file is safe. Ugh. What a hack. Works, but ... ick. This does present the seed of an interesting idea, though. What if there was a USRCFG: file pool where user and product configurations were put by default, and IBM and other ISVs searched it, but were never allowed to update it directly? Separating the actual running config from IBM's default config and the code would be a really nice thing for migration. Would remove a lot of the reasons not to use VMSYS: for software installation. IBM code goes in VMSYS:, CA code goes in CASYS:, BMC in BMCSYS: etc. Configuration and customization go in USRCFG:. Easy to implement tools that compare the user's config with the new recommended config, identify if there are deprecated or changed statements, etc. Just a thought. -- db
Re: RMSMASTR and shutdowns
On Thursday, 06/23/2011 at 05:12 EDT, Marcy Cortes wrote: > Out of the box, RMSMASTR behaves very badly on a signal shutdown of your VM > system. > > We have to use this to mount tapes in the VTS. > > RMSMASTR has files in VMSYSU: and VMSYS:, which both use signal shutdown by > default. > > RMSMASTR hangs up the shutdown of VMSYS: until your system default shutdown > time is up. That could be very long time. Or not, but not getting all the way > down has required us to need FORCE starts on some systems on occasions, so a > shorter time isn't even helpful. > > So we wrote our own SHUTTRAP thing to issue a DMSMSRM STOP command. > This doesn't reliably work either. It's very timing dependent since this > service machine gets the signal at the same time as VMSERVR and VMSERVS and if > they beat it, the DFSMSRM STOP says not authorized (the auth file is in VMSYSU:) > > I opened a PMR once upon a time and it was rejected. > > We're trying to get things automated enough so that operations does nothing on > the VM side and GDPS which signals the processor controller to shutdown the > LPAR is sufficient. > > > Does anyone else think this should be considered a defect? I do! I do! Sadly, that doesn't mean much. As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to redirect RMSMASTER to another server. That private little SFS server, solely to hold the configuration file, would be configured with NOSHUTDOWNSIGNAL. After CA:Operator shuts down RMSMASTER, it can then shut down the SFS. If it doesn't get shutdown normally, no biggie, since you would match this with a change to RMSMASTER's PROFILE EXEC to copy the REAL config file from a minidisk of your choosing into SFS before initializing the server. Then, if you should have to rebuild Private Little SFS from scratch, it doesn't matter - the config file is safe. Alan Altmark Senior Managing z/VM and Linux 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: RMSMASTR and shutdowns
It might be nice if you could tell CP to stagger its shutdown signals, but I don't think that's going to happen. That's what automation's for... What about a combination of your approaches? 1. Put the NOSHUTDOWNSIGNAL in the SFS servers' parms files as you said. 2. Have VM:Operator (or your other SHUTTRAP thingy) first do the dmsrm stop followed by a force if unsuccessful. 3. When RMSMASTER is down, or in the last 10 or so of your 300-second window send the SFS servers a STOP command. -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System wrote on 06/23/2011 02:09:45 PM: > From: Marcy Cortes > To: IBMVM@LISTSERV.UARK.EDU > Date: 06/23/2011 02:14 PM > Subject: RMSMASTR and shutdowns > Sent by: The IBM z/VM Operating System -- snip -- > We'll probably work around it by one of these things > 1. Use CA VM:Operator to FORCE RMSMASTR upon message "HCPSHU6018I > The processor controller has sent a shutdown signal with a timeout > interval of 300 seconds" > 2. Use FORCE if dfsmsrm stop fails with "DGTUDR2016E User not > authorized to issue this command" > 3. Put NOSHUTDOWNSIGNAL in the parms file for VMSERVS and VMSERVU. > Not nice to them, but what would we lose? Not much I think.
RMSMASTR and shutdowns
Out of the box, RMSMASTR behaves very badly on a signal shutdown of your VM system. We have to use this to mount tapes in the VTS. RMSMASTR has files in VMSYSU: and VMSYS:, which both use signal shutdown by default. RMSMASTR hangs up the shutdown of VMSYS: until your system default shutdown time is up. That could be very long time. Or not, but not getting all the way down has required us to need FORCE starts on some systems on occasions, so a shorter time isn't even helpful. So we wrote our own SHUTTRAP thing to issue a DMSMSRM STOP command. This doesn't reliably work either. It's very timing dependent since this service machine gets the signal at the same time as VMSERVR and VMSERVS and if they beat it, the DFSMSRM STOP says not authorized (the auth file is in VMSYSU:) I opened a PMR once upon a time and it was rejected. We're trying to get things automated enough so that operations does nothing on the VM side and GDPS which signals the processor controller to shutdown the LPAR is sufficient. Does anyone else think this should be considered a defect? We'll probably work around it by one of these things 1. Use CA VM:Operator to FORCE RMSMASTR upon message "HCPSHU6018I The processor controller has sent a shutdown signal with a timeout interval of 300 seconds" 2. Use FORCE if dfsmsrm stop fails with "DGTUDR2016E User not authorized to issue this command" 3. Put NOSHUTDOWNSIGNAL in the parms file for VMSERVS and VMSERVU. Not nice to them, but what would we lose? Not much I think. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
