ObjectStore Management

Chapter 5 Using Locator Files to Set Up Server-Remote Databases

This chapter provides information for using a locator file to set up access to databases that do not reside on the same host as a Server.

The topics discussed include

What Is a Server-Remote Database?

When an ObjectStore application accesses a file database, the ObjectStore Server handling that access is required to be running on the file server host containing the database; that is, the database must be Server-local. However, you can override this default for file databases, and allow access to Server-remote databases, that is, access to databases that are not stored on an ObjectStore Server host.

Description of the Locator File

The locator file contains one or more host declarations and one or more locator rules. It can also include comments.

Each host declaration specifies a host name or a group of host names and the host machine type.

Each locator rule specifies

The name of the host (file server) where the database resides
The pathname of a database or group of databases
Which ObjectStore Server controls access to the specified database
How to translate the database name from its form on the file server to the form needed by the ObjectStore Server

Format

Each locator file has the following format:

host-declaration-1 
host-declaration-2 
... 
host-declaration-n 
locator-rule-1 
END
locator-rule-2 
END
... 
locator-rule-n 
END

Example

This example file contains two host declarations, one locator rule, and one comment.

HOST redwood unix
HOST oak pc
FILE_HOST oak
FILE_PATHNAME c:\oak1\test1\.+
SERVER_HOST redwood
REPLACE c:\oak1\test1 \suite1
REPLACE_DELIMITERS
END
#end of locator file

Host declarations

The host declarations are the first two lines. They inform ObjectStore about the operating systems running on the hosts referred to in the locator rules that follow. This allows ObjectStore to execute the REPLACE_DELIMITERS command, explained below.

Locator rule

The locator rule in this file indicates that the ObjectStore Server on the host named redwood controls access to any file database that meets both of these conditions:

The database resides on the file server host named oak.
The pathname by which it is known to that file server is c:\oak1\test1\ followed by one or more characters (any characters).

The locator rule specifies that the pathname by which this file database is known to the ObjectStore Server (redwood) can be obtained by

Replacing c:\oak1\test1 with \suite1 in the pathname by which the database is known to the file server.
Replacing the standard delimiter used by oak's operating system (\) with the standard delimiter used by redwood's operating system (/).

The END statement indicates the end of a locator rule.

Applying the rule

If an application contains the call

os_database::open("/suite1/test1.db");

and the host of the application has oak's directory c:\oak1\test1 mounted as /suite1, ObjectStore translates /suite1/test1.db into a pathname that is canonical for the file server host oak, that is, c:\oak1\test1\test1.db. This translation is the pathname by which the database is known to the file server, and it is used as input to the locator file.

The rule above applies in this case, because the file server host has the specified name (oak) and the input pathname c:\oak1\test1\test1.db matches the pattern in the rule: c:\oak1\test1\.+.

The rule specifies that the ObjectStore Server on redwood should handle access to the database. The rule also specifies that this database is known to redwood as /suite1/test1.db, the result of substituting \suite1 for c:\oak1\test1 in c:\oak1\test1\test1.db and then substituting "/" for "\".

A database to which the locator rule does not apply is handled just as if there were no locator file; it is handled by the ObjectStore Server running on the file server host containing the database.

Comments

Comments begin with # and go to the end of the line.

Case sensitivity

Case is not significant for keywords in locator files.

Declaring Hosts

A locator file begins with one or more host declarations. Each host declaration has the form

HOST host-name-pattern { unix | pc | unc }

where host-name-pattern is a character string pattern that specifies a set of host names. The rules about how character string patterns are written and used are discussed in Using Character String Patterns in Locator Files. For example, to specify that all hosts are UNIX systems, you would include this statement:

HOST .* UNIX

ObjectStore uses the earliest HOST declaration whose host-name-pattern matches a given host name. The declaration ObjectStore uses for a given host name determines the host's associated standard delimiter as used by the REPLACE_DELIMITERS translation command. See Specifying Translation Commands.

The following table shows how a host declaration determines an associated standard delimiter:

Operating System Delimiter
unix

/

pc

\

unc

\

Operating System	Delimiter
unix	/
pc	\
unc	\

