ObjectStore Management

Chapter 8 Managing ObjectStore on Windows

This chapter provides information for managing ObjectStore on Windows NT and Windows 95. For complete information, you should consult the first six chapters of this book along with this chapter.

The topics covered include

Using ObjectStore Utilities

During installation, you use the ObjectStore Setup Utility (SETUP.EXE) to configure ObjectStore daemons and applications - the Server, Cache Manager, Database Manager, and Browser.

All utility executables are stored in ObjectStore's BIN directory.

Memory Requirements for Windows 95

Object Design recommends a minimum of 16 MB memory on Windows 95 systems. The ObjectStore Server is tuned for high performance on network servers. Because of this, it sometimes does not run efficiently on systems with less than 16 MB physical memory. If you use less than 16 MB physical memory, read this section carefully to ensure that your system can run ObjectStore properly. The information here applies to Server-only and client-only installations. The goal is to minimize memory consumption.

Performance

With less than 16 MB physical memory, ObjectStore's performance might be degraded, and in some cases Windows 95 itself might be unreliable.

Unsupported configuration

You should never run a network server on Windows 95 with less than 16 MB physical memory; Object Design does not support this configuration. Stand-alone systems with less than 16 MB physical memory require careful tuning to achieve adequate performance and efficient resource consumption.

Run only ObjectStore clients

Generally, systems that run only ObjectStore clients have the fewest problems with memory consumption.

Virtual memory requirements

The sum of your physical memory and the swap file size must be at least 24 MB. For example, if you have 8 MB physical memory, your swap file must be at least 16 MB. In all cases, Object Design recommends a minimum 8 MB swap file. Set up the Windows 95 swap file in the Control Panel System icon.

Modifying Server parameters

When running an ObjectStore Server on a stand-alone system with less than 16 MB physical memory, you can reduce the Server's memory consumption by setting the following Server parameters as indicated in the following table. You must restart the Server for the new parameter settings to take effect.


Parameter	Setting
Log Record Segment Buffer Size	256 sectors (default is 1024)
Max Data Propagation Per Propagate	256 sectors (default is 256)
Propagation Buffer Size	512 sectors (default is 8192)

Modifying client environment variables

You can reduce memory consumption by setting the OS_CACHE_SIZE environment variable to an amount less than its default size of 8 MB (8388608). The minimum size on Windows 95 is 480 KB (491520). Generally, on systems with 12 MB physical memory, 3 MB (3145728) is a good value. Some applications that access large amounts of data simultaneously might require larger values.

The client cache is only filled as persistent data is actually allocated or referenced. If your application references only a small amount of persistent data, reducing OS_CACHE_SIZE will probably have little or no effect.

Reducing OS_AS_SIZE and/or OS_COMMSEG_SIZE to conserve memory is generally not worthwhile.

Specifying File Database Pathnames

You specify a file database with an operating system pathname. For example:

os_database::open("d:\\carter\\myfiledb")

UNC pathname

The syntax for specifying a UNC pathname is

os_database::open("\\\\servername\\sharename\\myfiledb")

In C and C++, you must escape the back slash (\) with another back slash.

You can also specify a relative pathname.

Server-remote databases

You usually store a file database on a host that is running an ObjectStore Server. However, you can use a locator file to allow databases that are remote from the Server. See Chapter 5, Using Locator Files to Set Up Server-Remote Databases.

Server names

You can specify a Server name when you open or create a database. The Server name identifies the Server host on which the database is located. For example:


Server on a UNIX host:	elvis:/usr/barbar/employees
Server on a Windows host:	elvis:D:\usr\barbar\employees

This specifies a database, employees, in the directory \usr\barbar on the host elvis.

This method of specifying a pathname is called a Server-relative pathname. The token before the first colon names a Server host, and the rest of the string is parsed by that Server in the syntax used on the Server host operating system. Among other things, this is useful when no remote file protocol (such as NFS) is in use between the client and Server hosts.

Setting Server Parameters

The Server, Cache Manager, and Browser store their parameters in a central location.

Each Server parameter that you can specify is described in Chapter 2, Server Parameters.

Windows

On Windows NT and Windows 95, parameters are in the Windows registry database.

Changing parameters

You can edit these parameters using the ObjectStore utility SETUP.EXE. SETUP.EXE allows you to modify all fields except for license information. ObjectStore license information is written by the INSTALL program.

