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