This chapter provides information about compiling, linking, and debugging your application.

The earlier topics address all platforms. The last three topics are each dedicated to a specific platform or group of platforms.

• Using Standard Template Libraries
• Moving an Application and Its Schema
• Working with Virtual Function Table (VTBL) Pointers and Discriminant Functions
• Missing VTBLs
• Using new and delete Operators with cfront
• Debugging Applications
• Dependency of Object Files on Header Files
• Retrofitting Makefiles
• UNIX
• Windows
• OS/2

ObjectStore can now be used to store STL objects persistently. There are a number of STL class library implementations available that can be used with ObjectStore. For example, ObjectSpace, Rogue Wave, and Visual C++ offer such implementations.

How to Store STL Types Persistently

1. Include the STL header files as well as the ObjectStore headers in the schema source file, and then mark the STL types. See Creating Schema Source Files.
   
   
2. Provide an STL allocator for persistent storage. The ObjectStore distribution does not include allocators, but does include an example that shows you how to create your own.
   
   

Microsoft Visual C++ Restriction

Moving an Application and Its Schema

Syntax

ossetasp -p  executable 
ossetasp  executable database


-p 

Instructs ossetasp to display the pathname of the specified executable's application schema database. Do not specify  database in the command line when you include -p.


 executable 

Specifies the pathname of an executable. On Windows systems, this can also be the pathname of a DLL.


 database 

Specifies the pathname of an application schema database. ObjectStore patches the specified executable so it uses this application schema. 

When you move or copy an ObjectStore application to a machine that is not running a Server, leave the application schema database on the Server host. Normally, the application schema database must be local to the Server.

After you copy or move an application to another machine, you must patch the executable so that it can find the application schema database. Run the ossetasp utility with the absolute pathname of the application schema database. Be sure to specify the name of the Server host.

A locator file allows a database and its application schema to be on a machine other than the Server host. See ObjectStore Management, Chapter 5, Using Locator Files to Set Up Server-Remote Databases.

Windows NT

Restrictions

Working with Virtual Function Table (VTBL) Pointers and Discriminant Functions

• Virtual function tables (vtbls)
• Union discriminant functions

Persistent storage

Discriminants

Relocation

When your application references a persistent object of a class with virtual functions, ObjectStore must fill in the vtbl pointer in the object. To fill in the vtbl pointer, ObjectStore must know the address of the vtbl for the class. Virtual function tables are not stored in databases; they are part of your executable.

During relocation, ObjectStore might need vtbls and discriminant functions. It finds them in tables that map class names to references to both vtbls and discriminant functions. The schema generator generates a C++ source file (or object file for Visual C++) containing these tables that relate your schema to your application.

These tables are filled in during application link or postlink or at program start-up time, or some combination of these, depending on the platform. At each of these steps, the referenced vtbls and discriminants are searched for in the executable and, if found, are entered into the tables. At run time, ObjectStore can use these tables to find items for relocation.

On cfront platforms, the os_postlink executable performs this job. On other platforms, the compiler does it. On some platforms, this search might be done at run time based on the currently available DLLs.

Missing VTBLs

Symbols Missing When Linking ObjectStore Applications

void foo_force_vfts(void*){
      force_vfts(new A);
      foo_force_vfts(new B);

      ...
}

Abstract classes

class A {
      virtual void foo() = 0;
};
class B : public A {
       virtual void foo();
};

class A {
      virtual void foo() = 0;
      A(){}
      friend void force_vfts(void*);
      A(void*);
};
class B : public A {
      virtual void foo();
};

Instantiating collection classes

void foo_force_vfts(void*) {
      foo_force_vfts(new os_Set< missing-type>);
      foo_force_vfts(new os_List< missing-type>);
      foo_force_vfts(new os_Array< missing-type>);
      foo_force_vfts(new os_Bag< missing-type>);
      foo_force_vfts(new os_Collection< missing-type>);
}

Run-Time Errors from Missing VTBLs

Sometimes an executable does not have vtbls for all classes with virtual functions in the schema. When a vtbl pointer for a class is not available, ObjectStore fills in the vtbl pointer for the class's instance with a special vtbl that signals an error when any of the virtual functions is called.

No constructor

Class not in schema

Inline virtual functions when using noncfront compilers

When you are using a noncfront compiler (except on OS/2), if all virtual functions of a class are inline, either because they are defined fully in the class specification or with the inline keyword, the compiler treats the virtual function table as static. Because the virtual function table is viewed as static, the vtbl pointers for such a class are not available (that is, not seen globally, therefore not available to ObjectStore) because the locations of the virtual functions were not filled in by ossg.

The solution to this problem is to put an out-of-line virtual function in each class with a missing vtbl. You can either modify an inline function or you can add a trivial noninline function. To determine which classes need an out-of-line virtual function, you can run ossg with the -no_weak_symbols option. This identifies missing vtbls at link time rather than at run time. For information about this option, see page 43.

A class that meets the following conditions might also need the addition of a noninline virtual function:

• Has at least one virtual base class
• Has at least one virtual function defined by a base class
• Does not define any virtual functions

Visual C++

OS/2

-rtdp option

To obtain a list of missing vtbls at run time, set the OS_TRACE_MISSING_VTBLS environment parameter. See ObjectStore Management, OS_TRACE_MISSING_VTBLS.

AIX C Set ++ - Virtual Function Table Pointers

ObjectStore derives these addresses as part of schema generation. The application schema source file generated by ossg contains extern declarations of the vft symbols. The schema generator stores their addresses in a table when your program starts execution.

Normally, vfts are declared extern in all modules that reference them except in the module that defines the first noninline virtual function. That module defines the vft as a global symbol.

However, there are several cases in which there is no module that corresponds to the first noninline virtual function. For example, all the class's virtual functions can be inline. In these cases, C Set ++ generates a static vft in each module that allocates an object of the class. In such a case, the application schema source file cannot link to the vft, since it is static in some other module or modules.

You can tell if you have such classes with the -qinfo:vft argument to C Set ++. If it informs you of any classes with static links, and if you want to store them persistently, you must either add an out-of-line virtual function to each such class, or use the command-line arguments that control vft allocation to make the vfts accessible. Aside from making ObjectStore work, it makes your executable smaller. Here is an example of -qinfo:vft output:

class A {
public:
      virtual foo():
      int a;
      A() {a=0;}
};
class B : public virtual A {
public:
      virtual foo();
      int b;
      B() {b=1;}
};
class C : public B {
      int c;
      C() {c=2;}
};
int B::foo() {}
xlC_r -qinfo=vft -c x.C

"x.C", line 29.1: 1540-017: (W) Return value of type "int" is expected.
"x.C", line 1.1: 1540-281: (I) The virtual function table for "A" will be 
defined where "A::foo()
"x.C", line 10.1: 1540-280: (I) The virtual function table for "B" is defined 
with "extern" links.
"x.C", line 20.1: 1540-280: (I) The virtual function table for "C" is defined 
with "extern" links.

The simplest way to make C Set ++ work with ObjectStore is to create an additional source file that includes the definitions for classes that have static links. Compile it with -qvftable, and link it. This does not avoid the extra static copies of the table in any modules that allocate objects of this class, but it does allow the application schema source file to link to them.

To avoid extra copies, you have to compile all ordinary sources with -qnovftable, and then add -qvftable to the appropriate sources so that each vft is defined exactly one time.

Using new and delete Operators with cfront

Note that there is still a limitation that ObjectStore cannot completely address - if a shared library that is not itself linked with the ObjectStore library uses C++ allocation, it will not share the copy of _new_handler provided by ObjectStore.

Debugging Applications

• Set the OS_TRACE_MISSING_VTBLS environment variable. If you run the application with OS_TRACE_MISSING_VTBLS set, ObjectStore catalogs vtbls that
  • Were not found at initialization
  • Might result in err_missing_vtbl errors later on

• Run the osverifydb utility after an application creates a database. This allows you to check for invalid pointers.
• If the database information is incorrect, you can examine it with the ObjectStore Inspector.
• If performance is the issue, you can use the ObjectStore Performance Expert (OPE) as a debugging tool.

Dependency of Object Files on Header Files

In previous releases on some platforms, ObjectStore provided the osmakedep command. This is no longer the case. Your compiler vendor should supply you with a configuration management tool.

Retrofitting Makefiles

If you copy an on-line version of an ObjectStore makefile from ObjectStore documentation sources, make sure that you have tabs at the beginning of appropriate lines and not spaces.

UNIX

Linking with ObjectStore Libraries

Requirement

You must also link with either the libosthr or libosths libraries. You must link with additional ObjectStore libraries according to the features you use in your code, as shown in the following table. If there is more than one library, you must specify them in the order given. See Examples of Passing Libraries to the Linker.

If Your Application Uses This Feature	Link with These Libraries in This Order
Any ObjectStore feature	libos {libosthr or libosths}
Collections	liboscol libos {libosthr or libosths}
Compactor	liboscmp libos {libosthr or libosths}
Database utilities:
os_dbutil::osverifydb()	liboscol libosmop libostcl libosdbu libos {libosthr or libosths}
All other os_dbutil methods	libosdbu libos {libosthr or libosths}
MOP	libosmop liboscol libos {libosthr or libosths}
Queries and indexes	libosqry liboscol libos {libosthr or libosths}
Relationships	liboscol libos {libosthr or libosths}
Schema evolution	libosse libosqry liboscol libos {libosthr or libosths}
C run-time library	libos {libosthr or libosths}

Threads library

If you have a real threads package, link with the libosthr library. The libosths library is a stub threads library.

IRIX shared process (sproc) restrictions

• All file descriptors are shared in the group.
• All accesses to ObjectStore using external interfaces, and potential page faults, are single-threaded through a single process at any given time.

Specifying libraries

CC -L$(OS_ROOTDIR)/lib -o my_exec main.o os_schema.o foo.o 
-los

Exclusive libraries

HP-UX and DCE

When using threads (libosthr), while ObjectStore is running in its fault handler, DCE masks most signals. Therefore, when DCE is linked into an ObjectStore application, ObjectStore's fault handler reenables the following signals:

• SIGHUP
• SIGINT
• SIGQUIT
• SIGBUS
• SIGSEGV
• SIGVTALRM

extern "C" void _ODI_set_reenable_mask(unsigned int new_mask);
extern "C" unsigned int _ODI_get_reenable_mask();

The mask is a bit vector of the signal values. A value of 1 indicates that the corresponding signal is enabled when ObjectStore's fault handler is entered.

Note that _ODI_get_reenable_mask returns 0 if _ODI_set_reenable_mask has not been called.

Also note that regardless of the reenable_mask value, ObjectStore always reenables the signal being handled (SIGSEGV or SIGBUS).

Examples of Passing Libraries to the Linker

-loscmp -losmop -losqry -loscol -los {-losthr | losths}

-losse -losqry -loscol -los {-losthr | losths}

-losdbu -los {-losthr | losths}

{-losse | -loscmp} -losmop -losqry -loscol -los -losdbu -losu -losths

{-losse | -loscmp} -losmop -losqry -loscol -los -losdbu -losu -losthr 

Usually, DEC C++ uses 64 bits for all pointers in generated code. The eXtended Truncated Address Support Option (xtaso), and other #pragma directives and compiler options, let code with 32-bit pointers coexist within this 64-bit operating system environment. If you use only -xtaso, and have 64-bit pointers in the objects stored in your database, then your database will not be heterogeneous.

Note that within a compilation unit, pragma statements allow the user to switch between 32-bit and 64-bit classes selectively. However, ossg deals with these pragma statements at the granularity of a complete top-level class.

Software version requirements

If you are uncertain what versions of software are running on your system, check them with the following commands.

To determine the operating system version, enter

uname -a

V3.2 148 

To determine the version of the compiler, enter

cxx -V | tail -1

DEC C++ V5.1-1 

How to use the -xtaso option

This means that when you write ObjectStore applications, you need to use some of the methods described in this section to accommodate 32- and 64-bit pointers. Specifically, the considerations you must address are

• Header files
• System-defined function declarations with pointers in the signature
• ObjectStore collections class libraries

Compiler options and pointer size directives

The pointer size compiler options are -xtaso, -xtaso_short, -vptr_size, and -vptr_size_short. You can accommodate 32- and 64-bit code using the -xtaso and -vptr_size or -xtaso_short and -vptr_size_short compiler options. The following table describes the compiler options:

Compiler Option	Description
-xtaso	Sets the default pointer size of the compilation unit to 64 bits (for all pointers except virtual function and virtual base pointers in a C++ class object). This is the normal default unless overridden by -xtaso_short.
-xtaso_short	Sets the default pointer size of the compilation unit to 32 bits (for all pointers except virtual function and virtual base pointers in a C++ class object).
-vptr_size	Makes 64 bits the default size of virtual function and virtual base pointers in a C++ class object. This is the default unless overridden by -vptr_size_short.
-vptr_size_short	Makes 32 bits the default size of virtual function and virtual base pointers in a C++ class object.

Whenever any of these options is specified on the command line, the following actions occur:

• #pragma pointer_size is enabled. This pragma statement only has an effect if you specify a pointer size compiler option on the command line.
• The cxx command automatically passes the -taso option to the linker. This option causes the linker to load the executable in the lower 31-bit addressable virtual address range. This means the program is limited to a 31-bit virtual address space whenever you use any of the pointer-size compiler options.

To use ObjectStore with the DEC C++ compiler, you must select one of the following methods of protecting pointer size assumptions:

• Use the -xtaso option and wrap all pointer declarations that refer to other pointers so that the referring pointer size and the referred-to pointer size agree. In foo**, the foo* that is pointed to must agree with the foo** declaration.

• Use ObjectStore typedefs to allow the code to compile as required independently of the -xtaso option. Do not use these with a persistent class.
• Use -xtaso_short and force everything to 32-bit pointers.

If heterogeneity is not a consideration for your application and you are not concerned with the amount of memory used for 64-bit pointers, you can take advantage of the 64-bit operating system environment and compile using the -xtaso option. This option makes 64 bits the default pointer size and uses 32-bit pointers for particular declarations. In such a case, it is possible to use third-party class libraries that only support 64-bit pointers. See "Using the -xtaso option" for details about using this option.

If heterogeneity is an important consideration for your application, you can easily take advantage of ObjectStore's 32-bit pointers in this 64-bit operating system environment by compiling with the -xtaso_short option. This option makes 32 bits the default pointer size and uses 64-bit pointers for particular declarations. The 32-bit pointer data type allows you to minimize the amount of memory used by dynamically allocated pointers, and assists in porting applications that contain assumptions about pointer sizes. See "Using the -xtaso option" for details about this option.

#pragma pointer_size directive

• References
• Pointers to member declarations
• Implied this pointer argument declarations in member function declarations
• Function declarations
• Array declarations

For this pragma statement to have any effect, specify -xtaso, -xtaso_short, -vptr_size, or -vptr_size_short on the cxx command.

#Pragma Directive	Description
pointer_size	Controls the pointer size of all pointers except virtual function and virtual base pointers in a C++ class object. Has an effect only if you specify one or more of the pointer-size compiler options.
required_pointer_size	Has the same effect as #pragma pointer_size but is always enabled, whether or not you specify any pointer-size compiler options.
required_vptr_size	Controls the size of virtual function and virtual base pointers in a C++ class object. Always enabled, whether or not you specify any pointer size compiler options.

This pragma statement has the following syntax:

      #pragma pointer_size {long|64}
      #pragma pointer_size {short|32}
      #pragma pointer_size restore
      #pragma pointer_size save

The save and restore options are particularly useful for specifying mixed pointer support and for protecting header files that interface to older objects. Objects compiled with multiple pointer size pragma statements are not compatible with old object files, and the compiler cannot detect that incompatible objects are being combined.

Using the -xtaso option

With this approach, most pointers in your application are 64 bits, and 32 bits are used for selected pointers. To use this method, compile with -xtaso to enable #pragma pointer_size and cause the cxx command to pass -taso to the linker. In addition, use #pragma pointer_size, #pragma required_pointer_size, and #pragma required_vptr_size to control the pointer sizes for particular declarations. For example, to save space in an object, declare a class as follows:

#pragma pointer_size save
#pragma required_vptr_size save
#pragma pointer_size short
#pragma required_vptr_size long
            class Table_Node {
                  char *table;    // 32 bit pointers
                  Table_Node *next;
                  Table_Node *(Table_Node::*search)(char *);
                              // pointer to member has
                              // 2 32 bit fields
            public:
                  void insert_node(char *);
                  Table_Node *extract_node(char *);
                  Table_Node *search_forward(char *);
                  Table_Node *search_backward(char *);
            };
#pragma pointer_size restore
#pragma required_vptr_size restore

Using typedefs

Use typedefs when building an application using the -xtaso option to avoid compilation errors that result from incompatible interface definitions. The following code example produces such a compilation error:

#include <ostore/ostore.hh>
int main(int, char **)
{
      os_int32 max_servers;
      os_server **servers;
      os_int32 n_servers;
      objectstore::get_all_servers(max_servers, servers, n_servers);
}
$ cxx example.cc -c -xtaso

example.cc:9: error: In this statement, the referenced type of the pointer 
value "servers" is "long pointer to os_server", which is not compatible with 
"short pointer to os_server".
Compilation terminated with errors.

An example of such a typedef is os_server_p. It is defined as an os_server*.

If you modify the example, replacing os_server **servers with os_server_p *servers, the program compiles cleanly:

#include <ostore/ostore.hh>
int main(int, char **)
{
      os_int32 max_servers;
      os_server_p *servers;
      os_int32 n_servers;
      objectstore::get_all_servers(max_servers, servers, n_servers);
}
$ cxx example.cc -c -xtaso 

The comprehensive list of typedefs supplied by the ObjectStore header files follows

typedef char const* os_char_const_p;

typedef char* os_char_p;

typedef objectstore_exception& objectstore_exception_r;

typedef os_bound_query const& os_bound_query_const_r;

typedef os_canonical_ptom& os_canonical_ptom_r;

typedef os_coll_query& os_coll_query_r;

typedef os_coll_rep_descriptor const& os_coll_rep_descriptor_const_r;

typedef os_coll_rep_descriptor const* os_coll_rep_descriptor_const_p;

typedef os_collection const& os_collection_const_r;

typedef os_collection* os_collection_p;

typedef os_cursor const& os_cursor_const_r;

typedef os_database_root& os_database_root_r;

typedef os_int32& os_int32_r;

typedef os_old_reference& os_old_reference_r;

typedef os_old_reference_version& os_old_reference_version_r;

typedef os_rawfs_entry* os_rawfs_entry_p;

typedef os_reference& os_reference_r;

typedef os_reference_local& os_reference_local_r;

typedef os_reference_version& os_reference_version_r;

typedef os_transaction const* os_transaction_const_p;

typedef os_typed_pointer_void const& os_typed_pointer_void_const_r;

