ChangeLogTag:Sun Nov 11 11:40:23 2001 Balachandran Natarajan <bala@cs.wustl.edu>

1 files changed, 325 insertions, 324 deletions

diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html
index 0e8389327ff..989709bf42b 100644
--- a/TAO/docs/Options.html
+++ b/TAO/docs/Options.html
@@ -22,7 +22,7 @@ providing value for options or environment variables to them.  These
 options are commonly specified as (1) environment variables or (2)
 strings passed on the command-line.  Command-line options and
 environment variables to control global ORB features, such as the IOR
-format or ORB's bootstrapping methods.  They are generally passed to
+format or ORB's bootstrapping methods.	They are generally passed to
 component initialization methods for consumption. <P>
 
 In addition, options in <code>svc.conf</code> file provide a mechanism
@@ -53,40 +53,40 @@ The following environment variables are supported by TAO:
   <TR>
     <TD><CODE>NameServiceIOR</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies which IOR the Naming Service is listening on.
+	Specifies which IOR the Naming Service is listening on.
     </TD>
   </TR>
   <TR>
     <TD><CODE>NameServicePort</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies which port the Naming Service is listening on for multicast
-        requests.
+	Specifies which port the Naming Service is listening on for multicast
+	requests.
     </TD>
   </TR>
   <TR>
     <TD><CODE>TradingServiceIOR</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies which IOR the Trading Service is listening on.
+	Specifies which IOR the Trading Service is listening on.
     </TD>
   </TR>
   <TR>
     <TD><CODE>TradingServicePort</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies which port the Trading Service is listening on for multicast
-        requests.
+	Specifies which port the Trading Service is listening on for multicast
+	requests.
     </TD>
   </TR>
   <TR>
     <TD><CODE>ImplRepoServiceIOR</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies the IOR of an Implementation Repository.
+	Specifies the IOR of an Implementation Repository.
     </TD>
   </TR>
   <TR>
     <TD><CODE>ImplRepoServicePort</CODE> <EM>which</EM></TD>
     <TD>
-        Specifies which port the Implementation Repository is listening on for
-        multicast requests.
+	Specifies which port the Implementation Repository is listening on for
+	multicast requests.
     </TD>
   </TR>
 </TABLE>
@@ -111,7 +111,7 @@ mentioned above:</P>
   <LI><A HREF="#RT_ORB_Loader"><CODE>RT_ORB_Loader</CODE></A>
 </UL>
 
-The details of the options are mentioned below. 
+The details of the options are mentioned below.
 </blockquote>
 
 
@@ -134,9 +134,9 @@ merged with <a href="#-ORBCollocation"><code>-ORBCollocation</code></a>.
   <tr>
     <TD><CODE><A NAME="-ORBSvcConf">-ORBSvcConf</A></CODE> <EM>config filename</EM></TD>
     <TD>Specifies the name of the file from which it will read dynamic service configuration
-        directives <EM>ala</EM> ACE's Service Configurator. By
-        default, a service configurator-based application will look
-        for a file named "svc.conf" in the current directory.</TD>
+	directives <EM>ala</EM> ACE's Service Configurator. By
+	default, a service configurator-based application will look
+	for a file named "svc.conf" in the current directory.</TD>
   </TR>
   <!-- <TR NAME="ORBsvcconf"> -->
   <tr>
@@ -148,7 +148,7 @@ merged with <a href="#-ORBCollocation"><code>-ORBCollocation</code></a>.
     NAME="-ORBServiceConfigLoggerKey">-ORBServiceConfigLoggerKey</A></CODE>
     <EM>logger key</EM></TD>
     <TD>Set the logger key in the <CODE>ACE_Service_Config</CODE>
-    framework.  Equivalent to the <CODE>-k</CODE> option on the ACE
+    framework.	Equivalent to the <CODE>-k</CODE> option on the ACE
     service configurator class.
     </TD>
   </TR>
@@ -159,152 +159,152 @@ merged with <a href="#-ORBCollocation"><code>-ORBCollocation</code></a>.
   <TR>
     <TD><CODE>-ORBDebug</CODE></TD>
     <TD>Turns on the output of debugging messages within ACE's Service Configurator
-        componentry.</TD>
+	componentry.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBDebugLevel</CODE> <EM>level</EM></TD>
     <TD>Control the level of debugging in the ORB. Higher number produce
-        more output (try 10).
+	more output (try 10).
     </TD>
   </TR>
   <TR>
     <TD><CODE><A HREF="ORBEndpoint.html">-ORBEndpoint</A></CODE>
-              <EM>endpoint</EM></TD>
+	      <EM>endpoint</EM></TD>
     <TD><a name="-ORBEndpoint"></a>Tells the ORB to listen for requests on the