Specifying Locator Rules

After the host declarations, a locator file contains a sequence of one or more locator rules. Each rule has the following form:

Syntax for
locator rules

FILE_HOST file-server-host-name-pattern 
FILE_PATHNAME pathname-pattern 
SERVER_HOST ObjectStore-Server-host-name 
[translation-command-1 
 translation-command-2 
... 
 translation-command-n] 
[access-specification]

When does a rule apply to a database?

ObjectStore applies a locator rule to a database when these conditions are both true:

The database resides on a file server host whose name has the form specified in the FILE_HOST statement.
The name by which the database is known to the file server has the form specified in the FILE_PATHNAME statement.

The first locator rule in a file that applies to a database determines

The ObjectStore Server to handle access to that database
The pathname by which that database is known to that ObjectStore Server

If ObjectStore does not find a rule that applies to a database, then the Server running on the host containing the database handles access to the databases. This always occurs when there is no locator file.

Specifying FILE_HOST Statements

A FILE_HOST statement specifies the host name of a system where a Server-remote database is stored. The statement has the form

FILE_HOST file-server-host-name-pattern

where file-server-host-name-pattern is a character string pattern for the name of a file server. See Using Character String Patterns in Locator Files.

If a database specified in an application resides on a file server host whose name has this form, then the rule containing this statement might apply to the database (see FILE_PATHNAME statement that follows). If the database's file server host has a name that does not match file-server-host-name-pattern, the rule does not apply to the database.

There is one special file-server-host-name-pattern:

@LOCALHOST

This value indicates the host of the ObjectStore application.

Specifying FILE_PATHNAME Statements

A FILE_PATHNAME statement specifies a pathname by which a database is known to its host. This statement has the form

FILE_PATHNAME pathname-pattern

where pathname-pattern is a character string pattern. See Using Character String Patterns in Locator Files.

If the name by which a database is known to the file server matches pathname-pattern, then the rule containing this statement applies to the database, provided the database's file server host has a name that matches the rule's file-server-host-name-pattern. If the database's name does not match the pathname-pattern, the rule does not apply to the database.

Specifying SERVER_HOST Statements

The SERVER_HOST statement specifies the name of a host running an ObjectStore Server. This statement has the form

SERVER_HOST ObjectStore-Server-host-name

where ObjectStore-Server-host-name is the name of a host running an ObjectStore Server. You can enclose this name in quotation marks (" "). If a locator rule applies to a database, this statement specifies the name of the ObjectStore Server that handles access to the database.

There are two special ObjectStore-Server-host-names:

@LOCALHOST specifies the ObjectStore Server running on the host of the application.
@INVALID_SERVER indicates that ObjectStore should signal an error if the locator rule including it applies to a database.

Specifying Translation Commands

Each locator rule can contain an optional sequence of one or more translation commands. If a rule applies to a database, this sequence specifies how to translate from the name by which a database is known to the file server containing it to the name by which the database is known to the ObjectStore Server specified by the rule.

A translation command has one of the following forms:

REPLACE pattern substitution-string
REPLACE_DELIMITERS
ALL_UPPERCASE
ALL_LOWERCASE

Execution order

All REPLACE commands are executed before any other commands in the sequence of translation commands. The first REPLACE command in the sequence applies to the input pathname. This is the pathname by which a database is known to the file server on which it resides. Each subsequent REPLACE command applies to the output of the previous REPLACE command.

The output of the last REPLACE command is then used as input to the REPLACE_DELIMITERS command (if there is one). The output of that is then used as the input to the ALL_UPPERCASE or ALL_LOWERCASE command (if there is one). Supplying both an ALL_UPPERCASE and an ALL_LOWERCASE command results in an error.

REPLACE syntax

The REPLACE command has the form

REPLACE pattern substitution-string

It indicates that the first substring of the input pathname (FILE_PATHNAME pattern) that matches pattern should be replaced by substitution-string.

The substitution-string can be empty, and is optionally enclosed in quotation marks ("x"). If you want the quotation marks to be interpreted literally, use two consecutive quotation marks (""x"").

