[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== GFE's with NLM v1.5 on Token Ring (Networking Products) ====
=== At 30 NOV 1999 12:24:42PM Ian Lord wrote: ===
{{tag>"Networking Products"}}
We have a client running Arev 3.12 on NT Workstations across a 16MB token ring network on a Novel 4.12 SFT3 server. They are using version 1.5 of the NLM. But are still getting large amounts of GFE's.
The server is dedicated to the Arev system only.
The arev is run through a batch file which loads and unloads the TSR and is also setup to use the correct amount of memory.
Transaction tracking is turned off on the server.
There have been 3 GFE's in the last two days. They have not occured on the same table.
Does anyone have any ideas as to why there are large numbers of GFE's occuring?
----
=== At 30 NOV 1999 12:52PM Tim Marler @ Prosolve Software wrote: ===
Hi Ian,
Firstly, the NLM will (or should) only prevent further GFE's. If you already had GFE's they won't have been fixed by installing the NLM. These GFE's will need to be fixed along with any others so it may be worth verifying all your tables.
Are they using the correct network driver, it should be the IPX-Netware driver. In Arev at TCL type WHO and check the driver being used.
Make sure you have a REVPARAM file (no extension) in all directories with Rev files in. The REVPARAM file should contain "ServerOnly=1" or "ServerOnly=True". This prevents any access to the Linear Hash files by apps not using the correct driver. To test you are using the correct driver and the REVPARAM file is doing its job, unload the NLM and then try and run your app, you shouldn't be able to get in.
Another thing to check is which network client you are using.
HTH
Tim
Tim Marler
Prosolve Software
Revelation Software (UK) Preferred Partner
http://www.prosolve.co.uk
----
=== At 30 NOV 1999 01:27PM Stephen S. Revelation wrote: ===
Ian,
Tim's correct about any pre-existing GFEs. These may in-turn spawn future GFEs after the NLMs are functioning properly.
I'd recommend doing as Tim had said then restoring the IPX Adv. Netware network driver with the REVPARAM setting to TRUE as Tim stated.
However, after squaring all of this away, be [i]sure[/i] that the NLMs can be seen from the network driver by going to the TCL (F5) and typing: EDIT SYSTABLES VOC. You should see a string of six consecutive 'F's in the fifth row indicating everything is functioning fine. If you can see this and have already fixed any prior GFEs, you should be OK from here.
-Stephen
----
=== At 01 DEC 1999 04:35AM Ian Lord wrote: ===
Many thanks for the quick response, guys.
1. Existing GFE's
We have verifyied all their tables and it does not show any latent GFE's, ie row in wrong group errors. I have had past experience where there has been a row in wrong group error, but the system would allow users to add new rows until it hit that particuler group.
2. They are using the correct Arev network driver IPX-Netware driver.
3. I did not set the revparam files up for any of their arev volumes as there is only ONE arev system. However there are several different datasets. If they try to access the Arev systems without the LHIPXTSR or any portion of the NLM not working, the system will not allow them access to Arev.
4. The client is are using the latest Novell client for NT 4.60.202 with the patches. When the NLM was installed, I tried to use version 4.51, but it did not allow us access to the arev. It also would not allow access to a local backup copy ot the arev system.
5. When the NLM was installed, I checked the systables entries and found that found that the fifth row does contain 6 'F's. The only thing I can say is that not all of the tables in the dataset had any data in the fifith row. I do not know if this would cause a problem or how to fix it if it does. Some of these tables where generated in very early versions of Arev.
It has been known for their network wich contains a mix of OS2, NT4 and Novell on token ring to have very heavy usage, which causes the network to slow down by considerable amounts. They are planning an AMT network in the near future, but need the problems sorted ASAP. Could the network speed cause the GFE's?
Also the last time a GFE was reported, the user had two arev session open, using different datasets (different directories) but with the same volume label. This has been corrected and one of the volume labels has been renamed to avoid this problem in the future.
Any further Ideas please......
----
=== At 01 DEC 1999 06:46AM amcauley@sprezzatura.com onmouseover=window.status=why not click here to send me email?;return(true)", [url=http://www.sprezzatura.com" onMouseOver=window.status=Why not click here to visit our web site?';return(true)]Sprezzatura Group[/url] wrote: ===
Could you verify that when you have 2 AREVs open you have two unique station ids?
amcauley@sprezzatura.com
[url=http://www.sprezzatura.com" ]Sprezzatura Ltd[/url]
[i]World Leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
----
=== At 01 DEC 1999 11:25AM Ian Lord wrote: ===
Andrew
I have verified that the station ID's are unique.
there is no problem here..
Ian
----
=== At 02 DEC 1999 11:16AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote: ===
I seem to recall a certain NLM program (who shall remain nameless, but we can call him PM) saying that on token rings you should enable the source routing cache.
akaplan@sprezzatura.com
[url=http://www.sprezzatura.com]Sprezzatura Group[/url]
[img]http://www.sprezzatura.com/zz.jpg[/img]
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=44C883BFB5B9877585256839005FA556|View this thread on the forum...]]