-        interface specified by <I><EM>endpoint</EM></I>.  Endpoints are
-        specified using a URL style format.  An endpoint has the form:
-        <blockquote><CODE>
-        protocol://V.v@addr1,...,W.w@addrN
-        </CODE></blockquote>
-        where <CODE>V.v</CODE> and <CODE>W.w</CODE> are optional protcol versions for
-        each address.  An example of an IIOP endpoint is:
-        <blockquote><CODE>
-        iiop://<I><EM>hostname</EM></I>:<I><EM>port</EM></I>
-        </CODE></blockquote>
-        Sets of endpoints may be specified using multiple <CODE>-ORBEndpoint</CODE>
-        options or by delimiting endpoints with a semi-colon (;).  For example,
-        <blockquote><CODE>
-        -ORBEndpoint iiop://localhost:9999 -ORBEndpoint uiop:///tmp/mylocalsock -ORBEndpoint shmiop://10002
-        </CODE></blockquote>
-        is equivalent to:
-        <blockquote><CODE>
-        -ORBEndpoint 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002'
-        </CODE></blockquote>
-        Notice the single quotes (') in the latter option specification.  Single
-        quotes are needed to prevent the shell from interpreting text after the
-        semi-colon as another command to run.<P>
-        If an endpoint is specified without an <CODE>addr</CODE> such as the following:
-        <blockquote><CODE>
-        -ORBEndpoint uiop:// -ORBEndpoint shmiop://
-        </CODE></blockquote>
-        then a default endpoint will be created for the specified protocol.
-        <P>
-        This is a server side option.
+	interface specified by <I><EM>endpoint</EM></I>.  Endpoints are
+	specified using a URL style format.  An endpoint has the form:
+	<blockquote><CODE>
+	protocol://V.v@addr1,...,W.w@addrN
+	</CODE></blockquote>
+	where <CODE>V.v</CODE> and <CODE>W.w</CODE> are optional protcol versions for
+	each address.  An example of an IIOP endpoint is:
+	<blockquote><CODE>
+	iiop://<I><EM>hostname</EM></I>:<I><EM>port</EM></I>
+	</CODE></blockquote>
+	Sets of endpoints may be specified using multiple <CODE>-ORBEndpoint</CODE>
+	options or by delimiting endpoints with a semi-colon (;).  For example,
+	<blockquote><CODE>
+	-ORBEndpoint iiop://localhost:9999 -ORBEndpoint uiop:///tmp/mylocalsock -ORBEndpoint shmiop://10002
+	</CODE></blockquote>
+	is equivalent to:
+	<blockquote><CODE>
+	-ORBEndpoint 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002'
+	</CODE></blockquote>
+	Notice the single quotes (') in the latter option specification.  Single
+	quotes are needed to prevent the shell from interpreting text after the
+	semi-colon as another command to run.<P>
+	If an endpoint is specified without an <CODE>addr</CODE> such as the following:
+	<blockquote><CODE>
+	-ORBEndpoint uiop:// -ORBEndpoint shmiop://
+	</CODE></blockquote>
+	then a default endpoint will be created for the specified protocol.
+	<P>
+	This is a server side option.
     </TD>
   </TR>
 
   <TR>
     <TD><CODE>-ORBObjRefStyle</CODE> <EM>which</EM></TD>
     <TD>Specifies the user-visible style of object references. The range of values
-        is <CODE>IOR</CODE> (default), which is the traditional nonsensical object reference,
-        or <CODE>URL</CODE>, which looks more like a URL.</TD>
+	is <CODE>IOR</CODE> (default), which is the traditional nonsensical object reference,
+	or <CODE>URL</CODE>, which looks more like a URL.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBRcvSock</CODE> <EM>receive buffer size</EM></TD>
     <TD><A NAME="-ORBRcvSock"></a>Specify the size of the socket receive buffer as a positive, non-zero integer.
-        If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD>
+	If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBSndSock</CODE> <EM>send buffer size</EM></TD>
     <TD><A NAME="-ORBSndSock"></a>Specify the size of the socket send buffer as a positive, non-zero integer.
-        If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD>
+	If not specified, the ACE_DEFAULT_MAX_SOCKET_BUFSIZ default is used.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBNodelay</CODE> <EM>boolean (0|1)</EM></TD>
     <TD><A NAME="-ORBNodelay"></a>Enable or disable the TCP_NODELAY
-        option. By default, TCP_NODELAY is enabled.</TD>
+	option. By default, TCP_NODELAY is enabled.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBNameServicePort</CODE> <EM>portspec</EM></TD>
     <TD>Specifies which port the Naming Service is listening on for
-        multicast requests. By default,
-        TAO_DEFAULT_NAME_SERVICE_REQUEST_PORT, which is 10013 is used.</TD>
+	multicast requests. By default,
+	TAO_DEFAULT_NAME_SERVICE_REQUEST_PORT, which is 10013 is used.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBTradingServicePort</CODE> <EM>portspec</EM></TD>
     <TD>Specifies to which port the Trading Service is listening on for
-        multicast requests. By default,
-        TAO_DEFAULT_TRADING_SERVICE_REQUEST_PORT which is 10016 is used.</TD>
+	multicast requests. By default,
+	TAO_DEFAULT_TRADING_SERVICE_REQUEST_PORT which is 10016 is used.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBImplRepoServicePort</CODE> <EM>portspec</EM></TD>
     <TD>Specifies to which port the Implementation Repository is listening on for
-        multicast requests. By default,
-        TAO_DEFAULT_IMPLREPO_SERVER_REQUEST_PORT which is 10018 is to
-        be used.</TD>
+	multicast requests. By default,
+	TAO_DEFAULT_IMPLREPO_SERVER_REQUEST_PORT which is 10018 is to
+	be used.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBMulticastDiscoveryEndpoint</CODE> <EM>end_point</EM></TD>
     <TD>Specifies the endpoint that should be used for locating the
-        Naming Service through multicast. <EM>end_point</EM> is of the
-        form ip-number:port-number (e.g., "tango.cs.wustl.edu:1234" or
-        "128.252.166.57:1234"). If there is no ':' in the end_point it
-        is assumed to be a port number, with the IP address being INADDR_ANY.
+	Naming Service through multicast. <EM>end_point</EM> is of the
+	form ip-number:port-number (e.g., "tango.cs.wustl.edu:1234" or
+	"128.252.166.57:1234"). If there is no ':' in the end_point it
+	is assumed to be a port number, with the IP address being INADDR_ANY.
   </TR>
   <TR>
     <TD><CODE>-ORBCollocation</CODE> <EM>global/per-orb/no</EM></TD>
     <TD><a name="-ORBCollocation"></a>Specifies the use of collocation
-        object optimization.  If <em>global</em> is
-        specified, objects in the same process will be treated as collocated.
-        If <em>per-orb</em> is specified, only objects in the same ORB are
-        treated as collocated.  When <em>no</em> is specified, no objects are
-        treated as collocated.   Default is global.</TD>
+	object optimization.  If <em>global</em> is
+	specified, objects in the same process will be treated as collocated.
+	If <em>per-orb</em> is specified, only objects in the same ORB are
+	treated as collocated.	When <em>no</em> is specified, no objects are
+	treated as collocated.	 Default is global.</TD>
   </TR>
   <TR>
     <TD>
-        <CODE>-ORBCollocationStrategy</CODE> <EM>thru_poa/direct</EM>
+	<CODE>-ORBCollocationStrategy</CODE> <EM>thru_poa/direct</EM>
     </TD>
     <TD>
-        Specifies what kind of collocated object to use.  If the
-        <em>thru_poa</em> strategy is used, TAO uses the collocation
-        object implementation that respects POA's current state and
-        policies.   When using the <em>direct</em> strategy, method
-        invocations on collocated objects become direct calls to servant
-        without checking POA's status (which translates to better
-        performance.)  Notice that the interfaces that you wish to use
-        direct collocation with must be compiled with <code>
-        <a href="compiler.html#collocation-stubs">-Gd</a>
-        </code>. Default is thru_poa.
+	Specifies what kind of collocated object to use.  If the
+	<em>thru_poa</em> strategy is used, TAO uses the collocation
+	object implementation that respects POA's current state and
+	policies.   When using the <em>direct</em> strategy, method
+	invocations on collocated objects become direct calls to servant
+	without checking POA's status (which translates to better
+	performance.)  Notice that the interfaces that you wish to use
+	direct collocation with must be compiled with <code>
+	<a href="compiler.html#collocation-stubs">-Gd</a>
+	</code>. Default is thru_poa.
     </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBPreconnect</CODE> <EM>endpoint</EM></TD>
     <TD><A name="-ORBPreconnect"></a>Pre-establishes a blocking connection to
