

Temp. Rev C -



Information for DOS Users Migrating to OS/2  17

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

chapter 1 Information for DOS Users Migrating  to OS/2

This chapter explains the basic differences between using NetWare
from an  OS/2 workstation and using NetWare from a DOS
workstation.

For information about OS/2, see the OS/2 Installation Guide or the
online  "Master Help Index."

The NetWare Requester for OS/2 provides the same functionality for
OS/2  users as the DOS Requester does for DOS users. After you
install the NetWare  Requester on your workstation, you can
connect to a NetWare network and  perform basic network tasks.

Topic Page

ODI LAN Drivers 18

IPX 18

NET .CFG File 19

Logging In 19

Utilities 20

Drive Mappings and Search Drives 21

Other Protocols 22


Temp. Rev C -



18 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

The NetWare Workstation for OS/2 kit also provides the same
protocol support  that the NetWare Workstation for DOS and Windows
kit provides:

u IPX

u SPX

u Named Pipes

u NetBIOS emulation ODI LAN Drivers

ODI LAN drivers used by the Requester serve the same purpose and
follow the  same technical specifications as ODI LAN drivers used
by the NetWare  Workstation for DOS and 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 AUT OEXEC.B AT. (For OS/2,
network drivers are  always loaded in CONFIG.SYS. AUT OEXEC.B AT
is not used in OS/2. OS/2  requires all device drivers to be
loaded in the CONFIG.SYS. file). IPX

The NetWare Requester 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.SYS, called VIPX.SYS. VIPX talks to
IPX to allow DOS  sessions to communicate on the network. In a
virtual DOS session, you run  VIPX provided with the Requester
rather than the IPX provided in the NetWare  Workstation for DOS
and Windows kit.

When you install the NetWare Requester, lines to load IPX and VIPX
are  loaded automatically in CONFIG.SYS.


Temp. Rev C -



Information for DOS Users Migrating to OS/2  19

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



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.

The NET.CFG file for OS/2 has options and settings just as the
NET.CFG file  in DOS does. However, the options and settings are
somewhat different. Some  of them use different syntax and
configure different software components.

Because of this, you cannot just copy a NET.CFG from a DOS
workstation to  an OS/2 workstation and expect it to work. You
should instead create a new  NET .CFG file for the OS/2
workstation (if NET.CFG is required).

In OS/2, the NET.CFG file is edited or created with the NetWare
Requester  installation program. This program contains online help
showing the syntax of  all options.

In DOS, the NET.CFG file is edited or created with a text editor.

You can put both 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, NETX will use the DOS options.
NetWare Requester for OS/2 ignores  the DOS options. Logging In

When you boot your workstation, the NetWare Requester
automatically maps  drive L: to the SYS:LOGIN directory. This
mapping combines with the L:\OS2  mapping the Requester
installation puts in your path, and gives you a search  path to
the login utilities. You do not have to change to drive L: in
order to log  in.

The NetWare Requester does not support a LASTDRIVE NET.CFG
setting.

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 the NetWare  Tools, you would already
be logged in to the location you logged in to at the  command
line.

You cannot login to the network from the NetWare Tools.  Note


Temp. Rev C -



20 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

You can also log in to the network 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 will use a
NETX.EXE shell and  a virtualized version of IPX, VIPX.SYS.
Chapter 3  explains more about  setting up virtual sessions.

When logging in from virtual sessions, you do not have NetWare
Directory  Services support. This means that you can only log in
to a NetWare v4.0  network that has bindery emulation. If you boot
a DOS session from a real DOS  kernel instead of the one shipped
with OS/2, you can run the NetWare  Workstation for DOS software
and obtain NetWare v4.0 functionality. 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 DOS utilities 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.

Because the OS/2 utilities may not be installed on all servers,
the NetWare  Requester installation program copies LOGIN, NLIST,
MAP, and CX to the  \NETWARE directory where the Requester files
are located. This allows you  to access other servers where OS/2
utilities are installed.

Note


Temp. Rev C -



Information for DOS Users Migrating to OS/2  21

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Drive Mappings and Search Drives

Search drives are not 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 the CONFIG.SYS
file. The OS/2 Installation Guide  contains more information about
PATH, LIBPATH, and DPATH.

Mapping to Login Utilities

When you boot your workstation, the NetWare Requester connects to
the first  server it finds and maps drive L: to the SYS:LOGIN
directory. This mapping  combines with the L:\OS2 mapping the
Requester installation puts in your  path, and gives you a search
path to the login utilities. Once you log in, the L:  mapping
disappears.

Mapping to Public Utilities

The NetWare v4.0 default login script for OS/2 contains the
following line  mapping drive P: to the utilities:

MAP P:=SYS:PUBLIC

This mapping combines with the P:\OS2 mapping the Requester
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 P:, the utility  from the \OS2 subdirectory will
be executed.

Even though your search path gets set to SYS:PUBLIC\OS2 by
default, your P:  drive stays mapped to SYS:PUBLIC. If you change
to the P: drive, you will be  in the SYS:PUBLIC directory, not the
SYS:PUBLIC\OS2 subdirectory. If you  type a utility name while at
the P: drive, the DOS version of the utility will be  executed.

If you go to drive P: and then change to the \OS2 subdirectory,
your search path  will no longer be valid. Your search path will
be expecting to find an \OS2  subdirectory to the P: drive. Since
drive P: will be mapped to  SYS:PUBLIC\OS2, the OS/2 path command
will be looking for a directory with  the following name:

SYS:PUBLIC\OS2\OS2

Chapter 3, "Creating Login Scripts and Menus" of Supervising the
Network  explains more about login scripts.

Important


Temp. Rev C -



22 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Other Protocols

The NetWare Workstation for OS/2 kit provides support for the
following  protocols:

u SPX

u NetBIOS emulation

u Named Pipes

These protocols are used to support OS/2 clients and servers on a
distributed  application network. SPX is also used to support some
NetWare printing  utilities.

The protocols included with the NetWare Requester can only be run
on OS/2  Workstations. Separate programs are provided in the
NetWare Workstation for  DOS and Windows kit to support these
protocols on DOS and Windows  Workstations.

Named Pipes and NetBIOS on an OS/2 workstation can connect to the
DOS  Named Pipes Extender TSR and NetBIOS.EXE TSR, respectively,
running on  a DOS workstation.

You can select support for these protocols in the NetWare
Requester  Installation program. The protocols you selected are
loaded in the  CONFIG.SYS file.

To access SPX, NetBIOS, and Named Pipes support from virtual DOS
and  Windows sessions on OS/2, you must load some programs
provided with the  NetWare Requester. Chapter 9, "Setting Up Named
Pipes and NetBIOS  Protocols" explains more about using protocols
from virtual DOS and  Windows sessions.


Temp. Rev C -



Information for NetWare v2.x and v3.x Users Upgrading to NetWare
v4.0  23

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

CHAPTER 2 Information for NetWarev2.x  and v3.x Users Upgrading to

NetWarev4.0

If you used the NetWare Requester for OS/2 v2.0 with NetWare v3.x
and v2.x  servers, you should be aw are of differences in NetWare
v4.0.

Significant changes have been made in the following areas:

Topic Page

Default Frame Type for Workstation ODI Drivers 24

Selecting a Preferred Server 25

Logging in to the Network 26

Mappings in Default Login Script 27

Mapping to the Public Utilities 27

Login Scripts 29

Virtual DOS and Windows Sessions 30


Temp. Rev C -



24 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Default Frame Type for Workstation ODI Drivers

The default frame type for Ethernet ODI drivers (such as
NE2000.SYS) has  changed. In NetWare v3.x and NetWare v2.x,
Ethernet drivers defaulted to  Ethernet_802.3. In NetWare v4.0,
they default to Ethernet_802.2.

NetWare v4.0 server drivers for Ethernet also default to
Ethernet_802.2.  Servers and workstations use the same frame type
to communicate with each  other.

Routers on the network also have to support the frame type or your
workstation  often will not be able to get a connection. Some
routers currently in use on your  network may not support the new
Ethernet_802.2 default.

Your workstation may not be able to connect to a network expecting
Ethernet_802.3 if you use the Ethernet_802.2 default.

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 the NET.CFG file. 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 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.

The setting "frame" on page 252 explains more about setting a
frame type in  your NET.CFG file.

Important


Temp. Rev C -



Information for NetWare v2.x and v3.x Users Upgrading to NetWare
v4.0  25

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Selecting a Preferred Server

NetWare v4.0 uses trees and contexts rather than servers to
identify what you  log in to. "NetWare Directory Services" in
Concepts explains more about trees  and contexts.

A new NET.CFG setting called "preferred tree" has been created.
You can use  "preferred tree" the same way you used "preferred
server," except you specify  a tree name rather than a server
name. "Preferred tree" is only for sites that  have more than one
directory tree.

For example, to initially connect to a tree called Novell, you
would type the  following lines in your NET.CFG file:

netware requester preferred tree novell

Chapter 4, "Setting Up Workstations to Log In to the Network," of
Workstation  Basics and Installation explains more about putting
the "preferred tree" setting  in your NET.CFG file.

"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 what you have in your NET.CFG file, the Requester
will first try  to establish a default connection to an NDS server
when you turn your machine  on. This connection is made to the
first directory services server that responds  to the Requester.

If the Requester succeeds in connecting to an NDS server, it will
then look for  a preferred tree. Once it connects to a preferred
tree, it will check to see if you  have a preferred server
specified. If that server is in the current context, it will
connect to that server.

If the Requester cannot connect to a NetWare Directory Services
server, it will  try to establish a default connection to a
bindery server. If it connects to a  bindery server, it will first
look for a preferred server, ignoring any preferred  tree line you
have specified.


Temp. Rev C -



26 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Logging in to the Network

When you log in under NetWare v4.0, you log in to a network rather
than a  server. This means you log in to a location in the
Directory (called a context)  rather than a server on the network.
"NetWare Directory Services" in Concepts  explains more about the
directory.

Logging in from the OS/2 Command Line

You use the NetWare v4.0 LOGIN utility to log in from a command
line. This  utility is copied to your hard drive when you install
the Requester, and it is also  located in the SYS:LOGIN\OS2
directory.

With the LOGIN utility, you can specify a context in the Directory
tree. For  example, to log in to a NetWare v4.0 network, type:

LOGIN .JOHN.SALES_MKTG

JOHN  is the User object. SALES_MKTG  is the Organization object.

You can use the NetWare v4.0 LOGIN utility to log in to NetWare
v3.11  servers. Use the same login syntax you used for the NetWare
v3.11 utility and  add the /B option. For example, you would type

LOGIN SALES_MKTG/NANCY /B

"Bindery Emulation" and "NetWare Directory Services" in Concepts
explain  more about the bindery and the Directory. Chapter 4,
"Setting Up Workstations  to Log In to the Network" of Workstation
Basics and Installation explains  more setting up a workstation
for logging in. Chapter 5, "Workstation Login"  of Workstation
Basics and Installation explains more about logging in.

Logging in from the Desktop

You should log in from the command line rather than from the OS/2
"Network"  icon on your desktop.

If you log in from the "Network" icon on your desktop, you will be
logged in  as a bindery emulation client, not a NetWare Directory
Services client. Your  login script will not be run and you will
not be authenticated to the Directory.


Temp. Rev C -



Information for NetWare v2.x and v3.x Users Upgrading to NetWare
v4.0  27

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



The attachment from NetWare Tools is not a login. It does not run
a login script  or disconnect you from previous logins. However,
it does authenticate you to  the Directory. We suggest you log in
from the command line before using the  Attach feature in NetWare
Tools.  Mappings in Default Login Script

In NetWare v2.x and 3.x, a default login script was executed if
you had no other  login script of any kind.

In NetWare v4.0, the default login script still exists. Unless the
system  administrator specifies otherwise with a parameter in the
system login script,  it is executed any time a user login script
does not exist. In NetWare v4.0, the  default login script is
executed even when a system login script exists. This is  a change
from NetWare v3.x.

The NetWare v4.0 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 Requester
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 P:, the utility  from the \OS2 subdirectory will
be executed.

Even though your search path gets set to SYS:PUBLIC\OS2 by
default, your P:  drive stays mapped to SYS:PUBLIC. If you change
to drive P:, you will be in the  SYS:PUBLIC directory, not the
SYS:PUBLIC\OS2 subdirectory. If you type a  utility name while at
the P: drive, the DOS version of the utility will be executed.

If you go to drive P: and then change to the \OS2 subdirectory,
your search path  will no longer be valid. Your search path will
be expecting to find an \OS2  subdirectory to the P: drive. Since
the P: drive will be mapped to  SYS:PUBLIC\OS2, the OS/2 path
command will be looking for a directory with  the following name:

SYS:PUBLIC\OS2\OS2 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:

Important


Temp. Rev C -



28 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

MAP P:=SYS:PUBLIC

Chapter 3, "Creating Login Scripts and Menus" of Supervising the
Network  explains more about mapping drives in login scripts.

Why Drive P:

This mapping combines with the P:\OS2 directory the Requester
installation  puts in your path. The combination gives you a
search path to the  SYS:PUBLIC\OS2 directory.

If you use another mapping besides P:, that mapping will not
combine with the  P:\OS2 directory the Requester automatically
puts in your path. In this case,  you won't have a search path to
the utilities.

When you type a utility name from any drive other than P:, the
utility from the  \OS2 subdirectory will be executed.

Why SYS:PUBLIC and not SYS:PUBLIC\OS2

Do not map the P: drive to SYS:PUBLIC\OS2.

The NetWare utilities for OS/2 need to find language-specific
files in the parent  directory of the directory from which they
were executed. For example, a  utility executed from
SYS:PUBLIC\OS2 expects to find an \NLS subdirectory  in the
SYS:PUBLIC directory.

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 does not recognize that there is  a parent
directory for the utilities. When the utilities try to locate the
\NLS  subdirectory in their own parent directory, they are
returned an error by OS/2,  and your utility won't run.

If you change to the P: drive, you will be in the SYS:PUBLIC
directory, not the  SYS:PUBLIC\OS2 subdirectory. If you type a
utility name while at the P: drive,  the DOS version of the
utility will be executed.

If you go to drive P: and then change to the \OS2 subdirectory,
your search path  will no longer be valid. Your search path will
be expecting to find an \OS2  subdirectory to the P: drive. Since
drive P: will be mapped to  SYS:PUBLIC\OS2, the OS/2 path command
will be looking for a directory with  the following name:

Important


Temp. Rev C -



Information for NetWare v2.x and v3.x Users Upgrading to NetWare
v4.0  29

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



SYS:PUBLIC\OS2\OS2 Login Scripts

You can login from

An OS/2 session

A global or private DOS or Windows session

A global session booted from a real DOS kernel and running VSHELL

A private session booted from a real DOS kernel and running the
NetWare  v4.0 DOS Requester

The following table shows what login script is executed for which
type of login  and how to edit those login scripts.


Temp. Rev C -



30 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Virtual DOS and Windows Sessions

With the NetWare Requester v2.01, you have full NetWare v3.11
functionality  from both Private and Global sessions. However, you
do not have NetWare  Directory Services (NetWare v4.0)
functionality.

This means that you can run NetWare v4.0 DOS utilities from a DOS
session,  but you will not have access to NetWare Directory
Services. To a NetWare v4.0  server, you will appear as a NetWare
v3.11 bindery emulation client. "Bindery  Emulation" in Concepts
explains more about bindery emulation clients.

You can obtain NetWare Directory Services functionality by booting
from a  different DOS kernel than the one included with OS/2 and
loading the NetWare  v4.0 DOS Requester software. Boot from a real
DOS kernel by using the

Table 2-1 Ho w to edit login scripts for each type of session

If you login from Login script run How login script is edited

OS/2 session NetWare v4.0 Login  Profile object With the NetWare
Administrator for OS/2  utility. See Utilities Reference.

Private  DOS/Windo ws  session

NetWare v3.11 DOS  login script From a text editor. Edit the
SYS:MAIL\userID\LOGIN file.  Or use a NetWare v3.11 utility, such
as  SYSCON.

Global DOS/Windows  session NetWare v3.11 DOS  login script From a
text editor. Edit the  SYS:MAIL\userID\LOGIN file.  Or use a
NetWare v3.11 utility, such as  SYSCON.

Global session  booted from real DOS  kernel and running  VSHELL

NetWare v3.11 DOS  login script From a text editor. Edit the
SYS:MAIL\userID\LOGIN file.  Or use a NetWare v3.11 utility, such
as  SYSCON.

Private session  booted from real DOS  kernel and running  v4.0
DOS Requester

NetWare v4.0 Login  Profile object With the NetWare Administrator
for OS/2  utility. See Utilities Reference.


Temp. Rev C -



Information for NetWare v2.x and v3.x Users Upgrading to NetWare
v4.0  31

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



DOS_ST AR TUP_DRIVE setting. The OS/2 online "Master Help Index"
explains how to do this.

Sessions booted from a real DOS kernel can have either private or
global  support. Global sessions booted with a real DOS kernel
have NetWare v3.11  support. Private sessions booted with a real
DOS kernel can have NetWare v4.0  support if you load the NetWare
v4.0 DOS Requester.

"Network Access From Virtual DOS and Windows" on page 33 explains
more  about setting up virtual DOS and Windows sessions.

Figure 2-1 on page32 shows what NetWare functionality you have
under all  types of virtual sessions.

Changes to Global NetWare Support

Global support has been enhanced to provide full NetWare v3.11
functionality.  Applications or utilities that did not run in a
Global session with Requester  v2.0 should run properly under
v2.01.

Changes to Private NetWare Support

The instructions in this section apply to DOS and Windows sessions
already set  up under the NetWare Requester v2.0. For sessions not
set up yet, you will  need to read "Network Access From Virtual
DOS and Windows" on page 33  instead of doing these steps.

NETX.COM has changed to NETX.EXE. This means you must open the DOS
Settings Notebook for each session and make the following changes:

1. For the DOS_VERSION setting, change the line that includes
NETX.COM to read:

NETX.EXE,5,00,214

2. For the DOS_FILES setting, change 255 to 214.

Note

Procedure 1 2 3


Temp. Rev C -



32 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Figure 2-1 NetWare support in DOS/Windows sessions

NetWare feature* * * * * * * * * Access to NetWare v4.0* as an NDS
client* * Access to NetWare * v3.11 as a bindery client* * Access
to NetWare v4.0* network administration* utilities* * Ability to
manage print* jobs* * Access to v4.0 NetWare * Tools* * Access to
NetWare v4.0* electronic documentation * (ElectroText)

OS/2* sessions* * * * * * * * Yes* * * Yes* * * Yes 2* * * * Yes*
* * Yes 6 * * * No

Private* Virtual* DOS* sessions* * * * * * No* * * Yes* * * No * *
* * Yes 4 * * * No* * * No

Global* Virtual* DOS* sessions* * * * * * No* * * Yes* * * No * *
* * Yes 4 * * * No* * * No

Private* Virtual* Windows* sessions* * * * * * No* * * Yes* * *
No* * * * No* * * No* * * Yes

Global* Virtual* Windows* sessions* * * * * * No* * * Yes* * * No
* * * * No* * * No* * * Yes

Private* sessions* using a* real DOS* kernel &* running* 4.0 DOS*
Requester* * Yes* * * Yes* * * Yes 3* * * * Yes 5 * * * Yes 7 * *
* No

Global* sessions* using a* real DOS* kernel 1 * * * * * No* * *
Yes* * * No* * * * No* * * No* * * No

1. You cannot run the v4.0 DOS Requester on a Global session that
uses a real DOS kernel.  Your* NetWare support comes from VSHELL
instead.  VSHELL is NetWare v3.11-compliant.* * 2. Use the NetWare
Administrator for OS/2.* * 3. Use NETADMIN for DOS.* * 4. You can
use NetWare v4.0 printing utilities for DOS to manage print jobs
form a regular DOS session.* However, you will only be able to see
queues that are in the bindery context of NetWare v3.11 server*
objects.* * 5. In a DOS session that uses a real DOS kernel, you
can use NetWare v4.0 printing utilities for DOS* with full v4.0
functionality.  You will see all queues rather than just bindery
context queues.* * 6. Use NetWare Tools for OS/2.* * 7. Use
NETUSER for DOS.


Temp. Rev C -



Network Access From Virtual DOS and Windows  33

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

CHAPTER  3 Netw ork Access From Virtual DOS  and Windows

Topic Page

Cautions for All Types of Sessions 35

Customizing Icons For Global Support 37

