Communications Server

Network Administration Guide


Chapter 3. Planning for AnyNet Support

Communications Server allows for two types of AnyNet support:

The AnyNet SNA over TCP/IP function in Communications Server enables SNA applications to communicate over interconnected IP and SNA networks.

The SNA over TCP/IP access node function enables SNA applications residing on an IP network to communicate. This function supports independent LU 6.2 and dependent LU 0, 1, 2, 3, or 6.2 either with or without dependent LU requester (DLUR). In addition, the SNA over TCP/IP access node can be used in conjunction with SNA gateway to enable SNA gateway sessions over TCP/IP.

The SNA over TCP/IP gateway function extends the reach of SNA applications by enabling SNA applications in an SNA network to communicate with SNA applications in an IP network. The SNA over TCP/IP gateway supports independent LU 6.2 sessions.

For more information on how to configure AnyNet SNA over TCP/IP, see Configuring AnyNet SNA over TCP/IP.

The Sockets over SNA access node function enables TCP/IP application programs using the WinSock 1.1 and WinSock 2.0 socket interface to communicate over an SNA network.

The Sockets over SNA gateway function enables sockets applications in SNA and TCP/IP networks to communicate. Sockets over SNA gateways are often used to connect isolated TCP/IP networks using an SNA backbone network.

Refer to Configuring AnyNet Sockets over SNA for more information about configuring Sockets over SNA.


Configuring AnyNet SNA over TCP/IP

This section contains detailed information about configuring AnyNet SNA over TCP/IP.

Mapping SNA Resources to IP Addresses

One of the most crucial steps to enable SNA over TCP/IP communication is not done through Communication Server panels. Before SNA sessions or connections can be established, SNA over TCP/IP must determine the IP address of the partner. This is achieved by mapping the SNA identifier of the partner to an IP address using the following steps:

  1. SNA over TCP/IP receives the SNA identifier from Communications Server in one of the following formats:
  2. SNA over TCP/IP takes the identifier and generates a domain name:

    Figure 20 shows examples of domain names generated by SNA over TCP/IP.

    Figure 20. Formats of the Domain Names That SNA over TCP/IP Builds


    REQTEXT

  3. SNA over TCP/IP requests that the domain name be translated to an IP address.
  4. TCP/IP uses the HOSTS file or domain name server to translate the domain name into an IP address (for example, 9.67.192.28).

When the IP network includes SNA over TCP/IP gateways, consider the following additional address mapping issues:

Defining Domain Names and IP Addresses

This section describes the TCP/IP name resolution function, used by AnyNet to map SNA resources to IP addresses. This function queries both the local HOSTS file and any domain name servers to convert a domain name (for example, lu1.neta1.sna.ibm.com) into an IP address (for example, 10.1.1.1).

HOSTS File
You can use TCP/IP HOSTS files to map domain names to IP addresses for your network. However, as your network becomes larger and maintaining the HOSTS file on each end-user workstation becomes too time-consuming, it is recommended that you use a domain name server.

The HOSTS file (in the drivers\etc subdirectory of your Windows NT system directory) lists:

For example, if your IP address is 10.1.1.1, network ID is NETA1, SNA resource name is LUA1, and SNA domain name suffix is the default (sna.ibm.com), enter the following in your HOSTS file:

  10.1.1.1     lua1.neta1.sna.ibm.com

Domain Name Server
Domain names and IP addresses can also be defined in the domain name server database.

Each SNA identifier is mapped to a corresponding IP address by a domain name server. The location of these servers is configured in the Network section of the Control Panel.

For more information on HOSTS files and domain name servers, refer to your TCP/IP documentation. If your workstation is using the TCP/IP support in Windows NT, refer to the online TCP/IP documentation that is included with the Windows NT product.

SNA over TCP/IP Gateway Considerations

The following information pertains to gateways but not to access node functions.

Defining Unique CP Names and Connection Network Names

For configurations that have two or more SNA over TCP/IP gateways connecting an SNA network with two or more IP networks, you need todefine a unique SNA control point (CP) name and a unique SNA connection network name for each IP network.

All LUs that reside on access nodes in the IP network appear to reside on a node with this CP name.

Use the reverse data file of the domain name server or the HOSTS file to define the CP name and the connection network name for a given IP network. Map the IP address 127.0.0.3 to the CP name and map the IP address 127.0.0.4 to the connection network name.