The special variable $f (where $ is the escape character) designates the string that matches the database host name in the current rule.

Parentheses ( ( and ) ) in pattern do not affect which pattern is matched, but make it possible for a replacement string to include the input substring that matches the parenthesized part of the character string pattern. The variable $1 in a substitution-string refers to the substring that matches the first parenthesized expression in pattern, $2 refers to the substring that matches the second parenthesized expression, and so on.

You need not specify an escape character for parentheses in character string patterns.

Any string designated by a variable such as $1 appears as all lowercase in the output.

Example

For example, if the string that matches file-server-host-name-pattern in the current rule is inuk and the input string is

/kayak/usr1/foo/bar/file.db

then the translation command

REPLACE /foo/(bar)/file$.db  /newdirectory/$1/$f/file.db

generates

/kayak/usr1/newdirectory/bar/inuk/file.db

The first two elements of the input string are used unchanged. The replacement begins with the third element, /foo, and proceeds as follows:


Original Expression	Replacement Expression	Explanation
/(bar)	$1	The $1 variable matches the first parenthesized expression, in this case bar.
Not applicable	$f	The variable $f says to substitute the database host name, in this case, inuk.
file$.db	file.db	Substitutes file.db for file$.db. The $ in the original expression is required as an escape character for the file extension delimiter ".".

REPLACE_DELIMITERS

The REPLACE_DELIMITERS command indicates that each occurrence in the input of the standard delimiter associated with the file server host should be replaced with the standard delimiter associated with the ObjectStore Server host. See Declaring Hosts.

ALL_UPPERCASE

The ALL_UPPERCASE command indicates that the output should be the same as the input except that lowercase characters in the input should appear in uppercase in the output.

ALL_LOWERCASE

The ALL_LOWERCASE command indicates that the output should be the same as the input except that uppercase characters in the input should appear in lowercase in the output.

Specifying Read or Write Access

Each locator rule can contain an optional access specification. This specification is one of

READ_ONLY
READ_WRITE

ObjectStore signals an error if the access specification does not match the access specified in the call to os_database::open() or create().

Using Character String Patterns in Locator Files

In some parts of locator files, you can specify a character string pattern. This allows you to write rules that can apply to more than one specific input. For example, if all machines using ObjectStore use a PC syntax for file pathnames, then a single HOST declaration that covers them all would be

HOST declaration example

HOST .+ pc

The alternative to using a character string pattern is to write a HOST declaration for each PC, for example:

HOST foo pc
HOST bar pc
HOST amnesiac pc
HOST snoball pc

Specifying the character string pattern .+ is better than listing each host because you do not need to modify the locator file when you add a new PC host to the network.

Directory specification example

Here is another example. Suppose there is a directory named c:\home\place\stuff that contains many files and directories, including

c:\home\place\stuff\more\file.db
c:\home\place\stuff\less\deeper\nota.db

You want to describe all files and directories that are in the directory c:\home\place\stuff and below. You can specify this with the character string pattern

c:\home\place\stuff\.+

Maximum length

The maximum length of a character string pattern is 512 characters.

There are three rules to know when writing character string patterns. An understanding of the following terms is needed to correctly apply the rules.

Definitions of terms

The target is character string input. For example, the pathname an application specifies for a database is the target.

The pattern is a character string pattern in a locator file.

Pattern matching is the process that compares a target with a pattern.

If the target matches the pattern, the result is true. If the target does not match the pattern, the result is false.

Rules for Writing Character String Patterns

Here are the three rules for writing character string patterns.

Pattern and target
can be the same

You can specify the pattern as the exact characters that are expected in the target.

This is the simplest kind of pattern. For example, if the only UNIX host is a machine named dog, the simplest HOST declaration that contains a pattern that matches the target is

HOST dog unix

When pattern matching seems to be causing problems, it often helps to simplify all patterns according to this rule.

Use metacharacters

You can specify metacharacters in a pattern. This allows a single pattern to match more than one target.

The table in the next section describes the metacharacters you can specify in a pattern. Metacharacters you can specify were chosen to avoid confusion with characters that commonly occur in targets.