Setting Up Drive Mappings in Global Sessions 40

Customizing Icons For Private Support 42

Special Instructions for Win-OS2 Icons 48

Special Instructions for DOS_STAR TUP_DRIVE Sessions 50

Disabling Network Support in Virtual Sessions 53


Temp. Rev C -



34 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

From a virtual DOS or Windows session, you can have three kinds of
NetWare  support:

u Global logins All DOS, 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.

u Private logins All DOS and 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 Windows sessions to be separate  from logins from OS/2
sessions.

u No logins. Sessions with network support disabled have IPX/SPX
support, but no  NetWare login support.


Temp. Rev C -



Network Access From Virtual DOS and Windows  35

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Set up NetWare support for virtual DOS and Windows in two ways:

u Set a default type of support (Global, Private, None) that
applies to all  existing DOS and Windows icons, as well as any new
icons that are  created.  If you choose this default in the
NetWare Requester installation program,  it is automatically
loaded in the CONFIG.SYS file. To change the default  support, run
the NetWare Requester installation program and refer to the
online help. Chapter 3, "Installing a NetWare Workstation" of
Workstation  Basics and Installation explains about running the
installation.

u Customize the type of support for each DOS and Windows icon on
your  desktop.  All sessions started from the customized icon will
have the type of support  you specify. For instructions on
customizing NetWare support per icon,  see the sections that
follow. If you want 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 may want to
create "Global DOS Full Screen" and "Private  DOS Full Screen"
icons.  Cautions for All Types of Sessions

Version of NetWare Supported

From a virtual DOS or Windows session, you can access NetWare
v3.11  networks. On these networks, you can receive full NetWare
support, just as if  you were using an actual DOS or Windows
workstation. You can also receive  support for just the IPX, SPX,
Named Pipes and NetBIOS protocols.

You cannot access NetWare v4.0 networks from virtual DOS and
Windows  sessions unless those networks support bindery emulation.
If a NetWare v4.0  network supports bindery emulation, your DOS or
Windows session will be  seen as a bindery-based client.

HoWever, if you are booting a DOS session from a version of DOS
other than  the one shipped with OS/2 (using OS/2's DOS_STAR
TUP_DRIVE feature), you  can access NetWare 4.0 networks from that
session. See "Special Instructions  for DOS_STAR TUP_DRIVE
Sessions" on page50.

Suggestion

Note


Temp. Rev C -



36 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 are running the
version of DOS included with  OS/2, set the COMSPEC variable to
the following location:

SET COMSPEC= drive :\OS2\MDOS\COMMAND.COM

You can set the COMSPEC variable at the command line or in a login
script.

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-
-change the  COMSPEC v ariable in your login script.

Login Issues

Figure 2-1 on page32 shows what login scripts are executed from
which type  of session and how to edit those login scripts.

Also, when you logout from 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 will be
drive D:.

If you logout from a network drive, the drive remains the same.


Temp. Rev C -



Network Access From Virtual DOS and Windows  37

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Customizing Icons For Global Support

Prerequisites o Read "Cautions for All Types of Sessions" on
page35.  o Make sure network support for virtual sessions is
enabled. If not,  enable it by running the Requester installation
program. Chapter 3,  "Installing a NetWare Workstation" of
Workstation Basics and  Installation explains how to run the
Requester installation. Virtual  session support is enabled by
default.

Procedures

To set up global NetWare support for an icon, do the following:

1. Open the "DOS Settings" notebook for the DOS or Windows icon
on your desktop. For more information on opening DOS Settings, see
"DOS Settings" in  the OS/2 online "Master Help Index." Figure 3-1
shows how to open DOS  Settings.

Figure 3-1 Opening DOS  Settings

2. In the "DOS Settings" Notebook, choose the "Session" tab.
Figure 3-2  illustrates the "Session" tab page.

Checklist

Procedure 1 2 3


Temp. Rev C -



38 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 3-2 Choosing the  "Session" tab

3. On the "Session" screen, choose the "DOS Settings . . ."
button.  Figure 3-3  illustrates the "DOS Settings" screen.


Temp. Rev C -



Network Access From Virtual DOS and Windows  39

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 3-3 The DOS Settings Screen

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. You only need  to add this line if you want to
use the NetWare CAPTURE command  feature from the virtual session.
If 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 more information on loading DOS device
drivers.

Note


Temp. Rev C -



40 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

5. Specify that all drives are available to NetWare. 5a. Select
"DOS_LASTDRIVE." 5b. Type Z in the "Value" field. This tells
NetWare that all drives up through Z are available for use  in the
session.

6. Choose Global NetWare support. 6a. Select "NETWARE_RESOURCES ."
6b. Type GLOBAL in the "Value" field. You can also choose "GLOBAL"
from the drop-down list box.  Every session you start from this
icon will have global support.

7. Enable virtual IPX for this session.  7a. Select
"VIPX_ENABLED." 7b. Select "On."

8. Save and exit "DOS Settings." 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 will  show up as root drives in global DOS sessions.
Root drives mapped in global  DOS sessions will 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 DOS session do not
apply to other DOS sessions. To eliminate  confusion, avoid using
search drives in a global environment. Instead, obtain  the same
functionality by setting up your environment as outlined in the
procedures below.

Procedures

1. Decide which drives you want mapped in your global environment.
Decide which of those drives need to be included in a search path.
Procedure 1 2 3


Temp. Rev C -



Network Access From Virtual DOS and Windows  41

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



2. Edit your NetWare v4.0 login script (used in OS/2 sessions) and
include MAP statements for all NetWare drives.

3. Edit your NetWare v3.11 DOS login script and include MAP ROO T
statements for all NetWare drives.  To edit your NetWare v3.11 DOS
login script, use a text editor to edit the  SYS:MAIL\userID\LOGIN
file or use a NetWare v3.11 utility such as  SYSCON. Use MAP ROO T
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  w ant 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, you would add the  following
to your path:t

H:\; If needed, you can also include drive letters in the data
path statement  (DPATH). The DPATH statement is where OS/2
searches for non executable, non-.DLL files.


Temp. Rev C -



42 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

5. Create a DOS.BAT file which includes a path to the same drives
you  included in the CONFIG.SYS file.  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 directories  that already exist in the PATH statement.
You cannot include DPATH statements in the DOS.BAT file. DOS 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" text entry box, type /K followed by a space
and the  name of the .BAT file. The file will then be 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."  Customizing Icons For Private
Support

Prerequisites o Read "Cautions for All Types of Sessions" on
page35.  o Make sure network support for virtual sessions is
enabled. If not,  enable it by running the Requester installation
program. Chapter 3,  "Installing a NetWare Workstation" of
Workstation Basics and  Installation explains how to run the
installation. Virtual session  support is enabled by default.

Checklist


Temp. Rev C -



Network Access From Virtual DOS and Windows  43

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

To set up private NetWare support for an icon, do the following:

1. Open the "DOS Settings" Notebook for the DOS or Windows icon
on your desktop. For more information on opening DOS Settings, see
"DOS Settings" in  the OS/2 online "Master Help Index." Figure 3-1
shows how to open DOS  Settings.

Figure 3-4 Opening DOS  Settings

2. In the "DOS Settings" Notebook, choose the "Session" tab.
Figure 3-2  illustrates the "Session" tab page.

Procedure 1 2 3


Temp. Rev C -



44 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 3-5 Choosing the  "Session" tab

3. On the "Session" screen, choose the "DOS Settings . . ."
button.  Figure 3-3  illustrates the "DOS Settings" screen.


Temp. Rev C -



Network Access From Virtual DOS and Windows  45

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 3-6 The DOS Settings Screen

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. You only need  to add this line if you want to
use the NetWare CAPTURE command  feature from the virtual session.
If 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 more information on loading DOS device
drivers.

Note


Temp. Rev C -



46 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

5. Specify how many files the session can open simultaneously. 5a.
Select "DOS_FILES." 5b. Type 214 in the "Value" field.

6. Specify what 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 session.

7. Specify the correct version of NETX.EXE. 7a. Select
"DOS_VERSION." 7b. In the "Value:" field, find the line that
specifies the version of  NETX and replace it with the following
line:

NETX.EXE,5,00,214

8. Choose Private NetWare support. 8a. Select "NETWARE_RESOURCES
."  8b. Type PRIVATE  in the "Value" field. You can also choose
"Private" from the drop-down list box. Every  session you start
from this icon will its own NetWare login.

9. Enable virtual IPX for this session.  9a. Select
"VIPX_ENABLED." 9b. Select "On."

10.Save and exit "DOS Settings."


Temp. Rev C -



Network Access From Virtual DOS and Windows  47

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



11.Load the NETX.EXE program 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" text entry box, type /K followed by a space,
the directory path, and the NETX.EXE filename. The file will then
be  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 load NETX.EXE automatically for all
DOS and Windows sessions, put  the following command in an AUT
OEXEC.B AT file in 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 Requester
files.  If you want IPX/SPX-only support, don't load NETX. If you
don't load  NETX.EXE, you will not be able to log in to a NetWare
network, but DOS  and Windows applications will be able to use the
IPX protocol.

Note


Temp. Rev C -



48 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Special Instructions for Win-OS2 Icons

These instructions apply to the Windows 3.0 support that was
shipped with  OS/2 v2.0.

Prerequisites o Read "Cautions for All Types of Sessions" on
page35. o Complete"Customizing Icons For Global Support" on page37
or  "Customizing Icons For Private Support" on page42 for the Win
OS2 icon.

Procedures

You need several additional files for Win-OS2 NetWare support:

NWIPXSPX.DLL NETWARE.DRV TBMI2.COM NWPOPUP.EXE NETWARE.HLP

By default, these files are copied to the \OS2\MDOS\WINOS2\SYSTEM
directory on your boot drive when you install the NetWare
Requester.

The TBMI2 file must be loaded before you run any Windows programs
that  make IPX or SPX calls. We recommend loading it before you
run any  Windows programs.

To load TBMI2 automatically for all sessions started from a single
icon:

1. Make and use a copy of a DOS icon.

Checklist

Procedure 1 2 3


Temp. Rev C -



Network Access From Virtual DOS and Windows  49

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 the "Program" tab.

6. In the "Optional Parameters" field, type the following line:

/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 the "Session" tab.

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 load TBMI2.COM automatically for all DOS and Windows sessions,
put  the following command in an AUT OEXEC.B AT file in the root
of your boot  drive:

drive :\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM

Replace drive with the letter of your boot drive.


Temp. Rev C -



50 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Special Instructions for DOS_STAR TUP_DRIVE Sessions

If you want to boot a version of DOS other than what shipped with
OS/2, refer  to the OS/2 online Master Help Index which explains
more about the  DOS_ST AR TUP_DRIVE feature.

If you are using DOS_STAR TUP_DRIVE to boot a session, you can
have  global or private NetWare support, just as from a regular
virtual session.

However, in a private DOS_STAR TUP_DRIVE session, you can also run
the  NetWare v4.0 DOS Requester and have NetWare v4.0 support.
From this kind  of DOS session, you can log in as a NetWare v4.0
DOS client.

If you do not want to load (or do not have) NetWare v4.0
Workstation for DOS  software, you should still load NETX.EXE,
shipped with the Requester. In this  case, you will have the same
limitation of being only a NetWare v3.11 client  as you would have
from a session booted from the DOS shipped with OS/2.

The following sections explain how to set up DOS_STAR TUP_DRIVE
sessions globally or privately.

Setting up Global DOS_STAR TUP_DRIVE Sessions

Prerequisites o Read "Cautions for All Types of Sessions" on
page35. o Set up your session to boot from another version of DOS.
This  involves creating a boot image file, setting  DOS_ST AR
TUP_DRIVE, and certain other tasks using the  VMDISK utilitly. See
the OS/2 online "Master Help Index."  o Make sure network support
for virtual sessions is enabled. If not,  enable it by running the
Requester installation program. Chapter 3  "Installing a NetWare
Workstation" of Workstation Basics and  Installation explains how
to run the installation program. Virtual  session support is
enabled by default.  o Set up your session for global NetWare
support by following the  instructions in "Customizing Icons For
Global Support" on page37  and "Setting Up Drive Mappings in
Global Sessions" on page40.

Checklist


Temp. Rev C -



Network Access From Virtual DOS and Windows  51

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

Type the following lines in the CONFIG.SYS file on the DOS
diskette or  partition you will boot from:

device= drive :\os2\mdos\fsfilter.sys device= drive :path
\dosvshll.sys device= drive :path \dosvipx.sys lastdrive=z

Replace drive and path with the drive and path names where the
NetWare  Requester 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.

Setting Up Private DOS_STAR TUP_DRIVE Sessions

Prerequisites o Read "Cautions for All Types of Sessions" on
page35. o Set up your session to boot from another version of DOS.
This  involves creating a boot image file, setting  DOS_ST AR
TUP_DRIVE, and certain other tasks using the  VMDISK utilitly. See
the OS/2 online "Master Help Index."  o Make sure network support
for virtual sessions is enabled. If not,  enable it by running the
Requester installation program. Chapter 3,  "Installing a NetWare
Workstation" of Workstation Basics and  Installation explains how
to run the Requester installation. Virtual  session support is
enabled by default.  o Set up your session for private NetWare
support by following the  instructions in "Customizing Icons For
Private Support" on page42.

Procedures

1. Type the following lines in the CONFIG.SYS file on the DOS
diskette or partition you will boot from:

Procedure 1 2 3

Checklist

Procedure 1 2 3


Temp. Rev C -



52 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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  Requester files
are located. Replace letter with the last local drive  accessible
to the session. NetWare drives start after this letter.  The
FSFILTER.SYS driver provided by OS/2 gives the  DOS_ST AR
TUP_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 Workstation for DOS software. 2a. To load
NetWare v4.0 DOS Requester, follow the directions in  NetWare
Workstation for DOS and Windows . Use the  software on the DOS
Requester diskette, WSDOS_1 . 2b. To load NETX.EXE for NetWare
v3.11 support, follow the  instructions in Step 11 on page47. Use
the software on the  OS/2 Requester diskette, WSOS2_1 .

Any network drives mapped in an OS/2 session will show up as local
drives in  a private DOS_STAR TUP_DRIVE session.


Temp. Rev C -



Network Access From Virtual DOS and Windows  53

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Disabling Network Support in Virtual Sessions

To disable all network support, run the NetWare Requester
installation  program and deselect "Support for DOS and Windows
Sessions." Then reboot  your machine. This keeps VIPX.SYS and
VSHELL.SYS from loading.

To reenable support, run the install and select "Support for DOS
and Windows  Sessions."

Chapter 3, "Installing a NetWare Workstation" of Workstation
Basics and  Installation explains how to run the Requester
installation program.

For a technical diagram of NetWare support in a virtual
DOS/Windows  session, see Appendix C, "Architecture Diagrams."


Temp. Rev C -



54 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993


Temp. Rev C -



Ho w to Configure Your Workstation  55

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

chapter 4 Ho w to Configure Your Workstation

This chapter contains instructions for configuring the NetWare
Requester for  OS/2 v2.01.

Complete information for the configuration options is found in the
help screens  in the NetWare Requester installation program and in
Appendix B on page  245.

Topic Page

When Is Configuration Required 56

Procedures 58

NET .CFG Format Requirements 61

Quick Reference List of NET.CFG Options 62


Temp. Rev C -



56 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

When Is Configuration Required

Read the table below to decide if you must configure the
workstation before  the NetWare Requester will run.

Configuration may be useful in other circumstances shown in the
table below.  These circumstances are described in detail in the
remaining chapters of this  manual.

Table 4-1 Situations when configuration is required

You must configure if For information, go to

Your workstation has  more than one network  board

Chapter 5, "Network Boards and Drivers"

Your workstation has a  single board, but the  board is not using
the  factory default settings

Chapter 5, "Network Boards and Drivers"

Your network uses an  Ethernet frame type other  than
Ethernet_802.2

Chapter 5, "Network Boards and Drivers"

The NetWare Requester  will share a network  board with other
software

Chapter 8, "Sharing a Network Board With  IBM Software"


Temp. Rev C -



Ho w to Configure Your Workstation  57

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Table 4-2 Other situations when configuration might be useful

You may want to configure if For information, go to

You want to change the  default packet signature  security level

Chapter 6, "Improving Speed and  Security"

You want to turn off  Packet Burst or Large  Internet Packet
transmissions

Chapter 6, "Improving Speed and  Security"

Your workstation will  connect to a Token-Ring  network using
Source  Routing

Chapter 7, "Using OS/2 Workstations on a  Token-Ring Network"

Your workstation will  need to use the NetBIOS  or Named Pipes
protocols

Chapter 9, "Setting Up Named Pipes and  NetBIOS Protocols"

Your want your  Workstation to connect to  a preferred server

The "preferred server" setting on page 277  and the "preferred
tree" setting on page  278.

You are setting up remote  booting workstations Chapter 11,
"Remote-Booting OS/2  Workstations"


Temp. Rev C -



58 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Procedures

Configuration options for the NetWare Requester are stored in the
NET.CFG  file. When you start up your workstation, the NetWare
Requester searches for  NET .CFG in the directories specified in
the DPATH line in the CONFIG.SYS  file. If the Requester does not
find a NET.CFG file, it starts up using the default  configuration
values built into the Requester.

The NET.CFG file is located in the root directory of your boot
drive. If you  have previously configured the Requester, a NET.CFG
file already exists for  your workstation. Change the current
configuration by modifying and saving  the existing file.

Reinstalling the NetWare Requester will not overwrite an existing
NET.CFG  file; instead, the existing NET.CFG file will appear in
the installation program  for you to edit.

If you have not configured the Requester before, a NET.CFG file
does not exist  for your workstation. You must create this file in
order to configure the  Requester.

To create or edit NET.CFG, you can use either of the following:

u The NetWare Requester installation program. Use the online help
in the  program to determine what to include in the file.

A text editor. Use the format requirements in this chapter and the
reference  pages in "NET.CFG Options Reference" on page 245 to
determine what  to include in the file.

To edit or create NET.CFG with the installation program:

1. Start the NetWare Requester installation program. Choose the
"Installation" icon in the "Novell" group window on your  desktop
or insert the WSOS2_1 diskette and type INSTALL at a command
prompt. The "NetWare Requester for OS/2 Installation Utility"
window  appears.

2. Select "This workstation. . ." from the "Configuration" menu.
The "Edit NET.CFG File for This Workstation" window appears.

Procedure 1 2 3


Temp. Rev C -



Ho w to Configure Your Workstation  59

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



3. Check the location of the NET.CFG file. Change the location if
you  w ant. Use the online help if necessary.

4. Type the NET.CFG options you want in the "Current NET.CFG File
Contents" box.  See Figure 4-1 for an explanation of how to edit
the NET.CFG file. Read  the NET.CFG format requirements from the
online help or from the next  section.  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  following keys:
Table 4-3 Key definitions for the NET.CFG window

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 (text will  reappear the next time  you refresh the
window) <Shift><Delete>

Paste text <Shift><Insert>

Delete text (deleted text  cannot be pasted) <Ctrl><Delete>


Temp. Rev C -



60 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Figure 4-1 Ho w to edit the NET.CFG file

     Read online * help for the topic* you selected.

     Select the type* of information you* want to see.

        Select a * NET.CFG option, * setting, or topic.

    Type NET.CFG*     options and*     settings here.

       Save your* configuration or* change your mind.

1 4

2 3

5


Temp. Rev C -



Ho w to Configure Your Workstation  61

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



5. To save your changes to NET.CFG, choose "Save."

6. To exit the installation program, double-click in the upper
left corner  of the main window.

7. Use OS/2's "Shutdown" feature to reboot your workstation.
Installation and configuration changes will not take effect until
you reboot. NET .CFG Format Requirements

Each NET.CFG option has several settings. In this chapter, these
settings are  alphabetized under the option to which they apply.
Options and settings do not  have to be alphabetized in the
NET.CFG file.

Use the following rules to create or modify a NET.CFG file:

u Type options at the left margin of the file with no spaces
before or after  them. Options are not case-sensitive.

u Type one option per line.

u Type settings, one per line, on the lines following the option
to which they  apply. When editing the NET.CFG from the
installation program, 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.

u Place a hard return at the end of every line in the file,
including the last  line. Blank lines are not necessary and are
ignored.  If you don't put a return at the end of the last line,
the line will be ignored.

u Precede comments with a semicolon.

Warning


Temp. Rev C -



62 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Figure 4-2 illustrates NET.CFG format. Figure 4-2 NET .CFG format

