                       Readme file for the 
                 NetWare Requester for OS/2 v2.0
                         included in the 
              NetWare Workstation Kit for OS/2 v2.0
                          October 1992


This Readme file explains known software problems and
issues, as well as corrections to the documentation. 
This Readme replaces the Readme sent with the general release
of the NetWare Workstation Kit for OS/2 v2.0. This readme 
applies to the general release software, not NSD#2.

General
-------
#1  This release does not support the remote-boot (RIPL) feature.  
Remote-boot support will be included in an NSD at a later date. 

#2  If you want to establish file server connections and map drives 
before executing the OS/2 startup folder or the STARTUP.CMD file, 
add the following line to your CONFIG.SYS file:

CALL=C:\NETWARE\LOGIN.EXE SERVER\USER
	   
If you installed the Requester files in a location other than the 
default, replace "C:\NETWARE" with the location of the Requester 
files.  This capability is useful for automatically starting 
programs from network drives.  

#3  The NetWare Requester manual incorrectly states that 
DBNMPIPE.EXE is found on the NetWare Requester for OS/2 v2.0 
diskette.  DBNMPIPE.EXE is part of the SQL Server software from 
Microsoft.


Virtual DOS and Windows Sessions
--------------------------------
NOTE: Use the virtual session information in this readme file rather than
the information in chapter 8 of the NetWare Requester for OS/2 v2.0 
manual. The information in this readme is more recent.  

#4  Network support in virtual sessions can be private, global, or 
IPX/SPX-only. When you install the NetWare Requester with support 
for virtual sessions, the default support is for IPX/SPX-only.
IPX/SPX-only becomes private support when you run NETX.COM in a session. 

Note:  By default, the NetWare Resources Property will be set to
Private.  However, until you run NETX.EXE, the support is
actually IPX/SPX-only. 

IPX/SPX-ONLY.  All DOS and Windows sessions set up for IPX/SPX-only 
support do not have a NetWare connection, but they do provide 
support for DOS IPX and SPX applications and access to OS/2-redirected
NetWare resources such as drives and printers. IPX/SPX-only support 
uses the DOSVIPX.SYS (for VM Boot sessions) and VIPX.SYS 
programs included on the NetWare Requester diskette. 

PRIVATE.  All DOS and Windows sessions set up for private login 
support have their own connection to the NetWare network. Private 
login support uses the DOSVIPX.SYS, VIPX.SYS, and NETX.EXE programs 
included on the NetWare Requester for OS/2 diskette. 

GLOBAL.  All DOS, and Windows sessions set up for global login 
support share a single connection to a NetWare network with OS/2 
sessions. Global login support uses the DOSVIPX.SYS, VIPX.SYS, 
VSHELL.SYS, and DOSVSHLL.SYS programs included on the NetWare 
Requester diskette.

#5  Many of your non-NetWare-aware programs will function in an IPX/
SPX-only environment, and since this environment requires the least 
setup, you should try your programs in this environment first. If 
the programs do not run properly in an IPX/SPX-only environment, 
run them in a private or global environment. The private login 
environment provides support for all NetWare features and utilities. 
The global environment does not currently support the FILER utility and
programs that use temporary drive connections. Support for these 
features will be provided at a later time.  

#6  For all virtual sessions you start, the COMSPEC variable must 
point to the correct version of DOS.  If you are running the version 
of DOS included with OS/2, the COMSPEC variable should be set as 
follows:

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

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.  Be sure 
to check the COMSPEC variable definition AFTER logging in. 

#7  If you are running a Windows program that uses the IPX or SPX 
protocol but does not access a NetWare server, you must load the 
TBMI.COM program BEFORE running the program. Load TBMI 
automatically before each session by including the following line 
in your AUTOEXEC.BAT file:

drive:\path\TBMI.COM

Replace "drive:\path" with the location of the TBMI.COM file. By 
default, TBMI.COM is copied to the \NETWARE directory with the 
other Requester files. For more information about TBMI, see the 
NetWare documentation for Windows workstations. 

#8  When you log out from an OS/2 session, the drive for your login 
directory is drive L:.  When you log out from a virtual DOS session, 
the drive for your login directory is the last physical drive plus 
one. For example, if your last physical drive is C:, the drive for 
your login directory will be D:. This means that the drive you see 
after logging out depends on whether you log out from a DOS or an 
OS/2 session. 


Private Virtual Sessions
------------------------
#9 To set up private login support, do the following steps. 