The following example shows entries in the reverse data file. For an IP network with SNA network ID NETA, CP name MYCPNAME, and connection network name MYCNET, you would define the following entries:

127.0.0.3       NETA.MYCPNAME.
127.0.0.4       NETA.MYCNET.

Notes:

  1. A period is required at the end of the name only if the definition is in the DNS reverse data file. No period is used in HOSTS file definitions.

  2. Do not include the SNA domain name suffix.

The AnyNet SNA over TCP/IP function of Communications Server provides a default CP name ($ANYNET.$GWCP) and a default connection network name ($ANYNET.$GWCNET). In configurations with one IP network, you can use the default by not defining a CP name or a connection network name. In configurations with multiple gateways connecting multiple IP networks, one IP network can use the default. You must, however, define a unique CP name and connection network name for all other IP networks.

Figure 21 shows how to define the CP name and the connection network name for a configuration with two IP networks.

Figure 21. Defining a CP Name and a Connection Network Name

REQTEXT

Using the Wildcard Entry to Reduce Domain Name Server Definitions

If you are using the SNA over TCP/IP gateway and your configuration meets the following naming restrictions, you can reduce the number of domain name server entries by defining a domain name entry for each SNA network ID that can be accessed through one or more SNA over TCP/IP gateways.

By coding a single domain name entry for each SNA network ID, you do not have to define a domain name entry for every LU in the SNA network that you want to communicate with over the IP network. You can use a wildcard entry (*) to specify the LU name of all LUs that have the same SNA network ID. By substituting a wildcard entry for the luname in the entry, you define a single domain name server entry that represents all LUs in that particular network.
Note:If you use the wildcard entry, you must use the full wildcard. Partial wildcards, such as LUA*, are not valid.

The wildcard entry is mapped to the IP address of the first SNA over TCP/IP gateway used to reach the network with that SNA network ID. As shown in Figure 22, logical units SNAAPPL1, APPC1, APPC2, and LU5 reside in network NETB and can only be reached from the IP network through an SNA over TCP/IP gateway with IP address IPgwg. If the SNA domain name suffix is SNA.IBM.COM, you define the following entry in the domain name server:

     *.NETB.SNA.IBM.COM       IPgwg

This entry is used for all four logical units.
Note:You have the option of defining each logical unit individually.

Figure 22. Domain Name Server Definitions for a Single Gateway Connected to an SNA Network with Two Network IDs

REQTEXT

Each SNA network must have a unique entry. As shown in Figure 22, if you also have SNAAPPLX, APPCX, and LUY in network NETC, which can only be reached through the SNA over TCP/IP gateway with IP address IPgwg, the domain name server entries are as follows:

     *.NETB.SNA.IBM.COM      IPgwg
     *.NETC.SNA.IBM.COM      IPgwg

In addition, each gateway must have a unique entry. If you add a parallel SNA over TCP/IP gateway, as shown in Figure 23, with IP address IPgwh to the preceding example, the domain name server entries are as follows:

     *.NETB.SNA.IBM.COM      IPgwg
     *.NETC.SNA.IBM.COM      IPgwg
     *.NETB.SNA.IBM.COM      IPgwh
     *.NETC.SNA.IBM.COM      IPgwh

Figure 23. Domain Name Server Definitions for Parallel Gateways Connected to an SNA Network with Two Network IDs

REQTEXT

SNA over TCP/IP Access Node Function Considerations

The following information pertains to access nodes only, and not to gateways.

How to Route SNA Sessions over AnyNet SNA over TCP/IP

When an SNA application initiates a session, Communications Server must first determine which transport to use - either SNA, IP, or a combination of the two.

You configure which transport you prefer by setting the routing preference. The routing preference can be set for the whole node via the default routing preference on the AnyNet over TCP/IP device or on a per LU basis when defining partner LUs.

The routing preference table is used only for new sessions. Previously existing sessions use the same transport; they are not brought down and rerouted if the routing preference table is changed.
Note:The routing preference for a node only governs sessions that are initiated from the node (access node sessions). Sessions that go through a node are not affected by the routing preference.

You can set or modify the default routing preference to one of the following:

Native first
Requests are routed over SNA. If no SNA route is available, requests are routed over TCP/IP.

Non-native first
Requests are routed over TCP/IP. If no TCP/IP route is available, requests are routed over SNA.

Native only
Requests are routed only over SNA. If no SNA route is available, the connection will fail.

