$ # Note on Problems Updating ODBC/DRDA Driver During Setup
A problem can occur when SNA Server Setup attempts to update certain .DLL files required for the ODBC/DRDA driver. The following or similar message can appear:
SNA Server 2.11 SP1: acmsetup.exe - DLL initialization failed
Initialization of DLL  Z:\WINNT\I386\SERVER\ODBC\ODBCCP32.DLL failed.  The process terminated abnormally
This problem can occur if older ODBC .DLL files exist on the computer when SNA Server Setup attempts to update the ODBC/DRCDA driver. If you encounter this problem, after installing SNA Server 2.11 or SNA Server 2.11 Service Pack #1, update the ODBC/DRDA driver by running SETUP.EXE in the \WINNT\platform\SERVER\ODBC directory on the Service Pack #1 CD-ROM or in the \platform\SYSTEM\ODBC directory on the SNA Server 2.11 CD-ROM.

$ # Additional Information
This section contains new information about using SNA Server version 2.11.
Note on Running  INSTALL.BAT From a Shared Network Directory on Windows NT Shell Update Release
Note on Installing the Bus-Tech Channel Link Service
Note on Using Shared Folders from Client Access or PC Support
Note on Twinax Link Services (ANDWTDLC and IBMTDLC)
Notes on Installing Eicon Link Services (ECSDLC or ECX25)
Note on APPC Invokable TPs and Removal of SNA Server or Client
Note on Installing SNA Server and Rebuilding the Windows NT Emergency Repair Disk
Note on Updating DEMO SDLC Link Service from the Service Pack
Note on Problems Updating ODBC/DRDA Driver During Setup

$ # SNA Server 2.11 Service Pack 1 Installation Instructions
If you received this Service Pack as part of a release of SNA Server 2.11, the Service Pack updates are automatically applied when you install SNA Server 2.11 from this CD-ROM.
If you received this Service Pack separately, upgrade your environment by running UPDATE.EXE or UPDATE.BAT in the appropriate directory. 
For example, to update SNA Server on an Intel-based computer, run \WINNT\I386\SERVER\UPDATE.EXE. If you are upgrading MS-DOS-based or OS/2-based client software, run UPDATE.BAT in the \MSDOS or \OS2 directories, respectively.
Note that there is no update program for the Windows 95 client. If you installed the Windows 95 client from the Microsoft FTP site on the Internet, first remove that installation using the remove option in the SNA client Setup program, then run SETUP.EXE in the Win95 directory of the Service Pack 1.

$ # SNA Server 2.11 Service Pack #1 Bug Fixes
TN3270
Error Message Text
SNA Server Admin
APPC/CPI-C API
AFTP
TCP/IP
LUA/RUI/SLI API
Application Exceptions
Clients
Setup
Connections/Link Services

$ # TN3270 Bug Fixes
TN3270 Incorrectly Formats LU-SSCP Data From The Host
TN3270 Service Will Not Start With A Large Config File
TN3270 Server Rejects Client Model Types
TN3270 Server Can Incorrectly Terminate a Session
TN3270 Server Service Fails to Start Automatically
TN3270 User Session Is Lost Unexpectedly
Memory Leak in TN3270 Server if RU Sizes Exceed TN3270 Defaults
TN3270 Hang if Host Sends Maximum RU Equal to 0 in BIND
TN3270 Clients Cannot Connect with a Lower-Case LU Name
TN3270 Server Rejects First Data RU After Host's CLEAR Message
TN3270 Server Incorrectly Formats Mod 5 Terminal LU-SSCP Screens
TN3270 Server Does Not Generate a Dr. Watson Log

$ # Error Message Text Bug Fixes
Event 624 Logs Improper File Name in Explanation Text
SNA Server DLC Outage Codes Should be Logged in Hex.
Enhanced Error Description for Message 631
Event 24 Is Logged w/ Severity Levels Information and Warning
SNA Server Internal Traces Do Not Log SNA Server Version

$ # SNA Server Admin Bug Fixes
Changing Domains in SNA Admin Gives Wrong Status Information
SNA Admin Error Message Changing Domains When Using TCP/IP
SNA Server Does Not Allow Configuration of LU Address 255
SNA Server 2.11 Admin shows Inactive Status In Error
SNACFG.EXE Fails with Spaces in Username Parameter
Error 3846: The Control Point Name is Invalid
SNA Server Admin May Show Incorrect Status for LUs 54 - 106
2 Connections Using Same Link Service and Destination Address
SNA Server Admin "Select Domain" Dialog Box Suspended
Error 4119 when Selecting SNA Server Admin Security Options
WINMGT.H Problems with Win32 Structure Packing
SNA Server Event 553 Running Novell Requestor for Windows NT

$ # APPC/CPI-C API Bug Fixes
Cannot Build APPC Library DTRACS.LIB
APPC Allocation Error Running Multithreaded Random & Bounce TP
SNA Server Admin Lists Wrong Dependent APPC LU as "In Session"
Windows 95 AFTP Client Reports WINAPPC.DLL is Corrupt
Win32 CPIC CMEPLN Call May Return Truncated Partner LU Name
SNA Server Windows 3.x APPC Display Call May Cause GP Fault
Client RPC Call for Remote APPC LU List Causes SNABASE Error
SNA Server CPIC cmscsp Call Rejects Zero Length Password
WinAPPCCancelAsyncRequest Never Returns WAPPCALREADY (0xF000)
CPI-C cmecsu() Call Always Returns pLengthUserID=1
SNA Server Event 38, Qualifier 0004 and 0005 Not Documented
VB CPIC Application Returns CM_PRODUCT_SPECIFIC_ERROR (20)
SNA Server EHNAPPC Security fails using 10 Character User ID
SNA Server Event ID 18 Reports Incorrect Sense Data
APPC Problem Handling AP_PGM Security with NULL Password
APPC/5250 Hot Backup Fails if Configured for "On Demand"
Event 582 may occur when running Win 3.x APPC or CPIC App
RECEIVE_ALLOCATE Fails With F011 on Windows 95 Clients
SNA Server 2.11 CD missing Rally-compatible PC Support API
EHNAPPC Data Stream Header Data Being Passed to TP
5250 Applet Causes GP Fault when Entering AS/400 Host Editor
The CPIC Thunk DLL Does not Support XCECST()/CMECST() Calls
SNA Server Events 94 and 592 Fill Up Application Log

$ # AFTP Bug Fixes
AFTP -F Script Fails if Password is Eight Characters Long
AFTP Server May Stop Accepting New Conversations
AFTP Client Does Not call WinCPICCleanup()

$ # TCP/IP Bug Fixes
Stop Msg: 0x0000003F NO_MORE_SYSTEM_PTEs SNA & TCP/IP Sockets
Problems with Multiple Sessions over TCP/IP using NetSoft Elite
SNA Server Fails to Release Memory in SNA TCP/IP Interface DLL

$ # LUA/RUI/SLI API Bug Fixes
LUA Program Receives Host Sign-On Screen Twice and then Hangs
SLI Interface Returns Truncated Data on SSCP-LU Session
Dynamically Loading/Unloading WINRUI32.DLL Causes System Hang
SNA Server Incorrectly Flips Sense Code Sent by RUI App.
RUI Application Does Not See STSN.REQ
RUI Problem Handling RUI_SEND After Sense Data Received
Windows NT LUA Application Hangs After 32767 SLI_SEND Commands
WinRUICleanup Sets Incorrect Return Code
SNA Server WinSLI Library Does Not Support Format 1 InitSelf
32-bit Windows SLI Applications Encounter Application Exception
RUI FI RH Bit Modified by SNA Server

$ # Application Exception Bug Fixes
Stopping SNA Server Causes Application Exception in SNALINK.EXE
SNASERVR.EXE Traps When it Receives an Illegal SIGNAL Command
Event 11 (1178) Causes SNA Server to Fail Abnormally
Invalid Named Pipe Message Causes SNABASE.EXE Exception
Event 624: SNA Server Application Exception
Winlogon Traps Running Performance Monitor Against SNA Server
Application Exception in SNA Server 802.2 Link Service
Attachmate Extra! 3270 V4.x Causes Trap in SNA Server Service

$ # Client Bug Fixes
SNA Win 3.x Client (WNAP.EXE) Hogs CPU, Affects Some Apps
SNA Server Event 563 and Win 3.x Client Application Problems
SNA Server Setup Resets CA400 Settings in WNAP
Problem Accessing SNA Server from Windows NT RAS Client
Emulator Disconnected after FMI Error Code x‘0050‘
SNA Server Windows 95 Client 5250 Applet Print Screen Fails
Windows 95 SnaBase Uses Taskbar Even When Not Shown
Win95 Client Setup Puts SnaTcp Registry Key in Wrong Place
SNA Server Win3x Banyan Client Displays Incorrect Username
SNA Server Error: Cannot Load Lucida Typewriter Font
SNA Server 3270 Emulator Session Drops With Event ID 21
SNA Remote Access Service Client May Not See Remote Network

$ # Setup Bug Fixes
SNA Server Windows 3.x Client Setup Fails without AUTOEXEC.BAT
SNA Server Setup Always Adds COMNETMN to Registry in Error
Setup: Wrong Info in "Select Client/Server Protocols" Dialog
Disk and Setup Problems with Win16 to Win32 Thunking DLL Files
MS-DOS Client Setup Fails with Error CSU7520

$ # Connection/Link Service Bug Fixes
Downstream Connection Should Default to Incoming Calls
SNA Server Twinax Connection to IBM 5494 Traps with 0x00000050
DEMO SDLC Link Service Setup Script Removes Wrong Link Service
SNA Server DFT Link Service Outage 0x11 (DSR Failure)
SDLC Multidrop Primary Configuration Problems
SDLC Multidrop Primary Needs to be Remote End = Host System.
DSPU Through Demo Link Service Causes Scrolling 3270 Screen
Failure of One SDLC Multidrop Connection Reactivates All Others
802.2 Link Service Hangs APPC Program or Causes Event ID 592
Node Retries Open(Link) on X.25 Even After Error is Reported
AS/400 Demo Link Service Fails to Log Events

$ # SNA Server 2.11 Service Pack #1 Enhancements to Existing Features
ODBC DRDA Driver Enhancements
TN3270E Support Added to the TN3270 Service of SNA Server
TN3270 Server Now Supports Client Load Balancing
Ability to Change Password Added to SNA Win3.x Client
RUI Interface Enhancement to Avoid Duplicate Signon Screens
RUI_READ Enhancement for Receiving Large RUs
Dynamically Adding LUA LUs is Supported
Performance Improvements for 3270/LUA Apps
Support for sending User ID on Attach when AP_SAME specified
2 New Win32 CPIC APIs: Asynch Verb Completion Via WinNT Events
TPSTART Enhanced to Support 16-bit Windows Applications
SnaBase Now Limits Domain or Subdomain to 15 SNA Servers
Compatibility with S/36
Disabling TCP/IP Nagle Algorithm Improves Speed on Slow Nets
How to Enable SNA Server IPX/SPX Clients to Use SPXII
SNA Admin Loads Faster with Improvements in SNACFG.DLL
Improvements for EIS/3270 and APPC Resource Location
Internet Firewall Support in SNA Server
SNA Server MS-DOS Router Session Limit Increased to 10
SNA Server Pool Limit Extended to 10,000
Username/Password Support in SNA Server Win95 Client Registry
Domain/Server Command Line Parameter Added to SNAADMIN

$ # Windows 95 Client Software
Windows 95 Client
The SNA Server Client for Windows 95, previously available only through the Internet on the Microsoft World Wide Web and the Microsoft FTP server sites, is now included in the latest SNA Server Service Pack.
Banyan Vines Transport
Support for the Banyan VINES transport has been added to the Windows 95 client in this Service Pack. The Banyan VINES option will now appear in the Select Client/Server Protocols dialog box during the Windows 95 client setup if Banyan VINES is detected on the client machine.
While testing this new Windows 95 client support against SNA Server 2.11, a memory leak problem was found in the SNA Server 2.11 Vines transport interface (SNABV.DLL). This problem does not occur if the SNA Server Windows 95 Banyan client is not being used.

RESOLUTION
==========

Microsoft has updated the file LIBS\WIN32\SNABV.DLL to correct this
problem.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kb3rdparty kbbug2.11
KBSubcategory: ntnetserv ntconfig
Additional reference words: prodsna 2.11

$ # Installing the FTP-AFTP Proxy Gateway Service
You will need to have both the AFTP and FTP Services installed on your machine before you can set up the FTP-AFTP Proxy Gateway service.
To install the AFTP Service
1	Install SNA Server	
2	Configure APPC resources in SNA Server Admin
3	Configure the AFTP Server
4	Start the AFTP Server service
For detailed instructions on these steps, please refer to Chapter 12 of the Microsoft SNA Server Enhancements Guide.
To install the FTP Services
1	In the Control Panel group of Program Manager, click on the Network icon.
2	Click the Add Software button.
3	In the Add Network Software dialog box, select the TCP/IP protocol and related components.
4	Click Continue.
5	Select the FTP Server Service check box. If this check box is grayed, then the FTP Server Service is already installed.
6	Click Continue.
7	Enter the location of the Windows NT distribution files.
8	Click continue.
9	Make any desired changes in the FTP Service dialog box, and click OK.
10	Click OK to close the Network Settings dialog box.
11	Restart your computer.
To set up the FTP-AFTP Proxy Gateway service
At an MS-DOS command prompt, type
cd \snaroot\system 
ftpregsu
This changes the NT registry entry for ImagePath from WindowsNTSystemRoot\System32\FTPSVC.exe to SNAroot\System\gateway.exe in the following registry entry:
HKEY_LOCAL_MACHINE
    SYSTEM
        CurrentControlSet
            Services
                FTPSVC

$ # Using the FTP-AFTP Proxy Gateway Service
To connect to a host and issue FTP commands though the FTP-AFTP Proxy
1	Start the MS-DOS command prompt and type
FTP WinNTServerName
2	To start an FTP-AFTP session on a host, type
User: Username@SNADestination
Password: Password
Username is your host user name
SNADestination is a valid AFTP address for an SNA host system. This can be a CPI-C symbolic destination name defined by system administrator in SNA Admin, or can be the name of an APPC partner LU, or the fully qualified LU name in the form NetName.LUName
Password is the password for your user name on the host.
Example:
User: bobda@appn.rainier
There are a number of commands in the AFTP Client that are not supported by an FTP Client, for example recfm for controlling the host record format for uploaded files. These commands can be implemented in FTP through the use of the quote facility or the SITE command, depending on your client. Choose the method supported by your FTP client.

$ # FTP-AFTP Proxy Gateway Service
The FTP-AFTP Proxy Gateway service provides Microsoft SNA Server version 2.11 users with the ability to access files on a mainframe or AS/400 using conventional FTP clients through a Windows NT FTP server. The Microsoft SNA Server FTP-AFTP Proxy Gateway enhances the existing Windows NT FTP service with an FTP proxy service. The user connects to the FTP service on Windows NT as usual, but switches from Windows NT FTP to AFTP by specifying an SNA destination on the FTP USER command.
Installing the service
Using the service

$ # Distributed Link Service Example
For example, a bank maintains an IBM mainframe to which a number of SNA Servers are connected using a channel link service. The administrator of these SNA Servers configures them to be available to Distributed Link Service on remote SNA Servers. 
At each of the bank’s branch offices is an SNA Server on a LAN that is connected to the central office LAN via TCP/IP over a leased line. The administrator of these branch SNA Servers configures Distributed Link Service to use the link services on all the centralized SNA Servers. 
Should one of the centralized SNA Servers fail, any remote SNA Servers that were connected to the host through the failed centralized SNA Server automatically reconnect to the host through one of the remaining centralized SNA Servers. If the WAN link should fail, the TCP/IP routers on these links can provide dynamic rerouting without losing the SNA link between branch office and central office. If all the WAN connections between a branch LAN and the central-office LAN should fail, the branch SNA Server can be configured to connect to the host via a direct dial-up SDLC connection as an ultimate backup.

$ # Limitations Using 802.2 Link Service
The 802.2 link service cannot support more than one 802.2 connection to the same MAC address (that is, to the same host) at the same time, whether the connections originate from the local or a remote SNA Server.  The 802.2 protocol specification does not permit two distinct connections to have the same Source MAC, Source SAP, Destination MAC and Destination SAP.  Because of this, you must configure a different 802.2 link service for each SNA Server PU connected to a given host, and each link service must use a different Source SAP value. 
This diagram shows this in detail using two DLC 802.2 link services. Note that if Remote SNA Server B attempts to use the link service \\SNALCL\SNADLC1, the connection will fail.

When you make an 802.2 link service available to Distributed Link Service on other SNA Servers, it cannot be used by the local SNA Server, and is not visible in SNA Admin on the local machine.

