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 » <mike.wal...@aonhewitt.com> 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 <dbo...@sinenomine.net> > 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