Quick Reference List of NET.CFG Options

Figure 4-3 lists all NET.CFG options and settings, as well as the
default value  for each option or setting. More detailed
information is on the reference pages  beginning on page 245.

link driver ne2000 int 4* port 360* frame ethernet_802.3 link
driver ne1000 int 5* port 310* node address 02608c861759 protocol
stack spx sessions 256 netware requester preferred server sales
named pipes client sessions 16* server sessions 255* service
threads 32

Settings indented* under option, one* setting per line.

Hard return and* line feed after all * lines, including the* last
line.

Options typed flush* left, one per line.


Temp. Rev C -



Ho w to Configure Your Workstation  63

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Figure 4-3 NET .CFG quick  reference

netware netbios abort timeout number* broadcast count number*
broadcast delay number* commands number* internet [on/off]* listen
timeout number* names number* retry count number* *

30,000* internet on:4, internet off:2* internet on:2,000, internet
off:1,000* 32* on* 6,000* 24* 20

daemon configuration

NetWare Configuration Options Options and Settings Defaults

message timeout number messages do not timeout displayharderrors
no messages display link driver name 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 ?* slot number

[#1], set by driver* set by driver* [#1], set by driver* [#1], set
by driver, [set by driver]* preset on board* [#1], set by driver,
[set by driver]* IPX, 0, Ethernet_802.2* slot ?* slot ?

none

named pipes client sessions number* server sessions number*
service threads number

16* 32* 3

link support buffers number [buffer_size] 20, [1514]


Temp. Rev C -



64 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Figure 4-3 continued NET .CFG quick  reference

protocol stack ipx bind name* router mem size* sockets number

first driver in CONFIG.SYS* 450* 64* *

netware requester cache buffers number* large internet packets
off* name context context* packet burst off* preferred server
servername* preferred tree treename* request retries number*
sessions number* signature level number

8* on* none* on* none* none* 20* 8* 1 protocol odinsup bind driver
[number] none, [first one found]

protocol stack spx abort timeout number* listen timeout number*
retry count number* send timeout number* sessions number* verify
timeout number

30,000* 6,000* 20* determined by SPX* 16* 3,000

NetWare Configuration Options (continued) Options and Settings
Defaults

protocol route source route def gbr mbr nodes n board n 16, 1

retry delay number* sessions number* verify timeout number

500* 16* 3,000


Temp. Rev C -



Network Boards and Drivers  65

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

chapter 5 Netw ork Boards and Drivers

This chapter explains network board and driver issues. For basic
information  about boards and drivers, see the documentation for
your network board.

Matching Driver Settings with Board Settings

Network boards come with factory defaults for such hardware
settings as:

u Direct memory access channel (DMA)

u Interrupt line (IRQ)

u Input/output port

u Memory range

u Node address

These factory defaults can usually be changed by moving jumpers or
setting  switches.

The NetWare Requester for OS/2 expects each board to be using the
default  settings. Therefore, if you change the factory default
for any of the hardware  settings listed above, you must tell the
OS/2 ODI driver what the new setting is.

Topic Page

Matching Driver Settings with Board Settings 65

Specifying Frame Types for a Driver 67

Why Have More Than One Network Board 69

Setting Up Tw o Network Boards 72


Temp. Rev C -



66 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

To do this, use the "Link Driver" option in the NET.CFG file. The
"Link  Driver" option allows you to set the following hardware-
related settings:

link driver  name dma [ index ] channel int [ index ] irq mem [
index ] starting_address  [size ] node address  number port [
index ] starting_port  [number ]

"How to Configure Your Workstation" on page55 explains more about
putting  options in the NET.CFG file. "Link Driver" on page249
explains more about  using these settings.

Shortcut for EISA and Micro Channel Boards

If you are using an EISA or Micro Channel board, you do not have
to specify  the hardware settings shown above. The OS/2 ODI driver
scans the card and  automatically determines what settings are in
use.

You just have to tell the NetWare Requester what slot the network
board you're  using is in, or tell it to scan all slots. Do this
with the "Link Driver" option and  the "slot" setting in the
NET.CFG file:

link driver  name slot  number

Replace number with the number of the slot, or replace number with
a question  mark to tell the Requester to scan all slots. The
section "slot" on page260  explains more about using the "slot"
setting.


Temp. Rev C -



Network Boards and Drivers  67

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Specifying Frame Types for a Driver

All communications on a network consist of packets of information
being sent  between computers.

There are different kinds of packets, distinguished from each
other mainly by  the order of the information in the packet. Each
kind of packet follows its own  set of rules. This set of rules is
called a frame type.

When a computer sends and receives a particular kind of packet,
then that  computer is transmitting with that particular frame
type.

By default, each network driver uses only one kind of frame type.
However,  most drivers also support other frame types. For
example, an NE2000 driver  supports Ethernet_802.2,
Ethernet_802.3, Ethernet_II, and Ethernet_SNAP.

The following table lists some common network boards and the frame
types  supported by each. This list is not comprehensive.  Table
5-1 List of frame types and drivers

Frame type Network 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


Temp. Rev C -



68 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

You can use the "Link Driver" option in the NET.CFG file to tell
the driver  what frames types you want used. You can only specify
frame types supported  by that driver.

link driver  name frame  name

Replace name with the name of the frame type. To specify more than
one frame  type, you can type additional frame type lines.

"How to Configure Your Workstation" on page55 explains more about
how to  put options in the NET.CFG file. The section "frame" on
page252 explains  more about using the "frame" setting.

Cautions When Changing Frame Type

The default frame type for Ethernet ODI drivers has changed. In
NetWare v2.x  and NetWare v3.x, Ethernet drivers defaulted to
Ethernet_802.3. In NetWare  v4.0, they default to Ethernet_802.2.

NetWare v4.0 server drivers for Ethernet also default to
Ethernet_802.2.  Servers and workstations must use the same frame
types to communicate with  each other.

Routers on the network also have to support the frame types or
your  Workstation often will not be able to get a connection. Some
routers currently  in use on your network may not support the new
Ethernet_802.2 default.

Your workstation may not be able to connect to a network expecting
the old  default if you use the new Ethernet_802.2 default.

To eliminate 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 the NET.CFG file. Include a
line similar to the following,  replacing ne2000 with the name of
your ODI driver:

IBM_pcn2_snap PCN2, PCN2L, LANSUP

No vell_rx-net TRXNET , TRXNET2

Table 5-1 continued List of frame types and drivers

Frame type Network board driver

Important


Temp. Rev C -



Network Boards and Drivers  69

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



link driver ne2000 frame ethernet_802.3 frame ethernet_802.2

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.

The section "frame" on page252 explains more about setting a frame
type in  your NET.CFG file. Why Have More Than One Network Board

When using the NetWare Requester, there are only two conditions
where you  benefit from having more than one network board in your
computer:

u When each board supports a different communications software
package.

u When each board is connected to a physically separate network,
but those  networks are connected with one or more routers.  In
this case, a second board may be useful. Additional boards after
the  second will be completely ignored.

If you have two network boards, you must be aw are of some
configuration  issues, discussed in the following sections.
Important


Temp. Rev C -



70 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Tw o or More Communications Packages

You may want to use two or more network boards when each board
supports  its own communications software package.

For instance, you may want to have Communications Manager use one
board  and NetWare Requester use another. Or you may want NetWare
for OS/2 to use  one board and NetWare Requester to use another.

In these cases, each package provides the driver for its own
board, and the  setup for NetWare Requester is just as if only one
board existed. There are no  additional steps to set up the second
board, since that board is entirely  controlled by the other
communications package.

In most cases, the NetWare Requester can share a board with other
comm unication packages so that you do not need to purchase two
boards. To  have the NetWare Requester share a board with Extended
Services or LAN  Services, see "Sharing a Network Board With IBM
Software" on page95. To  have NetWare Requester share a board with
NetWare for OS/2, see NetWare  v4.0 Installation Supplement for
OS/2 Servers.

Tw o Connected Networks

You may want to use two network boards when each board is
connected to a  physically separate network, but those networks
are connected with one or  more routers.

If your two networks are physically connected, your second board
may serve  as a backup route if the connection to your first board
fails.

If the networks are not physically connected, the second board
will not be able  to act as a backup.

Why Do the Networks Have to Be Connected

When the workstation boots, the IPX protocol binds to all network
boards that  have OS/2 ODI drivers loaded. Whenever IPX needs to
find a new destination  on the network, it queries the network for
possible routes to that destination.

IPX only sends out a destination query on the primary network
board. It never  queries the secondary (or other) board for a
route.

Note


Temp. Rev C -



Network Boards and Drivers  71

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



If IPX does not find the destination using the primary board, you
see a  connection error, even if the destination could be found if
IPX were to use the  second board.

If each board is connected to a physically separate network,
destinations on the  second board's network will never be found.
Only destinations on the first  board's network will be locatable.

Ho w is The Second Board a Backup

Once IPX finds a destination using the primary network board, it
stores the  route to that destination in a router table and makes
the connection.

After the connection is made, IPX checks all networks that are
connected to  that destination for any other possible routes from
your OS/2 workstation to the  destination.

If it finds a secondary route, IPX rebuilds the router tables and
stores that route.  If the primary connection fails, IPX will use
the secondary route to continue  transmissions to that
destination.

The destination always has to be available initially from the
primary board.  HoWever, once the destination is found through the
primary board and the  connection is made, a route from the
secondary board may be used to continue  transmission if the
primary connection fails.

What Happens If the Primary Connection Is Broken

If IPX is using a route through the second board, the primary
connection can  be broken without causing the secondary connection
to fail.

However, the secondary board does not ever become the primary
board even  when the primary board fails. This means that if IPX
needs to find a new  destination while the primary connection is
down, it will not be able to query  for the destination, since
queries are only sent on the primary board.

To allow IPX to find new destinations, you will have to restore
the primary  connection.

Important

Important

Important


Temp. Rev C -



72 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Setting Up Tw o Network Boards

If you have two network boards in your computer, you may need to

u Load an additional ODI driver. See page 72.

u Change which board IPX uses as primary. See page 74.

u Define hardware settings and frame type for each board. See page
77.

Loading the Driver for an Additional Board

The NetWare Requester installation program allows you to specify
an ODI  driver. That driver is then loaded automatically in the
CONFIG.SYS file.

You may need to load an additional ODI driver manually in the
CONFIG.SYS  file if

u You have two network boards, and

u Those boards use different ODI drivers.

If the boards use the same ODI driver (for example, two NE2000
boards),  simply load the driver once when you install the
Requester, then go to  "Specifying Primary with Tw o Boards of the
Same Type" on page74. Do not  complete the steps in this section.

Prerequisite o Install the NetWare Requester with one of the ODI
drivers. It does  not matter which one. Chapter 3, "Installing a
NetWare  Workstation" of Workstation Basics and Installation
explains how to  install the Requester.

Important

Checklist


Temp. Rev C -



Network Boards and Drivers  73

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Procedures

1. Open the CONFIG.SYS file in a text editor. For example, to use
the OS/2 System Editor at the 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 Requester lines, find the line loading the first
ODI  driver.  For a list of common ODI drivers, see Table5-1,
"List of frame types and  drivers," on page67.

3. Decide which driver you want IPX to recognize as primary.  The
driver for the primary board is the only one IPX uses to query the
network for a route. The driver for the secondary board is never
queried.  "Why Have More Than One Network Board" on page69
explains more  about primary and secondary boards.

4. Type 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 the CONFIG.SYS file is the primary driver.
You  can also specify a primary driver with the "Protocol Stack
IPX bind"  setting in the NET.CFG file.  Type the correct path to
the driver in the line. If you are using a Novell supplied driver,
the driver is located where your other Requester files were
installed, usually in C:\NETWARE.  For example, to load an NE2000
driver from the default location, type the  following:

C:\NETWARE\NE2000.SYS If you have two boards using the same driver
name (such as two NE1000  boards), do not load the driver twice.

Procedure 1 2 3

Note


Temp. Rev C -



74 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

5. Save and exit the CONFIG.SYS file.

6. Reboot your machine to load the additional drivers.

Changing Which Board Is Primary

The board whose driver loads first in the CONFIG.SYS file is the
primary  board. You can change which board is primary by

u Reordering drivers in the CONFIG.SYS file. The previous section,
"Loading the Driver for an Additional Board" on  page72 explains
how to edit the CONFIG.SYS file.

u Using a NET.CFG option to bind IPX to a different driver.

To change which board IPX views as primary, use the "Protocol
Stack IPX"  option in the NET.CFG file:

protocol stack ipx bind  drivername

Replace drivername with the name of the driver that controls the
board, and  indent the "Bind" setting. For example, to set a
Token-Ring board as primary,  type:

protocol stack ipx bind token

"Protocol Stack IPX" on page283 explains more about using this
option.

Specifying Primary with Tw o Boards of the Same Type

If you have two 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 the NET.CFG file to
specify that the  driver is used twice. Do this by placing two
"Link Driver" sections in your  NET .CFG file, each one specifying
the driver name and the hardware settings  used by that board.


Temp. Rev C -



Network Boards and Drivers  75

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



The hardware settings for at least one of the boards must be
specified, since  you cannot have two boards of the same type both
using the default hardware  settings.

"Matching Driver Settings with Board Settings" on page65 explains
more  about specifying hardware settings with the "Link Driver"
option.

For example, if you have two NE2000 boards, you may include the
following  lines in your NET.CFG file:

link driver ne2000 frame ethernet_802.3 frame ethernet_802.2 int 5
port 360

link driver ne2000 frame ethernet_802.3 frame ethernet_802.2 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
board will be ignored entirely.

The board whose line comes first in the NET.CFG file is the one
IPX uses as  primary.

Shortcut for Multiple EISA and Micro Channel Boards

If you are using two EISA or Micro Channel 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
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 card and automatically  determines what hardware
settings are in use.

For example, for two NE3200 boards, type:

Important


Temp. Rev C -



76 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

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 board in slot 2 becomes the primary board
because the  driver for it was loaded first.

To change which board is primary, reorder the "Link Driver"
sections. For  example, to set the 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

The section "slot" on page260 explains more.

Why Change Which Board Is Primary

There are two scenarios in which you may want to change which
board is  primary.

Scenario 1: Faster queries on networks connected with a router

Suppose your primary board is attached to a network and your
secondary board  is attached to a network. The two networks are
connected with a router.

Because of the router, IPX can reach a destination on the second
network by  going through the first network, then the router, and
then the second network.


Temp. Rev C -



Network Boards and Drivers  77

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



However, IPX may have been able to find the destination faster if
it was  querying from the second network board rather than the
first. In this case, you  may want to use the NET.CFG option to
change the secondary board to  primary and have IPX use it for
queries.

If you did this, queries would not be sent on the former primary
board.

Scenario 2: Switching the board in use on unconnected networks

Suppose you have two network boards, each connected to a
physically separate  network. Since IPX only queries the primary
board, you will only have access  to the first network unless you
change which board is primary.

In this case, you may want to change the NET.CFG option and reboot
whenever you want to access the other network.

Or it may be easier to

u Unplug your cable from one board and connect it to the other
board, or

u Connect the networks with a router

Setting Hardware Settings and Frame Type for Each Board

The requirements for setting hardware settings and frame type in
the NET.CFG  file are the same whether you have one board or two
boards.

The only difference is if you have more than one board, you may
need to  specify a "Link Driver" section for each board.

To see how to set hardware settings or frame type using "Link
Driver," see  "Matching Driver Settings with Board Settings" on
page65 and "Specifying  Frame Types for a Driver" on page67.


Temp. Rev C -



78 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

For example, if you have an NE2000 and a Token-Ring board, you
might type

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 slot 2

If you have two boards with the same driver name (such as NE2000),
see  "Specifying Primary with Tw o Boards of the Same Type" on
page74 for  information about using the "Link Driver" option.


Temp. Rev C -



Improving Speed and Security  79

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

chapter 6 Improving Speed and Security

You can use three features to improve speed and security on your
network:

u Packet Burst

u Large Internet Packets

u Packet Signature Level

Topic Page

Improving Speed with Packet Burst 80

Improving Speed by Using Large Internet Packets 81

Improving Security by Using Packet Signature 81


Temp. Rev C -



80 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Improving Speed with 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 aw are of Packet  Burst.

Disabling Packet Burst

Packet Burst is enabled at the workstation by default. You can
disable it by  adding the following line to the workstation's
NET.CFG file:

netware requester packet burst off

See the "packet burst off" setting on page 276 for information on
Packet Burst.


Temp. Rev C -



Improving Speed and Security  81

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



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 v4.0, 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
NetWare server.  The largest packet size that the NetWare 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 lines in the NET.CFG file:

netware requester large internet packets off Improving Security by
Using Packet Signature

NCP Packet Signature is an enhanced security feature that protects
servers and  clients using the NetWare Core Protocol by preventing
packet forgery.

Without the NCP Packet Signature installed, 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.


Temp. Rev C -



82 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

A two-part process between the client and the NetWare server
determines the  NCP Packet Signature:

At LOGIN, the server and the client determine a shared, secret key
known  as the session key.

u 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.

The Packet Burst loadable module, PBURST .NLM, 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.

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. NetWare
servers and clients both have  four settable signature levels.

The signature options for servers and clients combine to determine
the level of  NCP Packet Signature on the network.

Some 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.

Note

Note


Temp. Rev C -



Improving Speed and Security  83

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



Server Levels

Server packet signature levels are assigned by a new 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.

Effective Packet Signature

The packet signature levels for the server and the client interact
to create the  "effective" packet signature. Some combinations of
server and client levels do  not allow logging in.

Table 6-1 NCP P acket Signature levels

Number Explanation

0 Client does not sign packets

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)


Temp. Rev C -



84 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Table 6-1 shows the interactive relationship between the server
packet  signature levels and the client signature levels.

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:

u Only executable programs reside on the server.

All workstation users on the network are known and trusted by the
supervisor.

u 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.

u Someone can easily access the network cabling system.

u There is an unattended, publicly accessible workstation on the
network.

Table 6-2 Effective Packet Signature of server and client

IF Server = 0 Server = 1 Server = 2 Server = 3

Client = 0 No packet  signature No packet  signature No packet
signature No login

Client = 1 No packet  signature No packet  signature Packet
signature Packet  signature

Client = 2 No packet  signature Packet  signature Packet
signature Packet  signature

Client = 3 No login Packet  signature Packet  signature Packet
signature


Temp. Rev C -



Improving Speed and Security  85

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)



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 sets 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 sets the server to level 2, and the clients
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 NetWare server contains some
sensitive data.

The network supervisor sets the server to level 3. Clients 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 sets the sensitive server to level 3 and
the unattended  client to level 0.

Packet Signature Troubleshooting Tips

This section describes some solutions to problems that may be
associated with  using NCP Packet Signature.


Temp. Rev C -



86 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993 (beta)

Clients Are Not Signing Packets

Make sure each OS/2 workstation has NetWare Requester v2.01
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 Requester v2.01 installed.

The following situations do not allow logging in:

u Server packet signature = 3, client signature = 0

u Server packet signature = 0, client signature = 3

u Utilities are old and do not support NCP Packet Signature

u The Requester is old and does not support NCP Packet Signature.

"Error Receiving From the NetWork" Appears

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
on the network. Add a preferred server  statement to the NET.CFG
file for all clients that have access to secure servers  (level
3).


Temp. Rev C -



Using OS/2 Workstations on a Token-Ring Network  87

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

chapter 7 Using OS/2 Workstations on a  Token-Ring Network

If your Token-Ring network includes IBM source-routing bridges,
computers  use source routing to communicate across those bridges.

If you do not use source-routing bridges, skip this chapter.

This chapter explains how to install and configure source routing
on NetWare  servers and OS/2 workstations. NetWare Workstation for
DOS and Windows  explains how to configure source routing on DOS
workstations.

If your network requires source routing, you must install source-
routing  software on both workstations and servers. Novell's
source-routing software  includes:

u ROUTE.NLM (for servers)

u ROUTE.SYS (for OS/2 workstations)

This software routes only IPX packets.

Topic Page

Installing Source Routing on the Server 88

Installing Source Routing on the Workstation 89

Configuring Source Routing on the Workstation 90


Temp. Rev C -



88 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Installing Source Routing on the Server

1. At the server console, load ROUTE.NLM b y typing:

LOAD ROUTE ROUTE.NLM is located in the SYS:SYSTEM directory. You
can load it  with command line parameters. Utilities Reference
explains more about  the parameters.  You can also load ROUTE.NLM
in a startup file.

