ChangeLogTag:Thu Dec 30 13:21:37 2004 Chris Cleeland <cleeland@ociweb.com>

1 files changed, 49 insertions, 51 deletions

diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html
index c9310ec1519..2876d2a416e 100644
--- a/TAO/docs/Options.html
+++ b/TAO/docs/Options.html
@@ -92,7 +92,7 @@ high-performance applications.
   <li> <b>Command-line options</b> are passed to the ORB
 initialization
 factory method, <code>CORBA::ORB_init()</code>, by an application
-using the standard <i>argc, argv</i> tuple passed to the application's
+using the standard <i>argc/argv</i> tuple passed to the application's
     <code>main()</code>. Most of the options that can be exercised
 through
 environment variables can also be manipulated through command-line
@@ -108,13 +108,7 @@ configurator file, whose default file name is
     <code>svc.conf</code>. The service configurator is opened and
 processed by the ORB in <code>CORBA::ORB_init()</code>. The service
 configurator processing is done after all the command-line options
-have been<!-- Bala, should this be "processed" or just "parsed"?
-There could be a different -->
-parsed.
-    <p><!-- It should be just "parsed". The options from the command lines
-<!-- are just parsed in ORB_init () and stored for later use -->
-<!-- For the service configurator it is tricky. To be on the safer
-<!-- side I would say "processed". --></p>
+have been parsed.
   </li>
 </ul>
 <p></p>
@@ -377,7 +371,7 @@ default is used.</td>
 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>
+compile-time flag defined in <CODE>orbconf.h</CODE>.</td>
       </tr>
       <tr>
         <td><code>-ORBSingleReadOptimization</code> <em>boolean (0|1)</em></td>
@@ -390,7 +384,7 @@ the ORB will do a read of size <code>TAO_MAXBUFSIZE</code>, hoping to
 read the entire request. If more than one request is read they will be
 queued up for processing later.
         <p> This option defaults to <code>1</code> because it can
-provide better performance. However, in the case of RT-CORBA, this
+provide better performance.  In the case of Real-time CORBA, however, this
 option should be set to <code>0</code>. Consider the following
 scenario: (1) two requests are read from one socket, (2) the additional
 request is queued, and (3) the ORB uses its Reactor's notification
@@ -405,13 +399,13 @@ preferences over normal I/O, thereby causing priority inversion.</p>
        <td><code>-ORBDisableRTCollocation</code> <em>boolean
        (0|1)</em></td> <td><a name="-ORBDisableRTCollocation"></a>This
        option controls whether the application wants to use or discard
-       RT collocation decisions made by the RT ORB. A value of true
-       disables RT collocation decisions and falls back on the default
-       collocation decisions implemented in the default ORB. This is
-       very useful for applications using the RT ORB and doesn't want
+       RT collocation decisions made by the RT ORB. A value of
+       <CODE>1</CODE> (true) disables RT collocation decisions and falls back on the default
+       collocation decisions implemented in the default ORB, which is
+       useful for applications using the RT ORB and doesn't want
        to use the RT collocation decisions but fallback on the default
        decisions for better performance. The default value is
-       <code>0</code>. </td>      
+       <code>0</code> (false). </td>      
        </tr>
     </tbody>
   </table>
@@ -436,7 +430,7 @@ selection within a TAO application.
         <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 '/'
