Managing ObjectStore

Chapter 3

Environment Variables

This chapter describes the ObjectStore client environment variables.

These alphabetically ordered variables are described in the pages that follow.

Specifying Values for Environment Variables

You can set environment variables to modify the characteristics of the client environment. The variables you set apply to the process in which you set them and, consequently, to ObjectStore applications that you start from that process.

An environment variable is available on all platforms unless noted otherwise in this chapter. Defaults appear in the left margin.

The value for a variable is either an integer, a Boolean value, or a string that can have certain values as described in this chapter. When you set a variable string to an empty string, ObjectStore uses the default. When you set an integer or Boolean variable to a blank string (nonempty), ObjectStore interprets it as 0 or false.

Specifying integers

When a variable has a numeric value, it is an unsigned integer (leading + or - is dropped) that ObjectStore reads as a constant according to the rules of the C programming language. An empty setting results in a value of 0. If the whole value cannot be parsed, ObjectStore signals an error such as the following:

<err-0001-0040>The value of variable_name, bad_value, is not a valid 
integer. (err-misc)

Specifying Boolean values

When a variable has a Boolean value you can specify any nonnull value except 0 to set the variable. When the value for a Boolean variable is false, it means that the variable is not set. To turn off a Boolean variable, set it to 0.

A true setting for an environment variable is anything nonempty or nonnull that does not completely parse as a constant to the value of 0 according to the rules of the C programming language. For example, the following values return true:

The following values return false:

OS_AS_SIZE

Default: by platform

Sets the size, in bytes, of the persistent storage region in the address space for each client. Specify values in numbers of bytes in decimal values that are 0x10000 aligned (64 KB). Typically, it is not necessary to specify a value for this variable. The default value varies from platform to platform, as shown in the table at OS_AS_START, under the heading "Platform".

The size of the persistent storage region on the creating platform typically determines the size of the largest object you can store in a database. This is because ObjectStore commits the entire object in the transaction that allocates it. However, if the maximum size of a cluster is smaller than OS_AS_SIZE, the largest object you can store is limited to the maximum cluster size. (Allocation is limited to a single cluster.)

Caution

An incorrect value for OS_AS_SIZE or OS_AS_START can cause failures. Be absolutely certain that you understand the way addresses are assigned on your platform before you modify these values.

For example, if you quadruple OS_AS_SIZE, your application runs on a SPARCserver/470, but fails on SPARC 1 and SPARC PC systems.

When considering address space, note the important distinction between assigning an address and mapping an address. When ObjectStore assigns an address, it means that the client determines where it would put those pages if it needed them. Assigning an address reserves it so that it cannot be assigned to another page. When ObjectStore maps a page to an address, it means that the page is available to the client.

When a page uses hard pointers to refer to pages outside the region, ObjectStore assigns address space to those pages. This makes it possible, in certain situations, to use up available address space by touching a single page. In many cases, changing OS_AS_SIZE solves this problem. However, there are cases in which the schema design could benefit from the strategic application of references and sometimes a reworking of transaction semantics.

If the application uses soft pointers instead of hard pointers to point to data in other regions, ObjectStore does not assign address space to the other regions until the soft pointers are actually resolved. In programs with complex schemas using pages that refer to objects in many other regions (a high degree of "non-local fan out"), use soft pointers instead of hard pointers. If the client exhausts the address space, it might be possible to reorganize some of the client's transactions to reduce the amount of data being referenced in any single transaction.

OS_AS_START

Default:
by platform

Sets the address of the beginning of the persistent storage region of the process's address space. Specify values in numbers of bytes in decimal values that are 0x10000 aligned (64 KB). Typically, you do not supply a value for this variable. Default values vary by platform, as shown in the table under the heading "Platform".

Individual platforms impose further constraints on the values that are legal.

See OS_AS_SIZE for a caution about the use of this variable.

The following table shows the specifications for the persistent storage region in a process's address space:
PlatformDefault Starting Address
OS_AS_START
Default Size
OS_AS_SIZE
Default Ending Address
Digital UNIX

0x35000000

512 MB+ (0x2003000)

0x5503000

HP-UX

0x563A0000

300 MB (0x12C00000)

0x68FA0000

IBM RS/6000

0x40000000

1024 MB (0x40000000)

0x80000000

Intel Windows NT
and 95

0x30000000

512 MB (0x20000000)

0x50000000

SGI MIPS

0x30000000

255 MB (0x19000000)

0x3FFF0000

Sun SPARC Solaris 2

0xE2000000

192 MB (0x0C000000)

0xEE000000

Windows NT

