Copyright: Planning Guide
Citation: Planning Guide


Microsoft SNA Server Master Table of Contents
Microsoft SNA Server

Master Table of Contents

	SNA Server Enhancements Guide
	SNA Server Installation Guide
	SNA Server Administration Guide
	Managing Microsoft SNA Server
	SNA Server Planning Guide
	SNA Server TN3270 Service
	3270/5250 Applet User's Guide
	SNA Server Reference
	SNA Server Glossary
	APPC Programmer's Guide
	CPI-C Programmer's Guide
	LUA Programmer's Guide
	SNA Device Interface Specification
	3270 Emulator Interface Specification
	Comprehensive Index


Planning Guide Contents
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Before You Begin
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

How to Use This Guide

Document Conventions

Common Abbreviations

Finding Further Information

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Before You Begin
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 1
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

SNA Server: Network Overview

Basic Concepts

Communication Between Clients and SNA Servers

Communication Between SNA Servers

Communication Between SNA Servers and Host Computers: Connections

3270 Users Connecting to a Mainframe

5250 Users Connecting to an AS/400

Finding Further Basic Information

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 2
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Centralized and Branch Configurations

Deciding About Domains and Server Roles

Deciding Whether to Create a Separate Domain

Deciding About Domain Controllers (Logon Servers)

Deciding About Primary, Backup, and Member SNA Servers

Choosing and Setting Up Network Protocols on SNA Servers

Network Protocol Choices for SNA Servers

Interfaces for Specifying Network Protocol Choices

Network Protocols Used for Client-Server Communication

Network Protocols Used for Server-Server (Broadcast) Communication

Finding Additional Information About Client-Server Protocols

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 3
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Variables that Affect Hardware Requirements

Evaluating Demand and Performance on an SNA Server

Performance Monitor

Studying and Understanding Performance Data

Useful Performance Counters on SNA Servers

Viewing Explanation Text in Performance Monitor

Status Information in SNA Server Admin

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 4
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Overview of Connections

Settings to Check for Connections

Settings to Check on All Connections

Settings to Check on 802.2 Connections

802.2 Adapters and Link Services: Installation Pointers

802.2 Connections: Configuration Pointers

802.2 Connections: Troubleshooting

Settings to Check on SDLC Connections

SDLC Adapters and Link Services: Installation Pointers

SDLC Connections: Configuration Pointers

SDLC Connections: Troubleshooting

Settings to Check on X.25 Connections

X.25 Adapters and Link Services: Installation Pointers

X.25 Connections: Configuration Pointers

X.25 Connections: Troubleshooting

Settings to Check on Channel, DFT, and Twinax Connections

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 5
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Configuring for 3270 with Hot Backup Across Servers

Connections for 3270 with Hot Backup Across Servers

Host Settings Corresponding to Example

LUs for 3270 with Hot Backup Across Servers

3270 LUs on the Second Server

LU Pools for 3270 with Hot Backup Across Servers

Users and Groups for 3270 with Hot Backup Across Servers

Completing the Configuration

Configuring for 3270 with Hot Backup Across Connections

Connections for 3270 with Hot Backup Across Connections

Token Ring Connection for Hot Backup Across Connections

SDLC Connection for Hot Backup Across Connections

Host Settings Corresponding to Example

LUs for 3270 with Hot Backup Across Connections

3270 LUs on the Second Connection

LU Pools for 3270 with Hot Backup Across Connections

Users and Groups for 3270 with Hot Backup Across Connections

Completing the Configuration

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 6
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Configuring for 5250 with Hot Backup Across Servers

Viewing User and Computer Names of 5250 Users

Server Settings for 5250 with Hot Backup Across Servers

Local LUs for 5250 with Hot Backup Across Servers

Local LU on the Second Server

Connections for 5250 with Hot Backup Across Servers

Connection on the Second Server

AS/400 and SNA Server Settings (for Servers and Connections)

Remote LUs for 5250 with Hot Backup Across Servers

Remote LU on the Second Server

Users and Groups for 5250 with Hot Backup Across Servers

Completing the Configuration

Configuring for 5250 with LU Names Based on User Names

Users and Groups for 5250 (Multiple LU Example)

Server Settings for 5250 (Multiple LU Example)

Connection for 5250 (Multiple LU Example)

AS/400 and SNA Server Settings (for Server and Connection)

Remote LU for 5250 (Multiple Local LU Example)

Local LUs for 5250 (Multiple LU Example)

Saving and Backing Up the Configuration Before Exiting

Using snacfg to Create Multiple Local LUs

Using snacfg to Assign LUs to Each User

Viewing the Completed Configuration

Software and Configurations on AS/400 Clients

5250 Clients Using Direct Windows APPC or EHNAPPC

AS/400 Clients Using PC Support

AS/400 Clients Using the NetSoft Router

AS/400 Clients Using CA/400

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Chapter 7
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Overview of Downstream Connections and LUs

Overview of the Example Configuration

Connections for Support of Downstream Systems

Host Connection: SDLC

Host Settings Corresponding to Example

Downstream Connections: Token Ring

Second Token Ring Connection

Additional Token Ring Connections

Creating Downstream LUs on the Host Connection

Downstream Pools: Another Option

Associating Downstream LUs with Downstream Connections

Creating More Associations Between LUs and Connections

Adjusting the Numbering of Downstream LUs

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Appendix A
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Overview of Network Protocols for Clients

Client Logons and the Storing of Passwords

Types of Client Logons

Simplifying Logon on Clients Not Using Microsoft Networking

Error Message 546 on a Client

Important SNA Server Setup Options

Important Setup Options on an SNA Server

Important Setup Options on a Client

Adjusting Clients Running Windows for Workgroups

Domain and Password Settings for Clients Running Windows for Workgroups

Domain Settings with Windows for Workgroups

Password Settings with Windows for Workgroups

SYSTEM.INI Setting for Clients Running Windows for Workgroups

Details About How Clients Use Protocols

Clients Using Microsoft Networking (Named Pipes)

Clients Using NetWare (IPX/SPX)

Checklist for Clients Using NetWare (IPX/SPX)

Clients Using Banyan VINES IP

StreetTalk Naming System

Checklist for Clients Using Banyan VINES IP

Clients Using TCP/IP

Specifying Local or Remote Client Information with TCP/IP

Clients Using AppleTalk

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Appendix B
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Event 23 on an SNA Server

Event 182 on an SNA Server

Event 230 on an SNA Server

Event 2001 on an SNA Server

Error Message 546 on a Client

User Rights to Access a Server from the Network

Memory Problems on Client Systems

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables


Planning Guide Contents, Appendix C
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Maximizing Throughput on SNA Servers

Optimizing Background Processing on SNA Servers

Figures and Tables

Figures

Tables


Planning Guide Contents, Figures
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Client Request, Sponsor Connection, and Locating of Needed Server

3270 Users Connecting Through SNA Server to a Mainframe

5250 Users Connecting Through SNA Server to an AS/400

Centralized Plan

Noncentralized (Branch) Plan

One Protocol for All Communication Between Servers and Clients

Two Protocols (Microsoft Networking and IPX/SPX) in a Domain

Three Protocols (Microsoft Networking, TCP/IP, and IPX/SPX) in a Domain

Select Client/Server Protocols Dialog Box (Accessed through SNA Server Setup)

Server Broadcasts Dialog Box (Accessed through SNA Server Admin)

SNA Server Hardware Requirements in Relation to Usage and Number of Users

Summary of Important Elements in Connections

Using 3270 LU Pools to Provide Hot Backup Across Servers

Providing Sessions when One Server is Down

Example Configuration: Servers and Connections Window

Example Configuration: Connection Properties Dialog Box

Example Configuration: SDLC Setup Dialog Box

Example Configuration: Servers and Connections Window

Example Configuration: Insert LU Dialog Box

Example Configuration: Add LU Range Dialog Box

Example Configuration: 3270 LU Range Properties Dialog Box

Example Configuration: New Pool Dialog Box

Example Configuration: New Pool Dialog Box

Example Configuration: Windows Enlarged for Drag-and-Drop

Example Configuration: LUs Selected for Drag-and-Drop

Example Configuration: Drag-and-Drop of LUs Onto Pools

Example Configuration: Pool Containing LUs

Example Configuration: Add Users and Groups Dialog Box

Example Configuration: Users and Groups Window with New Groups

Example Configuration: Drag-and-Drop of Pools Onto Groups

Using 3270 LU Pools to Provide Hot Backup Across Connections

Providing Sessions when One Connection is Down

Example Configuration: Servers and Connections Window

Example Configuration: Connection Properties Dialog Box

Example Configuration: 802.2 Setup Dialog Box

Example Configuration: Connection Properties Dialog Box

Example Configuration: SDLC Setup Dialog Box

Example Configuration: Servers and Connections Window

Example Configuration: Insert LU Dialog Box

Example Configuration: Add LU Range Dialog Box

Example Configuration: 3270 LU Range Properties Dialog Box

Example Configuration: New Pool Dialog Box

Example Configuration: New Pool Dialog Box

Example Configuration: Windows Enlarged for Drag-and-Drop

Example Configuration: LUs Selected for Drag-and-Drop

Example Configuration: Drag-and-Drop of LUs Onto Pools

Example Configuration: Pool Containing LUs

Example Configuration: Add Users and Groups Dialog Box

Example Configuration: Users and Groups Window with New Groups

Example Configuration: Drag-and-Drop of Pools Onto Groups

How APPC Elements Map to a 5250 Configuration

Providing Support for 5250 with Hot Backup Across Servers

Providing 5250 Sessions when One Server is Down

Example Configuration: Servers and Connections Window

Specifying Names on One Server for Support of 5250

Specifying Names on a Second Server for Support of 5250

One Local APPC LU for 5250 with Hot Backup

Two Local LUs for 5250 with Hot Backup Across Servers

Example Configuration: Connection Properties Dialog Box

Example Configuration: SDLC Setup Dialog Box

One Remote APPC LU for 5250 with Hot Backup

Two Remote LUs for 5250 with Hot Backup Across Servers

Example Configuration: Add Users and Groups Dialog Box

Example Configuration: Users and Groups Window with New Group

Example Configuration: LU Aliases Assigned to a Group

Example Configuration: Add Users and Groups Dialog Box

Example Configuration: Users and Groups Window with New Users

Example Configuration: Servers and Connections Window

Specifying Names on One Server for Support of 5250

Example Configuration: Connection Properties Dialog Box

Example Configuration: 802.2 Setup Dialog Box

Remote APPC LU for 5250 (Multiple Local LUs Example)

One Local APPC LU for 5250 with Hot Backup

Using snacfg to Create Multiple LUs

Configuration Containing Multiple Local LUs, One for Each User

Communication with a Downstream System

Using Correct Identifiers and Max BTU Lengths

Downstream Systems Connecting Through an SNA Server

Steps for Creating a Configuration that Supports Downstream

Example Configuration: Servers and Connections Window

Example Configuration: Connection Properties Dialog Box

Example Configuration: SDLC Setup Dialog Box

Example Configuration: Connection Properties Dialog Box

Example Configuration: 802.2 Setup Dialog Box

Example Configuration: Insert Connection Dialog Box

Example Configuration: Connection Properties Dialog Box

Example Configuration: 802.2 Setup Dialog Box

Example Configuration: Servers and Connections Window

Example Configuration: Insert LU Dialog Box

Example Configuration: Add LU Range Dialog Box

Example Configuration: Downstream LU Range Properties Dialog Box

Example Configuration: Assign Downstream LU/Pool Sessions Dialog Box

Example Configuration: Downstream Connection and Associated Downstream LU

Example Configuration: Downstream Connection and Associated Downstream LU

Example Configuration: Creating an Empty Pool as a Placeholder

Example Configuration: Three Empty Pools Created as Placeholders

Example Configuration: Assign Downstream LU/Pool Sessions Dialog Box

Example Configuration: Three Empty Pools Selected

Example Configuration: Three Pools and One LU Assigned to a Connection

Example Configuration: Changing the Order of Selected LU Sessions

Example Configuration: Downstream LU Number Corrected for DOWN1

Example Configuration: Upstream LU Numbers Unchanged

Tables


Planning Guide Contents, Tables
Microsoft SNA Server

Planning Guide

Contents

Before You Begin

Understanding Licensing Options

Part 1    Basics

Chapter 1    Introduction to SNA Server

Chapter 2    Server Placement and Protocol Choices

Part 2    Planning the Hardware for an SNA Server Installation

Chapter 3    Basic Methods for Evaluating Hardware Requirements

Part 3    Creating the SNA Server Configuration

Chapter 4    Establishing a Connection Successfully

Chapter 5    Examples of Configurations for 3270

Chapter 6    Examples of Configurations for 5250

Chapter 7    Example of a Configuration for Downstream Connections

Part 4    Appendixes

Appendix A    Network Protocols and Client-Server Communication

Appendix B    Interpreting Events or Errors on SNA Servers or Clients

Appendix C    Options for Maximizing Communications Throughput

Figures and Tables

Figures

Tables

Identifying the Relevant Chapters and Appendixes of this Guide

Common Speeds for 802.2 Connections

Common Speeds for SDLC Lines

Finding Further Basic Information

Modifying Network Protocol Choices on an SNA Server

Recommendations for Selecting a Server-to-Server Transport Protocol

General Hardware Guidelines

Items to Consider When Configuring a Connection

Choices of Client Software for Use with Any Version of OS/400

Additional Choice of Client Software for OS/400 Version v3r1


How to Use This Guide
1 of 5

Before You Begin

The Microsoft SNA Server Planning Guide provides background information and example configurations to help you plan and implement an SNA Server installation. This guide is designed to supplement (but not replace) other guides such as the Microsoft SNA Server Installation Guide and the Microsoft SNA Server Administration Guide. This guide can lead you through the process of creating a basic configuration, such as one for 3270 with hot backup. The other documents in the SNA Server document set can then provide variations and additional details.


How to Use This Guide
Before You Begin	2 of 5

How to Use This Guide

The following table will help you identify the sections relevant to your situation:

Table 0.1    Identifying the Relevant Chapters and Appendixes of this Guide

Planning or decision stage you’re in	Relevant chapter
How to begin; how to approach the concepts needed for planning an SNA Server installation	Chapter 1, “Introduction to SNA Server”
Whether to centralize your SNA servers	Chapter 2, “Server Placement and Protocol Choices”
How to select and set up network protocols on  your SNA servers	Chapter 2, “Server Placement and Protocol Choices”
What hardware you’ll need	Chapter 3, “Basic Methods for Evaluating Hardware Requirements”
How to establish or troubleshoot a connection to a mainframe or AS/400	Chapter 4, “Establishing a Connection Successfully” Appendix B, “Interpreting Events or Errors on SNA Servers or Clients”
How to support 3270 users	Chapter 5, “Examples of Configurations for 3270"
How to support 5250 users	Chapter 6, “Examples of Configurations for 5250"
How to support downstream systems	Chapter 7, “Example of a Configuration for Downstream Connections"
How to ensure that clients can communicate with SNA servers	Appendix A, “Network Protocols and Client-Server Communication"
How to interpret some events or errors on SNA servers or clients	Appendix B, “Interpreting Events or Errors on SNA Servers or Clients"
How to tune a server dedicated to communications	Appendix C, “Options for Maximizing Communications Throughput”


Document Conventions
Before You Begin	3 of 5

Document Conventions

Throughout this manual, the following conventions distinguish elements of text.

Convention	Purpose

bold	Indicates syntax items that must be typed exactly as shown.

italic	Indicates variables.

monospace	Represents examples and program code.

SMALL CAPS	Represent return values and key names, such as CTRL.

UPPERCASE	Represents filenames, paths, volumes, array and structure names, values, and conversation states.

[brackets]	Enclose optional items in syntax statements.

{braces}	Enclose required items in syntax statements.

| (vertical bar)	Stands for OR and separates items in syntax statements.

... (ellipsis)	Indicates that the preceding syntax item can be repeated.  If a punctuation mark precedes the ellipsis, you must include the punctuation when repeating the item.

X'nnnn'	Indicates hexadecimal digits.


Common Abbreviations
Before You Begin	4 of 5

Common Abbreviations

The following is an alphabetical list of common abbreviations used in this manual. For definitions of these and other SNA terms, see the glossary in the Microsoft SNA Server Reference.

Abbreviation	Description

API	Application programming interface

APPC	Advanced Program-to-Program Communication

ASCII	American Standard Code for Information Interchange

BTU	Basic transmission unit

CPI-C	Common Programming Interface for Communications

CSV	Common Service Verb

CTS	Clear-to-send

DFT	Distributed function terminal

DLC	Data link control

DLL	Dynamic-link library

DSR	Data-set-ready

DTR	Data-terminal-ready

EBCDIC	Extended Binary Coded Decimal Interchange Code

EISA	Extended Industry Standard Architecture

FDDI	Fiber Distributed Data Interface

FEP	Front-end processor

IDE	Integrated Device Electronics

IEEE	Institute of Electrical and Electronics Engineers

IPX/SPX	Internetwork packet exchange/Sequenced packet exchange

K	Kilobyte

LU	Logical unit

LUA	Conventional Logical Unit Application programming interface

MB	Megabyte

NCP	Network Control Program

NRZ	Nonreturn to zero

NRZI	Nonreturn to zero inverted

PU	Physical unit

PVC	Permanent virtual circuit

QLLC	Qualified logical link control

RAID	Redundant Arrays of Inexpensive Disks

RAS	Remote Access Service

RTM	Response time monitor

RTS	Request-to-send

RU	Request/response unit

RUI	Request Unit Interface

SAP	System access point

SCSI	Small computer system interface

SDLC	Synchronous Data Link Control

SID	Security ID

SLI	Session Level Interface

SNA	Systems Network Architecture

SQL	Structured query language

SSCP	System services control point

SVC	Switched virtual circuit

TCP/IP	Transmission Control Protocol/Internet Protocol

TP	Transaction program

VTAM	Virtual Telecommunications Access Method

WAN	Wide area network


Finding Further Information
Before You Begin	5 of 5

Finding Further Information

For more information about SNA Server, see the following manuals:

Microsoft SNA Server Installation Guide

Microsoft SNA Server Administration Guide

Microsoft SNA Server Reference

For more information about SNA and about 3270 information display systems, see the following manuals:

IBM 3270 Information Display System: 3274 Control Unit Description and Programmer’s Guide

IBM 3270 Information Display System: Color and Programmed Symbols

IBM 3270 Information Display System: 3274 Control Unit Display Station: Operator’s Guide

IBM Systems Network Architecture: Technical Overview

IBM Systems Network Architecture: Concepts and Products

IBM Advanced Communications Function Products Installation Guide

IBM Installation and Resource Definition

IBM 9370 LAN Token Ring Support

IBM SNA Format and Protocol Reference Manual: Architectural Logic

For more information about LU 6.2, APPC, and/or CPI-C, see the following manuals:

Microsoft SNA Server APPC Programmer’s Guide

Microsoft SNA Server CPI-C Programmer’s Guide

IBM Systems Network Architecture: Introduction to APPC

IBM Systems Network Architecture: Transaction Programmer’s Reference Manual for LU Type 6.2

IBM SNA: Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2

IBM SNA: Formats

IBM SNA: Technical Overview

IBM SNA: ACF/VTAM Programming for LU Type 6.2


Understanding Licensing Options
1 of 1

Understanding Licensing Options

During installation of SNA Server, you will be prompted to choose a licensing mode for your SNA servers: Per Seat or Per Server. This section outlines the differences between the two licensing modes. For more detailed information about licensing, consult with your Microsoft software provider.

Per Seat

This mode is oriented toward the number of SNA Server clients (or downstream systems) in your installation. For this mode, you must purchase a Client Access License for each client computer (or downstream system) that will access one or more SNA servers. The number of Client Access Licenses you purchase reflects the number of client or downstream computers (“seats”) in your installation, regardless of how many people use those computers or whether those computers all access an SNA server at the same time.

Per Server

This mode is oriented toward the maximum number of client-connections (or downstream connections) that will be made to an SNA server at a given time. To use this mode with a given SNA server, you must purchase as many Client Access Licenses as the maximum number of clients (or downstream systems) that will connect to that SNA server at any point in time. In other words, each Client Access License allows one additional concurrent client-connection (or concurrent downstream connection) to that SNA server.

Notice that with SNA servers configured to provide hot backup and load balancing, the number of clients supported by an SNA server may vary widely from hour to hour. The following example shows how the licenses work in this situation. It is not intended as a recommendation for purchasing either mode of license, but only as a description of how the licenses work with hot backup.

For example, consider an installation where two SNA servers support a total of 400 users, and the SNA servers are configured to provide hot backup for each other. If both servers are running, each will be used by about 200 clients. However, if one server goes down, the other may soon be supporting all 400 clients (if they are all requesting SNA sessions). To license such an installation in Per Seat mode, you would purchase 400 Client Access Licenses, and it would not matter how the client load shifted between servers. To license such an installation in Per Server mode, if you expected that either server might support 400 clients from time to time, you would purchase 400 Client Access Licenses for each of the two servers, or a total of 800 Client Access Licenses. The 800 licenses would cover all situations in which one server or the other went down.

In this example, more licenses would be needed with Per Server mode than with Per Seat. In other situations, for example, an installation with 100 workers distributed over two shifts so that only 50 SNA sessions are required per shift, the mode requiring the least licenses would be Per Server. Use the preceding guidelines to evaluate how each licensing mode would work at your installation.


Introduction to SNA Server
Chapter 1	1 of 9

Introduction to SNA Server

Microsoft SNA Server is a server process that runs on the Microsoft Windows NT [image] Server operating system. SNA Server acts as an SNA gateway that connects LAN-based PCs with IBM mainframes or AS/400 systems, which use IBM SNA protocols. SNA Server handles all translation back and forth between LAN protocols (such as TCP/IP and IPX) and SNA protocols; this frees client PCs from having to contain and use the SNA protocols.

The bidirectional communication provided by SNA Server includes support for 3270 and 5250 terminal emulation, printer emulation, file transfer, and program-to-program communications. SNA Server supports client functions on all popular PC operating systems, including Windows NT [image], Windows [image], MS-DOS [image], OS/2 [image], UNIX [image], and Macintosh [image]. SNA Server provides this connectivity with a broad set of features that includes:

Complete compatibility with existing Novell [image] Network protocols, cards, and drivers.

Familiar and easy-to-use graphical interface for installation, administration, and troubleshooting.

Complete SNA protocol support (LU and PU protocols, datalink protocols).

Complete SNA API support — APPC, CPI-C, LUA, and CSV, along with HLLAPI. (All APIs are included in SNA Server, except HLLAPI, which should be obtained through third-party vendors.)

The highest capacity of any SNA gateway (for sessions and clients and for servers per domain).

Centralized and remote administration, including administration via IBM NetView [image] and RAS (Remote Access Service).

Support for both centralized and branch configurations.

The greatest security of any SNA gateway (SNA Server is designed to meet C2level security).

Load balancing, hot backup, and other fault-tolerance features.

Support for every key corporate desktop system and LAN protocol (including IPX/SPX and TCP/IP).

Open, modular, extensible architecture.

A design that is scalable, multiplatform, and compatible with symmetric multiprocessing (SMP).

Complete context-sensitive help and online documentation.

Complete functionality provided in one package.

SNA Server offers PC users reliable and secure access to IBM host computing with the familiar user interface of desktop PCs and the flexibility of modern LAN systems.


SNA Server: Network Overview
Introduction to SNA Server	2 of 9

SNA Server: Network Overview

By using advanced client-server architecture to distribute the communications processing, SNA Server maximizes the power of your host computers and desktop PCs. Each PC uses standard LAN protocols to connect to one or more SNA servers. The servers then provide shared links to host computers using SNA protocols. SNA Server carries the bulk of the communications workload, thus reducing the storage and processing requirements on desktop PCs.


Basic Concepts
Introduction to SNA Server	3 of 9

Basic Concepts

The following sections outline some basic concepts needed for understanding an SNA Server installation. They describe the elements of communication needed by a client connecting through an SNA server to a host (a mainframe or AS/400 system).


Communication Between Clients and SNA Servers
Introduction to SNA Server	4 of 9

Basic Concepts

Communication Between Clients and SNA Servers

When a client first makes a request for communication with the SNA network, it establishes an initial connection (the “sponsor” connection) with an SNA server. The “sponsor” server provides the client with all the names of SNA servers in the domain. From these names, the client tries servers at random until the requested LU or pool is located. Figure 1.1 illustrates the sponsor-connection process.

Figure 1.1    Client Request, Sponsor Connection, and Locating of Needed Server

SNA servers and clients keep track of the names of SNA servers in the domain through the SnaBase service (formerly known as the network access protocol or NAP). For clients, sponsor connections, together with the SnaBase, provide a view into the server domain.

Clients can communicate through a number of different LAN protocols: Microsoft networking (named pipes), IPX/SPX (the protocol used with NetWare), Banyan [image] VINES [image] IP, TCP/IP, or AppleTalk [image].

Important

In order for the different client-server protocols to be handled correctly by SNA Server, both clients and servers must have the network software and the SNA Server software installed correctly. For diagrams and background information, see Chapter 2, “Server Placement and Protocol Choices” and Appendix A, “Network Protocols and Client-Server Communication.” For installation instructions, also see the documentation for the software you are installing — Windows NT Server and the associated network software, SNA Server server software, network software on clients, and/or SNA Server client software. (For installation of clients using TCP/IP, use the installation instructions in Appendix A of this guide, which supersede the instructions in the Microsoft SNA Server Installation Guide.)

In addition, note that if you have clients running Windows for Workgroups version 3.11 that connect to SNA servers running Windows NT version 3.5 or 3.51, you may need to set an option in the SYSTEM.INI file on each client. For details, see “Adjusting Clients Running Windows for Workgroups” in Appendix A.


Communication Between SNA Servers
Introduction to SNA Server	5 of 9

Basic Concepts

Communication Between SNA Servers

SNA servers communicate with each other using mailslot or datagram broadcast messages to the domain. The SNA servers use the SnaBase service to keep track of server names and client names, and the names of available transaction programs (TPs, which are the programs used for communication through APPC or CPI-C).

Windows NT Server supports multiple protocols simultaneously, but there is no need to send the same SNA Server broadcasts over multiple protocols. Therefore, SNA Server (version 2.1 or later) allows you to choose the protocol for server broadcasts. Through SNA Server Admin, you can specify the following:

What network protocol should be used for server broadcasts. The possible protocols are Microsoft networking (named pipes), Novell NetWare (IPX/SPX), Banyan VINES, and TCP/IP. You must make sure there is one protocol that is available on all SNA servers in the domain, and use that protocol for server broadcasts.

Important

The choice of network protocol for server broadcasts can affect efficiency. For details, see Chapter 2, “Server Placement and Protocol Choices.”

Whether server broadcasts should be sent in a way that can be received by older types of clients and servers — that is, version 2.0 SNA servers and/or Comm Server clients.

Supporting older servers and clients in this way involves a decrease in efficiency, because the version 2.1 SNA servers must send significantly more broadcasts. Therefore, avoid using these options unless necessary. For more information, see the detailed upgrading information in Chapter 4 of the Microsoft SNA Server Installation Guide.

Whether the broadcasts should be propagated across IP routed networks. On a TCP/IP WAN, the datagrams used by SNA servers are multicast messages, which typically are not propagated across IP routers. Through SNA Server Admin, however, you can enable the propagation of multicast messages across IP routed networks to all primary and backup domain controllers in the Windows NT domain. For details, see “Network Protocols Used for Server-Server (Broadcast) Communication” in Chapter 2.


Communication Between SNA Servers and Host Computers: Connections
Introduction to SNA Server	6 of 9

Basic Concepts

Communication Between SNA Servers and Host Computers: Connections

Within the context of SNA Server, a connection is the data communication path between an SNA server and an IBM host (mainframe or AS/400). A connection corresponds to a PU definition on a mainframe or a controller on an AS/400. The connection is what makes it possible for a PC user on the LAN to communicate with a host via an SNA server. Note that SNA connections do not use BISYNC, an older IBM standard for communications.

An SNA server can use any of the types of connections in the following list. To choose a connection type for your SNA server(s), first contact the host administrator and find out what type of connection is available to the mainframe or AS/400. If more than one type is available, choose a type based on comparisons of cost and speed.

802.2 (token ring, Ethernet, or FDDI)

Token ring, Ethernet, or FDDI connections use the IEEE 802.2 protocol. With a mainframe, an 802.2 connection goes to a 37xx front-end processor (FEP) or a 3174 communications controller (or, rarely, to an adapter in the mainframe). With an AS/400 system, an 802.2 connection goes directly to the AS/400.

These connections are generally faster than other connections except for Channel. Table 1.1 provides details:

Table 1.1    Common Speeds for 802.2 Connections

Type of 802.2 connection	Common speeds

Token ring	4 Mbps (megabits per second) or 16 Mbps

Ethernet	10 Mbps

FDDI	100 Mbps (or more); however, the FDDI line communicates through a front-end processor that is channel-attached to the mainframe, and this may limit the overall speed f communications.

Synchronous Data Link Control (SDLC) — standard phone line with modem

SDLC uses a standard phone line, which may be leased or switched and may be point-to-point or multidrop. An SDLC line is used with a modem (or other type of Data Circuit – terminating Equipment, that is, DCE) at each end. With a mainframe, an SDLC line goes (through a modem or other DCE) to a 37xx front-end processor (FEP), 3174 communications controller, or integrated synchronous adapter. With an AS/400 system, an SDLC line goes through a modem or other DCE and then directly to the AS/400.

An SDLC connection is slower than an 802.2 or Channel connection. Common speeds for SDLC connections are listed in Table 1.2:

Table 1.2    Common Speeds for SDLC Lines

Type of transmission	Common speeds

Analog (conventional phone line)	9600 bits per second, or  14.4 or 19.2 kilobits per second

Digital Data System (DDS)	56 kilobits per second  (sometimes 64 kilobits per second)

Integrated Services Digital Network (ISDN)	56 kilobits per second (can be more)

T1 carrier system (digital)	1.544 Mbps (megabits per second)

E1 carrier system (digital)	2.048 Mbps

X.25 (packet-switching network)

X.25 is the CCITT standard used for communication over a packet-switching network; it uses the qualified logical link control protocol (QLLC). With a mainframe, an X.25 line goes to a 37xx front-end processor (FEP), 3174 communications controller, or integrated synchronous adapter. With an AS/400 system, an X.25 line goes directly to the AS/400.

An X.25 connection is slower than an 802.2 or Channel connection. Common speeds for X.25 connections are the same as for SDLC, as listed previously in Table 1.2.

DFT

DFT stands for distributed function terminal. DFT works with IBM 3270 control units, and the cable used is often coaxial. Note that a DFT connection supports no more than five sessions. DFT connections transmit at 2.35 megabits per second, which is intermediate in speed (for example, slower than 802.2 but faster than SDLC connections).

Channel

Channel connections provide direct channel attachment to a mainframe. Channel connections are parallel rather than serial, and are generally faster than other connections. There are two types of Channel connections: older “Bus and Tag,” which operates at 3 or 4.5 megabits per second; and newer fiber-optic ESCON, which operates at 10 megabits per second.

Twinax

Twinax connections use twinaxial cable to connect to an AS/400 through a remote workstation controller or an integrated Twinax adapter on the AS/400. SNA Server Twinax connections support LU 6.2 only. Twinax connections generally transmit at 1 megabit per second.