+<CODE>-ORBInitRef</CODE>. It requires a URL prefix that, after appending a slash '/'
 ('|' for the 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 based on the standard <code>corbaloc</code>
@@ -478,8 +472,8 @@ since domain names are the standard address notation for IORs.</td>
         <td><code>-ORBEnforcePreferredInterfaces</code>
         <em>Yes/No</em></td> 
         <td><a name="-ORBEnforcePreferredInterfaces"></a> This option
-        specifies whether -ORBPreferredInterfaces option needs to be
-        enforced. The option is supposed to help with the following
+        specifies whether <CODE>-ORBPreferredInterfaces</CODE> option
+        needs to be enforced. The option is supposed to help with the following
         usecase. It is possible that under some situations the
         preferred local network may not have a route to the target
         host/interface. The ORB can do one of the following. The ORB
@@ -496,10 +490,10 @@ since domain names are the standard address notation for IORs.</td>
         <td><code>-ORBListenEndpoints</code> <em>endpoint</em></td>
         <td><a name="-ORBListenEndpoints"></a> This option was
         introduced with the CORBA <a
-        href="http://cgi.omg.org/docs/orbos/01-01-04.pdf"> ORT </a>
-        (Object Reference Template) specification. It instructs a
+        href="http://cgi.omg.org/docs/orbos/01-01-04.pdf">Object
+            Reference Template</A> (ORT) specification. It instructs a
         server ORB to listen for requests on the interface specified
-        by <code>endpoint</code>. When used with RT-CORBA, the option
+        by <code>endpoint</code>. When used with Real-time CORBA, the option
         specifies the endpoints that the default thread pool listens
         to.  TAO endpoints are specified using a URL style format. An
         endpoint has the form:
@@ -512,7 +506,7 @@ since domain names are the standard address notation for IORs.</td>
 
         Sets of endpoints may be specified using multiple
         <code>-ORBListenEndpoints</code> options or by delimiting
-        endpoints with a semi-colon (;). For example,
+        endpoints with a semi-colon (;).  For example,
         <blockquote><code>-ORBListenEndpoints iiop://localhost:9999
         -ORBListenEndpoints uiop:///tmp/mylocalsock
         -ORBListenEndpoints shmiop://10002 </code></blockquote> is
@@ -546,8 +540,8 @@ since domain names are the standard address notation for IORs.</td>
         <em>thread-pool-id:thread-lane-id endpoint</em></td> <td><a
         name="-ORBLaneListenEndpoints"></a> This option allows the
         user to specify endpoints for thread pools and lanes. This
-        option is only meaningful when used with RT-CORBA and only
-        makes sense when the thread pools and lanes are created in the
+        option is only meaningful when used with Real-time CORBA and
+        only makes sense when the thread pools and lanes are created in the
         same order across server incarnations.  See <a
         href="#-ORBListenEndpoints"><code>-ORBListenEndPoints</code></a>
         option on how to specify endpoints.  An example is:
@@ -650,9 +644,9 @@ provided for specific application requirements.
       <tr>
         <td><code>-ORBId</code> <em>orb_name</em></td>
         <td><a name="-ORBId"></a>This option allows the name of an ORB
-to be set to <code>orb_name</code>. The ORBId will be passed to the
-ORB_init() method to differentiate coexisting ORBs (when there are more
-than one ORBs).</td>
+to be set to <code>orb_name</code>. The <CODE>ORBId</CODE> will be
+passed to the <CODE>CORBA::ORB_init()</CODE> method to differentiate
+coexisting ORBs (when there is more than one ORB).</td>
       </tr>
       <tr>
         <td><code>-ORBServerId</code> <em>server_id</em></td>
@@ -844,14 +838,16 @@ new IOR formats </a>using this option. </td>
         <td><code>-ORBConnectionPurgingStrategy</code> <em>type</em></td>
         <td><a name="-ORBConnectionPurgingStrategy"></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. 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 not used. The possible values for type are lru, lfu,
-fifo and null. The default is LRU (Least Recently Used). The others LFU
-(Least Frequently Used), FIFO (First In First Out), and null (No
-connections are purged) are contained within the TAO Strategies
+If a process continues to run and these connections are not reused,
+however, the cache will continue to grow.  Before each new connection,
+therefore, the cache is checked and purged if it has reached the limit
+specified by the <CODE>-ORBConnectionCacheMax</CODE> option or the
+system default if that option was not used. The possible values for
+type are <CODE>lru</CODE>, <CODE>lfu</CODE>, <CODE>fifo</CODE>, and
+<CODE>null</CODE>. The default is <CODE>lru</CODE> (least recently
+used). The other options are <CODE>lfu</CODE> (least frequently used),
+<CODE>fifo</CODE> (first in first out), and <CODE>null</CODE> (no
+connections are purged) and are contained within the TAO Strategies
 library. </td>
       </tr>
       <tr>
@@ -859,7 +855,7 @@ library. </td>
         <td><a name="-ORBConnectionCacheMax"></a>The transport cache
 will grow to a maximum of the specified limit. The default is system
 dependent, but can be overridden at compile-time by defining the
-preprocessor macro TAO_CONNECTION_CACHE_MAXIMUM. </td>
+preprocessor macro <CODE>TAO_CONNECTION_CACHE_MAXIMUM</CODE>. </td>
       </tr>
       <tr>
         <td><code>-ORBMuxedConnectionMax</code> <em>number</em></td>
@@ -1012,23 +1008,25 @@ default.</td>
       <tr>
         <td><code>-ORBReactorThreadQueue</code> <em>which</em></td>
         <td><a name="-ORBReactorThreadQueue"></a>Applies only to the
-ACE_TP_Reactor, i.e., when <code>-ORBReactorType</code> = <code>tp</code>,
-and specifies the order, last-in-first-out (<em>which</em> = <code>LIFO</code>),
-the default, or first-in-first-out (<em>which</em> = <code>FIFO</code>),
-in which waiting threads are selected to run by the
-ACE_Select_Reactor_Token. </td>
+<CODE>ACE_TP_Reactor</CODE>, i.e., when <code>-ORBReactorType</code> =
+<code>tp</code>, and specifies the order, last-in-first-out
+(<em>which</em> = <code>LIFO</code>), the default, or
+first-in-first-out (<em>which</em> = <code>FIFO</code>), in which
+waiting threads are selected to run by the
+<CODE>ACE_Select_Reactor_Token</CODE>. </td>
       </tr>
       <tr>
         <td><code>-ORBInputCDRAllocator</code> <em>which</em></td>
-        <td><a name="-ORBInputCDRAllocator"></a>Specify whether the ORB
-uses locked (<em>which</em> = <code>thread</code>) or lock-free (<em>which</em>
-= <code>null</code>) allocators for the incoming CDR buffers. Though <code>null</code>
-should give the optimal performance; we made the default <code>thread</code>.
-TAO optimizations for octet sequences will not work in all cases when
-the allocator does not have locks (for example if the octet sequences
-are part of a return value). Using locked allocators also allows the
-users to take advantage of the TAO octet sequence extensions to
-preserve the buffer after the upcall. </td>
+        <td><a name="-ORBInputCDRAllocator"></a>Specify whether the
+ORB uses locked (<em>which</em> = <code>thread</code>) or lock-free
+(<em>which</em> = <code>null</code>) allocators for the incoming CDR
+buffers. Though <code>null</code> should give the optimal performance;
+we made the default <code>thread</code>.  TAO optimizations for octet
+sequences will not work in all cases when the allocator does not have
+locks (for example if the octet sequences are part of a return
+value). Using locked allocators also allows the users to take
+advantage of the TAO octet sequence extensions to preserve the buffer
+after the upcall. </td>
       </tr>
       <tr>
         <td><code>-ORBAMHResponseHandlerAllocator</code> <em>which</em></td>
@@ -1288,7 +1286,7 @@ 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>
 <p>
-        MT_NOUPCALL means use a client connection handler that
+        <CODE>MT_NOUPCALL</CODE> means use a client connection handler that
         participates in the leader-follower model like MT, but, like
         RW, does not allow handling of nested upcalls within the
         waiting thread.  Note that with this strategy it is possible