/*
 *
 * DISCLAIMER OF WARRANTIES.
 * The following [enclosed] code is sample code created by IBM
 * Corporation and ported to Win32 by Zephyr Technologies, Inc. This
 * sample code is not part of any standard or IBM
 * product and is provided to you solely for the purpose of assisting
 * you in the development of your applications.  The code is provided
 * "AS IS". IBM MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
 * NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
 * FOR A PARTICULAR PURPOSE, REGARDING THE FUNCTION OR PERFORMANCE OF
 * THIS CODE.  IBM shall not be liable for any damages arising out of
 * your use of the sample code, even if they have been advised of the
 * possibility of such damages.
 *
 * DISTRIBUTION.
 * This sample code can be freely distributed, copied, altered, and
 * incorporated into other software, provided that it bears the above
 * Copyright notice and DISCLAIMER intact.
 */


      *** IMPORTANT: YOU MUST READ AND FOLLOW THE DIRECTIONS IN  ***
      *** THIS FILE IN ORDER TO CORRECTLY BUILD AND RUN THE DSOM ***
      *** SAMPLES.                                               ***


PREPARING TO BUILD AND RUN THE DSOM CPP SAMPLES
===============================================

These samples require that you have already set up the SOM environment
variables using somenv.bat.  In addition, you must set up some DSOM
variables - or at least verify that they have been set.

These are as follows (you can use somdenv.bat, or you can add it to 
somenv.bat.)

somdenv.bat contains lines like:

  set SOMDDIR=<directory for your implementation registry>

  set HOSTNAME=localhost
  set USERNAME=<your_name>

You should edit it to add your computer to the USER name.

The SOMIR variable should include som.ir in the current directory in its
list of IR files.

The samples in the "cpp" subdirectory also require the strict CORBA-
compliant C bindings and SMADDSTAR to be undefined.  In addition,
they require that you have built the C++ .xh files.  These files are
produced by running the "somxh" command.


BUILDING A DSOM SAMPLE
======================

Makefiles are provided in each sample subdirectory.  Enter 
"nmake -f makefile.msc all" to compile all necessary IDL files, update
the Implementation Repository and build all necessary dlls and
executables.

RUNNING A DSOM SAMPLE
=====================

To run a sample, you must first start the DSOM daemon, "somdd".
Because the samples build DSOM servers, dynamically loadable libraries,
and Interface Repository data into the current directory (rather than
into common directories), you must start somdd (and any DSOM servers 
required by the sample) from the directory in which the sample was built.

As you move from one DSOM sample to the next, you must terminate the DSOM
daemon and the DSOM servers that are running for the first sample and restart
them from the next sample's directory.  Refer to "Cleaning Up After Running a
DSOM Sample" below.

Review the README files in the sample subdirectories for additional
instructions.


CLEANING UP AFTER RUNNING A DSOM SAMPLE
=======================================

The DSOM servers and DSOM daemon can be stopped by pressing Ctrl+C or
selecting "End Task" after selecting that task from the task list.

Enter "nmake -f makefile.msc clean" to clean up a sample directory. 


OVERVIEW OF DSOM CPP SAMPLES
============================

The cpp/animal.gui subdirectories contain the source for:

  testsvr - a simple generic server which uses the SOM Object Adapter
            to automatically load class libraries and execute requests
            on objects instantiated in the server

  anitest - a sample client program which uses static bindings to invoke
            methods on remote objects

The cpp/dii.gui subdirectories contain the source for:

  diitest - a sample client program which uses the Dynamic Invocation
            Interface (DII) to invoke a method on a remote object


The cpp/event.gui subdirectories contains the source for

  eventsvr - a server which supports the class libraries - cell, eventch and
             eventcomm and in which remote instances of these classes reside.

  eventcli - client program which invokes methods on the remote "cell" class
             instance

  consumer - a second client program which invokes methods on a remote "event
             channel" instance to pull events from the channel.

The cpp/stack.gui subdirectories contains the source for:

  client  - a sample client program which uses a simple Stack
            class implementation. The client program is the same one
            explained in the SOMobjects Developer Toolkit Users Guide
            (Chapter 6)

