Networking two AS/400 over LAN with SNA

From Try-AS/400
Jump to navigation Jump to search

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

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.[1] 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.

Other means of networking machines includes Enterprise Extender (EE), and AnyNet.

Services requiring a SNA connection include, but are not limited to:

  • DRDA: Distributed Relational Database Architecture; to transparently use database tables on other machines,
  • SNADS: Systems Network Architecture Distribution Services, similar to 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),
  • qautocfg, and qautormt system variables set to 1,
  • qautovrt system variable set to *nomax.

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

Note: For the sake of simplicity, this article assumes the remote AS/400's name is nibbler.[2] 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.

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 dspneta command. Changing network parameters is done by the chgneta command.[3] Unfortunately, the textual descriptions shown on the dspneta screen differ slightly from the ones shown on the chgneta 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.

What chgneta parameter
System name sysname
Local network ID lclnetid
Local control point name lclcpname
Default local location name lcllocname
APPN node type nodetype

Example: 

chgneta lclnetid(pocnet) nodetype(*netnode)[4]

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 next section.

Depending on the LAN technology in use, you need to use the appropriate command:

  • crtlineth for Ethernet,
  • crtlintrn for Token Ring.

The line description needs to know the resource name of the LAN I/O-Adapter. Use the command dsphdwrsc type(*cmn) to get a screen showing all communications resources.[5] Locate your LAN I/O-Adapter's port in that list and take a note of its resource name, e. 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)

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.[6]

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.

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

  • ethstd = *all
  • tcponly = *no

are set accordingly. If not, you need to vary off the line description and use chglineth ethstd(*all) tcponly(*no) 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 to revive the network connection. You have been warned!
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 — has been carried forward to the LAN world, which seems somewhat alien from todays standards.[7]

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:

What Parameter Where to find Example
Remote control point name rmtcpname dspneta, Local control point name nibbler
Exchange ID exchid dsplind lind(ethline), Exchange identifier 05641789
MAC address adptadr dsplind lind(ethline), Local adapter address 002035C5816D

With all parameters known, you can now create the appropriate controller description. Note, this is one long line:[8] 

crtctlappc ctld(nibbler) linktype(*lan) swtlinlst(ethline) rmtcpname(nibbler) exchid(05641789) adptadr(002035c5816d) nodetype(*calc) tmsgrpnbr(*calc) autodltdev(*no) swtdsc(*no) cmnrcylmt(1 10)[9]

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 wrkappnsts option(*loc) 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 (dspmsg msgq(qsysopr)) for more information.

Next, you can run the APPC ping command. It works quite akin to the well-known TCP/IP ping command.[10]

  • call qcmd
  • Press F10 to include detailed messages
  • aping rmtlocname(nibbler)

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:

  • swtdsc(*no) to prevent the connection being torn down after the idle counter runs off[11]
  • cmnrcylmt(1 10)[9]

By default, both controller descriptions are created with inlcnn(*dial). 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 inlcnn(*ans). 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 inlcnn(*dial)) 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

Footnotes

  1. ↑ 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.
  2. ↑ My personal primary AS/400's name, and a character in the Futurama animated TV show.
  3. ↑ Note that you need to press F4 instead of Enter to get a screen of changeable values.
  4. ↑ You might receive a message that network attributes cannot be changed while APPC controller descriptions are varied on. Use the wrkctld 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.
  5. ↑ Per the initial comment of this article, you also can see which IOP is handling those communication I/O Adapters.
  6. ↑ If you use cheapernet type BNC/coax 50 Ω cabling, half-duplex is the sole supported, and physically possible option.
  7. ↑ 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.
  8. ↑ Run call qcmd to get a display with more space.
  9. ↑ 9.0 9.1 I feel the defaults have a too long retry time and force error state transition after too few tries.
  10. ↑ Not available on V3 and earlier by default.
  11. ↑ Each connect and disconnect puts messages into the qsysopr message queue, leading to unwanted log spam.
Retrieved from "http://try-as400.pocnet.net/index.php?title=Networking_two_AS/400_over_LAN_with_SNA&oldid=1394"