-        each listed <EM>endpoint</EM>. If a connection cannot be established the
-        failed preconnection will be ignored and the next preconnection in the list
-        will be processed.  Successful and unsuccessful preconnections will be
-        displayed if a debugging level greater than or equal to one is specified by
-        using the <CODE>-ORBDebugLevel</CODE> option.  Listing the same combination
-        multiple times will properly establish multiple connections to that endpoint.
-        The <CODE>-ORBPreconnect</CODE> option uses the same endpoint format as the
-        <CODE>-ORBEndpoint</CODE> option.
-        <P>
-        This is a client-side option.
-        <P>
-        <FONT COLOR=RED>-ORBPreconnect is <STRONG>deprecated</STRONG>.
-        This option will be removed in the near future.  The Real-Time CORBA standard
-        <CODE>validate_connection()</CODE> method should be used
-        instead.
+	each listed <EM>endpoint</EM>. If a connection cannot be established the
+	failed preconnection will be ignored and the next preconnection in the list
+	will be processed.  Successful and unsuccessful preconnections will be
+	displayed if a debugging level greater than or equal to one is specified by
+	using the <CODE>-ORBDebugLevel</CODE> option.  Listing the same combination
+	multiple times will properly establish multiple connections to that endpoint.
+	The <CODE>-ORBPreconnect</CODE> option uses the same endpoint format as the
+	<CODE>-ORBEndpoint</CODE> option.
+	<P>
+	This is a client-side option.
+	<P>
+	<FONT COLOR=RED>-ORBPreconnect is <STRONG>deprecated</STRONG>.
+	This option will be removed in the near future.  The Real-Time CORBA standard
+	<CODE>validate_connection()</CODE> method should be used
+	instead.
     </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBCDRTradeoff</CODE> <EM>maxsize</EM></TD>
     <TD><A name="-ORBCDRTradeoff"></a>Control the strategy to tradeoff
-        between copy vs. no copy marshalling of octet sequences.
-        If an octet sequence is smaller than <EM>maxsize</EM> and the current
-        message block contains enough space for it the octet sequence is
-        copied instead of appended to the CDR stream. By default,
-        ACE_DEFAULT_CDR_MEMORY_TRADEOFF is used.
+	between copy vs. no copy marshalling of octet sequences.
+	If an octet sequence is smaller than <EM>maxsize</EM> and the current
+	message block contains enough space for it the octet sequence is
+	copied instead of appended to the CDR stream. By default,
+	ACE_DEFAULT_CDR_MEMORY_TRADEOFF is used.
     </TD>
   </TR>
   <TR>
@@ -315,70 +315,76 @@ ORB.  This option is generally only useful when dynamically loading
 the ORB.
      <P>
       <FONT COLOR=RED>This option is <STRONG>deprecated</STRONG>.  It
-        is no longer needed since the Service Configurator is now
-        reentrant and thread-safe.</FONT>
+	is no longer needed since the Service Configurator is now
+	reentrant and thread-safe.</FONT>
 
    </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBGIOPlite</CODE></TD>
     <TD><A name="-ORBGIOPlite"></a> This option has been
-        deprecated. Please see
-        <i>$TAO_ROOT/docs/pluggable_messaging.html </i> for more details. </TD>
+	deprecated. Please see
+	<i>$TAO_ROOT/docs/pluggable_messaging.html </i> for more details. </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBDottedDecimalAddresses</CODE> <EM>boolean (0|1)</EM></TD>
     <TD><A name="-ORBDottedDecimalAddresses"></a> Use the dotted decimal
