Re: PROP restart of OSA
No, it is not in the current definitions. Can AUTORESTART be added to a device without bouncing the stack? (it is a production system...) Shimon Original message Date: Mon, 5 May 2008 18:20:18 -0400 From: Alan Altmark [EMAIL PROTECTED] Subject: Re: PROP restart of OSA To: IBMVM@LISTSERV.UARK.EDU On Monday, 05/05/2008 at 10:32 EDT, Shimon Lebowitz [EMAIL PROTECTED] wrote: Yes, a manual restart does help. I log in through a different connection and do IFCONFIG SGLAN UP That is what I want PROP to do too. I could be mistaken (maybe Mary Ellen or Miguel can jump in here), but I think it worked only because the problem was repaired prior to your ifconfig up. Did you try the AUTORESTART? Alan Altmark z/VM Development IBM Endicott
Re: PROP restart of OSA
I think Alan is correct. (Of course, I've been trained to believe that is always the case.) Mary Ellen Carollo z/VM Development
Re: PROP restart of OSA
On Monday, 05/05/2008 at 08:03 EDT, Shimon Lebowitz [EMAIL PROTECTED]
wrote:
Hi,
I have occasionally had an OSA go down, as happened today.
Here are the messages I got from user TCPIP on the operator
console:
* 05/05/08 *
06:37:34 DTCOSD309W RECEIVED ADAPTER-INITIATED STOP LAN
* 05/05/08 *
06:37:34 DTCOSD082E OSD SHUTTING DOWN:
06:37:34 DTCPRI385IDEVICE OSA-B5:
06:37:34 DTCPRI386I TYPE: OSD, STATUS: READY
06:37:34 DTCPRI387I ENVELOPE QUEUE SIZE: 0
06:37:34 DTCPRI388I ADDRESS: B500
06:37:34 DTCQDI001I QDIO DEVICE OSA-B5 DEVICE NUMBER B502:
06:37:34 DTCQDI007I DISABLE FOR QDIO DATA TRANSFERS
I would like to prepare a routine to be triggered when these
messages are seen by PROP. My problem is that the message
lines which describe a problem ('stop lan', 'shutting down',
'disable') do not include the device address or link name, and the
lines with the device do not mention the problem, but PROP
works on the basis of a single line.
How do other people deal with this?
1. Add AUTORESTART to the DEVICE definition
or
2. Use a virtual NIC on a VSWITCH. The VSWITCH has better error recovery
than the stack. It also gives you the ability to have a second OSA on
stand-by without having to code dual interfaces in the stack.
In any case, you don't want PROP to handle this. A STOP LAN is the
result of a switch failing or being recycled, or a cable pull. A manual
restart won't help.
Alan Altmark
z/VM Development
IBM Endicott
Re: PROP restart of OSA
Yes, a manual restart does help.
I log in through a different connection and do
IFCONFIG SGLAN UP
That is what I want PROP to do too.
Original message
Date: Mon, 5 May 2008 08:38:04 -0400
From: Alan Altmark [EMAIL PROTECTED]
Subject: Re: PROP restart of OSA
To: IBMVM@LISTSERV.UARK.EDU
On Monday, 05/05/2008 at 08:03 EDT, Shimon Lebowitz
[EMAIL PROTECTED]
wrote:
Hi,
I have occasionally had an OSA go down, as happened today.
Here are the messages I got from user TCPIP on the operator
console:
* 05/05/08 *
06:37:34 DTCOSD309W RECEIVED ADAPTER-INITIATED STOP LAN
* 05/05/08 *
06:37:34 DTCOSD082E OSD SHUTTING DOWN:
06:37:34 DTCPRI385IDEVICE OSA-B5:
06:37:34 DTCPRI386I TYPE: OSD, STATUS: READY
06:37:34 DTCPRI387I ENVELOPE QUEUE SIZE: 0
06:37:34 DTCPRI388I ADDRESS: B500
06:37:34 DTCQDI001I QDIO DEVICE OSA-B5 DEVICE NUMBER B502:
06:37:34 DTCQDI007I DISABLE FOR QDIO DATA TRANSFERS
I would like to prepare a routine to be triggered when
these
messages are seen by PROP. My problem is that the message
lines which describe a problem ('stop lan', 'shutting
down',
'disable') do not include the device address or link name,
and the
lines with the device do not mention the problem, but PROP
works on the basis of a single line.
How do other people deal with this?
1. Add AUTORESTART to the DEVICE definition
or
2. Use a virtual NIC on a VSWITCH. The VSWITCH has better
error recovery
than the stack. It also gives you the ability to have a
second OSA on
stand-by without having to code dual interfaces in the stack.
In any case, you don't want PROP to handle this. A STOP
LAN is the
result of a switch failing or being recycled, or a cable
pull. A manual
restart won't help.
Alan Altmark
z/VM Development
IBM Endicott
Re: PROP restart of OSA
Shimon,
I write VM:Operator macroes instead of PROP execs but this looks as if two
routines are needed.
The first would key off the DTCOSD309W message and set a session globalv
variable with the timestamp
The second would key of the DTCQDI001I message to check the time stamp in the
session globalv variable that it is the same as that of the DTCOSD309W message.
Then it would take action.
A perfectionist might say you have to check the seconds, and overflow to the
next minute, but my guess is all these have the exact same time. But...
Jim
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Shimon Lebowitz
Sent: Monday, May 05, 2008 10:32 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: PROP restart of OSA
Yes, a manual restart does help.
I log in through a different connection and do
IFCONFIG SGLAN UP
That is what I want PROP to do too.
Original message
Date: Mon, 5 May 2008 08:38:04 -0400
From: Alan Altmark [EMAIL PROTECTED]
Subject: Re: PROP restart of OSA
To: IBMVM@LISTSERV.UARK.EDU
On Monday, 05/05/2008 at 08:03 EDT, Shimon Lebowitz
[EMAIL PROTECTED]
wrote:
Hi,
I have occasionally had an OSA go down, as happened today. Here are
the messages I got from user TCPIP on the operator
console:
* 05/05/08 *
06:37:34 DTCOSD309W RECEIVED ADAPTER-INITIATED STOP LAN
* 05/05/08 *
06:37:34 DTCOSD082E OSD SHUTTING DOWN:
06:37:34 DTCPRI385IDEVICE OSA-B5:
06:37:34 DTCPRI386I TYPE: OSD, STATUS: READY
06:37:34 DTCPRI387I ENVELOPE QUEUE SIZE: 0
06:37:34 DTCPRI388I ADDRESS: B500
06:37:34 DTCQDI001I QDIO DEVICE OSA-B5 DEVICE NUMBER B502:
06:37:34 DTCQDI007I DISABLE FOR QDIO DATA TRANSFERS
I would like to prepare a routine to be triggered when
these
messages are seen by PROP. My problem is that the message lines which
describe a problem ('stop lan', 'shutting
down',
'disable') do not include the device address or link name,
and the
lines with the device do not mention the problem, but PROP works on
the basis of a single line.
How do other people deal with this?
1. Add AUTORESTART to the DEVICE definition
or
2. Use a virtual NIC on a VSWITCH. The VSWITCH has better
error recovery
than the stack. It also gives you the ability to have a
second OSA on
stand-by without having to code dual interfaces in the stack.
In any case, you don't want PROP to handle this. A STOP
LAN is the
result of a switch failing or being recycled, or a cable
pull. A manual
restart won't help.
Alan Altmark
z/VM Development
IBM Endicott
This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically indicated,
this message is not an offer to sell or a solicitation of any investment
products or other financial product or service, an official confirmation of any
transaction, or an official statement of Merrill Lynch. Subject to applicable
law, Merrill Lynch may monitor, review and retain e-communications (EC)
traveling through its networks/systems. The laws of the country of each
sender/recipient may impact the handling of EC, and EC may be archived,
supervised and produced in countries other than the country in which you are
located. This message cannot be guaranteed to be secure or error-free. This
message is subject to terms available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you
consent to the foregoing.
Re: PROP restart of OSA
On Monday, 05/05/2008 at 10:32 EDT, Shimon Lebowitz [EMAIL PROTECTED] wrote: Yes, a manual restart does help. I log in through a different connection and do IFCONFIG SGLAN UP That is what I want PROP to do too. I could be mistaken (maybe Mary Ellen or Miguel can jump in here), but I think it worked only because the problem was repaired prior to your ifconfig up. Did you try the AUTORESTART? Alan Altmark z/VM Development IBM Endicott