To set Server parameters, run SETUP.EXE, select Advanced Options, and then select Server Parameters. See your ObjectStore installation guide for additional information about using SETUP.EXE.

After you modify a Server parameter, you must shut down and restart the Server for the parameter to take effect.

Starting the Server

There are several ways to start the Server. One way is to use the ObjectStore setup utility, SETUP.EXE, to configure the Server to start automatically at system start-up.

Windows NT

On Windows NT, you can configure the Server as an NT service. This is the preferred method.

When starting the Server as an NT service, you can specify osserver command-line options in the following table in the NT service administration dialog.

On Windows NT, you can run the Server as an NT console application. In this case, you run OSSERVER.EXE from an NT command window, passing -console as the first argument.

At start-up, ObjectStore configures the Server according to parameter options in the registry database.

Windows 95

On Windows 95, you can start the Server manually by double-clicking on the ObjectStore Server icon in the ObjectStore folder, or by using Start | Run, or from an MS-DOS prompt window.

Command-line options

Ordinarily, you use Server parameters to control the Server's behavior. However, you can also specify the following command-line options to osserver.


-c	Checkpoint. Forces all data to be propagated from the log to the database. The Server does not start after this checkpoint.
-con or -console	Windows NT only: runs the Server as a console-mode application. If you specify this option, it must be the first option you specify.
-d int	Starts the Server in debug mode. Specify an integer from 1 through 50. The larger the number, the more information ObjectStore provides. If the ObjectStore Server Service is running, you must stop it and restart it. Use the Services applet in the Control Panel. Another alternative is to stop the ObjectStore Server Service. Then you can specify the -con option so that ObjectStore displays the information on the screen. Debug output goes to %OS_TMPDIR%\osserver.txt.
-i	Initializes the Server log file and the rawfs, if you have one, with a confirmation prompt. Use with caution.
-I	(Uppercase I) Initializes the Server log file and the rawfs, if you have one, without a confirmation prompt. Use with extreme caution.
-v	Displays Server parameter values at start-up.

Use -i and -I with caution

Be sure to move all data out of the log before you initialize it. See ossvrchkpt: Moving Data Out of the Server Transaction Log. Be sure to back up all data in the rawfs before you initialize it. See osbackup: Backing Up Databases.

When you initialize the transaction log, anything in the log is lost. The Server resizes the log to the values specified by the Log Data Segment Initial Size and Log Record Segment Initial Size Server parameters. When the log is in the rawfs, this frees space for use by other files. When the log is in the native file system, this reallocates space dedicated to the transaction log. The size of the log does not change.

Initializing when you have a rawfs

If you have a rawfs, then specifying the -i or -I option with osserver initializes the rawfs and the transaction log. When you specify -i, ObjectStore responds with

The entire ObjectStore file system on this host is about to be initialized, 
thus destroying any data currently in it. Unless you have a backup of the 
ObjectStore file system, it will be impossible to recover the old contents 
once the initialization is started. Are you sure that you want to reinitialize 
the ObjectStore file system?

When you specify -I, this message does not appear.

Initializing when you do not have a rawfs

If you do not have a rawfs, then specifying the -i or -I option with osserver initializes only the transaction log. When you specify -i, ObjectStore responds with

You have asked for initialization which will create a new transaction log, 
deleting any old log that might exist, thus destroying any recovery data in 
the old log. This might leave some file databases in a broken state. Are 
you sure that you want to create a new log?

When you specify -I, this message does not appear.

Start-up message

After starting, the Server displays the message Server started to let you know that it is ready to accept requests from clients on the network.

Troubleshooting Windows NT

You might have a situation where you cannot run the Server and the Cache Manager as NT Services, even after defining autostart for them. You receive the following error:

Starting process
Process could not start
error 1067: Process terminated unexpectedly

The first thing to assess is if the Server and Cache Manager can be started in console mode using the -con option to osserver. If they start properly in console mode, this problem is likely to be a permission problem or an incorrect definition for the ObjectStore image path in the registry.

Try the following to determine what is wrong with the ObjectStore definition of NT Services.

