View source for Networking two AS/400 over LAN with SNA

This article shows how to '''network two AS/400 via LAN, with SNA''' APPN/APPC over 802.2 DLC.

<blockquote>'''Note:''' This configuration is supported only for older machines with dedicated I/O processors (IOPs): APPN runs at least in part on the IOPs handling the IOAs.<ref>Contrary, the APPN expansion protocol ''High Performance Routing'' (HPR) runs on the machine's main CPU. Depending on said CPU's raw processing power, you may choose to disable HPR in your APPC controller descriptions.</ref> As a rule of thumb, Gigabit Ethernet IOAs are not supported by any IOP and thus run ''IOP-less''. This class of adapters was introduced with the multi-core POWER5 CPU generation of machines, where IOP duties are in fact handled by one of the CPU cores. Most often, "true" rack mountable machines with accompanying rails are POWER5 or newer and fall into this class of machines. APPN over 802.2 DLC support might even have been removed from later IBM i code bases, together with support for dedicated IOPs and subordinate IOAs.</blockquote>

Other means of networking machines includes [[Networking two AS/400 with Enterprise Extender|Enterprise Extender]] (EE), and [[Networking two AS/400 with AnyNet|AnyNet]].

Services requiring a SNA connection include, but are not limited to:
* '''[[wikipedia:DRDA|DRDA]]''': Distributed Relational Database Architecture; to transparently use database tables on other machines,
* '''[[wikipedia:SNADS|SNADS]]''': Systems Network Architecture Distribution Services, similar to [[wikipedia:UUCP|UUCP]]; to do background transfers of files, and messages,
* Terminal Passthrough, very similar to Telnet.

Basic requirements for all involved machines:
* a working LAN I/O-Adapter (Token Ring, or Ethernet),
* <code>qautocfg</code>, and <code>qautormt</code> system variables set to <code>1</code>,
* <code>qautovrt</code> system variable set to <code>*nomax</code>.

Networks are a layered architecture, and so is the configuration.

<blockquote>'''Note:''' For the sake of simplicity, this article assumes the remote AS/400's name is ''nibbler''.<ref>My personal primary AS/400's name, and a character in the ''Futurama'' animated TV show.</ref> The local machine's name is never mentioned, because it doesn't matter for local configuration. The only exception is the paragraph regarding the line description, but I (hopefully!) made clear that a line description is required on '''both''' machines. Regarding the line description, the system name doesn't matter. Only for the controller description, and connection testing, the name matters.</blockquote>

== Basic SNA configuration ==
If your installation is not pristine, better check (and possibly set) some basic networking parameters.

Depending on your use case, it might be beneficial to decide on your "primary" and "secondary" machines. The primary machine you mainly use should be set to be a ''network node'', while all others can remain at the default ''end node''.

A bit overly simplified, a ''network node'' (mainly, but not only) provides name resolution services to all other nodes in an APPN network. This is a bit like a TCP/IP capable machine running a DNS server.

Checking network parameters is done by the <code>dspneta</code> command. Changing network parameters is done by the <code>chgneta</code> command.<ref>Note that you need to press <code>F4</code> instead of <code>Enter</code> to get a screen of changeable values.</ref> Unfortunately, the textual descriptions shown on the <code>dspneta</code> screen differ slightly from the ones shown on the <code>chgneta</code> prompt screen.

In addition, you may choose to give your machines nice names instead of their serial numbers. This involves an IPL to activate the change, though.

:{|class="wikitable"
!What
!<code>chgneta</code> parameter
|-
|System name
|<code>sysname</code>
|-
|Local network ID
|<code>lclnetid</code>
|-
|Local control point name
|<code>lclcpname</code>
|-
|Default local location name
|<code>lcllocname</code>
|-
|APPN node type
|<code>nodetype</code>
|}

Example:
 chgneta lclnetid(pocnet) nodetype(*netnode)<ref>You might receive a message that network attributes cannot be changed while APPC controller descriptions are varied on. Use the <code>wrkctld</code> screen to identify all controller descriptions of type *APPC, put ''8=Work with status'' into the Opt selection, and vary them off in the subsequent screens.</ref>

