Re: Stubborn OSA Express-3 ?
yes, we got: EZZ4329I LINK OSA Look for messages like: yes, we got: EZZ4329I LINK OSAEGFCLNK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK OSAEGF8LNK at the time we moved the cables. after all 6 cables were connected to the new, single switch (I know, this is a SPoF), the only OSAs we were able to ping/telnet were the OSC CHPID-type (OSA-Express2) for our MCS consoles and non-SNA TSO sessions. All other OSAs on OSD CHPID-type (OSA-Express3) were not reachable. I understand that the ARP cache might have had the old MAC address of the old switch stored, but I wonder if there is a command or another way to tell : just forget all your connections so far, from now on you are connected to a new switch whose MAC address is The only way which on Sunday did work was resetting the OSAs the hard-way, from the SE. Is is a WAD, or are we BAD ? ;-) Annswer to BTW2: we have 2 physical OSA-Express3 (4 OSD channel type) and two physical OSA-Express2 (2 OSC and two OSE channel type). Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stubborn OSA Express-3 ?
Walter I always wondered why the manual bothered mentioning the famous downloading of IP addresses in the preamble to the section on Querying and Purging the ARP Cache - and now - I guess - I know! You need to keep in mind that OSA logic is playing fast and loose with ARP entries as IP addresses fly around in your Communications Server IP component. The conclusion would appear to be to purge the ARP cache when you are reconfiguring the IP address environment of your LAN - which actually sounds eminently sensible whatever tricks may be happening under the covers! So that's purge the ARP cache rather than shut down LPARS - should be a bit easier and, well, a bit less disruptive! Chris Mason [1] Open Systems Adapter-Express Customers Guide and Reference, Chapter 9, OSA Port Management: quote Querying and Purging the ARP Cache The Address Resolution Protocol (ARP) cache resides on the OSA-Express feature. When TCP/IP is started in QDIO mode, it downloads all the home IP addresses in the stack and stores them in the ARP cache. When running OSA- Express features in QDIO mode in a z/OS V1R4, z/VM Version 4 Release 4, or Linux environment, you can query and purge the contents of the ARP cache. Communications Server for z/OS V1R4 adds support for querying and purging the ARP cache using the following commands: To purge the ARP cache on z/OS VARY TCPIP,,PURGEcache,linkname for example, v tcpip,,purgec,link4 To query the ARP cache on z/OS DISPLAY TCPIP,,NETSTAT,ARP,ip_addr for example, d tcpip,,net,arp,10.11.91.200 or TSO NETSTAT command, for example, netstat arp all tcp tcpip To query the ARP cache on z/VM NETSTAT command, for example, netstat arp * See z/VM TCPIP Users Guide. The Linux qetharp utility is available to query or purge the contents of the ARP cache, for example: qetharp -q eth0 shows all ARP entries for OSA-Express interface eth0, while qetharp -p eth0 removes all entries from the ARP cache for OSA-Express port eth0. See Linux for zSeries: Device Drivers and Installation Commands, LNUX-1103, for a complete description of this command. /quote On Wed, 19 May 2010 02:58:12 -0700, Walter Marguccio walter_marguc...@yahoo.com wrote: yes, we got: EZZ4329I LINK OSA Look for messages like: yes, we got: EZZ4329I LINK OSAEGFCLNK HAS TAKEN OVER ARP RESPONSIBILITY FOR INACTIVE LINK OSAEGF8LNK at the time we moved the cables. after all 6 cables were connected to the new, single switch (I know, this is a SPoF), the only OSAs we were able to ping/telnet were the OSC CHPID-type (OSA- Express2) for our MCS consoles and non-SNA TSO sessions. All other OSAs on OSD CHPID-type (OSA-Express3) were not reachable. I understand that the ARP cache might have had the old MAC address of the old switch stored, but I wonder if there is a command or another way to tell : just forget all your connections so far, from now on you are connected to a new switch whose MAC address is The only way which on Sunday did work was resetting the OSAs the hard- way, from the SE. Is is a WAD, or are we BAD ? ;-) Annswer to BTW2: we have 2 physical OSA-Express3 (4 OSD channel type) and two physical OSA-Express2 (2 OSC and two OSE channel type). Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stubborn OSA Express-3 ?
So that's purge the ARP cache rather than shut down LPARS Chris, So that's purge the ARP cache rather than shut down LPARS - should be a bit easier and, well, a bit less disruptive! indeed. Thanks very much!! Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Stubborn OSA Express-3 ?
we have a z01-BC model K03, 4 LPARs, equipped with 4 OSA E Hello list, we have a z01-BC model K03, 4 LPARs, equipped with 4 OSA Express-3 1GB Ethernet SX (CHPID OSD) and 2 OSA Express-2 (CHPID OSC). Last Sunday we had to swap our network switch with a new one, and after we connected the cables coming from all OSAs to the new switch, we were able to ping/telnet to the OSCs (I had back MCS consoles and TSO via non-SNA) but we weren't be able to ping/telnet to the OSDs anymore. Issuing D TCPIP,,N,DEV from the console showed all 4 devices in ACTIVE status. Issuing a TSO ping from one LPAR to all others was successful, too. D NET,TRL,TRLE=trle_name for our TRLEs showed ACTIVE as well. Eventually we had to shutdown all 4 LPARs, configuring all 4 OSAs OSD off from the Service Element, put the same cards in Service Mode, put everything back on line, IPL and voila', the OSAs OSD were reachable again. I can't believe that a sophisticated hw like the z10 and its OSA-Express cards need such a reset action after a switch has been swapped. My impression is that we missed a much easier solution which could have prevented us to shutdown an entire Sysplex and be cut off from the rest ofthe world for two hours. Can someone shed some light ? Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stubborn OSA Express-3 ?
Walter Marguccio pisze: we have a z01-BC model K03, 4 LPARs, equipped with 4 OSA E Hello list, we have a z01-BC model K03, 4 LPARs, equipped with 4 OSA Express-3 1GB Ethernet SX (CHPID OSD) and 2 OSA Express-2 (CHPID OSC). Last Sunday we had to swap our network switch with a new one, and after we connected the cables coming from all OSAs to the new switch, we were able to ping/telnet to the OSCs (I had back MCS consoles and TSO via non-SNA) but we weren't be able to ping/telnet to the OSDs anymore. Issuing D TCPIP,,N,DEV from the console showed all 4 devices in ACTIVE status. Issuing a TSO ping from one LPAR to all others was successful, too. D NET,TRL,TRLE=trle_name for our TRLEs showed ACTIVE as well. Eventually we had to shutdown all 4 LPARs, configuring all 4 OSAs OSD off from the Service Element, put the same cards in Service Mode, put everything back on line, IPL and voila', the OSAs OSD were reachable again. I can't believe that a sophisticated hw like the z10 and its OSA-Express cards need such a reset action after a switch has been swapped. My impression is that we missed a much easier solution which could have prevented us to shutdown an entire Sysplex and be cut off from the rest ofthe world for two hours. Can someone shed some light ? 1. In the old days sophisticated OSA cards had to be varied OFF/ON whenever Eth signal was lost. It was big pain in the *ss. Nowadays, OSA Express2 (and newer) cards do not have such feature anymore. (BTW: No need to shutdown LPARs, it can be done online, only network is affected - but it's already down) What happened in your case? I suspect it can be related to ARP takeover process. Look for messages like: EZD0041I INTERFACE ethname1 HAS TAKEN BACK ARP RESPONSIBILITY FROM INTERFACE ethname2 BTW2: Do you really have 4 OSA Ex3 cards and 2 Ex2 cards or PORTs? If cards then you have 4x4 + 2x2 = 20 Eth ports. Quite a lot. And 4 OSC servers. If ports, then you have one OSE Ex3 and one OSA Ex2 card. Sounds more reasonable. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