If you ran an earlier ObjectStore release, confirm that it was properly uninstalled prior to installing the new release. This is necessary so that the image path is properly set for the NT Services.
Ensure that ObjectStore was installed using an account with Administrative privileges.
To run the Server and Cache Manager as NT Services, you must log on with Administrative privileges.
Confirm that the OS_ROOTDIR environment variable is set and that it points to the proper ObjectStore installation.
Make sure that the image path for the Server and Cache Manager is correct. To check this, run Regedt32 from a window and follow the path
```
      HKEY_LOCAL_MACHINE | System | CurrentControlSet | Services

      | ObjectStore Cache Manager R4.0
```
Then, check that the setting for the image path is correct. Do the same for ObjectStore Server R4.0.
Check that the user account used to log in includes the log in as a service.... privilege.

If the same executables do not bring up ObjectStore properly even in console mode (especially if the Server does not start from the command line using the -con option), then it is not a permission problem.

If it is not a permission problem, then it is very likely that the transaction log has not been initialized. In this case, a message can be seen in the %OS_TMPDIR%osserver.txt output:

When a partition is not specified, the transaction log is needed.

This is usually the last message in osserver.txt or in the Server start-up output in debug mode. If this is not the case, then in the window from where you start the Server, enter

>set OS_DEBUG_NETWORK=1

and

>start /min osserver -con -F -v -d 10 > server.out

>osserver -con -F -v -d 10 > server.out

if the start command is not recognized.

After that send the server.out file to Object Design support.

Creating a Rawfs

Maintaining a rawfs provides a fast, convenient way to manage all ObjectStore databases at your site. See Managing the Rawfs.

Creating a rawfs

To create the rawfs or add partitions to an existing rawfs, use the SETUP.EXE utility. When you create the rawfs, you specify a disk drive letter and a file name. After you create the rawfs, you can add file partitions. See your installation guide for details.

Using SETUP.EXE to Add File Partitions

Be sure to shut down the Server before you run SETUP.EXE. You cannot run SETUP.EXE while the Server is running.

The PartitionN Server parameter specifies the partitions in the rawfs. It creates the Server partition file if it does not exist, using the pathname given in the PartitionN statement. You add a partition to the rawfs by specifying a PartitionN statement when prompted to by the SETUP.EXE utility. Each PartitionN statement has the following form:

Syntax

PartitionN FILE pathname {expandable | nonexpandable}

N 

Specifies a positive integer from 0 to n. PartitionN statements can appear in the Server parameters file in any order, but empty slots are not allowed. For example, if you have four partitions, they must be numbered 0 through 3. Required.


FILE

Specifies that the partition is a file partition. Required.


pathname

Specifies the absolute pathname of the partition. It must begin with a drive letter, colon, and back slash. 


expandable | nonexpandable

Indicates whether or not the size of the partition can increase. Required.

N	Specifies a positive integer from 0 to n. PartitionN statements can appear in the Server parameters file in any order, but empty slots are not allowed. For example, if you have four partitions, they must be numbered 0 through 3. Required.
FILE	Specifies that the partition is a file partition. Required.
pathname	Specifies the absolute pathname of the partition. It must begin with a drive letter, colon, and back slash.
expandable \| nonexpandable	Indicates whether or not the size of the partition can increase. Required.

It is unnecessary to specify more than one file in the same drive letter.

Example

Partition0 FILE c:\mypart0 expandable
Partition1 FILE d:\mypart1 expandable
Partition2 FILE e:\bigpart99 expandable

Modifying Partition Size

Controlling expansion

You can control expansion of the rawfs as follows:

If one file is used, it expands dynamically as needed, as long as there is room in the partition containing the file.
If multiple files are used for the rawfs, they can expand dynamically, if you specify expandable in the PartitionN statement.

For example, suppose the rawfs contains three files (\usr1\one, \usr2\two, and \usr3\three). If you want to permit only two of the files to expand, use SETUP.EXE to specify the partitions as follows:

Example

Partition0: FILE c:\usr1\one expandable
Partition1: FILE d:\usr2\two expandable
Partition2: FILE e:\usr3\three nonexpandable

When you exit from SETUP.EXE, it prompts you to indicate whether or not you want to restart the Server. If you indicate No, you must run osserver to start the Server.

Starting the Cache Manager

Windows NT

The Cache Manager is an NT Service that is usually configured to start when the system is booted. Alternatively, you can configure it to start automatically when it is needed. Use the Control Panel Services applet to configure the Cache Manager for Manual Start-up.

To start the Cache Manager from your account, you must have domain user listed as one of your privileges. If you do not, you might receive the message

Error auto starting Cache Manager. Unable to open service database. 
Access is denied.

You might receive this message when you log in to your domain account rather than logging directly into the computer name account. If this is the case, you need to ask your system administrator to check your user privileges in that domain or configure the Cache Manager for Automatic Start-up.