typedef tix_exception* tix_exception_p;

typedef void const* os_void_const_p;

typedef void const*& os_void_const_p_r;

typedef void* os_void_p;

typedef void*& os_void_p_r;

.

Using the -xtaso_short option

To use this option, compile with the -xtaso_short and -vptr_size_short options on the cxx command. The -vptr_size_ short option makes 32 bits the default size of virtual function and virtual base pointers in a C++ class object. The -vptr_size_ short option also enables #pragma pointer_size and passes -taso to the linker.

It is important to protect header files so that when the header file is included in a compilation (using #include), the pointer size assumptions are the same as those made when the code associated with the header files was compiled.

#pragmas and function declarations

• Modify each header file
• Use the header file protection option provided with the DEC C++ compiler

#pragma pointer_size save
#pragma pointer_size long
extern "C" {
int getrusage (
      int who,
      struct rusage *r_usage );
}
#pragma pointer_size restore

#pragma __environment save              // Save pointer size
#pragma __environment header_defaults   // set to system defaults
// existing header file
#pragma__environment restore // Restore pointer size

• __DECC_include_prologue.h
• __DECC_include_epilogue.h

For example, if the source code has #include <stdio.h>, the order of file processing would be

1. /usr/include/__DECC_include_prologue.h
   
   
2. /usr/include/stdio.h
   
   
3. /usr/include/__DECC_include_epilogue.h
   
   
4. Whatever follows #include <stdio.h>
   
   

/usr/lib/cmplrs/cxx/protect_system_headers.sh

The default directory tree root assumed by the script is /usr/include, but you can specify other roots.

Embedded ObjectStore members

Troubleshooting Errors

• In an example such as $OS_ROOTDIR/examples/coll, if you change the TFLAGS to be only -xtaso, and your OSSCHEMA_FLAGS remain -xtaso_short, your code compiles without any warning messages. However, an attempt to run the code produces an error such as

      No handler for exception:
      Miscellaneous ObjectStore error
      An inconsistency was detected during the allocation of an object of 
      type part. The compiler believes the allocation size should be 40 bytes,
      while the schema believes it should be 32 bytes. Verify that the 
      arguments to `new' match the type and/or array count of the object
      being allocated.
      (err_misc)
      Abort process (core dumped)

• If you try to use ossg without any -taso flags, the following error occurs:

      ossg -assf osschema.cc -asdb coll.adb   -I/usr/local/ostore/4.0.0.C/
      include schema.cc /usr/local/ostore/4.0.0.C/lib/liboscol.ldb
      <err-0004-0008>
      The following class definitions in library schema "/usr/local/
      ostore/4.0.0.C/lib/liboscol.ldb" 
      were inconsistent with the corresponding definitions obtained from 
      other library or compilation schemas specified for building the 
      application schema:
      "os_set" from the schema source file "/usr/local/ostore/4.0.0.C/
      include/ostore/coll/coll_int.hh"
      the class size changed from 24 to 40
      "os_tinyarray" from the schema source file "/usr/local/
      ostore/4.0.0.C/include/ostore/coll/query.hh"...
      *** Exit 1
      Stop.

No handler for exception:
Attempt to call virtual function without vtbl.
Vtbl for type os_packed_list not linked into application. (err_missing_vtbl)
IOT trap (core dumped)

$(CCC) +eh -Wl,-E -g -o test test.o os_schema.o $(LDLIBS)

HP aC++ Source Files

Note that HP recommends that you use extensions consisting only of .c or .C without additional characters, because while the compiler accepts the additional characters, other HP tools and environments might not.

If you compile only, each C++ source file produces an object file whose prefix is identical to the source file but with a .o suffix. However, if you compile and link a single source file into an executable program in one step, the .o file is automatically deleted.

HP C++ Compiler Messages

CC: "myprog.C", line 82: warning: debug.object_ids: weird 
vtable->vclass for os_Collection <const MyObject*> (198)
CC: "myprog.C", line 8: warning: debug.emit_variable: bad address found
for name ABC::xyz::ex (251)

pxdb: [cu: 0 index: 0x136] can't link template/expansion
pxdb: [cu: 0 index: 0x14f] can't link template/expansion
pxdb: [cu: 0 index: 0x168] can't link template/expansion
pxdb: [cu: 0 index: 0x181] can't link template/expansion

CC: "myprog.cc", line 342: warning: label in block with destructors (2048)

SGI IRIX Compiler Option

Sun C++ Compiler Options

-vdelx compiler option

delete [] persistent_array;

error: delete [] does not correspond to any \Qnew'

On Solaris 2.x systems, you must compile (and link) ObjectStore applications with real thread support. Specify -losthr on the link line to supply the proper library for real thread support. The libosths library, a stub threads library, can also be used with Solaris 2.x systems. Using this library can result in higher performance in some circumstances because it turns off thread locking.

Debugging with DBX

Solaris 2 Linking

• Use the libosthr library in linking an application that links with
  -mt (or -lthread).
• Use the libosths library in linking an application that does not link with -mt (or -lthread).

On Solaris 2.x, you must always specify the -mt compiler option on the CC command line. This is required for a successful compilation.

Linking with threads

CC -mt -I$(OS_ROOTDIR)/include $(CCFLAGS) -o foo 
            -L$(OS_ROOTDIR)/lib -los -losthr 

• Use -mt (or -lthread) on the link line.
• Link with libosthr.

CC -I$(OS_ROOTDIR)/include $(CCFLAGS) -o foo 
            -L$(OS_ROOTDIR)/lib -los -losths

• Do not use -mt on the link line.
• Do not explicitly place -lthread in the link line.
• Link with libosths.

In an ObjectStore makefile, in the LDLIBS line, you must specify each library with which you are linking.

Then, in the line of the makefile where ossg generates the application schema, you must specify the library schemas needed by your application schema. For each library schema that you specify in the ossg command line, you must specify the corresponding library in the LDLIBS line.

Note that the reverse is not true. For each library that you specify in the LDLIBS line, you do not necessarily specify a library schema in the ossg command line. This is because every library does not necessarily have a library schema. Only those libraries that store or retrieve persistent data have associated library schemas.

OS_POSTLINK and os_postlink

Tabs and spaces

Application schema database

Makefile template

include $(OS_ROOTDIR)/etc/ostore.lib.mk
APPLICATION_SCHEMA_PATH= app-schema-db 
LDLIBS = $(OS_EXPORT) -losqry -loscol -los -losths [ other libraries]
SOURCES = .cc  files 
OBJECTS = .o  files 
EXECUTABLES =  executables 
CCC=CC 
all: ${EXECUTABLES}
executable: $(OBJECTS) os_schema.o
      $(CCC) -o executable $(OBJECTS) os_schema.o \
            $(LDLIBS)
       $(OS_POSTLINK) executable
.o  files: .cc f iles 
      ${CCC} $(CPPFLAGS) -c .cc  files 
os_schema.o: os_schema.cc
      $(CCC) $(CPPFLAGS) -c os_schema.cc
os_schema.cc: schema.cc

      ossg -assf os_schema.cc -asdb $(APPLICATION_SCHEMA_
PATH) \
            $(CPPFLAGS) schema.cc $(OS_ROOTDIR)/lib/libosqry.ldb \
            $(OS_ROOTDIR)/lib/liboscol.ldb
clean:
      osrm -f ${APPLICATION_SCHEMA_PATH}
      rm -f ${EXECUTABLES} ${OBJECTS} os_schema.* 

These handlers are critical to ObjectStore's operation. If your application disturbs them, it will fail, and it might fail in a way that makes it difficult to determine why it failed.

If you must temporarily change the state of the handler for SIGSEGV and SIGBUS, be sure to save and restore the complete state. You cannot do this with the signal entry point; you must call sigaction and save the contents of the structure returned as the old handler state.

Makefile for Building from Compilation Schemas

all: my_exec
my_exec: main.o os_schema.o foo.o bar.o
      CC -o my_exec main.o os_schema.o foo.o bar.o -los
      $(OS_POSTLINK) my_exec
my_exec.cdb:: schema_source1.o
      ossg -csdb my_exec.cdb $(CPPFLAGS) schema_source1.cc
      touch schema_source1.o
my_exec.cdb:: schema_source2.o
      ossg -csdb my_exec.cdb $(CPPFLAGS) schema_source2.cc
      touch schema_source2.o
os_schema.cc: my_exec.cdb
      ossg -asdb my_exec.adb -assf os_schema.cc my_exec.cdb

Establishing Fault Handlers in POSIX Thread Environments

ObjectStore provides two macros to help you do this:

• OS_ESTABLISH_FAULT_HANDLER establishes the start of the fault handler block.
• OS_END_FAULT_HANDLER ends the fault handler block.

A typical function that uses these macros in an ObjectStore application would look like this:

void thread_1(  ) {
      OS_ESTABLISH_FAULT_HANDLER
      ... your code...
      OS_END_FAULT_HANDLER
return  value;
}

You can benefit from using these macros, even on platforms not requiring them. This practice helps ensure portability of code, and also guards against potential problems resulting from future changes to your operating system.

Virtual Function Table Pointers

When ObjectStore is fully initialized, it examines each of the shared libraries specified at link time that was opened by shl_load or cxxshl_load. ObjectStore searches the shared libraries for the symbols that identify the tables in the schema object file. After it finds these symbols, it searches again to find as many vtbls and discriminants as it can.

Debugging Applications

SGI IRIX

HP-UX

z 10 irs
z 11 irs

ignore 10
ignore 11

ignore SEGV

Solaris C++ Search Paths

/usr/include/stddef.h line 30: syntax error on input" (103)

Windows

Note that you must use the 32-bit edition of Visual C++.

Linking with ObjectStore Libraries

On Windows platforms, the only ObjectStore library is ostore.lib. You must link with this library every time you build an ObjectStore application.

Use Custom Build to Run ossg

How to customize Visual C++

Ensure That You Include Required Files

If you edit your environment to remove %OS_ROOTDIR%\include from your INCLUDE environment variable, you must add the following argument to your compilation and ossg commands.

-I%OS_ROOTDIR%\include

Make and Compiler Options

mycode.obj: mycode.cpp 
      cl -c -W3 -EHa -G4 -D_X86_=1 -DWIN32 -MD -Zi -vmg -vmv\
      I$(OS_ROOTDIR)\include mycode.cpp

The option -MD is required in order for you to use msvcrt.lib, which is required by ObjectStore.

The implementation of TIX exceptions depends on C++ exceptions. All ObjectStore modules should be compiled with the /EHa option. ObjectStore header files that rely on C++ exception handling use a pragma statement to ensure that /EHa is used. If you do not specify /EHa when you compile files that use those headers, you receive an error such as

osdraw.cpp(168) : error C4530: C++ exception handler used, but unwind 
semantics are not enabled. Specify -EHa 

The option -Zi causes debugging information to be put in the project database. You can also use the -Z7 or -Zd option.

All compiler and linker options not mentioned explicitly can be set as you want.

Use the Standard Run-Time Library on Windows NT

Run-time libraries

ObjectStore is linked with msvcrt.lib, which allows ObjectStore to freely allocate objects in any ObjectStore DLL and deallocate them in any other ObjectStore DLL. This is because all ObjectStore DLLs share the single allocator in MSVCRT40.DLL.

Because ObjectStore is linked with msvcrt.lib, it is easy for most applications that also link with msvcrt.lib to deallocate objects that are allocated by ObjectStore APIs (for example, os_collection::query()).

Compiling DLLs

You can use a library DLL that is not compiled with the -MD option. Keep in mind that it has a separate copy of the C run-time library and therefore you cannot share certain objects between that DLL and the rest of the application.

Compiling DLLs without msvcrt.lib

If you must link with LIBC.LIB or LIBCMT.LIB, you can do one of two things:

• Ask the vendor of the software that uses LIBC.LIB or LIBCMT.LIB to use msvcrt.lib instead. You cannot design an application as a set of cooperating DLLs if the vendor does not support msvcrt.lib. For example, if you want to use something that needs to share C run-time objects but was not compiled with the -MD option, you need to contact that vendor.
• Encapsulate all code that uses ObjectStore in one or more DLLs. In other words, instead of directly calling ObjectStore APIs like os_database::open() from the executable, call your own OpenOSDatabase() function that is in a DLL that was linked with msvcrt.lib. You can then link the executable with LIBC.LIB or LIBCMT.LIB. You must ensure that any objects passed between the executable and the DLL are deallocated by the correct allocator.

Required

• You must link ObjectStore applications with the library ostore.lib. To do so you can either add %OS_ROOTDIR%\lib to your LIB environment variable and put ostore.lib on the link command line, or you can put %OS_ROOTDIR%\lib\ostore.lib on the link command line. The reference to ostore.lib can be anywhere on the link command line as long as it appears before any explicit references to msvcrt.lib (the C run-time library). If you are using MFC, see Building ObjectStore/Microsoft Foundation Class Applications.

• You must link with msvcrt.lib. This is the C run-time library with which all ObjectStore DLLs and executables are linked.

Linking an executable file would look like this:

link @<< 
-NODEFAULTLIB -machine:i386 -subsystem:windows -debug 

-debug-type:cv -out:myapp.exe myapp.obj myschema.obj ostore.lib 
msvcrt.lib kernel32.lib user32.lib gdi32.lib winspool.lib 
<<

link @<< 
-NODEFAULTLIB -dll -machine:i386 -debug -debugtype:cv 
-out:myapp.dll myapp.obj myschema.obj ostore.lib msvcrt.lib
kernel32.lib user32.lib gdi32.lib winspool.lib 
<<

In both examples, the %OS_ROOTDIR%\lib directory must be listed in your LIB environment variable. This is normally set up by the ObjectStore installation program.

Sample Makefile

The schema generator (ossg) is a C++ compiler front end that parses C++ source code to obtain information. This means that you must pass the same compiler flags to ossg as you pass to the compiler when you are compiling your source. It is especially important to duplicate the -I, -D, and -Zp arguments. Also, remember that -MD implies -D_DLL, so pass the -D_DLL to ossg. Note how $(COMPILER_OPTS) is used for both compilation and schema generation in the following makefile fragment.

!include $(OS_ROOTDIR)\etc\ostore.mak
OBJECTS=note.obj
EXECUTABLES=note.exe
APPLICATION_SCHEMA_PATH=note.adb
all: $(EXECUTABLES)
myschema.obj: schema.cc
      ossg -asof myschema.obj -asdb $(APPLICATION_SCHEMA_
PATH) \
            $(COMPILER_OPTS) schema.cc 
note.obj: note.cc
      $(COMPILER) $(COMPILER_OPTS) note.cc
note.exe: $(OBJECTS) myschema.obj
      $(CL_LINK) /OUT:note.exe $(OBJECTS) myschema.obj \
            $(OS_ROOTDIR)\lib\ostore.lib
clean:
      -osrm -f $(APPLICATION_SCHEMA_PATH)
      -del $(OBJECTS) osschema.*

Sample file

!include $(OS_ROOTDIR)\etc\ostore.mak
OBJECTS=note.obj
EXECUTABLES=note.exe
APPLICATION_SCHEMA_PATH=note.adb
all: $(EXECUTABLES)
myschema.obj: schema.cc
      ossg -asof myschema.obj -asdb $(APPLICATION_SCHEMA_
PATH) \
            $(COMPILER_OPTS) schema.cc \            $(OS_
ROOTDIR)\lib\osquery.ldb \1
            $(OS_ROOTDIR)\lib\os_coll.ldb2
note.obj: note.cc
      $(COMPILER) $(COMPILER_OPTS) note.cc
note.exe: $(OBJECTS) myschema.obj
      $(CL_LINK) /OUT:note.exe $(OBJECTS) myschema.obj \
            $(OS_ROOTDIR)\lib\ostore.lib
clean:
      -osrm -f $(APPLICATION_SCHEMA_PATH)
      -del $(OBJECTS) osschema.*

²Add collections library schema.

Specifying Environment Variables

You can edit these environment variables using the Control Panel System applet.

On Windows NT, ObjectStore adds these variables to the system environment.

Debugging Your Application

First-Chance Exception in  yourprog.exe: 0xC0000005: Access Violation.
First-Chance Exception in  yourprog.exe: ( something.DLL) 0xC0000005: 
Access Violation.

Under Debug | Exceptions, the default for exception C0000005 Access Violation is Stop if not handled. Do not change this to Stop Always. If you do, ObjectStore cannot function normally.

Obtaining a stack trace

The debug DLLs are available on the distribution CDROM.

To obtain a back trace using the debug DLLs, put the debug DLL directory in the front of the path environment and then run the msvc debugger.

For example, using myapps on drive C and a CDROM on drive E, you would issue the following commands:

C:\myapps> set path = e:\windows\debnt\bin;%path%
C:\myapps> start msvc myapps.exe

Abnormal Application Exit

• Set the environment variable OS_DEF_BREAK_ACTION. See ObjectStore Management, Chapter 3, Environment Variables.
• Include code in your program that uses the static method for the class tix_exception called set_unhandled_exception_hook(); see %OS_ROOTDIR%\include\ostore\tix.hh.

#include <iostream.h>
#include <ostore/ostore.hh>
void break_hook(tix_exception *err, os_int32, char* message){
cout << "Set break point here" << endl;
cout << "Have a look at the stack " << endl;
// You may also want to put up a message box that displays
// the contents of the message parameter.
}
main(int argc, char *argv[])
{      OS_ESTABLISH_FAULT_HANDLER
      os_database *db1;
      objectstore::initialize();
      tix_exception::set_unhandled_exception_hook(break_hook);
      do_something_fun();
      OS_END_FAULT_HANDLER
}

1. Putting OS_ESTABLISH_FAULT_HANDLER and objectstore::initialize code in WinMain.
   
   
2. Putting OS_ESTABLISH_FAULT_HANDLER in threads created with CWinThread::CreateThread.
   
   
3. Integrating ObjectStore's overloading of operator new and delete with MFC's DEBUG_NEW macro.
   
   
4. Adding knowledge of nonmapped persistent pointers to MFC's valid-address checking.
   
   
5. Adding support for persistent new of MFC types.
   
   

Issue 1

Issue 2

Issue 3

To do this, add the following to stdafx.h after including ostore.hh and afxwin.h:

// If we let DEBUG_NEW keep the definition that it's given in 
// afxwin.h, 
// and let the "#define new DEBUG_NEW" from afx.h stay, then our
// overloadings of new won't be recognized by the compiler.
      #ifndef _AFX_NO_DEBUG_CRT
      #ifdef DEBUG_NEW
      #undef DEBUG_NEW
      #define DEBUG_NEW new
      #endif
      #ifdef new
      #undef new
      #define new new
      #endif
      #endif

// This declaration taken from ostore.h */
extern "C" void _OSSYSCALL objectstore_delete(void *);
// In DEBUG mode, MFC has its own operator delete. We need to get
// first dibs on the deletion if the thing being deleted is persistent.
//
#if defined(_DEBUG) && !defined(_AFX_NO_DEBUG_CRT)
inline void operator delete(void* p)
      {
      objectstore_delete(p);
}
      #endif

Issue 5

Class os_CString

Class os_CString has the same layout and member functions, but it includes get_os_typespec() members and cast-to-CString members. This means that users can easily pass them from the database to MFC and back. To use os_CString, include <ostore/oscstring.h> in your source code.

You can find the source code for os_CString in the directory %OS_ROOTDIR%\examples\ospmfc.

Generating MFC Applications Using ObjectStore AppWizards

When an application is generated with this wizard, all the code needed for ObjectStore is inserted into your project. The following is what is inserted in addition to standard code provided by VC++:

• Copy of AfxWinMain() that establishes ObjectStore fault handling and calls initialization functions
• Code to stdafx.h that includes ObjectStore header files and ensures that the correct operator new is called
• Skeleton for ObjectStore schema in schema.scm file
• ObjectStore headers and libraries that are added to the makefile

• INCLUDE must include %OS_ROOTDIR%\INCLUDE.
• LIB must include %OS_ROOTDIR%\LIB.

The source code for the ObjectStore AppWizard can be found in the directory %OS_ROOTDIR%\examples\ostoreaw.

Using the AppWizard

1. Start Microsoft Developer Studio.
   
   
2. In the File menu, select New.
   
   
3. From the dialog box displayed, select the Projects tab and select ObjectStore AppWizard.
   
   
4. Enter the project name and click OK.
   
   
5. In these steps, select the MFC-specific options you prefer.
   
   
6. Check Use ObjectStore Collections if you want your application to use ObjectStore collections. This will include collections-related files and initialize ObjectStore collections at the right place.
   
   
7. Click on Finish to generate a project with correct ObjectStore include files and initializations.
   
   

Manual steps

You must add OS_ESTABLISH_FAULT_HANDLER to the top-level threads functions when using threads.

Using the Visual C++ Integrated Development Environment (IDE)

1. Choose a file name extension for your schema source file other than .cpp, for example, .osg.
   
   
2. Set up a Custom Build rule that specifies that the schema object file is to be built from the schema source file, by using the command
   
   

      ossg < other ossg args> schema.osg

Using ObjectStore Within a DLL

In the directory %OS_ROOTDIR%\examples\dll, there are two subdirectories, LIBSCHM and NOSCHM. These two directories demonstrate two ways to use ObjectStore from within a DLL.

Each of these two directories contains two subdirectories, PROG and LIB. The LIB directory creates a DLL called people.dll that uses ObjectStore. The PROG directory creates a program that uses people.dll.

The difference between the directories LIBSCHM and NOSCHM is as follows:

• The directory LIBSCHM\LIB creates a DLL that uses ObjectStore and a library schema to go with the DLL. The directory LIBSCHM\PROG uses the library schema in addition to its own schema sources to create an application schema.
• The directory NOSCHM is an example of how you create a DLL that uses ObjectStore but is to be linked with programs that are not using ObjectStore. The objective is to avoid concern with schema generation and linking rules in the application makefiles.

Building Applications on Machines Remote from the Server

All databases, including application schemas and library schemas, must physically reside on the same machine as the Server. The schema generator expects to be able to connect to a Server and produces an error message if it cannot do so. Consequently, you must provide the schema generator with a Server-relative pathname. There are two ways to do this.

You can specify ObjectStore Server-relative pathnames even if you are not using NFS or another file-sharing option. This does not rely on any file system protocol. Instead, this syntax is recognized by ObjectStore tools. Using Server-relative pathnames, the ossg command line would look like this:

Example 1

ossg -asdb foo:c:\appdir\appschema.adb -assf osschema.cc /
      -cd schmdefs.hh myschema foo:c:\ostore\lib\os_coll.ldb

• The Server is on a remote machine named foo.
• There is a directory on foo's C drive called appdir.
• ObjectStore is installed on foo's C drive in the ostore directory.

If you can use Windows networking to connect to a network drive on the Server, you can use pathnames that start with that network drive letter.

Example 2

nfs use x: bar:/usr

ossg -asdb x:\appdir\appschema.adb -assf osschema.cc \
      -cd schmdefs.hh myschema.cc x:\ostore\lib\os_coll.ldb \
      x:\ostore\lib\os_query.ldb

• The Server is on a remote machine named bar.
• The application is in /usr/appdir on bar.
• ObjectStore is installed in /usr/ostore on bar.

Macros for fault and exception handling

Therefore, every ObjectStore application must put a handler for access violations at the top of every stack in the program. This normally means putting a handler in a program's main or WinMain function and, if the program uses multiple threads, putting a handler in the first function of each new thread.

ObjectStore provides two macros to use in establishing a fault handler:

• OS_ESTABLISH_FAULT_HANDLER establishes the start of the fault handler block.
• OS_END_FAULT_HANDLER ends the fault handler block.

int main (int argc, char** argv) {
      OS_ESTABLISH_FAULT_HANDLER
      ... your code...
      OS_END_FAULT_HANDLER
return  value;
}

Threads

objectstore::initialize() need only be called once, even though an application has multiple threads.

long double and warning C4069

c:\ostore\include\ostore\mop.hh(1041) : warning C4069: long double is 
the same precision as double

#pragma warning ( default : 4069 )

Windows DEBUG and DDEBUG Builds of ObjectStore

debug

ddebug

Installing DEBUG.ZIP or DDEBUG.ZIP

1. Install ObjectStore Release 5.1 with the SETUP program. See ObjectStore installation for Windows NT documentation for instructions.
   
   
2. Shut down the ObjectStore Server and Cache Manager by using the ObjectStore SETUP program. Answer Yes to the question about shutting down servers, then exit from SETUP.
   
   
3. Go to the %OS_ROOTDIR% directory.
   
   
4. Rename bin and binsngl directories (from the command prompt window or Windows Explorer) to retail.bin and retail.binsngl.
   
   
5. Unzip the file (DEBUG.ZIP or DDEBUG.ZIP) from the command prompt by typing the following command.The -d option creates and restores the directories included in the zip file.
   
   

         pkunzip -d debug.zip 
   

6. Run the ObjectStore SETUP program to start the Server. In the first setup dialog, select the Setup Server option. In the menu Choosing to start ObjectStore services automatically, select Yes. Then a Confirm Message dialog asks if you want to start the services right now. Select Yes.
   
   

To use the ddebug build, install the ddebug libraries as directed in Installing DEBUG.ZIP or DDEBUG.ZIP. Then compile your application using the /MDd switch. Using Project | Settings in Developer Studio, select C/C++, Category Code Generation, Use runtime library Debug Multithreaded DLL. This automatically selects ostored.lib as a default library. To run the resulting application, ensure that the ddebug build is in your PATH.

The following table compares the features of retail ObjectStore, debug, and ddebug:

Characteristic	Retail	debug	ddebug
Installation with INSTALL?	Yes	No	No
Optimized?	Yes	No	Yes
ObjectStore symbols available?	No	Yes	Yes
Drop-in capability?	Yes	Yes	No

Compiling and linking applications

* The /MDd option defines the symbol _DEBUG, which determines the link library used by ObjectStore.

OS/2

Using Compiler Options

Prohibited

You cannot use these compiler options when compiling code that includes ObjectStore header files:

/EHa	No exception support
/H	Short external names
/Ms	Use _System calling sequence
/Sc	Use cfront language standard
/Sg	Set margins
/Sp	Pack structures
/Sq	Use sequence numbers

Specifying default language for files

No rules

Note: Previous releases of ObjectStore on OS/2 required the /Su4 compiler option. While it is not required for ObjectStore Release 5.1 applications, you must continue to specify it if you want your application to be compatible with databases that were created with ObjectStore Release 3. The /Su4 option is required for compatibility whether or not you upgraded your databases to be ObjectStore Release 5.1 databases. An alternative to specifying this option is to perform schema evolution on the existing databases.

Linking Your Files

Required library

The reference to ostore.lib can be anywhere on the link command line as long as it appears before any explicit references to CPPOM30I.LIB (the C++ run-time library).

You must call the function objectstore::initialize() before calling any other ObjectStore interface function.

Case sensitivity

Compiling the application schema source file

icc /C /Gd /Gm myschema.cpp

Linking object files into an executable

icc /Tdp /B"STACK:32768" /Femy_exec.exe myschema.obj \ my_
ob1.obj my_ob2.obj %OS_ROOTDIR%\lib\ostore.lib 

myschema.obj: myschema.cpp
      ossg -assf myschema.cpp -cd schmdefs.hh -asdb 
myschema.adb \
            myschema $(OS_ROOTDIR)\lib\os_coll.ldb
      icc /C /Gd /Gm myschema.cpp
my_exec.exe: my_exec.obj myschema.obj 
      icc /Tdp /B"STACK:32768" /Femy_exec.exe my_exec.obj \
            myschema.obj $(OS_ROOTDIR)\lib\ostore.lib 

OBJECTS=note.obj
EXECUTABLES=note.exe
APPLICATION_SCHEMA_PATH=note.adb
all: $(EXECUTABLES)
myschema.obj: myschema.cc
      icc /C /Gd /Gm /Ti myschema.cc
myschema.cc: schema.cc
      ossg -assf myschema.cc -cd schmdefs.hh \
            -asdb $(APPLICATION_SCHEMA_PATH) \
            $(CPPFLAGS) schema.cc 
note.obj: note.cc
      icc /C /Gd /Gm /Ti note.cc
note.exe: $(OBJECTS) myschema.obj
      icc /Tdp /B"STACK:32768" /Fenote.exe $(OBJECTS) 
myschema.obj \
      $(OS_ROOTDIR)\lib\ostore.lib
clean:
      -osrm -f $(APPLICATION_SCHEMA_PATH)
      -del $(OBJECTS) osschema.*

OBJECTS=note.obj
EXECUTABLES=note.exe
APPLICATION_SCHEMA_PATH=note.adb
all: $(EXECUTABLES)
myschema.obj: myschema.cc
      icc /C /Gd /Gm /Ti myschema.cc
myschema.cc: schema.cc
      ossg -assf myschema.cc -cd schmdefs.hh \
            -asdb $(APPLICATION_SCHEMA_PATH) \
            $(CPPFLAGS) schema.cc \

            $(OS_ROOTDIR)\lib\osquery.ldb \
            $(OS_ROOTDIR)\lib\os_coll.ldb
note.obj: note.cc
      icc /C /Gd /Gm /Ti note.cc
note.exe: $(OBJECTS) myschema.obj
      icc /Tdp /B"STACK:32768" /Fenote.exe $(OBJECTS) 
myschema.obj \
      $(OS_ROOTDIR)\lib\ostore.lib
clean:
      -osrm -f $(APPLICATION_SCHEMA_PATH)
      -del $(OBJECTS) osschema.*

You can do this by using the OS/2 environment variable PMDEXCEPT. When this environment variable is set to 1, the debugger unconditionally passes ObjectStore exceptions to ObjectStore.

However, if your application fails with a general protection fault, setting PMDEXCEPT causes the program to exit before you can debug the error.

If you need to debug this kind of problem, set a breakpoint on the first instruction in O4LOW.DLL. This breakpoint occurs only if there is a general protection fault that ObjectStore declines to handle (such as dereferencing a null pointer).

Obtaining a stack trace

To obtain a back trace using the debug DLLs, put the debug DLL directory in the front of the LIBPATH environment, reboot, and then run the IPMD debugger.

Pass Source Files to ossg

Building Applications on Machines Remote from the Server

All databases, including application schemas and library schemas, must physically reside on the same machine as the Server. The schema generator expects to be able to connect to a Server and produces an error message if it cannot do so. Consequently, you must provide the schema generator with a Server-relative pathname. There are two ways to do this.

You can specify ObjectStore Server-relative pathnames even if you are not using NFS or another file sharing option. This does not rely on any file system protocol. Instead, this syntax is recognized by ObjectStore tools. Using Server-relative pathnames, the ossg command line would look like this:

Example 1

ossg -asdb foo:c:\appdir\appschema.adb -assf osschema.cc /
      -cd schmdefs.hh myschema foo:c:\ostore\lib\os_coll.ldb

• The Server is on a remote machine named foo.
• There is a directory on foo's C drive called appdir.
• ObjectStore is installed on foo's C drive in the ostore directory.

Example 2

mount x: foo:c:\

ossg -asdb x:\appdir\appschema.adb -assf osschema.cc \
      -cd schmdefs.hh myschema.cc x:\ostore\lib\os_coll.ldb \
      x:\ostore\lib\os_query.ldb

Updated: 03/26/98 19:59:13