SNA Server 2.11 Service Pack #1 Contents
Microsoft® SNA Server 2.11 Service Pack 1 Contents

Microsoft SNA Server version 2.11 Service Pack #1 enhances SNA Server  version 2.11 and SNA Workstation version 2.11 with a number of bug fixes, new features, and enhancements to existing features. To print the contents of the entire Help file, in Microsoft Word open the SNASP1.RTF file that is included on the CD-ROM in the same directory as this Help file, and choose Print from the File menu.

Installation Instructions

Bug Fixes

Enhancements to Existing Features

New Features

SNA Server Licensing Information

Corrections and Additions to SNA Server Documentation

New White Papers, Case Studies, and other Collateral

Additional Information


SNA Server 2.11 Service Pack #1 Installation Instructions
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 x0050

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 Availability

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


Additional New Link Services
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


SNA Server 2.11 Licensing Information
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 Reviewers 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 purchasers 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


Changes to SNA Server 2.11 Documentation
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.


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 about SNA Server 2.11
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


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.

Reviewers Guide

SNA Server 2.11 Reviewer's Guide, Microsoft SNA Server 2.11 Test Drives for the Reviewers Guide, and Microsoft SNA Server 2.11 Demo Script Test Drives for the Reviewers 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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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:


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


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


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


TN3270E Print Job Hangs in Print Manager
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


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


Emulator Disconnected after FMI Error Code x0050

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


SNA Server 2.11 Performance Improvements for 3270/LUA Apps
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


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


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


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


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


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


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


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


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


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


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


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


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


SNA Windows 3.x Trace Utility (WINTRACE)
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


 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


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


The Windows 95 Client, Previously Available Only Through the Internet, Is Now Included
 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.


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.


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


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


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


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