-        notation for addresses. By default domain names are used in IORs.</TD>
+	notation for addresses. By default domain names are used in IORs.</TD>
   </TR>
   <TR>
     <TD><CODE>-ORBInitRef</CODE> <EM>ObjectId=IOR</EM></TD>
     <TD><A name="-ORBInitRef"></a> Allows specification of an arbitrary
-        object reference for an initial service. The IOR could be in any
-        one of the following formats : OMG IOR, URL, corbaloc (including
-        uioploc) or file. corbaloc is a multiple end-point IOR understood by
-        the string_to_object () method and used as a boot-strapping
-        mechanism by the resolve_initial_references () method. The mappings
-        specified through this argument override the orb-install-time
-        defaults. The file://<I>pathname</I> interprets the contents of the
-        <I>pathname</I> file as an object reference in any of the above
-        formats.
+	object reference for an initial service. The IOR could be in any
+	one of the following formats : OMG IOR, URL, corbaloc (including
+	uioploc) or file. corbaloc is a multiple end-point IOR understood by
+	the string_to_object () method and used as a boot-strapping
+	mechanism by the resolve_initial_references () method. The mappings
+	specified through this argument override the orb-install-time
+	defaults. The file://<I>pathname</I> interprets the contents of the
+	<I>pathname</I> file as an object reference in any of the above
+	formats.
     </TD>
   </TR>
 
   <TR>
     <TD><CODE>-ORBDefaultInitRef</CODE> <EM>IOR prefix</EM></TD>
     <TD><A name="-ORBDefaultInitRef"></a> This argument allows
-        resolution of initial references not explicitly specified with
-        -ORBInitRef. It requires a URL prefix that, after appending a
-        slash '/' ('|' for UIOP pluggable protocol) and a simple
-        object key, forms a new URL to identify an initial object
-        reference. The URL prefix format currently supported is
-        corbaloc.
+	resolution of initial references not explicitly specified with
+	-ORBInitRef. It requires a URL prefix that, after appending a
+	slash '/' ('|' for UIOP pluggable protocol) and a simple
+	object key, forms a new URL to identify an initial object
+	reference. The URL prefix format currently supported is
+	corbaloc.
     </TD>
   </TR>
 
   <TR>
     <TD><CODE>-ORBStdProfileComponents</CODE> <EM>boolean (0|1)</EM></TD>
     <TD><A name="-ORBStdProfileComponents"></a> If <EM>0</EM> then the ORB
-        does not generate the OMG standardized profile
-        components, such as the ORB type and code sets.
-        Notice that the presence of this components is optional
-        in GIOP 1.1
-        The default value is controlled by a compile-time flag
-        (check orbconf.h).</TD>
+	does not generate the OMG standardized profile
+	components, such as the ORB type and code sets.
+	Notice that the presence of this components is optional
+	in GIOP 1.1
+	The default value is controlled by a compile-time flag
+	(check orbconf.h).</TD>
   </TR>
 
   <TR>
     <TD><CODE>-ORBResources</CODE> <EM>which</EM></TD>
     <TD><A name=-ORBResources>Control the use of thread specific resources
-        in the ORB.
-        If (<em>which</em> = <code>global</code>) then the
-        same set of resources are shared by all the threads
-        that use that ORB.
-        If (<em>which</em> = <code>tss</code>) then each that
-        uses that ORB gets its own set of resources.
-        Currently the resources are limited to the reactor.
+	in the ORB.
+	If (<em>which</em> = <code>global</code>) then the
+	same set of resources are shared by all the threads
+	that use that ORB.
+	If (<em>which</em> = <code>tss</code>) then each that
+	uses that ORB gets its own set of resources.
+
+	<P><B>NOTE:</B> This option has almost negligible effect on the
+    ORB. The right type of resources are selected by the ORB during
+    runtime. For example the memory for the output datapath always
+    defaults to TSS. If the message needs queuing the ORB decides to
+    use global memory. The option would be deprecated in the future
+    versions of TAO. </P>
     </TD>
   </TR>
 
@@ -386,16 +392,16 @@ the ORB.
   <TR>
     <TD><CODE>-ORBUseIMR</CODE> <EM>boolean (0|1)</EM></TD>
     <TD><A name=-ORBUseIMR></A>This argument specifies that for POAs with the
-        PERSISTENT policy, that the Implementation Repository should be used for
-        notification of startup and shutdown and Object References should be changed
-        to use the Implementation Repository also.
+	PERSISTENT policy, that the Implementation Repository should be used for
+	notification of startup and shutdown and Object References should be changed
+	to use the Implementation Repository also.
     </TD>
   </TR>
 
   <TR>
     <TD><CODE>-ORBLogFile</CODE> <EM>log file name</EM></TD>
     <TD><A name=-ORBLogFile></A>Causes all ACE_DEBUG and ACE_ERROR
-        output to be redirected to the specified file.
+	output to be redirected to the specified file.
     </TD>
   </TR>
 
@@ -422,20 +428,21 @@ would load all the options listed within "".
   <TR>
     <TD><CODE>-ORBResources</CODE> <EM>which</EM></TD>
     <TD>Specify whether each thread uses a global
-        (<em>which</em> = <code>global</code>) or a thread-specific
-        (<em>which</em> = <code>tss</code>) instance for the resources it
-        returns. The default is <CODE>global</CODE>.
-        <B>NOTE:</B> This option controls the default value for
-        the ORB option of the same name.</A>.
+	(<em>which</em> = <code>global</code>) or a thread-specific
+	(<em>which</em> = <code>tss</code>) instance for the resources it
+	returns. The default is <CODE>global</CODE>.
+	<B>NOTE:</B> This option controls the default value for
+	the ORB option of the same name. The note in the ORB option
+	also applies to this case too. </A>.
     </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBReactorMaskSignals</CODE> <EM>0/1</EM></TD>
     <TD>ACE select reactors mask signals during upcalls to the event
