On Wed, 14 Oct 2009 08:22:37 -0400 Mrohs, Ray said: >The link comes right back up after its disconnected. But from a security >standpoint it seems that a link that is idle and stays connected to its >peer is more secure than one that is waiting for a connection to happen. >Maybe these firewall rules are aimed more at unattended workstations. If >all else fails, I'll set up a scheduled message to the peer node to keep >the link up, but I like to use vendor-supplied solutions if they are >available.
If you are running PROP on both nodes, you can use PROPCHK to verify connectivity to the remote site, and you can take action at that point automatically. Since the PROPCHK action itself will cause data to travel, it might be enough to keep your link up, and it is a vendor-supplied solution. /ahw >Ray Mrohs >-----Original Message----- >From: The IBM z/VM Operating System [mailto:[email protected]] On >Behalf Of Alan Altmark >Sent: Tuesday, October 13, 2009 1:48 PM >To: [email protected] >Subject: Re: Network timeout on TCPIP RSCS links >As you have discovered, KEEPALIV=YES is the default for TCPNJE links. >The >firewall may be ignoring keepalives. Firewall Folks need to look at >their >logs. >Note that keepalives have the undesirable side effect of bringing down a >link when there is a transient error, even when there is no file >transmission in progress. >Alan Altmark >z/VM Development >IBM Endicott