2. (Conditional) Load ROUTE.NLM again if you have two network
boards in your server.  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.

Procedure 1 2 3


Temp. Rev C -



Using OS/2 Workstations on a Token-Ring Network  89

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Installing Source Routing on the Workstation

Prerequisites o Install the Netware Requester with a TOKEN ODI
driver. Chapter 3,  "Installing a NetWare Worsktation" of
Workstation Basics and  Installation explains how to install the
Requester.  o Install source routing on all NetWare servers on the
same network  as source-routing bridges by following the
instructions in "Installing  Source Routing on the Server" on page
88. o Understand source routing. The September 1990 Novell
Application Notes contains a thorough explanation of source
routing.

Procedures

1. Open the CONFIG.SYS file in a text editor. 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 Requester lines, find the line loading your
TOKEN  ODI driver.  If you are using Novell-supplied ODI drivers,
the driver will be called  TOKEN.SYS.  If you are using LANSUP.SYS
and an NDIS driver, you will not have an ODI  driver loaded. In
this case, find LANSUP.SYS. "Setting Up LANSUP" on  page 121
explains more about LANSUP.

Checklist

Procedure 1 2 3

Note


Temp. Rev C -



90 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

3. Following the line that loads the TOKEN ODI driver, type a new
line  to load the ROUTE.SYS driver. Specify the correct location
of ROUTE.SYS in this line. ROUTE.SYS is  located where your other
Requester files are, usually in C:\NETWARE.  For example, to load
ROUTE.SYS from the default location, type:

C:\NETWARE\ROUTE.SYS

4. Save and exit the CONFIG.SYS file.

5. Use the OS/2 "Shutdown" feature to reboot your machine.
Configuring Source Routing on the Workstation

Follow the procedures in this section to

u Determine whether you need to configure source routing, and

u Configure source routing, if needed.

Prerequisites o Install the NetWare Requester. Chapter 3,
"Installing a NetWare  Workstation" of Workstation Basics and
Installation explains how to  install the Requester.  o Install
source routing on the server. See "Installing Source Routing  on
the Server" on page 88. o Install source routing on the
workstation. See "Installing Source  Routing on the Workstation"
on page 89.  o Understand source routing thoroughly. This section
does not  explain source-routing terminology or how packets are
routed. You  can read IBM publications (such as IBM Token-Ring
Network  Architecture Reference) or the September 1990 Novell
Application  Notes.

Procedures

1. Start the NetWare Requester Installation program.

Checklist

Procedure 1 2 3


Temp. Rev C -



Using OS/2 Workstations on a Token-Ring Network  91

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 the NET.CFG file and choose "Edit." The
"Edit NET.CFG" window appears. See Figure 7-1. 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 following
keys: Table 7-1 Key definitions for the NET.CFG window

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 (text will  reappear the next time  you refresh the
window) <Shift><Delete>

Paste text <Shift><Insert>

Delete text (deleted text  cannot be pasted) <Ctrl><Delete>


Temp. Rev C -



92 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 7-1 Editing NET.CFG for  source routing

     Read online * help for the topic* you selected.

     Select the type* of information you* want to see.

        Select a * NET.CFG option, * setting, or topic.

    Type NET.CFG*     options and*     settings here.

       Save your* configuration or* change your mind.

1 4

2 3

5


Temp. Rev C -



Using OS/2 Workstations on a Token-Ring Network  93

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 to see more information about the
setting  you've selected.  5c. (Optional) If you decide to change
the configuration, type the  configur ation lines (as shown in the
"Usage" help window) in  the "Current NET.CFG File Contents" box.
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 the "Usage"
button.  Repeat steps 5a through 5c for each setting.

6. Choose "Save."

7. Exit the NetWare Requester Installation program and use the
OS/2  "Shutdown" feature to reboot your computer.

Important


Temp. Rev C -



94 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993


Temp. Rev C -



Sharing a Network Board With IBM Software  95

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

chapter 8 Sharing a Network Board With IBM  Software

Use this chapter if you want the NetWare Requester to share a
network board  with one or more of the following IBM software
products:

u Extended Services

u LAN Server

u LAN Requester

If 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 "Setting  Up NetBIOS for OS/2" on page160.

Topic Page

Ho w Board Sharing Is Possible 96

Setting Up ODINSUP 97

Setting Up LANSUP 121

Note


Temp. Rev C -



96 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Ho w Board Sharing Is Possible

The NetWare Requester 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 Requester uses a different driver
specification than  Extended Services and LAN Services, the
NetWare Requester can still share a  network board with these
products. This is possible because of two drivers that  Novell
provides:

u ODINSUP .SYS The ODINSUP driver lets Extended Services and LAN
Services use ODI  network drivers. Use ODINSUP when you want the
ODI network driver  to control the board. See "Setting Up ODINSUP"
on page97.

u LANSUP .SYS The LANSUP driver lets the NetWare Requester use
NDIS network  drivers. Use LANSUP when you want the NDIS driver to
control the  board. See "Setting Up LANSUP" on page121.


Temp. Rev C -



Sharing a Network Board With IBM Software  97

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Setting Up ODINSUP

Except 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.

ODINSUP installation involves three parts, all done in a text
editor. Each part  sets up a different configuration file. You
must do all three parts.

ODINSUP supports Ethernet and Token-Ring compatible ODI drivers.
It does  not support ARCnet or PC Network II drivers.

Step Page

Part A: Binding ODI Drivers in PROTOCOL.INI 98

Part B: Loading ODINSUP in CONFIG.SYS 102

Part C: Configuring ODINSUP in NET.CFG 104

Sample Configuration Files for ODINSUP 111

Note


Temp. Rev C -



98 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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:

u Bind the NDIS protocol stack to the ODI drivers

u Remove the line binding the NDIS protocol stack to the NDIS MAC
drivers These instructions are for LAN Server and LAN Requester
v2.x.

Prerequisites o 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.
o 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.  o After installing all
IBM software, install the NetWare Requester  v2.01 as instructed
in Chapter 3, "Installing a NetWare Workstation"  of Workstation
Basics and Installation. Using the ODI driver for the  board,
verify that you can get connections properly on your  NetWare
network. Chapter 5, "Workstation Login" of Workstation  Basics and
Installation explains about logging in to a NetWare  network. Once
you install the NetWare Requester, 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.

Note

Checklist

Note


Temp. Rev C -



Sharing a Network Board With IBM Software  99

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

1. Open the PROTOCOL.INI file in a text editor.  For example, to
use the OS/2 System Editor at the command line, type:

E C:\IBMCOM\PROTOCOL.INI PROTOCOL.INI is located in the \IBMCOM
directory on your boot drive.

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 any of the
following sections, depending on  whether you have Extended
Services or LAN Services installed:

[NETBEUI_nif] [LANDD_nif]

3. Use a semicolon to remark out all Bindings lines found in
Step2.  For example, your PROTOCOL.INI for a Token-Ring driver
might look as  follows:

[LANDD_nif] . . ; Bindings = IBMTOK_NIF

Procedure 1 2 3


Temp. Rev C -



100 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

4. After each remarked-out Bindings line, add a line to bind the
NDIS  protocol to an ODI driver. Follow the same syntax as the
line you remarked 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). If you do not know which ODI
driver name to use, you can reboot your  machine. An error message
will appear, displaying the name of the ODI  driver that should be
used. If you do this, be sure to 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.

Suggestion


Temp. Rev C -



Sharing a Network Board With IBM Software  101

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 MA C
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 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" on page102.


Temp. Rev C -



102 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Part B: Loading ODINSUP in CONFIG.SYS

In this section, you edit the CONFIG.SYS file in a text editor to
do the  following:

u Load the ODINSUP driver

u Prevent the NDIS network driver (MAC) from loading

Prerequisite o Follow the instructions in "Part A: Binding ODI
Drivers in  PROTOCOL.INI" on page98.

Procedures

1. Open the CONFIG.SYS file in a text editor.  CONFIG.SYS is
located in 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. Remark out the NDIS MAC driver that is equivalent to the ODI
driver you are using. For example, to remark 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 remark
out the lines to load those drivers.

Checklist

Procedure 1 2 3


Temp. Rev C -



Sharing a Network Board With IBM Software  103

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



4. In the NetWare Requester 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  Requester files (\NETWARE by default).
For example, to load the ODINSUP protocol from the default
location,  type:

DEVICE=C:\NETWARE\ODINSUP.SYS If 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.

6a. If your file meets load order requirements, go to Step8.  6b.
If your file violates load order requirements, go to Step7.

7. Rearrange your CONFIG.SYS file to meet load order requirements
for ODINSUP.

Table 8-1 Load order requirements for ODINSUP CONFIG.SYS file

These components . . . Must load BEFORE these components . . .

PROTMAN.OS2 (in OS/2 section right  after path statements) The
ODINSUP protocol

LSL.SYS (in NetWare Requester  section) The ODI driver  The
ODINSUP protocol

The ODI driver (in NetWare Requester  section) The ODINSUP
protocol

NWIFS .IFS (in NetWare Requester  section) NETWKST A.200 (only in
LAN Services configurations)

Note


Temp. Rev C -



104 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

We suggest you make your file match the sample file shown for your
environment. See page 111 for a list of sample configuration
files.  After rearranging your CONFIG.SYS file, go on to Step8.

8. Save and exit the CONFIG.SYS file. Do not exit the text editor.
Go to "Part C: Configuring ODINSUP in  NET .CFG" on page104.

Part C: Configuring ODINSUP in NET.CFG

A NET.CFG file is required to use ODINSUP.

In this section, you edit or create a NET.CFG that does the
following:

u Enables frame types for ODINSUP.

u Specifies to ODINSUP the node address known by Extended Services
and  the format in which that address is transmitted.

u Binds ODINSUP to an ODI driver or drivers.

u Increases the size of the packet that can be transmitted through
the Link  Support layer (if necessary.)

Prerequisites o Follow the instructions in "Part A: Binding ODI
Drivers in  PROTOCOL.INI" on page98. o Follow the instructions in
"Part B: Loading ODINSUP in  CONFIG.SYS" on page102.

Important

Checklist


Temp. Rev C -



Sharing a Network Board With IBM Software  105

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

1. Open the NET.CFG text file in the text editor.  NET .CFG is
located in the root of your boot drive. If the NET.CFG file  does
not exist, create a new file by 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. The setting "frame" on
page252  explains more about frame types and the frame setting.
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 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.

Procedure 1 2 3


Temp. Rev C -



106 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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" on page61.

3. Read the following chart to determine whether you need to
specify  a node address in the NET.CFG file.

If you are using . . . Do this. . .

Extended Services or  LAN Services set up  for universally
administered  addresses

You do not need to specify a node address. Go  to Step5.

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 Step4.

Important


Temp. Rev C -



Sharing a Network Board With IBM Software  107

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 6-byte hexadecimal  number (12
characters). Use the address you located in Step3. 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): u Token-Ring  u 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 is  specified most significant bit
first, the default format for Token-Ring.


Temp. Rev C -



108 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 If you
do not know the node address, you can type a "dummy" address and
go to the next step. When you reboot your machine, an error
message  showing the correct address will be displayed. At that
point, you can edit  the NET.CFG file again and insert the address
that was displayed at boot  time.

Note


Temp. Rev C -



Sharing a Network Board With IBM Software  109

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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. Type the
following lines:

protocol odinsup bind  drivername Replace drivername with the name
of the ODI driver you installed  with the Requester.  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 can 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 "Protocol ODINSUP" on
page281 explains more about the  "Protocol Odinsup" option.


Temp. Rev C -



110 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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.  The Requester 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. "Link Support" on
page261 explains more information about using  this option.  For
example, you might type:

link support buffers 14 4202 For Token-Ring 16/4 boards, the
NetWare Requester will probably  have maximum performance if you
specify 14 buffers, each with a  size of 4202 bytes, as shown in
the example above.

Important


Temp. Rev C -



Sharing a Network Board With IBM Software  111

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 Requester and Extended Services/LAN
Services will then  use the same ODI driver and board to transmit
on the network.

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.

If you follow the steps in "Setting Up ODINSUP" on page97, your
configuration  files will look like the ones shown. We recommend
following the steps rather  than just referring to these sample
files.

Sample Files Page ODINSUP Files from an Extended Services
Environment 112

Extended Services Token-Ring PROTOCOL.INI file for ODINSUP 112

Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 1)
113

Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 2)
114

Extended Services Token-Ring NET.CFG file for ODINSUP 115 ODINSUP
Files from a LAN Requester Environment 115

LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 1)
116

LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 2)
117

LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 1) 118

LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 2) 119

LAN Requester Token-Ring NET.CFG file for ODINSUP 120

Note


Temp. Rev C -



112 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

ODINSUP Files from an Extended Services Environment

These files came from a computer with the following software
installed:

u OS/2 v2.0

u Extended Services v1.0 (locally-administered addresses)

u NetWare Requester v2.01 with ODINSUP.

The computer used Communications Manager to make a LAN connection
to  an IBM host.

Figure 8-1 illustrates a PROTOCOL.INI file for this environment.
Figure 8-1 Extended Services Token-Ring PROTOCOL.INI  file for
ODINSUP

[PROT_MAN]* **    DRIVERNAME = PROTMAN$***** * [IBMLXCFG]* **
LANDD_nif = LANDD.NIF* **    IBMTOK_nif = IBMTOK.NIF******* *
[LANDD_nif]* **    DRIVERNAME = LANDD$***  ;    BINDINGS =
IBMTOK_nif** *     BINDINGS = TOKEN* **    Links = 41* **    Users
= 4**  *    Max_Saps = 4* **    NetAddress = "T400000007030"* *
[IBMTOK_nif]* **    DRIVERNAME = IBMTOK$* * [TOKEN]***

Remark out this line binding * the NDIS TOKEN driver.

Add this line binding the* ODI TOKEN driver.

This node address must be* specified in the NET.CFG.

Include this line at the end* of the file. Put a blank line *
before and after it.


Temp. Rev C -



Sharing a Network Board With IBM Software  113

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-2 and Figure 8-3 illustrate a CONFIG.SYS file for the
environment  shown on page 112.  Figure 8-2 Extended Services
Token-Ring CONFIG.SYS  file for ODINSUP (part 1)

   .***    .***
LIBPATH=.;D:\OS2\DLL;D:\MUGLIB\DLL;D:\OS2\MDOS;D:\CMLIB\DLL;D:\;*
D:\OS2\APPS\DLL;D:\IBMCOM\DLL;D:\NETWARE;***
SET ** PATH=D:\OS2;D:\MUGLIB;D:\OS2\SYSTEM;D:\OS2\MDOS\WINOS2;D:\*
CMLIB;D:\CMLIB\APPN;D:\OS2\INSTALL;D:\;D:\OS2\MDOS;D:\OS2\APPS;*
L:\OS2;P:\OS2;D:\NETWARE;***
SET ** DPATH=D:\OS2;D:\MUGLIB\DLL;D:\CMLIB;D:\CMLIB\APPN;D:\OS2\*
SYSTEM;D:\OS2\MDOS\WINOS2;D:\OS2\INSTALL;D:\;D:\OS2\BITMAP;D:\*
OS2\MDOS;D:\OS2\APPS;D:\IBMCOM;L:\OS2;D:\NETWARE;***
DEVICE=D:\ibmcom\lanmsgdd.os2 /I:D:\ibmcom***
DEVICE=D:\ibmcom\protman.os2 /I:D:\ibmcom***
DEVICE=D:\ibmcom\protocol\LANDD.OS2***
DEVICE=D:\ibmcom\protocol\LANDLLDD.OS2***    .***    .***
DEVICE=D:\CMLIB\ACSLDLAN.SYS*** RUN=D:\OS2\EPW.EXE***
RUN=D:\ibmcom\protocol\landll.exe***
RUN=D:\ibmcom\protocol\netbind.exe***
RUN=D:\ibmcom\lanmsgex.exe**rem *
DEVICE=D:\IBMCOM\MACS\IBMTOK.OS2***
DEVICE=D:\CMLIB\APPN\CMKFMDE.SYS**    .***    .*** *

Protocol Manager* is loaded by* Extended Services.

Continued on next page.

You must remark* out the NDIS* TOKEN driver.


Temp. Rev C -



114 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-3 Extended Services Token-Ring CONFIG.SYS  file for
ODINSUP (part 2)

Figure 8-4 illustrates a NET.CFG file for the environment shown on
page 112.

REM --- NetWare Requester statements BEGIN ---*** SET
NWLANGUAGE=ENGLISH*** DEVICE=D:\NETWARE\LSL.SYS***
RUN=D:\NETWARE\DDAEMON.EXE*** DEVICE=D:\NETWARE\TOKEN.SYS***
DEVICE=D:NETWARE\ROUTE.SYS*** DEVICE=D:\NETWARE\ODINSUP.SYS***
DEVICE=D:\NETWARE\IPX.SYS*** DEVICE=D:\NETWARE\SPX.SYS***
RUN=D:\NETWARE\SPDAEMON.EXE*** DEVICE=D:\NETWARE\NMPIPE.SYS*** rem
DEVICE=D:\NETWARE\NPSERVER.SYS*** RUN=D:\NETWARE\NPDAEMON.EXE***
DEVICE=D:\NETWARE\NWREQ.SYS*** IFS=D:\NETWARE\NWIFS.IFS***
RUN=D:\NETWARE\NWDAEMON.EXE*** rem
DEVICE=D:\NETWARE\NETBIOS.SYS*** rem
RUN=D:\NETWARE\NBDAEMON.EXE*** DEVICE=D:\NETWARE\VIPX.SYS***
DEVICE=D:\NETWARE\VSHELL.SYS PRIVATE*** REM --- NetWare Requester
statements END ---***    .***    .*** *

NetWare file system loads.

1. PROTMAN.OS2* 2. LSL.SYS* 3. ODI driver* 4. ODINSUP* *

Load order requirements

LSL loads.

ODI driver loads.

NetWare * Requester* statements * are loaded* by the * Requester *
installation. You must include * this line to load * ODINSUP.


Temp. Rev C -



Sharing a Network Board With IBM Software  115

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-4 Extended Services Token-Ring NET.CFG file for  ODINSUP

ODINSUP Files from a LAN Requester Environment

These files came from a computer with the following software
installed:

u OS/2 v2.0

u LAN Requester v2.0

u NetWare Requester v2.01 with ODINSUP

Figure 8-5 and Figure 8-6 illustrate a Protocol.INI for this
environment. Figure  8-7 and Figure 8-8 illustrate a CONFIG.SYS
file for this environment.

link driver token* **   node address 400000007030* **   frame
token-ring* **   frame token-ring_snap***** * Protocol odinsup* **
bind token*******

ODI driver name.

1. Link driver* 2. Protocol ODINSUP

Order requirements

Bind both available* TOKEN frame types* to the ODI driver.

Bind ODINSUP* to the ODI driver.

Put a blank line at* the end of the file* and between options.


Temp. Rev C -



116 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-5 LAN Requester Token-Ring PROTOCOL.INI file  for ODINSUP
(part 1)

Add this line binding the * ODI TOKEN driver.

Continued on next page.

[PROT_MAN]*    ** DriverName = PROTMAN$***** [IBMLXCFG]*    **
IBMTOK_nif = IBMTOK.nif*    ** NETBEUI_nif = NETBEUI.nif*    **
LANDD_nif = LANDD.nif***** * ;*-----------------------------------
--------------------**** ;*---------- PROTOCOL SECTION -----------
-**** ;*-------------------------------------------------------
******* * [NETBEUI_nif]*    ** DriverName = netbeui$* ;  **
Bindings = IBMTOK_nif*       Bindings = TOKEN**     *
ETHERAND_TYPE = "I"*    ** USEADDRREV = "YES"*    ** SESSIONS =
40*    ** NCBS = 95*    ** NAMES = 21*    ** SELECTORS = 5*    **
USEMAXDATAGRAM = "NO"*    ** ADAPTRATE = 1000*    ** WINDOWERRORS
= 0*    ** TI = 30000*    ** T1 = 500*    ** T2 = 200*    ** MAXIN
= 1*    ** MAXOUT = 1*    ** NETBIOSTIMEOUT = 500*    **
NETBIOSRETRIES = 8*    ** NAMECACHE = 0*    ** PIGGYBACKACKS = 1*
** DATAGRAMPACKETS = 2*    ** PACKETS = 350*    ** PIPELINE = 5*
MAXTRANSMITS = 6*    ** MINTRANSMITS = 2*    ** DLCRETRIES = 5

Comment out this line binding * the NDIS TOKEN driver.


