Clients logs in but %LOGIN_NAME reports 'someone else'

[Brian Schonecker]

I have a lot of old DOS based clients on an Arcnet network using the 16 bit
clients. I've been unable to get the 32 bit client to work with the Thomas
Conrad arcnet cards.

The user logs in fine but when the BINDERY login script executes, it says
that the %LOGIN_NAME variable is SOMEONE ELSE. Example:

<autoexec.bat snippits>

netx
ipxodi
lsl
tcpip blah blah (ignore the order of the above, I'm going by memory)

F:
F:\LOGIN > login enterprise/CNCMachine

(CNCMachine has no password BTW)
<system responds> Good morning, HP_PRINTER, you are user #343

MAP P:=ENTEPRISE/Users:HP_PRINTER
Invalid mapping..

c:
cd\WIN
WIN

(or something like that).

I've found that if I do a DSREPAIR then at the PC in question log out of
ENTERPRISE and log in to another BINDERY server "FS1" as a user with admin
privs and then back in as the original user, the problem goes away.

I've also noticed that if I comment out WIN in the autoexec.bat and RE-login
the CNCMachine user from _DOS_ itself, the system login script sees the user
as it should be (ie:CNCMachine - not some 'random' user)

This is isolated only to DOS clients on a BINDERY connection.

[Barry St.John [SysOp]]

In article <90gnbb$9u...@nexus.provo.novell.com>, Brian Schonecker wrote:

> I've been unable to get the 32 bit client to work with the Thomas
> Conrad arcnet cards.

Novell did not develop a 32-bit TSM for ARCNet. For DOS/Win3x clients,
you are better off staying with VLM v1.21.

> The user logs in fine but when the BINDERY login script executes, it
> says that the %LOGIN_NAME variable is SOMEONE ELSE.

This could be a result of connection numbers going higher than 255. 256
shows as connection 0, 257 as connection 1, etc.

Client32 is going to use two connection slots on the server, though only
one takes a license. VLM doesn't do this. This might help you keep your
total connections below 255.

-Barry. [Novell Support Connection SysOp]

[Brian Schonecker]

I appreciate the response.

So how can I resolve this problem? Currently I have to go out to resolve
this issue again. Could it be that the previous server had only 125
licenses and the current server has 250?

B

"Barry St.John [SysOp]" <Chicago...@compuserve.com> wrote in message
news:VA.00000d9...@gf5q0.firstfedbankkc.com...

[Barry St.John [SysOp]]

In article <90on6f$2p...@nexus.provo.novell.com>, Brian Schonecker wrote:

> Could it be that the previous server had only 125
> licenses and the current server has 250?

It's not necessarily the number of licenses, but the number of server
connections. Not all connections use licenses. When you look at a
connection in monitor you'll see it is listed as authenticated or normal.
Only the normal ones use a license. BUT some software use an integer
(0-255) for the connection number. If the actual connection number is too
large then you can see symptoms like what you describe. I seem to recall
that VLM falls into this category. Certainly versions released prior to
NetWare 4.0 will.

You don't state what version of NetWare you are running, but I recommend
you put the latest support pack on it.

As for no 32-bit TSM existing, you *can* still use the 16-bit ARCNet
driver with Client32 (I've done it and it does work), and Client32 will
recognize the higher connection numbers.

Also, what version of Client32 is this you are trying to run? I recommend
you use v2.20 or higher.