On Windows NT, 2 GB is the maximum user-mode address space. Your program, its data, and ObjectStore's address space must fit in 2 GB. A user program on Windows NT uses the bottom 2 GB of address space. DLLs and the like use up space at 0x10000000; stacks use up space at 0x7fxxxxxx. Consequently, there are only 1.75 GB available.

SPARCstation 10

There is no address space hole on the SPARCstation 10. In a single mmap, you can map any portion of the address space from address 0 to the process stack (around 0xefffe000). However, a single call to mmap has a limit of 0x80000000 bytes (approximately 2 GB). For ObjectStore, that means you can use only half of the entire 32-bit address space.

SPARCstation 1000

On a SPARCstation 1000, the address space available for mapping starts above the break. The break is the top of the process's heap. The heap grows by increasing the break. It is risky to map a persistent range that is too near the break because a growing heap might collide with the persistent range.

The hole in the SPARCstation 2's address space begins at 0x20000000 and ends at 0xe0000000. Addresses above the hole are available for mapping, but ObjectStore requires that the persistent range be contiguous so the range cannot span the hole.

On Solaris 2, the default start address is 0xe2000000, just above the end of the hole. The persistent range can be placed on either side of the hole on both systems.

On a SPARCstation 2 running Solaris 2, the size of the persistent range is limited on the high end by the area in which shared libraries and other objects placed by the system are allocated. This starts below the stack, around 0xf0000000, and grows downward.

On the SPARCstation 1000, though, this area starts around 0xe0000000 and grows downward. Apparently, on the SPARCstation 1000, ObjectStore's default range is sandwiched between the stack and shared libraries. Because the hole does not constrain the available space on this machine, the system gives the stack a bit more room to grow by placing shared libraries at lower addresses.

For a maximum persistent range on the SPARCstation 1000, the range from 0x10000000 to 0xd0000000 should be safe to use and large enough for nearly any purpose. However, you should test this before you put an application into production that depends on it.

SPARCcenter 2000

Up to 1.8 GB can be allocated in a single mmap call.

OS_AUTH

Overrides the authentication search protocol (see Authentication Required). The format for specifying this variable is OS_AUTH=type or OS_AUTH=host:type, where type is one of the values listed in the table below and host is the name of the server.

The valid types that OS_AUTH can be assigned are as follows:
ValueAuthentication
NONE

No authentication

SYS

Sun ONC RPC AUTH_SYS authentication

DES

ONC RPC AUTH_DES authentication

NP

UNIX seteuid/setegid or Windows LogonUser authentication (Name Password)

NT_LOCAL

Windows NT ImpersonateLoggedOnUser authentication

NT_REMOTE

Windows NT Security Service Provider authentication

You can also use a semicolon-separated list of authentication types to specify authentication types for various hosts. This list can include one default value. See examples following the next paragraph.

OS_AUTH can specify only one default authentication type and it can specify only one authentication type per host. The client performs network name lookup, so it is not necessary to list the aliases of a host. For example, if the default DNS domain is odi.com and a Server has two network names - server1 and server-one - the host names server1, server-one, and server1.odi.com are all the same host.

If OS_AUTH specifies a host-specific authentication type that is not supported by the Server, the default value is used if the Server supports the default.

If the Server supports neither the specified authentication type nor the default type, the client attempts to find a type supported by both the client and the Server. If it does not find a supported authentication type, it signals an err_authentication_failure error.

Examples

OS_AUTH=server1:DES;SYS
Instructs the client to use SYS authentication for all Servers except server1. When connecting to server1, the client uses DES authentication if server1 supports it. If server1 does not support DES or SYS, an authentication method is selected from the list of authentication types that the Server supports.

OS_AUTH=NONE
Instructs the client to use no authorization. If a server does not support the NONE type, an authentication method is selected from the list of authentication types the Server supports.

OS_AUTH=server1:NP
Instructs the client to use Name Password authentication when connecting to server1. For any other Server, an authentication method is selected from the list of authentication types that Server supports.

OS_BROWSER_NUMERIC_FORMAT

Default:
ObjectStore defaults

Allows you to set the output format of numeric types. It supports the following types: int, long, double, ldouble, float, uint, ulong, short, and ushort. If you do not set any of these types, ObjectStore defaults are used.

The following example sets the display format of all int types to hexadecimal, all float types to four-digit precision, and all ulong types to hexadecimal.

OS_BROWSER_NUMERIC_
FORMAT="int=%x,float=%.4f,ulong=%x"

OS_CACHE_DIR



Default:
/tmp/ostore