-        handlers.  This is only useful if the application is going to
-        trap those signals and handle them in any way.
-        Disabling the mask can improve performance by reducing the
-        number of kernel level locks.
+	handlers.  This is only useful if the application is going to
+	trap those signals and handle them in any way.
+	Disabling the mask can improve performance by reducing the
+	number of kernel level locks.
     </TD>
   </TR>
 <TR>
@@ -467,7 +474,7 @@ would load all the options listed within "".
       and <CODE>file:</CODE>.
       The application developer can
       <A HREF="ior_parsing.html">
-        add new IOR formats
+	add new IOR formats
       </A>
       using this option.
   </TD>
@@ -477,7 +484,7 @@ would load all the options listed within "".
   <TD><a name="-ORBConnectionCachingStrategy"></a>
       Opened connections are added to the transport cache so they can be
       reused.  However, if a process continues to run and these
-      connections are not reused, the cache will continue to grow. 
+      connections are not reused, the cache will continue to grow.
       Therefore, before each new connection, the cache is checked and
       purged if it has reached the limit specified by the
       -ORBConnectionCacheMax option or the system default if that option was
@@ -570,175 +577,169 @@ would load all the options listed within ""
   <TR>
 
     <TD><a name="orb_concurrency"><CODE>-ORBConcurrency</CODE></a>
-        <EM>which</EM></TD>
+	<EM>which</EM></TD>
     <TD>Specify which
-        concurrency strategy to use.  Range of values is <code>reactive</code>
-        for a purely Reactor-driven concurrency strategy or
-        <code>thread-per-connection</code> for creating a new thread to
-        service each connection. The default is reactive.
-              <P>
-                TAO also supports the thread-pool concurrency model
-                but this is implemented by the user, creating multiple
-                threads that call <CODE>ORB::run()</CODE> and using
-                the <CODE>-ORBReactorType tp</CODE> option.
-              </P>
+	concurrency strategy to use.  Range of values is <code>reactive</code>
+	for a purely Reactor-driven concurrency strategy or
+	<code>thread-per-connection</code> for creating a new thread to
+	service each connection. The default is reactive.
     </TD>
   </TR>
   <TR>
 
     <TD><a name="server_timeout"><CODE>-ORBThreadPerConnectionTimeout</CODE></a>
-        <EM>milliseconds</EM></TD>
+	<EM>milliseconds</EM></TD>
     <TD>In many platforms it is impossible to interrupt the server
-              threads created by the
-              <code>thread-per-connection</code> model.
-              This is because these threads are blocked in
-              <CODE>read()</CODE> operations (and not in
-              <CODE>select()</CODE>).
-              As a workaround, the server threads
-              periodically poll the ORB to find out if they should
-              shutdown.
-              This option controls the period of the polling,
-              expressed in milliseconds.
-              Applications that do not shutdown, or that can otherwise
-              ensure that no server threads will be running at
-              shutdown (for example if all the clients terminate
-              before the server) can disable the polling using  the
-              magic value <CODE>INFINITE</CODE>.
-
-              <P>
-                If the option is not provided then the ORB uses the
-                compile time flag
-                <CODE>TAO_DEFAULT_THREAD_PER_CONNECTION_TIMEOUT</CODE>,
-                this flag also expresses the time in milliseconds (as
-                a string constant) and the magic value
-                <CODE>"INFINITE"</CODE> can be used to disable polling
-                entirely. This yields a slight performance improvement
-                (around 1%).
-              </P>
-            </TD>
+	      threads created by the
+	      <code>thread-per-connection</code> model.
+	      This is because these threads are blocked in
+	      <CODE>read()</CODE> operations (and not in
+	      <CODE>select()</CODE>).
+	      As a workaround, the server threads
+	      periodically poll the ORB to find out if they should
+	      shutdown.
+	      This option controls the period of the polling,
+	      expressed in milliseconds.
+	      Applications that do not shutdown, or that can otherwise
+	      ensure that no server threads will be running at
+	      shutdown (for example if all the clients terminate
+	      before the server) can disable the polling using	the
+	      magic value <CODE>INFINITE</CODE>.
+
+	      <P>
+		If the option is not provided then the ORB uses the
+		compile time flag
+		<CODE>TAO_DEFAULT_THREAD_PER_CONNECTION_TIMEOUT</CODE>,
+		this flag also expresses the time in milliseconds (as
+		a string constant) and the magic value
+		<CODE>"INFINITE"</CODE> can be used to disable polling
+		entirely. This yields a slight performance improvement
+		(around 1%).
+	      </P>
+	    </TD>
   </TR>
   <TR>
     <TD><CODE>-ORBActiveObjectMapSize</CODE> <EM>active object map
-        size</EM></TD>
+	size</EM></TD>
     <TD>Specify the size of the active object map. If not
-        specified, the default value is 64.</TD>
+	specified, the default value is 64.</TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBUseridPolicyDemuxStrategy</CODE> <EM>user id policy
-        based demultiplexing strategy</EM></TD>
+	based demultiplexing strategy</EM></TD>
     <TD>Specify the demultiplexing
-        lookup strategy to be used with the user id policy.  The
-        <EM>demultiplexing strategy</EM> can be one of <CODE>dynamic</CODE> or
-        <CODE>linear</CODE>.  This option defaults to use the
-        <CODE>dynamic</CODE> strategy. </TD>
+	lookup strategy to be used with the user id policy.  The
+	<EM>demultiplexing strategy</EM> can be one of <CODE>dynamic</CODE> or
+	<CODE>linear</CODE>.  This option defaults to use the
+	<CODE>dynamic</CODE> strategy. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBSystemidPolicyDemuxStrategy</CODE> <EM>system id policy
-        based demultiplexing strategy</EM></TD>
+	based demultiplexing strategy</EM></TD>
 
     <TD>Specify the demultiplexing lookup strategy to be used with the