Temp. Rev C -



Sharing a Network Board With IBM Software  117

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-6 LAN Requester Token-Ring PROTOCOL.INI file  for ODINSUP
(part 2)

[LANDD_nif]* *   * DriverName = LANDD$* ;  ** Bindings =
IBMTOK_nif*       Bindings = TOKEN*    ** ETHERAND_TYPE = "I"*
** SYSTEM_KEY = 0x0*    ** OPEN_OPTIONS = 0x2000*    ** TRACE =
0x0*    ** LINKS = 8*    ** MAX_SAPS = 3*    ** MAX_G_SAPS = 0*
** USERS = 3*    ** TI_TICK_G1 = 255*    ** T1_TICK_G1 = 15*    **
T2_TICK_G1 = 3*    ** TI_TICK_G2 = 255*    ** T1_TICK_G2 = 25*
** T2_TICK_G2 = 10*    ** IPACKETS = 250*    ** UIPACKETS = 100*
** MAXTRANSMITS = 6*    ** MINTRANSMITS = 2*    ** TCBS = 64**
GDTS = 30*    ** ELEMENTS = 800******* * ;;*----------------------
---------------------------------**** ;*--------------- MAC
SECTION  -----------------**** ;*---------------------------------
----------------------******** * [IBMTOK_nif]*    ** DriverName =
IBMTOK$*    ** PRIMARY*       MAXTRANSMITS = 12*    ** RECVBUFS =
2*    ** RECVBUFSIZE = 256*    ** XMITBUFS = 1** * [TOKEN]

Add this line binding the * ODI TOKEN driver.

Comment out this line binding * the NDIS TOKEN driver.

You must include this line.* Put a blank line before and after it.


Temp. Rev C -



118 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-7 LAN Requester Token-Ring CONFIG.SYS file  for ODINSUP
(part 1)

     .* **   .***
LIBPATH=C:\MUGLIB\DLL;C:\IBMLAN\NETLIB;.;C:\OS2\DLL;C:\OS2\MDOS;C:
\;C:\OS2\* APPS\DLL;C:\NETWARE;C:\ibmcom\dll;*** SET **
PATH=C:\IBMLAN\NETPROG;C:\MUGLIB;C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS*
\*
WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;L:\OS2;P:\OS2;*C
:\NETWARE;*** SET **
DPATH=C:\IBMLAN\NETPROG;C:\IBMLAN;C:\MUGLIB;C:\OS2;C:\OS2\SYSTEM;*
C:\OS2\*
MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\AP
PS;L:\OS2;* C:\NETWARE;C:\ibmcom;* **   .* **   ***
DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protocol\LANDD.OS2***
DEVICE=C:\ibmcom\protocol\LANDLLDD.OS2* **   .* **
.*** CODEPAGE=437,850***
DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP***
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2*******
REM DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2***
DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200*** * *

Protocol Manager* is loaded by* LAN Services.

The LAN Services * NETBIOS driver loads.

You must remark* out the NDIS* TOKEN driver. Continued on next
page.


Temp. Rev C -



Sharing a Network Board With IBM Software  119

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-8 LAN Requester Token-Ring CONFIG.SYS file  for ODINSUP
(part 2)

REM --- NetWare Requester statements BEGIN ---***
SET NWLANGUAGE=ENGLISH***
DEVICE=C:\NETWARE\LSL.SYS***
RUN=C:\NETWARE\DDAEMON.EXE***
DEVICE=C:\NETWARE\TOKEN.SYS***
DEVICE=C:\NETWARE\ROUTE.SYS***
DEVICE=C:\NETWARE\ODINSUP.SYS***
DEVICE=C:\NETWARE\IPX.SYS***
DEVICE=C:\NETWARE\SPX.SYS***
RUN=C:\NETWARE\SPDAEMON.EXE***
rem DEVICE=C:\NETWARE\NMPIPE.SYS***
rem DEVICE=C:\NETWARE\NPSERVER.SYS***
rem RUN=C:\NETWARE\NPDAEMON.EXE***
DEVICE=C:\NETWARE\NWREQ.SYS***
IFS=C:\NETWARE\NWIFS.IFS***
RUN=C:\NETWARE\NWDAEMON.EXE***
rem DEVICE=C:\NETWARE\NETBIOS.SYS***
rem RUN=C:\NETWARE\NBDAEMON.EXE***
DEVICE=C:\NETWARE\VIPX.SYS***
DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE***
REM --- NetWare Requester statements END ---*******    .*    .*
IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N***
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2***
RUN=C:\IBMLAN\NETPROG\LSDAEMON.EXE***
RUN=C:\ibmcom\protocol\landll.exe***
RUN=C:\ibmcom\protocol\netbind.exe***
RUN=C:\ibmcom\lanmsgex.exe***

1. PROTMAN.OS2* 2. LSL.SYS* 3. ODI driver* 4. ODINSUP* *

Load order requirements

The LAN Services * file system loads.

1. NWIFS.IFS* 2. NETWKSTA.200

LSL loads. ODI driver loads.

NetWare * Requester* statements * are loaded* by the * Requester *
installation.

NetWare file * system loads.

You must include * this line to load * ODINSUP.


Temp. Rev C -



120 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-9 illustrates a NET.CFG file for the environment shown on
page 115.  Figure 8-9 LAN Requester Token-Ring NET.CFG file for
ODINSUP

link driver token* **   frame token-ring* **   frame token-
ring_snap***** * protocol odinsup* **   bind token*******

ODI driver name.

1. Link driver* 2. Protocol ODINSUP

Order requirements

Bind both available* TOKEN frame types* to the ODI driver. Bind
the ODI driver* to ODINSUP.

Put a blank line at* the end of the file* and between options.


Temp. Rev C -



Sharing a Network Board With IBM Software  121

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Setting Up LANSUP

Except where noted, the instructions in this section apply whether
you have  Extended Services, LAN Services, or both. How ever, 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. The parts and their page numbers
are shown in the following  table:

Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN
and  TOKENEE modules used in the NetWare Requester v1.3.  CMGRLAN
and  TOKENEE are not supported in the NetWare Requester v2.01.

LANSUP w orks with NDIS drivers for PC Network II, Ethernet, and
Token Ring network boards.

Step Page

Part A: Loading LANSUP in CONFIG.SYS 122

Part B: Configuring LANSUP in NET.CFG 124

Part C: Increasing Packet Size for LANSUP (Optional) 128

Sample Configuration Files for LANSUP 132

Note


Temp. Rev C -



122 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Part A: Loading LANSUP in CONFIG.SYS

In this section, you use the NetWare Requester installation
program to load  LANSUP in the CONFIG.SYS file.

If you have not yet installed the NetWare Requester, you can
install the  Requester at the same time as you install LANSUP.

These instructions are for LAN Server and LAN Requester v2.x.

Prerequisites o Install Extended Services on the workstation.
Verify that you can  get a Communications Manager or Database
Manager connection.  See the documentation for Extended Services.
o 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.

Procedures

1. Start the NetWare Requester Installation program.  If the
Requester is not installed, you can start the program from your
WSOS2_1 diskette. Type INSTALL. You can install the Requester with
this procedure.  If the Requester 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."

Note

Checklist

Procedure 1 2 3


Temp. Rev C -



Sharing a Network Board With IBM Software  123

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



4. Select an action from the "Requester Installation" screen based
on  whether the Requester is installed: 4a. If the Requester is
not installed, select "Edit CONFIG.SYS and  Copy All Files . . . "
and choose "OK." 4b. If the Requester is already installed, select
"Only Edit  CONFIG.SYS . . ." and choose "OK."

5. Select LANSUP as the ODI 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 the Requester, the "Copy Requester Files" screen
appears. Continue with Step9.  If you have installed the
Requester, the main installation menu appears.  Go to "Part B:
Configuring LANSUP in NET.CFG" on page124.

9. Choose "Copy" and follow the screens to finish installing the
Requester.  When the main menu returns, go to "Part B: Configuring
LANSUP in  NET .CFG" on page124.


Temp. Rev C -



124 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Part B: Configuring LANSUP in NET.CFG

A NET.CFG file is required to use LANSUP.

In this section, you edit or create a NET.CFG file that does the
following:

u Enables frame types for LANSUP

u 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 o Install the NetWare Requester with LANSUP by
following the  instructions in "Part A: Loading LANSUP in
CONFIG.SYS" on  page 122.

Procedures

1. Choose "This workstation . .." from the "Configuration" menu of
the  NetWare Requester installation program.  If the NetWare
Requester installation program is not running, complete  the steps
in "Part A: Loading LANSUP in CONFIG.SYS" on page122  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:

Important

Checklist

Procedure 1 2 3


Temp. Rev C -



Sharing a Network Board With IBM Software  125

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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.  Table 8-2 lists the supported frame types for
LANSUP:

For example, to enable a frame types 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. 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

Table 8-2 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

Important


Temp. Rev C -



126 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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. Read the following chart to determine what node address you
should use.

6. In the "Current NET.CFG File Contents" box, type a line to
specify  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): u Token-Ring  u PC Network II Ethernet frames are canonical
(LSB).

If you are using . . . Get the node address from here . . .

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


Temp. Rev C -



Sharing a Network Board With IBM Software  127

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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.


Temp. Rev C -



128 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 If you do not know the node address, you can
type a "dummy" address and  go to the next step. When you reboot
your machine, an error message  showing the correct address will
be displayed. 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 xxx, (the Link Support
default), transmission speed  may improve if you increase the Link
Support Layer default to the board's  maximum allowed size. 7a. If
you want to increase the packet size, go to "Part C:  Increasing
Packet Size for LANSUP (Optional)" on page128.  7b. If you do not
want to increase the packet size, go to Step8.

8. Choose "Save . . ."

9. Exit the NetWare Requester 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. The  NetWare Requester and Extended Services or LAN
Services will then use  the same NDIS driver and board to transmit
on the network.

Part C: Increasing Packet Size for LANSUP (Optional)

Only do this section if you were directed to come here in Step 7a
on page 128.

Note


Temp. Rev C -



Sharing a Network Board With IBM Software  129

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



In this section, you

u Edit the NET.CFG file to increase the size of the packet that
can be  transmitted through LANSUP.

u Edit the PROTOCOL.INI to increase the size of the packet that
can be  transmitted through the NDIS drivers.

Prerequisite o Install the NetWare Requester with LANSUP by
following the  instructions in "Part A: Binding ODI Drivers in
PROTOCOL.INI" on  page 98. o Follow the instructions in "Part B:
Configuring LANSUP in  NET .CFG" on page124.

Procedures

1. Select "Link support" in the "NET.CFG Options" box on the left
of  your screen.  If the Requester installation program is not
open to the "Edit NET.CFG  Window", complete the steps in "Part B:
Configuring LANSUP in  NET .CFG" on page124. 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.

Checklist

Procedure 1 2 3


Temp. Rev C -



130 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

4. In the "Current NET.CFG File Contents," type lines to change
the  "Link Support buffers" setting.  Follow the usage
requirements shown in the help window.  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.  The
Requester 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. "Link
Support" on page261 explains more information about using this
option.  For example, you might type:

link support buffers 14 4202 For Token-Ring 16/4 boards, the
NetWare Requester will probably have  maximum performance if you
specify 14 buffers, each with a size of 4202  bytes, as shown in
the example above.

5. Choose "Save . . ."

6. Exit the NetWare Requester installation program.  Without
rebooting your machine, go to Step 7.

7. Run the IBM LAPS program to edit PROTOCOL.INI..

Important


Temp. Rev C -



Sharing a Network Board With IBM Software  131

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



8. Change the transmit buffer size to a number 6 bytes larger than
the  number you set for the Link Support buffer size in Step4.
The value you specify must be a multiple of 8. See your LAPS
documentation for more information about changing the transmit
buffer  size.  Use a 4208 transmit buffer size if you are using
Token-Ring 16/4 boards.  The LAPS program inserts the following
line in NDIS MAC driver section  of your PROTOCOL.INI:

XMITBUFSIZE = 4208

9. Exit the LAPS program.

10.Choose "Shutdown" from the OS/2 System menu to reboot your
machine.  When your machine starts again, LANSUP support will be
set up.  NetWare Requester and Extended Services/LAN Services will
transmit to  the network from the same NDIS driver and network
board.

Important


Temp. Rev C -



132 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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.

If you follow the steps in "Setting Up LANSUP" on page121, your
configuration  files will look like the ones shown. We recommend
following the steps rather  than just referring to these sample
files.

Sample Files Page ODINSUP Files from an Extended Services
Environment 112

Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 1)
134

Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 2)
135

Extended Services Token-Ring NET.CFG file for LANSUP 136

Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 1)
137

Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 1)
137 ODINSUP Files from a LAN Requester Environment 115

LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 1) 139

LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 2) 140

LAN Requester Token-Ring NET.CFG file for LANSUP 141

LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 1) 142

LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 2) 143

Note


Temp. Rev C -



Sharing a Network Board With IBM Software  133

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



LANSUP Files from an Extended Services Environment

These files came from a computer with the following software
installed:

u OS/2 v2.0

u Extended Services v1.0 (locally-administered addresses)

u NetWare Requester v2.01 with LANSUP.

The computer used Communications Manager to make a LAN connection
to  an IBM host. Figure 8-10 and Figure 8-11 illustrate a
CONFIG.SYS file.


Temp. Rev C -



134 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-10 Extended Services Token-Ring CONFIG.SYS  file for
LANSUP (part 1)

     .*      .* *    .   **
LIBPATH=.;C:\OS2\DLL;C:\MUGLIB\DLL;C:\OS2\MDOS;C:\CMLIB\DLL;C:\;C*
:\OS2\APPS\* DLL;C:\NETWARE;C:\ibmcom\dll;*** SET **
PATH=C:\OS2;C:\MUGLIB;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\CMLIB;C*
:\CMLIB\*
APPN;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;L:\OS2;P:*\OS2;C:\
NETWARE;*** SET **
DPATH=C:\OS2;C:\MUGLIB\DLL;C:\CMLIB;C:\CMLIB\APPN;C:\OS2\SYSTEM;C*
:\OS2\*
MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:*\OS2\A
PPS;L:\* OS2;C:\NETWARE;C:\ibmcom;* **   .* **   .***
DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protocol\LANDD.OS2***
DEVICE=C:\ibmcom\protocol\LANDLLDD.OS2* **   .* **   .* **   .***
DEVICE=C:\CMLIB\ACSLDLAN.SYS*** RUN=C:\OS2\EPW.EXE***
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2***
RUN=C:\ibmcom\protocol\landll.exe***
RUN=C:\ibmcom\protocol\netbind.exe***
RUN=C:\ibmcom\lanmsgex.exe***
DEVICE=C:\CMLIB\APPN\CMKFMDE.SYS***** * REM --- NetWare Requester
statements BEGIN ---*** SET NWLANGUAGE=ENGLISH***
DEVICE=C:\NETWARE\LSL.SYS*** RUN=C:\NETWARE\DDAEMON.EXE***
DEVICE=C:\NETWARE\LANSUP.SYS*** DEVICE=C:\NETWARE\ROUTE.SYS***
DEVICE=C:\NETWARE\IPX.SYS*** *** * Continued on next page.

Protocol Manager* is loaded by* Extended Services.

NetWare * Requester* statements * are loaded* by the * Requester *
installation.

NDIS TOKEN driver* is loaded by* Extended Services.

LSL loads.

LANSUP loads.


Temp. Rev C -



Sharing a Network Board With IBM Software  135

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-11 Extended Services Token-Ring CONFIG.SYS  file for
LANSUP (part 2)

DEVICE=C:\NETWARE\SPX.SYS* RUN=C:\NETWARE\SPDAEMON.EXE***
DEVICE=C:\NETWARE\NMPIPE.SYS*** rem
DEVICE=C:\NETWARE\NPSERVER.SYS*** RUN=C:\NETWARE\NPDAEMON.EXE***
DEVICE=C:\NETWARE\NWREQ.SYS*** IFS=C:\NETWARE\NWIFS.IFS***
RUN=C:\NETWARE\NWDAEMON.EXE*** rem
DEVICE=C:\NETWARE\NETBIOS.SYS*** rem
RUN=C:\NETWARE\NBDAEMON.EXE*** DEVICE=C:\NETWARE\VIPX.SYS***
DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE*** REM --- NetWare Requester
statements END ---*

NetWare file system loads.


Temp. Rev C -



136 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-12 illustrates a NET.CFG for the environment shown on
page 133. Figure 8-12 Extended Services Token-Ring NET.CFG file
for  LANSUP

Figure 8-13 and Figure 8-13 illustrate a PROTOCOL.INI for the
environment  shown on page 133.

link driver lansup* **   node address 10005a8c62d4M* **   frame
token-ring* **   frame token-ring_snap***** * link support* **
buffers 14 4202

Set node address.* * Bind both available* TOKEN frame types* to
LANSUP.

You can increase Link* Support buffer size for 4 KB* boards.

Use the address specified* in "NetAddress" in * PROTOCOL.INI.

Locally-administered* addresses

Use the address assigned* to the board by the vendor.

Universally-administered* addresses "XMITBUFSIZE" in*
PROTOCOL.INI* must be 6 more than* this number and * divisible by
8.


Temp. Rev C -



Sharing a Network Board With IBM Software  137

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-13 Extended Services Token-Ring PROTOCOL.INI  file for
LANSUP (part 1)

[PROT_MAN]*    ** DriverName = PROTMAN$***** * [IBMLXCFG]*    **
IBMTOK_nif = IBMTOK.NIF*    ** LANDD_nif = LANDD.NIF***** * ;*----
---------------------------------------------------**** ;*--------
-- PROTOCOL SECTION ------------**** ;*---------------------------
----------------------------****** * [LANDD_nif]** *
DriverName = LANDD$*    ** Bindings = IBMTOK_nif**     *
ETHERAND_TYPE = "I"*    ** SYSTEM_KEY = 0x0*    ** OPEN_OPTIONS =
0x2000*    ** TRACE = 0x0*    ** LINKS = 41*    ** MAX_SAPS = 4*
** MAX_G_SAPS = 0*    ** USERS = 4*    ** TI_TICK_G1 = 255*    **
T1_TICK_G1 = 15*    ** T2_TICK_G1 = 3*    ** TI_TICK_G2 = 255*
** T1_TICK_G2 = 25*    ** T2_TICK_G2 = 10*    ** IPACKETS = 250*
** UIPACKETS = 100*    ** MAXTRANSMITS = 6*    ** MINTRANSMITS =
2*    ** TCBS = 64*    ** GDTS = 30*    ** ELEMENTS = 800******* *

NDIS TOKEN * driver is bound.

Continued on next page.


Temp. Rev C -



138 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-14 Extended Services Token-Ring PROTOCOL.INI  file for
LANSUP (part 2)

LANSUP Files from a LAN Requester Environment

These files came from a computer with the following software
installed:

u OS/2 v2.0

u LAN Requester v2.0

u NetWare Requester v2.01 with LANSUP

Figure 8-15 and Figure 8-16 illustrate a CONFIG.SYS file for this
environment.

;*-------------------------------------------------------**** ;*--
------------- MAC SECTION  -----------------**** ;*---------------
----------------------------------------******** * [IBMTOK_nif]*
** DriverName = IBMTOK$*    ** PRIMARY*    ** MAXTRANSMITS = 12*
** RECVBUFS = 2*    ** RECVBUFSIZE = 256*    ** XMITBUFS = 1*
** XMITBUFSIZE = 4208* For Token-Ring 16/4 boards, "Link Support
buffer size"* in NET.CFG must be 6 bytes less than this number.

Note: This example uses universally-administered addresses, so a
node address is not *           specified in PROTOCOL.INI.


Temp. Rev C -



Sharing a Network Board With IBM Software  139

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-15 LAN Requester Token-Ring CONFIG.SYS file  for LANSUP
(part 1)

Protocol Manager* is loaded by* LAN Services.

For TOKEN LANSUP environments,* you must run the IBM LAPS program*
and install 802.2 support to load these * components.

     .* **   .***