A) Make sure network support for virtual sessions was installed 
when you installed the Requester. If it wasn't installed, use the 
Requester installation procedure to edit the CONFIG.SYS and install 
virtual session support. 

B) Open the DOS Settings Notebook for a DOS or Windows icon on your 
desktop.  Modify the Settings notebook for each DOS and Windows 
icon you want to have private support. 

C) Select the DOS_LASTDRIVE property and type a drive letter other 
than Z. The letter should name the last drive you want to appear 
as local in this session. In this session, NetWare can use all 
drives occurring after the letter you specify.

D) Select the DOS_FILES property and type 214.

E) Select the DOS_VERSION property and replace NETX.COM with NETX.EXE.

F) To enable the NetWare CAPTURE command, select the DOS_DEVICE 
property and type the following line:

drive:\OS2\MDOS\LPTDD.SYS

Replace "drive" with the drive letter of your boot drive. 

G) Exit the DOS Settings Notebook.

H) Load the NETX.EXE program in each session. To load NETX.EXE 
automatically in ALL DOS and Windows sessions, put the following 
command in an AUTOEXEC.BAT file in the root of your boot drive:

drive:\path\NETX.EXE

Replace "drive:\path" with the location of NETX.EXE. By default, 
NETX.EXE is installed in \NETWARE with the other Requester files. 

To load NETX.EXE automatically for every session you start from a 
particular icon, use the Optional Parameters feature on the 
Settings Notebook for that icon. In the Optional Parameters text 
entry box, type /K followed by a space, the directory path, and the 
NETX.EXE filename.  The file will then be executed at the start of 
every session opened from that icon. For example, to load NETX.EXE 
from the default location, type the following:

/K C:\NETWARE\NETX.EXE

For more information about Optional Parameters, see your OS/2 
documentation. 

#10 To access the network from a private session booted with a 
version of DOS other than the one included in OS/2, type the 
following lines in the CONFIG.SYS file on the DOS diskette or 
partition you will boot from:

DEVICE=drive:\OS2\MDOS\FSFILTER.SYS
DEVICE=drive:\path\DOSVIPX.SYS
FILES=214

Replace "drive:\path" with the drive and directory where the 
NetWare Requester files are located.   


Global Virtual Sessions
-----------------------
#11  To set up global login support, do the following steps.  

A) Make sure network support for virtual sessions was installed 
when you installed the Requester. If it wasn't installed, use the 
Requester installation procedure to edit the CONFIG.SYS and install 
virtual session support. 

B) Open the DOS Settings Notebook for a DOS or Windows icon on your 
desktop. Modify the Settings notebook for each DOS and Windows icon 
you want to have global support.

C) Select the NETWARE_RESOURCES property and choose the GLOBAL 
button. 

D) Exit the DOS Settings Notebook.

#12  To access the network from a global session booted with a 
version of DOS other than the one included in OS/2, type the 
following lines in the CONFIG.SYS file on the DOS diskette or 
partition you will boot from:

DEVICE=drive:\OS2\MDOS\FSFILTER.SYS
DEVICE=drive:\path\DOSVSHLL.SYS
DEVICE=drive:\path\DOSVIPX.SYS

Replace "drive:\path" with the drive and directory where the 
NetWare Requester files are located.  

#13  The global login support provided with VSHELL does not support 
programs, such as NETWARE.DRV, that use temporary drive 
connections.  Therefore, run Windows programs that are NetWare-
aware--and other programs that encounter problems--in a private 
rather than a global environment. 

#14  Drive mappings in DOS differ slightly from drive mappings in 
OS/2.  In OS/2, all mapped drives function like root drives, so 
drives mapped in OS/2 sessions will show up as root drives in global 
DOS sessions.  Root drives mapped in global DOS sessions will show 
up as normal drives in OS/2 sessions. 

Search drive mappings are not used in OS/2.  Therefore, search 
drives mapped in global DOS sessions are ignored in OS/2 sessions.  
Also, search drives mapped in one DOS session do not apply to other 
DOS sessions.  To eliminate confusion, avoid using search drives 
completely in a global environment.  Instead, obtain the same 
functionality by setting up your environment as follows: 

A)  If you want to use both global and private login support from 
the same machine, create two "DOS Full Screen" icons on your 
desktop.  Name one icon for global and one for private. 

B)  Follow the instructions in the NetWare Requester manual to set 
up the DOS Settings for both the global and private icons. 

C)  Decide which drives you want mapped in your global environment.  
Decide which of those drives need to be included in a search path. 

D)  Edit your OS/2 login script and include map statements for all 
NetWare drives. 