-        system id policy. The <EM>demultiplexing strategy</EM> can be
-        one of <CODE>dynamic</CODE>, <CODE>linear</CODE>, or
-        <CODE>active</CODE>. This option defaults to use the
-        <CODE>dynamic</CODE> strategy when
-        <CODE>-ORBAllowReactivationOfSystemids</CODE> is true, and to
-        <CODE>active</CODE> strategy when
-        <CODE>-ORBAllowReactivationOfSystemids</CODE> is false. </TD>
+	system id policy. The <EM>demultiplexing strategy</EM> can be
+	one of <CODE>dynamic</CODE>, <CODE>linear</CODE>, or
+	<CODE>active</CODE>. This option defaults to use the
+	<CODE>dynamic</CODE> strategy when
+	<CODE>-ORBAllowReactivationOfSystemids</CODE> is true, and to
+	<CODE>active</CODE> strategy when
+	<CODE>-ORBAllowReactivationOfSystemids</CODE> is false. </TD>
 
   </TR>
   <TR>
 
     <TD><CODE>-ORBUniqueidPolicyReverseDemuxStrategy</CODE> <EM>unique id
-        policy based reverse demultiplexing strategy</EM></TD>
+	policy based reverse demultiplexing strategy</EM></TD>
     <TD>Specify the
-        reverse demultiplexing lookup strategy to be used with the unique id
-        policy. The <EM>reverse demultiplexing strategy</EM> can be one of
-        <CODE>dynamic</CODE> or <CODE>linear</CODE>. This option defaults to
-        use the <CODE>dynamic</CODE> strategy. </TD>
+	reverse demultiplexing lookup strategy to be used with the unique id
+	policy. The <EM>reverse demultiplexing strategy</EM> can be one of
+	<CODE>dynamic</CODE> or <CODE>linear</CODE>. This option defaults to
+	use the <CODE>dynamic</CODE> strategy. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBAllowReactivationOfSystemids</CODE> <EM>allows
-        reactivation of system ids</EM></TD>
+	reactivation of system ids</EM></TD>
     <TD>Specify whether system ids
-        can be reactivated, i.e., once an id that was generated by the system
-        has be deactivated, will the user reactivate a new servant using the
-        old id.  If the user is not going to use this feature, the IORs can be
-        shortened, an extra comparison in the critical upcall path removed,
-        and some memory on the server side can be saved. The
-        <CODE>ORBAllowReactivationOfSystemids</CODE> can be <CODE>0</CODE> or
-        <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
+	can be reactivated, i.e., once an id that was generated by the system
+	has be deactivated, will the user reactivate a new servant using the
+	old id.  If the user is not going to use this feature, the IORs can be
+	shortened, an extra comparison in the critical upcall path removed,
+	and some memory on the server side can be saved. The
+	<CODE>ORBAllowReactivationOfSystemids</CODE> can be <CODE>0</CODE> or
+	<CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBActiveHintInIds</CODE> <EM>adds an active hint in
-        ids</EM></TD>
+	ids</EM></TD>
     <TD>Specify whether an active hint should be added to
-        ids. With active hints, ids can be found quickly.  However, they lead
-        to larger IORs. Note that this option is disregarded
-        <CODE>-ORBAllowReactivationOfSystemids</CODE> is set to
-        <CODE>0</CODE>. The <EM>-ORBActiveHintInIds</EM> can be <CODE>0</CODE>
-        or <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
+	ids. With active hints, ids can be found quickly.  However, they lead
+	to larger IORs. Note that this option is disregarded
+	<CODE>-ORBAllowReactivationOfSystemids</CODE> is set to
+	<CODE>0</CODE>. The <EM>-ORBActiveHintInIds</EM> can be <CODE>0</CODE>
+	or <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBPoaMapSize</CODE> <EM>poa map size</EM></TD>
     <TD>Specify
-        the size of the poa map. If not specified, the default value is
-        24.</TD>
+	the size of the poa map. If not specified, the default value is
+	24.</TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBPersistentidPolicyDemuxStrategy</CODE> <EM>persistent
-        id policy based demultiplexing strategy</EM></TD>
+	id policy based demultiplexing strategy</EM></TD>
     <TD>Specify the
-        demultiplexing lookup strategy to be used with the persistent id
-        policy.  The <EM>demultiplexing strategy</EM> can be one of
-        <CODE>dynamic</CODE> or <CODE>linear</CODE>.  This option defaults to
-        use the <CODE>dynamic</CODE> strategy. </TD>
+	demultiplexing lookup strategy to be used with the persistent id
+	policy.  The <EM>demultiplexing strategy</EM> can be one of
+	<CODE>dynamic</CODE> or <CODE>linear</CODE>.  This option defaults to
+	use the <CODE>dynamic</CODE> strategy. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBTransientidPolicyDemuxStrategy</CODE> <EM>transient id
-        policy based demultiplexing strategy</EM></TD>
+	policy based demultiplexing strategy</EM></TD>
     <TD>Specify the
-        demultiplexing lookup strategy to be used with the transient id
-        policy. The <EM>demultiplexing strategy</EM> can be one of
-        <CODE>dynamic</CODE>, <CODE>linear</CODE>, or
-        <CODE>active</CODE>. This option defaults to use the
-        <CODE>active</CODE> strategy. </TD>
+	demultiplexing lookup strategy to be used with the transient id
+	policy. The <EM>demultiplexing strategy</EM> can be one of
+	<CODE>dynamic</CODE>, <CODE>linear</CODE>, or
+	<CODE>active</CODE>. This option defaults to use the
+	<CODE>active</CODE> strategy. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBActiveHintInPOANames</CODE> <EM>adds an active hint in
-        poa names</EM></TD>
+	poa names</EM></TD>
     <TD>Specify whether an active hint should be added
