From: viking@iastate.edu (Dan Sorenson)
Subject: Strange FoxPro behavior on Novell 2.15c LAN
Summary: I've implemented parallel processing without trying.
Keywords: Foxpro, Novell, recent lockups
Organization: Iowa State University, Ames IA
Date: Sat, 10 Oct 1992 04:16:01 GMT

	Note the crossposting!  This seems relevant to both
groups, and I'm stumped on which is the culprit.

	I'm running FoxPro/LAN 2.0 on a Novell 2.15c LAN.  We have
some Apex 286's on a thin-wire Ethernet, each using SMC ethernet
boards.  Each machine runs DOS 5.0 up high, netx down low, and
smartdrv.exe with whatever it can get a hold of. (sadly, no EMS
memory on these, and I haven't gotten QEMM yet)  I run DOS high
to free up memory, but NETX low due to reports of it being a
bit unreliable if loaded high.

	Alright, here's where it gets wierd.  All queries and data
entry are handled with various .prg files, one acting as a program
launcher to call others as necessary.  For example, MENU.PRG is
a simple menu that issues the command "do stats" to run the
program STATS.PRG, which does some statistical analysis.  The
menu program then closes all, releases all, and goes back into
its near-infinite loop.  I did this to avoid having to re-start
foxpro when done iwth one routine.

	Today I had to modify an if-else-then conditional, so I
completed my modification, had the other user exit to MENU,
compiled it, and had her launch it again.  On my machine, the new
conditional takes effect.  On hers, it does not.  This is while
using the same data set!  How is this possible?  MENU.prg was not
modified, and the program I modified is called by MENU.  I do not
use the menu program on my workstation, but can this make any
sort of difference?

	I've also noticed that I am less often seeing a "Cannot create
program.fxp" error on the screen.  This usually happens when I modify
a procedure and attempt to re-compile while somebody else is running the
program.  Most often, I'll re-compile from my workstation but have
occassionally just left it as the new program code should be compiled
again by whatever workstation attempts to run it first.  This last
has not been happening on a few occassions, leading to two different
versions of the program being run at the same time.

	So what can I look for?  This doesn't sound like a FoxPro bug,
as it's just recently started happening.  My workstations can't
hold much of these programs in memory, and smartdrv.exe doesn't cache
the file server-resident programs anyway.  Could it be something to do
with the Novell cache not being updated quickly enough or time-stamping
the files with the correct time so Fox can know the source has changed?
The only hardware changes made recently were the addition of the MENU.prg
program launcher application, upgrading all machines to DOS 5.0, adding
the disk cache from Smartdrv.exe, and adding another meg of RAM to the
286 boxes that all this is happening on.

	Frankly, I'm stumped, and I can't reliably re-create this
problem either.  Strangely enough, we've also noticed that on some
rare occassions a program will be launched but the workstation will
lock up shortly after launching the next .fxp; we can't re-create
this either.  All things point to FoxPro being the culprit, but it
has just started happening and I've not patched anything since it was
first installed.

	Oh, Novell support claims it's either Fox or a small gremlin
in my workstations, fox claims it can't happen, and the workstation
manufacturer claims that any of the above might cause it.  <grrrrr>

<Dan Sorenson, DoD #1066 |"I see angels on Ariels in leather and>
<z1dan@exnet.iastate.edu | chrome, Swooping down from heaven to >
<viking@iastate.edu      | carry me home."   ---    R. Thompson >
<ISU thinks I need more education, which they provide for a fee.>



Newsgroups: comp.databases