E)  Edit your DOS login script and include map root statements for 
all NetWare drives.  Use MAP ROOT rather than MAP for consistency 
between DOS and OS/2.  For easiest maintenance, both login scripts 
should contain identical map statements. 

F)  Create an OS/2 .CMD file which includes a path statement and 
the drive letters you want included in the path.  The path is where 
OS/2 searches for .EXE, .CMD, and .COM files.  For example, to 
include drive P: in the search path, type the following line in 
your .CMD file: 

SET PATH=%PATH%;p:\;

Note:  The "%PATH%;" appends whatever you type to the directories 
that already exist in the PATH statement.  

If needed, you can also include a drive letter in the data path 
(DPATH).  The DPATH is where OS/2 searches for non-executable,  
non-.DLL types of files.  To include drive P: in the DATH, you would 
type the following line in your .CMD file:

SET DPATH=%DPATH%;p:\;

G) Create a DOS .BAT file which includes the same PATH statements 
you included in the OS/2 .CMD file.  You cannot include DPATH 
statements in the DOS .BAT file.  DOS PATH statements are limited 
to 123 characters, so try to map drives to the exact directories 
you need and minimize the number of subdirectories you specify.

H)  Run the .CMD file each time you open an OS/2 session. Run the 
.BAT file each time you open a DOS global session. One way to do 
this is to use the Optional Parameters feature on the Settings 
Notebook.  In the Optional Parameters text entry box, type /K 
followed by a space and the name of the .CMD or .BAT file.  The 
file will then be executed at the start of every session opened 
from that icon.  

For more information about PATH, DPATH, Settings, or Optional 
Parameters, see your OS/2 documentation. 

#15  DOS applications using VSHELL may not be able to open files 
on a NetWare v3.11 server if you do not have file scan rights in 
the directory where the files are located.  If your application 
cannot open a file, check your file scan rights.  This does not 
apply to applications using NETX.

#16  The VSHELL program is compatible with 3.x DOS programs. It is 
not compatible with earlier versions of DOS programs that use 
NetWare FCB function calls.  


Named Pipes and SPX
-------------------
#17  The maximum number of Named Pipes servers supported on a single 
network is 100. 

#18  When you have booted a virtual session with a version of DOS
other than the one included in OS/2, you must run the Named Pipes
Extender for DOS/Windows (DOSNP.EXE) to use the Named Pipes 
protocol in that session.  In this situation, you can have only one 
Named Pipes redirector per OS/2 machine--either one DOS/Windows
or one OS/2.

You do NOT need to run the Named Pipes Extender in virtual sessions
booted from the DOS version included with OS/2.  Also, you can have more
than one redirector in these sessions.

#19  The "abort timeout," "listen timeout," "send timeout," and 
"verify timeout" settings for the Protocol Stack SPX option have 
an upper limit of 65,535 milliseconds.


NetBIOS
---------
#20   Some defaults for the NetWare NetBIOS option in the NET.CFG 
file are incorrectly documented in the NetWare Requester manual.  
The correct defaults are:

COMMANDS    Default=128 commands
NAMES            Default=32 names
SESSIONS       Default =64 sessions, maximum allowed=64 sessions

#21  Chapter 7 of the NetWare Requester manual shows two incorrect 
examples of modifying the PROTOCOL.INI file.  In both cases, you 
do not need to type "LM10," although "LM10" is shown in the example.  
The lines added to PROTOCOL.INI should read:

[NETBIOS]
 DriverName = NETBIOS$
 ADAPTER0 = IPXNB$,0,16,16,8

#22  To run NetBIOS applications from a virtual session when 
Extended Services/LAN Services are NOT loaded, do not install 
Novell's NETBIOS.SYS as instructed in the NetWare Requester manual. 
Just run the NETBIOS.EXE program in the virtual session.  You can only
have one NetBIOS connection per OS/2 machine.  It can be either one
DOS/Windows connection or one OS/2 connection. 

#23  NetBIOS requests from a virtual Windows session do not go 
through Novell's Windows NETAPI.DLL as documented in the NetWare 
Requester manual.  The requests go directly to NETBIOS.EXE. 


Using ODINSUP (Interoperability)
--------------------------------
#24  Each time you install IBM communications and networking 
software, install or reinstall the NetWare Requester afterward.  
The order that components load in the CONFIG.SYS file is important 
when running ODINSUP, NetBIOS, or LANSUP. The NetWare Requester 
installation program automatically orders the statements 
correctly. 