I strongly recommend to either leave the default value ("APPN") for the local network ID, or use a common name for all machines in the local network.

== Line description ==
The ''line description'' "drives" the LAN I/O-Adapter.

If your machine(s) already use TCP/IP, skip to the [[#Checking an existing line description|next section]].

Depending on the LAN technology in use, you need to use the appropriate command:
* <code>crtlineth</code> for Ethernet,
* <code>crtlintrn</code> for Token Ring.

The line description needs to know the ''resource name'' of the LAN I/O-Adapter. Use the command <code>dsphdwrsc type(*cmn)</code> to get a screen showing all communications resources.<ref>Per the initial comment of this article, you also can see which IOP is handling those communication I/O Adapters.</ref> Locate your LAN I/O-Adapter's port in that list and take a note of its ''resource name'', e.&thinsp;g. ''cmn03''. Example:

 Resource        Type  Status                Text
 CMB01           6756  Operational           Combined function IOP
   LIN03         2723  Operational           LAN Adapter
     CMN03       2723  Operational           Ethernet Port
   LIN01         2720  Operational           Comm Adapter
     CMN01       2720  Operational           Comm Port
   LIN02         2724  Operational           LAN Adapter
     CMN02       2724  Operational           Token-Ring Port
   LIN04         2850  Operational           File Server IOA
     CMN04       2838  Operational           Ethernet Port
     CMN11       6B00  Operational           Virtual Port
   LIN12         285A  Operational           LAN Adapter

Then, create the appropriate line description. Example:
 crtlineth lind(ethline) rsrcname(cmn03) autocrtctl(*yes) autodltctl(*none) cmnrcylmt(15 1)

<blockquote>'''Note:''' For Ethernet type line descriptions, the default parameters might force a half-duplex connection. Depending on the IOA in use, full-duplex setting might not be supported. In any case, make sure that the device on the other side of the network cable (Switch) matches the adapter's duplex setting, or you will experience severe performance degradation.<ref>If you use cheapernet type BNC/coax 50&thinsp;Ω cabling, half-duplex is the sole supported, and physically possible option.</ref></blockquote>

Make sure your cable connection is set up properly. Afterwards, you can ''vary on'' your new line description.
 vrycfg cfgobj(ethline) cfgtype(*lin) status(*on)

'''Note:''' You need to do this step on each involved machine.

If successful, skip the next step, and proceed to [[#Controller description|controller description]].

=== Checking an existing line description ===
If you TCP/IP is already configured on the machine, a line description is already configured and in use. You need to make sure that the parameters
* <code>ethstd</code> = <code>*all</code>
* <code>tcponly</code> = <code>*no</code>
are set accordingly. If not, you need to ''vary off'' the line description and use <code>chglineth ethstd(*all) tcponly(*no)</code> to set the parameters to the required values for SNA. Then, ''vary on'' the line description again. '''Note:''' Depending on the OS/400 release in use, one or both of those parameters might not be available.

Depending on existing configuration objects depending on the line description, you might get a message that there's a message in the ''qsysopr'' message queue waiting to be handled. This message should ensure that you know what you do when you force a ''vary off'' of said line description.

<blockquote>'''CAUTION!''' You are '''required''' to either have console access or some other means to access your machine. If you ''vary off'' the line description, and confirm the qsysopr message via a session established over that particular LAN I/O-Adapter, you'll "saw off the branch you're sitting on". If left without a working network connection, and without console, you can't do much more than force an IPL (power-cycle) of the machine to revive the network connection. You have been warned!<br>
Of course, the existing parameters still would need to be changed.</blockquote>

== Controller description ==
The ''controller description'' is the configuration object for your designated peer machine.

<blockquote>'''Note:''' SNA protocols stem from an era, when there were no LANs. Networks were either dialup (switched) or leased lines, but in almost any case direct point to point connections between adjacent machines. This concept — the need to manually configure adjacent network nodes — has been carried forward to the LAN world, which seems somewhat alien from todays standards.<ref>SNA doesn't know about something akin to ARP to automatically find peers on the local LAN segment through broadcast mechanisms. SNA has a capability called ''connection network'', which roughly resembles a central ARP server, but this is out of scope for this document. For now, refer to the appropriate IBM documentation for details.</ref></blockquote>

You need to create the controller description on only one machine. The other machine will recognize the incoming connection attempt, and create the appropriate "mirror" controller description.

To actually create the controller description, you need to collect the following information '''from the other machine''':
:{|class="wikitable"
!What
!Parameter
!Where to find
!Example
|-
|Remote control point name
|<code>rmtcpname</code>
|<code>dspneta</code>, Local control point name
|nibbler
|-
|Exchange ID
|<code>exchid</code>
|<code>dsplind lind(ethline)</code>, Exchange identifier
|05641789
|-
|MAC address
|<code>adptadr</code>
|<code>dsplind lind(ethline)</code>, Local adapter address
|002035C5816D
|}

With all parameters known, you can now create the appropriate controller description. Note, this is one long line:<ref>Run <code>call qcmd</code> to get a display with more space.</ref>

 crtctlappc ctld(nibbler) linktype(*lan) swtlinlst(ethline) rmtcpname(nibbler) exchid(05641789) adptadr(002035c5816d) nodetype(*calc) tmsgrpnbr(*calc) autodltdev(*no) swtdsc(*no) cmnrcylmt(1 10)<ref name="cmnrcylmt">I feel the defaults have a too long retry time and force error state transition after too few tries.</ref>

If you now vary on the controller description, the other machine should show some activity while protocols are negotiated, and according objects being created:
 vrycfg cfgobj(nibbler) cfgtype(*ctl) status(*on)

== Checking connectivity ==
First, run <code>wrkappnsts option(*loc)</code> on any machine. You'll get a screen where you should see an entry for your remote machine's name. If the list is empty, the connection has not been established. See the ''qsysopr'' message queue (<code>dspmsg msgq(qsysopr)</code>) for more information.

Next, you can run the APPC ping command. It works quite akin to the well-known TCP/IP ping command.<ref>Not available on V3 and earlier by default.</ref>
* <code>call qcmd</code>
* Press <code>F10</code> to include detailed messages
* <code>aping rmtlocname(nibbler)</code>

If everything worked out well, you'll get a screen showing output similar to:
 Verifying APPC connection to remote location APPN.NIBBLER on mode BLANK.
 Allocate took 0,599 seconds.
 Remote system type is OS/400.
 Initial exchange took 0,154 seconds.
 Iteration 1 took 0,009 seconds.
 Iteration 2 took 0,008 seconds.
 Round-trip (in milliseconds) min/avg/max = 8/8/9

== Cleanup and optimizations ==
The (automatically created) controller description on the remote machine (in this example: ''nibbler'') uses some default values. I recommend to change the controller description on the remote machine accordingly:
* <code>swtdsc(*no)</code> to prevent the connection being torn down after the idle counter runs off<ref>Each connect and disconnect puts messages into the ''qsysopr'' message queue, leading to unwanted log spam.</ref>
* <code>cmnrcylmt(1 10)</code><ref name="cmnrcylmt" />

By default, both controller descriptions are created with <code>inlcnn(*dial)</code>. If only one machine is IPL'd, and the recovery tries are exhausted, the controller description will be set to an error state. In this state, no more outgoing connections are attempted, and no incoming connections matching that particular controller description are accepted. This condition can be resolved by a ''vary off'' and ''vary on'' of the controller description in error state. This is a manual process and thus not very comfy to handle.

Depending on your use case, it might be beneficial to decide on your "primary" and "secondary" machines. The primary machine you mainly use might have the controller description changed to <code>inlcnn(*ans)</code>. No outgoing connections are attempted, and the controller description will not be set to error state. When you IPL the other machine, that machine's controller description (still being set to <code>inlcnn(*dial)</code>) will force a dial-out to your already running machine. The latter will answer the incoming request. This procedure prevents annoying error states.

As usual, you need to vary off the configuration object to make changes, and vary on afterwards.

== See also==
* [[Configuring SNA Distribution Services]]
* [[Networking two AS/400 with Enterprise Extender]]
* [[Networking two AS/400 with AnyNet]]
* [[Integrating LAN-less Machines into a local Token Ring]]

== Footnotes ==
<references />

[[Category: Software Configuration Guide]]