I am resubmitting this problem as the original is buried back on the 3rd.

I have a client that is running an Arev 3.12 application on a WAN, Novell Network with the NLM installed. The WAN consists of 12 client sites with the data volumes pointing to a centralized server and the program volumes and windows (including REVBOOT) pointing to the 12 local servers. The majority of their stations are DOS but they are experimenting with some Windows 95 stations. All 95 suggestions (including 4096 memory configuration and background caching off) have been configured. Ever since they went to the WAN setup with the NLM they have been experiencing numerous Group 0, Code 5 (initial setup failed) GFE's. These GFE's are not phantoms and have only been occurring in blank tables or tables that have only 1-2 records (63 tables out of 291). Sometimes the error also occurs in Dictionary files. Since the tables are blank I have been clearing them and the error temporarily disappears. These GFE's do not seem to be problematic, but I would like to find out why they are occurring. Additionally, when they d

o occur they cause the "VERIFYLH volume" command to freeze. Any ideas would be appreciated.

Also, they have been complaining that when they save a large record, they lose the data volume connection and the record is lost. The NLM version is 1.10 and TSR version 1.12. The settings on the TSR are /c:120 and the server time out parameter is set to 20 minutes. The Communication stats show a Clients peak of 33. The Linear Hash stats show peak file variables at 141 with maximum set to the default of 2500. The Peak file handles are at 573 with the maximum set to the default of 5000. Peak lock is 25. There are 291 tables at the central server (808 if you include index and dictionary files). I realize that I might gain some performance if I reduce the Maximum File variables and file handles settings but would these settings be related to the "timing-out" that seems to be sporadically ocurring? Again any ideas are appreciated.

Answers to Aaron's questions:

Is the NLM on every server or just the central one?

The NLM is only on the central server. The client states this is the configuration that Rev Tech gave them a year ago when they were planning to covert to a WAN. The REVPARAM file has been added to the subdirectories on the central server.

What client is in use on the DOS and Win95 stations?

DOS - NETX IPXODI

Win95 -Microsoft Client for Netware Network.

What's the network topology, ethernet or token-ring? Arcnet?

Ethernet

- Thanks in advance, Sandra

You didn't mention which Novell version you are using. I didn't see

it anyway. Here are some things to think about:

If you are using Novell 3.x

1) You must have the zerobyte.nlm fix otherwise small files could

   have problems. This is a Novell NLM patch. Basically, it screws

   up the network FAT table because a files is 0 bytes, like many

   OV files tend to be for small rev files.

2) You must have fatfix.nlm and patchman.nlm installed on Novell.

   These are Novell NLMs as well. The Fatfix.nlm will cure problems

   with larger files. I have no idea what the patchman.nlm does.

If you are using Novel 4.x

1) You need the TurboDIS.NLM patch from Novell. This corrects 

   problems with large rev files during periods of heavy usage and 

   is required if you are using RevTech's NLM.

I would verify that the open fileds on the remote ends are being handled by the NLM. Just write a little program and look at the

file handle. If there 6 Fs (FFFFFF) in the file handle, the NLM is handling it. The revparam file should make sure of this, but I'd check it anyway.

For the DOS workstations, double check on the versions on your Network Programs like IPX.ODI and LSL.COM. Make sure they are the most up to date versions.

For the Win95 workstations, check the packet size in the network

properties for the protocal (it's late, i think that's right). Take it off Auto and set it to the correct value.

MAke sure the Revtech NLM is set to use the same Packet size that is on the Network.

Good Luck!

Brock Prusha

DFM Systems, Inc

[email protected]

Thanks for the input. I will have the client check for these patches.

- Sandra

View this thread on the forum...