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.

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 to 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.

== 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 use the default ("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 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 *cmn</code> to get a screen showing all communications resources. Locate your LAN I/O-Adapter in that list and take a note of its ''resource name'', e.&thinsp;g. ''cmn03''.

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

'''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 that the 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>

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 to ''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.

'''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. You have been warned!<br>
Of course, the existing parameters still would need to be changed.

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

'''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, is carried forward to the LAN world.<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>

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)

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.
* <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 ==
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 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 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.

I also recommend to change the controller description on both machines to <code>cmnrcylmt(1 10)</code><ref>Interestingly, this parameter cannot be set with the initial <code>crtctlappc</code> command. I feel the defaults have a too long retry time and force error state transition after too few tries. Example:
 vrycfg cfgobj(nibbler) cfgtype(*ctl) status(*off)
 chgctlappc ctld(nibbler) cmnrcylmt(1 10)
 vrycfg cfgobj(nibbler) cfgtype(*ctl) status(*on)

To prevent errors:
# vary off on the dialing machine
# vary off on the answering machine
# run <code>chgctlappc</code> on both machines
# vary on on the answering machine
# vary on on the dialing machine

== See also==
* [[Integrating LAN-less Machines into a local Token Ring]]

== Footnotes ==
<references />

[[Category: Software Configuration Guide]]
[[Kategorie: Netzwerk]]