Recently we attempted to configure LANtastic to run with Dataease on a six station network.


SysOp's note:  The following information is based soley on the
knowledge and experiences of Tom Filliman.  I'd like to thank him for
passing along this info, it is thorough and definitive.

Recently we attempted to configure LANtastic to run with Dataease on
a six station network. After carefully following all the
instructions, Dataease would still hang after a few operations with a
continual "Resource Busy" message. A call to Artisoft yields "Double
the /F and /L parameters in SHARE.EXE".  That suggestion helps but
does not fully alleviate the situation. A call to Dataease technical
support yields "Set /L:1000 /F:32000".  Okay, that solves the problem
but knocks the file server into dedicated mode [running out of
memory], still not an acceptable solution...

Enter Foxpro/LAN.  Again, similar network hangs result, but Fox
provides some critical information:  We're running out of LOCKS! Time
to investigate the SHARE program.

                       SHARE.EXE Explained

Disclaimer: The information contained here represents a
combination of reference materials, experimentation, an interview
with a programmer at Microsoft, and others. As can be seen from
the dialogue above, not too many people understand what SHARE
really does. I take no responsibility for the consequences
resulting from the use of this information, and can not guarantee
its accuracy.

PURPOSE:
SHARE is an extension to DOS which provides information to
programs (such as LANtastic) about the current status of a file
or a section of a file. It makes decisions about the ability of
an application program to acquire information from a file or
write information to a file. It helps multiple users "share"
files.

REQUIRED INFORMATION:
During SHARE's execution, it requires memory space to store two
data tables. The amount of space for these tables and
consequently their resulting capacity is controlled at invocation
by two parameters /F and /L. If one or both parameters are
missing then defaults are used [explained below]. The defaults
are fine for most applications, but can easily be violated by a
large number of users or applications that behave in certain
ways. Unfortunately, when SHARE runs out of space to do its job,
applications seldom report the correct error message. Therefore,
a good understanding of what these parameters mean can solve a
lot of network related problems.

SHARE INTERNAL OPERATION:
When a network file is opened for use in a program. SHARE in
conjunction with DOS performs a number of checks on the request.
First, if not already in use by another user, SHARE enters the
complete pathname for the file in its internal table and assigns
that entry an internal handle number. It then enters in a second
table the handle and a number which represents the file area
being used and how it is being used by this particular
application. This construction is called a LOCK! If the file
being used had already been opened by another user, it already
has an entry in the table and a unique handle. In this situation,
SHARE scans the lock table for LOCKS which match this file, then
makes a determination on whether or not to grant the file request
based on possible LOCK collisions. This mechanism generates the
infamous "Sharing violation error . . ."

THE /F PARAMETER:
The first data table that SHARE maintains is a two dimensional
array that stores the COMPLETE PATHNAME for each open file on the
server and an associated handle number. SHARE needs enough memory
to store the full pathname of each open file plus eleven bytes
for the handle and overhead. The parameter represents the amount
of space IN BYTES to reserve for this table. You can find a worst
case scenario by writing the pathname (before drive redirection)
of the longest filename in the deepest subdirectory, adding
eleven bytes and multiplying by the number of FILES in your
CONFIG.SYS. For example, my longest pathname is:
"C:\utility\diags\clocks\uscal.dat" and my FILES= in CONFIG.SYS
is 40. The pathname contains 33 characters + 11 = 44. 44 * 40 =
1760. So at worst case, the /F should read /F:1760. By default /F
starts at 2048, which should be enough for FILES= of 65 or less.
In actual practice, DOS is usually not called upon to maintain
more than fifty files open at once. From this it becomes clear
that the /F parameter can be left alone and that Dataease's
suggestion that "/F:32000" be used is a colossal waste of RAM.
[As it turns out, the /F parameter being set correctly is the
difference between being able to run Dataease on the server or
not.]

THE /L PARAMETER:
Ahhh.. This is the more important part, pay attention! Each open
file also requires at least one lock but could have dozens. Each
time an application requests a portion of a file (such as a
record in a database) a lock on only that portion of the file
that contains the desired information is issued. The lock remains
in effect until the application program specifically removes it.
In Dbase and Foxbase [and others], there is a program imposed
restriction of only one lock used in each database file (two get
used really). However, in other programs like FoxPro/LAN and
Dataease, an unlimited number of locks can be issued on each
file. [Well, unlimited is limited to the number of small chunks
that a file can be broken up into.] So with these programs, one
could have ten open databases with say fifty record locks in
each. This means that SHARE would be maintaining 510 locks plus
maybe a dozen or so extra locks for other open support files. WOW
522 locks!! The /L parameter specifies the maximum number of
locks that can be used and defaults to a paltry sixty. Each lock
requires that seven bytes be reserved in memory. Locks are harder
to predetermine, but since they are cheap it pays to be generous
with them. In a typical LANtastic network, a /L setting of
"/L:500" is usually sufficient for one to ten users, but
"/L:1000" could be used for programs like Dataease that make
frequent use of multiple record locks.

Author:   Tom Filliman
          Fillimerica, Incorporated

Comments

Popular posts from this blog

BOTTOM LIVE script

Evidence supporting quantum information processing in animals

ARMIES OF CHAOS