Non-native only
Requests are routed only over TCP/IP. If no TCP/IP route is available, the connection will fail.

AnyNet SNA over TCP/IP Configuration Examples

This section includes examples of AnyNet enabling SNA over IP communication. The following configuration instructions are complete only for the Windows NT operating system. In all examples, the SNA domain name suffix is SNA.IBM.COM.

For more information about configuring AnyNet for any other platforms mentioned in this section (such as VTAM or AS/400), refer to the appropriate product documentation.

Example 1. Running APPC or CPI-C Applications over a TCP/IP Network



REQTEXT

Steps

Follow these steps to establish communications between the two Windows NT nodes. Note that in this example, the CP names are used as LU names.

For Node A, do as follows:

  1. Add the following entry to the local HOSTS file:
    172.25.11.2  CP2.NETA.SNA.IBM.COM
    
  2. Use NETA.CP1 as the control point name during node setup. Ensure that the routing preference is set to route sessions over TCP/IP. Refer to the SNA Node Configuration help panels for more information.

For Node B, do as follows:

  1. Add the following entry to the local HOSTS file:
    172.25.11.1  CP1.NETA.SNA.IBM.COM
    
  2. Use NETA.CP2 as the control point name during node setup. Ensure that the routing preference is set to route sessions over TCP/IP. Refer to the SNA Node Configuration help panels for more information.

Example 2. 3270 Emulation via DLUR over a TCP/IP Network



REQTEXT

Steps

Follow these steps to establish communications between Node A and Node B.

For Node B, do as follows:

  1. Add the following entry to the local HOSTS file:
            192.168.7.8   CP1.NETA.SNA.IBM.COM
    
  2. Use NETA.CP2 as the control point name during node setup and NETA.CP1 as the DLUS name when configuring DLUR PUs. Ensure that the routing preference is set to route sessions over TCP/IP. Refer to the SNA Node Configuration help panels for more information.

For Node A, add the following entries to the HOSTS file:

192.168.7.10   CP2.NETA.SNA.IBM.COM
192.168.7.10   DEPLU1.NETA.SNA.IBM.COM

Note that MVS AnyNet SNA over TCP/IP currently requires DLUS/DLUR for dependent LU communication.

Example 3. Using an SNA Gateway to Enable 3270 Emulation Between SNA and TCP/IP Networks




REQTEXT

Steps

Follow these steps to establish communications between Node B and the VTAM host.

For Node A, do as follows:

  1. Add the following entry to the local HOSTS file:
    172.16.5.6 05D57BF2.SNA.IBM.COM
    
  2. Use NETA.CP2 as the control point name during node setup and use ANYNET device to assign implicit templates when defining clients. Refer to the SNA Node Configuration help panels for more information.

For Node B, add the following to the local HOSTS file:

172.16.3.4  CP2.NETA.SNA.IBM.COM

Example 4. Using an SNA Gateway for 3270 Emulation over a TCP/IP Network




REQTEXT

Steps

Follow these steps to establish communications between Node C and Node A.

For Node B, do as follows:

  1. Add the following entry to the local HOSTS file:
    10.1.1.3  CP1.NETA.SNA.IBM.COM
    
  2. Use NETA.CP2 as the control point name during node setup, NETA.CP1 as the adjacent CP name when defining the AnyNet SNA over TCP/IP connection definition, and NETA.CP3 as the DLUS name when assigning the DLUS to a client template. Ensure that routing preference is set to non-native for NETA.CP3. Refer to the SNA Node Configuration help panels for more information.

For Node C, do as follows:

  1. Add the following entry to the HOSTS file:
        10.1.1.2    CP2.NETA.SNA.IBM.COM
    
  2. Use NETA.CP1 as the control point name during node setup, and NETA.CP2 as the adjacent CP name when defining the AnyNet SNA over TCP/IP connection definition. Refer to the SNA Node Configuration help panels for more information.

For Node A, add the following entry to the HOSTS file:

        10.1.1.2   CP2.NETA.SNA.IBM.COM
        10.1.1.2   DEPLU1.NETA.SNA.IBM.COM

Example 5. 3270 Emulation from Two Windows NT Workstations on Different IP Networks




REQTEXT

Steps

Follow these steps to establish communications from the Nodes A and D to Node E.