Specifies the pathname of the directory in which ObjectStore places the client cache and communications segment (commseg) files. Specifying an alternative pathname can be useful when your /tmp/ostore directory is small. ObjectStore places the cache file in the specified directory and assigns a file name to avoid conflicts between multiple processes that are running ObjectStore and using the same directories.

If OS_CACHE_DIR is not set, ObjectStore places the cache file in the directory specified by the Cache Directory parameter in the Cache Manager parameters file, if one exists. See Setting Cache Manager Parameters.

This directory should not be an NFS mount point; this can result in slower client performance and in potential problems with memory mapping over NFS.

Cache and commseg files should be in the same directory. See OS_COMMSEG_DIR for related information.

Windows

The operating system determines the location of the cache in virtual memory. You cannot change the location.

OS_CACHE_SIZE

Default: 8 MB ObjectStore Single: 2 MB

Size of client cache, in bytes. The cache size defaults to 8 MB, except for ObjectStore single applications, for which the default cache size is 2 MB. In either case, the default cache size can be overridden using the OS_CACHE_SIZE environment variable.

Note that the size of the client cache does not limit the size of an object that can be in the database. ObjectStore can store an object on multiple pages and can swap pages in and out of the client cache as needed.

When you are trying to determine the optimum cache size for your application, consider data access patterns as well as the amount of data that is accessed. In other words, both size and operation are important. The goal is to minimize the number of times the client must swap pages out of the cache and send them back to the Server.

Also consider the amount of physical memory in your machine. Usually, it is desirable for the cache to stay in physical memory rather than to be swapped out to disk.

The cache size is limited only by the amount of resources (address space, memory or disk space) on the machine.

If necessary, ObjectStore rounds down the number you specify to a page-size boundary, that is, a multiple of the page size.

OS_CMGR_STARTUP_LOCK



Default:
varies
by platform

Specifies an alternative location for the Cache Manager start-up lock file.

On UNIX systems, ObjectStore clients automatically start a Cache Manager if one is not already running. ObjectStore uses a special file, called a start-up lock file, to ensure that only one Cache Manager starts on a host. The default location for this file is
Solaris 2

/var/tmp/cmgr6_startup_lock

Other systems
(not Windows)

/tmp/cmgr6_startup_lock

If a Cache Manager is not already running, a client

  1. Creates the start-up lock file

  2. Launches the Cache Manager

  3. Ensures that the client can communicate with the Cache Manager

  4. Deletes the start-up lock file

The start-up lock file does not contain anything. Its existence serves as a lock while a client is starting a Cache Manager. This prevents other clients from also starting a Cache Manager.

If you do not want to use the default location for the start-up lock file, or if the default location is unavailable, you can specify an alternative location with the OS_CMGR_STARTUP_LOCK environment variable. Set this variable to a local pathname.

ObjectStore tries to use the default first. If it is not possible to use the default, ObjectStore uses the pathname you specified for OS_CMGR_STARTUP_LOCK.

The client process must have the authority to create the specified file.

OS_COLL_POOL_ALLOC_CHLIST_BLKS

Default: false

Specifies that chained list blocks should be pool allocated. To set this variable, specify any nonnull value except 0.

OS_COMMSEG_DIR



Default:
/tmp/ostore

Pathname of the directory used for the communications segment. ObjectStore places the commseg in the /tmp/ostore directory automatically. If the UNIX file system containing /tmp/ostore is very small, it might be desirable to locate the communication segment elsewhere.

ObjectStore places the commseg in the specified directory and assigns a unique file name to avoid conflicts between multiple processes that are all running ObjectStore and using the same OS_COMMSEG_DIR setting.

Commseg and cache files should be in the same directory. See OS_CACHE_DIR for related information.

This directory should not be an NFS mount point because this can result in slower client performance and can create potential problems with memory mapping over NFS.

Windows

The operating system determines the location of the commseg in shared memory. You cannot change the location.

OS_COMP_SCHEMA_CHANGE_ACTION

Default: error

Controls the severity of the error resulting from a type mismatch during library and compilation schema generation. You can set it to
error

The type mismatch is reported as an error. The compilation is eventually terminated and the compilation schema remains unchanged.

silent

The type mismatch is not reported. The new type definition replaces the previous definition in the compilation schema.

warn

The type mismatch is reported as a warning. The new type definition replaces the previous definition in the compilation schema.

OS_DEBUG_C0000005



Default: false

Instructs ObjectStore to display a message box if a fault occurs and the ObjectStore exception handler sees it. The message explains the fault as an Attempt to read location 0x1234 from EIP 0x10231023. This can be useful in locating access violations in your code. To set this variable, specify any nonnull value except 0 to turn on this variable.

OS_DEBUG_LOCATOR_FILE

Default: 0

