#EDIR DATA#
NetWare Workstation for OS/2DisclaimerNovell®, Inc. makes no representations or warranties with respect to the contents or use of this manual, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.Further, Novell, Inc. makes no representations or warranties with respect to any NetWare software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of NetWare software, at any time, without any obligation to notify any person or entity of such changes.TrademarksBtrieve, DR DOS, EXOS, LANalyzer, NetWare, OnLan/PC, Novell, and the N design are registered trademarks of Novell, Inc.Advanced NetWare, Boot Support Module, BSM, ElectroText, Hardware Specific Module, Hot Fix, HSM, Internetwork Packet Exchange, LAN Service, Link Support Layer, LSL, Media Support Module, MSM, Multiple Link Interface, MLI, Multiple Link Interface Driver, MLID, Multiple Protocol Interface, MPI, NetWare Access Server, NetWare Access Services, NetWare Core Protocol, NCP, NetWare Directory Services, NDS, NetWare DOS Requester, NDR, NetWare Express, NetWare Loadable Module, NLM, NetWare Management Agent, NetWare MultiProtocol Router, NetWare NFS, NetWare Requester, NetWare RPC, NetWare Runtime, Network Support Encyclopedia, NetWare 3270 LAN Workstation, NetWare 3270 LAN Workstation for DOS, NetWare 3270 LAN Workstation for Windows, NLM, NE/2, NE/2-32, NE1000, NE1500T, NE2000, NE2100, NE3200, NE32HUB, Novell Labs, Novell Virtual Terminal, NVT, NTR2000, Open Data-Link Interface, ODI, Packet Burst, RX-Net/2, SFT, Topology Specific Module, TSM, TSA, Transaction Tracking System, TTS, Turbo RX-Net, Virtual Loadable Module, and VLM are trademarks of Novell, Inc.NetWire is a service mark of Novell, Inc.Novell Authorized Reseller is a collective mark of Novell, Inc.3Com and 3+Share are registered trademarks of 3Com Corporation.ARCnet is a registered trademark of Datapoint Corporation.AT&T is a registered trademark of AT&T.Apple, AppleShare, AppleTalk, ImageWriter, LaserWriter, LocalTalk, and Macintosh are registered trademarks of Apple Computer, Inc.Citizen is a registered trademark of Tokei Kabushiki Kaisha.COMPAQ is a registered trademark of Compaq Computer Corporation.CompuServe is a registered trademark of CompuServe, Inc.DDS is a trademark of Sony Corporation.DEC is a trademark of Digital Equipment Corporation.Epson is a registered trademark of Seiko Epson Corporation.GE Information Services is a trademark of General Electric Company, USA, which is not connected with the General Electric Company p.l.c. of England.Hayes is a registered trademark of Hayes Microcomputer Products, Inc.Hewlett-Packard, Deskjet, HP, Laserjet, PCL, and Vectra are registered trademarks of Hewlett-Packard Company.IBM, AT, Micro Channel, NetView, OS/2, ProPrinter, and PS/2 are registered trademarks of International Business Machines Corporation.IBM Operating System/2 Local Area Network Server (LAN Server), Presentation Manager, SAA, and XT are trademarks of International Business Machines Corporation.Intel is a registered trademark of Intel Corporation.LAN Manager and LAN Manager Server are trademarks of Microsoft Corporation.Lotus is a registered trademark of Lotus Development Corporation.Microsoft and MS-DOS are registered trademarks of Microsoft Corporation.NFS is a registered trademark of Sun Microsystems, Inc.Okidata and Microline are registered trademarks of Oki Electric Industry Co., Ltd.Panasonic is a registered trademark of Panasonic Office Automation.Pinwriter, Spinwriter, and NEC are registered trademarks of NEC Corporation.PostScript is a registered trademark of Adobe Systems Incorporated.SDI is a registered trademark of Systems Data, Inc.SQL Server is a trademark of Sybase, Inc.Unicode is a registered trademark of Transoft Ltd.UNIX is a registered trademark of UNIX System Laboratories, Inc., a subsidiary of AT&T.WordPerfect is a registered trademark of WordPerfect Corporation.Xerox Diablo is a registered trademark of Xerox Corporation.Copyright Notices© Copyright 1983-1993 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.Novell, Inc.122 East 1700 SouthProvo, UT 84606U.S.A.Portions of Concepts and Supervising the Network are copyrighted © 1993 Imagery Software, Inc.LBL="0"ID="FM60120"How to Use this ManualBefore using this manual, use the Workstation Basics and Installation manual to install the NetWare Requester for OS/2. This manual explains how to configure your network connection for your OS/2 workstation. Follow the chart on IDREF="FM27431"page xiv to determine which parts of the manual to use. This manual is also accompanied by a quick reference card. This card provides an overview of the installation process and a list of all NET.CFG options.LBL="1"ID="FM27431"How to use this manualFILE="c312q06a.pbm"LBL="1"Information for DOS Users Migrating to OS/2 idxid="w233"book="_idx" docset="nw312" tidref="i1638"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM81702"ODI LAN DriversWIDTH="48"IDREF="FM81702"2IDREF="FM62427"IPXIDREF="FM62427"2IDREF="FM45879"NET.CFG FileIDREF="FM45879"3IDREF="FM74310"Logging InIDREF="FM74310"4IDREF="FM61363"UtilitiesIDREF="FM61363"5IDREF="FM50248"Drive Mappings and Search DrivesIDREF="FM50248"5IDREF="FM74329"Other ProtocolsIDREF="FM55507"6This 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."After you install the NetWare Requester on your workstation, you can connect to a NetWare network and perform basic network tasks.The NetWare Workstation for OS/2 kit also provides the same protocol support that the NetWare Workstation for DOS and Windows kit provides:IPXSPXNamed PipesNetBIOS emulationID="FM81702"ODI LAN Drivers idxid="w234"book="_idx" docset="nw312" tidref="i4799"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 software.OS/2 ODI drivers have the same filenames as DOS ODI drivers, except they have a .SYS extension instead of a .COM extension.OS/2 ODI drivers are loaded in the CONFIG.SYS file, whereas the DOS ODI drivers are loaded in the AUTOEXEC.BAT. (For OS/2, network drivers are always idxid="w235"book="_idx" docset="nw312" tidref="i4799"loaded in CONFIG.SYS. AUTOEXEC.BAT is not used in OS/2. OS/2 requires all device drivers to be loaded in the CONFIG.SYS. file). idxid="w236"book="_idx" docset="nw312" tidref="i1119"ID="FM62427"IPX idxid="w237"book="_idx" docset="nw312" tidref="i3005"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.ID="FM45879"NET.CFG File idxid="w238"book="_idx" docset="nw312" tidref="i4097"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 created and edited with the NetWare Requester installation program. This program contains online help showing the syntax of all options.In DOS, the NET.CFG file is created and edited 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, the NetWare Workstation for DOS and Windows software will use the DOS options. The NetWare Requester for OS/2 ignores the DOS options.ID="FM74310"Logging In idxid="w239"book="_idx" docset="nw312" tidref="i3387"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 for OS/2 does not support a idxid="w240"book="_idx" docset="nw312" tidref="i3187"LASTDRIVE setting in the NET.CFG file.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.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. IDREF="FM75599"Chapter 3, "Network Access From Virtual DOS and Windows"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.ID="FM61363"Utilities idxid="w241"book="_idx" docset="nw312" tidref="i7237"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.ID="FM50248"Drive idxid="w242"book="_idx" docset="nw312" tidref="i3732"Mappings idxid="w243"book="_idx" docset="nw312" tidref="i1723"and Search Drives idxid="w244"book="_idx" docset="nw312" tidref="i6163"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 idxid="w245"book="_idx" docset="nw312" tidref="i7237"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 idxid="w246"book="_idx" docset="nw312" tidref="i7237"The NetWare v4.0 default login script for OS/2 contains the following line mapping drive P: to the utilities:  MAP P:=SYS:PUBLICThis 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\OS2Chapter 3, "book="supernt" docset="nw40"Creating Login Scripts and Menus," of Supervising the Network explains more about login scripts.ID="FM55507"ID="FM74329"Other Protocols idxid="w247"book="_idx" docset="nw312" tidref="i5640"The NetWare Workstation for OS/2 kit provides support for the following protocols:SPXNetBIOS emulationNamed PipesThese 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. IDREF="FM34869"Chapter 9, "Setting Up Named Pipes and NetBIOS Protocols," explains more about using protocols from virtual DOS and Windows sessions.LBL="2"Information for NetWare v2.x and v3.x Users Upgrading to NetWare v4.0 idxid="w248"book="_idx" docset="nw312" tidref="i7094"If you used the NetWare Requester for OS/2 v2.0 with NetWare v3.x and v2.x servers, you should be aware of differences in NetWare v4.0. Significant changes have been made in the following areas:WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM73975"Default Frame Type for Workstation ODI DriversWIDTH="48"IDREF="FM73975"10IDREF="FM53587"Selecting a Preferred ServerIDREF="FM53587"11IDREF="FM81379"Logging In to the NetworkIDREF="FM81379"12IDREF="FM11635"Mappings in Default Login ScriptIDREF="FM11635"13IDREF="FM15972"Mapping to the Public UtilitiesIDREF="FM15972"14IDREF="FM58503"Login ScriptsIDREF="FM58503"15IDREF="FM90581"Virtual DOS and Windows SessionsIDREF="FM90581"16ID="FM73975"Default Frame Type for Workstation ODI DriversThe 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.3The 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 IDREF="FM82317""frame" on page 242 explains more about setting a frame type in your NET.CFG file.ID="FM53587"Selecting a Preferred idxid="w249"book="_idx" docset="nw312" tidref="i5137"ServerNetWare v4.0 uses trees and contexts rather than servers to identify what you log in to. "book="concepts" docset="nw40"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 novellChapter 4, "book="ws_get" docset="nw40"Setting Up Workstations to Log In to the Network," of Workstation Basics and Installation explains more about putting the " idxid="w250"book="_idx" docset="nw312" tidref="i5144"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 fs1Regardless 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 idxid="w251"book="_idx" docset="nw312" tidref="i1504"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.ID="FM81379"Logging In to the Network idxid="w252"book="_idx" docset="nw312" tidref="i3387"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. "book="concepts" docset="nw40"NetWare Directory Services" in Concepts explains more about the Directory. Logging In from the OS/2 Command Line idxid="w253"book="_idx" docset="nw312" tidref="i3387"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_MKTGJOHN 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"book="concepts" docset="nw40"Bindery Emulation" and "book="concepts" docset="nw40"NetWare Directory Services" in Concepts explain more about the bindery and the Directory. Chapter 4, "book="ws_get" docset="nw40"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, "book="ws_get" docset="nw40"Workstation Login," of Workstation Basics and Installation explains more about logging in.Logging In from the Desktop idxid="w254"book="_idx" docset="nw312" tidref="i3387"You should log in from the command line rather than from the OS/2 "Network" icon idxid="w255"book="_idx" docset="nw312" tidref="i3387"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.The attachment from idxid="w256"book="_idx" docset="nw312" tidref="i3387"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.ID="FM11635"Mappings idxid="w257"book="_idx" docset="nw312" tidref="i3732"in Default Login Script idxid="w258"book="_idx" docset="nw312" tidref="i3732"idxid="w259"book="_idx" docset="nw312" tidref="i7237"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 idxid="w260"book="_idx" docset="nw312" tidref="i3546"idxid="w261"book="_idx" docset="nw312" tidref="i7237"utilities:  MAP P:=SYS:PUBLICThis 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\OS2ID="FM15972"Mapping to the Public Utilities idxid="w262"book="_idx" docset="nw312" tidref="i3546"When setting up system or user idxid="w263"book="_idx" docset="nw312" tidref="i3546"login scripts for OS/2 users, always map drive P: to SYS:PUBLIC, as shown:  MAP P:=SYS:PUBLICChapter 3, "book="supernt" docset="nw40"Creating Login Scripts and Menus," of Supervising the Network explains more about mapping drives in login scripts.Why Drive P: idxid="w264"book="_idx" docset="nw312" tidref="i1723"idxid="w265"book="_idx" docset="nw312" tidref="i7237"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\OS2Do 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 will not 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:SYS:PUBLIC\OS2\OS2ID="FM58503"Login ScriptsYou can log in fromAn OS/2 sessionA global or private DOS or Windows sessionA global session booted from a real DOS kernel and running VSHELLA private session booted from a real DOS kernel and running the NetWare v4.0 DOS RequesterThe following table shows what login script is executed for which type of login, and how to edit those login scripts.LBL="2-1" INLINE="F"How to edit login scripts for each type of sessionWIDTH="108"If you log in fromWIDTH="108"Login script runWIDTH="192"How login script is editedWIDTH="108"OS/2 sessionWIDTH="108"NetWare v4.0 Login  Profile objectWIDTH="192"With the NetWare Administrator for OS/2  utility. See book="utilref" docset="nw40"Utilities Reference.Private DOS/Windows  sessionNetWare v3.11 DOS  login scriptFrom a text editor. Edit the  SYS:MAIL\userID\LOGIN file.Or use a NetWare v3.11 utility, such as  SYSCON.Global DOS/Windows  sessionNetWare v3.11 DOS  login scriptFrom 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 VSHELLNetWare v3.11 DOS  login scriptFrom 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 RequesterNetWare v4.0 Login  Profile objectWith the NetWare Administrator for OS/2  utility. See book="utilref" docset="nw40"Utilities Reference.ID="FM90581"Virtual DOS and Windows Sessions idxid="w266"book="_idx" docset="nw312" tidref="i7313"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. "book="concepts" docset="nw40"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 DOS_STARTUP_DRIVE setting. The OS/2 online "Master Help Index" explains how to do this.Sessions booted from a idxid="w267"book="_idx" docset="nw312" tidref="i1711"idxid="w268"book="_idx" docset="nw312" tidref="i1638"real idxid="w269"book="_idx" docset="nw312" tidref="i7313"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.IDREF="FM75599"Chapter 3, "Network Access From Virtual DOS and Windows," explains more about setting up virtual DOS and Windows sessions.IDREF="FM94086"Figure 2-1 on page 18 shows what NetWare functionality you have under all types of virtual sessions.Changes idxid="w270"book="_idx" docset="nw312" tidref="i7313"to Global NetWare Supportidxid="w271"book="_idx" docset="nw312" tidref="i2553"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 idxid="w272"book="_idx" docset="nw312" tidref="i7313"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 IDREF="FM75599"Chapter 3, "Network Access From Virtual DOS and Windows," instead of doing these steps.NETX.COM idxid="w273"book="_idx" docset="nw312" tidref="i4591"has changed to NETX.EXE idxid="w274"book="_idx" docset="nw312" tidref="i4591". This means you must open the DOS Settings Notebook for each session and make the following changes:ProceduresFor the DOS_VERSION setting, change the line that includes NETX.COM to read:  NETX.EXE,5,00,214For the DOS_FILES setting, change 255 to 214.LBL="2-1"ID="FM94086"NetWare support in DOS/Windows sessionsFILE="c312q74a.pbm"LBL="3"ID="FM75599"Network Access From Virtual DOS and Windows idxid="w275"book="_idx" docset="nw312" tidref="i7313"idxid="w276"book="_idx" docset="nw312" tidref="i7313"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM22516"Cautions for All Types of SessionsWIDTH="48"IDREF="FM22516"21IDREF="FM35532"Customizing Icons For Global SupportIDREF="FM35532"23IDREF="FM58788"Setting Up Drive Mappings in Global SessionsIDREF="FM58788"27IDREF="FM60865"Customizing Icons For Private SupportIDREF="FM60865"29IDREF="FM24573"Special Instructions for Win-OS2 IconsIDREF="FM24573"34IDREF="FM47202"Special Instructions for DOS_STARTUP_DRIVE SessionsIDREF="FM47202"36IDREF="FM67637"Disabling Network Support in Virtual SessionsIDREF="FM67637"39From a virtual DOS or Windows session, you can have three kinds of NetWare support:Global logins idxid="w277"book="_idx" docset="nw312" tidref="i2550"idxid="w278"book="_idx" docset="nw312" tidref="i5574"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.Private loginsAll 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.No logins.Sessions with network support disabled have IPX/SPX support, but no NetWare login support.Set up NetWare support for virtual DOS and Windows in two ways: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, "book="ws_get" docset="nw40"Installing a NetWare Workstation," in Workstation Basics and Installation explains about running the installation.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.ID="FM22516"Cautions for All Types of Sessions idxid="w279"book="_idx" docset="nw312" tidref="i7313"Version of NetWare SupportedFrom 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_STARTUP_DRIVE feature), you can access NetWare 4.0 networks from that session. See IDREF="FM47202""Special Instructions for DOS_STARTUP_DRIVE Sessions" on page 36.Accessing the Correct Version of DOSFor all virtual sessions you start, the COMSPEC idxid="w280"book="_idx" docset="nw312" tidref="i1109"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.COMYou 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 idxid="w281"book="_idx" docset="nw312" tidref="i3546"often contain a statement assigning COMSPEC to a network drive, so be sure to check---and if necessary, reset---the COMSPEC variable in your login script.Login IssuesIDREF="FM94086"Figure 2-1 on page 18 shows what login scripts are executed from which type of session and how to edit those login scripts.Also, when you log out 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 log out from a network drive, the drive remains the same.ID="FM35532"Customizing Icons For Global idxid="w282"book="_idx" docset="nw312" tidref="i2553"Support idxid="w283"book="_idx" docset="nw312" tidref="i7313"PrerequisitesRead IDREF="FM22516""Cautions for All Types of Sessions" on page 21.Make sure network support for virtual sessions is enabled. If not, enable it by running the Requester installation program. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," of Workstation Basics and Installation explains how to run the Requester installation. Virtual session support is enabled by default.ProceduresTo set up global NetWare support for an icon, do the following:Open the "D idxid="w284"book="_idx" docset="nw312" tidref="i1638"OS 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." IDREF="FM58788"Figure 3-1 shows how to open DOS Settings.LBL="3-1"ID="FM58788"Opening DOS SettingsFILE="c312q71a.pbm"In the "DOS Settings" Notebook, choose the "Session" tab.IDREF="FM92784"Figure 3-2 illustrates the "Session" tab page.LBL="3-2"ID="FM92784"Choosing the "Session" tabFILE="c312q67a.pbm"On the "Session" screen, choose the "DOS Settings . . ." button.IDREF="FM43832"Figure 3-3 illustrates the "DOS Settings" screen.LBL="3-3"ID="FM43832"The DOS Settings ScreenFILE="c312q72a.pbm"(Optional) Enable the NetWare CAPTURE feature for the session.Select idxid="w285"book="_idx" docset="nw312" tidref="i900"idxid="w286"book="_idx" docset="nw312" tidref="i5567"idxid="w287"book="_idx" docset="nw312" tidref="i3590"idxid="w288"book="_idx" docset="nw312" tidref="i2300"idxid="w289"book="_idx" docset="nw312" tidref="i1704""DOS_DEVICE" on the "DOS Settings" screenType the following line in the "Value" field:  drive:\OS2\MDOS\LPTDD.SYSReplace 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.Specify that all drives are available to NetWare.Select "DOS_LASTDRIVE. idxid="w290"book="_idx" docset="nw312" tidref="i1708""Type Z in the "Value" field.This tells NetWare that all drives up through Z are available for use in the session.Choose Global NetWare support.Select " idxid="w291"book="_idx" docset="nw312" tidref="i4460"NETWARE_RESOURCES."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.Enable virtual IPX for this session.Select "VIPX_ENABLED idxid="w292"book="_idx" docset="nw312" tidref="i7301"."Select "On."Save and exit "DOS Settings."ID="FM58788"Setting Up Drive idxid="w293"book="_idx" docset="nw312" tidref="i2553"Mappings idxid="w294"book="_idx" docset="nw312" tidref="i1723"in Global idxid="w295"book="_idx" docset="nw312" tidref="i7313"Sessions idxid="w296"book="_idx" docset="nw312" tidref="i3732"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.ProceduresDecide which drives you want mapped in your global environment. Decide which of those drives need to be included in a search path.Edit your NetWare v4.0 login script (used in OS/2 sessions) and include MAP statements for all NetWare drives.Edit your NetWare v3.11 DOS login script and include MAP ROOT 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 ROOT rather than MAP for consistency between DOS and OS/2 sessions. For easiest maintenance, both login scripts should contain identical map statements.Edit your OS/2 CONFIG.SYS file and include the drive letters you want 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:  H:\;If needed, you can also include drive letters in the data path statement (DPATH). The DPATH statement is where OS/2 searches for nonexecutable, non-.DLL files.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.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."ID="FM60865"Customizing Icons For idxid="w297"book="_idx" docset="nw312" tidref="i7313"Private Support idxid="w298"book="_idx" docset="nw312" tidref="i5574"PrerequisitesRead IDREF="FM22516""Cautions for All Types of Sessions" on page 21.Make sure network support for virtual sessions is enabled. If not, enable it by running the Requester installation program. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," of Workstation Basics and Installation explains how to run the installation. Virtual session support is enabled by default.ProceduresTo set up private NetWare support for an icon, do the following:Open the "D idxid="w299"book="_idx" docset="nw312" tidref="i1638"OS 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." IDREF="FM58788"Figure 3-1 shows how to open DOS Settings.LBL="3-4"ID="FM58788"Opening DOS SettingsFILE="c312q71a.pbm"In the "DOS Settings" Notebook, choose the "Session" tab.IDREF="FM92784"Figure 3-2 illustrates the "Session" tab page.LBL="3-5"ID="FM92784"Choosing the "Session" tabFILE="c312q67a.pbm"On the "Session" screen, choose the "DOS Settings . . ." button.IDREF="FM43832"Figure 3-3 illustrates the "DOS Settings" screen.LBL="3-6"ID="FM43832"The DOS Settings ScreenFILE="c312q72a.pbm"(Optional) Enable the NetWare CAPTURE feature for the session.Select idxid="w300"book="_idx" docset="nw312" tidref="i900"idxid="w301"book="_idx" docset="nw312" tidref="i5568"idxid="w302"book="_idx" docset="nw312" tidref="i3590"idxid="w303"book="_idx" docset="nw312" tidref="i2300"idxid="w304"book="_idx" docset="nw312" tidref="i1704""DOS_DEVICE" on the "DOS Settings" screenType the following line in the "Value" field:  drive:\OS2\MDOS\LPTDD.SYSReplace 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.Specify how many files the session can open simultaneously.Select " idxid="w305"book="_idx" docset="nw312" tidref="i1707"DOS_FILES."Type 214 in the "Value" field.Specify what drives are available to NetWare.Select "DOS_LASTDRIVE. idxid="w306"book="_idx" docset="nw312" tidref="i1708""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 a global session.Specify the correct version of NETX.EXE.Select "DOS_VERSION. idxid="w307"book="_idx" docset="nw312" tidref="i1715""In the "Value" field, find the line that specifies the version of NETX and replace it with the following line:  NETX.EXE,5,00,255Choose Private NetWare support.Select " idxid="w308"book="_idx" docset="nw312" tidref="i4460"NETWARE_RESOURCES."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 have its own NetWare login.Enable virtual IPX for this session.Select "VIPX_ENABLED."Select "On."Save and exit "DOS Settings."ID="FM80167"Load the NETX.EXE idxid="w309"book="_idx" docset="nw312" tidref="i4591"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.EXEFor more information about optional parameters, see "parameters, starting programs with" in the OS/2 online Master Help Index.To load NETX.EXE automatically for all DOS and Windows sessions, put the following command in an AUTOEXEC.BAT file in the root of your boot drive:  drive:\path\NETX.EXEReplace 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.ID="FM24573"Special Instructions for idxid="w310"book="_idx" docset="nw312" tidref="i7313"Win-OS2 idxid="w311"book="_idx" docset="nw312" tidref="i7441"IconsThese instructions apply to the Windows 3.0 support that was shipped with OS/2 v2.0.PrerequisitesRead IDREF="FM22516""Cautions for All Types of Sessions" on page 21.CompleteIDREF="FM35532""Customizing Icons For Global Support" on page 23 or IDREF="FM60865""Customizing Icons For Private Support" on page 29 for the Win-OS2 icon.ProceduresYou need several additional files for Win-OS2 NetWare support:  NWIPXSPX.DLL  NETWARE.DRV  TBMI2.COM  NWPOPUP.EXE  NETWARE.HLPBy default, these files are copied to the \OS2\MDOS\WINOS2\SYSTEM directory on your boot drive when you install the NetWare Requester.The idxid="w312"book="_idx" docset="nw312" tidref="i6806"TBMI2 idxid="w313"book="_idx" docset="nw312" tidref="i2300"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:Make and use a copy of a DOS icon.Create a batch file (.BAT extension) with the following lines:  drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COM  WINOS2.COM  EXITReplace drive with the letter of your boot drive.Save the batch file in the following directory:  \OS2\MDOS\WINOS2\SYSTEMOpen the "Settings" for the icon.Choose the "Program" tab.In the "Optional Parameters" field, type the following line:  /K drive:\OS2\MDOS\WINOS2\batchfile.batReplace drive with the letter of your boot drive. Replace batchfile with the name of your batch file.Choose the "Session" tab.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 the OS/2 online "Master Help Index."To load TBMI2.COM automatically for all DOS and Windows sessions, put the following command in an AUTOEXEC.BAT file in the root of your boot drive:  drive:\OS2\MDOS\WINOS2\SYSTEM\TBMI2.COMReplace drive with the letter of your boot drive.ID="FM47202"ID="FM63171"ID="FM19464"Special Instructions for idxid="w314"book="_idx" docset="nw312" tidref="i1711"idxid="w315"book="_idx" docset="nw312" tidref="i7313"DOS_STARTUP_DRIVE idxid="w316"book="_idx" docset="nw312" tidref="i7329"SessionsIf 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_STARTUP_DRIVE feature.If you are using DOS_STARTUP_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_STARTUP_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_STARTUP_DRIVE sessions globally or privately.Setting up Global DOS_STARTUP_DRIVE SessionsPrerequisitesRead IDREF="FM22516""Cautions for All Types of Sessions" on page 21.Set up your session to boot from another version of DOS. This involves creating a boot idxid="w317"book="_idx" docset="nw312" tidref="i733"image file, setting DOS_STARTUP_DRIVE, and certain other idxid="w318"book="_idx" docset="nw312" tidref="i7330"tasks using the VMDISK utilitly. See the OS/2 online "Master Help Index."Make sure network support for virtual sessions is enabled. If not, enable it by running the Requester installation program. Chapter 3 "book="ws_get" docset="nw40"Installing a NetWare Workstation," of Workstation Basics and Installation explains how to run the installation program. Virtual session support is enabled by default.Set up your session for global NetWare support by following the instructions in IDREF="FM35532""Customizing Icons For Global Support" on page 23 and IDREF="FM58788""Setting Up Drive Mappings in Global Sessions" on page 27.ProceduresType 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\ idxid="w319"book="_idx" docset="nw312" tidref="i3187"idxid="w320"book="_idx" docset="nw312" tidref="i1052"dosvshll.sys  device=drive:path\dosvipx.sys  lastdrive=zReplace 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_STARTUP_DRIVE SessionsPrerequisitesRead IDREF="FM22516""Cautions for All Types of Sessions" on page 21.Set up your session to boot from another version of DOS. This involves creating a boot idxid="w321"book="_idx" docset="nw312" tidref="i733"image file, setting DOS_STARTUP_DRIVE, and certain other idxid="w322"book="_idx" docset="nw312" tidref="i7330"tasks using the VMDISK utilitly. See the OS/2 online "Master Help Index."Make sure network support for virtual sessions is enabled. If not, enable it by running the Requester installation program. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," of Workstation Basics and Installation explains how to run the Requester installation. Virtual session support is enabled by default.Set up your session for private NetWare support by following the instructions in IDREF="FM60865""Customizing Icons For Private Support" on page 29.ProceduresType 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\dosvipx.sys  files=214  lastdrive=letterReplace 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_STARTUP_DRIVE session access to OS/2 HPFS drives and Named Pipes support. See the OS/2 documentation for more information about FSFILTER.SYS.Load the NetWare Workstation for DOS software.To load NetWare v4.0 DOS Requester, follow the directions in book="ws_dos" docset="nw40"NetWare Workstation for DOS and Windows. Use the software on the DOS Requester diskette, WSDOS_1.To load NETX.EXE for NetWare v3.11 support, follow the instructions in IDREF="FM80167"Step 11 on page 33. 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_STARTUP_DRIVE session.ID="FM67637"Disabling idxid="w323"book="_idx" docset="nw312" tidref="i5574"idxid="w324"book="_idx" docset="nw312" tidref="i1543"Network idxid="w325"book="_idx" docset="nw312" tidref="i2553"idxid="w326"book="_idx" docset="nw312" tidref="i7313"Support in Virtual SessionsTo 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, "book="ws_get" docset="nw40"Installing a NetWare Workstation," in Workstation Basics and Installation explains how to run the Requester installation program.ID="FM52852"For a technical diagram of NetWare support in a virtual DOS/Windows session, IDREF="FM78537"see Appendix C, "Architecture Diagrams."LBL="4"ID="FM16745"How to Configure Your WorkstationID="FM17116"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM50780"When Is Configuration RequiredWIDTH="48"IDREF="FM50780"42IDREF="FM12931"ProceduresIDREF="FM12931"44IDREF="FM45501"NET.CFG Format RequirementsIDREF="FM45501"47IDREF="FM28802"Quick Reference List of NET.CFG OptionsIDREF="FM28802"48This 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 IDREF="FM73872"Appendix B on page 235.ID="FM50780"When Is Configuration idxid="w327"book="_idx" docset="nw312" tidref="i1165"RequiredRead the table below to decide if you must configure the workstation before the NetWare Requester will run.LBL="4-1" INLINE="F"Situations when configuration is requiredWIDTH="120"You must configure ifWIDTH="180"For information, go toWIDTH="120"Your workstation has  more than one network  boardWIDTH="180"IDREF="FM16745"Chapter 5, "Network Boards and Drivers"Your workstation has a  single board, but the  board is not using the  factory default settingsIDREF="FM16745"Chapter 5, "Network Boards and Drivers"Your network uses an  Ethernet frame type other  than Ethernet_802.2IDREF="FM16745"Chapter 5, "Network Boards and Drivers"The NetWare Requester  will share a network  board with other  softwareIDREF="FM39812"Chapter 8, "Sharing a Network Board  With IBM Software"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.LBL="4-2" INLINE="F"Other situations when configuration might be usefulWIDTH="120"You may want to configure ifWIDTH="180"For information, go toWIDTH="120"You want to change the  default packet signature  security levelWIDTH="180"IDREF="FM16745"Chapter 6, "Improving Speed and  Security"You want to turn off  Packet Burst or Large  Internet Packet  transmissionsIDREF="FM16745"Chapter 6, "Improving Speed and  Security"Your workstation will  connect to a Token-Ring  network using Source  RoutingIDREF="FM63720"Chapter 7, "Using OS/2 Workstations on a  Token-Ring Network"Your workstation will  need to use the NetBIOS  or Named Pipes  protocolsIDREF="FM34869"Chapter 9, "Setting Up Named Pipes and  NetBIOS Protocols"Your want your  workstation to connect  to a preferred serverThe IDREF="FM61797""preferred server" setting on page  267 and the IDREF="FM68034""preferred tree" setting on  page 269.You are setting up  remote booting  workstationsIDREF="FM97261"Chapter 11, "Remote-Booting OS/2  Workstations"ID="FM12931"ID="FM53222"Procedures idxid="w328"book="_idx" docset="nw312" tidref="i1165"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 idxid="w329"book="_idx" docset="nw312" tidref="i2300"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: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 IDREF="FM73872"Appendix B on page 235 to determine what to include in the file.To edit or create NET.CFG with the installation program: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.Select "This workstation. . ." from the "Configuration" menu.The "Edit NET.CFG File for This Workstation" window appears.Check the location of the NET.CFG file. Change the location if you want.Use the online help if necessary.Type the NET.CFG options you want in the "Current NET.CFG File Contents" box.See IDREF="FM89881"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:LBL="4-3" INLINE="F"Key definitions for the NET.CFG windowWIDTH="120"To do thisWIDTH="192"Use these keysWIDTH="120"Highlight textWIDTH="192"Click and drag with the mouse, or move the  cursor with the arrow keys while holding  down the <Shift> keyCopy 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>LBL="4-1"ID="FM89881"How to edit the idxid="w330"book="_idx" docset="nw312" tidref="i4097"NET.CFG fileFILE="c312q04a.pbm"To save your changes to NET.CFG, choose "Save."To exit the installation program, double-click in the upper left corner of the main window.Use OS/2's "Shutdown" feature to reboot your workstation.Installation and configuration changes will not take effect until you reboot.ID="FM45501"ID="FM83224"NET.CFG idxid="w331"book="_idx" docset="nw312" tidref="i4097"Format RequirementsEach 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:Type options at the left margin of the file with no spaces before or after them. Options are not case-sensitive.Type one option per line.Type settings, one per line, on the lines following the option to which they apply. When editing 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.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.Precede comments with a semicolon.IDREF="FM17825"Figure 4-2 illustrates NET.CFG format.LBL="4-2"ID="FM17825"NET.CFG formatFILE="c312q01a.pbm"ID="FM28802"Quick Reference List of NET.CFG Options idxid="w332"book="_idx" docset="nw312" tidref="i4127"IDREF="FM19476"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 IDREF="FM73872"235.LBL="4-3"ID="FM19476"NET.CFG quick referenceFILE="c312q08a.pbm"LBL="5"ID="FM16745"Network Boards and DriversID="FM17116"This chapter explains network board and driver issues. For basic information about boards and drivers, see the documentation for your network board.WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM26624"Matching Driver Settings with Board SettingsWIDTH="48"IDREF="FM26624"51IDREF="FM64269"Specifying Frame Types for a DriverIDREF="FM64269"53IDREF="FM23495"Why Have More Than One Network BoardIDREF="FM23495"55IDREF="FM75291"Setting Up Two Network BoardsIDREF="FM75291"58ID="FM26624"Matching idxid="w333"book="_idx" docset="nw312" tidref="i4799"Driver Settings with Board SettingsNetwork boards come with factory idxid="w334"book="_idx" docset="nw312" tidref="i4494"defaults for such hardware settings as:Direct memory access channel (DMA) idxid="w335"book="_idx" docset="nw312" tidref="i1635"Interrupt line (IRQ) idxid="w336"book="_idx" docset="nw312" tidref="i2908"Input/output port idxid="w337"book="_idx" docset="nw312" tidref="i5113"Memory range idxid="w338"book="_idx" docset="nw312" tidref="i3801"Node addressThese 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.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]IDREF="FM16745""How to Configure Your Workstation" on page 41 explains more about putting options in the NET.CFG file. IDREF="FM28739""Link Driver" on page 239 explains more about using these settings.Shortcut for EISA and idxid="w339"book="_idx" docset="nw312" tidref="i4799"Micro Channel BoardsIf 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 board 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 idxid="w340"book="_idx" docset="nw312" tidref="i6350""slot" setting in the NET.CFG file:  link driver name     slot numberReplace number with the number of the slot, or replace number with a question mark to tell the Requester to scan all slots. The section IDREF="FM91351""slot" on page 250 explains more about using the "slot" setting.ID="FM64269"Specifying Frame idxid="w341"book="_idx" docset="nw312" tidref="i2504"Types for a DriverAll 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 aframe 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.LBL="5-1" INLINE="F"ID="FM83727"List of frame types and driversWIDTH="96"Frame type idxid="w342"book="_idx" docset="nw312" tidref="i2504"WIDTH="216"ID="FM80009"Network board driverWIDTH="96"Ethernet_802.3WIDTH="216"NE1000, NE2000, NE2100, NE2, NE2-32,  3C501, 3C503, 3C505, 3C523, EXOS205,  EXOS215, ODINSUPEthernet_802.2NE1000, NE2000, NE2100, NE2, NE2-32,  3C501, 3C503, EXOS205, EXOS215, ODINSUP,  LANSUPEthernet_IINE1000, NE2000, NE2100, NE2, NE2-32,  3C501, 3C503, 3C505, 3C523, EXOS205,  EXOS215, ODINSUPEthernet_SNAPNE1000, NE2000, NE2100, NE2, NE2-32,  3C501, 3C503, EXOS205, EXOS215, ODINSUP.  LANSUPToken-RingODINSUP, TOKEN, LANSUPToken-Ring_SNAPODINSUP, TOKEN, LANSUPIBM_pcn2_802.2PCN2, PCN2L, LANSUPIBM_pcn2_snapPCN2, PCN2L, LANSUPNovell_rx-netTRXNET, TRXNET2You 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 nameReplace name with the name of the frame type. To specify more than one frame type, you can type additional frame type lines.IDREF="FM16745""How to Configure Your Workstation" on page 41 explains more about how to put options in the NET.CFG file. The section idxid="w343"book="_idx" docset="nw312" tidref="i2503"IDREF="FM82317""frame" on page 242 explains more about using the "frame" setting.Cautions When Changing idxid="w344"book="_idx" docset="nw312" tidref="i2504"idxid="w345"book="_idx" docset="nw312" tidref="i2504"Frame Typeidxid="w346"book="_idx" docset="nw312" tidref="i4799"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 idxid="w347"book="_idx" docset="nw312" tidref="i1198"connect idxid="w348"book="_idx" docset="nw312" tidref="i1839"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:  link driver ne2000     frame ethernet_802.3     frame ethernet_802.2The 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 IDREF="FM82317""frame" on page 242 explains more about setting a frame type in your NET.CFG file.ID="FM23495"Why Have More Than One Network Board idxid="w349"book="_idx" docset="nw312" tidref="i4494"When using the NetWare Requester, there are only two conditions where you benefit from having more than one network board in your computer:When each board supports a different communications software package.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 aware of some configuration issues, discussed in the following sections.Two or More Communications PackagesYou 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 for 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 communication 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 IDREF="FM39812""Sharing a Network Board With IBM Software" on page 81. To have NetWare Requester share a board with NetWare for OS/2, see book="srv_os2" docset="nw40"NetWare v4.0 Installation Supplement for OS/2 Servers.Two Connected NetworksYou 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 ConnectedWhen 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.idxid="w350"book="_idx" docset="nw312" tidref="i3005"IPX only sends out a destination query on the idxid="w351"book="_idx" docset="nw312" tidref="i5149"primary idxid="w352"book="_idx" docset="nw312" tidref="i4494"network board. It never queries the secondary (or other) board for a route.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.How is The Second Board a BackupOnce 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 BrokenIf 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.ID="FM75291"Setting Up Two idxid="w353"book="_idx" docset="nw312" tidref="i4494"Network BoardsIf you have two network boards in your computer, you may need toLoad an additional ODI driver. See IDREF="FM49403"page 58.Change which board IPX uses as primary. See IDREF="FM69403"page 60.Define hardware settings and frame type for each board. See IDREF="FM32863"page 63.ID="FM49403"Loading the idxid="w354"book="_idx" docset="nw312" tidref="i4799"Driver for an Additional BoardThe 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 ifYou have two network boards, andThose 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 IDREF="FM46750""Specifying Primary with Two Boards of the Same Type" on page 60. Do not complete the steps in this section.PrerequisiteInstall the NetWare Requester with one of the ODI drivers. It does not matter which one. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," in Workstation Basics and Installation explains how to install the Requester.ProceduresOpen 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.SYSCONFIG.SYS is generally located in the root of your boot drive.In the NetWare Requester lines, find the line loading the first ODI driver.For a list of common ODI drivers, see IDREF="FM83727"Table 5-1, "List of frame types and drivers," on page 53.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. IDREF="FM23495""Why Have More Than One Network Board" on page 55 explains more about primary and secondary boards.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.SYSIf you have two boards using the same driver name (such as two NE1000 boards), do not load the driver twice.Save and exit the CONFIG.SYS file.Reboot your machine to load the additional drivers.ID="FM69403"Changing Which Board Is Primary idxid="w355"book="_idx" docset="nw312" tidref="i4494"idxid="w356"book="_idx" docset="nw312" tidref="i4097"The board whose driver loads first in the CONFIG.SYS file is the primary board. You can change which board is primary byReordering drivers in the CONFIG.SYS file.The previous section, IDREF="FM49403""Loading the Driver for an Additional Board" on page 58, explains how to edit the CONFIG.SYS file.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 idxid="w357"book="_idx" docset="nw312" tidref="i5616"ipx     bind drivernameReplace 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 tokenIDREF="FM38316""Protocol Stack IPX" on page 274 explains more about using this option.ID="FM46750"Specifying Primary with Two Boards of the Same idxid="w358"book="_idx" docset="nw312" tidref="i4494"TypeIf 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.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.IDREF="FM26624""Matching Driver Settings with Board Settings" on page 51 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 320Putting 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 idxid="w359"book="_idx" docset="nw312" tidref="i3889"Boards idxid="w360"book="_idx" docset="nw312" tidref="i1804"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 board and automatically determines what hardware settings are in use.For example, for two NE3200 boards, type:  link driver ne3200     frame ethernet_802.3     frame ethernet_802.2     slot 2  link driver ne3200     frame ethernet_802.3     frame ethernet_802.2     slot 1In 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 2The section IDREF="FM91351""slot" on page 250 explains more.Why Change Which Board Is Primary idxid="w361"book="_idx" docset="nw312" tidref="i4494"There are two scenarios in which you may want to change which board is primary.Scenario 1: Faster queries on networks connected with a routerSuppose 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.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 networksSuppose 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 toUnplug your cable from one board and connect it to the other board, orConnect the networks with a routerID="FM32863"Setting Hardware Settings and Frame Type for Each Board idxid="w362"book="_idx" docset="nw312" tidref="i4097"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 IDREF="FM26624""Matching Driver Settings with Board Settings" on page 51 and IDREF="FM64269""Specifying Frame Types for a Driver" on page 53.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 2If you have two boards with the same driver name (such as NE2000), see IDREF="FM46750""Specifying Primary with Two Boards of the Same Type" on page 60 for information about using the "Link Driver" option.LBL="6"ID="FM16745"Improving Speed and SecurityID="FM17116"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM54026"Improving Speed with Packet BurstWIDTH="48"IDREF="FM54026"66IDREF="FM49792"Improving Speed by Using Large Internet PacketsIDREF="FM49792"67IDREF="FM94412"Improving Security by Using Packet SignatureIDREF="FM94412"67You can use three features to improve speed and security on your network:Packet BurstLarge Internet PacketsPacket Signature LevelID="FM54026"Improving Speed with Packet idxid="w363"book="_idx" docset="nw312" tidref="i4872"BurstPacket Burst is a protocol that speeds the transfer of multiple-packet NCP reads and writes. Packet Burst eliminates the need to sequence and acknowledge each packet. With Packet Burst, the server or client sends a whole set (or burst) of packets before it requires an acknowledgment.Packet Burst reduces network traffic by allowing multiple packets to be acknowledged. Packet Burst also monitors dropped packets and retransmits only the missing packets.At connection time, maximum burst sizes are negotiated with each server. Since Packet Burst is established with each connection, it's possible to "burst" with one server but not with another.Once you establish a Packet Burst connection between a workstation and a server, the workstation automatically uses Packet Burst whenever an application requests to write more than three times the maximum packet size of data. This means that an application doesn't have to be aware of Packet Burst.Disabling Packet Burst idxid="w364"book="_idx" docset="nw312" tidref="i4872"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 offSee the IDREF="FM89210""packet burst off" setting on page 267 for information on Packet Burst.ID="FM49792"Improving Speed by Using idxid="w365"book="_idx" docset="nw312" tidref="i3164"Large Internet PacketsLarge 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 PacketsLIP 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 offID="FM94412"Improving idxid="w366"book="_idx" docset="nw312" tidref="i6206"Security by Using Packet Signature idxid="w367"book="_idx" docset="nw312" tidref="i4886"idxid="w368"book="_idx" docset="nw312" tidref="i4055"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.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.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 OptionsBecause 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.Server LevelsServer packet signature levels are assigned by a new SET parameter. See book="utilref" docset="nw40"Utilities Reference for more information.Client LevelsPacket signature levels at the workstation are assigned by using the following NET.CFG option:  netware requester     signature level numberReplace number with 0, 1, 2, or 3. The default is 1.LBL="6-1" INLINE="F"NCP Packet Signature levelsWIDTH="72"NumberWIDTH="240"ExplanationWIDTH="72"0WIDTH="240"Client does not sign packets1Client signs packets only if the server requests it (server  option is 2 or higher)2Client signs packets if the server is capable of signing  (server option is 1 or higher)3Client signs packets and requires the server to sign  packets (or login will fail)Effective Packet SignatureThe 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-2 shows the interactive relationship between the server packet signature levels and the client signature levels.LBL="6-2" INLINE="F"Effective Packet Signature of server and clientWIDTH="84"IFWIDTH="84"Server = 0WIDTH="84"Server = 1WIDTH="84"Server = 2WIDTH="84"Server = 3WIDTH="84"Client = 0WIDTH="84"No packet  signatureWIDTH="84"No packet  signatureWIDTH="84"No packet  signatureWIDTH="84"No loginClient = 1No packet  signatureNo packet  signaturePacket  signaturePacket  signatureClient = 2No packet  signaturePacket  signaturePacket  signaturePacket  signatureClient = 3No loginPacket  signaturePacket  signaturePacket  signatureWhen to Use NCP Packet Signature idxid="w369"book="_idx" docset="nw312" tidref="i4886"NCP Packet Signature is not required for every installation. Some network supervisors may choose not to use NCP Packet Signature because they can tolerate certain security risks.You may not need to use NCP Packet Signature if:Only executable programs reside on the server.All workstation users on the network are known and trusted by the supervisor.Data on the NetWare server is not sensitive; loss or corruption of this data will not impact operations.You may want to use NCP Packet Signature if:An untrustworthy user uses a workstation on the network.Someone can easily access the network cabling system.There is an unattended, publicly accessible workstation on the network.The default NCP Packet Signature level is 1 for clients and 2 for servers. In general, this setting provides the most flexibility while still offering protection from forged packets. Below are some examples of using different signature levels.All Information on the Server Is SensitiveIf 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 Nonsensitive Information Reside on the Same ServerThe 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 WorkstationsThe 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 AccessibleAn 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 idxid="w370"book="_idx" docset="nw312" tidref="i4886"This section describes some solutions to problems that may be associated with using NCP Packet Signature.Clients Are Not Signing PacketsMake 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 idxid="w371"book="_idx" docset="nw312" tidref="i1198"idxid="w372"book="_idx" docset="nw312" tidref="i3387"Make sure each workstation has NetWare Requester v2.01 installed.The following situations do not allow logging in:Server packet signature = 3, client signature = 0Server packet signature = 0, client signature = 3Utilities are old and do not support NCP Packet SignatureThe Requester is old and does not support NCP Packet Signature."Error Receiving From the NetWork" AppearsThe 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 ServerThe 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).LBL="7"ID="FM63720"Using OS/2 Workstations on a Token-Ring NetworkWIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM52823"Installing Source Routing on the ServerWIDTH="48"IDREF="FM52823"74IDREF="FM80219"Installing Source Routing on the WorkstationIDREF="FM80219"75IDREF="FM55132"Configuring Source Routing on the WorkstationIDREF="FM55132"76idxid="w373"book="_idx" docset="nw312" tidref="i6829"idxid="w374"book="_idx" docset="nw312" tidref="i6429"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. book="ws_dos" docset="nw40"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:ROUTE.NLM (for servers)ROUTE.SYS (for OS/2 workstations)This software routes only IPX packets.ID="FM52823"Installing idxid="w375"book="_idx" docset="nw312" tidref="i6429"Source Routing on the Server idxid="w376"book="_idx" docset="nw312" tidref="i2869"ProceduresAt the server console, load ROUTE.NLM by typing:  LOAD ROUTEROUTE.NLM is located in the SYS:SYSTEM directory. You can load it with command line parameters. book="utilref" docset="nw40"Utilities Reference explains more about the parameters.You can also load ROUTE.NLM in a startup file.(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=02You can change a source-routing parameter after ROUTE is loaded. Type the LOAD ROUTEidxid="w377"book="_idx" docset="nw312" tidref="i6020" command followed by the parameter you want to change.ID="FM80219"Installing Source idxid="w378"book="_idx" docset="nw312" tidref="i6429"Routing on the Workstation idxid="w379"book="_idx" docset="nw312" tidref="i2869"PrerequisitesInstall the Netware Requester with a TOKEN ODI driver. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Worsktation," in Workstation Basics and Installation explains how to install the Requester.Install source routing on all NetWare servers on the same network as source-routing bridges by following the instructions in IDREF="FM52823""Installing Source Routing on the Server" on page 74.Understand source routing. The September 1990 Novell Application Notes contains a thorough explanation of source routing.ProceduresOpen 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.SYSCONFIG.SYS is generally located in the root of your boot drive.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. IDREF="FM87147""Setting Up LANSUP" on page 107 explains more about LANSUP.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.SYSSave and exit the CONFIG.SYS file.Use the OS/2 "Shutdown" feature to reboot your machine.ID="FM55132"Configuring Source Routing idxid="w380"book="_idx" docset="nw312" tidref="i6429"on the WorkstationFollow the procedures in this section toDetermine whether you need to configure source routing, andConfigure source routing, if needed.PrerequisitesInstall the NetWare Requester. Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," in Workstation Basics and Installation explains how to install the Requester.Install source routing on the server. See IDREF="FM52823""Installing Source Routing on the Server" on page 74.Install source routing on the workstation. See IDREF="FM80219""Installing Source Routing on the Workstation" on page 75.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.ProceduresStart the NetWare Requester Installation program.You can choose the "Installation" icon from the "Novell" group on your desktop.Choose "This workstation . . ." from the "Configuration" menu.Verify the location of the NET.CFG file and choose "Edit."The "Edit NET.CFG" window appears. See IDREF="FM88360"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:LBL="7-1" INLINE="F"Key definitions for the NET.CFG windowWIDTH="120"To do this . . .WIDTH="192"Use these keys . . . .WIDTH="120"Highlight textWIDTH="192"Click and drag with the mouse, or move the  cursor with the arrow keys while holding  down the <Shift> keyCopy 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>LBL="7-1"ID="FM88360"Editing NET.CFG for source routingFILE="c312q70a.pbm"Select "Token-Ring source routing" from the "NET.CFG Options" box on the left of your screen.Determine whether to change the configuration for the "def", "gbr", "mbr", "nodes" and "board" settings under "Token-Ring source routing."Select one of the five settings.Example: select "def"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.(Optional) If you decide to change the configuration, type the configuration 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.Choose "Save."Exit the NetWare Requester Installation program and use the OS/2 "Shutdown" feature to reboot your computer.LBL="8"ID="FM39812"Sharing a Network Board With IBM Software idxid="w381"book="_idx" docset="nw312" tidref="i2702"idxid="w382"book="_idx" docset="nw312" tidref="i4342"idxid="w383"book="_idx" docset="nw312" tidref="i4342"idxid="w384"book="_idx" docset="nw312" tidref="i2699"Use this chapter if you want the NetWare Requester to share a network idxid="w385"book="_idx" docset="nw312" tidref="i4494"board with one or more of the following IBM software products:Extended Services idxid="w386"book="_idx" docset="nw312" tidref="i1945"LAN Server idxid="w387"book="_idx" docset="nw312" tidref="i3135"LAN Requester idxid="w388"book="_idx" docset="nw312" tidref="i3132"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM97282"How Board Sharing Is PossibleWIDTH="48"IDREF="FM97282"82IDREF="FM62336"Setting Up ODINSUPIDREF="FM62336"83IDREF="FM87147"Setting Up LANSUPIDREF="FM87147"107If 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 IDREF="FM85973""Setting Up NetBIOS for OS/2" on page 146.ID="FM97282"How Board Sharing Is PossibleThe 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 idxid="w389"book="_idx" docset="nw312" tidref="i4073"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:ODINSUP.SYS idxid="w390"book="_idx" docset="nw312" tidref="i4806"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 IDREF="FM62336""Setting Up ODINSUP" on page 83.LANSUP.SYS idxid="w391"book="_idx" docset="nw312" tidref="i3154"The LANSUP driver lets the NetWare Requester use NDIS network drivers. Use LANSUP when you want the NDIS driver to control the board. See IDREF="FM87147""Setting Up LANSUP" on page 107.ID="FM62336"Setting Up ODINSUP idxid="w392"book="_idx" docset="nw312" tidref="i4806"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.WIDTH="264"StepWIDTH="48"PageWIDTH="264"IDREF="FM33397"Part A: Binding ODI Drivers in PROTOCOL.INIWIDTH="48"IDREF="FM33397"84IDREF="FM72939"Part B: Loading ODINSUP in CONFIG.SYSIDREF="FM72939"88IDREF="FM17229"Part C: Configuring ODINSUP in NET.CFGIDREF="FM17229"90IDREF="FM42614"Sample Configuration Files for ODINSUPIDREF="FM42614"97ODINSUP supports Ethernet and Token-Ring compatible ODI drivers. It does not support ARCnet or PC Network II drivers.ID="FM33397"Part A: Binding ODI Drivers in idxid="w393"book="_idx" docset="nw312" tidref="i5631"PROTOCOL.INI idxid="w394"book="_idx" docset="nw312" tidref="i2300"In this section, you edit the PROTOCOL.INI file in a text editor to do the following:Bind the NDIS protocol stack to the ODI driversRemove the line binding the NDIS protocol stack to the NDIS MAC driversThese instructions are for LAN Server and LAN Requester v2.x.PrerequisitesInstall Extended Services on the workstation. If you have an NDIS driver for the network board in your computer, verify that you can get a Communications Manager or Database Manager connection. See the documentation for Extended Services.Install LAN Server or LAN Requester on the workstation. If you have an NDIS driver for the network board in your computer, verify that you can get connections properly on your LAN Server network. See the documentation for LAN Services.After installing all IBM software, install the NetWare Requester v2.01 as instructed in Chapter 3, "book="ws_get" docset="nw40"Installing a NetWare Workstation," in Workstation Basics and Installation. Using the ODI driver for the board, verify that you can get connections properly on your NetWare network. Chapter 5, "book="ws_get" docset="nw40"Workstation Login" in 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.Procedures 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.INIPROTOCOL.INI is located in the \IBMCOM directory on your boot drive.ID="FM52020"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_NIFBindings lines may be in any of the following sections, depending on whether you have Extended Services or LAN Services installed:  [NETBEUI_nif]  [LANDD_nif]Use a semicolon to remark out all Bindings lines found in IDREF="FM52020"Step 2.For example, your PROTOCOL.INI for a Token-Ring driver might look as follows:  [LANDD_nif]      .      .      ; Bindings = IBMTOK_NIFAfter 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 = TOKENSince 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.(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(Conditional) Bind the NDIS protocol to additional ODI drivers.To bind the NDIS protocol to more than one ODI driver, type both driver names on the same line, separated by a comma.For example, to bind to both an NE2000 driver and an NE1000 driver, type:  Bindings=ne2000,ne1000Add an empty header for the ODI drivers.Locate the MAC SECTION of the PROTOCOL.INI file.You can search for MAC SECTION.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.Save and exit the PROTOCOL.INI file.Do not exit the text editor. Go to IDREF="FM72939""Part B: Loading ODINSUP in CONFIG.SYS" on page 88.ID="FM72939"Part B: Loading ODINSUP in CONFIG.SYS idxid="w395"book="_idx" docset="nw312" tidref="i1119"idxid="w396"book="_idx" docset="nw312" tidref="i2300"In this section, you edit the CONFIG.SYS file in a text editor to do the following:Load the ODINSUP driverPrevent the NDIS network driver (MAC) from loadingPrerequisiteFollow the instructions in IDREF="FM33397""Part A: Binding ODI Drivers in PROTOCOL.INI" on page 84.Procedures Open the CONFIG.SYS file in a text editor.CONFIG.SYS is located in the root of your boot drive.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.OS2If you don't know the name of your NDIS driver, see your Extended Services or LAN Services documentation.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.OS2If you have network boards and NDIS drivers for other communications software, do not remark out the lines to load those drivers.In the NetWare Requester lines, find the line loading the ODI driver.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.SYSIf you have the Source-Routing driver, ROUTE.SYS, loaded after the ODI driver, put the ODINSUP line after the ROUTE.SYS line.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 idxid="w397"book="_idx" docset="nw312" tidref="i1119".LBL="8-1" INLINE="F"Load order requirements for ODINSUP CONFIG.SYS fileWIDTH="180"These components . . .WIDTH="240"Must load BEFORE these components . . .WIDTH="180"PROTMAN.OS2 (in OS/2 section right  after path statements)WIDTH="240"The ODINSUP protocolLSL.SYS (in NetWare Requester section)The ODI driverThe ODINSUP protocolThe ODI driver (in NetWare Requester  section)The ODINSUP protocolNWIFS.IFS idxid="w398"book="_idx" docset="nw312" tidref="i2300"idxid="w399"book="_idx" docset="nw312" tidref="i4785"(in NetWare Requester  section)idxid="w400"book="_idx" docset="nw312" tidref="i4463"NETWKSTA.200 (only in LAN Services configurations)If your file meets load order requirements, go to IDREF="FM85009"Step 8.If your file violates load order requirements, go to IDREF="FM82769"Step 7.ID="FM82769"Rearrange your CONFIG.SYS file to meet load order requirements for ODINSUP.We suggest you make your file match the sample file shown for your environment. See IDREF="FM42614"page 97 for a list of sample configuration files.After rearranging your CONFIG.SYS file, go on to IDREF="FM85009"Step 8.ID="FM85009"Save and exit the CONFIG.SYS file.Do not exit the text editor. Go to IDREF="FM17229""Part C: Configuring ODINSUP in NET.CFG" on page 90.ID="FM17229"Part C: Configuring ODINSUP in NET.CFG idxid="w401"book="_idx" docset="nw312" tidref="i2300"idxid="w402"book="_idx" docset="nw312" tidref="i4097"A NET.CFG file is required to use ODINSUP.In this section, you edit or create a NET.CFG that does the following:Enables frame types for ODINSUP.Specifies to ODINSUP the node address known by Extended Services and the format in which that address is transmitted.Binds ODINSUP to an ODI driver or drivers.Increases the size of the packet that can be transmitted through the Link Support layer (if necessary.)PrerequisitesFollow the instructions in IDREF="FM33397""Part A: Binding ODI Drivers in PROTOCOL.INI" on page 84.Follow the instructions in IDREF="FM72939""Part B: Loading ODINSUP in CONFIG.SYS" on page 88.Procedures 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.Enable frame types for ODINSUP.Type the following line at the top of the file:  link driver drivernameReplace drivername with the name of your ODI driver. For example, for a Token-Ring driver, type:  link driver tokenUnder 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 IDREF="FM82317""frame" on page 242 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_snapTo 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_snapThe 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.Whenever you edit the NET.CFG file, you must indent settings, as well as follow the other format requirements explained in IDREF="FM45501""NET.CFG Format Requirements" on page 47.ID="FM77010"Read the following chart to determine whether you need to specify a node address in the NET.CFG file.WIDTH="108"If you are using . . .WIDTH="204"Do this. . .WIDTH="108"Extended Services or  LAN Services set up  for universally- administered  addressesWIDTH="204"You do not need to specify a node address. Go  to IDREF="FM61647"Step 5.Extended Services or  LAN Services set up  for locally- administered  addressesYou must specify a idxid="w403"book="_idx" docset="nw312" tidref="i4645"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 lineNetAddress = "T400000007030"the address you specify in NET.CFG is400000007030Go to IDREF="FM52010"Step 4.ID="FM52010"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 IDREF="FM77010"Step 3.For example, to set a node address for a Token-Ring board in an Extended Services environment, type:  node address 400000007030If your board supports octet bit reversal, you can specify the address in either canonical (least significant bit first) or non-canonical (most significant bit first) format.By default, the following frames are non-canonical (MSB):Token-RingPC Network IIEthernet 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 400000007030Note 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 token     frame token-ring     frame token-ring_snap     node address 020000000E0CLIn 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 00001B1B055CIf 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.ID="FM61647"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.Type the following lines:  protocol odinsup     bind drivernameReplace 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(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 2IDREF="FM53606""Protocol ODINSUP" on page 272 explains more about the "Protocol Odinsup" option.ID="FM86068"(Optional) Increase the size of the packet transmitted through the Link Support Layer. idxid="w404"book="_idx" docset="nw312" tidref="i4890"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 1,514 (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:Under the Link driver lines, type the following line:  link supportUnder the Link Support line, type the following line:  buffers number sizeIndent the line. Replace Replacenumber with a number of buffers greater than 1. Replacebuffer_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 1,514 bytes equals 30,280 bytes.IDREF="FM30704""Link Support" on page 251 explains more information about using this option.For example, you might type:  lin idxid="w405"book="_idx" docset="nw312" tidref="i3215"k support     buffers 14 4202For Token-Ring 16/4 boards, the NetWare Requester will probably have maximum performance if you specify 14 buffers, each with a size of 4,202 bytes, as shown in the example above.ID="FM43734"Save your changes and exit the NET.CFG file.Exit the text editor.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.ID="FM42614"ID="FM83865"ID="FM91165"Sample Configuration Files for ODINSUP idxid="w406"book="_idx" docset="nw312" tidref="i4806"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 IDREF="FM62336""Setting Up ODINSUP" on page 83, your configuration files will look like the ones shown. We recommend following the steps rather than just referring to these sample files.WIDTH="372"Sample FilesWIDTH="48"PageWIDTH="372"IDREF="FM12691"LANSUP Files from an Extended Services EnvironmentWIDTH="48"IDREF="FM12691"119WIDTH="372"IDREF="FM88259"Extended Services Token-Ring PROTOCOL.INI file for ODINSUPWIDTH="48"IDREF="FM88259"98IDREF="FM38988"Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 1)IDREF="FM38988"99IDREF="FM95138"Extended Services Token-Ring CONFIG.SYS file for ODINSUP (part 2)IDREF="FM95138"100IDREF="FM88268"Extended Services Token-Ring NET.CFG file for ODINSUPIDREF="FM88268"101WIDTH="372"IDREF="FM52892"LANSUP Files from a LAN Requester EnvironmentWIDTH="48"IDREF="FM52892"124IDREF="FM24823"LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 1)IDREF="FM24823"102IDREF="FM21041"LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP (part 2)IDREF="FM21041"103IDREF="FM44967"LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 1)IDREF="FM44967"104IDREF="FM47983"LAN Requester Token-Ring CONFIG.SYS file for ODINSUP (part 2)IDREF="FM47983"105IDREF="FM71297"LAN Requester Token-Ring NET.CFG file for ODINSUPIDREF="FM71297"106ID="FM12691"ODINSUP Files from an Extended Services EnvironmentThese files came from a computer with the following software installed:ID="FM61515"OS/2 v2.0Extended Services v1.0 (locally-administered addresses)NetWare Requester v2.01 with ODINSUP.The computer used Communications Manager to make a LAN connection to an IBM host.IDREF="FM88259"Figure 8-1 illustrates a PROTOCOL.INI file for this environment.LBL="8-1"ID="FM88259"Extended Services Token-Ring PROTOCOL.INI file for ODINSUP idxid="w407"book="_idx" docset="nw312" tidref="i2300"idxid="w408"book="_idx" docset="nw312" tidref="i5631"FILE="c312q50a.pbm"IDREF="FM38988"Figure 8-2   illustrates a CONFIG.SYS file for the environment shown on IDREF="FM61515"page 98.LBL="8-2"ID="FM38988"Extended Services Token-Ring CONFIG.SYS file for ODINSUP idxid="w409"book="_idx" docset="nw312" tidref="i2300"idxid="w410"book="_idx" docset="nw312" tidref="i1119"FILE="c312q18a.pbm"IDREF="FM88268"Figure 8-4 illustrates a NET.CFG file for the environment shown on IDREF="FM61515"page 98.LBL="8-4"ID="FM88268"Extended Services Token-Ring NET.CFG file for ODINSUP idxid="w411"book="_idx" docset="nw312" tidref="i2300"idxid="w412"book="_idx" docset="nw312" tidref="i4097"FILE="c312q51a.pbm"ID="FM52892"ODINSUP Files from a LAN Requester EnvironmentThese files came from a computer with the following software installed:ID="FM52187"OS/2 v2.0LAN Requester v2.0NetWare Requester v2.01 with ODINSUPIDREF="FM24823"Figure 8-5 illustrates a Protocol.INI for this environment. IDREF="FM44967"Figure 8-7   illustrates a CONFIG.SYS file for this environment.LBL="8-5"ID="FM24823"LAN Requester Token-Ring PROTOCOL.INI file for ODINSUP idxid="w413"book="_idx" docset="nw312" tidref="i5631"idxid="w414"book="_idx" docset="nw312" tidref="i2300"FILE="c312q57a.pbm"LBL="8-7"ID="FM44967"LAN Requester Token-Ring CONFIG.SYS file for ODINSUP idxid="w415"book="_idx" docset="nw312" tidref="i1119"idxid="w416"book="_idx" docset="nw312" tidref="i2300"FILE="c312q55a.pbm"IDREF="FM71297"Figure 8-9 illustrates a NET.CFG file for the environment shown on IDREF="FM52187"page 101.LBL="8-9"ID="FM71297"LAN Requester Token-Ring NET.CFG file for ODINSUP idxid="w417"book="_idx" docset="nw312" tidref="i2300"idxid="w418"book="_idx" docset="nw312" tidref="i4097"FILE="c312q56a.pbm"ID="FM87147"Setting Up LANSUP idxid="w419"book="_idx" docset="nw312" tidref="i3154"idxid="w420"book="_idx" docset="nw312" tidref="i4342"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.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:WIDTH="264"StepWIDTH="48"PageWIDTH="264"IDREF="FM11232"Part A: Loading LANSUP in CONFIG.SYSWIDTH="48"IDREF="FM11232"108IDREF="FM91745"Part B: Configuring LANSUP in NET.CFGIDREF="FM91745"110IDREF="FM86400"Part C: Increasing Packet Size for LANSUP (Optional)IDREF="FM86400"115IDREF="FM46364"Sample Configuration Files for LANSUPIDREF="FM46364"118Novell's LAN Support (LANSUP) device driver replaces the CMGRLAN idxid="w421"book="_idx" docset="nw312" tidref="i999"and TOKENEE idxid="w422"book="_idx" docset="nw312" tidref="i6837"modules used in the NetWare Requester v1.3.  CMGRLAN and TOKENEE are not supported in the NetWare Requester v2.01.LANSUP works with idxid="w423"book="_idx" docset="nw312" tidref="i4073"NDIS drivers for PC Network II, Ethernet, and Token-Ring network boards.ID="FM11232"Part A: Loading LANSUP in CONFIG.SYS idxid="w424"book="_idx" docset="nw312" tidref="i1119"idxid="w425"book="_idx" docset="nw312" tidref="i2300"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.PrerequisitesInstall Extended Services on the workstation. Verify that you can get a Communications Manager or Database Manager connection. See the documentation for Extended Services.Install LAN Server or LAN Requester on the workstation. Verify that you can get a connection on your LAN Server network. See the documentation for LAN Services.Procedures  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.Choose "Requester on Workstation" from the "Installation" menu.Verify the target and source directory and choose "OK."Select an action from the "Requester Installation" screen based on whether the Requester is installed:If the Requester is not installed, select "Edit CONFIG.SYS and Copy All Files . . . " and choose "OK."If the Requester is already installed, select "Only Edit CONFIG.SYS . . ." and choose "OK."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.SYSSelect your preferences for NetWare support for DOS and Windows applications and choose "Continue . . ."Select your preferences for optional protocol support and choose "Save . . ."Verify the filename and location and choose "OK."If you have not installed the Requester, the "Copy Requester Files" screen appears. Continue with IDREF="FM63326"Step 9.If you have installed the Requester, the main installation menu appears. Go to IDREF="FM91745""Part B: Configuring LANSUP in NET.CFG" on page 110.ID="FM63326"Choose "Copy" and follow the screens to finish installing the Requester.When the main menu returns, go to IDREF="FM91745""Part B: Configuring LANSUP in NET.CFG" on page 110.ID="FM91745"Part B: Configuring LANSUP in NET.CFG idxid="w426"book="_idx" docset="nw312" tidref="i4097"idxid="w427"book="_idx" docset="nw312" tidref="i1165"idxid="w428"book="_idx" docset="nw312" tidref="i2300"A NET.CFG file is required to use LANSUP.In this section, you edit or create a NET.CFG file that does the following:Enables frame types for LANSUPSpecifies to LANSUP the node address used by the network board and the format that address is transmitted inIn this section, you also decide whether to increase the size of the packet that can be transmitted through LANSUP.PrerequisiteInstall the NetWare Requester with LANSUP by following the instructions in IDREF="FM11232""Part A: Loading LANSUP in CONFIG.SYS" on page 108.Procedures 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 IDREF="FM11232""Part A: Loading LANSUP in CONFIG.SYS" on page 108 and then return here.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.In the "Current NET.CFG File Contents" box, type the following line:  link driver lansupUnder the Link Driver line, type lines to enable at least one frame type.LANSUP can be used with Ethernet, Token-Ring, and PCNet boards. IDREF="FM86270"Table 8-2 lists the supported frame types for LANSUP:LBL="8-2" INLINE="F"ID="FM86270"List of frame types supported by LANSUPWIDTH="120"BoardWIDTH="192"Frame types supportedWIDTH="120"Token-RingWIDTH="192"TOKEN-RINGTOKEN-RING_SNAPEthernetETHERNET_802.2ETHERNET_SNAPPCNetIBM_PCN2_802.2IBM_PCN2_SNAPFor example, to enable a frame types for Token-Ring, type the following:  link driver lansup     frame token-ringTo enable both frame types for Ethernet, type the following:  link driver lansup     frame ethernet_802.2     frame ethernet_snapThe 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 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.Read the following chart to determine what node address you should use.WIDTH="108"If you are using . . .WIDTH="204"Get the node address from here . . .WIDTH="108"Extended Services or  LAN Services set up  for universally- administered  addressesWIDTH="204"Use the address assigned to the board by the  vendor.Extended Services or  LAN Services set up  for locally- administered  addressesUse the idxid="w429"book="_idx" docset="nw312" tidref="i4645"address shown in the "NetAddress"  parameter in the PROTOCOL.INI file. Remove  the T first. For example, if the PROTOCOL.INI  file shows the lineNetAddress = "T400000007030"the address you specify in NET.CFG is400000007030In 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 10005a8c62d4If your board supports octet bit reversal, you can specify the address in either canonical (least significant bit first) or non-canonical (most significant bit first) format.By default, the following frames are non-canonical (MSB):Token-RingPC Network IIEthernet frames are canonical (LSB).If you specify the address in the format that is not default, you must type an M (most significant bit first) or L (least significant bit first) at the end of the address to tell ODINSUP which format you used.For example, for a Token-Ring environment using the default format for the node address, the "Current NET.CFG file contents" box should contain lines similar to the following:  link driver lansup     frame token-ring     node address 10005a8c62d4Note 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 08005A31462BLIn this case, an L after the node address is needed because the address is specified in least significant bit first format, the format which is not the default for Token-Ring.For an Ethernet environment, the "Current NET.CFG file contents" box should contain lines similar to the following:  link driver lansup     frame ethernet_802.2     frame ethernet_snap     node address 00001B1B055CIf 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.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.ID="FM15948"If you want to increase the packet size, go to IDREF="FM86400""Part C: Increasing Packet Size for LANSUP (Optional)" on page 115.If you do not want to increase the packet size, go to IDREF="FM68193"Step 8.ID="FM68193"Choose "Save . . ."Exit the NetWare Requester Installation program.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.ID="FM86400"Part C: Increasing Packet Size for LANSUP (Optional) idxid="w430"book="_idx" docset="nw312" tidref="i4890"Only do this section if you were directed to come here in IDREF="FM15948"Step 7a on page 114.In this section, youEdit the NET.CFG file to increase the size of the packet that can be transmitted through LANSUP.Edit the PROTOCOL.INI to increase the size of the packet that can be transmitted through the NDIS drivers.PrerequisitesInstall the NetWare Requester with LANSUP by following the instructions in IDREF="FM33397""Part A: Binding ODI Drivers in PROTOCOL.INI" on page 84.Follow the instructions in IDREF="FM91745""Part B: Configuring LANSUP in NET.CFG" on page 110.Procedures 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 IDREF="FM91745""Part B: Configuring LANSUP in NET.CFG" on page 110. Then come back to this step.Select "buffers" under "Link Support."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.ID="FM82316"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 Replacenumber with a number of buffers greater than 1. Replacebuffer_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 1,514 bytes equals 30,280 bytes.IDREF="FM30704""Link Support" on page 251 explains more information about using this option.For example, you might type:  lin idxid="w431"book="_idx" docset="nw312" tidref="i3215"k support     buffers 14 4202For Token-Ring 16/4 boards, the NetWare Requester will probably have maximum performance if you specify 14 buffers, each with a size of 4,202 bytes, as shown in the example above.Choose "Save . . ."Exit the NetWare Requester installation program.Without rebooting your machine, go to Step 7.Run the IBM LAPS program to edit PROTOCOL.INI.. idxid="w432"book="_idx" docset="nw312" tidref="i2300"idxid="w433"book="_idx" docset="nw312" tidref="i5631"Change the transmit buffer size to a number 6 bytes larger than the number you set for the Link Support buffer size in IDREF="FM82316"Step 4.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 = 4208Exit the LAPS program.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.ID="FM46364"Sample Configuration Files for LANSUPThis 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 IDREF="FM87147""Setting Up LANSUP" on page 107, your configuration files will look like the ones shown. We recommend following the steps rather than just referring to these sample files.WIDTH="372"Sample FilesWIDTH="48"PageWIDTH="372"IDREF="FM12691"LANSUP Files from an Extended Services EnvironmentWIDTH="48"IDREF="FM12691"119WIDTH="372"IDREF="FM28564"Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 1)WIDTH="48"IDREF="FM28564"120IDREF="FM23164"Extended Services Token-Ring CONFIG.SYS file for LANSUP (part 2)IDREF="FM23164"121IDREF="FM24616"Extended Services Token-Ring NET.CFG file for LANSUPIDREF="FM24616"122IDREF="FM12790"Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 2)IDREF="FM12790"124IDREF="FM12790"Extended Services Token-Ring PROTOCOL.INI file for LANSUP (part 2)IDREF="FM12790"124WIDTH="372"IDREF="FM52892"LANSUP Files from a LAN Requester EnvironmentWIDTH="48"IDREF="FM52892"124IDREF="FM80194"LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 1)IDREF="FM80194"125IDREF="FM75181"LAN Requester Token-Ring CONFIG.SYS file for LANSUP (part 2)IDREF="FM75181"126IDREF="FM20866"LAN Requester Token-Ring NET.CFG file for LANSUPIDREF="FM20866"127IDREF="FM71555"LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 1)IDREF="FM71555"128IDREF="FM64302"LAN Requester Token-Ring PROTOCOL.INI file for LANSUP (part 2)IDREF="FM64302"129ID="FM12691"LANSUP Files from an Extended Services EnvironmentThese files came from a computer with the following software installed:ID="FM55663"OS/2 v2.0Extended Services v1.0 (locally-administered addresses)NetWare Requester v2.01 with LANSUP.The computer used Communications Manager to make a LAN connection to an IBM host. IDREF="FM28564"Figure 8-10 illustrates a CONFIG.SYS file.LBL="8-10"ID="FM28564"Extended Services Token-Ring CONFIG.SYS file for LANSUP idxid="w434"book="_idx" docset="nw312" tidref="i1119"idxid="w435"book="_idx" docset="nw312" tidref="i2300"FILE="c312q52a.pbm"IDREF="FM24616"Figure 8-12 illustrates a NET.CFG for the environment shown on IDREF="FM55663"page 119.LBL="8-12"ID="FM24616"Extended Services Token-Ring NET.CFG file for LANSUP idxid="w436"book="_idx" docset="nw312" tidref="i4097"idxid="w437"book="_idx" docset="nw312" tidref="i2300"FILE="c312q54a.pbm"IDREF="FM12790"Figure 8-13 illustrates a PROTOCOL.INI for the environment shown on IDREF="FM55663"page 119.LBL="8-13"ID="FM12790"Extended Services Token-Ring PROTOCOL.INI file for LANSUP idxid="w438"book="_idx" docset="nw312" tidref="i5631"idxid="w439"book="_idx" docset="nw312" tidref="i2300"FILE="c312q53a.pbm"ID="FM52892"LANSUP Files from a LAN Requester EnvironmentThese files came from a computer with the following software installed:ID="FM15531"OS/2 v2.0LAN Requester v2.0NetWare Requester v2.01 with LANSUPIDREF="FM80194"Figure 8-15   illustrates a CONFIG.SYS file for this environment.LBL="8-15"ID="FM80194"LAN Requester Token-Ring CONFIG.SYS file for LANSUP idxid="w440"book="_idx" docset="nw312" tidref="i1119"idxid="w441"book="_idx" docset="nw312" tidref="i2300"FILE="c312q60a.pbm"IDREF="FM20866"Figure 8-17 illustrates a NET.CFG for the environment shown on IDREF="FM15531"page 124.LBL="8-17"ID="FM20866"LAN Requester Token-Ring NET.CFG file for LANSUP idxid="w442"book="_idx" docset="nw312" tidref="i4097"idxid="w443"book="_idx" docset="nw312" tidref="i2300"FILE="c312q59a.pbm"IDREF="FM71555"Figure 8-18   illustrates a PROTOCOL.INI for the environment shown on IDREF="FM15531"page 124.LBL="8-18"ID="FM71555"LAN Requester Token-Ring PROTOCOL.INI file for LANSUP idxid="w444"book="_idx" docset="nw312" tidref="i5631"idxid="w445"book="_idx" docset="nw312" tidref="i2300"FILE="c312q58a.pbm"LBL="9"ID="FM34869"Setting Up Named Pipes and NetBIOS Protocols idxid="w446"book="_idx" docset="nw312" tidref="i1622"idxid="w447"book="_idx" docset="nw312" tidref="i6245"idxid="w448"book="_idx" docset="nw312" tidref="i993"WIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM76859"About the Protocol Support in the NetWare RequesterWIDTH="48"IDREF="FM76859"132IDREF="FM25310"Setting Up Named Pipes for OS/2IDREF="FM25310"135IDREF="FM21725"Setting Up Named Pipes for DOS and WindowsIDREF="FM21725"143IDREF="FM85973"Setting Up NetBIOS for OS/2IDREF="FM85973"146IDREF="FM62792"Setting Up NetBIOS for DOS and WindowsIDREF="FM62792"170This chapter explains how to install and configure the Named Pipes and NetBIOS protocols. ID="FM76859"About the Protocol Support in the NetWare RequesterNovell provides four kinds of protocol support with the NetWare Requester for OS/2: idxid="w449"book="_idx" docset="nw312" tidref="i5640"IPXSPXNamed PipesNetBIOS (emulation)idxid="w450"book="_idx" docset="nw312" tidref="i5640"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:Distributed application clients and serversNon-NetWare network clients and serversTerminals connected to mainframes or minicomputersFor 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. IDREF="FM99461"Figure 9-1 illustrates the components of a idxid="w451"book="_idx" docset="nw312" tidref="i1622"distributed application network. Note that protocol support software usually must be installed independent of installing the distributed application software. LBL="9-1"ID="FM99461"Protocol software is separate from distributed application softwareFILE="c312q41a.pbm"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. IDREF="FM34504"Figure 9-2 shows how a NetWare network and a distributed application network share cabling. LBL="9-2"ID="FM34504"A distributed application on a NetWare networkFILE="c312q42a.pbm"ID="FM25310"Setting Up Named Pipes for OS/2You 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. ID="FM26379"Installing Named Pipes for OS/2 idxid="w452"book="_idx" docset="nw312" tidref="i2869"idxid="w453"book="_idx" docset="nw312" tidref="i4007"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.IDREF="FM57835""Protocol Requests from OS/2 Sessions" on page 291 explains how Novell's Named Pipes support for OS/2 works. PrerequisiteInstall your Named Pipes distributed application. See the documentation for your application. ProceduresStart 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. Choose "Requester on Workstation" from the "Installation" menu. Verify the target and source directory and choose "OK."Select an action from the "Requester Installation" screen based on whether the Requester is installed:If the Requester is not installed, select "Edit CONFIG.SYS and Copy All Files . . . " and choose "OK."If the Requester is already installed, select "Only Edit CONFIG.SYS . . ." and choose "OK."Select the ODI driver for your network board and choose "Continue. . ."Select your preferences for NetWare support for DOS and Windows applications and choose "Continue . . ."Select "Remote Named Pipes Support." Set up your workstation as a Named Pipes client or server.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 theIDREF="FM50371""Configuring Named Pipes for OS/2" section, you will be told to do the IDREF="FM91398""Special Instructions for SQL Client Workstations" section. 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. Choose "Save . . ." Verify the filename and location and choose "OK."If you have not previously installed the Requester, the "Copy Requester Files" screen appears. Continue with IDREF="FM28749"Step 11. If you have previously installed the Requester, the main installation menu appears. Go to IDREF="FM50371""Configuring Named Pipes for OS/2" on page 137. ID="FM28749"Choose "Copy" and follow the screens to finish installing the Requester. When the main menu returns, go to IDREF="FM50371""Configuring Named Pipes for OS/2" on page 137. ID="FM50371"Configuring Named Pipes for OS/2 idxid="w454"book="_idx" docset="nw312" tidref="i4007"idxid="w455"book="_idx" docset="nw312" tidref="i1165"Novell's Named Pipes support comes with default configuration settings. You may want to customize the configuration. Follow the instructions below toDetermine whether you need to change the default configuration for Named Pipes and SPX, andChange the configuration if necessary. You can change the configuration for such features as Available number of client and server sessionsNumber of service threads available for Named Pipes communicationNumber of SPX sessions available for Named Pipes and other SPX communication (Named Pipes uses SPX)PrerequisiteThe NetWare Requester for OS/2 must be installed. If it is not installed, do the steps in IDREF="FM26379""Installing Named Pipes for OS/2" on page 135. ProceduresStart 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.Choose "This workstation . . ." from the "Configuration" menu. Verify the location of the NET.CFG file and choose "Edit."The "Edit NET.CFG" window appears. See IDREF="FM56085"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:LBL="9-1" INLINE="F"Key definitions for the NET.CFG windowWIDTH="120"To do this . . .WIDTH="192"Use these keys . . . .WIDTH="120"Highlight textWIDTH="192"Click and drag with the mouse, or move the  cursor with the arrow keys while holding  down the <Shift> keyCopy 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>LBL="9-3"ID="FM56085"Editing NET.CFG for Named PipesFILE="c312q69a.pbm"Select "Named Pipes" from the "NET.CFG Options" box on the left of your screen. 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.Select one of the three settings. For example, select "client sessions."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. (Optional) If you decide to change the configuration, type the configuration 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. Select "Protocol Stack SPX" from the "NET.CFG Options" box on the left of your screen. Select the "sessions" setting under "Protocol Stack SPX."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. (Optional) If you decide to change the configuration, type the configuration 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. Choose "Save."Exit the NetWare Requester installation program. If your workstation will be a client for the SQL Server distributed application, close the installation program and go to IDREF="FM91398""Special Instructions for SQL Client Workstations" on page 141. Do not reboot yet.If your workstation will not be a SQL client, close the installation program and use the OS/2 "Shutdown" feature to reboot your computer.ID="FM91398"Special Instructions for SQL Client Workstations idxid="w456"book="_idx" docset="nw312" tidref="i6461"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 idxid="w457"book="_idx" docset="nw312" tidref="i2300"idxid="w458"book="_idx" docset="nw312" tidref="i4162"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:ProceduresInsert the WSOS2_1 diskette into a floppy drive.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 would 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\BINPBe sure to copy the files from the \SQL directory, since there is also a NETAPI.DLL in the root directory on the diskette. The two NETAPI.DLL files are not the same. The \SQL NETAPI.DLL emulates certain features of LAN 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. Open your CONFIG.SYS file in a text editor. 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. Save and exit the CONFIG.SYS file. 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. ID="FM21725"Setting Up Named Pipes for DOS and Windows idxid="w459"book="_idx" docset="nw312" tidref="i4007"idxid="w460"book="_idx" docset="nw312" tidref="i2869"idxid="w461"book="_idx" docset="nw312" tidref="i7313"This section applies to virtual DOS and Windows sessions only. See the book="ws_dos" docset="nw40"NetWare Workstation for DOS and Windows manual 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:PrerequisitesEnable IPX support for virtual sessions. IDREF="FM75599"Chapter 3, "Network Access From Virtual DOS and Windows," explains how to do this. Enable Named Pipes support for OS/2 sessions. IDREF="FM25310""Setting Up Named Pipes for OS/2" on page 135 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:WIDTH="120"If you want Named Pipes forWIDTH="192"Go toWIDTH="120"Virtual Windows sessionsWIDTH="192"IDREF="FM67244""For Virtual Windows Named Pipes Clients"  on page 144Sessions with the  DOS_STARTUP_DRIVE  featureIDREF="FM19464""For Sessions with DOS_STARTUP_DRIVE  Set" on page 144ID="FM67244"For Virtual Windows Named Pipes Clients idxid="w462"book="_idx" docset="nw312" tidref="i4007"Copy the idxid="w463"book="_idx" docset="nw312" tidref="i2300"idxid="w464"book="_idx" docset="nw312" tidref="i4162"NETAPI.DLL file from the \WINDOWS.NP subdirectory on the WSOS2_1 diskette to one of the following locations on your hard disk:The \OS2\MDOS\WINOS2 subdirectory (since this directory contains WINOS2.COM)The \OS2\MDOS\WINOS2\SYSTEM subdirectory (since this directory contains the Windows KERNEL.EXE)The directory of the application that runs Named PipesThis 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. IDREF="FM33194""Protocol Requests from DOS/Windows Sessions" on page 303 explains how Named Pipes support works for virtual DOS and Windows clients.ID="FM98918"ID="FM19464"For Sessions with idxid="w465"book="_idx" docset="nw312" tidref="i4007"DOS_STARTUP_DRIVE Set idxid="w466"book="_idx" docset="nw312" tidref="i1711"idxid="w467"book="_idx" docset="nw312" tidref="i7327"Sessions set with DOS_STARTUP_DRIVE boot from a version of idxid="w468"book="_idx" docset="nw312" tidref="i2533"idxid="w469"book="_idx" docset="nw312" tidref="i7329"idxid="w470"book="_idx" docset="nw312" tidref="i1638"DOS other than the one included in OS/2. The OS/2 online "Master Help Index" explains more about the DOS_STARTUP_DRIVE feature. If you are using idxid="w471"book="_idx" docset="nw312" tidref="i2300"DOS_STARTUP_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_STARTUP_DRIVE session. (The CONFIG.SYS file is bound into the image file you boot the session from. See your OS/2 documentation.)To load the FSFILTER.SYS driver, do the following:ProceduresOpen the CONFIG.SYS file for the DOS_STARTUP_DRIVE session in a text editor. On a new line in the file, type a line to load FSFILTER.SYS.For example, you might type:  DEVICE=C:\OS2\MDOS\FSFILTER.SYSSave 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_STARTUP_DRIVE session. It will conflict with the OS/2 Named Pipes driver. ID="FM85973"Setting Up NetBIOS for OS/2 idxid="w472"book="_idx" docset="nw312" tidref="i4187"idxid="w473"book="_idx" docset="nw312" tidref="i4169"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 idxid="w474"book="_idx" docset="nw312" tidref="i4187"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. IDREF="FM57835""Protocol Requests from OS/2 Sessions" on page 291 explains more about how Novell's NetBIOS driver works. WIDTH="264"TopicsWIDTH="48"PageWIDTH="264"IDREF="FM75002"Determining Which NetBIOS Drivers to Set UpWIDTH="48"IDREF="FM75002"146IDREF="FM79688"Setting Up the Novell NetBIOS DriverIDREF="FM79688"151IDREF="FM40784"Configuring NETBIOS.OS2 with PROTOCOL.INIIDREF="FM40784"158IDREF="FM30479"Configuring NETWKSTA.200 with IBMLAN.INIIDREF="FM30479"163ID="FM75002"Determining Which NetBIOS Drivers to Set UpUse 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 onWhether you have Extended Services or LAN Services installed on your workstation, andThe interface used by your application.Your Installed IBM SoftwareNetBIOS support is provided withExtended Services idxid="w475"book="_idx" docset="nw312" tidref="i1945"Extended Services NetBIOS support is included in the LAPS programs. NetBIOS-related pieces of LAPS idxid="w476"book="_idx" docset="nw312" tidref="i3159"are NETAPI.DLL idxid="w477"book="_idx" docset="nw312" tidref="i2699"idxid="w478"book="_idx" docset="nw312" tidref="i2300"idxid="w479"book="_idx" docset="nw312" tidref="i4162"ACSNETB.DLLNETBIOS.OS2NETBEUI.OS2LANPDD, and LANVDDLAN Services idxid="w480"book="_idx" docset="nw312" tidref="i3144"LAN Services NetBIOS support is included in the LAPS program and in NETWKSTA.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. However, the files shown may also be included in other packages. For example, you may have received the IBM LAPS program without receiving Extended Services. In this case, you might 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. Your Application's InterfaceOS/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:ACSNETB.DLL idxid="w481"book="_idx" docset="nw312" tidref="i2300"idxid="w482"book="_idx" docset="nw312" tidref="i139"idxid="w483"book="_idx" docset="nw312" tidref="i4034"idxid="w484"book="_idx" docset="nw312" tidref="i4185"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. The NETAPI.DLL idxid="w485"book="_idx" docset="nw312" tidref="i2300"idxid="w486"book="_idx" docset="nw312" tidref="i4162"idxid="w487"book="_idx" docset="nw312" tidref="i2704"idxid="w488"book="_idx" docset="nw312" tidref="i4191"This is the original OS/2 NetBIOS Submit interface. This interface was supported by idxid="w489"book="_idx" docset="nw312" tidref="i3131"LAN Manager and LAN Server idxid="w490"book="_idx" docset="nw312" tidref="i3147"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 IDREF="FM87108"Figure 9-4 or IDREF="FM69194"Figure 9-5 to seeWhether the IBM or Novell NetBIOS driver can be accessed by your application, andWhere to find instructions on setting up the drivers.LBL="9-4"ID="FM87108"ID="FM16027"Determine what idxid="w491"book="_idx" docset="nw312" tidref="i4169"NetBIOS support you have for NetBIOS 3.0 (NB30) applicationsFILE="c312q10a.pbm"LBL="9-5"ID="FM69194"ID="FM87108"ID="FM16027"Determine what NetBIOS support you have for NetBIOS Submit applicationsFILE="c312q09a.pbm"ID="FM79688"Setting Up the Novell NetBIOS DriverDo this section only if you were directed here from the flow chart in IDREF="FM69194"Figure 9-5 because you Have a NetBIOS Submit applicationHave Extended ServicesDo not have LAN ServicesAs IDREF="FM47459"Figure 9-7 shows, the idxid="w492"book="_idx" docset="nw312" tidref="i4169"Novell NetBIOS driver interfaces with Novell's NETAPI.DLL file when you do not have Extended Services.LBL="9-6"ID="FM47459"NetBIOS Requests through Novell's NetBIOS DriverFILE="c312q63a.pbm"As IDREF="FM47459"Figure 9-7 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. LBL="9-7"ID="FM47459"NetBIOS Requests through Novell's NetBIOS Driver with Extended Services installedFILE="c312q75a.pbm"Follow the procedures in IDREF="FM17293""Installing the Driver" on page 153 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 idxid="w493"book="_idx" docset="nw312" tidref="i2300"idxid="w494"book="_idx" docset="nw312" tidref="i4162"NETAPI.DLL file from IBM. The one shipped with base Extended Services 1.0 does not provide the intended NetBIOS support. ID="FM17293"Installing the Driver idxid="w495"book="_idx" docset="nw312" tidref="i2869"idxid="w496"book="_idx" docset="nw312" tidref="i4169"PrerequisitesInstall Extended Services if you have it. See the IBM documentation for Extended Services. Install your NetBIOS application. See the documentation for your application. ProceduresYou 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. 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. Choose "Requester on Workstation" from the "Installation" menu. Verify the target and source directory and choose "OK."Select an action from the "Requester Installation" screen based on whether the Requester is installed:If the Requester is not installed, select "Edit CONFIG.SYS and Copy All Files . . . " and choose "OK."If the Requester is already installed, select "Only Edit CONFIG.SYS . . ." and choose "OK."Select the ODI driver for your network board and choose "Continue. . ."Select your preferences for NetWare support for DOS and Windows applications and choose "Continue . . ."Select "NetBIOS Emulation for OS/2 Sessions." Choose "Save . . ." Verify the filename and location and choose "OK."If you have not previously installed the Requester, the "Copy Requester Files" screen appears. Continue with IDREF="FM32721"Step 10. If you have previously installed the Requester, the main installation menu appears. Go to IDREF="FM24938""Configuring the Driver" on page 154. ID="FM32721"Choose "Copy" and follow the screens to finish installing the Requester. When the main menu returns, go to IDREF="FM24938""Configuring the Driver" on page 154. ID="FM24938"Configuring the Driver idxid="w497"book="_idx" docset="nw312" tidref="i4169"idxid="w498"book="_idx" docset="nw312" tidref="i1165"Novell's NetBIOS driver comes with default configuration settings. You may want to customize the configuration. Follow the instructions below toDetermine whether you need to change the default configuration for NetWare NetBIOS, andChange the configuration if necessary. You can change the configuration to manage such features asNamesSessionsCommands If you do not know what NetBIOS names, sessions, and commands are, see the documentation for your NetBIOS application. PrerequisiteThe NetWare Requester for OS/2 must be installed. If it is not installed, do the steps in IDREF="FM17293""Installing the Driver" on page 153. ProceduresStart 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.Choose "This workstation . . ." from the "Configuration" menu. Verify the location of the NET.CFG file and choose "Edit."The "Edit NET.CFG" window appears. See IDREF="FM27333"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:LBL="9-2" INLINE="F"Key definitions for the NET.CFG windowWIDTH="120"To do this . . .WIDTH="192"Use these keys . . . .WIDTH="120"Highlight textWIDTH="192"Click and drag with the mouse, or move the  cursor with the arrow keys while holding  down the <Shift> keyCopy 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>LBL="9-8"ID="FM27333"Editing NET.CFG for NetBIOSFILE="c312q68a.pbm"Select "NetWare NetBIOS" from the "NET.CFG Options" box on the left of your screen. 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.ID="FM97996"Select one of the settings. For example, select "abort timeout."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. ID="FM16563"(Optional) If you decide to change the configuration, type the configuration 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. ID="FM40306"Repeat IDREF="FM97996"Steps 5a through IDREF="FM16563"5c for each setting. Choose "Save."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:IDREF="FM40784""Configuring NETBIOS.OS2 with PROTOCOL.INI" on page 158IDREF="FM30479""Configuring NETWKSTA.200 with IBMLAN.INI" on page 163If you do not know which of these two sections to read, go to IDREF="FM75002""Determining Which NetBIOS Drivers to Set Up" on page 146. ID="FM40784"Configuring NETBIOS.OS2 idxid="w499"book="_idx" docset="nw312" tidref="i2300"idxid="w500"book="_idx" docset="nw312" tidref="i4192"with PROTOCOL.INI idxid="w501"book="_idx" docset="nw312" tidref="i2300"idxid="w502"book="_idx" docset="nw312" tidref="i5631"Do this section only if you were directed here from the flow chart in IDREF="FM16027"Figure 9-4 because you Have the LAPS program, and Have a NetBIOS 3.0 application. As IDREF="FM52552"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 NETBEUI.OS2, IBM's NetBIOS driver, orNETBIOS.SYS, Novell's NetBIOS driverThis 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. LBL="9-9"ID="FM52552"NetBIOS Requests through NETBIOS.OS2FILE="c312q65a.pbm"PrerequisitesInstall Extended Services with NetBIOS support. Verify that you can get a NetBIOS connection.Install LAN Services (NetBIOS support is installed by default). Verify that you can get a LAN connection. Do the steps in IDREF="FM79688""Setting Up the Novell NetBIOS Driver" on page 151 to install the NetWare Requester with the Novell NetBIOS driver. ProceduresIn this procedure, you edit the PROTOCOL.INI file to define a virtual adapter for the Novell and IBM NetBIOS drivers.  Open the PROTOCOL.INI file in a text editor. For example, to use the OS/2 System Editor at the command line, you would type:  E C:\IBMCOM\PROTOCOL.INIPROTOCOL.INI is located in the \IBMCOM directory. ID="FM52020"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.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. 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  idxid="w503"book="_idx" docset="nw312" tidref="i142"ADAPTERa = b,c,sessions,commands,namesIf you have existing ADAPTER lines, leave them. Replace the variables in the line with values shown in the following chart:LBL="9-3" INLINE="F"Paremeters for defining dual NetBIOS in PROTOCOL.INIWIDTH="72"VariableWIDTH="348"Meaning of variableWIDTH="72"ADAPTERWIDTH="348"Adapter is a key word for NETBIOS.OS2. It is not case-sensitive.aReplace a with a number from 0 to 3. This is the adapter number used by the  application.When specifying an adapter number:Do not use the same number that is used in any other adapter statements. Each  adapter number can only be defined to one NetBIOS driver.Do not skip adapter numbers. For example, if you have an existing adapter  statement that uses ADAPTER0, use ADAPTER1 for your next adapter  statement. bReplace b with the device name for the NetBIOS driver. NETBIOS.OS2 recognizes  this name when determining which driver to pass NetBIOS calls to. Replace b with IPXNB$ for the Novell NetBIOS driver. Replace b with NETBEUI$ for the IBM NetBIOS driver. cReplace c with a number from 0 to 3. This number is the virtual adapter number  used by the target NetBIOS driver. For Novell's NetBIOS driver, always specify 0. For IBM's NetBIOS driver, specify whichever virtual adapter you want used. See  the Extended Services documentation on NETBEUI.OS2 for more information  on how it uses virtual adapters. sessions idxid="w504"book="_idx" docset="nw312" tidref="i4169"Replace sessions with the number of NetBIOS sessions you want allocated to  NetBIOS 3.0 applications. This number specifies the maximum number of sessions  that can be active between NETBIOS.OS2 and Novell's NetBIOS driver. Novell's NetBIOS driver is configured 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 lowest. 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 idxid="w505"book="_idx" docset="nw312" tidref="i4169"Replace commands with the number of NetBIOS commands you want allocated to  the NB30 NetBIOS application. This number specifies the maximum number of  commands that can be active between NETBIOS.OS2 and Novell's NetBIOS driver. Novell's NetBIOS driver is configured 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. names idxid="w506"book="_idx" docset="nw312" tidref="i4169"Replace names with the number of NetBIOS names you want allocated to the NB30  application. This number specifies the maximum number of names that can be  active between NETBIOS.OS2 and Novell's NetBIOS driver. Novell's NetBIOS driver is configured 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. 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,8For more information about defining adapters in NETBIOS.OS2, see your Extended Services documentation. Insert a blank line at the end of the file. ID="FM68743"Save the PROTOCOL.INI file and exit your text editor.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. ID="FM30479"Configuring NETWKSTA.200 idxid="w507"book="_idx" docset="nw312" tidref="i2300"idxid="w508"book="_idx" docset="nw312" tidref="i2706"idxid="w509"book="_idx" docset="nw312" tidref="i2300"idxid="w510"book="_idx" docset="nw312" tidref="i4465"with IBMLAN.INIDo this section only if you were directed here from the flow chart on IDREF="FM69194"Figure 9-5 because you Have a NetBIOS Submit application, and Have LAN ServicesAs IDREF="FM98073"Figure 9-10 shows, NETAPI.DLL interfaces with IBM's NETWKSTA.200. The idxid="w511"book="_idx" docset="nw312" tidref="i2300"idxid="w512"book="_idx" docset="nw312" tidref="i4162"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. NETWKSTA.200 can be configured to pass NetBIOS requests to either NETBEUI.OS2, IBM's NetBIOS driver, orNETBIOS.SYS, Novell's NetBIOS driverThis 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. LBL="9-10"ID="FM98073"NetBIOS Requests through NETWKSTA.200FILE="c312q64a.pbm"PrerequisitesInstall Extended Services if you have it.Install LAN Services (NetBIOS support is installed by default). Verify that you can get a LAN connection. Do the steps in IDREF="FM79688""Setting Up the Novell NetBIOS Driver" on page 151 to install the NetWare Requester with the Novell NetBIOS driver. Procedures Open the IBMLAN.INI file in a text editor. For example, to use the OS/2 System Editor at the command line, you would type:  E C:\IBMLAN\IBMLAN.INIIBMLAN.INI is located in the \IBMLAN directory on your boot drive. ID="FM52020"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,14This line defines net1 as the network using the IBM NetBIOS driver. 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,14You must change the IBM driver because the Novell driver has to be defined to net1 in order for dual NetBIOS to work.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 Novell's NetBIOS driver, comment out the line for the IBM driver with a semicolon. The line must be indented at least one space and must follow other formatting requirements for IBMLAN.INI. The Novell line you add should look similar to the following  neta = b,c,LM10,sessions,commands,namesReplace the variables in the line with values shown in the following table:LBL="9-4" INLINE="F"Parameters for defining dual NetBIOS in IBMLAN.INIWIDTH="72"VariableWIDTH="348"Meaning of variableWIDTH="72"NETWIDTH="348"NET is a standard key word for NETWKSTA.200. It is not case-sensitive.aReplace a with a number from 1 to 4. This is the number of the network you want  NETBIOS.OS2 to use when sending NetBIOS requests to a NETBIOS driver. Each  NetBIOS driver must have its own network number. When specifying a network number:Use 1 for the Novell NetBIOS driver and 2 for the IBM NetBIOS driver.Do not use the same number that is used in any other net statements. Each  network number can only be defined to one NetBIOS driver.Do not skip numbers. For example, if you have an existing net statement that  uses NET1, use NET2 for your next statement. bReplace b with the device name for the NetBIOS driver. NETWKSTA.200 recognizes  this name when determining which driver to pass NetBIOS calls to. Replace b with IPXNB$ for the Novell NetBIOS driver. (NETBEUI$ is the device name for the IBM NetBIOS driver.)LM10 idxid="w513"book="_idx" docset="nw312" tidref="i3235"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. cReplace 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  NETWKSTA.200. For Novell's NetBIOS driver, always specify 1. 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 idxid="w514"book="_idx" docset="nw312" tidref="i4169"Replace sessions with the number of NetBIOS sessions you want allocated to the  NetBIOS Submit application. This number specifies the maximum number of  sessions that can be active between NETWKSTA.200 and Novell's NetBIOS driver. Novell's NetBIOS driver is configured with the sessions setting in the NET.CFG file.  The number of sessions 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 idxid="w515"book="_idx" docset="nw312" tidref="i4169"Replace commands with the number of NetBIOS commands you want allocated to  the NetBIOS Submit application. This number specifies the maximum number of  commands that can be active between NETWKSTA.200 and Novell's NetBIOS  driver. Novell's NetBIOS driver is configured with the names setting 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 idxid="w516"book="_idx" docset="nw312" tidref="i4169"Replace names with the number of NetBIOS names you want allocated to the  NetBIOS Submit application. This number specifies the maximum number of  names that can be active between NETWKSTA.200 and Novell's NetBIOS driver. Novell's NetBIOS driver is configured with the names setting in 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. 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,8For more information about defining networks for NETWKSTA.200, see your LAN Services documentation. If your computer is a LAN Server idxid="w517"book="_idx" docset="nw312" tidref="i3135", do the following:Find the [server] line in your IBMLAN.INI file.ID="FM51429"At the end of the [server] section, find the following line:  srvnets = netaAdd 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,NET2The 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. If your computer is a LAN Requester idxid="w518"book="_idx" docset="nw312" tidref="i3132", do the following:Find the [requester] line in your IBMLAN.INI file.ID="FM51429"At the end of the [requester] section, find the following line:  wrknets = netaAdd the Novell NetBIOS network to the line. Separate the Novell net from any existing nets with a comma.For example:  wrknets = NET1,NET2The 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. ID="FM68743"Save the IBMLAN.INI file and exit your text editor. 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. NETWKSTA.200 idxid="w519"book="_idx" docset="nw312" tidref="i4465"idxid="w520"book="_idx" docset="nw312" tidref="i2300"must be started before any kind of NetBIOS connection will work. You can start it automatically on booting or with the LAN Services NETSTART idxid="w521"book="_idx" docset="nw312" tidref="i4193"command at a command line. See your LAN Services documentation for more information. ID="FM62792"Setting Up NetBIOS for DOS and Windows idxid="w522"book="_idx" docset="nw312" tidref="i4169"idxid="w523"book="_idx" docset="nw312" tidref="i7313"This section applies to virtual DOS and Windows sessions under OS/2 only. See the book="ws_dos" docset="nw40"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 idxid="w524"book="_idx" docset="nw312" tidref="i4169"NetWare NetBIOS support is not virtualized idxid="w525"book="_idx" docset="nw312" tidref="i4169". 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. IBM LAPS NetBIOS idxid="w526"book="_idx" docset="nw312" tidref="i4169"Support idxid="w527"book="_idx" docset="nw312" tidref="i4169"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. WIDTH="120"To use . . .WIDTH="192"Go to . . .WIDTH="120"NetWare Requester non- virtualized NetBIOS  supportWIDTH="192"IDREF="FM66356""Using NetWare NetBIOS Support for a  Single DOS Session" on page 171LAPS virtualized NetBIOS  supportIDREF="FM30130""Using LAPS NetBIOS Support for Virtual  Sessions" on page 173ID="FM66356"Using NetWare NetBIOS Support for a Single DOS SessionAs IDREF="FM63674"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.LBL="9-11"ID="FM63674"Novell NetBIOS Support for a virtual sessionFILE="c312q66a.pbm"PrerequisitesEnable IPX support for virtual sessions. IDREF="FM75599""Network Access From Virtual DOS and Windows" on page 19 explains how to do this. 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." IDREF="FM17293""Installing the Driver" on page 153 explains how to run the installation program.ProceduresFollow the instructions in the NetWare Workstation for DOS and Windows manual. Use that documentation to Load NETBIOS.EXE in a single DOS session.Configure NetWare NetBIOS for DOS if necessary. ID="FM30130"Using LAPS NetBIOS Support for Virtual SessionsAs IDREF="FM38858"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. LBL="9-12"ID="FM38858"LAPS NetBIOS Support for Virtual SessionsFILE="c312q62a.pbm"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. Avoiding Resource idxid="w528"book="_idx" docset="nw312" tidref="i5907"Errors idxid="w529"book="_idx" docset="nw312" tidref="i1859"As you can see in IDREF="FM38858"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 aware of a potential resource limitation. If you have previously followed the steps in the IDREF="FM40784""Configuring NETBIOS.OS2 with PROTOCOL.INI" on page 158, 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:Whenever you're using virtual NetBIOS connections, increase the default resources allowed for the NETBIOS driver in NET.CFG.IDREF="FM24938""Configuring the Driver" on page 154 explains how to increase the defaults for the OS/2 NetBIOS driver.Explicitly specify the resources consumed for each virtual session you use. IDREF="FM10500""Procedures" on page 175 explains how to explicitly specify resources.ID="FM52484"PrerequisitesInstall Extended Services with NetBIOS support. See the Extended Services documentation.Install LAN Services if you have it. See the LAN Services documentation. Install the NetWare Requester with NetBIOS support. IDREF="FM79688""Setting Up the Novell NetBIOS Driver" on page 151 explains how to do this. Configure NETBIOS.OS2 to use both the Novell and IBM drivers. IDREF="FM40784""Configuring NETBIOS.OS2 with PROTOCOL.INI" on page 158 explains how to do this. ID="FM10500"ProceduresThese instructions explain how to set resource information for Extended Services virtualized NetBIOS. This information is stored with a program called idxid="w530"book="_idx" docset="nw312" tidref="i2300"idxid="w531"book="_idx" docset="nw312" tidref="i3600"LTSVCFG.COM. The LTSVCFG.COM program is included with LAPS in Extended Services and LAN Services. Open the virtual session.Execute the LTSVCFG.COM program 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=12Three parameters that apply to NetBIOS resources are:  s=number of NetBIOS sessions idxid="w532"book="_idx" docset="nw312" tidref="i4169"  n=names idxid="w533"book="_idx" docset="nw312" tidref="i4169"  idxid="w534"book="_idx" docset="nw312" tidref="i1052"c=commands idxid="w535"book="_idx" docset="nw312" tidref="i4169"For more information about these and other NetBIOS parameters, see the LAPS documentation on NetBIOS. 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=16Names=24Commands=32You may have changed these defaults in your NET.CFG file.LBL="10"Backing Up Your OS/2 WorkstationWIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM68439"Starting the TSA_OS2 ManuallyWIDTH="48"IDREF="FM68439"178IDREF="FM70588"Starting the TSA_OS2 AutomaticallyIDREF="FM70588"180IDREF="FM23256"Setting Up Your TSA_OS2.CFG FileIDREF="FM23256"181The system administrator or backup administrator can back up your OS/2 workstation to the network. To allow access, run the NetWare idxid="w536"book="_idx" docset="nw312" tidref="i6697"idxid="w537"book="_idx" docset="nw312" tidref="i7036"idxid="w538"book="_idx" docset="nw312" tidref="i621"TSA_OS2 (Target Service Agent) program on your workstation.The TSA_OS2 program runs as an application in an OS/2 session. You can continue working in other sessions while TSA_OS2 is running on your workstation. Whenever the TSA_OS2 is running, SBACKUP or another backup program can access the hard drive data.The TSA_OS2 is installed automatically on the hard drive when you install the NetWare 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:Users on the network who can access your hard drivePassword they must type in the backup program before accessing your hard driveDrives on the hard drive that Ycan be backed upChapter 8, "book="supernt" docset="nw40"Backing Up and Restoring Data," in Supervising the Network explains more about backing up workstations and servers.ID="FM68439"Starting the TSA_OS2 idxid="w539"book="_idx" docset="nw312" tidref="i621"Manually idxid="w540"book="_idx" docset="nw312" tidref="i7036"This section explains how to start TSA_OS2 manually by choosing its icon on your desktop. IDREF="FM70588""Starting the TSA_OS2 Automatically" on page 180 explains how to start the TSA_OS2 automatically each time you boot your workstation.PrerequisitesLoad the TSA_OS2.NLM on the server. See Chapter 8, "book="supernt" docset="nw40"Backing Up and Restoring Data," in Supervising the Network.Install the NetWare Requester. See Chapter 3, "Installing a NetWare Workstation" in Workstation Basics and Installation.ProceduresChoose the "Novell" icon on your OS/2 desktop.The "Novell" window appears.From the "Novell" window on your desktop, choose the icon for the TSA_OS2.EXE program.The TSA_OS2 main window appears. See IDREF="FM34245"Figure 10-1.LBL="10-1"ID="FM34245"The TSA_OS2 main windowFILE="c312q73a.pbm"Choose the features you want from the menu bar.Choose "Help" or press <F1> for more information.ID="FM70588"Starting the TSA_OS2 idxid="w541"book="_idx" docset="nw312" tidref="i621"Automatically idxid="w542"book="_idx" docset="nw312" tidref="i7036"You can set up the TSA_OS2 program to start up automatically each time you boot your machine. To do this, you need toPlace your TSA_OS2 icon in the "Startup" folder.This section explains how to put the icon in the "Startup" folder.Set up your TSA_OS2.CFG file.IDREF="FM23256""Setting Up Your TSA_OS2.CFG File" on page 181 explains how to use a TSA_OS2.CFG file.PrerequisitesLoad the TSA_OS2.NLM on the server. See Chapter 8, "book="supernt" docset="nw40"Backing Up and Restoring Data" in Supervising the Network.Install the NetWare Requester. See Chapter 3, "Installing a NetWare Workstation," in Workstation Basics and Installation.InstructionsOpen the "OS/2 System" folder on your desktop.The "OS/2 System" window appears.Open the "Startup" folder from the "OS/2 System" window.The "Startup" window appears.Without closing the "Startup" window, open the "Novell" group on your desktop.The "Novell" window appears.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.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.ID="FM23256"Setting Up Your TSA_OS2.CFG File idxid="w543"book="_idx" docset="nw312" tidref="i2300"idxid="w544"book="_idx" docset="nw312" tidref="i7040"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. IDREF="FM12812"Table 10-1 lists the parameters you can type in the configuration file.LBL="10-1" INLINE="F"ID="FM12812"List of TSA_OS2.CFG parameters idxid="w545"book="_idx" docset="nw312" tidref="i7040"WIDTH="84"ParameterWIDTH="180"DescriptionWIDTH="144"ExampleWIDTH="84"WSName idxid="w546"book="_idx" docset="nw312" tidref="i7551"idxid="w547"book="_idx" docset="nw312" tidref="i4964"WIDTH="180"The Target Service name you assign to  your workstation. Do not use spaces in  the workstation name.WIDTH="144"WSName JO_OS2ServerName idxid="w548"book="_idx" docset="nw312" tidref="i6246"idxid="w549"book="_idx" docset="nw312" tidref="i4964"The name of the server where the Target  Service Agent Router NLM is loaded.ServerName SALES_MKTGUserName idxid="w550"book="_idx" docset="nw312" tidref="i7172"idxid="w551"book="_idx" docset="nw312" tidref="i4964"The User objects you allow to attach to  the OS/2 workstation. Repeat this line for  each User object. If you want to specify a  password, simply specify it on the same  line as the username.The username must be one that is  defined on the network. The password is  unique to your workstation, not the  same password the user types to access  the network. If you specify a idxid="w552"book="_idx" docset="nw312" tidref="i5016"password,  the backup administrator will have to  type that password in the backup  program.UserName NANCYor to set a password of NEATO:UserName NANCY NEATOHideResource idxid="w553"book="_idx" docset="nw312" tidref="i2662"idxid="w554"book="_idx" docset="nw312" tidref="i4964"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 CHideResource D:AutoRegister idxid="w555"book="_idx" docset="nw312" tidref="i620"idxid="w556"book="_idx" docset="nw312" tidref="i4964"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 ONorAutoRegister OFFTempFilesDir idxid="w557"book="_idx" docset="nw312" tidref="i4964"idxid="w558"book="_idx" docset="nw312" tidref="i6764"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_TSAThe following is a sample idxid="w559"book="_idx" docset="nw312" tidref="i2300"idxid="w560"book="_idx" docset="nw312" tidref="i7040"TSA_OS2.CFG configuration file:  WSName Joe's_Machine  ServerName SALES_MKTG  UserName FredJ  UserName Mark  UserName admin  UserName lisa NEATO  HideResource c:  hideresource b:  AUTOREGISTER on  tempfilesdir c:\ emp_os2The file is not case-sensitive.LBL="11"ID="FM97261"Remote-Booting OS/2 Workstations idxid="w561"book="_idx" docset="nw312" tidref="i5789"idxid="w562"book="_idx" docset="nw312" tidref="i739"idxid="w563"book="_idx" docset="nw312" tidref="i2869"idxid="w564"book="_idx" docset="nw312" tidref="i5598"idxid="w565"book="_idx" docset="nw312" tidref="i5844"idxid="w566"book="_idx" docset="nw312" tidref="i5836"idxid="w567"book="_idx" docset="nw312" tidref="i5844"idxid="w568"book="_idx" docset="nw312" tidref="i5844"idxid="w569"book="_idx" docset="nw312" tidref="i5836"idxid="w570"book="_idx" docset="nw312" tidref="i5836"WIDTH="240"TopicWIDTH="60"PageWIDTH="240"IDREF="FM41226"Setting Up a Server to Boot Workstations RemotelyWIDTH="60"IDREF="FM41226"184IDREF="FM86543"Installing OS/2 Files for Remote WorkstationsIDREF="FM86543"186IDREF="FM65768"Installing RIPL Files for Remote WorkstationsIDREF="FM65768"190IDREF="FM29241"Adding Remote Workstations to the NetworkIDREF="FM29241"194IDREF="FM72733"Configuring the Requester for Remote WorkstationsIDREF="FM72733"203OS/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.ID="FM41226"Setting Up a Server to Boot Workstations Remotely idxid="w571"book="_idx" docset="nw312" tidref="i5836"Creating Users and Granting AccessYou have to set up accounts for Remote boot users. Do the following:ProceduresCreate the idxid="w572"book="_idx" docset="nw312" tidref="i6067"RPL User object. idxid="w573"book="_idx" docset="nw312" tidref="i7144"RPL is the username each remote workstation uses to make the initial connection to the network. Chapter 1, "book="supernt" docset="nw40"Managing NetWare Directory Services Objects," in Supervising the Network explains more about creating users.Do not require a password 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 IDREF="FM57138"Step 3.Create a User object for each user who will use a remote workstation. idxid="w574"book="_idx" docset="nw312" tidref="i7144"ID="FM57138"Grant access to the RPL User.The RPL user needs at least Read and File Scan access toThe SYS:RPL2 directoryThe SYS:RPL2\COMPUTER directory and all its subdirectoriesThese directories are created automatically during remote workstation installation.Grant access to each remote workstation user.All remote users need access toThe SYS:RPL2 directory idxid="w575"book="_idx" docset="nw312" tidref="i6619"The \OS2 and \NETWARE subdirectories under SYS:RPL2Their home directories under SYS:RPL2\USERThese directories are created automatically during remote workstation installation.Users should not have access toOther users' home directories under SYS:RPL2\USERThe SYS: volumebook="supernt" docset="nw40"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 BoardsYou can remote boot OS/2 workstations that have any of the following Novell boards:NE1000NE2000NE2To remote boot OS/2 workstations with these boards, you do not need to load any RPL loadable modules (NLMs) on the server.Follow the instructions in the rest of this chapter.To Boot Workstations with IBM BoardsYou can remote boot workstations that have either of the following IBM boards:PCN2LTOKENTo 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:ProceduresAt the server console, type  LOAD RPLThen type  BIND RPL TO driverReplace 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 the book="utilref" docset="nw40"Utilities Reference manual.ID="FM86543"Installing OS/2 Files for Remote WorkstationsComplete the steps in this section if you are:Setting up idxid="w576"book="_idx" docset="nw312" tidref="i5836"idxid="w577"book="_idx" docset="nw312" tidref="i5836"remote workstations for the first time.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 IDREF="FM29241"page 194.PrerequisitesFor the Workstation You're Installing FromMake sure OS/2 is installed on the workstation C: drive. It must be drive C:.Install the NetWare Requester in the \NETWARE directoryMake sure the workstation connected to a server when it booted.Move 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.)Make sure the CONFIG.SYS file only loads programs that remote workstations will need. idxid="w578"book="_idx" docset="nw312" tidref="i5836"Obtain an OS/2 installation diskette if you are setting up PS/2 computers as remote workstations. If you are using PS/2 idxid="w579"book="_idx" docset="nw312" tidref="i5655"computers as remote workstations, the program must copy some files from this diskette.For the NetWare Servers Where You're Installing Remote Boot SupportMake sure you have the Supervisor object right to the NetWare Server object.Make sure enough disk space is free on each server where you want 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.Do the steps in IDREF="FM41226""Setting Up a Server to Boot Workstations Remotely" on page 184.ProceduresAll 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 = OFFYou can type this command at the server console or put it in your server AUTOEXEC.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.On a workstation with the NetWare Requester installed, open the NetWare Requester for OS/2 installation program.IDREF="FM95517"Figure 11-1 shows how to open the program.LBL="11-1"ID="FM95517"Opening the installation program from the Novell groupFILE="c312q11a.pbm"The "NetWare Requester for OS/2 Installation Utility" window appears. Use the online help as necessary.Choose "Remote workstations. . ." from the "Installation" menu.The "Install Requester for Remote Workstations" window appears.Select "Only Copy OS/2 Files . . . " and choose "OK"You can choose other actions from the "Remote Workstation Installation" screen if you want.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).Choose "OK."All OS/2 and NetWare Requester files are copied to the servers.After the files are copied, do the following.WIDTH="108"If you want to . . .WIDTH="180"Do this . . .WIDTH="108"Copy remote boot filesWIDTH="180"Without exiting the installation program,  go to IDREF="FM65768"page 190.Add remote  workstations to the  networkWithout exiting the installation program,  go to IDREF="FM29241"page 194.Configure the Requester  for remote workstationsWithout exiting the installation program,  go to IDREF="FM72905"page 203.Exit the installation  programChoose "Close" from the system menu in  the upper left corner of the Installation  window.ID="FM35976"What Happens When You Install OS/2 FilesA 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 idxid="w580"book="_idx" docset="nw312" tidref="i6619"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. IDREF="FM41226""Setting Up a Server to Boot Workstations Remotely" on page 184 explains more about securing the SYS:RPL2 directory and its subdirectories.OS/2 v1.3 remote idxid="w581"book="_idx" docset="nw312" tidref="i5836"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.Every file from the workstation drive C: is copied to the SYS:RPL2 directory on the server.ID="FM65768"Installing RIPL Files for Remote WorkstationsComplete the steps in this section if you are:Setting up idxid="w582"book="_idx" docset="nw312" tidref="i5836"idxid="w583"book="_idx" docset="nw312" tidref="i5836"remote workstations for the first time.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 IDREF="FM29241"page 194.PrerequisitesFor the Workstation You're Installing FromMake sure the NetWare Requester is installed.Make sure the workstation connected to a server when it booted.For the NetWare servers where you're installing remote boot supportMake sure you have the Supervisor object right to the NetWare server object.Do the steps in IDREF="FM41226""Setting Up a Server to Boot Workstations Remotely" on page 184.Do the steps in IDREF="FM86543""Installing OS/2 Files for Remote Workstations" on page 186.ProceduresAll remote files must be installed on each server on the network. There is no way 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.On a workstation with the NetWare Requester installed, open the NetWare Requester for OS/2 installation program.IDREF="FM53458"Figure 11-2  shows how to open the program.LBL="11-2"ID="FM53458"Opening the installation program from the Novell groupFILE="c312q11a.pbm"The "NetWare Requester for OS/2 Installation Utility" window appears. Use the online help as necessary.Choose "Remote workstations. . ." from the "Installation" menu.The "Install Requester for Remote Workstations" window appears.Choose "Only Copy RIPL Files . . ."You can choose other actions from the "Remote Workstation Installation" screen if you want.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)Choose "OK."All remote boot files are copied to the servers.After the files are copied, do the following.WIDTH="120"If you want to . . .WIDTH="192"Do this . . .WIDTH="120"Add remote  workstations to the  networkWIDTH="192"Without exiting the installation program,  go to IDREF="FM29241"page 194.Configure the Requester  for remote workstationsWithout exiting the installation program,  go to IDREF="FM72733"page 203.Exit the installation  programChoose "Close" from the system menu in  the upper left corner of the Installation  window.What Happens When You Install RIPL FilesWhen you use the installation program to install remote workstation support, the following actions occur.ID="FM28360"Directories Are Createdidxid="w584"book="_idx" docset="nw312" tidref="i6619"SYSRPL2 is created if it didn't already existThe \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 IDREF="FM29696"Figure 11-5 on IDREF="FM29696"page 202.Files Are CopiedThe following remote boot image files are copied to the SYS:LOGIN directory:TOKEN.200NE2.200NE2000.200NE1000.200PCN2L.200These 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:MINI.IFSMICRO.IFSID="FM29241"Adding idxid="w585"book="_idx" docset="nw312" tidref="i5836"Remote Workstations to the NetworkEach 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.Complete the steps in this section on each server if you are:Setting up remote workstations for the first timeUpgrading existing remote workstations from OS/2 v1.3 to OS/2 v2.0Adding remote workstations to the networkAdding a server to the network (complete the steps on this server for every remote workstation currently defined on the other servers)PrerequisitesFor the Workstation You're Installing FromMake sure the NetWare Requester is installed.Make sure the workstation connected to a server when it booted.For Workstations You're Booting RemotelyMake 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.Make sure the matching remote boot PROMs are installed on each network board.Make sure the workstation is properly cabled to the network.Make sure you know the network and node address of the workstation you're booting remotely.ProceduresWhenever possible, use the same type of idxid="w586"book="_idx" docset="nw312" tidref="i4494"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.Start up an OS/2 workstation that has the Requester installed.Open the "Novell" group icon on the desktop.Choose the Install icon in the "Novell-Contents" window.LBL="11-3"Opening the Installation program from the "Novell" groupFILE="c312q11a.pbm"The "NetWare Requester for OS/2 Installation Utility" window appears.Choose "Remote workstations. . ." from the "Installation" menu.The "Add Remote Workstations" menu appears.Choose "Add remote workstations . . ."Choose servers on which you want to define remote workstations.For more information, use the online help.Add the workstations you want.Remote users are easier to manage if you assign only one remote workstation to a username. If you do let one user log in to more than one workstation, you can use the idxid="w587"book="_idx" docset="nw312" tidref="i3419""Logical Name" option to set up each workstation's configuration differently.Choose "Help" or press <F1> for more information.Exit the installation program.To Remote Boot Workstations With Hard DisksIf 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: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 IDREF="FM34896""To Run RPLON" on page 198.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 IDREF="FM59816""To Locate SWAPPER.DAT Locally" on page 198.ID="FM34896"To Run RPLONInsert theWSOS2_1 diskette into a floppy drive of the workstation you want to boot remotely.Change to the drive you put the diskette into.For example, for a diskette in drive A:, type:  CD A: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.ID="FM59816"To Locate SWAPPER.DAT LocallyGo 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\JOHNEach user's home directory on the network contains that users CONFIG.SYS file and several other OS/2 files. IDREF="FM29696"Figure 11-5  on page 202 shows the complete network directory structure for remote workstations.In a text editor, open the CONFIG.SYS file.In the CONFIG.SYS file, find the line that designates the SWAPPATH.You can search for SWAPPATH. The line looks like the following:  SWAPPATH=C:\OS2\SYSTEM 2048 2048Remember that to OS/2, the SYS:RPL2 directory is drive C:.Change the SWAPPATH line to point to the local hard drive.For example, to point to the root of a local drive D:  SWAPPATH=D:\ 2048 2048Save and exit the CONFIG.SYS file.When you boot the remote workstation, the SWAPPER.DAT will be stored locally.ID="FM11537"ID="FM35976"What Happens When You Add Remote idxid="w588"book="_idx" docset="nw312" tidref="i5836"WorkstationsWhen you add remote workstations to a network, the following actions occur.Directories Are CreatedIf you have not yet installed remote workstation support on the network, the idxid="w589"book="_idx" docset="nw312" tidref="i6619"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 JADAMS would have a home directory of:  SYS:RPL2\USER\JADAMSA 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.BBBA 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 CreatedA file called idxid="w590"book="_idx" docset="nw312" tidref="i2300"idxid="w591"book="_idx" docset="nw312" tidref="i1131"idxid="w592"book="_idx" docset="nw312" tidref="i742"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 idxid="w593"book="_idx" docset="nw312" tidref="i2300"BOOTCONF.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.This file tells the server which idxid="w594"book="_idx" docset="nw312" tidref="i5793"idxid="w595"book="_idx" docset="nw312" tidref="i733"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.200See IDREF="FM21028"Figure 11-4 for an explanation of the lines in the BOOTCONF.SYS file.LBL="11-4"ID="FM21028"Format of BOOTCONF.SYS fileFILE="c312q17a.pbm"Files Are CopiedEvery 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 idxid="w596"book="_idx" docset="nw312" tidref="i1119".SYS Is Copied and ModifiedA CONFIG.SYS file is copied from the local drive of the OS/2 workstation you are installing from to each user's subdirectory on each server.This CONFIG.SYS is modified slightly for each user. The line 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.IDREF="FM29696"Figure 11-5  shows the complete directory structure that is created for remote workstation support.LBL="11-5"ID="FM29696"Directory idxid="w597"book="_idx" docset="nw312" tidref="i1516"structure for remote workstation supportFILE="c312q15a.pbm"ID="FM72905"ID="FM72733"Configuring idxid="w598"book="_idx" docset="nw312" tidref="i5836"idxid="w599"book="_idx" docset="nw312" tidref="i1165"the Requester for Remote WorkstationsConfigure the NetWare Requester for remote workstations by running the NetWare Requester installation program and choosing "Remote workstations . . ." from the "Configuration" menu. IDREF="FM16745""How to Configure Your Workstation" on page 41 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 idxid="w600"book="_idx" docset="nw312" tidref="i1131"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.CFGRemember that the SYS:RPL2 directory becomes the root of the C: driveLBL="A"ID="FM54476"System Messages idxid="w601"book="_idx" docset="nw312" tidref="i6667"idxid="w602"book="_idx" docset="nw312" tidref="i3839"idxid="w603"book="_idx" docset="nw312" tidref="i1848"This chapter includes system messages and explanations for all NetWare Requester v2.01 drivers and daemons. Messages for the NetWare Tools or the Network Printer (NPRINTER.EXE) programs are not included. For information about messages for those modules, see book="utilref" docset="nw40"System Messages.REQ0106: An error occurred during attempt to get shared memory. Explanation: DDAEMON.EXE attempted to access the daemon's shared memory, but failed. At this point, the program has verified that the shared memory exists, but is unable to access it. This may be an internal program error. Action: Try rebooting your system. If the problem persists, call your Novell Authorized Reseller. REQ0107: An error occurred during attempt to allocate a shared segment. Explanation: DDAEMON.EXE tried to create shared memory, but none is available. This error usually occurs when the device drivers and applications currently running on your system require more memory than your system has available. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0108: The daemon cannot access the Link Support Layer. Error: <code>. Explanation: DDAEMON.EXE cannot find the Link Support device driver LSL.SYS. Action: Make sure that the device driver LSL.SYS has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the LSL for any errors or warnings, and correct the problems indicated. Try again. If this error persists, call your Novell Authorized Reseller.REQ0109: The DDAEMON is already loaded. Explanation: DDAEMON.EXE tried to create shared memory for the first time, but the memory already exists. Another daemon is already running. The attempt to create shared memory is terminated. Action: Make sure that you are not trying to run multiple copies of the daemon. Typically the daemon is run from the CONFIG.SYS file at system startup and does not need to be executed again.REQ0204: The system does not have enough memory for socket tables. Explanation: OS/2 lacks sufficient system memory for IPX to allocate memory for its socket tables. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0205: The LAN support module could not be installed. Explanation: Either the LSL.SYS driver failed to load, or the "DEVICE=" statement is missing from the CONFIG.SYS file.Action: Either correct the problem that kept the LSL.SYS driver from loading (indicated in an error message preceding this one), or add the "DEVICE=" statement to the CONFIG.SYS file. REQ0206: The IPX MLID could not be installed. Explanation: Either the Multiple Link Interface Driver (MLID) specified in the CONFIG.SYS failed to load, or the "DEVICE=" statement for an MLID is missing from the CONFIG.SYS file. Action: Either correct the problem that kept the MLID from loading (indicated in an error message preceding this one), or add the "DEVICE=" statement to the CONFIG.SYS file. REQ0207: The configured LAN-A driver does not support IPX. Explanation: The Multiple Link Interface Driver (MLID) to which IPX.SYS attempted to bind does not support IPX-based data transmissions. Action: Bind IPX to an MLID that supports IPX-based data transmissions.REQ0208: The IPX protocol handler cannot be registered. Explanation: IPX cannot register with the LSL.SYS driver because the LSL is servicing its maximum number of protocol stacks. Action: Remove the "DEVICE=" statements for any unnecessary protocol stacks from the CONFIG.SYS file. REQ0209: The IPX entry point cannot be initialized. Explanation: The IPX and link support layer (LSL) versions may not be compatible versions.Action: Make sure that the IPX.SYS driver and LSL.SYS driver are compatible. If they are not, obtain compatible drivers from your Novell Authorized Reseller. If this is not the problem, contact your Novell Authorized Reseller for customer assistance.REQ0210: An internal error occurred. The IPX router socket cannot be opened. Explanation: IPX was unable to open the router socket due to an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0211: An internal error occurred. A router selector cannot be allocated. Explanation: IPX was unable to allocate an OS/2 router selector due to an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0212: The system has insufficient memory to allocate a router. Explanation: OS/2 cannot access sufficient system memory for IPX routing purposes. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0213: Router memory is exhausted. Explanation: IPX did not have enough memory previously allocated for routing purposes. Action: Increase the size of the IPX router memory in the NET.CFG "ROUTER MEM" statement.REQ0214: An internal error prevented CGroup variable initialization. Explanation: An internal program error has occurred. IPX was unable to initialize internal variables. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0215: An internal error prevented DosHlp variable initialization. Explanation: OS/2 internal variables were either incomplete or invalid. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0216: IPX cannot register with OS/2 for PDD-to-VDD communications. Explanation: This is an internal program error. IPX cannot register with OS/2 for VIPX.SYS driver support. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0217: The IPX device driver is not running. Explanation: Either IPX.SYS encountered a fatal error during system initialization, or the "DEVICE=[path]IPX.SYS" statement was missing from the CONFIG.SYS file. If the problem is a fatal error, another message should precede this one that identifies the specific error that occurred.Action: Either resolve the fatal problem (indicated in a preceding message), or add the "DEVICE=" statement to the CONFIG.SYS file; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0231: The default protocol configuration option is not used for IPX. Explanation: IPX cannot be configured as a default protocol stack. Action: Remove this option statement from the NET.CFG file.REQ0232: The prescan protocol configuration option is not used for IPX. Explanation: IPX cannot be configured as a prescan protocol stack. Action: Remove this option statement from the NET.CFG file.REQ0233: The OS/2 version number cannot be found; OS/2 v2.0 is assumed. Explanation: IPX's query of OS/2 for the version number returned a value that did not match the value it expected to receive. Action: Make sure the OS/2 version installed on the machine is v2.0 or later.REQ0304: An LSL error occurred. NET.CFG buffers are too big for ECB pool.Explanation: The configured buffer size for the Link Support component is too large. Total available buffer space is around 60 KB, but the Link Support Layer (LSL) is unable to allocate even one buffer of the requested size in its buffer space. See "book="concepts" docset="nw40"Link Support Layer" in Concepts for more information about LSL.Action: Reduce the Link Support component's buffer size in the NET.CFG file. It is more important to have several smaller buffers available than one large one. It is a waste of system memory to configure buffers much larger than the communications media can support.REQ0305: The Link Support module (LSL) could not install the AES timer.Explanation: The Link Support Layer (LSL) could not register its timer handler with the operating system because the maximum number of handlers have already been installed. This timer handler is a critical component of the Requester, and none of the Novell-supplied communication handlers can be expected to work properly without it. See "book="concepts" docset="nw40"Link Support Layer" in Concepts for more information about LSL.Action: Previously installed device drivers (those entered before LSL.SYS in the CONFIG.SYS file) have used all available timer resources. Identify those device drivers and either remove or reconfigure them. Since the Requestor's communications handlers all use a common timer service in the LSL, only one available timer handler is required for proper operation. If you are unable to resolve this problem, contact your Novell Authorized Reseller.REQ0306: The Link Support module could not initialize its call gate.Explanation: The Link Support module could not register its entry point with the operating system. This entry point is vital to most of the Requester's communications components, and its absence will cause them to fail. The most likely cause of this error is a previously loaded device driver that is using too many kernel resources. Action: Try removing application device drivers installed before LSL.SYS in the CONFIG.SYS file. It is highly unlikely that a device driver from the OS/2 base system has caused this error. If the problem persists, contact your Novell Authorized Reseller.REQ0404: NetBIOS error occurred. Link Support module cannot be installed. Explanation: NetBIOS could not open or communicate with the Link Support LINKSUP_ device driver. This can happen if the Link Support Layer (LSL) driver has not been properly installed or if you are using the wrong version of the driver. See "book="concepts" docset="nw40"Link Support Layer" in Concepts for more information about LSL.Action: Make sure that the device driver LSL.SYS has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the LSL for any errors or warnings, and correct the problems indicated. If the Link Support device driver is initializing properly, the problem is with incompatible versions of the software. NetBIOS and Link Support are usually installed together from a single installation diskette. Try reinstalling them. If the problem persists, contact your Novell Authorized Reseller.REQ0405: NetBIOS error occurred. The IPX module is not installed. Explanation: NetBIOS could not open or communicate with the Link Support LINKSUP_ device driver. This can happen if the Link Support Layer (LSL) driver has not been properly installed or if you are using the wrong version of the driver. See "book="concepts" docset="nw40"Link Support Layer" in Concepts for more information about LSL.Action: Make sure that the device driver LSL.SYS has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the LSL for any errors or warnings, and correct the problems indicated. If the Link Support device driver is initializing properly, the problem is with incompatible versions of the software. NetBIOS and Link Support are usually installed together from a single installation diskette. Try reinstalling them. If the problem persists, contact your Novell Authorized Reseller.REQ0406: The NetBIOS call gate cannot be initialized. Explanation: This is an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0407: NetBIOS error occurred. The program cannot initialize local NCBs. Explanation: Insufficient memory is available for the NCBs requested. Usually this error is caused by incorrect configuration information in the NET.CFG file. However, the underlying problem could also be a lack of global system resources in the OS/2 Global Descriptor Table. Action: Reduce the number of commands in the NetBIOS section of the CONFIG.SYS file. (The default number of commands is 12; the maximum allowed is 25.) You also might be able to reduce the number of node names (possible range is 0-126). Additional possibilities include adding RAM, reducing your configuration options (for example, reducing the size of DIRCACHE) or removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2 and then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0408: NetBIOS emulator parameters are too large for the memory pool. Explanation: Insufficient memory is available for all of the control tables needed by the NetBIOS emulator. Action: The amount of table space available to the NetBIOS emulator cannot be increased. The only way to solve this problem is to reduce the number of NetBIOS resources you are requesting. You can do this by modifying the NETBIOS parameters in the NET.CFG file. If the problem persists, contact your Novell Authorized Reseller.REQ0409: Incompatible versions of OS/2 and NetBIOS are running. Explanation: You are attempting to run NetBIOS v2.01 on some version of OS/2 earlier than OS/2 v2.0. Action: Either install OS/2 v2.0 to run with NetBIOS v2.01, or install a different version of NetWare NetBIOS to match your OS/2 version.REQ0504: The SPX module is not installed. Explanation: The NMPIPE.SYS driver could not open or communicate with the SPX.SYS driver. Action: Make sure that the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0505: The IPX module is not installed. Explanation: NMPIPE.SYS could not open or communicate with the IPX.SYS driver. Action: Make sure that the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0519: An incorrect OS/2 version is being used. Explanation: Either the DosGetVersion call failed (an internal program error), or the OS/2 version currently running is not v2.0 or later. Action: Make sure the client OS and NMPIPE.SYS driver are compatible versions. If the problem persists, contact your Novell Authorized Reseller. REQ0520: The driver cannot register the PDD for VDD-to-PDD communications. Explanation: NMPIPE.SYS could not register IPX as a PDD so that PDD to VDD communication may take place. Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also make sure the OS/2 version is v2.0 or later; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0613: Invalid characters were specified in COMPUTERNAME. Explanation: The Named Pipes server name specified after NPDAEMON.EXE is invalid. Action: Make sure the server name is not more than 15 characters and is composed of letters, numbers, and these special characters: !#$%&()-.@^_\Q{}~REQ0614: An error occurred during attempt to initialize NPCALLS.DLL. Explanation: The NPDaemon could not initialize NPCALLS.DLL. Action: Make sure the NPCALLS.DLL file in the NetWare Requester directory is included in the LIBPATH statement of the CONFIG.SYS file. If you are running Named Pipes, make sure the NMPIPE.SYS driver and NPSERVER.SYS are correctly configured in the CONFIG.SYS file.REQ0615: The Named Pipes daemon could not be registered. Error: <code>. Explanation: The NPDaemon could not open or communicate with the NMPIPE.SYS driver. Action: Make sure the NMPIPE.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems. Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0616: An error occurred during attempt to allocate shared memory. Explanation: The NPDaemon could not allocate shared memory. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0617: An error occurred during attempt to allocate the ECB pool. Explanation: The NPDaemon could not allocate memory for the ECB pool. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0618: An error occurred during attempt to create a system semaphore. Explanation: A DosCreateSem call failed. An internal program error may have occurred. Action: Try again. If the error persists, contact your Novell Authorized Reseller.REQ0619: An error occurred during attempt to create a thread. Explanation: A beginthread call failed. An internal program error may have occurred.Action: Try again. If the error persists, contact your Novell Authorized Reseller.REQ0620: A dynamic socket could not be opened. Error: <code>. Explanation: The NPDaemon failed to open a dynamic socket. Action: Increase the socket count specified in the NET.CFG file; then reboot the system and try again. If the problem persists, contact your Novell Authorized Reseller. REQ0621: A well-known socket could not be opened. Error: <code>. Explanation: The NPDaemon could not open Netware's registered Named Pipe socket; the socket may already be in use. Action: Increase the SPX socket count in the NET.CFG and shut down OS/2; then reboot the system.REQ0622: The NPDaemon cannot get the internet address. Error: <code>. Explanation: An IpxGetInternetworkAddress call failed. Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also make sure the IPXCALLS.DLL file is in the NetWare Requester directory; then try again. If the problem persists, notify your Novell Authorized Reseller.REQ0623: The NPDaemon cannot get the local target. Error: <code>. Explanation: An IpxGetLocalTarget call failed. Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also make sure the IPXCALLS.DLL file is in the NetWare Requester directory; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0624: The service advertising function failed. Error: <code>. Explanation: An IpxSend call to advertise this workstation as Named Pipe Server failed. Action: Make sure the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also make sure the IPXCALLS.DLL file is in the NetWare Requester directory; the try again. If the problem persists, contact your Novell Authorized Reseller.REQ0625: The broadcast socket cannot be opened. Error: <code>. Explanation: The broadcast socket cannot be opened. This is a registered socket by which SAPs can be received. Possibly this socket has already been opened. Action: Increase the socket count in the NET.CFG file and shut down OS/2 and then reboot the system. If the problem persists, contact your Novell Authorized Reseller. REQ0626: An error occurred during attempt to get code page information. Explanation: A call to DosGetCtryInfo failed. This may be an internal program error. Action: Make sure the OS/2 is version 2.0 or later. If so, and the problem persists, contact your Novell Authorized Reseller.REQ0628: Memory cannot be allocated for turbo buffers. Explanation: The NPDaemon could not allocate memory for turbo buffers. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0629: A connection thread died abnormally. Error: <code>. Explanation: The connection controller thread died unexpectedly. Action: Make sure that the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also make sure all of your Named Pipe drivers are within the same major version (for example, v2.x); then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0630: The specified computer name is already registered on the internet. Explanation: The Named Pipes server name specified in the CONFIG.SYS file has already been used on the network. Action: Use a different server name.REQ0631: The receive buffer manager died abnormally. Error: <code>. Explanation: The receive buffer manager thread died unexpectedly. Action: Make sure that your Named Pipes drivers are within the same major version (for example, v2.x). If so, try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0632: An error occurred checking for nondedicated server. Explanation: The NPDaemon could not open or communicate with the NWREQ.SYS driver. Action: Make sure that the NWREQ.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Make sure NWREQ.SYS is version 2.0 or greater. Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0633: An error occurred allocating memory for nondedicated SAP buffer. Explanation: NPDaemon could not allocate memory. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0634: The NPDaemon could not obtain a server list. Explanation: The Named Pipes daemon failed in its attempt to obtain a list of servers from the NetWare for OS/2 server running on the same machine. Action: Make sure you are running the latest version of the NetWare for OS/2 server. If the problem persists, contact your Novell Authorized Reseller.REQ0704: The SPX module is not installed. Explanation: The Named Pipes daemon could not open or communicate with the SPX.SYS driver. Action: Make sure that the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0705: The IPX module is not installed. Explanation: The Named Pipes daemon could not open or communicate with the IPX.SYS driver. Action: Make sure that the IPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0719: An incorrect OS/2 version is being used. Explanation: The DosGetVersion call failed (which would indicate an internal program error) or the OS/2 version currently running is not v2.0 or later. Action: Make sure that the client OS and NMPIPE.SYS driver are compatible; then try again. If the problem persists, contact your Novell Authorized Reseller. REQ0806: The program cannot get code page information. Error: <code>. Explanation: The OS/2 system is not returning code page information. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0807: The Requester device driver and daemon are incompatible versions. Explanation: The most likely cause of this problem is that NWDAEMON.EXE and NWREQ.SYS driver were not installed from the same installation disk. Action: Install the Requester driver again, making sure it is from the correct installation disk.REQ0808: The worker DLL cannot be registered. Error: <code>. Explanation: The NWWORKER.DLL could not register with the Requester. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0809: The broadcast handler cannot be registered. Error: <code>. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0810: The program cannot get system information. Error: <code>. Explanation: The OS/2 system is not returning system information. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0811: The janitor thread priority cannot be set. Error: <code>. Explanation: The janitor thread is set to run at regular priority. The system had trouble setting the priority. Action: Ignore the error.REQ0812: The janitor daemon cannot be registered. Error: <code>. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0813: The program cannot get the current drive map. Error: <code>. Explanation: The OS/2 system is not returning the current drive map. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0814: The program cannot set the current drive map. Error: <code>. Explanation: The OS/2 system is not setting the current drive map. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0815: The program cannot get the connection ID. Error: <code>. Explanation: The Requester tried to locate a NetWare server when it initialized. Either no servers are currently running or a cabling problem exists. Action: Make sure the NetWare server is running and functioning properly. Also make sure the OS/2 machine has a working connection to the network; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ0816: An error occurred during attempt to initialize the cache. Explanation: The caching function is not working. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0817: The daemon could not boost the thread priority. Explanation: The thread is set to run at a greater priority. The system had trouble setting the priority. Action: Ignore the error.REQ0818: The daemon could not register the DosBox handler. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0820: Not enough memory for diagnostic daemon. Error: <code>. Explanation: The NWDaemon program tried to allocate memory from the system for the diagnostic thread to use as a stack, but the system returned an error. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0821: The diagnostic daemon cannot be started. Error: <code>. Explanation: The NWDaemon tried to start the diagnostic thread but the system encountered an error condition. The system may have too many threads already running, or this may be an internal program error. Action: Try closing other applications that are currently running. If the problem persists, contact your Novell Authorized Reseller.REQ0822: The diagnostic daemon priority cannot be changed. Error: <code>. Explanation: The diagnostic thread is set to run at regular priority. The system had trouble setting the priority. Action: Ignore the error.REQ0823: Not enough memory to start a new thread. Error: <code>. Explanation: The NWDaemon could not allocate memory from the system to create a thread for a new task. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0824: The SPX send thread cannot be started. Error: <code>. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0825: The SPX receive thread cannot be started. Error: <code>. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0826: The SFT 3 handler cannot be registered. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0827: Packet Burst cannot be initialized. Explanation: This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ0843: Not enough memory for a network management thread (<error code>). Explanation: The NWDaemon tried to allocate memory from the system for a thread to initialize network management, but memory was not available. Network management cannot be initialized. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0844: A named pipe cannot be started for network management (<error code>). Explanation: The NWDaemon could not allocate a named pipe. Network management will not be supported until the computer is rebooted. This error could result from a variety of causes. Named Pipes or SPX may not be loaded, one of your drivers may have opened too many Named Pipes already, you may not have enough memory or disk space, or it may be an internal program error. Action: Make sure that Named Pipes and SPX are loaded and that your system has enough memory. (If you suspect a memory problem, see the discussion for message 843.) After completing these actions, reboot the system and try again. If the problem persists, contact your Novell Authorized Reseller.REQ0845: Not enough memory to run network management (<error code>). Explanation: The NWDaemon program tried to allocate memory from the system to run network management, but memory is not available. Network Management will not run until memory is available and the system is rebooted. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0904: The NWREQ.SYS driver is not loaded. Explanation: The Requester cannot be initialized until the driver is loaded. Action: Load the NWREQ.SYS driver.REQ0914: The program cannot allocate selectors for the workspace table. Explanation: All available memory selectors are being used by the system or by previously loaded device drivers. Action: Remove optional or unneeded device drivers from the CONFIG.SYS file and try again. If the problem persists, contact your Novell Authorized Reseller.REQ0915: The program cannot allocate memory for the workspace table. Explanation: All available system memory is in use. The Requester cannot load properly. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0917: Memory is not available for the cache table. Caching is disabled. Explanation: All available system memory is in use by the system. The Requester cannot load properly. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ0919: An incorrect OS/2 version is being used. Explanation: The major versions of the Requester and OS/2 do not match. Action: Upgrade the Requester or OS/2.REQ0937: The Requester driver version does not match the IFS version. Explanation: NWIFS.IFS and NWREQ.SYS were not installed from the same installation disk. Action: Install the Requester again. If the problem persists, contact your Novell Authorized Reseller.REQ1004: The LAN support module is not installed. Explanation: The Requester driver requires the LSL.SYS driver to be running when it loads. Either the "DEVICE=C:\NETWARE\LSL.SYS" line is missing from the CONFIG.SYS file or the LSL encountered an error while loading. Action: Check the CONFIG.SYS file for the LSL.SYS driver. If this is not the problem, contact your Novell Authorized Reseller.REQ1008: A NetWare server cannot be found. Explanation: The Requester tries to locate a NetWare server when it initializes. Either no servers are currently running or there is a cabling problem. Action: Make sure that the NetWare server is running and operating properly. Also make sure that the OS/2 machine is connected to the network.REQ1010: The program cannot allocate selectors for the connection table. Explanation: All available memory selectors are being used by the system or by previously loaded device drivers. Action: Remove optional or unneeded device drivers from the CONFIG.SYS file and try again. If the problem persists, contact your Novell Authorized Reseller.REQ1011: The program cannot allocate memory for the connection table. Explanation: All available system memory is in use. The Requester cannot load properly. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system.If the problem persists, contact your Novell Authorized Reseller.REQ1019: An incorrect OS/2 version is being used. Explanation: The major version of the Requester and OS/2 do not match. Action: Upgrade the Requester or OS/2.REQ1021: The config file cannot be parsed. Default parameters will be used. Explanation: The Requester driver could not read parameters in the NET.CFG file. Action: Make sure the syntax for the NetWare Requester section of the file is correct.REQ1022: An unrecoverable error occurred. The driver was not loaded. Explanation: The driver could not load properly. This is probably an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1024: The program cannot allocate selectors for worker support. Explanation: All available memory selectors are being used by the system or by previously loaded device drivers. Action: Remove optional or unneeded device drivers from the CONFIG.SYS file. Then try again. If the problem persists, contact your Novell Authorized Reseller.REQ1038: The program cannot allocate memory for the error message buffer. Explanation: All available system memory is in use by the system. The Requester cannot load properly. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ1039: The Requester could not send to NetWare server <number> as <number>. Explanation: The Requester waits for a response from the server after each request. If the server does not respond within a certain amount of time, the Requester times out. Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1040: The Requester timed out waiting for reply from server <number>. Explanation: The Requester waits for a response from the server after each request. If the server does not respond within a certain amount of time, the Requester times out. Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1041: Server <number> did not respond to a request. Explanation: The Requester waits for a response from the server after each request. If the server does not respond within a certain amount of time, the Requester times out. This error can also occur if the server responds with an unexpected response.Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1042: Connection to NetWare server <number> as <number> is now invalid. Explanation: The Requester waits for a response from the server after each request. If the server does not respond within a certain amount of time, the Requester times out. Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1043: Routing to NetWare server <number> has been disrupted. Explanation: The network route to the server has been disrupted. Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1045: Routing to NetWare server <number> has been disrupted. Explanation: The network route to the server has been disrupted. Action: Make sure that the server is still running and functioning properly. Also make sure that all routers between the workstation and the server are still running. If the problem persists, contact your Novell Authorized Reseller.REQ1106: The SPDaemon cannot get the SPX version. Error: <code>. Explanation: The SpxGetVersion call failed. This may be an internal program error. Action: Make sure that the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Check for a mismatch of driver versions. If the problem persists, contact your Novell Authorized Reseller.REQ1107: The SPX driver and the SPX daemon are incompatible versions. Explanation: The SPX.SYS driver and SPDAEMON.EXE versions may not match. Action: Make sure that the client SPX.SYS driver and SPDAEMON.EXE are compatible versions. If the problem persists, contact your Novell Authorized Reseller. REQ1108: The SPX driver entry cannot be obtained. Error: <code>. Explanation: The SPDaemon could not get a handle to the SPX.SYS driver. This may be an internal program error. Action: Make sure that the client SPX.SYS driver and SPDAEMON.EXE versions are compatible. If the problem persists, contact your Novell Authorized Reseller. REQ1109: The SPX daemon is already loaded. Error: <code>. Explanation: The SPDAEMON.EXE has already registered with the SPX.SYS driver, which means it is already loaded. Action: Make sure that the daemon SPDAEMON.EXE has not been entered in the CONFIG.SYS file more than once. REQ1110: The daemon cannot register with the SPX driver. Error: <code>. Explanation: The SPDaemon cannot communicate with the SPX.SYS driver. Action: Make sure that the SPX.SYS file has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Check for a mismatch of driver versions. If the problem persists, contact your Novell Authorized Reseller. REQ1111: The SPX device handle cannot be closed. Error: <code>. Explanation: The SPDeamon cannot close the device handle. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1112: The SPDaemon cannot wait on semaphore. Error: <code>. Explanation: A DosSemSetWait call failed. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1113: System information segments cannot be obtained. Error: <code>. Explanation: The DosGetInfoSeg call failed. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1114: Priority for the lock thread cannot be set. Error: <code>. Explanation: The DosSetPrty call failed. This may be internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1115: The SPX driver cannot be accessed. Error: <code>. Explanation: The SPDaemon was not able to access SPX.SYS through the call gate. Action: Make sure that the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Also check for a mismatch of driver versions; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ1116: Priority for an AES thread cannot be set. Error: <code>. Explanation: The DosSetPrty call failed. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1117: Priority for a watchdog thread cannot be set. Error: <code>. Explanation: The DosSetPrty call failed. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1118: Priority for a session thread cannot be set. Error: <code>. Explanation: The DosSetPrty call failed. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1119: The SPXCALLS.DLL cannot register with the SPX driver. Explanation: The SPXCALLS.DLL cannot communicate with the SPX.SYS driver. Action: Check to see if the SPX.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Check for a mismatch of driver versions; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ1205: The driver cannot initialize the CGroup Data variables. Explanation: Normally, key data variable are stored in the driver's CGroup for easy and reliable access. However, in this instance the variables could not be initialized due to a memory-related error. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller. REQ1206: The driver cannot configure SPX. Explanation: The driver in conjunction with the NWCONFIG.DLL failed to parse the NET.CFG file for the SPX parameters. Action: Make sure the format of the NET.CFG file is correct.REQ1207: The driver failed to get support hooks from the LSL or IPX. Explanation: SPX could not open or communicate with either the LINKSUP_ (LSL.SYS) or the IPX_ (IPX.SYS) drivers. The most likely cause of this error is that one or both of these drivers has been improperly installed. Action: Make sure that the device drivers LSL.SYS and IPX.SYS have been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Check for a mismatch of driver versions; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ1208: The OS/2 version cannot be obtained; OS/2 v2.0 is assumed. Explanation: The DosGetVersion call failed (an internal program error), or the OS\2 version currently running is not v2.0 or later. Action: Make sure that OS/2 and the SPX.SYS driver are compatible versions. If this is not the problem, contact your Novell Authorized Reseller.REQ1209: The driver cannot get OS/2 DOS variables. Explanation: The SPX.SYS driver could not obtain either the system or local information segment. This may be an internal program error. Action: Try again. If the problem persists, contact your Novell Authorized Reseller.REQ1210: The driver cannot initialize the SPX call gate. Explanation: The SPX.SYS driver could not register a call gate with the LSL.SYS driver. Action: Make sure that the LSL.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. Check for a mismatch of driver versions; then try again. If the problem persists, contact your Novell Authorized Reseller.REQ1211: The driver cannot allocate memory for SPX use. Explanation: The system does not have enough memory to run SPX. Action: Try adding RAM, reducing your configuration options in the CONFIG.SYS file (for example, reducing the size of DIRCACHE), removing optional device drivers from the CONFIG.SYS file, and freeing up some hard disk space by deleting unnecessary programs. If you are using multiple disk partitions, consider moving the OS/2 swapper file to a larger partition. Disk compression utilities may also be available that can help resolve this problem. After completing these actions, shut down OS/2; then reboot the system. If the problem persists, contact your Novell Authorized Reseller.REQ1301: The application cannot initialize named pipes. Explanation: The application could not open or communicate with the NMPIPE.SYS driver. Most likely, the NMPIPE.SYS driver is not entered in the CONFIG.SYS file. Action: Make sure that the NMPIPE.SYS driver has been properly entered in the CONFIG.SYS file. If so, check the messages displayed by the driver for any errors or warnings, and correct the problems indicated. If the problem persists, contact your Novell Authorized Reseller.LBL="B"ID="FM73872"NET.CFG Options ReferenceWIDTH="264"TopicWIDTH="48"PageWIDTH="264"IDREF="FM98722"Using the NET.CFG Reference PagesWIDTH="48"IDREF="FM98722"236IDREF="FM83875"Daemon ConfigurationIDREF="FM83875"237IDREF="FM89232"DisplayHardErrorsIDREF="FM89232"238IDREF="FM28739"Link DriverIDREF="FM28739"239IDREF="FM25534"Link SupportIDREF="FM25534"251IDREF="FM59417"Named PipesIDREF="FM59417"253IDREF="FM99769"NetWare NetBIOSIDREF="FM99769"256IDREF="FM57102"NetWare RequesterIDREF="FM57102"264IDREF="FM53606"Protocol ODINSUPIDREF="FM53606"272IDREF="FM38316"Protocol Stack IPXIDREF="FM38316"274IDREF="FM73864"Protocol Stack SPXIDREF="FM73864"277IDREF="FM53519"Token-Ring Source-Route DriverIDREF="FM53519"282ID="FM37650"This appendix contains an alphabetical listing of all NET.CFG options. For instructions on how to edit the NET.CFG file, format requirements, and reasons to configure, IDREF="FM16745"see Chapter 4, "How to Configure Your Workstation."All the information in this appendix is also found online in the NetWare Requester installation and configuration program.ID="FM98722"Using the NET.CFG Reference PagesIDREF="FM26840"Figure B-1 explains how to read the NET.CFG reference pages in this chapter.LBL="B-1"ID="FM26840"Format of NET.CFG reference pagesFILE="c312q02a.pbm"ID="FM83875"Daemon Configuration idxid="w604"book="_idx" docset="nw312" tidref="i1300"Use this option to control the length of time network-related error messages stay on your screen. This option controls only pop-up and broadcast messages. Pop-up and broadcast messages appear in a small box on your screen and prompt you to "Press <Esc> to continue . . ." Settingmessage timeout idxid="w605"book="_idx" docset="nw312" tidref="i3838"WIDTH="60"SyntaxWIDTH="240"daemon configuration   message timeout numberReplace number with a number of milliseconds  that you want pop-up and broadcast messages to  display on your screen before disappearing. Replace number with 0 (zero) to prevent pop-up  and broadcast messages from displaying at all.If you leave this line out of your NET.CFG, pop- ups and broadcast messages are displayed until  you press <Esc>. DefaultPop-up and broadcast messages display until you  press <Esc>.ExampleTo prevent pop-up and broadcast messages from  displaying:daemon configuration   message timeout 0ID="FM89232"DisplayHardErrors idxid="w606"book="_idx" docset="nw312" tidref="i1621"idxid="w607"book="_idx" docset="nw312" tidref="i4127"Use this option to keep programs running without interaction when a idxid="w608"book="_idx" docset="nw312" tidref="i2639"hard error is displayed. With this option set, hard errors are automatically returned to the program that caused them rather than displayed to you for further interaction. This option is useful for sites with unattended workstations. Be careful about using it in other environments as you might turn off important messages.Hard errors display on a full screen and prompt you to choose among several actions. These error idxid="w609"book="_idx" docset="nw312" tidref="i3839"messages cause background processes to suspend until you respond to the message.displayharderrors noWIDTH="60"SyntaxWIDTH="240"Type displayharderrors no to keep error messages  from displaying. To display error messages, leave this line out of  your NET.CFG file.DefaultError messages are displayed. ExampleTo prevent hard error messages from displaying:displayharderrors noID="FM28739"Link Driver idxid="w610"book="_idx" docset="nw312" tidref="i4127"idxid="w611"book="_idx" docset="nw312" tidref="i3201"Use this option to specify the hardware configuration of the LAN drivers for each network board in your workstation. Use this option only if the network boards are not using the default settings. The settings you specify with this option should match the hardware settings for your boards. If you have more than one network board in your workstation, put this option in your NET.CFG file for each board. Syntax  link driver name     dma [index] channel     frame name     int [index]irq     mem [index] starting_address [size]     node address number     port [index] starting_port [number]     protocol nameidframe     slot numberOptionlink driverUse this option to specify the name of the LAN driver whose defaults you want to modify. WIDTH="60"SyntaxWIDTH="240"link driver nameReplace name with the name of the driver. IDREF="FM37012"Table B-1 lists some network boards and their  driver names.LBL="B-1" INLINE="F"ID="FM37012"List of network boards and driversWIDTH="60"Driver nameWIDTH="240"Network boardWIDTH="60"NE2WIDTH="240"Novell Ethernet NE/2NE2_32Novell Ethernet NE/2-32NE1000Novell Ethernet NE1000NE2000Novell Ethernet NE2000TOKENIBM Token-Ring LANSUPBoards using NDIS driversODINSUPIBM Token-Ring and Ethernet Communications Manager3C5013Com EtherLink series 5013C5033Com EtherLink series 5033C5053Com EtherLink series 5053C5233Com EtherLink/MC seriesPCN2IBM PC Network II and II/A (older Novell frame format)PCN2LIBM PC Network II and II/A (newer IBM frame format)The PCN2 and PCN2L drivers cannot be used in the same workstation. WIDTH="60"DefaultWIDTH="240"None.ExampleTo configure an IBM Token-Ring PC driver, type  the following with any settings from the  following pages: link driver tokenSettingsDMA idxid="w612"book="_idx" docset="nw312" tidref="i1635"idxid="w613"book="_idx" docset="nw312" tidref="i3201"Use this setting to specify which direct memory access (DMA) channel the network board uses. WIDTH="60"SyntaxWIDTH="240"link driver name   dma [index]channelReplace index with either #1 or #2 (optional).The driver configuration table for each board can  store the DMA channel number on either of two  lines. The lines are labeled #1 and #2. Replace channel with the number of the DMA  channel used by the board. The channel numbers for different network  boards are recorded in the documentation from  the board manufacturers. DefaultsIndex: #1 Most boards use this default.Channel: Set by the driver. See the  documentation for the board. You can't change the DMA setting on 3Com  Etherlink 503 boards, and you do not need to  change it on 3Com Etherlink 505 boards. You can  change the DMA setting on 3Com Etherlink 523  boards.ExampleTo set the DMA channel for a 3Com Etherlink 505  board:link driver 3C505   dma 7ID="FM82317"frame idxid="w614"book="_idx" docset="nw312" tidref="i2504"idxid="w615"book="_idx" docset="nw312" tidref="i3201"Use this setting to specify which frame type the driver for your network board uses. Use this setting only for boards that support more than one frame type or if you want multiple networks (separate network addresses) to share the same network board and cabling.The frame type transmitted by the workstation should match the type of packets being transmitted by the servers on your network. WIDTH="60"SyntaxWIDTH="240"link driver name   frame nameReplace name with the name of the frame type.  The following table lists common frame types  and the network board drivers that support each  type. This list is not comprehensive.LBL="B-2" INLINE="F"List of frame types and driversWIDTH="108"Frame typeWIDTH="204"Network board driverWIDTH="108"Ethernet_802.3WIDTH="204"NE1000, NE2000, NE2100, NE2, NE2_32,  3C501, 3C503, 3C505, 3C523, EXOS205,  EXOS215, ODINSUPEthernet_802.2NE1000, NE2000, NE2100, NE2, NE2_32,  3C501, 3C503, EXOS205, EXOS215,  ODINSUP, LANSUPEthernet_IINE1000, NE2000, NE2100, NE2, NE2_32,  3C501, 3C503, 3C505, 3C523, EXOS205,  EXOS215, ODINSUPEthernet_SNAPNE1000, NE2000, NE2100, NE2, NE2_32,  3C501, 3C503, EXOS205, EXOS215,  ODINSUP, LANSUPToken-RingODINSUP, TOKEN, LANSUPToken-Ring_SNAPODINSUP, TOKEN, LANSUPIBM_pcn2_802.2PCN2, PCN2L, LANSUPIBM_pcn2_snapPCN2, PCN2L, LANSUPNovell_rx-netTRXNET, TRXNET2DefaultSet by the driver. See the documentation for the  board. ExamplesTo specify the Ethernet_802.2 frame type for an  NE2000 board: link driver ne2000   frame ethernet_802.2To specify the Ethernet_802.2 and  Ethernet_802.3 frame types for an NE1000 board  (for two logical networks): link driver ne1000   frame ethernet_802.2   frame ethernet_802.3If you are using the ODINSUP driver, you must enable multiple frame types for each driver. For Ethernet, enable Ethernet_802.3, Ethernet_II, Ethernet_802.2, and Ethernet_SNAP.For Token-Ring, enable Token-Ring and Token-Ring_SNAP. For more information about ODINSUP, IDREF="FM39812"see Chapter 8, "Sharing a Network Board With IBM Software."You can specify more than one frame type statement for a single driver. For example, you can specify that an Ethernet NE2000 board can use both Ethernet_802.2 and Ethernet_802.3 frame types. 802.2 is the type of communications sent on one network, and 802.3 is the type of communication sent on the other network. You can use up to four frame types for one set of Ethernet cabling. You can use either four network boards each with one frame type defined, or you can use one network board with four frames defined, or any similar combination. For Token-Ring cabling, two frames types are the maximum allowed.The default frame type for Ethernet drivers has changed to Ethernet_802.2.  This may conflict with the frame type used on your network. See IDREF="FM64269""Specifying Frame Types for a Driver" on page 53 for more information about specifying frame type. int idxid="w616"book="_idx" docset="nw312" tidref="i2954"Use this setting to specify which interrupt line idxid="w617"book="_idx" docset="nw312" tidref="i3201"(IRQ) idxid="w618"book="_idx" docset="nw312" tidref="i3029"the network board uses to communicate with the driver. WIDTH="60"SyntaxWIDTH="240"link driver name   int [index]irqReplace index with either #1 or #2 (optional).The driver configuration table for each board can  store the interrupt line number on either of two  lines in the table. The lines are labeled #1 and #2. Replace irq with the number of the interrupt line  used by the board. To determine the interrupt line number for your  network board, see the documentation for the  board. DefaultsIndex: #1IRQ: Set by the driver. See the documentation for  the board. ExampleTo set the interrupt line for an NE2000 board:link driver ne2000   int 3Before changing the interrupt setting for your board, be sure you know what interrupt settings are used on other hardware (such as monitors) that you are using. For example, interrupts 2 and 9-15 are usually reserved, so don't use those numbers (especially 2) for your network board. We recommend using 3, 5, or 7 for most network boards. If you are using a PS/2 computer on a Token-Ring network, do not autoconfigure with the Reference diskette. Doing so may cause problems.mem idxid="w619"book="_idx" docset="nw312" tidref="i3201"idxid="w620"book="_idx" docset="nw312" tidref="i3801"Use this setting to specify what range of memory can be used by the driver. WIDTH="60"SyntaxWIDTH="240"link driver name   mem [index]starting_addresssizeReplace index with either #1 or #2 (optional).The driver configuration table for each board can  store the memory range on either of two lines in  the table. The lines are labeled #1 and #2. Replace starting_address with a hexadecimal  memory address that begins the range. This  address must be five digits and the same as the  address designated for the board by the  manufacturer. (See the documentation for the  board). Replace size with a hexadecimal number of  paragraphs in the memory range (optional).DefaultsIndex: #1Starting_address: Set by the driver. See the  documentation for the board. Size: Set by the driver. See the documentation for  the board. ExampleTo set the memory range for a Token-Ring board:link driver token   mem cc000 200Assign each board a unique memory range. Be sure that you don't assign a range that is already being used by other hardware. (VGA monitors commonly use C6FFF and XVGA monitors commonly use CFFFF.)node address idxid="w621"book="_idx" docset="nw312" tidref="i3201"idxid="w622"book="_idx" docset="nw312" tidref="i4648"Use this setting to change the node address of a network board. This setting can only be used with network boards that allow you to override the preset address. WIDTH="60"SyntaxWIDTH="240"link driver name   node address numberReplace number with a hexadecimal address. You  can specify the address with either the least  significant bit first (lsb format) or the most  significant bit first (msb format).DefaultThe address preset on the board. ExampleTo change the address for board that uses the  ODINSUP driver:link driver odinsup   node address 02608c861759port idxid="w623"book="_idx" docset="nw312" tidref="i3201"idxid="w624"book="_idx" docset="nw312" tidref="i5113"Use this setting to specify which range of I/O ports the network board uses. WIDTH="60"SyntaxWIDTH="240"link driver name   port [index]starting_port[number]Replace index with either #1 or #2 (optional).The driver configuration table for each board can  store information about ports on either of two  lines in the table. The lines are labeled #1 and #2. Replace starting_port with a hexadecimal port  number that begins the range. We recommend  not using 2EO and 2FO since these port numbers  are normally used by ARCnet for other functions.Replace number with the hexadecimal number of  bytes in the range (optional).DefaultsIndex: #1Starting_port: Set by the driver. See the  documentation for the board. Number: Set by the driver. See the documentation  for the board.ExampleTo set the memory range for board that uses the  NE2000 driver:link driver ne2000   port 300protocol idxid="w625"book="_idx" docset="nw312" tidref="i3201"idxid="w626"book="_idx" docset="nw312" tidref="i5614"Use this setting to allow LAN drivers to use protocols that have different frame types. WIDTH="60"SyntaxWIDTH="240"link driver name   protocol nameIDframeReplace name with the acronym of an ODI- compliant protocol. Some common protocols are:ARPIPIPX (the NetWare protocol)RARPReplace ID with the hexadecimal number of the  protocol that goes with the frame type you  specify. The following table shows common  protocols with some frame types and  hexadecimal numbers they support.Replace frame with the name of the frame type  used with the protocol. The following table lists  some common frame types.LBL="B-3" INLINE="F"List of protocols, frame types, and hexadecimal ID numbersWIDTH="36"ProtocolWIDTH="132"Frame typeWIDTH="120"Hex numberWIDTH="36"IPXWIDTH="132"Ethernet_802.3Ethernet_802.2Token-RingIBM_PCN2_802.2Ethernet_IIEthernet_SNAPToken-Ring_SNAPIBM_PCN2_SNAPNovell_RX-NetWIDTH="120"0e0e0e08137813781378137faIPEthernet_IIEthernet_SNAPToken-Ring_SNAPNovell_RX-Net800800800d4ARPEthernet_IIEthernet_SNAPToken-Ring_SNAPNovell_RX-Net806806806d5RARPEthernet_IIEthernet_SNAPToken-Ring_SNAPNovell_RX-Net803580358035d6DefaultsName: IPXID: 0Frame: Ethernet_802.3ExampleTo specify the ARP protocol for an Ethernet II  frame:link driver NE2000   protocol arp 806 ethernet_iiID="FM91351"slot idxid="w627"book="_idx" docset="nw312" tidref="i3201"Use this setting to tell the Requester which expansion slot an EISA or MicroChannel board is using. EISA and Micro Channel boards are self-configuring, and the Requester can obtain all Link Driver information from the board itself. You have to tell the Requester which slot the board is using or, if you only have one board of a particular type, tell the Requester to scan all slots until it finds that board. . WIDTH="60"SyntaxWIDTH="240"link driver name   slot numberReplace number with the number of the  expansion slot the board is using or a question  mark to tell Requester to scan all slots. DefaultSlot ?ExampleTo automatically configure the drivers for an  NE/2 board in slot 4 and an NE/2 board in slot 2:link driver ne2   slot 4link driver ne2   slot 2This slot setting is the only Link Driver hardware- related setting you need to specify in this case. To scan the slots for a Novell Ethernet NE/2  board:link driver ne2   slot ?ID="FM25534"ID="FM30704"Link Support idxid="w628"book="_idx" docset="nw312" tidref="i4127"idxid="w629"book="_idx" docset="nw312" tidref="i3215"Use this option to adjust the number and size of communication buffers used by the Requester.Syntax  link support     buffers number [buffer_size]Settingsbuffers idxid="w630"book="_idx" docset="nw312" tidref="i860"WIDTH="60"SyntaxWIDTH="240"Replacenumber with a number of buffers greater  than 1. Replacebuffer_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.DefaultsNumber: 20 buffersBuffer_size: 1514 bytesExamplesFor an Ethernet configuration:link support   buffers 15 2800For a Token-Ring configuration:link support   buffers 14 4210NotesIncreasing efficiency. For most efficient communication, your link support buffer size should be the same size as the packets that your workstation will receive over the network. You may want to set the link support buffer size equal to the largest buffer size that the network boards in your workstation will support. Using the TRXNET.SYS driver. If your workstation experiences performance problems running with TRXNET.SYS, you may need to reconfigure the number and size of link support buffers allowed. Set the following values:   link support     buffers 15 4202TRXNET.SYS only supports SMC100, 110, and 120 cards. ID="FM59417"Named Pipes idxid="w631"book="_idx" docset="nw312" tidref="i4007"idxid="w632"book="_idx" docset="nw312" tidref="i4127"Use this option to manage Named Pipes sessions. Syntax  named pipes     client sessions number     server sessions number     service threads numberSettingsclient sessions idxid="w633"book="_idx" docset="nw312" tidref="i986"idxid="w634"book="_idx" docset="nw312" tidref="i4025"Use this setting to specify the maximum number of connections a workstation can establish with all Named Pipes servers. WIDTH="60"SyntaxWIDTH="240"named pipes   client sessions numberReplace number with a number from 3 to 128.You need at least one client session for each  connection from an OS/2 application to a Named  Pipes server. Default16 sessions.The default is usually adequate, except with  applications that use many Named Pipes.ExampleTo allow each client thirty sessions:named pipes   client sessions 30server sessions idxid="w635"book="_idx" docset="nw312" tidref="i4025"idxid="w636"book="_idx" docset="nw312" tidref="i6240"Use this setting to specify the maximum number of connections a Named Pipes server can support with all Named Pipes clients at any one time.WIDTH="60"SyntaxWIDTH="240"named pipes   server sessions numberReplace number with a number greater than 2. Novell's Named Pipes support is designed to  handle more than 1,000 server sessions; however,  because of OS/2 requirements, the practical upper  limit is much lower (around 400).You must have one more idxid="w637"book="_idx" docset="nw312" tidref="i6450"SPX session than  you  have Named Pipes server and client sessions  combined  (see IDREF="FM73864""Protocol Stack SPX" option on  page 277). If you specify fewer SPX sessions than Named  Pipes server sessions, the Requester will treat the  SPX session number as the maximum number of  Named Pipes server sessionsDefault32 sessions.ExampleTo allow each server three hundred sessions:named pipes   server sessions 300service threads idxid="w638"book="_idx" docset="nw312" tidref="i4025"idxid="w639"book="_idx" docset="nw312" tidref="i6267"Use this setting to specify the  number of threads the Named Pipes server can use to handle requests from all clients. WIDTH="60"SyntaxWIDTH="240"named pipes   service threads numberReplace number with a number from 1 to 32. If the client  application uses blocking pipes,  increase this default. If the client  application uses  non-blocking pipes, use the default value for  better performance. SQL Server does not use  blocking pipes.Default3 threadsExampleTo increase the number of threads a Named Pipes  server can use to twenty:named pipes   service threads 20For an OS/2 workstation to function as a Named Pipes server or client, you must have selected Named Pipes when you installed the Requester on that workstation.  See IDREF="FM26379""Installing Named Pipes for OS/2" on page 135.ID="FM99769"NetWare NetBIOS idxid="w640"book="_idx" docset="nw312" tidref="i4127"idxid="w641"book="_idx" docset="nw312" tidref="i4169"idxid="w642"book="_idx" docset="nw312" tidref="i4203"idxid="w643"book="_idx" docset="nw312" tidref="i4316"Use this option to manage NetBIOS names and sessions or to affect the internal memory allocation for NetBIOS. LBL="B-4" INLINE="F"Categories of NetWare NetBIOS settingsWIDTH="120"PurposeWIDTH="132"SettingWIDTH="48"PageWIDTH="120"Name managementWIDTH="132"Broadcast countBroadcast delayInternetNamesWIDTH="48"IDREF="FM60878"258IDREF="FM30147"259IDREF="FM23424"260IDREF="FM40911"261Session creationRetry countRetry delaySessionsIDREF="FM50189"262IDREF="FM63912"262IDREF="FM65254"263Session managementAbort timeoutListen timeoutVerify timeoutIDREF="FM52917"257IDREF="FM52917"257IDREF="FM52917"257Command managementCommandsIDREF="FM56421"260Syntax  netware netbios     abort timeout number     broadcast count number     broadcast delay number     commands number     internet [on|off]     listen timeout number     names number     retry count number     retry delay number     sessions number     verify timeout numberSettingsID="FM52917"abort idxid="w644"book="_idx" docset="nw312" tidref="i72"timeout idxid="w645"book="_idx" docset="nw312" tidref="i4316"listen idxid="w646"book="_idx" docset="nw312" tidref="i3228"timeout idxid="w647"book="_idx" docset="nw312" tidref="i4316"verify idxid="w648"book="_idx" docset="nw312" tidref="i7286"timeout idxid="w649"book="_idx" docset="nw312" tidref="i4316"Use these settings to monitor and control your NetBIOS connections. When NetBIOS sessions at a sending computer do not receive any transmissions from the receiving computer for the length of the "verify timeout" interval, NetBIOS sends a request-for-acknowledgment packet to the receiving computer.   NetBIOS then waits the length of the "listen timeout" interval to receive a response. If no response is received, NetBIOS sends another packet requesting immediate response. NetBIOS then waits the length of the "abort timeout" interval to receive a response. If no response is received, NetBIOS terminates the session.WIDTH="60"SyntaxWIDTH="240"netware netbios   abort timeout number   listen timeout number   verify timeout numberAbort timeout: Replace number with a number of  milliseconds greater than 500. Listen timeout: Replacenumber with a number of  milliseconds greater than 200Verify timeout: Replace number with a number of  milliseconds greater than 100. WIDTH="60"Syntax WIDTH="240"The ratio between these settings must remain the  same. For example, if you double the Listen  timeout value, you must also double the Abort  timeout and Verify timeout values.DefaultsAbort timeout: 30,000 millisecondsListen timeout: 6,000 millisecondsVerify timeout: 3,000 millisecondsExamplesTo make NetBIOS wait longer before sending a  request-for acknowledgment packet, sending the  packet requesting immediate response, and  terminating the session:netware netbios   abort timeout 45000   listen timeout 8000   verify timeout 4000ID="FM60878"broadcast idxid="w650"book="_idx" docset="nw312" tidref="i767"count idxid="w651"book="_idx" docset="nw312" tidref="i4316"Use this setting to specify how many times NetBIOS broadcasts a query or claim for the name being used by an application.WIDTH="60"SyntaxWIDTH="240"netware netbios   broadcast count numberReplace number with a number of queries greater  than 1. DefaultsWith internet on: 4 times.With internet off: 2 times.ExampleTo broadcast more often:netware netbios   broadcast count 8ID="FM30147"broadcast idxid="w652"book="_idx" docset="nw312" tidref="i768"delay idxid="w653"book="_idx" docset="nw312" tidref="i4316"Use this setting to specify how long NetBIOS waits between query or claim broadcasts. WIDTH="60"SyntaxWIDTH="240"netware netbios   broadcast delay numberReplace number with a number of milliseconds  greater than 100. DefaultsWith internet on: 2,000With internet off: 1,000ExampleTo wait longer between broadcasts:netware netbios   broadcast delay 3000ID="FM56421"commands idxid="w654"book="_idx" docset="nw312" tidref="i1052"idxid="w655"book="_idx" docset="nw312" tidref="i4316"Use this setting to specify how many NetBIOS commands can be buffered in the NetBIOS driver at any one time. WIDTH="60"SyntaxWIDTH="240"netware netbios   commands numberReplace number with a number of commands  from 8 to 64. Default32 commandsExampleTo run an application that requires a large  number of outstanding commands:netware netbios   commands 64ID="FM23424"internet idxid="w656"book="_idx" docset="nw312" tidref="i2943"idxid="w657"book="_idx" docset="nw312" tidref="i4316"Use this setting to transmit name-claim packets to and from all stations on the internetwork, or to and from stations on the local network only. Name-claim packets are packets that attempt to establish the uniqueness of the name of the station on which NetBIOS is running. WIDTH="60"SyntaxWIDTH="240"netware netbios   internet [on|off]Type on or off. DefaultOnExampleTo send and receive on the local network only:netware netbios   internet offID="FM40911"names idxid="w658"book="_idx" docset="nw312" tidref="i4029"idxid="w659"book="_idx" docset="nw312" tidref="i4316"Use this setting to specify how many names the workstation can have in its name table for remote stations. When you add a name to a station, the station broadcasts that name to all other nodes on the network.WIDTH="60"SyntaxWIDTH="240"netware netbios   names numberReplacenumber with a number of names from 4  to 64. You can use a name instead of a node address to  refer to a remote station.Default24 namesExampleTo allow 45 names:netware netbios   names 45ID="FM50189"retry count idxid="w660"book="_idx" docset="nw312" tidref="i4316"idxid="w661"book="_idx" docset="nw312" tidref="i5931"Use this setting to specify how many times NetBIOS transmits a request for connection or retransmits a failed communication. WIDTH="60"SyntaxWIDTH="240"netware netbios   retry count numberReplace number with a number greater than 0. Default20 timesExampleTo retransmit fifty times:netware netbios   retry count 50ID="FM63912"retry delay idxid="w662"book="_idx" docset="nw312" tidref="i4316"idxid="w663"book="_idx" docset="nw312" tidref="i5934"Use this setting to specify how many milliseconds NetBIOS waits between transmissions while establishing a connection or resending a data packet. WIDTH="60"SyntaxWIDTH="240"netware netbios   retry delay numberReplace number with a number of milliseconds  greater than 0. Default500 millisecondsExampleTo wait eight hundred milliseconds between  retransmission attempts:netware netbios   retry delay 800ID="FM65254"sessions idxid="w664"book="_idx" docset="nw312" tidref="i4316"idxid="w665"book="_idx" docset="nw312" tidref="i6281"Use this setting to specify how many simultaneous NetBIOS sessions can be supported by the NetBIOS driver. WIDTH="60"SyntaxWIDTH="240"netware netbios   sessions numberReplace number with a number of sessions from 4  to 64. Default16 sessionsExampleTo allow one hundred NetBIOS sessions:netware netbios   sessions 50ID="FM57102"NetWare Requester idxid="w666"book="_idx" docset="nw312" tidref="i4127"idxid="w667"book="_idx" docset="nw312" tidref="i4203"idxid="w668"book="_idx" docset="nw312" tidref="i4342"Use this option to control network requests from your workstation to a NetWare server. Syntax  netware requester     cache buffers number     directory services off     large internet packets off     name context context     packet burst off     preferred servername     preferred tree treename     request retries number     sessions number     signature level numberSettingscache idxid="w669"book="_idx" docset="nw312" tidref="i891"buffers idxid="w670"book="_idx" docset="nw312" tidref="i860"idxid="w671"book="_idx" docset="nw312" tidref="i4351"Use this setting to specify how many buffers the Requester can use to cache data from open files. Cache buffers minimize read and write traffic on the network. The more buffers there are, the faster the Requester performs; however, more buffers use up more memory.The Requester automatically uses the maximum buffer size permitted by each server to which the Requester is connected. However, the Requester cannot use more than 64 KB of total memory for cache buffers. Therefore, if the buffer size is large, you may not be allowed as many buffers as you specify.WIDTH="60"SyntaxWIDTH="240"netware requester   cache buffers numberReplace number with a number of buffers from 0  to 30. To turn off caching, specify 0.Default8 buffersExampleTo allow 15 cache buffers:netware requester   cache buffers 15directory services offUse this setting to disable directory services if you are on a NetWare 2.x or 3.x server. This will improve speed and overall performance because the Requester does not have to time out to establish initial connections with a NetWare v4.0 server. WIDTH="60"SyntaxWIDTH="240"netware requester   directory services offType directory services  off to disable directory  services.DefaultDirectory services is enabled.ExampleTo disable directory services:netware requester   directory services offlarge internet packets offUse this setting to disable large internet packets transmission. IDREF="FM16745""Improving Speed and Security" on page 65  explains more about large internet packets. WIDTH="60"SyntaxWIDTH="240"netware requester   large internet packets offType large internet packets off to turn off large  packet transmissions.DefaultLarge internet packets are transmitted.ExampleTo disable large packet transmission:netware requester   large internet packets offname context idxid="w672"book="_idx" docset="nw312" tidref="i4351"Use this setting to specify the workstation's name context in the directory services tree. Concepts explains more about name contexts. WIDTH="60"SyntaxWIDTH="240"netware requester   name context "context"Replace context with your name context in the  directory tree.DefaultAt the root of the tree.ExampleTo specify a name context:netware requester   name context "john.sales.novell us" ID="FM89210"packet burst off idxid="w673"book="_idx" docset="nw312" tidref="i4351"Use this setting to disable the packet burst feature. IDREF="FM54026""Improving Speed with Packet Burst" on page 66 explains more about the Packet Burst feature. WIDTH="60"SyntaxWIDTH="240"netware requester   packet burst offDefaultPacket burst is enabled. ExampleTo disable packet burst:netware requester   packet burst offID="FM61797"preferred server idxid="w674"book="_idx" docset="nw312" tidref="i4351"idxid="w675"book="_idx" docset="nw312" tidref="i5137"Use this setting to specify which NetWare server you want your workstation to attach to when it first accesses the network. If the server you specify is unavailable, your workstation will attach to the first available server. WIDTH="60"SyntaxWIDTH="240"netware requester   preferred server servernameReplace servername with the name of a server. The  server you specify should probably have the  NetWare utilities for OS/2 installed. DefaultNoneExampleTo attach to server FINANCE:netware requester   preferred server financeID="FM68034"preferred tree idxid="w676"book="_idx" docset="nw312" tidref="i4351"idxid="w677"book="_idx" docset="nw312" tidref="i5144"Use this setting to specify a tree name to connect. This setting is only for sites with more than one directory tree.WIDTH="60"SyntaxWIDTH="240"netware requester   preferred tree treenameReplace treename with the name of your tree. Tree  names can have up to 32 characters.DefaultNone.ExampleTo connect to  a tree named Novell:netware requester   preferred tree novellrequest retries idxid="w678"book="_idx" docset="nw312" tidref="i4351"idxid="w679"book="_idx" docset="nw312" tidref="i5864"Use this setting to specify how many times the Requester tries to resend a request following a communication error. WIDTH="60"SyntaxWIDTH="240"netware requester   request retries numberReplace number with a number of retries greater  than 5. Default20.ID="FM49382"Decrease the default if you are connected to the  network over a modem and you do not want to  waste phone time while the Requester keeps  trying to resend packets. ExampleTo decrease the number of times the Requester  tries to resend a packet:netware requester   request retries 10ID="FM17923"sessions idxid="w680"book="_idx" docset="nw312" tidref="i4351"idxid="w681"book="_idx" docset="nw312" tidref="i6281"Use this setting to specify the number of connections the Requester can have to all servers. WIDTH="60"SyntaxWIDTH="240"netware requester   sessions numberReplace number with a number of connections  from 8 to 32.  You must have at least three idxid="w682"book="_idx" docset="nw312" tidref="i3005"IPX  sockets for each session you allow. (See the IDREF="FM26008""sockets" setting on page 276.)Default8 sessionsExampleTo allow more server connections:netware requester   sessions 20You must also increase the sockets setting for the  Protocol Stack IPX option in this case.signature level idxid="w683"book="_idx" docset="nw312" tidref="i4351"Use this setting to assign a signature level. Signature levels help determine security on your network. IDREF="FM94412""Improving Security by Using Packet Signature" on page 67 explains more about signature levels.WIDTH="60"SyntaxWIDTH="240"NetWare Requester   signature level numberReplace number with 0, 1, 2, or 3.LBL="B-5" INLINE="F"ID="FM52897"List of NCP Packet Signature levelsWIDTH="60"NumberWIDTH="240"ExplanationWIDTH="60"0WIDTH="240"Workstation does not sign packets1Workstation signs packets only if the server requests it  (server option is 2 or higher)2Workstation signs packets if the server is capable of  signing (server option is 1 or higher)3Workstation signs packets and requires the server to sign  packets (or logging in will fail)IDREF="FM52897"Table B-5The default signature level anWIDTH="60"DefaultWIDTH="240"1 (Workstation signs packets only if the server  requests signing.)ExampleTo prevent the workstation from signing packets:netware requester   signature level 0ID="FM53606"Protocol ODINSUP idxid="w684"book="_idx" docset="nw312" tidref="i4127"idxid="w685"book="_idx" docset="nw312" tidref="i5610"Use this option to allow the NDIS protocol stack (used with Extended Services and LAN Services) to communicate using ODI Token-Ring or Ethernet drivers. IDREF="FM39812"See "Sharing a Network Board With IBM Software" on page 81 before using this option. Syntax  protocol odinsup     bind driver [number]SettingsbindUse this setting to bind the ODINSUP protocol to an ODI driver. When ODINSUP is bound to a driver, the network board for that driver is the board used for transmissions to and from the network.WIDTH="60"SyntaxWIDTH="240"protocol odinsup   bind driver[number]Replace driver with a Token-Ring or Ethernet ODI  driver name. See IDREF="FM37012"Table B-1, "List of network  boards and drivers," on page 240 for a list of  common driver names.Use number to bind ODINSUP to a particular  occurrence of a board when you have two boards  with the same name. Replace number with a  number from 1 to 4.For example, if you have two NE2000 network  boards in your workstation, bind ODINSUP to  each board by typing a 2 for the second board.ODINSUP can be bound to a maximum of four  ODI drivers.DefaultODINSUP binds to the first Ethernet or Token- Ring board it locates.ExamplesTo bind ODINSUP to a single NE2000 board in  your workstation:protocol ODINSUP   bind ne2000To bind ODINSUP to both the first and the  second NE2000 boards in your workstation:Protocol ODINSUP   bind ne2000   bind ne2000 2idxid="w686"book="_idx" docset="nw312" tidref="i5616"idxid="w687"book="_idx" docset="nw312" tidref="i4127"ID="FM38316"Protocol Stack IPX idxid="w688"book="_idx" docset="nw312" tidref="i3005"idxid="w689"book="_idx" docset="nw312" tidref="i5616"Use this option to adjust IPX communication between applications and the LAN drivers in your workstation.Syntax  protocol stack ipx     bind name     router mem size     sockets numberSettingsbind idxid="w690"book="_idx" docset="nw312" tidref="i5616"Use this setting to specify the primary network board in your workstation. By default, the primary board is the board whose driver loads first in the CONFIG.SYS file. If you specify a different board with this setting, that default is changed. See IDREF="FM16745"Chapter 5, "Network Boards and Drivers."WIDTH="60"SyntaxWIDTH="240"protocol stack ipx   bind nameReplace name with the driver name for your  network board. IDREF="FM37012"Table B-1, "List of network boards and drivers,"  on page 240 lists common network boards.DefaultThe first driver listed in your CONFIG.SYS file.ExampleTo specify a 3Com Etherlink 3C503 board as  primary:protocol stack ipx   bind 3C503router mem idxid="w691"book="_idx" docset="nw312" tidref="i5616"idxid="w692"book="_idx" docset="nw312" tidref="i6034"Use this setting to specify how many bytes in the router memory pool are allocated for routing requests to the network. WIDTH="60"SyntaxWIDTH="240"protocol stack ipx   router mem sizeReplace size with a number of bytes. Default450 bytesSince a size of 450 bytes accommodates up to 15  network boards per workstation, you should not  need to increase this default. ExampleTo increase the default:protocol stack ipx   router mem 500ID="FM26008"sockets idxid="w693"book="_idx" docset="nw312" tidref="i5616"idxid="w694"book="_idx" docset="nw312" tidref="i6395"Use this setting to specify how many sockets IPX can open at your workstation. WIDTH="60"SyntaxWIDTH="240"protocol stack ipx   sockets numberReplacenumber with a number of sockets between  9 and 128. If you are running IPX with the  Requester, do not set this value below 32. You need three sockets per server connection. The  default of 64 works for the default number of  server connections (see the IDREF="FM17923""sessions" setting on  page 270). Allow more sockets if your workstation connects  to many different servers or runs protocols (such  as idxid="w695"book="_idx" docset="nw312" tidref="i4007"Named Pipes) that require sockets. Default64 socketsExampleTo set the socket limit for a workstation  connected to several servers that is running  Named Pipes and applications that require  sockets:protocol stack ipx   sockets 128ID="FM73864"Protocol Stack SPX idxid="w696"book="_idx" docset="nw312" tidref="i4127"idxid="w697"book="_idx" docset="nw312" tidref="i5621"idxid="w698"book="_idx" docset="nw312" tidref="i6450"idxid="w699"book="_idx" docset="nw312" tidref="i5621"Use this option to adjust the number and characteristics of SPX connections between your workstation and other computers. Syntax  protocol stack spx     abort timeout number     listen timeout number     retry count number     send timeout number     sessions number     verify timeout numberSettingsabort idxid="w700"book="_idx" docset="nw312" tidref="i72"timeout idxid="w701"book="_idx" docset="nw312" tidref="i5621"listen idxid="w702"book="_idx" docset="nw312" tidref="i3228"timeout idxid="w703"book="_idx" docset="nw312" tidref="i5621"verify idxid="w704"book="_idx" docset="nw312" tidref="i7286"timeout idxid="w705"book="_idx" docset="nw312" tidref="i5621"Use these settings to monitor and control SPX connections. When SPX sessions at a sending computer do not receive transmissions from the receiving computer for the length of the "verify timeout" interval, SPX sends a keep-connection-alive packet to the receiving computer.   SPX then waits the length of the "listen timeout" interval to receive a response. If no response is received, SPX sends another packet requesting immediate acknowledgment. SPX then waits the length of the "abort timeout" interval to receive a response.If no response is received, SPX aborts the session. WIDTH="60"SyntaxWIDTH="240"protocol stack spx   abort timeout number   listen timeout number   verify timeout numberReplace number with a number of milliseconds  greater than 10. The ratio between these settings must remain the  same. For example, if you double the Listen  timeout value, you must also double the Abort  timeout and Verify timeout values.If the machine you are setting up will be a Named  Pipes server, double the default timeout values.DefaultAbort timeout: 30,000 millisecondsListen timeout: 6,000 millisecondsVerify timeout: 3,000 millisecondsExample To make SPX wait longer before sending a keep- connection-alive packet, sending the packet  requesting immediate response, or aborting the  session:protocol stack spx   abort timeout 40000   listen timeout 8000   verify timeout 4000retry count idxid="w706"book="_idx" docset="nw312" tidref="i5621"idxid="w707"book="_idx" docset="nw312" tidref="i5931"Use this setting to specify the number of times your workstation will resend packets that weren't acknowledged by the receiving computer the first time they were sentSome applications may set the "retry count" value. In these cases, the application-set value is used and the NET.CFG value is ignored. WIDTH="60"SyntaxWIDTH="240"protocol stack spx   retry count numberReplacenumber with a number of retries from 1 to  255. If your network traffic is heavy or if you are  transmitting across routers, you may want to  increase the default. Default15 retriesExampleTo increase the number of times packets are  resent:protocol stack spx   retry count 30send timeout idxid="w708"book="_idx" docset="nw312" tidref="i5621"idxid="w709"book="_idx" docset="nw312" tidref="i6226"Use this setting to specify how long SPX waits between attempts to send packets across the network.WIDTH="60"SyntaxWIDTH="240"protocol stack spx   send timeout numberReplace number with a number of milliseconds  greater than 500. This default works well in almost all cases.  Increase the default if you are using network  management products with a very large network  and you encounter many SPX connection errors. You may also want to increase the default for a  Named Pipes client that is operating faster than  the Named Pipes server to which it is connected.DefaultA continually calculated value based on the time  it takes SPX to get a response from the server.ExampleTo increase the wait between sends:protocol stack spx   send timeout 5600ID="FM17121"sessions idxid="w710"book="_idx" docset="nw312" tidref="i5621"idxid="w711"book="_idx" docset="nw312" tidref="i6281"Use this setting to specify how many SPX connections can be open simultaneously. WIDTH="60"SyntaxWIDTH="240"protocol stack spx   sessions numberReplace number with a number of SPX  connections greater than 8. Numbers higher than  1,000 may not work in all circumstances. If you run Named Pipes applications or other  applications that use SPX, you may need to  increase the default number of sessions.Default16 sessionsExampleTo increase the number of SPX sessions:protocol stack spx   sessions 64idxid="w712"book="_idx" docset="nw312" tidref="i4127"ID="FM53519"ID="FM11885"ID="FM94488"Token-Ring idxid="w713"book="_idx" docset="nw312" tidref="i6429"Source-Route DriverUse this option to configure the Requester for source-routing between Token-Ring networks that are connected with source routers. For more information about source routing, see IDREF="FM63720"Chapter 7, "Using OS/2 Workstations on a Token-Ring Network."Do not use this option if your Token-Ring networks do not use source routing. Syntax  protocol route     source route defgbrmbr nodes n board nSettingsboard idxid="w714"book="_idx" docset="nw312" tidref="i6829"Use this setting to specify the logical board (frame) of a particular type that is performing source routing. WIDTH="60"SyntaxWIDTH="240"protocol route   source route board nReplacen with a logical board (frame) number  from 1 to 16.For example, if a workstation has more than one  frame type listed in the Link Driver option, by  default only the first listed frame is source routed.  To enable source routing on the second or other  frames, you must explicitly specify the second  frame as logical board 2. Default1ExampleTo specify that logical board 2, the Token- Ring_SNAP frame, will also be source routed:link driver token   frame token-ring   frame token-ring_snapprotocol route   source route board 1   source route board 2DEF idxid="w715"book="_idx" docset="nw312" tidref="i1335"idxid="w716"book="_idx" docset="nw312" tidref="i6829"Use this setting (default frame) to prevent frames that have unknown destination addresses from being sent across Single Route IBM bridges.If this setting is specified, these frames are forwarded as All Routes Broadcast frames.If this setting is not specified, all frames that have addresses not in the workstation's Source Routing table are forwarded as Single Route Broadcast frames.If ROUTE.SYS has already been configured with the DEF setting, reloading ROUTE.SYS with this setting broadcasts all subsequent Single Route Broadcast frames as All Routes Broadcast frames. WIDTH="60"SyntaxWIDTH="240"protocol route   source route defType DEF to broadcast on all routes. Omit DEF to  broadcast on a single route only. DefaultDEF is omitted (single-route broadcast only)Change this default when you are unsure of the  stability of one or more routes in the network. Be  aware that using DEF will substantially increase  network traffic, especially on large, redundant  ring networks. ExampleTo broadcast on all routes:protocol route   source route defGBR idxid="w717"book="_idx" docset="nw312" tidref="i2540"idxid="w718"book="_idx" docset="nw312" tidref="i2541"idxid="w719"book="_idx" docset="nw312" tidref="i6829"Use this setting (general broadcast) to specify that all General BRoadcast frames are to be sent as All Routes Broadcast framesWIDTH="60"SyntaxWIDTH="240"protocol route   source route gbr Type GBR to broadcast to all destinations, on all  rings, by all routes. Omit GBR to broadcast to all  destinations, on all rings, by a single route. Change the default when you want to ensure  successful transmission across all possible routes.  If ROUTE has already been configured with this  setting, reconfiguring ROUTE with this setting  broadcasts all subsequent General Broadcast  frames as All Routes Broadcast frames.DefaultGBR is omitted (single route broadcast only)ExampleTo broadcast to all destinations, on all rings, by  all routes:protocol route   source route gbrMBR idxid="w720"book="_idx" docset="nw312" tidref="i3749"idxid="w721"book="_idx" docset="nw312" tidref="i3969"idxid="w722"book="_idx" docset="nw312" tidref="i6829"Use this setting (multicast) to specify that all Multicast Broadcast frames are to be sent as All Routes Broadcast frames.WIDTH="60"SyntaxWIDTH="240"protocol route   source route mbrType MBR to transmit multicast frames  simultaneously to a group of destinations by all  possible routes. Omit MBR to transmit multicast  frames by a single route. DefaultMBR is omitted (transmit by single route only)If ROUTE has already been configured with the  MBR setting, reconfiguring ROUTE with this  parameter broadcasts all subsequent Multicast  Broadcast frames as All Routes Broadcast frames. ExampleTo broadcast multicast frames simultaneously:protocol route   source route mbrnodes idxid="w723"book="_idx" docset="nw312" tidref="i4660"idxid="w724"book="_idx" docset="nw312" tidref="i6829"Use this setting to specify the number of table entries in the source-routing table. WIDTH="60"SyntaxWIDTH="240"protocol route   source route nodes nReplacen with a number of table entries from 8 to  255. If you type a number less than 8, 8 will be  used. Default16 entriesExampleTo allow twenty-four entries in the source- routing table:protocol route   source route nodes 24LBL="C"ID="FM78537"Architecture Diagrams idxid="w725"book="_idx" docset="nw312" tidref="i1422"idxid="w726"book="_idx" docset="nw312" tidref="i453"idxid="w727"book="_idx" docset="nw312" tidref="i4342"These diagrams provide a technical overview of the NetWare idxid="w728"book="_idx" docset="nw312" tidref="i6759"Requester for OS/2 v2.01. They can help you understand what components are used for the various functions the Requester performs (for example, which components are used to support Named Pipes). Specifically, the diagrams illustrate:The major functions of the Requester componentsThe different components of the Requester The relationships between componentsYou do not need to manually load the components shown in the diagrams. Select the settings you want in the Requester installation program, and the correct components will be loaded. To change the settings later, simply run the installation program again.WIDTH="372"Topics and architecture diagramsWIDTH="48"PageWIDTH="372"IDREF="FM78534"NetWare Requests from OS/2 SessionsWIDTH="48"IDREF="FM78534"289WIDTH="372"IDREF="FM21791"NetWare Core Protocol requestsWIDTH="48"IDREF="FM21791"289IDREF="FM69549"File system requestsIDREF="FM69549"290WIDTH="372"IDREF="FM57835"Protocol Requests from OS/2 SessionsWIDTH="48"IDREF="FM57835"291IDREF="FM18520"IPX-only requestsIDREF="FM18520"291IDREF="FM55192"SPX requestsIDREF="FM55192"292IDREF="FM94933"Named Pipes server requestsIDREF="FM94933"293IDREF="FM81088"Named Pipes client requestsIDREF="FM81088"294WIDTH="372"IDREF="FM57835"Protocol Requests from OS/2 Sessions (continued)WIDTH="48"IDREF="FM57835"291IDREF="FM56593"NetBIOS Submit requests using only Novell NetBIOS driverIDREF="FM56593"296IDREF="FM37878"NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services  loadedIDREF="FM37878"297IDREF="FM61486"NetBIOS Submit requests using either Novell or IBM NetBIOS driver with LAN Services  loadedIDREF="FM61486"298IDREF="FM62676"NB30 NetBIOS requests using either Novell or IBM NetBIOS driver with Extended Services  loadedIDREF="FM62676"299WIDTH="372"IDREF="FM10716"NetWare Requests from DOS/Windows SessionsWIDTH="48"IDREF="FM10716"300IDREF="FM15172"DOS/Windows NetWare Core Protocol requestsIDREF="FM15172"301IDREF="FM10180"DOS/Windows file system requestsIDREF="FM10180"302WIDTH="372"IDREF="FM33194"Protocol Requests from DOS/Windows SessionsWIDTH="48"IDREF="FM33194"303IDREF="FM74691"DOS/Windows SPX- or IPX-only requestsIDREF="FM74691"303IDREF="FM45098"DOS/Windows Named Pipes client requestsIDREF="FM45098"304IDREF="FM54260"DOS/Windows SQL client "Get Server" requestsIDREF="FM54260"305IDREF="FM67882"DOS and Windows NetBIOS requestsIDREF="FM67882"306IDREF="FM19648"NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services  loadedIDREF="FM37878"297WIDTH="372"IDREF="FM23686"Sharing a Network BoardWIDTH="48"IDREF="FM23686"308IDREF="FM86551"NetWare Requester and IBM software using ODINSUP to share a network boardIDREF="FM86551"309IDREF="FM15783"NetWare Requester and IBM software using LANSUP to share a network boardIDREF="FM15783"310ID="FM78534"NetWare Requests from OS/2 SessionsID="FM35513"NetWare Core Protocol RequestsNetWare Core Protocol requests go directly to the NetWare server without going through OS/2. Some of the NetWare utilities issue this kind of request. These requests are usually accompanied by file system requests, shown on page IDREF="FM49591"290.LBL="C-1"ID="FM21791"NetWare Core Protocol requestsFILE="c312q20a.pbm"ID="FM49591"File System Requests idxid="w729"book="_idx" docset="nw312" tidref="i2282"File system requests idxid="w730"book="_idx" docset="nw312" tidref="i2282"are handled by OS/2 before being passed on to the NetWare Requester. Any program which manipulates files on the network makes this kind of request. These requests are always accompanied by NetWare Core Protocol requests, shown on IDREF="FM35513"page 289.LBL="C-2"ID="FM69549"File system requestsFILE="c312q21a.pbm"ID="FM57835"Protocol Requests from OS/2 SessionsIPX-Only RequestsIPX requests are issued by IPX applications, including the Requester.LBL="C-3"ID="FM18520"IPX-only requestsFILE="c312q23a.pbm"SPX RequestsSPX requests are issued by SPX applications. Some NetWare print utilities and API calls use SPX.LBL="C-4"ID="FM55192"SPX requestsFILE="c312q22a.pbm"ID="FM24944"Named Pipes Server Requests idxid="w731"book="_idx" docset="nw312" tidref="i4007"Named Pipes server requests are made by Named Pipes distributed application servers.LBL="C-5"ID="FM94933"Named Pipes server requestsFILE="c312q24a.pbm"ID="FM17647"Named Pipes Client Requests idxid="w732"book="_idx" docset="nw312" tidref="i4007"Named Pipes client requests are issued by Named Pipes distributed application clients.LBL="C-6"ID="FM81088"Named Pipes client requestsFILE="c312q25a.pbm"ID="FM29449"NetBIOS RequestsWhat is NetBIOS idxid="w733"book="_idx" docset="nw312" tidref="i4169"NetBIOS is a "device-independent" protocol that lets applications use network boards without knowing the specifics of how the drivers for those boards work. NetBIOS applications issue NetBIOS commands which are routed to a specific network board driver. That driver handles the transmission of NetBIOS packets over the network. What is the Novell NetBIOS EmulatorNovell provides a NetBIOS emulator that allows applications running on an IPX-based network (such as NetWare) to communicate using NetBIOS. This NetBIOS emulator encapsulates NetBIOS packets inside of IPX packets. Then an ODI driver handles transmission of the IPX packets over the network. While your NetBIOS application communicates using NetBIOS commands, the NetBIOS emulator actually transmits IPX packets. The Novell NetBIOS emulator can only communicate with other emulators that use IPX. For example, if you have one workstation running the NetBIOS emulator and another workstation running IBM's NetBIOS, the two workstations cannot communicate. However, the NetBIOS emulator can run on the same OS/2 workstation as other NetBIOS implementations, including the NetBIOS provided with IBM Extended Services or LAN Services. Or, the NetBIOS emulator can run by itself. NetBIOS requests are issued by applications which use Novell NetBIOS emulation. If Extended Services or LAN Services is installed, requests follow a different path. See pages IDREF="FM14506"297 through IDREF="FM62676"299. LBL="C-7"ID="FM56593"NetBIOS Submit requests using only Novell NetBIOS driverFILE="c312q26a.pbm"LBL="C-8"ID="FM37878"ID="FM19648"ID="FM14506"NetBIOS Submit requests using only Novell NetBIOS driver with Extended Services loadedFILE="c312q36a.pbm"LBL="C-9"ID="FM61486"NetBIOS Submit requests using either Novell or IBM NetBIOS driver with LAN Services loadedFILE="c312q37a.pbm"LBL="C-10"ID="FM62676"NB30 NetBIOS requests using either Novell or IBM NetBIOS driver with Extended Services loadedFILE="c312q38a.pbm"ID="FM10716"NetWare Requests from DOS/Windows SessionsWhen you select "Support for Virtual DOS Sessions" in the NetWare Requester installation program, the installation program adds lines to the CONFIG.SYS file to load the VIPX and VSHELL components.The NETWARE_RESOURCES and VIPX_ENABLED properties are also created and added to the "DOS Settings" notebook of all DOS and Windows icons. These properties allow you to choose global support, private support, or no network support for each session.If you choose global support, VIPX and VSHELL are enabled for the session. If you choose private support, VIPX is enabled, VSHELL is not enabled, and you can manually load NETX.EXE If you don't load NETX.EXE, you receive IPX- and SPX-only support. If you choose VIPX_ENABLED OFF, then no NetWare support is loaded. VIPX must be enabled for either Global (using VSHELL) or Private (using NETX) sessions to work.LBL="C-11"ID="FM15172"DOS/Windows NetWare Core Protocol requestsFILE="c312q27a.pbm"LBL="C-12"ID="FM10180"DOS/Windows file system requests idxid="w734"book="_idx" docset="nw312" tidref="i2282"FILE="c312q28a.pbm"ID="FM33194"Protocol Requests from DOS/Windows SessionsLBL="C-13"ID="FM74691"DOS/Windows SPX- or IPX-only requestsFILE="c312q29a.pbm"LBL="C-14"ID="FM45098"DOS/Windows Named Pipes client idxid="w735"book="_idx" docset="nw312" tidref="i4007"requestsFILE="c312q30a.pbm"LBL="C-15"ID="FM54260"DOS/Windows SQL idxid="w736"book="_idx" docset="nw312" tidref="i6461"client "Get Server" requestsFILE="c312q31a.pbm"LBL="C-16"ID="FM67882"DOS and Windows NetBIOS requestsFILE="c312q32a.pbm"LBL="C-17"DOS and Windows NetBIOS requests with Extended Services loadedID="FM19648"FILE="c312q39a.pbm"ID="FM23686"Sharing a Network BoardHow Does ODINSUP Work? idxid="w737"book="_idx" docset="nw312" tidref="i4806"ODINSUP translates NDIS transmissions from Extended Services or LAN Services into a form that complies with the ODI drivers. ODINSUP also translates transmissions received from the network into a form readable by Extended Services and LAN Services. ODINSUP functions like a default protocol stack, meaning that it accepts requests from the Link Support Layer (LSL) that are not specifically marked for another registered protocol (such as IPX or TCP/IP). When it receives requests, ODINSUP passes them on to the NDIS protocol stack. ODINSUP allows IBM's Protocol Manager (found in Extended Services and LAN Services) to communicate with a network board without having to be aware of the details of transmission on that board (such as frame type). Instead, the details are handled at the ODI driver level and then transmissions are passed on to the Link Support Layer, which in turn passes them on to the correct protocol stack or to ODINSUP. ODINSUP translates the request to a form understood by Protocol Manager.IDREF="FM39812""Sharing a Network Board With IBM Software" on page 81 explains more about using ODINSUP.ODINSUP is for using ODI drivers. LANSUP is for using NDIS drivers. LBL="C-18"ID="FM86551"NetWare Requester and IBM software using ODINSUP idxid="w738"book="_idx" docset="nw312" tidref="i4806"to share a network boardFILE="c312q40a.pbm"LBL="C-19"ID="FM15783"NetWare Requester and IBM software using ID="FM96569"LANSUP idxid="w739"book="_idx" docset="nw312" tidref="i3154"to share a network boardFILE="c312q61a.pbm"