ObjectStore Management

Chapter 9

Managing ObjectStore on OS/2

This chapter provides information for managing ObjectStore on OS/2 systems. For complete information, you should consult the first six chapters of this book along with this chapter.

The topics discussed are

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 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 an OS/2 host:

elvis:D:\usr\barbar\employees

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

Setting Server Parameters

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

OSTORE.INI
The ObjectStore Server stores its parameters in the OSTORE.INI file. This file is in the standard format for OS/2 parameters files. The ObjectStore installation and setup utilities create the OSTORE.INI file and store it, by default, in the \OS2 directory on the boot drive.

OSSETUP
All Server parameters have default values. Object Design recommends that you use the default value for each parameter, which requires no action on your part. However, you can use the OSSETUP utility to modify parameters in the OSTORE.INI file. See your installation guide for information.

Using -p
If you do not want to use the Server parameters in the OSTORE.INI file, you can create a standard OS/2 parameters file that contains the parameter values you want. When you start the Server with the osserver utility, you can specify this Server parameters file with the -p option.

OS2.INI
OS2SYS.INI
Alternatively, you can remove the OSTORE.INI file and place Server parameters in the OS/2 user profiles, OS2.INI and OS2SYS.INI.

Search order
ObjectStore uses the following search order to find parameter settings:

  1. File specified with the -p option to osserver

  2. OSTORE.INI file created by OSSETUP

  3. OS/2 user profiles (OS2.INI and OS2SYS.INI)

If ObjectStore does not find a parameters file, it displays a message.

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

Starting the Server

You can start the Server

Regardless of when it is started, you can configure the Server with various command-line options and parameter file options that are read at start-up.

Command-line options
When you start the ObjectStore Server with the osserver utility, you can specify the following options:
-c

Forces all data to be propagated from the log to the database. The Server is not started following this checkpoint.

-d int

Starts the Server in debug mode. Specify an integer from 1 through 50. The larger the number, the more information ObjectStore provides. You can also specify the -F option so that ObjectStore displays the information on the screen.

ObjectStore copies debug output to the OSSERVER.TXT file, unless you redirect it to another file.

-F

Foreground. Runs the Server process in the foreground. This reverses the normal behavior, where the Server runs as a background process.

-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.

-p pathname

Specifies a file containing parameter settings that override those in OSTORE.INI.

-v

Shows Server parameter values at start-up.

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.

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 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.

Starting Cache Manager
The Cache Manager runs automatically when it is needed; no command is necessary to start it. However, if you do want to start the Cache Manager explicitly, use this command:

START /N OSCMGR4 0
Controlling access to Server
The host list on an OS/2 Server determines which hosts can access databases.

Using OS/2 Environment Variables

You can use these NFS client software variables

UNIX.GID

Default: not set
For ObjectStore on OS/2, specifies the group ID (GID) for a UNIX client process.

UNIX.UID

Default: not set
Specifies the UNIX user ID (UID) for a client process being accessed from an OS/2 Server.

Specifying Utility Names

FAT names
The File Allocation Table (FAT) file system restricts file names to an eight-character file name and three-character file name extension. Consequently, ObjectStore utility names are truncated to eight characters when ObjectStore is installed on a FAT file system.

HPFS names
When installed on a High Performance File System (HPFS), ObjectStore utilities use their full command names.

This book refers to ObjectStore utilities by their full names.

Utility executables
All utility executables are stored in ObjectStore's BIN directory. For example:

%OS_ROOTDIR%\BIN\OSSERVER.EXE

Finding Files Containing ObjectStore Messages

In some cases, when an ObjectStore daemon process reports an error, ObjectStore sends 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 one of the environment variables listed below to determine the directory in which to place these files. It searches in the following order:

Search order
  1. %OS_TMPDIR%

  2. %TEMP%

  3. %TMP%

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.

Deleting error files
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.

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 OSSETUP utility. When you create the rawfs, you specify a disk drive letter and a file name. After you create the rawfs, you add Server partitions. See your installation guide for details.

Using OSSETUP to Add File Partitions

Be sure to shut down the Server before you run OSSETUP. You cannot run OSSETUP while the Server is running. When you exit from OSSETUP, 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.

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 OSSETUP 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 parameter 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 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 partition.

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:

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 OSSETUP 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

Capturing Debug Information

If you need help from Object Design support, follow these steps to capture debug information.

  1. On all machines, create the c:\temp directory if it is not already there.

  2. Set the OS_TMPDIR environment variable to c:\temp by adding the following line to the config.sys file:

          SET OS_TMPDIR=c:\temp 
    
  3. Reboot all machines.

    ObjectStore looks for OS_TMPDIR, then TEMP, and finally TMP. If none of these are defined, ObjectStore writes to the boot drive.

  4. On the Server machine, open a window and stop the Server:

          ossvrsht -f hostname 
    
  5. Set the OS_DEBUG_NETWORK environment variable to 1.

  6. Start the Server with the following command:

          osserver -F -v -d 10 
    
    You do not need to redirect the output. ObjectStore places the output in the oss.out and osserver.txt files in the c:\temp directory, using the OS_TMPDIR environment variable.

    The osserver options have the following meanings:
    -F

    Runs the Server in the foreground.

    -v

    Runs the Server in verbose mode. This outputs a lot of information about what the Server is doing.

    -d

    Indicates that the following number is a debug level.

    10

    Specifies the debug level. The debug levels that you typically use are 1, 3, 5, or 10, depending on the level of detail required for the trace.

  7. On each client,

    1. Open a window and shut down the Cache Manager with the oscmshtd utility.
    2. Set the OS_DEBUG_NETWORK environment variable to 1.
    3. Start the Cache Manager with the command
                  oscmgr4 0 50 0 1 1
      
      You do not need to redirect the output. ObjectStore uses OS_TMPDIR to send the output to the osc4.out file. The oscmgr4 options have the following meanings:
      0

      Indicates that the Cache Manager was not automatically loaded with a previous connection to the first client.

      50

      Specifies the Cache Manager debug level.

      0

      Required queue length.

      1

      Turns on debug messages for individual Cache Manager threads.

      1

      Sends debug output to the osc4.out file.

      Before activating any client, open a window and set the environment OS_DEBUG_NETWORK variable to 1 in that window.

  8. From that window, run the client to produce the error, redirecting the network debug information to a file in order to capture it.

  9. Send the following output to Object Design:

File Locking with NFS

You can access a remote database with the syntax

host:drive:\path 
However, the IBM NFS implementation for OS/2 does not allow locking a file across an NFS volume. Doing so is not safe for databases that are remote to the ObjectStore Server. But it is quite safe if the database is physically located on the ObjectStore Server.

For example, a client can access a database by means of NFS. The client NFS mounts the drive from the ObjectStore Server so that it appears as a local drive on the client. Now the client can reference the database as, for example,

g:\my\path\to\database
ObjectStore translates that path to something the ObjectStore Server can understand, and since it is physically on the ObjectStore Server, it can locate the Server-local file.

There is another scenario that is not safe. In this case, the database is not physically resident on the ObjectStore Server. By default, ObjectStore does not allow this. You can, however, set up a locator file to allow it. See Chapter 5, Using Locator Files to Set Up Server-Remote Databases. In this unsafe scenario, the database is physically resident on a third machine, the NFS server, which might be the client machine. The ObjectStore Server needs to lock the database by means of NFS. On OS/2, this is not possible. You cannot lock across NFS volumes, which makes it difficult to guarantee the integrity of the database.



[previous] [next]

Copyright © 1997 Object Design, Inc. All rights reserved.

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