Instructs ObjectStore to send diagnostic information about the processing of the locator file to stderr.

When set to 0, the default, no information is provided.

When set to 1, ObjectStore generates a report every time the locator file is searched. This allows you to determine the input to the search exactly, which in turn enables you to diagnose the reason that the locator file is not providing the expected results.

If your application is a Windows GUI application, see OS_STDOUT_FILE.

OS_DEBUG_RECURSIVE_EXCEPTION



Default: false

On Windows only, when this is set, recursive exceptions are not handled by ObjectStore, so they can be debugged in a debugger.

OS_DEF_BREAK_ACTION



Default: false

Allows you to set a break point that obtains a stack trace before the stack is unwound. When you set this variable to 1, ObjectStore reaches a hard-coded break point immediately before an exception is signaled. This is useful when your application exits with an unhandled TIX exception and works with Visual C++'s just-in-time debugging. Setting OS_DEF_BREAK_ACTION also hits a breakpoint if ObjectStore's internal abort routine is called.

OS_DEF_EXCEPT_ACTION

Default: not set

Controls what happens if an unhandled exception is signaled. This is useful in debugging unhandled exceptions. You can specify the following values:
abort

ObjectStore aborts the process. On UNIX, ObjectStore creates a core file and, if you are running in a debugger, returns control to the debugger.

integer

Specify an integer greater than or equal to 1. ObjectStore exits from the program with the specified integer as the return value.

kill

ObjectStore action varies by platform:

Any other value

ObjectStore exits from the program with a return value of 1. This is the default.

OS_DEF_MESSAGE_ACTION



Default: not set

Determines the default message action for _ODI_message (used for unhandled TIX exceptions). You can set this variable to stderr or stdout to send the information there, or you can specify the name of a file to receive the information.

OS_DEFAULT_AS_PARTITION_SIZE

Default: not set

Specifies, in bytes, the amount of address spaced assigned to newly created sessions, unless overridden by objectstore::set_default_address_space_partition_size(). The actual amount assigned is the specified amount rounded up to the nearest 64 KB

For more information on sessions, see Chapter 3, Multithread and Multisession Applications, in Advanced C++ API User Guide.

OS_DISABLE_PROPAGATE_ON_COMMIT

Default: false

Intended for use with ObjectStore/Single, OS_DISABLE_PROPAGATE_ON_COMMIT controls when ObjectStore propagates committed data from the transaction log to a database. By default, this environment variable is false and data is propagated to a database when a top-level transaction commits. If this environment variable is set to true, the data is propagated when a database is closed and when an application ends normally. If an application ends prematurely, some of the data might not have been propagated to the database. This data is propagated the next time the ObjectStore is initialized or on a call to progagate_log().

For some applications, setting this environment variable to true can improve performance because data is written to the database less frequently. However, it increases the risk of data loss, which can happen if an application ends prematurely and the transaction log is deleted before the data is propagated to the database.

Applications can override this environment variable by using objectstore::set_propagate_on_commit(). For more information, see objectstore::get_propagate_on_commit() and objectstore::set_propagate_on_commit() in C++ API Reference.

OS_DISPLAY_INSTALL_MISMATCHES

Default: false

Displays to stdout any mismatches found during MOP dynamic type installation. When this variable is not set, the only indication of failure is that an exception is raised. To set this variable, specify any nonnull value except 0.

If your application is a Windows GUI application, see OS_STDOUT_FILE.

OS_ENABLE_REALTIME_COUNTERS

Default: false

Turns on the collection and display of timing statistics that measure ObjectStore performance. ObjectStore displays values of real-time counters that help show where time is being spent. To set this variable, specify any nonnull value except 0.

OS_FORCE_HANDLE_TRANS

OS_HANDLE_TRANS



Default: false

Controls what ObjectStore does if there is a memory fault on an address that is not in the persistent storage region of address space, for example, if you happen to dereference a null pointer.

When you set OS_FORCE_HANDLE_TRANS to any nonnull value except 0 (or objectstore::set_handle_transient_faults is called with the true argument) ObjectStore signals the appropriate exception: err_null_pointer or err_deref_transient_pointer. This causes dereferences to illegal non-ObjectStore addresses to signal a TIX exception and display a message, and lets you get a stack trace.

When you set OS_HANDLE_TRANS, ObjectStore runs the SIGSEGV handler that was in force before ObjectStore was fully initialized. If there is no such handler, ObjectStore signals the appropriate exception.

If neither of these variables is set, ObjectStore runs the SIGSEGV handler that was in force before ObjectStore was fully initialized. If there is no such handler, ObjectStore returns the signal to the operating system to handle. The operating system performs the usual actions for SIGSEGVs, for example, dumping core or some other action that depends on other environment variable settings.