LIBPATH=C:\MUGLIB\DLL;C:\IBMLAN\NETLIB;.;C:\OS2\DLL;C:\OS2\MDOS;C:
\;C:\OS2\* APPS\DLL;C:\NETWARE;C:\ibmcom\dll;*** SET **
PATH=C:\IBMLAN\NETPROG;C:\MUGLIB;C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\
WINOS2*
;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;L:\OS2;P:\OS2;C:\NETWA
RE;*** SET **
DPATH=C:\IBMLAN\NETPROG;C:\IBMLAN;C:\MUGLIB;C:\OS2;C:\OS2\SYSTEM;*
C:\OS2\*
MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\AP
PS;L:\OS2;* C:\NETWARE;C:\ibmcom;* **   .* **   .***
DEVICE=C:\ibmcom\lanmsgdd.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protman.os2 /I:C:\ibmcom***
DEVICE=C:\ibmcom\protocol\LANDD.OS2***
DEVICE=C:\ibmcom\protocol\LANDLLDD.OS2* **   .* **   .***
CODEPAGE=437,850*** DEVINFO=KBD,US,C:\OS2\KEYBOARD.DCP***
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2*******
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2***
DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200* *

The LAN Services* NETBIOS driver loads.

Continued on next page.

NDIS TOKEN * driver loads.


Temp. Rev C -



140 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-16 LAN Requester Token-Ring CONFIG.SYS file  for LANSUP
(part 2)

REM --- NetWare Requester statements BEGIN ---*** SET
NWLANGUAGE=ENGLISH*** DEVICE=C:\NETWARE\LSL.SYS***
RUN=C:\NETWARE\DDAEMON.EXE*** DEVICE=C:\NETWARE\LANSUP.SYS***
DEVICE=C:\NETWARE\ROUTE.SYS*** DEVICE=C:\NETWARE\IPX.SYS***
DEVICE=C:\NETWARE\SPX.SYS*** RUN=C:\NETWARE\SPDAEMON.EXE*** rem
DEVICE=C:\NETWARE\NMPIPE.SYS*** rem
DEVICE=C:\NETWARE\NPSERVER.SYS*** rem
RUN=C:\NETWARE\NPDAEMON.EXE*** DEVICE=C:\NETWARE\NWREQ.SYS***
IFS=C:\NETWARE\NWIFS.IFS*** RUN=C:\NETWARE\NWDAEMON.EXE*** rem
DEVICE=C:\NETWARE\NETBIOS.SYS*** rem
RUN=C:\NETWARE\NBDAEMON.EXE*** DEVICE=C:\NETWARE\VIPX.SYS***
DEVICE=C:\NETWARE\VSHELL.SYS PRIVATE*** REM --- NetWare Requester
statements END ---******* *** IFS=C:\IBMLAN\NETPROG\NETWKSTA.200
/I:C:\IBMLAN /N*** DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2***
RUN=C:\IBMLAN\NETPROG\LSDAEMON.EXE***
RUN=C:\ibmcom\protocol\landll.exe***
RUN=C:\ibmcom\protocol\netbind.exe*** RUN=C:\ibmcom\lanmsgex.exe*

NetWare file system loads.

LAN Services file* system loads.

1. NWIFS.IFS* 2. NETWKSTA.200

Load order requirements

LSL loads.

LANSUP loads.

NetWare * Requester* statements * are loaded* by the * Requester *
installation.


Temp. Rev C -



Sharing a Network Board With IBM Software  141

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-17 illustrates a NET.CFG for the environment shown on
page 138.  Figure 8-17 LAN Requester Token-Ring NET.CFG file for
LANSUP

Figure 8-18 and Figure 8-19 illustrate a PROTOCOL.INI for the
environment  shown on page 138.

link driver lansup* node address 10005a8c62d4M* frame token-ring

Set node address. Use the* address assigned to the board* by the
vendor.* * Bind aTOKEN frame * type to LANSUP. Put a blank line
at* the end of the file.


Temp. Rev C -



142 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 8-18 LAN Requester Token-Ring PROTOCOL.INI file  for LANSUP
(part 1)

Continued on next page.

[PROT_MAN]*    ** DriverName = PROTMAN$***** [IBMLXCFG]*    **
IBMTOK_nif = IBMTOK.nif*    ** NETBEUI_nif = NETBEUI.nif*    **
LANDD_nif = LANDD.nif***** * ;*-----------------------------------
--------------------**** ;*---------- PROTOCOL SECTION -----------
-**** ;*-------------------------------------------------------
******* * [NETBEUI_nif]*    ** DriverName = netbeui$*    **
Bindings = IBMTOK_nif*     * ETHERAND_TYPE = "I"*    ** USEADDRREV
= "YES"*    ** SESSIONS = 40*    ** NCBS = 95*    ** NAMES = 21*
** SELECTORS = 5*    ** USEMAXDATAGRAM = "NO"*    ** ADAPTRATE =
1000*    ** WINDOWERRORS = 0*    ** TI = 30000*    ** T1 = 500*
** T2 = 200*    ** MAXIN = 1*    ** MAXOUT = 1*    **
NETBIOSTIMEOUT = 500*    ** NETBIOSRETRIES = 8*    ** NAMECACHE =
0*    ** PIGGYBACKACKS = 1*    ** DATAGRAMPACKETS = 2*    **
PACKETS = 350*    ** PIPELINE = 5*      MAXTRANSMITS = 6*    **
MINTRANSMITS = 2*    ** DLCRETRIES = 5

LAN Services NetBIOS * protocol is configured. NDIS TOKEN* driver
is bound.


Temp. Rev C -



Sharing a Network Board With IBM Software  143

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 8-19 LAN Requester Token-Ring PROTOCOL.INI file  for LANSUP
(part 2)

[LANDD_nif]* *   * DriverName = LANDD$*    ** Bindings =
IBMTOK_nif*    ** ETHERAND_TYPE = "I"*    ** SYSTEM_KEY = 0x0*
** OPEN_OPTIONS = 0x2000*    ** TRACE = 0x0*    ** LINKS = 8*
** MAX_SAPS = 3*    ** MAX_G_SAPS = 0*    ** USERS = 3*    **
TI_TICK_G1 = 255*    ** T1_TICK_G1 = 15*    ** T2_TICK_G1 = 3*
** TI_TICK_G2 = 255*    ** T1_TICK_G2 = 25*    ** T2_TICK_G2 = 10*
** IPACKETS = 250*    ** UIPACKETS = 100*    ** MAXTRANSMITS = 6*
** MINTRANSMITS = 2*    ** TCBS = 64** GDTS = 30*    ** ELEMENTS =
800******* * ;;*--------------------------------------------------
-----**** ;*--------------- MAC SECTION  -----------------**** ;*-
------------------------------------------------------******** *
[IBMTOK_nif]*    ** DriverName = IBMTOK$*    ** PRIMARY*
MAXTRANSMITS = 12*    ** RECVBUFS = 2*    ** RECVBUFSIZE = 256*
** XMITBUFS = 1*

NDIS TOKEN driver is bound.

Note: You are not required to change anything in PROTOCOL.INI to
set up LANSUP.


Temp. Rev C -



144 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 145

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

chapter 9 Setting Up Named Pipes and  NetBIOS Protocols

This chapter explains how to install and configure the Named Pipes
and  NetBIOS protocols.

Topic Page

About the Protocol Support in the NetWare Requester 146

Setting Up Named Pipes for OS/2 149

Setting Up Named Pipes for DOS and Windows 157

Setting Up NetBIOS for OS/2 160

Setting Up NetBIOS for DOS and Windows 184


Temp. Rev C -



146 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

About the Protocol Support in the NetWare Requester

Novell provides four kinds of protocol support with the NetWare
Requester for  OS/2:

u IPX

u SPX

u Named Pipes

u NetBIOS (emulation)

NetWare servers and clients 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 automatically installed  when you install the
NetWare workstation software.

The SPX, NetBIOS, and Named Pipes protocols are provided by Novell
so that  NetWare clients and servers can also function as:

u Distributed application clients and servers

u Non-NetWare network clients and servers

u Terminals connected to mainframes or minicomputers

For example, the Lotus Notes distributed application uses NetBIOS
for  communications; Microsoft SQL Server uses Named Pipes.
LANServer  networks use NetBIOS, and many Communications Manager
connections to a  mainframe also use NetBIOS.

Other protocols not provided with the NetWare Workstation for OS/2
can also  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 book.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 147

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 9-1 illustrates the components of a distributed application
network.  Note that protocol support software usually must be
installed independent of  installing the distributed application
software.

Figure 9-1 Protocol software is  separate from  distributed
application  software OS/2 Protocol* support

Distributed* application* client

OS/2

Protocol* support

Distributed* application* server

Distributed* application* network D O S P r o t o c o l *

s u p p o r t

D i s t r i b u t e d *

a p p l i c a t i o n *

c l i e n t D O S P r o t o c o l *

s u p p o r t

D i s t r i b u t e d *

a p p l i c a t i o n *

c l i e n t

Provided by Novell

W i n d o w s


Temp. Rev C -



148 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Several different protocols can be installed on the same computer
at the same  time. All of these protocols can use the same network
cabling, though each  protocol may communicate on a completely
separate logical network. Figure  9-2 shows how a NetWare network
and a distributed application network share  cabling.

Figure 9-2 A distributed  application on a  NetWare network

I P X I P X

N a m e d p i p e s

OS/2* workstation

NetWare* server

OS/2* workstation

* NetWare client*

* Distributed application *   server

* NetWare client*

* Distributed application *   client


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 149

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Setting Up Named Pipes for OS/2

You must install the Named Pipes support you need on each computer
that will  use Named Pipes on the network. In most cases, you must
also set certain  configuration options for the protocol.

Installing Named Pipes for OS/2

Named Pipes support between sessions on a single OS/2 workstation
is  provided with 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.

"Protocol Requests from OS/2 Sessions" on page301 explains how
Novell's  Named Pipes support for OS/2 works.

Prerequisite o Install your Named Pipes distributed application.
See the  documentation for your application.

Procedures

1. Start the NetWare Requester installation program.  If the
Requester is not installed, you can start the program from your
WSOS2_1 diskette. Type INSTALL. You can install the Requester at
the  same time as you install Named Pipes.  If the Requester 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."

Checklist

Procedure 1 2 3


Temp. Rev C -



150 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

4. Select an action from the "Requester Installation" screen based
on  whether the Requester is installed: 4a. If the Requester is
not installed, select "Edit CONFIG.SYS and  Copy All Files . . . "
and choose "OK." 4b. If the Requester is already 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 "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
the"Configuring Named Pipes for OS/2" section,  you will be told
to do the "Special Instructions for SQL Client  Workstations"
section.  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 previously installed the Requester, the "Copy Requester
Files" screen appears. Continue with Step 11.  If you have
previously installed the Requester, the main installation menu
appears. Go to "Configuring Named Pipes for OS/2" on page151.

11.Choose "Copy" and follow the screens to finish installing the
Requester.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 151

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



When the main menu returns, go to "Configuring Named Pipes for
OS/2"  on page151.

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

u Determine whether you need to change the default configuration
for  Named Pipes and SPX, and

u Change the configuration if necessary.

You can change the configuration for such features as

Available number of client and server sessions

u Number of service threads available for Named Pipes
communication

u Number of SPX sessions available for Named Pipes and other SPX
communication (Named Pipes uses SPX)

Prerequisite o The NetWare Requester for OS/2 must be installed.
If it is not  installed, do the steps in "Installing Named Pipes
for OS/2" on  page 149.

Procedures

1. Start the NetWare Requester installation program.  The program
may already be running if you just installed Named Pipes  support.
If the program is not running, start it by choosing the
"Installation" icon from the "Novell" group on your desktop.

Checklist

Procedure 1 2 3


Temp. Rev C -



152 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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. See Figure 9-3. 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 following
keys: Table 9-1 Key definitions for the NET.CFG window

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 (text will  reappear the next time  you refresh the
window) <Shift><Delete>

Paste text <Shift><Insert>

Delete text (deleted text  cannot be pasted) <Ctrl><Delete>


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 153

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 9-3 Editing NET.CFG for  Named Pipes

     Read online * help for the topic* you selected.

     Select the type* of information you* want to see.

        Select a * NET.CFG option, * setting, or topic.

    Type NET.CFG*     options and*     settings here.

       Save your* configuration or* change your mind.

1 4

2 3

5


Temp. Rev C -



154 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 "service threads" 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 to see more information about the setting
you've selected.  5c. (Optional) If you decide to change the
configuration, type the  configur ation lines (as shown in the
"Usage" help window) into  the "Current NET.CFG File Contents"
box. 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 the
"Usage" button.  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 to see more information about the setting you've
selected.

Important


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 155

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



9. (Optional) If you decide to change the configuration, type the
configur ation lines (as shown in the "Usage" help window) into
the  "Current NET.CFG File Contents" box.  If you decide not to
change the configuration, no action is required for this  step.
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 the "Usage"
button.

10.Choose "Save."

11.Exit the NetWare Requester 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" on  page 155. Do not
reboot yet.  11b.If your workstation will not be a SQL client,
close the  installation program and use the OS/2 "Shutdown"
feature to  reboot your computer.

Special Instructions for SQL Client Workstations

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 the default NETAPI.DLL
contains (including the NETBIOS calls), as well as some additional
function  calls required by SQL clients.

Complete the following steps to copy these files to the correct
location:

1. Insert the WSOS2_1  diskette into a floppy drive.

Important

Procedure 1 2 3


Temp. Rev C -



156 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

2. Copy the NETAPI.DLL and NETOEM.DLL files from the \SQL
subdirectory on the diskette to the directory where the SQL front
end executable is located.  For example, if you are using a
Microsoft/Sybase SQL, the Novell files  w ould need to be copied
to the SQL\BINP subdirectory where SAF.EXE  is located.  You can
copy the files by dragging them on the desktop or by typing a
command such as the following at an OS/2 command line:

COPY A:\SQL\*.DLL C:\SQL\BINP Be sure to copy the files from the
\SQL directory, since there is also a  NET API.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 Server
support  that are required for SQL clients. However, this
NETAPI.DLL does not  provide full LAN Server support. An
application which assumes full LAN  Server support if it finds any
LAN Server calls may not run properly.

3. Open your CONFIG.SYS file in a text editor.

4. Type a dot and a semicolon as the first entry in the LIBPATH
statement:

.; For example, the first part of your LIBPATH might read:

LIBPATH=.;C:\OS2\DLL;C:\; . . . The dot and semicolon tell OS/2 to
look for Dynamic Link Libraries  (DLLs) in the current directory
first.

5. Save and exit the CONFIG.SYS file.

6. Use the OS/2 "Shutdown" feature to reboot your computer.  When
you execute the SAF.EXE, OS/2 will then use the NETAPI.DLL in  the
same directory.

Warning


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 157

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Setting Up Named Pipes for DOS and Windows

This section applies to virtual DOS and Windows sessions only. See
the  NetWare Workstation for DOS and Windows to set up Named Pipes
on an  actual DOS or Windows workstation.

Virtual DOS and Windows sessions can function as Named Pipes
clients; they  cannot function as Named Pipes servers.

If you've met the following prerequisites, you automatically have
Named Pipes  support for virtual DOS sessions: o Enable IPX
support for virtual sessions. Chapter 3, "Network  Access From
Virtual DOS and Windows" explains how to do this.  o Enable Named
Pipes support for OS/2 sessions. "Setting Up  Named Pipes for
OS/2" on page149 explains how to do this.

Do not load the Named Pipes extender in virtual DOS and Windows
sessions.

If you want Named Pipes support in any of the following
situations, you must  also see the sections shown:

If you want Named Pipes for Go to

Virtual Windows  sessions "For Virtual Windows Named Pipes
Clients"  on page158

Sessions with the  DOS_ST AR TUP_DRIVE  feature

"For Sessions with  DOS_ST AR TUP_DRIVE Set" on page158

Checklist

Important


Temp. Rev C -



158 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

For Virtual Windows Named Pipes Clients

Copy the NETAPI.DLL file from the \WINDOWS.NP subdirectory on the
WSOS2_1 diskette to one of the following locations on your hard
disk:

u The \OS2\MDOS\WINOS2 subdirectory (since this directory contains
WINOS2.COM)

u The \OS2\MDOS\WINOS2\SYSTEM subdirectory (since this directory
contains the Windows KERNEL.EXE)

u The directory of the application that runs Named Pipes

This NETAPI.DLL is a Windows file, not an OS/2 file, and is
provided specifically  for Named Pipes Windows clients. Do not
copy it over the NETAPI.DLL in the  \NETWARE directory.

"Protocol Requests from DOS/Windows Sessions" on page313 explains
how  Named Pipes support works for virtual DOS and Windows
clients.

For Sessions with DOS_STAR TUP_DRIVE Set

Sessions set with DOS_STAR TUP_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_STAR TUP_DRIVE feature.

If you are using DOS_STAR TUP_DRIVE to boot a session, you do not
need  to get your Named Pipes support from Novell. Instead, you
can load the  FSFILTER.SYS driver provided by OS/2.

Load the FSFILTER.SYS driver in the CONFIG.SYS file for the
DOS_ST AR TUP_DRIVE session. (The CONFIG.SYS file is bound into
the  image file you boot the session from. See your OS/2
documentation.)

Warning


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 159

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



To load the FSFILTER.SYS driver, do the following:

1. Open the CONFIG.SYS file for the DOS_STAR TUP_DRIVE  session in
a text editor.

2. On a new line in the file, type a line to load FSFILTER.SYS .
For example, you might type:

DEVICE=C:\OS2\MDOS\FSFILTER.SYS

3. Save and exit the CONFIG.SYS file.

See your OS/2 documentation for more information about loading
FSFILTER.SYS in your CONFIG.SYS.

Do not load the Novell Named Pipes Extender for DOS in the  DOS_ST
AR TUP_DRIVE session. It will conflict with the OS/2 Named Pipes
driver.

Procedure 1 2 3

Important


Temp. Rev C -



160 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Setting Up NetBIOS for OS/2

Novell NetWare Requester 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.

This chapter explains how to set up Novell's NetBIOS driver. It
also explains  how to configure your workstation for NetBIOS when
you also have IBM's  Extended Services or LAN Services NetBIOS
installed.

"Protocol Requests from OS/2 Sessions" on page301 explains more
about  how Novell's NetBIOS driver works.

Determining Which NetBIOS Drivers to Set Up

Use this section to determine whether your application needs
access to the  Novell NETBIOS.SYS driver, the IBM NETBEUI.OS2
driver, or both.

Which drivers your application can access depends on

u Whether you have Extended Services or LAN Services installed on
your  Workstation, and

u The interface used by your application.

Topics Page

Determining Which NetBIOS Drivers to Set Up 160

Setting Up the Novell NetBIOS Driver 165

Configuring NETBIOS.OS2 with PROTOCOL.INI 172

Configuring NETWKSTA.200 with IBMLAN.INI 177


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 161

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Your Installed IBM Software

NetBIOS support is provided with

u Extended Services Extended Services NetBIOS support is included
in the LAPS programs.  NetBIOS-related pieces of LAPS are

u NET API.DLL

A CSNETB.DLL

u NETBIOS.OS2

u NETBEUI.OS2

u LANPDD, and

u LANVDD

u LAN Services LAN Services NetBIOS support is included in the
LAPS program and in  NETWKST A.200.

Identify whether you have Extended Services, LAN Services, or
both. Then go  to the next section.

When this section refers to the NetBIOS support available with a
particular 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.

How ever, 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 actually have the NetBIOS support usually
provided by  Extended Services without having the whole Extended
Services product. Work  with IBM to resolve any questions about
what IBM files you have relating to  NetBIOS support.

Note


Temp. Rev C -



162 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Your Application's Interface

OS/2 NetBIOS applications use Dynamic Link Libraries (DLLs) to
interface  with NetBIOS drivers. Which DLL your application uses
depends on which  NetBIOS interface standard your application
follows:

A CSNETB.DLL  This is IBM's NetBIOS 3.0 (NB30) interface. The NB30
interface was  introduced by IBM in OS/2 v2.0, so applications
written before OS/2 v2.0  most likely cannot use it.

u The NETAPI.DLL  This is the original OS/2 NetBIOS Submit
interface. This interface was  supported by LAN Manager and LAN
Server before OS/2 v2.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.

See the documentation for your application to determine which
NetBIOS  interface it uses, then follow the flow charts in Figure
9-4 or Figure 9-5 to see

u Whether the IBM or Novell NetBIOS driver can be accessed by your
application, and

u Where to find instructions on setting up the drivers.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 163

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 9-4 Determine what NetBIOS support you have for  NetBIOS
3.0 (NB30) applications

Do you* have NetWare* Requester?

yes

Do* you have* LAPS with Extended* Services or LAN* Services?

no

Application can use* both IBM and Novell* NetBIOS drivers.* See
Configuring* NETBIOS.OS2 with* PROTOCOL.INI.

