Removed trailing whitespaces and corrected links to bugzilla

3 files changed, 90 insertions, 97 deletions

diff --git a/TAO/docs/HISTORY b/TAO/docs/HISTORY
index d97a8e35b2e..1aca43401f8 100644
--- a/TAO/docs/HISTORY
+++ b/TAO/docs/HISTORY
@@ -1,5 +1,3 @@
-@(#)HISTORY	1.1 95/09/13
-
 Mmmmmmmm DD, 1995 -- RELEASE 1.3:
 ---------------------------------
 Release 1.3 includes bugfixes, and support for the COM binary interface
diff --git a/TAO/docs/events_tutorial.html b/TAO/docs/events_tutorial.html
index 099bf1bd3ef..e171be0693d 100644
--- a/TAO/docs/events_tutorial.html
+++ b/TAO/docs/events_tutorial.html
@@ -16,7 +16,7 @@ bgcolor="#ffffff">
 <h1>Using the Real-Time Event Service</h1><P>
 
 <A HREF="http://www.cs.wustl.edu/~cdgill/">Chris Gill</a>,
-<A HREF="http://www.cs.wustl.edu/~harrison/">Tim Harrison</a>, and 
+<A HREF="http://www.cs.wustl.edu/~harrison/">Tim Harrison</a>, and
 <A HREF="http://www.cs.wustl.edu/~coryan/">Carlos O'Ryan</a><br><br>
 
 <A HREF="mailto:cdgill@cs.wustl.edu">cdgill@cs.wustl.edu</a>,
@@ -55,12 +55,12 @@ bgcolor="#ffffff">
 <tr><td>
 <h3>Introduction</h3>
 <BR>
-This material is intended to provide an introduction to the COS Event Model, 
+This material is intended to provide an introduction to the COS Event Model,
 the Real-Time extensions to that model in TAO, and a set of examples that
 illustrate the techniques used to build systems using these models. The CORBA
 Event Service provides a flexible model for asynchronous communication  among
 objects.  However, the standard CORBAEvent Service specification lacks
-important features required by real-time applications. These features include 
+important features required by real-time applications. These features include
 event filtering, event correlation, and periodic event processing.<P>
 
 The standard CORBA operation invocation model supports twoway, oneway,
@@ -78,7 +78,7 @@ models lack asynchronous message delivery, do not support timed
 invocations or group communication, and can lead to excessive polling
 by clients.  Moreover, standard oneway invocations might not implement
 reliable delivery and deferred synchronous invocations require the use
-of the CORBA Dynamic Invocation Interface (DII), which yields 
+of the CORBA Dynamic Invocation Interface (DII), which yields
 <A HREF="http://www.cs.wustl.edu/~schmidt/GLOBECOM-96.ps.gz">excessive
 overhead</A> for most real-time applications. <P>
 
@@ -124,36 +124,36 @@ The role of each component in the COS Event Model is outlined
 below:<P>
 
 <ul>
-  <li> <b><i>EventChannel</i></b> -- The EventChannel interface provides 
+  <li> <b><i>EventChannel</i></b> -- The EventChannel interface provides
        two factory methods, which allow applications to obtain consumer and
        supplier administration objects, respectively, and use them to create
        the other objects described below, to connect to the event channel. <P>
 
-  <li> <b><i>SupplierAdmin</i></b> -- The SupplierAdmin interface provides 
+  <li> <b><i>SupplierAdmin</i></b> -- The SupplierAdmin interface provides
        factory methods which create the appropriate supplier proxy objects. <P>
 
   <li> <b><i>ConsumerAdmin</i></b> -- The ConsumerAdmin interface provides
        factory methods which create the appropriate consumer proxy objects. <P>
 
-  <li> <b><i>ProxyPullSupplier</i></b> -- The ProxyPullSupplier 
+  <li> <b><i>ProxyPullSupplier</i></b> -- The ProxyPullSupplier
        interface is used by consumers in the pull model to connect and
        disconnect from the channel. This interface inherits from the
        PullSupplier interface, and acts as a proxy for the suppliers
        from which the channel will pull events. <P>
 
-  <li> <b><i>ProxyPushSupplier</i></b> -- The ProxyPushSupplier 
+  <li> <b><i>ProxyPushSupplier</i></b> -- The ProxyPushSupplier
        interface is used by consumers in the push model to connect and
        disconnect from the channel. This interface inherits from the
        PushSupplier interface, and acts as a proxy for the suppliers
        which will push events to the channel. <P>
 
-  <li> <b><i>ProxyPullConsumer</i></b> -- The ProxyPullConsumer 
+  <li> <b><i>ProxyPullConsumer</i></b> -- The ProxyPullConsumer
        interface is used by suppliers in the pull model to connect and
        disconnect from the channel. This interface inherits from the
        PullConsumer interface, and acts as a proxy for the consumers
        on whose behalf the channel will pull events. <P>
 
-  <li> <b><i>ProxyPushConsumer</i></b> -- The ProxyPushConsumer 
+  <li> <b><i>ProxyPushConsumer</i></b> -- The ProxyPushConsumer
        interface is used by suppliers in the push model to connect and
        disconnect from the channel. This interface inherits from the
        PushConsumer interface, and acts as a proxy for the consumers
@@ -214,7 +214,7 @@ below:<P>
 
   <li> <b><i>Suspend/resume</i></b> -- If a consumer's event
        dependencies change at run-time, it can utilize the
-       suspend/resume functionality through the new 
+       suspend/resume functionality through the new
        <code>ProxyPushSupplier::suspend</code> and
        <code>ProxyPushSupplier::resume</code> methods.  When a
        consumer invokes <code>ProxyPushSupplier::suspend</code>, the
@@ -234,7 +234,7 @@ based on these registrations, to ensure efficient event delivery.<P>
 
 <LI> <B><I>Event correlation</I></B> -- Consumers may register
 for event delivery based on conjunctive or disjunctive sets of events.  Conjunctive
-registrations cause the event channel to notify the consumer when <I>all</I> 
+registrations cause the event channel to notify the consumer when <I>all</I>
 events in the set have arrived.  Disjunctive registrations cause the event channel
 to notify the consumer when <I>any</I> event in the set has arrived.<P>
 
@@ -242,7 +242,7 @@ to notify the consumer when <I>any</I> event in the set has arrived.<P>
 may register for suppliers based on timed events.  Periodic suppliers push events
 into the channel at well defined intervals.<P>
 
-  <LI> <B><I>Active consumers and suppliers</I></B> -- See 
+  <LI> <B><I>Active consumers and suppliers</I></B> -- See
        <a href="events_tutorial.html#Section3">The Real-Time Event Service</a><P>.
 
 </ul>
@@ -274,7 +274,7 @@ into the channel at well defined intervals.<P>
 	 <LI> Source/type-based filtering<P>
 	 <LI> Conjunction/Disjunction (AND/OR) correlations<P>
        </ul>
-	      
+
   <li> Periodic and Aperiodic processing <P>
        <UL>
 	 <LI> Canonical timeouts<P>
@@ -302,30 +302,30 @@ into the channel at well defined intervals.<P>
 <h3>Characteristics of Real-Time Push Event Service Participants</h3>
 
 <tr><td>
-Two major roles are played by the participants in a real-time push event 
-service.<P>  
+Two major roles are played by the participants in a real-time push event
+service.<P>
 
 <tr><td>
-The first role is that of an event consumer, which receives events from the 
+The first role is that of an event consumer, which receives events from the
 event channel.  A consumer specifies the type and/or source id for each event
 it is interested in receiving.<P>
 
-In hard real-time applications, a consumer must also specify RT_Info data for 
+In hard real-time applications, a consumer must also specify RT_Info data for
 each event it is interested in receiving, and any other events on which that
 event depends.  The RT_Info structure resides in the Scheduler, and is
-accessed through the scheduler interface. A unique handle is returned to the 
-consumer when an RT_Info is created, which can then be used to set the 
+accessed through the scheduler interface. A unique handle is returned to the
+consumer when an RT_Info is created, which can then be used to set the
 information in the RT_Info.  An RT_Info handle may also be obtained via the
 Scheduler's lookup method.<P>
 
 <tr><td>
-The second role is that of an event supplier, which generates events and 
+The second role is that of an event supplier, which generates events and
 passes them into the event channel.  A supplier must specify its source id,
 and the type of each event it will generate.
 
 <tr><td>
 In hard real-time applications, a supplier must also specify RT_Info data for
-the events it will generate.  In particular, it must specify the maximum rate 
+the events it will generate.  In particular, it must specify the maximum rate
 at which it will generate each event.  This information is used by a real-time
 scheduler to assign appropriate dispatch priorities.<P>
 
@@ -349,7 +349,7 @@ which produces events in its own thread. Both consume events and produce events.
 <tr>
 <th>EC Roles
 <th>RT_Info Contents
-<th>Domain Examples 
+<th>Domain Examples
 </tr>
 
 <tr>
@@ -373,7 +373,7 @@ which produces events in its own thread. Both consume events and produce events.
 <tr>
 <td> Supplier
 <td> rate
-<td> Operator Control Panel, EC Reactor Threads 
+<td> Operator Control Panel, EC Reactor Threads
 </tr>
 
 </table></center>
@@ -400,7 +400,7 @@ which produces events in its own thread. Both consume events and produce events.
 </tr>
 
 <tr>
-<td> Supplier/Consumer  
+<td> Supplier/Consumer
 <td> internal node
 </tr>
 
@@ -507,26 +507,26 @@ which produces events in its own thread. Both consume events and produce events.
 <center><h3><a name="Section4_1">Providing QoS Information</a><h3></center><p>
 
 <tr><td>
-The following steps are only necessary for applications that make use of the 
-Event Service's hard real-time features.  Applications that do not need these 
-features and are configured with a null scheduler may skip the following 
+The following steps are only necessary for applications that make use of the
+Event Service's hard real-time features.  Applications that do not need these
+features and are configured with a null scheduler may skip the following
 operations on the scheduling server.
 
 <tr><td>
-For each operation, a Consumer should provide the worst case, expected, and 
-cached execution time for that operation.  It must also specify criticality and 
-importance values for each operation.  A real-time scheduler uses this information 
+For each operation, a Consumer should provide the worst case, expected, and
+cached execution time for that operation.  It must also specify criticality and
+importance values for each operation.  A real-time scheduler uses this information
 to order dispatches within a set of operations whose dependencies have been met.
 
 <tr><td>
-If it is a Consumer/Supplier (one which consumes an event and passively generates 
+If it is a Consumer/Supplier (one which consumes an event and passively generates
 one or more events from the thread in which it was called, as illustrated in the
 tables above), it must provide dependencies on one or more other events to the
-scheduler.  
+scheduler.
 
 <tr><td>
-If it is a Supplier/Consumer (one which consumes an event and actively generates 
-one or more events from its own thread, as illustrated in the tables above), it 
+If it is a Supplier/Consumer (one which consumes an event and actively generates
+one or more events from its own thread, as illustrated in the tables above), it
 must also specify the rate at which it will generate the new events by passing a
 positive value in the period argument to the scheduler set method.  It may also
 indicate a positive number of threads in which the dispatch will be made.  If the
@@ -548,24 +548,24 @@ defaults to 1.
 
   // Create new RT_Info descriptors for three events.
 
-  RtecScheduler::handle_t handle1 = 
+  RtecScheduler::handle_t handle1 =
     server->create ("event_1",              // Name of entry point
                     TAO_TRY_ENV             // Environment
                    );
-      
-  RtecScheduler::handle_t handle2 = 
+
+  RtecScheduler::handle_t handle2 =
     server->create ("event_2",              // Name of entry point
                     TAO_TRY_ENV             // Environment
                    );
 
-  RtecScheduler::handle_t handle3 = 
+  RtecScheduler::handle_t handle3 =
     server->create ("event_3",              // Name of entry point
                     TAO_TRY_ENV             // Environment
                    );
 
 
   // Register as a consumer/supplier: act as a supplier of event_1 but with
-  // a consumer dependency on event_3.  Therefore, the actual period and 
+  // a consumer dependency on event_3.  Therefore, the actual period and
   // number of threads for event_1 depends on the characteristics of event_3.
   server->set (handle1,                     // RT_Info handle
                RtecScheduler::HIGH_CRITICALITY,   // Criticality
@@ -626,8 +626,8 @@ defaults to 1.
 </h3>
 
 <tr><td>
-The following code is derived from the EC_Throughput consumer code, which can be 
-found in TAO in the file: 
+The following code is derived from the EC_Throughput consumer code, which can be
+found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a>
 
@@ -647,7 +647,7 @@ Test_Consumer::connect (const char* name,
   // configured with a null scheduler may skip the following operations on the
   // scheduling server.
 
-  // Obtain a reference to the scheduler from the ACE_Scheduler_Factory. 
+  // Obtain a reference to the scheduler from the ACE_Scheduler_Factory.
   RtecScheduler::Scheduler_ptr server =
     ACE_Scheduler_Factory::server ();
 
@@ -657,7 +657,7 @@ Test_Consumer::connect (const char* name,
     server->create (name, _env);
   TAO_CHECK_ENV_RETURN_VOID(_env);
 
-  // Set the attributes for the RT_Info.  
+  // Set the attributes for the RT_Info.
   ACE_Time_Value tv (0, 2000);
   TimeBase::TimeT time;
   ORBSVCS_Time::Time_Value_to_TimeT (time, tv);
@@ -673,7 +673,7 @@ Test_Consumer::connect (const char* name,
   TAO_CHECK_ENV_RETURN_VOID(_env);
 
   // Specify a disjunctive dependency on the arrival of event_a, the arrival
-  // of event b, OR the arrival of an event service shutdown event.  Note that 
+  // of event b, OR the arrival of an event service shutdown event.  Note that
   // the same RT_Info is used for each event.  This can be used to simplify
   // code in applications using a null scheduler, or to consolidate events
   // with identical characteristics in hard real-time applications.
@@ -710,7 +710,7 @@ Test_Consumer::connect (const char* name,
 
 <tr><td>
 The following code is derived from the EC_Throughput consumer driver code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer_Driver.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer_Driver.cpp</a>
 
@@ -777,7 +777,7 @@ ECT_Consumer_Driver::run (int argc, char* argv[])
 
       // Use the Naming Service to locate the Scheduling Service and
       // use the Scheduler_Factory to keep a global pointer to the
-      // latter. 
+      // latter.
 
       // Initialize the scheduler factory to operate in configuration mode.
       if (ACE_Scheduler_Factory::use_config (naming_context.in ()) == -1)
@@ -857,7 +857,7 @@ ECT_Consumer_Driver::run (int argc, char* argv[])
 
 <tr><td>
 The following code is derived from the EC_Throughput consumer code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a>
 
@@ -922,8 +922,8 @@ Test_Consumer::push (const RtecEventComm::EventSet& events,
 </h3>
 
 <tr><td>
-The following code is derived from the EC_Throughput consumer code, which can be 
-found in TAO in the file: 
+The following code is derived from the EC_Throughput consumer code, which can be
+found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a>
 
@@ -954,11 +954,11 @@ Test_Consumer::disconnect (CORBA::Environment &_env)
   // transit.
 
   // Without a flushing protocol we need to deactivate the
-  // servant to stop accepting push () requests for any 
+  // servant to stop accepting push () requests for any
   // incoming events.
 
   // Deactivate the servant
-  PortableServer::POA_var poa = 
+  PortableServer::POA_var poa =
     this->_default_POA (_env);
   TAO_CHECK_ENV_RETURN_VOID (_env);
   PortableServer::ObjectId_var id =
@@ -1010,7 +1010,7 @@ set of operations whose dependencies have been met.
 The Event Service matches supplier publications with consumer subscriptions to
 provide efficient event filtering. Providing incorrect publications or
 subscriptions will result in missed events.  The Event Service also uses the
-subscription information to create additional dependencies between registered 
+subscription information to create additional dependencies between registered
 RT_Infos.  Thus, providing correct supplier publication and consumer
 subscription information is also critical for correct scheduling in hard
 real-time applications.
@@ -1037,12 +1037,12 @@ server.
 
   // Create new RT_Info descriptors for two events.
 
-  RtecScheduler::handle_t handle0 = 
+  RtecScheduler::handle_t handle0 =
     server->create ("event_0",              // Name of entry point
                     TAO_TRY_ENV             // Environment
                    );
 
-  RtecScheduler::handle_t handle1 = 
+  RtecScheduler::handle_t handle1 =
     server->create ("event_1",              // Name of entry point
                     TAO_TRY_ENV             // Environment
                    );
@@ -1086,7 +1086,7 @@ server.
 
 <tr><td>
 The following code is derived from the EC_Throughput supplier code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a>
 
@@ -1114,18 +1114,18 @@ Test_Supplier::connect (const char* name,
   this->burst_pause_ = burst_pause;
   this->event_a_ = event_a;
   this->event_b_ = event_b;
-   
+
   // Register operations with the scheduling service.  The following steps are
   // only necessary for applications that make use of the Event Service's hard
   // real-time features.  Applications that do not need these features and are
   // configured with a null scheduler may skip the following operations on the
   // scheduling server.
 
-  // Obtain a reference to the scheduling service. 
+  // Obtain a reference to the scheduling service.
   RtecScheduler::Scheduler_ptr server =
     ACE_Scheduler_Factory::server ();
 
-  // Create an RT_Info descriptor for the passed operation name. 
+  // Create an RT_Info descriptor for the passed operation name.
   RtecScheduler::handle_t rt_info =
     server->create (name, _env);
   TAO_CHECK_ENV_RETURN_VOID (_env);
@@ -1149,7 +1149,7 @@ Test_Supplier::connect (const char* name,
                _env);
   TAO_CHECK_ENV_RETURN_VOID (_env);
 
-  // Now, create a supplier id, and publish the events 
+  // Now, create a supplier id, and publish the events
   // that will be supplied under this id.
 
   // Create a supplier id from the passed name
@@ -1169,7 +1169,7 @@ Test_Supplier::connect (const char* name,
               ACE_ES_EVENT_SHUTDOWN,
               rt_info, 1);
 
-  // And finally, some boiler plate code to connect a supplier 
+  // And finally, some boiler plate code to connect a supplier
   // to the Event Service.  This is where the connection is
   // actually made.
 
@@ -1200,7 +1200,7 @@ Test_Supplier::connect (const char* name,
 
 <tr><td>
 The following code is derived from the EC_Throughput supplier driver code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier_Driver.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier_Driver.cpp</a>
 
@@ -1268,7 +1268,7 @@ ECT_Supplier_Driver::run (int argc, char* argv[])
 
       // Use the Naming Service to locate the Scheduling Service and
       // use the Scheduler_Factory to keep a global pointer to the
-      // latter. 
+      // latter.
 
       // Initialize the scheduler factory to operate in configuration mode.
       if (ACE_Scheduler_Factory::use_config (naming_context.in ()) == -1)
@@ -1351,7 +1351,7 @@ ECT_Supplier_Driver::run (int argc, char* argv[])
 
 <tr><td>
 The following code is derived from the EC_Throughput supplier code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a>
 
@@ -1415,12 +1415,12 @@ Test_Supplier::svc ()
 
               TAO_CHECK_ENV;
             }
- 
+
           // Sleep until it's time to send the next burst.
           ACE_OS::sleep (tv);
         }
 
-      // Send a "magic" type of event to inform the consumer that we are 
+      // Send a "magic" type of event to inform the consumer that we are
       // not sending anything else...
 
       // Send one event shutdown from each supplier
@@ -1428,7 +1428,7 @@ Test_Supplier::svc ()
       this->consumer_proxy ()->push(event, TAO_TRY_ENV);
       TAO_CHECK_ENV;
       this->timer_.stop ();
-      
+
     }
   TAO_CATCH (CORBA::SystemException, sys_ex)
     {
@@ -1455,7 +1455,7 @@ Test_Supplier::svc ()
 
 <tr><td>
 The following code is derived from the EC_Throughput supplier code, which
-can be found in TAO in the file: 
+can be found in TAO in the file:
 <A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp">
 $TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a>
 
@@ -1478,13 +1478,13 @@ Test_Supplier::disconnect (CORBA::Environment &_env)
   this->consumer_proxy_ =
     RtecEventChannelAdmin::ProxyPushConsumer::_nil ();
 
-  // We need to stop accepting disconnect_push_supplier () requests 
+  // We need to stop accepting disconnect_push_supplier () requests
   // for this supplier, before it is safe to destroy the supplier.
   // As required by the CORBA spec, you must explicitly deactivate
   // a servant before destroying it.
 
   // Deactivate the servant
-  PortableServer::POA_var poa = 
+  PortableServer::POA_var poa =
     this->supplier_._default_POA (_env);
   TAO_CHECK_ENV_RETURN_VOID (_env);
   PortableServer::ObjectId_var id =
@@ -1511,7 +1511,7 @@ Test_Supplier::disconnect (CORBA::Environment &_env)
 <BR>
 
 The following code is derived from the Event_Service executable, which can be
-found in TAO in the file: 
+found in TAO in the file:
 <A HREF="../orbsvcs/Event_Service/Event_Service.cpp">
 $TAO_ROOT/orbsvcs/Event_Service/Event_Service.cpp</a>
 
@@ -1571,8 +1571,8 @@ int main (int argc, char *argv[])
       RtecScheduler::Scheduler_var scheduler;
 
 
-      // Create a new servant to implement the Scheduling Service, 
-      // register it with the Naming Service, and use the 
+      // Create a new servant to implement the Scheduling Service,
+      // register it with the Naming Service, and use the
       // Scheduler_Factory to keep a global pointer to the new
       // Scheduling Service.
 
@@ -1655,8 +1655,8 @@ int main (int argc, char *argv[])
       if (orb->run () == -1)
         ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "run"), 1);
 
-      // Now the Event Service is finished.  We could deactivate the 
-      // EC and SS here, but we don't need to, as the server is 
+      // Now the Event Service is finished.  We could deactivate the
+      // EC and SS here, but we don't need to, as the server is
       // going down anyway.
 
 
@@ -1696,30 +1696,30 @@ int main (int argc, char *argv[])
 <tr><td>
 <h2><a name="Section7">Sample Applications</a></h2>
 
-<tr><td> 
-A number of sample applications are available in the directories under 
+<tr><td>
+A number of sample applications are available in the directories under
 <a href="../orbsvcs/tests/">
 TAO's ORB Services tests</a>.
 
 <tr><td>
 In particular, much of the code shown in this tutorial was drawn from the
-<a href="../orbsvcs/tests/EC_Throughput/"> 
+<a href="../orbsvcs/tests/EC_Throughput/">
 EC_Throughput</a> test.  This test exercises the Event Service and measures its
 throughput capabilities.
 
 <tr><td>
 A similar test,
-<a href="../orbsvcs/tests/Event_Latency/"> 
+<a href="../orbsvcs/tests/Event_Latency/">
 Event_Latency</a>, measures the latency of events through the Event Service.
 
 <tr><td>
 The
-<a href="../orbsvcs/tests/EC_Basic/"> 
+<a href="../orbsvcs/tests/EC_Basic/">
 EC_Basic</a> test demonstrates the basic use the Event Service.
 
 <tr><td>
 The
-<a href="../orbsvcs/tests/EC_Multiple/"> 
+<a href="../orbsvcs/tests/EC_Multiple/">
 EC_Multiple</a> test shows a number of ways to connect multiple Event Channels.
 
 
@@ -1742,27 +1742,27 @@ and
 <tr><td>
 <h2><a name="Section8">Reference Materials</a></h2>
 
-<tr><td> 
+<tr><td>
 The following materials were used in developing this tutorial: please refer to them for further information.
 
-<tr><td> 
+<tr><td>
 <br>
-<tr><td> 
+<tr><td>
 <h3>Books</h3>
 
-<tr><td> 
-Mowbray, T. and Zahavi, R. The Essential CORBA, Systems Integration Using Distributed Objects.  Wiley, 1995. 
+<tr><td>
+Mowbray, T. and Zahavi, R. The Essential CORBA, Systems Integration Using Distributed Objects.  Wiley, 1995.
 ISBN 0-471-10611-9
 
-<tr><td> 
+<tr><td>
 <br>
 
-<tr><td> 
+<tr><td>
 Baker, S.  CORBA Distributed Objects Using Orbix.  Addison-Wesley, 1997.  ISBN 0-201-92475-7
 
-<tr><td> 
+<tr><td>
 <br>
-<tr><td> 
+<tr><td>
 <h3>Papers</h3>
 
 <tr><td>
@@ -1792,7 +1792,6 @@ Design of the TAO Real-Time Object Request Broker</a>
 
 <center><table cellpadding=1 border=0 cellspacing=4>
 <tr><td>
-Last modified 10:50:30 CST 22 December 1998 by Chris Gill
 </table></center>
 
 </body></html>
diff --git a/TAO/docs/ior_parsing.html b/TAO/docs/ior_parsing.html
index ad9250f59b7..a18b8e01f54 100644
--- a/TAO/docs/ior_parsing.html
+++ b/TAO/docs/ior_parsing.html
@@ -218,9 +218,5 @@ static Resource_Factory "-ORBIORPaser HTTP_Parser"
 
     <hr>
     <address><a href="mailto:coryan@uci.edu">Carlos O'Ryan</a></address>
-<!-- Created: Tue Feb 20 08:42:57 PST 2001 -->
-<!-- hhmts start -->
-Last modified: Tue Feb 20 16:32:13 PST 2001
-<!-- hhmts end -->
   </body>
 </html>