Networking two AS/400 over LAN with SNA - Revision history

PoC: Better wording

2023-08-04T13:05:26Z

Better wording

← Older revision		Revision as of 15:05, 4 August 2023
Line 17:		Line 17:
	Networks are a layered architecture, and so is the configuration.		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 testing, the name matters.</blockquote>		<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 ==		== Basic SNA configuration ==

PoC: Further errors corrected

2023-08-03T09:48:39Z

Further errors corrected

← Older revision		Revision as of 11:48, 3 August 2023
Line 134:		Line 134:
	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>		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)		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:		If you now vary on the controller description, the other machine should show some activity while protocols are negotiated, and according objects being created:
Line 157:		Line 157:

	== Cleanup and optimizations ==		== 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~~.		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" />

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

	~~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~~.~~</ref> I feel~~ the ~~defaults have a too long retry time and force~~ error ~~state transition after too few tries~~. ~~Example:~~		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.
	~~vrycfg cfgobj(nibbler) cfgtype(ctl) status(off)~~
	~~chgctlappc ctld(nibbler) cmnrcylmt(1 10)~~
	~~vrycfg cfgobj(nibbler) cfgtype(ctl) status(on)~~

	~~To prevent errors:~~		As usual, you need to vary off the configuration object to make changes, and vary on afterwards.
	# 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==		== See also==

PoC: +Links

2023-08-03T09:09:52Z

+Links

← Older revision		Revision as of 11:09, 3 August 2023
Line 2:		Line 2:

	<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>		<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:		Services requiring a SNA connection include, but are not limited to:

PoC: Wording

2023-08-03T09:06:34Z

Wording

← Older revision		Revision as of 11:06, 3 August 2023
Line 1:		Line 1:
	This article shows how to '''network two AS/400 via LAN, with SNA''' APPN/APPC over 802.2 DLC.		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 machines, where IOP duties are in fact handled by one of the CPU cores. Most often, true rack mountable machines are POWER5 ~~and~~ 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>		<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>

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

PoC: More precise

2023-08-03T09:05:15Z

More precise

← Older revision		Revision as of 11:05, 3 August 2023
Line 1:		Line 1:
	This article shows how to '''network two AS/400 via LAN, with SNA''' APPN/APPC over 802.2 DLC.		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></blockquote>		<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 machines, where IOP duties are in fact handled by one of the CPU cores. Most often, true rack mountable machines are POWER5 and 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>

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

PoC: Reworked according to reader's input

2023-08-03T08:58:47Z

Reworked according to reader's input

← Older revision		Revision as of 10:58, 3 August 2023
Line 1:		Line 1:
	This article shows how to '''network two AS/400 via LAN, with SNA''' APPN/APPC over 802.2 DLC.		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></blockquote>

	Services requiring a SNA connection include, but are not limited to:		Services requiring a SNA connection include, but are not limited to:
Line 60:		Line 62:
	* <code>crtlintrn</code> for Token Ring.		* <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. g. ''cmn03''.		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. 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:		Then, create the appropriate line description. Example:
Line 158:		Line 173:
	== See also==		== See also==
	* [[Configuring SNA Distribution Services]]		* [[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]]		* [[Integrating LAN-less Machines into a local Token Ring]]

PoC: /* Cleanup and optimizations */ Typo

2023-08-03T00:14:03Z

Cleanup and optimizations: Typo

← Older revision		Revision as of 02:14, 3 August 2023
Line 144:		Line 144:
	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.		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:		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.</ref> 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)		vrycfg cfgobj(nibbler) cfgtype(ctl) status(off)
	chgctlappc ctld(nibbler) cmnrcylmt(1 10)		chgctlappc ctld(nibbler) cmnrcylmt(1 10)

PoC: /* See also */ Desired article

2023-08-03T00:12:57Z

PoC: /* Checking connectivity */ remark

2023-08-03T00:12:13Z

Checking connectivity: remark

← Older revision		Revision as of 02:12, 3 August 2023
Line 125:		Line 125:
	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.		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.		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>		* <code>call qcmd</code>
	* Press <code>F10</code> to include detailed messages		* Press <code>F10</code> to include detailed messages

PoC: /* Line description */ Now with links!

2023-08-03T00:09:43Z

Line description: Now with links!

← Older revision		Revision as of 02:09, 3 August 2023
Line 54:		Line 54:
	The ''line description'' "drives" the LAN I/O-Adapter.		The ''line description'' "drives" the LAN I/O-Adapter.

	If your machine(s) already use TCP/IP, skip to the next section.		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:		Depending on the LAN technology in use, you need to use the appropriate command:
Line 72:		Line 72:
	'''Note:''' You need to do this step on each involved machine.		'''Note:''' You need to do this step on each involved machine.

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

	=== Checking an existing line description ===		=== Checking an existing line description ===