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 » 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
Re: VMLINK behavior
Scott I will test this tomorrow... And back to tell you... Le 19/04/11 22:16, « Scott Rohling » scott.rohl...@gmail.com a écrit : Does VMLINK with the NONAMES option cause the same behavior? VMLINK user disk (NON I'm not sure about in this case, but NAMES files can sometimes create problems when using VMLINK - so I tend to use NONames Scott Rohling On Tue, Apr 19, 2011 at 2:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: EXTERNAL: VMLINK behavior
Robert, I can't confirm this right now, but if this ptf was in the last RSU from April 2011 for vm540, so... Yes it is applied... Alain Le 19/04/11 22:27, « Hodge, Robert L » robert.l.ho...@lmco.com a écrit : VM64870
Re: VMLINK behavior
Bruce, I'm near sure I have reconducted the last vmlink provided - this ptf included - by the IBM support from my VM530 to my VM540 RSU 1003... now I am with the rsu 1101 applied. Alain Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit : VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: VMLINK behavior
Bruce This ptf was for the case where the 190 was detached by vmlink... In my case i still have it... Alain Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit : VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: Dirmaint : cards ordre
Dave Ok I got it, thanks ! I would like to know how long does it take for you and others to migrate a directory ? Alain Le 07/04/11 19:40, « Dave Jones » d...@vsoft-software.com a écrit : Hi, Alan. The order in which the directory statements for a given user entry in the USER DIRECT file must appear is given in the CP Planning and Administration publication, Chapter 17. The *DVHOPT statement is an artifact used by DIRMAINT, and is ignored by the DIRECTXA command. As such, it's not really a part of the user directory entry. DJ On 04/07/2011 11:53 AM, Alain Benveniste wrote: I m trying to develop a tool to make directory migration easier and faster. At this time i would like to know if a doc references the order of the cards in a directory : USER card must precede the INCLUDE cardetc. and the last card should be *DVHOPT An other sequence would a serious problem ! Any idea ? Alain
Re: Temp SFS environment
Feedback: Reading Alan¹s answer, I thought to be unlucky,I changed my point of view in making some tests by defining my MDISK 301 to 305 as 3390 T-DISK. I fall in what Simon talked about : fileserv generate cmd didn¹t see the tdisk and ask me to link them... More ugly than my previous tests. I decided to freely supersede¹ Alan¹s directives to go back with my v-disk and check again the directory... and I got a idea. I had copied a VMSERVx directory to create my own SFS user. VMSERVx come with a MACHINE XC definition. I removed that line. And it works ! I am ready for communication¹. I don¹t say I will not have problems later but I think to be on the good way. All that brings a subsidiary question : is it important to preserve the machine xc in the VMSERVx directories (I should read the doc I think...) ? Thanks to all Alain
Re: RACF remote sharing facility (RRSF)
Alan I answered Kris that we didn't have Tivoly on our Zs. ...I would have hope to be the last guy on the list to require this to set off that nice(?) project :) Le 24/01/11 15:58, « Alan Altmark » alan_altm...@us.ibm.com a écrit : On Monday, 01/24/2011 at 07:06 EST, Alain Benveniste a.benveni...@free.fr wrote: We are looking how to propagate passwords between z/OS and z/VM. We want to remove nc-syncom. Z/OS has RRSF available, not z/VM. Any reason ? Will it be possible in a near future ? If you're not into the custom programming that Kris suggests, you can sync passwords via LDAP using IBM Tivoli Directory Integrator. The reason RRSF is not available for z/VM is simple: (1) it's expensive to do [only with the new TCP support was it even feasible], (2) the demand is weak. If you want RACF on z/OS and z/VM to talk via RRSF, you need to tell BOTH groups. For z/VM to cradle z/OS RRSF, it has to be built in a way that is cradle friendly, so there's work to be done on both sides. Did I say expensive already? 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 alan_altm...@us.ibm.com IBM Endicott