If you do not set up your own SIGSEGV handler before ObjectStore is initialized, the error message is Segmentation Violation: Core Dumped. If both variables are set, OS_FORCE_HANDLE_TRANS has precedence.

OS_IGNORE_LOCATOR_FILE

Default: false

Indicates that no locator file is associated with any application on the client. This overrides all other settings and function calls, including the existence of $OS_ROOTDIR/etc/locator. Specify any nonnull value except 0 to set this variable. Set this variable to 0 to allow locator files (this is the default).

When this variable is set to a nonnull nonzero value, locator files are not used but a small part of the locator file logic in the client is executed nonetheless. Consequently, if you have locator file debugging enabled, you still receive diagnostic information. See OS_DEBUG_LOCATOR_FILE.

For information about the locator file, see Description of the Locator File.

OS_INC_SCHEMA_INSTALLATION

Default: false

When set, ObjectStore creates new databases in incremental schema installation mode. This means that ObjectStore adds types to the database schema as they are needed. When this variable is not set, ObjectStore creates new databases in batch schema installation mode. This means that when ObjectStore creates a database, it creates a database schema that includes all types that might be allocated in the database.

To set this variable, specify any nonnull value except 0.

An application performs incremental rather than batch schema installation if either of these conditions is true:

You can override the effect of this environment variable for a particular process by using objectstore::set_incremental_schema_installation(). See the C++ API Reference. For a discussion of the issues involved, see the C++ API User Guide.

OS_INHIBIT_TIX_HANDLE

Default: not set

Specifies an error message substring for which exception handling is to be disabled.

Many end-user applications have omnibus error handlers to catch all errors being signaled and present them in an easily readable format to the user. This sometimes makes debugging difficult because the backtrace information has disappeared. When you specify a substring to OS_INHIBIT_TIX_HANDLE, if the substring appears in the formatted error message, exception handling is disabled for the specific error. You can then generate an unhandled exception dump for analysis or view the backtrace in a debugger.

Specify all to disable all handling.

OS_LANG_OVERRIDE



Default: not set

OS_LANG_OVERRIDE changes the behavior of ObjectStore without affecting other applications that depend on LANG.

LANG is a public environment variable that controls the selection of the message catalog sets appropriate for the specific language locale. It also is used internally to identify the character encoding used and, thus, affects the processing of strings. This variable might already be set by your system manager.

Because the LANG variable is public, Object Design supplies another variable, OS_LANG_OVERRIDE, that takes precedence over LANG. The result is that anywhere ObjectStore uses catalogs, OS_LANG_OVERRIDE can change the catalog path construction as well as the way strings are processed. OS_LANG_OVERRIDE also affects .msg file path construction for Object Design scripts such as osinstal and osconfig on platforms that use them.

There is a possibility that the value of LANG is not one of the variables shown in the following table. If the value set is not listed in the table, English is assumed unless OS_LANG_OVERRIDE is set to one of the values in the table.

The values recognized by ObjectStore appear in the following table:
ValueHP-UXNon-HP-UX
japanese

Shift JIS Code (SJIS)

Extended UNIX Code (EUC)

Ja_JP
jp_JP.sjis
ja_JP.sjis
japanese.sjis
ja__JP.PCK
jp__JP.PCK

Shift JIS Code (SJIS)

Shift JIS Code (SJIS)

Japanese
japanese.euc
japan
Japan
ja
jp_JP
jp_JP.euc
ja_JP
ja_JP.euc


Extended UNIX Code (EUC)

Extended UNIX Code (EUC)

OS_LIBDIR

Default: OS_ROOTDIR\lib

Specifies the directory that contains schema files distributed with ObjectStore. The directory must be on a machine that has a Server, so you do not receive an error when trying to access the schema files. This is set up by the installation process. The only exception to this is if you have a locator file set up to handle remote access to databases and you configure the relevant Server to allow remote access to databases.

If OS_ROOTDIR is on a machine that does not have an ObjectStore Server, you must copy or move the library schema files to a machine that is running a Server. Use this variable to specify the new directory.

OS_LOCATOR_ESCAPE_CHARACTER

Default: $

The default escape character for regular expressions in locator files is $, rather than the usual \. You can specify an escape character explicitly with this environment variable. For information about the locator file, see Description of the Locator File.

OS_LOCATOR_FILE

Default: false

The client environment variable OS_LOCATOR_FILE can be set to any legitimate argument to objectstore::set_locator_file(), with the same meaning. Calls to set_locator_file() override this setting. See the C++ API Reference. See also Description of the Locator File.

