Re: Cross system Shared File System...
It doesn't appear to be available on the VM download page any longer. Does anyone know where this package can be downloaded? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Friday, October 26, 2007 4:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Cross system Shared File System... IPGATE will do that for you if you have to use IP and aren't close enough for an ISFC CTC. I believe its on the VM Downloads page. Marcy Cortes 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. _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, October 26, 2007 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Cross system Shared File System... I used to do this with VTAM, but is there a way to implement cross-system SFS without VTAM in the mix? -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55 200 First Street SW / ( ) \ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but Join the story... Ride Ural. in practice, theory and practice are different. This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: Cross system Shared File System...
It's in SG245164. Said, Nick [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/30/2007 09:48 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Cross system Shared File System... -- Information from the mail header --- Sender: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Poster: Said, Nick [EMAIL PROTECTED] Subject: Re: Cross system Shared File System... --- It doesn't appear to be available on the VM download page any longer. Does anyone know where this package can be downloaded? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Friday, October 26, 2007 4:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Cross system Shared File System... IPGATE will do that for you if you have to use IP and aren't close enough for an ISFC CTC. =20 I believe its on the VM Downloads page. =20 Marcy Cortes 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. =20 _ =20 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, October 26, 2007 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Cross system Shared File System... I used to do this with VTAM, but is there a way to implement cross-system SFS without VTAM in the mix? --=20 .~.Robert P. Nix Mayo Foundation=20 /V\RO-OE-5-55 200 First Street SW=20 / ( ) \ 507-284-0844 Rochester, MN 55905=20 ^^-^^ -=20 In theory, theory and practice are the same, but Join the story... Ride Ural. in practice, theory and practice are different.=20 This email is intended for the recipient only. If you are not the intend= ed recipient please disregard, and do not use the information for any pur= pose.
RSCS TCPNJE links
I'm trying to get RSCS TCPNJE links established between a 1st level z/VM 5.2 RSCS node and a 2nd level z/VM 5.2 RSCS node. I know the TCPIP communication between the systems is working, as I can FTP between the systems. However, when I start the RSCS TCPNJE links I get: On 1st level: DMTCMY700I Activating link ZVM53 TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVM53 ready for session initiation DMTTNE190I Socket error on link ZVM53 (Connection refused) -- retrying DMTTNE182I Link ZVM53 session established DMTNCR905I Signon of link ZVM53 complete, buffer size=4096 DMTTNE570I Link ZVM53 now set to deactivate DMTTNE183I Link ZVM53 session terminated DMTMAN002I Link ZVM53 deactivated And on 2nd level: DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE182I Link ZVMRSCS session established DMTNCR905I Signon of link ZVMRSCS complete, buffer size=4096 DMTTNE951I Sign-off record received -- link ZVMRSCS being deactivated DMTTNE183I Link ZVMRSCS session terminated DMTMAN002I Link ZVMRSCS deactivated DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE190I Socket error on link ZVMRSCS (Connection refused) -- retrying DMTTNE190I Socket error on link ZVMRSCS (Connection timed out) -- retrying This is the 1st time I've tried setting up TCPNJE links. What am I doing wrong? This is how I defined the links: On 2nd level: LINKDEFINE ZVMRSCS TYPE TCPNJE AST NODE DIS3081 PARM ZVMRSCS ITO=0 HOST=172.30.8.11 LCLPORT=731 RMTPORT=731 (It ignores the NODE specification BTW). I tried it without the LCLPORT and RMTPORT at first and had problems, so thought it might be because there was no PORT definition in TCPIP PROFILE for port 175 and figured I might be able to borrow one of the port definitions for FTP. On 1st level, I defined it by command: sm rscs DEFINE ZVM53 TYPE TCPNJE AST PARM ITO=0 HOST=172.30.8.69 LCLPORT=731 RMTPORT=731 So, what am I missing? TIA
CSL routine?
OK, maybe I just missed it, but I can't seem to find a CSL routine that will take an SFS path and fully qualify it: . == SOMEPOOL:PHS3. SOMEPOOL:. == SOMEPOOL:PHS3. .BANANA== SOMEPOOL:PHS3.BANANA etc. While it's not hard to do this, it just *feels* like the kind of thing that CSL would offer... -- ...phsiii Phil Smith III Velocity Software www.velocity-software.com (703) 476-4511 (home office) (703) 568-6662 (cell)
Re: Cross system Shared File System...
I had one change to IPGATE: when using native SFS, the SFS server sees the CMS client's alternate userid and acts accordingly. When the standard IPGATE is involved, this no longer works, so I changed a couple of lines in IPGATE1Y I also changed 1 line IPGATE1, but I didn't note why. I think it was make make IPGATE run when using VIPA addresses. Both changes are available on request. (What is Alternate Userid? e.g. user KRIS submits a VM Batch job that is then executed in worker machine BATCH001; when the batch job connects to SFS, SFS uses the authority of user KRIS instead of BATCH001) 2007/10/30, Ken Watson [EMAIL PROTECTED]: It's in SG245164. *Said, Nick [EMAIL PROTECTED]* Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 10/30/2007 09:48 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Cross system Shared File System... -- Information from the mail header --- Sender: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Poster: Said, Nick [EMAIL PROTECTED] Subject: Re: Cross system Shared File System... --- It doesn't appear to be available on the VM download page any longer. Does anyone know where this package can be downloaded? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Friday, October 26, 2007 4:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Cross system Shared File System... IPGATE will do that for you if you have to use IP and aren't close enough for an ISFC CTC. =20 I believe its on the VM Downloads page. =20 Marcy Cortes 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. =20 _ =20 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of RPN01 Sent: Friday, October 26, 2007 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Cross system Shared File System... I used to do this with VTAM, but is there a way to implement cross-system SFS without VTAM in the mix? --=20 .~.Robert P. Nix Mayo Foundation=20 /V\RO-OE-5-55 200 First Street SW=20 / ( ) \ 507-284-0844 Rochester, MN 55905=20 ^^-^^ -=20 In theory, theory and practice are the same, but Join the story... Ride Ural. in practice, theory and practice are different.=20 This email is intended for the recipient only. If you are not the intend= ed recipient please disregard, and do not use the information for any pur= pose. -- Kris Buelens, IBM Belgium, VM customer support
Re: CSL routine?
I simply use the output LISTDIR dirid (NOSUBI know, not an API... Maybe DMSEXIFI can do it too. 2007/10/30, Phil Smith III [EMAIL PROTECTED]: OK, maybe I just missed it, but I can't seem to find a CSL routine that will take an SFS path and fully qualify it: . == SOMEPOOL:PHS3. SOMEPOOL:. == SOMEPOOL:PHS3. .BANANA== SOMEPOOL:PHS3.BANANA etc. While it's not hard to do this, it just *feels* like the kind of thing that CSL would offer... -- ...phsiii Phil Smith III Velocity Software www.velocity-software.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- Kris Buelens, IBM Belgium, VM customer support
Re: CSL routine?
DMSEXIDI is the CSL incantation: dir='.'; nocommit='NOCOMMIT' l=100 call CSL 'DMSEXIDI rc rs dir' length(dir) 'NOCOMMIT 8 RO WR EXT LN DIRO' say rc rs diro 2007/10/30, Kris Buelens [EMAIL PROTECTED]: I simply use the output LISTDIR dirid (NOSUBI know, not an API... Maybe DMSEXIFI can do it too. 2007/10/30, Phil Smith III [EMAIL PROTECTED] : OK, maybe I just missed it, but I can't seem to find a CSL routine that will take an SFS path and fully qualify it: . == SOMEPOOL:PHS3. SOMEPOOL:. == SOMEPOOL:PHS3. .BANANA== SOMEPOOL:PHS3.BANANA etc. While it's not hard to do this, it just *feels* like the kind of thing that CSL would offer... -- ...phsiii Phil Smith III Velocity Software www.velocity-software.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- Kris Buelens, IBM Belgium, VM customer support
Re: RSCS TCPNJE links
Maybe TCPIP's restriction on using low ports? I've got this in my PROFILE TCPIP PORT 175 TCP RSCS; RSCS TCPNJE driver 2007/10/30, Hooker, Don [EMAIL PROTECTED]: I'm trying to get RSCS TCPNJE links established between a 1st level z/VM 5.2 RSCS node and a 2nd level z/VM 5.2 RSCS node. I know the TCPIP communication between the systems is working, as I can FTP between the systems. However, when I start the RSCS TCPNJE links I get: On 1st level: DMTCMY700I Activating link ZVM53 TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVM53 ready for session initiation DMTTNE190I Socket error on link ZVM53 (Connection refused) -- retrying DMTTNE182I Link ZVM53 session established DMTNCR905I Signon of link ZVM53 complete, buffer size=4096 DMTTNE570I Link ZVM53 now set to deactivate DMTTNE183I Link ZVM53 session terminated DMTMAN002I Link ZVM53 deactivated And on 2nd level: DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE182I Link ZVMRSCS session established DMTNCR905I Signon of link ZVMRSCS complete, buffer size=4096 DMTTNE951I Sign-off record received -- link ZVMRSCS being deactivated DMTTNE183I Link ZVMRSCS session terminated DMTMAN002I Link ZVMRSCS deactivated DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE190I Socket error on link ZVMRSCS (Connection refused) -- retrying DMTTNE190I Socket error on link ZVMRSCS (Connection timed out) -- retrying This is the 1st time I've tried setting up TCPNJE links. What am I doing wrong? This is how I defined the links: On 2nd level: LINKDEFINE ZVMRSCS TYPE TCPNJE AST NODE DIS3081 PARM ZVMRSCS ITO=0 HOST=172.30.8.11 LCLPORT=731 RMTPORT=731 (It ignores the NODE specification BTW). I tried it without the LCLPORT and RMTPORT at first and had problems, so thought it might be because there was no PORT definition in TCPIP PROFILE for port 175 and figured I might be able to borrow one of the port definitions for FTP. On 1st level, I defined it by command: sm rscs DEFINE ZVM53 TYPE TCPNJE AST PARM ITO=0 HOST=172.30.8.69 LCLPORT=731 RMTPORT=731 So, what am I missing? TIA -- Kris Buelens, IBM Belgium, VM customer support
Re: RSCS TCPNJE links
You have to allow RSCS to use a low TCPIP port. In your PROFILE TCPIP, in the PORT section, add: 175 TCP RSCS NOAUTOLOG ; RSCS Link Or, you could put FREELOWPORTS in the ASSORTEDPARMS section which would allow RSCS (and any other userid) to use a low port without needing special authorization. On 10/30/07, Hooker, Don [EMAIL PROTECTED] wrote: I'm trying to get RSCS TCPNJE links established between a 1st level z/VM 5.2 RSCS node and a 2nd level z/VM 5.2 RSCS node. I know the TCPIP communication between the systems is working, as I can FTP between the systems. However, when I start the RSCS TCPNJE links I get: On 1st level: DMTCMY700I Activating link ZVM53 TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVM53 ready for session initiation DMTTNE190I Socket error on link ZVM53 (Connection refused) -- retrying DMTTNE182I Link ZVM53 session established DMTNCR905I Signon of link ZVM53 complete, buffer size=4096 DMTTNE570I Link ZVM53 now set to deactivate DMTTNE183I Link ZVM53 session terminated DMTMAN002I Link ZVM53 deactivated And on 2nd level: DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE182I Link ZVMRSCS session established DMTNCR905I Signon of link ZVMRSCS complete, buffer size=4096 DMTTNE951I Sign-off record received -- link ZVMRSCS being deactivated DMTTNE183I Link ZVMRSCS session terminated DMTMAN002I Link ZVMRSCS deactivated DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE190I Socket error on link ZVMRSCS (Connection refused) -- retrying DMTTNE190I Socket error on link ZVMRSCS (Connection timed out) -- retrying This is the 1st time I've tried setting up TCPNJE links. What am I doing wrong? This is how I defined the links: On 2nd level: LINKDEFINE ZVMRSCS TYPE TCPNJE AST NODE DIS3081 PARM ZVMRSCS ITO=0 HOST=172.30.8.11 LCLPORT=731 RMTPORT=731 (It ignores the NODE specification BTW). I tried it without the LCLPORT and RMTPORT at first and had problems, so thought it might be because there was no PORT definition in TCPIP PROFILE for port 175 and figured I might be able to borrow one of the port definitions for FTP. On 1st level, I defined it by command: sm rscs DEFINE ZVM53 TYPE TCPNJE AST PARM ITO=0 HOST=172.30.8.69 LCLPORT=731 RMTPORT=731 So, what am I missing? TIA -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY
Re: CSL routine?
I think you want DMSEXIDI, and you want the out_dirname that is returned. So, you pass it the input dirname (or filemode) and it returns the full directory name (if my memory of this is correct...) On 10/30/07, Phil Smith III [EMAIL PROTECTED] wrote: OK, maybe I just missed it, but I can't seem to find a CSL routine that will take an SFS path and fully qualify it: . == SOMEPOOL:PHS3. SOMEPOOL:. == SOMEPOOL:PHS3. .BANANA== SOMEPOOL:PHS3.BANANA etc. While it's not hard to do this, it just *feels* like the kind of thing that CSL would offer... -- ...phsiii Phil Smith III Velocity Software www.velocity-software.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY
Re: RSCS TCPNJE links
That PARM ITO-0 is the culprit. That says to not bring the link up under any circumstances. ITO=100 says to not time the link out. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hooker, Don Sent: Tuesday, October 30, 2007 7:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: RSCS TCPNJE links I'm trying to get RSCS TCPNJE links established between a 1st level z/VM 5.2 RSCS node and a 2nd level z/VM 5.2 RSCS node. I know the TCPIP communication between the systems is working, as I can FTP between the systems. However, when I start the RSCS TCPNJE links I get: On 1st level: DMTCMY700I Activating link ZVM53 TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVM53 ready for session initiation DMTTNE190I Socket error on link ZVM53 (Connection refused) -- retrying DMTTNE182I Link ZVM53 session established DMTNCR905I Signon of link ZVM53 complete, buffer size=4096 DMTTNE570I Link ZVM53 now set to deactivate DMTTNE183I Link ZVM53 session terminated DMTMAN002I Link ZVM53 deactivated And on 2nd level: DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE182I Link ZVMRSCS session established DMTNCR905I Signon of link ZVMRSCS complete, buffer size=4096 DMTTNE951I Sign-off record received -- link ZVMRSCS being deactivated DMTTNE183I Link ZVMRSCS session terminated DMTMAN002I Link ZVMRSCS deactivated DMTCMY700I Activating link ZVMRSCS TCPNJE line= class=* queueing=priority DMTTNE181I Link ZVMRSCS ready for session initiation DMTTNE190I Socket error on link ZVMRSCS (Connection refused) -- retrying DMTTNE190I Socket error on link ZVMRSCS (Connection timed out) -- retrying This is the 1st time I've tried setting up TCPNJE links. What am I doing wrong? This is how I defined the links: On 2nd level: LINKDEFINE ZVMRSCS TYPE TCPNJE AST NODE DIS3081 PARM ZVMRSCS ITO=0 HOST=172.30.8.11 LCLPORT=731 RMTPORT=731 (It ignores the NODE specification BTW). I tried it without the LCLPORT and RMTPORT at first and had problems, so thought it might be because there was no PORT definition in TCPIP PROFILE for port 175 and figured I might be able to borrow one of the port definitions for FTP. On 1st level, I defined it by command: sm rscs DEFINE ZVM53 TYPE TCPNJE AST PARM ITO=0 HOST=172.30.8.69 LCLPORT=731 RMTPORT=731 So, what am I missing? TIA
wherefor art thou forced?
We've had two guests forced off the system this morning. What can I do to track down the cause? Is this going to happen to more guests? 09:21:01 GRAF L0004 DISCONNECT S99KDT02 USERS = 34FORCED BY SYSTEM 09:36:01 USER DSC LOGOFF AS S99KDT02 USERS = 33FORCED BY SYSTEM 09:55:00 GRAF L0005 LOGON AS S99KDT02 USERS = 34FROM 10.6.7.66 09:56:16 GRAF L0005 DISCONNECT S99KDT02 USERS = 34 DVHRLY3886I Hourly processing started; with 0 log DVHRLY3886I files. DVHRLY3886I Hourly processing started; with 0 log DVHRLY3886I files. 10:01:34 GRAF L0005 RECONNECT S99KDT02 USERS = 34FROM 10.6.8.66 10:04:47 GRAF L0005 DISCONNECT S99KDT02 USERS = 34FORCED BY SYSTEM 10:08:19 GRAF L0007 RECONNECT S99KDT02 USERS = 34FROM 10.6.8.66 10:16:39 GRAF L0007 DISCONNECT S99KDT02 USERS = 34 10:18:07 GRAF L0003 DISCONNECT MAINTUSERS = 34BY LOGON FROM GRAF L0004 10:18:07 GRAF L0004 RECONNECT MAINTUSERS = 34FROM 10.6.8.66 10:18:38 GRAF L0006 DISCONNECT VMLEV2 USERS = 34FORCED BY SYSTEM 10:21:44 GRAF L0005 RECONNECT S99KDP01 USERS = 34FROM 10.6.8.66 10:22:19 GRAF L0005 DISCONNECT S99KDP01 USERS = 34 10:33:38 USER DSC LOGOFF AS VMLEV2 USERS = 33FORCED BY SYSTEM spool cons close to maint
Re: Upgrade to z/VM 5.3 hangs
VM64297 has closed and the corresponding PTF, UM32197, is now available. - Bill Holder, IBM Endicott, z/VM Development and Service
zLinux question
My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? To me this sounds normal but wanted to make sure it wasn't something we missed. We are going to try to set up something in TSA to better monitor it but again just checking. for example 10:24:23 HCPERP602I DASD 9DA1 AN INTERFACE CONTROL CHECK OCCURRED 10:24:23 HCPERP6303I SENSE = INVALID 10:24:23 HCPERP6304I IRB = 04C24017 46B22670 0002 0010E480 10:24:23 HCPERP6305I USERID = LINUX1 10:24:23 HCPERP2216I CHANNEL PATH ID = C4 10:24:23 HCPERP2220I PHYSICAL CHANNEL PATH ID = 0403 10:24:31 HCPERP2252I DEV 6A42 PATH 6D NOT OPERATIONAL 10:24:31 HCPERP602I DEV 6A42 AN INTERFACE CONTROL CHECK OCCURRED 10:24:31 HCPERP6303I SENSE = 000 10:24:31 HCPERP6303I 10:24:31 HCPERP6304I IRB = 04824017 0002 00084000 10:24:31 HCPERP6305I USERID = SYSTEM 10:24:31 HCPERP2216I CHANNEL PATH ID = 6D 10:24:31 HCPERP2220I PHYSICAL CHANNEL PATH ID = 0240 10:24:49 HCPERP2252I DEV F2B1 PATH 65 NOT OPERATIONAL 10:24:49 HCPERP2252I DEV F2B1 PATH 65 NOT OPERATIONAL Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? To me this sounds normal but wanted to make sure it wasn't something we missed. We are going to try to set up something in TSA to better monitor it but again just checking. for example 10:24:23 HCPERP602I DASD 9DA1 AN INTERFACE CONTROL CHECK OCCURRED 10:24:23 HCPERP6303I SENSE = INVALID 10:24:23 HCPERP6304I IRB = 04C24017 46B22670 0002 0010E480 10:24:23 HCPERP6305I USERID = LINUX1 10:24:23 HCPERP2216I CHANNEL PATH ID = C4 10:24:23 HCPERP2220I PHYSICAL CHANNEL PATH ID = 0403 10:24:31 HCPERP2252I DEV 6A42 PATH 6D NOT OPERATIONAL 10:24:31 HCPERP602I DEV 6A42 AN INTERFACE CONTROL CHECK OCCURRED 10:24:31 HCPERP6303I SENSE = 000 10:24:31 HCPERP6303I 10:24:31 HCPERP6304I IRB = 04824017 0002 00084000 10:24:31 HCPERP6305I USERID = SYSTEM 10:24:31 HCPERP2216I CHANNEL PATH ID = 6D 10:24:31 HCPERP2220I PHYSICAL CHANNEL PATH ID = 0240 10:24:49 HCPERP2252I DEV F2B1 PATH 65 NOT OPERATIONAL 10:24:49 HCPERP2252I DEV F2B1 PATH 65 NOT OPERATIONAL *Thanks* Andy Internet: Mailto:[EMAIL PROTECTED] The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: zLinux question
Rich - Thanks for replying, In zLinux is there away to build tolerance like any setting to say try 'x' amount of times before taking the error or is that all under the covers? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:15:06 PM: Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
So I take it the systems come bace(recovery) until another hit is taken? Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, October 30, 2007 2:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zLinux question Rich - Thanks for replying, In zLinux is there away to build tolerance like any setting to say try 'x' amount of times before taking the error or is that all under the covers? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:15:06 PM: Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: zLinux question
Actually with a hardware error like that, the z/VM messages tell most of the story (I misspoke) and z/VM is your best bet at recovery. It should handle the error condition better than Linux will (assuming you are using minidisks). Fixing your IFCC problem is the quickest route to a cure. Unless there's something in the newer DASD drivers, I don't know of any configurable retry mechanism. But that IFCC issue may cause you some real problems if it isn't corrected. [EMAIL PROTECTED] wrote: Rich - Thanks for replying, In zLinux is there away to build tolerance like any setting to say try 'x' amount of times before taking the error or is that all under the covers? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:15:06 PM: Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: zLinux question
Dumb question , I assuming the packs can be shared between VM and MVS. Have you checked MVS syslog to make sure someone hasn't varied a pack off/on? Or tried to access a pack they shouldn't. I know it seems like they wouldn't do it as often as it has happened but worth a look. The machine itself hasn't complained of any problems has it?? Mace From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, October 30, 2007 2:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zLinux question Rich - Thanks for replying, In zLinux is there away to build tolerance like any setting to say try 'x' amount of times before taking the error or is that all under the covers? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:15:06 PM: Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
RSCS TCPNJE links
Thanks for the replies. I was finally able to get it to work overriding the port via the LCLPORT=731 and RMTPORT=731 on the link parms. Richard Schuh hit the nail on the head with ITO=0. I had it backward in my head and thought that meant never time out. It was a learning experience though. It seems obvious now and makes perfect sense, but I was trying to get it working with the link names not matching the other end node's LOCAL node name. (Duh!).
Re: zLinux question
Note also that erep may have information that would be useful in diagnosing the problem. Get into the erep manual and figure out how to get the information its hoarding; give it to your systems or hardware people... -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 10/30/07 1:53 PM, Rich Smrcina [EMAIL PROTECTED] wrote: Actually with a hardware error like that, the z/VM messages tell most of the story (I misspoke) and z/VM is your best bet at recovery. It should handle the error condition better than Linux will (assuming you are using minidisks). Fixing your IFCC problem is the quickest route to a cure. Unless there's something in the newer DASD drivers, I don't know of any configurable retry mechanism. But that IFCC issue may cause you some real problems if it isn't corrected. [EMAIL PROTECTED] wrote: Rich - Thanks for replying, In zLinux is there away to build tolerance like any setting to say try 'x' amount of times before taking the error or is that all under the covers? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:15:06 PM: Andy, That's probably going to depend upon what lives on 9DA1. If it's a root filesystem or (gasp) a swap disk, then it's probably fair to say Linux may throw in the towel. But the z/VM messages don't tell the whole story, /var/log/messages may have more info. But as I say, if it's the root filesystem it may not be able to write the messages, then there's a vicious cycle and boom! I'd say check into what's causing the IFCC problems. [EMAIL PROTECTED] wrote: My background is z/OS so please excuse me Question: We have recently taken many hits (paths being lost, chip,ids etc see below) for some of our DASD which z/VM sits on and Redhat, we are looking into why. Each time we take such a hit we have lost different instances of zLinux. Now I understand the concept the OS z/Vm does the I/O and recovery through MIH etc. I am to assume then Redhat or SUSE any linux running under z/VM is dependant on the operating system for recovery. So it normal when taking a hit like the one below to loose a zLinux instance? The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: wherefor art thou forced?
Chris--Based on the console log you included, I think that Richard Schuh, is right. If a terminal or emulator session dies, CP usually forces the id after 15 minutes from the disconnect time unless you have changed the time in SYSTEM CONFIG. One thing you can do to help, altho, I don't think it will make a difference in what you saw with these id's, is to include a CP SET RUN ON in the id's PROFILE EXEC. We have the usual collection of disconnected service machines that just get XAUTOLOGed at system IPL time. Occasionally an id will be FORCED BY SYSTEM for a different reason that being disconnected from a terminal. We run with IBM's Programmable Operator running on the SYSOPER id and it has a trap for FORCED BY SYSTEM. It doesn't do any special analysis of the situation, but does XAUTOLOG a userid that is in a list of id's that should be kept up and send a message to the logical operator and a couple other id's that are generally logged on. It isn't very fancy, but it helps. Jim Little, Chris wrote: We've had two guests forced off the system this morning. What can I do to track down the cause? Is this going to happen to more guests? 09:21:01 GRAF L0004 DISCONNECT S99KDT02 USERS =3D 34FORCED BY SYSTEM 09:36:01 USER DSC LOGOFF AS S99KDT02 USERS =3D 33FORCED BY SYSTEM 09:55:00 GRAF L0005 LOGON AS S99KDT02 USERS =3D 34FROM 10.6.7.66 09:56:16 GRAF L0005 DISCONNECT S99KDT02 USERS =3D 34 DVHRLY3886I Hourly processing started; with 0 log DVHRLY3886I files. DVHRLY3886I Hourly processing started; with 0 log DVHRLY3886I files. 10:01:34 GRAF L0005 RECONNECT S99KDT02 USERS =3D 34FROM 10.6.8.66 10:04:47 GRAF L0005 DISCONNECT S99KDT02 USERS =3D 34FORCED BY SYSTEM 10:08:19 GRAF L0007 RECONNECT S99KDT02 USERS =3D 34FROM 10.6.8.66 10:16:39 GRAF L0007 DISCONNECT S99KDT02 USERS =3D 34 10:18:07 GRAF L0003 DISCONNECT MAINTUSERS =3D 34BY LOGON FROM = GRAF L0004=20 10:18:07 GRAF L0004 RECONNECT MAINTUSERS =3D 34FROM 10.6.8.66 10:18:38 GRAF L0006 DISCONNECT VMLEV2 USERS =3D 34FORCED BY SYSTEM 10:21:44 GRAF L0005 RECONNECT S99KDP01 USERS =3D 34FROM 10.6.8.66 10:22:19 GRAF L0005 DISCONNECT S99KDP01 USERS =3D 34 10:33:38 USER DSC LOGOFF AS VMLEV2 USERS =3D 33FORCED BY SYSTEM spool cons close to maint -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: wherefor art thou forced?
By the way - the change in the VM system config is to add Disconnect_Timeout Off to the Features line, such as: Features, . Disconnect_Timeout Off -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY
z/TPF List Server
Dear Lists: Is there a list server for z/TPF? HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: zLinux question
Larry - Im missing something we dont share these packs/dasd with any MVS system so what log am I checking? Thanks Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 02:32:25 PM: Dumb question , I assuming the packs can be shared between VM and MVS. Have you checked MVS syslog to make sure someone hasn?t varied a pack off/on? Or tried to access a pack they shouldn?t. I know it seems like they wouldn?t do it as often as it has happened but worth a look. The machine itself hasn?t complained of any problems has it?? Mace The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: z/TPF List Server
I worked in that arena for a number of years and I am not aware of anyone ever hosting a list server for TPF. Best bet has always been personal contacts established at conferences via the user group http://www.tpfug.org/ or of course there is also the IBM Lab. Regards, Rick Giz [EMAIL PROTECTED] 770-781-3206 _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Tuesday, October 30, 2007 6:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/TPF List Server Dear Lists: Is there a list server for z/TPF? HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: zLinux question
Thanks Robert But we already went down this route as I explained we know it was a hardware hit to a brocade device. That really wasnt my question we were told within a few minutes the chip'ds came back VM stayed up. But zLinux crashed on the VM system. Those of course involved with the chip'd taking the errors. Im just trying to find out is this normal, there are no time out values for zLinux to wait before going down hard or if it cant get to Root lets say once it dies? Sounds that way but wanting to see if there is anything we can do to prevent this other then the obvious make sure we dont take hardware hits ;) Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 03:58:42 PM: Note also that erep may have information that would be useful in diagnosing the problem. Get into the erep manual and figure out how to get the information its hoarding; give it to your systems or hardware people... -- .~.Robert P. Nix Mayo Foundation /V\RO-OE-5-55200 First Street SW The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
Is this an FCP device? I wonder if this is an MIH problem. To the group: Are there special MIH settings required for FCP devices? [EMAIL PROTECTED] wrote: Thanks Robert But we already went down this route as I explained we know it was a hardware hit to a brocade device. That really wasnt my question we were told within a few minutes the chip'ds came back VM stayed up. But zLinux crashed on the VM system. Those of course involved with the chip'd taking the errors. Im just trying to find out is this normal, there are no time out values for zLinux to wait before going down hard or if it cant get to Root lets say once it dies? Sounds that way but wanting to see if there is anything we can do to prevent this other then the obvious make sure we dont take hardware hits ;) Andy Internet: Mailto:[EMAIL PROTECTED] -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: z/TPF List Server
That confirms what I was thinking. I have never heard mention of a TPF list, and I have been lurking on the fringes of the TPF (PARS, ACP, ACP/TPF) world since the mid 1970s. Personal contacts and the development lab seem to obviate the need for a list. If you look at the number of TPF shops, it is quite small and dwindling (with the pending merger of WorldSpan and Galileo) compared to the number of VM, MVS, VSE or Linux licenses. With the smaller universe, a list really is not needed. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rick Giz Sent: Tuesday, October 30, 2007 4:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/TPF List Server I worked in that arena for a number of years and I am not aware of anyone ever hosting a list server for TPF. Best bet has always been personal contacts established at conferences via the user group http://www.tpfug.org/ or of course there is also the IBM Lab. Regards, Rick Giz [EMAIL PROTECTED] 770-781-3206 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Tuesday, October 30, 2007 6:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/TPF List Server Dear Lists: Is there a list server for z/TPF? HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: zLinux question
Rich - Sorry what is an FCP device? They are DASD IBM DS8300 or DS8000 type device in XRC mode. We have MIH set for 2:30 for them and was confirmed to be correct with our hardware person. Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 07:33:26 PM: Is this an FCP device? I wonder if this is an MIH problem. The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
On Tue, Oct 30, 2007 at 7:15 PM, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Thanks Robert But we already went down this route as I explained we know it was a hardware hit to a brocade device. That really wasnt my question we were told within a few minutes the chip'ds came back VM stayed up. But zLinux crashed on the VM system. Those of course involved with the chip'd taking the errors. Im just trying to find out is this normal, there are no As just about every response on mailing lists start with, it depends... On what OS was using a particular device for. If it had been one of z/VM's paging packs involved, things could have gotten ugly. (Not necessarily terminal, but certainly a little scary.) If it was one of Linux's application data volumes, more than likely Linux would have stayed up while the application died. There's no hard and fast rule here. time out values for zLinux to wait before going down hard or if it cant get to Root lets say once it dies? Sounds that way but wanting to see if there is anything we can do to prevent this other then the obvious make sure we dont take hardware hits ;) The Linux DASD device drivers have a fair amount of their own error recovery code in them. Not as good as z/VM's, probably (I'm in no position to judge that), but Linux doesn't just fall over with the first I/O error, either, since it also runs in an LPAR, and can't count on z/VM doing error recovery for it. It's usually going to be something fairly serious that causes a Linux system to crash. For example, I've been following an internal mailing list thread that was talking about a customer's midrange SLES system having the root file system get re-mounted as read-only. Various people confirmed that if Linux experiences non temporary errors writing to a file system, even /, it will re-mount the file system as read-only in an effort to prevent any (further) data corruption on that file system. If Linux is no longer able to even _read_ things from a file system that it needs to keep running, then yeah, your system is likely to throw a kernel panic and die. In your case, it sounds like you had something important to Linux go away for a long while (a few minutes is an eternity when you're talking about computers and I/O), and z/VM wasn't depending on any of those devices for its own continued functioning. Just be glad it wasn't the other way around. :) The things you'll want to look at are redundancy everywhere. In your paths to the switches (plural!), from the switches to the storage arrays (plural!), and so on. If an application is important enough, then you need to be looking at High Availability clustering techniques, and so on. With mainframe hardware, simply eliminating single points of failure gets you most of the way there. Mark Post
Re: zLinux question
So are the devices being accessed in 3390 mode? If so then they are not FCP devices. [EMAIL PROTECTED] wrote: Rich - Sorry what is an FCP device? They are DASD IBM DS8300 or DS8000 type device in XRC mode. We have MIH set for 2:30 for them and was confirmed to be correct with our hardware person. Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 07:33:26 PM: Is this an FCP device? I wonder if this is an MIH problem. The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: zLinux question
Rich - yes in 3390-3 emulation. Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 08:02:38 PM: So are the devices being accessed in 3390 mode? If so then they are not FCP devices. [EMAIL PROTECTED] wrote: Rich - Sorry what is an FCP device? They are DASD IBM DS8300 or DS8000 type device in XRC mode. We have MIH set for 2:30 for them and was confirmed to be correct with our hardware person. Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 07:33:26 PM: Is this an FCP device? I wonder if this is an MIH problem. -- The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
Thanks Alan... We do have TSA and do have GDPS set up but the mirrored volume is 140 miles away via XRC. Would this still work? Andy Internet: Mailto:[EMAIL PROTECTED] The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 10/30/2007 08:58:54 PM: On Tuesday, 10/30/2007 at 07:16 EDT, [EMAIL PROTECTED] wrote: Thanks Robert But we already went down this route as I explained we know it was a hardware hit to a brocade device. That really wasnt my question we were told within a few minutes the chip'ds came back VM stayed up. But zLinux crashed on the VM system. Those of course involved with the chip'd taking the errors. Im just trying to find out is this normal, there are no time out values for zLinux to wait before going down hard or if it cant get to Root lets say once it dies? Sounds that way but wanting to see if there is anything we can do to prevent this other then the obvious make sure we dont take hardware hits ;) To answer your question, an interface control check is a permanent I/O error (hence the HCPERP notifications and an EREP record was likely created). The channel subsystem has already tried all available paths to get to the device. There's nothing the guest can do to fix it. This is exactly the the kind of thing that Linux-HA and/or Tivoli System Automation for Linux [I think] can address using z/VM's HYPERSWAP command, if you have a z/OS GDPS solution. The I/O error would be trapped by the monitoring [Linux] guest and the failing volume replaced by a mirrored volume. (GDPS manages the mirroring.) Of course, if the primary and secondary volumes are coming through the same FICON switch then it won't help as much (protecting you only from port failures). Alan Altmark z/VM Development IBM Endicott The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: zLinux question
On Tuesday, 10/30/2007 at 07:16 EDT, [EMAIL PROTECTED] wrote: Thanks Robert But we already went down this route as I explained we know it was a hardware hit to a brocade device. That really wasnt my question we were told within a few minutes the chip'ds came back VM stayed up. But zLinux crashed on the VM system. Those of course involved with the chip'd taking the errors. Im just trying to find out is this normal, there are no time out values for zLinux to wait before going down hard or if it cant get to Root lets say once it dies? Sounds that way but wanting to see if there is anything we can do to prevent this other then the obvious make sure we dont take hardware hits ;) To answer your question, an interface control check is a permanent I/O error (hence the HCPERP notifications and an EREP record was likely created). The channel subsystem has already tried all available paths to get to the device. There's nothing the guest can do to fix it. This is exactly the the kind of thing that Linux-HA and/or Tivoli System Automation for Linux [I think] can address using z/VM's HYPERSWAP command, if you have a z/OS GDPS solution. The I/O error would be trapped by the monitoring [Linux] guest and the failing volume replaced by a mirrored volume. (GDPS manages the mirroring.) Of course, if the primary and secondary volumes are coming through the same FICON switch then it won't help as much (protecting you only from port failures). Alan Altmark z/VM Development IBM Endicott
