DEC SNA Peer Server Version 1.3 Release Notes September 15, 1995 Copyright (c) 1994, 1995 by Digital Equipment Corporation, Maynard, Massachusetts. All rights reserved. This document contains information not included in the DEC SNA Peer Server V1.3 documentation. It includes information about software problems and documentation changes. IMPORTANT Please read these notes before installing or using the software. Revision Information: This is a new document. Operating System Version: Digital UNIX AXP V3.2 DECnet Version: DECnet/OSI for Digital UNIX AXP V3.2 Software Version: DEC SNA Peer Server V1.3 Copyright (c) 1994, 1995 Digital Equipment Corporation Contents 1 INTRODUCTION 1 1.1 Version 1.3 Overview 1 2 SUPPORTING SOFTWARE 1 2.1 Digital UNIX 2 2.2 DECnet/OSI 2 2.3 X.25 2 3 INSTALLATION NOTES 3 3.1 Removing Prior Versions 3 3.2 NCL Initialization File Reuse 3 3.3 WDD Datalink Protocol Selection 4 4 OPERATING NOTES 4 4.1 Synchronous Communications Support (SDLC) 4 4.1.1 Modem Control and Link Configurations 5 4.1.1.1 Naming of Synchronous Lines 5 4.1.1.2 SDLC Modem Control Configurations 6 4.1.1.3 Multipoint Primary Not Supported in V1.3 9 4.1.1.4 Modem Connect Line Speed Characteristic 10 4.1.2 Additional Sync Comm Information 10 4.1.2.1 NRZI Encoding 11 4.1.2.2 SCC Device Name 11 4.1.2.3 CCITT V.24 Incompatibility with EIA RS-232C (DSYT1 and DNSES only) 11 4.1.3 SDLC Link Station 'Modulo' Characteristic 12 4.2 Qualified Logical Link Control (QLLC) 12 4.2.1 X.25 Configuration 12 4.2.2 X.25 Relay Considerations 13 4.3 LLC2 LAN Support 13 4.3.1 SAP Link Remote MAC Address Format 13 4.3.2 MAC Address Format when DECnet/OSI is Running 15 4.3.3 Token Ring Hardware 15 4.3.4 Ethernet Hardware 15 4.3.5 FDDI Hardware 15 4.3.6 Ethernet 802.3 vs. Ethernet V2 16 4.3.7 Operation in Bridged Token-Ring and FDDI Environments 16 4.4 WANDD Loader 16 4.5 Automatic Generation of NOTIFY(ONLINE) and NOTIFY(OFFLINE) 16 4.6 Using More Than 128 DECnet Connections 17 4.7 Specifying PU Name and Session Number on Client Connections 18 4.8 Session Termination Support Added for Non-IBM Mainframes 18 4.9 Startup Initialization Delay 18 iii Contents 4.10 OS/2 LAN Support Withheld 19 5 FIXED IN VERSION 1.3 19 6 KNOWN IBM RESTRICTIONS 19 6.1 Configuring Multiple Lines as PU T2.1 on the Peer Server 19 6.2 IBM 3745 Scanner Problem Running Above 230Kbps 19 6.3 NCP Problems with SDLC Mixed Modulo Stations on a Multipoint Line 20 6.4 NCP problems with modulo 128 Token Ring Stations 20 6.5 INIT-SELF rejected with sense code 10105006 20 6.6 VTAM ABEND S0C4 at ISTATCTR+1F0 20 7 KNOWN PROBLEMS AND PRODUCT RESTRICTIONS 21 7.1 Installation and System Configuration Restrictions 21 7.1.1 Common Agent must be selected for SNMP Management to be possible 21 7.2 Common Trace Facility (CTF) Notes 21 7.2.1 LU Tracepoints Not Supported 21 7.3 Restrictions with Network Management 21 7.3.1 NCL Delete Transmission Group "Wrong State" Exception 21 7.3.2 NCL Enable SDLC Link Station "Invalid Parameter" Exception 22 7.3.3 LocalEntityName Instance Specification 22 7.3.4 No Support for CMIP "with" Clauses on NCL Commands 23 7.3.5 Token Ring Entity not Manageable by SNMP 23 7.4 Restrictions with SNA LU Services 23 7.4.1 Independent LU Capability Problem with Passive Listens 23 7.5 SDLC Datalink Restrictions 24 7.5.1 Multipoint Full Duplex Configuration Requires TWA 24 7.5.2 Using the PBXDI ISA-bus synchronous communications controller 24 7.6 QLLC Datalink Restrictions 24 7.6.1 Temporary TGs Lack Automated Call Startup 24 7.6.2 Filtername Mismatch Error is Ambiguous 25 7.6.3 QLLC Link and Station must be Enabled Before TG 25 8 FILES INSTALLED/MODIFIED 25 iv Contents APPENDIX A DOCUMENTATION ADDENDA A-1 A.1 FDDI CONNECTIONS A-1 A.1.1 Planning A-1 A.1.1.1 FDDI Controller Configuration A-2 A.1.1.2 LLC2 Configuration A-3 A.1.2 Configuration A-3 A.1.2.1 t21setup kernel A-3 A.1.2.2 t21icu A-4 EXAMPLES A-1 t21setup kernel A-3 A-2 t21setup kernel A-3 A-3 t21icu A-5 FIGURES A-1 The FDDI Worksheet A-2 TABLES 1 Peer Server Installed Files 25 2 Peer Server Modified Files 27 v 1 Introduction These release notes are for Version 1.3 of the DEC SNA Peer Server. Following product installation, this file can be found in /var/sna/t21_V13-0_release_notes. The abbreviated Peer Server product name is used throughout this document. 1.1 Version 1.3 Overview The primary features of Version 1.3 of the Peer Server are: o Support for FDDI connections. Using LLC2, you can connect to IBM systems over an FDDI LAN. Refer to Appendix A for documentation on planning and con- figuring FDDI connections. o Support for synchronous communications via the PBXDI ISA-bus synchronous communications controllers. Refer to Section 7.5.2 for more information on using this controller. Peer Server V1.3 is a functional superset of Version 1.2. All processors and configurations supported with V1.2 are supported with V1.3. Please note that there is no new release of the Peer Server documentation in conjunction with this release of the Peer Server software. V1.2 of the Peer Server Documentation set is still current and valid. There are only a few addenda to the documentation for V1.3, and they are in Appendix A of this document. 2 Supporting Software You must have the supporting software installed before you can install the Peer Server software. This includes the correct version of the Digital UNIX operating system and, optionally, DECnet/OSI for Digital UNIX and X.25 for Digital UNIX. 1 2.1 Digital UNIX The Peer Server V1.3 software installs on Digital UNIX V3.2 or higher. In addition, you must install the Common Agent subset, (OSFCOMAGENTnnn), before installing the Peer Server. It is not necessary to configure Digital UNIX to use the Common Agent for management unless you want to be able to man- age the Peer Server using SNMP. If you do not select the use of the Common Agent when configuring Digital UNIX, you can still manage the Peer Server locally with ncl and remotely via DECnet/OSI if you have DECnet/OSI installed. 2.2 DECnet/OSI The Peer Server can use both TCP/IP and DECnet networks. If you plan to use DECnet, you must install DECnet/OSI for Digital UNIX V3.2 or later. If you wish to install or upgrade DECnet/OSI on a system that is already running version the Peer Server, then you should delete the Peer Server subsets before installing DECnet/OSI. See Section 3.1 for instructions on removing the Peer Server software. Once you have installed and configured DECnet/OSI, you should reinstall the Peer Server software. Unless you are planning to use DECnet communications for access to the Peer Server, there is no requirement that the DECnet/OSI layered product be installed on the Peer Server system. 2.3 X.25 With this version of the Peer Server, SNA traffic may be sent over X.25 Packet Switched Data Network (PSDN) backbones us- ing the Qualified Logical Link Control (QLLC) protocol. This enables X.25 customers to communicate with their IBM machines using SNA protocols over X.25 networks. To do so, you need the X.25 for Digital UNIX Systems V1.3 or later software product (available separately) installed prior to installing the Peer Server. You must also have the IBM software resident and con- figured on the IBM machine (for example X.25 Network Control Program Packet Switching Interface (NPSI), for IBM mainframe front end communications processors). The use of QLLC is supported with both types of X.25 PSDN ac- cess provided by the X.25 for Digital UNIX Systems product, namely: by direct synchronous communications link (LAPB) or by LAN access to an X.25 Relay node (LLC2). 2 Unless you are planning to use the QLLC protocol with the Peer Server, there is no requirement that the X.25 layered product be installed on the Peer Server system. 3 Installation Notes 3.1 Removing Prior Versions If you have an earlier version of the Peer Server software installed on your node, it must be deleted prior to installing this kit. To see whether a previous version is installed, issue the command setld -i | grep T21 The following subsets should be deleted to completely remove the Peer Server software prior to installing a new version of the Peer Server software, or prior to installing DECnet/OSI on a system that already has the Peer Server software installed. T21MGMTnnn T21SRVRnnn CTAANALnnn CTABASEnnn DNADLInnn DNANETMANnnn WDABASEnnn WDADATALNKSnnn WDADRIVERSnnn ZZAUTILnnn Delete the named subsets listed as installed (substituting the correct subset numbers for "nnn") using the command setld -d subset subset ... 3.2 NCL Initialization File Reuse Previous Peer Server customers can retain the NCL initial- ization script(s) configured for earlier versions of the Peer Server, provided they anticipate the same configuration for their V1.3 installation. (The default startup script is t21_init_sna_server.ncl in the /var/sna directory.) 3 3.3 WDD Datalink Protocol Selection The DEC SNA Peer Server Installation and Configuration manual describes the t21setup kernel build procedure. The instruc- tions for WDADATALNKS datalink protocol selection (HDLC/LAPB, LLC2) are provided with respect to the Peer Server datalink control interface (SDLC, QLLC, or LLC2). Specifically, for SDLC you need no WDADATALNKS protocol, for QLLC you typically need HDLC/LAPB, and to run SNA over LLC2 you need LLC2. As given, the instructions do not take into consideration WDADATALNKS selections required outside the scope of the Peer Server. For example, consider the case where you are running the X.25 for Digital UNIX Systems product using the X.25 Relay node feature (X.25 over LLC2 LAN to an X.25 Relay node) inde- pendent of the Peer Server, and you are installing Peer Server for SDLC access only. Despite the Peer Server not requiring LLC2 selection from the WDADATALNKS datalink protocol menu, you must nevertheless choose to include the kernel LLC2 support necessary for X.25 Relay. In addition, DEC SNA Peer Server Installation and Configuration states that you should choose HDLC/LAPB if you are configuring Peer Server for QLLC only. You should actually choose either HDLC/LAPB or LLC2 (or both) depending upon whether you are running X.25 with local synchronous or X.25 Relay support. 4 Operating Notes 4.1 Synchronous Communications Support (SDLC) As with earlier versions of the Peer Server, V1.3 supports IBM's Synchronous Data Link Control (SDLC) WAN datalink pro- tocol for the SNA connection to the adjacent PU T2.1 or PU T4 node. (The AS/400 is an example of a PU T2.1 node. A mainframe front-end communications processor, such as a 3745 running IBM's NCP software is an example of a PU T4.) As with earlier versions, the synchronous port used by the Peer Server is provided by a combination of the Digital UNIX WAN Device Drivers software (included on the Peer Server V1.3 kit) and the synchronous communications hardware itself. Four types of synchronous hardware are supported with V1.3 of the Peer Server: the built-in, integral SCC sync port, the optional DSYT1 high speed TURBOchannel adapter (DSYT1-BA), the optional DNSES EISA synchronous communications controller hardware, and the optional PBXDI ISA synchronous communications controller. 4 The SCC port supports the V.24/RS-232 interface only, at speeds up to 19.2 kb/s. The optional DSYT1 (also known as the DEC WANcontroller 720) and the DNSES adapters both contain two lines per device and support SDLC up to T1/E1 (2.048 Mb/s for a single line and up to 64 kb/s when both lines are used. The DSYT1 and DNSES support both the V.24/RS-232 and the V.35 physical interfaces. The PBXDI controller supports two lines; one model (PBXDI-AA) supports the V.24/RS-232 interface, an- other (PBXDI-AB) supports both RS-232 and V.35 interfaces. (A third model (PBXDI-AC) exists but should not be used for SDLC.) External clocking (modems, modem eliminators, or NCP "direct attach" lines) are required in all cases. The SCC port is present on all DEC 3000 AXP systems supported by the Peer Server. On the 3000-300 and 3000-300L, however, the SCC port may only be used with the Peer Server when it is otherwise not used as the console port (that is, a monitor must be used for the console). Multiple DSYT1, DNSES, or PBXDI devices may be used for a higher number of concurrent links (each device having two links). All require a free bus slot (TURBOchannel, EISA, and ISA bus, respectively), and slot availability varies by spe- cific system model. For example, the 3000 Model 800/S has up to 6 free TURBOchannel slots (thus 13 links - 6 DSYT1's and a single SCC - may be used in the extreme case). Similarly, the maximum number of DNSES units is limited by free EISA slots and specific hardware configuration. Consult the Digital Systems and Options Catalog (Alpha AXP product hardware information) for full configuration details. As in earlier versions, the Peer Server can be configured with multipoint secondary station support (multiple SDLC stations on a given physical link when that link is configured with the Peer Server assuming the secondary role). By providing more than one station address on a link, this feature permits the Peer Server to support more than 255 dependent Logical Units on a single physical line, thus saving costs. 4.1.1 Modem Control and Link Configurations 4.1.1.1 Naming of Synchronous Lines The Modem Connect Line entities are assigned names based on the order that the devices are named during configurarion. When you execute or re-execute t21setup (or wddsetup), make sure that the devices are named in the same order as previously, or else the existing configurations of Peer Server or other products may become invalid. 5 Please specify which device(s) {dsy scc none} are to be used. [scc]: dsy scc 4.1.1.2 SDLC Modem Control Configurations SDLC links may be established in the following configura- tions, based on the SDLC Link "Capability" and "Configuration" NCL characteristic attribute values, as well as the under- lying Modem Connect Line entity "Duplex" and, in the case of multipoint secondary, the number of stations config- ured on the SDLC link. The "Capability", "Configuration", "Duplex", and Station attribute values are initially set during the t21setup and wddsetup steps, and are saved in /var/dna/scripts/wdd.mconnect.ncl and /var/sna/t21_init_sna_server.ncl, respectively. See DEC SNA Peer Server Management for full details. 1. Point-to-point full duplex ("4 wire") This configuration is typically used for leased line or lo- cal modem eliminator connections, or for V.32 dialup full duplex modems. The Peer Server may be either secondary or primary (if connecting to an adjacent PU T2.1 node). Unless configured as a PU T2.0 device to the peer node, the role is typically negotiated by XID3 negotiation at link initializa- tion time. The characteristic combination of "SDLC Link Configuration = PointToPoint" with the corresponding underlying line set as "Modem Connect Line Duplex = Full" establishes the link as point-to-point full duplex. Only a single station is config- ured on the link. The adjacent peer node is likewise config- ured for full duplex, typically by specifying DUPLEX=FULL in the NCP LINE macro or AS/400 Line Definition. In this configuration, the Peer Server's Request to Send (RTS) signal is constantly asserted; Clear to Send (CTS) and Data Carrier Detect (DCD) are expected from the DCE. As is true for all the configurations discussed in this section, Data Set Ready (DSR) is constantly asserted and Data Terminal Ready (DTR) is expected in return from the DCE. 2. Point-to-point half duplex ("2 wire") This configuration is typically used for connections over switched, dialup links. The SDLC role support is the same as the full duplex case above. 6 The characteristic combination of "SDLC Link Configuration = PointToPoint" and corresponding underlying line set as "Modem Connect Line Duplex = Half" establishes the link as point-to-point half duplex. Only a single station is config- ured on the link. The adjacent peer node is likewise config- ured for half duplex, typically by specifying DUPLEX=HALF in the NCP LINE macro or AS/400 Line Definition. In this configuration, the Peer Server's Request to Send (RTS) signal is toggled as necessary for data transmission; Clear to Send (CTS) from the DCE is expected to rise ac- cordingly (and be lowered as RTS drops). Data Carrier Detect (DCD) is expected to rise and fall in concert with data received from the DCE. 3. Full duplex multipoint ("4 wire"); one station per link This configuration is used when the Peer Server is one of several nodes whose link stations are sharing the same SDLC link. The adjacent primary station is configured to sup- port multiple secondary station addresses (multiple PUs or devices), one of which is the Peer Server. SDLC polling is accomplished by cycling through the configured secondary station addresses. The other tributary nodes may be at re- mote sites (through multidrop modems) or locally situated. In the local case, physical splitting of the link from the primary station is typically done with a modem sharing de- vice. The standard IBM host (primary) multipoint configuration is set up with the primary side treating the multipoint link as a 4-wire, full duplex connection. Each tributary (secondary) station generates modem control signals in half duplex fashion. The primary node is thus configured for ("4 wire") full duplex with multiple stations/PUs, typically by specifying DUPLEX=FULL in the NCP LINE macro or AS/400 Line Definition. The characteristic attribute combination of "SDLC Link Configuration = MultiPoint" and corresponding underlying line set as "Modem Connect Line Duplex = Full" establishes the Peer Server link as full duplex multipoint. In this configuration, the Peer Server link will toggle its Request to Send (RTS) with data transmission, in the same manner as with point-to-point half duplex. Full duplex multipoint, however, differs from point-to-point half duplex in that the primary station holds its own Request to Send (RTS) high constantly, meaning the Peer Server sees constant Data Carrier Detect (DCD) from the DCE. 7 NOTE The use of two-way simultaneous (TWS) transfer mode (as specified on the SDLC link station) in the full duplex multipoint case is not recommended. A known restriction with RTS/CTS handling in the Wide Area Device Drivers (wdd) product can cause retransmission and, ultimately, link failure. 4. Full duplex multipoint ("4 wire"); multiple secondary This configuration is used when the Peer Server is config- ured as a secondary (link characteristic "Capability" is set to secondary) but multiple stations have been created and enabled on the link(s). In this configuration, the Peer Server link appears to the adjacent node as if it consisted of multiple physical sta- tions, and hence multiple corresponding Transmission Groups are created. The advantage to a multiple secondary config- uration is for dependent LU capable links: where a single link and station can architecturally support up to 255 LUs, the multiple secondary configuration can support 255 de- pendent LUs for each station configured on the link. The Peer Server is seen by the adjacent node (typically an IBM mainframe Front End Processor) as consisting of multiple Physical Units (PUs). This gives the Peer Server access to larger numbers of dependent LUs while saving the costs associated with running multiple SDLC links. With the multiple secondary configuration, a tradeoff exists with respect to performance. While additional line costs are avoided, higher numbers of addressable LUs must con- tend for a fixed amount of link layer bandwidth. Response time will increase as stations (and LUs) are added. However, multipoint secondary is designed to be as efficient as pos- sible by taking advantage of the SDLC group poll feature, where the primary station may issue a "general" poll ad- dressed to all stations on the link, rather than polling each in succession. The primary station must be genned for group polling to take advantage of this feature. See DEC SNA Peer Server Guide to IBM Resource Definition for more information. Physical modem control signals are maintained by the Peer Server in this configuration as they would be for point- to-point full duplex. Request to Send (RTS) is maintained high consistently and Data Carrier Detect (DCD) is expected to remain high as well. (Note that this differs from the modem control used in the single station per link case, all other characteristic values being equal.) This will minimize turnaround latency, and thus achieve optimal throughput. 8 The partner node must be configured as full duplex as well. Since the Peer Server holds RTS high in this case, this configuration will not function with other physical devices on the same SDLC link, either as true remote physical drops or through a modem splitter or modem sharing device. The characteristic attribute combination of "SDLC Link Configuration = MultiPoint", corresponding underlying line set as "Modem Connect Line Duplex = Full", and the exis- tence of more than a single SDLC station under the link establishes the Peer Server link as full duplex secondary multipoint. 5. Half duplex multipoint ("2 wire") This configuration is typically not used with SNA network configurations. If required, the Peer Server will accommo- date it with a point-to-point half duplex link configuration (see above) by specifying "Modem Connect Line Duplex = Half" in combination with an SDLC link Configuration characteris- tic value set to "MultiPoint". 6. Half duplex multipoint ("2 wire"); multiple secondary This configuration is also not typically used in IBM en- vironments; it is equivalent to the above case except that multiple stations are configured on the link (see the full duplex multiple secondary description above for a descrip- tion of multiple secondary). This configuration is the same as that described for full duplex multiple secondary, except that the underlying Modem Connect Line entity Duplex is set to half instead of full. Unlike full duplex multipoint secondary, this configuration may be used with additional physical devices multidropped on the link, provided the primary station is itself half duplex (with RTS transitioning with each transmit). Likewise, there are no restrictions with the use of modem sharing or modem splitting devices. NOTE The use of this configuration is currently not recom- mended. 4.1.1.3 Multipoint Primary Not Supported in V1.3 As with earlier versions, V1.3 of the Peer Server does not support multipoint primary link configurations, where the Peer Server is SDLC primary and a single SDLC link entity has greater than one link station subentity. 9 4.1.1.4 Modem Connect Line Speed Characteristic The following pertains to half-duplex and multipoint config- urations, in which the local Peer Server DTE is toggling its Request to Send (RTS). Because of a limitation with the SCC, DSYT1, and DNSES hard- ware with regard to transmit interrupts, the respective device driver must compute the time to retain RTS assertion following the last data byte transmitted. The delay time is a function of the actual line speed, and the driver must therefore be aware of the speed of the link. To accommodate the RTS drop delay computation, the Modem Connect Line entity includes a characteristic attribute called "Speed." If the Peer Server is to be used in a half-duplex or multipoint configuration, the Speed characteristic must be set to the actual speed at which the line is being externally clocked. Speed is entered in bits per second, for example a 19.2 kb/s link would have Speed set to 19200. (When set to zero, the default RTS computation assumes an actual line speed of 1200 bits per second.) Failure to set the speed accurately will result in unpre- dictable results with half-duplex and multidrop lines, from reduced line throughput to transmission failures. On a mul- tipoint line, it is possible that a misconfigured Peer Server line could affect data transfer between other tributary sta- tions and the primary station. The wddsetup step of the V1.3 Peer Server (/usr/sbin/wddsetup), invoked as part of the product installation, includes prompt- ing for line speed when the line specified is half duplex or full duplex multipoint. If the Digital UNIX WAN Device Drivers are already present and configured on the Peer Server tar- get node and the wddsetup step is not re-run during the Peer Server installation, you must ensure that the Speed character- istic is properly set for the lines to work properly in half duplex and multipoint modes. Re-running /usr/sbin/wddsetup or manually editing the Modem Connect startup NCL file in /var/dna/scripts/wdd.mconnect.ncl and restarting will render the change permanent. 4.1.2 Additional Sync Comm Information 10 4.1.2.1 NRZI Encoding The wddsetup step described in Section 4.1.1.4 also prompts for NRZI or Normal line bit encoding (specified in the Modem Connect Line Encoding characteristic attribute). NRZI (Non- Return to Zero Inverted) bit is used with some older modem devices. It is mandatory that line encoding be set properly; a miscon- figured link will result in the total inability to receive or transmit data with no apparent cause for the failure. 4.1.2.2 SCC Device Name The SCC built-in synchronous port is referred to by NCL manage- ment and the WAN Device Driver scripts (wddsetup) as the "sscc" device, and as communications port "sscc0". The latter forms must be used when entering network management or configuration commands. 4.1.2.3 CCITT V.24 Incompatibility with EIA RS-232C (DSYT1 and DNSES only) An incompatibility exists between the CCITT V.24 and EIA RS- 232C physical interface standards with respect to pins 18, 21 and 23. The DSYT1 and DNSES are engineered for strict accor- dance with the newer V.24 standard, and is therefore incom- patible with the older RS-232C interface. In order to permit the DSYT1 and DNSES to be used with RS-232C compliant devices, a V.24 hardware adapter connector is supplied with the V.24 cable set (BS19D-02), part number 12-27591-01. The adapter is attached to the DCE end of the BC19D-02 V.24 cable. Refer to the information sheet supplied with the cable hardware for more information (info sheet EK-BS19D-IS-001). Failure to use the adapter where indicated will result in an inability to activate the line and possibly even damage the modem or interface module. If you are unsure whether the adapter should be used or not, it should be fitted as a matter of course. Note that doing so may disable remote and local loop functions. This issue does not apply to the SCC sync port, which has tolerance for the difference in the standards. No adapter is required with the SCC. 11 4.1.3 SDLC Link Station 'Modulo' Characteristic The SDLC Link Station "modulo" characteristic has no effect on incoming SDLC connections. If XID3 negotiation is done, then the expected modulo value is defined by the exchanged window sizes. If XID3 negotiation is not done, then the expected value is defined by the "window size" characteristic of the SDLC Link Station alone (if window size > 7, then SNRME is expected). If a SNRM command is received when SNRME is expected (window size > 7), or vice versa, the unexpected command is ignored. 4.2 Qualified Logical Link Control (QLLC) As with earlier versions, V1.3 of the Peer Server supports the QLLC protocol, a popular method for transferring SNA traffic over X.25 networks. 4.2.1 X.25 Configuration The X.25 for Digital UNIX Systems product must be installed prior to installing the Peer Server to use QLLC. It is also essential that the Peer Server QLLC configuration step (see DEC SNA Peer Server Installation and Configuration) be performed based strictly on the existing X.25 configuration, such that the QLLC link characteristic attributes align with the corre- sponding parameters established with the X.25 setup. Achieving the necessary conformity between X.25 and the Peer Server QLLC configuration will generally require that X.25 itself also be modified. Specifically: - the Template Name must be a valid X.25 Access Template - the DTE Class must be a valid X.25 Access DTE Class - the Filter Name must be a valid X.25 Access Filter - QLLC links being used for incoming calls must have a Subsequent Protocol Identifier that matches the Call Data Value of the X.25 Access Filter being used 12 4.2.2 X.25 Relay Considerations If you are planning X.25 access to an IBM mainframe environment using QLLC over LLC2 (LAN connection to a Digital UNIX X.25 node using the X.25 Relay feature), be aware that the IBM X.25 Network Control Program Packet Switching Interface (NPSI) con- figuration may require an additional configuration parameter. The X.25 for Digital UNIX Systems software on the relay node adds additional facilities (0xCB caller extension subset) to the X.25 call, which is considered non-standard by NPSI V3R4 and earlier. The NSTDFAC (non-standard facility) parameter can be used on the X25.NET statement to prevent the CB facility specification from clearing the call. An example of the X25.NET statement with NSTDFAC coded appears below: X25.NET DM=YES,NETTYPE=1,CPHINDX=2,OUHINDX=3,NSTDFAC=(CB)... 4.3 LLC2 LAN Support As with earlier versions, V1.3 of the Peer Server supports the LLC2 CONS Local Area Network protocol. LLC2 is part of the WDADATALNKS subset included with the Peer Server and also with both the DECnet/OSI and X.25 products. As with the WAN Drivers software kits, WDADATALNKS is included in the Peer Server prod- uct kit to address those customers planning on running LLC2 but who do not have DECnet/OSI or X.25 installed. LLC2 is supported over CSMA-CD (Ethernet), Token Ring, and (as of V1.3) FDDI MAC layers. The Peer Server Configuration utility (t21icu) will create and configure the MAC entities (station and communications port) if required. This is the case if the device is not already in use for alternate LAN access (DECnet/OSI, X.25, etc.). 4.3.1 SAP Link Remote MAC Address Format During the Peer Server configuration step, it is essential that the 12-digit LAN adapter address of the remote device ("Remote MAC Address") be entered in the proper format. The Configuration utility (t21icu) requires that the address be specified in "canonical" format, not the "wire" format as it would appear on the physical token-ring. The t21icu utility does not compensate automatically. Confusion often arises around the address format because Ethernet and Token Ring LANs typically require that the ad- dress be specified in opposite form. Specifically, the bits in each octet of the address are reversed. 13 If you are configuring the Peer Server LLC2 SAP Link remote MAC address to be used with Ethernet, you normally use the address as it is supplied for the IBM node network interface (as speci- fied in the Local Adapter Address parameter of the AS/400 Line Description). Note that the specific form used may differ by IBM device type; check with your network administrator if in doubt. If you are configuring the Peer Server to be used with Token Ring, in general you will need to normalize the 12-digit address specified by IBM (for example, in the AS/400 Line Description) into canonical form. Address conversion through network bridge devices should gener- ally be transparent in this regard. If you are configuring Peer Server Ethernet through a bridge to Token Ring on an AS/400, for example, you would still convert the address as specified for Ethernet on the Peer Server. The address conversion to canonical form is performed as fol- lows: 1. Separate the 12-digit hexadecimal address into byte sets (sets of two digits each), for example 62 89 C2 B8 7A 31. 2. Reverse the positions of the characters in each of the 2- digit sets (26 98 2C 8B A7 13). 3. Mirror the bit pattern in each "nibble" (digit), such as 46 91 43 1D 5E 8C. It may be helpful to visualize each nib- ble as a series of four bits to perform this, and a basic understanding of hex arithmetic is required. For example, 0x2 is '0010', which when mirrored is '0100', or 0x4. 4. Enter the result from the previous step, separated by dashes, as the Remote MAC address (for example, 46-91-43- 1d-5e-8c). The help text for the Remote MAC Address prompt in the Configuration utility contains an additional example. If you are unsure as to whether a given MAC address should be normalized or not before entering it, consult your network administrator or Digital support. 14 4.3.2 MAC Address Format when DECnet/OSI is Running DECnet/OSI modifies the LAN address supplied by the physical LAN adapter when the DECnet routing circuit specifies that the address is to be set to a DECnet Phase IV-style format. For example, AA-00-04-00-nn-nn is used where nn-nn is calculated from the DECnet address. You must be aware of this fact when configuring your LAN node MAC addresses. For example, the AS/400 LAN Remote Adapter Address parameter value must correspond with the modified form of the Peer Server's MAC address when the AS/400 is to communicate with a Peer Server running DECnet/OSI. Installing DECnet/OSI at a later time following Peer Server installation and SNA LAN node configuration will thus require that your adjacent SNA LAN nodes (e.g. AS/400) have their remote MAC ad- dresses reconfigured for the Peer Server node's changed local MAC address. The correct Peer Server address may be obtained from the LAN station entity MAC address attribute, or from the DECnet/OSI utility /usr/sbin/dna_getaddr. 4.3.3 Token Ring Hardware The hardware adapter required for Token Ring is the DEC TRNcontroller 700 (DETRA) TURBOchannel card or the EISA Token Ring Communications Controller (DW300/DT424). Both accommo- date 4 and 16 Mb/s ring speeds (selectable). A single hardware adapter may be used simultaneously with multiple protocols (for example DECnet/OSI, IP, and X.25), using different SAPs. 4.3.4 Ethernet Hardware All Digital-supplied Alpha AXP Ethernet adapters supported under Digital UNIX V3.2 are supported with this version of the Peer Server. 4.3.5 FDDI Hardware All Digital-supplied Alpha AXP FDDI adapters supported under Digital UNIX V3.2 are supported with this version of the Peer Server. 15 4.3.6 Ethernet 802.3 vs. Ethernet V2 Peer Server V1.3 (and Digital UNIX) supports Ethernet using IEEE 802.3 frame format, and not Ethernet V2. This may be an issue when configuring SNA over Ethernet to an IBM SNA node, which typically has a configuration option for Ethernet 802.3 or V2 (with protocol type 80d5). Ensure that your IBM Ethernet implementations (both destina- tion nodes and bridges, such as the IBM 8209) are configured to use the 802.3 format for Ethernet frame transmission for communication with the Peer Server. 4.3.7 Operation in Bridged Token-Ring and FDDI Environments When running the Peer Server in a bridged environment, it is possible that an intervening bridge or LAN segment supports a maximum frame size than that configured in the two communi- cating systems. V1.3 of the Peer Server has been enhanced to detect this and automatically reduce the maximum frame size used in this case. 4.4 WANDD Loader The wdd_loader program runs as a daemon process and is re- sponsible for handling microcode loading and dumping for those synchronous devices that require it. This daemon must not be killed; doing so may result in a system panic. 4.5 Automatic Generation of NOTIFY(ONLINE) and NOTIFY(OFFLINE) Starting with V1.2, the Peer Server now sends ACTLU responses that indicate the LU is not available by default. The product then sends NOTIFY(ONLINE) when an access routine connects to the LU, and NOTIFY(OFFLINE) when the access routine discon- nects. This is different from previous versions of the product and also different from the PU2.0 Gateway-ST and Gateway-CT products. This behavior can be modified such that the Peer Server behaves exactly as previous version and products if necessary, but doing so will mean that the product cannot be used for 3270 Terminal Emulator access to AS/400 systems. While this behavior is typically closer to real IBM equipment, it does cause problems when connections to the LU are made and broken in quick succession. It also causes problems when the LU is in session when the Peer Server is deactivated, as the next time the LU is used the host application may attempt to re- 16 BIND to the LU (which can override the real session activation request sent by the client). To turn off this feature, you should edit the file /var/subsys/t21scl.stanza and modify the line use-notify = 1 to be use-notify = 0 then enter the following command (as root): # sysconfigdb -u -f /var/subsys/t21scl.stanza t21scl This will modify the permanent database, which will take affect next time the system is booted. To modify the running system, use the following command: # sysconfig -r t21scl use-notify=0 The new setting will take effect the next time each LU is acti- vated. 4.6 Using More Than 128 DECnet Connections The default DECnet configuration allows for a maximum of 128 concurrent DECnet links. If you wish to have more than 128 DECnet connections into the Peer Server system, you must edit the DECnet NSP startup script. Edit /var/dna/scripts/start_nsp_transport.ncl and add the fol- lowing two lines between the "create nsp" and "enable nsp" commands. The maximum remote nsaps characteristic must be set to at least 3 greater than the maximum transport connections characteristic. set nsp maximum transport connections = x set nsp maximum remote nsaps = y In addition, edit /var/dna/scripts/start_osi_transport.ncl and add the following two lines immediately before the (enable osi transport) commands. The maximum remote nsaps characteristic must be set to at least 3 greater than the maximum transport connections characteristic. set osi transport maximum transport connections = x set osi transport maximum remote nsaps = y In the above two cases, x is the number of DECnet connections that you wish to allow, and y is at least 3 more than that. Refer to the DECnet/OSI documentation for full details. 17 4.7 Specifying PU Name and Session Number on Client Connections The Peer Server Logical Units (LUs) are named entities and have an attribute called "Old Name" that can be set so that existing client applications can continue to connect to spe- cific LUs using the PU name and Session Address syntax used with DECnet/SNA Gateway-ST and -CT. Specify the Old Name in the format [pu-name.][session-number]. If a client connection is received by the Peer Server specify- ing only a PU-name and no session number, the Peer Server will not use the PU-name when attempting to match the connection to an LU with an "old name" set. 4.8 Session Termination Support Added for Non-IBM Mainframes Certain IBM plug compatible (PCM) mainframe SNA implemen- tations, e.g. Fujitsu, are known to require dependent SLU initiated session termination with (Rq)TERM-SELF instead of (Rq)UNBIND. This support has been added to Peer Server LU Services; in the case where an LU-LU session (Rq)UNBIND sent from Peer Server to the mainframe is rejected with 1003 -Rsp, a TERM-SELF will be sent from Peer Server to solicit an UNBIND from the PLU. This change addresses PCM compatibility without affect to stan- dard IBM mainframe session behavior. 4.9 Startup Initialization Delay The time between starting the Peer Server (from system boot, running of the t21icu Configuration utility, or explicit ex- ecution of "t21_sna_server start" from /sbin/init.d) and full initialization may be on the order of minutes, particularly if your specific t21_init_sna_server.ncl has a very large number of LUs and related entities specified. Confirmation of initialization completion can be seen by run- ning a Digital UNIX system utilization utility (for example iostat, to show CPU utilization dropoff following comple- tion) or by interactively running NCL on the Peer Server ma- chine, confirming final entity enabling. In addition, the file /var/tmp/t21_init_sna_server.log contains the output from the initialization. 18 4.10 OS/2 LAN Support Withheld As documented in DEC SNA Peer Server Guide to IBM Resource Definition, formal support for connections to OS/2 Extended Services and Communications Manager are limited in this release to SDLC. 5 Fixed in Version 1.3 Some restrictions and problems present in the V1.2 Peer Server product have been resolved in the V1.3 software, including: o The Peer Server will no longer crash if it receives an XID with a network-qualified PU name in the Network Name Control Vector. 6 Known IBM Restrictions The following sections list problems identified with IBM soft- ware that you may encounter when installing/running the Peer Server in your environment. APAR and PTF numbers are provided that can be used to ensure that your VTAM/NCP installation has the fixes applied. 6.1 Configuring Multiple Lines as PU T2.1 on the Peer Server If you are configuring multiple lines on the Peer Server to connect to the IBM front-end (3725/3745) as a PU T2.1 link (XID=YES on the PU macro) you need to code CONNTYPE=LEN on the PU macro also. If CONNTYPE=LEN is not coded, the activation of the second line fails with a sense code of 081D. This problem is due to the Peer Server sending the same CP Name on each link (which is consistent with an SNA LEN node). 6.2 IBM 3745 Scanner Problem Running Above 230Kbps When connecting a DSYT1 or DNSES high speed SDLC line to an IBM 3745 communications controller running a line speed of 256 kbps, the IBM controller may report hardware underruns. The symptoms of the problem on the Peer Server are that the link fails and restarts, or that a large number of SDLC frames are retransmitted. This problem is not seen on links running at 230 kbps or below. Contact your Digital Customer Support Center for an update or resolution to the problem if you plan to run SDLC links at that speed. 19 6.3 NCP Problems with SDLC Mixed Modulo Stations on a Multipoint Line A problem exists in NCP V4, V5, and V6 whereby an SDLC mul- tipoint line configured with PU T2.1 stations of both normal (modulo 8) and extended (modulo 128) SDLC window sizes can er- roneously issue a modulo 128 SDLC poll from the NCP to a modulo 8 station. This has been corrected with the following APARS from IBM: o NCP V4 IR24362 o NCP V5 IR24307 o NCP V6 IR24170 6.4 NCP problems with modulo 128 Token Ring Stations A problem exists in NCP, whereby the NCP is always indicating that it is able to receive 128 frames between acknowledge- ments from a modulo 128 token ring station, when in fact it can only receive much fewer. This results in many unnecessary retransmissions, and can seriously degrade performance. This has been corrected with the following APARs from IBM: o NCP V6 IR25667 6.5 INIT-SELF rejected with sense code 10105006 Under heavy traffic conditions, VTAM can intermittently reject INIT-SELF requests with a sense code of 10105006, when in fact the response should be positive. This has been corrected with the following APARs from IBM: o VTAM V4R1 OW02909 o VTAM V4R2 OW04173 6.6 VTAM ABEND S0C4 at ISTATCTR+1F0 VTAM can intermittently ABEND while writing an internal trace record when the Peer Server has just established the data link connection over X.25 or token ring. This has been corrected with the following APARs from IBM: o VTAM V4 OW06433 20 7 Known Problems and Product Restrictions Known restrictions existing in the V1.3 software are detailed in this section. 7.1 Installation and System Configuration Restrictions 7.1.1 Common Agent must be selected for SNMP Management to be possible In order for the Peer Server to be managed via SNMP, the Digital UNIX system must be configured to use the common agent for management. This can be done using the snmpsetup command. If the Common Agent is not configured for use, then it will still be possible to manage the Peer Server using the ncl util- ity locally. It is also possible to manage it remotely via DECnet/OSI if you have this product installed. 7.2 Common Trace Facility (CTF) Notes 7.2.1 LU Tracepoints Not Supported Because of a CTF limitation in the maximum number of concur- rently declared tracepoints, the V1.3 release of the Peer Server does not support tracing on the LU entity (LU trace- points) as described in DEC SNA Peer Server Management. Tracing can be done by Transmission Group to trace activity across all sessions on the TG, or on an individual session basis (Session tracepoints). Despite the lack of LU tracepoints, tracing of session(s) be- longing to a specific LU can be accomplished as shown in the following CTF command example (LU name "t001"): ctf>start sna lu services lu t001 session * 7.3 Restrictions with Network Management 7.3.1 NCL Delete Transmission Group "Wrong State" Exception A Transmission Group that is dependent LU capable and has one or more enabled LU Services dependent LUs referencing it cannot be deleted until the LUs are themselves disabled. An attempt to delete a Transmission Group with active dependent LUs will result in a "Wrong State" error exception. "Wrong State" is also produced for failed attempts to delete a Transmission Group when it is not first disabled (entity state OFF and pro- tocol state RESET), and both conditions must be considered when "Wrong State" is returned. 21 An example of the failure follows: ncl> dele sna cp serv t g tg005 Node 0 SNA CP Services Transmission Group TG005 AT 1994-11-23-10:11:07.000-05:00I----- FAILED IN DIRECTIVE: Delete DUE TO: Error specific to this entity's class REASON: Wrong state Description: Wrong state 7.3.2 NCL Enable SDLC Link Station "Invalid Parameter" Exception An ambiguous NCL exception of "Invalid Parameter" will be pro- duced when attempting to enable an SDLC link station where the station and/or the parent link have an invalid Send or Receive Frame Size set, respectively. This is most commonly a problem when configuring SDLC for the built-in SCC device, which has an upper limit size of 1021 bytes. Note the exception occurs when enabling the station and not the link. For example, a link configured with a Receive Frame Size of 1024 (too high) is successfully enabled. Its child station, with a Send Frame size of 1000 (legal) will incur an NCL "Invalid Parameter" exception at the point it is enabled. The solution in this example is to disable and correct the link Receive Frame Size, re-enable the link, and enable the station. An example of the failure follows: ncl> enable sdlc link sdlc-0 sta stn-40 Node 0 SDLC Link sdlc-0 Station stn-40 AT 1994-05-03-13:04:59.000-04:00I----- FAILED IN DIRECTIVE: Enable DUE TO: Error specific to this entity's class REASON: Failure Description: Failure Reason = Invalid Parameter 7.3.3 LocalEntityName Instance Specification With Peer Server V1.0 it was possible to specify a LocalEntityName instance using parenthesis, for example: set sna cp services trans group tg-1 - datalink = (sdlc link foo station bar) In fact, the V1.0 Initialization and Configuration Utility (t21icu) generated this syntax automatically. 22 Due to some changes in NCL processing introduced with DECnet/OSI V2.0, it is no longer valid to specify LocalEntityNames using parenthesis, and doing so will generate an NCL syntax error, e.g. "SYNTAX ERROR: No match was found for this string." The Peer Server t21icu has been modified to accommodate the new requirement; however, if you were a Peer Server V1.0 customer and will be running NCL scripts generated with the older t21icu utility (or generated manually), those scripts must be modified in order to work properly with V1.3. The t21_init_sna_server.log file, located in /var/tmp and created at the time of Peer Server startup, will reveal this error. 7.3.4 No Support for CMIP "with" Clauses on NCL Commands The Peer Server network management does not support using the prepositional phrases as documented in DEC SNA Peer Server Management. A future version of the Peer Server may add support for this. The following is an example of such a command: ncl> show sna access server port *, with node = xxxx" 7.3.5 Token Ring Entity not Manageable by SNMP Due to a problem with Digital UNIX built-in MIB Token Ring support, management of the Token Ring module with SNMP from POLYCENTER Netview is unsupported. We expect to correct this restriction in a future release. 7.4 Restrictions with SNA LU Services 7.4.1 Independent LU Capability Problem with Passive Listens Due to a problem in the Peer Server SNA LU Services mod- ule, client "passive" LU-LU session listens (Secondary LU, Independent LU session) will fail if the LU has been configured as Independent but with a Capability characteristic value of "secondary". The nature of the failure is "LU Unavailable". The workaround is to configure the LU with a Capability of "both". The Installation and Configuration utility uses "both" as the default, so the problem will be encountered only if the Capability is explicitly supplied as "secondary". 23 7.5 SDLC Datalink Restrictions 7.5.1 Multipoint Full Duplex Configuration Requires TWA As noted elsewhere, the use of two-way simultaneous (TWS) transfer mode (as specified on the SDLC link station) in the full duplex multipoint case is not recommended. A known re- striction with RTS/CTS handling in the Wide Area Device Drivers (wdd) can cause aborted frame retransmission and, ultimately, link failure. 7.5.2 Using the PBXDI ISA-bus synchronous communications controller o Only those models which support RS-232C or V.35 interfaces (PBXDI-AA and PBXDI-AB) are supported for use with SDLC. o Half-Duplex is not supported. o Transmission of frames larger than 1022 bytes (including SDLC header) is not supported. The SDLC Link Send Frame Size should not exceed 1020 for modulo 7, and 1019 for modulo 127. o The Interface Type attribute for the Modem Connect Line entity will not accurately reflect whether an RS-232C or V.35 interface is currently in use. This inaccuracy lies in the management attribute only and does not actually affect the operation of the controller. 7.6 QLLC Datalink Restrictions 7.6.1 Temporary TGs Lack Automated Call Startup Dependent LU session traffic (for example, 3270 LU2 termi- nal sessions) does not automatically activate a temporary Transmission Group when initiated from the client (Secondary LU) side. This handling is based on the assumption that an SLU not yet activated from the IBM host (that is, no ACTLU yet received) cannot initiate an LU-LU session (using INIT-SELF). There are circumstances with QLLC and X.25 networks where call initiation based on an SLU request for session could bene- fit from such behavior. We will be addressing this issue in a future release. 24 7.6.2 Filtername Mismatch Error is Ambiguous As explained in Section 4.2, the use of filter names must be consistent between the X.25 product and Peer Server QLLC entity configurations. If a QLLC link is set up with a filter name that doesn't exist in the X.25 configuration, an Enable of the TG fails with: FAILED IN DIRECTIVE: Enable DUE TO: The target implementation does not support this entity class Should this error occur, CTF may be used to determine if the problem is due to a filter mismatch as shown below (no event message is generated in this case). ctf>start qllc link *,live . . 08:06:31.94| Tx| 14| X_LISTEN_RE| 08:06:31.95|Rx | 16| X_ERROR_ACK (xerrno=-176) Specified . filter does not exist . 7.6.3 QLLC Link and Station must be Enabled Before TG When configuring a Transmission Group (TG) for use with a QLLC link, the link and underlying link station must be enabled before enabling the corresponding (TG). The enable of the TG will fail with an "entity class not supported" exception error if this order is not followed. 8 Files Installed/Modified The following table lists all the files placed onto the sys- tem during the Peer Server installation, or created during configuration. Table_1:_Peer_Server_Installed_Files___________________________ ___Directory______________Filename_____________________________ /dev/streams/ t21_smgd t21cpnm t21ctrl t21mgmt t21llc q25_qllc 25 Table_1_(Cont.):_Peer_Server_Installed_Files___________________ ___Directory______________Filename_____________________________ q25_mgd q25_xpi t21sd_ctrl t21sd_mgmt t21trc t21sdlc t21sess0 t21wadd /sbin/init.d/ t21_sna_server /sbin/rc0.d/ K09t21_sna_server /sbin/rc3.d/ S90t21_sna_server /sys/opt/T21SRVR120/ config.file files /usr/sbin/ t21_init_sna_server.ksh cacml t21cad t21cadgas t21mad t21mcd t21smd t21smc q25mad q25mcd t21trcd t21setup tn3270_setup tn3270_server /usr/share/dna/dict/ ncl_dna5_sdlc.ms ncl_dna5_sna_access_server.ms ncl_dna5_qllc.ms ncl_dna5_sna_lu_services.ms t21_server.hlp /var/sna/ q25mcd.conf qllc.mib snacp.mib 26 Table_1_(Cont.):_Peer_Server_Installed_Files___________________ ___Directory______________Filename_____________________________ snalu.mib snagap.mib sdlc.mib t21icu t21mcd.conf t21smc.conf t21strsetup.conf t21_V13-0_release_notes /var/subsys/ t21llc.mod t21qllc.mod t21scl.mod t21scl.stanza t21sdlc.mod __________________________t21spd.mod___________________________ The following table lists various operating system or layered product files that are replaced or modified by the Peer Server installation and configuration. Table_2:_Peer_Server_Modified_Files____________________________ ___Directory______________Filename_____________________________ /etc/eca/ mir.dat /usr/bin/ ctf /usr/share/ctf/ ctfua_library.c libctflibs.a ___/usr/share/dna/________cnmDictionary.dat____________________ 27 Appendix A Documentation Addenda This appendix contains additional information not found in the DEC SNA Peer Server Version 1.2 documentation set. The material in this section represents new material which has not yet been added to the regular documentation, but which will be added when the documentation is next released. The information in this appendix should be read in conjunc- tion with reading the regular documentation - it is not self- explanatory. A.1 FDDI Connections This section describes how to install and configure the Peer Server to use FDDI connections for SNA Communications. FDDI is a high-speed LAN connection. Like Token-Ring and Ethernet, you must use the LLC2 data link protocol to operate FDDI connections for SNA communications. A.1.1 Planning Before configuring the Peer Server, you need to gather some information that you will need to respond to all the configura- tion questions. The information listed below is in addition to what is de- scribed in Section 3 of the Installation and Configuration Guide. Documentation Addenda A-1 A.1.1.1 FDDI Controller Configuration When configuring the Peer Server, you can choose whether or not the Peer Server start-up procedure creates and initializes the FDDI entities which correspond to the FDDI controllers on your system. If you have another product, such as DECnet/OSI or X.25, which creates the FDDI entities before the Peer Server is started, then the Peer Server does not need to create the FDDI entities as part of its start-up procedure. If the FDDI entities are not created before the Peer Server is started, then the Peer Server start-up script needs to create the FDDI entities so that it can use FDDI for SNA communica- tions. You can determine if the FDDI entities are created by using the following NCL command: NCL> show fddi station * communication port By executing this command just before the Peer Server is started, you can determine if the Peer Server needs to create these entities. If the FDDI entities are already created, one or more FDDI Station entities will exist, and the communication port name will refer to an FDDI controller. Make a note of the station names and corresponding communications port names. If the FDDI entities must be created, then you need the list of FDDI adapters on your system, in the format 'ddn', where 'dd' is the device adapter name, and 'n' is adapter number. For example, fta0. Then, for each FDDI adapter, you must assign a station name: FDDI-0 for the first, FDDI-1 for the second, etc. The commu- nication port name for each station is the same as the FDDI adapter name. Figure A-1: The FDDI Worksheet _______________________________________________________________ FDDI Station [FDDI-0]: ________ ________ ________ Communication Port [fta0]: _____ _____ _____ Peer Server creates FDDI entities during start-up (y/n)? ___ _______________________________________________________________ A-2 Documentation Addenda A.1.1.2 LLC2 Configuration The planning for this is identical to planning Token Ring or Ethernet connections, with just a few exceptions. o The LAN Station Type is "FDDI". o The LAN Station Name is the FDDI station name, for example "FDDI-0". A.1.2 Configuration The following section describes how to use the Peer Server's installation and configuration procedures to generate an FDDI configuration. The information listed below is in addition to what is de- scribed in Sections 2 and 4 of the Installation and Configuration Guide. A.1.2.1 t21setup kernel When you are executing the t21setup kernel procedure to rebuild the kernel, the system will prompt you to choose if you want to include the LLC2 interface in the build. You must choose yes in order to use FDDI connections. Example A-1: t21setup kernel _______________________________________________________________ Do you wish to configure LLC2? (y/n) [n]: y _______________________________________________________________ Later in the configuration, the system will prompt you to to choose which level 2 datalink protocols you wish to install. You need to include the LLC2 (LAN) data link protocol, so you must choose option 3 or option 4. Example A-2: t21setup kernel _______________________________________________________________ Select one of the following data link protocol options: 1) No Level 2 datalink protocol is required. 2) The HDLC/LAPB Synchronous datalink protocols are required. 3) The LLC2 (LAN) datalink protocol is required. 4) All datalink protocols (HDLC/LAPB/LLC2) are required. _______________________________________________________________ Example A-2 Cont'd on next page Documentation Addenda A-3 Example A-2 (Cont.): t21setup kernel _______________________________________________________________ Enter datalink protocol option(s) required [2]: 4 _______________________________________________________________ A.1.2.2 t21icu When you are executing the t21icu configuration procedure, you need to enter information in the LLC2 Configuration sec- tion (section 2.3) to create SAPs and SAP Links for your FDDI connections. When the configuration utility prompts you for the LAN Station type of your SAP, enter "FDDI". When it prompts you for the LAN Station name for a SAP, provide the name of an FDDI Station entity, for example "FDDI-0". This name will either be the name of a pre-existing FDDI station entity, or the name of one which will be configured later. All other information is provided as per the documentation. Before you complete this section of the configuration, the procedure will prompt you to indicate if you wish to configure FDDI. Enter "yes" if the Peer Server is to create the FDDI entities as part of its start-up procedure. If you answer yes, you will be prompted to provide the commu- nication port name for each FDDI station that the Peer Server will use. A-4 Documentation Addenda Example A-3: t21icu _______________________________________________________________ Section 2.3 - LLC2 Configuration. --------------------------------- This section gathers information for LLC2 links. SAP Name [SNA-0] : LAN Station Type [Token Ring] : fddi LAN Station Name [FDDI-0] : Local LSAP Address [04] : LINK Name [LINK-0] : Maximum Data Size [1028] : Remote LSAP Address [04] : Remote MAC Address (xx-xx-xx-xx-xx-xx) [] : 08-00-cb-18-15-c3 LINK Name [] : SAP Name [] : The FDDI module entity and its subentity, station, are necessary for LLC2 operation over FDDI LAN. The entities may have already been created while configuring DECnet or X.25. If not, you will need to do it now. Do you wish to configure FDDI [YES] ? y Configuring LAN Station: FDDI-0 Communication port name [fta0] : _______________________________________________________________ Documentation Addenda A-5