3270 Users Connecting to a Mainframe
Introduction to SNA Server	7 of 9

Basic Concepts

3270 Users Connecting to a Mainframe

Figure 1.2 illustrates the basic elements of an installation where users of 3270 emulation software connect through an SNA server to an IBM mainframe. The diagram shows how different elements are labeled in SNA terminology: either as some kind of physical unit (PU), as a connection, or as some kind of logical unit (LU). An LU is simply a configurable unit that specifies the exact type of session to be established with the mainframe.

Figure 1.2    3270 Users Connecting Through SNA Server to a Mainframe

A 3270 user communicating with a host uses a 3270 LU; the 3270 LU has a specific name (recognized by the host), is associated with a specific connection, and supports a specific use (either printing, or terminal emulation of a particular size). A collection of 3270 LUs that will be used by a group of users can be placed in an LU pool, so that whenever a user needs an LU, the next one in the pool will be made available. The connection, the 3270 LU, the 3270 LU pool, and the list of users (or groups) are the basic elements to configure when supporting 3270 users in an SNA Server installation.

For examples of configurations to use when supporting 3270 users, see Chapter 5, “Examples of Configurations for 3270.”


5250 Users Connecting to an AS/400
Introduction to SNA Server	8 of 9

Basic Concepts

5250 Users Connecting to an AS/400

Figure 1.3 illustrates the basic elements of an installation where users of 5250 emulation software connect through an SNA server to an IBM AS/400. As with the previous diagram, this diagram shows how different elements are labeled in SNA terminology: as some kind of physical unit (PU), as a connection, or as some kind of logical unit (LU). LUs are simply configurable units that specify the exact type of session to be established with the AS/400.

Figure 1.3    5250 Users Connecting Through SNA Server to an AS/400

A 5250 user communicating with an AS/400 must use a pair of LU 6.2 LUs, also called APPC LUs; the pair contains a “local LU” and a “remote LU” (as seen from the point of view of the SNA server). Together, this LUs pair of LUs (with the “mode” that they use) contain the configuration information needed for establishing a session with the AS/400.

The 5250 user may share this pair of LUs with many other users at the same time, or may have exclusive use of the LUs (depending on the SNA Server configuration). In addition, SNA servers can be configured so that users can start 5250 emulation sessions without knowing the names of LUs to request. This configuration is accomplished with the use of “default LUs” that are specified for each 5250 user or for groups of users.

The LUs used for 5250 are called APPC LUs because 5250 emulation software uses the APPC protocol to communicate with the AS/400. The sections of the SNA Server documentation that describe the configuration of APPC LUs apply to configurations for 5250 emulation. SNA Server does not support LU 4 or LU 7, but provides 5250 terminal emulation and 5250 printer emulation through LU 6.2.

For examples of configurations to use when supporting 5250 users, see Chapter 6, “Examples of Configurations for 5250.”


Finding Further Basic Information
Introduction to SNA Server	9 of 9

Finding Further Basic Information

With an understanding of the concepts discussed in this chapter, you can begin to plan and implement an SNA Server installation that supports 3270 or 5250 users. The following table shows how to find further basic information:

Table 1.2    Finding Further Basic Information

Type of information	Source(s)
Diagrams and descriptions of other basic concepts used during installation and administration	Introductory sections of the following manuals:  Managing Microsoft SNA Server  Microsoft SNA Server Installation Guide  Microsoft SNA Server Administration Guide
Glossary of SNA Server terms	Microsoft SNA Server Reference
Forms to use when gathering information for connections and LUs	Appendix B of the Microsoft SNA Server Administration Guide
Examples of configurations for supporting 3270 users	Chapter 5, “Examples of Configurations for 3270” (in this guide)
Table showing how mainframe settings (VTAM and NCP) correspond to SNA Server settings	Chapter 5 of the Microsoft SNA Server Administration Guide
Examples of configurations for supporting 5250 users	Chapter 6, “Examples of Configurations for 5250” (in this guide)
Table showing how AS/400 settings correspond to SNA Server settings	Chapter 7 of the Microsoft SNA Server Administration Guide


Server Placement and Protocol Choices
Chapter 2	1 of 9

Server Placement and Protocol Choices

When planning an SNA Server domain, there are a number of key decisions to make regarding the organization of the domain. This chapter includes guidelines for decisions about the following topics:

The physical placement of SNA servers into a centralized or a branch configuration.

The placement of SNA servers into an existing Windows NT domain or a separate new domain.

The designation of SNA servers as domain controllers or as standard servers in the Windows NT domain.

The designation of SNA servers as primary SNA configuration server, backup SNA servers, or member servers.

The choice of network protocols to be used on SNA servers (IPX/SPX, Microsoft networking, TCP/IP, and so on).

For information about how to select hardware for an SNA Server installation, see Chapter 3, “Basic Methods for Evaluating Hardware Requirements.” For information about tuning SNA servers to maximize communications throughput, see Appendix C, “Options for Maximizing Communications Throughput.” For background information about Windows NT domains, see the Windows NT Server Concepts and Planning Guide.


Centralized and Branch Configurations
Server Placement and Protocol Choices	2 of 9

Centralized and Branch Configurations

There are two basic physical configurations in which SNA servers can be placed: centralized in one place, or distributed across branch locations of an enterprise. If centralized, the SNA servers are generally placed in a single domain near the mainframes, AS/400s, or other systems that they provide connections to. If distributed, the SNA servers are spread out across multiple LAN domains, with each domain containing one or more servers and the clients that use the server(s).

The centralized plan is shown in the following figure.

Centralized Plan

With the centralized approach, all servers and clients are connected by wide area network (WAN), links into a routed internetwork and may be located in the same building or across the country. The servers and clients use only one networking protocol (TCP/IP or IPX/SPX) to connect through the network. The SNA servers can connect to the host through Channel attachment, 16-megabit-per-second token ring, or other fast connections. Advantages of the centralized approach are as follows:

The SNA servers are easier to secure and administer because they are centrally located.

The SNA servers can provide hot backup and load balancing for each other (generally impossible if they are not on the same LAN).

The same WAN environment can be used for other purposes, such as Microsoft [image] SQL Server [image], mail, and printer and file sharing.

There is less need for SNA expertise at the remote sites.

Disadvantages of the centralized approach are as follows:

Greater investment in WAN links and routers is required (compared to the noncentralized approach). This is because the same SNA transactions require more traffic between the client and server than between the server and host.

Because there are no SNA servers at remote sites, these servers cannot be used as multipurpose departmental servers (that is, Windows NT Servers running multiple server applications).

The noncentralized plan is shown in the following figure.

Noncentralized (Branch) Plan

With the noncentralized approach, SNA servers are connected to the host through SNA links such as 802.2 (propagated through routers), SDLC, or X.25. The SNA servers may be administered locally, or administered remotely through RAS or NetView. The advantages of the noncentralized approach are as follows:

It is already used in many places and therefore does not require major changes or new investments.

It can be supported by low-bandwidth backbones such as SNA-only backbones, X.25 backbones, or other lines supporting less than 64 kilobits per second.

It uses smaller domains that may be easier to configure.

It can use smaller servers.

SNA servers at remote sites may also be usable as multipurpose departmental servers, leveraging the multitasking capabilities of Windows NT Server. Such servers can run Microsoft SQL Server, mail services, or other server applications along with SNA Server.

LUs, user accounts, and security settings can be maintained locally, and therefore can be made more responsive to local users’ needs.

Disadvantages of the noncentralized approach are as follows:

Hot backup and load balancing may be difficult or impossible, because the SNA servers are not on the same LAN.

Administrators with SNA expertise may need to be located at the branch sites.

If the installation uses an 802.2 backbone with routers, and if the backbone protocols are not SNA only, the routers must be quite sophisticated to priortize interactive communications.

For more information on network planning issues, see your Windows NT product documentation and/or product information for other network hardware and software products; in addition, see the next several sections.


Deciding About Domains and Server Roles
Server Placement and Protocol Choices	3 of 9

Deciding About Domains and Server Roles

The preceding section provides information to help you decide whether to use the centralized or noncentralized approach when choosing locations for SNA servers. The following sections discuss several other decisions you may need to make:

Whether SNA servers should be added to an existing Windows NT domain or placed in a separate domain.

Whether to install SNA servers on domain controllers.

What SNA Server role each server should have: primary SNA configuration server, backup SNA server, or member server.

For background information about Windows NT domains, see the Windows NT Server Concepts and Planning Guide.


Deciding Whether to Create a Separate Domain
Server Placement and Protocol Choices	4 of 9

Deciding About Domains and Server Roles

Deciding Whether to Create a Separate Domain

In deciding how to organize the domains in your installation, you may need to decide whether SNA servers should be placed in an existing domain or placed in a separate domain, perhaps with trust relationships to an existing domain. Unless your installation will have more than 50 SNA servers, base this decision on the discussion of domains and trust relationships, and the various domain models, in the Windows NT Server Planning and Concepts Guide. In other words, the decision should be made according to the optimal way to organize users, not according to the various functions of different servers in the domain. If you place SNA servers in a domain with servers performing other functions (for example, Systems Management Servers), it will generally have only a slight effect on the performance of the SNA servers.

If your installation will have more than 50 SNA servers, you must plan on dividing the SNA servers between two different domains. This is because the maximum number of SNA servers that can work together in one domain is 50.


Deciding About Domain Controllers (Logon Servers)
Server Placement and Protocol Choices	5 of 9

Deciding About Domains and Server Roles

Deciding About Domain Controllers (Logon Servers)

In addition to deciding about the placement and organization of your SNA servers, you will need to decide whether your SNA servers will also be domain controllers (logon servers) in the Windows NT domain. Specifically, you will need to decide whether each SNA server will also have a role of primary domain controller, backup domain controller, or just standard server (not a domain controller at all). For definitions of domain-controller roles, see the end of this section. Note that there must be one primary domain controller in each domain, so if the only Windows NT Servers in the domain are also SNA servers, one of those SNA servers must be the primary domain controller.

The primary SNA server does not have to be the primary domain controller, nor do backup SNA servers need to be backup domain controllers. You should make the decision about which servers to designate as domain controllers separately from the decision about which servers to designate as primary or backup SNA servers. This section provides guidelines for designating domain-controller roles, and the next section provides guidelines for designating SNA server roles.

The first factor to look at when making this decision is whether you have an IP network connected by routers. IProuted network. If you do, you must install the SNA servers on primary or backup domain controllers. Otherwise, you should base your decision on whether the other servers in the installation are mostly Windows NT Servers, or whether they are servers not running Windows NT — for example, NetWare or VINES servers. If the other servers are mostly Windows NT Servers, you may want to install SNA servers on standard servers, not on domain controllers. Otherwise, you may want to install SNA servers on domain controllers. The following list provides details.

Install the SNA servers on domain controllers (primary or backup) if the following points apply:

If the SNA servers are installed an IP-routed network, you must install the SNA servers on domain controllers (either primary or backup domain controllers).

This is because only domain controllers have the ability to propagate server-server datagrams over IP routers. Server-server datagrams are necessary for SNA servers working together in a domain. For important information about how to enable routing of server datagrams over IP routers, see “Network Protocols Used for Server-Server (Broadcast) Communication,” later in this chapter.

If the other servers are mostly NetWare or VINES servers, or other servers not running Windows NT, you may want to combine the domain-controller functions and the SNA Server functions on the same computers. In other words, you may want to install the SNA servers on primary or backup domain controllers. This allows logon processing to happen locally on the same server that will provide the SNA support needed by the user.

In this type of installation, users typically log on to the Windows NT domain only a few times a day, when starting an SNA session. The small number of logons will require a small amount of processing time on the servers, but will not require network communication with a domain controller, so overall the logon process will be efficient.

Install the SNA servers on standard servers only (not domain controllers) if the network is not IProuted and the following point applies:

If the other servers are mostly Windows NT Servers performing various functions (such as file-sharing), you may want to dedicate the SNA servers to SNA Server functions only, and have other servers be the domain controllers (primary or backup). In other words, you may want to install SNA Server only on standard servers (not on primary or backup domain controllers). This spares the SNA servers from having to carry the workload of logon processing.

In such a situation, many users may be logging on and off to the Windows NT domain throughout the day, and Windows NT Servers may be providing a variety of support such as logon scripts and access to shared files. This means that a significant load may be generated by logon attempts and other network activity. In such a domain, if SNA servers are dedicated to SNA Server functions only, they may be able to provide better response time to SNA users, because the servers are spared from having to process logon authentications or perform other network functions.

The following list provides definitions of primary domain controller, backup domain controller, and standard server.

Primary domain controller

The primary domain controller is the server that contains the master user-accounts database for a Windows NT domain. There can be only one primary domain controller in a domain. The primary domain controller shares the load of logon-processing with any backup domain controllers in the domain.

Backup domain controller

Backup domain controllers are servers onto which the user-accounts database for the domain is automatically replicated. There can zero, one, or many backup domain controllers in a domain. Backup domain controllers share the load of logon-processing with the primary domain controller.

Standard server (not a domain controller)

Standard Windows NT Servers are servers that do not contain a copy of the user-accounts database for the domain and do not perform logon authentication. There can zero, one, or many standard servers in a domain.

Note that SNA Server users require logon support in the Windows NT domain regardless of the LAN transport used — NetWare, TCP/IP, or any of the other transports. For more information about client logons, see Appendix A, “Network Protocols and Client-Server Communication.” For information about security with SNA Server, see Chapter 12 of the Microsoft SNA Server Administration Guide. For more information about Windows NT domains, see the Windows NT Server Concepts and Planning Guide.


Deciding About Primary, Backup, and Member SNA Servers
Server Placement and Protocol Choices	6 of 9

Deciding About Domains and Server Roles

Deciding About Primary, Backup, and Member SNA Servers

When planning an SNA Server installation, you must also decide whether each SNA server is to be the primary SNA server, a backup SNA server, or a member SNA server. Primary and backup SNA servers contain copies of the SNA Server configuration file, and member SNA servers do not. As mentioned in the preceding section, the primary SNA server does not have to be the primary domain controller, nor do backup SNA servers need to be backup domain controllers. You should make the decision about which servers to designate as primary or backup SNA servers separately from the decision about which servers to designate as domain controllers. This section provides guidelines for assigning SNA server roles, and, at the end of the section, definitions of the roles. For guidelines and definitions related to domain-controller roles, see the previous section.

When choosing which server will be the primary SNA server, choose a computer that is reliable and powerful, and that you can keep physically secure (if security is an issue in your installation). If possible, have one or more backup SNA servers in the domain as well, to maintain copies of the SNA Server configuration file in case the primary SNA server goes down. If security is an issue, the backup SNA servers should also be kept physically secure, since each one contains a copy of the SNA Server configuration file. For additional information about security, see Chapter 12 of the Microsoft SNA Server Administration Guide.

After you have designated one primary SNA server and several backup SNA servers, the remaining SNA servers can be designated as member SNA servers (SNA servers without a configuration file). As long as the primary SNA server is running, you can administer SNA Server from a member server just as you would from any other SNA server. (You can also manage SNA Server from a Windows NT – based client that has SNA Server Admin installed.) Note that you can limit the ability of users or groups to administer SNA Server by setting up SNA Server permissions. The process of setting up permissions is described in Chapter 12 of the Microsoft SNA Server Administration Guide.

In situations where the primary SNA server must be replaced (for example, because of hardware problems), a backup SNA server can be changed to become primary SNA server. To do this, if the former primary SNA server can still run, you use SNA Server Setup on that server to change its role to Backup (use the Role button to access the appropriate dialog box). Then, on the server that will become the primary SNA server, you use SNA Server Setup to change the role to Primary. (Following this sequence of steps ensures that there is only one primary SNA server at any given time.) Note that you cannot change the SNA server role by using SNA Server Admin.

The following list provides definitions of primary SNA server, backup SNA server, and member SNA server.

Primary SNA server

The primary SNA server is the server that contains the SNA Server configuration file for that domain. The configuration file reflects the SNA Server resources for the domain, including all SNA servers, link services, LUs, users recognized as part of the SNA Server configuration, and so on. There can be only one primary SNA server in the domain. Typically, the primary SNA server is the first server installed.

Backup SNA server

A backup SNA server is a server on which a read-only copy of the configuration file is replicated by SNA Server. There can be more than one backup server in a domain. If the primary SNA server goes down, SNA Server will use the read-only copy of the configuration file stored on a backup SNA server. When the configuration file from a backup server is used, servers and connections can be started and stopped, but the configuration cannot be changed or saved.

Member SNA server

A member SNA server does not contain the configuration file. One or more SNA servers can operate as member servers.

With SNA servers, as with any other server, maintain extra copies of important files to help protect against loss. To make an extra copy of the SNA Server configuration file: start SNA Server Admin and then, from the File menu, choose Backup. To restore a backed-up copy of the configuration file: from the File menu, choose Restore. (This kind of backing up is entirely separate from the replication that is automatically carried out by backup SNA servers.)

Note that the concept of a backup SNA server is different from the concept of hot backup. Hot backup is the capability of SNA servers in a domain to work together to provide session support even when a server or a connection is not working. When SNA servers provide hot backup, it means that LUs and other resources are configured so that they can automatically fill in and support sessions even if another similar resource is not available. For information, see Chapter 5, “Examples of Configurations for 3270” or Chapter 6, “Examples of Configurations for 5250.”


Choosing and Setting Up Network Protocols on SNA Servers
Server Placement and Protocol Choices	7 of 9

Choosing and Setting Up Network Protocols on SNA Servers

This section provides information about choosing and setting up network protocols (such as Microsoft networking, IPX/SPX, and TCP/IP) on SNA servers. For information about network protocols on SNA Server clients, see Appendix A, “Network Protocols and Client-Server Communication.” For information about specifying SNA (not LAN) protocols — SDLC, 802.2, X.25, and so on — see Chapter 4, “Establishing a Connection Successfully.”


Network Protocol Choices for SNA Servers
Server Placement and Protocol Choices	8 of 9

Choosing and Setting Up Network Protocols on SNA Servers

Network Protocol Choices for SNA Servers

You must choose the protocol(s) to be used for two different types of SNA Server communication: client-server communication and server-server communication. One protocol can be used for both, or a variety of different protocols can be used (provided that all servers share at least one protocol, and use it for server-server communication). The following diagram shows a network where Microsoft networking is used for all types of communication involving SNA servers and clients:

One Protocol for All Communication Between Servers and Clients

The next diagram shows a network where two protocols are used. For server-server communication, Microsoft networking (NetBEUI) is used; for client-server communication, IPX/SPX is used.

Two Protocols (Microsoft Networking and IPX/SPX) in a Domain

The next diagram shows a network where three protocols are used. For server-server communication, Microsoft networking (NetBEUI) is used; for client-server communication, TCP/IP and IPX/SPX are used.

Three Protocols (Microsoft Networking, TCP/IP, and IPX/SPX) in a Domain

Similarly, other combinations of protocols can be used, provided that all the SNA servers share one protocol, and use that protocol for server-server communication. For more information about using LAN protocols with SNA Server, see the remainder of this chapter.

Interfaces for Specifying Network Protocol Choices

The various network protocol choices on SNA servers fall naturally into different stages of the installation and configuration process and therefore are controlled through different interfaces. The interfaces include the Windows NT Server Control Panel, SNA Server Setup, and/or SNA Server Admin. Table 2.2 summarizes the interfaces used for modifying protocol choices:

Table 2.2    Modifying Network Protocol Choices on an SNA Server