OS_LOG_TIX_FORMAT

Default: false

The name of a log file to record all exceptions signaled. This file logs all printf control strings signaled, regardless of whether the exception is handled. This facility is especially useful for debugging two situations: recursive exceptions (common if you get exceptions during message processing) and bad printf strings.

OS_META_SCHEMA_DB

Default: $OS_ROOTDIR/lib/
metaschm.db

Specifies the metaschema database.

The metaschema database, which is shipped with ObjectStore, describes hidden internal types and is needed for operations such as data browsing, schema evolution, database verification, and the Metaobject Protocol (MOP).

The metaschema database must be on the same machine as the Server. The only exception to this is if you have a locator file that is set up to handle remote access to databases and you configure the relevant Server to allow remote access to databases.

Normally, the metaschema database is in $OS_ROOTDIR/lib but under certain circumstances, it might be elsewhere. This can happen when the machine on which $OS_ROOTDIR resides does not have a local ObjectStore Server. In this situation, unless you set up a locator file, you must copy the metaschema database to the machine that the Server runs on.

If you move the metaschema database out of $OS_ROOTDIR/lib, be sure to set this variable to the new location so that ObjectStore can find the metaschema database.

OS_NETWORK



Specifies the network dynamic link libraries (DLLs) to be loaded and used by all ObjectStore executables. The default is

O6NETNSM,O6NETTCP
Normally, you need not change the default setting. In other words, you do not usually set OS_NETWORK. Possible values for OS_NETWORK are

Possible values

In standard operation, ObjectStore detects automatically the networks that are present, and OS_NETWORK does not need to be set. However, you can set OS_NETWORK to a comma-delimited list in situations in which you want more control over the network used by ObjectStore.

Network list order

The order of the list is important. When you set the OS_NETWORK variable, you must almost always specify O6NETNSM as the first network in the list. For local connections, the local network (O6NETNSM for Windows) offers significantly higher performance than any other network.

If you omit the local network or do not specify it first, starting an ObjectStore application might fail to start the Cache Manager automatically. You must then start the Cache Manager manually before running the first ObjectStore application. Many other operations can fail if these DLLs are not specified at all or are not specified first.

When to change
the default

Suppose that you originally installed ObjectStore on a system connected to a network, then you disconnect the system from the network. You must set OS_NETWORK so that it no longer expects to enable network protocols. For example, if your system was previously using TCP and now it is a stand-alone system, you might receive the following error when you try to run ObjectStore:

ObjectStore internal error
connect failed (err_internal)
Set OS_NETWORK to O6NETNSM on Windows to prevent the TCP interface from loading and allow the Server to initialize normally.

On Windows, if you have an unsupported TCP/IP stack on your machine and you experience problems, set OS_NETWORK to O6NETNSM so that ObjectStore does not attempt to initialize or use the unsupported network.

OS_NO_MAPPED



Default: true

Instructs ObjectStore not to use mapped communication between the client and the Server. ObjectStore uses mapped communication only if the client and the Server are on the same host and the Server parameter Allow Shared Communications is set. To set this variable, specify any nonnull value except 0.

OS_NOTIFICATION_QUEUE_SIZE

Default: not set

Specifies the maximum number of notifications that can be in a process's notification queue. Notification queues are part of the ObjectStore Cache Manager process. The Cache Manager has a notification queue for each local client.

If an application does not call the set_queue_size() function, ObjectStore uses the value you specify for OS_NOTIFICATION_QUEUE_SIZE. If an application does not call set_queue_size() and this environment variable is not set, ObjectStore uses a default value of 50.

The maximum allowable value for this variable is 16383. If you set this variable to a higher value, ObjectStore uses 16383 as the value, rather than the value you set.

The API for setting the maximum length of the notification queue is os_notification::maximum_notification_queue_length().

OS_OSDUMP_APPSCHEMA_PATH

Allows users to give a different path for osdump.adb.

OS_OSLOAD_APPSCHEMA_PATH

Allows users to give a different path for osload.adb.

OS_OSSG_CPP

Default:
by platform

Sets the C preprocessor used by ossg. You can set this variable to a nondefault C preprocessor. The following table shows the default preprocessor on each platform:
UNIX

cpp

Windows

cl

OS_PASSWORD

Specifies a password to be used by a client application to connect to an ObjectStore Server, used with the OS_USERNAME environment variable. If the client allows Name Password authentication, the client connects to the Server without prompting for a username and password.

OS_PORT_FILE

Default: by platform

The name of a ports file for network services. See Modifying Network Port Settings.

OS_PRINT_CLIENT_COUNTERS

Default: false

