friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8826eae394
ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/qtocrtvtcpa.htm

2133 lines
72 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
<title>Retrieve TCP/IP Attributes (QtocRtvTCPA) API</title>
<!-- Begin Header Records -->
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<!-- Created for V5R1-->
<!-- Change History: -->
<!-- YYMMDD USERID Change description -->
<!-- 050603 SGLEZ Add new V5R4 IPv6 formats -->
<!-- Edited by Sglez Jun 05 ========================================= -->
<!-- End Header Records ============================================= -->
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
</head>
<body>
<a name="Top_Of_Page"></a>
<!--Java sync-link-->
<script type="text/javascript" language="Javascript" src="../rzahg/synch.js">
</script>
<h2>Retrieve TCP/IP Attributes (QtocRtvTCPA) API</h2>
<div class="box" style="width: 60%;">
&nbsp;&nbsp;Required Parameter Group:<br>
<!-- iddvc RMBR -->
<br>
<table width="100%">
<tr>
<td align="center" valign="top" width="10%">1</td>
<td align="left" valign="top" width="50%">Receiver variable</td>
<td align="left" valign="top" width="20%">Output</td>
<td align="left" valign="top" width="20%">Char(*)</td>
</tr>
<tr>
<td align="center" valign="top">2</td>
<td align="left" valign="top">Length of receiver variable</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">3</td>
<td align="left" valign="top">Format name</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Char(8)</td>
</tr>
<tr>
<td align="center" valign="top">4</td>
<td align="left" valign="top">Error code</td>
<td align="left" valign="top">I/O</td>
<td align="left" valign="top">Char(*)</td>
</tr>
</table>
<br>
&nbsp;&nbsp;Service Program: QTOCNETSTS<br>
<!-- iddvc RMBR -->
<br>
&nbsp;&nbsp;Threadsafe: Yes<br>
<!-- iddvc RMBR -->
<br>
</div>
<p>The Retrieve TCP/IP
Attributes (QtocRtvTCPA) API retrieves TCP/IPv4 and TCP/IPv6 stack
attributes.</p>
<br>
<h3>Authorities and Locks</h3>
<p>None.</p>
<br>
<h3>Required Parameter Group</h3>
<dl>
<dt><strong>Receiver variable</strong></dt>
<dd>OUTPUT; CHAR(*)<br>
<p>The variable that is to receive the information requested. You can specify
the size of this area to be smaller than the format requested if you specify
the length of receiver variable parameter correctly. As a result, the API
returns only the data that the area can hold.</p>
</dd>
<dt><strong>Length of receiver variable</strong></dt>
<dd>OUTPUT; BINARY(4)<br>
<p>The length of the receiver variable. If this value is larger than the actual
size of the receiver variable, the result may not be predictable. The minimum
length is 8 bytes.</p>
</dd>
<dt><strong>Format name</strong></dt>
<dd>INPUT; CHAR(8)<br>
<p>The format of the space information to be returned. The format names
supported are:</p>
<table cellpadding="5">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top"><em>TCPA0100</em></td>
<td align="left" valign="top">TCP/IPv4 stack status. Refer to <a href=
"#TCPA0100">TCPA0100 Format</a> for details on the format.</td>
</tr>
<tr>
<td align="left" valign="top"><em>TCPA0200</em></td>
<td align="left" valign="top">TCP/IPv4 stack attributes in addition to TCP/IPv4
stack status. Refer to <a href="#TCPA0100">TCPA0100 Format</a> and <a href=
"#TCPA0200">TCPA0200 Format</a> for details on the format.</td>
</tr>
<tr>
<td align="left" valign="top"><em>TCPA0300</em></td>
<td align="left" valign="top">TCP/IP domain attributes in addition to TCP/IPv4
stack status. Refer to <a href="#TCPA0100">TCPA0100 Format</a> and <a href=
"#TCPA0300">TCPA0300 Format</a> for details on the format.</td>
</tr>
<tr>
<td align="left" valign="top"><em>TCPA1100</em></td>
<td align="left" valign="top">TCP/IPv6 stack status. Refer to <a href=
"#TCPA1100">TCPA1100 Format</a> for details on the format.</td>
</tr>
<tr>
<td align="left" valign="top"><em>TCPA1200</em></td>
<td align="left" valign="top">TCP/IPv6 stack attributes in addition to TCP/IPv6
stack status. Refer to <a href="#TCPA1100">TCPA1100 Format</a> and <a href=
"#TCPA1200">TCPA1200 Format</a> for details on the format.
<img src="delta.gif" alt="Start of change">As of V5R4, this format is
replaced with TCPA1300 and should no longer be used.
<img src="deltaend.gif" alt="End of change"></td>
</tr>
<tr>
<td align="left" valign="top"><img src="delta.gif" alt="Start of change"><em>TCPA1300</em></td>
<td align="left" valign="top">TCP/IPv6 stack attributes in addition to TCP/IPv6 stack status.
Refer to <a href="#TCPA1100">TCPA1100 Format</a> and <a href="#TCPA1300">TCPA1300
Format</a> for details on the format. This format replaces TCPA1200.
<img src="deltaend.gif" alt="End of change"></td>
</tr>
</table>
<br>
</dd>
<dt><strong>Error code</strong></dt>
<dd>I/O; CHAR(*)<br>
<p>The structure in which to return error information. For the format of the
structure, see <a href="../apiref/error.htm#hdrerrcod">Error Code Parameter</a>.</p>
</dd>
</dl>
<br>
<h3>Format of TCP/IP Attributes Information</h3>
<p>To retrieve the current TCP/IPv4 stack status, use format <a href=
"#TCPA0100">TCPA0100</a>.</p>
<p>For detailed TCP/IPv4 stack attributes in addition to the TCP/IPv4 stack
status, use format <a href="#TCPA0200">TCPA0200</a>.</p>
<p>For domain name system information in addition to the TCP/IPv4 stack status,
use format <a href="#TCPA0300">TCPA0300</a>.</p>
<br>
<p>To retrieve the current TCP/IPv6 stack status, use format <a href=
"#TCPA1100">TCPA1100</a>.</p>
<p><img src="delta.gif" alt="Start of change">For detailed TCP/IPv6 stack
attributes in addition to the TCP/IPv6 stack
status, use format <a href="#TCPA1300">TCPA1300</a>.<img src="deltaend.gif" alt="End of change"></p>
<br>
<h3><a name="TCPA0100">TCPA0100 Format</a></h3>
<p>This format returns information regarding the status of the TCP/IPv4 stack.
For detailed descriptions of the fields in the table, see <a href=
"#TCPA0100_FIELD">Field Descriptions</a>.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%">BINARY(4)</td>
<td align="left" valign="top" width="60%">Bytes returned</td>
</tr>
<tr>
<td align="center" valign="top">4</td>
<td align="center" valign="top">4</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Bytes available</td>
</tr>
<tr>
<td align="center" valign="top">8</td>
<td align="center" valign="top">8</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP/IPv4 stack status</td>
</tr>
<tr>
<td align="center" valign="top">12</td>
<td align="center" valign="top">C</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">How long active</td>
</tr>
<tr>
<td align="center" valign="top">16</td>
<td align="center" valign="top">10</td>
<td align="left" valign="top">CHAR(8)</td>
<td align="left" valign="top">When last started - date</td>
</tr>
<tr>
<td align="center" valign="top">24</td>
<td align="center" valign="top">18</td>
<td align="left" valign="top">CHAR(6)</td>
<td align="left" valign="top">When last started - time</td>
</tr>
<tr>
<td align="center" valign="top">30</td>
<td align="center" valign="top">1E</td>
<td align="left" valign="top">CHAR(8)</td>
<td align="left" valign="top">When last ended - date</td>
</tr>
<tr>
<td align="center" valign="top">38</td>
<td align="center" valign="top">26</td>
<td align="left" valign="top">CHAR(6)</td>
<td align="left" valign="top">When last ended - time</td>
</tr>
<tr>
<td align="center" valign="top">44</td>
<td align="center" valign="top">2C</td>
<td align="left" valign="top">CHAR(10)</td>
<td align="left" valign="top">Who last started - job name</td>
</tr>
<tr>
<td align="center" valign="top">54</td>
<td align="center" valign="top">36</td>
<td align="left" valign="top">CHAR(10)</td>
<td align="left" valign="top">Who last started - job user name</td>
</tr>
<tr>
<td align="center" valign="top">64</td>
<td align="center" valign="top">40</td>
<td align="left" valign="top">CHAR(6)</td>
<td align="left" valign="top">Who last started - job number</td>
</tr>
<tr>
<td align="center" valign="top">70</td>
<td align="center" valign="top">46</td>
<td align="left" valign="top">CHAR(16)</td>
<td align="left" valign="top">Who last started - internal job identifier</td>
</tr>
<tr>
<td align="center" valign="top">86</td>
<td align="center" valign="top">56</td>
<td align="left" valign="top">CHAR(10)</td>
<td align="left" valign="top">Who last ended - job name</td>
</tr>
<tr>
<td align="center" valign="top">96</td>
<td align="center" valign="top">60</td>
<td align="left" valign="top">CHAR(10)</td>
<td align="left" valign="top">Who last ended - job user name</td>
</tr>
<tr>
<td align="center" valign="top">106</td>
<td align="center" valign="top">6A</td>
<td align="left" valign="top">CHAR(6)</td>
<td align="left" valign="top">Who last ended - job number</td>
</tr>
<tr>
<td align="center" valign="top">112</td>
<td align="center" valign="top">70</td>
<td align="left" valign="top">CHAR(16)</td>
<td align="left" valign="top">Who last ended - internal job identifier</td>
</tr>
<tr>
<td align="center" valign="top">128</td>
<td align="center" valign="top">80</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Offset to additional information</td>
</tr>
<tr>
<td align="center" valign="top">132</td>
<td align="center" valign="top">84</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Length of additional information</td>
</tr>
<tr>
<td align="center" valign="top">136</td>
<td align="center" valign="top">88</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Limited mode</td>
</tr>
<tr>
<td align="center" valign="top">140</td>
<td align="center" valign="top">8C</td>
<td align="left" valign="top">&nbsp;</td>
<td align="left" valign="top">&nbsp;</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA0100_FIELD"></a>Field Descriptions</h3>
<p><strong>Bytes available.</strong> The number of bytes of data available to
be returned. All available data is returned if enough space is provided.</p>
<p><strong>Bytes returned.</strong> The number of bytes of data returned.</p>
<p><strong>How long active.</strong> How long, in seconds, the TCP/IP stack has
been active if it is active currently, or how long it was active the last time
it was up if it is currently inactive.</p>
<p><strong>Length of additional information.</strong> The length in bytes of
additional information returned that is not part of format TCPA0100.</p>
<p><strong>Limited
mode.</strong> The current value of the TCP/IP Limited mode flag. TCP/IPv4 can
operate while the system is in the restricted state, with limited
functionality.</p>
<p>Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">No - The system is not currently running TCP/IPv4
in limited mode.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Yes - The system is currently running TCP/IPv4 in
limited mode.</td>
</tr>
</table>
<p><strong>Offset to additional information.</strong> The offset from the
beginning of the receiver variable, in bytes, to the start of the next format
if a format other than TCPA0100 is requested. This field allows expansion of
the basic information. A value of zero is returned if only the TCPA0100 format
is requested.</p>
<p><strong>Reserved.</strong> An ignored field.</p>
<p><strong>TCP/IPv4 stack status.</strong> The current status of the system
TCP/IPv4 stack. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Inactive - The TCP/IPv4 stack is not
operational.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Active - The TCP/IPv4 stack is operational.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Starting - The TCP/IPv4 stack not operational,
but is in the process of starting.</td>
</tr>
<tr>
<td align="left" valign="top"><em>3</em></td>
<td align="left" valign="top">Ending, immediate - The TCP/IPv4 stack is
operational, but is in the process of ending.</td>
</tr>
<tr>
<td align="left" valign="top"><em>4</em></td>
<td align="left" valign="top">Ending, controlled - The TCP/IPv4 stack is
operational, but is in the process of ending.</td>
</tr>
</table>
<p><strong>When last ended - date.</strong> The date when the TCP/IP stack was
last ended. The format is YYYYMMDD, where:</p>
<table cellpadding="5">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top">YYYY</td>
<td align="left" valign="top">Year</td>
</tr>
<tr>
<td align="left" valign="top">MM</td>
<td align="left" valign="top">Month</td>
</tr>
<tr>
<td align="left" valign="top">DD</td>
<td align="left" valign="top">Day</td>
</tr>
</table>
<p><strong>When last ended - time.</strong> The time when the TCP/IP stack was
last ended. The format is HHMMSS, in 24-hour time, where:</p>
<table cellpadding="5">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top">HH</td>
<td align="left" valign="top">Hour</td>
</tr>
<tr>
<td align="left" valign="top">MM</td>
<td align="left" valign="top">Minute</td>
</tr>
<tr>
<td align="left" valign="top">SS</td>
<td align="left" valign="top">Second</td>
</tr>
</table>
<p><strong>When last started - date.</strong> The date when the TCP/IP stack
was last started. The format is YYYYMMDD, where:</p>
<table cellpadding="5">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top">YYYY</td>
<td align="left" valign="top">Year</td>
</tr>
<tr>
<td align="left" valign="top">MM</td>
<td align="left" valign="top">Month</td>
</tr>
<tr>
<td align="left" valign="top">DD</td>
<td align="left" valign="top">Day</td>
</tr>
</table>
<p><strong>When last started - time.</strong> The time when the TCP/IP stack
was last started. The format is HHMMSS, in 24-hour time, where:</p>
<table cellpadding="5">
<!-- cols="15 85" -->
<tr>
<td align="left" valign="top">HH</td>
<td align="left" valign="top">Hour</td>
</tr>
<tr>
<td align="left" valign="top">MM</td>
<td align="left" valign="top">Minute</td>
</tr>
<tr>
<td align="left" valign="top">SS</td>
<td align="left" valign="top">Second</td>
</tr>
</table>
<p><strong>Who last ended - internal job identifier.</strong> A value sent to
other APIs to speed the process of locating the job on the system. Only i5/OS APIs
use this identifier. This field is all NULLs if the
TCP/IP stack has not been ended since the last initial program load (IPL), or
if the job that ended the TCP/IP stack is no longer active.</p>
<p><strong>Who last ended - job name.</strong> The name of the job responsible
for ending the TCP/IP stack the last time it was ended. If the TCP/IP stack has
not been ended since the last initial program load (IPL), this field is all
NULLs.</p>
<p><strong>Who last ended - job number.</strong> The job number responsible for
ending the TCP/IP stack the last time it was ended. If the TCP/IP stack has not
been ended since the last initial program load (IPL), this field is all
NULLs.</p>
<p><strong>Who last ended - job user name.</strong> The name of the user
responsible for ending the TCP/IP stack the last time it was ended. If the
TCP/IP stack has not been ended since the last initial program load (IPL), this
field is all NULLs.</p>
<p><strong>Who last started - internal job identifier.</strong> A value sent to
other APIs to speed the process of locating the job on the system. Only i5/OS APIs
use this identifier. This field is all NULLs if the
TCP/IP stack has not been started since the last initial program load (IPL), or
if the job that started the TCP/IP stack is no longer active.</p>
<p><strong>Who last started - job name.</strong> The name of the job
responsible for starting the TCP/IP stack the last time it was started. If the
TCP/IP stack has not been started since the last initial program load (IPL),
this field will be all NULLs.</p>
<p><strong>Who last started - job number.</strong> The job number of the job
responsible for starting the TCP/IP stack the last time it was started. If the
TCP/IP stack has not been started since the last initial program load (IPL),
this field will be all NULLs.</p>
<p><strong>Who last started - job user name.</strong> The user name of the job
responsible for starting the TCP/IP stack the last time it was started. If the
TCP/IP stack has not been started since the last initial program load (IPL),
this field will be all NULLs.</p>
<br>
<h3><a name="TCPA0200"></a>TCPA0200 Format</h3>
<p>This format returns detailed information about the TCP/IPv4 stack attributes
in addition to the TCP/IPv4 stack status (format TCPA0100). For detailed
descriptions of the fields in the table, see <a href="#TCPA0200_FIELD">Field
Descriptions</a>.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%"><br>
</td>
<td align="left" valign="top" width="60%">Returns everything from format
TCPA0100</td>
</tr>
<tr>
<td valign="top" colspan="2" rowspan="27">Decimal and hexadecimal offsets are
reached by using the offset to additional information field in format
TCPA0100.</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">IP datagram forwarding</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">UDP checksum</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Log protocol errors</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">IP source routing</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP urgent pointer</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">IP reassembly timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">IP time to live</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP keep alive</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP receive buffer</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP send buffer</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">ARP cache timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">MTU path discovery</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">MTU discovery interval</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">QoS enablement</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">QoS timer resolution</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">QoS data path optimization</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Dead gateway detection enablement</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Dead gateway detection interval</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP time wait timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP R1 retransmission count</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP R2 retransmission count</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP minimum retransmission timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP close connection message</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Network file cache enablement</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Network file cache timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Network file cache size</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Explicit congession notification</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA0200_FIELD"></a>Field Descriptions</h3>
<p><strong>ARP cache timeout.</strong> The ARP cache time-out value, in minutes
The purpose of the time-out value is to flush out-of-date cache entries from
the ARP cache.</p>
<p>The default ARP cache time-out interval is 5 minutes. Valid values range
from 1 through 1440 minutes (24 hours).</p>
<p><strong>Dead gateway detection enablement.</strong> Whether dead gateway
detection is turned on or off. Dead gateway detection is a mechanism that
involves polling all attached gateways. If no reply is received to the polls,
all routes using that gateway are inactivated. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Dead gateway detection is off.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Dead gateway detection is on. This is the default
value.</td>
</tr>
</table>
<p><strong>Dead gateway detection interval.</strong> The amount of time, in
minutes, between dead gateway detection polls. When the time interval is
exceeded, all attached gateways are polled to determine their availability.</p>
<p>The default dead gateway detection interval is 2 minutes. Valid values range
from 1 through 60 minutes.</p>
<p><strong>Explicit congession notification (ECN).</strong> If ECN is enabled
routers can notify end-nodes of congestion before queues overflow. Without ECN
end-nodes can only detect congestion when packets are lost due to queues
overflowing.</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">ECN is not enabled for the system. This is the
default value.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">ECN is enabled for the system.</td>
</tr>
</table>
<p><strong>IP datagram forwarding.</strong> Whether the IP layer forwards
Internet Protocol (IP) datagrams between different networks. It specifies
whether the IP layer is acting as a gateway.</p>
<p><strong>Note:</strong> IP does not forward datagrams between interfaces on
the same subnet.</p>
<p>The i5/OS implementation of TCP/IP does not include full gateway function
as defined in RFC1009. Subsets of the gateway functions are supported. One of
the gateway functions supported is IP datagram forwarding capabilities. The
possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">IP datagrams are not forwarded. This is the
default value.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">IP datagrams are forwarded.</td>
</tr>
</table>
<p><strong>IP reassembly timeout.</strong> The IP datagram reassembly time, in
seconds. If this time is exceeded, a partially reassembled datagram is
discarded and an ICMP time exceeded message is sent to the source host.</p>
<p>The default IP reassembly timeout is 10 seconds. Valid values range from 5
through 120 seconds.</p>
<p><strong>IP source routing.</strong> Whether IP source routing currently is
on or off. If IP source routing is on, it means that this system is specifying
the route that outgoing IP packets take instead of allowing normal dynamic
routing to take place. Some firewalls will not pass datagrams that have IP
source routing switched on. The possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">IP source routing is off.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">IP source routing is on. This is the default
value.</td>
</tr>
</table>
<p><strong>IP time to live.</strong> The current TTL value. The IP datagram
time-to-live value specifies a relative limit on the number of hops across
which an IP datagram remains active. The time-to-live value acts as a hop count
that is decremented by each gateway to prevent internet routing loops.</p>
<p><strong>Note:</strong> Even though this parameter is specified as a
time-to-live value, it is not used as a time value. It is used as a counter.
The standard description is time to live as specified in RFCs.</p>
<p><strong>Note:</strong> This IP datagram time-to-live value is not used for
datagrams sent to an IP multicast group address. The default IP datagram
time-to-live value for datagram sent to an IP multicast group is always 1, as
specified by the Internet standards. Individual multicast applications may
override this default using the IP_MULTICAST_TTL socket option.</p>
<p>The default time-to-live value is 64. Valid values range from 1 through
255.</p>
<p><strong>Log protocol errors.</strong> Enables a user to log protocol errors
that occur during the processing of TCP/IP data. These TCP/IP stack layer
functions use this parameter to determine if they log protocol-specific errors:
IP, ICMP, ARP, and NAM. TCP and UDP do not log protocol errors.</p>
<p>The 7004 error reference code is logged when the LOGPCLERR(*YES) option is
specified and inbound datagrams are silently discarded. Silently discarded
means that an ICMP message is not returned to the originating host when a
datagram is discarded because of header errors. Examples of such datagrams
include those with invalid checksums and invalid destination addresses.</p>
<p>The error reference code is for information only. No action should be taken
as a result of this error reference code. It is generated to assist with remote
device or TCP/IP network problem analysis.</p>
<p><strong>Note:</strong> These error conditions cannot be processed using an
APAR.</p>
<p>The log protocol errors parameter should be used when error conditions
require the logging of TCP/IP data, such as datagrams, to determine network
problems.</p>
<p>The data is logged in the system error log. This error log is available
through the Start System Service Tools (STRSST) command. The possible values
are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Protocol errors are not logged.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Protocol errors are logged.</td>
</tr>
</table>
<p><strong>MTU discovery interval.</strong> The amount of time, in minutes,
that the TCP/IP protocol stack will cache the results of a path MTU discovery.
When the time interval is exceeded, the path MTU is rediscovered.</p>
<p>The default path MTU discovery interval is 10 minutes. Valid values range
from 5 through 40320 minutes (28 days). A special value is:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>-1</em></td>
<td align="left" valign="top">*ONCE - Means that path MTUs should not be
recalculated after the first discovery.</td>
</tr>
</table>
<p><strong>MTU path discovery.</strong> Whether the Path Maximum Transmission
Unit (MTU) discovery function is enabled on this system.</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">MTU Path Discovery is disabled for this
system.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">MTU Path Discovery is enabled for this system.
This is the default value.</td>
</tr>
</table>
<p><strong>Network file cache enablement.</strong> The current enablement
status of the Network File Cache (NFC) function. The Network File Cache is used
for the support of FRCA (Fast Response Cache Accelerator). FCRA dramatically
improves the performance of serving non-secure static content by Web and other
TCP servers.</p>
<p>Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">*NO - Network file cache is currently disabled on
this system.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">*YES - Network file cache is currently enabled on
this system.</td>
</tr>
</table>
<p><strong>Network file cache size.</strong> The maximum amount of storage that
may be used by the Network File Cache (NFC) for the entire system. This number
is the total storage used by all TCP servers for caching files. The storage
being allocated is DASD or disk and is not directly allocated from main memory.
Valid values range from 10 through 100000 megabytes (100GB).</p>
<p><strong>Network file cache timeout.</strong> The maximum amount of time in
seconds that a file can be cached in the Network File Cache (NFC). This
attribute ensures that a file is refreshed at a regular interval. Valid values
range from 30 through 604800 seconds (one week).</p>
<p>Special values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">*NOMAX - Network file cache entries will not
timeout.</td>
</tr>
</table>
<p><strong>QoS data path optimization.</strong> The type of data path
optimization in use by Quality of Service (QoS). This field indicates the
extent which QoS will batch datagrams so as to optimize performance at the risk
of increasing jitter, or delay. The normal setting maximizes performance by
doing more batching of datagram packets. The MinDelay setting minimizes delay
by doing less batching of datagram packets and just sending them when they are
ready. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">*NORMAL - Maximize performance. This setting is
the default.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">*MINDELAY - Minimize delay.</td>
</tr>
</table>
<p><strong>QoS enablement.</strong> Whether Quality of Service (QoS), IP Type
of Service (TOS), or neither of the two are in use. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">*TOS - Type of Service bytes in the IP headers
are in use.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">*YES - QoS is in use.</td>
</tr>
<tr>
<td align="left" valign="top"><em>3</em></td>
<td align="left" valign="top">*NO - QoS is not in use and the Type of Service
byte is not in use. This setting is the default.</td>
</tr>
</table>
<p><strong>QoS timer resolution.</strong> The Quality of Service (QoS) timer
resolution value in milliseconds. This field indicates the amount of control
possible over delay variations. A higher timer resolution value contributes to
more jitter (delay), and a lower timer resolution uses more CPU time. The timer
resolution value that can be tolerated is very dependent on the application.
For example, video is highly sensitive to large delay variations. To achieve a
smooth rate of flow, timers need to use small timer increments. The smaller the
resolution, the smoother the data flow, but at a higher cost in terms of system
overhead to manage timers.</p>
<p>The default QoS timer resolution is 100 milliseconds. Valid values range
from 5 to 5000 milliseconds.</p>
<p><strong>TCP close connection
message.</strong> The value of the TCP close connection message attribute. The
TCP close connection message attribute specifies whether abnormally closed TCP
connections will be logged by messages to the QTCP message queue. TCP
connections could be abnormally closed for the following reasons:</p>
<ul>
<li>TCP connection closed due to the 10 minute Close_Wait time_out.</li>
<li>TCP connection closed due to the R2 retry threshold being exceeded.</li>
<li>TCP connection closed due to the keep alive time-out value being
exceeded.</li>
</ul>
<p>Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">*THRESHOLD - At most, one abnormally closed TCP
connection message per minute will be logged. This value is the default
setting.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">*ALL - All abnormally closed TCP connections will
be loged. Note that there are some conditions that could cause MANY closed
connection messages to be logged at the same time.</td>
</tr>
<tr>
<td align="left" valign="top"><em>3</em></td>
<td align="left" valign="top">*NONE - Abnormally closed TCP connections will not
be logged.</td>
</tr>
</table>
<p><strong>TCP keep alive.</strong> The amount of time, in minutes, that TCP
waits before sending out a probe to the other side of a connection. The probe
is sent when the connection is otherwise idle, even when there is no data to be
sent.</p>
<p>The transmission of keep-alive packets is controlled by individual sockets
applications through use of the SO_KEEPALIVE socket option. For more
information, <a href="../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in
the iSeries Information Center.</p>
<p>The default keep-alive time interval is 120 minutes. Valid values range from
1 through 40320 minutes (28 days).</p>
<p><strong>TCP minimum
retransmission timeout.</strong> The current value of the configurable TCP
minimum retransmission timeout attribute, in milliseconds. This attribute
specifies the amount of time that TCP will wait for an acknowledgement (ACK) of
a packet. When this amount of time has passed without an acknowledgement, TCP
will perform the first retransmission of the packet. The default TCP minimum
retransmission timeout is 250 milliseconds. Valid values range from 100 through
1000 milliseconds.</p>
<p><strong>TCP R1 retransmission count.</strong> The R1 retransmission count
value. The default value is 3. Valid values range from 1 to 15, and R1 must be
less than R2.</p>
<p><strong>TCP R2 retransmission count.</strong> The R2 retransmission count
value. The default value is 16. Valid values range from 2 to 16, and R2 must be
greater than R1.</p>
<p><strong>TCP receive buffer.</strong> What to allocate for the default
receive buffer size. The TCP receive window size is based on this value.
Decreasing this value decreases the amount of data that the remote system can
send before being read by the local application. Decreasing this value may
improve performance in situations where many retransmissions occur due to the
overrunning of a network adapter.</p>
<p><strong>Notes:</strong></p>
<ol>
<li>User Datagram Protocol (UDP) does not have a configurable receive buffer
size.</li>
<li>This value is also used as the default receive buffer size by IP over SNA
processing.</li>
<li>Setting this parameter does not guarantee the size of the TCP receive
buffer. This is the default buffer size that is used for initial TCP connection
negotiations. An individual application can override this value by using the
SO_RCVBUF socket option. For more information, see <a href=
"../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in the iSeries
Information Center.</li>
</ol>
<p>The default TCP receive buffer size is 8192 (8K) bytes. Valid values range
from 512 through 8388608 (8MB) bytes.</p>
<p><strong>TCP send buffer.</strong> The TCP send buffer size. This parameter
informs TCP what to use for the default send buffer size. The TCP send buffer
size provides a limit on the number of outgoing bytes that are buffered by TCP.
Once this limit is reached, attempts to send additional bytes may result in the
application blocking until the number of outgoing bytes buffered drops below
this limit. The number of outgoing bytes buffered is decremented when the
remote system acknowledges the data sent.</p>
<p><strong>Notes:</strong></p>
<ol>
<li>This value is used also as the default send buffer size by IP over SNA
processing.</li>
<li>UDP does not have a configurable send buffer size.</li>
<li>Setting this parameter does not guarantee the size of the TCP send buffer.
This is the default buffer size that is used for initial TCP connection
negotiations. An individual application can override this value by using the
SO_SNDBUF socket option. For more information, see <a href=
"../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in the iSeries
Information Center.</li>
</ol>
<p>The default TCP send buffer size is 8192 (8K) bytes. Valid values range from
512 through 8388608 (8M) bytes.</p>
<p><strong>TCP time wait timeout.</strong> The amount of time, in seconds, for
which a socket pair (client IP address and port, server IP address and port)
cannot be reused after a connection is closed. The maximum value possible is 2
MSL (maximum segment lifetime). The default value is 120 seconds. Valid values
range from 0 (no timer) to 14400 seconds (240 minutes).</p>
<p><strong>TCP urgent pointer.</strong> The convention to follow when
interpreting which byte the urgent pointer in the TCP header points to. The
urgent pointer in the TCP header points to either the byte immediately
following the last byte of urgent data (BSD convention) or the last byte of the
urgent data (RFC convention).</p>
<p><strong>Note:</strong> This value must be consistent between the local and
remote ends of a TCP connection. Socket applications that use this value must
use it consistently between the client and server applications. This value is
set on a system basis. All applications using this system will use this value.
The possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Use the BSD defined convention. The TCP urgent
pointer points to the byte immediately following the last byte of urgent data.
This is the default value.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Use the RFC defined convention. The TCP urgent
pointer points to the last byte of the urgent data.</td>
</tr>
</table>
<p><strong>UDP checksum.</strong> Whether UDP processing should generate and
validate checksums. It is strongly recommended that you use UDP checksum
processing. If you are concerned about obtaining the best possible performance
and are not concerned with the protection provided by UDP checksum processing,
turn UDP checksum processing off. The possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Checksum protection is not provided for UDP
data.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Checksum protection is provided for UDP data.
This is the default value.</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA0300"></a>TCPA0300 Format</h3>
<p>This format returns detailed information about the TCP/IP domain attributes,
in addition to the TCP/IPv4 stack status (format TCPA0100). For detailed
descriptions of the fields in the table, see <a href="#TCPA0300_FIELD">Field
Descriptions</a>.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%"></td>
<td align="left" valign="top" width="60%">Returns everything from format
TCPA0100</td>
</tr>
<tr>
<td valign="top" colspan="2" rowspan="13">Decimal and hexadecimal offsets are
reached by using the offset to additional information field in format
TCPA0100.</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Offset to list of internet addresses</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Number of internet addresses</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Entry length for list of internet addresses</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">DNS protocol</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Retries</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Time interval</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Search order</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Initial domain name server</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">DNS listening port</td>
</tr>
<tr>
<td align="left" valign="top">CHAR(64)</td>
<td align="left" valign="top">Host name</td>
</tr>
<tr>
<td align="left" valign="top">CHAR(255)</td>
<td align="left" valign="top">Domain name</td>
</tr>
<tr>
<td align="left" valign="top">CHAR(1)</td>
<td align="left" valign="top">Reserved</td>
</tr>
<tr>
<td align="left" valign="top">
<img src="delta.gif" alt="Start of change">CHAR(256)<img src="deltaend.gif" alt="End of change"></td>
<td align="left" valign="top">Domain search list</td>
</tr>
</table>
<br>
<br>
<p><strong>List of Internet Addresses.</strong> These fields repeat for each
Domain Name Server (DNS) Internet address.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%">CHAR(15)</td>
<td align="left" valign="top" width="60%">Internet address</td>
</tr>
<tr>
<td align="center" valign="top">15</td>
<td align="center" valign="top">F</td>
<td align="left" valign="top">CHAR(1)</td>
<td align="left" valign="top">Reserved</td>
</tr>
<tr>
<td align="center" valign="top">16</td>
<td align="center" valign="top">10</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Internet address binary</td>
</tr>
<tr>
<td align="center" valign="top">20</td>
<td align="center" valign="top">14</td>
<td align="left" valign="top">&nbsp;</td>
<td align="left" valign="top">&nbsp;</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA0300_FIELD"></a>Field Descriptions</h3>
<p><strong>DNS listening port.</strong> The remote TCP/IP port number used to
contact the Domain Name Server (DNS) or Servers listed in the Internet address
parameter. 53 is the well-known port used for this purpose.</p>
<p><strong>Note:</strong> Use of a TCP/IP port number other than the well-known
port 53 for use by the Domain Name Server (DNS) can result in TCP/IP
communication problems. You may inadvertently use a port number that is
reserved for use by another TCP/IP application.</p>
<p>The default DNS Listening port is 53. Valid values range from 1 to
65532.</p>
<p><strong>DNS protocol.</strong> The TCP/IP protocol used to communicate with
the Domain Name Server (DNS) specified in the Internet address parameter. User
Datagram Protocol (UDP) typically is used for this purpose. Use TCP only if
your Domain Name Server (DNS) is specifically configured to use the
Transmission Control Protocol (TCP). Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Use of the User Datagram Protocol (UDP) to
communicate with the Domain Name Server or Servers.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Use of the Transmission Control Protocol (TCP) to
communicate with the Domain Name Server or Servers.</td>
</tr>
</table>
<p><strong>Domain name.</strong> The name of the TCP/IP domain of which this
system is a member.</p>
<p><strong>Domain search list.</strong> The TCP/IP domains to be searched
whenever a host name is not given as a Fully Qualified Domain Name (FQDN). Up
to six domains may be specified, separated by spaces. The list is null
terminated.</p>
<p><strong>Entry length for list of internet addresses.</strong> The entry
length in bytes of each element in the list of Domain Name Server (DNS)
Internet addresses returned with this format. A value of zero is returned if
the list is empty.</p>
<p><strong>Host name.</strong> The TCP/IP host name of this system. This field
returns the value specified by the CHGTCPDMN command, and is the preferred
system name if the system has more than one name corresponding to multiple
interfaces.</p>
<p><strong>Note:</strong> This system's TCP/IP host name must also be defined
in the local host table or the Domain Name Server (DNS) specified in the
Internet address parameter. If no Domain Name Server (DNS) is specified, the
local TCP/IP host table is used.</p>
<p><strong>Initial domain name server.</strong> How the initial Domain Name
Server (DNS) is chosen when doing a name lookup. The first configured server
can always be queried first, or TCP/IP can rotate through the configured
servers in a round-robin fashion to provide a form of load balancing on the
servers. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">First. Do not rotate through the configured
Domain Name Servers (DNS); always start with the first one. This setting is the
default.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Rotate. Rotate through the configured Domain Name
Servers (DNS) in a round-robin fashion to choose the first one to query.</td>
</tr>
</table>
<p><strong>Internet address.</strong> The IP address of a Domain Name Server
(DNS) to be used by this system. There may be zero, one, two, or three Domain
Name Server (DNS) Internet addresses.</p>
<p>If the first Domain Name Server (DNS) in the list does not respond, the
second DNS server in the list will be contacted. If the second DNS server does
not respond, the third DNS server will contacted, and so on.</p>
<p>This field is specified in dotted-decimal form.</p>
<p><strong>Internet address binary.</strong> The binary representation of a
Domain Name Server (DNS) IP address.</p>
<p><strong>Number of internet addresses.</strong> The number of elements in the
list of Domain Name Server (DNS) Internet addresses returned with this format.
A value of zero is returned if the list is empty.</p>
<p><strong>Offset to list of internet addresses.</strong> The offset from the
beginning of the receiver variable, in bytes, to the first element in the list
of Domain Name Server (DNS) Internet addresses returned with this format. A
value of zero is returned if the list is empty.</p>
<p><strong>Retries.</strong> The number of additional attempts made to
establish communication with each Domain Name Server (DNS), in the event the
first attempt fails.</p>
<p>The default number of retries is 2. Valid values range from 0 to 99.</p>
<p><strong>Search order.</strong> Whether to search a Domain Name Server (DNS)
first to resolve a TCP/IP host name conflict, or to search the local TCP/IP
host table first.</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Local - This system will first search the TCP/IP
host table, located on this system, to resolve TCP/IP host names.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Remote - This system will search a remote or
local Domain Name Server (DNS) to resolve TCP/IP host names before searching
the local TCP/IP host table. The Domain Name Server (DNS) to use is specified
by the Internet Address parameter. This is the default value.</td>
</tr>
</table>
<p><strong>Time interval.</strong> The length of time in seconds this system
will wait before initiating a retry attempt to connect to a DNS server. The
default time interval is 2 seconds. Valid values range from 0 to 99.</p>
<br>
<h3><a name="TCPA1100">TCPA1100
Format</a></h3>
<p>This format returns information regarding the status of the TCP/IPv6 stack.
For detailed descriptions of the fields in the table, see <a href=
"#TCPA1100_FIELD">Field Descriptions</a>.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%">BINARY(4)</td>
<td align="left" valign="top" width="60%">Bytes returned</td>
</tr>
<tr>
<td align="center" valign="top">4</td>
<td align="center" valign="top">4</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Bytes available</td>
</tr>
<tr>
<td align="center" valign="top">8</td>
<td align="center" valign="top">8</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP/IPv6 stack status</td>
</tr>
<tr>
<td align="center" valign="top">12</td>
<td align="center" valign="top">C</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Offset to additional information</td>
</tr>
<tr>
<td align="center" valign="top">16</td>
<td align="center" valign="top">10</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Length of additional information</td>
</tr>
<tr>
<td align="center" valign="top">20</td>
<td align="center" valign="top">14</td>
<td align="left" valign="top">&nbsp;</td>
<td align="left" valign="top">&nbsp;</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA1100_FIELD"></a>Field Descriptions</h3>
<p><strong>Bytes available.</strong> The number of bytes of data available to
be returned. All available data is returned if enough space is provided.</p>
<p><strong>Bytes returned.</strong> The number of bytes of data returned.</p>
<p><strong>Length of additional information.</strong> The length in bytes of
additional information returned that is not part of format TCPA1100.</p>
<p><strong>Offset to additional information.</strong> The offset from the
beginning of the receiver variable, in bytes, to the start of the next format
if format TCPA1200
<img src="delta.gif" alt="Start of change">or format TCPA1300<img src="deltaend.gif" alt="End of change">
is requested. This field allows expansion of the basic
information. A value of zero is returned if only the TCPA1100 format is
requested.</p>
<p><strong>TCP/IPv6 stack status.</strong> The current status of the system
TCP/IPv6 stack. Possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Inactive - The TCP/IPv6 stack is not
operational.</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Active - The TCP/IPv6 stack is operational.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Starting - The TCP/IPv6 stack not operational,
but is in the process of starting.</td>
</tr>
<tr>
<td align="left" valign="top"><em>3</em></td>
<td align="left" valign="top">Ending, immediate - The TCP/IPv6 stack is
operational, but is in the process of ending.</td>
</tr>
<tr>
<td align="left" valign="top"><em>4</em></td>
<td align="left" valign="top">Ending, controlled - The TCP/IPv6 stack is
operational, but is in the process of ending.</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA1200"></a>TCPA1200 Format</h3>
<p>This format returns detailed information about the TCP/IPv6 stack attributes
in addition to the TCP/IPv6 stack status (format TCPA1100). For detailed
descriptions of the fields in the table, see <a href="#TCPA1200_FIELD">Field
Descriptions</a>.
<img src="delta.gif" alt="Start of change">As of V5R4, this format is being
replaced with TCPA1300 and should no longer be used.<img src="deltaend.gif" alt="End of change"></p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%"><br>
</td>
<td align="left" valign="top" width="60%">Returns everything from format
TCPA1100</td>
</tr>
<tr>
<td valign="top" colspan="2" rowspan="16">Decimal and hexadecimal offsets are
reached by using the offset to additional information field in format
TCPA1100.</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">ICMP error message send rate time</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Router solicitation max delay</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Router solicitation interval</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Router solicitation max transmits</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Neighbor advertisement max transmits</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Neighbor solicitation delay first probe time</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Neighbor solicitation max unicast solicits</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Neighbor solicitation max multicast solicits</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP keep alive</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP urgent pointer</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP receive buffer size</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP send buffer size</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP R1 retransmission count</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP R2 retransmission count</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP closed timewait timeout</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">TCP minimum retransmission timeout</td>
</tr>
</table>
<br>
<br>
<h3><a name="TCPA1200_FIELD">Field Descriptions</a></h3>
<p><strong>ICMP error message send rate time.</strong> The current value of the
ICMP error message send rate time attribute, in milliseconds. The ICMP error
message send rate time attribute controls how often ICMPv6 error messages will
be sent out by the system. This control mechanism allows the bandwidth and
forwarding costs of sending ICMPv6 error messages to be limited, as in the case
of many ICMPv6 error messages being generated in response to another host
sending a stream of erroneous packets. The default ICMP error message send rate
time is 1000 milliseconds (1 second). Valid values range from 10 through 5000
milliseconds (5 seconds).</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Neighbor advertisement max transmits.</strong> The current value of
the TCP/IPv6 stack Neighbor advertisement max transmits attribute. The Neighbor
advertisement max transmits attribute is specified as a number of
transmissions, and is the maximum number of unsolicited Neighbor Advertisements
that the system will send at a time. The system might send unsolicited Neighbor
Advertisements when one of its link-layer addresses changes (for example, hot-swap
of a physical interface card). The default value of the
Neighbor advertisement max transmits attribute is 3 transmissions. Valid values
range from 1 through 5 transmissions.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Neighbor solicitation delay first probe time.</strong> The current
value of the configured Neighbor solicitation delay first probe time attribute.
This attribute controls how long a Neighbor Cache entry will stay in the DELAY
state before the stack will send another Neighbor Solicitation and move the
Neighbor Cache entry's Reachability state to PROBE if reachability still has
not been confirmed. The default Neighbor solicitation delay first probe time is
5 seconds. Valid values range from 3 through 10 seconds.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Neighbor solicitation max multicast solicits.</strong> The current
value of the configured Neighbor solicitation max multicast solicits stack
attribute. This attribute controls the maximum number of multicast Neighbor
Solicitations which will be sent out when the system is performing link-layer
address resolution for another host (neighbor). If no Neighbor Advertisement is
received after the maximum number of Neighbor Solicitations have been sent out,
address resolution has failed, and an ICMPv6 error message will be returned to
the application. The default value of the Neighbor solicitation max multicast
solicits attribute is 3 transmissions. Valid values range from 1 through 5
transmissions.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Neighbor solicitation max unicast solicits.</strong> The current
value of the configured Neighbor solicitation max unicast solicits stack
attribute. This attribute controls the maximum number of unicast Neighbor
Solicitations which will be sent out when the system is performing link-layer
address resolution for another host with unicast Neighbor Solicitations.
Multicast is the normal way to perform Neighbor Discovery, but unicast Neighbor
Solicitations will be used if the local physical interface is not
multicast-capable. If no Neighbor Advertisement is received after the maximum
number of Neighbor Solicitations have been sent out, address resolution has
failed, and an ICMPv6 error message will be returned to the application. The
default Neighbor solicitation max unicast solicits value is 3 transmissions.
Valid values range from 1 through 5 transmissions.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Router solicitation interval.</strong> The Router solicitation
interval is the amount of time, in seconds, to wait between sending Router
Solicitations while waiting for a Router Advertisement in reply. The default
Router solicitation interval is 4 seconds. Valid values range from 2 through 5
seconds.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Router solicitation max delay.</strong> The Router solicitation max
delay attribute is the amount of time, in milliseconds, to wait for a Router
Advertisement reply after sending the last Router Solicitation. This attribute
is also used to calculate when to send the first Router Solicitation. To avoid
congestion on a link when many hosts start up at the same time (such as after a
power failure), the system will wait Router soliciation max delay seconds
before sending the first Router Solicitation. The default Router soliciation
max delay is 1000 milliseconds. Valid values range from 500 through 3000
milliseconds.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>Router solicitation max transmits.</strong> The maximum number of
Router Solicitations to transmit. If no Router Advertisements are received in
response to the transmitted Router Solicitations, the system concludes that
there is no IPv6 router on its link. The default Router solicitation max
transmits value is 3 transmissions. Valid values range from 1 through 5
transmissions.</p>
<p><img src="delta.gif" alt="Start of change"><strong>Note:</strong>
As of V5R4, this data is no longer available and is defaulted
to 0.<img src="deltaend.gif" alt="End of change"></p>
<p><strong>TCP closed timewait timeout.</strong> The amount of time, in
seconds, for which a socket pair (client IP address and port, server IP address
and port) cannot be reused after a connection is closed. The maximum value
possible is 2 MSL (maximum segment lifetime). The default value is 120 seconds.
Valid values range from 0 (no timer) to 14400 seconds (240 minutes).</p>
<p><strong>TCP keep alive.</strong> The amount of time, in minutes, that TCP
waits before sending out a probe to the other side of a connection. The probe
is sent when the connection is otherwise idle, even when there is no data to be
sent.</p>
<p>The transmission of keep-alive packets is controlled by individual sockets
applications through use of the SO_KEEPALIVE socket option. For more
information, <a href="../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in
the iSeries Information Center.</p>
<p>The default keep-alive time interval is 120 minutes. Valid values range from
1 through 40320 minutes (28 days).</p>
<p><strong>TCP minimum retransmission timeout.</strong> The current value of
the configurable TCP minimum retransmission timeout attribute, in milliseconds.
This attribute specifies the amount of time that TCP will wait for an
acknowledgement (ACK) of a packet. When this amount of time has passed without
an acknowledgement, TCP will perform the first retransmission of the packet.
The default TCP minimum retransmission timeout is 250 milliseconds. Valid
values range from 100 through 1000 milliseconds.</p>
<p><strong>TCP R1 retransmission count.</strong> The R1 retransmission count
value. The default value is 3. Valid values range from 1 to 15, and R1 must be
less than R2.</p>
<p><strong>TCP R2 retransmission count.</strong> The R2 retransmission count
value. The default value is 16. Valid values range from 2 to 16, and R2 must be
greater than R1.</p>
<p><strong>TCP receive buffer size.</strong> The TCP receive buffer size in
bytes. The TCP receive window size is based on this value. Decreasing this
value decreases the amount of data that the remote system can send before being
read by the local application. Decreasing this value may improve performance in
situations where many retransmissions occur due to the overrunning of a network
adapter.</p>
<p><strong>Notes:</strong></p>
<ol>
<li>User Datagram Protocol (UDP) does not have a configurable receive buffer
size.</li>
<li>This value is also used as the default receive buffer size by IP over SNA
processing.</li>
<li>Setting this parameter does not guarantee the size of the TCP receive
buffer. This is the default buffer size that is used for initial TCP connection
negotiations. An individual application can override this value by using the
SO_RCVBUF socket option. For more information, see <a href=
"../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in the iSeries
Information Center.</li>
</ol>
<p>The default TCP receive buffer size is 8192 (8K) bytes. Valid values range
from 512 through 8388608 (8MB) bytes.</p>
<p><strong>TCP send buffer size.</strong> The TCP send buffer size in bytes.
This parameter informs TCP what to use for the default send buffer size. The
TCP send buffer size provides a limit on the number of outgoing bytes that are
buffered by TCP. Once this limit is reached, attempts to send additional bytes
may result in the application blocking until the number of outgoing bytes
buffered drops below this limit. The number of outgoing bytes buffered is
decremented when the remote system acknowledges the data sent.</p>
<p><strong>Notes:</strong></p>
<ol>
<li>This value is used also as the default send buffer size by IP over SNA
processing.</li>
<li>UDP does not have a configurable send buffer size.</li>
<li>Setting this parameter does not guarantee the size of the TCP send buffer.
This is the default buffer size that is used for initial TCP connection
negotiations. An individual application can override this value by using the
SO_SNDBUF socket option. For more information, see <a href=
"../rzab6/rzab6soxoverview.htm">Sockets Programming</a> in the iSeries
Information Center.</li>
</ol>
<p>The default TCP send buffer size is 8192 (8K) bytes. Valid values range from
512 through 8388608 (8M) bytes.</p>
<p><strong>TCP urgent pointer.</strong> The convention to follow when
interpreting which byte the urgent pointer in the TCP header points to. The
urgent pointer in the TCP header points to either the byte immediately
following the last byte of urgent data (BSD convention) or the last byte of the
urgent data (RFC convention).</p>
<p><strong>Note:</strong> This value must be consistent between the local and
remote ends of a TCP connection. Socket applications that use this value must
use it consistently between the client and server applications. This value is
set on a system basis. All applications using this system will use this value.
The possible values are:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Use the BSD defined convention. The TCP urgent
pointer points to the byte immediately following the last byte of urgent data.
This is the default value.</td>
</tr>
<tr>
<td align="left" valign="top"><em>2</em></td>
<td align="left" valign="top">Use the RFC defined convention. The TCP urgent
pointer points to the last byte of the urgent data.</td>
</tr>
</table>
<br>
<h3><img src="delta.gif" alt="Start of change"><a name="TCPA1300"></a>TCPA1300 Format</h3>
<p>This format returns information regarding the status of the TCP/IPv6 stack.
For detailed descriptions of the fields in the table, see
<a href="#TCPA1300_FIELD">Field Descriptions</a>.</p>
<table border width="80%">
<tr>
<th align="center" valign="bottom" colspan="2">Offset</th>
<th align="left" valign="bottom" rowspan="2">Type</th>
<th align="left" valign="bottom" rowspan="2">Field</th>
</tr>
<tr>
<th align="center" valign="bottom">Dec</th>
<th align="center" valign="bottom">Hex</th>
</tr>
<tr>
<td align="center" valign="top" width="10%">0</td>
<td align="center" valign="top" width="10%">0</td>
<td align="left" valign="top" width="20%"><br>
</td>
<td align="left" valign="top" width="60%">Returns everything from format
TCPA1100</td>
</tr>
<tr>
<td valign="top" colspan="2" rowspan="16">Decimal and hexadecimal offsets are
reached by using the offset to additional information field in format
TCPA1100.</td>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Address selection preference</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">ICMP error message burst limit</td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">ICMP error message send rate </td>
</tr>
<tr>
<td align="left" valign="top">BINARY(4)</td>
<td align="left" valign="top">Hop limit</td>
</tr>
</table>
<h3><a name="TCPA1300_FIELD">Field Descriptions</a></h3>
<p><strong>Address selection preference.</strong> 6to4 address or a native IPv6
address if both are available on both the local and remote host. Possible values are:</p>
<table cellpadding="5">
<tr>
<td align="left" valign="top"><em>0</em></td>
<td align="left" valign="top">Prefer Native</td>
</tr>
<tr>
<td align="left" valign="top"><em>1</em></td>
<td align="left" valign="top">Prefer 6to4</td>
</tr>
</table>
<p><strong>Hop limit.</strong> The configured IPv6 Hop Limit value specified for
all physical interfaces. The Hop limit field is the IPv6 replacement for the
IPv4 Time to live (TTL) field. The Hop limit value specifies a relative limit on
the number of hops across which an IPv6 datagram remains active. The Hop limit
value is hop count that is decremented by each gateway to prevent internet routing
loops. The default Hop limit value is 64. Valid values range from 1 through 255 hops.</p>
<p><strong>ICMP error message burst limit.</strong> The maximum number of ICMP error messages
sent in a burst. The default value is 10. Valid values range from 1 through 255.</p>
<p><strong>ICMP error message send rate.</strong> The average rate limit of sending
ICMP error messages in packets/second. The default value is 10. Valid values
range from 1 through 255.<img src="deltaend.gif" alt="End of change"></p>
<h3>Error Messages</h3>
<table width="100%" cellpadding="5">
<!-- cols="15 85" -->
<tr>
<th align="left" valign="top">Message ID</th>
<th align="left" valign="top">Error Message Text</th>
</tr>
<tr>
<td width="15%" valign="top">TCP84C6 E</td>
<td width="85%" valign="top">Internal operations error - RESULT &amp;1 CC &amp;2 RC &amp;3
ERRNO &amp;4.</td>
</tr>
<tr>
<td align="left" valign="top">CPF24B4 E</td>
<td align="left" valign="top">Severe error while addressing parameter
list.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C19 E</td>
<td align="left" valign="top">Error occurred with receiver variable
specified.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C21 E</td>
<td align="left" valign="top">Format name &amp;1 is not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C24 E</td>
<td align="left" valign="top">Length of the receiver variable is not
valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C90 E</td>
<td align="left" valign="top">Literal value cannot be changed.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3CF1 E</td>
<td align="left" valign="top">Error code parameter not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF8100 E</td>
<td align="left" valign="top">All CPF81xx messages could be returned. xx is
from 01 to FF.</td>
</tr>
<tr>
<td align="left" valign="top">CPF9872 E</td>
<td align="left" valign="top">Program or service program &amp;1 in library
&amp;2 ended. Reason code &amp;3.</td>
</tr>
</table>
<br>
<hr>
API introduced: V5R1
<hr>
<table cellpadding="2" cellspacing="2" align="center">
<tr align="center">
<td valign="middle" align="center"><a href="#Top_Of_Page">Top</a> | <a href=
"comm.htm">Communications APIs</a> | <a href="aplist.htm">APIs by category</a>
</td>
</tr>
</table>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink