<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Socket IO fails with BROKEN PIPE in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956410#M53053</link>
    <description>An application on VMS creates a socket to an application on TRU64 (or another Unix), sends data over that socket (~ 1490 bytes), and next will send another message (~ 65 bytes) and after that, a larger number of similar messages, in size limited to about 80- byets each, and in the end it reads back an aknowledgement message.&lt;BR /&gt;On the same port, messages are transferred from the Unix application to a TCPIP-service on VMS that ends existance once the message has been processed - this port id therefore bi-directional.&lt;BR /&gt;&lt;BR /&gt;This works fine but for one site: The first message is transfered without error but sending the next fails with errno=32, errtxt = "broken pipe".&lt;BR /&gt;I couldn't find any information on this error in the VMS manuals, and searching HP site for "EPIPE"  revealed a number of documents on HP-UX and an article on the differences between TRU64 and HP-UX.&lt;BR /&gt;Since this happens on that site only, I guess it is something on the Unix side; traffic the other way seems to have no problem.&lt;BR /&gt;My questions are:&lt;BR /&gt;* What could cause the error&lt;BR /&gt;* What can (and should) be done at the remote site to prevent the problem?&lt;BR /&gt;&lt;BR /&gt;(VMS version 7.dunno, TCPIP 5.dunno either)&lt;BR /&gt;(TRU64? version: unknown)</description>
    <pubDate>Wed, 01 Feb 2006 08:35:10 GMT</pubDate>
    <dc:creator>Willem Grooters</dc:creator>
    <dc:date>2006-02-01T08:35:10Z</dc:date>
    <item>
      <title>Socket IO fails with BROKEN PIPE</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956410#M53053</link>
      <description>An application on VMS creates a socket to an application on TRU64 (or another Unix), sends data over that socket (~ 1490 bytes), and next will send another message (~ 65 bytes) and after that, a larger number of similar messages, in size limited to about 80- byets each, and in the end it reads back an aknowledgement message.&lt;BR /&gt;On the same port, messages are transferred from the Unix application to a TCPIP-service on VMS that ends existance once the message has been processed - this port id therefore bi-directional.&lt;BR /&gt;&lt;BR /&gt;This works fine but for one site: The first message is transfered without error but sending the next fails with errno=32, errtxt = "broken pipe".&lt;BR /&gt;I couldn't find any information on this error in the VMS manuals, and searching HP site for "EPIPE"  revealed a number of documents on HP-UX and an article on the differences between TRU64 and HP-UX.&lt;BR /&gt;Since this happens on that site only, I guess it is something on the Unix side; traffic the other way seems to have no problem.&lt;BR /&gt;My questions are:&lt;BR /&gt;* What could cause the error&lt;BR /&gt;* What can (and should) be done at the remote site to prevent the problem?&lt;BR /&gt;&lt;BR /&gt;(VMS version 7.dunno, TCPIP 5.dunno either)&lt;BR /&gt;(TRU64? version: unknown)</description>
      <pubDate>Wed, 01 Feb 2006 08:35:10 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956410#M53053</guid>
      <dc:creator>Willem Grooters</dc:creator>
      <dc:date>2006-02-01T08:35:10Z</dc:date>
    </item>
    <item>
      <title>Re: Socket IO fails with BROKEN PIPE</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956411#M53054</link>
      <description>&amp;gt; * What could cause the error&lt;BR /&gt;&lt;BR /&gt;The remote end closed the socket.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; * What can (and should) be done at the remote site to prevent the problem?&lt;BR /&gt;&lt;BR /&gt;If there is an intervening firewall, insure it is not dropping the connection. If you rule that out, then look for a programming error on the remote end.&lt;BR /&gt;&lt;BR /&gt;Using a tool such as TCPDUMP while a connection is in progress may prove enlightening.</description>
      <pubDate>Wed, 01 Feb 2006 09:21:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956411#M53054</guid>
      <dc:creator>Jim_McKinney</dc:creator>
      <dc:date>2006-02-01T09:21:08Z</dc:date>
    </item>
    <item>
      <title>Re: Socket IO fails with BROKEN PIPE</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956412#M53055</link>
      <description>Jan,&lt;BR /&gt;&lt;BR /&gt;Post a tcptrace/prot=tcp/fu.&lt;BR /&gt;&lt;BR /&gt;Is there internet between the 2 nodes ?&lt;BR /&gt;&lt;BR /&gt;We recently had a problem of unknown nature and switching to another phone (inbelpunt) solved the problem.&lt;BR /&gt;&lt;BR /&gt;Wim</description>
      <pubDate>Wed, 01 Feb 2006 09:45:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956412#M53055</guid>
      <dc:creator>Wim Van den Wyngaert</dc:creator>
      <dc:date>2006-02-01T09:45:47Z</dc:date>
    </item>
    <item>
      <title>Re: Socket IO fails with BROKEN PIPE</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956413#M53056</link>
      <description>Bad habit by previous programmer not to supply the right values. Chnaged code and found reason - in the other program.</description>
      <pubDate>Sun, 08 Oct 2006 15:19:44 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-io-fails-with-broken-pipe/m-p/4956413#M53056</guid>
      <dc:creator>Willem Grooters</dc:creator>
      <dc:date>2006-10-08T15:19:44Z</dc:date>
    </item>
  </channel>
</rss>