For Node A, do as follows:

  1. Add the following entries to the local HOSTS file:
            10.2.4.8    CP5.NETB.SNA.IBM.COM
            127.0.0.4   IPNET1.GWCNET
            127.0.0.3   IPNET1.CP1
    
  2. Use NETA.CP1 as the control point name during node setup, and NETB.CP5 as the DLUS name when configuring DLUR PUs. Ensure that the routing preference for NETB.CP5 is set to non-native. Refer to the SNA Node Configuration help panels for more information.

For Node B, add the following entries to the HOSTS file:

        10.2.4.6    CP1.NETA.SNA.IBM.COM
        127.0.0.2   DEPLU1.NETA.SNA.IBM.COM
        10.2.4.6    DEPLU1.NETA.SNA.IBM.COM
        127.0.0.4   IPNET1.GWCNET
        127.0.0.3   IPNET1.CP1

For Node C, add the following entries to the HOSTS file:

        172.20.1.2  CP4.NETC.SNA.IBM.COM
        127.0.0.2   DEPLU2.NETC.SNA.IBM.COM
        172.20.1.2  DEPLU2.NETC.SNA.IBM.COM
        127.0.0.4   IPNET2.GWCNET
        127.0.0.3   IPNET2.CP2

For Node D, do as follows:

  1. Add the following entry to the local HOSTS file:
            172.20.1.1  CP5.NETB.SNA.IBM.COM
            127.0.0.4   IPNET2.GWCNET
            127.0.0.3   IPNET2.CP2
    
  2. Use NETC.CP4 as the control point name during node setup, and NETB.CP5 as the DLUS name when configuring DLUR PUs. Ensure that the routing preference for NETB.CP5 is set to non-native. Refer to the SNA Node Configuration help panels for more information.

Helpful Hints

This section contains helpful hints on tuning, TCP/IP connectivity via SLIP or PPP, and dynamic IP addresses.

Tuning

If you can access an LU through multiple SNA over TCP/IP gateways, and you have mapped that LU name to multiple IP addresses, increase the CONN_RETRY_SECS and CONNWAIT_SECS parameters of the ANYNET_COMMOM_PARAMETERS keyword when configuring the AnyNet base parameters. This ensures that TCP connections will be attempted to all possible adapters and gateways. It can take as long as 90 seconds for a TCP connection to fail to an inactive IP address.

Dynamic IP addresses

Generally, AnyNet SNA over TCP/IP depends on SNA resources (for example, LU names, CP names, or idblk/num) being statically mapped to IP addresses. However, depending on your configuration and how your connections are initiated, you might be able to use AnyNet SNA over TCP/IP in environments where IP addresses are dynamically assigned (for example, DHCP).

APPC or CPIC Applications

An SNA over TCP/IP access node with a dynamically assigned IP address may always initiate sessions to another SNA over TCP/IP access node or gateway with a static IP address.

The only way an SNA over TCP/IP access node or gateway with a static IP address (node A) can initiate a session to a partner with a dynamic IP address (node B) is:

  1. Node B initiated a session to or through node A first.
  2. The session initiated in Step 1 is still active.

Dependent LU Applications
Note:The information in this section applies to LU 0, 1, 2, 3, or dependent 6.2 applications.

SNA over TCP/IP access nodes with dynamically assigned IP addresses can support dependent LU communications if the following criteria are met:

Dependent LU communication through DLUS/DLUR over AnyNet SNA over TCP/IP is not supported if the DLUR node has a dynamically assigned IP address.


Configuring AnyNet Sockets over SNA

This section contains information about how to configure Sockets over SNA.

The Sockets over SNA access node function of Communications Server enables WinSock compliant applications to communicate over SNA networks. The Sockets over SNA gateway function enables socket applications in SNA and IP networks to communicate.

How Does Sockets over SNA Work?

Figure 24 shows the structure of a Windows NT node that is running Sockets over SNA and illustrates how socket application programs and Sockets over SNA operate on a Windows NT node.

Figure 24. Structure of a Windows NT Node Running Sockets over SNA


REQTEXT

WinSock is an API that lets socket applications run in a Windows environment.

Sockets over SNA does not provide a WinSock interface and does not process socket calls. Instead, WinSock applications use the WinSock interface of the native TCP/IP stack. The Sockets over SNA gateway code enables these applications to communicate across the SNA network.

Sockets over SNA gateway will allow socket applications running in an IP network to communicate with socket applications running on Sockets over SNA nodes. This is accomplished by routing packets between the SNA and IP networks and transforming them between SNA and IP protocols. The AnyNet gateway device driver assists in routing packets between TCP/IP and SNA networks, and the Sockets over SNA code converts between the two protocols.