#25  The CONFIG.SYS interoperability example in the NetWare 
Requester manual is incorrect.  When running the NetWare Requester 
with Extended Services or LAN Services, IBM's NETWKSTA.200 file 
should load after the NWIFS.IFS in the CONFIG.SYS file.  Following 
is a new CONFIG.SYS example. This is an excerpt rather than a complete
CONFIG.SYS file. 

LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\NETWARE;
SET PATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; 
C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;L:\OS2;P:\OS2;
SET DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; 
C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;        

DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM 
DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM 
DEVICE=C:\IBMCOM\PROTOCOL\LANDD.OS2 
DEVICE=C:IBMCOM\PROTOCOL\NETBEUI.OS2
rem DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 
RUN=C:\IBMCOM\PROTOCOL\LANDLL.EXE 
RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE 
RUN=C:\IBMCOM\LANMSGEX.EXE 
DEVICE=C:\IBMLAN\NETPROG\RDHELP.200

rem --- NetWare Requester statements BEGIN --- 
DEVICE=C:\NETWARE\LSL.SYS 
RUN=C:\NETWARE\DDAEMON.EXE 
DEVICE=C:\NETWARE\TOKEN.SYS 
DEVICE=C:\NETWARE\ROUTE.SYS 
DEVICE=C:\NETWARE\ODINSUP.SYS
DEVICE=C:\NETWARE\IPX.SYS 
DEVICE=C:\NETWARE\SPX.SYS 
RUN=C:\NETWARE\SPDAEMON.EXE 
rem DEVICE=C:\NETWARE\NMPIPE.SYS 
rem DEVICE=C:\NETWARE\NPSERVER.SYS 
rem RUN=C:\NETWARE\NPDAEMON.EXE NP_COMPUTERNAME 
DEVICE=C:\NETWARE\NWREQ.SYS 
IFS=C:\NETWARE\NWIFS.IFS 
RUN=C:\NETWARE\NWDAEMON.EXE 
rem DEVICE=C:\NETWARE\NETBIOS.SYS 
rem RUN=C:\NETWARE\NBDAEMON.EXE 
DEVICE=C:\NETWARE\VIPX.SYS 
rem --- NetWare Requester statements END ---

IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN 
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 


NOTE:  If you are using the ODINSUP driver, you must comment out the
corresponding NDIS MAC drivers as directed in the NetWare Requester
for OS/2 manual. 

#26  If you are using Token-Ring network boards that support frame 
sizes up to 4 KB, type the following lines in your NET.CFG file:

Link Support
   buffers 14 4202

The manual incorrectly says to use "15" instead of "14".

#27  If you are using ODINSUP, you do not need to make sure that 
the Communications Manager transmit buffers are 6 bytes larger than 
your NetWare Requester Link Support buffers. The NetWare Requester 
manual is incorrect. 

#28  The directions in chapter 6 of the manual for increasing the 
packet size are incorrect for network boards that support frame 
sizes up to 2 KB.  Follow these instructions.  If the network boards 
you're using support only frame sizes up to 2 KB, the default size 
(buffers 20 1514) is adequate for Ethernet boards.  If Token-Ring 
boards require 2 KB, the size must be increased to:

Link Support
   buffers n 2154

Replace "n" with a number less than or equal to 28, so that the 
maximum memory size of 64 KB is not exceeded. 


Using LANSUP (Interoperability)
-------------------------------
#29  Novell's LAN Support (LANSUP) device driver replaces the 
CMGRLAN and TOKENEE modules used in the NetWare Requester v1.3. 
CMGRLAN and TOKENEE are not supported in the NetWare Requester 
v2.0. LANSUP meets the needs of IBM LAN users who would like to 
access NetWare but do not have an ODI-compliant network board 
driver for the board in the workstation. 

LANSUP supports PC Network II in addition to Ethernet and Token-
Ring compatible drivers. ODINSUP and LANSUP provide essentially the 
same functionality, but each targets a different communications 
interoperability environment (LANSUP for primary IBM LAN users or 
ODINSUP for primary NetWare users). 

To use LANSUP, do the following:

A)  Install all IBM communication and database products that will 
be used. 

B)  Install the NetWare Requester for OS/2 v2.0

C)  Modify the CONFIG.SYS file by doing the following:

- Make sure that LANSUP.SYS is loaded after PROTMAN.OS2 and 
  LSL.SYS. If the CONFIG.SYS contains a statement to load an 
  ODI driver, replace the ODI driver name with LANSUP.SYS. If 
  the CONFIG.SYS does not contain an ODI driver, add the 
  statement to load LANSUP.SYS. 

