I have two NetWare 5.1 (SP4) servers (IBM 232x), two SMC TigerStack Switches
(SMC6624M), one 3com switch and running on 100mbps network. One NetWare is
the primary server and the other is standby server (NetWare Standby Server)
linked with VIPX on dedicated 100mbps LAN card (Integrated NIC).
Primary server is connected to TigerStack (1) on 1000mbps (SMC GigabitNIC on
IPX and IP) and Standby to TigerStack(2) on 1000mbps. Stack-Up module to
connect two TigerStacks and direct cable to 3Com switch with MDI. All user's
connection ports in both TigerStacks have been configured to 100mbps
half-duplex but not on the 3Com switch.
The problem; if I were to copy a large files (380MB) to a different folder,
one by one all workstation will display 'Please wait while <Program>
retries' message. The program they are using is a DOS customised software.
It is quite annoying as sometimes it can continue but most of the time hung
the workstation completely. Worst of all after restarting of workstations,
connections are not release from NetWare server thus causing CPU utilisation
to shoot up to 40%. At this point workstation will consistently receive
'auto-reconnect' message if workstation was left idle for awhile hence need
to restart the workstation again, a pain indeed.
The only way to lower down the CPU utilisation level in NetWare server is to
down it but what you know! It cannot be downed because of open connections.
The only way is to trigger NetWare debug console and 'Quit' but damage has
been done because mirroring to Standby server is dirty. So when we restart
the primary server, re-mirroring will be activated and hell it is so slow
that we have to shutdown the standby server and re-mirror later on.
Not sure which group this message should belong to because it might be the
VLM (1.21) or Client32 (IPX and IP dated 10 Dec 98) or it might be the
NetWare server. Hope someone can help out by providing some advice, thanks.
First, it's unlikely that VLM v1.21 is the source of your problem.
Second, Client32 v2.71 is also an unlikely source of the problem EXCEPT
that it looks like you might be running it for both IPX and IP. I
would recommend you configure the client only for one or the other, and
not both, if at all possible. I cannot tell from the info you provided
what version of Client32 you have there, but to be sure get v2.71 here:
Compare it to what you're using and update if needed.
If you need to run this for IP only, try this one instead. It's
already configured for IP:
Aside from that, I would look at the server/network side of things.
And from the sounds of it, since you have many/all workstations
affected when this happens, I'm inclined to go that way to begin with.
-Barry. [Novell Support Forum SysOp]
Okay thanks I will do a search.
I can configure to turn off "Opportunistic Locking" in Net.cfg of a
workstation right? How about the rest like 'Cache Writes","Delay Writes",
"File Cache Level" and "Max Cache Size"? How do these related or there are
Do these commands work in VLM and Client32?
Netware DOS Requester
File Cache Level=0
Max Cache Size=0
<Nw...@veder.com> wrote :
> Could this be OP-LOCK related?
> Search for OP-LOCK TIDs 'n patches at Novell.
I had changed all workstation to VLM v1.21 but previously I was on Client32
v2.71. Should I remove IP binding from the Netware server, you think it
>"Barry St.John" wrote :
I already made a proposal to change the 3Com to TigerStack II and hopefully
they will change it. With this I can configure the TigerStack II to have a
consistent Lan speed and see how it goes there. There should not be any
difference between configuring the Lan speed on the switch and Net.Cfg in
the workstation, right? It is easier to set the speed on the switch than on
each individual workstation because of many varieties of NIC.
Which speed would you suggest, Full Duplex or Half Duplex? I configured it
to be Half Duplex now.
"Dave Lunn" wrote :
> I am with Barry that the client is most unlikely to be your problem.
> I think maybe you have a file locking/releasing problem caused by the
> transfers being so slow. The transfers being slow is likely caused by the
> lan having speed/duplex mismatches and hammering the bejeepers out of you.
> Try working through it NIC by NIC and each switch getting all to run set
> If you speed up the transfers then the users won't be shutting down their
> with locks established or pending.
The lan speed setting in the net.cfg is not going to affect the NIC on a VLM
client that's been forced.
If you are running *all* fast ethernet NICs, then set them all to Auto. If
it's a mixture, set the switch(s) to Auto and all the fast NICs to auto and
the 10baseT NICs to 10/half.
I have no use for a Full Duplex setting in this day and age. Anymore it is
a source of trouble and to be avoided at all costs.
> Do these commands work in VLM and Client32?
> Netware DOS Requester
> Cache Writes=OFF
> Opportunistic Locking=OFF
> Delay Writes=OFF
> File Cache Level=0
> Max Cache Size=0
No, those are only for Client32. VLM will ignore them.
FWIW, when you specify 'File Cache Level = 0' you effectively disable
the cache. Therefore you do not need 'Max Cache Size = 0'.
Furthermore, should you enable the cache you should set Max Cache Size
= 2048. If you leave it at zero C32 could allocate up to half your
available memory for client-side caching. That's way too much. I
haven't found much, if any, benefit to allocating more than 2MB.