[comp.protocols.tcp-ip.ibmpc] Help with BYU Novell shell and packet driver

charles@umbc4.umbc.edu (Charles) (05/17/91)

This is a request for help with the BYU Novell shell using BYU's IPX and
Clarkson packet driver vers. 9, and NCSA Telnet 2.2d. With the packet driver we
did not have to econfig the server, but instead use the -n switch when
running the packet driver.
 
I am testing this on a PC 286 with a 3c503 ethernet card. It works ok, I
can sign in to our Novell server, then go back to c: drive and telnet to
a host, or vice-versa. The problem is something is messing up the novell
search drive mapping, which occurs when I log in to novell. What should 
happen is that the log-in script appends a statement adding the novell
server's drive path to the local PC's path, and then when logging out,
the path is reset, and leaves only the PC's path. 

What actually happens is that if I telnet first, then shell to dos using the
ALT-E command, then log onto novell, the PC path is not appended with the 
novell drives; typing 'path' at the c: prompt shows only the PC's path.
When I try to get to a drive on the novell though, drive x or z for example,
I can still change drives on the server, they just don't show up.

Conversely, if I connect to novell first, the novell drive map is appended to
the PC path. Then, I can telnet to a host, again shell out to dos, and log
out of novell. At this point, the novell drives are not taken off the pc's
path, as they should be. When I try to go to one of the novell drives the
pc reports 'invalid drive', even though the path statement clearly shows them.
So, something seems to be interfering with novell. 
If anyone has seen this problem, any suggestions would be appreciated.

eric@daccess (Eric Ashley) (05/29/91)

What you are experiencing here is a nasty little problem that DOS has.  A
secondary command proccess (shelling out to DOS) gets its own UNIQUE environ-
ment.  When you login or logout from your Novell server in a DOS shell, the
environment of that secondary shell gets the path correctly updated.  But
once that process terminates, you again have the environment (including the 
path) that you had before starting your program in the primary command process.

DOS does not define an easy way of determining where the parents environment is
located, so a secondary command process won't alter it.  In short, only alter 
your environment in the primary command process (command line) if that change
will be needed after you exit any app you may be running.