BARR/RJE manual

Token Ring

This topic provides an overview of Barr's TRN host connection support and a discussion of stacks and configurations, with examples for various adapters.

• TRN Host Connection Support

• Barr TRN Stacks

TRN Host Connection Support

Barr's TRN connection to the host is made through an 802.2 connection implemented with the IBM LAN Support Program (LSP). Barr recommends LSP version 1.35 or later.

This interface to the TRN adapter is normally implemented by use of two drivers in the config.sys: DXMA0MOD, which is known as the interrupt arbiter, and DXMC0MOD, which is the device driver for the adapter itself. These drivers vary by adapter.

LSP is the interface between the TRN adapter and any applications that want to access the adapter, allowing the adapter to be "shared" among multiple applications. To make it work as designed with the Barr software, all applications must talk to the LSP interface. Novell is an example of an application that can be configured to talk to the LSP or the adapter.

Documentation to set up host connections is found in one of two places. Connections to a 3745 are configured in the host NCP/VTAM definitions, much like an SDLC connection, while a 3174 connection is configured at the controller itself. The 3174 is configured by answering a series of questions in a configuration mode.

Communications to the Host

The Communication Scope should show the following sequence when connecting to a host:

Stat I A S Xidz Xidrz Xid Xid Xidr C...

Stat – Barr software has been requested status from the adapter. If the adapter returns a close, the Barr software initializes and opens the adapter with I A. The console displays Using TRN address <############>. This 12-digit number normally will match either the burned-in address of the Token Ring adapter or a locally administered address set up in a configuration file on the PC.

S – Barr software opens the Service Access Point (SAP) on the adapter. The SAP is the point of entry to the adapter for applications. Barr software by default attempts to attach to SAP 04. If this is used by another application, either E43 will appear on the Communication Scope, or an error that the SAP is in use will appear on the operation screen. The SAP that is asked for can be set in the software. Remember to use multiples of 04 and to tell the host controller what SAP the software is using. In a 3174, this is done in question 940.

Xidz – Barr software sends this command to test that a valid path exists to the station matching the address in the LOCADDR field under Communication Link.

Xidrz – Incoming response to the Xidz. Versions later than 90D25 verify that this is a response from the correct device by checking the sender's address. An Xidrz does not verify that the LOCADDR in the software is the desired device, only that a device with that address exists on the network. Any TRN device can answer a poll. The test for a controller comes from the Xids that follow. Multiple responses can be received in a Source Routing situation. The software answers the first response received.

Xid – This command serves two functions. The first Xid is the request to attach to the device that responded. If the device on the other end is set up to allow access, the device will then respond with an Xid telling the software to attach. Note that a 3174 will not return an Xid response if the address of the Barr station is not listed in its internal table (questions 940-941).

Xidr – Having received an Xid telling the software to attempt connection, the Barr software responds by sending the IDBLK and IDNUM to the host controller. If the request is accepted, then a C is displayed on the scope to show that an ACTPU has been received and that the Barr software is connected to VTAM. The message LLC link <###########> is Active will be displayed on the console now. The 12-digit number must match the number entered into the LOCADDR field in the software.

Common Problems and Solutions

The best way of analyzing TRN communications problems is by looking at the operation screen. Most of the time, the direction the problem needs to be taken will be indicated there. When checking the scope, the BARR/RJE manual is very complete in explaining the characters. Following are some common solutions.

Problem – TRN connection not being made. Screen says Using TRN Address 000000000000.

Analysis – Not displaying a TRN address indicates that Barr is not initializing the TRN adapter, or that another application has initialized the adapter.

Solution – Check that LAN Support has been loaded on the machine. Also check to see if another application is running on the PC. This could be Novell or another LAN product. The TRN adapter must be initialized so multiple applications can gain access. This could also be indicative of a failure of DXMC0MOD to load the adapter.

Problem – TRN connection not being made. Communication Scope shows StatIA. No message on screen about adapter address. Computer keyboard is locked up.

Analysis – Not displaying a TRN address indicates that Barr is not initializing the Token Ring adapter, or that another application has initialized the adapter. This is generally a conflict problem on the computer. An IRQ conflict may exist, or upper memory may not be available to the adapter.

Solution – Quick test: Use F8 to step through the config.sys and skip loading the memory manager. If the problem disappears, the memory manager was interfering with the Token Ring adapter.