No NetBIOS* support for* application.* Get LAPS.

START NetBIOS 3.0* (NB30)* application

Application* can use IBM * NETBEUI.OS2* driver.* See LAPS*
documentation.

yes no


Temp. Rev C -



164 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 9-5 Determine what NetBIOS support you have for  NetBIOS
Submit applications

Do you* have NetWare* Requester?

yes

Do you* have NetWare* Requester?

Do* you have* LAN* Services?

no

Application can use* both IBM and Novell* NetBIOS drivers.* See
Configuring* NETWKSTA.200 with* IBMLAN.INI.

No NetBIOS* support for* application.* Get LAN Services*  or*
NetWare Requester.

Application can use* Novell NetBIOS.SYS* driver with Novell*
NETAPI.DLL.* See Setting Up the* Novell NetBIOS driver.

START NetBIOS* Submit* application

Application* can use IBM * NETBEUI.OS2* driver.* See* LAN
Services* documentation.

yes

Do you* have Extended* Services?

yes Application can use* Novell NetBIOS.SYS* driver with Extended*
Services NETAPI.DLL.* See Setting Up the* Novell NetBIOS driver.

no

no

yesno


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 165

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Setting Up the Novell NetBIOS Driver

Do this section only if you were directed here from the flow chart
in Figure 9- 5 because you

u Have a NetBIOS Submit application

u Have Extended Services

u Do not have LAN Services

As Figure 9-6 shows, the Novell NetBIOS driver interfaces with
Novell's  NET API.DLL file when you do not have Extended Services.

Figure 9-6 NetBIOS Requests  through Novell's  NetBIOS Driver

NETBIOS

OS/2 applications that make NetBIOS Submit calls

NETAPI.DLL (Novell)

IPX


Temp. Rev C -



166 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

As Figure 9-6 shows, if you are using 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.

Figure 9-7  NetBIOS Requests  through Novell's  NetBIOS Driver
with  Extended Services  installed

Follow the procedures in "Installing the Driver" on page167 to use
the Novell  NetBIOS driver. The procedures apply whether or not
you have Extended  Services.

If you are using 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.

NETBIOS.SYS (Novell)

OS/2 applications that make NetBIOS Submit calls

NETAPI.DLL (ES)

IPX

NETSUB.DLL (Novell)

Important


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 167

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Installing the Driver

Prerequisites o Install Extended Services if you have it. See the
IBM  documentation for Extended Services.  o Install your NetBIOS
application. See the documentation for your  application.

Procedures

You can install the NetWare Requester from this procedure.

You must install the Novell NetBIOS driver on each computer that
will use  Novell NetBIOS on the network.

1. Start the NetWare Requester installation program.  If the
Requester is not installed, you can start the program from your
WSOS2_1 diskette. Type INSTALL. You can install the Requester at
the  same time as you install NetBIOS.  If the Requester 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 the Requester is installed: 4a. If the Requester is
not installed, select "Edit CONFIG.SYS and  Copy All Files . . . "
and choose "OK." 4b. If the Requester is already 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 . . ."

Checklist

Note

Procedure 1 2 3


Temp. Rev C -



168 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 the Requester, the "Copy Requester
Files" screen appears. Continue with Step 10.  If you have
previously installed the Requester, the main installation menu
appears. Go to "Configuring the Driver" on page168.

10.Choose "Copy" and follow the screens to finish installing the
Requester.  When the main menu returns, go to "Configuring the
Driver" on page168.

Configuring the Driver

Novell's NetBIOS driver comes with default configuration settings.
You may  w ant to customize the configuration. Follow the
instructions below to

u Determine whether you need to change the default configuration
for  NetWare NetBIOS, and

u Change the configuration if necessary.

You can change the configuration to manage such features as

u Names

u Sessions

u Commands

If you do not know what NetBIOS names, sessions, and commands are,
see the  documentation for your NetBIOS application.

Prerequisite o The NetWare Requester for OS/2 must be installed.
If it is not  installed, do the steps in "Installing the Driver"
on page167.  Checklist


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 169

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

1. Start the NetWare Requester Installation program.  The program
may already be running if you just installed the NetBIOS  driver.
If the program is not 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 the NET.CFG file and choose "Edit." The
"Edit NET.CFG" window appears. See Figure 9-8. 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 following
keys:  Table 9-2 Key definitions for the NET.CFG window

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 (text will  reappear the next time  you refresh the
window) <Shift><Delete>

Paste text <Shift><Insert>

Delete text (deleted text  cannot be pasted) <Ctrl><Delete>

Procedure 1 2 3


Temp. Rev C -



170 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 9-8 Editing NET.CFG for  NetBIOS

4. Select "NetWare NetBIOS" from the "NET.CFG Options" box on the
left of your screen.

     Read online * help for the topic* you selected.

     Select the type* of information you* want to see.

        Select a * NET.CFG option, * setting, or topic.

    Type NET.CFG*     options and*     settings here.

       Save your* configuration or* change your mind.

1 4

2 3

5


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 171

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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) If you decide to
change the configuration, type the  configur ation lines (as shown
in the "Usage" help window) into  the "Current NET.CFG File
Contents" box. 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 the "Usage" button.  Repeat steps 5a through 5c for
each setting.

6. Choose "Save."

7. Exit the NetWare Requester 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: u "Configuring NETBIOS.OS2 with
PROTOCOL.INI" on page172 u "Configuring NETWKSTA.200 with
IBMLAN.INI" on page177 If you do not know which of these two
sections to read, go to  "Determining Which NetBIOS Drivers to Set
Up" on page160.

Important


Temp. Rev C -



172 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Configuring NETBIOS.OS2 with PROTOCOL.INI

Do this section only if you were directed here from the flow chart
in Figure 9- 4 because you

u Have the LAPS program, and

u Have a NetBIOS 3.0 application.

As Figure 9-9 shows, IBM's ACSNETB.DLL interfaces with
NETBIOS.OS2,  also provided by IBM. NETBIOS.OS2 can be configured
to pass NetBIOS  requests to either

u NETBEUI.OS2, IBM's NetBIOS driver, or

u 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 talks only to NETBEUI.OS2.

Figure 9-9 NetBIOS Requests  through  NETBIOS .OS2

ACSNETB.DLL (IBM)

NETBIOS.OS2 (IBM) NETBIOS (Novell)

OS/2 applications that make NB30 NetBIOS calls

NETBEUI (IBM) IPX


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 173

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Prerequisites o Install Extended Services with NetBIOS support.
Verify that you  can get a NetBIOS connection. o Install LAN
Services (NetBIOS support is installed by default).  Verify that
you can get a LAN connection.  o Do the steps in "Setting Up the
Novell NetBIOS Driver" on page165  to install the NetWare
Requester with the Novell NetBIOS driver.

Procedures

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.  For example, to
use the OS/2 System Editor at the command line, you  w ould type:

E C:\IBMCOM\PROTOCOL.INI PROTOCOL.INI is located in the \IBMCOM
directory.

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.

Checklist

Procedure 1 2 3


Temp. Rev C -



174 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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.  When 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 will also need to
add a line for the IBM network.  Each line you add should look
similar to the following

ADAPTER a = b,c,sessions ,commands ,names If you have existing
ADAPTER lines, leave them.  Replace the variables in the line with
values shown in the following chart: Table 9-3 Paremeters for
defining dual NetBIOS in PROTOCOL.INI

Variable Meaning of variable

AD APTER 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:

u Do not use the same number that is used in any other adapter
statements.  Each adapter number can only be defined to one
NetBIOS driver.

u Do not skip adapter numbers. For example, if you have an
existing 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.

u Replace b with IPXNB$ for the Novell NetBIOS driver.

u Replace b with NETBEUI$ for the IBM NetBIOS driver.

Note

Note


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 175

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



c Replace c with a number from 0 to 3. This number is the virtual
adapter number  used by the target NetBIOS driver.

u For Novell's NetBIOS driver, always specify 0.

u For IBM's NetBIOS driver, specify whichever virtual adapter you
want used.  See the Extended Services documentation on NETBEUI.OS2
for more  information on how it uses virtual adapters.

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.  No vell's NetBIOS driver
is configured with the sessions setting in the NET.CFG file.  The
number of sessions actually allocated to the application is either
the NET.CFG  value or the value on this line of the PROTOCOL.INI,
whichever is low est.  For example, if you set 64 sessions in
NET.CFG, and the value on this line is only  48, NetBIOS 3.0
applications will only be able to use 48 sessions.  If you set 30
sessions in NET.CFG and the value on this line is 50, NetBIOS 3.0
applications will only be able to 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.  No vell's
NetBIOS driver is configured with the commands setting in the
NET.CFG  file . The number of commands actually 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 128 commands in NET.CFG, and the value on this line is
only 100, the application will only be able 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.

Table 9-3 continued Paremeters for defining dual NetBIOS in
PROTOCOL.INI

Variable Meaning of variable


Temp. Rev C -



176 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 will be  able to use each driver you defined with an
Adapter line.

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.  No vell's NetBIOS driver is
configured with the names setting in the NET.CFG file.  The number
of names actually 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 128 names in
NET.CFG, and the value on this line is only  100, the application
will only be able to use 100 names.  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.

Table 9-3 continued Paremeters for defining dual NetBIOS in
PROTOCOL.INI

Variable Meaning of variable


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 177

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Configuring NETWKST A.200 with IBMLAN.INI

Do this section only if you were directed here from the flow chart
on Figure 9- 5 because you

u Have a NetBIOS Submit application, and

u Have LAN Services

As Figure 9-10 shows, NETAPI.DLL interfaces with IBM's NETWKST
A.200.  The NETAPI.DLL file used is the one provided with LAN
Services. This  happens by default, since the \MUGLIB\DLL
directory which stores the LAN  Services NETAPI.DLL comes earlier
in the path than the \NETWARE  directory which contains the
NetWare Requester NETAPI.DLL.

NETWKST A.200 can be configured to pass NetBIOS requests to either

u NETBEUI.OS2, IBM's NetBIOS driver, or

u 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.

Figure 9-10 NetBIOS Requests  through  NETWKST A.200

NETWKSTA.200 (IBM) NETBIOS (Novell)

OS/2 applications that make NetBIOS Submit calls

NETAPI.DLL (LS)

NETBEUI (IBM) IPX


Temp. Rev C -



178 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Prerequisites o Install Extended Services if you have it. o
Install LAN Services (NetBIOS support is installed by default).
Verify that you can get a LAN connection.  o Do the steps in
"Setting Up the Novell NetBIOS Driver" on page165  to install the
NetWare Requester with the Novell NetBIOS driver.

Procedures

1. Open the IBMLAN.INI file in a text editor.  For example, to use
the OS/2 System Editor at the command line, you  w ould type:

E C:\IBMLAN\IBMLAN.INI IBMLAN.INI is located in the \IBMLAN
directory on your boot drive.

Checklist

Procedure 1 2 3


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 179

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



2. Find the following line:

[networks] Underneath the [networks] line, you should see a line
similar to the  following defining a particular network as the one
using IBM's NetBIOS  driver, NETBEUI.OS2:

net1 = NETBEUI$,1,LM10,32,50,14 This 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 look like the following:

net2 = NETBEUI$,1,LM10,32,50,14 You must change the IBM driver
because the Novell driver has to be  defined to net1 in order for
dual NetBIOS to work.

4. Underneath any existing net statements, type a line assigning
network number 1 to the Novell NetBIOS driver.  A network for IBM
NetBIOS is defined by default in both LAN Requester  and LAN
Server. If you want NetBIOS Submit applications to only use  No
vell'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 following table:

Note


Temp. Rev C -



180 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Table 9-4 Parameters for defining dual NetBIOS in IBMLAN.INI

Variable Meaning of variable

NET NET is a standard key word for NETWKST A.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:

u Use 1 for the Novell NetBIOS driver and 2 for the IBM NetBIOS
driver.

u 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.

u Do not skip numbers. For example, if you have an existing net
statement that  uses NET1, use NET2 for your next statement.

b Replace b with the device name for the NetBIOS driver. NETWKST
A.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 1 to 4. This number is the virtual
adapter number  used by the target NetBIOS driver to receive
NetBIOS requests from  NETWKST A.200.

u For Novell's NetBIOS driver, always specify 1.

u For IBM's NetBIOS driver, specify whichever virtual adapter you
want used.  See the Extended Services documentation on NETBEUI.OS2
for more  information on how it uses virtual adapters.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 181

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 NETWKST A.200 and Novell's NetBIOS driver.  No vell's
NetBIOS driver is configured with the sessions setting in the
NET.CFG file.  The number of sessions 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
64 sessions in NET.CFG, and the value on this line is only  48,
the application will only be able to use 48 sessions.  If you set
30 sessions in NET.CFG and the value on this line is 50, the
application  will only be able to 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 NETWKST A.200 and Novell's NetBIOS  driver.  No vell's
NetBIOS driver is configured with the names setting in the NET.CFG
file.  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 will only be able 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
NETWKST A.200 and Novell's NetBIOS driver.  No vell's NetBIOS
driver is configured with the names setting in the NET.CFG file.
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 will only be able to use 100 names.  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.

Table 9-4 continued Parameters for defining dual NetBIOS in
IBMLAN.INI

Variable Meaning of variable


Temp. Rev C -



182 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

For example, to enable applications to use both the Novell or the
IBM  NetBIOS driver, 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 = net a 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 what network to send NetBIOS calls
for  servers on.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 183

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



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 = net a 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 will be  able to use both the Novell and the IBM
NetBIOS driver.

NETWKST A.200 must be started before any kind of NetBIOS
connection will  w ork. You can start it automatically on booting
or with the LAN Services  NETST AR T command at a command line.
See your LAN Services  documentation for more information.

Note


Temp. Rev C -



184 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Setting Up NetBIOS for DOS and Windows

This section applies to virtual DOS and Windows sessions under
OS/2 only.  See the NetWare Workstation for DOS and Windows
documentation to set up  NetBIOS on an actual DOS or Windows
workstation.

NetWare Requester 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 the NETBIOS.EXE program in a virtual session, you
will not  be able to get NetBIOS connections from your OS/2
sessions or any other DOS  and Windows sessions until the
NETBIOS.EXE program is unloaded. You will  only have one NetBIOS
connection from a single virtual session. This is true  even if
your OS/2 NetBIOS drivers appears to be loaded.


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 185

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



IBM LAPS NetBIOS Support

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.

Using NetWare NetBIOS Support for a Single DOS Session

As Figure 9-11 shows, NetWare NetBIOS support for a single DOS
session  goes through NETBIOS.EXE and VIPX.

When using NetWare NetBIOS for a single DOS session, you cannot
have  NetBIOS connections from any other DOS, Windows, or OS/2
sessions. You  must disable NetBIOS support for OS/2 sessions.

To use . . . Go to . . .

NetWare Requester  non-virtualized  NetBIOS support

"Using NetWare NetBIOS Support for a  Single DOS Session" on
page185

LAPS virtualized  NetBIOS support "Using LAPS NetBIOS Support for
Virtual  Sessions" on page187

Important


Temp. Rev C -



186 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 9-11 No vell NetBIOS Support for a virtual session

Prerequisites o Enable IPX support for virtual sessions. "Network
Access From  Virtual DOS and Windows" on page33 explains how to do
this.  o Disable NetBIOS support for OS/2 sessions. Novell's
NetBIOS  solution for DOS boxes is not virtual and so does not
allow any  other NetBIOS drivers to be running at the same time.
Disable  NetBIOS support by running the NetWare Requester
installation  program and deselecting "NetBIOS Emulation for
OS/2." "Installing  the Driver" on page167 explains how to run the
installation  program.

IPX

DOSOS/2

VIPX

NETBIOS.EXE

DOS/Windows application

Checklist


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 187

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Procedures

Follow the instructions in the NetWare Workstation for DOS and
Windows  manual. Use that documentation to

u Load NETBIOS.EXE in a single DOS session.

u Configure NetWare NetBIOS for DOS if necessary.

Using LAPS NetBIOS Support for Virtual Sessions

As Figure 9-12 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.  Figure
9-12 LAPS NetBIOS Support for Virtual Sessions

LAPS NetBIOS support follows the NetBIOS 3.0 (NB30) standard. You
can  run NetBIOS applications in a virtual session even if those
applications are not  NB30 conformant. However, the need for
increasing resources in a session is  more likely when running
non-NB30 applications.

Virtual DOSOS/2

LANVDD.OS2 (IBM)

DOS applications that make NetBIOS calls

LANPDD.OS2 (IBM)

NETBIOS (Novell)NETBEUI (IBM)

NETBIOS.OS2 (IBM)


Temp. Rev C -



188 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Avoiding Resource Errors

As you can see in Figure 9-12, your virtualized NetBIOS sessions
can be  supported by Novell's OS/2 NETBIOS.SYS driver or Extended
Services's  OS/2 NETBEUI.OS2 driver or both.

When virtual sessions are supported by Novell's OS/2 NetBIOS
driver, you  must be aw are of a potential resource limitation.

If you have previously folloWed the steps in the "Configuring
NETBIOS.OS2 with  PROTOCOL.INI" on page172, then 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, you
may find that  all of the resources in one of the NetBIOS
components get reserved and  additional applications will not run.
You will see a resource error when you try  and make NetBIOS
connections.

You can minimize the possibility that NetBIOS will run out of
resources by  doing both or either of the following:

u Whenever you're using virtual NetBIOS connections, increase the
default  resources allowed for the NETBIOS driver in NET.CFG.
"Configuring the Driver" on page168 explains how to increase the
defaults for the OS/2 NetBIOS driver.

u Explicitly specify the resources consumed for each virtual
session you  use.  "Procedures" on page189 explains how to
explicitly specify resources.

Note


Temp. Rev C -



Setting Up Named Pipes and NetBIOS Protocols 189

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Prerequisites o Install Extended Services with NetBIOS support.
See the Extended  Services documentation. o Install LAN Services
if you have it. See the LAN Services  documentation.  o Install
the NetWare Requester with NetBIOS support. "Setting Up  the
Novell NetBIOS Driver" on page165 explains how to do this.  o
Configure NETBIOS .OS2 to use both the Novell and IBM drivers.
"Configuring NETBIOS.OS2 with PROTOCOL.INI" on page172  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.

1. Open the virtual session.

2. Execute the LTSVCFG.COM prog ram with the command line
parameters you need.  For example, you might type the following to
set the number of NetBIOS  commands to 12:

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.

Checklist

Procedure 1 2 3


Temp. Rev C -



190 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

You cannot set the parameters for LTSVCFG.COM to amounts higher
than  the amounts currently 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.

Important


Temp. Rev C -



Backing Up Your OS/2 Workstation  191

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

chapter 10 Bac king Up Your OS/2 Workstation

The system administrator or backup administrator 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, SBA CKUP 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 Requester for OS/2. An icon for the TSA_OS2
is placed in the Novell  group on your desktop.

With the TSA_OS2 program, you can specify:

u Which users on the network can access your hard drive

u What password they must type in the backup program before
accessing  your hard drive

u Which drives on the hard drive can be backed up

Chapter 8, "Backing Up and Restoring Data" of Supervising the
Network  explains more about backing up workstations and servers.

Topic Page

Starting the TSA_OS2 Manually 192

Starting the TSA_OS2 Automatically 194

Setting Up Your TSA_OS2.CFG File 195


Temp. Rev C -



192 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Starting the TSA_OS2 Manually

This section explains how to start TSA_OS2 manually by choosing
its icon on  your desktop. "Starting the TSA_OS2 Automatically" on
page 194 explains  how to start the TSA_OS2 automatically each
time you boot your workstation.

Prerequisites o Load the TSA_OS2.NLM on the server. See Chapter 8,
"Backing  Up and Restoring Data" of Supervising the Network. o
Install the NetWare Requester. See Chapter 3, "Installing a
NetWare Workstation" of Workstation Basics and Installation.

Procedures

1. Choose the "Novell" icon on your OS/2 desktop. The "Novell"
window appears.

2. From the "Novell" window on your desktop, choose the icon for
the  TSA_OS2.EXE program. The TSA_OS2 main window appears. See
Figure 10-1.

Checklist

Procedure 1 2 3


Temp. Rev C -



Backing Up Your OS/2 Workstation  193

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



Figure 10-1 The TSA_OS2 main  window

3. Choose the features you want from the menu bar. Choose "Help"
or press <F1> for more information.


Temp. Rev C -



194 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Starting the TSA_OS2 Automatically

You can set up the TSA_OS2 program to start up automatically each
time you  boot your machine. To do this, you need to