Turns on display of counters that provide information about client performance. To set this variable, specify any nonnull value except 0.

OS_RCVBUF_SIZE

Default: 16384 bytes

Sets the default size of the network buffer used by the client to receive data from the Server. For best results, this size should be the same as the Server parameter Preferred Network Send Buffer Size. See Preferred Network Send Buffer Size for further information.

Note that some applications benefit from an increase in the size of the network buffers used by ObjectStore clients and Servers. You can change the size used by the clients from the default of 16384 bytes by setting the environment variables OS_SNDBUF_SIZE and OS_RCVBUF_SIZE. You can change the size used by the Server by setting the Server parameters Preferred Network Send Buffer Size and Preferred Network Receive Buffer Size. Usually, you achieve the best performance if OS_SNDBUF_SIZE is the same as Preferred Network Receive Buffer Size and OS_RCVBUF_SIZE is the same as Preferred Network Send Buffer Size.

Depending on the operating system, you might find that large values are rejected, which leads to reduced performance. Object Design recommends that you experiment by doubling the size until performance no longer improves.

OS_RESERVE_AS



Default: false

An optimization to ObjectStore increases performance, sometimes by a very significant factor. ObjectStore uses this optimization when this environment variable is not set. This means that performance is fast but that there is potential for confusion. ObjectStore does not use the optimization when this environment variable is set.

This optimization can cause problems if your own program calls the mmap system call with 0 as the first argument or if your program calls a subroutine library that does so. If your program does either of these things, you should disable the optimization, either by calling the entry point objectstore::set_reserve_as_mode(os_boolean new_mode) or by setting the environment variable OS_RESERVE_AS to any nonnull value except 0. If you both call the entry point and set OS_RESERVE_AS, the entry point takes precedence.

This variable affects the setting of reserve address space mode. When ObjectStore is in this mode, it always keeps the entire persistent region reserved, from the operating system's point of view, so that any other subsystem in the client process that maps something in and asks the operating system to assign some address space receives address space outside the persistent region.

If reserve address space mode is off, such a request might assign space that is part of ObjectStore's persistent region. This can cause problems because the subsystem appears unable to coexist with ObjectStore.

If reserve address space mode is off, however, operating system calls that manipulate the virtual address space are faster on some platforms.

OS_ROOTDIR

Default: varies
by platform

The top-level directory in the part of the file system hierarchy containing ObjectStore files serves as the prefix of various directory names used in search paths. This environment variable is required to run ObjectStore. You set the value of the variable when you install ObjectStore.

If you change the location of your ObjectStore installation, be sure to change the value specified for OS_ROOTDIR. Not doing so can cause the following message to be signaled:

no handler for exception:
no networks where registered, please verify your ostore network 
configuration: <err_0001_0141>
The client tried to find the Server over the network. With an incorrect setting for OS_ROOTDIR, this happens even when the client and Server are on the same machine.

Defaults

The following table shows the defaults for OS_ROOTDIR:
PlatformDefault for OS_ROOTDIR
Solaris 2

/opt/ODI/OS6.0

UNIX
(except Solaris 2)

/usr/local/ODI/OS6.0

Windows

The parent of the directory containing the O6LOW.DLL that is executing

Windows

If ObjectStore was not installed in C:\OSTORE, you must set OS_ROOTDIR to the location of the directory in which ObjectStore was installed. OS_ROOTDIR should be kept in the DOS environment, so that makefiles and DOS utilities can reference it.

OS_SCHEMA_KEY_HIGH

OS_SCHEMA_KEY_LOW

Default: 0

OS_SCHEMA_KEY_HIGH specifies the high 4 bytes of a 64-bit schema key.

OS_SCHEMA_KEY_LOW specifies the low 4 bytes of a 64-bit schema key.

If you run certain ObjectStore tools and utilities on schema-protected databases, set OS_SCHEMA_KEY_LOW and OS_SCHEMA_KEY_HIGH to specify the schema keys of the databases to be accessed. The tools and utilities for which you must set these variables include

Any ObjectStore application, including an ObjectStore tool or utility, can have a schema key that allows it to access a protected database with a matching key. Normally, you specify a key for an application programmatically. See objectstore::set_current_schema_key() in the C++ API Reference. These environment variables are provided because it is not possible for you to set the schema key of a tool or utility programmatically.

You can, however, build an application that performs the same function as an ObjectStore utility by calling a member of the class os_dbutil, os_compact, or os_schema_evolution. This application can specify the schema key programmatically.

Deploying applications

If you are deploying an application, you need to know that some ObjectStore tools (such as ossg) cannot be invoked from the ObjectStore API. To allow your customers to use such a tool on a database that you have protected, build an application that spawns the tool as a child process. Specify the key of the child process by setting the environment variables from within the application.