Problem – TRN connection to host fails. Communication Scope shows Xidz Xidz...;.Communication Scope shows XidzXidzXidz...; or XidzXidrzXidXidzXidrzXid...;, and Using TRN address ############ appears on the screen. Communication Scope shows XidzE22.

Analysis – Barr software is broadcasting on the network but either is not receiving a response or is receiving a response from an invalid device (not a controller), or the controller is not configured to accept the address of the Barr PC.

Solution – Check the value entered in LOCADDR under Communication Link and compare it to the value entered in question 900 of the 3174 configuration, or the value for LOCADDR in the VTAM definition for a 3745 connection. This value must match the value entered in the Barr software.

Also verify that the address of the Barr PC adapter has been entered in the appropriate tables at the controller. It can become a problem if a site is using the burned-in address from the adapter instead of a locally administered address (LAA). If an adapter is changed, then the address is different and the controller will not recognize the adapter when it identifies itself. This is a major reason for recommending that the LAAs be used.

Question 900 – 3174 TRN Address

Question 900 contains the value for the Token Ring address of the 3174 controller. This value will also be displayed in questions 940-941 and is the value that should be entered into Barr for LOCADDR under the 3174 (local or remote) communication options. This value contrasts with question 106, which is not specified for 3270 gateway connections (typical TRN).

There may be some controllers (3174s) that specify the SAP for this connection. IBM books do not cover this, so this may not be common.

TRN Address Formats

TRN addresses are usually formatted as follows.

For burned-in addresses, given the following address WWWW WWZZ ZZZZ:

W is the ID of the manufacturer (IBM's identifier is 10005A)
Z is the unique address for each adapter by this manufacturer

Locally administered addresses usually take the following format: 4000 XYYY YYYY.

X and Y are the user-assigned portion of a locally administered address. Generally, installations with 3174s will assign the address so that the middle four digits signify the device attached to (3174, for example), with the last four digits specifying the order on the device. The sample address 400031740003 signifies attachment to a 3174 and specifies that it is the third device defined for that controller.

Questions 940-941 – 3174 Local Controller

Question 940

S@ – This is the CUADDR (channel address) of the PU that Barr will use. This value should match the CUADDR entered in Barr. This will be in the range defined by questions 104 and 105. Note also that the TRN address on this line must match the value of the TRN address at Barr.

Ring@ – Token Ring address of the PC. This is the value that should come up when the Barr software starts, with the statement Using Token Ring Address 4###########.

SAP@ – Service Access Point. Normally 04.

T – For Barr, this should always be set to 1 to indicate that the attached device is a downstream PU.

Question 941

S@ – This is the CUADDR (channel address) of the PU that Barr will use. This value should match the CUADDR entered in Barr. This will be in the range defined by questions 104 and 105. Note also that the TRN address on this line must match the value of the TRN address at Barr.

Ring@ – Token Ring address of the PC. This is the value that should come up when the Barr software starts, with the statement Using Token Ring Address 4###########.

SAP@ – Service Access Point. Normally 04.

F – Transmit I-Frame Size. This is the MAXDATA value for 3174 controller.

0 – 265 bytes
1 – 521 bytes
2 – 1033 bytes
3 – 2042 bytes

Note that failing to match the Barr software to this setting can result in strange connection problems. The most common is that the line restarts when a 3270 session transmits data.

W – MAXOUT (transmit window size). With the Barr software, this is usually set to 2. (Setting this to 3 has not been successful.).

Barr TRN Stacks

Barr TRN software communicates across network hardware using the 802.2 LLC protocol. This can be accomplished in most cases by running the IBM LAN Support Program (LSP throughout this document). The adapter type is unimportant; Barr will run on Token Ring or Ethernet adapters. This document will show the stacks and configurations for the following: LSP over Token Ring, LSP and IPX over Token Ring, LSP via NDIS, ODI, ODI over LSP, NDIS over ODI, and Microsoft's LSP replacement: MSDLC. The document ends with examples for various adapters.

The stack representations in this stack are not accurate in showing all layers of the stack. The goal here is to illustrate the relationship between various drivers, not to show the exact layers in which these drivers reside. Also, TRN will refer to Barr's communication over 802.2; Token Ring will refer to adapters.

We will deal with three standards: LSP, NDIS, and ODI.

• LSP – IBM's LAN Support Program. This was the initial industry standard for sharing network adapters, in particular Token Ring adapters. It came out of IBM's Token Ring program in the mid-80s.

• NDIS – Network Driver Interface Specification. This was designed by 3Com and Microsoft to allow adapter sharing on various types of adapters. IBM wrote its DXME0MOD.SYS driver for access to this standard.

• ODI – The Open Data-Link Interface. This is Novell's answer to NDIS. Novell has attempted to dominate this arena by producing drivers that will allow users to run Novell under ODI without changes to their NDIS configurations. ODI is the standard protocol in use for Novell versions later than 3.11.

Barr Over LSP – IBM Token Ring Adapter

Let's begin with the simplest example of Barr communicating using the TRN interface. The following stack shows Barr communicating with LSP; no other application is using the adapter.

The only configuration necessary is to add two lines to the PC's CONFIG.SYS. They are:

DEVICE=DXMA0MOD.SYS
DEVICE=DXMC0MOD.SYS

DXMA0MOD.SYS is known as the Interrupt Arbiter and handles communications into LSP. DXMC0MOD.SYS is the adapter-specific driver that enables IBM Token Ring adapters to run LSP.

This configuration is usable with any Token Ring adapter built with the Tropic chipset. Manufacturers using this chipset include Intel, Olicom, 3Com, and Thomas Conrad. Other manufacturers will generally supply their own equivalents of LSP.

Note that the stack shows Barr not covering all of the LSP layer. LSP was designed to allow the network adapter to be shared by multiple applications. We can thus extend the above diagram to show another application — for our purposes a network — using the adapter for communication. The most common way that Barr TRN has been used through the years is in conjunction with Novell Netware, and the most common problem reported has been the user's inability to get Novell and Barr to share the adapter.

Barr and IPX Over LSP

Here's the simplest scenario: Barr coexisting with Novell networks running "straight" IPX (that is, without the ODI interface).

When using the IPX driver in Novell, the driver is configured for an individual adapter. Novell's SHGEN/WSGEN (depending on Novell version) utility creates an IPX driver based on choices in the software. Typically the user will configure IPX specifically for the adapter installed in the machine. This will not allow Barr to operate, as IPX takes exclusive control of the adapter. The stack pictured here shows Novell talking directly to the adapter, with Barr unable to access the adapter.

The user can, however, make a choice in SHGEN that will allow Barr and Novell to share the adapter. Instead of choosing the driver for the adapter installed, the user should choose the driver for the IBM LAN Support Program, which is included in the Novell package. In this scenario, Novell will then communicate with LSP instead of directly to the adapter, allowing the adapter to be shared, and Barr to be run in conjunction with Novell. Note how the following stack is different.

CONFIG.SYS remains the same as if Barr is the only application using the adapter. AUTOEXEC.BAT simply loads the network software necessary for Novell to load.

Barr Over NDIS

Up to now we have looked at running Barr on basic LSP over Token Ring adapters only; however, the move in IBM is toward Token Ring adapters that don't use the DXMC0MOD driver. Instead, these adapters use the NDIS standard. Also, at the outset it was mentioned that Barr will run over Ethernet. This is also accomplished using NDIS. This standard is more flexible but takes extra configuration. A new configuration file, PROTOCOL.INI, is necessary. Also, LSP is still used, but the driver is different. Now the user will run DXME0MOD.SYS, LSP's NDIS driver. Let's look at the stack first.

Notice that we have now added a new layer to the stack. NDIS becomes the interface between LSP and the adapter. LSP no longer cares what the adapter is; it talks to the NDIS layer.

Two new drivers are added to CONFIG.SYS: the MAC driver, which is an adapter-specific driver; and PROTMAN.DOS, the PROTocol MANager, which initializes the NDIS. Also, DXMC0MOD.SYS is replaced by the generic DXME0MOD.SYS.

PROTMAN.DOS will look at the PROTOCOL.INI file to find out what setup is necessary. After it has loaded and all the drivers are in memory, the drivers must be "bound" together. This is done by placing the NETBIND command in AUTOEXEC.BAT.

Finally, PROTOCOL.INI will contain sections that will set up both the MAC driver and LSP. This is a sample:

Again, <DRIVER> will always be replaced by the specific adapter driver you are running.

Much as we added Novell to the LSP mix above, NDIS will allow Novell and Barr to share the adapter. You need to get a driver from Microsoft to accomplish this. A more common method is to use Novell's ODI standard to share the adapter.

Novell ODI

ODI is Novell's attempt at allowing multiple protocols to share the same adapter. Novell has gone out of its way to maximize flexibility. It can run with Barr in one of two scenarios: Novell ODI over LSP, or NDIS running on top of ODI. The setup for ODI is similar to that for NDIS. It has equivalents for PROTMAN and the MAC driver. It also replaces PROTOCOL.INI, with parameters now set in NET.CFG.

The stack for ODI would look like this:

The MLID driver handles communications to the adapter, while LSL handles communication to the application. CONFIG.SYS is now empty and PROTOCOL.INI no longer exists. The work is now done in AUTOEXEC.BAT and Novell's NET.CFG file.

The NET.CFG gets one section added to it. A LINK DRIVER section must be added to enable the MLID driver. Among other parameters, it is here that the frames that will be passed across the adapter will be defined.

Adding Barr to the above mix requires commitment to a protocol. You may run either ODI on top of LSP, or NDIS on top of ODI. We'll examine both here.

Barr and ODI Over LSP

The simpler of the two is ODI on LSP. Here, we combine both worlds into one group of files. First, the stack. We document here an example for Tropic-based Token Ring adapters. Note that PROTOCOL.INI is not necessary in the configuration.

In this setup, the MLID driver is replaced by the Novell-supplied driver LANSUP.COM. This provides the interface between LSL and the ODI software. Barr knows nothing of this and is content sharing the adapter through LSP, the same as plain IPX.

As in the ODI example above, you will need to add a Link Driver section to NET.CFG.

These frame parameters must be present or Novell will be unable to communicate.

The final Novell stack involves loading NDIS on to the ODI stack.

NDIS Over ODI

ODI allows NDIS to run on its stack by replacing the MAC driver with ODINSUP, ODI's implementation of the MAC. The stack will look like a standard ODI stack, with additions for NDIS.

NDIS is now down to the PROTMAN.DOS driver, with the MAC driver removed from CONFIG.SYS. LSP loads as in our earlier examples.

Note that NDIS still requires a NETBIND to be executed.

PROTOCOL.INI still needs to configure the adapter as if it controlled the stack; however, instead of a section to initialize the MAC driver, it will make a reference to the ODI MLID driver. NET.CFG will define a Link Driver for the adapter and a Protocol section for ODINSUP that references the MLID.

As in earlier parts of the document, <DRIVER> is replaced with the appropriate adapter driver MLID.

Microsoft MS-DLC

Our last stack is Microsoft's. Their networking software (LanMan, WFWG, etc.) contains a driver called MSDLC that allows DLC-style communications to operate on their network. Barr will run under this driver, but so far speed seems to be lacking. This is an NDIS protocol that, without running LSP, will allow 802.2 communications across the adapter.

The stack:

This resembles the previous NDIS stacks with the difference that MS-DLC takes the place of LSP.

The configuration files will look much the same, simply replacing the LSP files with MSDLC.EXE. Netbind is replaced with a NET START command. PROTOCOL.INI adds a section for the DLC driver.

Note that the DLC_XIF section has LOAD and UNLOAD statements listed. These are required by the protocol. As always, replace <DRIVER> with your adapter driver name.

Examples

IBM 16/4 and Other Adapters with the Tropic Chipset; LSP Only

Some adapter companies supply their own versions of the drivers, but they are basically all the same.

Madge Smart Ringnode 16/4

This adapter is unique in that LSP, IPX, or ODI can be loaded from a single command: SMART.EXE. You simply add the command line option for the protocols you wish to load. It accomplishes this through use of .SMT files that need to be in the same directory as SMART. To load IPX and LSP (Madge uses the term LLC) onto this adapter, load the following into AUTOEXEC.BAT:

C:\<PATH>\SMART IPX LLC PATH=<PATH>

where <PATH> is the directory where SMART.EXE and the .SMT files are located.

Madge also supplies ODI drivers for SMART, as well as MADGEODI, their MLID driver.

IBM Lanstreamer

IBM's newest Token Ring adapter uses NDIS instead of LSP to load.

3Com 3C509 Running NDIS

Basically this is the same as the IBM LANSTREAMER, with replacements for the appropriate driver files.

NE2000 Running NDIS and ODI