u Place your TSA_OS2 icon in the "Startup" folder This section
explains how to put the icon in the "Startup" folder.

u Set up your TSA_OS2.CFG file  "Setting Up Your TSA_OS2.CFG File"
on page 195 explains how to use  a TSA_OS2.CFG file.

Prerequisites o Load the TSA_OS2.NLM on the server. See Chapter 8,
"Backing  Up and Restoring Data" of Supervising the Network. o
Install the NetWare Requester. See Chapter 3, "Installing a
NetWare Workstation" of Workstation Basics and Installation.

Instructions

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" window into the
"Startup" folder.  Whenever you reboot your machine, the TSA_OS2
program will start  automatically. If you have a TSA_OS2.CFG file
set up, that file will be  read each time the TSA_OS2 program
starts.

Checklist

Procedure 1 2 3


Temp. Rev C -



Backing Up Your OS/2 Workstation  195

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993



If backups at your site are normally done after hours, remember to
leave  the OS/2 workstations turned on or the backup administrator
will not be  able to access the hard drive. Setting Up Your
TSA_OS2.CFG File

You can create a text file called TSA_OS2.CFG to store settings
for the  TSA_OS2 program. These settings are automatically read by
the TSA_OS2  program each time the program starts up. Table 10-1
lists the parameters you  can type in the configuration file.
Table 10-1  List of TSA_OS2.CFG parameters

Parameter Description Example

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  passw ord, simply specify it on the same  line as
the username .  The username must be one that is  defined on the
network. The passw ord is  unique to your workstation, not the
same  passw ord the user types to access the  network. If you
specify a passw ord, the  backup administrator will have to type
that passw ord in the backup program.

UserName NANCY or to set a passw ord of NEATO: UserName NANCY NEA
TO

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:

Important


Temp. Rev C -



196 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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.

AutoRegister Automatically register with the Target  Service
Router NLM on the server  whenever your workstation boots. To use
this parameter, you must also 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 will be located in the  root of the directory
where you started  the TSA_OS2.EXE program from.

TempFilesDir C:\TEMP_TSA

Table 10-1  continued List of TSA_OS2.CFG parameters

Parameter Description Example


Temp. Rev C -



Remote-Booting OS/2 Workstations  197

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

chapter 11 Remote-Booting OS/2 Workstations

OS/2 workstations that boot from the network do not need a
workstation hard  disk. Instead, they can run OS/2 and the
Requester from network hard disks.

Remote-booting workstations must have network boards with remote
boot  PROMs attached. Boot PROMs allow workstations to connect to
the network  so that the boot information can be accessed.

Topic Page

Setting Up a Server to Boot Workstations Remotely 198

Installing OS/2 Files for Remote Workstations 200

Installing RIPL Files for Remote Workstations 204

Adding Remote Workstations to the Network 208

Configuring the Requester for Remote Workstations 217


Temp. Rev C -



198 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Setting Up a Server to Boot Workstations Remotely

Creating Users and Granting Access

You have to set up accounts for Remote boot users. Do the
following:

1. Create the RPL User object. RPL is the username each remote
workstation uses to make the initial  connection to the network.
Chapter 1, "Managing NetWare Directory  Services Objects" of
Supervising the Network explains more about  creating users.  Do
not require a passw ord for the RPL User object, or the remote
Workstations will not be able to make the connection. Protect the
account  by granting limited access, as explained in Step3.

2. Create a User object for each user who will use a remote
Workstation.

3. Grant access to the RPL User.  The RPL user needs at least read
and file scan access to u The SYS:RPL2 directory u The
SYS:RPL2\COMPUTER directory and all its subdirectories These
directories are created automatically during remote workstation
installation.

4. Grant access to each remote workstation user. All remote users
need access to  u The SYS:RPL2 directory u The \OS2 and \NETWARE
subdirectories under SYS:RPL2 u Their home directories under
SYS:RPL2\USER These directories are created automatically during
remote workstation  installation.

Procedure 1 2 3

Important


Temp. Rev C -



Remote-Booting OS/2 Workstations  199

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Users should not have access to u Other users' home directories
under SYS:RPL2\USER u The SYS: volume

Supervising the Network explains more about NetWare security and
granting  and prohibiting access.

Since the SYS:RPL2 directory becomes the root of the C: drive for
all remote  users, all remote users require access to this area.
You should not store critical  files in this directory. Instead,
store them in another network directory where  access can be more
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.

To Boot Workstations with Novell Boards

You can remote boot OS/2 workstations that have any of the
following Novell  boards:

u NE1000

u NE2000

u NE2

To remote boot OS/2 workstations with these boards, you do not
need to load  any RIPL loadable modules (NLMs) on the server.

Follow the instructions in the rest of this chapter.

Warning


Temp. Rev C -



200 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

To Boot Workstations with IBM Boards

You can remote boot workstations that have either of the following
IBM  boards:

u PCN2L

u TOKEN

To set up the server to remote boot this type of workstation, you
must load and  bind the RPL loadable module on each server by
doing the following:

1. At the server console, type

LOAD RPL

2. Then type

BIND RPL TO  driver Replace driver with the name of an LAN driver
in your server. You can  bind to more than one driver by
specifying additional bind statements. For more information about
the RPL loadable module, see NetWare  Utilities Reference manual.
Installing OS/2 Files for Remote Workstations

Complete the steps in this section if you are:

u Setting up remote workstations for the first time.

u Upgrading existing remote workstations from OS/2 v1.3 to OS/2
v2.0.

Adding a server to the network where remote workstations attach
(only for  the server you add).

Don't do the steps in this section every time you want to add a
remote  Workstation to the network. To add a remote workstation,
see page 208.

Procedure 1 2 3

Important


Temp. Rev C -



Remote-Booting OS/2 Workstations  201

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Prerequisites

For the Workstation You're Installing From o Make sure OS/2 is
installed on the workstation C: drive. It must be  drive C:. o
Install the NetWare Requester in the \NETWARE directory o Make
sure the workstation connected to a server when it booted. o Mo ve
to backup diskettes or delete all personal files in the C: drive.
(The installation program copies all files from the C: drive to
the  server.) o Make sure the CONFIG.SYS file only loads programs
that remote  Workstations will need. o Obtain an OS/2 installation
diskette if you are setting up PS/2  computers as remote
workstations. If you are using PS/2  computers as remote
workstations, the program must copy some  files from this
diskette.

For the NetWare Servers Where You're Installing Remote Boot
Support o Make sure you have the Supervisor object right to the
NetWare  Server object. o Make sure enough disk space is free on
each server where you  w ant to install. You need to allow 30 MB
for OS/2 plus enough  space for whatever files are on the
workstation hard drive you're  installing from. o Do the steps in
"Setting Up a Server to Boot Workstations  Remotely" on page198.

Checklist

Checklist


Temp. Rev C -



202 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Procedures

All remote files must be installed on each server on the network.
If you have  servers where you don't want to install remote
workstation support, you can set  the following paramter and the
servers will not respond to remote PROMs:

SET RESPOND TO GET NEAREST SERVER = OFF

You can type this command at the server console or put it in your
server  AUT OEXEC .NCF file. If you set this parameter, the server
will not be able to  boot remote workstations, but you will also
not have to install the files for remote  Workstations support on
that server. See Utilities Reference for more  information about
the SET command.

We recommend that you establish a separate physical network for
remote OS/2  users. Put as few servers on this network as you need
to support the number of  remote users you have. If you want,
connect this network to other networks at  your site through
routers. This setup saves time and server space.

1. On a workstation with the NetWare Requester installed, open the
NetWare Requester for OS/2 installation program.  Figure 11-1
shows how to open the program.

Figure 11-1 Opening the  installation program  from the Novell
group

Important

Procedure 1 2 3

1  Double-click here. 2  Then here.


Temp. Rev C -



Remote-Booting OS/2 Workstations  203

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

The "NetWare Requester for OS/2 Installation Utility" window
appears.  Use the online help as necessary.

2. Choose "Remote workstations. . ." from the "Installation" menu.
The "Install Requester for Remote Workstations" window appears.

3. Select "Only Copy OS/2 Files . . . " and choose "OK" You can
choose other actions from the "Remote Workstation Installation"
screen if you want.

4. Choose the server(s) you want the files copied to. You will be
attached to the server or servers you select. It must be installed
on all servers on local net (cable segment with same address).

5. Choose "OK."  All OS/2 and NetWare Requester files are copied
to the servers.

6. After the files are copied, do the following.

If you want to . . . Do this . . .

Copy remote boot files Without exiting the installation program,
go  to page 204.

Add remote  Workstations to the  network

Without exiting the installation program, go  to page 208.

Configure the Requester  for remote workstations Without exiting
the installation program, go  to page 217.

Exit the installation  program Choose "Close" from the system menu
in  the upper left corner of the Installation  window.


Temp. Rev C -



204 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

What Happens When You Install OS/2 Files

A SYS:RPL2 directory is created on each server you selected.  All
remote workstations use this directory as if it is their local
root drive.  Once remote users log in to the network, they can
access all information  in this directory.  Since the SYS:RPL2
directory is actually on the server and not on a local  disk,
NetWare security still applies. For example, you can limit remote
users' access to specific directories and files. "Setting Up a
Server to Boot  Workstations Remotely" on page198 explains more
about securing the  SYS:RPL2 directory and its subdirectories.
OS/2 v1.3 remote workstations used a directory called SYS:RPL.
This  directory is not erased when the SYS:RPL2 directory is
created. OS/2 v1.3  remote workstations and OS/2 v2.01
workstations can both boot on the  same network.

u Every file from the workstation drive C: is copied to the
SYS:RPL2  directory on the server.  Installing RIPL Files for
Remote Workstations

Complete the steps in this section if you are:

u Setting up remote workstations for the first time.

u Upgrading existing remote workstations from OS/2 v1.3 to OS/2
v2.0.

Adding a server to the network where remote workstations attach
(only for  the server you add).

Don't do the steps in this section every time you want to add a
remote  Workstation to the network. To add a remote workstation,
see page 208.

Prerequisites

For the Workstation You're Installing From o Make sure the NetWare
Requester is installed. o Make sure the workstation connected to a
server when it booted.

Note

Checklist


Temp. Rev C -



Remote-Booting OS/2 Workstations  205

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

For the NetWare servers where you're installing remote boot
support o Make sure you have the Supervisor object right to the
NetWare  server object. o Do the steps in "Setting Up a Server to
Boot Workstations  Remotely" on page198. o Do the steps in
"Installing OS/2 Files for Remote Workstations" on  page 200.

Procedures

All remote files must be installed on each server on the network.
There is no  w ay to specify which server a remote workstation
will initially establish a  connection with.

We recommend that you establish a separate physical network for
remote OS/2  users. Put as few servers on this network as you need
to support the number of  remote users you have. If you want,
connect this network to other networks at  your site through
routers. This setup saves time and server space.

1. On a workstation with the NetWare Requester installed, open the
NetWare Requester for OS/2 installation program.  Figure 11-2
shows how to open the program.

Checklist

Important

Procedure 1 2 3


Temp. Rev C -



206 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Figure 11-2 Opening the  installation program  from the Novell
group

The "NetWare Requester for OS/2 Installation Utility" window
appears.  Use the online help as necessary.

2. Choose "Remote workstations. . ." from the "Installation" menu.
The "Install Requester for Remote Workstations" window appears.

3. Choose "Only Copy RIPL Files . . ." You can choose other
actions from the "Remote Workstation Installation"  screen if you
want.

4. Choose the server(s) you want the RIPL files copied to. You
will be attached to the server or servers you select. It must be
installed  on all servers on local net (cable segment with same
address)

5. Choose "OK."  All remote boot files are copied to the servers.

6. After the files are copied, do the following.

If you want to . . . Do this . . .

1  Double-click here. 2  Then here.


Temp. Rev C -



Remote-Booting OS/2 Workstations  207

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

What Happens When You Install RIPL Files

When you use the installation program to install remote
workstation support,  the following actions occur.

Directories Are Created

u SYSRPL2 is created if it didn't already exist

u The \USER and \COMPUTER subdirectories are created under
SYS:RPL2 on each server.

For an illustration of the complete directory structure created
when you install  remote workstation support and add remote
workstations, see Figure 11-5 on  page 216.

Add remote workstations  to the network Without exiting the
installation program, go  to page 208.

Configure the Requester  for remote workstations Without exiting
the installation program, go  to page 217.

Exit the installation  program Choose "Close" from the system menu
in  the upper left corner of the Installation  window.


Temp. Rev C -



208 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Files Are Copied

The following remote boot image files are copied to the SYS:LOGIN
directory:

u TOKEN.200

u NE2.200

u NE2000.200

u NE1000.200

u PCN2L.200

These remote boot image files have different names than the remote
boot image  files used to boot OS/2 v1.3. OS/2 v1.3 remote boot
files are also located in the  SYS:LOGIN directory.

The following files are copied to the SYS:RPL2 directory:

u MINI.IFS

u MICR O.IFS Adding Remote Workstations to the Network

Each workstation you will boot from the network must be added to
the remote  boot setup on the network. You identify to each server
the user who will use  that workstation, the node address, and the
network board.

Workstations are added by running the Requester installation
program from a  Workstation that has a hard disk.


Temp. Rev C -



Remote-Booting OS/2 Workstations  209

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Complete the steps in this section on each server if you are:

u Setting up remote workstations for the first time

u Upgrading existing remote workstations from OS/2 v1.3 to OS/2
v2.0

Adding remote workstations to the network

Adding a server to the network (complete the steps on this server
for every  remote workstation currently defined on the other
servers)

Prerequisites

For the Workstation You're Installing From o Make sure the NetWare
Requester is installed.  o Make sure the workstation connected to
a server when it booted.

For Workstations You're Booting Remotely o Make sure each
workstation that will boot remotely has one of the  following
types of network boards installed: NE2, NE2000, NE1000,  or any
IBM-compatible PCN2L or Token-Ring board. o Make sure the matching
remote boot PROMs are installed on each  network board. o Make
sure the workstation is properly cabled to the network. o Make
sure you know the network and node address of the  Workstation
you're booting remotely.

Checklist

Checklist


Temp. Rev C -



210 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Procedures

Whenever possible, use the same type of network board in all
remote  Workstations. This will save you time when installing and
make configuring  remote workstations much easier.

If the installation program is already running, go to Step 4.

1. Start up an OS/2 workstation that has the Requester installed.

2. Open the "Novell" group icon on the desktop.

3. Choose the Install icon in the "Novell-Contents" window.

Figure 11-3 Opening the  Installation program  from the "Novell"
group

The "NetWare Requester for OS/2 Installation Utility" window
appears.

4. Choose "Remote workstations. . ." from the "Installation" menu.
The "Add Remote Workstations" menu appears.

5. Choose "Add remote workstations . . ."

Procedure 1 2 3

1  Double-click here.2  Then here.


Temp. Rev C -



Remote-Booting OS/2 Workstations  211

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

6. Choose servers on which you want to define remote workstations.
For more information, use the online help.

7. Add the workstations you want.  Remote users are easier to
manage if yoAssign only one remote  Workstation to a username. If
you do let one user log in to more than one  Workstation, you can
use the "Logical Name" option to set up each  Workstation's
configuration differently.  Choose "Help" or press <F1> for more
information.

8. Exit the installation program.

To Remote Boot Workstations With Hard Disks

If you want to remote boot 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 C: drive.

Also, you may need to do the following:

u If your hard disk is set to bootable or system (usually because
you have a  version of DOS installed on it), you need to run RPLON
to keep your hard  disk from booting. See "To run RPLON" on
page212.

u 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. See "To Locate SWAPPER.DAT
Locally" on  page212.


Temp. Rev C -



212 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

To run RPLON

1. Insert the WSOS2_1  diskette into a floppy drive of the
workstation  you want to boot remotely.

2. Change to the drive you put the diskette into. For example, for
a diskette in drive A:, type:

CD A:

3. Type:

\RPL\RPLON  <Enter> The RPLON program keeps the hard disk at the
workstation from booting.  To enable the hard disk again, insert
the WSOS2_1 diskette in the drive,  change to that drive, and type
\RPL\RPLOFF.

To Locate SWAPPER.D AT Locally

1. Go to the home directory on the network for the user who will
be  using the remote workstation.  For example, if JOHN will be
using the remote workstation with a hard  drive, go to the
following directory:

SYS:RPL2\USER\JOHN Each user's home directory on the network
contains that users  CONFIG.SYS file and several other OS/2 files.
Figure 11-5  on page 216  shows the complete network directory
structure for remote workstations.

2. In a text editor, open the CONFIG.SYS file.

Procedure 1 2 3

Procedure 1 2 3


Temp. Rev C -



Remote-Booting OS/2 Workstations  213

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

3. In the CONFIG.SYS file, find the line that designates the  SW
APP ATH. You can search for SWAPPATH. The line looks like the
following:

SWAPPATH=C:\OS2\SYSTEM 2048 2048 Remember that to OS/2, the
SYS:RPL2 directory is drive C:.

4. Change the SWAPP ATH line to point to the local hard drive. For
example, to point to the root of a local drive D:

SWAPPATH=D:\ 2048 2048

5. Save and exit the CONFIG.SYS file.  When you boot the remote
workstation, the SWAPPER.DAT will be  stored locally.

What Happens When You Add Remote Workstations

When you add remote workstations to a network, the following
actions occur.

Directories Are Created

If you have not yet installed remote workstation support on the
network, the  SYS:RPL2 and the \USER and \COMPUTER directories are
created on each  server.

The following directories are 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 JAD AMS w ould have a home directory of:
SYS:RPL2\USER\JAD AMS


Temp. Rev C -



214 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

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 was
2223345BBBBB, the node address directory would be:
SYS:RPL2\COMPUTER\223345BB.BBB

A subdirectory containing the Workplace Shell desktop in each
user's  subdirectory. 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 subdirectory.  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 BOO TCONF .SYS file is created in the SYS:LOGIN directory.  If a
BOOTCONF .SYS file already exists (from other installations of
remote workstations), the information for the new workstations is
added  to the beginning of the file.


Temp. Rev C -



Remote-Booting OS/2 Workstations  215

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

This file tells the server which boot image file to use for each
workstation.  The BOOTCONF .SYS file contains lines identifying
which remote  Workstation uses which type of network board. For
example, a line for a  Token-Ring workstation might be as follows:

0xDOC20,1b0276A32222=TOKEN.200 See Figure 11-4 for an explanation
of the lines in the BOOTCONF .SYS  file.

Figure 11-4  Format of  BOO TCONF .SYS file

Files Are Copied

Every file in the \DESKTOP and \SPOOL subdirectories are copied
from the  local drive of the OS/2 workstation to the server.

These files allow remote 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.

The number zero * and the letter x are * the first characters * on
the line.

0xDOC20,1B025322BB11=TOKEN.200

The network* address followed* by a comma* comes next.

The node address * and an equal sign * come next.

The name of the* remote boot image* file is last.


Temp. Rev C -



216 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

This CONFIG.SYS is modified slightly for each user. The line which
loads  HPFS is commented out, and the directory in the SWAPPATH
line is changed.  Also, disk caching is turned off and the ODI
driver is changed to the driver you  selected.

Figure 11-5  shows the complete directory structure that is
created for remote  Workstation support. Figure 11-5 Directory
structure for remote workstation  support

\User

Server

sys:

\OS2 \Computer

\User3

(OS/2 files)

CONFIG.SYS,* OS2SYS.INI,* OS2.INI files

\RPL2

\NetWare

(OS/2 system files)

\User2\User1 \Node3\Node2\Node1

(CONFIG.WSS file) (CONFIG.WSS file)

(Requester files)

\Lab\Office

CONFIG.SYS,* OS2SYS.INI,* OS2.INI files

These are users' home* directories.

These are users' node* address directories.

These are home directories* for a user with a logical name.


Temp. Rev C -



Remote-Booting OS/2 Workstations  217

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993

Configuring the Requester for Remote Workstations

Configure the NetWare Requester for remote workstations by running
the  NetWare Requester installation program and choosing "Remote
workstations .  . ." from the "Configuration" menu. "How to
Configure Your Workstation" on  page55 explains more about
configuring from the installation program.

When you configure remote workstations, the Requester 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 remote
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 the Requester 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

Remember that the SYS:RPL2 directory becomes the root of the C:
drive Note


Temp. Rev C -



218 NetWare Workstation for OS/2 v2.01

NetWare Workstation for OS/2 v2.01  100-001413-001    23 April
1993