- Make sure that the NetWare NWIFS.IFS loads before the OS/2  
  NETWKSTA.200 file.

Following is an excerpt from a CONFIG.SYS file for using LANSUP:

LIBPATH=.;C:\OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\NETWARE;
SET PATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; 
C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;L:\OS2;P:\OS2;
SET DPATH=C:\OS2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL; 
C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\NETWARE;        

DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM 
DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM 
DEVICE=C:\IBMCOM\PROTOCOL\LANDD.OS2 
DEVICE=C:IBMCOM\PROTOCOL\NETBEUI.OS2
DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 
RUN=C:\IBMCOM\PROTOCOL\LANDLL.EXE 
RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE 
RUN=C:\IBMCOM\LANMSGEX.EXE 
DEVICE=C:\IBMLAN\NETPROG\RDHELP.200

rem --- NetWare Requester statements BEGIN --- 
DEVICE=C:\NETWARE\LSL.SYS 
RUN=C:\NETWARE\DDAEMON.EXE 
rem Replace TOKEN.SYS with LANSUP.SYS
DEVICE=C:\NETWARE\LANSUP.SYS 
DEVICE=C:\NETWARE\ROUTE.SYS 
DEVICE=C:\NETWARE\IPX.SYS 
DEVICE=C:\NETWARE\SPX.SYS 
RUN=C:\NETWARE\SPDAEMON.EXE 
rem DEVICE=C:\NETWARE\NMPIPE.SYS 
rem DEVICE=C:\NETWARE\NPSERVER.SYS 
rem RUN=C:\NETWARE\NPDAEMON.EXE NP_COMPUTERNAME 
DEVICE=C:\NETWARE\NWREQ.SYS 
IFS=C:\NETWARE\NWIFS.IFS 
RUN=C:\NETWARE\NWDAEMON.EXE 
rem DEVICE=C:\NETWARE\NETBIOS.SYS 
rem RUN=C:\NETWARE\NBDAEMON.EXE 
DEVICE=C:\NETWARE\VIPX.SYS 
rem --- NetWare Requester statements END ---

IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN 
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 

D)  Modify the NET.CFG file by doing the following:

- Use the Link Driver option to enable the frame types supported
  by Token-Ring, Ethernet, or PC Network II. You must enable at 
  least one frame type. Supported frame types are:  

  token-ring, token-ring_snap for Token-Ring 
  ethernet_802.2 and ethernet_snap for Ethernet 
  ibm_pcn2_802.2 and ibm_pcn2_snap for PC Network II

  For example, to enable both allowable frame types for Token-Ring, 
  type the following:

  Link Driver LANSUP
     frame token-ring
     frame token-ring_snap

 - Use the Link Driver statement to specify the node address 
   used by the network board. The node address is normally 
   printed on the board. For example, to enable one PC Network II 
   frame type and set the node address, type the following:

   Link Driver LANSUP
      node address 080000A564CBL
      frame ibm_pcn2_802.2

   The node address must be a 6-byte hexadecimal number (12 
   characters) followed by the letter L or M (standing for LSB 
   or MSB).  Note: If you do not know the node address, you can type 
   a "dummy" address and reboot the machine. At machine start-up, 
   the correct address will be displayed. 

- Use the Link Support statement to increase the size of the packet 
  to be transmitted. For Ethernet network boards that only support  
  frame sizes up to 2 KB, the default size (buffers 20 1514) is 
  adequate. If Token-Ring boards require 2 KB, the size must be 
  increased to 

  Link Support
     buffers n 2154

  Replace "n" with a number less than or equal to 28, so that the 
  maximum memory size of 64 KB is not exceeded.  For Token-Ring 
  boards that support frame sizes up to 4 KB, type the following 
  statement:

  Link Support
     buffers 14 4202

- (Optional) Change the default for whether addresses are 
  transmitted in canonical (least significant bit first) or 
  non-canonical (most significant bit first) form. By default, 
  Token-Ring and PC Network II frames are in non-canonical (or 
  MSB) format and Ethernet frames are canonical (LSB). 

  To change the default, add an LSB or MSB keyword after the 
  frame statement. For example, to enable both Token-Ring frame 
  types, and override the non-canonical form for one of the 
  frame types, add the following statement:

  Link Driver LANSUP
     frame token-ring
     frame token-ring_snap lsb

  Note: MSB and LSB can only be used if the network board 
  driver supports Octet Bit Reversal (OBR).
