Networking two AS/400 over LAN with SNA

From Try-AS/400
Revision as of 01:05, 3 August 2023 by PoC (talk | contribs) (→‎Line description: Typo)
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.

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 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),
  • qautocfg, and qautormt system variables set to 1,
  • qautovrt system variable set to *nomax.

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

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

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 *cmn 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. 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 the adapter's duplex setting, or you will experience severe performance degradation.[4]

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

  • 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.[5]

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

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

  • 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

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

I also recommend to change the controller description on both machines to cmnrcylmt(1 10)<ref>Interestingly, this parameter cannot be set with the initial crtctlappc 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:

  1. vary off on the dialing machine
  2. vary off on the answering machine
  3. run chgctlappc on both machines
  4. vary on on the answering machine
  5. vary on on the dialing machine

See also

Footnotes

  1. ↑ My personal primary AS/400's name, and a character in the Futurama animated TV show.
  2. ↑ Note that you need to press F4 instead of Enter to get a screen of changeable values.
  3. ↑ 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.
  4. ↑ If you use cheapernet type BNC/coax 50 Ω cabling, half-duplex is the sole supported, and physically possible option.
  5. ↑ 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.
  6. ↑ Run call qcmd to get a display with more space.
Retrieved from "http://try-as400.pocnet.net/index.php?title=Networking_two_AS/400_over_LAN_with_SNA&oldid=1381"