Contents of the NET33X.TXT file
NOVELL TECHNICAL INFORMATION DOCUMENT
TITLE: This file contains NETX, EMSNETX, and XMSNETX
DOCUMENT ID: TID014005
DOCUMENT REVISION: A
ALERT STATUS: Yellow
INFORMATION TYPE: Symptom Solution
README FOR: NET33X.EXE
NOVELL PRODUCT and VERSION:
NetWare Client for DOS/Windows
This version of the NetWare shells address the following issues: Support for
DOS versions 6.x, rather than just 6.0. Fixes INT 21-5C, INT 21-3F file
locking problem. Supports "Sharing Buffer Overflow" error. Fixes NCOPY /C
file date/time anomaly. Fixes INT 21 4B01h function that causes a w/s hang.
This shell now properly displays the correct print job number. Stack size was
increased to accommodate the "PRINT TAIL" parameter in the NET.CFG.
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL
MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE
INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL
MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION.
1) Provides support for DOS 6.x, rather than just 6.0 and below. Added
support for versions 6.x of DOS. (See the note at the bottom of this
2) Adds support for the NCP return code 150. Now when the shell
receives a 150 return code from Int 21 function 50h, it will put a
24h in the AX register, indicating a "sharing buffer overflow"
3) BACKUP from DOS 5.0 fails when specifying a NetWare drive as the
target drive. Int 21 function 60 was failing (file not found) when
parsing root directory names, such as "f:\".
4) Unable to set PRINT TAIL value in NET.CFG to 0. This has been fixed
in this release.
5) The destination file's date changes with the NCOPY /C option. A bug
in the cache code could cause NCOPY /C to update the destination
file with the current date and time. Specifically, using NCOPY /C
to copy a 30911 byte file would cause the bug. Some other sizes
would not fail.
6) Interrupt 21h function 40h errors were not being passed on to the
application. The shell was clearing the carry flag on write errors,
causing an application to believe that no write error had occurred.
7) Interrupt 21h function 4B01h (load but do not execute) was causing
the workstation to hang.
8) The stack size was increased in order to accommodate the "PRINT
TAIL" parameter in NET.CFG
9) Interrupt 21h function 4409h, which determines whether the specified
device is local or remote, was returning incorrect values when run
on a network drive.
10) The shell was returning an incorrect print job number.
11) If a section of a file is locked with int 21h - 5Ch, and then
another workstation accesses the same file and tries to read the
locked area with int 21h - 3Fh, it will return successful.
Self-Extracting File Name: NET33X.EXE Revision: A
Files Included Size Date Time Version
NET33X.TXT (This File)
NETX.EXE 78654 11-17-93 2:14p v3.32
EMSNETX.EXE 90510 11-17-93 2:16p v3.32
XMSNETX.EXE 87172 11-17-93 2:18p v3.32
1) Make a backup copy of the existing shell (NETX.EXE, XMSNETX.EXE or
2) Copy this new version over the existing shell.
3) Reboot the workstation.
IMPORTANT Note for PC DOS 6.10 users: (Problem using the %OS_VERSION
The default login script, as well as many system login script files
contain the following commands:
MAP INS S1:=SYS:PUBLIC
MAP INS S2:=SYS:PUBLIC/%MACHINE/%OS/%OS_VERSION
The %MACHINE variable applies to the LONG MACHINE TYPE= parameter
in the NET.CFG file. It defaults to IBM_PC
The %OS variable applies to the DOS NAME= parameter in the NET.CFG
file. It defaults to MSDOS. PCDOS users typically will create a
directory called PCDOS, and set DOS NAME=PCDOS in the workstation NET.CFG
file. This allows the co-existence of MSDOS and PCDOS with the same
version number to be mapped under the %OS directory. i.e.
The %OS_VERSION variable applies to the DOS VERSION returned from DOS INT
21h-Function 30h, which is the "GET DOS VERSION" function. We check the
AL register for the major version number, and the AH register for the
minor version number. Using INT 21h, Function 30h for PCDOS v6.00, will
return 6.00 as the version. This matches the DOS VER command from PCDOS
v6.00, which also returns version 6.00. However, using INT 21h, Function
30h for PCDOS v6.10, will also return 6.00 as the version. This does not
match the VER command from PCDOS v6.10, which shows the version as 6.10.
This is similar to what happens with DOS 4.01. The DOS VER command
(which returns an ASCII text string) reports the DOS version as version
4.01, but internally (using the Get Dos Version function call), DOS 4.01
reports itself as DOS version 4.00 to applications.
This means that PCDOS v6.10 users will be mapped to the:
SYS:PUBLIC\IBM_PC\PCDOS\V6.00 directory by default, since INT
21h-Function 30h returns 6.00 as the version, and the NETX.EXE shell
relies on this function to return the correct DOS version. This will
result in invalid command.com errors, if comspec is set to the network
"DOS directory" search mapping.
WORK AROUND OPTIONS
1) Add the following line to the workstation's config.sys file:
At the DOS prompt, type: SETVER NETX.EXE 6.10 (to add netx.exe to
the setver table.)
At the DOS prompt, type: SETVER (to list the elements in the
setver table, to make sure NETX.EXE was correctly added to the
NOTE: NETX.EXE can be removed from the setver table using the
following syntax: SETVER NETX.EXE /D Only do this if setver
is no longer needed to report the correct DOS version to the
Reboot the workstation, and load the network software.
OR, (instead of option 1)
2) Upgrade all workstations from PCDOS v6.00 to PCDOS v6.10, and place
the PCDOS v6.10 files into the: SYS:PUBLIC\IBM_PC\PCDOS\V6.00
directory. This will allow the default mapping of
SYS:PUBLIC\IBM_PC\PCDOS\V6.00 to work for v6.10 PCDOS users.