home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Encyclopedia 96-1
/
novell-nsepro-1996-1-cd2.iso
/
download
/
netware
/
os2dc1.exe
/
ENGLISH
/
OS2BOOK.INF
(
.txt
)
next >
Wrap
OS/2 Help File
|
1994-10-07
|
641KB
|
10,307 lines
ΓòÉΓòÉΓòÉ 1. READ ME FIRST ! ΓòÉΓòÉΓòÉ
We Need Your Comments
This online version of the NetWare Client for OS/2 User Guide is a new product
from Novell's Technical Publications Department.
Please give us your comments. Print this page and FAX or mail it to:
Novell, Inc.
Technical Publications
MS C-23-1
122 East 1700 South
Provo, UT 84606
FAX (801) 429-3002
How useful are the following resources in answering your questions about the
setup or configuration of the NetWare Client for OS/2?
Least Useful Most Useful
1 2 3 4 6 7 8 9 10 The hardcopy NetWare Client for OS/2 User
Guide.
1 2 3 4 6 7 8 9 10 This online NetWare Client for OS/2 User
Guide in native OS/2 format.
1 2 3 4 6 7 8 9 10 ElectroText(TM) (Novell's online
documentation in MS Windows format)
1 2 3 4 6 7 8 9 10 The Help screens for the various utilites
(i.e. NWADMIN, NWTOOLS, INSTALL)
Please comment on whether you like this online NetWare Client for OS/2 User
Guide and how you would like to see it improved.
ΓòÉΓòÉΓòÉ 2. NetWare Client for OS/2 User Guide ΓòÉΓòÉΓòÉ
NetWare Client for OS/2 User Guide
Disclaimer
Novell, Inc. makes no representations or warranties with respect to the
contents or use of this manual, and specifically disclaims any express or
implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make
changes to its content, at any time, without obligation to notify any person or
entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to
any NetWare software, and specifically disclaims any express or implied
warranties of merchantability or fitness for any particular purpose. Further,
Novell, Inc. reserves the right to make changes to any and all parts of NetWare
software, at any time, without any obligation to notify any person or entity of
such changes.
Trademarks Novell, Inc. has made every effort to supply trademark information
about company names, products, and services mentioned in this manual. The
following list of trademarks was derived from various sources.
NetWare and Novell are registered trademarks of Novell, Inc.
Internetwork Packet Exchange (IPX), LAN WorkPlace, MLID, NE1000, NE2000,
NetWare Client, NetWare Core Protocol (NCP), NetWare Directory Services
(NDS), NetWare Tools, Open Data-Link Interface (ODI), Packet Burst, SFT
III, SPX, and Technical Support Alliance (TSA) are trademarks of Novell,
Inc.
NetWire is a registered service mark of Novell, Inc.
UNIX is a registered trademark of UNIX System Laboratories, Inc., a wholly
owned subsidiary of Novell, Inc.
IBM and OS/2 are registered trademarks of International Business Machines
Corporation.
Copyright 1994 Novell, Inc. All rights reserved. No part of this publication
may be reporduced, photocopied, stored on a retrieval system, or transmitted
without the express written consent of the publisher.
NetWare Client for OS/2 User Guide
March 1994
ΓòÉΓòÉΓòÉ 3. Introduction ΓòÉΓòÉΓòÉ
Introduction
Topics
NetWare Client for OS/2 Features
Information for DOS Users Migrating to OS/2
NetWare 2 and 3 Users Upgrading to NetWare 4
ΓòÉΓòÉΓòÉ 3.1. NetWare Client for OS/2 Features ΓòÉΓòÉΓòÉ
NetWare Client for OS/2 Features
NetWare Client(TM) for OS/2 workstation software enables OS/2 workstations to
access NetWare servers. After you install NetWare Client for OS/2, you can
connect to a NetWare network and perform basic network tasks.
NetWare Client for OS/2
Γûá Supports both NetWare 3 and NetWare 4 servers.
Γûá Offers Remote Program Load (RPL) workstation access.
Γûá Supports SFTIII(TM) for both the client and SPX(TM).
Γûá Provides access for up to 9 parallel ports.
Γûá Supports OS/2, DOS/MS Windows private sessions, DOS/MS Windows global
sessions, VMBoot private sessions, and VMBoot global sessions for NetWare 3.
ΓòÉΓòÉΓòÉ 3.2. Information for DOS Users Migrating to OS/2 ΓòÉΓòÉΓòÉ
Information for DOS Users Migrating to OS/2
This section explains the basic differences between using NetWare from an OS/2
workstation and using NetWare from a DOS workstation.
ODI LAN Drivers
ODI LAN drivers used by NetWare Client for OS/2 serve the same purpose and
follow the same technical specifications as ODI LAN drivers used by NetWare
Client for DOS and MS Windows.
OS/2 ODI drivers have the same filenames as DOS ODI drivers, except they have a
.SYS extension instead of a .COM extension.
OS/2 ODI drivers are loaded in the CONFIG.SYS file, whereas the DOS ODI drivers
are loaded in the AUTOEXEC.BAT file.
Important For OS/2, network drivers and device drivers are always loaded in
CONFIG.SYS. AUTOEXEC.BAT is not used in OS/2.
IPX
NetWare Client for OS/2 uses the IPX protocol to connect to NetWare servers.
For OS/2, IPX is a .SYS file and is loaded in the CONFIG.SYS file with the
other NetWare drivers.
If you use virtual DOS sessions in OS/2, those sessions use a virtualized
version of IPX, called VIPX. VIPX talks to IPX to allow DOS sessions to
communicate on the network.
In a virtual DOS session, you run VIPX provided with NetWare Client for OS/2
rather than the IPX provided with NetWare Client for DOS and MS Windows.
When you install NetWare Client for OS/2, lines to load IPX and VIPX are loaded
automatically in CONFIG.SYS.
NET.CFG File
The NET.CFG file serves the same purpose under OS/2 as it does under DOS: it
allows you to configure your network connection.
NET.CFG for OS/2 has options and settings just as NET.CFG for DOS. However,
options and settings are somewhat different. Some of them use different syntax
and configure different software components.
Because of this, you cannot just copy NET.CFG from a DOS workstation to an OS/2
workstation and expect it to work. Instead, create a new NET.CFG file for the
OS/2 workstation if you have nondefault configurations.
In OS/2, NET.CFG is a text file that can be created or edited with the NetWare
Client for OS/2 installation program. This program contains online help showing
the syntax of all options. (NET.CFG can be edited with a text editor as well.)
You can put DOS and OS/2 NET.CFG options into the same NET.CFG file on your
OS/2 workstation. Then when you run a private virtual DOS session, NetWare
Client for DOS and MS Windows will use the DOS options. NetWare Client for OS/2
ignores the DOS options.
Logging In
When you boot your workstation, NetWare Client for OS/2 maps drive L: as the
default drive to the SYS:LOGIN directory (configurable in NET.CFG).
This mapping combines with the L:\OS2 mapping that the NetWare Client for OS/2
installation puts in your path, and gives you a search path to the login
utilities. (You don't have to change to drive L: to log in.)
NetWare Client for OS/2 does not support a LASTDRIVE setting in CONFIG.SYS.
You can log in from any OS/2 session or the desktop, and your login applies to
all other OS/2 sessions. For example, if you logged in from the command line of
an OS/2 session and then you went to the desktop and used NetWare Tools(TM),
you would already be logged in to the same location you logged in to at the
command line.
Important The attachment from NetWare Tools does not run a login script. To
execute a login script, run LOGIN from the command line.
You can also log in from virtual DOS sessions running on OS/2. You can set up
virtual sessions so that each session can support its own login to the network
(private sessions) or so that all sessions - including OS/2 - share a single
login to the network (global sessions).
Network support from virtual DOS sessions works much the same as network
support from regular DOS workstations. You use a NETX.EXE shell and a
virtualized version of IPX, called VIPX.SYS.
Important When logging in from virtual sessions, you do not have NetWare
Directory Services (NDS) support. This means that you can only log in to a
NetWare 4 network that has bindery emulation.
Utilities
NetWare utilities for OS/2 have the same names as NetWare utilities for DOS.
However, OS/2 utilities are different executable files than DOS utilities.
NetWare OS/2 utilities are in the SYS:PUBLIC\OS2 and SYS:LOGIN\OS2 directories
so they do not overlap with NetWare utilities for DOS in the SYS:PUBLIC and
SYS:LOGIN directories. If you run a NetWare DOS utility in OS/2, OS/2 will try
to start a DOS session to run that utility.
The following utility files are available from the NetWare Client for OS/2
diskettes:
Γûá CX.EXE
Γûá MAP.EXE
Γûá NETX.EXE
Γûá NLIST.EXE
Γûá NPRINTER.EXE
Drive Mappings and Search Drives
Search drives are not used in OS/2. Instead, the search functionality to
NetWare utilities and other programs is set up with PATH, LIBPATH, and DPATH
statements in CONFIG.SYS.
Mapping to Login Utilities
When you boot your workstation, NetWare Client for OS/2 connects to the first
server it finds and maps drive L: to the SYS:LOGIN directory (configurable in
NET.CFG).
This mapping combines with the L:\OS2 mapping that the NetWare Client for OS/2
installation puts in your path and gives you a search path to the login
utilities.
Once you log in, drive L: disappears.
Mapping to Public Utilities
The NetWare default login script for OS/2 contains the following line mapping
drive P: to public utilities:
MAP P:=SYS:PUBLIC
This mapping combines with the P:\OS2 mapping that the NetWare Client for OS/2
installation puts in your path and gives you a search path to the
SYS:PUBLIC\OS2 directory. When you type a utility name from any drive other
than drive P:, the utility from the \OS2 subdirectory is executed.
Important Even though your search path gets set to SYS:PUBLIC\OS2 by default,
drive P: stays mapped to SYS:PUBLIC.
If you change to drive P:, you are in SYS:PUBLIC, not SYS:PUBLIC\OS2. If you
type a utility name at drive P:, the DOS version of the utility is executed.
Other Protocols
NetWare Client for OS/2 provides support for the following protocols:
IPX
SPX
Named Pipes
NetBIOS
These protocols support OS/2 client workstations and servers on a distributed
application network. SPX supports some NetWare printing utilities.
DOS client workstations running DOS Named Pipes or NetBIOS can connect to OS/2
application servers running Named Pipes or NetBIOS.
You can select support for these protocols in the NetWare Client for OS/2
installation program. The protocols you select are loaded into CONFIG.SYS.
To access SPX, Named Pipes, and NetBIOS support from virtual DOS and MS
Windows sessions on OS/2, you must load some programs provided with NetWare
Client for OS/2.
ΓòÉΓòÉΓòÉ 3.3. NetWare 2 and 3 Users Upgrading to NetWare 4 ΓòÉΓòÉΓòÉ
NetWare 2 and 3 Users Upgrading to NetWare 4
Significant changes have been made in the following areas:
Γûá Default frame type for Ethernet ODI drivers
Γûá Selecting a preferred server
Γûá Logging in to the network
Γûá Login scripts
Γûá Mappings in the default login script
Γûá Mapping to the public utilities
Γûá Virtual DOS and MS Windows sessions
Default Frame Type for Ethernet ODI Drivers
The default frame type for Ethernet ODI drivers has changed. In NetWare 2 and
3, Ethernet drivers defaulted to the Ethernet 802.3 frame type. In NetWare 4,
they default to the Ethernet 802.2 frame type.
NetWare 4 server drivers for Ethernet also default to the Ethernet 802.2 frame
type. Servers and workstations use the same frame type to communicate with
each other.
Routers must also support the frame type or your workstation can't get a
connection. Some routers on your network may not support the Ethernet 802.2
frame type default.
Important If you use the Ethernet 802.2 frame type on your workstation, it
can't connect to a network expecting the Ethernet 802.3 frame type.
To eliminate a potential conflict, you can define both frame types (Ethernet
802.2 and Ethernet 802.3) on your network.
For the workstation, define frame types in NET.CFG. Include a line similar to
the following, replacing NE2000 with the name of your ODI driver:
link driver ne2000
frame ethernet_802.2
frame ethernet_802.3
The first frame type defined is the only one used for the initial "Get Nearest
Server" request.
Therefore, if some of your servers use only one frame type, such as Ethernet
802.3, put that frame type first. That way your workstation can make a default
connection to those servers.
Selecting a Preferred Server
NetWare Directory Services (NDS) provided in NetWare 4 uses trees and contexts
rather than servers to identify what you log in to.
A new NET.CFG setting called preferred tree has been created. Use preferred
tree in NetWare 4 the same way you used preferred server in NetWare 2 and 3
(except you specify a tree name rather than a server name).
Use preferred tree only for sites that have more than one Directory tree.
For example, to initially connect to a tree called Novell, add the following
lines in your NET.CFG file:
netware requester
preferred tree novell
Preferred server is still a supported setting; however, the syntax has
changed. You now type the word server as well as a server name. For example:
netware requester
preferred server fs1
Regardless of your NET.CFG file, NetWare Client for OS/2 first tries to
establish a default connection to an NDS server. This connection is made to
the first NDS server that responds.
If NetWare Client for OS/2 succeeds in connecting to an NDS server, it then
looks for a preferred tree. Once it connects to a preferred tree, it checks to
see if you have a preferred server specified. If that server is in the current
context, it connects to that server.
If NetWare Client for OS/2 can't connect to an NDS server, it tries to
establish a default connection to a bindery server.
If it connects to a bindery server, it first looks for a preferred server,
ignoring any preferred tree you specified.
Logging In to the Network
When you log in under NetWare 4, you log in to a Directory tree rather than a
server. This means you log in to a location in the Directory (called a
context) rather than to a server.
Logging in from the OS/2 Command Line
You use the NetWare 4 LOGIN utility to log in from a command line. This
utility is located in the SYS:LOGIN\OS2 directory.
With LOGIN, you can specify a context in the Directory tree. A context
includes a User object and an Organization object.
For example, to log in to a NetWare 4 network, type
LOGIN .JOHN.SALES_MKTG
JOHN is the User object. SALES_MKTG is the Organization object.
You can use the NetWare 4 LOGIN utility to log in to NetWare 3.1x servers. Use
the same login syntax you used for NetWare 3.1x LOGIN and add the /B option.
For example, type
LOGIN SALES_MKTG/NANCY /B
NetWare Tools Attach Feature
The attachment from NetWare Tools does not run a login script. You must run
LOGIN from the command line to execute a login script.
Mappings in Default Login Script
In NetWare 2 and 3, a default login script was executed if you had no other
login script.
In NetWare 4, the default login script still exists. Unless the network
supervisor specifies otherwise, using a parameter in the system login script,
it is executed when a user login script does not exist.
Also, search drives aren't used in OS/2. Instead, the search functionality to
the NetWare utilities and other programs is set up with PATH, LIBPATH, and
DPATH statements in CONFIG.SYS.
The NetWare 4 default login script contains the following line mapping drive
P: to the utilities:
MAP P:=SYS:PUBLIC
This mapping combines with the P:\OS2 mapping the NetWare Client for OS/2
installation puts in your path and gives you a search path to the
SYS:PUBLIC\OS2 directory.
When you execute a utility from any drive other than drive P:, the utility
from the \OS2 subdirectory is executed.
Important Even though your search path is set to SYS:PUBLIC\OS2 by default,
drive P: stays mapped to SYS:PUBLIC.
If you change to drive P:, you are in SYS:PUBLIC, not SYS:PUBLIC\OS2. If you
execute a utility at drive P:, the DOS version of the utility is executed.
Mapping to the Public Utilities
When setting up system or user login scripts for OS/2 users, always map drive
P: to SYS:PUBLIC, as shown:
MAP P:=SYS:PUBLIC
Why Drive P:
This mapping combines with the P:\OS2 directory the NetWare Client for OS/2
installation puts in your path. The combination gives you a search path to
SYS:PUBLIC\OS2.
If you use another mapping besides P:, that mapping will not combine with the
P:\OS2 directory that NetWare Client for OS/2 puts in your path, leaving you
without a search path to the utilities.
When you execute a utility from a drive other than drive P:, the utility from
the \OS2 subdirectory is executed.
Why SYS:PUBLIC and not SYS:PUBLIC\OS2
Important Do not map drive P: to SYS:PUBLIC\OS2.
The NetWare utilities for OS/2 need to find language-specific files in the
parent directory of the directory they are executed from.
For example, a utility executed from SYS:PUBLIC\OS2 expects to find an \NLS
subdirectory in SYS:PUBLIC.
If the drive allowing access to the utilities is mapped to SYS:PUBLIC\OS2,
that directory becomes the root of the drive, since all network drives mapped
in OS/2 are root drives.
This means that OS/2 doesn't recognize a parent directory for utilities. When
utilities try to locate the \NLS subdirectory in their own parent directory,
OS/2 returns an error and your utility won't run.
Important If you change to drive P:, you are in SYS:PUBLIC, not
SYS:PUBLIC\OS2. If you execute a utility from drive P:, the DOS version of the
utility is executed.
Login Scripts
The How To Edit Login Scripts for Each Type of Session table shows the login
script executed the type of login and how to edit the login script.
Login Script Commands Not Supported in OS/2
OS/2 login scripts do not support the following commands:
COMSPEC
DOS BREAK
MACHINE NAME
The following commands have unique functions or limitations when used in OS/2
login scripts.
Command Limitation
EXIT Does not support the filename parameter.
DRIVE Sets the default for the login process only.
INCLUDE If you use an include statement, you must specify a Universal Naming
Convention (UNC) pathname for the file to be included. For example,
if the file to be included is called INCLUDE.TXT and it is located
on NetWare server FS1, volume SYS:, directory PUBLIC, the include
statement should read: INCLUDE \\FS1\SYS\PUBLIC\INCLUDE.TXT
MAP You cannot map search drives in OS/2. The same functionality is
provided by using the OS/2 PATH and DPATH commands. See the OS/2
documentation.
SET Sets the environment variable for the login process only. Spawned
processes inherit the variable, but the variable disappears when
LOGIN terminates.
Virtual DOS and MS Windows Sessions
With NetWare Client for OS/2, you have full NetWare 3.1x functionality from
both private and global sessions. However, you don't have NDS functionality
(provided with NetWare 4).
This means you can run NetWare 4 DOS utilities from a DOS session, but you
can't access NetWare Directory Services. To a NetWare 4 server, your client
appears to be a NetWare 3.1x bindery emulation client.
To obtain NDS functionality, boot from a different DOS kernel than the one
included with OS/2 and load the NetWare Client for DOS and MS Windows
software.
Boot from a real DOS kernel by using the DOS_STARTUP_DRIVE setting. The OS/2
online Master Help Index explains how.
Sessions booted from a real DOS kernel can have private or global support.
Global sessions booted with a real DOS kernel have NetWare 3.1x support.
Private sessions booted with a real DOS kernel can have NetWare 4 support if
you load the NetWare Client for DOS and MS Windows.
NetWare support in DOS/Windows sessions
ΓòÉΓòÉΓòÉ 3.3.1. How To Edit Login Scripts for Each Type of Session ΓòÉΓòÉΓòÉ
How To Edit Login Scripts for Each Type of Session
If you log in from Login script run How login script is edited
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
OS/2 session NetWare 4 Login With the NetWare Administrator
Profile object for OS/2 utility.
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
OS/2 session NetWare 3.12 Use SYSCON.
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
Private DOS/MS NetWare 3.1x DOS From a text editor. Edit the
Windows session login script SYS:MAIL\userID\LOGIN file or
use a NetWare 3.1x utility,
such as SYSCON.
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
Global DOS/MS NetWare 3.1x DOS From a text editor. Edit the
Windows session login script SYS:MAIL\userID\LOGIN file or
use a NetWare 3.1x utility,
such as SYSCON.
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
Global session NetWare 3.1x DOS From a text editor. Edit the
booted from real DOS login script SYS:MAIL\userID\LOGIN file or
kernel and running use a NetWare 3.1x utility,
NETX.EXE such as SYSCON.
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ
Private session NetWare 4 Login With the NetWare Administrator
booted from real DOS Profile object for OS/2 utility.
kernel and running
NetWare Client for
DOS and MS Windows
ΓòÉΓòÉΓòÉ 4. Preparing Hardware ΓòÉΓòÉΓòÉ
Preparing Hardware
Hardware Prerequisites
The following checklist will help you prepare your workstation for installing
NetWare Client for OS/2.
Checklist
An IBM personal computer (or compatible) with a 386 (SX or DX)
processor. OS/2 2.x operates only with 386 (SX and DX) processors and
above because of its 32-bit architecture
A hard disk with 3 MB of free storage for NetWare Client for OS/2 files
8 MB of RAM
A 1 to 1.44MB 3.5-inch diskette drive
If you want to use Remote Program Load (RPL),a Remote Reset PROM
inserted in each RPL workstation
A mouse or compatible pointing device
A network board installed in your workstation
A VGA monitor
Network Cabling
Each type of network board requires unique cabling. For requirements, see the
manufacturer's documentation packaged with the board.
Important Token ring network boards must have a physical connection to the MAU
before you install NetWare Client for OS/2. Otherwise, the TOKEN driver will
not load.
Determining Network Board Settings
The NetWare Client for OS/2 installation program requires specific information
about the network board in your workstation.
Before installing NetWare Client for OS/2, record the values for the following
settings:
Checklist
Hardware interrupt
In most cases, you can use interrupt line 3 or interrupt line 5 for your
network board. If neither interrupt line 3 nor interrupt line 5 is
available, see the manufacturer's documentation.
Note: We recommend that you don't use interrupt line 2. It may interfere
with the VGA adapter.
Base I/O port
Each hardware device included in your workstation must have a different
base I/O port setting. For more information, see the manufacturer's
documentation.
Frame type
All workstations and servers using a single network address must use the
same frame type. The default for Novell ODI drivers is 802.2.
Other settings
Other settings unique to the network board installed in your workstation.
(See the documentation provided with your network board.)
Important In most cases, leave your network board set to the factory settings.
If you need to change the default settings, see the manufacturer's
documentation.
You can obtain setting information for your network board by using the
following procedures.
Finding board settings
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéIf you have Then Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéEISA or MCA Run the computer's setup or reference Γöé
Γöénetwork boards program. This program will list the values Γöé
Γöé for your network board settings. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéISA network Physically view the network board to obtain Γöé
Γöéboards the specific settings. The documentation Γöé
Γöé provided with your network board will direct Γöé
Γöé you where to locate each value. Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓòÉΓòÉΓòÉ 5. Installing NetWare Client for OS/2 ΓòÉΓòÉΓòÉ
Installing NetWare Client for OS/2
Topic
Installation Overview
Installing NetWare Client for OS/2 from Diskettes
Installing NetWare Client for OS/2 from CD-ROM
Upgrading NetWare Client for OS/2 from a Network Directory
Installing and Using NetWare VLM Boot
ΓòÉΓòÉΓòÉ 5.1. Installation Overview ΓòÉΓòÉΓòÉ
Installation Overview
Four things happen when you install NetWare Client for OS/2:
Γûá A directory is created on your workstation
Γûá Files are copied
Γûá The Novell group icon is created
Γûá The CONFIG.SYS file is modified
A Directory Is Created on Your Workstation
By default, a \NETWARE directory is created in the root of the drive from
which you boot OS/2. (If you specify another directory, it is created.)
Files Are Copied
All NetWare Client for OS/2 files are copied to the directory specified during
installation. You can change your settings later without copying additional
files from the WSOS2_1 diskette. Six kinds of files are copied:
Γûá NetWare Client for OS/2 program files
Γûá DLL files (Dynamic Link Libraries) for OS/2
Γûá DLL file for MS Windows
Γûá Network board drivers
Γûá Utility files (INSTALL, NPRINTER, NWTOOLS, LOGIN, NLIST, MAP, CX, OS2_TSA)
Γûá Unicode tables
Most files on the diskette are compressed. The installation program
decompresses them. To decompress a file, use the NWUNPACK utility on the
diskette. Type NWUNPACK and the target directory, followed by the name of a
file.
Important If you install NetWare Client for OS/2 on an OS/2 for Windows
workstation, the files are copied to the WINDOWS/SYSTEM directory.
The Novell Group Icon Is Created
A group icon called Novell is created on the OS/2 desktop. This group contains
Γûá The NetWare Client for OS/2 installation program
Γûá NetWare Tools
Γûá The NPRINTER remote printing utility
Γûá The OS2_TSA program
The CONFIG.SYS File Is Modified
The previous version of CONFIG.SYS is automatically saved as CONFIG.BAK.
The NETWARE directory (or the directory you specify) is included at the end of
the PATH, LIBPATH, and DPATH statements so that OS/2 can find the NetWare
Client for OS/2 files. Based on the ODI driver and settings you choose, the
NetWare Client for OS/2 section of CONFIG.SYS includes lines loading NetWare
Client for OS/2 components. This section is identified by comment lines before
and after.
Important Don't delete the comment lines before and after the NetWare Client
for OS/2 lines. Everything between these comments is deleted and rewritten
when you use the installation program to edit CONFIG.SYS.
Therefore, make a backup copy of CONFIG.SYS after your NetWare Client for OS/2
installation is completed.
Other configuration programs, such as IBM's Extended Services, may rearrange
CONFIG.SYS in such a way as to invalidate NetWare Client for OS/2.
ΓòÉΓòÉΓòÉ 5.2. Installing NetWare Client for OS/2 from Diskettes ΓòÉΓòÉΓòÉ
Installing NetWare Client for OS/2 from Diskettes
If you are installing NetWare Client for OS/2 from diskettes for the first
time, complete the following.
Prerequisites
Checklist
Γûá Have working copies of the following NetWare Client for OS/2 diskettes:
Γûá WSOS2_1
Γûá WSOS2_2
Γûá WSOS2_3
Γûá WSDRV_1
Γûá OS2UTIL1
Γûá OS2DOC_1
Γûá (Optional) Have working copies of any NetWare compatible third-party network
board drivers.
You need a third-party MLID driver for the network board installed in your
workstation if one is not provided with the NetWare Client for OS/2 software.
NetWare Client for OS/2 supports most network boards. If NetWare Client for
OS/2 does not list a driver for your network board, check the packaging or
contact the network board manufacturer to obtain a NetWare-compatible driver.
Important If NetWare Client for OS/2 was running previously on your
workstation, then a number of NetWare files have been opened by OS/2 through
the NetWare Client for OS/2 statements in the CONFIG.SYS.
As new files are being copied by the installation utility, you will see errors
appear because the existing files of the same name cannot be closed and
replaced by the installation utility. This might cause compatability problems
because of the files that were not updated.
The best way to resolve this issue is to boot your OS/2 workstation without
NetWare Client for OS/2 loaded. That way, all of the necessary files are
copied correctly.
Procedure 1. Go to the OS/2 desktop.
2. Insert the diskette labeled WSOS2_1 into a disk drive.
3. Choose the "Drive A" icon on the desktop.
The "Drive A Tree View" window appears.
4. From the "Drive A Tree View", select the "Drive A" icon.
5. Select the "INSTALL.EXE" icon to load the installation program.
6. From the "Installation" menu, select "Requester on workstation..."
The "Set Target Directory" window appears.
7. Set the appropriate path and source drive. Choose OK.
The "Requester Installation" window appears.
8. Accept the default of "Edit CONFIG.SYS and Copy All Files" by choosing OK.
NoteThe other three choices are for changing the initial installation of
NetWare Client for OS/2.
The "Step 1 - Choose the ODI LAN Driver" window appears.
9. Select the appropriate driver.
9a. Choose the arrow next to the "ODI LAN Driver" window.
9b. Insert "WSDRV_1" in drive A: as instructed. Choose "OK."
9c. Select the LAN Driver provided by NetWare Client for OS/2 or a
third-party vendor.
9d. Choose "Continue."
The "Step 2 - Choose NetWare Support for DOS and Windows Applications"
window appears.
10. Select "IPX Support for DOS and MS Windows" and "Default NetWare Shell
Support", and then choose "Continue."
For more information on available selections, choose "Help."
The "Suggested Default Settings to AUTOEXEC.BAT" window appears.
11. Accept the default by choosing "Save."
For more information on available selections, choose "Help."
12. When asked if you want to add files to another batch file, select "No."
Note If you select "Yes," you can customize boot files for individual DOS
sessions. Typically, all DOS sessions use the same boot file (i.e., the
AUTOEXEC.BAT file).
13. If prompted to change the DOS_LASTDRIVE setting, select "OK".
Important Make sure your DOS_LASTDRIVE setting is correct upon completion of
NetWare Client for OS/2 installation. See "Changing and Saving DOS and
WIN-OS/2 Settings" in the OS/2 Master Help Index.
The "Step 3 - Choose Optional Protocols" window appears.
14. Accept the defaults by choosing "Save".
For more information on available selections, choose "Help".
The "Save Changes to CONFIG.SYS" window appears.
15. To save the file as CONFIG.SYS, choose "OK." To save the file under a
different name, edit the window.
The "Copy ODI LAN Driver Files" window appears.
16. Accept the default by choosing "OK."
For more information on available selections, choose "Help".
The "Copy Requester Files" window appears.
17. Choose "Copy."
If NetWare Client for OS/2 was running previously on your workstation,
then a number of NetWare files have been opened by OS/2 through the
NetWare Client for OS/2 statements in the CONFIG.SYS.
As new files are being copied by the installation utility, you will see
errors appear because the existing files of the same name cannot be closed
and replaced by the installation utility. This might cause compatability
problems because of the files that were not updated.
The best way to resolve this issue is to boot your OS/2 workstation
without NetWare Client for OS/2 loaded. That way, all of the necessary
files are copied correctly.
18. To complete installation, follow instructions on your screen.
19. Read the final screen that appears after installation.
20. Configure your workstation.
Detailed information on each configuration option is located in NET.CFG
Options Reference
Important For changes to take effect from your configuration, restart your
workstation.
ΓòÉΓòÉΓòÉ 5.3. Installing NetWare Client for OS/2 from CD-ROM ΓòÉΓòÉΓòÉ
Installing NetWare Client for OS/2 from CD-ROM
You can use the NetWare server installation program on CD-ROM to copy
workstation installation files to the PUBLIC\CLIENT directory on volume SYS:.
Copying Client Installation Software from the CD-ROM to the Server
To copy NetWare Client for OS/2 installation software from the CD-ROM to the
server, follow these steps below.
Prerequsite
Checklist CD-ROM drive installed as a device on your workstation according to
the manufacturer's instructions.
Procedure 1. Log in.
2. Make a subdirectory named CLIENT under SYS:PUBLIC for the workstation
installation files.
3. Copy files from the CLIENT directory on the CD-ROM to SYS:PUBLIC\CLIENT by
typing either:
NCOPY drive:\source path\*.* drive:\destination path /s/e/c
or
XCOPY drive:\source path\*.* drive:\destination path /s/e/v
For example, type
XCOPY D:\CLIENT\OS2\*.* H:\PUBLIC\CLIENT /s /e /v
Important Don't use the COPY command for this procedure. The directory
structure within each subdirectory must be maintained.
SuggestionYou can also set up your CD-ROM drive as a volume on your network.
This allows you to run workstation installation programs directly from
subdirectories under CLIENT on the CD-ROM.
Creating Workstation Installation Diskettes from CD-ROM
To install the CD-ROM either as a local volume or as a network device, follow
these steps.
Procedure 1. Format high-density diskettes using the FORMAT command.
You must format three diskettes for the NetWare Client for OS/2
installation.
2. Go to the drive corresponding to the CD-ROM.
3. Change to the CLIENT directory on the CD-ROM.
4. Change to the OS/2 subdirectory.
5. Set the "nwlanguage environment" variable.
Type the following at the command line:
SET NWLANGUAGE=language <Enter>
Replace language with the appropriate language found in the NLS
subdirectory under CLIENT\OS2.
6. Type
MAKEDISK drive_letter: language <Enter>
For example, type either
MAKEDISK A: ENGLISH <Enter>
or
MAKEDISK B: ENGLISH <Enter>
MAKEDISK copies client installation files from the CD-ROM directory to the
diskettes.
7. Save these diskettes until after you have installed all NetWare
workstations.
ΓòÉΓòÉΓòÉ 5.4. Upgrading NetWare Client for OS/2 from a Network Directory ΓòÉΓòÉΓòÉ
Upgrading NetWare Client for OS/2 from a Network Directory
Note This feature is only available on NetWare 3.12 and NetWare 4 servers.
The following checklist and procedures help set up your workstation for
installing NetWare workstation software from a network directory.
It is the quickest and easiest way to upgrade NetWare client software.
Prerequisites
Checklist Γûá A version of the NetWare Client for OS/2 software running on your
workstation.
Γûá A copy of the NetWare Client for OS/2 software must exist on your network.
Warning If NetWare Client for OS/2 was running previously on your workstation,
then a number of NetWare files have been opened by OS/2 through the NetWare
Client for OS/2 statements in the CONFIG.SYS. As new files are being copied by
the installation utility, you will see errors appear because the existing files
of the same name cannot be closed and replaced by the installation utility.
This may cause compatability problems because of the files that were not
updated. The best way to resolve this issue is to boot your OS/2 workstation
without NetWare Client for OS/2 loaded. Then, all of the necessary files will
be copied correctly.
Procedure
1. Log in.
2. Map a drive to the PUBLIC\CLIENT\OS2 directory on volume SYS:.
3. Type INSTALL.
4. From the "Installation" menu, select "Requester on workstation..."
The "Set Target Directory" window appears.
5. Set the appropriate path and source drive. Choose OK.
The "Requester Installation" window appears.
6. Accept the default of "Edit CONFIG.SYS and Copy All Files" by choosing OK.
NoteThe other three choices are for changing the initial installation of
NetWare Client for OS/2.
The "Step 1 - Choose the ODI LAN Driver" window appears.
7. Select the appropriate driver.
8a. Choose the arrow next to the "ODI LAN Driver" window.
8b. Insert "WSDRV_1" in drive A: as instructed. Choose "OK."
8c. Select the LAN Driver provided by NetWare Client for OS/2 or a
third-party vendor.
8d. Choose "Continue."
The "Step 2 - Choose NetWare Support for DOS and Windows Applications"
window appears.
9. Select "IPX Support for DOS and MS Windows" and "Default NetWare Shell
Support", and then choose "Continue."
For more information on available selections, choose "Help."
The "Suggested Default Settings to AUTOEXEC.BAT" window appears.
10. Accept the default by choosing "Save."
For more information on available selections, choose "Help."
11. When asked if you want to add files to another batch file, select "No."
Note If you select "Yes," you can customize boot files for individual DOS
sessions. Typically, all DOS sessions use the same boot file (i.e., the
AUTOEXEC.BAT file).
12. If prompted to change the DOS_LASTDRIVE setting, select "OK".
Important Make sure your DOS_LASTDRIVE setting is correct upon completion of
NetWare Client for OS/2 installation. See "Changing and Saving DOS and
WIN-OS/2 Settings" in the OS/2 Master Help Index.
The "Step 3 - Choose Optional Protocols" window appears.
13. Accept the defaults by choosing "Save".
For more information on available selections, choose "Help".
The "Save Changes to CONFIG.SYS" window appears.
14. To save the file as CONFIG.SYS, choose "OK." To save the file under a
different name, edit the window.
The "Copy ODI LAN Driver Files" window appears.
15. Accept the default by choosing "OK."
For more information on available selections, choose "Help".
The "Copy Requester Files" window appears.
16. Choose "Copy."
If NetWare Client for OS/2 was running previously on your workstation,
then a number of NetWare files have been opened by OS/2 through the
NetWare Client for OS/2 statements in the CONFIG.SYS.
As new files are being copied by the installation utility, you will see
errors appear because the existing files of the same name cannot be closed
and replaced by the installation utility. This might cause compatability
problems because of the files that were not updated.
The best way to resolve this issue is to boot your OS/2 workstation
without NetWare Client for OS/2 loaded. That way, all of the necessary
files are copied correctly.
17. To complete installation, follow instructions on your screen.
18. Read the final screen that appears after installation.
19. Configure your workstation.
Detailed information on each configuration option is located in NET.CFG
Options Reference
Important For changes to take effect from your configuration, restart your
workstation.
ΓòÉΓòÉΓòÉ 5.5. Installing and Using NetWare VLM Boot ΓòÉΓòÉΓòÉ
Installing and Using NetWare VLM Boot
NetWare Virtual Loadable Module (VLM) Boot makes it possible to have an actual
DOS kernel running on an OS/2 workstation. This DOS kernel allows you to
effectively run NetWare Administrator from an OS/2 client workstation.
Prerequisites
Checklist
ΓûáOS/2 verison 2.11 installed on your client workstation. NetWare VLM Boot will
not run on OS/2 version 2.1 or earlier.
ΓûáNetWare Client for OS/2 installed on your client workstation
ΓûáA copy of the DOS_VLMBOOT diskette
ΓûáA floppy drive on your client workstation
Installing NetWare VLM Boot
1. Go to the OS/2 desktop.
2. Open the "Novell" folder.
3. Choose the Install icon.
4. From the Configuration menu, choose "VLM Boot Setup."
The "VLM Boot Setup" screen appears.
5. Enter the source floppy drive letter or accept the default, and then select
╨║OK.Γòæ
6. Insert the DOS_VLMBOOT diskette into the selected source drive and then
select ╨║OK.Γòæ
The "Create a NetWare VLM Boot Image File" screen appears.
7. Select the "Create a NetWare VLM Boot image file" checkbox.
8. Enter the source floppy drive letter or accept the default and then select
"OK."
A NetWare VLM Boot file is created.
9. Exit the Installation program and restart your workstation.
Using NetWare VLM Boot
1. Go to the OS/2 desktop.
2. Open the "Novell" folder.
3. Choose the "VLMBOOT" icon.
An actual DOS session is now open on your workstation and attached to your
network.
ΓòÉΓòÉΓòÉ 6. Configuring NetWare Client for OS/2 ΓòÉΓòÉΓòÉ
Configuring NetWare Client for OS/2
This section has information about five topics:
Configuration Overview
Using NET.CFG
NET.CFG File Format Requirements
Creating or Editing NET.CFG
Quick Reference List of NET.CFG Options
ΓòÉΓòÉΓòÉ 6.1. Configuration Overview ΓòÉΓòÉΓòÉ
Configuration Overview
After you've installed NetWare Client for OS/2 on your workstation, you must
configure it to run with your network.
Configuration options for NetWare Client for OS/2 are stored in the NET.CFG
file. When you start up your workstation, NetWare Client for OS/2 searches for
NET.CFG in the directories specified in the DPATH line in CONFIG.SYS. If
NetWare Client for OS/2 doesn't find a NET.CFG file, it starts up using the
default configuration values built into the software.
When Configuration Is Required
You must configure NetWare Client for OS/2 if
Γûá Your workstation has more than one network board
Γûá Your workstation has a single board, but the board is not using factory
default settings
Γûá Your network uses an Ethernet frame type other than Ethernet 802.2
Γûá NetWare Client for OS/2 will share a network board with other software
Other Situations When Configuration Might Be Useful
Configuration may also be useful in these circumstances:
Γûá You want to change the default packet signature security level.
Γûá You want to turn off Packet Burst or Large Internet Packet
transmissions.
Γûá Your workstation will connect to a token ring network using source
routing.
Γûá Your workstation will use NetBIOS or Dual NetBIOS protocols.
Γûá Your workstation will use Named Pipes protocol.
Γûá You want your workstation to connect to a preferred Directory tree.
Γûá You are setting up Remote Program Load (RPL) workstations.
Γûá You want to change your default login drive.
About Protocol Support in NetWare Client for OS/2
NetWare Client for OS/2 provides four kinds of protocol support:
Γûá IPX
Γûá SPX
Γûá Named Pipes
Γûá NetBIOS (emulation)
NetWare servers and client workstations use IPX as the primary protocol to
communicate with each other. They also use SPX for some communications, such
as communications between a workstation running NPRINTER and a NetWare print
server. Support for IPX on the workstation is installed when you install
NetWare Client for OS/2.
SPX, NetBIOS, and Named Pipes protocols are provided by Novell so that NetWare
clients and servers can also function as
Γûá Distributed application clients and servers
Γûá Non-NetWare network clients and servers
Γûá Terminals connected to mainframes or minicomputers
For example, the Lotus Notes* distributed application uses NetBIOS or SPX for
communications; Microsoft SQL Server uses Named Pipes. LANServer networks use
NetBIOS, and many Communications Manager connections to a gateway also use
NetBIOS.
Other protocols not provided with NetWare Client for OS/2 can be used for
these purposes. For example, the TCP/IP protocol provided by Novell's LAN
Workplace for OS/2 is commonly used for connections to UNIXΓò£ hosts. These
other protocols are not discussed in this document.
The figure below illustrates the components of a distributed application
network.
Several protocols can be installed on the same computer at the same time. All
of these protocols can use the same network cabling, although each protocol
might communicate on a completely separate logical network. The figure below
shows how a NetWare network and a distributed application network share
cabling.
ΓòÉΓòÉΓòÉ 6.2. Using NET.CFG ΓòÉΓòÉΓòÉ
Using NET.CFG
Configuration options for NetWare Client for OS/2 are stored in a NET.CFG file.
When you turn on your workstation, NetWare Client for OS/2 searches for NET.CFG
in the directories specified in the DPATH line of CONFIG.SYS. If NetWare Client
for OS/2 does not find NET.CFG, it uses a set of default configuration values
built into the software.
NET.CFG is located in the root directory of your boot drive. If you have
previously configured NetWare Client for OS/2 on a workstation, a NET.CFG file
already exists for your workstation. You can change the current configuration
by modifying and saving the existing file.
Reinstalling NetWare Client for OS/2 will not overwrite an existing NET.CFG
file; instead, the existing NET.CFG file will appear in the installation
program for you to edit.
Important If you have not configured NetWare Client for OS/2 on your
workstation before, a NET.CFG file does not exist for your workstation. You
must create this file to configure your workstation.
ΓòÉΓòÉΓòÉ 6.3. NET.CFG Format Requirements ΓòÉΓòÉΓòÉ
NET.CFG Format Requirements
The illustration below shows the NET.CFG format.
To create of modify NET.CFG, use the following rules:
Γûá Type options at the left margin of the file with no spaces before or after
them. Options are not case-sensitive.
Γûá Type one option per line.
Γûá Type settings, one per line, on the lines following the option to which they
apply.
Γûá When editing NET.CFG, use the Space bar, rather than the Tab key, to indent
these settings. The Tab key moves to the next field on the screen.
Γûá Indent settings at least one space. Settings are not case-sensitive.
Γûá Place a hard return at the end of every line in the file, including the last
line.
Warning If you don't put a hard return at the end of the last line, the line is
ignored.
Γûá Blank lines are not necessary and are ignored.
Γûá Precede comment lines with a semicolon (;).
ΓòÉΓòÉΓòÉ 6.4. Creating or Editing NET.CFG ΓòÉΓòÉΓòÉ
Creating or Editing NET.CFG
Prerequisite
NetWare Client for OS/2 is installed on your workstation.
Procedures: To create or edit NET.CFG with the installation program
1. Go to the OS/2 desktop.
2. Choose the "Novell" icon on the desktop.
3. Choose the "Install" icon in the "Novell" window.
4. From the "Configuration" menu, select "This workstation. . ."
The "Default Location for NET.CFG File" window appears.
5. Enter the path of the NET.CFG file and select "Edit".
The NET.CFG edit screen appears. If this is a new installation, there is
not a default NET.CFG file and the "Current NET.CFG File Contents" box
will be empty.
6. Type the NET.CFG options you want in the "Current NET.CFG File Contents"
box.
A typical NET.CFG might look like
link driver ne2000
int 5
port 340
frame ethernet_802.3
netware requester
default login drive f
display hard errors off
name context "finance.novell"
preferred tree redwood
signature level 3
NoteThe "default login drive" setting requires changes to the CONFIG.SYS file.
See NET.CFG Options Reference for more information.
Signature level 3 is the most secure, requires Packed Burst to be enabled, and
the server signature level needs to be set at level 1 or higher for login. See
Improving Speed and Security for more information.
The figure below shows a more detailed explanation of how to use the "Edit the
NET.CFG file for this workstation" window.
7. To save your changes to the NET.CFG file, choose "Save."
8. To exit the installation program, double-click in the upper left corner of
the main window.
9. For changes to take effect from your configuration, use the OS/2 shutdown
feature and start your workstation.
Important Installation and configuration changes will not take effect until
you restart your workstation.
If you are still having problems see the Troubleshooting Section for helpful
tips.
ΓòÉΓòÉΓòÉ 6.5. Quick Reference List of NET.CFG Options ΓòÉΓòÉΓòÉ
Quick Reference List of NET.CFG Options
The figure below lists NET.CFG options and settings and the default value for
each.
ΓòÉΓòÉΓòÉ 7. Using Network Boards and LAN Drivers ΓòÉΓòÉΓòÉ
Using Network Boards and LAN Drivers
This section provides information about five topics
Specifying Frame Types for LAN Driver
Matching Network Board and ODI Driver Settings
Cautions When Changing Frame Type
Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types
Using More than One Network Board
ΓòÉΓòÉΓòÉ 7.1. Matching Network Board and ODI Driver Settings ΓòÉΓòÉΓòÉ
Matching Network Board and ODI Driver Settings
Important NetWare Client for OS/2 software expects each network board to use
the board's factory default settings. If you have changed the settings on your
network board, you must make corresponding changes in the OS/2 client software.
This is done through the NET.CFG.
Network boards come with factory defaults for such hardware settings as
Γûá Direct memory access channel (DMA)
Γûá Interrupt line (IRQ)
Γûá Input/output port
Γûá Memory range
Γûá Node address
The NetWare Client for OS/2 software, as shipped, expects each network board
to be using the default settings. These factory defaults can usually be
changed by moving jumpers, setting switches, or through a configuration
utility provided by the manufacturer of the network board.
Therefore, if you change the factory default for any of the hardware settings
listed above, you must tell the OS/2 ODI driver the new setting.
To do this, use the "link driver" option in NET.CFG. The "link driver" option
allows you to configure your software to correspond to your hardware settings:
link driver name
dma [index] channel
int [index] irq
mem [index] starting_address [size]
node address number
port [index] starting_port [number]
Shortcut for Microchannel and EISA LAN Drivers
If you are using Microchannel or EISA network boards, you do not need to
specify the hardware settings shown above. The LAN driver scans the network
board and determines which settings are in use.
You must tell NetWare Client for OS/2 the slot number where the network board
is located. You can also tell NetWare Client for OS/2 to scan all slots. To
define the network board slot, use the "Link Driver" option in NET.CFG.
link driver name
slot number
Replace number with the slot number or with a question mark if you want to
scan all slots.
See NET.CFG Options Reference for more information.
ΓòÉΓòÉΓòÉ 7.2. Specifying Frame Types for LAN Drivers ΓòÉΓòÉΓòÉ
Specifying Frame Types for LAN Drivers
Overview
All communications on a network consist of packets of information being sent
between computers.
There are different kinds of packets, distinguished from each other by the
order and type of the information in the packet. Each kind of packet has its
own definition, called a frame type.
For each computer to communicate by a certain frame type, each computer must be
configured to use that frame type.
A network board in your workstation allows your workstation to communicate
with other workstations on your network and with the NetWare server.
LAN driver software serves as the link between your workstation's operating
system and the network.
By default, each LAN driver uses only one kind of frame type. However, most LAN
drivers can support other frame types if they are configured to do so through
the NET.CFG.
For example, an NE2000 LAN driver supports the following frame types: Ethernet
802.2, Ethernet 802.3, Ethernet II, and Ethernet SNAP.
The "Frame Types and LAN Drivers" table lists common frame types and the
network board drivers that support each type. This list is not comprehensive.
Link Driver Option
The Link Driver option in NET.CFG tells the Lan driver what frame types you
use. You can only specify frame types supported by that driver.
Syntax
link driver name
frame name
Replace name with the name of the frame type.
Example
For example, to link your NE2000 LAN driver to the Ethernet 802.2 frame type,
you would enter into your NET.CFG file.
link driver ne2000
frame ethernet_802.2
ΓòÉΓòÉΓòÉ 7.3. Cautions With the Default Frame Type ΓòÉΓòÉΓòÉ
Cautions With the Default Frame Type
Note: In NetWare 2 and 3, Ethernet drivers default to the Ethernet 802.3 frame
type. In NetWare 4, they default to Ethernet 802.2 frame type.
NetWare 4 server drivers for Ethernet default to the Ethernet 802.2 frame type.
Servers and workstations must use the same frame types to communicate with each
other.
Routers must also support the same frame types or your packets will not be
routed correctly. This will disrupt communications and if your workstation does
not get a connection, it will likely fail. Some routers on your network might
not support the new Ethernet 802.2 frame type.
Important Your workstation might not connect to a network expecting the old
default of Ethernet 802.3 if you use the new default of Ethernet 802.2.
ΓòÉΓòÉΓòÉ 7.4. Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types ΓòÉΓòÉΓòÉ
Defining Both Ethernet 802.2 and Ethernet 802.3 Frame Types
You can define both Ethernet 802.2 and Ethernet 802.3 on your network to
eliminate conflicts due to default frame type settings.
For your workstation, define frame types in NET.CFG. Include a line similar to
the following, replacing ne2000 with the name of your ODI driver:
link driver ne2000
frame ethernet_802.3
frame ethernet_802.2
The first frame type defined is the only one used for the initial "Get Nearest
Server" request. Therefore, if you have servers using only one frame type,
such as Ethernet 802.3, put that frame type first. That way your workstation
can make a default connection to those servers.
See NET.CFG Options Reference for more information about the link driver
option.
ΓòÉΓòÉΓòÉ 7.5. Using More than One Network Board ΓòÉΓòÉΓòÉ
Using More than One Network Board
Note: In most cases NetWare Client for OS/2 can share a network board with
other communications packages so you do not need to purchase two network
boards.
This section describes
Γûá Reasons for having more than one network board
Γûá Setting up two network boards
Γûá Choosing a primary network board
Reasons for Having More Than One Network Board
When using NetWare Client for OS/2, there are two conditions where you might
benefit from having more than one network board in your computer:
Γûá When each network board supports a different communications software package
Γûá When each network board is connected to a physically separate network
If you have two network boards, be aware of the configuration issues in the
following sections.
Additional network boards (those after the second defined network board) are
ignored.
Different Communications Packages
You might want to use two or more network boards when each board is supported
by its own communications software package.
For instance, you might want to have Communications Manager use one network
board and NetWare Client for OS/2 use another. Or you might want NetWare for
OS/2 to use one network board and the NetWare Client for OS/2 to use another.
In these cases, each package provides the driver for its own board. The setup
for NetWare Client for OS/2 is the same as if only one network board existed.
There are no additional steps to set up the second network board under NetWare,
since that network board is controlled by the other communications package. It
may need to be configured under the other communications package.
Note: In most cases, NetWare Client for OS/2 can share a network board with
other communication packages, so you do not need to purchase two network
boards.
Physically Separate Networks
You might want to use two network boards with each board being connected to its
own network. This makes it possible for a custom application to access both
networks at one time. However, a workstation with only NetWare Client for OS/2
cannot serve as a router between the two networks. This means that, although
both networks are connected to the same physical machine, there is no
communication between the two networks. (The OS/2 workstation can become a
router using NetWare for OS/2).
If your two networks are connected through another machine serving as a router,
your second network board may serve as a backup route if the connection to your
first board fails. Again, your OS/2 workstation is not routing (unless you are
using NetWare for OS/2).
Using The Second Network Board as a Backup
When the workstation boots, the IPX protocol binds to all network boards that
have OS/2 ODI drivers loaded. Whenever NetWare Client for OS/2 needs to find a
new destination on the network, it queries the network for possible routes to
that destination.
Important NetWare Client for OS/2 sends out a destination query only on the
primary network board. It never queries the secondary (or other) board for a
route. If NetWare Client for OS/2 doesn't find the destination using the
primary network board, you see a connection error, even if the destination
could be found using the second network board. (However, the network on the
second network board can be queried using IPX calls from a custom program).
Once NetWare Client for OS/2 finds a destination using the primary network
board, it stores the route to that destination in a router table and makes a
connection.
After a connection is made, NetWare Client for OS/2 checks all networks
connected to that destination for other possible routes from your OS/2
workstation to the destination.
If it finds a secondary route, NetWare Client for OS/2 rebuilds the router
tables and stores that route. If the primary connection fails, NetWare Client
for OS/2 will use the secondary route to continue transmissions to that
destination.
If NetWare Client for OS/2 is using a route through the second network board,
the primary connection can be broken without causing the secondary connection
to fail.
However, the secondary network board never becomes the primary board, even if
the primary board fails. This means that if NetWare Client for OS/2 needs to
find a new destination while the primary connection is down, it can't query for
the destination, since queries are only sent on the primary board.
Important To allow NetWare Client for OS/2 to find new destinations, restore
the primary connection.
Setting Up Two Network Boards
If you have two network boards in your computer, you may need to
Γûá Define hardware settings and frame type for each network board
Γûá Load a driver for each board
Γûá Choose a primary network board
Defining Hardware Settings and Frame Type for Each Network Board
If you have more than one network board, you will need to load a separate
driver and specify a "Link Driver" section for each network board.
For example, if you have an NE2000 board (the primary board) and a token ring
network board, you might include these in NET.CFG.
link driver ne2000
frame ethernet_802.3
frame ethernet_802.2
int 5
port 360
link driver token
frame token-ring
frame token-ring_snap
int 3
port A20
mem CC00
Loading the ODI Driver for an Additional Network Board
NetWare Client for OS/2 installation program allows you to specify an ODI
driver. That driver is then autoloaded in CONFIG.SYS, but you might need to
load an additional ODI driver manually in the CONFIG.SYS file if
Γûá You have two network boards, and
Γûá Those network boards use different ODI drivers.
Important If the network boards use the same ODI driver (for example, two
NE2000 boards), load the driver once when you install NetWare Client for OS/2.
Prerequisites
Checklist Install NetWare Client for OS/2 with one of the ODI drivers.
Check to see if the second network board is installed and free from hardware
conflicts.
Procedure
1. Using a text editor, open CONFIG.SYS.
For example, to use the OS/2 System Editor at the OS/2 command line, type
E C:\CONFIG.SYS <Enter>
CONFIG.SYS is in the root of your boot drive. (In this example, drive C:
is the boot drive.)
2. In NetWare Client for OS/2 lines, find the line loading the first ODI
driver.
3. Decide which driver you want IPX to recognize as primary.
The driver for the primary network board is the only driver IPX uses to
query the network for a route. The driver for the secondary network board
is never queried.
4. Type a new line to load an additional driver.
To load a driver as primary, type the line above the existing driver line.
To load a driver as secondary, type the line below the existing line.
The first driver loaded in CONFIG.SYS is the primary driver.
Type the path to the driver in the line. If you use a Novell-supplied
driver, the driver is located in the directory where you installed the
NetWare Client for OS/2 files, usually in C:\NETWARE.
For example, to load an NE2000 driver from the default location, type
DEVICE=C:\NETWARE\NE2000.SYS
Note: If you have two network boards using the same driver name (such as two
NE2000 boards), do not load the driver twice.
5. Save and exit the CONFIG.SYS file.
6. Edit NET.CFG to reflect the changes.
7. Use the OS/2 "shutdown" feature to reboot your machine in order to load the
additional drivers.
Choosing a Primary Network Board
The network board whose driver loads first in CONFIG.SYS is the primary
network board. You can change which network board is primary by
Γûá Reordering drivers in CONFIG.SYS.
Γûá Using a NET.CFG option to bind IPX to a different driver.
To change which network board IPX views as primary, use the "Protocol Stack
IPX" option in NET.CFG.
protocol stack ipx
bind drivername
Replace drivername with the name of the driver that controls the network
board, and indent the "bind" setting. For example, to set a token ring board
as primary, type
protocol stack ipx
bind token
2.Switching the Network Board in Use on Unconnected Networks
If you have two network boards and each is connected to a physically separate
network, you might want to
Γûá Change which board is primary in NET.CFG and reboot when you want to
access the other network.
Γûá Get a network switch box that allows you to change between physically
separate networks.
Γûá Connect the networks with a router.
Specifying Primary with Two Network Boards of the Same Type
If you have two network boards using the same type of ODI driver (such as
two NE2000 boards), do not load the same driver twice in the CONFIG.SYS
file and do not specify a "Protocol Stack IPX" option.
Instead, use the "link driver" option in NET.CFG to specify that the
driver is used twice. Do this by placing two "link driver" sections in
NET.CFG, each one specifying the driver name and hardware settings used by
that network board.
The hardware settings for at least one of the network boards must be
specified, since you cannot have two network boards of the same type both
using the default hardware settings.
For example, if you have two NE2000 network boards, you might include the
following lines in the NET.CFG file:
link driver ne2000
frame ethernet_802.2
frame ethernet_802.3
int 5
port 360
link driver ne2000
frame ethernet_802.2
frame ethernet_802.3
int 4
port 320
Putting two occurrences of "link driver ne2000" loads the NE2000 driver
twice.
If you do not specify two "Link Driver" sections, a driver will not be
loaded for the second board, and the second network board is ignored.
Important The network board whose line comes first in the NET.CFG file is
the one IPX uses as primary.
Shortcut for Multiple EISA and Microchannel Boards
If you are using two EISA or Microchannel boards that use the same driver
(such as NE3200 or 3C523), you still must specify a "Link Driver" section
for each board.
However, instead of specifying the hardware settings used on the network
board, you can specify the "slot" setting. The "slot" setting tells the
ODI driver which slot a network board is in. The driver then scans the
board and automatically determines what hardware settings are in use.
For example, for two NE3200 boards, type
link driver ne3200
frame ethernet_802.3
frame ethernet_802.2
slot 2
link driver ne3200
frame ethernet_802.3
frame ethernet_802.2
slot 1
In this example, the network board in slot 2 becomes the primary network
board because the driver for it was loaded first.
To change which network board is primary, reorder the "Link Driver"
sections. For example, to set the network board in slot 1 as primary, type
link driver ne3200
frame ethernet_802.3
frame ethernet_802.2
slot 1
link driver ne3200
frame ethernet_802.3
frame ethernet_802.2
slot 2
ΓòÉΓòÉΓòÉ 8. Logging In to Your Network ΓòÉΓòÉΓòÉ
Logging In to Your Network
The following topics are available:
Setting Up Workstations to Log In
Understanding Logging In to NetWare Directory Services (NDS)
Logging In from the OS/2 Command Line
Logging In to NetWare 2 and 3 Bindery Servers with NDS Utilities
Modifying NET.CFG To Log In to NetWare 2 or 3
Modifying NET.CFG TO Log In to NetWare 4
Network Login Window
ΓòÉΓòÉΓòÉ 8.1. Setting Up Workstations to Log In ΓòÉΓòÉΓòÉ
Setting Up Workstations to Log In
OS/2 supports a variety of operating system platforms referred to as
"sessions." The following headings will direct you to the kind of login that
works best with the platform you use.
Proper workstation setup can make logging in to a bindery and NetWare Directory
Services network virtually transparent. This chapter assumes that the following
tasks are completed:
Checklist NetWare Client for OS/2 is installed and running on your
workstation
Your workstation NET.CFG file has been modified for login
A User object or user account is created for each user
A home directory is created for each user
With the necessary modifications made to your NET.CFG file, you need only your
username and password to log in.
ΓòÉΓòÉΓòÉ 8.2. Understanding Logging In to NetWare Directory Services (NDS) ΓòÉΓòÉΓòÉ
Understanding Logging In to NetWare Directory Services (NDS)
NetWare Directory Services (NDS), used in NetWare 4, makes logging in
convenient because you log in to the network rather than log in to a server.
User information resides in a global database. Each "User Object" is assigned a
position, or "context" within the database that informs the network where your
workstation is in relationship to the network. This context is referred to as
your "name context."
When you log in, the LOGIN utility must know your context, or where your
particular User object is located. The User object's context forms its complete
name. The path from the object to the root of the tree forms the object's
complete name, which is unique among other object's names.
Your User object's complete name is a bottom-up traversal of the tree, from the
object up to the root.
Using Your Complete Name for Logging In
When you use a complete name of a User object, specify the common name first,
followed by a period (.). Then specify the container object, also followed by a
period, and so on up through the Organization object name (and the Country
object name, if used).
So, depending on the way your network is defined, your User object's complete
name could be represented by:
Common name.Organizational Unit name.Organization name.Country name
Specifying the Name Type of an Object
At times, such as when you move from one Container object to another, you must
include the name type of the object when typing out the complete name of the
object. A name type distinguishes the class of object you are referring to,
such as a User object or an Organizational Unit object.
For example, you could express
ESAYERS.SALES PV.SALES.NOVELL US
as:
CN=ESAYERS.OU=SALES PV.OU=SALES.O=NOVELL US
where CN is the common name of the User object, OU is the Organizational Unit
name, and O is the Organization name.
If you refer to an object that is in the same Container object as your User
object, refer to that object only by its common name instead of its complete
name.
Important You must always include the name type of the object (CN or OU or O)
in the complete name when you include the Country object in your Directory
tree, even when referring to objects located in the same Container object.
Changing Your Context
You may need to change your context to simplify your login or your reference
to other objects in your Directory tree. Two ways to change your context are:
Γûá Using the CX.EXE, included with NetWare Client for OS/2.
Γûá Using the "name context" command in NET.CFG.
ΓòÉΓòÉΓòÉ 8.3. Logging In from the OS/2 Command Line ΓòÉΓòÉΓòÉ
Logging In from the OS/2 Command Line
Important The default login drive is drive L:, unless it has been changed in
your NET.CFG.
NetWare Client for OS/2 maps drive L: as the default login drive, mapped to
SYS:LOGIN. However, you should log in from your NetWare workstation directory
(default C:\NETWARE). LOGIN connects your workstation to the network.
Logging In to NetWare Directory Services
Procedure
1. Open an OS/2 Full Screen or Window.
A prompt similar to the following appears:
[C:/]
2. Log in using one of the following ways:
2a. To log in using your username only, type
login username <Enter>
For example, type
login esayers <Enter>
2b. To log in to a specific server, type
login servername\username <Enter>
For example, type
login tsmkt\esayers <Enter>
3. If required, type your password.
ΓòÉΓòÉΓòÉ 8.4. Logging In to NetWare 2 and 3 Bindery Servers Using NDS Utilities ΓòÉΓòÉΓòÉ
Logging In to NetWare 2 and 3 Bindery Servers Using NDS Utilities
Important The default login drive is drive L:, unless it has been changed in
your NET.CFG file.
Procedure
1. Type
login server/username /b <Enter>
Replace "server" with the name of the bindery server. Replace "username"
with your username. For example, type
F:\login tsmkt/esayers /b <Enter>
2. If required, type your password.
ΓòÉΓòÉΓòÉ 8.5. Modifying NET.CFG To Log In To NetWare 2 or 3 ΓòÉΓòÉΓòÉ
Modifying NET.CFG To Log In To NetWare 2 or 3
When logging in to NetWare 2 or 3, you attach to a server. Following, you make
additional attachments to other servers you have a user account on.
Using the Preferred Server Setting
To direct NetWare Client for OS/2 to the server your user information is saved
on, use the preferred server setting in the NET.CFG file. For networks with
multiple servers, this setting is very useful to speed up logging in to the
network. This setting also allow you to log in with only your username.
Adding the Preferred Server Setting to NET.CFG for OS/2
Procedure
1. Using a text editor, open your NET.CFG.
Your workstation's NET.CFG file was copied to the target directory for
OS/2 files specified during the NetWare Client for OS/2 installation.
2. Under the "NetWare Requester" option, type
preferred server <servername>
For example, type
preferred server mktsales
Example of the NetWare Requester Line for OS/2
Netware Requester
Preferred server mktsales
ΓòÉΓòÉΓòÉ 8.6. Modifying NET.CFG To Log In To NetWare 4 ΓòÉΓòÉΓòÉ
Modifying NET.CFG To Log In To NetWare 4
When logging in to NetWare 4, you don't attach to individual servers (as with
previous versions of NetWare), but you log in to the entire network.
With your complete name (CN), you can simplify the login process by adding
information to your workstation's NET.CFG file. You add lines to the NetWare
Requester option.
If you add lines for the following settings, you don't need to type your
complete name each time you log in. The settings are:
Γûá Name Context
Γûá Preferred Tree
You must know your context before making these modifications. Without knowing
the context, you can't add entries for the settings.
Using the Name Context Setting
To inform NetWare Client for OS/2 of your name context, use the "name context"
setting in NET.CFG. LOGIN can then locate your User object and connect you to
the network.
If you are using NetWare 4, add this setting to NET.CFG. The setting is as
follows:
netware requester
Name Context "context"
Using the Preferred Tree Setting
To direct NetWare Client for OS/2 to the Directory tree where your name
context is set, use the "preferred tree" setting in NET.CFG. LOGIN can then
search only the preferred Directory tree.
If you are using NetWare 4 on a network with multiple Directory trees, add
this setting to your NET.CFG file. The setting is as follows:
netware requester
preferred tree treename
The default is set to the root, so if duplicate usernames exist within
separate Directory trees, the "preferred tree" setting avoids confusion.
Note Don't use both "preferred server" and "preferred tree" simultaneously.
The second setting overrides the first.
ΓòÉΓòÉΓòÉ 8.7. Network Login Window ΓòÉΓòÉΓòÉ
Network Login Window
When booting OS/2 2.1, a pop-up network login window sometimes displays,
because OS/2 can restart PROGRAMS, TASKLIST, FOLDERS, and CONNECTIONS
automatically by using the SET AUTOSTART variable in CONFIG.SYS.
For example, if the following line is in CONFIG.SYS,
SET AUTOSTART=PROGRAMS, TASKLIST, FOLDERS, CONNECTIONS
then the pop-up login window displays.
In a NetWare environment, it is best not to include the SET
AUTOSTART=CONNECTIONS line in CONFIG.SYS. The recommended syntax is
SET AUTOSTART=PROGRAMS, TASKLIST, FOLDERS
Use the OS/2 version of LOGIN or NetWare Tools to log in because these
utilities allow you to automatically set up your NetWare environment (map
drives and capture ports) and the pop-up login window does not.
The OS/2 version of LOGIN will run OS/2 login scripts (system and/or user login
scripts) and NetWare Tools allows you to create and load file settings that
function similar to login scripts.
ΓòÉΓòÉΓòÉ 9. Using Virtual DOS and Windows ΓòÉΓòÉΓòÉ
Using Virtual DOS and Windows
Overview
From a virtual DOS or MS Windows session, you can have three kinds of NetWare
support:
Global logins
All DOS, MS Windows, and OS/2 sessions set up for global login support
share a single login to a NetWare server. Drives that are mapped in one
session apply to the other sessions. A port captured in one session is
also captured in other sessions. This is useful in environments where the
number of connections is carefully monitored.
Private logins
All DOS and MS Windows sessions set up for private login support have
their own logins to a NetWare server. Drive mappings and port captures
from one session do not apply to the other sessions. This is useful in
environments where users need more than one connection to a server and
where users need logins from DOS or MS Windows sessions to be separate
from logins from OS/2 sessions.
No logins
Sessions with network support disabled have IPX/SPX support, but no
NetWare login support.
Set up NetWare support for virtual DOS and MS Windows in two ways:
1. Set a default type of support (global, private, none) that applies to all
existing DOS and MS Windows icons, as well as any new icons that are created.
If you choose this default in NetWare Client for OS/2 Installation
program, it is automatically loaded in the CONFIG.SYS file. To change the
default support
Γûá Run the NetWare Client for OS/2 Installation program.
Γûá Under the "Installation" menu, choose "Requester on workstation..."
Γûá Select the appropriate target directory and choose "OK."
Γûá Under the "Requester Installation" window, select "Only Edit
CONFIG.SYS..." Choose "OK."
Γûá Under "Choose ODI LAN driver," choose "Continue" unless changes
have been made in your LAN driver configuration.
Γûá Under "Choose NetWare Support of DOS and Windows Applications",
select the desired default support. Choose "Continue."
Γûá Continue installation.
2. Customize the type of support for each DOS and MS Windows icon on
your desktop.
All sessions started from the customized icon have the type of
support you specify. For instructions on customizing NetWare support
per icon, see the sections that follow.
To set up icons with different kinds of network support, label the icons for
those sessions something that indicates the type of support. For example, you
might want to create Global DOS Full Screen and Private DOS Full Screen icons.
Topics
Information for All Types of Sessions
Logging In from an OS/2 Virtual DOS Session
Customizing Icons For Global Support
Setting Up Drive Mappings in Global Sessions
Customizing Icons For Private Support
Special Instructions for Win-OS2 Icons
Special Instructions for DOS_STARTUP_DRIVE Sessions
Disabling Network Support in All Virtual Sessions
Setting Up Named Pipes for Virtual DOS and MS Windows
Setting Up NetBIOS for Virtual DOS and MS Windows
ΓòÉΓòÉΓòÉ 9.1. Information for All Types of Sessions ΓòÉΓòÉΓòÉ
Information for All Types of Sessions
NetWare 3 and 4 Support
From a virtual DOS or MS Windows session, you can access NetWare 3
(bindery-based) networks. On these networks, you can receive full NetWare
support, just as if you were using an actual DOS or MS Windows workstation. You
can also receive support for just the IPX, SPX, Named Pipes and NetBIOS
protocols.
Note You cannot access NetWare 4 networks from virtual DOS and MS Windows
sessions unless those networks support bindery emulation. If a NetWare 4
network supports bindery emulation, your DOS or MS Windows session will be seen
as a bindery-based client.
Accessing the Correct Version of DOS
For all virtual sessions you start, the COMSPEC variable must point to the
correct version of DOS. If you use the version of DOS included with OS/2, set
the COMSPEC variable to the following
SET COMSPEC=drive:\OS2\MDOS\COMMAND.COM
You can set the COMSPEC variable at the command line, in a login script, or
through "DOS Setting" from the OS/2 desktop.
Replace drive: with the letter of your boot drive. If you are running another
version of DOS, the COMSPEC variable should point to the location of the
COMMAND.COM file for that version.
NetWare login scripts often contain a statement assigning COMSPEC to a network
drive, so be sure to check-and if necessary, reset-the COMSPEC variable in
your login script.
Login Issues
The How to Edit Login Scripts For Each Type of Session table shows which login
scripts are executed from which type of session and how to edit those login
scripts.
Logout Issues
When you log out from a local drive in a DOS session, the drive for your login
directory is the last drive (set with DOS_LAST_DRIVE in DOS Settings) plus
one. For example, if your last DOS drive is C:, the drive you see after
logging out is drive D:.
If you log out from a network drive, the drive remains the same.
ΓòÉΓòÉΓòÉ 9.2. Logging In from an OS/2 Virtual DOS Session ΓòÉΓòÉΓòÉ
Logging In from an OS/2 Virtual DOS Session
Logging in from an OS/2 virtual DOS session is the same as logging in from a
DOS prompt.
NoteYou cannot log in to a NetWare 4 network from a virtual DOS session unless
the network supports bindery emulation. If a NetWare 4 network supports bindery
emulation, your DOS session is seen as a bindery-based workstation.
Procedure If you added NETX.EXE to your AUTOEXEC.BAT file during the NetWare
Client for OS/2 installation, skip to Step 2.
1. Load the NetWare shell (NETX.EXE) for both global and private sessions.
Type
NETX.EXE
NoteThe OS/2 virtual DOS environment does not support NetWare Directory
Services (NDS) and NetWare 4 VLMs. This means that you can log in to a NetWare
3 server or a NetWare 4 server through bindery emulation. You must first load
NETX.EXE before logging in.
2. Open a virtual DOS Full Screen or DOS Window.
A prompt similar to the following appears:
[C:/]
3. Change to the first network drive.
3a. For global sessions, type
L: <Enter>
NetWare Client for OS/2 maps drive L: to the first network drive
default unles you've changed the parameter in NET.CFG.
3b. for private sessions, use the drive that is the next letter away from
the DOS LASTDRIVE, or your last physical drive.
For example, if you indicated that drive D: is your last DOS drive,
or last physical drive, you could map drive E: to a network drive.
Drive E: is the next letter away from drive D:, your last physical
drive.
4. Type
login server/username <Enter>
Replace server with the name of the bindery server. Replace username with your
username. For example, type
F:\login tsmkt/esayers <Enter>
5. If required, type your password.
Logging In from an OS/2 Virtual DOS Boot Session (VMBOOT)
Logging in from an OS/2 VM Boot environment is the same as logging in from a
DOS prompt.
Important You must first open a VMBOOT full screen or window before initiating
login procedures from the DOS prompt in OS/2.
ΓòÉΓòÉΓòÉ 9.3. Customizing Icons for Global Support ΓòÉΓòÉΓòÉ
Customizing Icons for Global Support
Prerequisites
Checklist
See Information for All Types of Sessions
Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 Installation program. Virtual session
support is enabled by default.
Procedure To set up global NetWare support for an icon, do the following:
1. Open the "DOS Settings" notebook for the DOS or MS Windows icon on your
desktop.
For information on opening DOS Settings, see "DOS Settings" in the OS/2
online "Master Help Index."
2. In the "DOS Settings" Notebook, choose the "Session" tab.
3. On the "Session" screen, choose "DOS Settings . . ."
4. (Optional) Enable the NetWare CAPTURE feature for the session.
4a. Select "DOS_DEVICE" on the "DOS Settings" screen
4b. Type the following line in the "Value" field:
drive:\OS2\MDOS\LPTDD.SYS
Replace drive with the drive letter of your boot drive. Add this line only
if you want to use the CAPTURE command from the virtual session.
NoteIf you want this device driver to be loaded for every virtual session
you open, you can load it in the OS/2 CONFIG.SYS file instead of in the
"DOS Settings" notebook. (See the OS/2 online "Master Help Index" for
information on loading DOS device drivers.)
5. Specify that all drives are available to NetWare.
5a. Select "DOS_LASTDRIVE."
5b. Type the drive letter for your last physical drive in the value field.
For example, if the last physical drive on you client workstation is
drive D:, type D in the value field.
Important The last physical drive for all global sessions will be the last
physical drive indicated in the "DOS_LASTDRIVE" setting.
6. Specify how many files the session can open simultaneously.
6a. Select "DOS_FILES."
6b. Type 214.
7. Choose Global NetWare support.
7a. Select "NETWARE_RESOURCES."
7b. Type GLOBAL in the "Value" field.
You can also choose "GLOBAL" from the drop-down list. Every session you
start from this icon will have global support.
8. Enable virtual IPX for this session.
8a. Select "VIPX_ENABLED."
8b. Select "On."
9. Save and exit "DOS Settings."
10. Load NETX.EXE in each session where you want to log in to the network.
To load NETX.EXE automatically for every session you start from a particular
icon, use Optional Parameters on the DOS Settings notebook for that icon.
In the Optional Parameters box, type /K followed by a space, the directory
path, and the NETX.EXE filename. The file will then execute at the start of
every session opened from that icon.
For example, to load NETX.EXE from the default location, type
/K C:\NETWARE\NETX.EXE
For more about optional parameters, see "parameters, starting programs with"
in the OS/2 online Master Help Index.
To load NETX.EXE automatically for all DOS and MS Windows sessions, put the
following command in an AUTOEXEC.BAT file at the root of your boot drive:
drive:\path\NETX
Replace drive and path with the location of your NETX.EXE file. By default,
NETX is installed in \NETWARE with the NetWare Client for OS/2 files.
NoteIf you want IPX/SPX-only support, don't load NETX. If you don't load NETX,
you can't log in to a NetWare network, but DOS and MS Windows applications can
use the IPX protocol.
ΓòÉΓòÉΓòÉ 9.4. Setting Up Drive Mappings in Global Sessions ΓòÉΓòÉΓòÉ
Setting Up Drive Mappings in Global Sessions
Drive mappings in DOS differ from drive mappings in OS/2. In OS/2, all mapped
drives function like root drives, so drives mapped in OS/2 sessions show up as
root drives in global DOS sessions. Root drives mapped in global DOS sessions
show up as root drives in OS/2 sessions.
Search drive mappings are not used in OS/2. Therefore, search drives mapped in
global DOS sessions are ignored in OS/2 sessions. Also, search drives mapped in
one global DOS session do not apply to other global DOS sessions. To eliminate
confusion, avoid using search drives in a global environment. Instead, set up
your environment as outlined in the following procedures.
Procedure
1. Decide which drives you want mapped in your global environment. Decide which
of those drives need to be included in a search path.
2. Edit your NetWare 4 login script (used in OS/2 sessions) and include MAP
statements for all NetWare drives.
3. Edit your NetWare 3 DOS login script and include MAP ROOT statements for all
NetWare drives.
To edit your NetWare 3 DOS login script, use a text editor to edit the
SYS:MAIL\userID\LOGIN file or use a NetWare 3 utility such as SYSCON.
Use MAP ROOT rather than MAP for consistency between DOS and OS/2 sessions. For
easiest maintenance, both login scripts should contain identical map
statements.
4. Edit your OS/2 CONFIG.SYS file and include the drive letters you want to be
searchable in your PATH statement.
This path is where OS/2 searches for .EXE, .CMD, and .COM files. For example,
to include drive H: in the search path, add the following to your path:
H:\;
If needed, you can also include drive letters in the data path statement
(DPATH). DPATH is where OS/2 searches for non-executable, non-.DLL files.
5. Create a DOS.BAT file which includes a path to the same drives you included
in CONFIG.SYS.
This path is where DOS searches for files. For example, to include drive H: in
the search path, type the following line in your .BAT file:
SET PATH=%PATH%;h:\;
Note that the "%PATH%" appends whatever you type to the existing PATH
statement.
You can't include DPATH statements in the DOS.BAT file. PATH statements are
limited to 123 characters, so try to map drives to the exact directories you
need and minimize the number of subdirectories you specify.
6. Run the .BAT file each time you open a DOS global session.
You can use "Optional Parameters" on the "Settings" notebook. In the "Optional
Parameters" box, type /K followed by a space and the name of the batch (.BAT)
file. The file is then executed at the start of every session opened from that
icon.
For more information about PATH, DPATH, Settings, or Parameters, see the OS/2
online "Master Help Index."
ΓòÉΓòÉΓòÉ 9.5. Customizing Icons For Private Support ΓòÉΓòÉΓòÉ
Customizing Icons For Private Support
Prerequisites
Checklist
See Information for All Types of Sessions.
Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 Installation program. Virtual session
support is enabled by default.
Procedures
To set up private NetWare support for an icon, do the following:
1. Open the "DOS Settings" notebook for the DOS or MS Windows icon on your
desktop.
For more information on opening DOS Settings, see "DOS Settings" in the OS/2
online "Master Help Index."
2. In the "DOS Settings" notebook, choose "Session".
3. On the "Session" screen, choose "DOS Settings . . ."
4. (Optional) Enable CAPTURE for the session.
4a. Select "DOS_DEVICE" on the "DOS Settings" screen
4b. Type the following line in the "Value" field:
drive:\OS2\MDOS\LPTDD.SYS
Replace drive with the drive letter of your boot drive. Add this line only
if you want to use CAPTURE from the virtual session.
NoteIf you want this device driver to be loaded for every virtual session
you open, add it to the OS/2 CONFIG.SYS file instead of the "DOS Settings"
notebook. (See the OS/2 online "Master Help Index" for information on
loading DOS device drivers.)
5. Specify how many files the session can open simultaneously.
5a. Select "DOS_FILES."
5b. Type 214 in the "Value" field.
6. Specify which drives are available to NetWare.
6a. Select "DOS_LASTDRIVE."
6b. Type a drive letter other than Z in the "Value" field.
All drives after this letter are available to the private NetWare
connection in this session. All drives up to this letter are on your local
hard drive or available for use in global sessions.
7. Choose Private NetWare support.
7a. Select "NETWARE_RESOURCES."
7b. Type PRIVATE in the "Value" field.
You can also choose "Private" from the drop-down list. Every session you
start from this icon will its own NetWare login.
8. Enable virtual IPX for this session.
8a.Select "VIPX_ENABLED."
8b. Select "On."
9. Save and exit "DOS Settings."
10. Load NETX.EXE in each session where you want to log in to the network.
To autoload NETX.EXE for every session you start from a particular icon, use
"Optional Parameters" on the "DOS Settings" notebook for that icon.
In the "Optional Parameters" type /K followed by a space, the directory path,
and the NETX.EXE filename. The file is then executed at the start of every
session opened from that icon. For example, to load NETX.EXE from the default
location, type the following:
/K C:\NETWARE\NETX.EXE
For more information about optional parameters, see "parameters, starting
programs with" in OS/2 online Master Help Index.
To autoload NETX.EXE for all DOS and MS Windows sessions, put the following
command in an AUTOEXEC.BAT file at the root of your boot drive:
drive:\path\NETX.EXE
Replace drive and path with the location of your NETX.EXE file. By default,
NETX.EXE is installed in \NETWARE with the NetWare Client for OS/2 files.
NoteIf you want IPX/SPX-only support, don't load NETX.EXE. If you don't load
NETX.EXE, you can't log in to a NetWare network, but DOS and MS Windows
applications can use the IPX protocol.
ΓòÉΓòÉΓòÉ 9.6. Special Instructions for Win-OS2 Icons ΓòÉΓòÉΓòÉ
Special Instructions for Win-OS2 Icons
NoteNetWare and NetWare Client for OS/2 provide name space support. See
"Concepts" for more about name space.
These instructions apply to the MS Windows 3.x support that was shipped with
OS/2 v2.x.
Prerequisites
Checklist Read Information for All Types of Sessions.
Complete Customizing Icons for Global Support or Customizing Icons for
Private Support
Procedures You need several additional files for Win-OS2 NetWare support:
NWIPXSPX.DLL
NETWARE.DRV
TBMI2.COM
NWPOPUP.EXE
NETWARE.HLP
NWNETAPI.DLL
NETAPI.DLL
By default, these files are copied to the \OS2\MDOS\WINOS2\SYSTEM directory on
your boot drive when you install NetWare Client for OS/2. If you are using
OS/2 for Windows, these files are copied to the WINDOWS directory.
Important The TBMI2.COM must be loaded before you run any MS Windows programs
that make IPX or SPX calls. If you did not install TBMI2.COM during the
NetWare Client for OS/2 installation, we recommend that you load it before you
run any MS Windows programs.
TBMI2.COM does not load automatically. To autoload TBMI2.COM for all sessions
started from a single icon:
Procedure 1. Make and use a copy of a DOS icon.
2. Create a batch file (.BAT extension) with the following lines:
drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM
WINOS2.COM
EXIT
Replace drive with the letter of your boot drive.
3. Save the batch file in the following directory:
\OS2\MDOS\WINOS2\SYSTEM
4. Open the "Settings" for the icon.
5. Choose "Program".
6. In the "Optional Parameters" field, type the following
/K drive:\OS2\MDOS\WINOS2\batchfile.bat
Replace drive with the letter of your boot drive. Replace batchfile with
the name of your batch file.
7. Choose "Session".
8. Make sure "DOS Full Screen" is selected.
Each time you choose this icon, TBMI2 is loaded and Win-OS2 is started.
For more information about optional parameters, see "parameters, starting
programs with" in OS/2's online Master Help Index.
To autoload TBMI2.COM for all DOS and MS Windows sessions, put the following
command in an AUTOEXEC.BAT file in the root of your boot drive:
drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM
Replace drive with the letter of your boot drive.
ΓòÉΓòÉΓòÉ 9.7. Special Instructions for DOS_STARTUP_DRIVE Sessions ΓòÉΓòÉΓòÉ
Special Instructions for DOS_STARTUP_DRIVE Sessions
If you want to boot a version of DOS other than the one shipped with OS/2,
refer to the OS/2 online Master Help Index, which explains more about the
DOS_STARTUP_DRIVE feature.
The following sections explain how to set up DOS_STARTUP_DRIVE sessions
globally or privately.
Setting up Global DOS_STARTUP_DRIVE Sessions
Prerequisites
See Information for All Types of Sessions
Set up your session to boot from another version of DOS. This involves
several tasks, such as creating a boot image file, and setting
DOS_STARTUP_DRIVE. You may want to set up another partition on your hard drive
(although not necessary), as well as do certain other tasks using the VMDISK
utilitly. See the OS/2 online "Master Help Index."
Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 installation program. Virtual session
support is enabled by default.
Set up your session for global NetWare support by following the instructions
in Customizing Icons for Global Support or Customizing Icons for Private
Support and Setting Up Drive Mappings in Global Sessions.
Procedures:
1. Add the following lines to the CONFIG.SYS file on the DOS diskette or
partition you boot from:
device=drive:\os2\mdos\fsfilter.sys
device=drive:path\dosvipx.sys
lastdrive=last physcial drive
Replace drive and path with the drive and path names where the NetWare
Client for OS/2 files are located.
Type the lastdrive line only if you want the last global drive to be
something different than the last drive in use by OS/2 at the time you
start the virtual session.
2. Load NETX.EXE
Setting Up Private DOS_STARTUP_DRIVE Sessions
Prerequisites
See Information for All Types of Sessions
Set up your session to boot from another version of DOS. This involves
several tasks such as creating a boot image file, and setting
DOS_STARTUP_DRIVE. You may want to set up another partition on your hard drive
(although not necessary), as well as do certain other tasks using the VMDISK
utilitly. See the OS/2 online "Master Help Index."
Make sure network support for virtual sessions is enabled. If not, enable it
by running the NetWare Client for OS/2 installation program.
Set up your session for private NetWare support by following the
instructions in Customizing Icons For Private Support.
Procedures
1. Add the following lines to the CONFIG.SYS file on the DOS diskette or
partition you will boot from:
device=drive:\os2\mdos\fsfilter.sys
device=drive:path\dosvipx.sys
files=214
lastdrive=letter
Replace drive: and path with the drive and path names where the NetWare
Client for OS/2 files are located. Replace letter with the last local
drive accessible to the session for NETX.EXE or Z for VLMs. NetWare drives
start after this letter.
NoteThe FSFILTER.SYS driver provided by OS/2 gives the DOS_STARTUP_DRIVE
session access to OS/2 HPFS drives and Named Pipes support. See the OS/2
documentation for more information about FSFILTER.SYS.
2. Load the NetWare Client for DOS and MS Windows software.
2a. Follow the directions in NetWare Client for DOS and MS Windows. Use
the software on the NetWare Client for DOS and MS Windows diskette,
WSDOS_1.
2b. To load NETX.EXE for NetWare 3 support, use the software on the
NetWare Client for OS/2 diskette, WSOS2_1. Load NETX.EXE in each session
where you want to log in to the network.
To autoload NETX.EXE for every session you start from a particular icon,
use "Optional Parameters" on the "DOS Settings" notebook for that icon.
In the "Optional Parameters" type /K followed by a space, the directory
path, and the NETX.EXE filename. The file is then executed at the start of
every session opened from that icon. For example, to load NETX.EXE from
the default location, type the following:
/K C:\NETWARE\NETX.EXE
For more information about optional parameters, see "parameters, starting
programs with" in OS/2 online Master Help Index.
To autoload NETX.EXE for all DOS and MS Windows sessions, put the
following command in an AUTOEXEC.BAT file at the root of your boot drive:
drive:\path\NETX.EXE
Replace drive and path with the location of your NETX.EXE file. By
default, NETX.EXE is installed in \NETWARE with the NetWare Client for
OS/2 files.
NoteIf you want IPX/SPX-only support, don't load NETX.EXE. If you don't load
NETX.EXE, you can't log in to a NetWare network, but DOS and MS Windows
applications can use the IPX protocol.
Network drives mapped in an OS/2 session show up as local drives in a private
DOS_STARTUP_DRIVE session.
ΓòÉΓòÉΓòÉ 9.8. Disabling Network Support in All Virtual Sessions ΓòÉΓòÉΓòÉ
Disabling Network Support in All Virtual Sessions
To disable all network support, run the NetWare Client for OS/2 Installation
program and deselect "Support for DOS and Windows Sessions." Then reboot your
machine. This keeps VIPX.SYS and VSHELL.SYS from loading.
To re-enable support, run the install and select "Support for DOS and Windows
Sessions."
ΓòÉΓòÉΓòÉ 9.9. Setting Up Named Pipes for Virtual DOS and Windows ΓòÉΓòÉΓòÉ
Setting Up Named Pipes for Virtual DOS and Windows
Important This section applies to virtual DOS and Windows sessions only.
Virtual DOS and MS Windows sessions can function as Named Pipes clients; they
cannot function as Named Pipes servers.
If you've enabled Named Pipes support for OS/2 sessions, you automatically have
Named Pipes support for virtual DOS sessions. See "Installing Named Pipes for
OS/2"
Important: Do not load the Named Pipes extender (DOSNP.EXE) in virtual DOS and
MS Windows sessions. If you want Named Pipes support in either of the following
situations, see those sections:
For Virtual MS Windows SQL Named Pipes Clients
For Sessions with DOS_STARTUP_DRIVE Set
ΓòÉΓòÉΓòÉ 9.10. For Virtual MS Windows SQL Named Pipes Clients ΓòÉΓòÉΓòÉ
For Virtual MS Windows SQL Named Pipes Clients
Verify that the NETAPI.DLL file from the \WINDOWS subdirectory on the WSOS2_1
diskette was copied to one of the following locations on your hard disk:
The \OS2\MDOS\WINOS2 subdirectory (which contains WINOS2.COM)
The \OS2\MDOS\WINOS2\SYSTEM subdirectory (which contains the MS Windows
KERNEL.EXE)
The directory of the application that runs Named Pipes
Warning This NETAPI.DLL is an MS Windows file, not an OS/2 file, and is
provided specifically for MS Windows SQL Named Pipes Windows clients. Do not
copy it over the NETAPI.DLL in the \NETWARE directory.
ΓòÉΓòÉΓòÉ 9.11. For Sessions with DOS_STARTUP_DRIVE Set ΓòÉΓòÉΓòÉ
For Sessions with DOS_STARTUP_DRIVE Set
Sessions set with DOS_STARTUP_DRIVE boot from a version of DOS other than the
one included in OS/2. The OS/2 online "Master Help Index" explains more about
the DOS_STARTUP_DRIVE feature.
If you use DOS_STARTUP_DRIVE to boot a session, you do not need to get Named
Pipes support from Novell. Instead, load the FSFILTER.SYS driver provided by
OS/2.
Load the FSFILTER.SYS driver in the CONFIG.SYS file for the DOS_STARTUP_DRIVE
session. (CONFIG.SYS is bound into the image file you boot the session from.
See your OS/2 documentation.)
To load the FSFILTER.SYS driver, do the following:
Procedure
1. Open CONFIG.SYS for the DOS_STARTUP_DRIVE session in a text editor.
2. On a new line in the file, type a line to load FSFILTER.SYS.
For example, type
DEVICE=C:\OS2\MDOS\FSFILTER.SYS
3. Save and exit CONFIG.SYS
See your OS/2 documentation for more information about loading FSFILTER.SYS in
CONFIG.SYS.
Important: Do not load the Novell Named Pipes Extender for DOS in the
DOS_STARTUP_DRIVE session. It will conflict with the OS/2 Named Pipes driver.
ΓòÉΓòÉΓòÉ 9.12. Setting Up NetBIOS for Virtual DOS and MS Windows ΓòÉΓòÉΓòÉ
Setting Up NetBIOS for Virtual DOS and MS Windows
This section applies to virtual DOS and MS Windows sessions under OS/2 only. To
set up NetBIOS on an actual DOS or MS Windows workstation, see the NetWare
Client for DOS and MS Windows documentation.
NetWare Client for OS/2 and the IBM LAPS program both support the NetBIOS
protocol in a virtual session. However, the type of support is different.
NetWare NetBIOS Support
NetWare NetBIOS support is not virtualized. This means that the session will
not use the same NetBIOS driver that is used by OS/2 sessions.
Instead, you must load the NETBIOS.EXE TSR program in the session, just as you
would to get NetBIOS support on an actual DOS workstation.
When you use NETBIOS.EXE in a virtual session, you can't get NetBIOS
connections from OS/2 sessions or from any other DOS or MS Windows sessions
until NETBIOS.EXE is unloaded. You will only have one NetBIOS connection from a
single virtual session. This is true even if your OS/2 NetBIOS driver appears
to be loaded.
As the following diagram shows, NetWare NetBIOS support for a single DOS
session goes through NETBIOS.EXE and VIPX.
IBM LAPS NetBIOS Support
Prerequisites
Γûá Enable IPX support for virtual sessions. See "Customizing Icons for Global
Support" or "Customizing Icons For Private Support."
ΓûáDisable NetBIOS support for OS/2 sessions. Novell's NetBIOS solution for DOS
boxes is not virtual and doesn't allow other NetBIOS drivers to be running at
the same time. Disable NetBIOS support by running the NetWare Client for OS/2
installation program and deselecting "NetBIOS Emulation for OS/2." "Setting Up
the Novell NetBIOS Driver" explains how to run the installation program.
Procedure Follow the instructions in the NetWare Client for DOS and MS Windows
manual. Use that documentation to
1. Load NETBIOS.EXE in a single DOS session.
2. Configure NetWare NetBIOS for DOS if necessary.
The LAPS NetBIOS support is virtualized, meaning that you do not have the
single-connection limitation. You do not have access to this virtualized
support unless you have the LAPS protocols, included with both Extended
Services and LAN Services from IBM.
As the following diagram shows, LAPS virtual NETBIOS support goes through
LANVDD and LANPDD. It uses the NETBIOS.OS2 interface to communicate with either
the Novell or IBM NetBIOS driver.
LAPS NetBIOS support follows the NetBIOS 3.0 (NB30) standard. You can run
NetBIOS applications in a virtual session even if those applications do not
conform with NB30. However, the need for increasing resources in a session is
more likely when running non-NB30 applications.
Avoiding Resource Errors
Your virtualized NetBIOS sessions can be supported by Novell's OS/2 NETBIOS.SYS
driver or by Extended Services's OS/2 NETBEUI.OS2 driver or by both.
When virtual sessions are supported by Novell's OS/2 NetBIOS driver, be aware
of a potential resource limitation.
noteIf you have previously followed the steps in Configuring NETBIOS.OS2 with
PROTOCOL.INI, you are using Novell's driver.
LAPS NetBIOS support for virtual sessions follows the NetBIOS 3.0 (NB30)
standard. Among other things, a NetBIOS 3.0 application reserves a certain
number of names, commands, and sessions when it first executes.
If you run NetBIOS applications in several virtual sessions, all resources in
one of the NetBIOS components must be reserved and additional applications will
not run. You see a resource error when you try to make NetBIOS connections.
You can minimize the possibility that NetBIOS will run out of resources by
doing both or either of the following:
Whenever you're using virtual NetBIOS connections, increase the default
resources allowed for the NETBIOS driver in NET.CFG.
Configuring the Driver explains how to increase the defaults for the OS/2
NetBIOS driver.
Specify the resources consumed for each virtual session you use. How to
specify resources is explained below.
Prerequisites
Checklist Install Extended Services with NetBIOS support. See the Extended
Services documentation.
Install LAN Services if you have it. See the LAN Services documentation.
Install NetWare Client for OS/2 with NetBIOS support. Setting Up the Novell
NetBIOS Driver explains how to do this.
Configure NETBIOS.OS2 to use both Novell and IBM drivers. Configuring
NETBIOS.OS2 with PROTOCOL.INI explains how to do this.
Procedures
These instructions explain how to set resource information for Extended
Services virtualized NetBIOS. This information is stored with a program called
LTSVCFG.COM.
The LTSVCFG.COM program is included with LAPS in Extended Services and LAN
Services.
Procedure
1. Open the virtual session.
2. Execute LTSVCFG.COM with the command line parameters you need.
For example, to set the number of NetBIOS commands to 12, type the following:
LTSVCFG.COM C=12
Three parameters that apply to NetBIOS resources are:
s="number of NetBIOS sessions"
n="names"
c="commands"
For more information about these and other NetBIOS parameters, see the LAPS
documentation on NetBIOS.
Important You cannot set parameters for LTSVCFG.COM to amounts higher than
amounts set for the NETBIOS.OS2 or NETBIOS.SYS driver. The default sessions,
names, and commands settings for the NETBIOS.SYS driver are:
Sessions=16
Names=24
Commands=32
You may have changed these defaults in your NET.CFG file.
ΓòÉΓòÉΓòÉ 10. Backing Up Your Workstation ΓòÉΓòÉΓòÉ
Backing Up Your Workstation
Overview
The network supervisor or backup supervisor can back up your OS/2 workstation
to the network. To allow access, run the NetWare TSA_OS2 (Target Service Agent)
program on your workstation.
The TSA_OS2 program runs as an application in an OS/2 session. You can continue
working in other sessions while TSA_OS2 is running on your workstation.
Whenever the TSA_OS2 is running, SBACKUP or another backup program can access
the hard drive data.
The TSA_OS2 is installed automatically on the hard drive when you install the
NetWare Client for OS/2 software. An icon for the TSA_OS2 is placed in the
Novell group on your desktop.
With the TSA_OS2 program, you can specify:
Γûá Which users on the network can access your hard drive
Γûá What password must be typed in the backup program before accessing your hard
drive
Γûá Which drives on the hard disk can be backed up
Starting TSA_OS2 Manually
This section explains how to start TSA_OS2 manually by choosing its icon on
your desktop.
Prerequisites
Load TSA_OS2.NLM on the server. See Supervising the Network for more
information.
Install NetWare Client for OS/2.
Procedure 1. Choose the "Novell" icon on your OS/2 desktop.
The "Novell-Icon View" window appears.
2. From the "Novell-Icon View" window on your desktop, choose the NetWare TSA
icon for the TSA_OS2.EXE program.
The TSA_OS2 main window appears.
3. Choose the features you want from the menu bar.
For more information about this feature, choose "Help.".
Starting TSA_OS2 Automatically
You can set up TSA_OS2 to start each time you boot your machine. To do this
Γûá Place your TSA_OS2 icon in the "Startup" folder. This section explains how
to put the icon in the "Startup" folder.
Γûá Set up your TSA_OS2.CFG file. Setting up your TSA_OS2.CFG file is explained
in the next section.
Prerequisites
Load the TSA_OS2.NLM on the server. See Supervising the Network for more
information.
Install NetWare Client for OS/2.
Procedure 1. Open the "OS/2 System" folder on your desktop.
The "OS/2 System" window appears.
2. Open the "Startup" folder from the "OS/2 System" window.
The "Startup" window appears.
3. Without closing the "Startup" window, open the "Novell" group on your
desktop.
The "Novell" window appears.
4. Drag the TSA_OS2.EXE icon from the "Novell-Icon View" window into the
"Startup" folder.
Whenever you reboot your workstation, the TSA_OS2 program will start
automatically.
Important If backups at your site are done after hours, remember to leave the
OS/2 workstations turned on or the backup supervisor will not be able to
access the hard disk.
Setting Up Your TSA_OS2.CFG File
You can create a text file called TSA_OS2.CFG to store settings for TSA_OS2.
These settings are read by TSA_OS2 each time the program starts up. The
parameters you can type in the configuration file are listed below.
List of TSA_OS2.CFG parameters
WSName
The Target Service name you assign to your workstation. Do not use spaces
in the workstation name.
WSName JO_OS2
ServerName
The name of the server where the Target Service Agent Router NLM is
loaded.
ServerName SALES_MKTG
UserName
The User objects you allow to attach to the OS/2 workstation. Repeat this
line for each User object. If you want to specify a password, specify it
on the same line as the username.
The username must be one defined on the network. The password is unique to
your workstation, not the same password the user types to access the
network. If you specify a password, the backup administrator will have to
type that password in the backup program.
UserName NANCY
or to set a password of NEATO:
UserName NANCY NEATO
HideResource
The drives you do not want to be backed up. Repeat this line for each
drive. The colon after the driver letter is allowed, but not required.
HideResource C
HideResource D:
AutoRegister
Automatically register with the Target Service Router NLM on the server
whenever your workstation boots. To use this parameter, specify a valid
WSName, ServerName, and UserName.
AutoRegister ON
or
AutoRegister OFF
TempFilesDir
The location on your hard drive where the backup program can temporarily
store files during backup. These files are removed when backup is
completed. Do not use spaces in the directory name.
If you do not specify this parameter, the temporary directory is located
in the root of the directory where you executed TSA_OS2.EXE.
TempFilesDir C:\TEMP_TSA
The following is a sample TSA_OS2.CFG configuration file:
WSName Joe's_Machine
ServerName SALES_MKTG
UserName FredJ
UserName Mark
UserName admin
UserName nancy NEATO
HideResource c:
hideresource b:
AUTOREGISTER on
tempfilesdir c:\temp_os2
The file is not case-sensitive.
ΓòÉΓòÉΓòÉ 11. Using Remote Program Load ΓòÉΓòÉΓòÉ
Using Remote Program Load
Topics Discussed
Prerequisites
Creating Users and Granting Rights
Installing OS/2 Files for RPL Workstations
Installing RPL Files for RPL Workstations
Setting Up RPL Workstations
Using RPL on Workstations with Hard Disks
Configuring NetWare Client for OS/2 for RPL Workstations
Overview
ImportantTo install Remote Program Load (RPL), you must have Supervisor object
rights to the NetWare Server(s) that the workstation will attach to.
RPL lets OS/2 workstations boot from network hard disks rather than booting
from a local hard disk.
What Happens When You Add RPL Workstations
When you add RPL workstations to a network, the following actions occur:
Γûá Directories are created.
Γûá Files are created.
Γûá Files are copied.
Γûá CONFIG.SYS is copied and modified.
Directories Are Created
If you have not installed RPL workstation support, the SYS:RPL2 and the \USER
and \COMPUTER directories will be created on each server.
Also the following directories will be created for each workstation you add:
Γûá A user's home directory under the \USER directory.
This directory has the same name as the username you specify. For example,
a user named JADAMS would have a home directory of
SYS:RPL2\USER\JADAMS
If a logical name was specified (for example, LAB_1), then the home
directory would be
SYS:RPL2\USER\JADAMS\LAB_1
Γûá A user's node address directory under the \COMPUTER directory.
This directory has the same name as the last 11 characters of the
workstation node address. For example, if the node address is
2223345BBBBB, the node address directory would be
SYS:RPL2\COMPUTER\223345BB.BBB
Γûá A subdirectory containing the OS/2 desktop in each user's home directory.
This directory is called OS!2_2.0_D if you're installing from a FAT drive
and "OS2 20 Desktop" if you're installing from an HPFS drive.
Γûá A \SPOOL subdirectory in each user's home directory.
This directory contains all desktop printing files.
Files Are Created
Γûá A file called CONFIG.WSS is created in each user's node address directory on
the server.
This file tells OS/2 to use the OS2.INI, OS2SYS.INI, and CONFIG.SYS files
from the user's home directory on the network instead of trying to find
these files in their regular locations on a local drive.
It also tells OS/2 to use the desktop files and \SPOOL subdirectory from
the user's home directory on the network rather than from a local hard
disk.
Γûá A BOOTCONF.SYS file is created in the SYS:LOGIN directory.
If a BOOTCONF.SYS file exists (from other installations of RPL
workstations), the information for the new workstations is added to the
beginning of the file.
This file tells the server which boot image file to use for each
workstation and contains lines identifying which RPL workstation uses
which type of network board. For example, a line for an NE2000 workstation
might be as follows:
0xDOC20,1b0276A32222=NE2000.RPL
See Format of BOOTCONF.SYS File for an explanation of the lines in the
BOOTCONF.SYS file.
Files Are Copied
All files in the \DESKTOP and \SPOOL subdirectories are copied from the
local drive of the OS/2 workstation to the server. Also, all files in
CONFIG.WSS are copied.
These files allow RPL workstations to load customized versions of OS/2 and
the OS/2 desktop.
CONFIG.SYS Is Copied and Modified
A CONFIG.SYS file is copied from the local drive of the OS/2 workstation
you are installing from to each user's subdirectory on each server.
This CONFIG.SYS is modified slightly for each user. The line that loads
HPFS is commented out, and the directory in the SWAPPATH line is changed.
This CONFIG.SYS is modified for each user. The line that loads HPFS is
commented out, and the directory in the SWAPPATH line is changed.
All lines beginning with IFS= are commented out before the IFS=NWIFS line.
The NWIFS line must be the first installable file system loaded.
If the user wants to run a CD-ROM drive from the RPL workstation, the
IFS=CDFS line must be moved to after the NetWare Requester statements in
CONFIG.SYS.
Also, disk caching is turned off and the ODI driver is changed to the
driver you selected.
Directory Structure for RPL Workstation Support shows the complete network
directory structure for remote workstations.
ΓòÉΓòÉΓòÉ 11.1. Prerequisites ΓòÉΓòÉΓòÉ
Prerequisites
Three computers are needed to install an RPL workstation:
Γûá The server that the RPL workstation will attach to
Γûá A computer with OS/2 and NetWare Client for OS/2 installed that can access
the server (referred to as the client workstation).
Γûá A computer to be used as the RPL workstation refered to as the RPL
workstation.
There are prerequisites for each of these three computers.
Prerequisites for the NetWare Server
Checklist The server must be running either NetWare 3 or 4.
You must have Supervisor object rights to the server that the RPL workstation
will attach to.
Enough disk space must be on the server for RPL workstation installation. You
need 30 MB for OS/2 plus enough space for additional files you need.
Prerequisites for the Client Workstation
Checklist
Make sure OS/2 is installed on the workstation C: drive. It must be drive C:.
Make sure that NetWare Client for OS/2 is installed in the \NETWARE
directory.
Make sure the client workstation is connected to the server.
If drive C: has HPFS, make sure the OS/2 name space is loaded for volume SYS:
or the server where the remote workstation files will be installed.
Move or delete all your personal files that are on drive C:. (The
installation program copies all files from drive C: to the server.)
Make sure the desktop is arranged in the way you want the RPL workstation to
appear. The RPL workstation's desktop will look like the desktop of the
workstation you're installing from.
Make sure the workstation only loads the programs that the RPL workstations
need. Programs can be loaded from CONFIG.SYS, .CMD files, or the Startup
folder.
Make sure all programs needed by RPL workstations are located on drive C:
(this only applies to programs on the hard drive). For example, make sure your
E-mail program on C:\EMAIL does not store mail files in the D:\MYMAIL directory
or use E:\TEMP for initialization files. The RPL workstations will not have
drives D: or E: available.
If you set up PS/2 computers as RPL workstations, obtain an OS/2 installation
diskette . If you use PS/2 computers as RPL workstations, the program copies
some files form this diskette.
Prerequisites for the RPL Workstation
Checklist RPL workstations must have network boards with Remote Boot PROMs
attached. Remote Reset PROMs allow workstations to connect to the network so
that boot information can be accessed.
Determine the type of Remote Boot PROM you have. The RPL workstation
installation will ask if you have a "New Enhanced Boot PROM" or an "Older Style
Boot PROM." Older Style Boot PROMs were made before 1992. If you don't know
what type of PROM you have, find the part number and call the PROM
manufacturer.
noteIBM token ring EPROMS are always considered New Enhanced Boot PROMs, no
matter what year they were manufactured.
If you have New Enhanced Boot PROMs, make sure RPL.NLM is loaded on the
server. Older style boot PROMs don't require RPL.NLM.
Make sure the workstation is cabled to the network.
Make sure you know the network and node address of the RPL workstation.
Determining Boot PROM Types
IBM Boards
You can use RPL with the following IBM boards:
Γûá PCN2L
Γûá TOKEN
These boards are always considered new enhanced boot PROMs.
Novell Boards
You can use RPL with the following Novell boards:
Γûá NE1000
Γûá NE2000
Γûá NE/2
These boards can have either new enhanced boot PROMs or older style
boot PROMs.
Loading RPL.NLM for IBM Boards or New Enhanced Boot PROMs
Important If you use IBM boards or Novell boards that support New Enhanced
Boot PROMs, use the following procedure.
To set up the server to use RPL with this type of workstation, load and bind
the RPL loadable module on each server.
Procedures 1. At the server console, type
LOAD RPL
NoteRPL.NLM is shipped with NetWare Client for OS/2. It is on WSOS2_1 in the
RPL directory.
2. Type
BIND RPL TO driver PS=servername NODEFAULT
Replace driver with the name of a LAN driver in your server. To bind more
than one driver, use additional bind statements.
Replace servername with the name of the server that has the RPL files.
3. For Ethernet PROMs, bind RPL to the 802.2 frame type.
NoteThe first frame type in NET.CFG must correspond to the frame type that RPL
is bound to. For example, if you typed at the server console prompt:
BIND RPL TO NE2000 [FRAME=ETHERNET_802.2]
The NET.CFG setting on the workstation should look like
link driver ne2000
frame ethernet_802.2
Where Ethernet_802.2 is the first frame type listed.
For more information about the RPL loadable module, see NetWare Utilities
Reference manual.
ΓòÉΓòÉΓòÉ 11.2. Creating Users and Granting Rights ΓòÉΓòÉΓòÉ
Creating Users and Granting Rights
NoteThis procedure only works for NetWare 4 users. NetWare 3 users should use
SYSCON.EXE.
ImportantTo complete the RPL installation, you must have Supervisor object
rights to the server that the RPL workstation will attach to.
You must set up accounts for RPL workstations. Do the following:
Procedures
1. Create the RPL User object.
1a. From the attached client workstation, log in.
1b. At the C:> prompt, type NWADMIN.
The "NetWare Administrator" window appears.
1c. Highlight the Container object that will contain the new user.
1d. From the "Object" menu, choose "Create"
The "New Object" window appears.
1e. Select the "User" icon.
1f. Choose "OK"
The "Create User" window appears.
1g. In the "Login Name" field, type RPL.
RPL is the username each RPL workstation uses to make the initial
connection to the network.
1h. In the "Last Name:" field, type RPL.
1i. Choose "Create."
You are returned to the "NetWare Administrator" window.
2. Repeate Steps 1c through 1i to create a User object for each person who
will use a RPL workstation.
3. Grant access to the RPL User.
ImportantDo not require a password for the RPL User object, or the RPL
workstations can't make the connection. Protect the account by granting
limited access, as explained in Step 4.
The RPL user needs at least read and file scan access to
Γûá The SYS:RPL2 directory
Γûá The SYS:RPL2\COMPUTER directory and all its subdirectories
These directories are created automatically during RPL workstation
installation.
4. Grant minimal access rights to each RPL workstation user.
All RPL workstations need
Γûá File scan and read access to the SYS:RPL2 directory
Γûá File scan and read access the \OS2 and \NETWARE subdirectories under
SYS:RPL2
Γûá Supervisory access rights to their home directories under SYS:RPL2\USER
These directories are created automatically during RPL workstation
installation.
Users do not have to be given access to other users' home directories under
SYS:RPL2\USER
Supervising the Network explains more about NetWare security and granting and
prohibiting access.
Warning Since the SYS:RPL2 directory becomes the root of drive C: for all RPL
workstations, all RPL users require access to this area. Do not store
confidential files in this directory. Instead, store them in another network
directory where access can be restricted.
You may want to warn users about this lack of privacy and encourage them to
store data in their home directories (for example, C:\USER\MARY) or in another
location on the network.
ΓòÉΓòÉΓòÉ 11.3. Installing OS/2 Files for RPL Workstations ΓòÉΓòÉΓòÉ
Installing OS/2 Files for RPL Workstations
What Happens When You Install OS/2 Files
When you install OS/2 files for RPL workstations, the following actions occur:
Γûá A SYS:RPL2 directory is created on each server you select.
All RPL workstations use this directory as if it is their local boot
drive. Once RPL users log in, they can access all information in this
directory.
Since the SYS:RPL2 directory is on the server and not on a local disk,
NetWare security still applies. For example, you can limit RPL users'
access to specific directories and files. "Creating Users and Granting
Rights" explains more about securing the SYS:RPL2 directory and its
subdirectories.
NoteOS/2 1.3 RPL workstations used a directory called SYS:RPL. This directory
is not erased when the SYS:RPL2 directory is created. OS/2 version 1.3 RPL
workstations and OS/2 version 2.10 RPL workstations can both boot on the same
network.
Γûá Every file from workstation drive C: is copied to the SYS:RPL2 directory on
the server.
Complete the steps in this section if you are
Γûá Setting up RPL workstations for the first time.
Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x.
Γûá Upgrading OS/2 on the server (i.e. from OS/2 2.0 to OS/2 2.1).
Γûá Adding a server to the network where RPL workstations attach (only for the
server you add).
Important If you use older style boot PROMS, don't do the steps in this
section every time you add an RPL workstation to the network. See Setting Up
RPL Workstations.
Important RPL files must be installed on all network servers. If some servers
don't use RPL support, use the following SET paramter at each server's console
prompt, or include in each server's AUTOEXEC.NCF file, and the servers will
not respond to remote PROMs:
SET RESPOND TO GET NEAREST SERVER = OFF
If you set this parameter on each server, the server will not respond to
Remote Reset PROMs and it can't boot RPL workstations, but you won't need to
install the files for RPL workstations support on that server. For more
information about the SET command, see Utilities Reference.
We recommend that you establish a separate physical network for RPL users. Put
only the servers on this network that are need to support the number of RPL
users you have. If you want, connect this network to other networks at your
site through routers. This setup saves time and server space.
Procedures
1. On the client workstation, log in to the server where you want the OS/2
files for RPL workstations.
2. Open the NetWare Requester for OS/2 installation program.
The "NetWare Requester for OS/2 Installation Utility" window appears. Use
the online help as necessary.
3. From the "Installation" menu, choose "Remote workstations. . ."
The "Remote Workstation Installation" window appears.
NoteThe "Copy All Files and Setup Workstation..." option has three separate
components: copying OS/2 files, copying RPL files, and setting up RPL
workstations. Each of these procedures are explained individually.
4. Select "Only Copy OS/2 Files . . . " and choose "OK"
You can choose other actions from the "Remote Workstation Installation"
screen.
5. Choose the servers you want the files copied to.
You are attached to the servers you select. The files must be installed on
all servers on the local net (cable segment with same address).
6. Choose "OK."
All OS/2 and NetWare Client for OS/2 files are copied to the servers.
7. After the files are copied, do the following.
If you want to . . .
Do this . . .
Copy RPL files
Without exiting the installation program, go to Installing RPL Files for
RPL Workstations
Add RPL workstations to the network
Without exiting the installation program, go to Setting Up RPL
Workstations
Configure NetWare Client for OS/2 for RPL workstations
Without exiting the installation program, go to Configuring the NetWare
Client for OS/2 for RPL Workstations
Exit the installation program
Choose "Close" from the system menu in the upper left corner of the
Installation window.
ΓòÉΓòÉΓòÉ 11.4. Installing RPL Files for RPL Workstations ΓòÉΓòÉΓòÉ
Installing RPL Files for RPL Workstations
What Happens When You Install RPL Files
When you use the installation program to install RPL workstation support, the
following actions occur.
Γûá Directories are created.
Γûá Files are copied.
Directories Are Created
Γûá SYS:RPL2 is created if it doesn't already exist
Γûá The \USER and \COMPUTER subdirectories are created under SYS:RPL2 on each
server.
See Directory Structure for RPL Workstation Support for the complete directory
structure created when you install remote workstation support and add RPL
workstations.
Files Are Copied
The following RPL files are copied to the SYS:LOGIN directory:
Γûá NE2.200
Γûá NE2000.200
Γûá NE1000.200
Γûá RPLOS2.200
Γûá RBOOT.RPL
Γûá ETHER.RPL
Γûá TOKEN.RPL
These files have different names than the RPL files used to boot OS/2 1.3.
OS/2 1.3 RPL boot files are also located in the SYS:LOGIN directory.
The following files are copied to the SYS:RPL2 directory:
Γûá MINI.IFS
Γûá MICRO.IFS
Procedure
Complete the steps in this section if you are:
Γûá Setting up RPL workstations for the first time.
Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x.
Γûá Installing a new version of NetWare Client for OS/2.
Γûá Adding a server to the network where RPL workstations attach (only for the
server you add).
Don't do the steps in this section every time you want to add an RPL
workstation to the network. See Setting Up RPL Workstations.
Important All RPL files must be installed on each server on the network. There
is no way to specify which server an RPL workstation will initially establish
a connection with.
We recommend that you establish a separate physical network for RPL users. Put
only the servers on this network that are needed to support the number of RPL
users you have. If you want, connect this network to other networks at your
site through routers. This setup saves time and server space.
Procedures:
1. On the client workstation, open the NetWare Client for OS/2 installation
program.
The "NetWare Requester for OS/2 Installation Utility" window appears. Use
online help as necessary.
2. From the "Installation" menu, Choose "Remote workstations. . ."
The "Remote Workstation Installation" window appears.
NoteThe Copy All Files and Setup Workstations... option has three separate
components: copying OS/2 files, copying RPL files, and setting up RPL
workstations. Each of these procedures are explained individually.
3. Choose "Only Copy RPL Files . . ."
You can also choose other actions from the "Remote Workstation
Installation" screen.
4. Choose the servers you want the RPL files copied to.
You will be attached to the servers you select. The RPL files must be
installed on all servers on the local net (cable segment with same
address).
5. Choose "OK."
All RPL boot files are copied to the servers.
6. Select the source drive for the RPL files.
The default is the drive where INSTALL.EXE was loaded. If you loaded
INSTALL.EXE from the hard drive, change this to your floppy drive and
insert the first installation diskette in it.
7. Choose "OK".
8. After the files are copied, do the following.
If you want to . . .
Do this . . .
Add RPL workstations to the network
Without exiting the installation program, go to Setting Up RPL
Workstations
Configure NetWare Client for OS/2 for RPL workstations
Without exiting the installation program, go to Configuring the NetWare
Client for OS/2 for RPL Workstations
Exit the installation program
Choose "Close" from the system menu in the upper left corner of the
Installation window.
ΓòÉΓòÉΓòÉ 11.5. Setting Up RPL Workstations ΓòÉΓòÉΓòÉ
Setting Up RPL Workstations
What Happens When You Set Up RPL Workstations
Each RPL workstation you boot from the network must be added to the RPL setup
on the network. You identify to each server the user for that workstation, the
node address, and the network board.
RPL workstations are added by running the NetWare Client for OS/2 installation
program from a workstation that has OS/2 installed on drive C:.
Complete the steps in this section on each server if you are
Γûá Setting up RPL workstations for the first time
Γûá Upgrading existing RPL workstations from OS/2 1.3 to OS/2 2.x
Γûá Adding RPL workstations to the network
NoteWhenever possible, use the same type of network board in all RPL
workstations. This saves you time when you install and configure RPL
workstations.
If the installation program is already running, go to Step 4.
Procedure
1. Log in from the client workstation.
2.Open the "Novell" group icon on the desktop.
3.Choose the "Install" icon in the "Novell-Icon View" window.
The "NetWare Workstation for OS/2 Installation Utility" window appears.
4. From the "Installation" menu, choose "Remote workstations. . ."
The "Remote Workstation Installation" menu appears.
NoteThe Copy All Files and Setup Workstations... option has three separate
components: copying OS/2 files, copying RPL files, and setting up RPL
workstations. Each of these procedures are explained individually.
5. Choose "Only SetUp Workstations. . ."
6. Choose "OK."
The "Select 1 or More File Servers" window appears.
7. Choose servers on which you want to define RPL workstations.
For a list of available servers, choose "Attach." Then choose the arrow at
the end of the "Server name" field. For more information, use the online
help.
8. When you've selected all the servers you want, choose "OK."
The "Select the type of BOOT PROM in the target workstation" window
appears.
9. Select the type of BOOT PROM you have.
If you have an IBM board or if the board was manufactured during or after
1992, select "New Enhanced BOOT PROM"
If your board was manufactured before 1992, Select "Older style BOOT
PROM".
If you aren't sure what type of board you have, find the board's part
number and contact the board's manufacturer.
Important If you use token ring, the boot PROM is always considered as a New
Enhanced Boot PROM, no matter when it was manuractured.
10. Choose "OK."
The "Add Remote Boot Workstation" window appears.
Different versions of this window appear, depending on the type of BOOT
PROM you selected in Step 9.
11. Complete all fields in the window.
NoteUser name should be the actual name or login name of the person you are
setting up the RPL workstation for. Logical Name becomes the name of the
subdirectory under that user.
For example, if you set up the user name as SUSAN and the logical name is LAB,
the path would read RPL2\USER\SUSAN\LAB.
12. Choose "Add."
13. Exit the installation program.
Using an RPL Workstation with Virtual DOS
RPL workstations are unable to remap drive C:. Even if you are using global
DOS, RPL workstations treat global DOS the same as private DOS.
For example, if you were in global DOS and remapped drive C:, the remapped
drive C: will not show up when you go to a private DOS session.
ΓòÉΓòÉΓòÉ 11.6. Using RPL on Workstations with Hard Disks ΓòÉΓòÉΓòÉ
Using RPL on Workstations with Hard Disks
To use RPL on a workstation with a hard disk, label your hard drive a drive
other than C:. Drive C: must be assigned to the SYS:RPL2 network directory.
OS/2 thinks this network directory is the local drive C:.
Also, you may need to determine whether your hard disk has an operating system
or not, you can format it (FAT) and use it to store your OS/2 SWAPPER.DAT file.
This will cut down on network traffic.
Locating SWAPPER.DAT Locally
Procedure 1. Go to the home directory on the network for the user who will be
using the RPL workstation.
For example, if JOHN will be using the RPL workstation with a hard drive,
go to the following directory:
SYS:RPL2\USER\JOHN
Each user's home directory on the network contains that user's CONFIG.SYS
file and several other OS/2 files. Directory Structure for RPL Workstation
Support shows a complete directory structure.
2. Using a text editor, open the CONFIG.SYS file.
3. In the CONFIG.SYS file, find the line that designates the SWAPPATH.
You can search for SWAPPATH. The line looks like the following:
SWAPPATH=C:\USER\JOHN 2048 2048
Remember that to OS/2, the SYS:RPL2 directory is drive C:.
4. Change the SWAPPATH line to point to the local hard drive.
For example, to point to the root of local drive D:
SWAPPATH=D:\ 2048 2048
5. Save and exit the CONFIG.SYS file.
When you boot the RPL workstation, the SWAPPER.DAT will be stored locally.
ΓòÉΓòÉΓòÉ 11.7. Configuring NetWare Client for OS/2 for RPL Workstations ΓòÉΓòÉΓòÉ
Configuring NetWare Client for OS/2 for RPL Workstations
Configure NetWare Client for OS/2 for RPL workstations by running the NetWare
Client for OS/2 installation program and choosing "Remote workstations . . ."
from the "Configuration" menu.
When you configure RPL workstations, the NetWare Client for OS/2 installation
program puts a NET.CFG configuration file in the home directory of the users
you specify. The home directory is located under SYS:RPL2\USER on each server
on the local network.
The NET.CFG you create with the installation program should be identical on all
servers on the local network so RPL workstations boot the same way each time.
For example, if user JOHN has a NET.CFG file in his user directory on SERVER1,
then a copy of the same NET.CFG file should be placed in his home directory on
SERVER2.
The installation program puts a line in each user's CONFIG.WSS file in the
workstation subdirectory, telling NetWare Client for OS/2 where to find the
NET.CFG file. For example, for John's NET.CFG file, the installation program
puts in the following line:
C:\NET.CFG C:\USER\JOHN\NET.CFG
Important Remember that the SYS:RPL2 directory becomes the root of the C:
drive. If the RPL workstation is using the Ethernet frame type, the frame type
specified in the NET.CFG file must be the same as the frame type used by the
PROM. New Enhanced Boot PROMs use 802.2. Older style boot PROMs use 802.3.
ΓòÉΓòÉΓòÉ 11.7.1. Directory Structure for RPL Workstation Support ΓòÉΓòÉΓòÉ
Directory Structure for RPL Workstation Support
ΓòÉΓòÉΓòÉ 11.7.2. Format of BOOTCONF.SYS file ΓòÉΓòÉΓòÉ
Format of BOOTCONF.SYS file
ΓòÉΓòÉΓòÉ 12. Improving Speed and Security ΓòÉΓòÉΓòÉ
Improving Speed and Security
This chapter discusses three features that help to improve speed and security
on your network.
Improving Speed by Using Packet Burst
Improving Speed by Using Large Internet Packets
Improving Security by Using NCP Packet Signature
ΓòÉΓòÉΓòÉ 12.1. Improving Speed by Using Packet Burst ΓòÉΓòÉΓòÉ
Improving Speed by Using Packet Burst
Packet Burst is a protocol that speeds the transfer of multiple-packet NCP
reads and writes. Packet Burst eliminates the need to sequence and acknowledge
each packet. With Packet Burst, the server or client sends a whole set (or
burst) of packets before it requires an acknowledgment.
Packet Burst reduces network traffic by allowing multiple packets to be
acknowledged. Packet Burst also monitors dropped packets and retransmits only
the missing packets.
At connection time, maximum burst sizes are negotiated with each server. Since
Packet Burst is established with each connection, it's possible to "burst" with
one server but not with another.
Once you establish a Packet Burst connection between a workstation and a
server, the workstation automatically uses Packet Burst whenever an application
requests to write more than three times the maximum packet size of data. This
means that an application doesn't have to be aware of Packet Burst.
Disabling Packet Burst
Packet Burst is enabled at the workstation by default. You can disable it by
adding the following to the workstation's NET.CFG file:
netware requester
packet burst off
ΓòÉΓòÉΓòÉ 12.2. Improving Speed by Using Large Internet Packets ΓòÉΓòÉΓòÉ
Improving Speed by Using Large Internet Packets
Large Internet Packet (LIP) functionality allows the internet packet size to be
increased from the default 576 bytes. By allowing the NetWare packet size to be
increased, LIP enhances transmission over bridges and routers.
In NetWare 4, the workstation requests an acceptable packet size. However,
unlike previous versions of NetWare, the NetWare server doesn't default to 576
bytes when a router is detected.
Instead, the workstation attempts to send larger packets to the server. The
largest packet size that the server accepts is the packet size used to
communicate.
Disabling Large Internet Packets
LIP functionality is enabled by default on the workstation. To disable it,
enter the following to the NET.CFG file:
netware requester
large internet packets off
ΓòÉΓòÉΓòÉ 12.3. Improving Security by Using NCP Packet Signature ΓòÉΓòÉΓòÉ
Improving Security by Using NCP Packet Signature
NetWare Core Protocol (NCP) Packet Signature is an enhanced security feature
that protects servers and clients using NCP by preventing packet forgery.
Without NCP Packet Signature, a network client can pose as a more privileged
client to send a forged NCP request to a NetWare server. By forging the proper
NCP request packet, an intruder could gain Supervisor rights and access to all
network resources.
NCP Packet Signature prevents packet forgery by requiring the server and the
client to "sign" each NCP packet. The packet signature changes with every
packet.
NCP packets with incorrect signatures are discarded without breaking the
client's connection with the server. However, an alert message about the
invalid packet is sent to the error log, the affected client, and the server
console. The alert message contains the login name and the station address of
the affected client.
A two-part process between the client and the server determines the NCP Packet
Signature:
Γûá At LOGIN, the server and the client determine a shared, secret key known as
the session key.
Γûá For each request or response packet, the server and the client calculate a
signature based on the session key, a "fingerprint" algorithm, and the previous
packet's signature. The unique signature is appended to the NCP packet.
If NCP Packet Signature is installed correctly on the server and all of its
clients, it is virtually impossible to forge a valid NCP packet.
NoteThe Packet Burst loadable module, PBURST.NLM (NetWare 3.11 only), must be
loaded on NetWare servers in order for NCP Packet Signature to work. However,
using Packet Burst to transfer data between servers and clients is optional.
NCP Packet Signature Options
Because the packet signature process consumes CPU resources and slows
performance, both for the client and the NetWare server, NCP Packet Signature
is optional.
Several signature options are available, ranging from never signing NCP packets
to always signing NCP packets. Servers and clients both have four signature
levels that can be set.
The signature options for servers and clients combine to determine the level of
NCP Packet Signature on the network.
NoteSome combinations of server and client packet signature levels may slow
performance. However, low CPU-demand systems may not show any performance
degradation. Network supervisors can choose the packet signature level that
meets both their performance needs and their security requirements.
Server Levels
Server packet signature levels are assigned by a SET parameter. See Utilities
Reference for more information.
Client Levels
Packet signature levels at the workstation are assigned by using the following
NET.CFG option:
netware requester
signature level number
Replace number with 0, 1, 2, or 3. The default is 1.
NCP Packet Signature levels
Number Explanation
0 Client does not sign packets (login fails if server is set to 3)
1 Client signs packets only if the server requests it (server option
is 2 or higher)
2 Client signs packets if the server is capable of signing (server
option is 1 or higher)
3 Client signs packets and requires the server to sign packets (or
login will fail)
Effective Packet Signature Levels
The packet signature levels for server and client interact to create the
"effective" packet signature. Some combinations of server and client levels do
not allow logging in.
The table below shows the interactive relationship between the server packet
signature levels and the client signature levels.
Effective Packet Signature of Server and Client
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéIf Server=0 Server=1 Server=2 Server=3 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéClient=0 No packet No packet No packet No login Γöé
Γöé signature signature signature Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéClient=1 No packet No packet Packet Packet Γöé
Γöé signature signature signature signature Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéClient=2 No packet Packet Packet Packet Γöé
Γöé signature signature signature signature Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéClient=3 No login Packet Packet Packet Γöé
Γöé signature signature signature Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
When to Use NCP Packet Signature
NCP Packet Signature is not required for every installation. Some network
supervisors may choose not to use NCP Packet Signature because they can
tolerate certain security risks.
You may not need to use NCP Packet Signature if
Γûá Only executable programs reside on the server.
Γûá All workstation users on the network are known and trusted by the
supervisor.
Γûá Data on the NetWare server is not sensitive; loss or corruption of this data
will not impact operations.
You may want to use NCP Packet Signature if
Γûá An untrustworthy user uses a workstation on the network.
Γûá Someone can easily access the network cabling system.
Γûá There is an unattended, publicly accessible workstation on the network.
The default NCP Packet Signature level is 1 for clients and 2 for servers. In
general, this setting provides the most flexibility while still offering
protection from forged packets. Below are some examples of using different
signature levels.
All Information on the Server Is Sensitive
If an intruder gains access to any information on the NetWare server, it could
damage the company.
The network supervisor should set the server to level 3 and all clients to
level 3 for maximum protection.
Sensitive and Non Sensitive Information Reside on the Same Server
The NetWare server has a directory for executable programs and a separate
directory for corporate finances.
The network supervisor should set the server to level 2 and the clients
(including himself) that need access to corporate finances to level 3. All
other clients remain at the default, level 1.
Users Often Change Locations and Workstations
The network supervisor is uncertain which employees will be using which
workstations, and the server contains some sensitive data.
The network supervisor should set the server to level 3. Clients should remain
at the default, level 1.
Workstation Is Publicly Accessible
An unattended workstation is set up for public access to non-sensitive
information, but another server on the network contains sensitive information.
The network supervisor should set the sensitive server to level 3 and the
unattended client to level 0.
NCP Packet Signature Troubleshooting Tips
This section describes some solutions to problems that may be associated with
using NCP Packet Signature.
Clients Are Not Signing Packets
Make sure each OS/2 workstation has NetWare Client for OS/2 installed.
Make sure that NCP Packet Signature is not turned off in the NET.CFG file.
Clients Cannot Log In
Make sure each workstation has NetWare Client for OS/2 installed.
The following situations do not allow logging in:
Γûá Server packet signature level=3, client packet signature level=0
Γûá Server packet signature level=0, client packet signature level=3
Γûá Utilities are old and do not support NCP Packet Signature
Γûá The NetWare Client for OS/2 software is not version 2.1 and does not support
NCP Packet Signature.
"Error Receiving From the Network" Message
The client is using an old LOGIN.EXE file that does not include NCP Packet
Signature. Make sure the new LOGIN.EXE and other new utilities are installed
in the \OS2 subdirectory on all servers on the network.
Unsecure Clients Log In to Secure Server
The clients are using an old LOGIN.EXE file that does not include NCP Packet
Signature. Make sure the new LOGIN.EXE and other new utilities are installed
in the \OS2 subdirectory on all servers. Add a preferred server statement to
the NET.CFG file for all clients that have access to secure servers (level 3).
ΓòÉΓòÉΓòÉ 13. Using Token Ring Networks ΓòÉΓòÉΓòÉ
Using Token Ring Networks
Overview
If your token ring network includes IBM* source-routing bridges, your computers
use source routing to communicate across those bridges.
This chapter explains how to install and configure source routing on NetWare
servers and OS/2 workstations.
If your network requires source routing, install source-routing software on
both workstations and servers. Novell's source-routing software includes
Γûá ROUTE.NLM (for servers)
Γûá ROUTE.SYS (for OS/2 client workstations)
This software routes only IPX packets.
Other topics discussed include:
Installing Source-Routing on the Server
Installing Source-Routing on the Workstation
Configuring Source-Routing on the Workstation
ΓòÉΓòÉΓòÉ 13.1. Installing Source Routing on the Server ΓòÉΓòÉΓòÉ
Installing Source Routing on the Server
Procedure 1. At the server console, load ROUTE.NLM by typing
LOAD ROUTE
ROUTE.NLM is located in the SYS:SYSTEM directory. You can load it with
command line parameters. You can also load ROUTE.NLM from a startup file.
Utilities Reference explains more about the parameters.
2. (Conditional) If you have two network boards in your server, load ROUTE.NLM
again.
Use the "board" parameter to specify a board number. For example, type
LOAD ROUTE BOARD=02
You can change a source-routing parameter after ROUTE is loaded. Type the
LOAD ROUTE command followed by the parameter you want to change.
ΓòÉΓòÉΓòÉ 13.2. Installing Source Routing on the Workstation ΓòÉΓòÉΓòÉ
Installing Source Routing on the Workstation
Prerequisites
Checklist
Install Netware Client for OS/2 with a TOKEN ODI driver.
Understand source routing. (See the September 1990 Novell Application Notes.)
Procedure 1. Using a text editor, open the CONFIG.SYS file.
For example, to use the OS/2 System Editor at an OS/2 command line, type
E C:\CONFIG.SYS
CONFIG.SYS is always located in the root of your boot drive.
2. In the NetWare Client for OS/2 lines, find the line loading your TOKEN ODI
driver.
If you use Novell-supplied ODI drivers, the driver is called TOKEN.SYS.
NoteIf use LANSUP.SYS and an NDIS driver, you do have an ODI driver loaded. In
this case, find LANSUP.SYS.
3. After the line that loads the TOKEN ODI driver, add a line to load the
ROUTE.SYS driver.
Specify the location of ROUTE.SYS. ROUTE.SYS is located where the other
NetWare Client for OS/2 files are, usually in C:\NETWARE.
For example, to load ROUTE.SYS from the default location, type
DEVICE=C:\NETWARE\ROUTE.SYS
4. Save and exit the CONFIG.SYS file.
5. Use the OS/2 "Shutdown" feature to reboot your machine.
ΓòÉΓòÉΓòÉ 13.3. Configuring Source Routing on the Workstation ΓòÉΓòÉΓòÉ
Configuring Source Routing on the Workstation
Follow the procedures in this section to
Γûá Determine whether you need to configure source routing, and
Γûá Configure source routing, if needed.
Prerequisites
Checklist
Install NetWare Client for OS/2.
Install source routing on the server. See "Installing Source Routing on the
Server"
Install source routing on the workstation.
Understand source routing thoroughly. This section does not explain
source-routing terminology or how packets are routed. See related IBM
publications, such as IBM Token Ring Network Architecture Reference or the
September 1990 Novell Application Notes.
Procedures 1. Start the NetWare Client for OS/2 installation program.
You can choose the "Installation" icon from the "Novell" group on your
desktop.
2. Choose "This workstation . . ." from the "Configuration" menu.
3. Verify the location of NET.CFG and choose "Edit."
The "Edit NET.CFG" window appears. You can cut and and paste text from the
help window at the bottom of the screen to the "Current NET.CFG File
Contents" window. Use the Key Definitions for the NET.CFG File chart.
4. Select "Token-Ring source routing" from the "NET.CFG Options" box on the
left of your screen.
5. Determine whether to change the configuration for the "def", "gbr", "mbr",
"nodes" and "board" settings under "Token-Ring source routing."
5a. Select one of the five settings.
Example: select "def".
5b. Read the help window at the bottom of the screen to determine whether
to change the configuration for the setting.
You can choose the "Usage," "Description," and "Example" buttons on
the right of the window for more information about the setting you've
selected.
5c.(Optional) To change the configuration, add the configuration lines (as
shown in the "Usage" help window) in the "Current NET.CFG File Contents"
box.
Important You must follow the format requirements explained in the "Format of
NET.CFG Options" topic. To see these requirements, select this topic from the
"NET.CFG Options" box and choose "Usage".
Repeat Steps 5a through 5c for each setting.
6.Choose "Save."
7.Exit the NetWare Client for OS/2 Installation program and use the OS/2
"Shutdown" feature to restart your computer.
ΓòÉΓòÉΓòÉ 13.4. Key definitions for the NET.CFG file. ΓòÉΓòÉΓòÉ
Key definitions for the NET.CFG file
To do this ... Use these keys ...
Highlight text Click and drag with the mouse, or move the cursor with the
arrow keys while holding down the <Shift> key
Copy text <Ctrl><Insert>
Cut text <Shift><Delete> (text will reappear the next time you
refresh the window)
Paste text <Shift><Insert>
Delete text <Ctrl><Delete> (deleted text cannot be pasted)
ΓòÉΓòÉΓòÉ 14. Using Named Pipes ΓòÉΓòÉΓòÉ
Using Named Pipes
The following topics are discussed.
Installing Named Pipes for OS/2
Configuring Named Pipes for OS/2
Special Instructions for SQL Client Workstations
ΓòÉΓòÉΓòÉ 14.1. Installing Named Pipes for OS/2 ΓòÉΓòÉΓòÉ
You must install Named Pipes support on each computer that will use Named Pipes
on the network. In most cases, you must also set certain configuration options
for the protocol.
Named Pipes support between sessions on a single OS/2 client workstation is
provided by the OS/2 operating system.
However, if you need OS/2 sessions to communicate with other computers on the
network using Named Pipes, you must install remote Named Pipes support.
Prerequisite
Install your Named Pipes distributed application. See the documentation for
your application.
Procedure
1. Start the NetWare Client for OS/2 Installation program.
If NetWare Client for OS/2 is not installed, you can start the program
from your WSOS2_1 diskette. Type INSTALL. You can install NetWare Client
for OS/2 at the same time as you install Named Pipes.
If NetWare Client for OS/2 is already installed, start the program by
choosing "Installation" from the "Novell" group on your desktop.
2. Choose "Requester on Workstation" from the "Installation" menu.
3. Verify the target directory and source drive and choose "OK."
4. Select an action from the "Requester Installation" screen based on whether
NetWare Client for OS/2 is installed:
4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
and Copy All Files . . . " and choose "OK."
4b. If NetWare Client for OS/2 is already installed, select "Only Edit
CONFIG.SYS . . ." and choose "OK."
5. Select the ODI LAN driver for your network board and choose "Continue. . ."
6. Select your preferences for NetWare support for DOS and MS Windows
applications and choose "Continue . . ."
7. Select "Remote Named Pipes Support."
8. Set up your workstation as a Named Pipes client or server.
8a. Choose "Client Support Only" to set up your workstation as a Named
Pipes application client.
If your workstation will be a client for the SQL Server distributed
application, you must do some additional steps. After completing this
section and "Configuring Named Pipes for OS/2", go to "Special
Instructions for SQL Client Workstations".
8b. Choose "Client and Server Support" and type a machine name to set up
your workstation as a Named Pipes application server.
Choose "Help" to see the syntax requirements for the machine name.
9. Choose "Save . . ."
10. Verify the filename and location and choose "OK."
If you have not installed NetWare Client for OS/2, the "Copy Requester
Files" screen appears. Continue with Step 11.
If you have previously installed NetWare Client for OS/2, the main
installation menu appears.
11. Choose "Copy" and follow the screens to finish installing NetWare Client
for OS/2.
ΓòÉΓòÉΓòÉ 14.2. Configuring Named Pipes for OS/2 ΓòÉΓòÉΓòÉ
Configuring Named Pipes for OS/2
Novell's Named Pipes support comes with default configuration settings. You may
want to customize the configuration. Follow the instructions below to
Γûá Determine whether you need to change the default configuration for Named
Pipes and SPX.
Γûá Change the configuration if necessary.
You can change the configuration for such features as
Γûá Available number of client and server sessions
Γûá Number of SPX sessions available for Named Pipes and other SPX communication
(Named Pipes uses SPX)
Prerequisite
NetWare Client for OS/2 must be installed.
Procedure 1. Start the NetWare Client for OS/2 Installation program.
The program might already be running if you just installed Named Pipes
support. If the program is not running, choose the "Installation" icon
from the "Novell" group on your desktop.
2. Choose "This workstation . . ." from the "Configuration" menu.
3. Verify the location of the NET.CFG file and choose "Edit."
The "Edit NET.CFG" window appears. You can cut and and paste text from the
help window at the bottom of the screen to the "Current NET.CFG File
Contents" window. Use the Key Definitions for the NET.CFG File chart.
4. Select "Named Pipes" from the "NET.CFG Options" box on the left of your
screen.
5. Determine whether to change the configuration for the "client sessions",
"server sessions" and settings under "Named Pipes."
If you decide not to change the configuration for a setting, no action is
required for that setting.
5a. Select one of the three settings.
For example, select "client sessions."
5b. Read the help window at the bottom of the screen to determine whether
to change the configuration for the setting.
You can choose the "Usage," "Description," and "Example" buttons on
the right of your screen for more information about the setting
you've selected.
5c. (Optional) To change the configuration, add the configuration lines
(as shown in the "Usage" help window) to the "Current NET.CFG File
Contents" box.
Important You must follow the format requirements explained in the "Format of
NET.CFG Options" topic. To see these requirements, select this topic from the
"NET.CFG Options" box and choose "Usage".
Repeat Steps 5a through 5c for each setting.
6. Select "Protocol Stack SPX" from the "NET.CFG Options" box on the left of
your screen.
7. Select the "sessions" setting under "Protocol Stack SPX."
8. Read the help window at the bottom of the screen to determine whether to
change the configuration for "sessions."
You can choose the "Usage," "Description" and "Example" buttons on the
right of your screen for more information about the setting you've
selected.
9. (Optional) To change the configuration, add the configuration lines (shown
in the "Usage" help window) to the "Current NET.CFG File Contents" box.
If you decide not to change the configuration, no action is required for
this step.
Important You must follow the format requirements explained in the "Format of
NET.CFG Options" topic. To see these requirements, select this topic from the
"NET.CFG Options" box and choose "Usage".
10. Choose "Save."
11. Exit the NetWare Client for OS/2 Installation program.
11a. If your workstation will be a client for the SQL Server distributed
application, close the installation program and go to "Special
Instructions for SQL Client Workstations" Do not restart your computer
yet.
11b. If your workstation will not be an SQL client, close the installation
program and use the OS/2 "Shutdown" feature to restart your computer.
ΓòÉΓòÉΓòÉ 14.3. Special Instructions for SQL Client Workstations ΓòÉΓòÉΓòÉ
Special Instructions for SQL Client Workstations
Important This is only for emulated DOS sessions.
OS/2 Client workstations for the SQL Server distributed application must use
special versions of the NETAPI.DLL and NETOEM.DLL files. These files are
contained in a \SQL directory on the WSOS2_1 diskette.
The \SQL NETAPI.DLL contains everything that the default NETAPI.DLL contains
(including the NETBIOS calls), as well as some additional function calls
required by SQL clients and servers.
Complete the following steps to copy these files to the correct location
Procedure 1. Insert the WSOS2_1 diskette into a floppy disk drive.
2. Copy the existing NETAPI.DLL loacated in the \NETWARE subdirectory to
NETAPI.BAK.
3. Create a \NETWARE\INSTALL$.NEW subdirectory.
4. Copy the NETAPI.DLL and NETOEM.DLL files from the \SQL subdirectory on the
diskette to the \NETWARE\INSTALL$.NEW subdirectory.
Warning Be sure to copy the files from the \SQL directory, since there is also
a NETAPI.DLL in the root directory on the diskette. The two NETAPI.DLL files
are not the same.
The \SQL NETAPI.DLL emulates certain features of LAN Manager support that are
required for SQL clients. However, this NETAPI.DLL does not provide full LAN
Manager support. An application that assumes full LAN Manager support if it
finds any LAN Manager calls may not run properly.
5. Use the OS/2 "Shutdown" feature to restart your computer.
ΓòÉΓòÉΓòÉ 15. Using NetBIOS ΓòÉΓòÉΓòÉ
Using NetBIOS
The following topics are discussed in this section:
Determining Which NetBIOS Drivers to Set Up
Setting Up the Novell NetBIOS Driver
Configuring NETBIOS.OS2 with PROTOCOL.INI
Important The NetBIOS protocol was designed for small-scale networks. While
Novell has added functionality to the original specification, Novell's NetBIOS
emulation still works most effectively with small-scale networks. We recommend
that you use SPX instead of NetBIOS if your applications support SPX, your
network contains several thousand workstations, and your LAN segments are
interconnected with more than one router.
Overview
This chapter explains how to set up Novell's NetBIOS driver and how to
configure your workstation for NetBIOS when you also have IBM's Extended
Services or LAN Services NetBIOS installed.
NetWare Client for OS/2 provides a NetBIOS driver, NETBIOS.SYS, that emulates
the NetBIOS protocol.
The NetBIOS provided by Novell is called an emulator because it does not
transmit NetBIOS packets on the network. Instead, NetBIOS packets are
encapsulated in IPX packets, and the IPX packets are transmitted.
IBM Extended Services and LAN Services provide a native NetBIOS driver,
NETBEUI.OS2, rather than an emulation.
ΓòÉΓòÉΓòÉ 15.1. Determining Which NetBIOS Drivers to Set Up ΓòÉΓòÉΓòÉ
Determining Which NetBIOS Drivers to Set Up
When this section refers to the NetBIOS support available with an IBM product
(such as Extended Services), we assume the product includes the files we list.
By default, the files shown here are included in Extended Services and LAN
Services packages. By default, LAPS is included in both packages, although
different NetBIOS components are actually used in each package.
However, the files shown may also be included in other packages. For example,
you may have received the IBM LAPS program without receiving Extended Services.
In this case, you might have the NetBIOS support usually provided by Extended
Services without having the whole Extended Services product. Contact IBM to
resolve any questions about what IBM files you have relating to NetBIOS
support.
Use this section to determine whether your application needs access to the
Novell NETBIOS.SYS driver, the IBM NETBEUI.OS2 driver, or both.
The drivers your application can access depends on the following:
Γûá Whether you have Extended Services or LAN Services installed on your
workstation.
Γûá The interface used by your application.
Your Installed IBM Software
NetBIOS support is provided with:
Γûá Extended Services
Γûá LAN Services
Extended Services
Extended Services NetBIOS support is included in the LAPS programs.
NetBIOS-related pieces of LAPS are
Γûá NETAPI.DLL
Γûá ACSNETB.DLL
Γûá NETBIOS.OS2
Γûá NETBEUI.OS2
Γûá LANPDD
Γûá LANVDD
LAN Services
LAN Services NetBIOS support is included in the LAPS program and in
NETWKSTA.200.
Your Application's Interface
OS/2 NetBIOS applications use Dynamic Link Libraries (DLLs) to interface with
NetBIOS drivers. The DLL your application uses depends on the NetBIOS interface
standard your application follows:
Γûá ACSNETB.DLL
This is IBM's NetBIOS 3.0 (NB30) interface introduced in OS/2 Version 2.0.
Applications written before OS/2 Version 2.0 most likely cannot use it.
Γûá The NETAPI.DLL
This is the original OS/2 NetBIOS Submit interface, supported by LAN
Manager and LAN Server before OS/2 Version 2.0 was released.
You can run applications that use different interfaces at the same time, as
long as you have the support for each interface installed and configured. For
example, you can run an NB30 application and a NetBIOS Submit application on
the same workstation.
Refer to the documentation for your application to determine which NetBIOS
interface it uses; then follow the flowcharts below to see
Γûá Whether the IBM or Novell NetBIOS driver can be accessed by your
application.
Γûá Where to find instructions on setting up the drivers.
Chart Determine What NetBIOS Support You Have for NetBIOS 3.0 (NB30)
applications
Chart Determine What NetBIOS Support You Have for NetBIOS Submit
Applications
ΓòÉΓòÉΓòÉ 15.1.1. Determine what NetBIOS support you have for NetBIOS 3.0 ΓòÉΓòÉΓòÉ
(NB30) applications Determine what NetBIOS support you have for NetBIOS 3.0
(NB30) applications
ΓòÉΓòÉΓòÉ 15.1.2. Determine What NetBIOS Support You Have for NetBIOS Submit ΓòÉΓòÉΓòÉ
Applications Determine What NetBIOS Support You Have for NetBIOS Submit
Applications
ΓòÉΓòÉΓòÉ 15.2. Setting Up the Novell NetBIOS Driver ΓòÉΓòÉΓòÉ
Setting Up the Novell NetBIOS Driver
Do this section only if you were directed here from the flow chart Determine
What NetBIOS Support You Have for NetBIOS Submit Applications because you
Γûá Have a NetBIOS Submit application
Γûá Have Extended Services
Γûá Do not have LAN Services
As the figure below shows, the Novell NetBIOS driver interfaces with Novell's
NETAPI.DLL file when you do not have Extended Services.
NetBIOS Requests through Novell's NetBIOS Driver
As the figure shows, if you use Extended Services, the NETAPI.DLL is the one
from the Extended Services package. This NETAPI.DLL interfaces with a
NETSUB.DLL file from Novell, which in turn works with the Novell NetBIOS
driver.
NetBIOS Requests through Novell's NetBIOS Driver with Extended Services
Installed
Follow the procedures in "Installing the Driver" to use the Novell NetBIOS
driver. The procedures apply whether or not you have Extended Services.
Important If you use Extended Services, you must get an updated NETAPI.DLL file
from IBM. The one shipped with base Extended Services 1.0 does not provide the
intended NetBIOS support.
ΓòÉΓòÉΓòÉ 15.2.1. Installing the Driver ΓòÉΓòÉΓòÉ
Installing the Driver
Prerequisites
Install Extended Services if you have it. See the IBM documentation for
Extended Services.
Install your NetBIOS application. See the documentation for your application.
NoteYou can install NetWare Client for OS/2 from this procedure.
You must install the Novell NetBIOS driver on each computer that will use
Novell NetBIOS.
Procedure 1. Start the NetWare Client for OS/2 Installation program.
If NetWare Client for OS/2 is not installed, start the program from your
WSOS2_1 diskette. Type INSTALL. You can install NetWare Client for OS/2
when you install NetBIOS.
If NetWare Client for OS/2 is installed, start the program by choosing
"Installation" from the "Novell" group on your desktop.
2. Choose "Requester on Workstation" from the "Installation" menu.
3. Verify the target and source directory and choose "OK."
4. Select an action from the "Requester Installation" screen based on whether
NetWare Client for OS/2 is installed
4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
and Copy All Files . . . " and choose "OK."
4b. If NetWare Client for OS/2 is installed, select "Only Edit CONFIG.SYS
. . ." and choose "OK."
5. Select the ODI driver for your network board and choose "Continue. . ."
6. Select your preferences for NetWare support for DOS and Windows
applications and choose "Continue . . ."
7. Select "NetBIOS Emulation for OS/2 Sessions."
8. Choose "Save . . ."
9. Verify the filename and location and choose "OK."
If you have not previously installed NetWare Client for OS/2, the "Copy
Requester Files" screen appears. Continue with Step 10.
If you have previously installed NetWare Client for OS/2, the main
installation menu appears. Go to "Configuring the Driver" below.
10. Choose "Copy" and follow the screens to finish installing NetWare Client
for OS/2.
When the main menu returns, go to "Configuring the Driver" below.
Configuring the Driver
Novell's NetBIOS driver comes with default configuration settings. You may
want to customize the configuration. Follow the instructions below to
Γûá Determine whether you need to change the default configuration for NetWare
NetBIOS.
Γûá Change the configuration if necessary.
You can change the configuration to manage such features as names, sessions,
and commands.
If you do not know what NetBIOS names, sessions, and commands are, see the
documentation for your NetBIOS application.
Prerequisite
NetWare Client for OS/2 must be installed.
Procedure 1. Start the NetWare Client for OS/2 Installation program.
The program may already be running if you just installed the NetBIOS
driver.
If it isn't running, start it by choosing the "Installation" icon from the
"Novell" group on your desktop.
2. Choose "This workstation . . ." from the "Configuration" menu.
3. Verify the location of NET.CFG and choose "Edit."
The "Edit NET.CFG" window appears. You can cut and and paste text from the
help window at the bottom of the screen to the "Current NET.CFG File
Contents" window. Use the Key Definitions for the NET.CFG File chart.
4. Select "NetWare NetBIOS" from the "NET.CFG Options" box on the left of your
screen.
5. Determine whether to change the configuration for the settings under
"NetWare NetBIOS."
If you decide not to change the configuration for a setting, no action is
required for that setting.
5a. Select one of the settings.
For example, select "abort timeout."
5b. Read the help window at the bottom of the screen to determine whether
to change the configuration for the setting.
You can choose the "Usage," "Description," and "Example" buttons on
the right of your screen to see more information about the setting
you've selected.
5c. (Optional) To change the configuration, add the configuration lines
(as shown in the "Usage" help window) into the "Current NET.CFG File
Contents" box.
Important You must follow the format requirements explained in the "Format of
NET.CFG Options" topic. To see these requirements, select this topic from the
"NET.CFG Options" box and choose "Usage".
Repeat steps 5a through 5c for each setting.
6. Choose "Save."
7. Exit the NetWare Client for OS/2 Installation program.
If your NetBIOS application will not access the IBM NetBIOS driver, use
the OS/2 "Shutdown" feature to reboot your computer.
If your NetBIOS application will access the IBM NetBIOS driver, do not
reboot. Instead, configure the IBM driver as instructed in one of the
following sections :
Γûá "Configuring NETBIOS.OS2 with PROTOCOL.INI"
Γûá "Configuring NETWKSTA.200 with IBMLAN.INI" in the "Configuring
NETBIOS.OS2 with PROTOCOL.INI" section
If you do not know which of these two sections to read, go to "Determining
Which NetBIOS Drivers to Set Up."
ΓòÉΓòÉΓòÉ 15.3. Configuring NETBIOS.OS2 with PROTOCOL.INI ΓòÉΓòÉΓòÉ
Do this section only if you were directed here from the flow chart in the
figure Determine What NetBIOS Support You Have for NetBIOS 3.0 (NB30)
Applications because you
Γûá Have the LAPS program.
Γûá Have a NetBIOS 3.0 application.
As the figure below shows, IBM's ACSNETB.DLL interfaces with NETBIOS.OS2, also
provided by IBM. NETBIOS.OS2 can be configured to pass NetBIOS requests to
either of the following:
Γûá NETBEUI.OS2, IBM's NetBIOS driver.
Γûá NETBIOS.SYS, Novell's NetBIOS driver.
This section explains how to configure NETBIOS.OS2 to support both NetBIOS
drivers simultaneously or to support only Novell's driver.
If you only want to use IBM's NetBIOS driver, you do not need to configure. By
default, NETBIOS.OS2 communicates only to NETBEUI.OS2.
NetBIOS Requests through NETBIOS.OS2
Prerequisites
Checklist Install Extended Services with NetBIOS support. Verify that you can
get a NetBIOS connection.
Install LAN Services (NetBIOS support is installed by default). Verify that
you can get a LAN connection.
Install NetWare Client for OS/2 with the Novell NetBIOS driver.
In this procedure, you edit the PROTOCOL.INI file to define a virtual adapter
for the Novell and IBM NetBIOS drivers.
Procedure In this procedure, you edit the PROTOCOL.INI file to define a virtual
adapter for the Novell and IBM NetBIOS drivers.
1. Open the PROTOCOL.INI file in a text editor.
PROTOCOL.INI is located in the \IBMCOM directory.
For example, to use the OS/2 System Editor at the command line, type:
E C:\IBMCOM\PROTOCOL.INI <Enter>
2. Find the following line:
[NETBIOS]
If the [NETBIOS] line does not exist, type the line at the end of the
PROTOCOL.INI file, exactly as shown.
3. On a new line under [NETBIOS], type the following line:
DriverName = NETBIOS$
The line must be indented at least one space and must follow other
formatting requirements for IBMLAN.INI. NETBIOS$ is the device name of
NETBIOS.OS2.
If the line already exists, go to the next step.
4. On a new line under the DriverName line, type lines assigning adapter
numbers to the IBM and Novell NetBIOS drivers.
To allow NB30 NetBIOS applications to use only Novell's NetBIOS driver,
add a line for Novell's NetBIOS.
To allow NB30 applications to use both Novell and IBM drivers, add another
line for IBM's NetBIOS.
NoteWhen you define the Novell NetBIOS network, your default definition for
the IBM NetBIOS network is no longer defined. So, if you are going to use IBM
NetBIOS driver, you must add a line for the IBM network.
Each line you add should look similar to the following:
ADAPTERa = b,c,sessions,commands,names
NoteIf you have existing ADAPTER lines, leave them.
Replace the variables in the line with values shown in the Paremeters for
Defining NetBIOS in PROTOCOL.INI chart.
For example, to enable applications to use both the Novell or the IBM
NetBIOS driver, the lines in your PROTOCOL.INI file might read:
[NETBIOS]
DriverName = NETBIOS$
Adapter0 = ipxnb$,0,16,16,8
Adapter1 = netbeui$,0,32,14,8
For more information about defining adapters in NETBIOS.OS2, see your
Extended Services documentation.
5. Insert a blank line at the end of the file.
6. Save the PROTOCOL.INI file and exit your text editor.
7. Use the "Shutdown" feature from the OS/2 system menu to reboot your
computer.
When your computer restarts, your NB30 NetBIOS applications can use each
driver you defined with an adapter line.
Configuring NETWKSTA.200 with IBMLAN.INI
Do this section only if you were directed here from the flow chart Determine
What NetBIOS Support You Have for NetBIOS Submit Applications because you:
Γûá Have a NetBIOS Submit application.
Γûá Have LAN Services.
As the figure below shows, NETAPI.DLL interfaces with IBM's NETWKSTA.200. The
NETAPI.DLL file used is the one provided with LAN Services. This happens by
default, since the \MUGLIB\DLL directory that stores the LAN Services
NETAPI.DLL comes earlier in the path than the \NETWARE directory that contains
the NetWare Client for OS/2 NETAPI.DLL.
NetBIOS Requests through NETWKSTA.200
NETWKSTA.200 can be configured to pass NetBIOS requests to either
Γûá NETBEUI.OS2, IBM's NetBIOS driver.
Γûá NETBIOS.SYS, Novell's NetBIOS driver.
This section explains how to configure NETWKSTA.200 to support both NetBIOS
drivers simultaneously or to support only Novell's driver.
If you only want to use IBM's NetBIOS driver, you do not need to configure. By
default, NETWKSTA.200 talks only to NETBEUI.OS2.
Prerequisites
Checklist Install Extended Services if you have it.
Install LAN Services (NetBIOS support is installed by default). Verify that
you can get a LAN connection.
Install NetWare Client for OS/2 with the Novell NetBIOS driver.
Procedure 1.Open the IBMLAN.INI file in a text editor.
IBMLAN.INI is located in the \IBMLAN directory on your boot drive.
For example, to use the OS/2 System Editor at the command line, type
E C:\IBMLAN\IBMLAN.INI <Enter>
2. Find the following line:
[networks]
Underneath the [networks] line, you should see a line, similar to the
following, that defines a particular network as the one using IBM's
NetBIOS driver, NETBEUI.OS2:
net1 = NETBEUI$,1,LM10,32,50,14
In this case, the line defines net1 as the network using the IBM NetBIOS
driver.
3. If the IBM driver is defined to net1, change the 1 to a 2.
The line should be similar to the following:
net2 = NETBEUI$,1,LM10,32,50,14
You must change the IBM driver because the Novell driver must be defined
to net1 for dual NetBIOS to work.
4. Underneath any existing net statements, type a line assigning network
number 1 to the Novell NetBIOS driver.
NoteA network for IBM NetBIOS is defined by default in both LAN Requester and
LAN Server. If you want NetBIOS Submit applications to only use Novell's
NetBIOS driver, comment out the line for the IBM driver with a semicolon.
The line must be indented at least one space and must follow other
formatting requirements for IBMLAN.INI.
The Novell line you add should look similar to the following
neta = b,c,LM10,sessions,commands,names
Replace the variables in the line with values shown in the Parameters for
Defining Dual NetBIOS in IBMLAN.INI table:
For example, to enable applications to use both the Novell and the IBM
NetBIOS drivers, the lines in your IBMLAN.INI file might read:
[networks]
net1 = IPXNB$,1,LM10,32,16,8
net2 = NETBEUI$,1,LM10,16,16,8
For more information about defining networks for NETWKSTA.200, see your
LAN Services documentation.
5. If your computer is a LAN Server, do the following:
5a. Find the [server] line in your IBMLAN.INI file.
5b. At the end of the [server] section, find the following line:
srvnets = neta
5c. Add the Novell NetBIOS network to the line.
Separate the Novell net from any existing nets with a comma.
For example, if Novell's NetBIOS driver was net2:
srvnets = NET1,NET2
The line must be indented at least one space and must follow other
formatting requirements for IBMLAN.INI.
This line tells LAN Services the network to send NetBIOS calls for
servers on.
6. If your computer is a LAN Requester, do the following:
6a. Find the [requester] line in your IBMLAN.INI file.
6b. At the end of the [requester] section, find the following line:
wrknets = neta
6c. Add the Novell NetBIOS network to the line.
Separate the Novell net from any existing nets with a comma.
For example:
wrknets = NET1,NET2
The line must be indented at least one space and must follow other
formatting requirements for IBMLAN.INI.
This line tells LAN Services what network to send NetBIOS calls for
workstations on.
7. Save the IBMLAN.INI file and exit your text editor.
8. Use the "Shutdown" feature from the OS/2 system menu to reboot your
computer.
When your computer restarts, your NetBIOS Submit applications can use both
the Novell and the IBM NetBIOS drivers.
NoteNETWKSTA.200 must be started before any kind of NetBIOS connection will
work. You can start it automatically on startup or with the LAN Services
NETSTART command at a command line. See your LAN Services documentation.
ΓòÉΓòÉΓòÉ 15.3.1. Parameters for Defining NetBIOS in PROTOCOL.INI ΓòÉΓòÉΓòÉ
Paremeters for Defining NetBIOS in PROTOCOL.INI
This chart has the format:
Variable
Meaning of variable
ADAPTER
Adapter is a key word for NETBIOS.OS2. It is not case-sensitive.
a
Replace "a" with a number from 0 to 3. This is the adapter number
used by the application.
When specifying an adapter number:
Γûá Do not use the same number used in any other adapter
statements. Each adapter number can only be defined to one
NetBIOS driver.
Γûá Do not skip adapter numbers. For example, if you have an
adapter statement that uses ADAPTER0, use ADAPTER1 for your next
adapter statement.
b
Replace "b" with the device name for the NetBIOS driver. NETBIOS.OS2
recognizes this name when determining which driver to pass NetBIOS
calls to.
Γûá Replace "b" with IPXNB$ for the Novell NetBIOS driver.
Γûá Replace "b" with NETBEUI$ for the IBM NetBIOS driver.
c
Replace "c" with a number from 0 to 3. This number is the virtual
adapter number used by the target NetBIOS driver.
Γûá For Novell's NetBIOS driver, always specify 0.
Γûá For IBM's NetBIOS driver, specify whichever virtual adapter
you want used. See the Extended Services documentation on
NETBEUI.OS2.
sessions
Replace "sessions" with the number of NetBIOS sessions you want
allocated to NetBIOS 3.0 applications. This number specifies the
maximum number of sessions that can be active between NETBIOS.OS2 and
Novell's NetBIOS driver.
Novell's NetBIOS driver is configured by the sessions setting in the
NET.CFG. The number of sessions allocated to the application is
either the NET.CFG value or the value on this line of the
PROTOCOL.INI, whichever is lowest.
For example, if you set 64 sessions in NET.CFG, and the value on this
line is only 48, NetBIOS 3.0 applications can only use 48 sessions.
However, if you set 30 sessions in NET.CFG and the value on this line
is 50, NetBIOS 3.0 applications can use 30 sessions.
commands
Replace commands with the number of NetBIOS commands you want
allocated to the NB30 NetBIOS application. This number specifies the
maximum number of commands that can be active between NETBIOS.OS2 and
Novell's NetBIOS driver.
Novell's NetBIOS driver is configured by the commands setting in
NET.CFG. The number of commands actually allocated to the application
is either the NET.CFG value or the value on this line of
PROTOCOL.INI, whichever is lowest.
For example, if you set 128 commands in NET.CFG, and the value on
this line is only 100, the application can only use 100 commands.
If you set 80 commands in NET.CFG and the value on this line is 95,
the application can only use 80 commands.
names
Replace names with the number of NetBIOS names you want allocated to
the NB30 application. This number specifies the maximum number of
names that can be active between NETBIOS.OS2 and Novell's NetBIOS
driver.
Novell's NetBIOS driver is configured by the names setting NET.CFG.
The number of names allocated to the application is either the
NET.CFG value or the value on this line PROTOCOL.INI, whichever is
lowest.
For example, if you set 128 names in NET.CFG, and the value on this
line is only 100, the application can only use 100 names.
However, if you set 80 names in NET.CFG and the value on this line is
95, the application can only to use 80 names.
ΓòÉΓòÉΓòÉ 15.3.2. Parameters for Defining Dual NetBIOS in IBMLAN.INI ΓòÉΓòÉΓòÉ
Parameters for Defining Dual NetBIOS in IBMLAN.INI
Variable
Meaning of variable
NET
NET is a standard key word for NETWKSTA.200. It is not
case-sensitive.
a
Replace "a" with a number from 1 to 4. This is the number of the
network you want NETBIOS.OS2 to use when sending NetBIOS requests to
a NETBIOS driver. Each NetBIOS driver must have its own network
number.
When specifying a network number:
Γûá Use 1 for the Novell NetBIOS driver and 2 for the IBM NetBIOS
driver.
Γûá Do not use the same number that is used in any other net
statements. Each network number can only be defined to one
NetBIOS driver.
Γûá Do not skip numbers. For example, if you have a net statement
that uses NET1, use NET2 for your next statement.
b
Replace "b" with the device name for the NetBIOS driver. NETWKSTA.200
recognizes this name when determining which driver to pass NetBIOS
calls to.
Replace "b" with IPXNB$ for the Novell NetBIOS driver.
(NETBEUI$ is the device name for the IBM NetBIOS driver.)
LM10
LM10 is the name of the protocol that enables NETWKSTA.200 to
communicate with more than one NetBIOS driver. Type it exactly as it
appears.
c
Replace "c" with a number from 0 to 3. This number is the virtual
adapter number used by the target NetBIOS driver to receive NetBIOS
requests from NETWKSTA.200.
Γûá For Novell's NetBIOS driver, always specify 0.
Γûá For IBM's NetBIOS driver, specify whichever virtual adapter
you want used. See the Extended Services documentation on
NETBEUI.OS2.
sessions
Replace "sessions" with the number of NetBIOS sessions you want
allocated to the NetBIOS Submit application. This number specifies
the maximum number of sessions that can be active between
NETWKSTA.200 and Novell's NetBIOS driver.
Novell's NetBIOS driver is configured with the sessions setting in
the NET.CFG file. The number of sessions allocated to the application
is either the NET.CFG value or the value on this line of the
IBMLAN.INI, whichever is lowest.
For example, if you set 64 sessions in NET.CFG, and the value on this
line is only 48, the application can only use 48 sessions.
However, if you set 30 sessions in NET.CFG and the value on this line
is 50, the application can only be use 30 sessions.
commands
Replace "commands" with the number of NetBIOS commands you want
allocated to the NetBIOS Submit application. This number specifies
the maximum number of commands that can be active between
NETWKSTA.200 and Novell's NetBIOS driver.
Novell's NetBIOS driver is configured with the names setting NET.CFG.
The number of names actually allocated to the application is either
the NET.CFG value or the value on this line of the IBMLAN.INI,
whichever is lowest.
For example, if you set 128 commands in NET.CFG, and the value on
this line is only 100, the application can only to use 100 commands.
If you set 80 commands in NET.CFG and the value on this line is 95,
the application will only be able to use 80 commands.
names
Replace names with the number of NetBIOS names you want allocated to
the NetBIOS Submit application. This number specifies the maximum
number of names that can be active between NETWKSTA.200 and Novell's
NetBIOS driver.
Novell's NetBIOS driver is configured with the names setting in
NET.CFG. The number of names actually allocated to the application is
either the NET.CFG value or the value on this line of the IBMLAN.INI,
whichever is lowest.
For example, if you set 128 names in NET.CFG, and the value on this
line is only 100, the application can only use 100 names.
However, if you set 80 names in NET.CFG and the value on this line is
95, the application will only be able to use 80 names.
ΓòÉΓòÉΓòÉ 16. Using ODINSUP ΓòÉΓòÉΓòÉ
Using ODINSUP
This section discusses:
How Board Sharing Is Possible
Setting Up ODINSUP
Use this chapter if you want NetWare Client for OS/2 to share a network board
with one or more of the following IBM software products:
Γûá Extended Services
Γûá LAN Server
Γûá LAN Requester
NoteIf you have Extended Services or LAN Services, you may also want to set up
the NetBIOS protocol. After doing the steps in this chapter, you can see
"Using NetBIOS".
ΓòÉΓòÉΓòÉ 16.1. How Board Sharing Is Possible ΓòÉΓòÉΓòÉ
How Board Sharing Is Possible
NetWare Client for OS/2 uses protocol drivers and network drivers written to
the ODI (Open Data-Link Interface) specification.
Extended Services and LAN Services use protocol drivers and network drivers
written to the NDIS specification.
Even though NetWare Client for OS/2 uses a different driver specification than
Extended Services and LAN Services, NetWare Client for OS/2 can still share a
network board with these products. This is possible because of two drivers that
Novell provides:
Γûá ODINSUP,
Which lets Extended Services and LAN Services use ODI LAN drivers. Use
ODINSUP when you want the ODI network driver to control the board. See
Setting Up ODINSUP.
Γûá LANSUP,
Which lets NetWare Client for OS/2 use NDIS network drivers. Use LANSUP
when you want the NDIS driver to control the board. See Setting Up LANSUP.
ΓòÉΓòÉΓòÉ 16.2. Setting Up ODINSUP ΓòÉΓòÉΓòÉ
Setting Up ODINSUP
NoteExcept where noted, the instructions in this section apply whether you have
Extended Services, LAN Services, or both. However, the sample configuration
files differ depending on the IBM software you have. Be sure to refer to the
correct sample files for your environment.
ODINSUP installation can be done automatically using the "Utilities" option of
the OS/2 Workstation Installation program, or by modifying the configuration
files with a text editor.
The sections listed below discuss how to set up each of the three parts using a
text editor. Each part sets up a different configuration file. You must
complete all three parts.
Part A: Binding ODI Drivers in PROTOCOL.INI
Part B: Loading ODINSUP in CONFIG.SYS
Part C: Configuring ODINSUP in NET.CFG
Sample Configuration Files for ODINSUP
ODINSUP supports Ethernet- and token ring-compatible ODI drivers. It does not
support ARCnet or PC Network II drivers.
ΓòÉΓòÉΓòÉ 16.2.1. Part A: Binding ODI Drivers in PROTOCOL.INI ΓòÉΓòÉΓòÉ
Part A: Binding ODI Drivers in PROTOCOL.INI
In this section, you edit the PROTOCOL.INI file in a text editor to do the
following:
Γûá Bind the NDIS protocol stack to the ODI drivers
Γûá Remove the line binding the NDIS protocol stack to the NDIS MAC drivers
NoteThese instructions are for LAN Server and LAN Requester 2.x.
Prerequisites
Checklist
Install Extended Services on the workstation. If you have an NDIS driver for
the network board in your computer, verify that you can get a Communications
Manager or Database Manager connection. See the documentation for Extended
Services.
Install LAN Server or LAN Requester on the workstation. If you have an NDIS
driver for the network board in your computer, verify that you can get
connections properly on your LAN Server network. See the documentation for LAN
Services.
After installing all IBM software, install NetWare Client for OS/2. Using the
ODI driver for the board, verify that you can get connections properly on your
NetWare network.
NoteOnce you install NetWare Client for OS/2, Extended Services and LAN
Services will not be able to use the network board to make connections until
you have completely set up ODINSUP as instructed in this chapter.
Procedure 1. Open the PROTOCOL.INI file in a text editor.
PROTOCOL.INI is located in the \IBMCOM directory on your boot drive.
For example, to use the OS/2 System Editor at the command line, type
E C:\IBMCOM\PROTOCOL.INI
2. Find all occurrences of the lines that bind the NDIS MAC drivers.
You can search for Bindings = NDIS MAC driver.
If you don't know the name of the NDIS driver to look for, see your
Extended Services or LAN Services documentation.
For example, to search for a token ring NDIS driver, find the following
line:
Bindings = IBMTOK_NIF
Bindings lines may be in either of the following sections, depending on
whether you have Extended Services or LAN Services installed:
[NETBEUI_nif]
[LANDD_nif]
3. Use a semicolon to comment out all Bindings lines found in Step2.
For example, your PROTOCOL.INI for a token ring driver might look like the
following:
[LANDD_nif]
.
.
; Bindings = IBMTOK_NIF
4. After each commented-out Bindings line, add a line to bind the NDIS
protocol to an ODI driver.
Follow the same syntax as the line you commented out, using the ODI driver
name instead of the NDIS driver name.
For example, to add a line for the TOKEN.SYS ODI driver:
[LANDD_nif]
.
.
; Bindings = IBMTOK_NIF
Bindings = TOKEN
Since driver names in the PROTOCOL.INI file cannot start with a number, place
an X before 3Com drivers and other drivers that start with a number (Example:
Bindings = X3C503).
Suggestion If you do not know which ODI driver name to use, you can restart
your machine. An error message will appear, displaying the name of the ODI
driver that should be used. If you do this, reopen the PROTOCOL.INI file and
return to this step of the procedure.
5. (Conditional) Type an instance number to bind the NDIS protocol to a
particular occurrence of a board.
If you have two or more network boards using the same ODI driver, the NDIS
protocol uses the first network board of that type.
To have NDIS use a board other than the first one found, you can specify
an instance number. Type the instance number at the end of the driver
name, with no space between the driver name and the instance number.
For example, if you have two token ring network boards, have NDIS use the
second board by typing an instance number for the second board, as shown:
[LANDD_nif]
.
.
; Bindings = IBMTOK_NIF
Bindings = TOKEN2
6. (Conditional) Bind the NDIS protocol to additional ODI drivers.
To bind the NDIS protocol to more than one ODI driver, type both driver
names on the same line, separated by a comma.
For example, to bind to both an NE2000 driver and an NE1000 driver, type:
Bindings=ne2000,ne1000
7. Add an empty header for the ODI drivers.
7a. Locate the MAC SECTION of the PROTOCOL.INI file.
You can search for MAC SECTION.
7b. At the end of the MAC section, type a header for each ODI driver you
specified in a Bindings line in Steps 4 through 6.
Use the ODI driver name. For example, for a token ring ODI driver,
type the following line:
[TOKEN]
Put a blank line before and after the header section. If the driver
name starts with a number, you do not need an X in front of the
number for this step.
This ODI driver header is a place holder so that if you configure
with the LAPS program in the future, the Bindings information will
not be erased.
8. Save and exit the PROTOCOL.INI file.
Do not exit the text editor. Go to "Part B: Loading ODINSUP in CONFIG.SYS"
ΓòÉΓòÉΓòÉ 16.2.2. Part B: Loading ODINSUP in CONFIG.SYS ΓòÉΓòÉΓòÉ
Part B: Loading ODINSUP in CONFIG.SYS
In this section, you edit the CONFIG.SYS file in a text editor to do the
following:
Γûá Load the ODINSUP driver
Γûá Prevent the NDIS network driver (MAC) from loading
Prerequisite
Follow the instructions in "Part A: Binding ODI Drivers in PROTOCOL.INI"
Procedure 1. Open the CONFIG.SYS file in a text editor.
CONFIG.SYS is located at the root of your boot drive.
2. Find the lines that load the NDIS MAC drivers.
For example, for a token driver, search for the following line:
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2
If you don't know the name of your NDIS driver, see your Extended Services
or LAN Services documentation.
3. Comment out the NDIS MAC driver that is equivalent to the ODI driver you
are using.
For example, to comment out a token ring NDIS MAC driver, place a REM
command in front of the line that loads it, as shown:
REM DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2
If you have network boards and NDIS drivers for other communications
software, do not comment out the lines to load those drivers.
4. In NetWare Client for OS/2 lines, find the line loading the ODI driver.
5. On a new line underneath the ODI driver, insert a line to load the ODINSUP
protocol.
ODINSUP is located in the directory where you installed the NetWare Client
for OS/2 files (\NETWARE by default).
For example, to load the ODINSUP protocol from the default location, type:
DEVICE=C:\NETWARE\ODINSUP.SYS
NoteIf you have the Source-Routing driver, ROUTE.SYS, loaded after the ODI
driver, put the ODINSUP line after the ROUTE.SYS line.
6. Verify that your file meets the load order requirements shown in the table
below.
By default, these load order requirements will be met.
If you have rearranged your CONFIG.SYS, it may violate the load order
requirements.
Load Order Requirements for ODINSUP CONFIG.SYS File
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéThese components . . . ΓöéMust load before these Γöé
Γöé Γöécomponents . . . Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPROTMAN.OS2 (in OS/2 section ΓöéThe ODINSUP protocol Γöé
Γöéright after path statements) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéLSL.SYS (in NetWare Client forΓöéThe ODI driver The ODINSUP Γöé
ΓöéOS/2 section) Γöéprotocol Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéThe ODI driver (in NetWare ΓöéThe ODINSUP protocol Γöé
ΓöéClient for OS/2 section) Γöé Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéNWIFS.IFS (in NetWare Client ΓöéNETWKSTA.200 (only in LAN Γöé
Γöéfor OS/2 section) ΓöéServices configurations) Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
6a. If your file meets load order requirements, go to Step 8.
6b. If your file violates load order requirements, go to Step 7.
7. Rearrange your CONFIG.SYS file to meet load order requirements for ODINSUP.
We suggest you make your file match the sample file shown for your
environment. See "Sample Configuration Files for ODINSUP" for a list of
sample configuration files.
After rearranging your CONFIG.SYS file, go on to Step 8.
8. Save and exit the CONFIG.SYS file.
Do not exit the text editor. Go to "Part C: Configuring ODINSUP in NET.CFG"
ΓòÉΓòÉΓòÉ 16.2.3. Part C: Configuring ODINSUP in NET.CFG ΓòÉΓòÉΓòÉ
Part C: Configuring ODINSUP in NET.CFG
Important A NET.CFG file is required to use ODINSUP.
In this section, you edit or create a NET.CFG that does the following:
Γûá Enables frame types for ODINSUP.
Γûá Specifies to ODINSUP the node address known by Extended Services and the
format in which that address is transmitted.
Γûá Binds ODINSUP to an ODI driver or drivers.
Γûá Increases the size of the packet that can be transmitted through the Link
Support Layer program (if necessary).
Prerequisites
Checklist Follow the instructions in "Part A: Binding ODI Drivers in
PROTOCOL.INI"
Follow the instructions in "Part B: Loading ODINSUP in CONFIG.SYS"
Procedure 1. Open the NET.CFG text file in the text editor.
NET.CFG is located in the root of your boot drive. If NET.CFG does not
exist, create a new file with that name.
2. Enable frame types for ODINSUP.
2a. Type the following line at the top of the file:
link driver drivername
Replace drivername with the name of your ODI driver. For example, for
a token ring driver, type:
link driver token
2b. Under the Link Driver line, type the lines to enable frame types.
Enable all frame types supported by the board.
Use the frame setting to do this.
For example, to enable all frame types for token ring, type the
following:
link driver token
frame token-ring
frame token-ring_snap
To enable all frame types for Ethernet, type the following:
link driver ne2000
frame ethernet_802.3
frame ethernet_802.2
frame ethernet_ii
frame ethernet_snap
The first frame defined is the only one used for the initial "Get
Nearest Server" request. Therefore, if some servers that are using
only one frame type, such as Ethernet_802.3, put that frame type
first. That way your workstation will be able to make a default
connection to those servers.
Important Whenever you edit the NET.CFG file, you must indent
settings, as well as follow the other format requirements explained
in "NET.CFG Format Requirements".
3. Read the following to determine whether you need to specify a node address
in the NET.CFG file.
If you are using Extended Services or LAN Services set up for universally
administered addresses
You do not need to specify a node address. Go to Step 5.
If you are using Extended Services or LAN Services set up for locally
administered addresses
You must specify a node address. Use the address shown in the
"NetAddress" parameter in the PROTOCOL.INI file. Remove the T first.
For example, if the PROTOCOL.INI file shows the line
NetAddress = "T400000007030"
the address you specify in NET.CFG is
400000007030
Go to Step 4.
4. Type a line specifying the node address.
Type this line under the "Link Driver" option, above or below the lines
enabling frame types. The node address must be a 6byte hexadecimal number
(12 characters). Use the address you located in Step 3.
For example, to set a node address for a token ring board in an Extended
Services environment, type:
node address 400000007030
If your board supports octet bit reversal, you can specify the address in
either canonical (least significant bit first) or non-canonical (most
significant bit first) format.
By default, the following frames are non-canonical (MSB):
Γûá Token ring
Γûá PC Network II
Ethernet frames are canonical (LSB).
If you specify the address in the format that is not default, you must
type an M (most significant bit first) or L (least significant bit first)
at the end of the address to tell ODINSUP which format you used.
For example, for a token ring environment using the default format for the
node address, the "Current NET.CFG file contents" box should contain lines
similar to the following:
link driver token
frame token-ring
frame token-ring_snap
node address 400000007030
Note that an M after the node address is not needed because the address
specifies most significant bit first, the default format for token ring.
For a token ring environment using the non-default format for the same
node address, the "Current NET.CFG file contents" box should contain lines
similar to the following:
link driver token
frame token-ring
frame token-ring_snap
node address 020000000E0CL
In this case, an L after the node address is needed because the address is
specified in least significant-bit-first format, the format which is not
the default for token ring.
For an Ethernet Extended Services environment, the NET.CFG file should now
contain lines similar to the following:
link driver ne2000
frame ethernet_802.3
frame ethernet_802.2
frame ethernet_ii
frame ethernet_snap
node address 00001B1B055C
NoteIf you don't know the node address, you can type a "dummy" address and
continue. When you reboot your machine, a message showing the correct address
will appear. At that point, you can edit the NET.CFG file again and insert the
address that was displayed at boot time.
5. Bind ODINSUP to one or more ODI drivers.
When ODINSUP is bound to a driver, the network board for that driver is
used for Extended Services and LAN Services transmissions.
5a. Add the following lines:
protocol odinsup
bind drivername
Replace drivername with the name of the ODI driver you installed with
NetWare Client for OS/2.
For example, for a token ring ODI driver, type
protocol odinsup
bind token
5b. (Conditional) Specify an instance number if you have two or more
boards using the same ODI driver.
If you have two or more network boards using the same ODI driver,
ODINSUP searches the network board slots in order and binds only to
the first board of that type it finds.
To have ODINSUP bind to a board other than the first one found, you
specify an instance number.
ODINSUP can be bound to a maximum of four boards.
For example, if you have two token ring network boards, bind ODINSUP
to both boards by typing an instance number for the second board, as
shown:
protocol odinsup
bind token
bind token 2
6. (Optional) Increase the size of the packet transmitted through the Link
Support Layer.
Increasing the packet size may improve transmission speed if you are using
a Token Ring 16/4 board.
For other kinds of board, see the board documentation to determine the
maximum packet size supported by the board. If the board supports a packet
size larger than 1514, (the Link Support default), transmission speed may
improve if you increase the Link Support Layer default to the board's
maximum allowed size.
To increase the default,
6a. Under the Link driver lines, type the following line:
link support
6b. Under the Link Support line, type the following line:
buffers number size
Indent the line. Replace Replace number with a number of buffers
greater than 1. Replace buffer_size with a number of bytes greater
than 576.
NetWare Client for OS/2 cannot use more than 64 KB of memory for
communication buffers. Header information takes 5 KB. This means that
the buffer number multiplied by the buffer size (plus the header
information) cannot be greater than 65,536 bytes. For example, 20
buffers multiplied by 1514 bytes equals 30,280 bytes.
For example, you might type
link support
buffers 14 4202
Important For Token Ring 16/4 boards, NetWare Client for OS/2 will probably
have maximum performance if you specify 14 buffers, each with a size of 4202
bytes, as shown in the example above.
7. Save your changes and exit the NET.CFG file.
8. Exit the text editor.
9. Choose "Shutdown" from the OS/2 System menu to reboot your machine.
When your machine starts again, ODINSUP support will be completely set up.
NetWare Client for OS/2 and Extended Services/LAN Services will then use
the same ODI driver and board to transmit on the network.
ΓòÉΓòÉΓòÉ 16.2.4. Sample Configuration Files for ODINSUP ΓòÉΓòÉΓòÉ
Sample Configuration Files for ODINSUP
This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI files for
both Extended Services and LAN Requester environments.
NoteIf you follow the steps in "Setting Up ODINSUP", your configuration files
will look like the ones shown. We recommend following the steps rather than
just referring to these sample files.
ODINSUP Files for an Extended Services Environment
These files came from a computer with the following software installed:
Γûá OS/2 2.1
Γûá Extended Services 1.0 (locally-administered addresses)
Γûá NetWare Client for OS/2 with ODINSUP.
The computer used Communications Manager to make a LAN connection to an IBM
host.
Sample Files
Extended Services Token Ring PROTOCOL.INI File for ODINSUP
Extended Services Token Ring CONFIG.SYS File for ODINSUP
Extended Services Token Ring NET.CFG File for ODINSUP
ODINSUP Files for a LAN Requester Environment
These files came from a computer with the following software installed:
Γûá OS/2 2.1
Γûá LAN Requester 2.0
Γûá NetWare Client for OS/2 with ODINSUP
Sample Files
LAN Requester Token Ring PROTOCOL.INI File for ODINSUP
LAN Requester Token Ring CONFIG.SYS File for ODINSUP
LAN Requester Token Ring NET.CFG File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.5. Extended Services Token Ring PROTOCOL.INI File for ODINSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring PROTOCOL.INI File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.6. Extended Services Token Ring CONFIG.SYS File for ODINSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring CONFIG.SYS File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.7. Extended Services Token Ring NET.CFG File for ODINSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring NET.CFG File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.8. Requester Token Ring PROTOCOL.INI File for ODINSUP ΓòÉΓòÉΓòÉ
Requester Token Ring PROTOCOL.INI File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.9. LAN Requester Token Ring CONFIG.SYS File for ODINSUP ΓòÉΓòÉΓòÉ
LAN Requester Token Ring CONFIG.SYS File for ODINSUP
ΓòÉΓòÉΓòÉ 16.2.10. LAN Requester Token Ring NET.CFG File for ODINSUP ΓòÉΓòÉΓòÉ
LAN Requester Token Ring NET.CFG File for ODINSUP
ΓòÉΓòÉΓòÉ 17. Using LANSUP ΓòÉΓòÉΓòÉ
Using LANSUP
This section discusses:
How Board Sharing Is Possible
Setting Up LANSUP
Use this chapter if you want NetWare Client for OS/2 to share a network board
with one or more of the following IBM software products:
Γûá Extended Services
Γûá LAN Server
Γûá LAN Requester
NoteIf you have Extended Services or LAN Services, you may also want to
set up the NetBIOS protocol. After doing the steps in this chapter, you
can see "Using NetBIOS".
ΓòÉΓòÉΓòÉ 17.1. How Board Sharing Is Possible ΓòÉΓòÉΓòÉ
How Board Sharing Is Possible
NetWare Client for OS/2 uses protocol drivers and network drivers written to
the ODI (Open Data-Link Interface) specification.
Extended Services and LAN Services use protocol drivers and network drivers
written to the NDIS specification.
Even though NetWare Client for OS/2 uses a different driver specification than
Extended Services and LAN Services, NetWare Client for OS/2 can still share a
network board with these products. This is possible because of two drivers that
Novell provides:
Γûá ODINSUP,
Which lets Extended Services and LAN Services use ODI LAN drivers. Use
ODINSUP when you want the ODI network driver to control the board. See
Setting Up ODINSUP.
Γûá LANSUP,
Which lets NetWare Client for OS/2 use NDIS network drivers. Use LANSUP
when you want the NDIS driver to control the board. See Setting Up LANSUP.
ΓòÉΓòÉΓòÉ 17.2. Setting Up LANSUP ΓòÉΓòÉΓòÉ
Setting Up LANSUP
NoteExcept where noted, the instructions in this section apply whether you have
Extended Services, LAN Services, or both. However, the sample configuration
files shown differ depending on what IBM software you have. Be sure to refer to
the correct files for your environment.
Setting up LANSUP involves three parts. The first two parts are required; the
third is optional.
Part A: Loading LANSUP in CONFIG.SYS
Part B: Configuring LANSUP in NET.CFG
Part C: Increasing Packet Size for LANSUP (Optional)
Sample Configuration Files for LANSUP
Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN and TOKENEE
modules used in NetWare Client for OS/2 1.3. CMGRLAN and TOKENEE are not
supported in NetWare Client for OS/2 2.1.
LANSUP works with NDIS drivers for PC Network II, Ethernet, and Token-Ring
network boards.
ΓòÉΓòÉΓòÉ 17.2.1. Part A: Loading LANSUP in CONFIG.SYS ΓòÉΓòÉΓòÉ
Part A: Loading LANSUP in CONFIG.SYS
In this section, you use the NetWare Client for OS/2 Installation program to
load LANSUP in the CONFIG.SYS file.
If you have not yet installed NetWare Client for OS/2, you can install it at
the same time as you install LANSUP.
NoteThese instructions are for LAN Server and LAN Requester version 2.x.
Prerequisites
Install Extended Services on the workstation. Verify that you can get a
Communications Manager or Database Manager connection. See the documentation
for Extended Services.
Install LAN Server or LAN Requester on the workstation. Verify that you can
get a connection on your LAN Server network. See the documentation for LAN
Services.
Procedure 1. Start the NetWare Client for OS/2 Installation program.
If NetWare Client for OS/2 is not installed, you can start the program
from your WSOS2_1 diskette. Type INSTALL. You can install NetWare Client
for OS/2 with this procedure.
If NetWare Client for OS/2 is already installed, you can start the program
by choosing the "Installation" icon from the "Novell" group on your
desktop.
2. Choose "Requester on Workstation" from the "Installation" menu.
3. Verify the target and source directory and choose "OK."
4. Select an action from the "Requester Installation" screen based on whether
NetWare Client for OS/2 is installed.
4a. If NetWare Client for OS/2 is not installed, select "Edit CONFIG.SYS
and Copy All Files . . . " and choose "OK."
4b. If NetWare Client for OS/2 is installed, select "Only Edit CONFIG.SYS
. . ." and choose "OK."
5. Select LANSUP as the ODI LAN driver for your network board and choose
"Continue..."
Selecting LANSUP inserts the following line in the correct place in your
CONFIG.SYS file:
DEVICE=drive:\NETWARE\LANSUP.SYS
6. Select your preferences for NetWare support for DOS and Windows
applications and choose "Continue . . ."
7. Select your preferences for optional protocol support and choose "Save . .
."
8. Verify the filename and location and choose "OK."
If you have not installed NetWare Client for OS/2, the "Copy Requester
Files" screen appears. Continue with Step 9.
If you have installed NetWare Client for OS/2, the main installation menu
appears. Go to "Part B: Configuring LANSUP in NET.CFG".
9. Choose "Copy" and follow the screens to finish installing NetWare Client
for OS/2.
When the main menu returns, go to "Part B: Configuring LANSUP in NET.CFG".
ΓòÉΓòÉΓòÉ 17.2.2. Part B: Configuring LANSUP in NET.CFG ΓòÉΓòÉΓòÉ
Part B: Configuring LANSUP in NET.CFG
Important A NET.CFG file is required to use LANSUP.
In this section, you edit or create a NET.CFG file that does the following:
Γûá Enables frame types for LANSUP
Γûá Specifies to LANSUP the node address used by the network board and the format
that address is transmitted in
In this section, you also decide whether to increase the size of the packet
that can be transmitted through LANSUP.
Prerequisite
Install NetWare Client for OS/2 with LANSUP by following the instructions in
"Part A: Loading LANSUP in CONFIG.SYS"
Procedure 1. Choose "This workstation . .." from the "Configuration" menu of
the NetWare Client for OS/2 Installation program.
If the NetWare Client for OS/2 Installation program is not running,
complete the steps in "Part A: Loading LANSUP in CONFIG.SYS" and then
return here.
2. Verify the location of the NET.CFG file and choose "Edit."
The "Edit NET.CFG" window appears.
You can choose a topic in the "NET.CFG Options" box on this screen to get
information about a topic. Then read the help window at the bottom of the
screen.
Choose the "Usage," "Description" and "Example" buttons on the right of
your screen to see more information about the topic you've selected.
For example, to see what frame types are supported for token ring drivers,
choose "frame" from under "Link Driver" in the "NET.CFG Options" box. Then
read the information in the help window.
3. In the "Current NET.CFG File Contents" box, type the following line:
link driver lansup
4. Under the Link Driver line, type lines to enable at least one frame type.
LANSUP can be used with Ethernet, token ring, and PCNet boards. The table
below lists the supported frame types for LANSUP:
List of Frame Types Supported by LANSUP
Board Frame types supported
Token ring TOKEN-RING, TOKEN-RING_SNAP
Ethernet ETHERNET_802.2, ETHERNET_SNAP
PCNet IBM_PCN2_802.2, IBM_PCN2_SNAP
For example, to enable a frame type for token ring, type the following:
link driver lansup
frame token-ring
To enable both frame types for Ethernet, type the following:
link driver lansup
frame ethernet_802.2
frame ethernet_snap
The first frame defined is the only one used for the initial Get Nearest
Server request. Therefore, if you have some servers that are using only
one frame type, such as Ethernet 802.3, put that frame type first. That
way your workstation will be able to make a default connection to those
servers.
Important Use the Space bar to indent the lines. The <Tab> key moves you
to the next box on the screen. Put a blank line at the end of the file.
You must follow these and other format requirements explained in the
"Format of NET.CFG Options" topic. To see these requirements, select this
topic from the "NET.CFG Options" box and choose the "Usage" button. Then
read the information in the help window at the bottom of the screen.
5. Determine what node address you should use.
If you are using Extended Services or LAN Services set up for universally
administered addresses
Use the address assigned to the board by the vendor.
Extended Services or LAN Services set up for locally administered
addresses.
Use the address shown in the "NetAddress" parameter in the PROTOCOL.INI
file. Remove the T first. For example, if the PROTOCOL.INI file shows the
line
NetAddress = "T400000007030"
the address you specify in NET.CFG is
400000007030
6. Type a line specifying the node address.
Type this line under the "Link Driver" option, above or below the lines
enabling frame types. The node address must be a 6 byte hexadecimal number
(12 characters).
For example, to set a node address for a token ring board in a LAN
Services environment, type:
node address 10005a8c62d4
If your board supports octet bit reversal, you can specify the address in
either canonical (least significant bit first) or non-canonical (most
significant bit first) format.
By default, the following frames are non-canonical (MSB):
Γûá Token ring
Γûá PC Network II
Ethernet frames are canonical (LSB).
If you specify the address in the format that is not default, you must
type an M (most significant bit first) or L (least significant bit first)
at the end of the address to tell ODINSUP which format you used.
For example, for a token ring environment using the default format for the
node address, the "Current NET.CFG file contents" box should contain lines
similar to the following:
link driver lansup
frame token-ring
node address 10005a8c62d4
Note that an M after the node address is not needed because the address is
specified most significant bit first, the default format for token ring.
For a token ring environment using the non-default format for the same
node address, the "Current NET.CFG file contents" box should contain lines
similar to the following:
link driver lansup
frame token-ring
node address 08005A31462BL
In this case, an L after the node address is needed because the address is
specified in least significant bit first format, the format which is not
the default for token ring.
For an Ethernet environment, the "Current NET.CFG file contents" box
should contain lines similar to the following:
link driver lansup
frame ethernet_802.2
frame ethernet_snap
node address 00001B1B055C
NoteIf you do not know the node address, you can type a "dummy" address and go
to the next step. When you reboot your machine, a message showing the correct
address will appear. At that point, you can edit NET.CFG again and insert the
address that was displayed at boot time.
7. Decide whether to increase the size of the packet transmitted to the NDIS
driver by LANSUP.
Increasing the packet size may improve transmission speed if you are using
a Token Ring 16/4 board.
For other kinds of board, see the board documentation to determine the
maximum packet size supported by the board. If the board supports a packet
size larger than the Link Support Layer default, transmission speed may
improve if you increase the Link Support Layer default to the board's
maximum allowed size.
7a. To increase the packet size, go to "Part C: Increasing Packet Size for
LANSUP (Optional)."
7b. If you do not want to increase the packet size, go to Step 8.
8. Choose "Save . . ."
9. Exit the NetWare Client for OS/2 Installation program.
10. Choose "Shutdown" from the OS/2 System menu to reboot your machine.
When your computer starts again, LANSUP support will be set up. NetWare
Client for OS/2 and Extended Services or LAN Services will then use the
same NDIS driver and board to transmit on the network.
ΓòÉΓòÉΓòÉ 17.2.3. Part C: Increasing Packet Size for LANSUP (Optional) ΓòÉΓòÉΓòÉ
Part C: Increasing Packet Size for LANSUP (Optional)
Complete this section only if you were directed to come here from a previous
section.
In this section, you
Γûá Edit NET.CFG to increase the size of the packet that can be transmitted
through LANSUP.
Γûá Edit PROTOCOL.INI to increase the size of the packet that can be transmitted
through the NDIS drivers.
Prerequisite
Install NetWare Client for OS/2 with LANSUP by following the instructions in
Part A: Loading LANSUP in CONFIG.SYS.
Follow the instructions in Part B: Configuring LANSUP in NET.CFG.
Procedure 1. Select "Link support" in the "NET.CFG Options" box on the left of
your screen.
If the NetWare Client for OS/2 Installation program is not open to the
"Edit NET.CFG Window", complete the steps in Part B: Configuring LANSUP in
NET.CFG Then come back to this step.
2. Select "buffers" under "Link Support."
3. Read the information in the help window at the bottom of the screen to see
how to set the Link Support buffers.
You can choose the "Usage," "Description" and "Example" buttons on the
right of your screen to see more information about Link Support.
4. In the "Current NET.CFG File Contents," add lines to change the "Link
Support buffers" setting.
Follow the usage requirements shown in the help window.
Indent the line. Replace number with a number of buffers greater than 1.
Replace buffer_size with a number of bytes greater than 576.
NetWare Client for OS/2 cannot use more than 64 KB of memory for
communication buffers. Header information takes 5 KB of memory. This means
that the buffer number multiplied by the buffer size (plus the header
information) cannot be greater than 65,536 bytes. For example, 20 buffers
multiplied by 1514 bytes equals 30,280 bytes.
For example, you might type
link support
buffers 14 4202
Important For Token Ring 16/4 boards, NetWare Client for OS/2 will probably
have maximum performance if you specify 14 buffers, each with a size of 4,202
bytes, as shown in the example above.
5. Choose "Save . . ."
6. Exit the NetWare Client for OS/2 Installation program. Without rebooting
your machine, go to Step 7.
7. Run the IBM LAPS program to edit PROTOCOL.INI.
8. Change the transmit buffer size to a number 6 bytes larger than the number
you set for the Link Support buffer size in Step 4.
The value you specify must be a multiple of 8. See your LAPS documentation
for more about changing the transmit buffer size.
Important Use a transmit buffer size of 4,208 if you are using Token Ring 16/4
boards.
The LAPS program inserts the following line in the NDIS MAC driver section
of your PROTOCOL.INI file:
XMITBUFSIZE = 4208
9. Exit the LAPS program.
10. Choose "Shutdown" from the OS/2 System menu to restart your machine.
When your machine starts again, LANSUP support will be set up.
NetWare Client for OS/2 and Extended Services/LAN Services will transmit
to the network from the same NDIS driver and network board.
ΓòÉΓòÉΓòÉ 17.2.4. Sample Configuration Files for LANSUP ΓòÉΓòÉΓòÉ
Sample Configuration Files for LANSUP
This section contains sample CONFIG.SYS, NET.CFG, and PROTOCOL.INI files for
both Extended Services and LAN Requester environments.
NoteIf you follow the steps in "Setting Up LANSUP", your configuration files
will look like the ones shown. We recommend following the steps rather than
just referring to these sample files.
LANSUP Files for an Extended Services Environment
These files came from a computer with the following software installed:
Γûá OS/2 Version 2.1
Γûá Extended Services version 1.0 (locally-administered addresses)
Γûá NetWare Client for OS/2 with LANSUP.
The computer used Communications Manager to make a LAN connection to an IBM
host.
Sample Files
Extended Services Token Ring CONFIG.SYS File for LANSUP
Extended Services Token Ring NET.CFG File for LANSUP
Extended Services Token Ring PROTOCOL.INI File for LANSUP
ODINSUP Files for a LAN Requester Environment
These files came from a computer with the following software installed:
Γûá OS/2 v2.1
Γûá LAN Requester v2.0
Γûá NetWare Client for OS/2 with LANSUP
Sample Files
LAN Requester Token Ring CONFIG.SYS File for LANSUP
LAN Requester Token Ring NET.CFG File for LANSUP
LAN Requester Token Ring PROTOCOL.INI File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.5. Extended Services Token Ring CONFIG.SYS File for LANSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring CONFIG.SYS File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.6. Extended Services Token Ring NET.CFG File for LANSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring NET.CFG File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.7. Extended Services Token Ring PROTOCOL.INI File for LANSUP ΓòÉΓòÉΓòÉ
Extended Services Token Ring PROTOCOL.INI File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.8. LAN Requester Token Ring CONFIG.SYS File for LANSUP ΓòÉΓòÉΓòÉ
LAN Requester Token Ring CONFIG.SYS File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.9. LAN Requester Token Ring NET.CFG File for LANSUP ΓòÉΓòÉΓòÉ
LAN Requester Token Ring NET.CFG File for LANSUP
ΓòÉΓòÉΓòÉ 17.2.10. LAN Requester Token Ring PROTOCOL.INI File for LANSUP ΓòÉΓòÉΓòÉ
LAN Requester Token Ring PROTOCOL.INI File for LANSUP
ΓòÉΓòÉΓòÉ 18. NET.CFG Options Reference ΓòÉΓòÉΓòÉ
NET.CFG Options Reference
This is an alphabetical listing of all NET.CFG options. For instructions on
editing the NET.CFG file, format requirements, and reasons to configure, see
Configuring NetWare Client for OS/2.
All the information in this appendix is also found online in the NetWare
Requester installation and configuration program.
Topics
Daemon Configuration
Link Driver
Link Support
Named Pipes
NetWare NetBIOS
NetWare Requester
Protocol ODINSUP
Protocol Stack IPX
Protocol Stack SPX
Token-Ring Source-Route Driver
ΓòÉΓòÉΓòÉ 18.1. Daemon Configuration ΓòÉΓòÉΓòÉ
Daemon Configuration
Use this option to control the length of time network-related error messages
stay on your screen. This option controls only pop-up and broadcast messages.
NotePop-up and broadcast messages appear in a small box on your screen and
prompt you to "Press <Esc> to continue ..."
Syntax
daemon configuration
message timeout number
Message timeout
Replace number with a number of milliseconds that you want pop-up and
broadcast messages to display on your screen before disappearing.
Replace number with 0 (zero) to prevent pop-up and broadcast messages from
displaying at all.
If you leave this line out of your NET.CFG, pop-ups and broadcast messages
are displayed until you press <Esc>.
Default
Pop-up and broadcast messages display until you press <Esc>.
Example
To prevent pop-up and broadcast messages from displaying:
daemon configuration
message timeout 0
ΓòÉΓòÉΓòÉ 18.2. Link Driver ΓòÉΓòÉΓòÉ
Link Driver
Use this option to specify the hardware configuration of the LAN drivers for
each network board in your workstation.
Use this option only if the network boards are not using the default settings.
The settings you specify with this option should match the hardware settings
for your boards.
NoteIf you have more than one network board in your workstation, put this
option in your NET.CFG file for each board.
Syntax
link driver name
alternate
dma [index] channel
frame name
int [index] irq
mem [index] starting_address [size]
node address number
port [index] starting_port [number]
protocol name id frame
slot number
ΓòÉΓòÉΓòÉ 18.2.1. link driver ΓòÉΓòÉΓòÉ
link driver
Use this option to specify the name of the LAN driver whose defaults you want
to modify.
Syntax
link driver name
Replace name with the name of the driver. The List of Network Boards and
Drivers lists some network boards and their driver names.
Default
None.
Example
To configure an IBM Token-Ring PC driver, type the following with any
settings.
link driver token
ΓòÉΓòÉΓòÉ 18.2.2. alternate ΓòÉΓòÉΓòÉ
alternate
Specifies an alternate board. Normally, the LANSUP, IBM token ring and NTR2000,
and PCN2L drivers use the primary board.
Syntax
link driver name
alternate
Default
None
Example
To specify the LANSUP.COM driver to use an alternate board, you would place
the following lines in your NET.CFG file:
link driver name
alternate
ΓòÉΓòÉΓòÉ 18.2.3. DMA ΓòÉΓòÉΓòÉ
DMA
Use this setting to specify which direct memory access (DMA) channel the
network board uses.
Syntax
link driver name
dma [index] channel
Replace index with either #1 or #2 (optional).
The driver configuration table for each board can store the DMA channel number
on either of two lines. The lines are labeled #1 and #2.
Replace channel with the number of the DMA channel used by the board.
The channel numbers for different network boards are recorded in the
documentation from the board manufacturers.
Defaults
Index: #1
Most boards use this default.
Channel: Set by the driver. See the documentation for the board.
You can't change the DMA setting on 3Com Etherlink 503 boards, and you do not
need to change it on 3Com Etherlink 505 boards. You can change the DMA setting
on 3Com Etherlink 523 boards.
Example
To set the DMA channel for a 3Com Etherlink 505 board:
link driver 3C505
dma 7
ΓòÉΓòÉΓòÉ 18.2.4. frame ΓòÉΓòÉΓòÉ
frame
Use this setting to specify which frame type the driver for your network board
uses.
Use this setting only for boards that support more than one frame type or if
you want multiple networks (separate network addresses) to share the same
network board and cabling.
The frame type transmitted by the workstation should match the type of packets
being transmitted by the servers on your network.
Syntax
link driver name
frame name
Replace name with the name of the frame type. The Frame Types and LAN Drivers
table lists common frame types and the network board drivers that support each
type. This list is not comprehensive.
Default
Set by the driver. See the documentation for the board.
Examples
To specify the Ethernet_802.2 frame type for an NE2000 board:
link driver ne2000
frame ethernet_802.2
To specify the Ethernet_802.2 and Ethernet_802.3 frame types for an NE1000
board (for two logical networks):
link driver ne1000
frame ethernet_802.2
frame ethernet_802.3
If you are using the ODINSUP driver, you must enable multiple frame types for
each driver. For Ethernet, enable Ethernet_802.3, Ethernet_II, Ethernet_802.2,
and Ethernet_SNAP.
For Token-Ring, enable Token-Ring and Token-Ring_SNAP. For more information
about ODINSUP, see Using ODINSUP
You can specify more than one frame type statement for a single driver. For
example, you can specify that an Ethernet NE2000 board can use both
Ethernet_802.2 and Ethernet_802.3 frame types. 802.2 is the type of
communications sent on one network, and 802.3 is the type of communication
sent on the other network.
You can use up to four frame types for one set of Ethernet cabling. You can
use either four network boards each with one frame type defined, or you can
use one network board with four frames defined, or any similar combination.
For Token-Ring cabling, two frames types are the maximum allowed.
The default frame type for Ethernet drivers has changed to Ethernet_802.2.
This may conflict with the frame type used on your network. See Specifying
Frame Types for a LAN Driver for more information about specifying frame type.
ΓòÉΓòÉΓòÉ 18.2.5. int ΓòÉΓòÉΓòÉ
int
Use this setting to specify which interrupt line (IRQ) the network board uses
to communicate with the driver.
Syntax
link driver name
int [index] irq
Replace index with either #1 or #2 (optional).
The driver configuration table for each board can store the interrupt line
number on either of two lines in the table. The lines are labeled #1 and #2.
Replace irq with the number of the interrupt line used by the board.
To determine the interrupt line number for your network board, see the
documentation for the board.
Defaults
Index: #1
IRQ: Set by the driver. See the documentation for the board.
Example
To set the interrupt line for an NE2000 board:
link driver ne2000
int 3
Before changing the interrupt setting for your board, be sure you know what
interrupt settings are used on other hardware (such as monitors) that you are
using. For example, interrupts 2 and 9-15 are usually reserved, so don't use
those numbers (especially 2) for your network board. We recommend using 3, 5,
or 7 for most network boards.
If you are using a PS/2 computer on a Token-Ring network, do not autoconfigure
with the Reference diskette. Doing so may cause problems.
ΓòÉΓòÉΓòÉ 18.2.6. mem ΓòÉΓòÉΓòÉ
mem
Use this setting to specify what range of memory can be used by the driver.
Syntax
link driver name
mem [index] starting_address size
Replace index with either #1 or #2 (optional).
The driver configuration table for each board can store the memory range on
either of two lines in the table. The lines are labeled #1 and #2.
Replace starting_address with a hexadecimal memory address that begins the
range. This address must be five digits and the same as the address designated
for the board by the manufacturer. (See the documentation for the board).
Replace size with a hexadecimal number of paragraphs in the memory range
(optional).
Defaults
"Index: #1" = ROM address
"Index: #2" = RAM address (D8000 by default by TOKEN.SYS)
Starting_address: Set by the driver. See the documentation for the board.
Size: Set by the driver. See the documentation for the board.
Example
To set the memory range for a Token-Ring board:
link driver token
mem cc000 200
Assign each board a unique memory range. Be sure that you don't assign a range
that is already being used by other hardware. (VGA monitors commonly use
A0000-C6FFF and XVGA monitors commonly use A0000-CFFFF.)
ΓòÉΓòÉΓòÉ 18.2.7. node address ΓòÉΓòÉΓòÉ
node address
Use this setting to change the node address of a network board. This setting
can only be used with network boards that allow you to override the preset
address.
Syntax
link driver name
node address number
Replace number with a hexadecimal address. You can specify the address with
either the least significant bit first (lsb format) or the most significant
bit first (msb format).
Default
The address preset on the board.
Example
To change the address for board that uses the ODINSUP driver:
link driver odinsup
node address 02608c861759
ΓòÉΓòÉΓòÉ 18.2.8. port ΓòÉΓòÉΓòÉ
port
Use this setting to specify which range of I/O ports the network board uses.
Syntax
link driver name
port [index] starting_port [number]
Replace index with either #1 or #2 (optional).
The driver configuration table for each board can store information about
ports on either of two lines in the table. The lines are labeled #1 and #2.
Replace starting_port with a hexadecimal port number that begins the range. We
recommend not using 2EO and 2FO since these port numbers are normally used by
ARCnet for other functions.
Replace number with the hexadecimal number of bytes in the range (optional).
Defaults
Index: #1
Starting_port: Set by the driver. See the documentation for the board.
Number: Set by the driver. See the documentation for the board.
Example
To set the memory range for board that uses the NE2000 driver:
link driver ne2000
port 300
ΓòÉΓòÉΓòÉ 18.2.9. protocol ΓòÉΓòÉΓòÉ
protocol
Use this setting to allow LAN drivers to use protocols that have different
frame types.
Syntax
link driver name
protocol name ID frame
Replace name with the acronym of an ODI-compliant protocol. Some common
protocols are:
ARP
IP
IPX (the NetWare protocol)
RARP
Replace ID with the hexadecimal number of the protocol that goes with the
frame type you specify.
Replace frame with the name of the frame type used with the protocol. The
Protocol and Frame type table shows common protocols with some frame types and
hexadecimal numbers they support.
Defaults
Name: IPX
ID: 0
Frame: Ethernet_802.3
Example
To specify the ARP protocol for an Ethernet II frame:
link driver NE2000
protocol arp 806 ethernet_ii
ΓòÉΓòÉΓòÉ 18.2.10. slot ΓòÉΓòÉΓòÉ
slot
Use this setting to tell the NetWare Client for OS/2 which expansion slot an
EISA or Microchannel board is using.
EISA and Microchannel boards are self-configuring, and the NetWare Client for
OS/2 can obtain all Link Driver information from the board itself. You have to
tell the NetWare Client for OS/2 which slot the board is using or, if you only
have one board of a particular type, tell the NetWare Client for OS/2 to scan
all slots until it finds that board.
Syntax
link driver name
slot number
Replace number with the number of the expansion slot the board is using or a
question mark to tell NetWare Client for OS/2 to scan all slots.
Default
None
Example
To automatically configure the drivers for an NE/2 board in slot 4 and an NE/2
board in slot 2:
link driver ne2
slot 4
link driver ne2
slot 2
This slot setting is the only Link Driver hardware-related setting you need to
specify in this case.
To scan all slots for a Novell Ethernet NE/2 board:
link driver ne2
slot ?
ΓòÉΓòÉΓòÉ 18.2.11. LAN Driver Table ΓòÉΓòÉΓòÉ
List of Network Boards and Driver Table
This table is a list of common network boards and drivers
Driver name Network board
NE2 Novell Ethernet NE/2
NE2_32 Novell Ethernet NE/2-32
NE1000 Novell Ethernet NE1000
NE2000 Novell Ethernet NE2000
TOKEN IBM Token ring
LANSUP Boards using NDIS drivers
ODINSUP IBM Token ring and Ethernet Communications Manager
3C501 3Com EtherLink series 501
3C503 3Com EtherLink series 503
3C505 3Com EtherLink series 505
3C523 3Com EtherLink/MC series
PCN2 IBM PC Network II and II/A (older Novell frame format)
PCN2L IBM PC Network II and II/A (newer IBM frame format)
NoteThe PCN2 and PCN2L drivers cannot be used in the same workstation.
ΓòÉΓòÉΓòÉ 18.2.12. List of Frame Types and LAN Drivers ΓòÉΓòÉΓòÉ
List of Frame Types and LAN Drivers
Frame type LAN board driver
Ethernet 802.3 NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503, 3C505,
3C523, EXOS205, EXOS215, ODINSUP
Ethernet 802.2 NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503,
EXOS205, EXOS215, ODINSUP, LANSUP
Ethernet II NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503, 3C505,
3C523, EXOS205, EXOS215, ODINSUP
Ethernet SNAP NE1000, NE2000, NE2100, NE2, NE2 32, 3C501, 3C503,
EXOS205, EXOS215, ODINSUP, LANSUP
Token ring ODINSUP, TOKEN, LANSUP
Token ring SNAP ODINSUP, TOKEN, LANSUP
IBM pcn2 802.2 PCN2, PCN2L, LANSUP
IBM pcn2 snap PCN2, PCN2L, LANSUP
Novell rx-net TRXNET, TRXNET2
ΓòÉΓòÉΓòÉ 18.2.13. Protocols and Frame types ΓòÉΓòÉΓòÉ
List of protocols, frame types, and hexadecimal ID numbers
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéProtocol ΓöéFrame type ΓöéHex numberΓöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéIPX ΓöéEthernet_802.3 Γöé0 Γöé
Γöé ΓöéEthernet_802.2 ΓöéE0 Γöé
Γöé ΓöéToken-Ring ΓöéE0 Γöé
Γöé ΓöéIBM_PCN2_802.2 ΓöéE0 Γöé
Γöé ΓöéEthernet_II Γöé8137 Γöé
Γöé ΓöéEthernet_SNAP Γöé8137 Γöé
Γöé ΓöéToken-Ring_SNAPΓöé8137 Γöé
Γöé ΓöéIBM_PCN2_SNAP Γöé8137 Γöé
Γöé ΓöéNovell_RX-Net ΓöéFA Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéIP ΓöéEthernet_II Γöé800 Γöé
Γöé ΓöéEthernet_SNAP Γöé800 Γöé
Γöé ΓöéToken-Ring_SNAPΓöé800 Γöé
Γöé ΓöéNovell_RX-Net ΓöéD4 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéARP ΓöéEthernet_II Γöé806 Γöé
Γöé ΓöéEthernet_SNAP Γöé806 Γöé
Γöé ΓöéToken-Ring_SNAPΓöé806 Γöé
Γöé ΓöéNovell_RX-Net ΓöéD5 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéRARP ΓöéEthernet_II Γöé8035 Γöé
Γöé ΓöéEthernet_SNAP Γöé8035 Γöé
Γöé ΓöéToken-Ring_SNAPΓöé8035 Γöé
Γöé ΓöéNovell_RX-Net ΓöéD6 Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
ΓòÉΓòÉΓòÉ 18.3. Link Support ΓòÉΓòÉΓòÉ
Link Support
Use this option to adjust the number and size of communication buffers used by
NetWare Client for OS/2.
Syntax
link support
buffers number [buffer_size]
buffers
Replace number with a number of buffers greater than 1.
Replace buffer_size with a number of bytes greater than 576.
The NetWare Client for OS/2 cannot use more than 64 KB of memory for
communication buffers. Header information takes 5 KB. This means that the
buffer number multiplied by the buffer size (plus the header information)
cannot be greater than 65,536 bytes. For example, 20 buffers multiplied by
1514 bytes equals 30,280 bytes.
Defaults
Number: 20 buffers
Buffer_size: 1514 bytes
Examples
For an Ethernet configuration:
link support
buffers 15 1514
For a Token-Ring configuration:
link support
buffers 14 4210
Notes
1. Increasing efficiency. For most efficient communication, your link support
buffer size should be the same size as the packets that your workstation will
receive over the network. You may want to set the link support buffer size
equal to the largest buffer size that the network boards in your workstation
will support.
2. Using the TRXNET.SYS driver. If your workstation experiences performance
problems running with TRXNET.SYS, you may need to reconfigure the number and
size of link support buffers allowed. Set the following values:
link support
buffers 15 4202
TRXNET.SYS only supports SMC100, 110, and 120 cards.
ΓòÉΓòÉΓòÉ 18.4. Named Pipes ΓòÉΓòÉΓòÉ
Named Pipes
Use this option to manage Named Pipes sessions.
Syntax
named pipes
advertise board board number
client sessions number
machine names number
ΓòÉΓòÉΓòÉ 18.4.1. advertise board ΓòÉΓòÉΓòÉ
advertise board
Use this setting to specify a board that the Named Pipes server uses to
advertise itself. You should only configure more than one of this setting when
the boards specified are part of separate networks.
Syntax
named pipes
advertise board board number
Replace board number with the logical board number of a network board. Board
number can be a value from 1 to 16.
Logical board numbers are assigned in ascending order to each frame type as
they appear in your configuration. Note that logical board numbers are
assigned to defaulted frame types.
The board number given must be the logical board number of a frame type used
by IPX. (Note: You specify IPX usage of a frame type by using the protocol
setting under the link driver option.)
Default
The Named Pipes server will advertise itself over IPX's primary network board
when this setting is not specified, out of range, or if the board number given
does not match the logical board number of a frame type in use by IPX.
Example
Configure Named Pipes server as follows in order to use the logical boards
defined by the NE2000 link driver and the Ethernet 802.2 and Ethernet 802.3
frame types to advertise the server:
Link Driver NE2
Frame Ethernet_802.2;logical board 1
Frame Ethernet_II;logical board 2
Protocol IPX E0 Ethernet_802.2
Protocol IP 800 Ethernet_II
Link Driver NE2000
Frame Ethernet_802.2;logical board 3
Frame Ethernet_802.3;logical board 4
Protocol IPX E0 Ethernet_802.2
Protocol IPX 0 Ethernet_802.3
Named Pipes
Advertise Board 3
Advertise Board 4
ΓòÉΓòÉΓòÉ 18.4.2. client sessions ΓòÉΓòÉΓòÉ
client sessions
Use this setting to specify the maximum number of connections a workstation can
establish with all Named Pipes servers.
Syntax
named pipes
client sessions number
Replace number with a number from 3 to 128.
You need at least one client session for each connection from an OS/2
application to a Named Pipes server.
Default
16 sessions.
The default is usually adequate, except with applications that use many Named
Pipes.
Example
To allow each client thirty sessions:
named pipes
client sessions 30
ΓòÉΓòÉΓòÉ 18.4.3. machine names ΓòÉΓòÉΓòÉ
macine names
Use this setting to force Named Pipes to create a local table of server names.
This is used in all sessions on an OS/2 client workstation. This setting is
necessary for remote Named Pipes operations when there are no NetWare servers
on the network.
Syntax
named pipes
machine names number
Replace number with a number from 4 to 100. The number represents how many
Named Pipes server names you want to cache.
Default
0 (i.e., query network for Named Pipes server names)
Example
To set the number of locally cached Named Pipes server names to 5:
named pipes
machine names 5
ΓòÉΓòÉΓòÉ 18.5. NetWare NetBIOS ΓòÉΓòÉΓòÉ
NetWare NetBIOS
Use this option to manage NetBIOS names and sessions or to affect the internal
memory allocation for NetBIOS.
Categories of NetWare NetBIOS settings
Name management
Broadcast count
Broadcast delay
Internet
Names
Session creation
Retry count
Retry delay
Sessions
Session management
Abort timeout
Listen timeout
Verify timeout
Command management
Commands
Syntax
netware netbios
abort timeout number
bind board number
broadcast count number
broadcast delay number
commands number
internet [on|off]
listen timeout number
names number
retry count number
retry delay number
sessions number
verify timeout number
ΓòÉΓòÉΓòÉ 18.5.1. Abort, Listen, and Verify Timeout ΓòÉΓòÉΓòÉ
abort, listen, and verify timeout
Use these settings to monitor and control your NetBIOS connections.
When NetBIOS sessions at a sending computer do not receive any transmissions
from the receiving computer for the length of the "verify timeout" interval,
NetBIOS sends a request-for-acknowledgment packet to the receiving computer.
NetBIOS then waits the length of the "listen timeout" interval to receive a
response.
If no response is received, NetBIOS sends another packet requesting immediate
response. NetBIOS then waits the length of the "abort timeout" interval to
receive a response.
If no response is received, NetBIOS terminates the session.
Syntax
netware netbios
abort timeout number
listen timeout number
verify timeout number
Abort timeout: Replace number with a number of milliseconds greater than 500.
Listen timeout: Replace number with a number of milliseconds greater than 200
Verify timeout: Replace number with a number of milliseconds greater than 100.
The ratio between these settings must remain the same. For example, if you
double the Listen timeout value, you must also double the Abort timeout and
Verify timeout values.
Defaults
Abort timeout: 30,000 milliseconds
Listen timeout: 6,000 milliseconds
Verify timeout: 3,000 milliseconds
Examples
To make NetBIOS wait longer before sending a request-for acknowledgment
packet, sending the packet requesting immediate response, and terminating the
session:
netware netbios
abort timeout 45000
listen timeout 8000
verify timeout 4000
ΓòÉΓòÉΓòÉ 18.5.2. broadcast count ΓòÉΓòÉΓòÉ
broadcast count
Use this setting to specify how many times NetBIOS broadcasts a query or claim
for the name being used by an application.
Syntax
netware netbios
broadcast count number
Replace number with a number of queries greater than 1.
Defaults
With internet on: 4 times.
With internet off: 2 times.
Example
To broadcast more often:
netware netbios
broadcast count 8
ΓòÉΓòÉΓòÉ 18.5.3. broadcast delay ΓòÉΓòÉΓòÉ
broadcast delay
Use this setting to specify how long NetBIOS waits between query or claim
broadcasts.
Syntax
netware netbios
broadcast delay number
Replace number with a number of milliseconds greater than 100.
Defaults
With internet on: 2,000
With internet off: 1,000
Example
To wait longer between broadcasts:
netware netbios
broadcast delay 3000
ΓòÉΓòÉΓòÉ 18.5.4. commands ΓòÉΓòÉΓòÉ
commands
Use this setting to specify how many NetBIOS commands can be buffered in the
NetBIOS driver at any one time.
Syntax
netware netbios
commands number
Replace number with a number of commands from 8 to 128.
Default
32 commands
Example
To run an application that requires a large number of outstanding commands:
netware netbios
commands 128
ΓòÉΓòÉΓòÉ 18.5.5. internet ΓòÉΓòÉΓòÉ
internet
Use this setting to transmit name-claim packets to and from all stations on the
internet, or to and from stations on the local network only.
Name-claim packets are packets which attempt to establish the uniqueness of the
name of the station on which NetBIOS is running.
Syntax
netware netbios
internet [on|off]
Type on or off
Default
On
Example
To send and receive on the local network only:
netware netbios
internet off
ΓòÉΓòÉΓòÉ 18.5.6. names ΓòÉΓòÉΓòÉ
names
Use this setting to specify how many names the workstation can have in its name
table for remote stations. When you add a name to a station, the station
broadcasts that name to all other nodes on the network.
Syntax
netware netbios
names number
Replace number with a number of names from 4 to 128.
You can use a name instead of a node address to refer to a remote station.
Default
24 names
Example
To allow forty-five names:
netware netbios
names 45
ΓòÉΓòÉΓòÉ 18.5.7. retry count ΓòÉΓòÉΓòÉ
retry count
Use this setting to specify how many times NetBIOS transmits a request for
connection or retransmits a failed communication.
Syntax
netware netbios
retry count number
Replace number with a number greater than 0.
Default
20 times
Example
To retransmit fifty times:
netware netbios
retry count 50
ΓòÉΓòÉΓòÉ 18.5.8. retry delay ΓòÉΓòÉΓòÉ
retry delay
Use this setting to specify how many milliseconds NetBIOS waits between
transmissions while establishing a connection or resending a data packet.
Syntax
netware netbios
retry delay number
Replace number with a number of milliseconds greater than 0.
Default
500 milliseconds
Example
To wait eight hundred milliseconds between retransmission attempts:
netware netbios
retry delay 800
ΓòÉΓòÉΓòÉ 18.5.9. sessions ΓòÉΓòÉΓòÉ
sessions
Use this setting to specify how many simultaneous NetBIOS sessions can be
supported by the NetBIOS driver.
Syntax
netware netbios
sessions number
Replace number with a number of sessions from 4 to 64.
Default
16 sessions
Example
To allow one hundred NetBIOS sessions:
netware netbios
sessions 50
ΓòÉΓòÉΓòÉ 18.5.10. Bind ΓòÉΓòÉΓòÉ
Bind
Use this setting to specify the primary NetBIOS netowrk board in your
workstaion.
NetBIOS uses its primary board to manage NetBIOS names. You can only configure
one primary NetBIOS network board.
Syntax
netware netbios
bind board_number
Replace board_number with the logical board number of a network board.
Board_number can be a value from 1 to 16.
Logical board numbers are assigned in ascending order to each frame type as
they appear in your configuration.
Note that logical board numbers are assigned to default frame types.
The board_number given must be the logical board number of a frame type used
by IPX.
Note: You specify IPX usage of a frame type by using the protocol setting
under the link driver option.
Default
NetBIOS uses IPX's primary baord as its own primary board when the bind
setting is not specified, out of range, or if the board_number given does not
match the logical board number of a frame type in use by IPX.
Example
Configure NetBIOS as follows in order to use the logical board defined by the
NE2000 link driver and the Ethernet 802.3 frame type as the NetBIOS primary
network board:
Link Driver NE2T
Frame Ethernet_802.2;logical board 1
Frame Ethernet_II;logical board 2
Protocol IPX 0 Ethernet_802.2
Protocol IP 800 Ethernet_II
Link Driver NE2000
Frame Ethernet_802.3;logical board 3
Protocol IPX 0 Ethernet_802.3
netware netbios
bind 3
ΓòÉΓòÉΓòÉ 18.6. NetWare Requester ΓòÉΓòÉΓòÉ
NetWare Requester
Use this option to control network requests from your workstation to a NetWare
server.
Syntax
netware requester
cache buffers number
default login drive driveletter
display hard errors off
large internet packets off
name context "context"
packet burst off
preferred server servername
preferred tree treename
request retries number
sessions number
signature level number
ΓòÉΓòÉΓòÉ 18.6.1. cache buffers ΓòÉΓòÉΓòÉ
cache buffers
Use this setting to specify how many buffers NetWare Client for OS/2 can use to
cache data from open files.
Cache buffers minimize read and write traffic on the network. The more buffers,
the faster NetWare Client for OS/2 performs; however, more buffers use up more
memory.
NetWare Client for OS/2 automatically uses the maximum buffer size permitted by
each server to which NetWare Client for OS/2 is connected. However, NetWare
Client for OS/2 cannot use more than 64 KB of total memory for cache buffers,
so if the buffer size is large, you may not be allowed as many buffers as you
specify.
Syntax
netware requester
cache buffers number
Replace number with a number of buffers from 0 to 30.
To turn off caching, specify 0.
Default
8 buffers
Example
To allow 15 cache buffers:
netware requester
cache buffers 15
ΓòÉΓòÉΓòÉ 18.6.2. large internet packets off ΓòÉΓòÉΓòÉ
Large Internet Packets Off
Use this setting to disable large internet packets transmission. Improving
Speed and Security explains more about large internet packets.
Syntax
netware requester
large internet packets off
Type large internet packets off to turn off large packet transmissions.
Default
Large internet packets are transmitted.
Example
To disable large packet transmission:
netware requester
large internet packets off
ΓòÉΓòÉΓòÉ 18.6.3. default login drive ΓòÉΓòÉΓòÉ
default login drive
Use this option to change the default login drive from drive L: to another
network drive.
Syntax
netware requester
default login drive drive letter
Replace drive letter with the letter of another network drive.
If you change the default login drive setting, you must also edit the LIBPATH,
DPATH, and PATH statements in your CONFIG.SYS file from L:\OS2 to drive
letter:\OS2.
Default
drive L:
Example
To change your default login drive from drive L: to drive F:
netware requester
default login drive f
In your CONFIG.SYS in the LIBPATH, DPATH, and PATH lines, you must change all
references of L:\OS2 to F:\OS2.
ΓòÉΓòÉΓòÉ 18.6.4. name context ΓòÉΓòÉΓòÉ
Name Context
Use this setting to specify the workstation's name context in the directory
services tree. Concepts explains more about name contexts.
Syntax
netware requester
name context context
Replace context with your name context in the directory tree.
Default
At the root of the tree.
Example
To specify a name context:
netware requester
name context "john.sales.novell us"
ΓòÉΓòÉΓòÉ 18.6.5. packet burst off ΓòÉΓòÉΓòÉ
packet burst off
Use this setting to disable the packet burst feature. Improving Speed with
Packet Burst explains more about the Packet Burst feature.
Syntax
netware requester
packet burst off
Default
Packet burst is enabled.
Example
To disable packet burst:
netware requester
packet burst off
ΓòÉΓòÉΓòÉ 18.6.6. preferred server ΓòÉΓòÉΓòÉ
preferred server
Use this setting to specify which NetWare server you want your workstation to
attach to when it first accesses the network.
NoteIf the server you specify is unavailable, your workstation will attach to
the first available server.
Syntax
netware requester
preferred server servername
Replace servername with the name of a server. The server you specify should
probably have the NetWare utilities for OS/2 installed.
Default
None
Example
To attach to server FINANCE:
netware requester
preferred server finance
ΓòÉΓòÉΓòÉ 18.6.7. preferred tree ΓòÉΓòÉΓòÉ
preferred tree
Use this setting to specify a tree name to connect. This setting is only for
sites with more than one directory tree.
Syntax
netware requester
preferred tree treename
Replace treename with the name of your tree. Tree names can have up to 32
characters.
Default
None.
Example
To connect to a tree named Novell:
netware requester
preferred tree novell
ΓòÉΓòÉΓòÉ 18.6.8. request retries ΓòÉΓòÉΓòÉ
request retries
Use this setting to specify how many times NetWare Client for OS/2 tries to
resend a request following a communication error.
Syntax
netware requester
request retries number
Replace number with a number of retries greater than 5.
Default
20.
Decrease the default if you are connected to the network over a modem and you
do not want to waste phone time while NetWare Client for OS/2 keeps trying to
resend packets.
Example
To decrease the number of times NetWare Client for OS/2 tries to resend a
packet:
netware requester
request retries 10
ΓòÉΓòÉΓòÉ 18.6.9. sessions ΓòÉΓòÉΓòÉ
sessions
Use this setting to specify the number of connections NetWare Client for OS/2
can have to all servers.
Syntax
netware requester
sessions number
Replace number with a number of connections from 8 to 32. You must have at
least three IPX sockets for each session you allow. See sockets
Default
8 sessions
Example
To allow more server connections:
netware requester
sessions 20
You must also increase the sockets setting for the Protocol Stack IPX option
in this case.
ΓòÉΓòÉΓòÉ 18.6.10. signature level ΓòÉΓòÉΓòÉ
signature level
Use this setting to assign a signature level. Signature levels help determine
security on your network. Improving Security by Using NCP Packet Signature
explains more about signature levels.
Syntax
netware requester
signature level number
Replace number with 0, 1, 2, or 3.
List of NCP Packet Signature levels
Number Explanation
0 Workstation does not sign packets
1 Workstation signs packets only if the server requests it (server
option is 2 or higher)
2 Workstation signs packets if the server is capable of signing
(server option is 1 or higher)
3 Workstation signs packets and requires the server to sign packets
(or logging in will fail)
Default
1 (Workstation signs packets only if the server requests signing.)
Example
To prevent the workstation from signing packets:
netware requester
signature level 0
ΓòÉΓòÉΓòÉ 18.6.11. display hard errors ΓòÉΓòÉΓòÉ
display hard errors
Use this option to keep programs running without interaction when a hard error
is displayed. With this option set, hard errors are automatically returned to
the program that caused them rather than displayed to you for further
interaction.
This option is useful for sites with unattended workstations. Be careful about
using it in other environments as you might turn off important messages.
NoteHard errors display on a full screen and prompt you to choose among several
actions. These error messages cause background processes to suspend until you
respond to the message.
Syntax
netware requester
display hard errors off
To display error messages, leave this line out of your NET.CFG file.
Default
Error messages are displayed.
Example
To prevent hard error messages from displaying:
netware requester
display hard errors off
ΓòÉΓòÉΓòÉ 18.7. Protocol ODINSUP ΓòÉΓòÉΓòÉ
Protocol ODINSUP
Use this option to allow the NDIS protocol stack (used with Extended Services
and LAN Services) to communicate using ODI Token-Ring or Ethernet drivers. See
Using ODINSUP before using this option.
Syntax
protocol odinsup
bind driver [number]
Use this setting to bind the ODINSUP protocol to an ODI driver. When ODINSUP
is bound to a driver, the network board for that driver is the board used for
transmissions to and from the network.
Replace driver with a Token-Ring or Ethernet ODI driver name. See List of
Network Boards and Drivers for a list of common driver names.
Use number to bind ODINSUP to a particular occurrence of a board when you have
two boards with the same name. Replace number with a number from 1 to 4.
For example, if you have two NE2000 network boards in your workstation, bind
ODINSUP to each board by typing a 2 for the second board.
ODINSUP can be bound to a maximum of four ODI drivers.
Default
ODINSUP binds to the first Ethernet or Token-Ring board it locates.
Examples
To bind ODINSUP to a single NE2000 board in your workstation:
protocol ODINSUP
bind ne2000
To bind ODINSUP to both the first and the second NE2000 boards in your
workstation:
Protocol ODINSUP
bind ne2000
bind ne2000 2
ΓòÉΓòÉΓòÉ 18.8. Protocol Stack IPX ΓòÉΓòÉΓòÉ
Protocol Stack IPX
Use this option to adjust IPX communication between applications and the LAN
drivers in your workstation.
Syntax
protocol stack ipx
bind name
router mem size
sockets number
ΓòÉΓòÉΓòÉ 18.8.1. bind ΓòÉΓòÉΓòÉ
bind
Use this setting to specify the primary network board in your workstation. By
default, the primary board is the board whose driver loads first in the
CONFIG.SYS file. If you specify a different board with this setting, that
default is changed. See Network Boards and Drivers.
Syntax
protocol stack ipx
bind name
Replace name with the driver name for your network board. List of Network
Boards and Drivers lists common network boards.
Default
The first driver listed in your CONFIG.SYS file.
Example
To specify a 3Com Etherlink 3C503 board as primary:
protocol stack ipx
bind 3C503
ΓòÉΓòÉΓòÉ 18.8.2. router mem ΓòÉΓòÉΓòÉ
router mem
Use this setting to specify how many bytes in the router memory pool are
allocated for routing requests to the network.
Syntax
protocol stack ipx
router mem size
Replace size with a number of bytes.
Default
450 bytes
Since a size of 450 bytes accommodates up to 15 network boards per
workstation, you should not need to increase this default.
Example
To increase the default:
protocol stack ipx
router mem 500
ΓòÉΓòÉΓòÉ 18.8.3. sockets ΓòÉΓòÉΓòÉ
sockets
Use this setting to specify how many sockets IPX can open at your workstation.
Syntax
protocol stack ipx
sockets number
Replace number with a number of sockets between 9 and 128. If you are running
IPX with NetWare Client for OS/2 do not set this value below 32.
You need three sockets per server connection. The default of 64 works for the
default number of server connections. See sessions.
Allow more sockets if your workstation connects to many different servers or
runs protocols (such as Named Pipes) that require sockets.
Default
64 sockets
Example
To set the socket limit for a workstation connected to several servers that is
running Named Pipes and applications that require sockets:
protocol stack ipx
sockets 128
ΓòÉΓòÉΓòÉ 18.9. Protocol Stack SPX ΓòÉΓòÉΓòÉ
Protocol Stack SPX
Use this option to adjust the number and characteristics of SPX connections
between your workstation and other computers.
Syntax
protocol stack spx
abort timeout number
listen timeout number
retry count number
send timeout number
sessions number
verify timeout number
ΓòÉΓòÉΓòÉ 18.9.1. Abort, Listen, and Verify Timeouts ΓòÉΓòÉΓòÉ
Abort timeout, Listen timeout and Verify timeout
Use these settings to monitor and control SPX connections.
When SPX sessions at a sending computer do not receive transmissions from the
receiving computer for the length of the "verify timeout" interval, SPX sends a
keep-connection-alive packet to the receiving computer. SPX then waits the
length of the "listen timeout" interval to receive a response.
If no response is received, SPX sends another packet requesting immediate
acknowledgment. SPX then waits the length of the "abort timeout" interval to
receive a response.
If no response is received, SPX aborts the session.
Syntax
protocol stack spx
abort timeout number
listen timeout number
verify timeout number
Replace number with a number of milliseconds greater than 10.
The ratio between these settings must remain the same. For example, if you
double the Listen timeout value, you must also double the Abort timeout and
Verify timeout values.
If the machine you are setting up will be a Named Pipes server, double the
default timeout values.
Default
Abort timeout: 30,000 milliseconds
Listen timeout: 6,000 milliseconds
Verify timeout: 3,000 milliseconds
Example
To make SPX wait longer before sending a keep-connection-alive packet, sending
the packet requesting immediate response, or aborting the session:
protocol stack spx
abort timeout 40000
listen timeout 8000
verify timeout 4000
ΓòÉΓòÉΓòÉ 18.9.2. Retry Count ΓòÉΓòÉΓòÉ
Retry Count
Use this setting to specify the number of times your workstation will resend
packets that weren't acknowledged by the receiving computer the first time they
were sent.
NoteSome applications may set the "retry count" value. In these cases, the
application-set value is used and the NET.CFG value is ignored.
Syntax
protocol stack spx
retry count number
Replace number with a number of retries from 1 to 255.
If your network traffic is heavy or if you are transmitting across routers,
you may want to increase the default.
Default
12 retries
Example
To increase the number of times packets are resent:
protocol stack spx
retry count 30
ΓòÉΓòÉΓòÉ 18.9.3. Send Timeout ΓòÉΓòÉΓòÉ
Send Timeout
Use this setting to specify how long SPX waits between attempts to send packets
across the network.
Syntax
protocol stack spx
send timeout number
Replace number with a number of milliseconds greater than 500.
This default works well in almost all cases. Increase the default if you are
using network management products with a very large network and you encounter
many SPX connection errors.
You may also want to increase the default for a Named Pipes client that is
operating faster than the Named Pipes server to which it is connected.
Default
A continually calculated value based on the time it takes SPX to get a
response from the server.
Example
To increase the wait between sends:
protocol stack spx
send timeout 5600
ΓòÉΓòÉΓòÉ 18.9.4. Sessions ΓòÉΓòÉΓòÉ
Sessions
Use this setting to specify how many SPX connections can be open
simultaneously.
Syntax
protocol stack spx
sessions number
Replace number with a number of SPX connections greater than 8. Numbers higher
than 1,000 may not work in all circumstances.
If you run Named Pipes applications or other applications that use SPX, you
may need to increase the default number of sessions.
Default
16 sessions
Example
To increase the number of SPX sessions:
protocol stack spx
sessions 64
ΓòÉΓòÉΓòÉ 18.10. Token-Ring Source-Route Driver ΓòÉΓòÉΓòÉ
Token-Ring Source-Route Driver
Use this option to configure the Requester for source-routing between
Token-Ring networks that are connected with source routers. For more
information about source routing, see Using OS/2 Workstations on a Token-Ring
Network.
NoteDo not use this option if your Token-Ring networks do not use source
routing.
Syntax
protocol route
source route def gbr mbr nodes n board n
board
Use this setting to specify the logical board (frame) of a particular type
that is performing source routing.
Syntax
protocol route
source route board n
Replace n with a logical board (frame) number from 1 to 16.
For example, if a workstation has more than one frame type listed in the Link
Driver option, by default only the first listed frame is source routed. To
enable source routing on the second or other frames, you must explicitly
specify the second frame as logical board 2.
Default
1
Example
To specify that logical board 2, the Token-Ring_SNAP frame, will also be
source routed:
link driver token
frame token-ring
frame token-ring_snap
protocol route
source route board 1
source route board 2
DEF
Use this setting (default frame) to prevent frames that have unknown
destination addresses from being sent across Single Route IBM bridges.
If this setting is specified, these frames are forwarded as All Routes
Broadcast frames.
If this setting is not specified, all frames that have addresses not in the
workstation's Source Routing table are forwarded as Single Route Broadcast
frames.
If ROUTE.SYS has already been configured with the DEF setting, reloading
ROUTE.SYS with this setting broadcasts all subsequent Single Route Broadcast
frames as All Routes Broadcast frames.
Syntax
protocol route
source route def
Type DEF to broadcast on all routes. Omit DEF to broadcast on a single route
only.
Default
DEF is omitted (single-route broadcast only)
Change this default when you are unsure of the stability of one or more routes
in the network. Be aware that using DEF will substantially increase network
traffic, especially on large, redundant ring networks.
Example
To broadcast on all routes:
protocol route
source route def
GBR
Use this setting (general broadcast) to specify that all General Broadcast
frames are to be sent as All Routes Broadcast frames.
Syntax
protocol route
source route gbr
Type GBR to broadcast to all destinations, on all rings, by all routes. Omit
GBR to broadcast to all destinations, on all rings, by a single route.
Change the default when you want to ensure successful transmission across all
possible routes. If ROUTE has already been configured with this setting,
reconfiguring ROUTE with this setting broadcasts all subsequent General
Broadcast frames as All Routes Broadcast frames.
Default
GBR is omitted (single route broadcast only)
Example
To broadcast to all destinations, on all rings, by all routes:
protocol route
source route gbr
MBR
Use this setting (multicast) to specify that all Multicast Broadcast frames
are to be sent as All Routes Broadcast frames.
Syntax
protocol route
source route mbr
Type MBR to transmit multicast frames simultaneously to a group of
destinations by all possible routes. Omit MBR to transmit multicast frames by
a single route.
Default
MBR is omitted (transmit by single route only)
If ROUTE has already been configured with the MBR setting, reconfiguring ROUTE
with this parameter broadcasts all subsequent Multicast Broadcast frames as
All Routes Broadcast frames.
Example
To broadcast multicast frames simultaneously:
protocol route
source route mbr
nodes
Use this setting to specify the number of table entries in the source-routing
table.
Syntax
protocol route
source route nodes n
Replace n with a number of table entries from 8 to 255. If you type a number
less than 8, 8 will be used.
Default
16 entries
Example
To allow twenty-four entries in the source-routing table:
protocol route
source route nodes 24
ΓòÉΓòÉΓòÉ 19. System Messages ΓòÉΓòÉΓòÉ
System Messages
This section includes system messages and explanations for all NetWare Client
for OS/2 drivers and daemons. Messages for the NetWare Tools or the Network
Printer (NPRINTER.EXE) programs are not included. For information about
messages for those modules, see the System Messages manual.
REQ0106: An error occurred during attempt to get shared memory.
Explanation DDAEMON.EXE attempted to access the daemon's shared memory, but
failed. At this point, the program has verified that the shared
memory exists, but is unable to access it. This may be an
internal program error.
Action Try rebooting your system. If the problem persists, call your
Novell Authorized Reseller.
REQ0107: An error occurred during attempt to allocate a shared segment.
Explanation DDAEMON.EXE tried to create shared memory, but none is
available. This error usually occurs when the device drivers
and applications currently running on your system require more
memory than your system has available.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0108: The daemon cannot access the Link Support Layer. Error: <code>.
Explanation DDAEMON.EXE cannot find the Link Support device driver LSL.SYS.
Action Make sure that the device driver LSL.SYS has been properly
entered in the CONFIG.SYS file. If so, check the messages
displayed by the LSL for any errors or warnings, and correct
the problems indicated. Try again. If this error persists, call
your Novell Authorized Reseller.
REQ0109: The DDAEMON is already loaded.
Explanation DDAEMON.EXE tried to create shared memory for the first time,
but the memory already exists. Another daemon is already
running. The attempt to create shared memory is terminated.
Action Make sure that you are not trying to run multiple copies of the
daemon. Typically the daemon is run from the CONFIG.SYS file at
system startup and does not need to be executed again.
REQ0204: The system does not have enough memory for socket tables.
Explanation OS/2 lacks sufficient system memory for IPX to allocate memory
for its socket tables.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0205: The LAN support module could not be installed.
Explanation Either the LSL.SYS driver failed to load, or the "DEVICE="
statement is missing from the CONFIG.SYS file.
Action Either correct the problem that kept the LSL.SYS driver from
loading (indicated in an error message preceding this one), or
add the "DEVICE=" statement to the CONFIG.SYS file.
REQ0206: The IPX MLID could not be installed.
Explanation Either the Multiple Link Interface Driver (MLID) specified in
the CONFIG.SYS failed to load, or the "DEVICE=" statement for
an MLID is missing from the CONFIG.SYS file.
Action Either correct the problem that kept the MLID from loading
(indicated in an error message preceding this one), or add the
"DEVICE=" statement to the CONFIG.SYS file.
REQ0207: The configured LAN-A driver does not support IPX.
Explanation The Multiple Link Interface Driver (MLID) to which IPX.SYS
attempted to bind does not support IPX-based data
transmissions.
Action Bind IPX to an MLID that supports IPX-based data transmissions.
REQ0208: The IPX protocol handler cannot be registered.
Explanation IPX cannot register with the LSL.SYS driver because the LSL is
servicing its maximum number of protocol stacks.
Action Remove the "DEVICE=" statements for any unnecessary protocol
stacks from the CONFIG.SYS file.
REQ0209: The IPX entry point cannot be initialized.
Explanation The IPX and link support layer (LSL) versions may not be
compatible versions.
Action Make sure that the IPX.SYS driver and LSL.SYS driver are
compatible. If they are not, obtain compatible drivers from
your Novell Authorized Reseller. If this is not the problem,
contact your Novell Authorized Reseller for customer
assistance.
REQ0210: An internal error occurred. The IPX router socket cannot be opened.
Explanation IPX was unable to open the router socket due to an internal
program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0211: An internal error occurred. A router selector cannot be allocated.
Explanation IPX was unable to allocate an OS/2 router selector due to an
internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0212: The system has insufficient memory to allocate a router.
Explanation OS/2 cannot access sufficient system memory for IPX routing
purposes.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0213: Router memory is exhausted.
Explanation IPX did not have enough memory previously allocated for routing
purposes.
Action Increase the size of the IPX router memory in the NET.CFG
"ROUTER MEM" statement.
REQ0214: An internal error prevented CGroup variable initialization.
Explanation An internal program error has occurred. IPX was unable to
initialize internal variables.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0215: An internal error prevented DosHlp variable initialization.
Explanation OS/2 internal variables were either incomplete or invalid.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0216: IPX cannot register with OS/2 for PDD-to-VDD communications.
Explanation This is an internal program error. IPX cannot register with
OS/2 for VIPX.SYS driver support.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0217: The IPX device driver is not running.
Explanation Either IPX.SYS encountered a fatal error during system
initialization, or the "DEVICE=[path]IPX.SYS" statement was
missing from the CONFIG.SYS file. If the problem is a fatal
error, another message should precede this one that identifies
the specific error that occurred.
Action Either resolve the fatal problem (indicated in a preceding
message), or add the "DEVICE=" statement to the CONFIG.SYS
file; then try again. If the problem persists, contact your
Novell Authorized Reseller.
REQ0231: The default protocol configuration option is not used for IPX.
Explanation IPX cannot be configured as a default protocol stack.
Action Remove this option statement from the NET.CFG file.
REQ0232: The prescan protocol configuration option is not used for IPX.
Explanation IPX cannot be configured as a prescan protocol stack.
Action Remove this option statement from the NET.CFG file.
REQ0233: The OS/2 version number cannot be found; OS/2 v2.0 is assumed.
Explanation IPX's query of OS/2 for the version number returned a value
that did not match the value it expected to receive.
Action Make sure the OS/2 version installed on the machine is v2.0 or
later.
REQ0304: An LSL error occurred. NET.CFG buffers are too big for ECB pool.
Explanation The configured buffer size for the Link Support component is
too large. Total available buffer space is around 60 KB, but
the Link Support Layer (LSL) is unable to allocate even one
buffer of the requested size in its buffer space. See "Link
Support Layer" in Concepts for more information about LSL.
Action Reduce the Link Support component's buffer size in the NET.CFG
file. It is more important to have several smaller buffers
available than one large one. It is a waste of system memory to
configure buffers much larger than the communications media can
support.
REQ0305: The Link Support module (LSL) could not install the AES timer.
Explanation The Link Support Layer (LSL) could not register its timer
handler with the operating system because the maximum number of
handlers have already been installed. This timer handler is a
critical component of the Requester, and none of the
Novell-supplied communication handlers can be expected to work
properly without it. See "Link Support Layer" in Concepts for
more information about LSL.
Action Previously installed device drivers (those entered before
LSL.SYS in the CONFIG.SYS file) have used all available timer
resources. Identify those device drivers and either remove or
reconfigure them. Since the Requestor's communications handlers
all use a common timer service in the LSL, only one available
timer handler is required for proper operation. If you are
unable to resolve this problem, contact your Novell Authorized
Reseller.
REQ0306: The Link Support module could not initialize its call gate.
Explanation The Link Support module could not register its entry point with
the operating system. This entry point is vital to most of the
Requester's communications components, and its absence will
cause them to fail. The most likely cause of this error is a
previously loaded device driver that is using too many kernel
resources.
Action Try removing application device drivers installed before
LSL.SYS in the CONFIG.SYS file. It is highly unlikely that a
device driver from the OS/2 base system has caused this error.
If the problem persists, contact your Novell Authorized
Reseller.
REQ0404: NetBIOS error occurred. Link Support module cannot be installed.
Explanation NetBIOS could not open or communicate with the Link Support
LINKSUP_ device driver. This can happen if the Link Support
Layer (LSL) driver has not been properly installed or if you
are using the wrong version of the driver. See "Link Support
Layer" in Concepts for more information about LSL.
Action Make sure that the device driver LSL.SYS has been properly
entered in the CONFIG.SYS file. If so, check the messages
displayed by the LSL for any errors or warnings, and correct
the problems indicated. If the Link Support device driver is
initializing properly, the problem is with incompatible
versions of the software. NetBIOS and Link Support are usually
installed together from a single installation diskette. Try
reinstalling them. If the problem persists, contact your Novell
Authorized Reseller.
REQ0405: NetBIOS error occurred. The IPX module is not installed.
Explanation NetBIOS could not open or communicate with the Link Support
LINKSUP_ device driver. This can happen if the Link Support
Layer (LSL) driver has not been properly installed or if you
are using the wrong version of the driver. See "Link Support
Layer" in Concepts for more information about LSL.
Action Make sure that the device driver LSL.SYS has been properly
entered in the CONFIG.SYS file. If so, check the messages
displayed by the LSL for any errors or warnings, and correct
the problems indicated. If the Link Support device driver is
initializing properly, the problem is with incompatible
versions of the software. NetBIOS and Link Support are usually
installed together from a single installation diskette. Try
reinstalling them. If the problem persists, contact your Novell
Authorized Reseller.
REQ0406: The NetBIOS call gate cannot be initialized.
Explanation This is an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0407: NetBIOS error occurred. The program cannot initialize local NCBs.
Explanation Insufficient memory is available for the NCBs requested.
Usually this error is caused by incorrect configuration
information in the NET.CFG file. However, the underlying
problem could also be a lack of global system resources in the
OS/2 Global Descriptor Table.
Action Reduce the number of commands in the NetBIOS section of the
CONFIG.SYS file. (The default number of commands is 12; the
maximum allowed is 25.) You also might be able to reduce the
number of node names (possible range is 0-126). Additional
possibilities include adding RAM, reducing your configuration
options (for example, reducing the size of DIRCACHE) or
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2 and then reboot the system. If the problem persists,
contact your Novell Authorized Reseller.
REQ0408: NetBIOS emulator parameters are too large for the memory pool.
Explanation Insufficient memory is available for all of the control tables
needed by the NetBIOS emulator.
Action The amount of table space available to the NetBIOS emulator
cannot be increased. The only way to solve this problem is to
reduce the number of NetBIOS resources you are requesting. You
can do this by modifying the NETBIOS parameters in the NET.CFG
file. If the problem persists, contact your Novell Authorized
Reseller.
REQ0409: Incompatible versions of OS/2 and NetBIOS are running.
Explanation You are attempting to run NetBIOS v2.10 on some version of OS/2
earlier than OS/2 v2.1.
Action Either install OS/2 v2.1 to run with NetBIOS v2.10, or install
a different version of NetWare NetBIOS to match your OS/2
version.
REQ0504: The SPX module is not installed.
Explanation The NMPIPE.SYS driver could not open or communicate with the
SPX.SYS driver.
Action Make sure that the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated; then try again. If the problem persists, contact
your Novell Authorized Reseller.
REQ0505: The IPX module is not installed.
Explanation NMPIPE.SYS could not open or communicate with the IPX.SYS
driver.
Action Make sure that the IPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated; then try again. If the problem persists, contact
your Novell Authorized Reseller.
REQ0519: An incorrect OS/2 version is being used.
Explanation Either the DosGetVersion call failed (an internal program
error), or the OS/2 version currently running is not v2.0 or
later.
Action Make sure the client OS and NMPIPE.SYS driver are compatible
versions. If the problem persists, contact your Novell
Authorized Reseller.
REQ0520: The driver cannot register the PDD for VDD-to-PDD communications.
Explanation NMPIPE.SYS could not register IPX as a PDD so that PDD to VDD
communication may take place.
Action Make sure the IPX.SYS driver has been properly entered in the
CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure the OS/2 version is v2.0 or later;
then try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0613: Invalid characters were specified in COMPUTERNAME.
Explanation The Named Pipes server name specified after NPDAEMON.EXE is
invalid.
Action Make sure the server name is not more than 15 characters and is
composed of letters, numbers, and these special characters:
!#$%&()-.@^_Γö┤{}~
REQ0614: An error occurred during attempt to initialize NPCALLS.DLL.
Explanation The NPDaemon could not initialize NPCALLS.DLL.
Action Make sure the NPCALLS.DLL file in the NetWare Requester
directory is included in the LIBPATH statement of the
CONFIG.SYS file. If you are running Named Pipes, make sure the
NMPIPE.SYS driver and NPSERVER.SYS are correctly configured in
the CONFIG.SYS file.
REQ0615: The Named Pipes daemon could not be registered. Error: <code>.
Explanation The NPDaemon could not open or communicate with the NMPIPE.SYS
driver.
Action Make sure the NMPIPE.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems.
Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0616: An error occurred during attempt to allocate shared memory.
Explanation The NPDaemon could not allocate shared memory.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0617: An error occurred during attempt to allocate the ECB pool.
Explanation The NPDaemon could not allocate memory for the ECB pool.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0618: An error occurred during attempt to create a system semaphore.
Explanation A DosCreateSem call failed. An internal program error may have
occurred.
Action Try again. If the error persists, contact your Novell
Authorized Reseller.
REQ0619: An error occurred during attempt to create a thread.
Explanation A beginthread call failed. An internal program error may have
occurred.
Action Try again. If the error persists, contact your Novell
Authorized Reseller.
REQ0620: A dynamic socket could not be opened. Error: <code>.
Explanation The NPDaemon failed to open a dynamic socket.
Action Increase the socket count specified in the NET.CFG file; then
reboot the system and try again. If the problem persists,
contact your Novell Authorized Reseller.
REQ0621: A well-known socket could not be opened. Error: <code>.
Explanation The NPDaemon could not open Netware's registered Named Pipe
socket; the socket may already be in use.
Action Increase the SPX socket count in the NET.CFG and shut down
OS/2; then reboot the system.
REQ0622: The NPDaemon cannot get the internet address. Error: <code>.
Explanation An IpxGetInternetworkAddress call failed.
Action Make sure the IPX.SYS driver has been properly entered in the
CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure the IPXCALLS.DLL file is in the
NetWare Requester directory; then try again. If the problem
persists, notify your Novell Authorized Reseller.
REQ0623: The NPDaemon cannot get the local target. Error: <code>.
Explanation An IpxGetLocalTarget call failed.
Action Make sure the IPX.SYS driver has been properly entered in the
CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure the IPXCALLS.DLL file is in the
NetWare Requester directory; then try again. If the problem
persists, contact your Novell Authorized Reseller.
REQ0624: The service advertising function failed. Error: <code>.
Explanation An IpxSend call to advertise this workstation as Named Pipe
Server failed.
Action Make sure the IPX.SYS driver has been properly entered in the
CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure the IPXCALLS.DLL file is in the
NetWare Requester directory; the try again. If the problem
persists, contact your Novell Authorized Reseller.
REQ0625: The broadcast socket cannot be opened. Error: <code>.
Explanation The broadcast socket cannot be opened. This is a registered
socket by which SAPs can be received. Possibly this socket has
already been opened.
Action Increase the socket count in the NET.CFG file and shut down
OS/2 and then reboot the system. If the problem persists,
contact your Novell Authorized Reseller.
REQ0626: An error occurred during attempt to get code page information.
Explanation A call to DosGetCtryInfo failed. This may be an internal
program error.
Action Make sure the OS/2 is version 2.0 or later. If so, and the
problem persists, contact your Novell Authorized Reseller.
REQ0628: Memory cannot be allocated for turbo buffers.
Explanation The NPDaemon could not allocate memory for turbo buffers.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0629: A connection thread died abnormally. Error: <code>.
Explanation The connection controller thread died unexpectedly.
Action Make sure that the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure all of your Named Pipe drivers are
within the same major version (for example, v2.x); then try
again. If the problem persists, contact your Novell Authorized
Reseller.
REQ0630: The specified computer name is already registered on the internet.
Explanation The Named Pipes server name specified in the CONFIG.SYS file
has already been used on the network.
Action Use a different server name.
REQ0631: The receive buffer manager died abnormally. Error: <code>.
Explanation The receive buffer manager thread died unexpectedly.
Action Make sure that your Named Pipes drivers are within the same
major version (for example, v2.x). If so, try adding RAM,
reducing your configuration options in the CONFIG.SYS file (for
example, reducing the size of DIRCACHE), removing optional
device drivers from the CONFIG.SYS file, and freeing up some
hard disk space by deleting unnecessary programs. If you are
using multiple disk partitions, consider moving the OS/2
swapper file to a larger partition. Disk compression utilities
may also be available that can help resolve this problem. After
completing these actions, shut down OS/2; then reboot the
system. If the problem persists, contact your Novell Authorized
Reseller.
REQ0635: General Service Query for Named Pipe Servers failed. Error: %1 %0
Explanation A call to IpxSend to issue a general service query for named
Pipe Servers failed.
Action Make sure the IPX.SYS driver has been properly entered in the
CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also make sure the IPXCALLS.DLL file is in the
NetWare Requester directory.Try again. If the problem persists,
contact your Novell authorized reseller.
REQ0636: An error occurred while obtaining the IPX card table.%0
Explanation A call to the npserver.sys driver to obtain the IPX card table
failed.
Action Make sure the IPX.SYS driver and the NPSERVER.SYS driver have
been properly entered in the CONFIG.SYS file. If so, check the
messages displayed by the drivers for any errors or warnings,
and correct the problems indicated. Also make sure the
IPXCALLS.DLL and NPCALLS.DLL files are in the NetWare Requester
directory. Try again. If the problem persists, contact your
Novell Authorized Reseller.
REQ0704: The SPX module is not installed.
Explanation The Named Pipes daemon could not open or communicate with the
SPX.SYS driver.
Action Make sure that the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated; then try again. If the problem persists, contact
your Novell Authorized Reseller.
REQ0705: The IPX module is not installed.
Explanation The Named Pipes daemon could not open or communicate with the
IPX.SYS driver.
Action Make sure that the IPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated; then try again. If the problem persists, contact
your Novell Authorized Reseller.
REQ0719: An incorrect OS/2 version is being used.
Explanation The DosGetVersion call failed (which would indicate an internal
program error) or the OS/2 version currently running is not
v2.0 or later.
Action Make sure that the client OS and NMPIPE.SYS driver are
compatible; then try again. If the problem persists, contact
your Novell Authorized Reseller.
REQ0806: The program cannot get code page information. Error: <code>.
Explanation The OS/2 system is not returning code page information. This
may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0807: The Requester device driver and daemon are incompatible versions.
Explanation The most likely cause of this problem is that NWDAEMON.EXE and
NWREQ.SYS driver were not installed from the same installation
disk.
Action Install the Requester driver again, making sure it is from the
correct installation disk.
REQ0808: The worker DLL cannot be registered. Error: <code>.
Explanation The NWWORKER.DLL could not register with the Requester. This
may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0809: The broadcast handler cannot be registered. Error: <code>.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0810: The program cannot get system information. Error: <code>.
Explanation The OS/2 system is not returning system information. This may
be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0811: The janitor thread priority cannot be set. Error: <code>.
Explanation The janitor thread is set to run at regular priority. The
system had trouble setting the priority.
Action Ignore the error.
REQ0812: The janitor daemon cannot be registered. Error: <code>.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0813: The program cannot get the current drive map. Error: <code>.
Explanation The OS/2 system is not returning the current drive map. This
may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0814: The program cannot set the current drive map. Error: <code>.
Explanation The OS/2 system is not setting the current drive map. This may
be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0815: The program cannot get the connection ID. Error: <code>.
Explanation The Requester tried to locate a NetWare server when it
initialized. Either no servers are currently running or a
cabling problem exists.
Action Make sure the NetWare server is running and functioning
properly. Also make sure the OS/2 machine has a working
connection to the network; then try again. If the problem
persists, contact your Novell Authorized Reseller.
REQ0816: An error occurred during attempt to initialize the cache.
Explanation The caching function is not working. This may be an internal
program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0817: The daemon could not boost the thread priority.
Explanation The thread is set to run at a greater priority. The system had
trouble setting the priority.
Action Ignore the error.
REQ0818: The daemon could not register the DosBox handler.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0820: Not enough memory for diagnostic daemon. Error: <code>.
Explanation The NWDaemon program tried to allocate memory from the system
for the diagnostic thread to use as a stack, but the system
returned an error.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0821: The diagnostic daemon cannot be started. Error: <code>.
Explanation The NWDaemon tried to start the diagnostic thread but the
system encountered an error condition. The system may have too
many threads already running, or this may be an internal
program error.
Action Try closing other applications that are currently running. If
the problem persists, contact your Novell Authorized Reseller.
REQ0822: The diagnostic daemon priority cannot be changed. Error: <code>.
Explanation The diagnostic thread is set to run at regular priority. The
system had trouble setting the priority.
Action Ignore the error.
REQ0823: Not enough memory to start a new thread. Error: <code>.
Explanation The NWDaemon could not allocate memory from the system to
create a thread for a new task.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0824: The SPX send thread cannot be started. Error: <code>.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0825: The SPX receive thread cannot be started. Error: <code>.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0826: The SFT 3 handler cannot be registered.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0827: Packet Burst cannot be initialized.
Explanation This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ0843: Not enough memory for a network management thread (<error code>).
Explanation The NWDaemon tried to allocate memory from the system for a
thread to initialize network management, but memory was not
available. Network management cannot be initialized.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0844: A named pipe cannot be started for network management (<error code>).
Explanation The NWDaemon could not allocate a named pipe. Network
management will not be supported until the computer is
rebooted. This error could result from a variety of causes.
Named Pipes or SPX may not be loaded, one of your drivers may
have opened too many Named Pipes already, you may not have
enough memory or disk space, or it may be an internal program
error.
Action Make sure that Named Pipes and SPX are loaded and that your
system has enough memory. (If you suspect a memory problem, see
the discussion for message 843.) After completing these
actions, reboot the system and try again. If the problem
persists, contact your Novell Authorized Reseller.
REQ0845: Not enough memory to run network management (<error code>).
Explanation The NWDaemon program tried to allocate memory from the system
to run network management, but memory is not available. Network
Management will not run until memory is available and the
system is rebooted.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0904: The NWREQ.SYS driver is not loaded.
Explanation NetWare Client for OS/2 cannot be initialized until the driver
is loaded.
Action Load the NWREQ.SYS driver.
REQ0914: The program cannot allocate selectors for the workspace table.
Explanation All available memory selectors are being used by the system or
by previously loaded device drivers.
Action Remove optional or unneeded device drivers from the CONFIG.SYS
file and try again. If the problem persists, contact your
Novell Authorized Reseller.
REQ0915: The program cannot allocate memory for the workspace table.
Explanation All available system memory is in use. NetWare Client for OS/2
cannot load properly.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0917: Memory is not available for the cache table. Caching is disabled.
Explanation All available system memory is in use by the system. NetWare
Client for OS/2 cannot load properly.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ0919: An incorrect OS/2 version is being used.
Explanation The major versions of NetWare Client for OS/2 and OS/2 do not
match.
Action Upgrade NetWare Client for OS/2 or OS/2.
REQ0937: The Requester driver version does not match the IFS version.
Explanation NWIFS.IFS and NWREQ.SYS were not installed from the same
installation disk.
Action Install NetWare Client for OS/2 again. If the problem persists,
contact your Novell Authorized Reseller.
REQ1005: The LAN support module is not installed.
Explanation NetWare Client for OS/2 driver requires the LSL.SYS driver to
be running when it loads. Either the
"DEVICE=C:\NETWARE\LSL.SYS" line is missing from the CONFIG.SYS
file or the LSL encountered an error while loading.
Action Check the CONFIG.SYS file for the LSL.SYS driver. If this is
not the problem, contact your Novell Authorized Reseller.
REQ1008: A NetWare server cannot be found.
Explanation NetWare Client for OS/2 tries to locate a NetWare server when
it initializes. Either no servers are currently running or
there is a cabling problem.
Action Make sure that the NetWare server is running and operating
properly. Also make sure that the OS/2 machine is connected to
the network.
REQ1010: The program cannot allocate selectors for the connection table.
Explanation All available memory selectors are being used by the system or
by previously loaded device drivers.
Action Remove optional or unneeded device drivers from the CONFIG.SYS
file and try again. If the problem persists, contact your
Novell Authorized Reseller.
REQ1011: The program cannot allocate memory for the connection table.
Explanation All available system memory is in use. NetWare Client for OS/2
cannot load properly.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system.If the problem persists, contact
your Novell Authorized Reseller.
REQ1019: An incorrect OS/2 version is being used.
Explanation The major version of NetWare Client for OS/2 and OS/2 do not
match.
Action Upgrade NetWare Client for OS/2 or OS/2.
REQ1021: The config file cannot be parsed. Default parameters will be used.
Explanation NetWare Client for OS/2 driver could not read parameters in the
NET.CFG file.
Action Make sure the syntax for the NetWare Requester section of the
file is correct.
REQ1022: An unrecoverable error occurred. The driver was not loaded.
Explanation The driver could not load properly. This is probably an
internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1024: The program cannot allocate selectors for worker support.
Explanation All available memory selectors are being used by the system or
by previously loaded device drivers.
Action Remove optional or unneeded device drivers from the CONFIG.SYS
file. Then try again. If the problem persists, contact your
Novell Authorized Reseller.
REQ1038: The program cannot allocate memory for the error message buffer.
Explanation All available system memory is in use by the system. NetWare
Client for OS/2 cannot load properly.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ1039: The Requester could not send to NetWare server <number> as <number>.
Explanation NetWare Client for OS/2 waits for a response from the server
after each request. If the server does not respond within a
certain amount of time, NetWare Client for OS/2 times out.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1040: The Requester timed out waiting for reply from server <number>.
Explanation NetWare Client for OS/2 waits for a response from the server
after each request. If the server does not respond within a
certain amount of time, NetWare Client for OS/2 times out.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1041: Server <number> did not respond to a request.
Explanation NetWare Client for OS/2 waits for a response from the server
after each request. If the server does not respond within a
certain amount of time, NetWare Client for OS/2 times out. This
error can also occur if the server responds with an unexpected
response.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1042: Connection to NetWare server <number> as <number> is now invalid.
Explanation NetWare Client for OS/2 waits for a response from the server
after each request. If the server does not respond within a
certain amount of time, NetWare Client for OS/2 times out.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1043: Routing to NetWare server <number> has been disrupted.
Explanation The network route to the server has been disrupted.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1045: Routing to NetWare server <number> has been disrupted.
Explanation The network route to the server has been disrupted.
Action Make sure that the server is still running and functioning
properly. Also make sure that all routers between the
workstation and the server are still running. If the problem
persists, contact your Novell Authorized Reseller.
REQ1106: The SPDaemon cannot get the SPX version. Error: <code>.
Explanation The SpxGetVersion call failed. This may be an internal program
error.
Action Make sure that the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Check for a mismatch of driver versions. If the
problem persists, contact your Novell Authorized Reseller.
REQ1107: The SPX driver and the SPX daemon are incompatible versions.
Explanation The SPX.SYS driver and SPDAEMON.EXE versions may not match.
Action Make sure that the client SPX.SYS driver and SPDAEMON.EXE are
compatible versions. If the problem persists, contact your
Novell Authorized Reseller.
REQ1108: The SPX driver entry cannot be obtained. Error: <code>.
Explanation The SPDaemon could not get a handle to the SPX.SYS driver. This
may be an internal program error.
Action Make sure that the client SPX.SYS driver and SPDAEMON.EXE
versions are compatible. If the problem persists, contact your
Novell Authorized Reseller.
REQ1109: The SPX daemon is already loaded. Error: <code>.
Explanation The SPDAEMON.EXE has already registered with the SPX.SYS
driver, which means it is already loaded.
Action Make sure that the daemon SPDAEMON.EXE has not been entered in
the CONFIG.SYS file more than once.
REQ1110: The daemon cannot register with the SPX driver. Error: <code>.
Explanation The SPDaemon cannot communicate with the SPX.SYS driver.
Action Make sure that the SPX.SYS file has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Check for a mismatch of driver versions. If the
problem persists, contact your Novell Authorized Reseller.
REQ1111: The SPX device handle cannot be closed. Error: <code>.
Explanation The SPDeamon cannot close the device handle. This may be an
internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1112: The SPDaemon cannot wait on semaphore. Error: <code>.
Explanation A DosSemSetWait call failed. This may be an internal program
error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1113: System information segments cannot be obtained. Error: <code>.
Explanation The DosGetInfoSeg call failed. This may be an internal program
error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1114: Priority for the lock thread cannot be set. Error: <code>.
Explanation The DosSetPrty call failed. This may be internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1115: The SPX driver cannot be accessed. Error: <code>.
Explanation The SPDaemon was not able to access SPX.SYS through the call
gate.
Action Make sure that the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Also check for a mismatch of driver versions; then
try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1116: Priority for an AES thread cannot be set. Error: <code>.
Explanation The DosSetPrty call failed. This may be an internal program
error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1117: Priority for a watchdog thread cannot be set. Error: <code>.
Explanation The DosSetPrty call failed. This may be an internal program
error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1118: Priority for a session thread cannot be set. Error: <code>.
Explanation The DosSetPrty call failed. This may be an internal program
error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1119: The SPXCALLS.DLL cannot register with the SPX driver.
Explanation The SPXCALLS.DLL cannot communicate with the SPX.SYS driver.
Action Check to see if the SPX.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Check for a mismatch of driver versions; then try
again. If the problem persists, contact your Novell Authorized
Reseller.
REQ1205: The driver cannot initialize the CGroup Data variables.
Explanation Normally, key data variable are stored in the driver's CGroup
for easy and reliable access. However, in this instance the
variables could not be initialized due to a memory-related
error.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ1206: The driver cannot configure SPX.
Explanation The driver in conjunction with the NWCONFIG.DLL failed to parse
the NET.CFG file for the SPX parameters.
Action Make sure the format of the NET.CFG file is correct.
REQ1207: The driver failed to get support hooks from the LSL or IPX.
Explanation SPX could not open or communicate with either the LINKSUP_
(LSL.SYS) or the IPX_ (IPX.SYS) drivers. The most likely cause
of this error is that one or both of these drivers has been
improperly installed.
Action Make sure that the device drivers LSL.SYS and IPX.SYS have been
properly entered in the CONFIG.SYS file. If so, check the
messages displayed by the driver for any errors or warnings,
and correct the problems indicated. Check for a mismatch of
driver versions; then try again. If the problem persists,
contact your Novell Authorized Reseller.
REQ1208: The OS/2 version cannot be obtained; OS/2 v2.0 is assumed.
Explanation The DosGetVersion call failed (an internal program error), or
the OS \2 version currently running is not v2.0 or later.
Action Make sure that OS/2 and the SPX.SYS driver are compatible
versions. If this is not the problem, contact your Novell
Authorized Reseller.
REQ1209: The driver cannot get OS/2 DOS variables.
Explanation The SPX.SYS driver could not obtain either the system or local
information segment. This may be an internal program error.
Action Try again. If the problem persists, contact your Novell
Authorized Reseller.
REQ1210: The driver cannot initialize the SPX call gate.
Explanation The SPX.SYS driver could not register a call gate with the
LSL.SYS driver.
Action Make sure that the LSL.SYS driver has been properly entered in
the CONFIG.SYS file. If so, check the messages displayed by the
driver for any errors or warnings, and correct the problems
indicated. Check for a mismatch of driver versions; then try
again. If the problem persists, contact your Novell Authorized
Reseller.
REQ1211: The driver cannot allocate memory for SPX use.
Explanation The system does not have enough memory to run SPX.
Action Try adding RAM, reducing your configuration options in the
CONFIG.SYS file (for example, reducing the size of DIRCACHE),
removing optional device drivers from the CONFIG.SYS file, and
freeing up some hard disk space by deleting unnecessary
programs. If you are using multiple disk partitions, consider
moving the OS/2 swapper file to a larger partition. Disk
compression utilities may also be available that can help
resolve this problem. After completing these actions, shut down
OS/2; then reboot the system. If the problem persists, contact
your Novell Authorized Reseller.
REQ1301: The application cannot initialize named pipes.
Explanation The application could not open or communicate with the
NMPIPE.SYS driver. Most likely, the NMPIPE.SYS driver is not
entered in the CONFIG.SYS file.
Action Make sure that the NMPIPE.SYS driver has been properly entered
in the CONFIG.SYS file. If so, check the messages displayed by
the driver for any errors or warnings, and correct the problems
indicated. If the problem persists, contact your Novell
Authorized Reseller.
ΓòÉΓòÉΓòÉ 20. Troubleshooting Tips and Where To Go for Help ΓòÉΓòÉΓòÉ
Troubleshooting Tips and Where To Go for Help
Troubleshooting Tips
Verify that:
Γûá Frame types are set the same on the workstation and the server.
Γûá Board configurations and software parameters match.
Γûá NET.CFG parameters, such as name context, match your NetWare system
configuration.
Γûá Network cabling is within IEEE specifications and is properly connected and
terminated.
Γûá All network software is the most recent version available.
Where To Go for Help
Novell offers a varitey of support, including
Γûá Novell Technical Support
Γûá NSEPRO
Γûá Your Novell Authorized Reseller
Γûá NetWire on CompuServ
Γûá Novell Application Notes
For more information, call 1-800-NETWARE.
For more information about OS/2, contact your IBM representative.
ΓòÉΓòÉΓòÉ 21. Architecture Diagrams ΓòÉΓòÉΓòÉ
Architecture Diagrams
These diagrams provide a technical overview of NetWare Client for OS/2*.
They can help you understand what components are used for the various functions
NetWare Client for OS/2 performs (for example, which components are used to
support Named Pipes).
Specifically, the diagrams illustrate
ΓûáThe major functions of NetWare Client for OS/2 components
ΓûáThe different components of NetWare Client for OS/2
ΓûáThe relationships between components
NoteYou do not need to manually load the components shown in the diagrams.
Select the settings you want in the NetWare Client for OS/2 installation
program, and the correct components will be loaded.
To change the settings later, run the installation program again. Topics and
architecture diagrams
NetWare Requests from OS/2 Sessions
NetWare Core Protocol Requests
File System Requests
Protocol Requests from OS/2 Sessions
IPX-Only Requests
SPX Requests
Named Pipes Server Requests
Named Pipes Client Requests
NetBIOS Requests
NetWare Requests from DOS/MS Windows Sessions
DOS/MS Windows NetWare Core Protocol Requests
DOS/MS Windows File System Requests
Protocol Requests from DOS/MS Windows Sessions
DOS/MS Windows SPX- or IPX-Only Requests
DOS/MS Windows Named Pipes Client Requests
DOS/MS Windows SQL Client Get Server Requests
DOS and MS Windows NetBIOS Requests
NetBIOS Submit Requests Using Only Novell NetBIOS Driver with Extended Services
Loaded
Sharing a Network Board
NetWare Client for OS/2 and IBM Software Using ODINSUP to Share a Network Board
NetWare Client for OS/2 and IBM Software Using LANSUP to Share a Network Board
ΓòÉΓòÉΓòÉ 21.1. NetWare Core Protocol Requests ΓòÉΓòÉΓòÉ
NetWare Core Protocol Requests
NetWare Core Protocol (NCP) requests go directly to the NetWare server without
going through OS/2.
Some NetWare utilities issue this kind of request. These requests are usually
accompanied by file system requests.
ΓòÉΓòÉΓòÉ 21.2. File System Requests ΓòÉΓòÉΓòÉ
File System Requests
File system requests are handled by OS/2 before being passed on to NetWare
Client for OS/2. Any program which manipulates files on the network makes this
kind of request.
These requests are always accompanied by NetWare Core Protocol requests.
ΓòÉΓòÉΓòÉ 21.3. IPX-Only Requests ΓòÉΓòÉΓòÉ
IPX-Only Requests
IPX requests are issued by IPX applications, including NetWare Client for OS/2.
ΓòÉΓòÉΓòÉ 21.4. SPX Requests ΓòÉΓòÉΓòÉ
SPX Requests
SPX requests are issued by SPX applications. Some NetWare print utilities and
API calls use SPX.
ΓòÉΓòÉΓòÉ 21.5. Named Pipes Server Requests ΓòÉΓòÉΓòÉ
Named Pipes Server Requests
Named Pipes server requests are made by Named Pipes distributed application
servers.
ΓòÉΓòÉΓòÉ 21.6. Named Pipes Client Requests ΓòÉΓòÉΓòÉ
Named Pipes Client Requests
Named Pipes client requests are issued by Named Pipes distributed application
clients.
ΓòÉΓòÉΓòÉ 21.7. NetBIOS Requests ΓòÉΓòÉΓòÉ
NetBIOS Requests
What is NetBIOS
NetBIOS is a "device-independent" protocol that lets applications use network
boards without knowing the specifics of how the drivers for those boards work.
NetBIOS applications issue NetBIOS commands which are routed to a specific
network board driver. That driver handles the transmission of NetBIOS packets
over the network.
What is the Novell NetBIOS Emulator
Novell provides a NetBIOS emulator that allows applications running on an
IPX-based network (such as NetWare) to communicate using NetBIOS.
This NetBIOS emulator encapsulates NetBIOS packets inside of IPX packets. Then
an ODI driver handles transmission of the IPX packets over the network.
While your NetBIOS application communicates using NetBIOS commands, the NetBIOS
emulator actually transmits IPX packets.
The Novell NetBIOS emulator can only communicate with other emulators that use
IPX.
For example, if you have one workstation running the NetBIOS emulator and
another workstation running IBM's NetBIOS, the two workstations cannot
communicate.
However, the NetBIOS emulator can run on the same OS/2 workstation as other
NetBIOS implementations, including the NetBIOS provided with IBM Extended
Services or LAN Services. Or, the NetBIOS emulator can run by itself.
NetBIOS requests are issued by applications which use Novell NetBIOS emulation.
If Extended Services or LAN Services is installed, requests follow a different
path.
NetBIOS Submit Requests Using Only Novell NetBIOS Driver
NetBIOS Submit Requests Using Only Novell NetBIOS Driver with Extended Services
Loaded
NetBIOS Submit Requests Using Either Novell or IBM NetBIOS Driver with LAN
Services Loaded
NB30 NetBIOS Requests Using Either Novell or IBM NetBIOS Driver with Extended
Services Loaded
ΓòÉΓòÉΓòÉ 21.8. NetWare Requests from DOS/MS Windows Sessions ΓòÉΓòÉΓòÉ
NetWare Requests from DOS/MS Windows Sessions
When you select support for virtual DOS sessions in the NetWare Client for OS/2
installation program, the installation program adds lines to the CONFIG.SYS
file to load the VIPX and VSHELL components.
The NETWARE_RESOURCES and VIPX_ENABLED properties are also created and added to
the DOS Settings notebook of all DOS and Windows icons.
These properties allow you to choose global support, private support, or no
network support for each session.
Γûá If you choose global support, VIPX and VSHELL are enabled for the session.
Γûá If you choose private support, VIPX is enabled, VSHELL is not enabled, and
you can manually load NETX.EXE
Γûá If you don't load NETX.EXE, you receive IPX- and SPX-only support.
Γûá If you choose VIPX_ENABLED OFF, then no NetWare support is loaded.
VIPX must be enabled for either global (using VSHELL) or private (using NETX)
sessions to work.
DOS/MS Windows NetWare Core Protocol Requests
DOS/MS Windows File System Requests
ΓòÉΓòÉΓòÉ 21.9. DOS/MS Windows SPX- or IPX-Only Requests ΓòÉΓòÉΓòÉ
DOS/MS Windows SPX- or IPX-Only Requests
ΓòÉΓòÉΓòÉ 21.10. DOS/MS Windows Named Pipes Client Requests ΓòÉΓòÉΓòÉ
DOS/MS Windows Named Pipes Client Requests.
ΓòÉΓòÉΓòÉ 21.11. DOS/MS Windows SQL Client Get Server Requests ΓòÉΓòÉΓòÉ
DOS/MS Windows SQL Client Get Server Requests
ΓòÉΓòÉΓòÉ 21.12. DOS and MS Windows NetBIOS Requests ΓòÉΓòÉΓòÉ
DOS and MS Windows NetBIOS Requests
ΓòÉΓòÉΓòÉ 21.13. DOS and MS Windows NetBIOS Requests with Extended Services Loaded ΓòÉΓòÉΓòÉ
DOS and MS Windows NetBIOS Requests with Extended Services Loaded
ΓòÉΓòÉΓòÉ 21.14. Sharing a Network Board ΓòÉΓòÉΓòÉ
Sharing a Network Board
How ODINSUP Works
ODINSUP translates NDIS transmissions from Extended Services or LAN Services
into a form that complies with the ODI drivers.
ODINSUP also translates transmissions received from the network into a form
readable by Extended Services and LAN Services.
ODINSUP functions like a default protocol stack, meaning that it accepts
requests from the Link Support Layer (LSL) that are not specifically marked for
another registered protocol (such as IPX or TCP/IP).
When it receives requests, ODINSUP passes them on to the NDIS protocol stack.
ODINSUP allows IBM's Protocol Manager (found in Extended Services and LAN
Services) to communicate with a network board without having to be aware of the
details of transmission on that board (such as frame type).
Instead, the details are handled at the ODI driver level and then transmissions
are passed on to the Link Support Layer, which in turn passes them on to the
correct protocol stack or to ODINSUP.
ODINSUP translates the request to a form understood by Protocol Manager.
"Using ODINSUP" explains more about using ODINSUP. ODINSUP is for using ODI
drivers. LANSUP is for using NDIS drivers.
NetWare Client for OS/2 and IBM Software Using ODINSUP to Share a Network Board
NetWare Client for OS/2 and IBM Software Using LANSUP to Share a Network Board