A frequently used metacharacter is the period (.), which matches any single character. Another is the plus sign (+), which matches one or more repetitions of what it immediately follows. For example:

.+

This matches any target that is at least one character long.

Mix exact strings with metacharacters

You can build complicated patterns from simple patterns by following one with another. For example:

dog.+

This matches any target that is at least four characters long and whose first three characters are dog.

Using Metacharacters in Patterns

The following table describes the metacharacters you can specify in a pattern.


Metacharacter	Description
.	A period represents any single character. A period matches a single character in the target.
*	An asterisk represents zero or more repetitions of the group to the immediate left. A group is one of the following: Single character Period metacharacter Something enclosed in parentheses Something enclosed in brackets ([ ]) For example: a* matches "", a, aa, aaaaaaa, and so on. .* matches anything, including nothing. (abc)* matches "", abc, abcabc, and so on. [05-9]* matches "", 0, 567, 98, and 99999960, but not 1234, and so on.
+	A plus sign represents one or more repetitions of the group to the immediate left. A group is one of the following: Single character Period metacharacter Something enclosed in parentheses Something enclosed in brackets ([ ]) For example: a+ matches a, aa, aaaaaaa, and so on. .+ matches anything, except nothing. (abc)+ matches abc, abcabc, and so on. [05-9]+ matches 98, 90, 99999960005, and so on.
[ and ]	Brackets enclose a character class. A character class is a special kind of pattern. If any character in the character class matches a single character in the target, the result is true. For example, the character class [abcd] matches the target a, but not e. Inside the brackets, the metacharacters' meanings do not apply, with two exceptions.
	When a caret (^) is the first character after the left bracket, the sense of the match is reversed. In other words, the result is false when a target matches any character in the character class. For example, [^a] matches any single character except a. A caret has no special meaning when it appears in a character class but is not the first character. For example, [a^] matches either a or ^ and nothing else. When a hyphen (-) is not the first or last character in a character class, the result is true for everything that is in the range of the two values on either side of the hyphen. For example, the character class [0-9] matches any single digit. If a hyphen is the first or last character, it has no special meaning. The exact set of characters defined when you specify a hyphen depends on the collating sequence of the machine, so some caution is advised. It is safe to assume that [0-9] means the ten digits on any ASCII system.
( and )	An open parenthesis starts a grouping. A close parenthesis ends a grouping. Parentheses group multiple characters so that the software can treat them as a unit. This is useful if sequences might repeat in the target, as shown in the examples above for asterisk and plus. Parentheses are also especially useful to delineate a grouping when you are doing string replacements. See the discussion of the REPLACE command in REPLACE syntax.
$	A dollar sign is an escape character. The purpose of the escape character is to provide a work around when the target might contain something that is a metacharacter if it appears in a pattern. For example, if the target is +, the pattern + would not match it because the plus sign is a metacharacter and has a special meaning in patterns. You need to escape the plus sign in this way, $+, when you want it to match a target with the value +.
	You must escape the following characters when they are not used as metacharacters: *. + [ ] ( ) $ ^ . The backslash (\) character has no meaning as a metacharacter; you do not need to use an escape character with it. The escape character is different from the other metacharacters because you can change it. However, it is not a good idea to do so. By default, the escape character is the dollar sign. You can use the OS_LOCATOR_ESCAPE_CHAR** environment variable to change the escape character to something other than the dollar sign. See OS_LOCATOR_ESCAPE_CHARACTER.
" "	Quotation marks optionally start and end a pattern. For example, "(abc)" is the same as (abc). You can use quotation marks for clarity. To embed quotation marks in a pattern or target, specify two consecutive quotation marks. For example, "a""a" is the three-character pattern made up of lowercase a, quotation marks, and lowercase a.
^	When you specify a caret outside a character class, precede it with the escape character. For example, "$^". Outside a character class, the use of the caret is reserved unless you precede it with an escape character.

Overriding the Default Locator File

The locator file for all ObjectStore clients is


UNIX	$OS_ROOTDIR/etc/locator
Windows and OS/2	%OS_ROOTDIR%\etc\locator