$ # Viewing Servers Connected Using Distributed Link Service
To list the remote SNA Servers that have active connections through link services on a particular SNA Server, type the following command at the MS-DOS prompt:
dlsstat \\servername
For example, to view the SNA Servers using Distributed Link Service to connect through a link service on an SNA Server named JIMGR, enter the following at the command prompt:
dlsstat \\jimgr
In this example, if JIMGR has two channel link services that have been configured to be available to Distributed Link Service on other SNA Servers, the output of this command might be:
Channel1 (Channel Link Service #1):
  \\BELLEVUE
Channel2 (Channel Link Service #2):
  \\LAKECITY
  \\KIRKLAND

$ # Specifying the Primary Protocol for Distributed Link Service
When SNA Server is set up to use more than one client-server protocol, Distributed Link Service attempts to establish communication between the SNA Servers first using TCP/IP, if present. If that fails, Distributed Link Service next attempts to connect using IPX/SPX and then Banyan VINES. To designate a protocol other than TCP/IP as the primary protocol to be used by Distributed Link Service, use Registry Editor to add or modify the following value in the Windows NT Registry:
HKEY_LOCAL_MACHINE
    SYSTEM
        CurrentControlSet
            Services
      	        LinkServiceName
                   Parameters
                     PrimaryTransport
This value is can be set to any of the following:
•	TCP/IP
•	IPX/SPX
•	VinesIP
You can also configure the TCP/IP KeepAlive time-out value for a Distributed Link Service connection by adding or modifying the following value in the Windows NT Registry:
HKEY_LOCAL_MACHINE
    SYSTEM
        CurrentControlSet
            Services
                LinkServiceName
                   Parameters
                     WatchDogTimeout
This is a REG_DWORD value that can be set from 30 to 7200 seconds. If this parameter is not present, SNA Server uses the default client-server KeepAlive time-out specified in the following Registry entry:
HKEY_LOCAL_MACHINE
    SYSTEM
        CurrentControlSet
            Services
                SnaBase
                   Parameters
                     WatchDogTimeout

$ # Security Considerations When Using Distributed Link Service
By default, when you make a link service available to Distributed Link Services on other SNA Servers, it will permit a connection from Distributed Link Services running on any remote SNA Server which is configured to connect to it.  This is similiar to the level of access control permitted by traditional passthrough gateways: Any downstream device that is configured for the correct MAC address can use the gateway.
However, you can restrict access to the distributable link service, requiring the remote Distributed Link Service to provide a valid Windows NT username and password.  The procedure requires coordination between the upstream and remote servers:
On the upstream server (the one running the distributable link service), define the following registry value:
HKEY_LOCAL_MACHINE
    SYSTEM
        CurrentControlSet
            Services
      	        SNABASE
                   DenyAnonymousAccess
This value is a REG_SZ value that allows anonymous access when set to 0. When set to any non-zero value, all distributable link services require a valid Windows NT username and password.
This registry flag is independent of  whether the Windows NT Guest account is enabled or disabled.  Even if you disable the Guest account, Distributed Link Services will be able to connect unless you set this flag in the registry.
If you set this flag, to gain access from a remote SNA Server, you must configure the Distributed Link Service on the remote server to run in a specific Windows NT user account by using the Windows NT Services Control Panel dialog box
To configure a Distributed Link Service to use a link service on a secure server
1	Open Control Panel, select "Services"
2	Double-click the Distributed Link Service.  These have service names of the form SnaRemx, where x starts at 1.
3	In the Service properties dialog box, choose This Account and type the Windows NT user name and password of a user account on the upstream server.  This user name must also match the user name of an account on the local server or in the sphere of trusted domains to which the downstream server belongs, and will automatically be given the  Log on as a Service privilege for Windows NT security.
Note that the domains of the downstream and upstream servers do not have to have a trust relationship.  You can simply create user accounts on both the downstream server and the upstream server that have the same user name and password.

$ # Distributed Link Service Benefits
•	The branch-based SNA Servers provide split-stack SNA gateway service for local PCs, simplifying configuration of the client PCs, conserving PUs and concentrating traffic on behalf of several PCs, which saves valuable network bandwidth. 
•	The branch-based SNA Server communicates with the central site SNA Servers via a native TCP/IP connection, which eliminates 802.2/LLC time-out problems associated with traditional SNA encapsulation methods. 
•	Since the central site SNA Servers provide the equivalent of PU pass-through service for the branch-based SNA Servers, the host operator sees each branch-based SNA Server as a PU and can manage the branches via standard NetView alerts and RunCmds. 
•	The branch-based SNA Servers can connect to the host via multiple centralized SNA Servers, load-balancing among the multiple central site SNA Servers at connect time. 
•	Should a central site SNA Server fail for any reason, the branch-based SNA Servers will automatically establish a new connection through an alternate centralized SNA Server for extra fault-tolerance. 
•	Should the wide-area network fail for any reason, the branch-based SNA Servers can be configured to connect to the host via a direct dial-up SDLC connection as a back-up that will be activated automatically upon the host connection failure. 
•	The routers at the branches only need to route TCP/IP, which provides for simplicity of wide-area network management and cost savings. 
•	Since the branch-based SNA Servers rely on the WAN services provided by the leading internetworking vendors, the Distributed Link Service will work over all existing and future WAN technologies, including leased lines, X.25, frame relay, and ATM networks. 
•	Unlike other "native" TCP/IP solutions such as TN3270, the Distributed Link Service is not limited in SNA functionality. Each branch-based SNA Server provides full SNA access for the local PCs, including PU2.0, PU2.1, and APPN LEN service as well as LU0, LU1, LU2, LU3, and LU6.2 support. Both mainframe and AS/400 access are supported. 
•	Although the majority of customers are moving to TCP/IP networks, the Distributed Link Service also fully supports IPX and Banyan VINES IP protocols. 

$ # Distributed Link Service
Distributed Link Service provides a method for an SNA Server to connect with a host using a link service installed on another SNA Server. Through the Distributed Link Service, a combination of remote and central site gateways interoperate to provide a number of benefits.
This diagram shows a common application of Distributed Link Service in a branch-office configuration.

For more information about Distributed Link Service, see \COLLATRL\PRESS\SOGAPR.DOC on the SNA Server version 2.11 Service Pack #1 CD-ROM.
Distributed Link Service Example
Limitations using 802.2 link service
Viewing servers connected using Distributed Link Service
Specifying the primary protocol for Distributed Link Service
Security considerations when using Distributed Link Service

$ # New and Enhanced Link Services
The following link services are available in this Service Pack:
•	Polaris PCI ESCON and Bus&Tag channel adapters
•	Digi Sync SDLC adapter
•	Eicon WAN Services X.25 and SDLC
•	Microgate T1 adapter for SDLC and X.25/QLLC
•	Bus-Tech EISA Bus&Tag channel adapter support integrated into the existing BTILINK service
•	DEMO SDLC Link Service

$ # DEMO SDLC Link Service
The 3270 Continuous Demo script has been modified to function with a client emulator connected to the SNA Server running the link service across a Downstream (DSPU) connection. 
In addition, a new script, called the 3270 File Transfer Demo, has been added to demonstrate transfer of a 1 MB file from a host to your local drive. Select this option for an emulation of a 3270 File Transfer. This demo emulates the receipt of a 1MB binary file from VM. Note that you must have 1MB of free disk space to successfully complete the file transfer.
To install this option, in SNA Server Setup, add a new DEMO SDLC Link Service, choosing the 3270 File Transfer Demo script.
To configure this demo script, follow the instructions for the 3270 Continuous Demo in the Microsoft SNA Server Enhancements Guide.
To operate the 3270 File Transfer Demo
1.	Start SNA Server Admin by double-clicking the SNA Server Admin icon in the Microsoft SNA
	Server group window.
2.	Start the server by selecting it in the Servers and Connections window and selecting Start Services from the Service menu.
3.	Start the 3270 Applet by double-clicking the SNA Server 3270 Applet icon in the Microsoft SNA Server group window.
4.	From the Session menu, choose Session Configuration.
5.	Ensure that the correct LU is selected (that is, the LU that has been configured for the 3270 File Transfer Demo script).
6.	From the Session menu, choose Connect.
7.	The SDLC connection activates (changing from On Demand to Active in SNA Admin), and the first host logon screen appears.
8.	Type vm, and press ENTER.
9.	The host will then prompt you for a password.
10.	Log on with your user ID and password.
11.	Click the Macro menu, and then click Clear to clear the screen.
	Note: This step must be done.
12.	Click the Transfer menu, and then click Receive File...
13.	In the Receive File dialog box, enter a valid filename in the PC file text box, and enter any characters in the other text boxes. (All text boxes must be filled in.)
14.	When transfer is complete, click Disconnect from the Session menu to disconnect, or press ENTER to log off and continue with this procedure to repeat the demonstration without disconnecting.
15.	Press ENTER again to return to the Userid And Password prompt screen.
16.	Enter the user ID and password and press ENTER to return to the Space Needle screen.
17.	Return to step 6 to repeat the file transfer demonstration.

$ # AFTP API Documentation
AFTP API Programmer's Guide has been added to the SDK in this SNA Server Service Pack. The APPC File Transfer Protocol (AFTP) API is a set of C-language routines that provides APPC file transfer capabilities. The API makes file-transfer programming easier by allowing you to access routines that will interact with any AFTP server.

If you received the Service Pack as part of an SNA Server release and if you install the online documentation, the online reference version of this material will be located in the HELP subdirectory of the SNA directory. However, AFTP API Programmer's Guide does not appear in the Contents window when you click the SNA Server Documentation icon in the Microsoft SNA Server program group. This will be remedied in a future release. You can view the AFTP API file by double-clicking its filename in File Manager.
If you received this Service Pack separately, the online help file will be found in the \DOCS\HELP directory.
Printable files for AFTP API are available in the following directories:
\DOCS\SDK\AFTP\DOC  (Word 2.0c files)
\DOCS\SDK\AFTP\DTF   (for direct output to a PostScript printer)

$ # SNA Server 2.11 Service Pack #1 New Features
This Service Pack contains a number of new features that provide SNA Server 2.11 with additional capabilities.
Windows 95 Client Software
FTP-AFTP Proxy Gateway Service
Distributed Link Service
New and Enhanced Link Services
AFTP API Documentation
New Mechanisms for Enabling Tracing on a Windows 3.x Client

$ # December 1995

Licensing Information for
Microsoft SNA Server
Version 2.11
When you deploy Microsoft SNA Server in your network, you must have a license for each SNA Server, plus an SNA Server Client Access License (CAL) for each client computer that accesses an SNA Server. 
The SNA Server licensing model provides a method for licensing SNA Server and its clients separately. 
SNA Server Licensing Model Overview
A client computer might be connecting to an SNA Server without itself executing any programs that involve SNA protocols. It might also use an SNA Server without running any client software provided by Microsoft. Despite this, such computers are clients of  SNA Server and require a valid CAL. The general rule is:
If an action by a client causes an immediate, delayed, or conditional action on the host via SNA Server, then an SNA Server CAL is required for the client. Conversely, if the host causes an action on a client through SNA Server, an SNA Server CAL is also required for the client.
The license agreements for SNA Server provide for two licensing modes: Per Server and Per Seat. The model that you should choose will depend on how you intend to use SNA Server in your network.
The Per Server option (also known as the concurrent model) lets you buy only as many SNA Server CALs as you need for the total number of client computers that access a given SNA Server at the same time. In other words, if you anticipate that no more than 100 client computers will require simultaneous access to a given SNA Server, you can purchase 100 SNA Server CALs  under the Per Server model. The Per Server option is the most economical if you have only one SNA Server or you expect only a fraction of the number of potential SNA Server clients will access a given SNA Server at the same time. 
On the other hand, the Per Seat option allows you to purchase an SNA Server CAL for each computer that will access any SNA Server at any time. Once a computer is licensed in Per Seat mode, it may access any SNA Server installed on the network at no additional charge. This option is the most economical if you have more than one SNA Server and you expect that most of your potential SNA Server clients will access an SNA Server at the same time. For example, if you have 500 computers that are set up to access two  SNA Servers configured for load balancing and hot backup, and more than half of those computers will access SNA Servers at the same time, you will find the Per Seat option to be more economical and easier to manage.
Note that configuring the SNA Server for Per Server mode does not preclude licensing other SNA Servers in Per Seat mode. However, enough licenses must be purchased to cover all client computers that can connect to all SNA Servers configured for the Per Seat licensing mode. Client computers that are covered only by the Per Server license of the dedicated SNA Server may not connect to SNA Servers licensed in Per Seat mode.
It is important to emphasize that the SNA Server CAL is separate from any license you may have purchased for client software. For example, if you purchase a license to use a third-party terminal emulator that incorporates SNA Server client-access software, the license you purchased gives you the right to use the software, but not the right to access an SNA Server. The CAL is provided through a Microsoft License Agreement card that specifies the number of CALs conveyed by the agreement and the server product that the clients are licensed to access. For example, at the top of the Microsoft License Agreement card will appear words similar to the following:
CLIENT ACCESS LICENSE FOR
MICROSOFT (R) SNA SERVER VERSION 2.11
LICENSES: 1
For information about obtaining SNA Server CALs, contact the reseller through whom you purchased SNA Server.
Another important distinction is between the SNA Server CAL and the Windows NT Server CAL. Computers used as SNA Server clients always require a valid SNA Server CAL; however, these client computers require a Windows NT Server CAL only if the client computer will be requiring the file, print, or remote access services (RAS) of the Windows NT Server itself. If the client computer will access the server only for SNA access, it does not require a Windows NT Server CAL.
The following sections will clarify when you need an SNA Server CAL for a particular use of SNA Server and will help you choose the appropriate licensing option. Except where noted, a required CAL can be obtained either through the Per Seat or Per Server licensing option. Except where noted, a required CAL can be obtained either through the Per Seat or Per Server licensing option. If, after reading this document, you are unsure about a licensing issue, you can send electronic mail with your questions to MSSNA@MICROSOFT.COM.
Multiple Sessions Running on a Client
An SNA Server CAL gives permission to use an individual computer to access an SNA Server. Running multiple host sessions on a client computer does not require you to purchase more than one CAL for the computer. For example, even though a user is running two sessions with a 3270 emulator, a single session with a 5250 emulator, and an active ODBC query against an AS/400, the computer requires only one SNA Server CAL. In other words, the SNA Server CAL applies to the licensed computer, not to the sessions running on the computer.
If you are comparing SNA Server to other SNA gateways, it is important to note this difference, since many other gateway products (such as Novell NetWare for SAA) require a separate license for each session that accesses the gateway. For more information comparing SNA Server and NetWare for SAA licensing, see “SNA Server Value” on page 19 in Microsoft SNA Server 2.11 Reviewer’s Guide (REVGUIDE.DOC in the COLLATRL\REVGUIDE directory on the SNA Server 2.11 CD-ROM).
Hot Backup
In most cases, it is most economical to use the Per Seat mode with multiple SNA Servers configured for hot backup and load balancing. When multiple SNA Servers provide hot backup for each other, the minimum number of  SNA Server CALs required for each server in Per Server mode must cover the number of clients that access the server under normal circumstances, plus the number of additional clients that could access the SNA Server when it takes on the clients of a failed SNA Server. For example, if two SNA Servers that normally support 500 clients each are configured to provide hot backup for each other, and if one of the servers fails, then it is possible that the remaining SNA Server could be called upon to support 1,000 clients. Consequently, both SNA Servers would require 1,000 SNA Server CALs in Per Server licensing mode to ensure adequate coverage (for a total of 2,000 CALs), but only 1,000 CALs in the Per Seat mode.
Because of this need for redundant SNA Server CALs, most organizations that use the hot backup capabilities of SNA Server will find the Per Seat licensing mode the most economical option. This will generally be the case unless only a small fraction of all potential users is expected to access the SNA Servers configured for hot backup at any given time.
Terminal Emulation
Except when a terminal emulator is running locally on an SNA Server, each computer running a terminal-emulator program that accesses SNA Server must be covered by a valid SNA Server CAL. Third-party terminal emulators do not commonly include an SNA Server CAL, which must be obtained separately. As stated earlier, the CAL is provided only through a Microsoft License Agreement card that specifies the number of CALs conveyed by the agreement. If your terminal emulator program is not accompanied by a Microsoft License Agreement card, you must obtain the SNA Server CAL separately from your reseller.
SNA Server includes a single license for a 3270 emulator applet and a 5250 emulator applet. The terms of the license for these applets allow each emulator to be run on a single computer only. In addition, you must also have a separate SNA Server CAL to run either applet on a system other than an SNA Server. 
Host Database Access
Unlike a terminal emulator, software that accesses host databases through SNA Server often works “in the background,” providing little or no evidence that SNA Server is involved in the transfer of data between the host and the client computer. Nevertheless, any computer that accesses data on a host via an SNA Server must be covered by a valid SNA Server CAL.
ODBC/DRDA Driver
SNA Server includes a single license for an ODBC/DRDA driver that provides access to Distributed Relational Database Architecture (DRDA) host databases (such as IBM DB2 databases) by client software that uses the Open Database Connectivity (ODBC) programming interface. This license allows you to use the driver on one computer only. If the driver is installed along with SNA Server client software on a computer other than an SNA Server, the computer must be covered by a valid SNA Server CAL. Additional licenses for the ODBC/DRDA driver must be purchased from StarWare (sales@starware.com).

Numerous custom and third-party applications provide access to host data. Some of these rely on SNA Server client software to connect client computers to an SNA Server. Obviously, every computer that uses SNA Server client software to access an SNA Server must be covered by a valid SNA Server CAL.
In many cases, however, database gateways do not rely on SNA Server client software running on the clients that access data on the host. Instead, the database gateway program is the only component that directly uses SNA Server to communicate with the host. The clients of these database gateways communicate with the gateway using a custom connection; the gateway, in turn, connects to the host  using SNA Server APIs on the server. Even though the computers exchanging data with the host do not directly connect to an SNA Server, an indirect connection exists which requires a valid SNA Server CAL.
This requirement applies when the gateway provides direct or indirect communication between the client computer and the host, such as when a particular request by a client results in the gateway transmitting the request to the host. It does not apply when host data is simply replicated to a database on the gateway server. For example, if a Microsoft SQL Server database on a server regularly replicates data from a host system to the local SQL Server using an SNA Server connection, a client computer that accesses the data on the SQL Server database is not required to be covered by an SNA Server CAL.
Internet Access
As Internet access becomes increasingly widespread, Internet services (such as the World Wide Web) and Internet-related tools (such as Web browsers) are being used to provide end users access to host data. For example, a Windows NT Server running SNA Server and Internet Information Server can use an ODBC/DRDA driver to extract information from a host database and publish it in Web pages.
Like other types of host-database access, a valid CAL is required for each Internet client that obtains host data through SNA Server. As explained previously, a client is any computer running software that causes a request to be transmitted to the host through SNA Server. In the case of information published on the Web, for example, each computer running a Web browser is considered a client if the end user can construct and transmit a query (either directly or by using predefined criteria provided by a Web page) that causes data to be transferred from the host to the end-user's computer. In such a case, there is practically no limit on the number of potential clients, and so the SNA Server clients should be licensed in Per Server mode.
On the other hand, if a server-based program periodically retrieves information from the host and stores it in a database on the Web server, and if end users access only the server-based data storage through their Web browsers, then only the server-based program is considered an SNA Server client, and only one CAL is required for that program. 
Proxy Gateways
A proxy gateway connects nodes on dissimilar networks by representing a node of one network to nodes on the other network as though the node were the proper type for the other network. In the case of SNA networks and SNA Server, a proxy gateway usually acts as a server for client computers on a LAN and as a client to SNA Server for communicating with the SNA network. An example of such a proxy gateway is the TN3270 Service included in SNA Server.
TN3270 Service for SNA Server allows TN3270 terminal emulators on a TCP/IP network to communicate with host computers on an SNA network. Any TN3270 emulator can communicate with a host computer through TN3270 Service and SNA Server, including TN3270 emulators running on such operating systems as UNIX. SNA Server client software is not required to be present on the client computer. Nevertheless, because there is a connection between a TN3270 client and a host through SNA Server, a valid SNA Server CAL is required for each client computer that connects to a host system through the TN3270 Service of  SNA Server.
A number of proxy gateway programs have been developed to allow multiple clients to communicate through one or more SNA Server connections to a host computer. An example of such a third-party gateway is a mail gateway service. As is the case with the TN3270 Service, a mail gateway service would communicate with one or more host systems on behalf of multiple LAN clients. Even though only a few SNA Server sessions would be involved (because the mail gateway service itself is the SNA Server client), the mail gateway would nevertheless be communicating with the host systems through SNA Server on behalf of its own clients. Therefore, a valid SNA Server CAL is required for each client on behalf of which the mail gateway is acting as proxy.
Due to technical limitations, Windows NT Server License Manager cannot track licenses required for third-party proxy gateways. If you are using such a gateway, it is your responsibility to ensure that you are in compliance with the terms of your SNA Server license. 
Downstream Systems
Even though downstream systems (also known as downstream PUs, or DSPUs) do not use SNA Server client software, they are still considered clients of the SNA Server through which they communicate with the host system. Consequently, each downstream system requires a valid SNA Server CAL.
Due to technical limitations, Windows NT Server License Manager cannot track licenses required for downstream systems connecting through an SNA Server.  If you are using such downstream connections, it is your responsibility to ensure that you are in compliance with the terms of your SNA Server license.
Remote Access Service
The Remote Access Service (RAS) facility of Windows NT Server is used in an SNA Server network for two purposes: to allow remote client computers to connect to an SNA Server via such links as telephone lines and ISDN, and to allow communication between remote LANs on an SNA wide-area network. How RAS is used will affect the number and type of CALs you will require. 
Remote client computers can connect to SNA Server through RAS, just as a remote client can connect to a Windows NT Server using RAS. As you might expect, you must purchase a SNA Server CAL for each client computer that connects to an SNA Server using RAS.
Often RAS is used to provide access to SNA Server by a large number of infrequent users. In such cases, it is usually more economical to set aside a single SNA Server to handle the RAS clients. This SNA Server can then be configured with enough SNA Server CALs in Per Server mode to meet the anticipated demand. If, on the other hand, the SNA Server were to be licensed in Per Seat mode, an SNA Server CAL would have to be purchased for every remote workstation that could connect to the SNA Server via RAS.
SNA Remote Access Service
SNA Remote Access Service allows Windows NT Server and Windows NT Workstation to access remote network servers through an SNA network as though the remote network server were connected directly to the LAN. A client computer that accesses remote servers through SNA Server Remote Access Service must have a SNA Server CAL for the SNA Server in the same LAN as the client. The client must also be covered by a Windows NT Server CAL if the client uses Windows NT Server file or print services.
Print Services
Typically, an SNA Server CAL is associated with a workstation or a server. In the case of print services, however, the printer is the SNA Server client. That is, if you route host print jobs through SNA Server to LAN-based printers, you must purchase an SNA Server CAL for each printer that is used in this fashion. The actual  physical printer device is the client to be licensed, so if a single printer is accessed through multiple print queues, only one SNA Server CAL is required in Per Seat mode. Note, however, that if the printer is accessed by multiple SNA Servers licensed in Per Server mode, then a valid SNA Server CAL is required for each SNA Server that accesses the printer.
For example, a branch office is set up with a printer in each of five departments. The branch office has three SNA Servers for communication with the host. The SNA Servers are configured to provide load balancing for the entire branch office, so print jobs can be routed through any SNA Server to one of the five department printers. If the SNA Servers are licensed for Per Server mode, each of the three SNA Servers requires the purchase of a SNA Server CAL for each of the five department printers, for a total of 15 SNA Server CALs. If, on the other hand, the SNA Servers are licensed for Per Seat mode, only five SNA Server CALs are required to cover all the printers.
File Transfer
The principles that govern the client-license requirements for file transfer programs are similar to those of host database access. That is, if the file-transfer program functions more or less automatically to replicate files between the host and a server through an SNA Server connection, then only the server on which the file-transfer program executes requires an SNA Server CAL. If, on the other hand, the file-transfer program moves files directly between the host and end-user workstations, then each of these end-user workstations requires a valid SNA Server CAL.
The licensing mode (Per Seat or Per Server) that is most economical for file-transfer applications depends on the frequency and duration of file transfers. If you have only one SNA Server, or you intend to support a large number of potential client computers, each of which performs file transfers only occasionally or very briefly, you will find the Per Server licensing option to be the most cost-effective. If, on the other hand, you have more than one SNA Server and most of your supported clients require frequent file transfers, you will probably find the Per Seat licensing option less costly. If the number of clients and volume of file transfers is such that you need to take advantage of the load-balancing and hot-backup capabilities of SNA Server, the Per Seat option is probably the best choice.
Third-Party and Custom APPC, CPI-C, and LUA Applications
In addition to the applications described in the preceding sections, many third-party and custom applications have been developed using the SNA Server APIs for APPC, CPI-C and LUA. When such applications run on client workstations, a valid SNA Server CAL is required for each client workstation. Even if the application calling the SNA Server APIs runs on the SNA Server itself, an SNA Server CAL is required for each client workstation that causes the application to communicate with the host through SNA Server on behalf of the client workstation. 
For example, an APPC transaction program (TP) runs on an SNA Server and acts as a server program to PC-based point-of-sale terminals. When a sale is registered on the terminal, the TP updates a host-based inventory database through SNA Server, plus  performs other functions (such as updating a SQL Server database with the purchaser’s address information). Even though the TP is running on the server only, it is accessing the host database through SNA Server on behalf of the clients, so each of the clients must be covered by a valid SNA Server CAL. 
Distributed Gateway Service
SNA Server 2.11 Service Pack 1 includes a new feature, Distributed Gateway Service, that allows SNA Server to communicate with a host through a link service running on another SNA Server as though the link service were installed on the local SNA Server. When an SNA Server is configured to communicate through a distributed link service, the remote SNA Server is not considered a client of the central SNA Server, and so no additional CAL is required for the remote server. Furthermore, clients that connect to the local SNA Server are considered clients of the local server only; additional SNA Server CALs are not required for those clients on the remote server.

$ # Correction to SNA Server Administration Guide
In Chapter 6, “Configuring LUs for APPC,” change the last paragraph in the subsection entitled “Configuring Local APPC LU Properties” in the section entitled “Section List for APPC” to the following:
The usual range for LU number is from 1 through 254. For a dependent LU that will be paired with a remote LU using a DFT connection, use a range of 2 through 254 in which the number is the decimal equivalent of the hexadecimal encoding of the port number and the logical terminal number. For example, for logical terminal 3 on DFT port 1 would be encoded as 13 (hex). The decimal equivalent of 13 (hex) is 19, which is the number that would be entered as the LU number in the LU Number field of the APPC LU Properties dialog box.

$ # Correction to SNA Server Reference
In Appendix C, “Registry and Environment Variables for SNA Server,” the documentation of several registry values is incorrect. 
The documentation states that the following values are interpreted differently if they are set to Yes or No:
•	NOTERMSELF
•	ALLOWBBRQE
•	NO4004
•	NO400D
•	NO2001
•	CLEANUP
•	ALLOCINACT
•	NOINITCNOS
•	NOPWDSUB
•	FNA_SUPPORT
•	HNA_SUPPORT
In fact, when present, these values are always interpreted as though they were set to Yes, even if they are set to No or some other value.
The following values are properly interpreted as No only if they are set to NO (all caps); if they are set to any other value, they are interpreted as Yes:
•	RETRYCNOS
•	RENEGLIMITS
The following value is properly interpreted as Yes only if it is set to YES (all caps); if it is set to any other value, it is interpreted as No:
•	NONOTIFYRSP

$ # Addition to CPI-C Programmer's Guide
In Chapter 1, "Introduction to CPI-C," of the CPI-C Programmer's Guide, in the section entitled, "Before Using Windows CPI-C," add the following to the beginning of the section:
Before calling any CPI-C functions, a Windows application should create its main window. When the CPIC library processes a CPIC call, it might need to yield to other components. The yield will not work if the application does not have a window.

$ # Correction to SNADIS
In Appendix A of the SNA Device Interface Specification, section A.2.1, Architecture Overview, "The Interface Record", should read as follows:
A.2.1  Architecture Overview
The Interface Record
Status information is transferred between the driver and the SNALink using a buffer known as the Interface Record. The driver allocates this buffer when it starts and maintains the information in it while it is running.
The contents of this buffer are copied to an SNALink buffer by using an IOCtl call of type READ_INTERFACE_RECORD.

$ # Modem Status Interface
The modem status application provides a set of RASmon-like modem lights. It is intended primarily for the Microgate cards with internal modems, but can be used with any SDLC/X.25 link service to show the modem status.
Overview
There are three interfaces from which modem status can be gathered:
•	The SNADIS Dumb Card Interface GetV24Status IOCtl call which reports the status of the Ring Indicator (DRI), Carrier Detect (DCD), Clear To Send (CTS), Data Set Ready (DSR)
•	The SNADIS Dumb Card Interface SetV24Status IOCtl which sets the status of the Data Terminal Ready (DTR) and Request To Send (RTS) lines.
•	The SNADIS Dumb Card Interface receive and transmit IOCtl calls, used to set the operating mode of the device driver.
Whenever one of the first two interfaces indicates a modem line is high, the corresponding light in the display is “lit.” However, the transmit/receive interface cannot provide a definitive indication as to whether the card is receiving data, only that it is ready to receive data. To get around this, and to give a reasonable semblance of ordinary data throughput, the receive and transmit lights are simulated by counters. Each link service tracks the number of frames received and transmitted. The display application interpolates the flashing of the receive and transmit lights from these counters.
Split of Responsibilities 
The changes necessary falls into two components:
•	The code within the link service, which monitors the status of the V24 lines and makes this available to the displaying application
•	The display application, which displays the status of the modem lines for a particular link service.
Implementation
The implementation falls into two parts:
•	Shared memory for the link services to communicate with the display application
•	Devioctl changes to write the status to the shared memory.
IHVs who use the SNA Server SDLC link service, and who fully implement the SNADIS interface will have no changes to make to use the modem status feature. However, they should check that the status returned by their devioctl conforms to that set out below.
IHVs who provide both the device driver and link service need to implement the code in their link service which initializes SNA Modem API and updates the modem status information.
SNA Modem API
To simplify the task for IHVs who want to use this feature, four new entry points have been added to SNALINK.DLL. An IHV who uses these must be linking with IHVLINK.LIB, a stub library which simply contains the exports library for SNALINK.DLL. This API encapsulates all of the shared memory/event/mutex creation and deletion. IHVs simply have to maintain the contents of a MODEM_STATUS structure.
Shared Memory Definition
The link services and the display application communicate via a block of shared memory, which is written to by the link service and read from by the display application. It is protected from simultaneous writes by a shared named mutex.

Figure 1. Shared Memory Structure
The shared memory header contains a count of links services using this shared memory and a list of link data for each link service. As each new link service attaches to the shared memory, they increment the number of users, and add their link data to the end of the list of links.

Figure 2. Link Data Structure
The link data structure contains the NULL terminated link service name and a set of byte fields, indicating the state of the modem lights. A non zero value in one of these fields indicates the light is on. These fields are updated by each link service when it detects that the status of a given line has changed from that in the shared memory.
Only link service initialization and termination accesses to the shared memory are protected by the mutex. As each link service has its own area of the shared memory in which to store the modem status, there is no opportunity for coincident writes to the memory, except when adding or removing link services.
As each link service terminates, it waits for the mutex,  decrements the use count, and removes its status data from the shared memory. After releasing the mutex, it sets the status event to notify the display program that a link service has gone. The link service which decrements the usage count to zero is responsible for deleting the shared memory and mutex.
SNAModemInitialize
The definition of SNAModemInitialize is:
void SNAModemInitialize()
It should be called once per link service process at initialization. The ideal place is SNALinkInitialize. It creates the shared memory and initializes it.
SNAModemAddLink
The definition for SNAModemAddLink is:
void SNAModemAddLink(
                      MODEM_STATUS ** ppModemStatus
                    )
This function should be called once per link initialization. For link services which support more than a single SNA link this call may be made multiple times. For link services which support only a single link, this call can be made immediately after SNAModemInitialize, otherwise it is preferable to call SNAModemAddLink as each port is initialized.
The IHV should declare a pointer to a MODEM_STATUS structure and pass its address into this function. 
The function returns a pointer into the shared memory block. The IHV may fill in the link service name and status information into this structure. The name is initially the name of the link service, but may need to be altered for multiport link services.
Internally SNAModemAddLink increments the usage count of the shared memory, and signals the display application that a new link has been added.
SNAModemDeleteLink
The definition for SNAModemDeleteLink is:
void SNAModemDeleteLink(
                         MODEM_STATUS * pModemStatus,
                       )
This function should be called when a LINK is terminating to delete the resources associated with a LINK. The parameters passed in must correspond to those returned by a call to SNAModemAddLink.
All resources in the link service associated with the modem status are deleted, and they must not be accessed by the IHV code after calling this function.
SNAModemTerminate
The definition for SNAModemTerminate is:
void SNAModemTerminate()
This function should be called once per link service process, at termination. The ideal place is SNALinkTerminate. If the link service supports a single link, it is acceptable to call SNAModemDeleteLink immediately before SNAModemTerminate. Otherwise it is better to call SNAModemDeleteLink as each link instance is terminated.
Shared Memory Data Structures
The following structures define the memory shared between the link service and the display application.
struct _ModemStatus
{
  char LSName[12];  // Link Service Name
  char V24In;       // V.24 input flags
#define MASK_CTS 1
#define MASK_DSR 2
#define MASK_DCD 4
#define MASK_DRI 8

  char V24Out;      // V.24 output flags
#define MASK_RTS 1
#define MASK_DTR 2

  unsigned short RxFrameCount; // Count of received frames
  unsigned short TxFrameCount; // Count of transmitted frames

  char Reserved[6]; // Padding / Expansion
} MODEM_STATUS;

struct _ModemStatusHdr
{
  DWORD UseCount;  // How many of next array in use
  MODEM_STATUS ModemStatus[MAX_LINK_SERVICES];
                   // Array of link service data
} MODEM_STATUS_HDR;
DevIoctl Definitions
The devioctl interface is modified to update the shared memory each time a modem status change is detected or caused by a GetV24 or SetV24 IOCtl. Code is manually added to the link service track the number of frames received and transmitted.
The devioctl changes are highlighted below:
#define SETV24STATUS                                                    \
         NtDeviceIoControlFile(seldrvrh,NULL,NULL,NULL,&IoStatus,       \
                               IoctlCodeSetV24,NULL,0L,                 \
                               &pInterfaceRecord->V24Out,1L);           \
                                                                        \
         if (SavedIROut != (InterfaceRecord.V24Out &                    \
                            (MASK_DTR | MASK_RTS)    ))                 \
         {                                                              \
           SavedIROut = (pInterfaceRecord->V24Out &                     \
                         (MASK_DTR | MASK_RTS)    );                    \
           pSharedMem->V24Out = pInterfaceRecord->V24Out;               \
         }

#define GETV24STATUS(rc)                                                \
         rc |= NtDeviceIoControlFile(seldrvrh,NULL,NULL,NULL,&IoStatus, \
                                   IoctlCodeGetV24,NULL,0L,NULL,0L);    \
         rc |= READINTERFACERECORD;                                     \
         if (SavedIRIn != (InterfaceRecord.V24In &                      \
                           (MASK_CTS | MASK_DSR | MASK_DCD| MASK_DRI))) \
         {                                                              \
           SavedIRIn = (InterfaceRecord.V24In &                         \
                        (MASK_CTS | MASK_DSR | MASK_DCD| MASK_DRI));    \
           pSharedMem->V24In = InterfaceRecord.V24In;                   \
         } 
pSharedMem is a pointer to the MODEM_STATUS structure for this link service.
SavedV24In and SavedV24Out are chars used to only notify the display application when status changes, not each time it is read or set.

$ # Performance Monitor Interface
This interface is provided to simplify the integration of SNADIS compliant link services with Windows NT Performance Monitor (Perfmon). It provides a common look and feel to all link service performance counters exported by SNADIS links, independent of the vendor, and link transport.
Data Structures
The statistics stored for a link service are stored in the following data structures, and are defined in SEMFPERF.H. For further explanation, see the API description below.
typedef struct adaptercounter {
    ULONG          count;
    ULONG          type;
    LONG           scale;
} ADAPTERCOUNTER;
The ADAPTERCOUNTER structure represents an individual Perfmon event, such as bytes throughput. All the data needed to display a single Perfmon event is stored in this structure.
The count field is maintained by the link service. Each time a Perfmon event happens the count field is incremented.
The type field instructs Perfmon whether the count field represents a counter (such as number of connection failures) or a rate such as throughput in bytes per second. For suitable values see the Win32 SDK documentation of PERF_COUNTER_* (e.g. PERF_COUNTER_COUNTER , PERF_COUNTER_RAWCOUNT.
The scale filed instructs Perfmon as to the default scale to use to display this counter. The counter is scaled by 10scale such that a scale of -1 multiplies the counter by 0.1.
typedef struct adapterperfdata {
    ULONG          inuse;
    ULONG          ServiceNameIndex;
    ULONG          FirstCounterIndex;

    ADAPTERCOUNTER TotalBytesReceived;
    ADAPTERCOUNTER TotalBytesTransmitted;
    ADAPTERCOUNTER TotalFramesReceived;
    ADAPTERCOUNTER TotalFramesTransmitted;
    ADAPTERCOUNTER SuccessfulConnects;
    ADAPTERCOUNTER ConnectionFailures;
    ADAPTERCOUNTER TotalBytesThroughput;
    ADAPTERCOUNTER TotalFramesThroughput;
    ADAPTERCOUNTER AdapterFailures;
    ADAPTERCOUNTER reserved[11];

    ULONG          pad;
} ADAPTERPERFDATA;
The ADAPTERPERFDATA structure simply groups the ADAPTERCOUNTERS together into a single block. It also has a few fields used internally by the link Perfmon code. The user should not change these fields.
API Entry Points
The following API entry points are exported from IHVLINK.DLL (and the import library, IHVLINK.LIB). They are called in the order as listed at link service initialization time.
void SNAInitLinkPerfmon(HANDLE * shrlockmutx, void ** shrptr)
This call initializes the link Perfmon code. The user defines a HANDLE and a void * locally. This call returns values in these. These values are then used on later calls to the Perfmon code.
ADAPTERPERFDATA * SNAGetLinkPerfArea(HANDLE shrlockmutx,
                                     ADAPTERPERFDATA * shrptr)
This call returns to the user a pointer to the shared data area used by Perfmon to stored the link statistics. The parameters are the returned values  from SNAInitLinkPerfmon. The user then fills out the ADAPTERCOUNTER members of the returned ADAPTERPERFDATA structure.
USHORT SNAGetPerfValues(int * pServiceNameIndex,
                        int * pFirstCounterIndex)
This call is used to fill in the ServiceNameindex and FirstCounterIndex fields in the returned ADAPTERPERFDATA structure.
Once these three calls have been made, the user simply maintains the count field in the ADAPTERCOUNTER structures, incrementing whenever data is received, connections fail etc.

$ # Changes to SNA Device Interface Specification
Correction to SNADIS
SNADIS addition: Modem Status Interface
SNADIS addition: Performance Monitor Interface

$ # Corrections and Additions to SNA Server Documentation
Information has become available since the SNA Server 2.11 documentation was printed that requires corrections and additions to the documentation. Additional corrections to the SNA Server documentation can be found in SNA Server Read Me (README.WRI).
SNA Server Administration Guide
SNA Server Reference
CPI-C Programmer's Guide
SNA Device Interface Specification

$ # Note on Running INSTALL.BAT From a Shared Network Directory on Windows NT Shell Update Release
You cannot run INSTALL.BAT from a shared network directory unless you first map the directory to a drive letter and run INSTALL.BAT through the logical drive. For example, to run INSTALL.BAT from a network drive using the MS-DOS command prompt, enter the following commands:
	net use drive: \\server\share
	drive:
	cd \install_directory (required only if INSTALL.BAT is not in the root directory)
	install

$ # Note on Installing the Bus-Tech Channel Link Service
Before you can install the Bus-Tech Channel Link Service from SNA Server Link Service setup, you must first install the device driver for the EBCA or MCCA adapter. This driver is installed through the Windows NT Network Control Panel Add Adapter dialog box. When prompted for the device, choose <Other> Requires Disk From Manufacturer, and specify SNAroot\SYSTEM\HWSETUP\BTILINK for the path to the driver software.

$ # Note on Using Shared Folders from Client Access or PC Support
Users can encounter unexpected behavior when using shared folders from IBM Client Access or PC Support through SNA Server. Specifically, when SNA Server connects multiple users through a single APPC LU-LU pair, the AS/400 host assigns access security based on the first user who logs on through a connection. Subsequent users who log on through that connection are then given the same access to shared folders as the first user, rather than receiving their appropriate level of access.
This problem results from the way security is implemented on the AS/400. This implementation is based on the assumption that each LU is assigned to a particular client computer, and so uses the same security context for all conversations through a given LU. Consequently, when SNA Server routes multiple user sessions through a single LU, the AS/400 does not assign the appropriate access level to subsequent users.
The only way to ensure that users are given the appropriate level of access to shared folders is to create multiple APPC LUs, assigning each as the default for a particular user or groups of users.

$ # Note on Twinax Link Services (ANDWTDLC and IBMTDLC)
Problems with data-intensive applications hanging have been encountered when using the twinax link services. If you are experiencing such problems, use the default RU size and a pacing count of one (1) for the mode you are using with the twinax link service.

$ # Notes on Installing Eicon Link Services (ECSDLC or ECX25)
To conserve hard disk space for systems that do not install them, most of the files used by the Eicon link services are not copied to the hard drive until you select either ECSDLC or ECX25 in Link Service Setup.   Therefore, when you install one of these link services, you must supply the SNA Server distribution medium (such as CD-ROM or floppy disks) to complete the installation.
If you are installing an Eicon link service from SNA Server 2.11 Service Pack #1, you must copy the \WINNT\platform\SERVER\EICON directory and its contents (including subdirectories) to the snaroot\SYSTEM\HWSETUP directory before installing the link service. For example, to install an Eicon link service in an Intel-based server which has SNA Server installed in a directory named \SNA from the Service Pack #1 CD-ROM, use File Manager to copy the CD-ROM directory \WINNT\I386\SERVER\EICON to \SNA\SYSTEM\HWSETUP on the server, and then run SNA Server Setup to install the link service. 
In addition, when you install an Eicon link service for the first time, you must restart Windows NT Server  before the link service will start. This is required because the link service relies on the PATH system variable to locate its program files, and changes to the PATH variable made by Link Service Setup do not take effect until Windows NT Server restarts. You do not need to restart after installing a second instance of any of the Eicon link services, however.

$ # Note on Installing SNA Server and Rebuilding the Windows NT Emergency Repair Disk
If you install SNA Server and then rebuild the Windows NT Emergency Repair Disk, you will encounter errors when you try to use the disk to restore Windows NT Server. 
A temporary workaround is available to prevent this problem. Before rebuilding the emergency repair disk, use Notepad or another text editor to edit the file WinNtRoot\REPAIR\SETUP.LOG (a hidden file). Find the following entries:

\SNA\system\hwsetup\snaclasp\3270 Logon Demo.dem = "3270log.scr", ...
\SNA\system\hwsetup\snaclasp\AS400 Demo.dem = "5250log.scr", ...
\SNA\system\hwsetup\snaclasp\3270 Continuous Demo.dem = "3270flsh.scr",...
\SNA\system\hwsetup\snaclasp\3270 File Transfer Demo.dem = "ft1kmain.scr",...

Then add quotation marks to the first item in each line as shown here:

"\SNA\system\hwsetup\snaclasp\3270 Logon Demo.dem" = "3270log.scr", ...
"\SNA\system\hwsetup\snaclasp\AS400 Demo.dem" = "5250log.scr", ...
"\SNA\system\hwsetup\snaclasp\3270 Continuous Demo.dem" = "3270flsh.scr",
"\SNA\system\hwsetup\snaclasp\3270 File Transfer Demo.dem" = "ft1kmain.scr",...

Save the file and then build the Emergency Repair Disk as usual.

$ # Note on Updating DEMO SDLC Link Service from the Service Pack
You cannot update a previously installed DEMO SDLC link service from SNA Server 2.11 Service Pack #1. Instead, you must remove and reinstall the DEMO SDLC link service.

$ # Additional Information
This section contains new information about using SNA Server version 2.11.
Note on Running  INSTALL.BAT From a Shared Network Directory on Windows NT Shell Update Release
Note on Installing the Bus-Tech Channel Link Service
Note on Using Shared Folders from Client Access or PC Support
Note on Twinax Link Services (ANDWTDLC and IBMTDLC)
Notes on Installing Eicon Link Services (ECSDLC or ECX25)
Note on APPC Invokable TPs and Removal of SNA Server or Client
Note on Installing SNA Server and Rebuilding the Windows NT Emergency Repair Disk
Note on Updating DEMO SDLC Link Service from the Service Pack

$ # New White Papers, Case Studies, and other Collateral
The \COLLATRL directory on the Service Pack 1 for SNA Server 2.11 CD-ROM includes subdirectories containing the following utilities and information:
Third Party Listings and Information
The Microsoft SNA Server Companion Product Catalog, listing third-party hardware and software products that are compatible with Microsoft SNA Server 2.11. Additionally, this directory contains presentations from third party vendors on products and technologies that are compatible with Microsoft SNA Server.
Customer Case Studies
Five technical case studies from Microsoft customers documenting how the implementation of Microsoft SNA Server solved mission critical business needs.
SNA Server Events
Presentations from Microsoft SNA Server Inside Track training sessions. Presentations and class materials from the seven SNA Server technical training sessions held at Microsoft TechEd 1995. Presentations from the 1995 Microsoft SNA Server Solutions Conference held in Seattle, Washington.
General Information
Documents and presentations covering general information about Microsoft SNA Server, including the SNA Server 2.11 product data sheet and certified performance test results.
Press Releases
Microsoft SNA Server 2.1 and 2.11 press releases. Press release and presentation on the SNA Open Gateway Architecture. 
Reviewer’s Guide
SNA Server 2.11 Reviewer's Guide, Microsoft SNA Server 2.11 Test Drives for the Reviewer’s Guide, and Microsoft SNA Server 2.11 Demo Script Test Drives for the Reviewer’s Guide.
Word and PowerPoint Viewers
Installable utilities for viewing the collateral provided on the Microsoft SNA Server 2.11 product CD-ROM. These utilities are for the Microsoft Windows 16-bit and Microsoft Windows 32-bit (Intel-only) environments. 
White Papers
White papers produced by Microsoft, as well as jointly produced by Microsoft and its supporting vendors.

$ # Note on APPC Invokable TPs and Removal of SNA Server or Client
When you do a full remove of SNA Server or Client, Setup removes the configuration information used to launch invokable APPC transaction programs, even if the corresponding TP was not provided by SNA Server or client installation in the first place.  If you plan on removing SNA Server or Client and later reinstalling it, you should also plan to reconfigure any third-party or locally developed APPC-based applications.

K # + K $ 32-bit Windows SLI Applications Encounter Application Exception
Article ID: Q106114
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

A 32-bit Windows application which uses the SNA Server Windows NT SLI
interface periodically encounters an application exception.

CAUSE
=====

The SLI interface was reusing a deleted control block due to a timing
related problem, leading to an application exception.

RESOLUTION
==========

Microsoft has updated the SNA Server 2.11 file, WINSLI32.DLL, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna

K # + K $ Invalid Named Pipe Message Causes SNABASE.EXE Exception
Article ID: Q106524
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

SNA Server generates a Dr. Watson error in SNABASE.EXE when it receives an
invalid message over a Named Pipe connection from a client. The SNA Server
also logs an Event ID 624 in the Windows NT Application Log (as shown in
the Event Viewer) indicating that an SNADUMP.LOG was created for
SNABASE.EXE. The following is an excerpt from a DRWTSN32.LOG that is
created following one of these SNABASE errors:

   Application exception occurred:
      App: snabase.DBG (pid=148)
      When: 10/31/1995 @ 11:29:1.2
      Exception number: c0000005 (access violation)

NOTE: Your DRWTSN32.LOG file will appear somewhat different than this
example.

CAUSE
=====

SNABASE.EXE on the SNA Server is not properly handling an invalid incoming
NewPipe messages from SNA Server clients over Named Pipe connections. The
NewPipe messages are only sent to the SNA Server when the WNAP (16-bit) or
SNABASE (32-bit) process is initializing on SNA Server clients.

WORKAROUND
==========

For Win 3.x clients, a potential workaround is to start WNAP in advance (by
adding WNAP.EXE to the startup group of Windows or Windows for Workgroups),
so that it's not automatically invoked when an SNA application or emulator
is started.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   <winroot>\SYSTEM\SNALM.DLL
   <winroot>\SYSTEM\SNAIP.DLL
   <winroot>\SYSTEM\SNANW.DLL
   <winroot>\SYSTEM\SNAAT.DLL
   <winroot>\SYSTEM\SNABV.DLL
   <winroot>\SYSTEM\SNANB.DLL

These corrected files increase validity checking on incoming NewPipe
messages received from clients over Named Pipe connections as well as the
other client/server protocols supported by SNA Server. In addition, SNA
Server now logs an Event 631 in the Application Log when it receives an
invalid NewPipe message from a client.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Event 624: SNA Server Application Exception
Article ID: Q107382
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

An application exception occurs in SNA Server and a Dr. Watson log is
generated. The log shows that exception C0000005 has occurred in module
SNASERVR. This only happens when the Attachmate Extra print emulator
communicates with SNA Server.

CAUSE
=====

This error is observed when the Attachmate Extra print emulator sends an
Open(PLU) response to the SNA Server over it's SSCP-LU connection, rather
than the PLU-SLU connection. The OPEN(PLU) response uses the FMI interface
which is a trusted interface. Because this is a trusted interface SNA
Server does not verify that the destination value is correct. When the PLU
session attempts to process the incorrect response, the exception occurs.

RESOLUTION
==========

Microsoft has updated the SNA Server 2.11 file, SNASERVR.EXE, to validate
the destination of the Open(PLU) response, rather than simply attempting to
process the message.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ TN3270 Incorrectly Formats LU-SSCP Data From The Host
Article ID: Q107451
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When the TN3270 Server converts LU-SSCP clear-text-format data from the
host into 3270 datastream format because TN3270 clients expect to receive
data in 3270 datastream format from the host, the TN3270 Server incorrectly
inserts new rows causing the bottom rows to wrap around to the top of the
screen.

CAUSE
=====

The TN3270 Server formatting code does not correctly handle the newline
character at the end of a line.

RESOLUTION
==========

Microsoft has updated the file <tnroot>\TN3SERVR.EXE to correct this
problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.11
KBSubcategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.11

K # + K $ Problem Accessing SNA Server from Windows NT RAS Client
Article ID: Q107637
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When you attempt to start a 3270 or 5250 session from a Windows NT RAS
client (or from a Windows NT computer which was rebooted without being
initially connected to a network), the emulator does not start and the
following error occurs:

  ERROR - The SnaBase service is not started.

Also, once SnaBase is started, the Windows NT user must still be authorized
to open a network session to the Windows NT server where SNA Server is
running, or the SNA session cannot connect. If this occurs, the 3270 applet
displays "No SNA Server found in domain", while the 5250 applet displays
error F004 (Comm_Subsystem_Not_Loaded).

CAUSE
=====

When Windows NT starts up, the SnaBase service is configured to autostart.
However, if SnaBase cannot initially connect to an SNA Server, SnaBase
stops before the user can establish the RAS connection.

If an administrator logs into the computer and the 3270 emulator is
started, the SnaBase service is autostarted. However, if a user logs into
the computer, the user does not have authority to start a Windows NT
service (for example, SnaBase service), so this error occurs.

Also, once SnaBase is started, the user must still have authority to open a
network session to the Windows NT computer where SNA Server is running. If
a user account exists on the Windows NT computer, the local user password
must match the Windows NT domain user password or access is denied.

RESOLUTION
==========

An SNA Server 2.11 update is available to correct this problem. Microsoft
has updated the following Windows NT client files to correct this problem:

   <snaroot>\SYSTEM\SNABASE.EXE
   <snaroot>\SYSTEM\SNADMOD.DLL

With this update applied, SnaBase does not terminate if you add the
following registry Value under the HKEY_LOCAL_MACHINE subtree under the
following subkey:

   /SYSTEM/CurrentControlSet/Services/SnaBase/  Parameters/

   Value Name: TerminateIfNoSponsors
   Data Type:  REG_DWORD
   Data: 0

If this entry is not present, or is set to 1, then SnaBase terminates if it
cannot open the sponsor connection.

Without applying this update, it is possible to work around this problem
by assigning the following rights to local users so that they have
authority to start SnaBase:

 - For Windows NT Workstation, the local user must be a member of the
   "Power Users" group.

 - For Windows NT Servers, the local user must be a member of the
   "Server Operators" group.

Also, once the SnaBase service is started, the Windows NT user must
still have authority to open a network session to the Windows NT computer
where the SNA Server is running. When connecting over RAS, a Windows NT
user must initially login to the computer using a local user account.
When attempting to get a session to the SNA Server, the local user
credentials are used to connect to the Windows NT computer where SNA Server
is running.

If the user passwords are not synchronized, and if the SNA client is
connecting to the server over named pipes, the user can still gain access
to the SNA Server by preestablishing a network session to the server before
starting their SNA application. To do this, the user can issue the
following command:

   net use \\<server_name>\ipc$ /user:<domain>\<user_name> *

where <server_name> is the SNA Server, <domain> is the Windows NT domain,
<user_name> is the Windows NT user name, and * causes the prompt for the
user's Windows NT password.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Server Event 553 Running Novell Requestor for Windows NT
Article ID: Q107726
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

SNA Server Admin hangs on startup and the SnaBase service encounters the
following error if Windows NT is installed with the Novell NetWare
Requestor for Windows NT, version 1.01:

   Event 553:  Could not create mailslot, rc = 10048

   Event 624:
   Creating dump file c:\sna\traces\SNADUMP.LOG for SNABASE.EXE

CAUSE
=====

The SnaBase service attempts to open the same socket number on both IPX and
SPX, although the Novell IPX/SPX driver for Windows NT does not allow this,
returning socket error 10048 which means the address is already in use.
Event 624 is logged to indicate that an unrecoverable error detected by
SnaBase.

RESOLUTION
==========

An update to SNA Server 2.11 corrects this problem by supporting the
ability to configure the SPX port number used by the SnaBase service.

Microsoft has updated the following files to correct this problem:

   On the server and Windows NT clients:  <snaroot>\SYSTEM\SNANW.DLL
   Windows 95 clients:                    <win95root>\SYSTEM\SNACNW.DLL
   Windows 3.x clients:                   <winroot>\SYSTEM\NWCLI.DLL

To configure the SPX port number, install the new file and add the
following registry value on the server under the HKEY_LOCAL_MACHINE subtree
under the following subkey:

   /SYSTEM/CurrentControlSet/Services/SnaBase/  Parameters/SnaSpx

Value Name: SnaBasePort
Data Type:  REG_DWORD
Data:       <hexadecimal number>

<hexadecimal number> is the port number in hexadecimal. This number must
not match the default of 0x84C8.

When this parameter is specified the SnaBase uses the new port number for
client "sponsor" connections over SPX. The default port number (0x84C8, or
33992 in decimal) is still used for server to server (IPX) communication.
This fix requires an update to all clients (except MS-DOS based clients)
because the clients assume that the SnaBase SPX port is always 0x84C8.
However, there is no client-side entry required because the server port
number is found dynamically through the Netware bindery.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ WinAPPCCancelAsyncRequest Never Returns WAPPCALREADY (0xF000)
Article ID: Q108071
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When an APPC application issues WinAPPCCancelAsyncRequest() after the
asynchronous routine has completed, WAPPCINVALID (0xF001) is returned
instead of WAPPCALREADY (0xF000). The SNA Server APPC Programmer's
Guide states that WAPPCALREADY should be returned in this instance.

CAUSE
=====

WinAPPCCancelAsyncRequest is not properly returning the WAPPCALREADY error
code as documented.

RESOLUTION
==========

An update to SNA Server 2.11 corrects this problem, so that
WinAPPCCancelAsyncRequest now returns WAPPCALREADY if an asynchronous
routine is being cancelled has already completed.

Microsoft has updated the following files to correct this problem:

   Windows NT:  <snaroot>\SYSTEM\WAPPC32.DLL
   Windows 95:  <win95root>\SYSTEM\WAPPC32.DLL
   Windows 3.x: <winroot>\SYSTEM\WINAPPC.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Event 624 Logs Improper File Name in Explanation Text
Article ID: Q109077
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When Event 624 appears in the System log, the dump file name included in
the event explanation incorrectly appears as follows:

   COMDUMPSNABASE.EXE.DMP

The following is an excerpt from the System log:

   Event ID: 624
   Source: SNA Server
   Creating dump file C:\SNA\traces\snadump.log for SNABASE.EXE

   EXPLANATION
   A process (SNABASE.EXE) ended abnormally due to a protection
   violation or similar condition and a dump file
   COMDUMPSNABASE.EXE.DMP has been created that contains
   information about the state of the process at the time of the
   exception. Register information is contained in your Windows
   NT root directory in the file DRWTSN32.LOG.

CAUSE
=====

SNA Server logs the Event 624 explanation text incorrectly.

RESOLUTION
===========

An update to SNA Server 2.11 corrects the dump file name forming problem.
With this update applied, the correct name is now logged:

 - For Windows NT:

      SNADUMP.LOG

 - For OS/2 clients:

      COMDUMP?.DMP

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Server Setup Resets CA400 Settings in WNAP
Article ID: Q134231
--------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
--------------------------------------------------------------------

SYMPTOMS
========

When you run SNA Client Win3x Setup after installing Client Access, you may
lose Client Access Connectivity.

CAUSE
=====

After you set up the SNA Client for CA400 support, the following line are
in the [wnap] section of your WIN.INI:

   CA400=YES
   CA400SharedFolders=YES

When you re-run the SNA Client Setup to change a client value such as
network protocol, Setup sets these entries back to their default value of
"NO." This causes CA400 support to fail.

RESOLUTION
==========

To correct this problem, open your WIN.INI file with a text editor, such as
Notepad, and manually edit these entries back to "YES".

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbsetup kbbug2.11
KBSubcategory: ntsetup
Additional reference words: 2.11 prodsna

K # + K $ SNA Server Does Not Allow Configuration of LU Address 255
Article ID: Q134688
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

SNA Server Admin does not allow you to configure LU number 255 when you
configure 3270, LUA, or Downstream LUs with SNA Server Admin.

NOTE: VTAM allows you to configure dependent LUs with a local address
(locaddr parameter in VTAM) of 255.

CAUSE
=====

SNA Server Admin allows you to configure LU numbers only up to 254.

Earlier versions of VTAM have a problem configuring and using LUs with a
local address of 255. Although the problem has been resolved on the host
this restriction still exists in SNA Server.

RESOLUTION
==========

Microsoft has updated the files SNASERVR.EXE, TRCSERVR.EXE, SNAADMIN.EXE,
SNACFG.DLL, and SNACFG.EXE, to correct this problem.

To work around this problem, do not use LU number 255 with SNA Server.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbsetup kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ AFTP -F Script Fails if Password is Eight Characters Long
Article ID: Q134691
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run the AFTP -F <INPUTFILE> command, the following error message
appears:

   The password is too long. The password must be between 1 and 8
   characters in length.

This symptom occurs when you use the AFTP client script processing feature
to automate AFTP client processes and your password in the inputfile is
eight characters long.

CAUSE
=====

The AFTP client code erroneously counts the Newline character at the end of
your eight-character password as the ninth character when it reads the
password from your inputfile.

NOTE: For additional information on AFTP and AFTP client script processing,
refer to the SNA Server 2.11 Enhancements Guide and the SNA Server 2.11
README.TXT file, respectively.

WORKAROUND
==========

To work around this problem, use a password with seven characters or fewer.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Changing Domains in SNA Admin Gives Wrong Status Information
Article ID: Q134906
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.10 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server Admin program allows an administrator to manage an entire
domain (or subdomain) of SNA Servers. The administrator can switch focus to
a different domain using the File / Select Domain option.

If there are connections of the same name configured within two different
SNA Server domains (or subdomains), SNA Admin may not display the correct
connection and LU status information when focusing on another domain.

CAUSE
=====

The SNA Server Admin program caches status information on a connection in
order to optimize performance. However, if the administrator switches to
another domain which happens to have a connection configured with the same
name as a connection in the previous domain, SNA Admin does not properly
retrieve the updated status information from the new server, causing the
connection and LU status information to be incorrect.

RESOLUTION
==========

Microsoft has updated the file SNAADMIN.EXE to correct this problem.

To work around this problem, the SNA Server 2.11 Admin must be stopped and
restarted.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11 admin hotfix

K # + K $ AFTP Server May Stop Accepting New Conversations
Article ID: Q134907
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If the SNA Server 2.11 AFTP Server service is configured to require
conversation security, an AFTP client attempts to log on and provides an
invalid password, and a new valid logon attempt immediately follows, the
AFTP server fails to accept additional client login requests.

CAUSE
=====

This failure occurs due to a timing problem within the SNA Server AFTP
server service.

RESOLUTION
==========

Microsoft has updated the files AFTPAPI.DLL, AFTP.EXE, and AFTPSERV.EXE to
correct this problem.

To work around this problem, stop and start the AFTPD service.

To disable the use of conversation security with the AFTP server service to
prevent the problem:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide
problems that may require you to reinstall Windows NT to correct them.
Microsoft cannot guarantee that any problems resulting from the use of
Registry Editor can be solved. Use this tool at your own risk.

1. Run Registry Editor (REGEDT32.EXE).

2. From the HKEY_LOCAL_MACHINE subtree, go to the following key:

      \SYSTEM\CurrentControlSet\Services\AFTPD\Parameters:

3. Set the following configuration parameter:

      ConversationSecurity: REG_SZ: NO

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 aftpd aftp aftpserv.exe

K # + K $ SNA Admin Error Message Changing Domains When Using TCP/IP
Article ID: Q135235
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server Admin program generates a Dr. Watson error on SNAADMIN.EXE
when you use "Select Domain" to choose another domain to administer. A Dr.
Watson similar to the following is generated:

   An application error has occurred and an application error log is being
   generated.
   snaadmin.exe
   Exception: access violation (0xc0000005), Address: 0x00aaaad9

NOTE: The actual Dr. Watson error may vary.

This problem occurs when TCP/IP is installed.

CAUSE
=====

The SNA Server TCP/IP transport DLL does not handle unexpected connection
terminations correctly when SNA Server Admin closes a remote domain.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 trap drwtsn32 subdomain

K # + K $ Application Exception in SNA Server 802.2 Link Service
Article ID: Q135317
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The following application exception occurs in the SNA Server 802.2 link
service:

   Application exception occurred:
           App: snalink.DBG (pid=169)
           When: 5/27/1995 @ 1:54:25.364
           Exception number: c0000005 (access violation)

CAUSE
=====

A timing condition occurs where the link service uses an invalid internal
link station control block index without first checking whether it is valid
or not.

RESOLUTION
==========

Microsoft has updated the file SNADLC.DLL to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server DLC Outage Codes Should be Logged in Hex.
Article ID: Q135354
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1 and 2.11
------------------------------------------------------------------------

SYMPTOMS
========

When an SNA Server connection failure occurs, SNA Server logs Event 23 in
the Windows NT application event log and indicates the error code returned
by the SNA Server link service in the Qualifier field. For example:

   Event ID: 23
   Source: SNA Server
   Description: Connection <connection> using Link Service <link> failed
                Qualifier = 00xx

The "xx" value in the Qualifier field indicates the "outage code", which is
logged in hex format, such as "00AE". The meaning of these hex-formatted
outage codes are documented in the SNA Server Reference Guide under Event
23, as well as in the SNA Server Device Interface Specification in Section
3.4.

When enabling SNA Server Data Link Control (DLC) tracing using the SNATRACE
program (on either the SNA Server service, or a link service), the
<snaroot>\traces\NODEMSG?.TRC message trace file will also log the outage
code. However, the outage code logged in the DLC message trace is logged in
decimal, which can cause confusion.  For example:

   | DLC  ---------------------------------------------- 14:15:37.37
   | DLC  05160000->01020100 DLCST OUTG
   | DLC                     Outage:174 UPTYPE:0 UPCNTR:0 COUNT:0
   | DLC
   | DLC  ---- Header  at address 00CF478C, 0 elements ----
   | DLC  18110000 00000000 00000000 0100C600     <..............F.>

In the above case, the outage code of 174 decimal is equivalent to 0xAE
hex.

CAUSE
=====

SNA Server DLC message tracing logs outage codes in decimal.

RESOLUTION
==========

When interpreting an SNA Server DLC message trace outage message, the
outage code should be converted to hex in order to locate the proper error
listed in the SNA Server Reference Guide.

Microsoft has updated the file SNATRCSN.DLL to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Event 11 (1178) Causes SNA Server to Fail Abnormally
Article ID: Q135355
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When a Local APPC LU / Remote APPC LU partnership is defined in the SNA
Server configuration file, SNA Server automatically negotiates the
parallel session limit with the remote system when the connection that
owns the Remote APPC LU is started. This negotiation occurs over an
SNASVCMG mode session between these APPC LUs, using the Change Number
of Sessions (CNOS) command as defined by IBM SNA architecture.

When a large number of APPC LUs are configured in SNA Server and SNA Server
is started, SNA Server builds the SNASVCMG mode BIND messages and CNOS
commands for all these LU/LU/mode partnerships and queues them internally
until they can be processed. If there are so many partnerships that the
internal SNA Server queue becomes exhausted, SNA Server logs the following
event in the Windows NT application event log:

   Event 11 (1178) Initialization Failure
   1178 = Insufficient resources for automatic session limit negotiation

After this error occurs, the SNA Server service terminates.

CAUSE
=====

SNA Server interprets this condition as a fatal error, causing the SNA
Server service (SNASERVR.EXE) to generate an SNA Server dump file.

RESOLUTION
==========

You can correct this problem by installing an SNA Server 2.11 fix that is
now available. This fix reduces the severity of the error so that SNA
Server attempts to recover from the condition, rather than failing.
Microsoft has updated the file SNASERVR.EXE to correct this problem.

To work around the problem without installing the fix:

 - Reduce the number of APPC LU partnerships.

   Using the SNA Server Admin program, select each Local APPC LU, choose
   the Partners button, and delete any LU/LU/mode partnerships that are not
   being used. When the Enable Automatic Partnering checkbox is selected on
   an APPC LU or Mode, this can cause extra LU/LU partnerships that are not
   intended.

 - Reduce the number of automatically activated sessions.

   Within the SNA Server APPC mode definition, the Automatic Activation
   Limit can be configured to automatically bind a specified number of
   LU6.2 sessions when the connection is started. Automatically starting an
   LU6.2 session ahead of time makes the session immediately available for
   an LU6.2 conversation. However, the overhead necessary to start an LU6.2
   session is often negligible, so automatic session activation is often
   unnecessary.

   Reducing the automatic activation limit will reduce the number of
   BIND messages that SNA Server will queue internally.

 - Defer CNOS processing until sessions are needed.

   The SNA Server service can be configured to defer the APPC LU CNOS
   processing until the LU sessions are actually requested by APPC
   applications. This feature can be enabled using the following registry
   entry:

      HKEY_LOCAL_MACHINE
      \SYSTEM\CurrentControlSet\Services\SnaServr\Parameters
      NOINITCNOS: REG_SZ: YES

   This setting will cause SNA Server to defer CNOS processing until
   an APPC application allocates a conversation over an APPC LU pair.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 Event 11 1178 cnos

K # + K $ Win32 CPIC CMEPLN Call May Return Truncated Partner LU Name
Article ID: Q135356
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If a Windows NT CPIC application calls Extract_Partner_LU_Name (cmepln) and
a fully qualified partner LU name is configured within the CPIC side
information in the SNA Server configuration file, the last byte of the
partner LU name is truncated.

This problem occurs only with Windows NT-based programs. The correct
partner LU name is returned to Initialize_Conversation (cminit), so this
problem occurs only with the cmepln call.

RESOLUTION
==========

Microsoft has updated the file SNABASE.EXE to correct this problem.

To work around the problem, configured the Partner LU name, from the CPIC
symbolic destination name properties dialog box, with an alias name rather
than a fully qualified name.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 cmepln

K # + K $ SDLC Multidrop Primary Configuration Problems
Article ID: Q135490
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

You have the following SDLC multidrop primary configuration problem:

 - If you assign a multidrop primary connection to a link service once, you
   are unable to assign other connections to it.

   -or-

 - If you assign a non-multidrop primary connection to a link service, for
   example, a peer to host connection, you cannot assign a multidrop
   primary connection to the link service.

These symptoms do not occur on standard SDLC leased or switched connections
to host systems where you select the Host system option in the SNA Admin
Connection Properties dialog box.

NOTE: A multidrop connection is a connection through which one primary
computer communicates with multiple secondary computers. SNA Server
supports multidrop connections to peer or downstream computers on leased
SDLC lines. You can configure up to four multidrop connections on each
line, with an SNA server as the primary server on each.

CAUSE
=====

There is a problem in SNAADMIN.EXE.

RESOLUTION
==========

Microsoft has updated the file SNAADMIN.EXE to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SDLC Multidrop Primary Needs to be Remote End = Host System.
Article ID: Q135491
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

A multidrop connection is a connection through which one primary computer
communicates with multiple secondary computers. SNA Server supports
multidrop connections to peer or downstream systems on leased SDLC lines.
You can configure up to four multidrop connections on each line, with an
SNA server as the primary server on each.

SNA Server Admin only allows the Multidrop Primary check box to be selected
if the Link Role is Peer (negotiable). It should be set to host (primary)
for multi-drop to work correctly. The Link Role is set in the Connection
Properties dialog box. To get to the Multidrop Primary check box, from the
Connection Properties dialog box, select the Setup button and then the
Advanced button.

RESOLUTION
==========

Microsoft has updated the file SNAADMIN.EXE to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ DSPU Through Demo Link Service Causes Scrolling 3270 Screen
Article ID: Q135492
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run DSPU through the 3270 Continuous Demo link service, your 3270
screen scrolls.

This problem occurs when you:

1. Install the 3270 Continuous Demo link service using SNA Server Setup,
   add a connection to use this link service, and add a Downstream LU to
   this connection.

2. On the same computer, you configure a Downstream 802.2 connection and
   assign the Downstream LU in step 1 to this connection. See the "SNA
   Server Administrator Guide" for details on configuring downstream
   connections.

3. Save this configuration in SNA Server Admin.

4. On a second computer, configure an on-demand 802.2 host connection
   pointing to the original computer.

5. Save this configuration in SNA Server Admin.

6. From the second computer, activate the 3270 session using the SNA
   Server 3270 application.

Because this session is associated with a connection configured for
"on-demand," the connection will start when the emulator requests a
session. The connection goes active after starting the 3270 application.
Let the 3270 application sit; notice that the DEMO SDLC connection cycles
between Active and Inactive status. The 3270 application will display the
Space Needle host signon screen over and over, shifting a few rows up the
screen each time.

If you manually activate the 802.2 connection on the second computer rather
than letting the application activate it, the connection does not
oscillate.

RESOLUTION
==========

Obtain a new script file and SNACLASP.DLL file to cope with the
extra NOTIFY RU that flows in this configuration.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 demo link service continuous

K # + K $ Failure of One SDLC Multidrop Connection Reactivates All Others
Article ID: Q135494
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

A multidrop connection is a connection through which a primary computer
communicates with multiple secondary computers. SNA Server supports
multidrop connections to peer or downstream computers on leased SDLC lines.
You can configure up to four multidrop connections on each line with one
SNA Server server acting as primary on each.

When SNA Server Admin is configured with more than 1 multidrop primary SDLC
connections and the active connection has an outage or timeout, the failing
connection is reactivated. However, all the other connections using the
same link service are (incorrectly) activated or reactivated as well.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 multidrop primary

K # + K $ 802.2 Link Service Hangs APPC Program or Causes Event ID 592
Article ID: Q136095
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When you download data from a host computer using an APPC program with 4K
RU sizes (pacing of 8), one or more of the following symptoms occur:

 - The following event appears in the application log:

      Event ID 592
      Descrition: Receive_Allocate timed out. No incoming allocate was
      accepted within the configured timeout period.

 - The APPC program freezes.

CAUSE
=====

When SNA server detects that DLC.SYS is in a local busy state, the 802.2
link service queries DLC.SYS once to see whether it has enough buffers to
clear it, but the 802.2 link service fails to continue querying if the
first query is unsuccessful.

This is a trace of the problem:

   (linkint.trc)
   |00000027.00000093 TRC_W  asy-wr writeptr now 24, linktype 4
   |00000027.00000093 a4ucc  completed READ - index = 0, rc = 0
   |00000027.00000093 a4ucc  DLC status - code = 1
   |00000027.00000093 a4ucc  entering local busy due to buffer shortage
   |00000027.00000093 a4ugb  get a DRB - command = 1e
   |00000027.00000093 a4ugb  get a general DRB
   |00000027.00000093 a4ugb  got a DRB 00073630 command 1e

RESOLUTION
==========

To resolve this problem, install the fix mentioned below.
The new 802.2 link service retries the query about every 0.2 seconds.
Microsoft has updated the file SNADLC.DLL to correct this problem.

To work around this problem if your program hangs, deactivate the LU on
both the host and in SNA Server.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbsetup kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server WinSLI Library Does Not Support Format 1 InitSelf
Article ID: Q137267
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When an SLI_Open API call is issued, and the SLI application has defined
format 1 Initself, the WinSLI library returns the following error message
in an RUI trace:

   initself not valid

CAUSE
=====

The SNA Server 2.0, 2.1 and 2.11 SLI interface was originally written
to support only Format 0 Initself messages. However, it has been expanded
in SNA Server 2.11 to support Format 1 as well.

Page 5-22 of the IBM SNA Formats Guide defines a format 1 Initself to
be identified as 810681 (bytes 0-2), while the format 0 Initself to
be identified as 010681.

RESOLUTION
==========

Microsoft has updated the files, WINSLI.DLL, for 16-bit clients, and
WINSLI32.DLL for 32-bit clients, to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 winsli format initself

K # + K $ SNA Server Windows 3.x APPC Display Call May Cause GP Fault
Article ID: Q137308
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.10, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If a Windows 3.x program calls the APPC DISPLAY verb and uses the
CSEXTNIDCSLISTND option to return a list of active SNA Servers in the
domain, the program may encounter an application exception in WINMGT.DLL,
WDMOD.DLL, application DLL, or may cause the computer to stop responding
(hang). For backwards compatibility, SNA Server included the APPC Display
verb CSEXTNIDCSLISTND for applications written to talk to IBM ES for OS/2
version 1.0.

This problem occurs only if there are no SNA Servers in the domain that are
configured to support a Netview connection.

CAUSE
=====

The winmgt calls the SNAReleaseBuffer with a random memory address
and releases a random memory segment (stack, dgroup or code).

RESOLUTION
==========

Microsoft has updated the file WINMGT.DLL to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 gpf general protection fault gp

K # + K $ Stop Msg: 0x0000003F NO_MORE_SYSTEM_PTEs SNA & TCP/IP Sockets
Article ID: Q137309
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.10 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

This Windows NT STOP Message appears when SNA Server 2.1 or 2.11 supports
users over native TCP/IP sockets.

   STOP: 0x0000003f
   NO_MORE_SYSTEM_PTEs

CAUSE
=====

When an SNA client computer has a TCP/IP socket connection to an SNA
Server, the server periodically sends a KeepAlive message to the client to
speed up the detection of a lost client LAN session. SNA Server TCP/IP
KeepAlive messages do not complete because the client's TCP receive window
size dropped to zero. The SNA Server keeps on queuing new KeepAlive
messages (even though earlier keep alive messages haven't completed) until
the SNA Server runs out of system PTEs.

RESOLUTION
==========

WARNING: Using the Registry Editor incorrectly can cause serious, system-
wide problems that may require you to reinstall Windows NT to correct them.
Microsoft cannot guarantee that any problems resulting from the use of the
Registry Editor can be solved. Use this tool at your own risk.

Microsoft has modified the files, SNADMOD.DLL and SNAIP.DLL, so that SNA
Server does not queue a new KeepAlive until the previous one has completed.
Thus, the connection is aborted after a configurable timeout. The timeout
is specified in the following registry parameter:

   Hkey_local_machine
     \System
       \CurrentControlSet
         \Services
           \SnaBase
             \Parameters
               \TcpIp
                 \KeepAliveLimit REG_DWORD: 0 - 0xFFFFFFFF
                                 (0 = Never abort)

The KeepAliveLimit specifies how many WatchDogTimeouts SNA Server waits
before aborting the connection. The default watchdogtimeout value is 60
seconds, though this is also configurable under:

   Hkey_local_machine
     \System
       \CurrentControlSet
         \Services
           \SnaBase
             \Parameters
               \watchdogtimeout REG_DWORD: <value>

If a second keepalive is sent to a client box, SNA Server now logs Event
700 to indicate this (logged only when detailed problem analysis logging is
enabled). If the limit is exhausted, then SNA Server logs a 701 event at a
high severity to indicate this. The client's IP address is logged in these
new events.

The registry value, HardClse, controls how the connection is aborted. If
the value is "yes", the connection is reset immediately and no effort is
made to close the connection gracefully. The default value is "no".
HardClse is found in the following subtree:

   Hkey_local_machine
     \System\CurrentControlSet
       \Services
         \SnaBase
           \Parameters
             \TcpIp
               \HardClse

   REG_SZ: ("no" -or- "yes")

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna no_more_system_ptes sna server

K # + K $ Client RPC Call for Remote APPC LU List Causes SNABASE Error
Article ID: Q137382
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, Versions  2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

SNA Server generates a Dr. Watson error in SNABASE.EXE when a client does a
RPC call to get a list of Remote APPC LUs which are paired with a Local
APPC LU. The SNA Server logs an Event ID 624 in the Windows NT Application
Log (as shown in the Event Viewer) indicating that a SNADUMP.LOG was
created for SNABASE.EXE. The error also generates a DRWTSN32.LOG when it
occurs. The following is an excerpt from a DRWTSN32.LOG that was created
following one of the SNABASE errors:

   Application exception occurred:
   App: C:\SNA\system\snabase.exe (pid=139)
   When: 8/7/1995 @ 10:38:21.884
   Exception number: c0000005 (access violation)

Your DRWTSN32.LOG file will appear somewhat different than this example.

NOTE: If using Windows NT Server 3.5, you will have to load the Windows NT
Symbols to get a proper Dr. Watson log when using SNA Server.

After the SNABASE error occurs, the SNA Server stops accepting sessions
from SNA Server clients until the SNA Server is shutdown and restarted.

CAUSE
=====

This error is caused when SNA Server tries to copy (read) a larger range of
memory than is in a memory buffer. This happens when a client makes an RPC
call to get the list of Remote APPC LUs partnered with a particular Local
APPC LU and the number of Remote APPC LUs exceed the size of the client's
buffer. The error only occurs if the memory buffer is located at the end of
a 4K page and the extra memory that SNA Server attempts to read is located
on the next uncommitted page. The buffer size is usually less than one
hundred bytes so the probability of this error is quite small.

RESOLUTION
==========

Microsoft has modified the files, SNABASE.EXE and SNADMOD.DLL, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.10 2.11 prodsna DRWTSN32.LOG SNADUMP.LOG trap

K # + K $ SNA Server CPIC cmscsp Call Rejects Zero Length Password
Article ID: Q137438
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If a CPIC application calls Set_Conversation_Security_Password (cmscsp)
and specifies a password of zero length, the call will return with error:

   CM_PROGRAM_PARAMETER_CHECK.

CAUSE
=====

The SNA Server CPIC interface on Windows NT, Windows 3.x and OS/2
incorrectly rejects a zero-length password.

RESOLUTION
==========

Microsoft has modified the following files to correct this problem:

   WCPIC32.DLL - Win32 client CPIC interface
   WINCPIC.DLL - Windows 3.x client CPIC interface
   CPIC.DLL    - OS/2 client CPIC interface

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv ntsecurity
Additional reference words: prodsna 2.11 CPIC cmscsp 0-length password

K # + K $ LUA Program Receives Host Sign-On Screen Twice and then Hangs
Article ID: Q137482
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you start your LUA program, the SSCP Welcome message screen appears
twice, and the LUA program seems to hang.

CAUSE
=====

Under certain timing conditions, when an LUA session is closed (with an
SLI_CLOSE statement) and immediately reopened (with an SLI_OPEN statement)
over a fast link, SNA Server may incorrectly resend the host SSCP welcome
message a second time to the LUA program. As a result the LUA program may
hang.

The following message flow causes this problem:

   LUA Program    SNA Server      Host
   -----------------------------------------------------
                                 <- UNBIND
                 UNBIND +RSP ->
                 NOTIFY(SLU disabled) ->
  SLI_CLOSE ->
  SLI_OPEN ->
                                 <- SSCP welcome message
                 <- SLI_OPEN(SSCP welcome message)
                                 <- NOTIFY +RSP
                 NOTIFY(SLU enabled) ->
                                 <- SSCP welcome message
  SLI_RECEIVE ->
                 <- SLI_RECEIVE (SSCP welcome message)
                                 <- NOTIFY +RSP

RESOLUTION
==========

To resolve this problem, upgrade to SNA Server version 2.11 and install the
updated file SNASERVR.EXE.

To work around this problem, you can put a small delay in the application
between the SLI_CLOSE completing and issuing the new SLI_OPEN command.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SLI Interface Returns Truncated Data on SSCP-LU Session
Article ID: Q137500
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

All messages received on the SSCP-LU session via SLI_OPEN or SLI_RECEIVE
API calls are truncated to 256 bytes of data. The SLI_OPEN returns with
AP_OK while SLI_RECEIVE returns the following error message:

   LUA_DATA_TRUNCATED.

This problem occurs with the SNA Server Windows 3.x and Win32 SLI API
interfaces.

CAUSE
=====

This is a problem in the SLI library. It is limiting the size of
SLI_RECEIVEs on the normal SSCP flow to 256 bytes, whereas many hosts
send larger RUs than this on the SSCP-LU session.

RESOLUTION
==========

Microsoft has updated the files, WINSLI.DLL and WINSLI32.DLL, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntgeneral
Additional reference words: prodsna 2.00 2.10 2.11 LUA SLI_OPEN
SLI_RECEIVE LUA_DATA_TRUNCATED

K # + K $ SNACFG.EXE Fails with Spaces in Username Parameter
Article ID: Q137576
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you issue the SNACFG USER <username> command to display user
information for the user specified by <username> and <username> contains
spaces, for example, Joe Blow, the following error message appears:

   Insufficient Privilege or the configuration file is locked for
   read\write access.

CAUSE
=====

The SNACFG.EXE program does not recognize a user name containing one or
more spaces.

RESOLUTION
==========

Microsoft has updated the files SNACFG.EXE and SNACFG.DLL to correct this
problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Error 3846: The Control Point Name is Invalid
Article ID: Q137577
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

After you install Microsoft SNA Server version 2.11 on a Microsoft
Windows NT server, the following error message appears when you run SNA
Admin:

   Error 3846:
   The Control Point Name is invalid.
   The name can be from one through eight alphanumeric characters long.

This problem occurs when the Windows NT server name begins with a digit.

CAUSE
=====

There is an IBM SNA standard that an APPC control point name cannot begin
with a digit. If the Local Control Point Name is not already configured on
the SNA Server, the Microsoft SNA Server 2.11 Admin program automatically
sets the Local Control Point Name (in the server properties dialog) to the
Windows NT computername. If the Windows NT computername starts with a
digit, the SNA Admin program sets the local control point name to an
invalid value.

WORKAROUND
==========

To work around this problem, open the COM.CFG file with the following
command line command:

   SNAADMIN C:\SNA\SYSTEM\CONFIG\COM.CFG

This opens the SNA Server configuration file off-line and allows you to
enter a valid Control Point name.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntgeneral
Additional reference words: prodsna 2.11 snaadmin 3846

K # + K $ Problems with Multiple Sessions over TCP/IP using NetSoft Elite
Article ID: Q137581
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you open multiple 3270 sessions with NetSoft Elite 3.5 over a SNA
Server 2.11 Windows 3.1 or Windows for Workgroups client configured to use
TCP/IP sockets to communicate with multiple SNA Servers, NetSoft Elite
displays the following errors and hangs:

   Error 2574: LU or LU Group not found in configuration
   Error 87: SSCP connection already open
   Error 85  No LU in group free

If you have a session already open, you may lose that session when you open
a second session.

NOTE: The above errors are returned by the SNA Server client interface.
These errors normally occur under the following conditions. For example:

 - Error 2574 can occur if you open a specific 3270 LU session when the SNA
   Server supporting that session is currently not active.

 - Error 85 can occur if another user already has the specific LU open.

 - Error 87 can occur if a pooled LU session is requested, though all LUs
   in the pool are already in use.

However, the symptoms above occur even though the SNA Server(s) and LUs
being requested are available.

CAUSE
=====

There are two separate causes.

First, when multiple sessions are opened using NetSoft Elite, the NetSoft
3270 emulator submits multiple Open (SSCP) requests at the same time.
However, the SNA client interface can only accept one Open (SSCP) request
at a time from a given windows process.

Secondly, the SNA Server Windows and Windows for Workgroups TCP/IP DLL file
is not handling the receipt of data on one TCP/IP socket while attempting
to connect to an SNA Server over a second socket, for example, when a
second session is opened. This leads to a lost client session error (or
Path error) that is returned to the emulator on the session that had been
working.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   Path and File name           Description
   --------------------------------------------------------------------
   <WINROOT>\SYSTEM\WDMOD.DLL   SNA Server Win 3.x client module
   <WINROOT>\SYSTEM\IPCLI.DLL   SNA Server Win 3.x TCP/IP interface
                                module
   <sna.win>\WNAP.EXE           SNA Server Win 3.x client moduleSTATUS

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

NetSoft Elite 3.5 is manufactured by a vendor independent of Microsoft; we
make no warranty, implied or otherwise, regarding this product's
performance or reliability.

KBCategory: kbnetwork kb3rdparty kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ TN3270 Service Will Not Start With A Large Config File
Article ID: Q137588
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server versions 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When the TN3270 server configuration file becomes too large the service
fails to start and the following error message is logged in the event log:

   Event 102: Source:tn3270 server
   Type error:
   TN3270 Service initialization completed by time-out.

   Explanation
   TN3270 Service initialization failed.

   Action
   Record message and contact technical support.

RESOLUTION
==========

Microsoft has updated the file, %tnserverroot%\TN3SERVR.EXE, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.11
KBSubcategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.11 tn3270

K # + K $ SNA Server DFT Link Service Outage 0x11 (DSR Failure)
Article ID: Q137804
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you use the IBMDFT.DLL driver with the Microsoft SNA Server, the
receipt of a large amount of data (such as a screen dump) causes the DFT
connection to disconnect with an Outage 0x11 message (that is a DSR
failure).

CAUSE
=====

The DFT link service is erroneously informing the node that it supports a
maximum frame size of 256 bytes. As a result, the node uses a maximum frame
size of 256 bytes. When the node has an RU larger than 256 bytes to send to
the link service, it segments the RU to stay at or below 256 bytes and
sends it in multiple parts. The link service cannot cope with this
(expecting to receive only whole RUs), and disconnects the connection.

RESOLUTION
==========

Microsoft has updated the file IBMDFT.DLL to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Server Event 563 and Win 3.x Client Application Problems
Article ID: Q137901
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The following symptoms can occur when 15 or more SNA Servers are installed
within a single Windows NT domain and Windows 3.x clients are being used:

 - The 3270 applet may fail to start and report "DL-BASE not initialized."

 - If you are using Wall Data Rumba, Rumba 3270 may fail to start and
   display the Interface Not Found message.

 - Clients that open an SNA application session may experience long
   delays before receiving a host sign-on screen.

 - The Windows NT application event log will include:

      Event ID: 564
      Description: Failed to initialize exit list processing, rc = 563

      Event ID: 563
      Description: The service table is full: too many network resources
      active.

   NOTE: The SNA client reports Event 563 to the server, so it's the
   client's internal "service table" that is full, not the server's.

CAUSE
=====

The SNA Server Windows 3.x client software supports sessions through
multiple SNA Servers. However, if there are more than 14 SNA Servers
currently running in the SNA Server domain, Win 3.x clients begin
experiencing these problem due to an internal limit within the SNA Server
Windows 3.x client service table. The service table is used by the
SNA Server client to internally manage the SNA client resources
being used on the client machine.

The SNA Server Win 3.x client service table contains 32 entries:

 - Two "overhead" entries (one for the sponsor connection [sponap]
   and one entry for WNAP).

 - One entry for every SNA Server service currently running in the domain.

 - One entry for every SNA Server configuration server (snabase)
   running in the domain (i.e. primary and backup servers).

 - One for each active Windows process which uses the SNA Win 3.x
   client API interfaces (i.e. the 3270 and 5250 applets each take
   one entry).

 - One for every "otherservers" entry configured on the client machine.

 - One for every invokable TP registered on the client machine.

If "otherserver" and APPC TPs are not being used, and you want to run a
3270 emulation product on the client, the maximum number of SNA Server
config servers in the domain is (32 - 3 = 29 % 2) = 14. If more than 14 SNA
servers are running in the domain, the above errors will be logged and the
user will not be able to run an emulator on the SNA Server Win 3.x client
machine.

RESOLUTION
===========

Microsoft has updated the following files to correct this problem:

   <snaroot>\WNAP.EXE
   WINDOWS\SYSTEM\WDMOD.DLL
NOTE: These files are applied to the SNA Server Windows 3.x client, not the
SNA Server.

The update to the SNA Win 3.x client software limits the number of
configuration servers kept in the service table to 2 entries. This extends
the theoretical number of SNA Servers supported in a domain to 27. However,
Microsoft strongly recommends that SNA Server 2.11 be deployed and the
subdomain feature implemented, allowing SNA Servers to be separated into
logical groups within a Windows NT domain. Using the subdomain feature, the
client users would connect only through one group of servers at a time. See
the SNA Server 2.11 Readme file for more information about the subdomain
feature.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.00 2.10 2.11 prodsna session drop hang

K # + K $ SNASERVR.EXE Traps When it Receives an Illegal SIGNAL Command
Article ID: Q137902
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server generates a Dr. Watson error when it receives an illegal
SIGNAL command from a host system. The DRWTSN32.LOG file indicates that an
Application Exception has occurred in SNASERVR.EXE. In addition, SNA Server
logs Event 624 in the Windows NT application log when the SNASERVR.EXE trap
occurs. The Event 624 has a description similar to the following:

   Creating dump file C:\SNA\traces\snadump.log for SNASERVR.EXE

   EXPLANATION
   A process (SNASERVR.EXE) ended abnormally due to a protection
   violation or similar condition and a dump file SNADUMP.LOG has been
   created that contains information about the state of the process at
   the time of the exception. Register information is contained in your
   Windows NT root directory in the file DRWTSN32.LOG.

CAUSE
=====

The SIGNAL command consists of the command byte and a four-byte value,
according to the IBM SNA Formats Guide. Therefore, any SIGNAL command that
consists of fewer than five bytes is illegal. The SNA Server Node
(SNASERVR.EXE) will trap as described above if it receives an illegal
SIGNAL command containing fewer than 5 bytes. In addition, a similar trap
on the receipt of an illegal LUSTAT command containing too few bytes is
also possible.

NOTE: Please refer to the RU section of the IBM SNA Formats Guide
(GA27-3136) for more specifics on format of SNA commands.

RESOLUTION
==========

Microsoft has updated the file SNASERVR.EXE to correct this problem.

MORE INFORMATION
=================

This problem was encountered by a customer when sending an illegal SIGNAL
command data message to SNA Server from a host simulator. This problem has
not been encountered when running SNA Server against actual SNA
connectivity products from IBM or any other vendor.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: node sig 3270 mainframe vtam prodsna event
viewer

K # + K $ TN3270 Server Rejects Client Model Types
Article ID: Q138015
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

If your TN3270 clients are configured with two LU pools, each with
different 3270 LU Model types, a TN3270 client is only able to connect with
one Model type.

Steps To Reproduce Problem
--------------------------

1. Use TN3270 Server Admin to set up two pools or use individual LU's:

     Pool1 use Model 2
     Pool2 use Model 5

2. Try to connect.

   NOTE: Only the Model 5 clients are able to connect in this example.

CAUSE
=====

When the TN3270 client accesses an LU for the first time, the TN3270 server
starts an LU list of LUs that the client may access, however, when the
client tries to connect to another LU, the TN3270 server fails to add that
LU to the LU list, thus always limiting the client to the first LU.

RESOLUTION
==========

Microsoft has updated the following file to correct this problem:

   <tnserverroot>\TN3SERVR.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

MORE INFORMATION
================

The problem lies in the TN3270 Server implementation of TCP/IP masking.
Each LU configured for use by the TN3270 Server can have TCP/IP masks
associated with it, and these masks specify the TCP/IP addresses of clients
that may connect through that LU. By default each LU has a mask that lets
any client connect. When a client first tries to connect (and this is
before the client has specified which Model type it wants to use) the
server builds a list of LUs that that client may access, based on the LU's
TCP/IP mask and the client's TCP/IP address.

In the Steps To Reproduce Problem example above, there are two LUs
configured, one that supports Model 2 requests and one that supports Model
5 requests. When the client tries to connect, the server builds the list of
LUs and stops when it has that one LU in the list. When the client tries to
connect again the LU it selects is always the one that supports Model 5
requests. When the client requests a Model 2 terminal, the server rejects
the request, because the only LU in the list is a Model 5 LU.

KBCategory: kbnetwork kbinterop kbbug2.11
KBSubCategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.11 tn3270

K # + K $ Attachmate Extra! 3270 V4.x Causes Trap in SNA Server Service
Article ID: Q138269
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

An application exception (trap) occurs in the SNA Server service
(SNASERVR.EXE) when used with the Attachmate Extra! 3270 version 4.x
emulator.

If you have Dr. Watson (DRWTSN32.EXE) configured as the default debugger,
the DRWTSN32.LOG shows an exception similar to the following:

   Application exception occurred:
      App: snaservr.DBG (pid=147)
      When: 8/1/1995 @ 16:39:1.590
      Exception number: c0000005 (access violation)

In addition, SNA Server logs Event 624 in the Windows NT Application Log
(as seen in the Event Viewer) when this trap occurs. The following is a
detailed description of the Event 624 that is logged when this trap occurs:

   Creating dump file C:\SNA\TRACES\SNADUMP.LOG for SNASERVR.EXE

   EXPLANATION
   A process (SNASERVR.EXE) ended abnormally due to a protection
   violation or similar condition and a dump file SNADUMP.LOG has been
   created that contains information about the state of the process at
   the time of the exception. Register information is contained in your
   Windows NT root directory in the file DRWTSN32.LOG.

CAUSE
=====

A 3270 emulator has two connections to the SNA Server service. One
connection is for SSCP-LU data and the other one is for PLU-SLU (Primary
Logical Unit - Secondary Logical Unit) data. The SNA Server service trap is
caused because the 3270 emulator is sending a PLU-SLU message on the
connection that is only meant to handle SSCP-LU data. This is behavior
which the SNA Server service is not expecting, and it traps when it
accesses its session control block for the SSCP-LU session and treats it as
a control block for the PLU-SLU session.

RESOLUTION
==========

Microsoft has modified the file, SNASERVR.EXE, to handle this error.

A 3270 emulator communicates with the SNA Server service over the Emulator
Interface Specification (EIS) interface. For performance reasons, this is a
trusted interface - that is, the SNA Server service assumes that messages
across this interface are correctly addressed and formatted. The fix for
this trap involves producing a SNA Server service which actually checks
that messages received from the emulator on the connection for SSCP-LU data
are in fact valid messages for that session, and discards them if they are
not. This fix allows the client to continue to function as if nothing had
happened and it prevents the SNA Server service from trapping.

A reproduction scenario hasn't been found to reliably cause this condition,
so the problem in the emulation is still under investigation. However, with
this update, the SNA Server now checks for this condition and no longer
leads to an application exception.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 dump third-party app
mainframe win3.x

K # + K $ Dynamically Loading/Unloading WINRUI32.DLL Causes System Hang
Article ID: Q138388
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When you dynamically load and unload the WINRUI32.DLL, your computer hangs.
This symptom occurs sporadically.

CAUSE
=====

This problem occurs during a call to FreeLibrary (hLibModule) where
hLibModule was previously set to the result of a call to LoadLibrary
(WINRUI32.DLL).

The hang occurs when the WINRUI32.DLL is unloaded by the FreeLibrary()call.
The hang is caused by WINRUI32.DLL trying to remove its DMOD routing
procedure during DLL detach processing. There are certain procedures that
cannot be reliable performed inside detach processing, for example, waiting
for something like the DMOD routing proc table to become available.

Existing applications that do not call WinRUIStartup/WinRUICleanup continue
to function as before.

RESOLUTION
==========

Microsoft has updated the file LIBS\WIN32WINRUI32.DLL to correct this
problem.

The fix to the WINRUI32.DLL removes the RUI routing procedure during the
processing of the WinRUICleanup() call and ensures that the DLL detach
processing does not attempt to do it again. To properly load and unload the
DLL you need to always call WinRUIStartup before your first RUI verb and
WinRUICleanup before freeing the WINRUI32.DLL.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbprg kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Win 3.x Client (WNAP.EXE) Hogs CPU, Affects Some Apps
Article ID: Q138389
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run the SNA Server Windows 3.x client process (WNAP.EXE), other
CPU-intensive Windows processes do not run properly. For example, a CPU-
intensive CAD application does not update the display in a timely fashion
when WNAP is running.

CAUSE
=====

WNAP has a loop in it that is constantly calling PeekMessage(), and then
processing any message it finds. If there is a low-priority task trying to
run (e.g., something like a screen-saver), that task is shut out.

RESOLUTION
==========

WNAP.EXE and WDMOD.DLL have been modified so that it now uses GetMessage()
instead of PeekMessage() if you add the line "PeekLoop=no" is in the [WNAP]
section of WIN.INI.  For example:

   [WNAP]
   PeekLoop=no

NOTE: The default is PeekLoop=yes.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv ntconfig
Additional reference words: prodsna wnap yield 2.00 2.10 2.11

K # + K $ Stopping SNA Server Causes Application Exception in SNALINK.EXE
Article ID: Q138611
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

An application exception (trap) occurs in the SNA Server 802.2 Link Service
when you stop SNA Server version 2.11. If DRWTSN32.EXE is configured as the
default debugger, the DRWTSN32.LOG includes an exception similar to the
following:

   Application exception occurred:
      App: snalink.DBG (pid=169)
      When: 08/2/1995 @ 1:54:25.364
      Exception number: c0000005 (access violation)

In addition, SNA Server logs Event 624 in the Windows NT Event Viewer
Application Log when this trap occurs. The following is a detailed
description of the Event 624 that is logged when the exception occurs:

Creating dump file C:\SNA\TRACES\SNADUMP.LOG for SNALINK.EXE

EXPLANATION:

A process (SNALINK.EXE) ended abnormally due to a protection violation or
similar condition and a dump file SNADUMP.LOG has been created that
contains information about the state of the process at the time of the
exception. Register information is contained in your Windows NT root
directory in the file DRWTSN32.LOG.

CAUSE
=====

The application exception is caused when the 802.2 Link Service tries to
access a pointer to a LCB after it has previously been freed.

RESOLUTION
==========

Microsoft has updated the follwing files to correct this problem:

   <snaroot>\SYSTEM\SNADLC.DLL
   <snaroot>\SYSTEM\HWSETUP\SNACLASP.INF

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 trap admin net stop snaservr.exe

K # + K $ SNA Server Admin May Show Incorrect Status for LUs 54 - 106
Article ID: Q138803
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

On your SNA Server supporting multiple connections, SNA Server Admin
displays that the status for a block of defined LUs between LU numbers 54
and 106 is Inactive even though the LUs are actually Available or In
Session.

The problem occurs if the all of the following are true in the order
listed:

1. There are two (or more) PUs (connections) defined on a SNA server.

2. Both PUs have 53 or more LUs defined.

3. SNA Server Admin is started and it asks the SNA server to send the
   current state (for example, Inactive, Available, In Session, etc.) of
   all LUs.

4. SNA Server Admin gets the state of all the LUs for the first PU, for
   example, PU_X.

5. Before SNA Server Admin gets the state of the LUs on the second PU, for
   example, PU_A, SNA Server gets notification that some of the LUs on PU_X
   have changed state.

6. SNA Server Admin gets the state of all the LUs on the second PU, PU_A,
   rather than the first PU, PU_X, because PU_A is alphabetically sorted
   before PU_X.

The problem does not occur if one or more of the following are true:

 - If PU_A is named PU_Z, for example, that is, if it is named so it is
   alphabetically sorted after PU_X.

 - If step 4 above comes after step 5, that is, if SNA Server Admin
   receives the PU_A LU status before any change notification for the PU_X
   LUs).

 - If PU_A or PU_X has 52 or fewer LUs defined.

 - If PU_A and PU_X are on different SNA servers.

CAUSE
=====

SNA Server Admin confuses LUs 54 to 106 on PU_A with LUs 54 to 106 of PU_X
(assuming sequential LU numbering).

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\SNAMANAG.DLL to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 sessions remote update
physical

K # + K $ SNA Server Incorrectly Flips Sense Code Sent by RUI App.
Article ID: Q138855
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

Sense codes from a BIND negative response sent by an RUI application are
sent incorrectly by SNA Server. For example, if an RUI application rejects
a BIND request with a sense code of 0821000E, a SNA trace shows SNA Server
sending a sense code of 2108000E instead.

For LUA applications, the primary sense code is flipped and the secondary
sense code stays in the correct format.

For 3270 Emulator Interface Specification (3270EIS) applications, the
primary sense code stays in the correct format and the secondary sense code
is flipped.

CAUSE
=====

When an RUI application closes a session with a BIND negative response, or
an UNBIND request and attaches sense codes, the primary sense code is
flipped when it is sent out by SNA Server.

RESOLUTION
==========

Microsoft has modified the files, SNASERVR.EXE and WINRUI32.DLL, with the
updated versions that correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Error 4119 when Selecting SNA Server Admin Security Options
Article ID: Q138856
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
  -------------------------------------------------------------------------

SYMPTOMS
========

When you select any of the options under SNA Server Admin Security the
following error message appears:

   Error: 4119
   Cannot find or connect to the primary SNA server to support your
   request.

Note: The three selections on SNA Server Admin Security menu are
Permissions, Auditing, and Owner.

CAUSE
=====

This error occurs if SNA Server is installed on a Windows NT Server that
has a computer name containing 15 characters.

When shared memory is being initialized, the GetComputerName() application
programming interface (API) call tries to null-terminate the computer name
string it writes to the shared memory Cfgbox field. This field is 15 bytes
long, as it should be, but that is one byte too short to hold the 15-
character computer name plus the null character. Therefore, the API
GetComputerName() returns without writing the string at all, leaving the
field full of zeroes.

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\SNABASE.EXE to correct this
problem.

To work around this problem, install SNA Server on a NT Server with a
computername shorter than 15-characters.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.10

K # + K $ TN3270 User Session Is Lost Unexpectedly
Article ID: Q138858
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you use a TN3270 client program through the SNA Server 2.11 TN3270
Server service:

 - A TN3270 user session may be lost unexpectedly.

 - A TN3270 file transfer upload request may appear to be hung, though
   the TN3270 display session may have been reset to the initial host
   signon screen.

 - A TN3270 client emulator may fail to get a session through the
   TN3270 server.

CAUSE
=====

The TN3270 server incorrectly requests definite response during a chain,
even though exception response was requested by the TN3270 client
application. The TN3270 server then receives the following error from the
SNA Server LUA API interface:

   prim_rc=0x1400 (LUA_UNSUCCESSFUL)
   sec_rc=0x00000740 (LUA_DEFINITE_RSP_NOT_ALLOWED)

This causes the session to be reset.

RESOLUTION
==========

To correct this problem, install the fix mentioned below. When exception
response protocol is being used, the TN3270 server now properly sets the
Definite Response indicator only when the End Chain (EC) is set.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kb3rdparty kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna hang freeze
team.

K # + K $ SNA Server Events 94 and 592 Fill Up Application Log
Article ID: Q138860
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When an APPC transaction program (TP) issues a RECEIVE_ALLOCATE which times
out (due to the APPC TP's Timeout value expiring), the Windows NT
application log fills up with the following SNA Server events:

   Event 94:  APPC remote conversation start failed

   Event 592: Receive Allocate has timed out

CAUSE
=====

This problem occurs when you run an APPC TP for a long time and the APPC TP
is designed to periodically re-issue a RECEIVE_ALLOCATE call even though no
incoming conversation startup request arrives for the TP.

SNA Server always logs these events, regardless of what default audit log
level you configure in the Logs dialog box that appears in SNA Server Admin
when you choose Logs from the Options menu.

RESOLUTION
==========

To resolve this problem you may obtain an update from Microsoft or work
around the problem as described below.

Update
------

Obtain the update to SNA Server 2.11 which reduces the audit log level of
event 94 and event 582. To prevent these events from logging, you must set
the default audit log level to Significant System Events in the Logs dialog
box by choosing Logs from the Options menu in SNA Admin.

NOTE: When SNA Server is installed, the default audit log level is already
set for Significant System Events.These events are still logged if the SNA
Server logging level is set for General Information Messages or Detailed
Problem Analysis.

Workaround
----------

To work around this problem and prevent the events from being logged,
increase the Timeout parameter of the TP within the registry. The Timeout
parameter determines the time that a RECEIVE_ALLOCATE waits for an incoming
attach message before returning an error. For manually started invokable
TPs, the Timeout parameter is configured in the registry under the
HKEY_LOCAL_MACHINE subtree under the following subkey:

   SYSTEM/CurrentControlSet/Services/SnaBase/
                                    Parameters/TPs/<tpname>/Parameters

where <tpname> is the name of the transaction program.

   Value Name: Timeout
   Data Type:  REG_DWORD
   Value:      <time in milliseconds>

If there is no entry configured, the timeout defaults to infinite, so the
RECEIVE_ALLOCATE never times out and Event 94 and 592 do not occur.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Server 2.11 CD missing Rally-compatible PC Support API
Article ID: Q138861
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server 2.11 readme file includes the following section, though
the alternate DLL files mentioned are not included on the 2.11 product CD:

   C.4. EHNAPPC.DLL Compatibility with Attachmate RALLY! and PC Support

   IBM PC Support and Attachmate RALLY! are examples of applications that
   depend on the static ordinal numbering of entry points in EHNAPPC.DLL.
   Various vendors' implementations of EHNAPPC.DLL differ in this static
   numbering, and many applications use dynamic linking by entry point name
   to avoid this problem.

   The version installed by default with the SNA Client is compatible
   with IBM CA/400. However, this version is not compatible with RALLY!,
   and will cause this application to fail via general protection failure
   or a pop-up message with the text "Assertion failed." SNA Server
   provides alternate versions of EHNAPPC.DLL and EHNRTRW.DLL which are
   compatible with the NetSoft EHNAPPC.DLL, for use with these
   applications.

   The alternate DLLs are found in the CD-ROM directory
   \CLIENTS\WIN3X\EHNNS\ and must be copied into the Windows system
   directory if you encounter this error.

CAUSE
=====

The alternate DLL files were inadvertently left off the SNA Server 2.11 CD.

RESOLUTION
==========

The alternate DLL files can be found in Rally.zip, located on the following
electronic locations:

 - Lib #2 of the MSSNA CompuServe.

 - FTP.MICROSOFT.COM, in \bussys\winnt\sna-public\rally.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kb3rdparty kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna

K # + K $ SNA Server 3270 Emulator Session Drops With Event ID 21
Article ID: Q138862
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you use the SNA Server 3270 emulator connected to a host application,
the 3270 emulator session may reset and Event 21 appears in the application
event log in Event Viewer. This is explained as:

   (1123) Negative Response Sent on Connection <value> (SENSE=081B0000).

NOTE: The 081B0000 sense code explains: "Receiver in transmit mode: A race
condition exists: a normal-fow request was received while the half-duplex
contention state was not receive, or while resources (such as buffers)
necessary for handling normal-flow data were unavailable."

CAUSE
=====

When the 3270 emulator receives an SNA Status Control (BID) request from
the host after you start typing, the 3270 applet accepts the BID. However,
the 3270 emulator may later reject the data from the host in the following
RU with the Begin Bracket Indicator (BBI) flag set. This causes the host
to drop the session.

RESOLUTION
==========

To correct this problem, apply the fix mentioned below.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 win3270

K # + K $ SNA Server Setup Always Adds COMNETMN to Registry in Error
Article ID: Q138863
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you install SNA Server 2.11, SNA Server Setup incorrectly adds a
second COMNETMN entry to the registry even though the existing entry is the
only entry necessary for SNA Server link services to send link alerts to
Netview, provided a Netview connection is configured in SNA Server Admin.

The second COMNETMN entry is added to the Windows NT registry under the
subtree HKEY_LOCAL_MACHINE under the following subkey:

 SYSTEM/CurrentControlSet/Services/LanmanServer/Parameters/NullSessionPipes

CAUSE
=====

SNA Server Setup fails to check if the COMNETMN pipe name is already
specified in the registry.

RESOLUTION
==========

Obtain the update to SNA Server Setup mentioned below.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server 2.11 Admin shows Inactive Status In Error
Article ID: Q138864
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When viewing the status of an SNA Server connection or LUs using the SNA
Server 2.11 Admin program, some connections or LUs may appear Inactive,
even though they are actually Available, or in use. Also, the status of a
connection or LUs may take several minutes before the correct status
appears in Admin.

These problems tends to occur when you view an SNA Server that is
configured with a large number of connections or 3270 LUs.

CAUSE
=====

The Admin program internal buffer used to receives SNA Server status
updates is being overrun. If an SNA Server is configured with a large
number of connections and LUs off these connections, any status change
causing a large number of update messages to flow to the Admin program can
lead to this problem.

RESOLUTION
==========

An update to the SNA Server Admin program increases an internal receive
buffer queue from 4K to 8K. If an incorrect Inactive status still occurs,
this internal buffer queue can be increased by creating and setting the
ManageQueueSize registry value under the HKEY_CURRENT_USER subtree under
the following subkey:

   \Software\Microsoft\SNAServer\CurrentVersion \SnaAdmin

Value Name: ManageQueueSize
Data Type:  REG_DWORD
Data:       <number>

If this entry is not specified then it defaults to 8. Setting this value to
16 (decimal) will result in 16 * 1024 * 16 bytes ( 256KB ) being allocated.

Microsoft has updated the file <snaroot>\SYSTEM\SNAADMIN.EXE to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv  ntdomain
Additional reference words: 2.11 prodsna

K # + K $ SNA Server Windows 95 Client 5250 Applet Print Screen Fails
Article ID: Q138882
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you try to print from the SNA Server Windows 95 client 5250 Applet,
printing fails to produce any printed output even though it appears to
process the Print command successfully.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\WIN5250.EXE
   <snaroot>\SYSTEM\SNASRV.EXE

NOTE: Install these files on the SNA Server Windows 95 client.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbprint kbbug2.10 kbbug2.11
KBSubcategory: ntprint
Additional reference words: prodsna 2.10 2.11 screen prtscrn win95

K # + K $ SNA Server Event 38, Qualifier 0004 and 0005 Not Documented
Article ID: Q139113
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
------------------------------------------------------------------------

SUMMARY
=======

The SNA Server Reference Guide documents the "qualifier" codes that are
used when SNA Server logs Event 38 in the Windows NT application event log.
However, qualifier 0004 and 0005 are not documented in the Reference Guide,
and the information that appears in the event log is limited.

Microsoft has updated the code that contains the event log text to correct
this problem.

MORE INFORMATION
================

The following information describes the conditions under which Event 38 are
logged, including a more complete description of each possible qualifier
code.

Event 38: APPC session deactivated abnormally

Qualifier:

0002 = The session was deactivated because of a temporary (retry) error,
       and may be retried.

       CAUSE: This can occur when the SNA Server connection to the remote
       system has been lost.

       ACTION: Look for an Event 23 error and check it's qualifier code.
       The SNA Server Reference Guide lists the possible qualifier codes
       and likely causes. For an 802.2 link, qualifier AE and AF indicate
       timeout (or possible media or bridge/router problems) on your LAN
       and will require a LAN trace to diagnose, along with your SNA Server
       configuration file. Pass this information to Microsoft support
       personnel.

0003 = The session was deactivated because of a permanent (no retry)
       error, such as a parameter mismatch. Contact the administrator of
       the partner LUs system to determine which parameters are mismatched.

       CAUSE: A configuration mismatch exists between SNA Server and the
       remote system, or the remote system's session has been reset while
       the SNA Server's conversation remained active.

       ACTION: Capture an SNA Server data link control (DLC) and LU6.2
       message trace of the problem. Pass these traces along with your
       SNA Server configuration file and your Windows NT application event
       log to Microsoft support personnel.

0004 = SNA Server unbound the session due to a protocol violation by the
       partner LU.

       CAUSE: SNA Server detected a protocol violation from the remote
       system on the session.

       ACTION: Capture an SNA Server data link control (DLC) and LU6.2
       message trace of the problem and provide to Microsoft support
       personnel.

0005 = SNA Server sent an UNBIND(Cleanup) message on this session to
       the remote system in order to clean up the session.

       CAUSE: This can be caused by (1) the 5250 emulator or APPC/CPIC
       program was ended by the user while in the middle of a conversation,
       or (2) the SNA Server client machine (where the 5250 emulator or
       APPC/CPIC program is running) has lost it's network session to the
       SNA Server.

       ACTION: If a 5250 user is losing their emulation session
       unexpectedly (due to the client's network session being lost to the
       SNA Server), capture SNA Server client internal trace, LU6.2 message
       trace and APPC API trace of the problem, along with a matching
       sniffer or network monitor trace showing the lost network session
       and provide to Microsoft support personnel.

      To enable SNA client internal tracing, please see the following
      article in the Microsoft Knowledge Base:

         ARTICLE-ID: Q123256
         TITLE     : Enabling SNA Server Windows 3.x Client Traces

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna 3.5 3.51

K # + K $ Windows 95 SnaBase Uses Taskbar Even When Not Shown
Article ID: Q139125
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you configure the SnaBase process included with the SNA Server Windows
95 client to use the taskbar, Windows 95 moves all other taskbar icons to
the left if the taskbar is full.

CAUSE
=====

The SNA Server Windows 95 SnaBase process is not properly handling its task
bar icon when it is configured to be hidden.

RESOLUTION
==========

Microsoft has updated the SnaBase service to hide itself and never add
itself to the task bar.

This update also fixes other small user interface (UI) related bugs:

 - The default menu option is now highlighted (only if no icon is on the
   task bar).

 - The configuration dialog box is now displayed close to the current
   cursor location instead of the bottom right corner .

 - The SnaBase makes sure that the task bar does not block any part of the
   configuration dialog box.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 win95x 95

K # + K $ Memory Leak in TN3270 Server if RU Sizes Exceed TN3270 Defaults
Article ID: Q139212
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When the TN3270 server runs for many days or weeks, server performance
becomes sluggish and Windows NT eventually runs out of virtual memory.
Also, Windows NT performance monitor shows paged pool bytes to be steadily
increasing for the TN3SERVR process.

CAUSE
=====

The TN3270 server initially allocates inbound and outbound buffers when
a TN3270 client connects to the server, using the inbound and outbound
"Default RU sizes" configured in the TN3270 Admin Options dialog.

However, if the TN3270 client's BIND request negotiates to larger RU
sizes than these defaults, the TN3270 server allocates new inbound and
outbound buffers though never frees the previously acquired buffers.

RESOLUTION
==========

To workaround this problem, increase the Inbound and/or Outbound default
RU sizes within the TN3270 Server Admin Options dialog to accommodate the
largest RU sizes that will be requested by the TN3270 client users.

To correct this problem, install the update to the SNA Server 2.11 TN3270
service mentioned below. Microsoft has updated the file
<ntroot>\TN3SERVR.EXE to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 3.50 3.51

K # + K $ Windows NT LUA Application Hangs After 32767 SLI_SEND Commands
Article ID: Q139329
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run an LUA/SLI application on Windows NT, the application stops
responding (hangs) after issuing 32767 SLI_SEND commands. The next SLI_SEND
command is never sent to the Host.

CAUSE
=====

The SLI_SEND hangs because an internal counter in the RUI library is being
incremented for each send, but never being decremented. Because the counter
is a 2 byte integer, it is wrapping to zero after 32,767 sends.

If the SNA Server RUI library and the server are receiving large inbound
RUs from the host, then the RUI library never decrements its internal send
credit. This can cause two possible errors:

 - If the SNA Server does return a credit message after receiving data from
   the RUI library, eventually the RUI library's send credit is incremented
   so much that it becomes zero, causing the RUI library to stop sending
   data because it thinks it has run out of credit.

 - If the RUI application is pumping data to the node (for example,
   transferring a file to the host), then it floods the node, because the
   RUI library always believes that it has enough credit.

RESOLUTION
==========

Microsoft has updated the files, WINRUI.DLL ,for 16-bit clients, and
WINRUI32.DLL, for 32-bit clients, and ACSRUI.DLL for OS/2 clients to
correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 winrui credit sli_send

K # + K $ WINMGT.H Problems with Win32 Structure Packing
Article ID: Q139355
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When building Win32 applications which use the SNA Server APPC Management
Verb functions (DISPLAY and CNOS), the verb control block passed to the SNA
Server interface does not have the correct non-packed structure.

CAUSE
=====

The WINMGT.H file is missing the proper packing statements.

RESOLUTION
==========

To resolve this problem, add these lines to the WINMGT.H include file.

At the beginning of these header files, these statements should be added:

   #ifdef WIN32

   #pragma pack(4)

   #endif

At the end of these header files, these statements should be added:

   #ifdef WIN32

   #pragma pack()

   #endif

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ TN3270 Server Service Fails to Start Automatically
Article ID: Q139356
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When configuring the TN3270 Server service for automatic startup (within
the Services application in Control Panel), the TN3270 service
intermittently fails to start when Windows NT rebooted.

CAUSE
=====

The TN3270 Server service requires that the SnaBase service has already
been started. However, the TN3270 Setup program does not indicate that
SnaBase is a dependent service within the TN3270 service entry in the
Windows NT registry.

While the SnaBase service is dynamically started if an application attempts
to use the SNA API client interfaces (such as, when TN3270 is started),
dynamic startup may not succeed in all cases when Windows NT is rebooted.

RESOLUTION
==========

To resolve this problem, run Registry Editor (REGEDT32.EXE).

WARNING: Using the Registry Editor incorrectly can cause serious, system-
wide problems that may require you to reinstall Windows NT to correct them.
Microsoft cannot guarantee that any problems resulting from the use of the
Registry Editor can be solved. Use this tool at your own risk.

From the HKEY_LOCAL_MACHINE subtree, go to the following key:

   /SYSTEM/CurrentControlSet/Services/TN3270

Add the following entry to the TN3270 Server registry key:

   DependOnService: REG_MULTI_SZ:  Tcpip
                                   SnaBase

NOTE: This problem is fixed in an update to the TN3270 Server SETUP.INF
file which automatically adds the above entry.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork  kbsetup kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server Win3x Banyan Client Displays Incorrect Username
Article ID: Q139377
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you use a username of 17 or more characters in the SNA Server Win3.x
Banyan logon dialog box, the dialog box truncates the actual username to 16
characters and then appends the domain name to the end. This causes the
client to fail with error 546. The user can correct the username once the
dialog box appears.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   LMCLI.DLL
   IPCLI.DLL
   NWCLI.DLL
   BVCLI.DLL
   WDMOD.DLL
   WLOGTR.DLL
   WNAP.EXE

The fix increases the username field to 32 characters.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server Error: Cannot Load Lucida Typewriter Font
Article ID: Q139379
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you start the SNA Server Windows NT 3270 applet, the following message
appears:

   Cannot load lucida typewriter font. Please ensure that ltype.ttf is
   in the windows system directory.

CAUSE
=====

Snafiles.inf does not tell setup to copy Ltype.ttf to the <ntroot>\system32
directory. This occurs only when you select only the 3270 emulator in SNA
Server Setup dialog box: Optional Components. If the defaults are accepted
by the user, Ltype.ttf gets copied appropriately.

RESOLUTION
==========

Microsoft has updated the file SNAFILES.INF to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Downstream Connection Should Default to Incoming Calls
Article ID: Q139423
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you configure a Downstream (DSPU) connection in SNA Server Admin, the
default Allowed Directions value is Outgoing Calls. However, most users
require that the Allowed Directions be set to Incoming Calls, so that the
downstream PU can initiate the connection.

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\SNAADMIN.EXE to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 x25

K # + K $ VB CPIC Application Returns CM_PRODUCT_SPECIFIC_ERROR (20)
Article ID: Q139501
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run identical C and Visual Basic (VB) CPIC applications, the C
application works correctly but the VB application fails on cmalloc() with
the following error:

   return code 20: cm_product_specific_error

CAUSE
=====

The SNA Server Windows 3.x client software incorrectly parses the CPIC
application program name, so its associated transaction program entries in
the WIN.INI file (such as the LocalLU parameter) are not found.

For example, if your application name is WIN-UP.EXE, under C it is known as
WIN-UP. The VB application sees this as WIN-UP.EXE. If you are not pooling
Local LUs as per Q132720 (SNA Server CPIC Allocate Error 20) the above
error appears, even if you have defined the following in the WIN.INI file
of the client computer:

   [WIN_UP]
   APPCLLU=<LOCALLU>

RESOLUTION
==========

To correct this problem:

 - Contact Microsoft Product Support for an update to SNA Server 2.11 and
   WINCPIC.DLL library.

   -OR-

 - Enable pooling. For additional information, please see the following
   article(s) in the Microsoft Knowledge Base:

      ARTICLE-ID: Q132720
      TITLE     : SNA Server CPIC Allocate Error 20
                  (CM_PRODUCT_SPECIFIC_ERROR)

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbprg
KBSubcategory: ntnetserv ntdistrib
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51 wincpic
VB LU prodsna

K # + K $ SNA Server Twinax Connection to IBM 5494 Traps with 0x00000050
Article ID: Q139507
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

After you stop an SNA Server that is connected through Twinax to an IBM
5494 or 5394 Controller (that is connected to an AS/400) and then restart
the server, the server fails with the following STOP message:

   STOP:0x00000050

CAUSE
=====

The SNA Server Twinax driver support is not handling the startup sequence
properly when connecting through an IBM 5394 or 5494, which differs
slightly from the native startup to an AS/400.

When the SNA Server Twinax link service starts, a Memory Descriptor List
(MDL) entry that is passed from User Mode to Kernel Mode is corrupt, hence
the bugcheck is called displaying the STOP:0x00000050.

RESOLUTION
==========

When you stop the SNA Server service, reboot the server before restarting
the service.

Microsoft has updated the following files to correct this problem:

   IBMTDLC.SYS
   ANDWTDLC.SYS
   SNATDLC.DLL.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbsetup kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna

K # + K $ RUI Application Does Not See STSN.REQ
Article ID: Q139509
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When you run an RUI application, during a RQR-CLEAR-STSN-UNBIND processing,
SNA Server intercepts and responds to the STSN.REQ without application
intervention. The RUI application does not see the STSN.REQ.

CAUSE
=====

A CLEAR request received immediately before the STSN causes the CS1APLTR
field of the SCB to be reset. However, CS1APLTR field should only be reset
when the session is deactivated.

RESOLUTION
===========

An update to the SNA Server 2.11 file SNASERVR.EXE corrects this problem.

For more information on definitions of RQR, CLEAR, STSN, and UNBIND, see
the RU Chapter of the IBM SNA Formats Guide.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ Enhanced Error Description for Message 631
Article ID: Q139674
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOM
=======

SNA Server may log the following error if an internal client-server
communication error is detected:

   Message 631
   Invalid message received across the LAN

   EXPLANATION: This is an internal error.

   ACTION: Contact support services at your site.

This message, however, does not indicate the underlying cause of the error.

CAUSE
=====

Message 631 is logged by SNA Server if any of the following error
conditions is detected in a message sent by another SNA Server
component:

 - The mhtype is invalid.
 - The message ID is invalid.
 - The sequence number is wrong.

The mhtype, message ID, and sequence number are included in all messages
passed between SNA Server components (for example, between SNA Server and a
3270 or APPC application, between SNA Server and a link service, and
between SnaBase and an SNA client).

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   SNAEVENT.DLL
   SNALM.DLL
   SNAIP.DLL
   SNANW.DLL
   SNANB.DLL
   SNABV.DLL
   SNAAT.DLL

With this fix applied, Message 631 now logs the following information:

 - The reason for logging the event.
 - Message header information.
 - Expected sequence number.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ APPC Problem Handling AP_PGM Security with NULL Password
Article ID: Q139678
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1 and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

If an APPC application issues an Allocate using AP_PGM conversation
security and specifies a password of NULL (where the remote system is
configured with conversation security and a zero-length password), the
Allocate will fail with a sense code of 080F6051 (AP_SECURITY_NOT_VALID).

CAUSE
=====

Instead of sending a zero length password in the FMH-5 Attach message, the
SNA Server APPC library sends a 1-byte password set to a value of "0x40",
instead of specifying a NULL password as it should.

RESOLUTION
==========

Microsoft has updated the files, WAPPC32.DLL (for Windows NT), WINAPPC.DLL
(for Windows 3.x), and APPC.DLL (for OS/2), to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.00 2.10 2.11 prodsna

K # + K $ RUI Problem Handling RUI_SEND After Sense Data Received
Article ID: Q139785
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If the host application sends sense data to an RUI application while the
RUI application is sending data, the SNA Server RUI library queues the
application data in error and never sends it, causing the RUI application
and the host application to become unsyncronized.

CAUSE
=====

The RUI application gets the sense data indicator (SDI) message and
correctly sends negative response. Because the RUI library is in the middle
of a chain (it has only received Begin Chain - BCI, not End Chain - ECI) it
sets a flag telling it to discard all data messages until it receives one
with ECI set. Unfortunately the server performs the same check. Therefore
the RUI library does not see the ECI flag until it receives the end of the
NEXT chain (the retried one).

RESOLUTION
==========

The RUI application can't work around this problem. The solution is for the
RUI library to detect that a new chain is starting without the purging one
ending, and simply to stop purging at that point.

An update to the SNA Server RUI DLL corrects this problem. Note that with
this update applied, the RUI application will still miss the Middle of
Chain (MC) and EC sequence numbers on the rejected chain.
Microsoft has updated the following files to correct this problem:

   Client Platforms     Updated Files
   -----------------------------------------------------------
   Win32                <snaroot>\system\WINRUI32.DLL
   Windows 3.x          <winroot>\system\WINRUI.DLL
   OS/2                 <snaroot>\ACSRUI.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ Event 582 may occur when running Win 3.x APPC or CPIC App
Article ID: Q139786
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run a 16-bit Windows APPC or CPIC application, the SNA Server
Windows 3.x client software displays the following error message:

   Error 582:
   No name supplied in the parameter list for this component

CAUSE
=====

There are two causes for this problem:

 - If the SNA Server 2.1 Windows 3.x client software is being used, and
   if the SNA client software is unable to  determine the Windows
   application name, or parse for its filename (used for internal
   reasons only), the SNA client will display this error. This problem
   is fixed in the SNA Server 2.11 Windows 3.x  client software.

 - When using the SNA Server 2.11 Windows client software, if the
   filename of the CPIC or APPC application happens to include a "0"
   (zero), the SNA client incorrectly parses the filename (again, used
   for internal reasons only), causing the error to occur.

RESOLUTION
==========

If the SNA Server 2.11 Windows 3.x client software is being used and
the application filename includes a "0", a simple workaround would be
to rename the file so it doesn't include the "0" character

An update to the SNA Server 2.11 Windows 3.x client software corrects
this problem.

The updated Windows 3.x client file is:

   <winroot>\SYSTEM\WDMOD.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ RECEIVE_ALLOCATE Fails With F011 on Windows 95 Clients
Article ID: Q139787
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The following errors were observed on the SNA Server Windows 95 client
software by a 32-bit Windows APPC application after it is autostarted
and then issues a RECEIVE_ALLOCATE as a operator started transaction
program. The RECEIVE_ALLOCATE may fail with the following error:

   primary_rc   = 0xF011     (unexpected DOS error)
   secondary_rc = 0x000002a2 (internal error, unable to add entry
                             to internal SNA client service table)

Also, when you stop the APPC application, the following error may
also occur on the Windows 95 client:

   Page fault in snakrnl.dll

CAUSE
=====

This is caused due to an internal error in the SNA Server Windows 95 client
software.

RESOLUTION
==========

This problem is fixed in an update to the SNA Server Windows 95 client
software.

Microsoft has updated the following files to correct this problem:

   <win95root>\SYSTEM\DMODAPPC.DLL
   <win95root>\SYSTEM\SNAKRNL.DLL
   <win95root>\SYSTEM\SNADMOD.DLL
   <sna95>\SNABASE.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Event 24 Is Logged w/ Severity Levels Information and Warning
Article ID: Q139818
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

An SNA Server Node logs Event 24 and sets the severity level in the system
log to Information. The following is an excerpt from the system log:

   Event ID: 24
   Type: Information

An SNA Server Message Trace, however, logs it as a Warning.

CAUSE
=====

Although Event 24 is an Informational severity, it is stored in NTEVTS.MC
as a Warning.

RESOLUTION
==========

Microsoft has updated SNA Server to correct this problem. Event 24 is now
logged with the Information severity level in the trace file and in the
system log.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50

K # + K $ Win95 Client Setup Puts SnaTcp Registry Key in Wrong Place
Article ID: Q139893
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

During setup of the Win95 SNA Client, Setup adds the SnaTcp key under the
HKEY_LOCAL_MACHINE subtree under the following subkey:

   \Software\Microsoft\SnaBase

However, the TCP/IP .DLL file expects the key under the following subkey:

   \Software\Microsoft\SnaBase\Parameters

RESOLUTION
==========

Install the fix mentioned below.

The SNA Server Windows 95 Setup script has been modified to create the
SnaTcp key under the HKEY_LOCAL_MACHINE subtree under the following subkey:

   \Software\Microsoft\SnaBase\Parameters

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbsetup kbnetwork
KBSubcategory: ntnetserv ntconfig
Additional reference words: prodsna 2.00 2.10 2.11 win95 registry

K # + K $ APPC/5250 Hot Backup Fails if Configured for "On Demand"
Article ID: Q139898
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

A 5250 emulator that loses the AS/400 session due to a connection outage on
a SNA Server gets the following error when you try to reestablish a session
with the AS/400:

   The connection to the AS/400 cannot be activated.

   Primary Return Code = 0003
   Secondary Return Code = 00000004

CAUSE
=====

When SNA Server is configured to use a default Local APPC LU, the hot
backup function for APPC/5250 does not give a Remote LU on a disabled
connection a lower priority than a Remote LU on an Inactive connection
which causes hot backup to fail. If only one of the connections is "Active"
and it fails, the other "On Demand" connections still have a lower priority
than the previously Active connection that has since failed. Since this
failed connection still has the higher priority, none of the On Demand
connections are activated. Therefore, hot backup fails and the 5250
emulator reports the error above.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   Source files affected:

      \DCL\S1SRC\SLPRCHLU.C

   Binaries affected:

      <snaroot>\SYSTEM\SNASERVR.EXE
      <snaroot>\SYSTEM\TRCSERVR.EXE

To work around this problem, SNA Servers that provide hot backup for
APPC/5250 sessions can have their AS/400 connections configured for "On
Server Startup" activation.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

MORE INFORMATION
================

If there are two or more SNA Servers in a domain that are configured to
provide Hot Backup for APPC/5250 sessions and those SNA Servers have
connections to an AS/400 that have a status of On Demand when viewed in SNA
Server Admin, the first 5250 emulator to request a session with the AS/400
forces one of these On Demand connections to become Active.

Subsequent 5250 sessions now use this Active connection to gain access to
the AS/400. If this Active connection fails, 5250 users that attempt to
reconnect to the AS/400 fail with the error described in the symptom
section.

If more than one of the SNA Servers in the domain have an Active connection
to the AS/400, 5250 users are able to reconnect to the AS/400 even if the
connection on the SNA Server that they were originally communicating
through fails.

For additional information on how to configure SNA Servers for hot backup
and load balancing, please see the following article in the Microsoft
Knowledge Base:

   ARTICLE-ID: Q128244
   TITLE     : SNA Server Load Balancing and Hot Backup

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ TN3270 Server Can Incorrectly Terminate a Session
Article ID: Q139978
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

There are two possible symptoms:

 - The TN3270 Server logs an error 309 and terminates the session.

   -or-

 - The TN3270 Server encounters an application exception.

CAUSE
=====

Occasionally, the TN3270 Server can process an RUI_READ completion before
the verb has actually completed.

The RUI event completion code in the TN3270 Server leaves open timing
windows where either of these two events might happen:

 - If an RUI_READ and RUI_WRITE are outstanding and the RUI_READ completes,
   the TN3270 Server might act as if the RUI_WRITE has completed.

   -or-

 - If an RUI_READ and RUI_WRITE are outstanding and the RUI_WRITE
   completes, the TN3270 Server might act as if the RUI_READ has completed.

In either case, the TN3270 Server can examine the RUI verb control block at
the same time the RUI library is filling in the verb control block.

RESOLUTION
==========

Microsoft has updated the file to correct this problem.

   EXE\WIN32\TN3SERVR.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.11
KBSubCategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.11

K # + K $ CPI-C cmecsu() Call Always Returns pLengthUserID=1
Article ID: Q140037
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

If a CPI-C application calls the following APIs:

   cmscsu()    Set_Conversation_Security_User_ID
   cmecsu() Extract_Conversation_Security_User_ID

the returned length on the extract call is always set to 1. It should
return the value that was passed through:

   cmscsu(pConversationID, pUserID, pLengthUserID)

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   Client Platforms       Updated Files
   -----------------------------------------------------------

   Windows NT clients     <SNAroot>\system\WCPIC32.DLL
   Windows 95 clients     <WIN95root>\system\WCPIC32.DLL
   Windows 3.x clients    <WIN3Xroot>\system\WINCPIC.DLL
   OS/2 clients           <SNAroot>\system\CPIC.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubCategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ DEMO SDLC Link Service Setup Script Removes Wrong Link Service
Article ID: Q140038
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

When you remove an SNA Server 2.11 DEMO SDLC Link Service using SNA Server
Setup, the DEMO SDLC Link Service setup script removes the wrong link
service.

After you select a DEMO SDLC Link Service in the Link Service Configuration
during SNA Server Setup and you click the Remove button, the wrong link
service is removed although the Link Services Installed listbox display is
correct.

CAUSE
=====

After adding DEMO SDLC Link Services during SNA Server Setup, if the number
of link services in the Link Services Installed listbox exceeds 10 items,
SNA Server incorrectly maps the displayed link services to the underlying
link service.

RESOLUTION
==========

The DEMO SDLC Link Service setup script (SNACLASP.INF) has been modified to
remove the correct link service.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubCategory: ntnetserv
Additional reference words: prodsna

K # + K $ 5250 Applet Causes GP Fault when Entering AS/400 Host Editor
Article ID: Q140266
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you attempt to work with AS/400 electronic mail or documents, the SNA
Server 2.1 and 2.11 5250 applets can encounter a General Protection Fault
(GPF) or application exception error. This problem occurs with the Windows
3.x and Windows NT 5250 applets on SNA Server 2.1, and the Windows NT 5250
applet on SNA Server 2.11.

CAUSE
=====

The problem is caused by the AS/400 interfacing with the applet as if it is
a host terminal. Therefore, when you try to work with mail or documents,
the AS/400 tries to use the Host Editor (as opposed to PC Text Assist or
the Adapted word processor). The 5250 applet does not support this mode.

RESOLUTION
==========

An update to the 5250 applet is available which prevents the application
exception from occurring. Instead, a blank screen appears now at which
point you must press the F3-key to return to the previous AS/400 screen.
This causes an internal error on the document you are trying to access.

To avoid this problem, you need to configure your AS/400 OfficeVision
environment to default to the Adapted word processor instead of PC Text
Assist. In addition to this change, an update to the 5250 applet is
necessary, since the AS/400 still tries to use the Host editor, but if that
fails, then drops to Adapted.

Microsoft has updated the following files to correct this problem:

   Windows NT:  <snaroot>\SYSTEM\WIN5250.EXE
                <snaroot>\SYSTEM\SNASRV.EXE
   Windows 3.x: <sna.win>\WIN5250.EXE
                <sna.win>\SNASRV.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11 rumba

K # + K $ SNA Server Internal Traces Do Not Log SNA Server Version
Article ID: Q140382
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server version number is not logged in SNA Server internal traces
when they are enabled for diagnostic purposes.

This symptom occurs whether the internal traces are enabled on the SNA
Server computer or SNA Server client computers.

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\SNATRC.DLL to improve SNA
Server tracing. SNA Server now queries the SNA Server version information
from certain SNA Server files. When the internal trace files are created or
wrapped, the file names and their versions are written as part of the file
header. The following are the SNA Server files for which version
information is obtained:

   SNABASE.EXE
   SNASERVR.EXE
   SNADMOD.DLL
   SNALINK.DLL
   SNALINK.EXE
   SNACFG.DLL
   SNAMANAG.DLL
   SNAADMIN.EXE

Note: The update only applies to the SNA Server server and the 32-bit SNA
Server clients (Windows NT & Windows 95). The update does not apply to 16-
bit (Windows 3.x) clients.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51 snatrace
.END:

K # + K $ SNA Server EHNAPPC Security fails using 10 Character User ID
Article ID: Q140423
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you use SNA Server client and IBM CA/400 (V3R1), you are prompted to
enter a User ID and password. If your user ID has nine or less characters,
you are able to log on. If your user ID has ten characters, the following
error appears:

   SNA Server EHNAPPC Security
   7003 Cannot assign a network drive

If you choose OK, the user ID and password prompt appears again. This time
only the first nine characters of the user ID appear in the User ID box.

CAUSE
=====

The SNA Server Win 3.x EHNAPPC interface does not properly
handle AS/400 signon if the AS/400 userid is ten characters in
length. The tenth character is truncated.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem (on
Windows 3.1x clients):

   <winroot>\SYSTEM\EHNAPPC.DLL
   <winroot>\SYSTEM\EHNRTRW.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna

K # + K $ SNA Server Event ID 18 Reports Incorrect Sense Data
Article ID: Q140524
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The Sense Data that is logged as part of the Event ID 18 description in the
Windows NT application log is not logged accurately.

This symptom occurs when SNA Server receives a BIND Negative Response or an
UNBIND Request for an APPC session and logs Event ID 18 in the Windows NT
application log.

However, SNA Server traces do show the correct Sense Data for the error
that is causing Event ID 18 to be logged.

Note: Chapter 9 of the IBM SNA Formats Guide (GA27-3136) details IBM Sense
Codes.

CAUSE
=====

Event ID 18 is logging incorrect Sense Data because of the following
two problems:

 - The secondary sense data (bytes 2 & 3) are being logged to a random
   value.
.
 - If either the primary or secondary sense data have a value of 8000 or
   greater, it is logged as FFFF8xxx.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNASERVR.EXE
   <snaroot>\SYSTEM\TRCSERVR.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ WinRUICleanup Sets Incorrect Return Code
Article ID: Q140526
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

WinRUICleanup function returns a value of zero, regardless of the success
or failure of the function. As a result, the application is not notified
that it is successfully deregistered.

CAUSE
=====

The WinRUICleanup function incorrectly always returns a value of zero.

RESOLUTION
==========

Microsoft has updated the following files to correct this problem:

   Windows NT:  <snaroot>\SYSTEM\WINRUI32.DLL
   Windows 3.x: <winroot>\SYSTEM\WINRUI.DLL

With this update applied,the WinRUICleanup function returns the correct
value. If the value is not 0, the application is successfully deregistered.
If the value is 0, the application is not deregistered.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ TN3270 Hang if Host Sends Maximum RU Equal to 0 in BIND
Article ID: Q140800
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------
SYMPTOMS
========

A TN3270 display session hangs if the Host sends a BIND RU that specifies
an Inbound Maximum RU size of 0 (indicating that no maximum RU size applies
on the session to the Host). 

This symptom occurs sporadically.

CAUSE
=====

There are two causes to this problem:

1. The TN3270 Server incorrectly interprets 0 as the maximum RU size which
   prevents it from sending any data to the host. When the host establishes
   a session and specifies the maximum inbound RU size as "no maximum", the
   TN3270 Server treats this as an RU size of zero bytes. This has the
   effect that it ignores all the data it receives from a TN3270
   client.

2. A TN3270 client may also misinterpret this byte and would then be
   unable to send any response to the TN3270 Server. The WRQ emulator is
   one such emulator.

RESOLUTION
==========

There is a fix for cause number one and two:

1. The fix for cause number 1 ensures that the TN3270 sends inbound data.
   The data is sent in Request Units (RUs) up to the "Default Inbound RU

   Size" specified in the "Options" dialog of TN3270 Admin.

2. To work around the second cause, the client problem, the TN3270 Server
   has a registry entry that allows a 0 RU size in the BIND image
   transmitted to the client to be overwritten by the "Default Inbound RU
   Size" specified in the "Options" dialog of TN3270 Admin. You can find
   the registry entry under the subtree HKEY_LOCAL_MACHINE under the
   subkey:

      CurrentControlSet\Services\TN3270\Parameters

   The registry value is as follows:

      Value Name: ReplaceRUSize
      Data Type:  REG_EXPAND_SZ

   If this entry is set to "ON" then the value for the inbound RU size in
   the BIND Image sent to the TN3270 client is set to the default inbound
   RU size as configured for the TN3270 Server, if the host has specified
   no maximum.

   Set this registry entry only if you experience this problem.

Microsoft has updated the following files to correct this problem:

 - <TN3270Root>\TN3SERVR.EXE
 - <TN3270Root>\TN3SERVR.DBG

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv

Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ TN3270 Clients Cannot Connect with a Lower-Case LU Name
Article ID: Q140814
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When a user at a TN3270 emulator requests to connect to SNA Server TN3270
Server using a specific LU and gives the lower-case version of the LU name,
the emulator fails to connect.

CAUSE
=====

The SNA Server LUA library is case-sensitive, and therefore does not accept
lower-case LU names.

RESOLUTION
==========

Microsoft corrected this problem. The fix causes all incoming names to be
converted to upper case.

Microsoft has updated the following files to correct this problem:

   <TN3270>\I386\SYMBOLS\EXE\TN3SERVR.DBG
   <TN3270>\I386\ TN3SERVR.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ Emulator Disconnected after FMI Error Code x‘0050‘
Article ID: Q140815
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
----------------------------------------------------------------------

SYMPTOMS
========

Wall Data 4.1 3270 emulator disconnects if you press the the PF1 function
key.

CAUSE
=====

The Wall Data 4.1 3270 emulator sends FMI STATUS (ACK) messages in response
to RQE data with random values in the message key and sequence number
fields.

Most of the time the SNA Server service ignores these messages. However, if
the message key is what the SNA Server service is expecting but the
sequence number is incorrect, then the SNA Server service closes the PLU-
SLU connection with the emulator.

RESOLUTION
==========

Microsoft has corrected this problem. The fix causes EventID 61 to be
logged the first time that the node receives an invalid STATUS ACK from an
emulator. Further, if a registry entry is set it does not close the PLU-SLU
connection on receiving one of the illegal messages which have the correct
message key.

This registry entry is located under the HKEY_LOCAL_MACHINE subtree, under
the following subkey:

   SYSTEM\CurrentControlSet\Services\SnaServr\  Parameters

The entry is:

   Value Name: BADSEQNO
   Data Type:  REG_SZ

This registry entry is considered turned on if it is set to any value.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNASERVR.EXE
   <snaroot>\SYSTEM\TRCSERVR.EXE
   <snaroot>\SYSTEM\SNAEVENT.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ EHNAPPC Data Stream Header Data Being Passed to TP
Article ID: Q140816
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When using mapped APPC conversations with the Enhanced Router API
(EHNAPPC.DLL), transaction programs (TPs) receive the extra data even
though they should not.

CAUSE
=====

When sending data, the SNA Server EHNAPPC.DLL is passing the extra 4-byte
Basic APPC conversation header into the APPC data stream when using a
MAPPED conversation. However, it should ignore the 4-byte header. The
header consists of:

 - 2 bytes that are reserved for LL field designation.
 - 2 bytes for the length of the data field.

RESOLUTION
==========

Microsoft modified the EHNAPPC.DLL file so that it only passed up the data
to the transaction program, not the 4-byte header.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ AFTP Client Does Not call WinCPICCleanup()
Article ID: Q140817
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

Applications using the SNA Server AFTP API do not close when there are no
more active connections open to it.

CAUSE
=====

The AFPT API library does not call WinCPICCleanup() when all the
applications using it terminate. However, it does call WinCPICStartup()
when an application first calls it.

RESOLUTION
==========

Microsoft has updated the files, AFTP.EXE and AFTPAPI.DLL, to correct this
problem.

The library is now changed to call WinCPICCleanup() when an application
has no more AFTP connections open to it.

A change has also been made to the AFTP client application to prevent it
from opening a new connection every time it closes one.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Setup: Wrong Info in "Select Client/Server Protocols" Dialog
Article ID: Q140820
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

You can only use one client/server protocol to communicate with a SNA
Server from a Windows NT SNA Server Client and the Client Setup erroneously
displays the following "Select Client/Server Protocols" dialog if multiple
protocols are detected on the Windows NT system:

   Several client/server protocols have been detected on this computer.

   SNA Client can work with any or all of them. Please choose the ones you
   want by clicking on their check boxes.

      Microsoft Networking (Named Pipes)
      Novell Netware
      Banyan Vines
      TCP/IP

When you choose Help for this dialog box the following information appears:

              Select Client/Server Protocol

   If Setup detects more than one client/server protocol on your
   computer, you must specify the client/server protocol(s) to use with
   SNA Server.

   To select client/server protocols

      1 In the Select Client/Server Protocols dialog box, select one,
        several, or all of the check boxes:

           Microsoft Networking (Named Pipes)
           Novell NetWare (IPX/SPX) (see Note on SPXII Protocol)
           Banyan VINES (see Note on Banyan Vines )
           TCP/IP (see Note on TCP/IP Protocol)
           (SNA servers only:) AppleTalk

        If the computer you are installing on does not include one or
        several of the client/server protocols, the corresponding check
        boxes are unavailable.

      2 Choose Continue.

        You will be prompted to supply the name of the network domain or
        SNA Server Subdomain.

CAUSE
=====

The Windows NT SNA Server Client Setup program was calling the same
"Client/Server Protocol" information called during SNA Server Setup.

RESOLUTION
==========

The setup scripts for the Windows NT SNA Server Client have been modified
so that the "Client/Server Protocol" dialogs return information specific to
the Windows NT SNA Server Client.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SETUP.INF
   <snaroot>\SNAFILES.INF

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ The CPIC Thunk DLL Does not Support XCECST()/CMECST() Calls
Article ID: Q140821
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The CPIC thunk dll does not support XCECST()/CMECST()
(Extract_Conversation_Security_Type) calls.

CAUSE
=====

The 16-bit CMSCST(), Set_Conversation_Security_Type is calling the 32-bit
CMSCSP(), Set_Conversation_Security_Password.

RESOLUTION
==========

Microsoft has updated the file WCPIC.DLL so that it now calls the
appropriate 16-bit function.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ Winlogon Traps Running Performance Monitor Against SNA Server
Article ID: Q140822
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run Performance Monitor against an SNA Server, Winlogon traps
after several hours of operation. The SNA Server services continue to run.
However, the following symptoms occur:

 - Users are not able to logon locally to the SNA Server.
 - RPC services such as the following do not function:

    - When Performance Monitor gathers details.
    - When you try to view events in the system, security, or application
      logs.

This symptom occurs sporadically.

CAUSE
=====

There is a problem in the way the SNA performance DLL is passing
information to Performance Monitor.

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\SNAPERF.DLL to correct this
problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51 performance
monitor winlogon trap

K # + K $ MS-DOS Client Setup Fails with Error CSU7520
Article ID: Q140823
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

After SNA Server MS-DOS client Setup copies all files to the destination
Workgroup Connections client with NetWare installed, Setup displays the
following error message:

   The following error has occurred: CSU7520: Can't open file %1

This does not happen on a Banyan Vines or Named Pipes client.

CAUSE
=====

Setup is spawning a piece of code that attempts to modify the SYSTEM.INI,
even though there is no SYSTEM.INI present on the client.

RESOLUTION
==========

Microsoft has updated the file <sna_cd_root>\CLIENTS\MSDOS\SETUP.EXE to
correct this problem.

Setup now tries to modify the Workgroup Connection SYSTEM.INI file only if
it is first detected by Setup.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ RUI FI RH Bit Modified by SNA Server
Article ID: Q140824
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

A node should always set the FI bit in the Request Header (RH) of a
response sent by FMI and RUI applications when the original FMD request
also had the FI bit set (even when the application explicitly cleared it).

The SNA Server node uses the RH from the original FMD request to generate
the RH of the response, setting the FI bit in the response if it was set in
the original request.

CAUSE
=====

This is contrary to the SNA Formats, which states that the FI must not be
set on FMD +responses. This fix ensures that the FI bit is cleared before a
response to an FMD request is sent.

RESOLUTION
==========

Microsoft has updated the files, SNASERVR.EXE and TRCSERVR.EXE, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51 FI FMD RH

K # + K $ Node Retries Open(Link) on X.25 Even After Error is Reported
Article ID: Q140825
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions  2.11
-------------------------------------------------------------------------

SYMPTOMS
========

If the SNALink cannot initialize successfully, it responds with an Open
(LINK) Error-Response containing an error code. Upon receiving an
Open(LINK) Error-Response on a link, the node should not continue to retry
connections on that link service. However, in the case of X.25 PVCs
(permanent virtual circuits), and  SDLC  (Synchronous Data Link Control)
leased connections, the node continues to retry.

Sample Trace
------------

   at 17:25:41.31 Open Link Request for Link Service SDL2
   at 17:25:41.40 Open Link Request for Link Service QLLC
   at 17:25:41.40 Open Link Response with Error code 01 for SDL2
   at 17:25:41.53 Open Link Response with Error code 01 for QLLC
   at 17:26:01.84 Open Link Request for Link Service SDL2
                                                    (retried every 20 sec.)

CAUSE
=====

The node fails to deal with leased connections correctly. It compares the
name of the link service against a list that does not exist for leased
connections.

RESOLUTION
==========

The node no longer retries Open(Link)s after any RSPERR on any link type.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K
KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 3.51

K # + K $ TN3270 Server Rejects First Data RU After Host's CLEAR Message
Article ID: Q140826
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server version 2.1, 2.11
----------------------------------------------------------------------

SYMPTOMS
========

A host application, such as TeleView, allows a user at a terminal to make a
connection and then spawn additional sessions on the SNA host. Under normal
conditions, the user may terminate a session with no further incident. In
this case, however, when a user ends even just one session, the rest of the
sessions are terminated. This condition may occur when running the TN3270
Service for Windows NT. The TN3270 Server may also generate the following
error:

   sense data = 081B0000

The IBM Systems Network Architecture (SNA) Formats guide provides the
following information regarding this error:

   081B0000
   Receiver in Transmit Mode:
   A race condition exists: a normal-flow request was received while the
   half-duplex contention state was NOT-RECEIVED, or while resources (such
   as buffers) necessary for handling normal-flow data were unavailable.

Contrary to the explanation given in the IBM SNA Formats guide, a race
condition does not exist in this case. The error is exhibited in the
following diagnostic tools:

From the Application Log:

   Event ID: 309
   INIT failed with LUA_COMM_SUBSYSTEM_NOT_LOADED / LUA_SEC_RC_OK for
   <IP_address> (port <port_number>).

   Event ID: 603
   TN3270 session with client at <IP_address> (port <port_number>) using LU
   <LU_name> terminated abnormally because:
      TN3270 Service Error 505
      SNA API verb INIT failed.
         Failure described as:
         SNA Server has not been started.

   Event ID: 698
   Invalid Destination L-value. Parameter: 0, Message: 0, Valid range
                                                                    <range>

   Event ID: 699
   Invalid message: MsgType 31, MhType 31

   Event  ID: 1955
   RUI_INIT failed for LU, primary_rc=4f0, secondary_rc=0

From an SNA Server API Trace:

   ...
   ... RUI    ---------------------------------------------- 13:50:43.15
   ... RUI    RUI_READ request
   ...
   ... RUI    ---------------------------------------------- 13:50:43.56
   ... RUI    RUI_READ response
   ... RUI    OK - OK
   ...
   ... RUI    ---------------------------------------------- 13:50:43.57
   ... RUI    RUI_WRITE request
   ...
   ... RUI    ---- Data at address 00119CC4 ----
   ... RUI    081B0000                                <....            >
   ... RUI    ---------------------------------------------- 13:50:43.65
   ... RUI    RUI_WRITE response
   ... RUI    OK - OK
   ...
   ... RUI    ---- Data at address 00119CC4 ----
   ... RUI    081B0000                                <....            >
   ...

From a TN3270 Server Trace:

   ...
   >11/27 13:50:43.062 (+ smidgen )  Event=TEV_DataToSNA
    Thread = 0x000000C3  Session = 0x0026B7D0  Socket = 0x0000017C
    VCB address=0x0026B9D8
    verb_length=0x0044  verb=0x0052 (RUI)  opcode=0x8004 (WRITE)
    sid=0x00010006  correlator=0x0026B7D0  post_handle=0x00000198
    prim_rc=LUA_OK  sec_rc=LUA_SEC_RC_OK
    lu_norm    lua_data_length=0x00000004
    TH Only    efi=0  oadi=0  daf=FD  oaf=01  snf=0001
    RH -RSP FMD fi=0   sdi=0  bci=1  eci=1  (Only)
    83 91 80    dr1=1  dr2=0  ri=1   qri=0  pi=1
                bbi=1  ebi=0  cdi=0  csi=0  edi=0  pdi=0
    000000  081b0000                             *....            *
   ...
   >11/27 13:50:43.562 (+ smidgen )  Event=TEV_DataToSNA
    Thread = 0x000000C3  Session = 0x0026B7D0  Socket = 0x0000017C
    VCB address=0x0026B9D8
    verb_length=0x0044  verb=0x0052 (RUI)  opcode=0x8004 (WRITE)
    sid=0x00010006  correlator=0x0026B7D0  post_handle=0x00000198
    prim_rc=LUA_OK  sec_rc=LUA_SEC_RC_OK
    lu_norm    lua_data_length=0x00000004
    TH Only    efi=0  oadi=0  daf=FD  oaf=01  snf=0002
    RH -RSP FMD fi=0   sdi=1  bci=1  eci=1  (Only)
    87 91 20    dr1=1  dr2=0  ri=1   qri=0  pi=1
                bbi=0  ebi=0  cdi=1  csi=0  edi=0  pdi=0
    000000  081b0000                             *....            *
   ...

CAUSE
=====

After receiving a CLEAR message from the SNA host, the TN3270 Server may
reject the first data response unit (RU) from the SNA host. There are two
issues here, both of which have now been fixed:

1. When the TN3270 Server receives a CLEAR message from the SNA host, it
   does not reset its internal state which keeps track of whether the
   TN3270 emulator or the host application has permission to send. This
   causes the TN3270 Server to reject the first data message received from
   the SNA host with a sense data = 081B0000, because the TN3270 Server
   assumes that the TN3270 emulator still has the permission to send. The
   TN3270 Server then rejects the next data message from the host. At this
   point, the host application gives up and terminates the session.

2. When the node receives data from the host application which it believes
   to be out of bracket it passes a message up to a Request Unit Interface
   (RUI) application with the Sense Data Included Indicator (sdi) bit set.
   On receiving this, the RUI application is supposed to send a negative
   response with the sense data which the node passed up to it. The TN3270
   Server, however, was not checking for this bit.

RESOLUTION
==========

Microsoft has updated the files, TN3NTMSG.DLL and TN3SERVR.EXE, to correct
this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ TN3270 Server Incorrectly Formats Mod 5 Terminal LU-SSCP Screens
Article ID: Q140827
 -------------------------------------------------------------------------
 The information in this article applies to:

  - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

Wall Data's Rumba TN3270 session screens are incorrectly formatted when
changing the default terminal type from Mod 3 to Mod 5 at session logon.
This problem does not occur when using a Rumba 3270 session or the SNA
Server 3270 applet.

RESOLUTION
==========

Microsoft has updated the file, TN3SERVR.EXE, to correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ TN3270 Server Does Not Generate a Dr. Watson Log
Article ID: Q140830
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When the TN3270 Server encounters an exception error it does not produce a
Dr. Watson log.

For additional information on Dr. Watson, please see the following article
in the Microsoft Knowledge Base:

   ARTICLE-ID: Q139378
   TITLE     : Debugging SNA Server Application Exceptions on Winnt

CAUSE
=====

The exception handling routine is setting an event that causes another
thread to terminate the process. Since the process is terminated, the
general exception handling procedure that creates the Dr. Watson log is not
called.

RESOLUTION
==========

Microsoft has updated the file <tnroot>\TN3SERVR.EXE to correct this
problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 3.51

K # + K $ Cannot Build APPC Library DTRACS.LIB
Article ID: Q140831
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

DTRACS.LIB fails to build because the module APPC_C.C does not compile for
MS-DOS.

MS-DOS support for Windows APPC applications is provided by linking with
the call-level interface library called DOSACS.LIB. DTRACS.LIB is the
traced version of DOSACS.LIB, used for debugging an MS-DOS APPC transaction
program (TP).

CAUSE
=====

This problem occurs because full internal tracing is turned on.

RESOLUTION
==========

The makefile was updated to decrease the hard coded trace severity for
APPC_C.C.

Microsoft has updated the file <SNA_CD_Root>\SDK\LIB\MSDOS\DTRACS.LIB to
correct this problem.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server Windows 3.x Client Setup Fails without AUTOEXEC.BAT
Article ID: Q140832
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The Windows 3.x SNA Client Setup fails with the following error if an
AUTOEXEC.BAT is not present:

   Setup is unable to detect any network on this computer. Please install a
   network and try Setup again later.

The same error occurs when running Setup on a client that was previously
installed if the AUTOEXEC.BAT has been removed from the system.

Please refer to Knowledge Base Article Q128118 for information on other
causes of this error message.

CAUSE
=====

Setup was treating the non-existence of AUTOEXEC.BAT as an error, and
returning early from the SNAValidate function before attempting to figure
out which network protocols are installed.

While investigating this problem, another problem was discovered.  If
there's no AUTOEXEC.BAT found when Setup starts, Setup tries to create one
while modifying the system files, and writes just one line to the new
AUTOEXEC.BAT:  "PATH C:\SNA.WIN;".

The next time Setup is run, it finds AUTOEXEC.BAT, but on its way out Setup
changes the line to "PATHC:\SNA.WIN;". The next time Setup runs, it doesn't
recognize the path line, so it adds another one like the first time. This
process is repeated each time Setup is executed.

WORKAROUND
==========

To work around this problem, add an AUTOEXEC.BAT to the system where the
client is being installed. The AUTOEXEC.BAT does not need to contain any
specific commands; it just needs to exist on the system.

RESOLUTION
==========

Microsoft has updated the file, WIN16CL.DLL, to correct this problem. The
Windows 3.x SNA Client Setup program now continues on with the SNAValidate
function if the AUTOEXEC.BAT does not exist. In addition, the Setup program
correctly writes the PATH statement.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ APPC Allocation Error Running Multithreaded Random & Bounce TP
Article ID: Q140833
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you run 4 to 5 copies of the Random & Bounce transaction program (TP)
with 8 threads each, the APPC Allocate() verb fails with error:

 - Primary Return Code: 0003: AP_ALLOCATION_ERROR
 - Secondary Return Code: 084C0000: AP_TRANS_PGM_NOT_AVAIL_NO_RETRY

The APPC return codes are logged after about 500,000 APPC verbs are
executed.

This problem was found using test applications and only under very heavy
stress, when invoking a TP over 65000 times, therefore, this symptom rarely
occurs.

CAUSE
=====

When the invoked TP issues the Receive_Allocate() verb and the
Receive_Allocate() verb decrements the semaphore counter, the decrement of
the semaphore counter (WaitForSingleObject())is done only when there are no
pending Allocate()s waiting, instead of every time a Receive_Allocate() is
processed.

Each time a dload (Incoming Allocate ()) is processed by SnaBase a
semaphore counter is increased (ReleaseSemaphore()) by one. After the
semaphore counter has reached 65535, the ReleaseSemaphore() call fails with
the following error:

   Error 289: ERROR_TOO_MANY_POSTS

The SnaBase that processes the incoming Allocate() does not log any errors.
However, the SnaServer who sent the Allocate() request, logs the following
error in the Event Viewer:

   Event ID: 60

   Failed to invoke APPC TP <value> (value), sense data = 084C0000

   EXPLANATION: An attempt to invoke the APPC TP shown has failed.

The most common cause of this error (084c0000) is due to configuration
problems where the invokable TP is not registered properly on an SNA Server
in the domain.

RESOLUTION
===========

The semaphore counter is now decremented every time a Receive_Allocate() is
processed.

Also, the SnaBase that processes the incoming Allocate(), logs a new error:

   Error 703 subcode 1015 - ReleaseSemaphore() failed.

There following six subcodes describe other possible allocate errors:

   1010 - The server who sent the dload message was not found in the local
          service table.
   1011 - The TP to be invoked was not found in the service table.
   1012 - DMOD failed to create a new service table entry for the
          Non-Queued TP.
   1013 - DMOD failed to create a new service table entry for the Queued
          TP.
   1014 - OpenSemaphore() failed.
   1016 - DMOD failed to start the TP (NT service or application).

Microsoft has an update for the following Windows 95 client files only:

   <Win95_root>\SYSTEM\DMODAPPC.DLL
   <Win95_root>\SYSTEM\SNADMOD.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server Admin Lists Wrong Dependent APPC LU as "In Session"
Article ID: Q140835
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

An SNA Server that has a local dependent APPC (LU6.2) session partnered
with multiple remote LUs shows that the wrong LU is "In Session".

This problem occurs sporadically.

CAUSE
=====

When SNA Server receives an unsolicited BIND for a dependent APPC LU, it
does not check the names in the BIND. SNA Server assumes that it is a BIND
for an LU on that LU address. However, if a local dependent APPC LU is
partnered with more than one remote LU, SNA server is in effect choosing at
random which LU it believes the BIND to be from.

RESOLUTION
==========

SNA Server has been modified so that it does examine the LU names in an
unsolicited BIND it receives for dependent APPC LUs.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNASERVR.EXE
   <snaroot>\SYSTEM\TRCSERVR.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ Windows 95 AFTP Client Reports WINAPPC.DLL is Corrupt
Article ID: Q140836
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

After installing the Windows 95 SNA Server client you receive the following
error when running AFTP:

   The c:\sna95\system\winappc.dll file appears to be corrupt.
   Reinstall the file and try again.

This problem occurs sporadically.

CAUSE
=====

There is a Win16-bit version of WINAPPC.DLL present on your Win32-bit
platform (that is, Windows 95 or Windows NT). The AFTP client links to the
16-bit WINAPPC.DLL but expects a 32-bit version of WINAPPC.DLL.

RESOLUTION
==========

AFTP.EXE has been modified so that it now calls WAPPC32.DLL directly.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\AFTP.EXE
   <snaroot>\SYSTEM\AFTPAPI.EXE

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 aftp appc sp1

K # + K $ AS/400 Demo Link Service Fails to Log Events
Article ID: Q140837
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

AS/400 Demo Link Service Transaction Programs (TPs) do not log events in
the Event Viewer's application log.

CAUSE
=====

SNACLASP.INF does not create the registry entry that references the event
DLL for the Demo Link Service.

RESOLUTION
==========

Microsoft has updated the file SNACLASP.INF to correctly modify the
registry.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 SDLC

K # + K $ Disk and Setup Problems with Win16 to Win32 Thunking DLL Files
Article ID: Q140839
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

There are two issues with the Win16 to Win32 thunking DLL files:

 - The \CLIENTS\WINNT\<Processor>\THUNK directory on the SNA Server 2.11
   compact disc misses the critical SNAHLP32.DLL file. This file provides
   all the mapping between the 16-bit and 32-bit interfaces.

   NOTE: The SNA Server 2.11 compact disc includes the Win16 to Win32
   thunking DLLs in both of the following directories:

    - <Processor>\SYSTEM\THUNK
    - \CLIENTS\WINNT\<Processor>\SYSTEM\THUNK

   where <Processor> stands for the I386, ALPHA, MIPS, or PPC processeor
   names that are used depending on what platform you are installing the
   SNA Server or Windows NT client on.

 - When you install a Windows NT client, the \THUNK directory and files are
   not copied to the hard drive even though they should be copied to the
   <snaroot>\SYSTEM\THUNK\ directory.

   NOTE: When you install the SNA Server, the \<Processor>\SYSTEM\THUNK\*.*
   files are copied properly to the server <snaroot>\SYSTEM\THUNK\*.*
   directory.

   NOTE: <Processor> stands for the I386, ALPHA, MIPS, or PPC processeor
   names that are used depending on what platform you are installing the
   SNA Server or Windows NT client on.

RESOLUTION
==========

Microsoft has updated the SNA Server SETUP.EXE file to copy the \THUNK
directory and files to client computer during the Windows NT SNA client
installation.

In addition, SNAHLP32.DLL will be included in the
CLIENTS\WINNT\<Processor>\THUNK directory on the next SNA Server compact
disc.

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ 2 Connections Using Same Link Service and Destination Address
Article ID: Q140840
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When SNA Server has two connections configured to use the same underlying
link service and same Remote Network Address, the remote end deactivates
the first connection as soon as an XID packet to activate the second
connection arrives.

It is true that two link stations cannot use the same source service access
point (SAP) address to the same destination link station. However, SNA
Server should not disrupt an already active connection when another request
arrives for the same Network address (or SAP) for the same link service.

With SNA Server 2.11 the following message appears when attempting to
configure two connections in this way:

"The same Remote Network Address and SAP have already been specified for
this link service in connection <connection name>. To create more than one
connection to the same remote machine, add one of more 802.2/DLC link
services via SNA Server Setup over the same adapter with different local
SAP addresses. This will auto-create additional connections in SNA Server
Admin. Alternatively, if further SAPs are available at the remote machine,
choose a different remote SAP for this connection. OK."

After you choose OK, SNA Server does not force the Administrator to change
the the configuration. Therefore, the above problem results.

RESOLUTION
==========

Microsoft has a fix that does not prevent an Administrator from configuring
two connections for the same remote network address using the same link
service. The 808.2 Link Service now detects the address conflict and
disables the second connection with the following event id:

   Event ID: 205 - "An address pair is already in use."

Note that it also detects the case where the address pair is first "in use"
due to an incoming call as well as an outbound one.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNASERVR.EXE
   <snaroot>\SYSTEM\TRCSERVR.EXE
   <snaroot>\SYSTEM\SNADLC.DLL
   <snaroot>\SYSTEM\SNAEVENT.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11 snatrace

K # + K $ SNA Server Admin "Select Domain" Dialog Box Suspended
Article ID: Q141115
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

The SNA Server Admin "Select Domain" dialog box suspends until a full list
of domains is shown. Anything you enter in the Domain field is not
processed until the browse list of domains is returned.

NOTE: The SNA Server Admin "Select Domain" dialog box allows an
administrator to enter the name of an SNA Server or SNA Server domain to be
administered.

RESOLUTION
==========

Microsoft has updated SNA Server Admin (SNAADMIN.EXE) to include a "Low
Speed Connection" check box that can be used to enable/disable browsing in
the "Select Domain" dialog box. If this check box is unchecked, SNA Server
Admin does not return a browse list of available domains.

Microsoft has updated the following files to correct this problem:

 - <snaroot>\SYSTEM\SNAADMIN.EXE
 - <snaroot>\SNAFILES.INF
 - <snaroot>\SNASFD.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ TN3270 Server Now Supports Client Load Balancing
Article ID: Q101235
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

SYMPTOMS
========

If all the resources are in use on the SNA Server 2.11 TN3270 server the
Hot-Backup feature of some TN3270 emulators does not work.

The Hot-Backup feature, implemented in some TN3270 emulators, allows you to
specify the IP addresses of several TN3270 Servers for the emulator to
attempt to connect to. If access is denied it attempts to connect to the
next IP address specified.

CAUSE
=====

The SNA Server TN3270 Server always listens on a socket, allowing an
emulator to connect (that is, it fails to deny the socket connection), even
if all of the configured resources on the server are in use causing it not
be able to service that connection. When the emulator successfully opens a
socket connection to one of the addresses, in this case the address of the
SNA Server TN3270 Server, the emulator is locked into that address and
cannot try another IP address specified with the Hot-Backup feature.

RESOLUTION
==========

Microsoft has enhanced the SNA Server 2.11 files, TN3SERVR.EXE and
TN3NTMSG.DLL, to fully support the Hot-Backup feature of TN3270 emulators.

This update supports the option to stop listening once all of the
configured SNA resources are in use, and to start listening again once some
become available. This feature is turned on by setting the following
registry entry under the HKEY_LOCAL_MACHINE subtree under the following
subkey:

   \CurrentControlSet\Services\TN3270\Parameters\CloseListenSocket

Type:  RG_EXPAND_SZ
Value: YES

If it is set to any other value or not set at all then the TN3270 Server
does not stop listening.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.11
KBSubcategory: ntnetserv ntprotocol
Additional reference words: prodsna 2.11

K # + K $ Ability to Change Password Added to SNA Win3.x Client
Article ID: Q106504
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1 and 2.11
------------------------------------------------------------------------

SUMMARY
=======

Previously, when you used the SNA Server Windows 3.x client to communicate
to the server over TCP/IP sockets, Netware IPX/SPX, or Banyan IP, you were
not able to change your Windows NT password if the password had expired on
the Windows NT Server.

Support for SNA Server Windows 3.x clients to change their expired Windows
NT password has been added in SNA Server 2.11 Service Pack 1. For this to
work, apply the Service Pack to the SNA Server 2.11 server and to the
Windows 3.x client. Also apply Service Pack 2 (or higher) to Windows NT
3.51 on the Primary Domain Controller (PDC).

MORE INFORMATION
================

This enhancement to the SNA Server Win3x client now allows clients running
non-named pipes interface along with the SNA Server Win3x 2.11 client to
have the ability to change their expired password in the Windows NT Server
domain. This enhancement works across all protocol stacks that are able to
use the SNA Server Win3x client software to access the SNA Server.

This enhancement to the SNA Server Client is possible due to enhancements
made in NT 3.51 Service Pack 2. To make use of this feature, the Primary
Domain Controller (PDC) must be running Windows NT 3.51 with Service Pack 2
or later. The SNA Server(s) do not necessarily need to be running at this
level but it is recommended.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbinterop kbbug2.00 kbbug2.10 kbbug2.11 kbfix2.11.sp1
KBSubcategory: ntnetserv ntdistrib ntdomain
Additional reference words: prodsna 2.00 2.10 2.11 password wnap 2.11a

K # + K $ RUI Interface Enhancement to Avoid Duplicate Signon Screens
Article ID: Q107384
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
------------------------------------------------------------------------

SUMMARY
=======

If an SLI_OPEN follows immediately after an SLI_CLOSE statement the SSCP
Welcome message screen may appear twice under some certain timing
conditions.

An SNA Server 2.11 update is available which closes a timing window where
this can occur. For additional information, please see the following
article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q137482
   Title     : LUA Program Receives Host Sign-On Screen Twice and then
               Hangs

However, with this update applied, this problem can still occur under
certain timing conditions described in this article.

An Additional Update Is Available
---------------------------------

Another update to SNA Server 2.11 now supports the ability to put a small
configurable delay between the SLI_CLOSE completion and issuing the new
SLI_OPEN statement. Microsoft has updated the following file to include
this feature:

   <snaroot>\system\WINRUI32.DLL

This update is for Win32 clients only and is implemented in the WIN32 RUI
Interface and exported as a new registry value.

Implementing the Update
-----------------------

To set this delay you have to obtain the update and add the new registry
value INITDELAY under the HKEY_LOCAL_MACHINE subtree under the following
subkey:

   SYSTEM\CurrentControlSet\Services\SnaBase\Parameters\Client

Use the following information when adding the new value:

   Value Name: INITDELAY
   Data Type:  REG_DWORD
   Data:       0-10 (decimal)

   Default:    0 seconds

This variable sets an optional delay in seconds in processing RUI_INIT
requests. If you do not specify an entry for data, there is no delay. If
you configure a value greater than 10, then a value of 10 is used.

MORE INFORMATION
================

When an LUA session is closed and immediately reopened, the SNA Server
may resend the host SSCP welcome message twice to the LUA application.
The following diagram explains what is happening:

Message flow as the node sees it.       Message flow as the host sees it.
    Host                Node                Host             Node
    ====                ====                ====             ====

      NOTIFY unavailable                      NOTIFY unavailable
        (SLU disabled)                         (SLU disabled)
     <--------------------                   <----------------

          NOTIFY +rsp                           NOTIFY +rsp
     -------------------->                   ----------------->

        NOTIFY available                        logon banner
     <--------------------                   ----------------->

        logon banner                           NOTIFY available
                                                (SLU enabled)
     -------------------->                   <-----------------

        NOTIFY +rsp                             NOTIFY +rsp
     -------------------->                   ----------------->

        logon banner                            logon banner
     -------------------->                   ----------------->

When the host receives the first NOTIFY it sends a logon screen. At the
same time, the node is sending the second NOTIFY. In this case by the time
that the logon screen reaches the node, the node has passed on the second
NOTIFY to the link service. In that situation the node is not able to
determine whether the logon screen was sent due to the first NOTIFY, or the
second NOTIFY, and so it passes it up to the application. Shortly
thereafter, the second logon screen arrives, and the node also passes that
up to the application.

This is because the underlying SSCP-LU session on which the NOTIFYs and the
logon screens flow is not brought down when the SLI session is brought down
and a new SLI session is started. Therefore, the node cannot tell that a
particular message on the SSCP-LU session is associated with the SLI
session which has been terminated.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna SLI

K # + K $ Support for sending User ID on Attach when AP_SAME specified
Article ID: Q135316
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SUMMARY
=======

In response to customer requests, Microsoft created an update for SNA
Server that allows APPC applications to automatically send the logged on
user ID in the LU6.2 attach message, when setting the security parameter to
AP_SAME. Prior to this enhancement to SNA Server, setting the AP_SAME
option would only transmit the USER_ID field when the program had been
previously invoked with conversation security by another APPC program.

MORE INFORMATION
================

This enhancement to the APPC API allows an invoking transaction program to
use the current logged-on Windows NT user ID as the user ID for APPC
Conversation Level security. To enable this feature:

1. The invoking TP must set the security parameter in the [MC_]ALLOCATE
   verb control block to AP_SAME.

2. The following registry setting, or WIN.INI [wnap] setting for Windows
   3.x, must be enabled:

   Windows NT:

      \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SnaBase
        \Parametrs\Client

         UnverifiedAP_SAME   REG_DWORD     0x1

   Windows 3.x:

      WIN.INI [WNAP] section:

         UnverifiedAP_SAME=YES

When this enhancement is used, the [MC_]Allocate causes an Attach request
to be transmitted containing the logged-on user ID and the Already Verified
indicator. No password is transmitted in this case. If the invoking
transaction program was itself invoked with an APPC user ID, that user ID,
not the Windows NT one, is used.

RESOLUTION
==========

Microsoft has updated the Windows NT client file WAPPC32.DLL, and the
Windows 3.x client files, WINAPPC.DLL and WNAP.EXE, to correct this
problem.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ Dynamically Adding LUA LUs is Supported
Article ID: Q135495
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

SNA Server Admin allows some changes to be made dynamically, so you do not
have to stop the SNA Server service. However, under SNA Server 2.0, 2.1,
and 2.11, SNA Server does not support the dynamic definition of LUA LUs.
The SNA Server service must be stopped and started when new LUA LUs are
added to the configuration.

RESOLUTION
==========

An enhancement to SNA Server 2.11 now supports the dynamic creation and
pooling of new LUA LUs.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11  pool lu

K # + K $ SnaBase Now Limits Domain or Subdomain to 15 SNA Servers
Article ID: Q137146
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------

A new feature has been added to SNA Server in SNA Server 2.11 Service Pack
1. Now, when the Snabase service starts (as it opens its configuration
file), it checks the number of SNA Servers in its subdomain. If there are
already 15 SNA Servers found in the configuration file, the SnaBase service
fails to start, Event 702 is logged into the Windows NT application log,
and a warning is displayed.

If the SnaBase service finds its own computer name in the configuration
file, COM.CFG, it does not stop or log an event, even if there are more
than 15 servers in the subdomain. This ensures that users who already have
more than 15 servers in their subdomain can use the updated SNABASE.EXE.
However, it does prevent an Administrator from adding any new SNA Servers
to the Windows NT domain or SNA Server "subdomain" which has already
reached its limit.

This feature was added to prevent complications resulting from too many SNA
Servers in the same subdomain. If there is a need for 15 or more servers in
aggregate, subdomains should be used.

NOTE: See the section entitled "G.2. Addition to SNA Server Planning Guide"
in the SNA Server 2.11 README.WRI file for more information about dividing
SNA Servers into separate subdomains.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11 kbfix2.11.sp1
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna

K # + K $ Performance Improvements for 3270/LUA Apps
Article ID: Q138270
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

This article describes performance enhancements that were made to SNA
Server service and client interfaces and how to obtain the update and how
to derive benefits from this update if you are using third-party 3270
emulation products that work over the LUA variant of the SNA Server EIS
interface.

MORE INFORMATION
================

The client-server protocol used to support the LUA-variant of the SNA
Server 3270 Emulator Interface Specification (EIS) and LUA RUI interface
has been enhanced to increase performance. The SNA Server service and
Win32, Win3.x, OS/2 and MS-DOS RUI client interfaces have been updated.
Down-level clients continue to function through the updated SNA Server
service.

Also, the SNA Server 3270 applets include an additional performance
improvement by requesting complete RUs rather than individual segments.

Any 3270 application that uses the LUA RUI interface, as well as any LUA
RUI application, performs faster with this update applied. However, 3270
applications which use the LUA variant of the SNA Server EIS interface may
require some further enhancements to take advantage of these performance
improvements. These enhancements are described in the To Implement The
Update section below.

To determine if a 3270 emulator uses the LUA-variant of the EIS interface,
enable SNA Server 3270 message tracing and open a 3270 session. If byte 34
of Element #1 in the Open(SSCP) message is set to 0x01, then the LUA
variant is being used. If byte 34 is set to 0x00, the LUA variant is not
being used and no further application changes are necessary to implement
the performance enhancements.

NOTE: The SNA Server 3270 applets use the LUA variant of the EIS interface.
These 3270 applets have been updated to implement the performance
enhancements described in this article.

Where Changes Were Made
-----------------------

The client-server message flow for the LUA-variant of the Emulator
Interface was less efficient than it could be. The following explains two
specific cases:

 - When a Begin Bracket RU is received by the server, the server and client
   currently exchange a Status Control (BID) and acknowledgement before the
   data is sent to the client. Similarly, when a bracket officially ends,
   the server sends a Status (Betb) message. Both of these messages are
   redundant for the LUA interface, because the application processes the
   RH flags on the RUs NOT the FMI indicators.

 - When a client acknowledges a data message, it has to wait for the server
   to acknowledge the acknowledgement with an ACKLUA message. This is so
   that the server can verify that the correct sequence number is provided
   on the response. This message has been removed by making the RUI
   application or 3270 EIS/LUA application responsible for tracking
   sequence numbers. The 3270 applet already acknowledges the correct
   sequence number, so the handshake is redundant.

These changes have been implemented ensuring full backward compatability,
so the new clients and servers can co-exist with previous versions.

To Implement the Update
-----------------------

To improve performance of your SNA Server 2.11 and the 3270 applets:

 - Contact Microsoft Product Support for the update.

To improve performance of your third-party 3270 emulation products which
work over the LUA variant of the SNA Server EIS interface:

 - Contact Microsoft Product Support for the update.

 - Make the changes described below in the section titled Third-Party 3270
   Emulation Products to support the performance enhancements available
   with the update.

Microsoft updated the following files for the enhancements:

 <snaroot>\system\SNASERVR.EXE - SNA Server service
 <snaroot>\system\TRCSERVR.EXE - Special traced version of SNA Server
                                 service
 <snaroot>\system\WINRUI32.DLL - Win32 client RUI DLL
 <winroot>\system\WINRUI.DLL   - Win 3.x client RUI DLL
 <snaroot>\ACSRUI.DLL          - OS/2 client RUI DLL
 <libs>\dos\dosacs.lib         - MS-DOS client RUI link library
 <libs>\dos\dtracs.lib         - Traced version of MS-DOS client RUI
                                 link library
 <snaroot>\SYSTEM\FMIS3270.DLL - Win32 3270 applet module
 <sna.win>\FMIS3270.DLL        - Win 3.x 3270 applet module

Third-Party 3270 Emulation Products
-----------------------------------

Third-party 3270 emulation products which work over the LUA variant of the
SNA Server EIS interface require the following enhancements to support the
performance enhancements available with the Microsoft update. Those 3270
emulation products or LUA applications that communicate over the LUA RUI
interface do not require any modifications to obtain the performance
improvements, because these changes are implemented by the RUI library.

Here is the information necessary for third party 3270 emulation vendors
to implement these performance improvements:

 - The LUA version number is contained in the Open(SSCP) request message
   at dataru[40] (dataru[39] is reserved and should be set to 0). The
   following are the supported values of the LUA version:

    - 0x01 - the original (that is, unmodified) LUA version of the EIS.

    - 0x02 - the new version incorporating the API changes below.

   If the emulator specifies a version greater than that supported by the
   current SNA Server, the server negotiates the version down on its
   Open (SSCP) response (see below). Modifications to the API are
   incremental; any emulator supporting any future version X must
   support all the version X-1 features.

   Note that startd must be set to 41 or greater. If startd is less than
   41, the emulator is indicating support for version 1 only.

 - SNA Server returns the version number to be used on the Open (SSCP)
   response message in the lower 7 bits of dataru[40] with the top bit
   always set to b'1'. If the emulator receives an Open (SSCP) response
   message with startd less than 41 or with the top bit of dataru[40]
   clear, it must assume that the node supports version 1 of the LUA
   version of the EIS only.

 - The Node continues to sent Status-Control (BID) messages when an
   explicit SNA BID request is received on the session (the RBI flag is set
   in the Application Flags bytes in the message header).

 - An emulator specifies that it is responsible for sequence number
   checking by setting the ackqual field of the Status-Acknowledge message
   to ACKLUA instead of ACKPOS. This causes the Node to generate a positive
   response on the session without returning a Status-Acknowledge (ACKLUA)
   message to the emulator. Note that if the emulator provides an incorrect
   sequence number no indication is sent to the emulator and no response
   is sent on the session. This change does not apply to negative responses
   or Status-Control-Acknowledge messages, for which emulators continue to
   receive Status-Acknowledge(ACKLUA) messages.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Compatibility with S/36
Article ID: Q138804
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
------------------------------------------------------------------------

SUMMARY
=======

This article describes how to configure SNA Server to communicate with an
IBM S/36 (SSP release 5.5 or later) over 802.2 Token Ring to support 5250
emulation. Both SNA Server
and S/36 configuration parameters are discussed.

NOTE: The SNA Server 5250 applet shipped with SNA server 2.11 and before
did not support S/36 device emulation. An updated applet which supports
both AS/400 and S/36 is available from Microsoft.

MORE INFORMATION
================

These instructions assume all of the following:

 - The Windows NT DLC transport driver is already installed and is bound to
   the correct network adapter.

 - The SNA Server DLC link service is already installed using SNA Server
   Setup.

 - The system has been restarted.

S/36 Configuration
------------------

1. Sign on to the S/36 console.

2. Determine the S/36 token ring adapter address:

    - At the command line type STATUS COMCNFIG.
    - Enter "1" in the field to display specific line status.
    - Enter "9" in the next screen to display the status of the token ring
      line.

   NOTE: Lines 9 and 10 are the only valid lines for token ring on the
   S/36. If no adapter address is displayed, verify that you are using the
   correct line number, and that the token ring card is properly installed.

3. Note the adapter address for use in configuring SNA Server. Press CMD7
   until you are back at the main S/36 menu. If necessary, use the BLDLIBR
   command to create a library to contain the communications configuration.

4. Type CNFIGICF to start configuring the S/36 communications.

5. First, define an ICF line member for your token ring line. On the
   "SSP-ICF CONFIGURATION MEMBER DEFINITION" screen enter a name for your
   token ring line member description and the library in which to create
   it. Type "1" to create a new member, then press ENTER.

6. On screen 2.0 enter "3" for SNA.

7. On screen 4.0 enter "4" for a token ring line member. A second question
   appears. Enter "Y" to indicate that APPC will be used.

8. On the "SNA LINE MEMBER ATTRIBUTES" screen, enter the exchange ID (XID)
   and SAP values. In most cases "00000" can be used for the XID and "04"
   can be used for the SAP.

9. On screen 12.5 type a "1" to create a new remote system with the name
   of your SNA Server in the "Remote System Name" field. Press ENTER.

10.On screen 13.0 enter "2" for a peer system. Press ENTER.

11.Enter the two parts of the SNA Server's XID. This value must match the
   Local node ID value in the 802.2 Setup window in SNA Server admin.
   Press ENTER.

12.Enter the adapter address and SAP value for your SNA Server. The
   appropriate SAP address for your SNA Server can be found in the Link
   properties for the link service used by the connection to the S/36.
   In most cases this will be "04". Press ENTER which returns you to the
   "SNA LINE MEMBER ATTRIBUTES" screen. Then press Cmd5 to restart
   CNFIGICF.

13.Define a communications subsystem member. The screen currently shows the
   name for the line member you just created. Change the member name to a
   new name for your new subsystem member. Select the following options:

      - "1" for Create a member.
      - "3" for SNA, "1" for SNA subsystem,
      - "7" for APPN.

   You should now see the "SUBSYSTEM MEMBER DEFINITION" screen.

14.Type the system and network names for your S/36. These values correspond
    to the Control Point Name and Network Name fields in the Remote Node
    Name section of the 802.2 Setup window.

15.On screen 28.0 select "1" to define a non-networking node. Press ENTER
   and you are prompted for a line member name. Type in the name of the
   line member from step 5 above. Press ENTER.

16.Type "1" to create a new location. Enter the name of your SNA Server in
   the Remote location name and Remote system name fields. This name must
   match the Control Point name in the Server Properties window in SNA
   Server Admin.

17.Type "2" next to the entry you just created and press ENTER. On the
   next screen enter "N" for Send alerts, "N" for Single-session location
   and "Y" for Stay Operational. Press ENTER, then CMD7 to return to the
   APPN SUBSYSTEM MEMBER DEFINITION screen.

18.Enter "5" to begin defining the QPCSUPP mode. The S/36 refers to modes
   as "session groups".

19.Type "1" to create a new session group, "QPCSUPP", in the Session group
   name and Default session group fields, then press Enter. Go down to the
   new entry and edit it with option "2".

20.Enter "1" for Interactive, "32" for the session limit, and "00" for the
   other fields. NOTE: It should be possible to set the maximum session
   limit to 64, but there is unofficial word that a single S/36 token ring
   card will only support 32 sessions. You will need to press ENTER twice
   to continue.

21.Enter "07" for the pacing size, "16384" for the maximum RU size, and "N"
   for the Acquire sessions field. Press Enter. You can now press CMD7
   until you exit CNFIGICF. Once you ENABLE the line your S/36 is ready to
   communicate.

SNA Server Configuration
------------------------

Configure the following entries using the SNA Server Admin program:

1. Select the SNA Server service (which appears as the Windows NT machine
   name), located in the Servers and Connections window of Admin. Enter the
   following parameters:

      SNA Network Control Point Name

       - Network Name =  APPN (or Network ID in the S/36 Subsystem Member
                         Definition).

       - Control Point Name = This is the Remote location name and Remote
                              system name in the S/36 APPN Subsystem Member
                              definition. For simplicity, this should be
                              set to the local Windows NT machine name.

      (These values were specified in step 14 of the S/36 configuration.)

      Choose OK.

2. Add a new Local APPC LU off the server service by choosing the Insert
   button and entering the following parameters:

      LU 6.2 Type  = Independent

      LU Alias     = For simplicity, this should be the same as the
                     Local LU Name below.

      Network Name = APPN (same as network name in step 1)

      LU Name      = This is the same as the control point name in step 1.

      All other entries can remain at default values.

   NOTE: It is most efficient for all SNA Server users to use the same
   Local APPC LU. However, it is possible to create a unique LU for each
   user if desired, where the LU alias and LU name above could be replaced
   with the actual user name (although this requires additional
   administration to maintain).

   Choose OK.

3. Configure the SNA Server 802.2 connection by zooming on the connection
   name:

      Link Service = SnaDlc1 (or name specified during SNA setup)

      Remote End   = Peer System

      Activation   = Pick the value appropriate for your environment.

      Allowed Directions = Outgoing calls. Check Incoming Calls if you
                           want the S/36 to be able to activate the link.

      Choose the Setup button configure the following parameters:

         Remote Network Address = Set to the network adapter address of the
                                  S/36.

         Local Node ID = Leave at default - 05D FFFFF.

         Remote Node Name:

         Network Name = APPN (same as Network Name in step 1)

         Control Point Name = S/36 local system name, configured in the
                              S/36 APPN Subsystem Member Definition.

         Remote Node ID = Not used (leave blank)

         Advanced options can be left at their default settings

      Choose OK.

4. Add a new Remote APPC LU off the connection by choosing the Insert
   button and entering the following parameters:

      LU Alias     = For simplicity, this should be the same as the
                     Remote APPC LU Name below.

      Network Name = APPN (Same as other network values above)

      LU Name      = Must be set to the S/36 system name.

      Uninterpreted LU Name = Not used (leave at default setting).

      Select Supports Parallel Sessions (required).

      Choose the Partners button. The Remote APPC LU must be partnered
      with the Local APPC LU created above, using the QPCSUPP mode. Because
      Enable Automatic Partnering is enabled by default for APPC LU's,
      this pairing will already be added.

   Choose OK.

5. Save the SNA Server configuration file and restart the SNA Server
   service. Once the SNA Server service is Active, all connections
   configured to activate on server startup will go into a Pending state,
   then switch to Active.

   NOTE: If the connection stays in Pending mode and doesn't activate:

   a. Check the Windows NT Application Event Log (using Event Viewer) to
      see the reason why the connection isn't activating. For example, if
      the S/36 is not responding to TEST commands, then the remote network
      address may not be correct.

   b. Verify the configuration entries above with your S/36 system
      administrator and make sure the S/36 line and communications
      subsystem are enabled.

   c. Check if the S/36 is logging any console messages when SNA Server
      attempts to establish the connection.

   d. If the connection activates but users are unable to open 5250
      sessions, zoom on the Status button on the Local APPC LU, which
      should show the following (when working correctly):

      Partner LU    Mode       Connection     Sessions   Limit
      -----------   --------   ------------   --------   ------
      <remote LU>   SNASVCMG   <connection>   0          2
      <remote LU>   QPCSUPP    <connection>   0          32

      This means that up to 32 sessions are available for use, though
      no sessions are currently active.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbsetup kbhowto kbbug2.11
KBSubcategory: ntnetserv ntconfig nthowto
Additional reference words: prodsna 2.00 2.10 2.11 3.50 3.51

K # + K $ Disabling TCP/IP Nagle Algorithm Improves Speed on Slow Nets
Article ID: Q138831
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SUMMARY
=======

This article explains the Nagle TCP/IP algorithm and how to manually
disable it on different the SNA Server client and server releases for
different operating systems. It also mentions how to obtain an update that
automatically disables this algorithm.
Microsoft has updated the file <snaroot>\SYSTEM\SNAIP.DLL to correct this
problem.

MORE INFORMATION
================

The Nagle TCP/IP Algorithm
--------------------------

The Nagle TCP/IP algorithm was designed to avoid problems with small
packets, called tinygrams, on slow networks. The algorithm says that a
TCP/IP connection can have only one outstanding small segment that has not
yet been acknowledged. The definition of "small" varies but usually it is
defined as "less than the segment size" which on ethernet is about 1500
bytes.

Manually Disabling the Nagle Algorithm
--------------------------------------

You can disable the Nagle algorithm by performing the SNA Server client and
server modifications mentioned below and following the instructions in the
Activating the Modifications section.

SNA Server Modifications
------------------------

1. Under the subtree HKEY_LOCAL_MACHINE add the subkey SNATCP under the
   following key:

      SYSTEM\CurrentControlSet\Services\Snabase\Parameters\

2. Choose Add Key from the Edit menu and use the following information:

      Value Name: NoDelay
      Data Type:  REG_SZ
      String:     yes

Windows 95 SNA Client Modifications
-----------------------------------

Add the same registry entry as SNA Server above.

Windows 3.x Modifications
-------------------------

Windows 3.x client always disables the Nagle algorithm and there is no way
to enable it.

Activating the Modifications
----------------------------

When the NoDelay is set to yes, the TCP/IP transport DLL uses the
TCP_NODELAY option when it opens a socket.

For this to take effect, the client server interface must be stopped and
restarted on both the server and client after the registry changes have
been made. The following table shows the name of the SNA client server
interface program and the corresponding operating system platform:

   Client Server Interface      Platform
   ----------------------------------------
   SNABASE Service              Windows NT
   SNABASE Service              Windows 95
   WNAP.EXE                     Windows 3.x

Note: The Nagle algorithm is defined in TCP/IP RFC 896.

Obtaining the Update to Automatically Disable the Nagle Algorithm
-----------------------------------------------------------------

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ How to Enable SNA Server IPX/SPX Clients to Use SPXII
Article ID: Q138832
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

One of the protocols that the SNA Server client server interface uses is
native IPX/SPX. SNA Server can be configured to talk over the improved
SPXII protocol.

MORE INFORMATION
================

An improved version of SPX is SPXII. SPXII has the following advantages:

 - SPXII can use the maximum packet size allowable by the network type. On
   an Ethernet LAN, for example, an SPX II packet can be a full 1518 bytes.
   Standard SPX is only capable of sending 576 byte packets.

 - SPXII can use "windowing" where multiple packets can be outstanding at
   one time. It uses negative acknowledgments (NAKs) to indicate that some
   packets were not received. Standard SPX allows only one packet to be
   outstanding at any time.

To enable the newer SPXII protocol to work with SNA Server, add the
following subkey to the registry:

   \Hkey_Local_machine
     \System
       \CurrentControlSet
         \Services
           \SnaBase
             \Parameters
                \SnaSpx

Then, add the following value:

   SPXII:REG_SZ:yes

SPXII has been supported since SNA Server 2.1 with the addition of
the registry entry, but only on Windows NT 3.5/3.51, not on Windows NT 3.1.

Client support is as follows:

 - Windows 95: Enable the same registry entry as above.
 - Windows NT: Enable the same registry entry as above.
 - Windows 3.x and MS-DOS: Supported if the server and the client
   IPXODI driver support SPXII.

RESOLUTION
==========

Microsoft has updated the file <SNAROOT>\SYSTEM\SNANW.DLL to correct this
problem.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Admin Loads Faster with Improvements in SNACFG.DLL
Article ID: Q138833
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

The following changes have been made to the configuration interface
(SNACFG.DLL) so that the SNA Server Administration program loads faster:

1. When the SNA Server configuration file (COM.CFG) is loaded, SNA Server
   no longer verifies that all SNA Server users and 3270 LUs/pools are
   uniquely defined in the configuration file.

2. The handling of SNA Server user record entries has been improved to
   speed up retrieval of user records, when requested by a 3270 emulation
   program.

Obtaining the Updated SNACFG.DLL
--------------------------------

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Improvements for EIS/3270 and APPC Resource Location
Article ID: Q138834
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

This article describes how the SNA Server client server interface locates
an available LU for both APPC and EIS/3270 applications, both with and
without Service Pack 1 installed.

Microsoft has updated the following files. Service Pack 1 is planned to be
released in December 1995. To obtain these files before Service Pack 1 is
released, contact Microsoft Product Support Services. Service Pack 1
includes the following modified files:

   Operating System     Modified Files
   ---------------------------------------------------------------
   Windows NT           SNABASE.EXE, SNACFG.DLL, SNADMOD.DLL, WAPPC32.DLL
   Windows 95           SNADMOD.DLL, WAPPC32.DLL
   Windows 3.x          WDMOD.DLL, WINAPPC.DLL

MORE INFORMATION
================

EIS/3270, Without Service Pack 1 Installed
------------------------------------------

Over the sponsor connection, the EIS/3270 application makes a sepdcrec()
call to acquire a list of the LUs/pools that are assigned to the client's
user record. On a connect request to open a session, the application issues
an OPEN SSCP request on the chosen LU/Pool name. The underlying DMOD (part
of the client server interface) attempts to locate the server that can
house this available LU by connecting to each server in the client's local
service table one by one until the specified LU/Pool is satisfied. It must
do this because the local service table does not contain any LU/Pool
information; it contains only server names.

APPC, Without Service Pack 1 Installed
--------------------------------------

During the TP_START request and ALLOCATE verb processing that a TP does to
get a conversation, the underlying DMOD (part of the client server
interface) attempts to locate the server that houses this available LU by
connecting to each server in the client's local service table one by one
until the specified LU-LU pair is satisfied. It must do this because the
local service table does not contain any APPC LU information; it contains
only server names.

EIS/3270, With Service Pack 1 Installed
---------------------------------------

The client still makes the normal sepdcrec() call to acquire a list of the
LUs/pools that are assigned to the client's user record. As part of the
OPEN SSCP message processing, the SNA Server client software sends a new
RPC request (RPC_LU_SERVER_LIST) to the SNA Server that is supporting the
client computer's sponsor connection. The requested LU name from the OPEN
SSCP is part of the RPC request. The sponsor server returns a list of the
servers who can possibly support the requested LU. If the LU is a dedicated
LU, the list has only one server name. If it is a POOL the list may have up
to 50 server names. After this RPC response, the resource locating
continues normally except that the client tries (in random order) only the
servers whose names are in the LUs server list. In general, the client
tries only the servers that can actually support the LU resource.

APPC, With Service Pack 1 Installed
-----------------------------------

The RPC request is sent as part of the TP_START request and ALLOCATE verb
processing. In both cases, the server returns the list of servers where the
local or remote LU Alias is configured. The rest is similar to 3270
resource location.

In both the EIS/3270 and the APPC, the RPC request is sent only once per
LU. The SNA Server client interface cashes the LU/Server information
internally. In Windows NT and Windows 95, the cache is flushed when the
application exits. In Windows 3.x, the cache is flushed when the client
server piece (Wnap.exe) terminates.

NOTE: If the sponsor server is not running SNA Server 2.11 with Service
Pack 1 installed, the client DMOD sends only one RPC request. After it gets
the "not supported" error it does not try again.

If the RPC request fails for any reason, for example if the sponsor does
not support the new RPC request, the DMOD uses the old resource locating
algorithm.

No changes are required to existing emulators, including the 3270
application that ships with SNA Server.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Internet Firewall Support in SNA Server
Article ID: Q139508
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

This article discusses the new SNA Server ability to support Internet
Firewalls and then gives instruction on the following:

 - How to allow SNA Server clients and SNA Servers to interoperate with
   screening routers, where the client does know the address of the SNA
   Server(s).

 - How to allow SNA Server clients and SNA Servers to interoperate with
   full-blown Internet firewalls, where the end user is not allowed to know
   the IP address of the SNA Server(s).

OVERVIEW
========

SNA server can be configured to use specific software port numbers.
Specific port numbers are commonly defined in software components to allow
administrators of Internet firewalls to filter packets based on port
number, thereby denying/accepting their propagation to the private network.
By assigning specific destination port numbers to SNA Server components,
SNA Server can interoperate with screening routers and full-blown firewalls
to meet the requirement that users of the public network should not know
the IP address of the SNA Server.

I. SNA Server Clients and SNA Servers Interoperation with
Screening Routers (Client knows the address of the SNA Server(s))
=================================================================

The following are the instructions on how to allow SNA Server clients and
SNA Servers to interoperate with screening routers, where the client does
know the address of the SNA Server(s).

Destination port numbers are configurable in SNA Server on the following
platforms:

 - Windows NT
 - Windows 95
 - Windows 3.x

The following transport protocols can be used:

 - TCP/IP
 - IPX/SPX
 - Vines IP

Each transport has the following three components that can have
administrator defined destination ports assigned to them:

 - DatagramPort.

   This port is used for datagram (mostly broadcast or multicast) traffic.
   Use the Server Broadcasts dialog in SNA Server Admin to control which
   transport is used for Server to Server communication.

 - SnaBasePort.

   This is the port where the server SnaBase listens for new client sponsor
   connections. Sponsor connections are used by the SNA Server client to
   learn about the SNA Server subdomain in which it participates.

 - SnaServerPort.

   This is the port where the SNASERVR.EXE waits for new application
   session requests.

The default values for destination port numbers are:

   Port            TCP/IP   IPX/SPX     Vines
   --------------------------------------------
   DatagramPort    1478     0x84C8      381
   SnaBasePort     1478     0x84C8      381
   SnaServerPort   1477     0x84C9      dynamic

There is no need to change any of these ports except when it is necessary
to run each SNA Server service and SNABase service with a unique port
number. It is the administrator‘s responsibility to make sure that the
ports are not used by other applications on the network.

NOTE: The DatagramPort must be the same in every server in a subdomain.

On Windows NT, the ports are configured in the registry under the subtree
HKEY_LOCAL_MACHINE under the subkey:

   System\CurrentControlSet\Services\SnaBase\Parameters\<transport>\

where <transport> is SnaTcp, SnaSpx, or SnaVines.

Add the following value name under the <transport> subkey:

   Value Name: <port>
   Data Type:  REG_DWORD

where <port> is DatagramPort, SnaBasePort, or SnaServerPort.

On Windows 95, the ports are configured in the registry under the subtree
HKEY_LOCAL_MACHINE under the subkey:

   Software\Microsoft\SnaBase\Parameters\<transport>\

where <transport> is SnaTcp, SnaSpx, or SnaVines.

Add the following value name under the <transport> subkey:

   Value Name: <port>
   Data Type:  REG_DWORD

where <port> is DatagramPort, SnaBasePort, or SnaServerPort.

On Windows 3.x, the ports are configured in the WIN.INI file under the
[WNAP] section:

   [WNAP]
   <port>=<value>

where <port> is DatagramPort, SnaBasePort, or SnaServerPort and value is
the port number either in decimal or hexadecimal notation.

Remote TCP/IP Clients
---------------------

For TCP/IP it is not enough just to add one SnaBasePort number to the
WIN.INI file or registry in Windows NT or Windows 95. Because every SNA
Server in the subdomain is potentially using a different destination port
number, every sponsor server requires its own entry. To make this possible,
the port names can be prefixed with a server name. For example, if the
SnaBase service on the server Server_A is using destination port 1234 and
the server Server_B is using destination port number 5678, you need to add
the following entries into the WIN.INI file or registry:

Windows NT or Windows 95 registry:

   Server_ASnaBasePort:REG_DWORD:1234
   Server_BSnaBasePort:REG_DWORD:5678

Windows 3.x WIN.INI file:

   Server_ASnaBasePort=1234
   Server_BSnaBasePort=5678

The clients get the SnaServer ports through the sponsor connection. On
IPX/SPX and Vines IP, the clients get the SnaBase ports from the NetWare
bindery and Vines StreetTalk respectively. There is no need to configure
any port numbers on these two client types.

OtherServers
------------

When you use the OtherServers parameter, use the following convention in
the WIN.INI file under the [WNAP] section:

   [WNAP]
   <server_nameX>SnaServerPort=3333
   <server_nameY>SnaServerPort=4444

You still need to include the following entry in this section:

   Otherservers=<server_nameX> <servernameY>

II. SNA Server Clients and SNA Servers Interoperation with Full-Blown
Internet firewalls (Client Cannot Know the IP address of the SNA Server(s))
===========================================================================

The following are the instructions on how to allow SNA Server clients and
SNA Servers to interoperate with full-blown Internet firewalls, where the
client is not allowed to know the IP address of the SNA Server(s).

First, follow directions in section I. above. Then, add the following entry
to the respective platform:

Windows NT:

1. In the registry, go to the subtree HKEY_LOCAL_MACHINE under the
   following subkey:

      System\CurrentControlSet\Services\SnaBase\Parameters\SnaTcp\

2. Add the following information:

   Value Name: FireWall
   Data Type:  REG_MULTI_SZ
   Data:       <list of firewall IP addresses>

Windows 95:

1. In the registry, go to the subtree HKEY_LOCAL_MACHINE under the
   following subkey:

      Software\Microsoft\SnaBase\Parameters\SnaTcp\

2. Add the following information:

   Value Name: FireWall
   Data Type:  REG_SZ
   Data:       <list of firewall IP addresses>

Windows 3.x:

1. Add the following information in the WIN.INI file under the [WNAP]
   section:

      [WNAP]
      FireWall =<list of firewall IP addresses>

The SNA Server IP transport replaces the real destination IP address with a
firewall address when it opens a connection to an SNA Server for both
application sessions or sponsor connection.

Microsoft has updated the following files:

   LIBS\WIN32\SNAIP.DLL
   LIBS\WIN32\SNANW.DLL
   LIBS\WIN32\SNABV.DLL
   LIBS\WIN95\SNACIP.DLL
   LIBS\WIN95\SNACNW.DLL
   LIBS\WIN95\SNACBV.DLL
   EXE\WIN16\IPCLI.DLL
   EXE\WIN16\NWCLI.DLL
   EXE\WIN16\BVCLI.DLL
   EXE\TWIN16\IPCLI.DLL
   EXE\TWIN16\NWCLI.DLL
   EXE\TWIN16\BVCLI.DLL

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ SNA Server MS-DOS Router Session Limit Increased to 10
Article ID: Q139512
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SYMPTOM
=======

The SNA Server 2.11 MS-DOS router is limited to 5 sessions.

RESOLUTION
==========

Microsoft has updated the file <sna_cd_root>\CLIENTS\MSDOS\ROUTER.EXE to
correct this problem.

The new file allows 10 sessions over the MS-DOS router.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ RUI_READ Enhancement for Receiving Large RUs
Article ID: Q139784
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
------------------------------------------------------------------------

SUMMARY
=======

If an LUA RUI application issues an RUI_READ request and passes a data
buffer that is smaller than the size of the RU being received, the RUI
interface returns a primary_rc of LUA_UNSUCCESSFUL and secondary_rc =
LUA_DATA_TRUNCATED. The RUI library returns as much data as possible to the
application's data buffer, but the remaining data in the RU is thrown away
and cannot be extracted on subsequent RUI_READ requests.

This forces the RUI application to allocate an RUI_READ data buffer large
enough to handle the full RU size.

To work around this restriction, an update to SNA Server 2.11 now supports
the ability for a Win32, Win 3.x and OS/2 RUI application to receive
primary_rc = LUA_OK and secondary_rc = LUA_DATA_INCOMPLETE (0x00000060)
on an RUI_READ call, so it can continue to repost new RUI_READs receive
the remainder of the data.

NOTE: This enhancement has not been accepted as part of the Microsoft
WOSA LUA API standard.

Microsoft has updated the following files for this enhancement:

   Client Platforms     Updated Files
   -----------------------------------------------------------
   Win32 clients        <snaroot>\system\WINRUI32.DLL
   Windows 3.x clients  <winroot>\system\WINRUI.DLL
   OS/2 clients         <snaroot>\ACSRUI.DLL
   MS-DOS clients       <sdk>\LIB\MSDOS\DOSACS.LIB
   SDK file             \SDK\INC\WINLUA.H

MORE INFORMATION
================

This new feature is enabled with an update to SNA Server 2.11 Service
Pack 1. To enable this new feature, the Win32, Win 3.x or OS/2 RUI
application must:

 - Set lua_resv56[3] to a non-zero value in the verb control block when
   calling RUI_INIT during session establishment.

 - Look for primary_rc = LUA_OK and secondary_rc = LUA_DATA_INCOMPLETE
   (0x00000060) when RUI_READ completes. If this occurs, the application
   should repost a new RUI_READ to receive the next block of data, until
   the primary_rc = LUA_OK and the secondary_rc = LUA_OK.

If the LUA_DATA_INCOMPLETE is returned on an RUI_READ, any subsequent
RUI_READ used to receive the remainder of the RU will contain the same
transmission header (TH) and request/response header (RH). For example,
if the RU is marked with the End Chain (EC) indicator and the first
RUI_READ returns with LUA_DATA_INCOMPLETE, and the second RUI_READ returns
the rest of the data, then on each RUI_READ the EC indicator is set by
the RUI library in the verb control block.

The following line should be added to the WINLUA.H file to support this
new feature:

   #define LUA_DATA_INCOMPLETE      LUA_FLIPL(0x00000060)

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbprg
KBSubcategory: ntnetserv
Additional reference words: 2.11 prodsna

K # + K $ ODBC DRDA Driver Enhancements
Article ID: Q140368
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
------------------------------------------------------------------------

SUMMARY
=======

Microsoft SNA Server 2.11 includes ODBC DRDA drivers for Windows 3.x and
Windows NT, as well as for the SNA Server Windows 95 client. These drivers
were licensed by Microsoft from Starware and are included in SNA Server
2.11 for demonstration purposes only for use on a single client computer.

This article describes the enhancements that have been made to these
Starware StarSQL ODBC drivers between the SNA Server 2.11 release and the
version included in SNA Server Service Pack 1.

The Starware ODBC drivers support connection to the following databases:

 - DB2/400 (AS/400 database)
 - DB2 (MVS)
 - DB2/VM (SQL/DS) - support added in SNA Server Service Pack 1

The bug fixes and enhancements are listed below.

MORE INFORMATION
================

The version of StarSQL on SNA Server 2.11 is:

   1.03.18.12

The version of StarSQL included with the SNA Server Windows 95 client is:

   1.04b3 (1.04.20.15).

Bug fixes and enhancements:

 - Fixed password length bug - should be 10 chars instead of 8.

 - Fixed GP-Fault if adding a DSN with the same name as an existing DSN.

 - Fixed problem executing SQL with more than 84 parameter markers. The
   problem was erronously reported to the end user as a communications link
   failure. The problem was most commonly encountered when uploading tables
   with a large number of columns.

 - The data types SQL_NUMERIC and SQL_DECIMAL can now handle values with a
   whole-number portion outside of the ranges of the SQL_C_LONG type.
   Values are now only restricted by the precision and scale attributes of
   the variable.

 - Fixed problem using the alternate catalog QSYS with AS/400 V2R2. Note
   that v2r2 customers cannot update non-journaled physical file. The
   lowest isolation level supported by v2r2 for DRDA requires journaling
   for update.

 - Fixed problem where Microsoft Access would fail to update DATE fields
   on DB2/MVS.

 - Support for SQL/DS (VM/VSE). See RmtTPName in Advanced Options for setup
   information.

 - AS/400 name filtering when using the system-wide catalog on the database
   server - see Restricted Catalog Views in Hints.

 - Fixed problem that caused the StarSQL 32-bit driver to attempt to
   connect to the database using isolation level NO COMMIT has been
   corrected.

 - Fixed memory release problem.

 - Added support for Windows 95 in the 32-bit Intel version of StarSQL.

 - 32-bit version is renamed from "StarSQL NT" to "StarSQL 32" (generic
   name for both Windows NT & Windows 95).

 - Fixed the StarSQL SQL Parser to allow string values of ASCII characters
   greater than x'7F'; use of such strings in an application program that
   does not bind parameter data caused the program to freeze (discovered by
   German user).

 - Windows 95 installation & 3D dialog issues resolved.

 - 32-bit Intel built with Visual C++ (VC++) 2.02.

 - Shipped with Microsoft gestalt and help files from MS612.

 - SQL0201.DLL - DB2 Common Server (DB2/6000, DB2/2, DB2/NT).

Changes to Gestalt functionality:

 - Read-only check box greyed if gestalt does not support read-write.

 - Provision for Error Messag Prefix to be obtained from gestalt.dll.

 - DataSourceSetup and DriverConnect modified to only display network
   services that are supported by GESTALT.DLL.

 - Connect, Driver Connect return error message if network (comm dll) is
   not supported by gestalt.

 - Fixed crash with 32-bit applications on Win32s (e.g. FoxPro).

 - Enhanced performance for SQLTables catalog function (DB2 MVS)
   (use dynamic rather than static SQL)

 - Gestalt DLLs have original name in properties.

 - Support stored procedures (OS/400 v3r1). Requires manual deletion of
   existing SWRC0000 and SWNC0000 packages (rebind at next connect).

Infrastructure changes for Japanese/DBCS (with two new modules):

 - SWHCNV16/32  - Host conversion dll - does all code page conversions;
   contains translation tables resources.

 - SWRSRC16/32 - resource-only dll containing dialogs and strings.

OS/400 v2r2 & v2r3 non-collection physical file procedure:

 - SQL-created tables and views are no longer filtered from the table list
   when you specify QSYS as the catalog qualifier. Requires manual deletion
   of any existing QSYS packages (rebind at next connect).

 - SQLStatistics and SQLSpecialColumns (when turned on) now return Primary Keys as unique indexes (DB2 MVS only).

 - Support for held cursors in DB2 MVS 2.3 & 3.1.

 - DBCS support with static SQL workaround for DSCRDBTBL.

 - Support for LATIN-2 languages (e.g. Polish).

 - Access to multimember files on OS/400® v3r1 from a custom application

 - SQLStatistics and SQLSpecialColumns (when turned on) now return Primary Keys as unique indexes (for DB2 MVS only)

 - Support for held cursors in DB2® MVS 2.3 and 3.1

 - Support for stored procedures in AS/400 DB2/400 v3r1

 - Changes in catalog behavior for DB2/400 v2r2 and v2r3 allowing you to see SQL-created tables
and views in noncollection libraries

 - Enhanced performance for SQLTables catalog function (DB2 MVS)

 - Support for DB2/NT

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11 memory leak

K # + K $ SNA Server Pool Limit Extended to 10,000.
Article ID: Q140554
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SUMMARY
=======

The limit for SNA Server 3270 LU pools is 1000.

Microsoft has updated the file SNACFG.DLL to extend this limitation to
10,000.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna

K # + K $ 2 New Win32 CPIC APIs: Asynch Verb Completion Via WinNT Events
Article ID: Q140555
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

The following two new Win32 CPIC API Calls have been added to SNA Server
2.11 to enable asynchronous verb completion using Windows NT Events:

 - WinCPICSetEvent()

 - WinCPICExtractEvent()

This article discusses the way CPIC verbs in general complete
asynchronously and how two new API calls complete asynchronously.

MORE INFORMATION
================

Currently, CPIC verbs complete asynchronously by posting a message to a
window. There is one such window for each CPIC application. Each CPIC
conversation can have one asynchronous verb outstanding at any time. When a
verb completes, the posting to the window takes as parameters the CPIC
conversation ID of the verb which has completed, and the return code of the
verb.

This new specification addresses the new requirement to allow CPIC verbs
running on Win32 to complete asynchronously through events, in common with
the other SNA Server asynchronous interfaces.

The prototypes are:

   /* Set_Conversation_Event */
   VOID WinCPICSetEvent(unsigned char CM_PTR, /*conversation_ID*/
   CM_EVENT_HANDLE CM_PTR, /* event handle */
   CM_RETURN_CODE CM_PTR); /* return_code  */

The parameters for this verb are:

 - Conversation ID, which is the ID of the conversation for which this
   event is used.

 - Event handle, which is the handle of the event which is to be cleared
   when an asynchronous verb on the conversation completes. This parameter
   can replace an already-defined event, or remove an already-defined event
   (by having NULL as the parameter).

 - Error code, which returns the error PROGRAM_PARAMETER_CHECK if
   any of the parameters are invalid.

Prototypes continued:

   /* Extract_Conversation_Event */
   VOID WinCPICExtractEvent(unsigned char CM_PTR /*conversation_ID*/
   CM_EVENT_HANDLE CM_PTR, /* event handle */
   CM_RETURN_CODE CM_PTR); /* return_code  */

The parameters for this verb are:

 - Conversation ID, which is the ID of the conversation for which the event
   handle is being extracted.

 - Event handle, which returns the event handle being used by this
   conversation. If no handle has been registered, it returns NULL.

 - Error code, which returns the error PROGRAM_PARAMETER_CHECK if any of
   the parameters are invalid.

When a verb is issued on a non-blocking conversation, it returns
CM_OPERATION_INCOMPLETE if it is going to complete asynchronously. If an
event has been registered with the conversation, then the application can
call WaitForSingleObject() or WaitForMultipleObjects() to be notified of
the completion of the verb. Once the verb has completed, the application
must then call cmwait() to determine the return code for the asynchronous
verb.

If no event has been registered, then the asynchronous verb completes as it
does at present, which is by posting a message to the window which the
application has registered with the CPIC library.

It is the responsibility of the application to reset the event, as it is
with other APIs.

An application can discover the event handle being used for a CPIC
conversation with the call WinCPICExtractEvent().

Internal Changes:

Asynchronous event completion inside the CPIC library is done by a macro
COMPLETE_ASYNC_VERB. This is changed to first check whether there is an
event handle associated with the conversation. If there is, it clears this
event. If there is not, it posts a message to a window as before.

The conversation control block is changed to have a field to contain the
event.

Microsoft has updated the following files to add the two new Win32 CPIC API
calls:

   LIBS\WIN32\WCPIC32.DLL
   LIBS\WINB32\WCPIC32.LIB
   LIBS\WIN32\WINCPIC.DLL
   LIBS\WIN32\WINCPIC.LIB
   LIBS\WIN32\SNATRC.DLL
   LIBS\WIN95\SNATRC.DLL

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ TPSTART Enhanced to Support 16-bit Windows Applications
Article ID: Q140609
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

When you attempt to invoke a 16-bit Windows application with TPSTART.EXE,
the invokable transaction program (TP) application program starter for SNA
Server Windows NT clients, the following errors occur:

 - On Windows NT 3.5:

      16-bit Windows subsystem
      NTVDM encountered a system error. Access is denied

      Choose close to terminate the app, or ignore to continue

   After pressing Ignore, this popup occurs 10-12 times. After choosing
   Ignore each time, the application finally starts. However, subsequent
   attempts to autostart the application fail.

 - On Windows NT 3.51:

      TPSTART.EXE calls CreateProcess properly, but it receives an Error 5
      (ACCESS_DENIED).

CAUSE
=====

TPSTART.EXE does not support the startup of 16-bit Windows applications.

The TPSTART.EXE program is setting the DETACHED_PROCESS flag when calling
CreateProcess, which causes the startup of 16-bit Windows applications to
fail with ACCESS_DENIED. This problem does not occur when starting 32-bit
Windows applications, even though the 32-bit application is not a detached
process.

Also, if the TP is configured as queued (with SNAServiceType=5), SNA Server
does not detect that the application has ended since the default Windows NT
virtual DOS machine (VDM) is still running. This causes a second invocation
of the TP to fail.

RESOLUTION
==========

Microsoft has updated the file <snaroot>\SYSTEM\TPSTART.EXE to correct this
problem.

To support autostarting of 16-bit Windows applications, the following new
TP-specific registry settings are now supported under the subtree
HKEY_LOCAL_MACHINE under the subkey:

   /SYSTEM/CurrentControlSet/Services/SnaBase/Parameters/TPs/<tpname>/
   Parameters/

Add following information:

   Value Name: Win16App
   Data Type:  REG_SZ
   Data:       YES

The following entry under the same subkey is also required to autostart 16-
bit Windows applications:

   Value Name: SeparateWowVDM
   Data Type:  REG_SZ
   Data:       YES

This causes TPSTART.EXE to start the 16-bit application in its own Windows
NT VDM. This entry is required if TP is queued (where SNAServiceType=5). If
the TP is configured as queued, and SeparateWowVDM is not set to YES, then
the TP is only invoked once. Subsequent attempts to start the TP fail,
because according to SNA Server the TP is still running, because SNA Server
finds that the Windows NT VDM (NTVDM) process ID is still running.
Starting a separate NTVDM corrects this problem because the NTVDM process
ends when the 16-bit Windows application ends.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11

K # + K $ New Mechanisms for Enabling Tracing on a Window 3.x Client
There are two methods you can use to enable tracing, WINTRACE.EXE, a GUI trace utility, or TRACES.TXT, an example tracing file.
SNA Windows 3.x Trace Utility (WINTRACE)
Article ID: Q140828
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.0, 2.1, and 2.11
------------------------------------------------------------------------

SUMMARY
=======

Previously, you had to manually edit the WIN.INI file to enable tracing on
the SNA Server Windows 3.x client. The new utility, WINTRACE.EXE, allows
you to select what type of tracing you want to enable thru a GUI interface
without having to load the WIN.INI file into an editor such as Notepad. The
new WINTRACE utility is located on the CD in the Clients\Win3x\Wintrace 
subdirectory and can be installed by running Setup from this location.

For more information on client side tracing see Chapter 13 of the "SNA
Server Administration Guide."

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv ntutil
Additional reference words: prodsna 2.00 2.10 2.11 tracing win3x trace

Windows 3.x Tracing Text File
Article ID: Q140838
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
-------------------------------------------------------------------------

SUMMARY
=======

During installation of an SNA Server Win3x client, the TRACES.TXT file is
installed to the <SNA_Win3x_root>\ directory. When troubleshooting, this
allows you to quickly enable client-side tracing by adding the needed
entries by cutting and pasting from that file because the file is already
on the client computer. (This eliminates the need to type the entries by
copying them from the SNA Server Administrator's Guide or having to have
access to the SNA Server compact disc that contains this file, too.)
The more information section shows the content of the TRACES.TXT file.

MORE INFORMATION
================

File contents of TRACES.TXT:

I. ENABLING SNA SERVER WIN3.X CLIENT TRACING:
=============================================

1. Load the WIN.INI file into a text editor.
2. Locate the [WNAP] section of the file.
3. Copy and Paste the following example trace entries to enable all tracing
options. Refer to page 259 of the SNA Server Administration Guide for
specific syntax conventions and tracing options.

;***********************************************************
;***************BEGINNING OF SNA SERVER TRACING*************
;***********************************************************

; FLIPLENGTH:
; [size in bytes] Controls how large each SNA Server trace
; file can grow (default: 250,000). If two trace file names
; are specified, SNA Server traces wrap between two trace
; files so the hard disk does not fill up.

Fliplength=250000

; TRACE FLUSHING:
; If you are investigating a problem that may cause your
; system to go down, be sure to include TraceFlushing=on, so ; that trace
information will be written to disk as soon as ; it is generated.
TraceFlushing=off disables trace
; flushing.

TraceFlushing=on

; INTERNAL TRACING:
; Enables activity within a software component of SNA
; Server. This applies to wnap.exe and SNA applications.
; Valid values are 0-16. 0 is full internal tracing while
; 16 disables internal tracing. NOTE: Refer to step
; 5 below for further instructions on internal tracing.

InternalTraceLevel=0
InternalTraceFile1=c:\int1.trc
InternalTraceFile2=c:\int2.trc

; MESSAGE TRACING:
; Traces messages passed into and out of a software
; component of SNA Server, including messages sent to and
; received from the SNA network. This applies to wnap and
; SNA applications.

InternalMessageTraceState=on
FMITraceState=on
PVITraceState=on
MessageTraceFile1=c:\msg1.txt
MessageTraceFile2=c:\msg2.trc

; API TRACING:
; Traces information passed into and out fo an SNA Server
; DLL, such as WINAPPC.DLL, as the DLL communicates with the
; application.

APITraceFile1=c:\api1.trc
APITraceFile2=c:\api2.trc

;APPC api tracing

APPCTraceState=on

;CSV api tracing

CSVTraceState=on

;RUE api tracing

RUITraceState=on

;HLLAPI api tracing

HLLAPITraceState=on

;CPIC api tracing

CPICTraceState=on

;***********************************************************
;***************END OF SNA SERVER TRACING ******************
;***********************************************************

4. Save the WIN.INI file as plain (ASCII) text (that is, avoid saving the
file in a special format specific to the text editor).

5. If Internal tracing is being enabled continue to step 6.

6. To enable Internal tracing:

a. On the client computer, back up the following files by copying them to a
different directory:

   WindowsRoot\SYSTEM\WDMOD.DLL
   WindowsRoot\SYSTEM\LMCLI.DLL
   WindowsRoot\SYSTEM\NWCLI.DLL
   WindowsRoot\SYSTEM\BVCLI.DLL
   WindowsRoot\SYSTEM\IPCLI.DLL
   SNAroot\WNAP.EXE

You will need to restore these files to their original location after you
finish with tracing on the client.

b. Access the installation medium (SNA Server CD or network share) for
client software:

To access the CD, insert it in a CD-ROM drive. To access the network share,
connect to it. (For information about how to create a share for
installation of clients over the network, see: Chapter 3 of the Microsoft
SNA Server Installation Guide.)

c. Change to the appropriate directory on the CD or network share:

On the CD, change to the \CLIENTS\WIN3X\TRACE directory.
On the network share, change to the \WIN3X\TRACE directory.

d. Copy the appropriate files to the hard disk of the client computer, as
described in the following table:

Type of tracing	Source file on or the CD or network share	Destination directory on the hard disk of the client compute	
Message or API	WDMOD.DLL	WindowsRoot\SYSTEM	
Internal	LMCLI.DLL	WindowsRoot\SYSTEM	
	NWCLI.DLL	WindowsRoot\SYSTEM	
	BVCLI.DL	WindowsRoot\SYSTEM	
	IPCLI.DLL	WindowsRoot\SYSTEM	
	WNAP.EXE	SNAroot	

Note that internal tracing is intended for the use of product-support
technicians; interpreting these traces requires a specialized knowledge
base.

e. Remove the CD from the drive, or disconnect from the network share.
f. Restart the SNA Server software and the Windows version 3.x software.

As trace files are created, they are stored in the path(s) specified by the
lines in the WIN.INI file.

II. DISABLING SNA SERVER WIN3.X CLIENT TRACING:
===============================================

1. Load the WIN.INI file into a text editor.
2. Locate the [WNAP] section of the file.
3. Add, modify, or remove lines under the [WNAP] section heading.
4. Save the WIN.INI file as plain (ASCII) text (that is, avoid saving the
file in a special format specific to the text editor).
5. Stop the SNA Server software and the Windows version 3.x software.
6. If Internal tracing was enabled, continue to step 7.

7. To disable Internal tracing:

a. Locate the copies of the files that were backed up during the preceding
procedure. The filenames are as follows:

   WDMOD.DLL
   LMCLI.DLL
   NWCLI.DLL
   BVCLI.DLL
   IPCLI.DLL
   WNAP.EXE

b.Copy the files to destination directions as follows:
Filename	Destination directory on the hard disk of the client computer	
WDMOD.DLL	WindowsRoot\SYSTEM	
LMCLI.DLL	WindowsRoot\SYSTEM	
NWCLI.DLL	WindowsRoot\SYSTEM	
BVCLI.DLL	WindowsRoot\SYSTEM	
IPCLI.DLL	WindowsRoot\SYSTEM	
WNAP.EXE	SNAroot	

c.Restart the SNA Server software and the Windows version 3.x software.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

 K # + K $ TN3270 Clients Do Not Accept "Do TN3270E"
Article ID: Q140829
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version  2.11
------------------------------------------------------------------------

SUMMARY
=======

"Do TN3270E" is a command sent from the TN3270E Server Service to the
TN3270 emulator during session initialization. It asks the TN3270 emulator
whether it can support the TN3270E protocol. Some TN3270 clients do not
accept the "Do TN3270E" message from the TN3270E server. This prevents
session establishment between the TN3270 client and TN3270E Server Service.
Sending the "Do TN3270E" command is a legal command according to RFC 1647."

RFC 1647 states the Following:

"Telnet clients and servers would be free to negotiate support of the
TN3270E option or not. If either side does not support TN3270E, traditional
TN3270 can be used; otherwise, a sub-negotiation will occur to determine
what subset of TN3270E will be used on the session. It is anticipated that
a client or server capable of both types of 3270 emulation would attempt to
negotiate TN3270E first, and only negotiate traditional tn3270 if the other
side refuses TN3270E."

SAMPLE TRACE
============

>12/08 11:18:16.828 (+ smidgen )  Event=TEV_Started

>12/08 11:18:30.217 (+ 13 secs )  Event=TEV_DataToClient
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 DO TN3270E
 Number of bytes = 3

>12/08 11:18:30.217 (+ smidgen )  Event=TEV_TCPSendIssued
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 Number of bytes = 3
 000000  fffd 28                                  !..(             !

>12/08 11:18:30.257 (+ 40 msecs)  Event=TEV_TCPRecvIssued
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4

>12/08 11:18:30.277 (+ 20 msecs)  Event=TEV_TCPSendCompleted
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 Bytes transferred = 3

>12/08 11:19:09.403 (+ 39 secs )  Event=TEV_TCPRecvCompleted
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 Bytes returned = 0

>12/08 11:19:09.423 (+ 20 msecs)  Event=TEV_SessionTerminationScheduled
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 NormalTermination

>12/08 11:19:09.463 (+ 40 msecs)  Event=TEV_SessionTermination
 Thread = 0x0000005E  Session = 0x0007A718  Socket = 0x000001B4
 Session terminated

RESOLUTION
==========

The TN3270E Server has a new registry entry that can be used to turn off
TN3270E support:

   Subtree:   HKEY_LOCAL_MACHINE
   Key:       \currentcontrolset\services\tn3270\parameters\NoTN3270E
   Type:      G_EXPAND_SZ
   Value:     ON

When this value is set to ON, the server reverts to being a TN3270 Server.
This registry setting effects all sessions; not just ones from TN3270
emulators.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

K # + K $ Username/Password Support in SNA Server Win95 Client Registry
Article ID: Q140834
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SUMMARY
=======

This article describes the update for SNA Server Windows 95 clients that
use a non-named-pipe transport (such as Banyan Vines, IPX/SPX, and TCP/IP
Sockets) and do not log on to a Windows NT domain.

When you configure a SNA Server Windows 95 client for a non-named pipe
transport SNA Server uses the Windows 95 cached password to validate users
for sponsor connections (A sponsor connection is used by SNA Server to
learn about the SNA Server domain.) However, if Windows 95 is not
configured to log on to a Windows NT domain, you must install the update
and provide  your SNA Server Windows 95 client registry with your Windows
NT domain username and password as explained below.

MORE INFORMATION
================

When to Use the Update
----------------------

The following conditions require you to install the update and configure
the Windows 95 client registry to supply a Windows NT domain username and
password:

 - If "Client for Microsoft Networks" is not listed in the Windows 95
   Control Panel Networks option.

   -or-

 - If, when you select "Client for Microsoft Networks", there is no check
   mark next to "Log on to Windows NT Domain".

Required Windows 95 Registry Entries
------------------------------------

The new update requires that you add new values and your Windows NT Domain
username and password to the Windows 95 registry.

You can add the required information under HKEY_CURRENT_USER or the
HKEY_LOCAL_MACHINE subtree. However, the Windows 95 client checks the
HKEY_CURRENT_USER first and therefore performs faster if you choose that
subtree. To add the information:

1. Under the HKEY_CURRENT_USER subtree (or the HKEY_LOCAL_MACHINE subtree),
   go to the following subkey:

      Software\Microsoft\SnaBase\Parameters

2. Add the following value names, data types, and data for your password
   and username:

      Value Name: Password
      Data Type:  REG_SZ
      Data:       <your_password>

      Value Name: UserName
      Data Type:  REG_SZ
      Data:       <your_user_name>

Updated Files
-------------

Microsoft has updated the following files:

   <SNA_Root>\SYSTEM\SNABASE.EXE
   <Windows_95_root>\SYSTEM\SNAKRNL.DLL

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack, 
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.11

 K # + K $ Windows 95 Client, Previously Available Only Through the Internet, Is Now Included
Article ID: Q000001
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11 with Service Pack 1
-------------------------------------------------------------------------

The SNA Server Windows 95 client, previously available only through the 
Internet, is now included on the Service Pack 1 compact disc for SNA Server 
for Windows NT, version 2.11.

K # + K $ Distributed Link Service
Article ID: Q000002
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11 with Service Pack 1
-------------------------------------------------------------------------

The Distributed Link Service provides a method for an SNA Server to connect 
with a host using a linkservice installed on another SNA Server. This 
feature includes the following:

 - It allows multiple SNA Servers to share a single adapter (such as a 
   channel adapter).

 - It supports load balancing across multiple Distributed Link Services.

 - It supports hot backup because the Distributed Link Service can select 
   alternate remote servers when a remote link fails.

 - It allows a branch SNA Server to connect to the host over a wide area 
   network (WAN ) supporting only a routable internetworking protocol such 
   as TCP/IP, rather than requiring an SNA WAN protocol such asSDLC or 
   bridged DLC.

$ # K Domain/Server Command Line Parameter Added to SNAADMIN
Article ID: Q141906
------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11a
------------------------------------------------------------------------

SUMMARY
=======

The SNA Server Administration utility has been enhanced to allow you to specify the domain or server you wish to administer using a command line parameter.

MORE INFORMATION
================
You can use SNA Admin to view a remote SNA Server or subdomain by using the /NET option to specify the server or subdomain name on the SNAADMIN command line. You can use the command line in a Program Manager program item or in a shortcut to provide a quick way to view a remote subdomain.
No validation is done on the given name.  If admin fails to connect, then the appropriate error message box is eventually shown.  If the string "/NET:" is incorrectly typed, then the message "Configuration file not found" is displayed. This same message is also displayed for any other syntax error on the command line.

The complete command line syntax is:
		SNAADMIN [/NO3D] [/READONLY]
		SNAADMIN [/NO3D] [/READONLY] /OFFLINE
		SNAADMIN [/NO3D] [/READONLY] OfflineConfigFile
		SNAADMIN [/NO3D] [/READONLY] /NET:Subdomain
		SNAADMIN [/NO3D] [/READONLY] /NET:\\Server
Parameters
	/NO3D
		 Avoids using CTL3D.DLL in case of difficulties with the installation of this shared DLL
	/READONLY
	Opens the selected subdomain in read-only mode, even if no other SNA Admin is active in that sub-domain.  Readonly mode permits you to control existing SNA Services (eg, start and stop connections), but not to change the configuration (eg, define new connections).
	/OFFLINE
	Opens a config file in offline-configuration mode, providing a file-selection dialog box to let you browse for the config file
OfflineConfigFile
	Specifies a configuration file to be opened in offline-configuration mode
/NET
	Specifies a remote SNA Server subdomain, either by name or by member server
Examples
	SNAADMIN browses the local subdomain 
SNAADMIN /NET:\\TRUTH browses the SNA subdomain of which server \\TRUTH is a member
SNAADMIN /NET:SYS-SNA browses the SNA subdomain SYS-SNA
SNAADMIN \\TRUTH\COMCFG\COM.CFG opens in offline configuration mode the config file whose UNC path is \\TRUTH\COMCFG\COM.CFG

K # + K $ TN3270E Support Added to the TN3270 Service of SNA Server
Article ID: Q139035
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11 with Service Pack 1
-------------------------------------------------------------------------
SUMMARY
=======
The TN3270 Service of SNA Server now supports the TN3270E protocol as
specified by RFC 1647. The new TN3270 Service adds support for the
following:

 - LU1 and LU3 printing.
 - The ability to associate a printer LU with a display LU.
 - The ability for a client to request connection to a specific LU or LU
   pool.
 - Standardized access to the SSCP-LU session.
 - Standardized support for the ATTN and SYSREQ keys.

MORE INFORMATION
================

These new TN3270E features are supported through the configuration tool.
See the Help file for additional information on configuring the new
features of the TN3270 Service.

The enhanced TN3270 Service relies on enhancements provided by the latest
SNA Server 2.11 Service Pack. You must install the Service Pack before
installing the enhanced TN3270 Service.

NOTE: Do not attempt to edit the TN3270 Service configuration file
directly; doing so can cause unpredictable results.

NOTE: Although you can still connect to the SNA Server TN3270 service with
a TN3270 client, you need a TN3270E client to make use of the TN3270E
features.

STATUS
======

This feature is included in the latest U.S. Service Pack for SNA Server for
Windows NT, version 2.11. For information on obtaining the Service Pack,
query on the following word in the Microsoft Knowledge Base (without the
spaces):

   S E R V P A C K

KBCategory: kbnetwork
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.00 2.10 2.11

K # + K $ SNA Remote Access Service Client May Not See Remote Network
Article ID: Q139300
----------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, version 2.11
----------------------------------------------------------------------
SYMPTOMS
========

When you are using SNA Remote Access Service (RAS), your SNA Server Windows
NT client is not able to see servers on the remote network and the
following error message appears when you attempt to issue the command
NET VIEW \\<server_name>, where <server_name> is a server on the remote
network:

   System error 53 has occured.
   The system path was not found.

The local SNA Server of the SNA Server Windows NT client can view servers
on the remote network.

CAUSE
=====

The following configuration can cause this problem:

An SNA Server NT client is running SNA Remote Access Service connected to a
local SNA Server over a LAN connection. The local SNA Server is then
connected to a Front End Processor. The Front End Processor is then
connected to a remote SNA Server running SNA Remote Access Service.

RESOLUTION
==========

On the SNA Server Windows NT client, add the LinkSpeed parameter in the
registry:

1. Go to the HKEY_LOCAL_MACHINE subtree under the following subkey:

      SOFTWARE\Microsoft\RAS\OTHER DEVICES\CONFIGURED\SnaRas\

2. Add the following:

      For Value Name: LinkSpeed
      For Data Type:  REG_DWORD
      For Data:       <value>

   where <value> is the baud rate of the local SNA Server link to the FEP.
   Valid values are: 2400, 4800, 9600, etc.

If the above registry entries do not correct the problem, change the
AuthenticateTimeout registry parameter:

1. Go to the HKEY_LOCAL_MACHINE subtree under the following subkey at both
   the RAS server and client:

      SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\

2. Set the AuthenticateTimeout parameter to 240 (decimal).
   (The default is 120.)

3. Reboot.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNARAS.DLL
   <snaroot>\SYSTEM\RASSNA.DLL
   <snaroot>\SYSTEM\TRCRAS.DLL
   <snaroot>\SYSTEM\TRCSNA.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.00 kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11 3.50 3.51

K # + K $ SNA Server Fails to Release Memory in SNA TCP/IP Interface DLL
Article ID: Q142037
-------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft SNA Server for Windows NT, versions 2.1 and 2.11
-------------------------------------------------------------------------

SYMPTOMS
========

A Windows NT Server running SNA Server 2.11 slows down when running SNA
Server clients that use TCP/IP.

This problem occurs sporadically.

CAUSE
=====

An SNA Server Service internal trace shows that SNA Server TCP/IP
asynchronous writes are not completing. These pending writes continue to
consume system memory. The SNA Server client configured for TCP/IP may
continuously attempt to open a session with the SNA Server. The SNA Server
tries to send a response but the write never completes and is unable to
release the i/o (input/output) buffer memory.

RESOLUTION
==========

SNAIP.DLL now aborts a connection if the connection has more than 100
pending writes queued. Every time a connection is aborted, an event 706 is
logged in the application log:

   Event Id: 706

   Description:
   Connection to client %2 has been aborted due to too many (%1) pending
   writes.

   Explanation

   SNA Server has aborted a TCP/IP connection because asynchronous writes
   queued on the connection have not completed.

   ACTION

   Provide network support personnel with the event log file(s) related to
   SNA, and SNA internal trace file(s). For information about SNA log and
   trace files, see the "Microsoft SNA Server Administration Guide."

You can configure the abort limit through the MaxPendingWrites registry
parameter under the HKEY_LOCAL_MACHINE subtree under the following subkey:

   System\CurrentControlSet\Services\SnaBase\Parameters\SnaTcp

The MaxPendingWrites parameter has the following Data Type and Data:

   Data Type: REG_DWORD
   Data:      <value> (decimal)

With the updated SNAIP.DLL installed, the default value is 100 (decimal).

This feature can be disabled by setting the MaxPendingWrites to 0. 
If the value is zero, snaip.dll will never abort a connection, regardless of 
the number of pending writes.

Microsoft has updated the following files to correct this problem:

   <snaroot>\SYSTEM\SNAIP.DLL
   <snaroot>\SYSTEM\SNAEVENT.DLL

STATUS
======

Microsoft has confirmed this to be a problem in SNA Server for Windows NT.
This problem was corrected in the latest SNA Server for Windows NT, 2.11
U.S. Service Pack. For information on obtaining the Service Pack, query on
the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K

KBCategory: kbnetwork kbbug2.10 kbbug2.11
KBSubcategory: ntnetserv
Additional reference words: prodsna 2.10 2.11