-        to poa names. With active hints, poa names can be found quickly.
-        However, they lead to larger IORs. The
-        <EM>-ORBActiveHintInPOANames</EM> can be <CODE>0</CODE> or
-        <CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
+	to poa names. With active hints, poa names can be found quickly.
+	However, they lead to larger IORs. The
+	<EM>-ORBActiveHintInPOANames</EM> can be <CODE>0</CODE> or
+	<CODE>1</CODE>. This option defaults to <CODE>1</CODE>. </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBThreadFlags</CODE> <EM>thread flags</EM></TD>
     <TD>Specify the flags used for thread creation. Flags can be any
-        logical-OR combination of <CODE>THR_DETACHED</CODE>,
-        <CODE>THR_BOUND</CODE>, <CODE>THR_NEW_LWP</CODE>,
-        <CODE>THE_SUSPENDED</CODE>. The default is <CODE>THR_BOUND |
-        THR_DETACHED</CODE> . </TD>
+	logical-OR combination of <CODE>THR_DETACHED</CODE>,
+	<CODE>THR_BOUND</CODE>, <CODE>THR_NEW_LWP</CODE>,
+	<CODE>THE_SUSPENDED</CODE>. The default is <CODE>THR_BOUND |
+	THR_DETACHED</CODE> . </TD>
   </TR>
   <TR>
 
     <TD><CODE>-ORBPOALock</CODE> <EM>lock type</EM></TD>
     <TD><a
-        name="-ORBPOALock"></a>Specify the type of lock to be used for POA
-        accesses.  Possible values for <em>lock type</em> are
-        <code>thread</code>, which specifies that an inter-thread mutex is
-        used to guarantee exclusive access, and <code>null</code>, which
-        specifies that no locking be performed.  The default is
-        <code>thread</code>.</TD>
+	name="-ORBPOALock"></a>Specify the type of lock to be used for POA
+	accesses.  Possible values for <em>lock type</em> are
+	<code>thread</code>, which specifies that an inter-thread mutex is
+	used to guarantee exclusive access, and <code>null</code>, which
+	specifies that no locking be performed.  The default is
+	<code>thread</code>.</TD>
   </TR>
 <!--
   <TR>
@@ -750,7 +751,7 @@ would load all the options listed within ""
 -->
     <TD><CODE>-ORBConnectorLock</CODE> <EM>lock type</EM></TD>
     <TD><a
-        name="-ORBConnectorLock"></a>This option has been deprecated.</TD>
+	name="-ORBConnectorLock"></a>This option has been deprecated.</TD>
   </TR>
 
 </TABLE>
@@ -775,13 +776,13 @@ would load all the options listed within "".
   <TR>
     <TD><CODE><a name="#-ORBProfileLock">-ORBProfileLock</a></CODE> <EM>which</EM></TD>
     <TD>
-        Specify the kind of synchronization primitive for the
-        Profiles.
-        Default is <code>thread</code>, which means that a regular thread
-        mutex is used. The
-        second option is <code>null</code>, which means a null lock is used.
-        This makes sense in case of optimizations and is allowed when
-        no forwarding is used or only a single threaded client.
+	Specify the kind of synchronization primitive for the
+	Profiles.
+	Default is <code>thread</code>, which means that a regular thread
+	mutex is used. The
+	second option is <code>null</code>, which means a null lock is used.
+	This makes sense in case of optimizations and is allowed when
+	no forwarding is used or only a single threaded client.
     </TD>
   </TR>
   <TR>
@@ -789,28 +790,28 @@ would load all the options listed within "".
 
     <TD><A name="-ORBClientConnectionHandler"></a>
 
-        ST means use the single-threaded client connection handler, i.e., the
-        leader follower model will not be used.  However, ST does support
-        nested upcalls and handling of new requests while waiting for the
-        reply from a server. <p>
-
-        MT means use the multi-threaded client connection handler which uses
-        the leader follower model. This model allows the use of multiple
-        threads with a single Reactor.  <p>
-
-        RW selects a strategy that simply blocks in recv() when waiting for a
-        response from the server instead of waiting in the Reactor.  The RW
-        strategy only works when the application does not have to worry about
-        new request showing up when waiting for a response. Therefore, this
-        strategy is appropriate only for "pure" clients. Note that
-        applications with nested upcalls are not "pure" clients. Also note
-        that this strategy will only effect two way calls, since there is no
-        waiting for one way calls. This strategy can also be used in an
-        application that is both a client and a server if the server side is
-        handled by a separate thread and the client threads are "pure"
-        clients. <p>
-
-        Default for this option is MT.
+	ST means use the single-threaded client connection handler, i.e., the
+	leader follower model will not be used.  However, ST does support
+	nested upcalls and handling of new requests while waiting for the
+	reply from a server. <p>
+
+	MT means use the multi-threaded client connection handler which uses
+	the leader follower model. This model allows the use of multiple
+	threads with a single Reactor.	<p>
+
+	RW selects a strategy that simply blocks in recv() when waiting for a
+	response from the server instead of waiting in the Reactor.  The RW
+	strategy only works when the application does not have to worry about
+	new request showing up when waiting for a response. Therefore, this
+	strategy is appropriate only for "pure" clients. Note that
+	applications with nested upcalls are not "pure" clients. Also note
+	that this strategy will only effect two way calls, since there is no
+	waiting for one way calls. This strategy can also be used in an
+	application that is both a client and a server if the server side is
+	handled by a separate thread and the client threads are "pure"
+	clients. <p>
+
+	Default for this option is MT.
 
     </TD>
   </TR>