These environment variables determine an application's schema key when an ObjectStore application attempts to access data in a schema-protected database and either of the following is true:

Remember that when the environment variables determine an application's schema key, all schema-protected databases that the application accesses must have the same schema key.

If you run an application on a schema-protected database and the application does not have a schema key, or the application's schema key does not match the database's schema key, ObjectStore signals err_schema_key and issues an error message such as the following:

Error using schema keys 
<err-0025-0151> The schema is protected and the key, if provided, did 
not match the one in the schema of database db1.

See also

For information about the schema protection API, see objectstore::set_current_schema_key(), os_database::change_schema_key(), and os_database::freeze_schema_key() in the C++ API Reference.

OS_SECURE_RPC_DOMAIN

Default: not set

Specifies a local domain name. For use with AUTH_DES authentication. If there is no system getdomainname() routine or if it returns null, this variable is consulted for the name of the local domain.

OS_SNDBUF_SIZE

Default: 16384 bytes

Sets the default size of the network buffer used by the client to transmit data to the Server. For best results, this size should be the same as the Server parameter Preferred Network Receive Buffer Size.

See Preferred Network Receive Buffer Size for additional information about the Server network buffer size. See further discussion about these parameters and the ways they affect performance in OS_RCVBUF_SIZE.

OS_STDOUT_FILE



Default: not set

Specifies the pathname of a file to which you want to redirect output that ObjectStore would otherwise send to stdout and stderr.

If your application is a Windows GUI and this variable is not set, ObjectStore displays the output in a message box.

To separate the output from several applications, you can set this variable to a pathname such as C:\TEMP\DEBUG.%d. ObjectStore substitutes the process ID in place of the %d.

OS_THREAD_LOCKS

Default: true

Determines whether ObjectStore uses a lock to ensure that only one thread at a time can execute within ObjectStore code other than collections code.

When this variable is true (set to a value other than 0), ObjectStore uses the thread lock. This is the default.

If OS_THREAD_LOCKS is false (set to 0), ObjectStore cannot use thread locks in any portion of ObjectStore.

OS_TIX_BUFFER_SIZE



Default: 8192

Specifies the size in bytes of the error report buffer. The default size is large enough for all reasonable and expected errors. However, if an error message is extremely long, it might overflow the buffer and cause the application to abort. If this happens, you can resolve the problem by setting this variable to a larger value.

OS_TIX_WD



Default: none

Specifies the working directory for ObjectStore when an unhandled TIX exception causes ObjectStore to create a core dump. (Whether there is a core dump depends on the platform and on the setting of the OS_DEF_EXCEPT_ACTION environment variable.)

When you specify a directory for OS_TIX_WD, ObjectStore sets that directory to be the working directory before it creates the core file.

This is particularly useful for ObjectStore daemons. For example, on UNIX systems the Cache Manager always runs with its working directory set to the root directory. This avoids administration problems such as preventing volumes from being unmounted. Set the OS_TIX_WD variable to control where ObjectStore puts core dumps of the Cache Manager daemon.

OS_TMPDIR



Default: not set

Specifies a directory in which to place temporary files. If you do not set OS_TMPDIR, ObjectStore uses the path returned by the Win32 API GetTempPath(). To set this variable, specify any nonnull value except 0.

OS_TRACE_MISSING_VTBLS

Default: false

Causes a run-time debugging message to be printed to stderr when a missing vtbl handler is installed for a class. The message identifies the class with the missing vtbl handler. For example:

Installing missing vtbl: Class: CCC Name: NNN Symbol: SSS
CCC

Identifies the class of the top-level object for which the vtbl was found to be missing.

NNN

Identifies the independent name of the vtbl. For example, Derived_class::Base_class.

SSS

Identifies the mangled name of the vtbl symbol that was missing.

When you are missing a vtbl, the err_missing_vtbl run-time error message does not indicate the vtbl that is missing. If you rerun the application with OS_TRACE_MISSING_VTBLS turned on, ObjectStore catalogs vtbls that

When you are debugging problems with missing vtbls, this helps determine those classes that need vtbls. Any nonempty value except 0 enables the debugging message.

OS_TURN_ON_ENGLISH_MESSAGES

When set to 1, forces the printing of English messages along with the catalog-retrieved language-specific message.

OS_USERNAME

Specifies a username to be used by a client application to connect to an ObjectStore Server; used with the OS_PASSWORD environment variable. If the client allows Name Password authentication, the client connects to the Server without prompting for a user name and password.



[previous] [next]

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

Updated: 03/11/99 11:18:50