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


This Readme file explains known software problems and
issues, as well as corrections to the documentation.


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.COM, 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.COM 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 255.

E) 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.

F) Exit the DOS Settings Notebook.

G) Load the NETX.COM program in each session. To load NETX.COM
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.COM

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

To load NETX.COM 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.COM filename. The file will then be executed at the start of
every session opened from that icon. For example, to load NETX.COM
from the default location, type the following:

/K C:\NETWARE\NETX.COM

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=255

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
RUN=C:\NETWARE\NWSPOOL.EXE
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 4210

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 4210

- (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).