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

At 10 MAR 1999 03:21:18PM Kevin Kastelic wrote:

We have Advanced Revelation 3.10 running on Novell Netware 4.10 and we are running the Revelation NLM 1.5.

All workstations are DOS 6.0 and all are running LHIPXTSR

We where restoring our AREV application from a tape backup to a different directory on the Novell server so that we could do some non production testing of an application. Durring the Restore, it appears that the Novell server unloaded the revelation NLM and caused all our users be disconnected from the Production AREV application

Has anyone ever experienced anything like this?


At 10 MAR 1999 03:27PM Scott Kearney wrote:

Kevin,

That's definitely not something the NLM should be doing. Did you perform a backup immediately prior to the restore? That could have been the culprit, if whoever set up your backup scripts (or whatever method you use) intentionally unloads the NLMs in order to avoid file-sharing violations.

Another possibility is that your restoration might have included files that were located in the \SYSTEM directory, and, in overwriting the extant NLM's, unloaded the NLM's from memory–although (admittiedly) I'm not sure if that is how Netware behaves.

Is this the first time you've performed a restore? I'd be curious to know if this unloading problem has happened on your machines before.

-Scott Revelation


At 10 MAR 1999 04:17PM Kevin Kastelic wrote:

We did not perform a backup immediatly prior to the restore, we were restoring from the previous days backup.

as for Restoring itself, the only files we were restoring where the arev files in our \arev and application Directories (\arev\tutor, \arev\sharp etc), but we where restoring them to \oldrev\arev\.

the only thing I can think of, is that our backup software (seagate Backup Exec) causes high utilization of the Netware server durring restores, and perhaps it caused the server to run out of memory

This is the first problem we have had since installing the NLM, that is why i posted my question…

Kevin


At 10 MAR 1999 04:24PM Kevin Kastelic wrote:

This is the first time that we have performed a restore of AREV since installing the NLM.

Kevin


At 10 MAR 1999 06:09PM Victor Engel wrote:

According the the NLM documentation, if there are inadequate resources available to the NLM it will unload itself to prevent damage to the database. You might want to analyze your NLM setup (check amount of memory required using the parameters you are using) and compare that to total server memory minus what is being used by the restore software.


At 11 MAR 1999 11:09AM Scott Kearney wrote:

Kevin,

If the Seagate restore program really does use that much of the server's resources, and you had quite a bit of use from users, then it sounds like Victor may be right about the system load bringing it down.

You might want to see what happens if you have everyone log out (so the NLM is relatively idle, except for some background indexing) and then do the restore again and see if the NLM unloads. I'm not sure if you have this sort of experimentation luxury, but it would be a good thing to test, just so you knew for sure what caused it to happen.

More importantly, make sure that you have REVPARAM files setup in each of your data (linear hash) directories. That way, if the server drops due to a system load issue, none of the copies of arev will try to write to the data by themselves (sure, they'll crash, but they would probably have crashed anyway, and with the REVPARAM in place, your data will be more secure).

-Scott Revelation


At 11 MAR 1999 03:06PM James Wasserlebendig wrote:

Tthe problem is you cannot load the same EXE twice as it is in violation of your license agreement. The NLM is smart enough to know this so it unloaded itself to prohibit you from commiting a felony.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/bc98e1d57243ebce85256730006fd07f.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1