When selecting...	Use this interface...	Use this menu, command, and/or option to access the dialog box...
Protocol(s) to be bound to a network adapter in the SNA server (so they are available for server-server and/or client-server communication.	Windows NT Server Control Panel	Network option with Add Software button (to remove software, select the software and choose Remove button)
Protocol(s) to be used for communicating with clients	SNA Server Setup	From Welcome dialog box, choose Continue, then choose Protocols
Protocol to be used for communication between servers	SNA Server Admin	Options menu, Server Broadcasts command
For important information about selecting protocols, see the next two sections.

Network Protocols Used for Client-Server Communication

Clients can communicate through a number of different LAN protocols: Microsoft networking (named pipes), IPX/SPX (the protocol used with NetWare), TCP/IP, Banyan VINES IP, or AppleTalk. (Clients using the NetSoft [image] NS/Router can also use NetBIOS, and SNA servers can be set up to support them.) In order for the different protocols to be handled correctly, both clients and servers must have the network software and the SNA Server software installed correctly. Correct installation ensures that two essential aspects of communication work correctly:

The servers and clients are “visible” to each other on the LAN. This results when the network software is installed correctly on all affected computers.

The SNA servers communicate with clients over the correct LAN protocol, and the clients direct their communication to the correct domain name or (for some clients using Microsoft networking or TCP/IP) to one or more correct server names. (In addition, with Banyan VINES, servers and clients must use the same StreetTalk [image] group name.) This results when the SNA Server software is installed correctly.

For SNA servers, to change the protocol(s) to be used for client-server communication, start SNA Server Setup, choose Continue, and then click the Protocols button. The Select Client/Server Protocols dialog box appears:

Select Client/Server Protocols Dialog Box (Accessed through SNA Server Setup)

As shown, the protocols that have been bound to adapters on the server can be chosen. (Protocols unavailable on that server are dimmed.)

Setting Up TCP/IP for Client-Server Communication

The following paragraphs provide some important details about running SNA Server Setup on servers that communicate with clients through TCP/IP.

If the server has TCP/IP installed and will communicate with clients that use TCP/IP, be sure that the selections in the Select Client/Server Protocols dialog box include TCP/IP. For such a server, if Microsoft Networking (Named Pipes) is selected and TCP/IP is not, the server can communicate through named pipes over TCP/IP, a protocol combination that does not recover from error conditions as effectively as native TCP/IP. Named pipes over TCP/IP is also less desirable as a protocol for client-server communication because of the limitation it imposes on the number of clients that SNA Server can support using that protocol. When running on Windows NT Server version 3.5, SNA Server can support fewer than 256 clients using named pipes over TCP/IP, and up to 2000 clients when running on Windows NT Server version 3.51.

Note that it is completely workable to select both TCP/IP and Microsoft Networking (Named Pipes). If these are both selected, the SNA server will use native TCP/IP with clients that use TCP/IP, and Microsoft Networking with clients that use Microsoft Networking.

Also, on an SNA server, if your choices in the Select Client/Server Protocols dialog box include TCP/IP but not Microsoft Networking (Named Pipes), the Network Domain Name dialog box appears. This dialog box contains only one item, the Domain Name field. The instructions for the dialog box (in the documentation) include a list of forms that the Domain Name can take for TCP/IP. However, the only correct Domain Name to specify on a server using TCP/IP is the name of the Windows NT domain. This contrasts with the information that can be typed into the equivalent dialog box during installation or modification of a client. On a client, the typed information can be one or more names or IP addresses of SNA servers that the client uses for SNA connectivity.

For information about how clients use TCP/IP when communicating with SNA servers, see Appendix A, “Network Protocols and Client-Server Communication.”

Network Protocols Used for Server-Server (Broadcast) Communication

SNA servers communicate with each other using mailslot or datagram broadcast messages to the domain. SNA Server (version 2.1 or later) allows you to make choices concerning these broadcasts. To do this, start SNA Server Admin and, in the Options menu, choose Server Broadcasts. The following dialog box appears.

Figure 2.1    Server Broadcasts Dialog Box (Accessed through SNA Server Admin)

The options in the Server Broadcasts dialog box are described in the following sections.

Factors to Consider Regarding Server Broadcast Protocols

As shown in Figure 2.1, you can select among the following protocols for server broadcasts: Microsoft networking (named pipes), Novell NetWare (IPX/SPX), Banyan VINES, and TCP/IP.

The protocol choice is domain-wide; you must use the same protocol for all server broadcasts.

Important

You must make sure there is one protocol that is available on all SNA servers in the domain, and use that protocol for server broadcasts.

For example, if all SNA servers in a domain use Microsoft networking, but only some use IPX/SPX, the protocol used for server broadcasts must be Microsoft networking.

Note that the server-server transport protocol does not have to be the same as the client-server protocol(s). For diagrams of some possibilities, see “Network Protocol Choices for SNA Servers,” earlier in this chapter.

The following table summarizes the recommendations for selecting a server-to-server transport protocol:

Table 2.2    Recommendations for Selecting a Server-to-Server Transport Protocol

Situation	Recommendation or requirement
There is only one protocol (for example, Microsoft networking) shared by all SNA servers in the domain, although some SNA servers can also use a second protocol (such as IPX/SPX) for communication with clients.	Requirement: Select a protocol shared by all SNA servers, not a protocol shared only by some SNA servers.
Each SNA server in the domain has two or more of the same protocols bound to the network adapter.	Recommendation: Select only one of the protocols shared by all servers. The protocol selected should not be Microsoft Networking (Named Pipes) unless the network includes IP routers (see the next listing in this table, and the text that follows this table).
SNA servers communicate across an IProuted network.	Requirement: Select Microsoft Networking (Named Pipes), and also select “Route Server Broadcasts over IP routers.” For this configuration, SNA servers must be installed on primary or backup domain controllers.
You must support version 2.0 SNA servers in the domain along with version 2.11 SNA servers.	Requirement: Choose either Microsoft Networking (Named Pipes) or Novell NetWare (IPX/SPX). (Other protocols will be dimmed when the option for supporting  version 2.0 servers is selected.) Version 2.0 SNA servers rely on these protocols. Recommendation: Upgrade to version 2.11 SNA servers when feasible. (See the next section.)
You must support DCA [image] /Microsoft Comm Server clients.	Requirement: Your selections must include Microsoft Networking (Named Pipes). DCA/Microsoft Comm Server clients rely on this protocol. Recommendation: Upgrade to version 2.11 SNA Server clients when feasible. (See the next section.)
You are focusing on optimal efficiency.	Recommendations: Upgrade any Comm Server 1.x clients and SNA Server version 2.0 servers to the appropriate SNA Server version 2.11 software. Then select one network protocol — for example, Novell NetWare (IPX/SPX) or TCP/IP but not both. Finally, for the Mean Time between Server Broadcasts, specify a value greater than or equal to 60 seconds. For more information about the Mean Time, see “Factors to Consider Regarding the Mean Time Between Server Broadcasts,” later in this chapter.
The rest of this chapter provides additional detail about the recommendations and requirements in Table 2.2.

Using multiple server-to-server transport protocols can add significantly to network overhead; this is because every server broadcast must be sent out through all protocols selected in SNA Server Admin.

Note

For highest efficiency, select only one protocol for broadcasts between SNA servers. The protocol must be available on all SNA servers in the domain. Where multiple choices are available (in other words, multiple protocols are bound to the network adapters on all SNA servers), select a protocol other than Microsoft Networking (Named Pipes). The exception to this is a network with IP routers; in this situation, the server-to-server transport protocol must be Microsoft networking.

This recommendation (about using a protocol other than Microsoft networking) is made because of design requirements for mailslot broadcasts. When these broadcasts are sent over Microsoft networking, there is no way for the local system to tell what protocol the receiving system will be using, so the broadcast is sent over all protocols bound to the local adapter. This causes multiple sending of mailslot broadcasts with Microsoft networking for adapters to which several protocols are bound. The mutiple broadcasts cause an increase in network traffic.

In other words, for highest efficiency, in domains where all SNA server adapters can use multiple protocols, and where broadcasts will not be routed over IP routers, for Server Broadcasts, select one (and only one) of the following: IPX/SPX, Banyan VINES, or TCP/IP.

As shown in Figure 2.1, you can also specify whether server broadcasts should be propagated across IP-routed networks. On a TCP/IP WAN, the broadcasts used by SNA servers are multicast (broadcast) messages, which typically are not propagated across IP routers. Through the Server Broadcasts dialog box, however, you can enable the propagation of broadcast messages across IP-routed networks to all primary and backup domain controllers in the Windows NT domain. For details, see Chapter 3 of the Microsoft SNA Server Administration Guide.

Note

If you select “Route Server Broadcasts over IP routers,” you must also select Microsoft Networking (Named Pipes).

You may be able to select extra protocols that do not exist in your network; however, selecting these has no effect. In the Server Broadcasts dialog box, a full range of protocols is displayed (unless you enable support of SNA Server 2.0 servers or Comm Server clients) only because the software on the local server has no way to determine what protocols are available on other computers on the network.

Factors to Consider Regarding Support of Older Versions

As shown in Figure 2.1, you can specify whether server broadcasts should be sent in a way that can be received by older types of clients and servers — that is, version 2.0 SNA servers and/or Comm Server clients.

If you choose “SNA Server 2.0 servers in the same domain,” the only available protocols for server broadcasts will be Microsoft Networking (Named Pipes) and Novell NetWare (IPX/SPX). (Other protocols will be dimmed.) This is because version 2.0 SNA servers rely on these protocols; you must choose at least one protocol.

If you choose to support DCA/Microsoft Comm Server clients, your selections must include Microsoft Networking (Named Pipes). These clients rely on this protocol.

Supporting older servers and clients in this way involves a decrease in efficiency, because the upgraded (version 2.11) SNA servers must send significantly more broadcasts. Therefore, avoid using these options unless necessary. For more information, see the detailed upgrading information in Chapter 4 of the Microsoft SNA Server Installation Guide.

Factors to Consider Regarding the Mean Time Between Server Broadcasts

The Server Broadcasts dialog box, shown in Figure 2.1, has an option called Mean Time between Server Broadcasts. You can specify this time period unless you choose to support SNA servers running version 2.0 or DCA/Microsoft Comm Server clients (in which case the Mean Time between Server Broadcasts will automatically be set at 45 seconds, so that the older software can be supported).

For optimal efficiency, upgrade all clients and servers and then disable the options for support of older versions; then, for the Mean Time between Server Broadcasts, specify a value greater than or equal to 60 seconds. The smaller this value, the less the efficiency, but the more the broadcasts compensate for loss of broadcast messages (which by definition are not guaranteed to be received). If messages are lost infrequently, an appropriate value might be 120 seconds; if messages are lost more frequently, an appropriate value might be 60 seconds.


Finding Additional Information About Client-Server Protocols
Server Placement and Protocol Choices	9 of 9

Choosing and Setting Up Network Protocols on SNA Servers

Finding Additional Information About Client-Server Protocols

This chapter provides information about client-server communication from the point of view of the servers. For additional information, including important details about installation, see the following:

Appendix A, “Network Protocols and Client-Server Communication”

The installation manuals or online help for your network software

For servers, the SNA Server Setup help

For clients, the SNA Server Setup help, or Appendix A, “Network Protocols and Client-Server Communication”


Basic Methods for Evaluating Hardware Requirements
Chapter 3	1 of 5

Basic Methods for Evaluating Hardware Requirements

Because SNA servers can be used in a wide variety of situations, there is no simple formula for figuring the amount of processing power required for a particular SNA server. Therefore, this chapter offers several kinds of information to help you evaluate hardware requirements:

A list of the elements that cause greater or lesser demands on hardware, to help you estimate the general level of your processing requirements. For example, an SNA server may serve large numbers of users, perhaps in the range of 1000 – 1500, indicating a need for large amounts of processing power, perhaps a Pentium [image] processor with 64 or even 128 megabytes of RAM. However, if your servers each support 500 users and most of those users connect briefly and at random times during the day, less processing power will be needed.

Methods for evaluating the current demand being made on an existing SNA server, and the ability of the existing hardware to support that demand. This will give you a valuable “baseline” from which to work.


Variables that Affect Hardware Requirements
Basic Methods for Evaluating Hardware Requirements	2 of 5

Variables that Affect Hardware Requirements

A large set of variables affects the amount of memory and processing power required for a particular SNA server. The major variables are as follows:

The number of clients served.

This is the most important variable affecting hardware requirements. Supporting large numbers of clients requires that servers not only have plenty of memory and processing capacity, but also fast, powerful LAN adapters. Such LAN adapters include their own processor and memory, and may use direct memory access (DMA). Without such adapters, the network interface may become the bottleneck in situations where many clients are being supported. Similarly, SNA adapters must be powerful enough to keep pace with the communications load.

The demand generated by the clients (constant, intermittent, heavy, light).

The number of SNA servers configured to work together within a particular domain.

This is affected by the “centralized” or “branch” configuration of the SNA Server installation. SNA servers in a centralized configuration are grouped together in domains and can therefore provide load balancing — that is, they can share the load. SNA servers in a branch configuration are separated by wide area network links, and cannot readily provide load balancing because of the communication delays involved. For details about centralized and branch configurations, see Chapter 2, “Server Placement and Protocol Choices.”

The additional network services (file-sharing, database access, mail service, and so on) provided by each SNA server.

The following table will allow you to estimate the approximate amount of processing power required for your SNA servers.

Table 3.1    General Hardware Guidelines

If your installation falls into this category...	Hardware guidelines are...
Approximately 1500 – 2000 users per server, with up to 10,000 sessions per server	Multiprocessor system or, if the number of users is around 1500 (not 2000), a very fast RISC-based system such as an Alpha/299. For either type of system, allow approximately 64 – 128 megabytes of memory. Two or more SNA servers per domain for hot backup. Connections (such as 802.2 or Channel) that are fast enough to avoid bottlenecks (recommended); multiple SNA adapters, except for Channel. Multiple LAN adapters to avoid LAN bottlenecks. Optionally, dedicated SNA servers that do not provide file sharing or other LAN services (depends on load created by other LAN services).
Up to 600 users per server (heavy use) or Up to 1500 users per server (light or intermittent use)	Pentium P90 or Alpha AXP [image] or MIPS [image] computer with approximately 64 – 128 megabytes of memory. Two or more SNA servers per domain for hot backup. Connections (such as 802.2 or Channel) that are fast enough to avoid bottlenecks (recommended); multiple SNA adapters may be needed, except for Channel. Multiple LAN adapters may be needed to avoid LAN bottlenecks. A more powerful CPU and more RAM may be needed if SNA servers must support significant additional loads, such as file sharing.
Up to 200 users per server (heavy use) or Up to 500 users per server (light or intermittent use)	486/66 with approximately 32 megabytes of memory. Two or more SNA servers per domain for hot backup. With limited load, connections that can handle 56 kilobits/second or more may still provide adequate response time. However, at speeds below 56 kilobits/second, multiple SNA adapters will be needed. A more powerful CPU and more RAM may be needed if SNA servers must support significant additional loads, such as file sharing.
Approximately 1 – 25 users per server	486/33 with approximately 16 megabytes of memory. Relatively slow connections, such as SDLC connections at 9600 bits per second, may still provide adequate speed. A more powerful CPU and more RAM may be needed if SNA servers must support significant additional loads, such as file sharing.
The following diagram illustrates basic hardware requirements for SNA servers.

SNA Server Hardware Requirements in Relation to Usage and Number of Users


Evaluating Demand and Performance on an SNA Server
Basic Methods for Evaluating Hardware Requirements	3 of 5

Evaluating Demand and Performance on an SNA Server

If you have one or more SNA servers currently in use, you can evaluate the demand and performance on the servers in order to obtain a benchmark, and to estimate hardware requirements for future growth. The two primary tools for doing this kind of evaluation are the Performance Monitor (which is part of Windows NT) and the server status information available through SNA Server Admin. The following sections describe these tools.

A full range of other diagnostic tools is available for SNA Server. For information about all the diagnostic tools (such as event logs), see Chapter 13 of the Microsoft SNA Server Administration Guide.

For information about some common event log entries on SNA servers, see Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.” For information about tuning SNA servers to maximize communications throughput, see Appendix C, “Options for Maximizing Communications Throughput.”


Performance Monitor
Basic Methods for Evaluating Hardware Requirements	4 of 5

Evaluating Demand and Performance on an SNA Server

Performance Monitor

The Performance Monitor is a graphical tool included in Windows NT. The Performance Monitor allows you to collect performance data on your computer or other computers on the network. To start the Performance Monitor, double-click on the Performance Monitor icon, located by default in the Administrative Tools program group. For detailed instructions for using Performance Monitor, see the online help or your Windows NT Server documentation.

Studying and Understanding Performance Data

Server performance is a very complex topic. Studying activity on a moderately or heavily used server involves studying a complex set of processes and process interactions. Detailed interpretation of the data requires an understanding of how the operating system works (for example, how virtual memory is managed or how processor time is divided between competing processes).

Therefore, background information is essential for understanding performance data. One source of background information is provided in the next section. Other sources of information include the following:

Inside Windows NT by Helen Custer (Microsoft Press)

Provides excellent information about how the operating system allocates resources such as processor time and memory.

Optimizing Windows NT, a volume by Russ Blake in the Windows NT Resource Kit (Microsoft Press)

Includes chapters about performance monitoring and capacity planning, as well as chapters about various kinds of bottlenecks — processor, memory, disk, cache, and network.

Microsoft Windows NT Concepts and Planning Guide

Part of the Microsoft Windows NT documentation set. Includes a chapter about monitoring network activity and performance.

The explanation text in Performance Monitor

Available while running Performance Monitor. For information, see “Viewing Explanation Text in Performance Monitor,” later in this chapter.

Useful Performance Counters on SNA Servers

The following list describes objects and counters that may be useful for evaluating the demand and performance on an SNA server. (Note: as SNA Server software is updated, counters will probably be added or improved, expanding the data available through Performance Monitor.)

Memory: Pages/sec

In order to understand memory load on a Windows NT Server, it is necessary to understand paging, a technique for implementing virtual memory. Paging is the swapping of blocks (pages) of program instructions or data back and forth between memory and disk, and is carried out as needed by the virtual memory manager in Windows NT.

Pages/sec is the number of pages read from the disk or written to the disk because they were not in memory when needed (that is, the number of “page faults” that required disk access). The counter includes paging traffic generated when the cache accesses file data for applications.

This is the primary counter for determining whether your server is paging excessively (or “thrashing”). As this counter goes up, server responsiveness slows, because of the time required for disk access (reading or writing). A server dedicated to communications should be equipped with enough physical memory so that little paging is required.

The highest acceptable value for Pages/sec varies from system to system. One way to judge whether system load is causing too much paging is to observe whether processor activity (System: %Total Processor Time) drops significantly as paging increases. This indicates that the system is occupied with swapping pages rather than with actually processing instructions.

The primary ways to correct excessive paging are to add more physical memory to the server, or to consider ways to decrease the demand on the server. Demand can be decreased by narrowing the variety of tasks that a server must perform or by decreasing the number of users accessing a server. For example, an overloaded multipurpose server (with file, print, and SNA server demands) could be dedicated to SNA server traffic only. Or, as another example, user loads placed on one SNA server could be divided between two SNA servers (this is called “load balancing’ and is demonstrated in Chapters 5 and 6 in descriptions of “hot backup across servers”). As mentioned, in any case of memory overload, adding physical memory may provide the needed performance increase.

A secondary way to decrease the impact of paging is to upgrade the disk system to be more efficient. This includes installing a faster disk, installing a second disk, using RAID striping, or similar upgrades. This upgrading does not decrease paging (Pages/sec), but speeds up the paging process itself. For example, replacing a slow IDE disk with a faster SCSI disk may make a given paging rate (perhaps 20 – 40 pages/sec) acceptable.

System: %Total Processor Time

Processor: %Processor Time

System: %Total Processor Time is the percentage of elapsed time during which the system processors are busy. It can be viewed as the fraction of total processor time spent doing useful work. Values of 60 – 80% during typical loads are good values, because they allow some reserve for peak loads. However, when the processor stays at 100% for periods of time, this may indicate a processor bottleneck. On a multiprocessor system, you can view Processor: %Processor Time for each processor, to see how the load is distributed among processors.

One useful way to view Total Processor Time values is in Chart view along with counters indicating increases and decreases in user load. For SNA user load, such counters include SNA Logical Unit Sessions: Throughput Bytes/Sec, and SNA Adapter adaptername: Throughput Frames/Sec. (These two counters are available only when there is SNA activity.) For example, you might notice that during a period of peak demand for SNA logical unit sessions, Total Processor Time reaches 100% and stays there. This could indicate that the SNA server is reaching peak capacity, and any future additional demand might require additional processors or additional servers.

It may also be helpful to view System: %Total Processor Time along with any other counters related to the server’s major functions. For example, for SNA servers that are also file servers, the Server: Server Sessions counter may be helpful. Other counters that may help you analyze the sources of processor activity are Process: %Processor Time for processes you think are relevant, as well as System: Total Interrupts/sec. Also, if your clients are using NetWare, consider looking at NWLink SPX: Connections Open. Similarly, if your clients use TCP/IP, consider looking at TCP: Connections Established.

System: Total Interrupts/sec

Processor: Interrupts/sec

System: Total Interrupts/sec is the rate at which the computer is receiving and servicing device interrupts. (Device interrupts are the signals a device sends to a processor to indicate that a task is complete or the device requires attention.) Some devices that may generate interrupts are SNA adapters, network adapters, the system timer (clock), and the mouse. System: Total Interrupts/sec provides an indication of how busy these devices are on a computer-wide basis.

Similarly, for each processor, Processor: Interrupts/sec is the rate the processor is receiving device interrupts.

Note that normal thread execution is suspended during interrupts. An interrupt may cause the processor to switch to another, higher-priority thread. Clock interrupts are periodic and frequent (on the order of 100/sec); they create a background of interrupt activity.

These counters can help indicate the general demand on a server, and may be useful when combined with processor and memory data such as System: %Total Processor Time and Memory: Pages/sec.

SNA Connections: Throughput Bytes/Sec

SNA Logical Unit Sessions: Throughput Bytes/Sec

SNA Adapter adaptername: Throughput Frames/Sec

These counters provide an indication of SNA activity. When observing these counters, it may also be useful to start SNA Server Admin and double-click on the server (the same one being observed in Performance Monitor). This will allow you to see the number of users and sessions that correlate with a particular level of SNA activity. This information, combined with data about the processor and memory load, can help you understand the load and performance on your SNA servers. (Note that low throughput does not necessarily mean poor performance, but instead may simply indicate that current activity is low.)

Note that measurement of frames/second may provide a better indicator of server load than bytes per second, because server overhead (for interrupt handling and message processing) increases per frame, not per byte. That is, a large frame with many bytes requires about the same overhead as a small frame with fewer bytes.

For suggested ways to tune SNA servers to maximize communications throughput, see Appendix C, “Options for Maximizing Communications Throughput.”

SNA Connections: Data Bytes Received/Sec

SNA Connections: Data Bytes Transmitted/Sec

SNA Logical Unit Sessions: Data Bytes Received/Sec

SNA Logical Unit Sessions: Data Bytes Transmitted/Sec

SNA Adapter adaptername: Data Bytes Received/Sec

SNA Adapter adaptername: Data Bytes Transmitted/Sec

SNA Adapter adaptername: Frames Received/Sec

SNA Adapter adaptername: Frames Transmitted/Sec

SNA Adapter adaptername: Throughput Bytes/Sec

These counters provide additional detail about SNA activity, when used with the previous three counters.

SNA Adapter adaptername: Adapter Failures

SNA Adapter adaptername: Connection Failures

SNA Adapter adaptername: Successful Connects

These counters may be useful for detecting patterns in which connections or adapters fail for short periods and then return to normal. (Event logs can provide more information about causes of failure.) You might also want to set up Performance Monitor alerts with these counters, so that an alert is triggered if too many failures are occurring.

Viewing Explanation Text in Performance Monitor

One source of information about performance counters is the explanation text available in Performance Monitor from Chart, Alert, or Report view.

To view explanation text for counters in Performance Monitor

1.	Start Performance Monitor.

2.	From the View menu, choose Chart, Alert, or Report.

Do not choose Log; explanation text is not available from Log view.

3.	From the Editor menu, choose Add To View (where View is Chart, Alert, or Report).

4.	In the resulting dialog box, choose the Explain button.

The dialog box expands to display a Counter Definition.

5.	Select an object and counter that you are interested in, and read the Counter Definition that appears.

The Counter Definition text can also be selected (using the mouse or keyboard) and then copied to the Clipboard by pressing CTRL+INS. The copied text can then be pasted into a file in a text editor for later printing or viewing.


Status Information in SNA Server Admin
Basic Methods for Evaluating Hardware Requirements	5 of 5

Evaluating Demand and Performance on an SNA Server

Status Information in SNA Server Admin

SNA Server Admin includes several types of status information that can supplement other performance information:

The status of servers and connections (Inactive, Pending, Active, and so on), which can be viewed in the Servers and Connections window by selecting the server of interest.

The number of users and the number of sessions, which can be viewed by double-clicking on the relevant SNA server. This information can be especially useful when viewed with data from Performance Monitor (see the preceding sections).

The names of active 5250 users being supported by a particular local LU. If there is only one local LU per server, the names will include all users with active 5250 sessions on a particular server. For more information, see “Viewing User and Computer Names of 5250 Users” in Chapter 6.


Establishing a Connection Successfully
Chapter 4	1 of 8

Establishing a Connection Successfully

This chapter describes some important configuration settings for a successful SNA Server connection. It provides an overview, gives instructions for a software update needed for some computers, describes settings to check for all connection types, and then provides instructions and tips for each connection type.

This chapter discusses SNA connections (SDLC, token ring, Ethernet, X.25, and so on), not LAN or WAN (network) protocols (IPX/SPX, TCP/IP, and so on). For information about network protocols on SNA servers, see Chapter 2, “Server Placement and Protocol Choices.” For information about network protocols on clients, see Appendix A, “Network Protocols and Client-Server Communication.”

For background information about SNA Server communication, see Chapter 1, “Introduction to SNA Server.” For information about tuning SNA servers to maximize communications throughput, see Appendix C, “Options for Maximizing Communications Throughput.”


Overview of Connections
Establishing a Connection Successfully	2 of 8

Overview of Connections

Within the context of SNA Server, a connection is the data communication path between an SNA server and an IBM host (mainframe or AS/400). A connection is what makes it possible for a PC user on the LAN to communicate with a host via an SNA server. For background information about connection types, see “Communication Between SNA Servers and Host Computers: Connections” in Chapter 1.

In order for a connection to be established successfully, a number of software settings and hardware characteristics must work together, as summarized in Figure 4.1.

Figure 4.1    Summary of Important Elements in Connections

Table 4.1 provides more details about important items to consider.

Table 4.1    Items to Consider When Configuring a Connection

Element	Important items to consider
Host configuration settings (VTAM, NCP, or AS/400 settings); must match the Connection and server settings on the SNA server	Mainframe Node ID settings: For most mainframes, IDBLK and IDNUM in the PU definition must be matched by the two parts of the Remote Node ID on the SNA Server connection. AS/400 name settings: For the AS/400, local and remote control point names (CP names) and network names must be matched with corresponding SNA Server settings (local names configured on the server; remote names on the connection). Addresses: For several connection types (802.2, X.25, Channel), host settings must be matched with equivalent settings on the SNA Server connection. For details, see the section about the type of connection you are configuring, later in this chapter. BTU length: For the mainframe, this is set through MAXDATA in the PU definition. For the AS/400, this is set through MAXFRAME. These should equal the Max BTU Length on the SNA Server connection. Other settings: For some connections, other settings are also important. For example, for SDLC, the NRZ/NRZI settings on the host must match those on the SNA Server connection. For details about these and other settings, see the section about the type of connection you are configuring, later in this chapter.
For SDLC and X.25: Communications hardware: line, modem (if applicable), and adapter characteristics; must match the  Link service and connection settings on the SNA server	Speed and duplexing: For SDLC and X.25, note the speed and duplexing capabilities of the line, modem (or DCE), and adapter, and make sure that they will not be exceeded by the settings in the SNA Server link service and connection. Settings for fast transmission or for full duplexing cause greater demands on hardware; both together (fast transmission plus full duplexing) cause the greatest demands. The hardware element with the smallest capacity will limit the capacity of the entire system. For example, with an SDLC adapter that lacks a coprocessor, full-duplex transmissions at high speeds cannot be used, even if the modem and line can handle them.


Settings to Check for Connections
Establishing a Connection Successfully	3 of 8

Settings to Check for Connections

The following sections list and describe the settings to check when configuring a new SNA Server connection or troubleshooting an existing connection. The first section lists settings to check for all types of connections. The remaining sections are organized according to connection type: 802.2, SDLC, X.25, Channel, DFT, and Twinax. Note that because Channel, DFT, and Twinax are relatively simple to configure, they are described together in one section.


Settings to Check on All Connections
Establishing a Connection Successfully	4 of 8

Settings to Check for Connections

Settings to Check on All Connections

When configuring a new SNA Server connection or troubleshooting an existing connection, regardless of the connection type, the identifiers must match between the SNA server and the host. The type of identifier (ID or name) is as follows:

For most mainframe connections

Node ID is the identifier used when exchanging identification (XIDs) with most mainframes. Check to make sure that the following items match; if they don’t, the SNA server is not identifying itself in a way that the host can recognize.

Identifier used on mainframe	Identifier to configure on SNA server
IDBLK and IDNUM in the PU definition	The two parts of the Local Node ID (configured on the connection)
For other mainframe connections

There are some situations where the mainframe does not use Node ID in XIDs, but instead uses network name and control point name. These situations include mainframes communicating through LU 6.2, and mainframes that call up the SNA server (meaning that the SNA server accepts incoming calls on that mainframe connection). In these situations, the following parameters must match.

Note

Use the following identifiers only when necessary. They are more complicated than needed for most mainframe connections, and add the potential for error when used unnecessarily.

Identifier used on mainframe (in unusual cases only)	Identifier to configure on SNA server
NETID in the VTAM Start command for the local SSCP CPNAME in the PU definition  NETID and  SSCPNAME in the VTAM Start command for the remote SSCP (VTAM system)	Local Network Name  (configured on the server) Local Control Point Name (configured on the server) Remote Network Name and Remote Control Point Name (configured on the connection)
For AS/400 connections

Network name and control point name (used together and called the fully qualified name) are the identifiers used when exchanging identification (XIDs) with AS/400 computers. Check to make sure that the following items match; if they don’t, the SNA server is not identifying itself in a way that the AS/400 can recognize.

Identifier used on AS/400	Identifier to configure on SNA server
RMTNETID (usually; often set to APPN); RMTCPNAME	Local Network Name and Local Control Point Name (configured on the server)
RMTNETID (often set to APPN);  CP Name (shown in the “Display network attributes” screen)	Remote Network Name and Remote Control Point Name (configured on the connection)
For more detailed information about remote node identifiers, see “Using Remote Node Identifiers” in Chapter 1 of the Microsoft SNA Server Administration Guide.

Note that event log entries can be very helpful in diagnosing and correcting mismatched identifiers between SNA server and host. To view event log entries related to SNA Server, in the Administrative Tools group, double-click the Event Viewer icon, and then, from the Log menu, choose Application. For entries related to SNA Server, the Source column has “SNA” in the name. Some common event log entries that occur on SNA servers are described in Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.”


Settings to Check on 802.2 Connections
Establishing a Connection Successfully	5 of 8

Settings to Check for Connections

Settings to Check on 802.2 Connections

An 802.2 connection is a token ring, Ethernet, or FDDI connection.

802.2 Adapters and Link Services: Installation Pointers

An 802.2 link service enables the SNA Server software to communicate with an Ethernet, token ring, or FDDI adapter. Detailed instructions for installing an 802.2 link service are provided in the Microsoft SNA Server Installation Guide. The following pointer highlights an important step for installing an 802.2 adapter and link service:

When you install a new adapter, check the interrupt, port address, and direct memory access (DMA) settings, to avoid conflicts with other adapters in the computer. The normal method for adjusting the settings among your adapters is through EISA configuration programs, jumpers on the motherboard, or configuration utilities (for example, the Control Panel Devices or Ports options, or utilities supplied with your adapters). For details about settings for IBM Token Ring adapters, see “IBM Token Ring Adapter Notes” in Chapter 2 of the Microsoft SNA Server Installation Guide.

One way of viewing the settings used by various adapters in your computer is to start WINMSD.EXE, the Windows NT Diagnostics utility, which includes an IRQ/Port Status button and a DMA/Memory button.

Note

Device drivers provided by SNA Server report any interrupt, port address, or DMA conflicts they detect to the Windows NT system event log. The events are listed under a Source of Service Control Manager or a driver name.

802.2 Connections: Configuration Pointers

Connections are configured through SNA Server Admin. The steps for configuring an 802.2 connection are described in detail in the Microsoft SNA Server Administration Guide and in the online help for SNA Server Admin. The following pointers indicate items to pay special attention to:

As with all connections, the identifiers must be configured correctly. For details, see “Settings to Check on All Connections,” earlier in this chapter.

Pay close attention to the Remote Network Address (which can be viewed by double-clicking the connection and choosing the Setup button); it should match the 12-digit hexadecimal network address of the remote host, peer, or downstream system. The following guidelines may help:

For...	Set the Remote Network Address to...
Connections to a 3174 controller	The value in the configuration response 900 of the controller's customization program.
Connections to a 3720, 3725, or 3745 front-end processor	LOCADDR in the NCP LINE macro.
Connections to an IBM mainframe	MACADDR in the VTAM PORT definition
Connections to an AS/400	ADPTADR in the Line Description on the AS/400
Check the Max BTU Length setting, found in the Advanced part of the 802.2 Setup dialog box (accessible by double-clicking the connection and then choosing the Setup button followed by the Advanced button). A BTU is also called an I-frame; it is the number of bytes that can be transmitted in a single data-link information frame.

Set the Max BTU Length so that it matches the capacity of the adapter and the host or downstream system. Otherwise, when the mainframe or AS/400 sends a logon screen, the BTU length (frame size) that is used will be unworkable, causing the connection to be dropped. The following table provides guidelines:

Adapter type	Max BTU Length to use
Token ring adapter that transmits at 4 Mbps (megabits per second)	Less than or equal to 4195.
Token ring adapter that transmits at 16 Mbps	The appropriate value for the host or downstream system; the adapter itself can handle the greatest Max BTU Length available with SNA Server, 16393.
Ethernet adapter	Less than or equal to 1493.
Connection type	Max BTU Length to use
Connection to a mainframe	Equal to MAXDATA in the PU definition on the mainframe (recommended).
Connection to an AS/400	Equal to MAXFRAME on the AS/400 (recommended).
Connection to a downstream system	Less than or equal to the maximum value supported by the downstream system.
Setting the Max BTU Length correctly is especially important for downstream connections.

With 802.2 connections, you can adjust a variety of other settings, especially timeout and retry settings. However, the defaults for the timeouts and retries are appropriate for most networks. Therefore, it is recommended that you do not adjust these settings unless you have a specific reason for doing so, and you understand the characteristics of your network as well as the way that the timeouts work. For descriptions of the timeout and retry settings, see the Microsoft SNA Server Administration Guide or the SNA Server Admin help.

802.2 Connections: Troubleshooting

The following table outlines some ways to interpret symptoms of a nonfunctioning 802.2 connection:

Symptom	Configuration item to check
Symptom: SNA server will not start; the System event log (viewable through the Event Viewer) contains messages about a link service failing to start.	Recommendation: Check that all existing link services are configured to work with functioning adapters. The SNA server service cannot start if any existing link service cannot start, even if that link service is not being used by any connection.
Symptom: SNA server will not start; System event log contains messages about conflicts in port addresses, IRQs, or DMA addresses.	Recommendation: Check the port address, IRQ setting, or DMA address of your 802.2 adapter, which may be conflicting with those of another adapter or port in your computer. Change the settings on one of the adapters or ports, if possible, or remove the conflicting adapter. For more information, see “802.2 Adapters and Link Services: Installation Pointers,” earlier in this chapter. Another source of information is “IBM Token Ring Adapter Notes” in Chapter 2 of the Microsoft SNA Server Installation Guide.
Symptom: Connection can only reach “Pending” status, and Application event log contains event 230.	Recommendation: Check that the identifiers (IDs or names) and/or the network address used by the host match the corresponding parameters in SNA Server Admin. (To view these parameters, double-click on the connection and then choose the Setup button.) The identifiers or addresses must match in order for the exchange of identifiers (XIDs) and test frames to complete successfully. For more information about identifiers, see the preceding section and “Settings to Check on All Connections,” earlier in this chapter.
Symptom: Connection (especially downstream connection) may become active, but reverts to “Pending” when first user attempts to start a session.	Recommendation: Check the Max BTU Length setting for the connection (to see the setting, in SNA Server Admin, double-click on the connection and then choose the Setup button followed by the Advanced button). For details about the correct setting to use, see the preceding section.
Symptom: Connection reaches “Active” status, but reverts to Pending; event 23 is generated in the Application event log.	Recommendation: Check for conditions described for event 23 in Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.” Possible causes include LAN or router problems, or actions by the remote system (for example, an AS/400 disconnecting because of lack of activity).
Note that with 3270 LUs, if one or more of the LUs never become active even when users are attempting to start sessions, the LOCADDR settings in the LU definitions in VTAM or NCP may not match the SNA Server LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP. To correct this, consult with the administrator of the host system.


Settings to Check on SDLC Connections
Establishing a Connection Successfully	6 of 8

Settings to Check for Connections

Settings to Check on SDLC Connections

An SDLC connection uses a standard phone line, which may be leased or switched and may be point-to-point or multidrop. The following sections provide pointers for configuring an SDLC connection.

SDLC Adapters and Link Services: Installation Pointers

An SDLC link service enables the SNA Server software to communicate with the SDLC adapter. For detailed instructions for installing an SDLC link service, see the Microsoft SNA Server Installation Guide. For detailed information about using a particular SDLC adapter or a particular modem (or DCE), see the adapter, modem, or DCE documentation.

The following pointers highlight important steps for installing an SDLC adapter and link service:

Selecting the Constant RTS option in the IBM SDLC Link Service Setup dialog box is the equivalent of the following in the NCP LINE macro:

DUPLEX=FULL

This configuration is recommended for all SDLC connections except tributary connections on multidrop SDLC lines. This configuration improves performance by eliminating several seconds of line turnaround delay after each transmission.

The Constant RTS option is mandatory if the line is used for full duplex, but it can also enhance performance on a half-duplex line.

When choosing an SDLC adapter, pay close attention to the speed and duplexing capabilities. Greater speed and/or full-duplexing capabilities allow an adapter to carry greater loads. Note that an adapter that lacks a coprocessor cannot handle full-duplex transmission at high transmission speeds, that is, greater than 9600 baud. (Examples of adapters lacking a coprocessor are the IBM SDLC, IBM MPCA, and MicroGate [image] adapters. For these adapters, half-duplex transmission is recommended.)

For adapters that lack a coprocessor, although half duplexing is slower, it has the advantage of requiring substantially less central proccessing unit (CPU) time, because it means that transmitted information will be processed as frames by the device driver via DMA. In contrast, if you use full duplex with such adapters, the device driver must handle interrupts as characters, placing more load on the CPU. However, if the CPU can handle the load, full duplex provides substantially faster throughput, if the host VTAM configuration also specifies full duplex (DATMODE=FULL in the PU definition).

After installation of the adapter and link service, you will need to configure the connection with the correct Duplex setting; for details, see the next section.

Stop all existing services that use the SDLC adapter before running SNA Server Setup. For example, stop the Remote Access Service if it uses the SDLC adapter. Only when these services are stopped can SNA Server Setup successfully autodetect the adapter.

Important

If you attempt to install an SDLC link service for an adapter that you know is physically installed in the computer, and a pop-up message appears, saying that SNA Server Setup cannot detect the adapter, choose Cancel. The message indicates that a service is currently using the SDLC adapter. Find out what service it is, stop the service, and then run SNA Server Setup again.

SNA Server Setup can detect the adapter only if no other service is using that adapter. If you do not choose Cancel when the pop-up message appears, SNA Server Setup continues the installation process using default values (not values attuned to that adapter, since Setup cannot detect it). As described in the preceding paragraph, to correct this situation, stop the service using the SDLC adapter and run SNA Server Setup again.

When you install a new adapter, check the interrupt, port address, and direct memory access (DMA) settings to avoid conflicts with other adapters in the computer. The normal method for adjusting the settings among your adapters is through EISA configuration programs, jumpers on the motherboard, or configuration utilities (for example, the Control Panel Devices or Ports options, or utilities supplied with your adapters). For details, see “Avoiding Interrupt or Address Conflicts Between Adapters” in Chapter 2 of the Microsoft SNA Server Installation Guide.

One way of viewing the settings used by various adapters in your computer is to start WINMSD.EXE, the Windows NT Diagnostics utility, which includes an IRQ/Port Status button and a DMA/Memory button.

Note

Device drivers provided by SNA Server report any interrupt, port address, or DMA conflicts they detect to the Windows NT system event log. The events are listed under a Source of Service Control Manager or a driver name.

To ensure that the line speed is set correctly through hardware or software settings, study the documentation for the modem or DCE. (Do not confuse setting the line speed with selecting the Data Rate, configurable through the SDLC Setup dialog box, under Advanced settings, in SNA Server Admin. The Data Rate setting controls the speed of transmissions between the SDLC adapter and the modem only.)

With a MicroGate adapter (or any adapter that can handle a server-stored phone number), if you want to use a server-stored number, check that both the link service and the modem are configured correctly for this. On the modem, it may be necessary to override the setting that causes the modem to autodial from its own stored number. (In modem terminology, when Data Terminal Ready — DTR — is raised, the modem must wait, not dial.) To find out how to override modem autodialing, see your modem or DCE documentation. For more information about modem requirements for using a server-stored phone number, see “Requirements for Using Server-Stored Numbers” in Chapter 2 of the Microsoft SNA Server Installation Guide or in the SNA Server Setup help.

SDLC Connections: Configuration Pointers

Connections are configured through SNA Server Admin. The steps for configuring an SDLC connection are described in detail in the Microsoft SNA Server Administration Guide and in the online help for SNA Server Admin. The following pointers indicate items to pay special attention to:

As with all connections, the settings must be configured correctly. For details, see “Settings to Check on All Connections,” earlier in this chapter.

If possible, configure the connection to use constant RTS. See the recommendations in “SDLC Adapters and Link Services: Installation Pointers,” earlier in this chapter.

The Duplex setting is found in the Advanced part of the SDLC Setup dialog box, accessible by double-clicking the connection and then choosing the Setup button followed by the Advanced button. Duplex can be Half or Full; the setting must not exceed the capabilities of the adapter and modem. For more information about the factors to consider when choosing the setting for Duplex, see the preceding section.

Check the Encoding setting, which is either nonreturn to zero (NRZ) or nonreturn to zero inverted (NRZI). The setting is in the Advanced part of the SDLC Setup dialog box, accessible by double-clicking the connection and then choosing the Setup button followed by the Advanced button. This setting must match the equivalent setting on the host. For connections to mainframes, the NRZI setting is found in the LINE/GROUP definition in VTAM or NCP. (If VTAM does not specify the NRZI setting, it defaults to NRZI = YES.) For connections to AS/400 computers, the NRZI setting is in the Line Description.

When multiple SDLC connections accept incoming calls and use the same link service, the encoding (NRZ/NRZI) settings for all the connections must match.

Check the Max BTU Length setting, found in the Advanced part of the SDLC Setup dialog box (accessible by double-clicking the connection and then choosing the Setup button followed by the Advanced button). A BTU is also called an I-frame; it is the number of bytes that can be transmitted in a single data-link information frame.

Set the Max BTU Length so that it matches the capacity of the adapter and the host or downstream system. Otherwise, when the mainframe or AS/400 sends a logon screen (typicaly a full screen), the BTU length (frame size) that is used will be unworkable, causing the connection to be dropped. The following table provides guidelines:

For...	Set the Max BTU Length to...
IBM SDLC adapter	521 or less.
Connection to a mainframe	Equal to MAXDATA in the PU definition on the mainframe (recommended).
Connection to an AS/400	Equal to MAXFRAME on the AS/400 (recommended).
Connection to a downstream system	Less than or equal to the maximum value supported by the downstream system.
Setting the Max BTU Length correctly is especially important for downstream connections.

With SDLC connections, you can adjust a variety of other settings, especially timeout and retry settings. However, the defaults for the timeouts and retries are appropriate for most networks. Therefore, it is recommended that you do not adjust these settings unless you have a specific reason for doing so, and you understand the characteristics of your communications lines as well as the way that the timeouts work. For descriptions of the timeout and retry settings, see the Microsoft SNA Server Administration Guide or the SNA Server Admin help.

SDLC Connections: Troubleshooting

To begin troubleshooting an SDLC connection, it is helpful to look at two simple indicators of activity: the server and connection status shown in SNA Server Admin, and the modem lights. Event logs also provide important information. The following table outlines some ways to interpret symptoms of a nonfunctioning SDLC connection:

Symptom	Configuration item to check
Symptom: SNA server will not start; the System event log (viewable through the Event Viewer) contains messages about a link service failing to start.	Recommendation: Check that all existing link services are configured to work with functioning adapters. The SNA server service cannot start if any existing link service cannot start, even if that link service is not being used by any connection.
Symptom: SNA server will not start; System event log contains messages about conflicts in port addresses, IRQs, or DMA addresses.	Recommendation: Check the port address, IRQ setting, or DMA channel of the SDLC adapter, which may be conflicting with those of another adapter (for example, a sound system adapter) or port in your computer. Change the settings on one of the adapters or ports, if possible, or remove the conflicting adapter. For more information, see “SDLC Adapters and Link Services: Installation Pointers,” earlier in this chapter.
Symptom: Modem lights may flash but the connection remains at Pending and does not go to Active.	Recommendation: Check the DMA channel setting (jumpers) on the adapter and compare this to the setting in SNA Server Setup. If the setting in SNA Server Setup specifies a nonexistent address, data cannot flow.
Symptom: Modem appears to make the connection (“receive data” light flashes, but “transmit data” light does not); however, connection status reaches “Pending” and then connection is dropped.	Recommendation: Check the cables; then check the Encoding (NRZ/NRZI) setting used by the host and compare this to the setting in SNA Server Admin (double-click the connection and choose the Setup button followed by the Advanced button). If the NRZ/NRZI settings do not match, the two ends of the connection begin negotiating but cannot interpret each other’s signals correctly. For more information, see the preceding section.
Symptom: Modem lights are flashing but the connection can only reach “Pending” status. Also, the Application event log contains event 182.	Recommendation: Check that the identifiers (IDs or names) used by the host match the ones used in SNA Server Admin (double-click on the connection and then choose the Setup button). If the identifiers do not match, the exchange ID (XID) process cannot complete successfully. For more information about identifiers, see “Settings to Check on All Connections,” earlier in this chapter.
Symptom: Connection (especially downstream connection) may become active, but reverts to “Pending” when first user attempts to start a session.	Recommendation: Check the Max BTU Length setting for the connection (to see the setting, in SNA Server Admin, double-click on the connection and then choose the Setup button followed by the Advanced button). For details about the correct setting to use, see the preceding section.
Note that with 3270 LUs, if one or more of the LUs never become active even when users are attempting to start sessions, the LOCADDR settings in the LU definitions in VTAM or NCP may not match the SNA Server LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP. To correct this, consult with the administrator of the host system.


Settings to Check on X.25 Connections
Establishing a Connection Successfully	7 of 8

Settings to Check for Connections

Settings to Check on X.25 Connections

An X.25 connection uses a packet-switching network, and communicates through the Qualified Logical Link Control (QLLC) protocol. The following sections provide pointers for configuring an X.25 connection.

X.25 Adapters and Link Services: Installation Pointers

An X.25 link service enables the SNA Server software to communicate with the X.25 adapter. Detailed instructions for installing an X.25 link service are provided in the Microsoft SNA Server Installation Guide. The following pointers highlight important steps for installing an X.25 adapter and link service:

When choosing an X.25 adapter, pay close attention to the speed capabilities. Greater speed allows an adapter to carry greater loads. Note that an adapter that lacks a coprocessor cannot handle high-speed transmission with full duplexing, the duplexing type used by SNA Server X.25 connections. (Examples of adapters lacking a coprocessor are the IBM SDLC and IBM MPCA adapters. For these adapters, the transmission speed must be 9600 baud or less.)

Contact your X.25 carrier or network administrator for information needed for your X.25 link service. The following table lists some important parameters to obtain information about:

Parameter to obtain information about from X.25 carrier	Corresponding parameter in SNA Server Setup	Typical value(s)
Local X.25 address	Local NUA Address	varies
Level 3 window size	Default L3 Window Size	2
Level 3 packet size	Default L3 Packet Size	512
Level 2 window size	L2 Window Size	7
Channel ranges (for outgoing SVC, two-way SVC, incoming SVC, and/or PVC)	Channel Ranges (Outgoing SVC, TwoWay SVC, Incoming SVC, and/or PVC)	vary
Note that the encoding setting (NRZ or NRZI) is almost always NRZ on X.25 networks; your network administrator or X.25 carrier can advise you about your network. (This setting must match the equivalent setting on the host. For connections to mainframes, the NRZI setting is found in the LINE/GROUP definition in VTAM or NCP. If VTAM does not specify the NRZI setting, it defaults to NRZI = YES. For connections to AS/400 computers, the NRZI setting is in the Line Description.)

For descriptions of all the preceding parameters, see Chapter 2 of the Microsoft SNA Server Installation Guide.

When you install a new adapter, check the interrupt, port address, and direct memory access (DMA) settings, to avoid conflicts with other adapters in the computer. The normal method for adjusting the settings among your adapters is through EISA configuration programs, jumpers on the motherboard, or configuration utilities (for example, the Control Panel Devices or Ports options, or utilities supplied with your adapters). For details, see “Avoiding Interrupt or Address Conflicts Between Adapters” in Chapter 2 of the Microsoft SNA Server Installation Guide.

One way of viewing the settings used by various adapters in your computer is to start WINMSD.EXE, the Windows NT Diagnostics utility, which includes an IRQ/Port Status button and a DMA/Memory button.

Note

Device drivers provided by SNA Server report any interrupt, port address, or DMA conflicts they detect to the Windows NT system event log. The events are listed under a Source of Service Control Manager or a driver name.

Ignore the option labeled “Switched: Server-Stored Number” in the X.25 link service setup dialog box. This option does not match capabilities currently available with X.25 link services; if chosen, the option behaves the same way as “Switched: Modem-Stored Number.”

With X.25 link services, you can also adjust the T1 timeout and N2 retry limit. However, the defaults for these are appropriate for most networks. Therefore, it is recommended that you do not adjust them unless you have a specific reason for doing so, and you understand the characteristics of your network as well as the way that the timeout works. For descriptions of T1 and N2, see the Microsoft SNA Server Installation Guide or the SNA Server Setup help.

X.25 Connections: Configuration Pointers

Connections are configured through SNA Server Admin. The steps for configuring an X.25 connection are described in detail in the Microsoft SNA Server Administration Guide and in the online help for SNA Server Admin. The following pointers indicate items to pay special attention to:

As with all connections, the identifiers must be configured correctly. For details, see “Settings to Check on All Connections,” earlier in this chapter.

Pay close attention to the Remote X.25 Address (accessible by double-clicking the connection and choosing the Setup button); it should match the address of the remote host, peer, or downstream system. The address consists of from 1 through 15 hexadecimal digits. If a 15-digit address is used, the final 3 digits are used for routing between stations with the same 12-digit address. For connections to a host using VTAM, the address should match the DIALNO parameter in the PORT definition. For connections to an AS/400, the address should match the local address of the AS/400 (assigned by the X.25 carrier).

Check the Max BTU Length setting, found in the Advanced part of the X.25 Setup dialog box (accessible by double-clicking the connection and then choosing the Setup button followed by the Advanced button). A BTU is a data-link information frame.

Set the Max BTU Length so that it matches the capacity of the adapter and the host or downstream system. Otherwise, when the mainframe or AS/400 sends a logon screen, the BTU length (frame size) that is used will be unworkable, causing the connection to be dropped. The following table provides guidelines:

For...	Set the Max BTU Length to...
IBM SDLC adapter	521 or less.
Connection to a mainframe	Equal to MAXDATA in the PU definition on the mainframe (recommended).
Connection to an AS/400	Equal to MAXFRAME on the AS/400 (recommended).
Connection to a downstream system	Less than or equal to the maximum value supported by the downstream system.
Setting the Max BTU Length correctly is especially important for downstream connections.

For SVC connections, check that the codes in User Data include C3, which specifies the QLLC protocol (the X.25 protocol used by SNA Server). To view User Data codes, double-click on the connection, followed by the Setup button, then choose the Advanced button. For information about other user data codes to use, contact your X.25 network administrator.

If each attempt at connection activation costs money due to access of the X.25 network, you may want to limit the number of these attempts. To do this, double-click on the connection, then choose the Setup button followed by the Retry Timers button. The Connection Activation Limits dialog box appears; set an appropriate maximum number of attempts. (The default is No limit.)

X.25 Connections: Troubleshooting

The following table outlines some ways to interpret symptoms of a nonfunctioning X.25 connection:

Symptom	Configuration item to check
Symptom: SNA server will not start; the System event log (viewable through the Event Viewer) contains messages about a link service failing to start.	Recommendation: Check that all existing link services are configured to work with functioning adapters. The SNA server service cannot start if any existing link service cannot start, even if that link service is not being used by any connection.
Symptom: SNA server will not start; System event log contains messages about conflicts in port addresses, IRQs, or DMA addresses.	Recommendation: Check the port address, IRQ setting, or DMA address of your X.25 adapter, which may be conflicting with those of another adapter or port in your computer. Change the settings on one of the adapters or ports, if possible, or remove the conflicting adapter. For more information, see “X.25 Adapters and Link Services: Installation Pointers,” earlier in this chapter.
Symptom: Connection can only reach “Pending” status, and Application event log contains event 23 with an outage code of 0x62 (for SVC) or 0x61 (for PVC).	Recommendation: Check that the identifiers (IDs or names) and/or the X.25 address used by the host match the corresponding parameters in SNA Server Admin. (To view these parameters, double-click on the connection and then choose the Setup button.) The identifiers or addresses must match in order for the exchange of identifiers (XIDs) and test frames to complete successfully. For more information about identifiers, see the preceding section and “Settings to Check on All Connections,” earlier in this chapter.
Symptom: Connection (especially downstream connection) may become active, but reverts to “Pending” when first user attempts to start a session.	Recommendation: Check the Max BTU Length setting for the connection (to see the setting, in SNA Server Admin, double-click on the connection and then choose the Setup button followed by the Advanced button). For details about the correct setting to use, see the preceding section.
Note that with 3270 LUs, if one or more of the LUs never become active even when users are attempting to start sessions, the LOCADDR settings in the LU definitions in VTAM or NCP may not match the SNA Server LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP. To correct this, consult with the administrator of the host system.


Settings to Check on Channel, DFT, and Twinax Connections
Establishing a Connection Successfully	8 of 8

Settings to Check for Connections

Settings to Check on Channel, DFT, and Twinax Connections

For Channel, DFT, and Twinax connections, the number of parameters involved is fewer than with other types of connections. The key parameters to note are those specifying addresses and, for Channel connections, the Max BTU Length. For detailed information about the parameters, see the appropriate sections in Chapter 2 of the Microsoft SNA Server Installation Guide and Chapter 3 of the Microsoft SNA Server Administration Guide. Alternatively, consult the online help for SNA Server Setup and SNA Server Admin.

Note that with 3270 LUs, if one or more of the LUs never become active even when users are attempting to start sessions, the LOCADDR settings in the LU definitions in VTAM or NCP may not match the SNA Server LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP. To correct this, consult with the administrator of the host system.


Examples of Configurations for 3270
Chapter 5	1 of 13

Examples of Configurations for 3270

This chapter provides examples of configurations that support connections to mainframes, allowing 3270 emulation on client systems. The first example illustrates configuring for 3270 with hot backup across servers; this configuration requires that the servers be located within the same LAN (not across a WAN). The second example illustrates configuring for 3270 with hot backup across connections (and adapters).

Both configurations illustrate the basic strategy for hot backup of 3270 sessions: after creating LUs on multiple servers and/or adapters (connections), place the LUs in an LU pool. When this LU pool is assigned to users (or groups), users can get LU support as long as any of the pooled LUs are available. If some of the pooled LUs are not functioning (for example, because a server or adapter stopped functioning), the user will not be affected, as long as some other LU in the pool is available.

LU pools can maximize access:

By allowing groups of intermittent users to use resources efficiently. For example, ten 3270 users who only need intermittent access may find that a pool of five 3270 LUs is adequate for their needs.

By providing hot backup. An LU pool can contain LUs from more than one server or adapter, so that even if one server or adapter stops working, users or applications using the pool can still get LU access. Users and applications may not even be aware that a server and/or adapter is not working, as long as one of the LUs in the pool is functioning.

By balancing the load between servers. If an LU pool contains LUs from more than one server, the load is shared according to the number of users per server.


Configuring for 3270 with Hot Backup Across Servers
Examples of Configurations for 3270	2 of 13

Configuring for 3270 with Hot Backup Across Servers

This section contains an example configuration that supports 3270 emulators on clients and includes hot backup across two servers. As with any configuration including hot backup across servers, this configuration requires that the servers be located relatively close together, that is, with communication across a LAN but not across a WAN.

The following diagrams illustrate the example configuration for 3270 with hot backup across servers.

Figure 5.1    Using 3270 LU Pools to Provide Hot Backup Across Servers

Figure 5.2    Providing Sessions when One Server is Down

As the illustrations show, even if SNASERV1 stops functioning, 3270 sessions will still be available through the LU pools assigned to the PRODUCTS group and the SALES group. Users in these groups may not even be aware that SNASERV1 has gone down, because the LU pools contain LUs from both SNASERV1 and SNASERV2.


Connections for 3270 with Hot Backup Across Servers
Examples of Configurations for 3270	3 of 13

Configuring for 3270 with Hot Backup Across Servers

Connections for 3270 with Hot Backup Across Servers

This example configuration includes two SNA servers with one SDLC connection on each one (for a total of two connections). The two connections are configured in very similar ways, so only one connection configuration is shown.

Important

This is an example configuration. You must adapt the example to your situation; for example, you must determine the correct node identifiers (such as Local Node ID) to use in your situation. For detailed information about configuring connections and LUs, see the Microsoft SNA Server Administration Guide.

The following illustration shows the configuration after two SNA servers have been installed, each with an SDLC adapter and the associated link service.

Example Configuration: Servers and Connections Window

The following dialog box is reached by double-clicking the SDLC1 connection (on SNASERV1). The illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: SDLC Setup Dialog Box


Host Settings Corresponding to Example
Examples of Configurations for 3270	4 of 13

Configuring for 3270 with Hot Backup Across Servers

Host Settings Corresponding to Example

The preceding settings in the example work with the following host settings:

Setting in the PU definition in  VTAM or NCP	Corresponding SNA Server setting
IDBLK=001 and IDNUM=00001	Local Node ID 001 00001
MAXDATA=521	Max BTU Length 521
ADDR=C1	Poll Address C1
Also note that the preceding Encoding setting of NRZI corresponds to the VTAM default, which is NRZI=YES in the LINE/GROUP definition.

The example connection on the server called SNASERV2 would be configured in the same way, except that the connection name would be SDLC2, and the Local Node ID would be 002 00002. This Local Node ID would correspond to a PU definition containing IDBLK=002 and IDNUM=00002.

The VTAM or NCP settings that match the LUs configured in the next two sections are described at the end of those sections.


LUs for 3270 with Hot Backup Across Servers
Examples of Configurations for 3270	5 of 13

Configuring for 3270 with Hot Backup Across Servers

LUs for 3270 with Hot Backup Across Servers

After connections are configured, the LUs for the example configuration are configured. The following dialog box shows the configuration after two SNA servers have been installed and a connection configured for each server:

Example Configuration: Servers and Connections Window

For the example configuration, the next steps are to select SDLC1 and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selections to be made are as follows:

Example Configuration: Insert LU Dialog Box

The next steps for the example are to choose OK and complete the Add LU Range dialog box:

Example Configuration: Add LU Range Dialog Box

The final steps for creating these LUs are to choose OK and complete the 3270 LU Range Properties dialog box as shown:

Example Configuration: 3270 LU Range Properties Dialog Box

The LUs now created have LU numbers from 1 through 100. In VTAM or NCP, these numbers are set in the LU definition with the LOCADDR parameter. Therefore, to work with the example configuration, the VTAM or NCP LU definition would have to include 100 instances of LOCADDR=, each with an appropriate number (from 1 through 100).

3270 LUs on the Second Server

For the example configuration, an additional, similar set of LUs would be created, this time on the server called SNASERV2 (which has a connection called SDLC2). The LUs would be called LU101 through LU200, and would have LU numbers from 101 through 200. In the VTAM or NCP configuration, the corresponding parameters would be found in the LU definition, which would include 100 instances of LOCADDR, each with an appropriate number (from 101 through 200).


LU Pools for 3270 with Hot Backup Across Servers
Examples of Configurations for 3270	6 of 13

Configuring for 3270 with Hot Backup Across Servers

LU Pools for 3270 with Hot Backup Across Servers

LU pools are an essential element of the example configuration, because they allow a user to be assigned a pool of LUs rather than single LUs. When the user accesses the pool, the next available LU in the pool is used for establishing a session with the mainframe. If the pool contains LUs from multiple servers, any of the servers can potentially fulfill a user’s request. Thus, if one server goes down, the LUs on another server can still be used by clients starting sessions. In other words, the servers provide hot backup for each other.

After LUs are configured, the LU pools for the example configuration are configured. To create the first pool, in the LU Pools window, from the Pools menu, the New Pool command is selected. The New Pool dialog box appears, and is completed as shown:

Example Configuration: New Pool Dialog Box

Similarly, a second pool is created:

Example Configuration: New Pool Dialog Box

The 3270 LU pools that have been created are empty at this point (that is, they are not useful to users yet). To place LUs in the pools, drag-and-drop can be used. To facilitate the drag-and-drop action, the windows can be arranged to look like the following illustration:

Example Configuration: Windows Enlarged for Drag-and-Drop

The LUs intended for POOL@PRD, that is, LU001 through LU050, can then be selected. This is done by clicking LU001, scrolling down in the window, holding the SHIFT key, and clicking LU050. This selects those 50 LUs:

Example Configuration: LUs Selected for Drag-and-Drop

The next step is to position the mouse on one of the selected LUs (it doesn’t matter which one), press and hold the mouse button, and drag the LUs to the pool named POOL@PRD:

Example Configuration: Drag-and-Drop of LUs Onto Pools

Note

After the LUs are released on the pool, they may not become visible in the display of the pool, if the relevant pool is not currently selected. To view the LUs, select the pool, as shown in the following illustration.

Example Configuration: Pool Containing LUs

For the example configuration, similar steps are carried out to assign LUs to pools as follows:

These LUs...	Are assigned to this pool...
LU051 through LU100 (on the connection SDLC1, which is on the server SNASERV1)	POOL@SAL
LU101 through LU150 (on the connection SDLC2, which is on the server SNASERV2)	POOL@PRD
LU151 through LU200 (on the connection SDLC2, which is on the server SNASERV2)	POOL@SAL
When these assignments are complete, all the LUs have been assigned to pools.


Users and Groups for 3270 with Hot Backup Across Servers
Examples of Configurations for 3270	7 of 13

Configuring for 3270 with Hot Backup Across Servers

Users and Groups for 3270 with Hot Backup Across Servers

For users and groups, SNA Server uses the same user accounts database that Windows NT uses. Therefore, the first step in supporting users through SNA Server is to use Windows NT Server to create the domain accounts for the users. For the example configuration, User Manager for Domains would be used to create appropriate user accounts for the users who will need 3270 LUs. Then, also in User Manager, the New Global Group command would be chosen from the User menu, and two groups created, called PRODUCTS and SALES. Each 3270 user is assigned to one of the two groups.

The remainder of the example configuration is set up through the Users and Groups window of SNA Server Admin. In this window, from the Users menu, the New User command is chosen, and the Add Users and Groups dialog box appears:

Example Configuration: Add Users and Groups Dialog Box

The next steps are to select the PRODUCTS group and choose the Add button, then select the SALES group and choose the Add button again. After the OK button is chosen, the Users and Groups window would appear as follows:

Example Configuration: Users and Groups Window with New Groups

To change the [Out of Date] heading on the Users and Groups windows, click the Save button. This saves the configuration and brings internal records up to date.

Finally, the appropriate pool is assigned to each group by dragging the pool icon and dropping it on the appropriate group. The following illustration shows the POOL@PRD pool being assigned to the PRODUCTS group. This action is repeated, to assign POOL@PRD twice to the PRODUCTS group. This way, users in the PRODUCTS group can each start two 3270 sessions at the same time.

Example Configuration: Drag-and-Drop of Pools Onto Groups

In a similar way, after the preceding assignments are done, POOL@SAL is assigned twice to the SALES group. Users in the SALES group can then start two 3270 sessions each.

Completing the Configuration

Once again, to change the [Out of Date] heading on the Users and Groups windows, click the Save button.

To start each server, select it and click the Start button. When the servers are started, the connections (which start on demand) and the LUs become available to the 3270 users.

Note

If the servers or connections cannot activate after you click the Start button for the server, for suggestions on troubleshooting, see Chapter 4, “Establishing a Connection Successfully.” If one or more 3270 LUs never become active even when users are attempting to start sessions, check with the administrator of the host system; the LOCADDR settings in the LU definitions in VTAM or NCP may not match your LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP.

For additional information about troubleshooting, see Appendix A, “Network Protocols and Client-Server Communication” and Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.”

The example configuration, as shown, provides hot backup across the servers SNASERV1 and SNASERV2. If SNASERV1 stopped functioning, the 3270 users in either of the two groups PRODUCTS and SALES could still get sessions through the respective pools, POOL@PRD and POOL@SAL. This is because the pools contain LUs not only from SNASERV1 but also from SNASERV2. Figures 5.1 and 5.2, earlier in this chapter, illustrate how the configuration provides hot backup.


Configuring for 3270 with Hot Backup Across Connections
Examples of Configurations for 3270	8 of 13

Configuring for 3270 with Hot Backup Across Connections

This section contains an example configuration that supports 3270 emulators on clients and includes hot backup across two connections. This configuration does not include hot backup across servers, and therefore does not require multiple servers to be located near each other.

The following diagrams illustrate the example configuration for 3270 with hot backup across connections.

Figure 5.3    Using 3270 LU Pools to Provide Hot Backup Across Connections

Figure 5.4    Providing Sessions when One Connection is Down

As the illustrations show, even if TOKEN1 reaches capacity or stops functioning, 3270 sessions will still be available through the LU pools assigned to GROUP1 and GROUP2. Users in these groups may not even be aware that TOKEN1 is unavailable, because the LU pools contain LUs from both TOKEN1 and SDLC1.


Connections for 3270 with Hot Backup Across Connections
Examples of Configurations for 3270	9 of 13

Configuring for 3270 with Hot Backup Across Connections

Connections for 3270 with Hot Backup Across Connections

This example configuration includes one SNA server with two connections: one a token ring connection and the other an SDLC connection. The token ring connection is intended for everyday use, with the SDLC connection being available if the token ring connection stops working or reaches capacity.

Important

This is an example configuration. You must adapt the example to your situation; for example, you must determine the correct node identifiers (such as Local Node ID) to use in your situation. For detailed information about configuring connections and LUs, see the Microsoft SNA Server Administration Guide.

The following illustration shows the configuration after installation. Along with the SNA server, two link services (for the two adapters, token ring and SDLC) have been installed.

Example Configuration: Servers and Connections Window

Token Ring Connection for Hot Backup Across Connections

The first connection described in this example configuration is the token ring connection. The following dialog box is reached by double-clicking TOKEN1 on SNASERV1. The illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

Note that the token ring connection activates on server startup. This means that unless something interferes with the token ring connection, it will be active and available whenever the SNA server is active.

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: 802.2 Setup Dialog Box

SDLC Connection for Hot Backup Across Connections

The following dialog box is reached by double-clicking the SDLC1 connection for SNASERV1. The illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

Note that the SDLC connection activates only on demand; if the token ring connection (already configured) is active and not at capacity, the SDLC connection will not be activated. Thus, the SDLC connection will be a backup for the token ring connection.

For this example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: SDLC Setup Dialog Box


Host Settings Corresponding to Example
Examples of Configurations for 3270	10 of 13

Configuring for 3270 with Hot Backup Across Connections

Host Settings Corresponding to Example

The preceding settings in this example work with the following host settings:

Setting in the PU definition  in VTAM or NCP	Corresponding SNA Server setting
IDBLK=001 and IDNUM=00001	For both connections: Local Node ID 001 00001
MACADDR=123456789012	For token ring (802.2) connection:  Remote Network Address
ADDR=C1	For SDLC connection:  Poll Address C1
MAXDATA=521	For both connections:  Max BTU Length 521
Also note that the preceding Encoding setting of NRZI corresponds to the VTAM default, which is NRZI=YES in the LINE/GROUP definition.

The VTAM or NCP settings that match the LUs configured in the next two sections are described at the end of those sections.


LUs for 3270 with Hot Backup Across Connections
Examples of Configurations for 3270	11 of 13

Configuring for 3270 with Hot Backup Across Connections

LUs for 3270 with Hot Backup Across Connections

After connections are configured, the LUs for the example configuration are configured. The following dialog box shows the configuration after two connections have been configured on the SNA server:

Example Configuration: Servers and Connections Window

For the example configuration, the next steps are to select TOKEN1 and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selections to be made are as follows:

Example Configuration: Insert LU Dialog Box

The next steps for the example are to choose OK and complete the Add LU Range dialog box:

Example Configuration: Add LU Range Dialog Box

The final steps for creating these LUs are to choose OK and complete the 3270 LU Range Properties dialog box as shown:

Example Configuration: 3270 LU Range Properties Dialog Box

The LUs just created have LU numbers from 1 through 100. In VTAM or NCP, these numbers are set in the LU definition with the LOCADDR parameter. Therefore, to work with the example configuration, the VTAM or NCP LU definition would have to include 100 instances of LOCADDR, each with an appropriate number (from 1 through 100).

3270 LUs on the Second Connection

For the example configuration, an additional, similar set of LUs would be created, this time on the SDLC connection. The LUs would be called LU101 through LU200, and would have LU numbers from 101 through 200. In the VTAM or NCP configuration, the corresponding parameters would be found in the LU definition, which would include 100 additional instances of LOCADDR, each with an appropriate number (from 101 through 200).


LU Pools for 3270 with Hot Backup Across Connections
Examples of Configurations for 3270	12 of 13

Configuring for 3270 with Hot Backup Across Connections

LU Pools for 3270 with Hot Backup Across Connections

LU pools are an essential element of this example configuration, because they allow a user to be assigned a pool of LUs rather than single LUs. When the user accesses the pool, the next available LU in the pool is used for establishing a session with the mainframe. If the pool contains LUs from multiple connections, any of the connections can potentially fulfill a user’s request. Thus, if one connection goes down, the LUs on another connection can still be used by clients starting sessions. In other words, the connections provide hot backup for each other.

After LUs are configured, the LU pools for the example configuration are configured. To create the first pool, in the LU Pools window, from the Pools menu, the New Pool command is selected. The New Pool dialog box appears, and is completed as shown:

Example Configuration: New Pool Dialog Box

Similarly, a second pool is created:

Example Configuration: New Pool Dialog Box

The 3270 LU pools that have been created are empty at this point (that is, they are not useful to users yet). To place LUs in the pools, drag-and-drop can be used. To facilitate the drag-and-drop action, the windows can be arranged to look like the following illustration:

Example Configuration: Windows Enlarged for Drag-and-Drop

The LUs intended for POOL1, that is, LU001 through LU050, can then be selected. This is done by clicking LU001, scrolling down in the window, holding the SHIFT key, and clicking LU050. This selects those 50 LUs:

Example Configuration: LUs Selected for Drag-and-Drop

The next step is to position the mouse on one of the selected LUs (it doesn’t matter which one), press and hold the mouse button, and drag the LUs to the pool named POOL1.

Example Configuration: Drag-and-Drop of LUs Onto Pools

Note

After the LUs are released on the pool, they may not become visible in the display of the pool, if the relevant pool is not currently selected. To view the LUs, select the pool, as shown in the following illustration.

Example Configuration: Pool Containing LUs

For the example configuration, similar steps are carried out to assign LUs to pools as follows:

These LUs...	Are assigned to this pool...
LU051 through LU100 (on the token ring connection)	POOL2
LU101 through LU150 (on the SDLC connection)	POOL1
LU151 through LU200 (on the SDLC connection)	POOL2
When these assignments are complete, all the LUs have been assigned to pools.


Users and Groups for 3270 with Hot Backup Across Connections
Examples of Configurations for 3270	13 of 13

Configuring for 3270 with Hot Backup Across Connections

Users and Groups for 3270 with Hot Backup Across Connections

For users and groups, SNA Server uses the same user accounts database that Windows NT uses. Therefore, the first step in supporting users through SNA Server is to use Windows NT Server to create the domain accounts for the users. For the example configuration, User Manager for Domains would be used to create appropriate user accounts for the users who will need 3270 LUs. Then, also in User Manager, the New Global Group command would be chosen from the User menu, and two groups created, called GROUP1 and GROUP2. Each 3270 user is assigned to one of the two groups.

The remainder of the example configuration is set up through the Users and Groups window of SNA Server Admin. In this window, from the Users menu, the New User command is chosen, and the Add Users and Groups dialog box appears:

Example Configuration: Add Users and Groups Dialog Box

The next steps are to select GROUP1 and choose the Add button, then select GROUP2 and choose the Add button again. After the OK button is chosen, the Users and Groups window would appear as follows:

Example Configuration: Users and Groups Window with New Groups

To change the [Out of Date] heading on the Users and Groups windows, click the Save button. This saves the configuration and brings internal records up to date.

Finally, the appropriate pool is assigned to each group by dragging the pool icon and dropping it on the appropriate group. The following illustration shows POOL1 being assigned to GROUP1. This action is repeated, to assign POOL1 twice to GROUP1. This way, users in GROUP1 can each start two 3270 sessions at the same time.

Example Configuration: Drag-and-Drop of Pools Onto Groups

In a similar way, after the preceding assignments are done, POOL2 is assigned twice to GROUP2. Users in GROUP2 can then start two 3270 sessions each.

Completing the Configuration

Once again, to change the [Out of Date] heading on the Users and Groups windows, click the Save button.

To start SNASERV1, select it and click the Start button. When SNASERV1 is started, the TOKEN1 connection starts (because it is configured to start on server startup); the LUs become available to the 3270 users. If SDLC1 is needed, it starts (because it is configured to start on demand).

Note

If the server or connections do not become active as expected, for suggestions on troubleshooting, see Chapter 4, “Establishing a Connection Successfully.” If one or more 3270 LUs never become active even when users are attempting to start sessions, check with the administrator of the host system; the LOCADDR settings in the LU definitions in VTAM or NCP may not match your LU numbers, or some or all of the LUs may be inactivated in VTAM or NCP.

For additional information about troubleshooting, see Appendix A, “Network Protocols and Client-Server Communication” and Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.”

The example configuration, as shown, provides hot backup across the connections TOKEN1 and SDLC1. If TOKEN1 stops functioning or reaches capacity, the 3270 users in either of the two groups GROUP1 and GROUP2 can still get sessions through the respective pools, POOL1 and POOL2. This is because the pools contain LUs not only from TOKEN1 but also from SDLC1. Figures 5.3 and 5.4, earlier in this chapter, illustrate how the configuration provides hot backup.


Examples of Configurations for 5250
Chapter 6	1 of 21

Examples of Configurations for 5250

The first part of this chapter provides two examples of SNA Server configurations that support connections to AS/400 computers, allowing 5250 emulation on client systems. The first example illustrates configuring for 5250 with hot backup across servers. The second example illustrates configuring for 5250 so that user names match LU names.

The second part of this chapter describes the software combinations that can be used on clients to provide 5250 emulation and other communication with an AS/400.


Configuring for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	2 of 21

Configuring for 5250 with Hot Backup Across Servers

This section contains an example configuration that supports 5250 emulation on clients and includes hot backup across two servers. For background information about supporting 5250 emulation on clients, see “5250 Users Connecting to an AS/400” in Chapter 1. For information about the software you can use on clients for 5250 emulation and for other features such as shared folders, see “Software and Configurations on AS/400 Clients,” later in this chapter.

The configuration in this example, like any configuration including hot backup across servers, requires that the servers be located relatively close together, that is, with communication across a LAN but not across a WAN.

All configurations for 5250 require that local and remote LUs be configured. Figure 6.1 shows the local and remote LUs used for this example configuration. Local and remote LUs are always needed for APPC, the underlying API used for all 5250 emulation.

Figure 6.1    How APPC Elements Map to a 5250 Configuration

The following diagrams show how the example configuration provides support for 5250 with hot backup across servers.

Figure 6.2    Providing Support for 5250 with Hot Backup Across Servers

Figure 6.3    Providing 5250 Sessions when One Server is Down

As the illustrations show, even if SNASERV1 stops functioning, 5250 sessions will still be available through the default local and default remote LU aliases assigned to the PLANGRP group. Users in this group may not even be aware that SNASERV1 has gone down, because they have been assigned the local LU alias called PLANLU, and this is the alias for local LUs on both SNASERV1 and SNASERV2.


Viewing User and Computer Names of 5250 Users
Examples of Configurations for 5250	3 of 21

Configuring for 5250 with Hot Backup Across Servers

Viewing User and Computer Names of 5250 Users

When using a configuration like the one in this section, you can view the names of the users with active 5250 sessions on each SNA server. To do this, use the following procedure.

To view 5250 users on an SNA server for which only one local APPC LU is configured

1.	Start SNA Server Admin.

2.	In the Servers and Connections window, select the SNA server you are interested in.

The local APPC LU configured on the server appears under LU Name.

3.	Double-click the local APPC LU.

The APPC LU Properties dialog box appears.

4.	Choose the Status button.

An APPC LU Status dialog box appears.

5.	Select the line with a mode of QPCSUPP, and choose the Zoom button.

A second APPC LU Status dialog box appears.

6.	View user names under User, and computer names under Computer.

The list shows all users and computers using QPCSUPP, the mode used by all 5250 sessions. Therefore, the list shows all users and computers with active 5250 sessions on this SNA server (assuming that the server has only one local APPC LU).

7.	To clear the dialog boxes, choose Close or Cancel in each one.


Server Settings for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	4 of 21

Configuring for 5250 with Hot Backup Across Servers

Server Settings for 5250 with Hot Backup Across Servers

This example configuration includes two SNA servers. In order to support 5250, each of the servers must be configured with a Local Network Name and Local Control Point Name.

Important

This is an example configuration. You must adapt the example to your situation; for example, you must determine the correct node identifiers (such as Local Network Name and Control Point Name) to use in your situation. For detailed information about configuring servers, connections, and LUs, see the Microsoft SNA Server Administration Guide.

The following illustration shows the configuration after two SNA servers have been installed, each with an SDLC adapter and the associated link service.

Example Configuration: Servers and Connections Window

The following dialog box is reached by double-clicking SNASERV1. The illustration shows the information to be entered for the example:

Specifying Names on One Server for Support of 5250

Similarly, the following dialog box is reached by double-clicking SNASERV2, and entering the local network name and control point name as shown:

Specifying Names on a Second Server for Support of 5250


Local LUs for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	5 of 21

Configuring for 5250 with Hot Backup Across Servers

Local LUs for 5250 with Hot Backup Across Servers

After servers are configured, the local LUs for the example configuration are configured. For the example configuration, the steps for initiating this are to select SNASERV1 and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selection to be made is as follows:

The next steps for the example are to choose OK and complete the New APPC LU Properties dialog box:

One Local APPC LU for 5250 with Hot Backup

The final step for creating the first local LU is to choose OK.

Local LU on the Second Server

For the example configuration, an additional, similar local LU would be created, this time on the server called SNASERV2. The local LU on SNASERV2 would have an LU Name of LU2, but would have the same LU Alias as the one already used, PLANLU. Thus, the two LUs have separate LU Names, LU1 and LU2, and a shared LU Alias, PLANLU. This makes it possible for them to support hot backup, because users will be assigned the alias PLANLU, and the SNA servers will interpret this to mean either LU1 or LU2. This way, if either LU is temporarily unavailable, users assigned PLANLU can still receive access to the AS/400 through the other LU.

The following composite illustration shows the configuration after the two local LUs have been created.

Two Local LUs for 5250 with Hot Backup Across Servers


Connections for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	6 of 21

Configuring for 5250 with Hot Backup Across Servers

Connections for 5250 with Hot Backup Across Servers

Before the necessary remote LUs can be configured for the example configuration, the connections for those LUs must be configured. For the example, there are two SDLC connections (one on each of two servers). The two connections, called SDLC1 and SDLC2, are configured in very similar ways, so only one connection configuration is shown.

The following dialog box is reached by double-clicking the SDLC1 connection (the connection on SNASERV1). The illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: SDLC Setup Dialog Box

Connection on the Second Server

The example connection on the server called SNASERV2 would be configured in the same way, except that the connection name would be SDLC2, and the Local Node ID would be 002 00002. The second connection would use the same Remote Network Name and Remote Control Point Name as the first connection: APPN and MAINSYS, respectively.


AS/400 and SNA Server Settings (for Servers and Connections)
Examples of Configurations for 5250	7 of 21

Configuring for 5250 with Hot Backup Across Servers

AS/400 and SNA Server Settings (for Servers and Connections)

The settings on SNASERV1 would work with the following AS/400 settings:

Setting on the AS/400	Corresponding SNA Server setting for SNASERV1
SWTDSC is *YES	Connection Activation is On Demand
RMTNETID is APPN; RMTCPNAME is SNASERV1	Local Network Name (on SNA Server) is APPN and Local Control Point Name (on SNA Server) is SNASERV1
RMTNETID is APPN;  CP name is MAINSYS	Remote Network Name (on connection) is APPN and Remote Control Point Name (on connection) is MAINSYS
EXCHID is 001 00001	Local Node ID is 001 00001
MAXFRAME is 521	Max BTU Length is 521
STNADR in Line Description is C1	Poll Address is C1
NRZI in Line Description is *YES	Encoding is NRZI
The second server, SNASERV2, and its connection, SDLC2, would follow the same pattern, except that the Local Node ID of 002 00002 would be matched by an EXCHID setting of 002 00002 on the AS/400. In addition, the Local Control Point Name, SNASERV2, would be matched by a RMTCPNAME of SNASERV2 on the AS/400.


Remote LUs for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	8 of 21

Configuring for 5250 with Hot Backup Across Servers

Remote LUs for 5250 with Hot Backup Across Servers

Next, the remote LUs for the example configuration are configured. This means that the next steps are to select SDLC1 and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selection to be made is as follows:

The next steps are to choose OK and complete the New APPC Remote LU Properties dialog box:

One Remote APPC LU for 5250 with Hot Backup

The final step for creating the first remote LU is to choose OK.

Remote LU on the Second Server

For the example configuration, an additional, very similar remote LU would be created, this time on the connection called SDLC2. Note that because both these LUs communicate with the same AS/400, they have the same name and alias (the name of the AS/400, MAINSYS). This contrasts with the way the local LUs are named; in order for the AS/400 to handle them correctly, the local LUs must have distinct LU Names (although they have the same LU Alias).

The following composite illustration shows the configuration after the two remote LUs have been created.

Two Remote LUs for 5250 with Hot Backup Across Servers


Users and Groups for 5250 with Hot Backup Across Servers
Examples of Configurations for 5250	9 of 21

Configuring for 5250 with Hot Backup Across Servers

Users and Groups for 5250 with Hot Backup Across Servers

For users and groups, SNA Server uses the Windows NT user accounts database. Therefore, the first step in supporting users through SNA Server is to use Windows NT Server to create the domain accounts for the users. For the example configuration, User Manager for Domains would be used to create appropriate user accounts for the users who will use 5250 to access the AS/400. Then, also in User Manager, the New Global Group command would be chosen from the User menu, and one group created, called PLANGRP. Each 5250 user is assigned to this group.

The remainder of the example configuration is set up through the Users and Groups window of SNA Server Admin. In this window, from the Users menu, the New User command is chosen, and the Add Users and Groups dialog box appears:

Example Configuration: Add Users and Groups Dialog Box

The next steps are to select PLANGRP and choose the Add button, then choose OK. The Users and Groups window would then appear as follows:

Example Configuration: Users and Groups Window with New Group

To change the [Out of Date] heading on the Users and Groups windows, click the Save button. This saves the configuration and brings internal records up to date.

Finally, the appropriate Local LU Alias and Remote LU Alias are assigned to PLANGRP, by double-clicking the group and selecting the correct LU aliases in the Group Properties dialog box.

Example Configuration: LU Aliases Assigned to a Group

With these assignments, members of PLANGRP do not need to memorize names of the LUs. They also do not need to know that there are actually two different LUs configured for their use, on two different servers. Instead, they need only start their emulators. SNA Server will recognize their membership in PLANGRP, and automatically attempt to give them access to MAINSYS through PLANLU. Since PLANLU is the LU alias both for LU1 (on SNASERV1) and for LU2 (on SNASERV2), either server can potentially provide sessions for the users in PLANGRP.

Completing the Configuration

Once again, to change the [Out of Date] heading on the Users and Groups windows, click the Save button.

To start each server, select it and click the Start button. When the servers are started, the connections (which start on demand) and the LUs become available to the 5250 users.

The example configuration, as shown, provides hot backup across the servers SNASERV1 and SNASERV2. If SNASERV1 stopped functioning, the 5250 users in PLANGRP could still get sessions through SNASERV2. SNASERV2 would provide the sessions through the local LU named LU2, which has the same LU Alias (PLANLU) as the local LU on SNASERV1. Since the local LUs are both paired with the remote LU called MAINSYS, they both provide access to the AS/400 computer called MAINSYS. Figures 6.2 and 6.3, earlier in this chapter, illustrate how the configuration provides hot backup.


Configuring for 5250 with LU Names Based on User Names
Examples of Configurations for 5250	10 of 21

Configuring for 5250 with LU Names Based on User Names

You may want a 5250 configuration that allows easy identification of active users as viewed from the AS/400. You can do this by configuring many local APPC LUs, each one named after the user who will use it. The example in this section demonstrates how to do this.

Note that when there are many LUs (as in the example), more time is spent in negotiating when the connection is started, because negotiations are carried out for each LULU pair. In addition, with more LUs, more AS/400 memory is required for managing them. For these reasons, you may prefer to have only local LU per server. With one local LU per server, you can still allow for easy identification of users as viewed from the AS/400. To do this, have users specify unique device names for each session in their 5250 emulator. That is, show each user how to use emulation software to start a session under a device name that matches or includes the user’s name. With this method, device names on the AS/400 identify active users, and the configuration of LUs can be kept simple and efficient.

For background information about supporting 5250 emulation on clients, see “5250 Users Connecting to an AS/400” in Chapter 1. For information about the software you can use on clients for 5250 emulation and for other features such as shared folders, see “Software and Configurations on AS/400 Clients,” later in this chapter.

This example configuration uses not only SNA Server Admin but the SNA Server command-line interface, snacfg. Note that this use of snacfg requires that commands be edited with precision in a text editor. However, using snacfg speeds up the process of creating many similar LUs. In addition, if a typing error occurs while using the kinds of snacfg commands shown in this example, the error cannot affect critical items such as the user names in the SNA Server configuration (which must match names in the Windows NT user account database). Instead, the effect of typing errors in this example would (at worst) be the creation of a misnamed local LU, that could be readily corrected in SNA Server Admin.

Note that there are a few snacfg commands (not shown in this example) that must be typed accurately, or a nonfunctioning configuration may result. The affected commands are the ones for adding a new adapter, user, or server to a configuration. For these actions, it is recommended that you use SNA Server Admin (not snacfg). For more information, see Appendix E in the Microsoft SNA Server Administration Guide.


Users and Groups for 5250 (Multiple LU Example)
Examples of Configurations for 5250	11 of 21

Configuring for 5250 with LU Names Based on User Names

Users and Groups for 5250 (Multiple LU Example)

For users and groups, SNA Server uses the same user accounts database that Windows NT uses. Therefore, the first step in this example configuration is to use Windows NT Server to create the domain accounts for the users.

Important

This is an example configuration. You must adapt the example to your situation; for example, you must determine the correct user names and node identifiers (such as Local Network Name and Control Point Name) to use in your situation. For detailed information about configuring servers, connections, LUs, and users, see other chapters in this guide, as well as the Microsoft SNA Server Administration Guide.

For this example, the names are as follows. User Manager for Domains would be used to create appropriate user accounts:

User	Name to be assigned to user account in Windows NT domain

Alex Allen	AlexA

Brenda Brown	BrendaB

Chris Carlin	ChrisC

Dana Donalds	DanaD

Errin Errol	ErrinE

The next step for the example configuration is to start SNA Server Admin and click on the Users and Groups window (or double-click on the Users and Groups icon). In this window, from the Users menu, the New User command is chosen, and the Add Users and Groups dialog box appears:

Example Configuration: Add Users and Groups Dialog Box

The next steps are to select AlexA, press SHIFT, and then select ErrinE, to choose all of the five users. Next, choose the Add button and then choose OK. The Users and Groups window would then appear as follows:

Example Configuration: Users and Groups Window with New Users

To change the [Out of Date] heading on the Users and Groups windows, click the Save button. This saves the configuration and brings internal records up to date.


Server Settings for 5250 (Multiple LU Example)
Examples of Configurations for 5250	12 of 21

Configuring for 5250 with LU Names Based on User Names

Server Settings for 5250 (Multiple LU Example)

This example configuration includes one SNA server, for which a Local Network Name and Local Control Point Name would be configured. These names are necessary for support of 5250.

The following illustration shows the Servers and Connections window (in SNA Server Admin) after one SNA server has been installed, along with a token ring adapter and the associated link service.

Example Configuration: Servers and Connections Window

The following dialog box is reached by double-clicking SNASERV1. The illustration shows the information to be entered for the example:

Specifying Names on One Server for Support of 5250


Connection for 5250 (Multiple LU Example)
Examples of Configurations for 5250	13 of 21

Configuring for 5250 with LU Names Based on User Names

Connection for 5250 (Multiple LU Example)

The next step for this example configuration is to conFigure a connection. For the example, there is one token ring connection, called TOKEN1.

The following dialog box is reached by double-clicking the TOKEN1 connection (which is created, although not configured, through the process of installing the token ring link service). The following illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: 802.2 Setup Dialog Box


AS/400 and SNA Server Settings (for Server and Connection)
Examples of Configurations for 5250	14 of 21

Configuring for 5250 with LU Names Based on User Names

AS/400 and SNA Server Settings (for Server and Connection)

The example settings on SNASERV1 would work with the following AS/400 settings:

Setting on the AS/400	Corresponding SNA Server setting for SNASERV1
SWTDSC is *NO	Connection Activation is On Server Startup
RMTNETID is APPN; RMTCPNAME is SNASERV1	Local Network Name (on server) is APPN and Local Control Point Name (on server) is SNASERV1
RMTNETID is APPN;  CP name is MAINSYS	Remote Network Name (on connection) is APPN and Remote Control Point Name (on connection) is MAINSYS
EXCHID is 001 00001	Local Node ID is 001 00001
MAXFRAME is 1929	Max BTU Length is 1929
ADPTADR in the Line Description is 123456789012	Remote Network Address is 123456789012


Remote LU for 5250 (Multiple Local LU Example)
Examples of Configurations for 5250	15 of 21

Configuring for 5250 with LU Names Based on User Names

Remote LU for 5250 (Multiple Local LU Example)

Next, the remote LU for the example configuration is configured. To do this, the next steps are to select TOKEN1 and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selection to be made is as follows:

The next steps for the example are to choose OK and complete the New APPC Remote LU Properties dialog box:

Remote APPC LU for 5250 (Multiple Local LUs Example)

The final step for creating the remote LU is to choose OK.


Local LUs for 5250 (Multiple LU Example)
Examples of Configurations for 5250	16 of 21

Configuring for 5250 with LU Names Based on User Names

Local LUs for 5250 (Multiple LU Example)

After servers are configured, the first local LU for the example configuration is configured. This is initiated by selecting SNASERV1 and then, from the Services menu, choosing Assign LUs. In the resulting dialog box, the selection to be made is as follows:

The next steps for the example are to choose OK and complete the New APPC LU Properties dialog box:

One Local APPC LU for 5250 with Hot Backup

The last step for creating the first local LU is to choose OK.

Saving and Backing Up the Configuration Before Exiting

The final steps for this part of the configuration are to save the configuration, back up the configuration (for protection against errors that might be made in the next steps), and exit SNA Server Admin. To do this, first, choose the Save button. Next, from the File menu, choose Backup, type a filename with the extension SNA, and then choose OK. Finally, from the File menu, choose Exit.

Using snacfg to Create Multiple Local LUs

This section outlines a method for using the SNA Server command line interface, snacfg, to create multiple local LUs. The LU name and alias for each of these LUs must be unique, because they will all be located on the same connection. For this example, the names given to the local LUs will match the user account names shown earlier (AlexA, BrendaB, ChrisC, and so on).

Note

To see the basic syntax for the snacfg command, type snacfg /? or a command such as snacfg appcllu /?. For background information and detailed syntax for the snacfg command, see Appendix E of the Microsoft SNA Server Administration Guide.

The steps for using the snacfg command to create mulitple LUs are shown in the following diagram:

Using snacfg to Create Multiple LUs

As shown in the diagram, the local LU that has already been created (the one called AlexA) is used as a template from which to create the other LUs. To do this, the existing “AlexA” LU settings are “captured” in the form of a command. This is done with the /print option of the snacfg command. Then the captured command syntax is loaded into a text editor, multiple copies are made, and each copy is modified so it specifies a unique name. At this point, each copy of the command is ready to create a new, unique LU. Finally, the resulting file (called a snacfg command file) is run by typing a single command at the prompt. The command file creates all the LUs specified in it.

Note

The examples of the snacfg commands in this section and the next section are based on the assumption that the configuration file to be changed has the default path, that is, SNAroot\SYSTEM\CONFIG\COM.CFG. If this is not the case, the commands would be modified according to the following syntax:

snacfg  #configpath  options

In other words, the word snacfg would be followed by the pound sign (#) and then, without a space, by the path of the configuration file to be viewed or changed. Further command parameters would then be typed after this path. For more information about the snacfg command, see Appendix E of the Microsoft SNA Server Administration Guide.

To begin the process of using the snacfg command, the first step is to make sure you have backed up the configuration and exited from SNA Server Admin (for instructions for doing this, see the end of the previous section). Then, from the command prompt, type

snacfg  appcllu  snaserv1:alexa  /print >sna_cmd1.txt

This command creates a command file called sna_cmd1.txt. The command file contains the command syntax that could be used to create a local APPC LU with the same settings as the local LU called AlexA. The next step is to load the command file (sna_cmd1.txt) into a text editor (such as Notepad). The command file appears as follows:

APPCLLU ALEXA /ADD	\

/SERVER:SNASERV1	\

/LUNUMBER:0	\

/NETNAME:APPN	\

/LUNAME:ALEXA	\

/COMMENT:""	\

/AUTOPARTNER:Yes	\

/DEFAULTPOOL:No	\

/TPTIMEOUT:60	\

Note that all these lines work together as one command, because of the backslash (\) character at the end of each line. The final backslash character must be removed so that the command, when copied, will be separate from what is placed after it. After the final backslash is removed, the command is copied and pasted three times, to create a total of four commands. Then the string ALEXA is searched for and replaced, so that each LU specified has a different LU alias (specified in the first line of the command) and LU name (specified after /LUNAME:). The result appears as follows:

APPCLLU BRENDAB /ADD	\

/SERVER:SNASERV1	\

/LUNUMBER:0	\

/NETNAME:APPN	\

/LUNAME:BRENDAB	\

/COMMENT:""	\

/AUTOPARTNER:Yes	\

/DEFAULTPOOL:No	\

/TPTIMEOUT:60

APPCLLU CHRISC /ADD	\

/SERVER:SNASERV1	\

/LUNUMBER:0	\

/NETNAME:APPN	\

/LUNAME:CHRISC	\

/COMMENT:""	\

/AUTOPARTNER:Yes	\

/DEFAULTPOOL:No	\

/TPTIMEOUT:60

APPCLLU DANAD /ADD	\

/SERVER:SNASERV1	\

/LUNUMBER:0	\

/NETNAME:APPN	\

/LUNAME:DANAD	\

/COMMENT:""	\

/AUTOPARTNER:Yes	\

/DEFAULTPOOL:No	\

/TPTIMEOUT:60

APPCLLU ERRINE /ADD	\

/SERVER:SNASERV1	\

/LUNUMBER:0	\

/NETNAME:APPN	\

/LUNAME:ERRINE	\

/COMMENT:""	\

/AUTOPARTNER:Yes	\

/DEFAULTPOOL:No	\

/TPTIMEOUT:60

At this point, it is a good idea to check over the file and make sure that ALEXA no longer appears in it and that the names typed in the lines containing APPCLLU and /LUNAME are not mistyped. Note that the two names used in each “block” (starting with APPCLLU and ending with /TPTIMEOUT:60) should match each other; they are the LU Alias and LU Name, respectively. (Also note that if there are any blank lines in the file, it will run successfully, but the resulting display will show the syntax for snacfg, as if something had been typed incorrectly.)

After the command file is saved, all that remains is to run it. If the command file (sna_cmd1.txt) is in the current directory, at the command prompt, type

snacfg  @sna_cmd1.txt

To check on whether all the intended LUs were created by the command file, type

snacfg  appcllu  /list

If all the intended LUs were created, the resulting display would include the following lines:

APPC LU	Server	Description
ALEXA	SNASERV1
BRENDAB	SNASERV1
CHRISC	SNASERV1
DANAD	SNASERV1
ERRINE	SNASERV1
To examine the LUs further, it is probably easiest to view them in SNA Server Admin. Because of the automatic partner settings used in this example, all the local LUs have automatically become partnered with the existing remote LU, MAINSYS, using the mode required for all communication with an AS/400, QPCSUPP. Note that if you start SNA Server Admin to view the LUs, you must exit again before continuing.

Using snacfg to Assign LUs to Each User

This section outlines a method for using the SNA Server command line interface, snacfg, to assign a different default local LU to each user in a list. The snacfg commands in this section also assign MAINSYS as the default remote LU for each user. When default LUs have been assigned, the users are not required to specify any LUs in order to start their 5250 emulators and connect to the AS/400 (MAINSYS). The list of users, as shown earlier, is AlexA, BrendaB, ChrisC, DanaD, and ErrinE.

Note

The forms of the snacfg user command shown in this example are fairly foolproof in use, because mistyping simply prevents the commands from running. However, there is an option (not used in this example) that can cause a nonfunctioning configuration if names are mistyped. This is the /add option when used with the snacfg user command. Therefore, it is recommended that when adding users, you use only SNA Server Admin (not snacfg user with the /add option). For more information, see Appendix E of the Microsoft SNA Server Administration Guide.

To create the commands that will assign the appropriate default LUs to the users, start a text editor and create the following lines (using copy and paste as needed):

user alexa /defloclu:alexa /defremlu:mainsys

user brendab /defloclu:brendab /defremlu:mainsys

user chrisc /defloclu:chrisc /defremlu:mainsys

user danad /defloclu:danad /defremlu:mainsys

user errine /defloclu:errine /defremlu:mainsys

The lines should be checked for mistyping; as stated in the previous note, if there are any mistakes, none of the commands will run (in other words, the configuration will be left unchanged).

The command file can then be saved with the name sna_cmd2.txt, so that the file can be run by typing the following command (assuming sna_cmd2.txt is in the current directory):

snacfg  @sna_cmd2.txt

If the command file cannot run because something in it was mistyped, in the resulting display, the first mistake is listed, along with its line number. If the command file runs successfully, the copyright information for snacfg appears, followed by lines similar to these:

Generating SID for User AlexA on Domain DOMAIN1

Generating SID for User BrendaB on Domain DOMAIN1

Generating SID for User ChrisC on Domain DOMAIN1

Generating SID for User DanaD on Domain DOMAIN1

Generating SID for User ErrinE on Domain DOMAIN1

After the command file runs successfully, if the methods in the previous sections were followed, the users in the list can each use a different local LU on the SNA server, and obtain access to the AS/400 called MAINSYS. A user would not be required to know the names of the LUs; the user could start a 5250 emulator with no LUs specified, and receive access to the default LUs assigned to him or her in the SNA Server configuration.

Viewing the Completed Configuration

To view the completed configuration, start SNA Server Admin. You can select the Users and Groups window and double-click on a user account to see the default LUs assigned to that user. The following illustration shows the default LUs assigned to the user AlexA:

Configuration Containing Multiple Local LUs, One for Each User

To make LU sessions available to users, you would start SNASERV1, by selecting it and then clicking the Start button. When SNASERV1 is started, the connection (which start on demand) and the LUs become available to the 5250 users.


Software and Configurations on AS/400 Clients
Examples of Configurations for 5250	17 of 21

Software and Configurations on AS/400 Clients

A variety of different combinations of software can be used on clients to provide 5250 emulation and other capabilities (such as shared folders on the AS/400). The various software types will work only in specific combinations; some types of software require configuration steps such as changes to CONFIG.SYS. In addition, the software that can be used on a client depends on what version of operating system (OS/400) is running on the AS/400.

With any OS/400 version, you can select from the software choices shown in Table 6.1. If the OS/400 version is v3r1 or later, you can also select from the software choice shown in Table 6.2. The tables list the possible operating systems on clients, the possible areas of client functionality, and the software that provides that functionality with SNA Server software.

Note

When studying Tables 6.1 and 6.2, take note of the company name (for example, Microsoft, IBM, or NetSoft) as well as the type of software component listed. Other types and brands of software may not work together. However, new software may become available after publication of this guide; consult with your software vendor for more information.

Also note that if you have OS/400 v3r1, you can use the software listed in  either Table 6.1 or 6.2. However, to use OS/400 v3r1 with IBM PC Support (on MS-DOS – based clients), be sure to use versions of PC Support that are recent enough to work with OS/400 v3r1; for details, see your IBM documentation.

Table 6.1    Choices of Client Software for Use with Any Version of OS/400

Operating system on client	Target functionality	Software components to install and use
Windows version 3.x, Windows for Workgroups version 3.x, or Windows NT	5250 emulation	5250 emulator based on Windows APPC or EHNAPPC but not using the Router API or Client Access/400; see SNA Server Product Companion Catalog for listings
Any operating system	Shared files	Any network software that allows sharing of files across the LAN
MS-DOS	Basic PC Support including shared folders	Basic PC Support (not Enhanced) SNA Server client software for MS-DOS Microsoft Router (replaces PC Support router)
MS-DOS	Extended PC Support (but without shared folders)	Extended PC Support SNA Server client software for MS-DOS Microsoft Router (replaces PC Support router) The IBM component called RTRMAP.EXE (provides communication between the extended PC Support functions and Router)
Windows version 3.x or Windows for Workgroups version 3.x	5250 emulation and shared folders	NetSoft Midrange Bundle [image], which includes NS/Router, NS/Folders{bmc tm.bmp} , Elite/400, and other components, including a NetBIOS protocol component for clients. If you use the NetBIOS component, be sure that in SNA Server Setup on the servers, you have selected the NetBIOS option in the Select Client/Server Protocols dialog box. Alternatively, instead of using the NetBIOS component on clients, you can use Novell NetWare (IPX/SPX) with the NetSoft Midrange Bundle. For more information, see the documentation for the NetSoft Midrange Bundle.
Note

For important information about how to use PC Support and the SNA Server Router, see Chapter 3 of the Microsoft SNA Server Installation Guide.

If the OS/400 version is v3r1 or later, you can select from the software choices shown in either Table 6.1 or Table 6.2. The tables list the possible operating systems on clients, the possible types of client functionality, and the software that provides that functionality with SNA Server software.

Table 6.2    Additional Choice of Client Software for OS/400 Version v3r1

Operating system on client	Target functionality	Software components to install and use
Windows version 3.x or Windows for Workgroups version 3.x	Client Access/400 (CA/400)	CA/400
The following sections describe the configuration of clients using the combinations of software listed in Tables 6.1 and 6.2. The sections describe the following:

5250 clients using direct Windows APPC or EHNAPPC (that is, where the 5250 emulation software is written to Windows APPC or EHNAPPC, and does not use the router API)

AS/400 clients using IBM PC Support

AS/400 clients using the NetSoft NS/Router

AS/400 clients using IBM CA/400


5250 Clients Using Direct Windows APPC or EHNAPPC
Examples of Configurations for 5250	18 of 21

Software and Configurations on AS/400 Clients

5250 Clients Using Direct Windows APPC or EHNAPPC

Some 5250 emulators are based directly on Windows APPC or EHNAPPC. Emulators based on Windows APPC or EHNAPPC can be used with SNA Server version 2.11. These emulators do not use PC Support, CA/400, or other router software (such as NS/Router or the PC Support router). Even the 5250 emulation component of PC Support or CA/400 can be used with SNA Server client software, replacing the router portion of these products. This means that if you use these emulators, you can avoid using the terminate-and-stay-resident (TSR) components used in PC Support. This helps prevent the problems associated with TSR components, increases the robustness of client systems, and keeps client configuration simple.

5250 emulators and other software based directly on Windows APPC or EHNAPPC do not include shared folders. However, the functionality provided by shared folders can be provided by file sharing on servers on the LAN. Often, using file sharing on the LAN instead of shared folders on the AS/400 makes downloading faster and easier for users.

For a list of 5250 emulators that use Windows APPC or EHNAPPC (in other words, that do not use the router API), see the SNA Server Companion Product Catalog.


AS/400 Clients Using PC Support
Examples of Configurations for 5250	19 of 21

Software and Configurations on AS/400 Clients

AS/400 Clients Using PC Support

One option for allowing communication between clients and AS/400 computers is IBM PC Support. Although IBM PC Support software can provide 5250 emulation and other functionality such as shared folders on the AS/400, PC Support requires a very specific environment and system configuration. PC Support requires terminate-and-stay-resident (TSR) components on the client, and (as originally designed) requires that the client use the DLC protocol instead of common LAN protocols such as IPX/SPX.

SNA Server software eliminates the necessity of using the DLC protocol with PC Support; clients can use common LAN protocols instead. This is made possible by the SNA Server Router (Router), which replaces the PC Support router component. With the Router, clients can communicate through an SNA server, which handles the protocols recognized by the AS/400.

Important

Only certain combinations of software work with PC Support software. Table 6.1 lists these combinations. For important configuration information about how to use PC Support and the SNA Server Router, see Chapter 3 of the Microsoft SNA Server Installation Guide.

As Table 6.1 shows, a typical use for PC Support software might be on an MS-DOS – based client communicating with an AS/400.


AS/400 Clients Using the NetSoft Router
Examples of Configurations for 5250	20 of 21

Software and Configurations on AS/400 Clients

AS/400 Clients Using the NetSoft Router

An option for allowing clients to use 5250 emulation and also access shared folders on the AS/400 is to use the NetSoft Midrange Bundle. The NetSoft Midrange Bundle includes NS/Router, NS/Folders, Elite/400, and other components, including a NetBIOS protocol component for clients. If you use the NetBIOS client component, be sure that in SNA Server Setup on the servers, you have selected the NetBIOS option in the Select Client/Server Protocols dialog box. For an illustration of this dialog box, see Appendix A, “Network Protocols and Client-Server Communication.”

Alternatively, you can use Novell NetWare (IPX/SPX) with the NS/Router on the client, instead of the NetBIOS component included in the NetSoft Midrange Bundle. For information about using NetWare on a client computer, see Appendix A, “Network Protocols and Client-Server Communication.”

As Table 6.1 shows, the NetSoft Midrange Bundle is useful for clients running Windows version 3.x or Windows for Workgroups, when communicating with an AS/400 running any version of OS/400, including v3r1 as well as earlier versions.

For more information about how to work with NS/Router, see the documentation for the NetSoft Midrange Bundle.


AS/400 Clients Using CA/400
Examples of Configurations for 5250	21 of 21

Software and Configurations on AS/400 Clients

AS/400 Clients Using CA/400

Client Access/400 (CA/400) is a new software product from IBM (as of 1995). CA/400 adds a Windows interface to existing PC Support functionality. CA/400 can be used on clients running Windows version 3.x (or Windows for Workgroups) and SNA Server client software, version 2.11. On an AS/400 that will be used with CA/400, the version of the OS/400 operating system must be v3r1 or later. For more information about CA/400, see the CA/400 documentation.


Example of a Configuration for Downstream Connections
Chapter 7	1 of 9

Example of a Configuration for Downstream Connections

This chapter contains an example configuration that supports downstream systems connecting through SNA Server to a mainframe. The chapter begins with an overview of downstream connections and LUs, followed by an overview of the example configuration and then a detailed description of the configuration.

For additional background information and detailed instructions for configuring downstream connections and LUs, see Chapter 9 of the Microsoft SNA Server Administration Guide.


Overview of Downstream Connections and LUs
	Example of a Configuration for Downstream Connections	2 of 9
Overview of Downstream Connections and LUs

Downstream connections and LUs allow an SNA server to support communication between mainframes and any device that supports SNA PU 2.0 protocols, such as IBM CM/2, PC/3270, or even a 3174 cluster controller. Even though such systems do not use the SNA Server client/server interface, with a downstream connection, they can use host connections available through the SNA server.

Figure 7.1 illustrates downstream connections and LUs:

Figure 7.1    Communication with a Downstream System

To the downstream system, there appears to be a direct connection to the host. The SNA server accomplishes this by mapping LU messages back and forth between the downstream system and the host. The information that SNA Server passes from the downstream system to the host includes LU information. Therefore, SNA Server does not store detailed LU configuration information for downstream LUs.

This kind of mapping is referred to as a “concentrator” gateway, because it can have the effect of concentrating many downstream PU clients onto the LUs of a single upstream PU to the mainframe.

However, SNA Server does store detailed connection information. As shown in Figure 7.1, communication with a downstream system involves two connections, the host (upstream) connection and the downstream connection. Each of these connections must have the correct settings for the remote system involved (host or downstream). The most important settings are the correct identifier or address (such as Remote Node ID or Remote Network Address) and the correct Max BTU Length. Figure 7.2 illustrates the importance of these settings.

Figure 7.2    Using Correct Identifiers and Max BTU Lengths

As the Figure indicates, the identifier (or address) and Max BTU Length used on the host (upstream) connection need not be (and probably will not be) the same as those for the downstream connection. SNA Server will translate the differences automatically when relaying information.

Note that communication via a downstream connection and downstream LU in SNA Server is always dependent, that is, controlled by a mainframe. Independent communication (not controlled by a mainframe) is not available via downstream LUs on SNA Server.


Overview of the Example Configuration
	Example of a Configuration for Downstream Connections	3 of 9
Overview of the Example Configuration

In this example configuration, which supports downstream systems connecting through an SNA server to a mainframe, the downstream systems are on a token ring network. The connection between the SNA server and the mainframe is SDLC. The SNA server identifies two of the downstream systems through network address (token ring address), and two through Node ID.

Figure 7.3 illustrates the example configuration.

Figure 7.3    Downstream Systems Connecting Through an SNA Server

Figure 7.4 illustrates the steps for creating a configuration that supports a downstream system:

Figure 7.4    Steps for Creating a Configuration that Supports Downstream

As the illustration shows, the downstream LU becomes associated with both the upstream (host) connection and the downstream connection. This is done by first creating the downstream LU on the host (upstream) connection and then associating that LU with the downstream connection. (These steps cannot be reversed.)

This example configuration illustrates the use of downstream LUs, but downstream LU pools (that is, groupings of downstream LUs) can also be used. When downstream LU pools are assigned to downstream connections, downstream systems can request the pool rather than an individual LU, and receive support as long as any of the pooled LUs are available. In this way, a downstream pool allows intermittently used downstream systems to make efficient use of upstream resources. For example, twenty downstream systems that only require intermittent LU access may be adequately served by a pool of ten downstream LUs. The users on the downstream systems will share the pooled downstream LUs on a first-come first-served basis. As soon as one user stops using a pooled LU, that LU again becomes available for another user to access.

Figure 7.4 (earlier in this chapter) shows the sequence of steps for creating a downstream configuration that uses LUs rather than LU pools. To include a downstream pool in a configuration, the pool would be created immediately after the downstream LUs are created — in Figure 7.4, this would be immediately after step 3. Then the downstream LUs would be assigned to the LU pool, and the pool (rather than the individual LUs) would be associated with the downstream connection. This corresponds to step 4 in Figure 7.4. Then, as shown in step 5, the Downstream LU Number of the LU pool could be adjusted so that it matched the number expected by the downstream system. After this configuration had been created, whenever the downstream system requested the Downstream LU Number that corresponded to the LU pool, SNA Server would provide the next available LU in the pool.

The remaining sections show how each of the steps is carried out for the example configuration.


Connections for Support of Downstream Systems
	Example of a Configuration for Downstream Connections	4 of 9
Connections for Support of Downstream Systems

This example configuration includes one SNA server. The server has an SDLC connection to a mainframe, and token ring connections to downstream systems.

Important

This is an example configuration. You must adapt the example to your situation; for example, you must determine the correct node identifiers (such as Local Node ID) to use in your situation. For detailed information about configuring connections and LUs, see the Microsoft SNA Server Administration Guide.

The following illustration shows the configuration after installation. Along with the SNA server, two link services (and two adapters, token ring and SDLC) have been installed.

Example Configuration: Servers and Connections Window


Host Connection: SDLC
	Example of a Configuration for Downstream Connections	5 of 9
Connections for Support of Downstream Systems

Host Connection: SDLC

The first connection described in this example configuration is the SDLC connection. The following dialog box is reached by double-clicking the SDLC1 connection on SNASERV1. The illustration shows the information to be entered for the example:

Example Configuration: Connection Properties Dialog Box

Note that the SDLC connection activates only on demand. When downstream systems request sessions that use the connection, SNA Server will activate it.

For this example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: SDLC Setup Dialog Box


Host Settings Corresponding to Example
	Example of a Configuration for Downstream Connections	6 of 9
Connections for Support of Downstream Systems

Host Settings Corresponding to Example

The preceding settings in this example work with the following host settings:

Setting in the PU definition  in VTAM or NCP	Corresponding SNA Server setting
IDBLK=001 and IDNUM=00001	Local Node ID 001 00001
ADDR=C1	Poll Address C1
MAXDATA=521	Max BTU Length 521
Also note that the preceding Encoding setting of NRZI corresponds to the VTAM default, which is NRZI=YES in the LINE/GROUP definition.

The VTAM or NCP settings that match the LUs configured in later sections are described at the end of those sections.


Downstream Connections: Token Ring
	Example of a Configuration for Downstream Connections	7 of 9
Connections for Support of Downstream Systems

Downstream Connections: Token Ring

The example configuration shows multiple downstream connections, all using token ring. For the first connection, the following dialog box is reached by double-clicking the existing token ring connection on SNASERV1. The illustration shows the information to be entered for the example. Note that for Remote End, Downstream is selected, and for Allowed Directions, Incoming Calls is selected:

Example Configuration: Connection Properties Dialog Box

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: 802.2 Setup Dialog Box

As shown in the preceding illustration, this downstream connection identifies a downstream system through the Remote Network Address (also called the token ring address). The connection is set up to accept communication from a downstream system with an address of 123456789012.

Important

The illustration shows a Max BTU Length setting of 1929, which is the default for a token ring connection. However, this value must be less than or equal to the maximum value supported on the downstream system. Otherwise, communication cannot be established.

For example, with the IBM PC/3270 software, the corresponding parameter is PIU Size (accessed through the ConFigure Link button) and the default is 265. This value does not match the default for a token ring connection on an SNA server, which is 1929. This mismatch will cause problems when the host sends a logon screen; SNA Server will relay the screen to the downstream client using frames that are 1929 bytes long instead of 265. To correct this, either increase the PIU Size (on the PC/3270 system) to 1929, or decrease the Max BTU Length (on the SNA server) to 265.

In summary, be sure to adjust the Max BTU Length as necessary to work with the downstream system. The Max BTU Length for the downstream connection need not match the Max BTU Length for the host (upstream) connection; for a diagram of this, see Figure 7.2.

Second Token Ring Connection

The next downstream connection for the example configuration will identify the downstream system through the Node ID. The connection is created by selecting SNASERV1 and then, from the Services menu, choosing New Connection. In the resulting dialog box, the following selection is made:

Example Configuration: Insert Connection Dialog Box

The next steps for the example are to choose OK and complete the Connection Properties dialog box:

Example Configuration: Connection Properties Dialog Box

For the example configuration, the next steps are to choose the Setup button and then the Advanced button. The following illustration shows the information to be entered for the example:

Example Configuration: 802.2 Setup Dialog Box

As shown in the preceding illustration, this downstream connection identifies a downstream system through the Remote Node ID. The connection is set up to accept communication from a downstream system with a node ID of 002 00002. The downstream system would be configured accordingly; for example, on a PC/3270 system, the Block ID would be 002 and the Physical Unit ID 00002.

Important

As in the illustration of TRDOWN1, the illustration for TRDOWN2 shows a Max BTU Length setting of 1929, which is the default for a token ring connection. However, this value must be less than or equal to the maximum value supported on the downstream system. Otherwise, communication cannot be established.

For example, with the IBM PC/3270 software, the corresponding parameter is PIU Size (accessed through the ConFigure Link button) and the default is 265. This value does not match the default for a token ring connection on an SNA server, which is 1929. This mismatch will cause problems when the host sends a logon screen; SNA Server will relay the screen to the downstream client using frames that are 1929 bytes long instead of 265. To correct this, either increase the PIU Size (on the PC/3270 system) to 1929, or decrease the Max BTU Length (on the SNA server) to 265.

In summary, be sure to adjust the Max BTU Length as necessary to work with the downstream system. The Max BTU Length for the downstream connection need not match the Max BTU Length for the host (upstream) connection; for a diagram of this, see Figure 7.2.

Additional Token Ring Connections

Additional token ring connections could be configured similarly to TRDOWN1 or TRDOWN2. Each connection would need a unique name, such as TRDOWN3, TRDOWN4, and so on. Each connection would be required to identify the downstream system in an appropriate way; for example, by using the correct Remote Network Address or the correct Remote Node ID for that system. Each connection would also be required to use a Max BTU Length that was not too large to be supported by the downstream system.

Note that all the downstream connections are configured to accept incoming calls only; such incoming connections begin “listening” for calls when the server is started. This makes the the Activation setting irrelevant for the downstream connections.


Creating Downstream LUs on the Host Connection
	Example of a Configuration for Downstream Connections	8 of 9
Connections for Support of Downstream Systems

Creating Downstream LUs on the Host Connection

After connections are configured, the LUs for the example configuration are configured. The following dialog box shows the configuration after one host connection (SDLC1) and multiple downstream connections (TRDOWN1 through TRDOWN4) have been configured on the SNA server:

Example Configuration: Servers and Connections Window

For the example configuration, the next steps are to ensure that SDLC1 is selected and then, from the Services menu, choose Assign LUs. In the resulting dialog box, the selections to be made are as follows:

Example Configuration: Insert LU Dialog Box

The next steps for the example are to choose OK and complete the Add LU Range dialog box:

Figure 7.5    Example Configuration: Add LU Range Dialog Box

The next step for creating these LUs is to choose OK in the Add LU Range dialog box. The Downstream LU Range Properties dialog box appears:

Example Configuration: Downstream LU Range Properties Dialog Box

After the OK button is chosen, the LUs are created, with LU numbers from 1 through 4. In VTAM or NCP, these numbers are set in the LU definition with the LOCADDR parameter. Therefore, to work with the example configuration, the VTAM or NCP LU definition would have to include four instances of LOCADDR, with settings of 1, 2, 3, and 4.

On the SNA Server end, these LU numbers can be modified by selecting each LU and specifying the desired number. Alternatively, on the SNA Server side, the LUs can be deleted and re-created with the intended LU numbers.

Downstream Pools: Another Option

Although the example configuration does not use downstream LU pools, these pools can be very useful, especially in situations where multiple downstream systems need intermittent access to upstream resources. For example, twenty downstream systems that only require intermittent access could share ten downstream LUs, if these LUs are placed in a pool. For a more detailed discussion of how such a pool works, see the text following Figure 7.4, earlier in this chapter.

For a configuration that uses a downstream pool, the pool is created immediately after the downstream LUs are created. The commands for working with pools are in the Pools menu, which becomes available when you select the LU Pools window. In the Pools menu, the New Pool command allows you to create a new pool; the New Pool dialog box allows you to name the pool and select Downstream as the Pool Type. Also in the Pools menu, the Assign LUs command allows you to assign existing downstream LUs to the pool. (You must assign LUs to a pool before the pool becomes functional.) After the pool is created and LUs are assigned to it, it can be associated with a downstream connection, just as an individual LU can be associated with a connection. For instructions about how to associate a downstream LU (or LU pool) with a downstream connection, and how to adjust the Downstream LU Number of a downstream pool, see the remainder of this chapter.

The Downstream LU Number of a pool works in a similar way to the Downstream LU Number of an individual LU. When a downstream system requests the Downstream LU Number that corresponds to an LU pool, SNA Server recognizes that the pool is being requested, and provides the next available LU in the pool. For a detailed description of how Downstream LU Numbers work, see “Adjusting the Numbering of Downstream LUs,” later in this chapter.


Associating Downstream LUs with Downstream Connections
	Example of a Configuration for Downstream Connections	9 of 9
Connections for Support of Downstream Systems

Associating Downstream LUs with Downstream Connections

After the preceding steps have been carried out, the example configuration contains a host connection, a number of downstream connections, and some newly created downstream LUs. These elements form the basic building blocks of the configuration, but they have not yet been linked up, because the downstream LUs have not yet been associated with a downstream connection (only with the host connection that the LUs were created on). The correct association links everything together. That is, the association makes clear that information coming in on the downstream connection is to be passed on along a specific downstream LU to a specific host (on the host connection). For diagrams, see Figures 7.1 and 7.4, earlier in this chapter.

Therefore, the next step for the example configuration is to select the downstream connection TRDOWN1 and then, from the Services menu, choose Assign LUs. The following illustration shows the selection to make in the Assign Downstream LU/Pool Sessions dialog box:

Example Configuration: Assign Downstream LU/Pool Sessions Dialog Box

If you wanted to associate more than one LU or LU pool with the downstream connection, you could use the SHIFT or CTRL key. To select multiple items in sequence, click the first item you want, hold down SHIFT, and click the last item you want. To select multiple items out of sequence, hold down CTRL as you click the items you want.

To associate the selected items (DOWN1 is selected in the illustration) with the downstream connection (TRDOWN1), choose OK. After the association is created, DOWN1 is listed to the right when TRDOWN1 is selected, as shown:

Example Configuration: Downstream Connection and Associated Downstream LU

Creating More Associations Between LUs and Connections

Additional associations are created by selecting the downstream connection and then, from the Services menu, choosing Assign LUs. After selecting the appropriate LU and choosing OK, the LU will be listed to the right of the downstream connection to which it has been assigned. The following illustration shows DOWN2 assigned to TRDOWN2.

Example Configuration: Downstream Connection and Associated Downstream LU

The step of associating downstream LUs with downstream connections is repeated until all downstream LUs have the correct association.

Adjusting the Numbering of Downstream LUs

In order to understand a downstream configuration, it is important to understand that downstream LUs have two different numbers:

The LU number, which identifies the LU to the mainframe, and is assigned when the LU is created (see Figure 7.5, earlier in this chapter)

The downstream LU number, which identifies an LU or LU pool to the downstream system

The LU number and the downstream LU number need not match, and probably will not match. After assigning a downstream LU to a downstream connection, it is important to make sure that the downstream LU number matches the LU number expected by the downstream system.

Downstream LU numbers cannot be typed into a dialog box, however. A downstream LU number is assigned by SNA Server to each LU or LU pool in the list for the downstream connection. SNA Server assigns downstream LU numbers starting with 2 and ascending consecutively. Therefore, one way to change downstream LU numbers is to reorder the list of LUs for the downstream connection. Another way to change downstream LU numbers is to use empty LU pools to take up unwanted numbers, leaving the correct (larger) numbers for other LU pools or LUs. These two methods will be combined in the example configuration.

In the example configuration, the downstream LUs have the following downstream LU numbers:

Downstream LU	Downstream LU number assigned by SNA Server
DOWN1	2 (on the TRDOWN1 connection)
DOWN2	2 (on the TRDOWN2 connection)
DOWN3	2 (on the TRDOWN3 connection)
DOWN4	2 (on the TRDOWN4 connection)
Suppose, however, that the downstream systems are set up to use the following numbers:

Downstream LU	Downstream LU number expected by the respective downstream system
DOWN1	5
DOWN2	2
DOWN3	2
DOWN4	2
This means that the downstream LU numbers will work correctly, except for DOWN1, where the number assigned by SNA Server is three less than the number expected by the downstream system. Therefore, for the example configuration, three downstream LU pools are created, but left empty of LUs; the pools will be used as placeholders. The first steps for doing this are to select the LU Pools window and then, from the Pools menu, choose New Pool. The resulting dialog box is completed as follows:

Example Configuration: Creating an Empty Pool as a Placeholder

After choosing OK, the action of creating a downstream pool is repeated two more times, to create three empty pools with the names of EMPTY2, EMPTY3, and EMPTY4. Because no LUs have been added to the pools, they provide no session support, but simply serve as placeholders. After the pools are created, they appear as follows:

Example Configuration: Three Empty Pools Created as Placeholders

The next step for changing the downstream LU number for DOWN1 is to associate the three pools with the downstream connection used by DOWN1, which is TRDOWN1. The steps for doing this are to select TRDOWN1 and, from the Services menu, choose Assign LUs. The Assign Downstream LU/Pool Sessions dialog box appears:

Example Configuration: Assign Downstream LU/Pool Sessions Dialog Box

To select all three pools, select EMPTY2, press and hold SHIFT, and select EMPTY4. The pools are selected:

Example Configuration: Three Empty Pools Selected

The next step is to choose OK. The display now appears as follows:

Example Configuration: Three Pools and One LU Assigned to a Connection

As the previous illustration shows, for DOWN1, the downstream LU number (under the heading LU #) is still 2. To change this number to 5, the empty pools must be moved up so that they are listed ahead of DOWN1. The steps for doing this are to select all three pools (by selecting the first pool, holding the SHIFT key, and selecting the last pool) and then, from the Services menu, choosing Reorder LUs. The Reorder LU Session dialog box appears; the number to type is shown in the following illustration:

Example Configuration: Changing the Order of Selected LU Sessions

The final step in reordering sessions is to choose OK. The three empty pools are moved up before session 2 (the former session number for DOWN1). Therefore, the downstream LU number for DOWN1 is now 5, as shown on the right side of the following:

Example Configuration: Downstream LU Number Corrected for DOWN1

Note that for DOWN1, the upstream LU number (the number recognized by the host) is still 1. This can be seen if SDLC1 is selected. In the resulting display, the four downstream LUs have the same LU numbers as before:

Example Configuration: Upstream LU Numbers Unchanged

In this way, both the downstream and the upstream LU numbers are set so that they work with the respective systems. The final step for the configuration is to choose the Save button.

To activate the SNA server so that it is available to support the downstream systems, select the server and then choose the Start button.


Network Protocols and Client-Server Communication
Appendix A	1 of 16

Network Protocols and Client-Server Communication

This appendix contains information about how clients using different network (LAN) protocols can communicate with SNA servers. The appendix includes the following:

An overview of how network protocols are used on clients, and how client logons work.

Procedures for checking the SNA Server Setup options specified on a client or server. These Setup options must be specified correctly in order for the client to communicate with an SNA server.

Descriptions and illustrations of how clients using each of the possible protocols locate an SNA server in the network.

For background information about client-server communication, see “Communication Between Clients and SNA Servers” in Chapter 1. For a discussion of SNA servers in relation to their use of network protocols, see “Choosing and Setting Up Network Protocols on SNA Servers” in Chapter 2. For information about problems with user rights or memory on client computers, see Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.”


Overview of Network Protocols for Clients
Network Protocols and Client-Server Communication	2 of 16

Overview of Network Protocols for Clients

SNA Server clients can communicate with servers through the following network (LAN) protocols:

Microsoft networking (named pipes)

IPX/SPX (the protocol used with NetWare)

Banyan VINES IP

TCP/IP

AppleTalk

Important

In order for the different client-server protocols to be handled correctly by SNA Server, both clients and servers must have the network software and the SNA Server software installed correctly. Be sure to follow the installation instructions in this appendix carefully, and follow the installation instructions for other software you are using (Windows NT Server and the associated network software, SNA Server server software, and network software on clients). For installation of clients using TCP/IP, be sure to use the installation instructions in this appendix, which supersede the instructions in the Microsoft SNA Server Installation Guide.

Correct installation of network and SNA Server software on servers and clients ensures that two essential aspects of communication work correctly:

The servers and clients are “visible” to each other on the LAN. This results when the network software is installed correctly on all affected computers.

The SNA servers communicate with clients over the correct LAN protocol, and the clients direct their communication to the correct domain name or (for some clients using Microsoft networking or TCP/IP) to one or more correct server names. (In addition, with Banyan VINES, servers and clients must use the same StreetTalk group name.) This results when the SNA Server software is installed correctly.

An SNA Server client must be set up to use the correct server or domain name, or (for Microsoft networking) set up to locate servers in the local domain. Otherwise the client will not be able to locate an SNA server.

Note

For clients running Windows for Workgroups version 3.11, special adjustments may be needed. For details, see “Adjusting Clients Running Windows for Workgroups,” later in this appendix.

For example, in order for a client to successfully communicate over NetWare, there must be working communication between the client, a NetWare server (which provides the client with names of SNA servers), and any SNA servers in the network. Figure A.1 illustrates how correct installation is necessary for successful communication:

Figure A.1    Correct Installation: Elements and Results

For information about how SNA Server allows you to view and choose the domain and protocols to be used by SNA servers and clients, see “Important SNA Server Setup Options,” later in this appendix. For details about how each of the network protocols works on an SNA Server client, see the section about that network protocol (for example, “Clients Using TCP/IP”), later in this appendix.


Client Logons and the Storing of Passwords
Network Protocols and Client-Server Communication	3 of 16

Overview of Network Protocols for Clients

Client Logons and the Storing of Passwords

For security reasons, a user at a client computer may have to log on several times before obtaining access through SNA Server to a mainframe or AS/400. Users may not always find this to be convenient. (The logon process can be simplified somewhat on clients running Windows version 3.x or MS-DOS, as described in the following sections.) The logons are necessary because starting an SNA session requires several kinds of access: access to the Windows NT domain, access to an SNA server, access to the mainframe or AS/400 and, possibly, access to programs on the mainframe or AS/400. (An example of such a program is an AS/400 program that uses conversation security when communicating with 5250 emulators.) Each layer of access may require an additional logon (depending on the operating system and the client-server protocol used on the client). In the case of clients running Windows NT, however, logging on using a domain account automatically provides access to the domain and to any SNA servers in the domain, regardless of the client-server protocol used.

Types of Client Logons

The number of logons required for establishing an SNA session from a client varies, depending mostly on what client-server protocol the client computer is using. The following list describes the logons.

Clients using Microsoft networking

A client using Microsoft networking must log on to the Windows NT domain and then must perform any logons required on the mainframe or AS/400. For example, a client using Microsoft networking and also using a 5250 emulator would log on once to the Windows NT domain, once to the AS/400 itself, and (in many cases) once to the AS/400 program that communicates with the 5250 emulator.

After clients using Microsoft networking are logged on to the domain, no additional logon is needed for access to SNA servers in the domain. That is, SNA Server can securely confirm the domain logon without any additional action by the user.

Note that with clients using Windows for Workgroups, a logon is required for starting Windows for Workgroups — but you can configure the client to simultaneously log you on to Windows for Workgroups and to the Windows NT domain. For information, see “Password Settings with Windows for Workgroups,” later in this chapter.

Clients using Novell NetWare or Banyan VINES

A client using NetWare or VINES must first log on to the NetWare or VINES network and then to the SNA servers; finally, the client must perform any logons required on the mainframe or AS/400. However, on clients running Windows version 3.x or MS-DOS, the logon to the SNA servers can be stored as a command, as described in the next section. This method simplifies the logon process but also diminishes security somewhat, because the user name and password are stored as plain text (without encryption). However, the method still provides reasonable security for many situations, because the other logons (for example, to an AS/400) are still secure.

Clients using TCP/IP

A client using TCP/IP must log on to the SNA servers (even if the client has already accessed other resources in the Windows NT domain) and then must perform any logons required on the mainframe or AS/400. However, on clients running Windows version 3.x or MS-DOS, the logon to the SNA servers can be stored as a command, as described in the next section. This method simplifies the logon process but also diminishes security somewhat, because the user name and password are stored as plain text (without encryption). However, the method still provides reasonable security for many situations, because the other logons (for example, to an AS/400) are still secure.

Simplifying Logon on Clients Not Using Microsoft Networking

The series of logons required for SNA access means that a series of passwords must be typed by the SNA user each time the client software is restarted. However, on clients not using Microsoft networking, the logon process can be simplified by storing one of the logons in a command, which can then be run automatically through standard methods for the operating system, for example, through a batch file on MS-DOS. The stored command works on client computers running Windows version 3.x or MS-DOS, and is described in the next sections. The command is slightly less secure than standard logons, because the user name and password are stored in plain text on the client computer. However, the method still provides reasonable security for many situations, because the other logons (for example, to an AS/400) are still secure.

Storing a Password on Clients Running Windows

On a client running Windows  and not running Microsoft networking, you can store the password for the SNA server by using one of three methods, depending on which version of Windows the client is running:

On computers running Windows for Workgroups, you can store the password in the password list that Windows for Workgroups maintains for each user.

On computers running Windows version 3.x and Windows for Workgroups, you can store the password in the WIN.INI file.

On computers running Windows version 3.x and Windows for Workgroups, you can store the user name and password in a command that logs the user on to the SNA servers.

By default, Windows for Workgroups stores domain and server passwords in a user-specific encrypted password list, a process known as password caching. Once a user has logged on to an SNA server while password caching is enabled, SNA Server version 2.11 client software can log on to the SNA server by using the cached password, without having to prompt the user.

For computers running Windows 3.x and computers running Windows for Workgroups that do not use password caching, the password can be stored in the [WNAP] section WIN.INI, as shown:

LogonPassword=password

Because the password is stored as plain text, this option is somewhat less secure than the password caching feature of Windows for Workgroups.

As an alternative to storing the password in the WIN.INI file, you can create a command (for example, as a Program Item) that will start the client software and log the client on to the SNA servers. Then the command can be run automatically (for example, by placing an icon in the Startup program group). In this way, the user will avoid having to type the password for logging on to the SNA servers (the same password is used for logging on to the Windows NT domain).

The command is as follows:

wnap  /user:username  /pwd:password

For username and password, substitute the appropriate user name and password. The command starts the SnaBase software (also called the Windows network access protocol or WNAP) and logs the user on to the SNA servers. An example of a client for whom the command might be appropriate is a client running Windows version 3.1 with NetWare.

A user who does not use a password may want to use the preceding syntax without typing any characters after /pwd:. This will suppress the dialog box that requests a password.

If the preceding syntax line is used on a client running Microsoft LAN Manager (in other words, Microsoft networking), the user and pwd options are ignored, because the logon to the domain automatically takes care of the logon to the SNA servers for clients using Microsoft networking.

Note that SNA Server clients running Windows version 3.x automatically store the name of the user who most recently logged on to the SNA servers; the name is displayed when another logon to the SNA servers is initiated. Only the user name (not the password) is stored in this way.

Storing a Password on Clients Running MS-DOS

On a client running MS-DOS and not running Microsoft networking, you can store a command that will start the client software and log the client on to the SNA servers. Then the command can be run as part of a batch file. In this way, the user will avoid having to type the password for logging on to the SNA servers (this is the same password as for logging on to the Windows NT domain).

The command is as follows:

snabase  /user:username  /pwd:password

For username and password, substitute the appropriate user name and password. The command starts the SnaBase software and logs the user on to the SNA servers.  An example of a client for whom the preceding command might be appropriate is an MS-DOS – based client running NetWare.

A user who does not use a password may want to use the preceding syntax without typing any characters after /pwd:. This will suppress the dialog box that requests a password.

If the preceding syntax line is used on a client running Microsoft LAN Manager (in other words, Microsoft networking), the user and pwd options are ignored, because the logon to the domain automatically takes care of the logon to the SNA servers for clients using Microsoft networking.

Note that with a client running MS-DOS, you can optionally store the user name only, without the password, to simplify logon to the SNA servers in the domain. To store the SNA user name on a client running MS-DOS, open the SNA.INI file, and search for a line that says

[SnaBase]

If the line does not exist, create it; the line denotes the SnaBase section. Then place the following line underneath the [SnaBase] line.

LogonUserName=username

For username, substitute the appropriate user name. Save the SNA.INI file and restart the client computer.


Error Message 546 on a Client
Network Protocols and Client-Server Communication	4 of 16

Overview of Network Protocols for Clients

Error Message 546 on a Client

Error message 546 occurs on a client when it is unable to establish a sponsor connection (the initial connection needed for all SNA Server communication) with any SNA server. If installation has not been completed correctly on a client and on the server(s) that the client uses, error message 546 will occur (except for Windows NT– based clients, on which message 1004 will occur). Message 546, along with other common events and errors, is described in Appendix B, “Interpreting Events or Errors on SNA Servers or Clients.”

The usual causes of error message 546 are as follows:

The network software or SNA Server software on the client (or SNA server) was installed incorrectly, and the client cannot locate an SNA server.

For this situation, check to see if the client also receives error 629. For NetWare or VINES clients, the presence or absence of error 629 is especially important information. With NetWare or VINES, error 629 indicates that the client could not complete the preliminary step of obtaining SNA server names from the NetWare or VINES server. If error 629 does not occur with error 546, NetWare or VINES clients are obtaining SNA server names, but cannot contact the SNA servers (perhaps the SNA servers have gone down, or there is some kind of router or LAN problem).

For information about troubleshooting these errors, see the sections of this appendix that apply to your situation, and see the installation documentation for your software.

The logged-on user does not have the right to access SNA servers over the LAN. For troubleshooting information related to Windows for Workgroups, see “Domain and Password Settings for Clients Running Windows for Workgroups,” later in this appendix. For additional troubleshooting information for all client operating systems, see “User Rights to Access a Server from the Network” in Appendix B.

The client computer does not have enough free conventional memory, and the SnaBase (also called the NAP or WNAP) runs out of memory. For information about troubleshooting this, see “Memory Problems on Client Systems” in Appendix B.


Important SNA Server Setup Options
Network Protocols and Client-Server Communication	5 of 16

Important SNA Server Setup Options

The following two sections illustrate and describe important SNA Server Setup options for an SNA server or client. These options must be set correctly in order for clients to locate SNA servers and start sessions. If the options are set incorrectly, clients may use the wrong protocols or may search the wrong locations for SNA servers.

On both SNA servers and clients, you can run the Setup program repeatedly, as needed, to view or change options. (Avoid running the Setup program multiple times simultaneously; close Setup each time before starting it again.)


Important Setup Options on an SNA Server
Network Protocols and Client-Server Communication	6 of 16

Important SNA Server Setup Options

Important Setup Options on an SNA Server

When SNA Server Setup options are specified correctly on an SNA server, the server will use the appropriate protocol(s) for communication with clients and (for servers supporting NetWare, VINES, TCP/IP, or NetBIOS) will have the correct domain name, so that clients can locate the SNA servers.

The dialog boxes that allow you to view setup options on an existing SNA server are the same dialog boxes that display during initial setup of the server. For more information about setup of an SNA server, see the Microsoft SNA Server Installation Guide.

To view or change client/server protocols and other Setup options on an SNA server

1.	On the existing SNA server, start SNA Server Setup.

An introductory Setup dialog box appears.

2.	Choose Continue.

The Setup Options dialog box appears.

3.	Choose the Protocols button.

The dialog box shown in Figure A.2 appears.

Figure A.2    Select Client/Server Protocols Dialog Box

The selected protocols are the ones that the SNA server currently supports when communicating with clients. Protocols not installed on the local server are dimmed.

For diagrams showing examples of protocols on servers and clients, see “Network Protocol Choices for SNA Servers” in Chapter 2.

4.	As needed, select or clear options, to add or remove support of client/server protocols.

In domains with multiple SNA servers, some servers may support different client/server protocols than others. In order for any given client to be supported, the protocol used by that client must be supported by at least one SNA server, and the LUs needed by that client must be on that server.

Select the NetBIOS option if the server will support clients using NS/Router but not using NetWare (IPX/SPX). NS/Router and a NetBIOS component for clients are included (along with other components) in the N/S Midrange Bundle [image].

Note

If the server has TCP/IP installed and will communicate with clients that use TCP/IP, be sure that the selections in the Select Client/Server Protocols dialog box include TCP/IP. If Microsoft Networking (Named Pipes) is selected and TCP/IP is not, the server can communicate through named pipes over TCP/IP, a protocol combination that does not recover from error conditions as effectively as native TCP/IP. (A similar situation exists with NetBIOS and TCP/IP.)

Provided that TCP/IP is selected, you can also select Microsoft Networking (Named Pipes) and/or NetBIOS. In this situation, the SNA server will use native TCP/IP with clients that use TCP/IP, and other protocols with clients that use the other protocols.

For additional details about which protocol(s) to choose, see “Choosing and Setting Up Network Protocols on SNA Servers” in Chapter 2, as well as the remainder of this appendix.

5.	Choose the Continue button. If you selected Microsoft Networking (Named Pipes), the Setup Options dialog box reappears, and you can skip the rest of this procedure. (To exit SNA Server Setup, choose Continue and then Exit.)

If you did not select Microsoft Networking (Named Pipes), the dialog box shown in Figure A.3 appears.

Figure A.3    Network Domain Name Dialog Box

6.	If the Network Domain Name dialog box appears, type the Windows NT domain name and then choose Continue.

This name must be correct if SNA servers are to support clients using NetWare, Banyan VINES, TCP/IP, NetBIOS, or AppleTalk.

Note

The instructions for this dialog box in the Microsoft SNA Server Installation Guide include a list of forms that the Domain Name can take for TCP/IP. However, the only correct Domain Name to specify on a server using TCP/IP is the name of the Windows NT domain. This contrasts with the information that can be typed into the equivalent dialog box during installation or modification of a client. For information about what to specify for a client, see “Specifying Local or Remote Client Information with TCP/IP,” later in this appendix.

If you are using Banyan VINES (and not Microsoft networking), the StreetTalk Group Name dialog box appears. Otherwise, the Setup Options dialog box reappears.

7.	If the StreetTalk Group Name dialog box appears, type the StreetTalk group name and then choose Continue. For important details about the name, see “Clients Using Banyan VINES IP,” later in this appendix.

The Setup Options dialog box reappears.

8.	Choose Continue.

9.	To exit SNA Server Setup, choose Exit.

10.	If you have changed the client/server protocol options or the network domain name, start the Control Panel, select the Services option, and stop and restart the SnaBase service to put the changes into effect.


Important Setup Options on a Client
Network Protocols and Client-Server Communication	7 of 16

Important SNA Server Setup Options

Important Setup Options on a Client

For SNA Server Client Setup, several key options supply the information a client must have for locating SNA servers. These options specify which protocol the client uses to communicate with SNA servers (if more than one protocol is available on the client) and which domain or server name(s) the client will direct SNA requests to.

The dialog boxes that allow you to view these options are the same dialog boxes that display during initial setup of the client. On both SNA servers and clients, you can run Setup repeatedly, as needed, to view or change options. (Avoid running the Setup program multiple times simultaneously; close Setup each time before starting it again.)

The client-server protocols that a client can use with SNA Server version 2.11 are shown in Table A.1:

Table A.1    Client-Server Protocols Available for SNA Server Version 2.11 Clients

Operating system on client	Client-server protocols that can be used for SNA Server communication
Windows NT	Microsoft networking (named pipes) Novell NetWare (IPX/SPX) Banyan VINES TCP/IP
Windows version 3.x or Windows for Workgroups	Microsoft networking (named pipes) Novell NetWare (IPX/SPX) Banyan VINES TCP/IP
MS-DOS	Microsoft networking (named pipes) Novell NetWare (IPX/SPX) Banyan VINES
OS/2	Microsoft networking (named pipes)
Macintosh	AppleTalk
When a client makes an SNA request, the client must direct that request to a domain or to one or more SNA servers. The appropriate way for a client to direct requests depends on the protocol used and the relative location of clients and servers. Table A.2 lists the ways clients direct SNA requests, and the information that will be requested by Setup during client installation. For more detail about how a client directs requests and locates SNA servers, see the the section about the appropriate type of client (for example, “Clients Using TCP/IP”), later in this appendix.

Table A.2    How Clients Direct SNA Requests

Network protocol used on client	How the client directs SNA requests	Information to find out before running client setup
Microsoft networking	Either to the local domain (if the SNA servers are in the same domain as the client), or to one or two specific SNA servers in a remote domain.	Whether the client is in the same domain as the SNA servers, and if not, one or two names of SNA servers.
Novell NetWare (IPX/SPX)	To a specific domain. The SNA servers must be located in this domain in order for the client to locate them.	The name of the Windows NT domain in which the SNA servers are located.
Banyan VINES	To a specific domain and specific StreetTalk group name. These names must match the ones specified during setup of the SNA servers.	The domain name and StreetTalk group name specified during setup of the SNA servers.
TCP/IP	Either to a domain name or to specific server names, depending on what is specified in the SNA Client Mode or SNA Server Location dialog box. Table A.3 lists the possible entries.	See Table A.3.
AppleTalk	To a specific Windows NT domain and AppleTalk zone. The domain must be the domain of the SNA servers; the AppleTalk zone must be the one specified in the Services for Macintosh software on the server(s).	The name of the domain and zone used by the SNA servers. Note: the client software for the Macintosh is included within most Macintosh emulators, and does not require separate installation.
The following procedures describe how to check the Setup options specified on an SNA Server client. The first procedure is for a client running Windows NT or Windows version 3.x, and the second procedure is for a client running MS-DOS.

Note

Clients running Windows for Workgroups may require other configuration steps in addition to the ones described in the following procedure. For more information, see “Adjusting Clients Running Windows for Workgroups,” later in this appendix.

To view or change Setup options on a client running Windows NT or Windows version 3.x

1.	Double-click the SNA Server Client Setup icon (located by default in the SNA Server program group).

An introductory Setup dialog box appears.

2.	Choose the Continue button.

A dialog box similar to the following appears:

Setup Options Dialog Box (on a Client Running Windows)

3.	For a client running Windows version 3.x, select Setup System Files only and then choose the Continue button.

For a client running Windows NT, choose the Configure button.

If Setup detects more than one client/server protocol on your client, a dialog box similar to Figure A.4 appears.

Figure A.4    Client/Server Protocols Dialog Box (on a Client Running Windows)

If this dialog box does not appear, only one network protocol is available on the client; for clients using Microsoft networking or TCP/IP, skip to step 7; for other clients, skip to step 5.

4.	If the Client/Server Protocols dialog box appears, select the protocol that the client will use to communicate with SNA servers, and then choose Continue. The protocols are as follows:

Microsoft Networking (Named Pipes)

Novell NetWare (IPX/SPX)

Banyan VINES

TCP/IP

If the client system does not include one or several of the client/server protocols, the corresponding options are unavailable.

On a Windows NT – based client, you can select more than one protocol, but it is recommended that you choose only one, for greater efficiency.

Note

If the client has TCP/IP installed, and the Client/Server Protocols dialog box appears, be sure to select TCP/IP. For such a client, if Microsoft Networking (Named Pipes) is selected instead of TCP/IP, the client will communicate through named pipes over TCP/IP, a protocol combination that does not recover from error conditions as effectively as native TCP/IP.

For information about the different protocols, see the documentation that came with the network software, as well as the remaining sections of this appendix.

If you select Novell NetWare or Banyan VINES, the Network Domain Name dialog box appears. Otherwise, the SNA Client Mode or SNA Server Location dialog box appears; if this is the case, skip to step 7.

5.	If the Network Domain Name dialog box appears, type the name of the Windows NT domain in which one more SNA servers are found.

Figure A.5 shows the dialog box as it appears with Windows version 3.x:

Figure A.5    Network Domain Name Dialog Box (on a Client Running Windows)

The network domain name must be correct in order for the client to find SNA servers. For an explanation of how the clients find SNA servers, see “Clients Using NetWare (IPX/SPX),” “Clients Using Banyan VINES IP,” or “Clients Using TCP/IP,” later in this appendix.

Next, if you are using Banyan VINES (and not Microsoft networking), the StreetTalk Group Name dialog box appears. Otherwise, Setup makes the requested modifications, and the final dialog box appears; skip to step 8.

6.	If the StreetTalk Group Name dialog box appears, type the StreetTalk group name and then choose Continue. For important details about the name, see “Clients Using Banyan VINES IP,” later in this appendix.

After completing the StreetTalk Group Name dialog box, skip to step 8.

7.	If the client uses Microsoft networking or TCP/IP, the SNA Client Mode or SNA Server Location dialog box appears. In this box, specify whether the client will look for SNA servers in the local domain (the same domain the client is in) or in a remote domain.

The SNA Client Mode dialog box appears with Windows NT; the SNA Server Location dialog box (shown in Figure A.6) appears with Windows version 3.x.

Figure A.6    SNA Server Location Dialog Box (on a Client Running Windows)

For a client using Microsoft networking (named pipes), the procedure is as follows. If the client is located in the same network domain (and on the same side of any routers) as the SNA servers, select Local Domain. If clients and servers are not in the same domain, or are separated by a router, select Remote Domain and type the names of one or two SNA servers to which the client will direct SNA requests. (If the client is running Windows NT, the dialog boxes are slightly different. Choose between Local or Remote; if you choose Remote, dialog boxes appear in which you type the names of one or two SNA servers to which the client will direct requests.)

Note

For important information about completing this dialog box for clients using TCP/IP, see “Clients Using TCP/IP,” later in this appendix.

As illustrated in Figure A.7 (later in this appendix), once a remote client is connected to one server, the client discovers all the other servers in that domain.

When your choices are complete, choose Continue. Setup makes the requested modifications, and the final Setup dialog box appears.

8.	To exit Setup, choose Exit.

9.	If you have made changes, restart your computer so that the changes will take effect.

To view or change Setup options on a client running MS-DOS

1.	Invoke SNA Server Client Setup by changing to the appropriate drive and directory and typing

setup

An introductory Setup screen appears.

2.	Press ENTER.

The Home Directory Path screen appears.

3.	Press ENTER.

The Select Function screen appears.

4.	In the Select Function screen, select “Set up system files only,” and then press ENTER.

If Setup detects more than one client/server protocol on your client, the Client/Server Protocols screen appears.

If the Client/Server Protocols screen does not appear, only one network protocol is available on the client; for clients using Microsoft networking, skip to step 9; for other clients, skip to step 7.

5.	If the Client/Server Protocols screen appears, select the protocol that the client will use to communicate with SNA servers:

Microsoft Networking

Novell NetWare

Banyan VINES

For information about the different protocols, see the documentation that came with the network software, as well as the remaining sections of this appendix.

6.	Press ENTER.

If you did not select Microsoft Networking, the Network Domain Name screen appears. Otherwise, the Remote Operation screen appears; skip to step 9..

7.	If the Network Domain Name screen appears, type the name of the Windows NT domain in which one more SNA servers are found, and then press ENTER.

This name must be correct in order for the client to find SNA servers. For an explanation of how an MS-DOS – based client finds SNA servers in a nonMicrosoft network (for example, in a NetWare network), see “Clients Using NetWare (IPX/SPX)” or “Clients Using Banyan VINES IP,” later in this appendix.

If you are using Banyan VINES, the StreetTalk Group Name screen appears. Otherwise, the Confirm Setup Execution screen appears; skip to step 10.

8.	If the StreetTalk Group Name screen appears, type the StreetTalk group name and then press ENTER. For important details about the name, see “Clients Using Banyan VINES IP,” later in this appendix.

After completing the StreetTalk Group Name dialog box, skip to step 10.

9.	If the client uses Microsoft networking, the Remote Operation screen appears. Choose the appropriate option:

No remote operation: If this client is located in the same network domain and on the same side of any routers as the SNA servers, select “No remote operation” and then press ENTER.

Remote operation: If this client is not located in the same domain as the SNA servers, or is separated from the SNA servers by a router, select “Remote operation” and then press ENTER. Two screens follow, requesting one or two names of SNA servers (the first name is required, but the second is optional). Type the names of one or two SNA servers to which the client will direct requests. After you finish with each screen, press ENTER.

As illustrated in Figure A.7 (later in this chapter), once a remote client is connected to one server, the client discovers all the other servers in that domain.

10.	When the Confirm Setup Execution screen appears, if you are satisfied with your choices, select Execute Setup and then press ENTER.

Setup makes the requested modifications, and the Setup Completed Successfully screen appears.

11.	Press ENTER.

12.	If you have made changes, restart your computer so the changes will take effect.


Adjusting Clients Running Windows for Workgroups
Network Protocols and Client-Server Communication	8 of 16

Adjusting Clients Running Windows for Workgroups

Clients running Windows for Workgroups have a very flexible set of options for network operation. As a result, these clients may require specific adjustments in order to communicate with SNA servers:

Clients running Windows for Workgroups and using Microsoft networking (not other network software) must use domain and password settings that coordinate with settings in SNA Server Client Setup. For example, if the client’s workgroup name does not match the server’s domain name, options in SNA Server Client Setup must be set accordingly. For information, see the next section.

Clients running Windows for Workgroups version 3.11 and connecting to an SNA server running Windows NT version 3.5 or 3.51 may require a specific setting in the SYSTEM.INI file. For information, see “SYSTEM.INI Setting for Clients Running Windows for Workgroups,” later in this appendix.


Domain and Password Settings for Clients Running Windows for Workgroups
Network Protocols and Client-Server Communication	9 of 16

Adjusting Clients Running Windows for Workgroups

Domain and Password Settings for Clients Running Windows for Workgroups

This section applies only to clients running Windows for Workgroups and using Microsoft networking to communicate with SNA servers. Such clients must be configured so that any domain names, workgroup names, local passwords, and domain passwords all work together smoothly.

Domain Settings with Windows for Workgroups

For domain names and workgroup names, use one of the following approaches:

Workgroup name differs from SNA Server domain name: For clients where the workgroup name must be different from the server’s domain name (the name of the Windows NT domain), in SNA Server Client Setup, you must use the Remote Domain setting. That is, in the SNA Server Location dialog box, select Remote Domain, and supply the name of one or two SNA servers to which the client will send requests. For details, see Figure A.6, earlier in this appendix, along with the text following the figure.

To view a client’s workgroup name, in the Control Panel, double-click the Network icon. The name is listed in the resulting dialog box.

Workgroup name matches SNA Server domain name: For clients where the workgroup name is the same as the server’s domain name (the name of the Windows NT domain), in SNA Server Client Setup, you can use the Local Domain setting. That is, in the SNA Server Location dialog box (Figure A.6), you can select Local Domain. When the client requests an SNA session, the request will reach the domain that has the same name as the client’s workgroup.

To view a client’s workgroup name, in the Control Panel, double-click the Network icon. The name is listed in the resulting dialog box.

Password Settings with Windows for Workgroups

For Windows for Workgroups passwords and domain passwords, use one of the following approaches:

Enable logon to the Windows NT domain automatically at startup: You can configure Windows for Workgroups to log the user on to the Windows NT domain automatically at startup.

To do this, first make sure that a user account has been created for the user in the Windows NT domain, and obtain the assigned user name and password. Next, on the client computer, from the Control Panel, double-click the Network icon and then choose the Startup button. In the Startup Settings dialog box, under Options for Enterprise Networking, find the check box labeled Log On to Windows NT or LAN Manager Domain. Select this check box, and type the Domain Name in the appropriate box. Choose OK repeatedly until the dialog boxes are closed. The next time Windows for Workgroups is restarted, the user will be prompted for both the local password and the domain password, and must type them correctly. Thereafter, only the local password is needed at startup, because the domain password is encrypted and stored (to be “unlocked” by the local password).

Note

After domain logon has been set up, it is important for the user to understand the difference between the local Windows for Workgroups password and the actual domain password. The local Windows for Workgroups password unlocks the (encrypted) password list that has been stored for that user on that computer. This password list includes a copy of the domain password, if the preceding configuration steps have been taken. The actual domain password is the password for that user’s account on the Windows NT domain, as recorded on Windows NT servers that are domain controllers.

The user’s domain account may be set up to require periodic changing of  the password. If the domain password expiration date is getting close, when the user logs on to the domain, pop-up warnings will appear on the user’s computer. (Note that the user must try to log on in order for the pop-up warnings to appear.) At this point, the user needs to understand the different buttons used for changing passwords with Windows for Workgroups. After choosing the Network option from the Control Panel, the button to use for changing the local password is the Password button. This only changes the password used to onlock the user’s local password list; it does not change the domain password.

To change the domain password, the user must choose the Startup button followed by the Set Password button. When the user changes the domain password using the Set Password button, the domain password is also changed in the local password file.

Make sure that users understand how to use these buttons correctly to change their local Windows for Workgroups password and to change their Windows NT domain password.

Log on only as needed, by using the net logon command: If the user does not log on to the Windows NT domain at startup, the following command can be used before starting an SNA session. At the MS-DOS prompt (from within Windows for Workgroups), type

net logon  username  /domain:domainname

After typing the command, the user is prompted for the domain password.


SYSTEM.INI Setting for Clients Running Windows for Workgroups
Network Protocols and Client-Server Communication	10 of 16

Adjusting Clients Running Windows for Workgroups

SYSTEM.INI Setting for Clients Running Windows for Workgroups

For a client running Windows for Workgroups version 3.11, if the following conditions are met, you will need to set an option in the SYSTEM.INI file on the client:

The client connects to an SNA server running Windows NT version 3.5 or 3.51.

The network software installed by default, including the Novell NetWare IPX/SPX software, has been allowed to remain on the client system.

For communication with an SNA server, the client uses Microsoft networking.

This means that the client/server protocol chosen in SNA Server Client Setup is Microsoft Networking (Named Pipes).

This is because servers running Windows NT version 3.5 or 3.51 include “direct hosting,” an additional, more efficient way of handling IPX/SPX. However, with a client running Windows for Workgroups version 3.11 and using Microsoft networking (named pipes), the client’s default method of SNA Server communication includes IPX/SPX but does not work with direct hosting. For more details about what direct hosting is and why clients running Windows for Workgroups version 3.11 must be adjusted, see the end of this section.

To adjust a client running Windows for Workgroups for use with an SNA server running Windows NT version 3.5 or 3.51

1.	On the client, use a text editor (such as Notepad) to open the SYSTEM.INI file, located in the Windows root directory.

2.	In the SYSTEM.INI file, find the section with the heading of [Network].

3.	Under the [Network] heading, add the following line:

DirectHost=NO

4.	Save the SYSTEM.INI file as plain (ASCII) text (that is, avoid saving the file in a special format specific to the text editor).

5.	Restart the client system.

This adjustment is needed because servers running Windows NT version 3.5 or 3.51 include “direct hosting.” With direct hosting, the server supports communication directly over IPX/SPX instead of over the combination of NetBIOS and IPX/SPX. Clients running Windows for Workgroups 3.11 and using setup defaults also support this more efficient type of communication — but only for accessing files and using Microsoft SQL Server functions. These clients cannot successfully communicate with SNA servers when the method of communication is direct hosting with IPX/SPX. (The type of communication that cannot be carried out is called “asynchronous named pipe communication”; it is needed by the SNA Server software.) All that is necessary for the clients to work is that they avoid using direct hosting over IPX/SPX when communicating with SNA servers. This is why the clients must have the DirectHost option set to NO in the SYSTEM.INI file.


Details About How Clients Use Protocols
Network Protocols and Client-Server Communication	11 of 16

Details About How Clients Use Protocols

The following sections describe how each type of client works with SNA Server. The clients are listed according to the protocol used: Microsoft networking (named pipes), Novell NetWare (IPX/SPX), Banyan VINES, TCP/IP, and AppleTalk.


Clients Using Microsoft Networking (Named Pipes)
Network Protocols and Client-Server Communication	12 of 16

Details About How Clients Use Protocols

Clients Using Microsoft Networking (Named Pipes)

The SNA Server clients that can use Microsoft networking (named pipes) include clients running the following:

MS-DOS with LAN Manager.

OS/2.

Windows with LAN Manager.

Windows for Workgroups and the included Microsoft networking software.

For clients running Windows for Workgroups version 3.11, be sure to see the previous section for configuration adjustments that must be made.

Some version of Windows NT, such as Windows NT Server version 3.51 or Windows NT Workstation version 3.5.

To find out how to check an SNA server or client to see if it uses Microsoft networking, see “Important SNA Server Setup Options,” earlier in this appendix.

Clients using Microsoft networking, like all SNA Server clients, use the sponsor-connection process in order to locate an SNA server that has the LU(s) or LU pool(s) needed by the client:

Figure A.7    Client Request, Sponsor Connection, and Locating of Needed Server

Clients using Microsoft networking use only the sponsor-connection process for locating SNA servers. In contrast, clients using NetWare, VINES, TCP/IP, or AppleTalk (described in later sections in this appendix) must first access the appropriate network name/address system, such as the NetWare bindery, and then use the sponsor-connection process.

With Microsoft networking, you can choose between two methods by which a client searches for SNA servers. Local operation means that the client locates the server through broadcasts in the local domain; therefore, the client must be in the same domain as the SNA servers, and must not be separated from the servers by a router. (For additional details about Windows for Workgroups and domain names, see “Domain and Password Settings for Clients Running Windows for Workgroups,” earlier in this chapter.) Remote operation means that the client searches for SNA servers by name, and therefore need not share a domain (nor be on the same side of any routers) as the SNA servers.

Note

Clients using Microsoft networking, like all clients, must be given sufficient user rights on SNA servers to access the servers across the network. These rights are controlled through the Windows NT User Manager, not SNA Server. For more information, see “User Rights to Access a Server from the Network” in Appendix B.


Clients Using NetWare (IPX/SPX)
Network Protocols and Client-Server Communication	13 of 16

Details About How Clients Use Protocols

Clients Using NetWare (IPX/SPX)

An SNA Server client using NetWare (IPX/SPX) relies on the “bindery” service on NetWare servers for information about resources on the network. Therefore, such a client goes through several steps in the process of requesting a session through an SNA server. Figure A.8 shows the process.

Figure A.8    NetWare Client Requesting Initial SNA Session

As Figure A.8 shows, at regular intervals, the SNA server registers its name in the bindery on the NetWare server. A client requests an initial SNA session by sending the request to the NetWare server. In response, the NetWare server scans the bindery list for the names of SNA servers in the client’s domain, and sends those names to the client. The client then selects a name at random and sends its request to that SNA server.

The first SNA server contacted by the client provides the “sponsor connection” for the client. The “sponsor” SNA server provides the client with the names of all the SNA servers in the domain, and then the client tries SNA servers at random until the necessary LU or pool is located. (For a diagram of the sponsor-connection process, see Figure A.7.) Subsequent SNA requests from the client use the same sponsor connection. In other words, the process of locating the first SNA server is not repeated unless the SnaBase (a basic software component) on the client is stopped and restarted.

Checklist for Clients Using NetWare (IPX/SPX)

Figures A.1 and A.8 indicate that certain conditions must be met before a client using NetWare will be able to locate an SNA server. When these conditions aren’t met, on the client, error messages 629 and/or 546 occur, and no SNA sessions will be established. Error 629 indicates that the client is not able to contact the NetWare server and/or obtain names of SNA servers; error 546 naturally follows, because it indicates that the client was unable to establish a sponsor connection.

When troubleshooting errors 629 and 546, check that all of the following conditions have been met:

The NetWare server is properly installed and running, so that the bindery service is available.

The SNA server has registered its name in the bindery on the NetWare server. Several elements are required for this. The first element happens automatically: the installation of the NWLink (IPX/SPX) software on Windows NT. The next two elements, frame-type matching and IPX router configuration, may require studying both the NetWare and Windows NT Server documentation. The frame types (802.2 versus 802.3) must match between the Windows NT Server and the NetWare Server; in addition, any IPX routers between the two servers must be configured to allow NetWare SAP broadcasts (Service Advertising Protocol broadcasts) to flow. Specifically, IPX routers must propagate sockets 84C8 and 84C9 to support the communication needed by SNA servers and clients.

Also, for the SNA server to register its name on the NetWare server, the SNA Server software must be installed to work with IPX/SPX. This means that in SNA Server Setup, the Novell NetWare (IPX/SPX) option must be selected in the Select Client/Server Protocols dialog box (see Figure A.2).

In addition, if the options selected in the Select Client/Server Protocols dialog box do not include Microsoft Networking (Named Pipes), the Network Domain Name dialog box appears, as shown in Figure A.3. The correct domain name must be typed in this dialog box (if the box appears); the name is registered (along with the server name) on the NetWare server. Only if the NetWare server is provided with correct domain names can it respond to client requests and provide the clients with SNA server names. For a diagram of how the servers and clients interact, see Figure A.8.

The logged-on user has sufficient user rights to access the SNA server across the network. These rights are controlled through the Windows NT User Manager, not SNA Server. For more information, see “User Rights to Access a Server from the Network” in Appendix B.

The client is capable of making contact with a NetWare server. This will happen if the NetWare software is installed correctly and is running on both the client and the NetWare server. Correct installation includes correct choice of frame types (802.2 versus 802.3) — these must match between the client and the server. Also, any IPX routers between the client and NetWare server must be configured to allow the client’s SAP queries to flow; this is how the client finds the NetWare server. Specifically, IPX routers must propagate sockets 84C8 and 84C9 to support the communication needed by SNA servers and clients.

In addition, for NetWare version 4.0, on the client, the bindery emulation service must be running (for support required by SNA Server software). For more information about the NetWare software, see the NetWare documentation.

The NetWare server that the client first contacts contains the needed information about SNA servers. This will happen if both the SNA Server client and server have been installed correctly.

As indicated in the example in Figure A.4, to use IPX/SPX correctly, the client must have the Novell NetWare (IPX/SPX) option selected. (On a client running Windows 3.x or MS-DOS, the dialog box or screen for this selection is called Client/Server Protocols. On a client running Windows NT, the dialog box is called Select Client/Server Protocols.)

In addition, if the Network Domain Name dialog box or screen appears (see Figure A.5), the correct domain name must be specified. The name ensures that the client’s request for information can be matched with the NetWare server’s bindery information about SNA servers. Otherwise, the process diagrammed in Figure A.8 cannot complete, and the client cannot receive the name of an SNA server.


Clients Using Banyan VINES IP
Network Protocols and Client-Server Communication	14 of 16

Details About How Clients Use Protocols

Clients Using Banyan VINES IP

An SNA Server client using Banyan VINES relies on the VINES StreetTalk naming services for information about resources on the network. Therefore, such a client goes through several steps in the process of requesting a session through an SNA server. Figure A.9 shows the process.

Figure A.9    VINES Client Requesting Initial SNA Session

As Figure A.9 shows, at startup time, the SNA server registers its name with the StreetTalk service on one or more VINES servers. Sometime later, a client requests an initial SNA session by sending the request to a VINES StreetTalk server. In response, the VINES server sends the client the names of the SNA servers (from the list in StreetTalk). The client then selects a name at random and sends its request to that SNA server.

The first SNA server contacted by the client provides the “sponsor connection” for the client. The “sponsor” SNA server provides the client with the names of all the SNA servers in the domain, and then the client tries SNA servers at random until the necessary LU or pool is located. For a diagram of the sponsor-connection process, see Figure A.7. Subsequent SNA requests from the client use the same sponsor connection. In other words, the process of locating the first SNA server is not repeated unless the SnaBase (a basic software component) on the client is stopped and restarted.

StreetTalk Naming System

When you install SNA Server software on a computer for which the networking software is Banyan VINES (and not Microsoft networking), SNA Server Setup creates a StreetTalk name for the computer. Setup does this by combining information stored on the Banyan VINES network with the network domain name and StreetTalk group name that you supply (in the appropriate dialog boxes). In order to run SNA Server Setup on such a computer, you must be logged on to the VINES network (the BAN.EXE program allows you to do this) and you must have administrative rights.

A StreetTalk name consists of three parts (identifying the item, group, and organization) with an @ sign between the parts: item@group@organization. For the first part (item), SNA Server Setup automatically uses the local computer name. The last two parts together (group@organization) are called the StreetTalk group name. SNA Server Setup allows you to type this two-part group name into the StreetTalk Group Name dialog box. If you leave this box blank, Setup uses the group name of the user currently logged on in the Banyan VINES network.

After you type the necessary names into Setup, SNA Server establishes communication on the Banyan VINES network; in Banyan VINES terminology, SNA Server creates a PC-based service through which it is represented to the Banyan VINES network. After this is accomplished, SNA Server creates a StreetTalk list, using the domain name that you typed into the Network Domain Name dialog box. All the SNA servers in a particular Windows NT domain add their names to the list on each of the servers; this identifies all the SNA servers to each other. Clients also use this list to locate the servers in their group.

Note

One important step for success with SNA Server and VINES is to ensure that all the servers and clients that will work together have the same StreetTalk group name. If you type the group name into the StreetTalk Group Name dialog box, type that same name for all the servers and clients. If you use the default, make sure that the group name of the user logged on in the Banyan VINES network during installation of SNA Server is always the same group name, regardless of whether client or server software is being installed.

Carrying out installation in this way ensures that the process illustrated in Figure A.9 will complete correctly.

Checklist for Clients Using Banyan VINES IP

Figures A.1 and A.9 indicate that certain conditions must be met before a client using Banyan VINES will be able to locate an SNA server. When these conditions aren’t met, on the client, error messages 629 and/or 546 occur, and no SNA sessions will be established. Error 629 indicates that the client is not able to contact the VINES server and/or obtain names of SNA servers; error 546 naturally follows, because it indicates that the client was unable to establish a sponsor connection.

When troubleshooting errors 629 and 546, check that all of the following conditions have been met:

The VINES server software is properly installed. (Note that the VINES server cannot be the same computer as the SNA server.)

The VINES server is running, so that StreetTalk services are available.

The SNA server has registered its name with StreetTalk on the VINES server. This will happen if the following are true:

On the SNA server, the VINES workstation software has been installed correctly.

For information about installing VINES software, see the VINES documentation.

On the SNA server, the VINES workstation software has been started and a VINES network logon has completed successfully.

To view or change the startup setting for the VINES workstation, in the Control Panel, double-click the Services icon. In the list of services, select VinesWorkstation. The startup setting is listed under Startup; to change the setting, choose the Startup button.

The SNA Server software has been installed by an administrator who has an account with administrative rights on the VINES server.

If the SNA server depends on a VINES “routing server” to forward requests to the VINES StreetTalk server, the routing server is set up to correctly forward those requests. Note that if you can log on to the VINES network from the SNA servers, the VINES routing servers are supporting communication correctly.

The SNA Server software is properly installed to work with VINES.

In order for SNA Server to work with VINES, during Setup, the Banyan VINES option must be selected in the Select Client/Server Protocols dialog box (Figure A.2).

In addition, if the options selected in the Select Client/Server Protocols dialog box do not include Microsoft Networking (Named Pipes), the Network Domain Name and StreetTalk Group Name dialog boxes each appear; the Network Domain Name dialog box is shown in Figure A.3. The correct names must be typed in these dialog boxes (if they appear); the names ensure that the SNA server registers the correct name with the VINES server. If this happens, that VINES server will be able to direct VINES clients to the SNA server. For a diagram of this process, see Figure A.9.

The logged-on user has sufficient user rights to access the SNA server across the network. These rights are controlled through the Windows NT User Manager, not SNA Server. For more information, see “User Rights to Access a Server from the Network” in Appendix B.

The client is capable of making contact with a VINES StreetTalk server. This requires the VINES software to be installed correctly and running on both the client and the VINES server. It also requires correct configuration of any VINES “routing servers” between the client and the VINES StreetTalk server, so that client requests reach the StreetTalk server. Note that if you can log on to the VINES network from the SNA clients, the VINES routing servers are supporting communication correctly.

For information about the VINES software, see the VINES documentation.

The VINES server that the client first contacts contains the needed information about SNA servers. This will happen if both the SNA Server client and server have been installed correctly.

To use VINES correctly, the client must have the Banyan VINES IP option selected in the appropriate Setup dialog box. (On a client running Windows 3.x or MS-DOS, the dialog box or screen for this selection is called Client/Server Protocols, and is shown in Figure A.4. On a client running Windows NT, the dialog box is called Select Client/Server Protocols.)

In addition, if the Network Domain Name (Figure A.5) and StreetTalk Group Name dialog boxes each appear, the correct names must be specified. The names ensure that the client’s request for information can be matched with the VINES server’s StreetTalk listings of SNA servers. Otherwise, the process diagrammed in Figure A.9 cannot complete, and the client cannot receive the name of an SNA server.


Clients Using TCP/IP
Network Protocols and Client-Server Communication	15 of 16

Details About How Clients Use Protocols

Clients Using TCP/IP

SNA Server clients running a version of Windows NT (such as Windows NT Workstation version 3.5) or a version of Windows 3.x (such as Windows version 3.1) can use TCP/IP as the client-server protocol. (Clients running MS-DOS or OS/2 cannot use TCP/IP to communicate with SNA servers.) The version of TCP/IP used on an SNA Server client must be either Microsoft TCP/IP or an equivalent Windows Sockets version 1.1 interface.

Clients using TCP/IP, like all SNA Server clients, use the sponsor-connection process in order to locate an SNA server that has the LU(s) or LU pool(s) needed by the client. This process is diagrammed in Figure A.7. Because clients use this process, they need to locate only one SNA server. After this server is located, it provides the client with all necessary information about other SNA servers in the domain.

Note

If the client has TCP/IP installed, and the Client/Server Protocols dialog box appears, be sure to select TCP/IP. For such a client, if Microsoft Networking (Named Pipes) is selected instead of TCP/IP, the client will communicate through named pipes over TCP/IP, a protocol combination that does not recover from error conditions as effectively as native TCP/IP.

Note that all SNA users must be given sufficient user rights on SNA servers to access the servers across the network. These rights are controlled through the Windows NT User Manager, not SNA Server. For more information, see “User Rights to Access a Server from the Network” in Appendix B.

Note

The remainder of this section requires a basic understanding of how TCP/IP handles names and addresses; this background information is available in your TCP/IP documentation.

An SNA Server client using TCP/IP uses standard TCP/IP methods to locate an SNA server: through broadcasting, through IP addresses, or through names that are translated into addresses by standard mechanisms (such as a HOSTS file or through the Domain Name System, DNS). For an SNA Server client that uses TCP/IP, you control the method that a client uses to locate SNA servers (through broadcast, address, or name) by controlling the information in the SNA Client Mode dialog box or the SNA Server Location dialog box (part of client Setup). The following sections provide recommendations about what to type in this dialog box for a client that uses TCP/IP.

Note that before attempting to establish communication involving SNA Server software, you can use the TCP/IP utility called ping to verify that contact can be established between client and server. This can help you identify basic TCP/IP problems, such as difficulties with name resolution or with routers. For information about the ping utility, see your TCP/IP documentation.

Important

The following section supersedes the corresponding printed documentation for SNA Server Client Setup, and provides important information about what to type in the SNA Client Mode or SNA Server Location dialog box on a client that uses TCP/IP.

For important information about setting up TCP/IP on an SNA server, see “Setting Up TCP/IP for Client-Server Communication” in Chapter 2 of this guide.

Specifying Local or Remote Client Information with TCP/IP

This section focuses on the information that you enter into the SNA Client Mode dialog box or the SNA Server Location dialog box during SNA Server Client Setup. This dialog box is illustrated in Figure A.6, in “Important Setup Options on a Client,” earlier in this appendix.

In order for a client to use TCP/IP, if the Client/Server Protocols dialog box (Figure A.4) appears during Setup, the TCP/IP option must be selected. In addition, the correct information must be specified in the SNA Client Mode dialog box or the SNA Server Location dialog box (Figure A.6). The information that you type into this dialog box affects the method that the client uses for locating an SNA server, as shown in Table A.3.

Table A.3    How a Client Using TCP/IP Locates an SNA Server

Information specified in SNA Client Mode dialog box or SNA Server Location dialog box (in client Setup)	Method client uses to locate SNA server	Advantages and disadvantages
Select Local Domain, and then, in the Network Domain Name dialog box, specify the name of the Windows NT domain that contains the SNA servers.	Broadcasts in the Windows NT domain	Advantages: Configuration is relatively simple. Disadvantages: As with any broadcasting on a TCP/IP network, the broadcasts may add significantly to the network load, and will not be forwarded across routers. Clients using this method will not be able to locate servers if all servers are on the other side of a router.
Select Remote Domain, and then specify one or more “host names” (that is, computer names), each including the TCP domain name (separate multiple names with spaces). For example, you could type  srv1.bldg1.com  srv2.bldg2.com	Translation of name(s) into IP address(es) by standard TCP/IP methods, such as a HOSTS file or through DNS	Advantages: The names are relatively simple (compared to IP addresses), resulting in fewer typing errors. Few if any broadcasts are needed (just those required for a DNS server to function). Client requests go directly to an SNA server. Disadvantages: As with any use of names on a TCP/IP network, the method for translating the name into an address must be set up correctly. For example, the HOSTS file or DNS must be set up correctly. With DNS servers, any routers between the client and the DNS servers must be configured appropriately. In addition, if none of the specified SNA servers is running when the client makes a request, the request will not be supported, even if other SNA servers are running in the domain at that time.
Select Remote Domain, and then specify one or more computer names of SNA servers (separate multiple names with spaces). For example, you could type  server1  server2  server3	Translation of  name(s) into IP address(es) through  an LMHOSTS file  or through a WINS server	Advantages: The names are relatively simple, resulting in fewer typing errors. Few if any broadcasts are needed (just those required for a WINS server to function). Client requests go directly to an SNA server. Disadvantages: As with any use of names on a TCP/IP network, the method for translating the name into an address must be set up correctly. That is, the LMHOSTS file or WINS server must be set up correctly. With WINS servers, any routers between the client and the WINS servers must be configured appropriately. In addition, if none of the specified SNA servers is running when the client makes a request, the request will not be supported, even if other SNA servers are running in the domain at that time.
Select Remote Domain, and then specify one or more IP addresses (separate multiple addresses with spaces). For example, you could type  11.123.45.67  11.123.45.68	IP address	Advantages: No broadcasts are used, minimizing network load. Client requests go directly to an SNA server. There is no need for translation of names into addresses (for example, DNS or WINS servers are not needed). Disadvantages: Addresses are difficult to remember; errors may occur when typing. In addition, if none of the specified SNA servers is running when the client makes a request, the request will not be supported, even if other SNA servers are running in the domain at that time.
The preceding table is the basis for the following recommendations for clients using TCP/IP.

Recommendations for Local or Remote Client Information for TCP/IP

The following recommendations for clients using TCP/IP can help you decide what name to specify in the SNA Client Mode dialog box or the SNA Server Location dialog box in Setup. The reasons for the recommendations are listed in the preceding table. The dialog box is shown in Figure A.6 and described in the preceding section.

In the dialog box, select Local Domain only if the clients are located on the same side of routers as most of the servers are, and if additional broadcast traffic will not cause difficulties on the network.

If clients and servers are located on opposite sides of routers, select Remote Domain and type either host names (that is, computer names, with or without TCP domain names) or IP addresses. If possible, type more than one name or address on each client; separate multiple names or addresses with spaces. Typing multiple names or addresses gives the client multiple chances of finding a functioning SNA server at any given time. In contrast, typing one name or address means that the specified SNA server must be functioning when the client makes a request, or the client will not receive SNA session support (even if other SNA servers are functioning at that time).

For example, if using multiple names that include TCP domain names, you could type

server1.location.com  server2.location.com  server3.location.com

If you use names, as with any other situation involving names over TCP/IP, you must make sure that some method is available to resolve the names into addresses. Examples of such methods are the HOSTS file (on the client), DNS servers, and WINS servers. For important information about how these methods work, see your TCP/IP documentation.


Clients Using AppleTalk
Network Protocols and Client-Server Communication	16 of 16

Details About How Clients Use Protocols

Clients Using AppleTalk

A computer running the Macintosh operating system (with the AppleTalk networking software) can communicate with SNA servers that are running Services for Macintosh (part of the Windows NT Server software). To install Services for Macintosh, see Microsoft Windows NT Server Services for Macintosh, or the online equivalent, MAC.HLP, on the Windows NT CD.

Note that the SNA client software for the Macintosh is included within most Macintosh emulators (and does not require separate installation). Before installing emulators on Macintosh clients, prepare the SNA server(s) to support these clients. To do this, first carry out the steps in the Microsoft SNA Server Installation Guide (the section to read is “Preparing an SNA Server to Support Macintosh Clients,” in Chapter 2). Then, start SNA Server Setup and choose the Protocols button; next, in the Select Client/Server Protocols dialog box, make sure AppleTalk is selected.

When you are ready to install emulators on the Macintosh clients, you will need to know the Windows NT domain and the AppleTalk zone of the SNA servers. Macintosh clients locate the SNA server through the domain name and zone name of the SNA servers.


Interpreting Events or Errors on SNA Servers or Clients
Appendix B	1 of 8

Interpreting Events or Errors on SNA Servers or Clients

Event logs and error messages provide invaluable information about events and problems on SNA servers and clients. On SNA servers, event logs can be used alone or with other diagnostic and monitoring tools. For example, you can designate certain events to be forwarded to a host console via NVAlert, or you can use Performance Monitor data or tracing to help pinpoint the cause of an error condition. The full range of diagnostic tools are described in Chapter 13 of the Microsoft SNA Server Administration Guide. In addition, Performance Monitor is described in this guide in Chapter 3, “Basic Methods for Evaluating Hardware Requirements.”

Note

If you are troubleshooting a connection or SNA server that won’t start (won’t reach Active status, as viewed from SNA Server Admin), be sure to consult Chapter 4, “Establishing a Connection Successfully.” Note that an SNA server will not start if it has a link service installed on a nonfunctioning adapter (even if that link service is not in use by any connection). All link services must be able to start before the SNA server can start.

On an SNA server or Windows NT – based client, events (also called error messages) are viewed through the Event Viewer. On a client running Windows version 3.x, OS/2, or MS-DOS, error messages are displayed on the command line or in pop-up boxes.

This appendix describes some common events and errors that occur on SNA servers and clients, and offers suggestions for troubleshooting them. The events described are as follows:

SNA servers only: Application log, event 23, with a Source of SNA Server. This reports the failure of a connection and/or link service.

SNA servers only: Application log, event 182, with a Source of SNA Server. This occurs on SDLC connections, and reports the inability of the server to establish communication with the mainframe or AS/400. This is often the result of incorrectly configured identifiers (XIDs), such as the Remote Node ID (or the Remote Node Network Name and Control Point Name). These identifiers are described in Chapter 4, “Establishing a Connection Successfully.”

SNA servers only: Application log, event 230, with a Source of SNA Server. This occurs only on 802.2 connections, and reports the inability of the server to establish communication with the mainframe or AS/400. This is often the result of an incorrectly configured  address or identifier (XID), such as the Remote Network Address, the Remote Node ID, or the Remote Node Network Name and Control Point Name. The address and identifiers are described in Chapter 4, “Establishing a Connection Successfully.”

SNA servers only: System log, event 2001, with a Source of Srv. This is a relatively unusual event, and reports a shortage of internal server resources. The event includes codes that contain important information, but interpreting the codes may require the support of a software technician. Be sure to save the System event log that contains this event for later reference, and make the log available to software support technicians if you request product support. To save a log, in Event Viewer, while the log is displayed, open the Log menu and choose Save As. The Save As dialog box allows you to specify a path and file name for the log. The default extension for event logs is EVT.

Clients only: Error message 546, reporting the inability of the client to find an SNA server and establish a sponsor connection. This error may be preceded by error 629, reporting that the client was unable to obtain needed information about SNA servers. (With NetWare or VINES, error 629 indicates that the client could not complete the preliminary step of obtaining SNA server names from the NetWare or VINES server.) Troubleshooting for this is covered in detail in Appendix A, “Network Protocols and Client-Server Communication.”

On SNA servers, events are recorded in the Application log. To view this log from within Event Viewer, from the Log menu, choose Application. Then, to find events related to SNA Server, look under the Source heading and find names starting with SNA. To view detail about an event, double-click the event. For more information about using the Windows NT Event Viewer, see your Windows NT documentation.

For a listing of SNA Server event numbers, names, and descriptions, see the Microsoft SNA Server Reference.

The following sections describe the events/errors in the previous list.


Event 23 on an SNA Server
Interpreting Events or Errors on SNA Servers or Clients	2 of 8

Event 23 on an SNA Server

Event text:	Connection value using Link Service value failed 	Qualifier = value

In order to interpret event 23 on an SNA server, be sure to note what return code is listed as a Qualifier. For a list of all return codes, see Message 23 in the Microsoft SNA Server Reference. The following list shows the common return codes and their usual causes.

For SDLC connections:	X'11'  Data Set Ready (DSR) failure.

Some causes of this code are as follows:

The modem is disconnected.

The host system dropped the line.

The exchange ID (XID) for the connection specifies a PU that is in use, inactivated, or invalid. Check with the host administrator regarding the PU.

The front-end processor (FEP) went down.

VTAM is stopped (for example, during weekend maintenance).

For token ring connections:	X'29'  Remote node not active.

This may indicate that the exchange ID (XID) for the connection specifies a PU that is inactivated. Check to see if the host administrator needs to activate the PU.

For token ring connections:	X'AE'  DISC/DM received.

This code indicates that the connection timed out or was dropped, perhaps because the mainframe or AS/400 was busy. Repeated occurrence of this event may indicate that the Response (t1) Timeout, the Receive ACK (t2) Timeout, and the Inactivity (ti) Timeout are set too low on the SNA server. (For descriptions of these timeouts, see the Microsoft SNA Server Administration Guide or the SNA Server Admin Help.) This code may also indicate an underlying LAN problem.

With an AS/400, this return code may indicate that the setting for switched disconnect (SWTDSC) is *YES, and no users have been active for a period of time; in this situation, the AS/400 will automatically disconnect.

For token ring connections:	X'AF'  Link lost.

This code indicates that the physical connection was lost, possibly because of a router problem or another underlying LAN problem.

For token ring connections:	X'AC'  FRMR sent.

Or	X'AD'  FRMR received.

These two codes both indicate that one or more frames were never acknowledged. This can happen when a router drops a packet. The codes may indicate some kind of router problem.

For X.25 connections:	X'61'  The permanent virtual circuit to the host has been reset (broken) either by the host or by the X.25 network itself.

Or	X'62'  An attempt to connect to the host through a switched virtual circuit has failed.

This code may indicate a mistake in the identifiers (IDs or names) and/or the X.25 address for the connection. To view these settings in SNA Server Admin, double-click the connection and then choose the Setup button. For more information about identifiers, see “Settings to Check on All Connections” in Chapter 4. For more information about the Remote X.25 Address, see “X.25 Connections: Configuration Pointers” in Chapter 4.

Alternatively, with a mainframe connection, this code may indicate that the XID type specified in SNA Server Admin is incorrect. To view this setting, double-click the connection, then choose the Setup button, and finally choose the Advanced button. Check with the host administrator regarding the XID type (Format 0 or Format 3) that can be accepted by the host.


Event 182 on an SNA Server
Interpreting Events or Errors on SNA Servers or Clients	3 of 8

Event 182 on an SNA Server

Event text:	Connection failure, code = value

Event 182 is similar to event 23 except that it occurs on SDLC connections on SNA servers. In order to interpret event 182 on an SNA server, be sure to note the return code in the first line of the event. The preceding section lists the most common return code, X'11', and its usual causes. For a list of all return codes, see Message 23 in the Microsoft SNA Server Reference.


Event 230 on an SNA Server
Interpreting Events or Errors on SNA Servers or Clients	4 of 8

Event 230 on an SNA Server

Event text:	Remote station not responding to qualifier commands

Event 230 occurs only on 802.2 connections on SNA servers. This event indicates that the remote station is not answering TEST or exchange-identifier (XID) frames. A probable cause is a mistake in the identifiers (IDs or names) and/or address for the connection. To view these settings in SNA Server Admin, double-click the connection and then choose the Setup button. Another possible cause is a router problem that prevents the router from passing DLC frames through to the specified remote address.

If the remote station is not responding to XID commands, check the identifiers (IDs or names) used in SNA Server Admin. These identifiers must match the corresponding parameters on the mainframe or AS/400. For more information about identifiers, see “Settings to Check on All Connections” in Chapter 4.

If the remote station is not responding to TEST commands, check the Remote Network Address used in SNA Server Admin. The address must match the corresponding address on the mainframe or AS/400. For more information about the Remote Network Address, see “802.2 Connections: Configuration Pointers” in Chapter 4.


Event 2001 on an SNA Server
Interpreting Events or Errors on SNA Servers or Clients	5 of 8

Event 2001 on an SNA Server

Error text:	The server was unable to perform an operation due to a shortage of available resources.

This relatively unusual event is recorded in the System event log; the Source is listed as Srv. The event reports a shortage of resources, such as the maximum number of receive buffers that the server can allocate (this number can be increased through the Windows NT Registry). When this event occurs, it contains hexadecimal data that is valuable to software support technicians. Be sure to save the System event log that contains this event for later reference, and make the log available to software support technicians if you request product support.

To save a log, in Event Viewer, while the log is displayed, open the Log menu and choose Save As. The Save As dialog box allows you to specify a path and file name for the log. The default extension for event logs is EVT.


Error Message 546 on a Client
Interpreting Events or Errors on SNA Servers or Clients	6 of 8

Error Message 546 on a Client

Error text:	SNA Server Error: 546  Cannot establish connection with SNA Server servername.

This error occurs only on clients. Possible causes of this error are as follows:

The client cannot find an SNA server in the domain, or cannot establish a sponsor connection to an SNA server.

For this situation, check to see if the client also receives error 629. For NetWare or VINES clients, the presence or absence of error 629 is especially important information. With NetWare or VINES, error 629 indicates that the client could not complete the preliminary step of obtaining SNA server names from the NetWare or VINES server. If error 629 does not occur with 546, NetWare or VINES clients are obtaining SNA server names, but cannot contact the SNA servers (perhaps the SNA servers have gone down or there is some kind of router or LAN problem).

For detailed information to help you troubleshoot such situations, see Appendix A, “Network Protocols and Client-Server Communication.” Appendix A includes sections that discuss clients running each type of network software (Microsoft networking, Novell NetWare, Banyan VINES, TCP/IP, and AppleTalk), as well as clients running Windows for Workgroups. Consult the section(s) that apply to your clients.

The logged-on user does not have the right to access SNA servers over the LAN.

For related troubleshooting information for Windows for Workgroups, see “Domain and Password Settings for Clients Running Windows for Workgroups” in Appendix A. For related troubleshooting information for all client operating systems, see the next section.

The client computer does not have enough free conventional memory, and the SnaBase (also called the NAP or WNAP) runs out of memory.

For information about troubleshooting this, see “Memory Problems on Client Systems,” later in this appendix.


User Rights to Access a Server from the Network
Interpreting Events or Errors on SNA Servers or Clients	7 of 8

Error Message 546 on a Client

User Rights to Access a Server from the Network

In order for SNA users to access SNA servers, they must have a basic user right on the SNA servers. This right is called “Access this computer from network.” If this right is unavailable to a user (or to a group that the user is in), the user will not be able to access the SNA server in any way, including viewing any shared directories on the server.

Note

This section applies to client systems running any operating system; for client systems running Windows for Workgroups, also see “Domain and Password Settings for Clients Running Windows for Workgroups” in Appendix A.

Note that if the client computer is running Microsoft networking, a brief test will tell you if the user has the correct access rights on the SNA server. To run the test, have the user try to connect to a shared directory on the SNA server. Start by sharing a directory on the server and giving Everyone Read permission to it; next, have the user log on to the domain; finally, have the user try to make a connection to the SNA server.

Use the following procedure to ensure that users have the correct user rights.

To ensure that a user has the right to access SNA servers from the network

1.	On an SNA server, double-click the icon for User Manager for Domains, located by default in the Administrative Tools group.

User Manager appears.

2.	From the Policies menu, choose User Rights.

The User Rights Policy dialog box appears.

3.	From the list labeled Right, select “Access this computer from network.”

Under Grant To, the list of users who have that right appears. The list should include the user you are interested in, or a group to which the user belongs.

4.	To add a user or group, choose the Add button and use the Add Users and Groups dialog box.

The Add Users and Groups dialog box works as it does in other contexts: you select a user or group, then choose the Add button, and finally choose OK.

5.	In the User Rights Policy dialog box, choose OK.

6.	On other SNA servers in the domain, repeat the procedure to ensure that all SNA users can access the servers.


Memory Problems on Client Systems
Interpreting Events or Errors on SNA Servers or Clients	8 of 8

Error Message 546 on a Client

Memory Problems on Client Systems

If a client computer does not have enough free conventional memory (memory located within the first megabyte, not extended memory), the SnaBase, also called the NAP or WNAP, may run out of memory. Symptoms of this include error 546, “Out of memory” errors, software stoppage (hangs), and the inability of the client to maintain a connection with the SNA server.

For information about troubleshooting problems other than memory problems on clients, see “Error Message 546 on a Client” earlier in this appendix, as well as Appendix A, “Network Protocols and Client-Server Communication.”

The following suggestions may help you free more conventional memory on client computers running Windows version 3.x, Windows for Workgroups, or MS-DOS.

Memory tuning on clients running Windows version 3.x

On a client running Windows version 3.x, the SnaBase (also called WNAP) will reserve enough memory buffers to handle connections through several SNA servers. If the client connects to only one SNA server, you can decrease the amount of reserved memory (increasing the amount of free memory). To do this, add the following entry to the [wnap] section of WIN.INI on the client:

maxpipes=6

This entry is used to determine the number of communication buffers that the SNA client software will allocate, regardless of whether the client uses Microsoft networking, IPX/SPX, Banyan VINES, or TCP/IP. To put this change into effect, stop and restart the SnaBase (the WNAP icon).

Further conventional memory can also be made available by removing any unnecessary drivers or terminate-and-stay-resident (TSR) software from the configuration, and maximizing the use of available upper memory blocks if MS-DOS 5.0 (or greater) is being used. For more information about these topics, see your MS-DOS documentation, or the documentation for drivers or TSR software.

Memory tuning on clients running Windows for Workgroups version 3.11

If Network Dynamic Data Exchange (DDE) is not being used, it can be disabled, which will free a significant amount of conventional memory. To disable it, first double-click the Control Panel icon, then double-click the Network icon. Next, in the Microsoft Windows Network dialog box, choose the Startup button. Finally, in the Startup Settings dialog box, under Startup Options, clear Enable Network DDE. Close all dialog boxes by choosing OK. To put this change into effect, restart the client computer.

Further conventional memory can also be made available by removing any unnecessary drivers or terminate-and-stay-resident (TSR) software from the configuration, and maximizing the use of available upper memory blocks if MS-DOS version 5.0 (or later) is being used. For more information about these topics, see your MS-DOS documentation, or the documentation for drivers or TSR software.

Memory tuning on clients running MS-DOS

On clients running MS-DOS, there are several ways to free conventional memory. One way is to remove any unnecessary drivers or terminate-and-stay-resident (TSR) software from the configuration. Another way is to maximize the use of available upper memory blocks if MS-DOS version 5.0 (or later) is being used. For more information about these topics, see your MS-DOS documentation, or the documentation for drivers or TSR software.


Options for Maximizing Communications Throughput
Appendix C	1 of 3

Options for Maximizing Communications Throughput

This appendix describes several options that you can check or set on SNA servers in order to maximize communications throughput. These options are recommended only on servers used mainly for communications; other servers (such as file servers) may require that other throughput (such as file-sharing throughput) be maximized instead. Servers used mainly for communications are servers on which most of the processing time goes to SNA Server, Microsoft SQL Server, Remote Access Service, or similar programs.

To study the effects of changing these options on a particular server, use Performance Monitor before and after the change. For some suggestions about using Performance Monitor, see Chapter 3, “Basic Methods for Evaluating Hardware Requirements.”


Maximizing Throughput on SNA Servers
Options for Maximizing Communications Throughput	2 of 3

Maximizing Throughput on SNA Servers

Servers used primarily for communications need to provide fast throughput, but don’t need to provide fast file access (as a file server would). Faster throughput will result if portions of memory are set aside for communications programs (such as SNA Server or Microsoft SQL Server). Such dedicated memory includes “nonpaged memory,” or portions of memory that are never swapped to disk, but remain available for immediate use at all times; this helps support fast throughput. Of course, if more memory is dedicated to SNA Server or similar programs, less memory is available for file-sharing (that is, for the Server service within Windows NT).

With Windows NT, you can view or change network throughput options, as described in the following procedure. For an SNA server, you may not need to change the throughput option, because SNA Server Setup automatically sets the option to maximize throughput for network applications.

To view or change throughput options (for a server used primarily for communications)

1.	From the Control Panel, double-click the Network icon.

The Network Settings dialog box appears.

2.	From the list under Installed Network Software, select Server.

3.	Choose the Configure button.

The Server dialog box appears:

Server Dialog Box

4.	For a server dedicated to communications, under Optimization, make sure that Maximize Throughput for Network Applications is selected.

5.	Choose OK, and then choose OK again.

If you made a change, the Network Settings Change dialog box appears. To put the changes into effect right away, choose Restart Now. To put the changes into effect later (at next startup), choose Don’t Restart Now.

For an additional way to tune a server used for communications, see the next section.


Optimizing Background Processing on SNA Servers
Options for Maximizing Communications Throughput	3 of 3

Optimizing Background Processing on SNA Servers

SNA servers used primarily for communications run many important background processes (processes not related to user actions in the current window). These servers generally do not need to run foreground processes at maximum speed. Therefore, SNA Server throughput can be increased by making the operating system more responsive to background processes and somewhat less responsive to foreground processes.

As would be expected, a server that is less responsive to foreground processes will run local applications (such as word-processing software, spreadsheets, or SNA Server Admin) more slowly. Therefore, the following procedure is most appropriate for servers used primarily to support clients, and not servers used locally as desktop computers.

To optimize background processing (for a server used primarily for communications)

1.	From the Control Panel, double-click the System icon.

The System dialog box appears.

2.	Choose the Tasking button.

The Tasking dialog box appears:

Tasking Dialog Box

3.	Under Foreground/Background Responsiveness, select Foreground and Background Applications Equally Responsive.

4.	Choose OK, and then choose OK again.

For an additional way to tune a server used for communications, see the preceding section.