Generating an LU 6.2 Call from a Socket Call

To enable TCP/IP-formatted information to route over SNA, Sockets over SNA maps IP addresses to SNA network-qualified LU names. When an application program invokes Sockets over SNA to establish a stream connection with another application program, Sockets over SNA establishes two half-duplex LU 6.2 conversations for the stream connection.

Sockets over SNA establishes one LU 6.2 conversation for all datagrams sent to a single destination. Conversations dedicated to datagram traffic are deallocated if they are unused for some specified period of time.

Mapping an IP Address to an SNA Network-Qualified Name

When an application program invokes Sockets over SNA to communicate with another application program, it supplies the IP address of the destination node. Sockets over SNA must map the IP address to an SNA address to issue an appropriate LU 6.2 call. For every IP address that identifies a node, there will be a corresponding SNA network-qualified name.

Routing and Mapping Overview explains how address mapping works and provides guidelines and requirements for setting up IP-LU address mapping.

Routing and Mapping Data over SNA and IP Networks

Sockets over SNA gateways enable communication between socket application programs in IP and SNA networks by combining the routing function of TCP/IP with the protocol translation and address mapping capabilities of Sockets over SNA.

Protocol translation and address mapping are required when data is routed between nodes that use different transport protocols. The Sockets over SNA gateway automatically performs protocol translation after determining the type of transport associated with the destination IP address. For a summary of the routing and mapping process, see How the Sockets over SNA Gateway Routes and Maps Data.

Application Program Support Provided by Sockets over SNA

Sockets over SNA supports WinSock 1.1 and WinSock 2.0 (Windows NT 4.0 only) applications that use AF_INET sockets.

Sockets over SNA does not support applications that use broadcasting.

If you intend to use Sockets over SNA gateway to route information to and from an MVS/ESA node configured with the VTAM V3R4.2 Sockets over SNA function, you must first install the route function on the MVS/ESA node. To install the route function on MVS/ESA, install the program temporary fix (PTF) UW03567. You can obtain PTFs through any of the following sources:

If you do not have access to these sources, contact the IBM Support Center.

Planning for Sockets over SNA

This section describes what the network planner should consider before configuring a network with Sockets over SNA.

Routing and Mapping Overview

This section explains basic concepts of Internet addressing and how these concepts relate to routing and mapping. It includes the following information:

Internet Addressing

Every host is assigned at least one unique Internet Protocol (IP) address, which is used to route data through the network.

Note:In the IP suite of protocols, host refers to an end system and can be any workstation; it does not have to be a mainframe.

The IP address assigned to the host does not define a host on the network; it defines a network interface on that host to a network. For example, the address of the SNA network interface identifies a node's connection to the SNA network.

A gateway host has a unique IP address for each network interface. Because Sockets over SNA gateway routes SNA and TCP/IP data, you must set up unique IP addresses for the TCP/IP and SNA interfaces.

The following section describes the IP address format, address classes, and network masks. For more detailed information, see your TCP/IP documentation.

IP Address Format and Classes

An IP address consists of a 2-part, 32-bit address field:

Default network masks are shown in Table 5.

Table 5. IP Address Masks Supported by Sockets over SNA
For a dotted decimal IP address in the form a.b.c.d, the range of values for a is:   Default Network Mask
1-127 255.0.0.0
128-191 255.255.0.0
192-223 255.255.255.0

Masks Used by Sockets over SNA

Sockets over SNA uses two types of masks:

IP Routing Table

Each host has an IP routing table that stores information about possible destinations and how to reach them. Route entries are added when:

For a routing table example, see Figure 25.

SNA Network ID Used by Sockets over SNA

For each route you define through the SNA interface (sna0), there must be a corresponding SNA network ID to which the IP network address is mapped. The number of SNA network IDs you define depends on how you want to map the IP network to the SNA network.

For example, if the socket applications using SNA are configured to use IP subnetworks 9.67.0.0 and 9.77.0.0, you can define an SNA network ID that corresponds to each IP subnetwork, or you can define one SNA network ID that corresponds to both subnetworks. Sockets over SNA does not require a unique one-to-one mapping between an IP network address and an SNA network ID.

How an IP Address Is Mapped to an LU Name

You can use either explicit or generated mapping to map IP addresses to SNA LU names:

How the Sockets over SNA Gateway Routes and Maps Data

The following steps briefly describe how Sockets over SNA Gateway determines whether to route data over SNA or TCP/IP, and how address mapping is handled:

  1. Sockets over SNA searches its routing table to find a route that enables data to reach the destination IP address. If Sockets over SNA does not find any matching routes, the connection request is forwarded to the native TCP/IP stack.
  2. If Sockets over SNA finds a matching route, the route entry indicates how the destination can be reached:
    1. If the router address is the address of a local network interface, such as sna0, the destination network, subnetwork, or host address can be reached directly.
    2. If the router address is the address of a gateway or router, the destination can only be reached through that intermediate gateway or router.

    Figure 25 shows an example of an IP routing table.

    Figure 25. Example of an IP Routing Panel

    +--------------------------------------------------------------------------------+
    |Destination IP Address    Destination Mask    Gateway IP Address   Use Count    |
    |----------------------------------------------------------------------------    |
    |1.2.3.4                   255.255.255.255     199.245.253.1        10           |
    |10.0.0.0                  255.0.0.0           199.245.253.2        0            |
    |10.11.0.0                 255.255.0.0         199.245.253.113      37           |
    |127.0.0.1                 255.255.255.255     127.0.0.1            8            |
    |128.1.0.0                 255.255.0.0         199.245.253.3        0            |
    |199.245.253.0             255.255.255.0       199.245.253.113      368          |
    +--------------------------------------------------------------------------------+
  3. If no route is found in the Sockets over SNA routing table, then Sockets over SNA assumes that the TCP/IP destination can be reached through a native IP network. Refer to your TCP/IP documentation for more information on how TCP/IP routes data.
  4. If the chosen route indicates that data should go over the SNA interface (sna0), Sockets over SNA looks up the next-hop address in the IP-LU mapping table:
    1. If Sockets over SNA finds a matching entry, an LU 6.2 connection is established.
    2. If Sockets over SNA does not find a matching entry, the connection attempt fails.
    3. Sockets over SNA passes the destination address and data to Communications Server.
  5. All routes defined to Sockets over SNA are mirrored to the native TCP/IP stack so that packets from IP can be routed over SNA.

Route Discovery Function

The route discovery function provided by Sockets over SNA gateway can help you route TCP/IP traffic more efficiently and reduce the number of explicitly defined route statements in your network. You do not have to select or configure this function.

One of the problems with large networks is how to discover the addition of new networks or subnetworks and which router to use to get to the new network or subnetwork. Sockets over SNA solves this problem by having all nodes initially use a default router that notifies other nodes when a more direct route is discovered. This is more efficient than using the typical TCP/IP solution of broadcasting routing information.
Note:To effectively use this function, algorithmic mapping of IP addresses to LU names and an APPN backbone network should be used. Otherwise, nodes must explicitly define LU names and IP addresses for all remote nodes with which they communicate.

Figure 26 shows a configuration example.

Figure 26. Example of a Network Using the Sockets over SNA Route Discovery Function


REQTEXT

In this scenario:

Defining Sockets over SNA Modes

Sockets over SNA uses LU 6.2 conversations to enable communication between socket application programs. When an LU 6.2 conversation is established, Sockets over SNA defines the mode and associated session characteristics of the connection. Communications Server uses the mode name to identify characteristics of the connection between the two Sockets over SNA nodes.

The default Sockets over SNA mode is BLANK. You can use the default mode for Sockets over SNA or define your own. To change the default Sockets over SNA mode, from the SNA Node Configuration window, click Configure AnyNet Sockets Over SNA and then click Modes. You can define another default mode for all TCP/IP traffic and assign a specific mode to a specific TCP/IP port.

If you specify an alternative mode that is not defined by Communications Server, you must define the session characteristics associated with that mode to Communications Server.

Changing the Idle-Timeout Interval

The idle timeout start option enables you to adjust the number of idle seconds before Sockets over SNA deallocates a datagram conversation. This interval enables you to balance using system resources to maintain an existing datagram conversation and taking longer to reestablish a new datagram conversation. For example, if you set this value low, unused datagram conversations end faster, but it takes longer to send the next datagram. The default idle-timeout interval is 90 seconds.

To modify the start option, from the SNA Node Configuration window, click Configure AnyNet Sockets over SNA, then click View/Change/Add, click the Advanced tab and select a new value for this option.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]