If you want to start the Cache Manager as a console application, use the following command:

oscmgr4 -con 0 [debug_level]

Windows 95

On Windows 95, the Cache Manager is started automatically as needed. If you need to start it manually, use Start | Run | oscmgr4 0 [debug_level].

Finding Files Containing ObjectStore Messages

In some cases, when an ObjectStore daemon process reports an error, ObjectStore routes the output to a file. These files are


Server errors	OSSERVER.TXT
Cache Manager errors	OSCMGR4.TXT

If the file does not already exist, ObjectStore creates it; if the file does exist, ObjectStore appends to it.

ObjectStore uses the path assigned to the environment variable OS_TMPDIR to determine the directory in which to place these files. If OS_TMPDIR is not set, ObjectStore uses the path returned by the Win32 API GetTempPath().

ObjectStore daemons seldom send messages to these files except under certain unusual error conditions. In these cases, this information can be helpful in understanding and resolving an error. When you report to Object Design a problem that might involve one of these daemons, find such a file, if it exists, and provide the contents.

When the daemon process is not running, you can safely delete the corresponding file. Usually, very little is ever sent to these files, so they are unlikely to occupy much disk space.

Accessing UNIX Databases from Windows

When accessing UNIX file databases over a network (such as with Intergraph PCNFS), the ObjectStore client on Windows NT prompts for a name and password. See Authentication Required.

If you want the ObjectStore client to use RPC authentication, use the Windows NT REGEDT32 utility, and set the following variables, where x.x is the ObjectStore release number, and username is your username:

HKEY_LOCAL_MACHINE\Software\Object DesignInc.\ObjectStorex.x\Remote\username\UNIX.UID 
HKEY_LOCAL_MACHINE\Software\Object DesignInc.\ObjectStorex.x\Remote\username\UNIX.GID

Set these variables (which are strings, such as REG-SZ) to the numeric values of the UNIX user and group IDs required. Note that you can edit these values only from a Windows NT account with Administrator privileges.

Note that the HKEY_LOCAL_MACHINE\Software\Object Design Inc.\ObjectStore.4.0\Remote has Administrator rights only. This is to prevent a security breach that can result if ordinary users have write privileges to this area. If you set up the values for an ordinary user who does not have Administrator privileges and the user tries to run an ObjectStore program, the user still must enter a user name/password to access the Server.

To prevent this, you can change the HKEY_LOCAL_MACHINE\Software\Object Design Inc.\ObjectStore.4.0\Remote to have read-only privileges for users with non-Administrator privileges. You can set the privileges using the Security | Permissions dialog in the registry editor.

About Client/Server Communication

Windows clients and Servers can use three network layers:

Within a single machine, ObjectStore uses an interprocess communication mechanism based on named shared memory objects.
Windows Sockets provide TCP/IP connections. Object Design tests and supports a limited number of Windows Sockets implementations.

A Server can and typically does serve all three networks simultaneously. A client chooses the first network available that recognizes the name of the Server host.

For more information, see ObjectStore Installation and License for Windows, Network Support.

Using an NT Server to Access Remote Databases

Netware

ObjectStore can be used with the Gateway Services for NetWare GSNW feature.

All Remote Hosts

If a Server is configured to allow remote databases, the Server can use UNC paths to access such databases. Using UNC paths is the preferred method because of permissions issues surrounding the use by a service of mounted drives. Server-relative paths such as

      serverhost:\\filehost\sharename\directory\foo.odb

or locator files that redirect all UNC paths to a named server host take advantage of this feature. In general, it is unnecessary to

Mount file host drives on your Server host
Use REPLACE statements in locator files

Use this feature with NT as well as NetWare file hosts.

Access Control for Remote Databases

Windows NT refuses to allow the Server to use credentials obtained from a remote client host on a remote file host. There are two alternatives to deal with this issue. They are described in Microsoft Knowledge Base article Q132679, available on the Microsoft TechNet CD, or on the web as

http://www.microsoft.com/kb/bussys/winnt/q132679.htm

The first choice is to run the Server normally, as Local System. This requires that the user Everyone is able to access remote files on behalf of remote clients. Note that this solution requires you to create an account for Everyone on non-Windows NT systems.

The second choice is to run the Server as another user. You can set this up by means of the Control Panel Services applet.

[previous] [next]

Updated: 03/26/98 20:46:29