@@ -820,16 +821,16 @@ would load all the options listed within "".
 
     <TD><A name="-ORBTransportMuxStrategy"></a>
 
-        EXCLUSIVE means that the Transport does not multiplex requests on a
-        connection. At a time, there can be only one request pending on a
-        connection.  <p>
+	EXCLUSIVE means that the Transport does not multiplex requests on a
+	connection. At a time, there can be only one request pending on a
+	connection.  <p>
 
-        MUXED means that Transport multiplexes more than one request at the
-        same time on a connection.  This option is often used in
-        conjunction with Asynchronous Method Invocation, because
-        multiple requests can be sent 'in bulk'. <p>
+	MUXED means that Transport multiplexes more than one request at the
+	same time on a connection.  This option is often used in
+	conjunction with Asynchronous Method Invocation, because
+	multiple requests can be sent 'in bulk'. <p>
 
-        Default for this option is MUXED.
+	Default for this option is MUXED.
 
     </TD>
   </TR>
@@ -837,7 +838,7 @@ would load all the options listed within "".
   <TR>
     <TD><CODE>-ORBConnectorLock</CODE> <EM>lock type</EM></TD>
     <TD><a
-        name="-ORBConnectorLock"></a> This option has been deprecated.
+	name="-ORBConnectorLock"></a> This option has been deprecated.
     </TD>
   </TR>
 
@@ -874,40 +875,40 @@ superseded by <code><A HREF="#-ORBReactorType">-ORBReactorType</A></code>.
   <TR>
     <TD><CODE>-ORBReactorType</CODE> <EM>which</EM></TD>
     <TD><a name="-ORBReactorType"></a>Specify what kind of reactor the
-        ORB uses. The default reactor is the ACE_TP_Reactor.
-        <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0">
-          <TR><TH><em>which</em></TH><TH>Reactor</TH>
-        </TR>
-        <TR>
-          <TD><CODE>select_mt</CODE></TD>
-          <TD>Use the multi-thread select-based reactor.</TD>
-        </TR>
-
-        <TR>
-          <TD><CODE>select_st</CODE></TD>
-          <TD>Use the single-thread select-based reactor.</TD>
-        </TR>
-
-        <TR>
-          <TD><CODE>fl</CODE></TD>
-          <TD>Use the FLReactor (FLTK-based).</TD>
-        </TR>
-
-        <TR>
-          <TD><CODE>wfmo</CODE></TD>
-          <TD>Use the WFMO reactor (Win32 only).</TD>
-        </TR>
-
-        <TR>
-          <TD><CODE>msg_wfmo</CODE></TD>
-          <TD>Use the MsgWFMO reactor (Win32 only).</TD>
-        </TR>
-
-        <TR>
-          <TD><CODE>tp</CODE></TD>
-          <TD>Use the <CODE>ACE_TP_Reactor</CODE>, a select based
-              thread-pool reactor.</TD>
-        </TR>
+	ORB uses. The default reactor is the ACE_TP_Reactor.
+	<TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0">
+	  <TR><TH><em>which</em></TH><TH>Reactor</TH>
+	</TR>
+	<TR>
+	  <TD><CODE>select_mt</CODE></TD>
+	  <TD>Use the multi-thread select-based reactor.</TD>
+	</TR>
+
+	<TR>
+	  <TD><CODE>select_st</CODE></TD>
+	  <TD>Use the single-thread select-based reactor.</TD>
+	</TR>
+
+	<TR>
+	  <TD><CODE>fl</CODE></TD>
+	  <TD>Use the FLReactor (FLTK-based).</TD>
+	</TR>
+
+	<TR>
+	  <TD><CODE>wfmo</CODE></TD>
+	  <TD>Use the WFMO reactor (Win32 only).</TD>
+	</TR>
+
+	<TR>
+	  <TD><CODE>msg_wfmo</CODE></TD>
+	  <TD>Use the MsgWFMO reactor (Win32 only).</TD>
+	</TR>
+
+	<TR>
+	  <TD><CODE>tp</CODE></TD>
+	  <TD>Use the <CODE>ACE_TP_Reactor</CODE>, a select based
+	      thread-pool reactor which is the default.</TD>
+	</TR>
       </TABLE>
 </TD>
 </TR>
@@ -935,7 +936,7 @@ superseded by <code><A HREF="#-ORBReactorType">-ORBReactorType</A></code>.
       Select the type of reactor registry.
       Currently two implementations are provided:
       <B>single</B> uses a single reactor per ORB, this is the default
-            and is sufficient for most applications.
+	    and is sufficient for most applications.
       Applications with stringent QoS requirements may prefer
       the <B>per-priority</B> strategy, in this case threads at
       different CORBA priorities are assigned different
@@ -969,12 +970,12 @@ would load all the options listed within "".
   <TD><a name="-ORBSchedPolicy"></a>
       Specify the scheduling policy used for the priority mapping
       computations and to specify the scheduling policy used when
-      creating RTCORBA threads. 
+      creating RTCORBA threads.
       Priority mappings map the CORBA priority range (from 0 to 32767)
       into the native OS priority range, but in some operating systems
       the range depends on the scheduling policy used.
       Valid values are <B>SCHED_OTHER</B>, <B>SCHED_FIFO</B> and
-      <B>SCHED_RR</B>.  Defaults to <B>SCHED_OTHER</B>. Note that in
+      <B>SCHED_RR</B>.	Defaults to <B>SCHED_OTHER</B>. Note that in
       some operating systems some of
       the scheduling policies require super user privileges.
   </TD>