To specify a different locator file for a particular client or application, you can either call an ObjectStore function from the application or set a client environment variable.

Calling an ObjectStore Function

The objectstore::set_locator_file() function specifies a locator file. Its declaration is

static void set_locator_file(const char *file_name)

The file_name argument points to the name of the locator file to be used the next time a database is opened. If you specify 0 for file_name, the application uses the client environment variable OS_LOCATOR_FILE to determine the locator file. A nonzero argument overrides any setting of OS_LOCATOR_FILE. If the specified file does not exist, ObjectStore signals the err_locator_misc exception. If the first character of the string pointed to by file_name is a white-space character or #, ObjectStore assumes the string is the contents of a file rather than a file name.

The objectstore::ignore_locator_file() function ensures that no locator file is associated with the application, regardless of the setting of OS_LOCATOR_FILE or calls to set_locator_file().

Setting a Client Environment Variable

You can set the client environment variable OS_LOCATOR_FILE to any legitimate argument for objectstore::set_locator_file(), with the same meaning. Calls to set_locator_file() override this environment variable.

Or, you can set OS_IGNORE_LOCATOR_FILE to ensure that no locator file is associated with the application. This overrides all other settings and function calls, including $OS_ROOTDIR/etc/locator.

When Multiple Servers Can Concurrently Access a Database

When an ObjectStore Server handles access to a Server-remote database, the Server holds a lock on the database as long as the database is open. If the database is open for read-only, the Server holds a read lock; if the database is open for read/write, the Server holds a write lock.

Read lock

When an ObjectStore Server holds a read lock on a database,

The Server allows read access by other Servers.
The Server prevents write access by other Servers.

Write lock

When an ObjectStore Server holds a write lock on a database,

The Server prevents other Servers from acquiring either a read lock or a write lock on the database.
The Server allows read access by other applications for which it is providing services.

When ObjectStore blocks a Server from acquiring a lock, it signals the err_database_lock_conflict exception. ObjectStore does not automatically try again to obtain the lock.

Turn off locking

You can turn off database-level locking by setting the Server parameter Allow NFS Locks to No. You must use extreme caution if you turn off locking. Concurrent database access by different Servers can corrupt the database. A mistake in a locator file can cause unintentional concurrent access of this sort.

Caution

The recommended mode of operation is

Database-level locking is on (the default).
Each database that is ever opened for read/write has exactly one ObjectStore Server assigned to it. This Server handles access to the database by all applications at your site. Follow this recommendation to ensure that two different clients do not contact different Servers for access to the same database.

Sample Locator Files

The following locator file allows access to databases on a UNIX server from a Windows ObjectStore Server. The ObjectStore Server is on the local host.

UNIX file host

To access Server-remote databases on a UNIX host from a Windows ObjectStore Server, you can modify the locator file as shown.

HOST @LOCALHOST pc
HOST andover unix
FILE_HOST andover
FILE_PATHNAME /h/andover/1/.+
SERVER_HOST @localhost
REPLACE /h/andover/1 u:
REPLACE_DELIMITERS
FILE_PATHNAME .*
SERVER_HOST @LOCALHOST
END

Remember that case is not significant for locator file keywords, so @localhost is acceptable. The REPLACE statement is important because ObjectStore must translate the Windows pathnames to UNIX pathnames. The REPLACE_DELIMITERS statement is also necessary for correct pathname translation.

Wildcards in host declarations

Suppose you want to set up access to databases on a large number of Server-remote hosts. This example shows an easy way to do it.

HOST andover unix
HOST .* pc
FILE_HOST andover
FILE_PATHNAME /h/andover/1/.+
SERVER_HOST @localhost
REPLACE /h/andover/1 u:
REPLACE_DELIMITERS
END
FILE_HOST .*
FILE_PATHNAME .*
SERVER_HOST @LOCALHOST
END

Use a wildcard to specify the largest group of hosts that are the same type. This works because ObjectStore searches locator rules sequentially and uses the first rule that applies. It is not an error for multiple rules to apply.

NFS-mounted $OS_ROOTDIR with same architectures

Here is an example of a locator file for an NFS-mounted $OS_ROOTDIR. The machine called registry has $OS_ROOTDIR mounted from towanda. The machine called towanda has its own $OS_ROOTDIR and is running an ObjectStore Server. Both machines have the same UNIX architecture. registry:/home/registry/linda is NFS-mounted onto towanda as /registry_linda.

In towanda's $OS_ROOTDIR/etc directory, the towanda_server_parameters file must be modified to have the line

Allow Remote Database Access: Yes

The locator file is in towanda's $OS_ROOTDIR/etc directory. With this locator file, you can build ObjectStore applications on registry.

HOST towanda unix
HOST registry unix
FILE_HOST registry
FILE_PATHNAME /home/registry/linda/.+
SERVER_HOST towanda
REPLACE /home/registry/linda /registry_linda
END

A locator file for an application that uses three machines

In this scenario, there are three Windows machines. One machine, bessie, is the ObjectStore Server host. Another machine, clover, is the File Server (NT) and is not running an ObjectStore Server. The remaining machine, jeep, is the ObjectStore client.

Here is the locator file that is placed in the %OS_ROOTDIR%\ETC directory of the ObjectStore client.

HOST bessie pc
HOST clover pc
FILE_HOST jeep
FILE_PATHNAME \\clover\share\\my-dir.+
SERVER_HOST bessie
REPLACE \\clover\share\my-dir t:\my-dir
END

The ObjectStore Server host bessie has the file server partition mounted as drive t:. This is necessary. You cannot expect the ObjectStore Server host to use UNC to access the file server. The file server must be mounted using the File Manager/Explorer or the net use command.

With this locator file, the ObjectStore client could access the database \\clover\share\my-dir\metaschm.db in either of the following ways:

\\clover\share\my-dir\metaschm.db
bessie:t:\share\metaschm.db

If the ObjectStore client has \\clover\share mounted to itself as drive G:, it could also use the following access patterns:

g:\my-dir\metaschm.db
metaschm.db

The last pattern works, assuming that the working directory is g:\my-dir.

Mounting $OS_ROOTDIR and mixing UNIX architectures

The following example is a locator file for different UNIX architectures where one of the machines mounts $OS_ROOTDIR from another machine. The machine named screamer is an HP with its own $OS_ROOTDIR, but without a local Server. The machine towanda is a Sun with its own $OS_ROOTDIR and a Server.

screamer:/home/screamer/box/linda is NFS-mounted onto towanda as /screamer_linda.

Again, in towanda's $OS_ROOTDIR/etc directory, the towanda_server_parameters file must be modified to have the line

Allow Remote Database Access: Yes

The locator file is in screamer's $OS_ROOTDIR/etc directory. With this locator file, you can build ObjectStore applications on screamer.

#Good locator file:
HOST towanda unix
HOST screamer unix
FILE_HOST screamer
FILE_PATHNAME /home/screamer/box/linda/.+
SERVER_HOST towanda
REPLACE /home/screamer/box/linda /screamer_linda
END

Accessing databases
on another Server host

The next locator file shows how an application that is local to an ObjectStore Server can access databases on other Server hosts. The application starts on Server host venus and then creates (opens) databases on disks that are local to the Server hosts mars and pluto.

HOST venus unix
HOST mars unix
HOST pluto unix
FILE_HOST mars
FILE_PATHNAME /local/directory/on/mars/.+
SERVER_HOST venus
REPLACE /local/directory/on/mars /mounted/directory/on/venus
END
FILE_HOST pluto
FILE_PATHNAME /local/directory/on/pluto/.+
SERVER_HOST venus
REPLACE /local/directory/on/pluto /mounted/directory/on/venus
END

Always using same ObjectStore Server

The following locator file always forces the use of the same ObjectStore Server regardless of where the database is. In this example, the hosts are all UNIX systems and tokyo is the host of the Server that you want all databases to use.

HOST .+ unix
FILE_HOST .+
FILE_PATHNAME .+
SERVER_HOST tokyo
END

Incorrect REPLACE line in locator file

Here is an example of an incorrect locator file that tries to accomplish the same setup:

#Bad locator file: do NOT put machine: in the REPLACE line
HOST towanda unix
HOST screamer unix
FILE_HOST screamer
FILE_PATHNAME /home/screamer/box/linda/.+
SERVER_HOST towanda
REPLACE screamer:/home/screamer/box/linda /screamer_linda
END
#end of locator file

This locator file would display a message like this:

schema2.cc line 20: error: the compilation schema database could not be 
opened because:   The directory was not found
re /home/screamer/box/linda/tutorial_IIA.comp_schema while 
creating file database
/home/screamer/box/linda/tutorial_IIA.comp_schema (host "towanda")

Missing matching pattern in locator file

Here is another example of an incorrect locator file:

#Bad locator file: Need the "/.+" after the file pathname for matching
HOST towanda unix
HOST screamer unix
FILE_HOST screamer
FILE_PATHNAME /home/screamer/box/linda
SERVER_HOST towanda
REPLACE /home/screamer/box/linda /screamer_linda
END

This locator file would display a message like this:

"schema2.cc", line 20: error: the compilation schema database could not 
be opened because:
The server refused the connection
Attempted to connect to server on local host, looking up database
"/home/screamer/box/linda/tutorial_IIA.comp_schema" on host
"screamer" failed: <err-0003-0004>Host refused connection.
(err_net_connection_refused). Possibly there is no server running
on this host. You can try the command
"/home/screamer/box/ostore/hp310/bin/ossvrping screamer" to check. 
(err_server_refused_connection)

Limitations When Using NFS to Access Remote Databases

The ObjectStore Server needs to act on behalf of its client processes and so it accesses files over the network, thereby relying on NFS. Where NFS fails, the ObjectStore Server also fails. The following table below describes NFS problems that can occur when you use locator files. These limitations are because of known NFS problems and do not necessarily apply when using other remote file access protocols.


Symptom	Reason	Workaround
Server crash. The oss_out file contains references to stale file handles. This most often occurs in conjunction with using the automounter.	The ObjectStore Server needs to access the file handle. When the file handle goes stale, the Server loses its ability to communicate with the database, and thus crashes. When the ObjectStore Server accesses the database, it does not exercise the automounter. Therefore, when you use the automounter there is an increased chance of seeing this problem. Object Design recommends not using the automounter. However, even hard mount points can become stale.	None. Object Design recommends that you do not use the automounter.
Server crash. The oss_out file contains references to permission problems.	Poorly configured NFS. You must configure NFS such that anon=0. When an application creates or opens a database, the Server acts on behalf of the user who is requesting the open/create. However, after the database is open, all reads and writes occur as root. When root attempts to log in to another machine, if anon=0 is not set, then the root must log in as the equivalent of noone, with no privileges. Setting anon=0 allows root on one machine (the Server machine) to have the same privileges as root on the other machine (where the database resides).	Configure NFS with anon=0.
Server crash. The oss_out file contains references to missing files.	Suppose a Server has started accessing a database and someone removes or renames the file. If the removal is done on a machine other than the database host, then NFS maintains a copy of the database so that the Server can continue to access it. However, if the removal occurs on the machine with the database (and the machine is not the Server host), then NFS does not retain a copy of the database for the Server process to continue using. Suddenly there is no database to access, even though the Server was already accessing it. It is also impossible to determine where the Server was in the access stage.	None.
Server crash. oss_out file contains references to remote file system's being full.	There is a Sun bug that prevents state flags from being correctly reset. Consequently, it is possible to fill a file system, remove a file, or decrease the size of a file, and have a system flag that continues to report that the file system is full.	Obtain a patch from Sun.
Server hang (wait state).	The Server requires the lock manager to be running on the machine that the Server is running on. If the lock manager is not running, the Server cannot do its job. The Server waits (appears to be hung) for the lock manager to be restarted. Once the lock manager is running, the Server can and will respond.	When a system reboots, ensure that the lock manager is running before the autostart of the Server.
Server hang (wait state).	Slow response from NFS. If, for any reason, NFS is slow to respond to requests for service, the Server must wait for those responses, just like any other client of NFS.	None.