Merge lp:~johill-lanl/epics-base/ca-ref-man-maint into lp:~epics-core/epics-base/3.15

[Jeff Hill]

This syncs the changes in the ca reference manual on the cvs main trunk with the main trunk at launchpad

[Ralph Lange (ralph-lange)]

In a lot of places, apostrophes (') are replaced by a right-single-quote character (’). This is wrong, as an apostophe is syntactically and semantically a different character than a single quote. (See http://en.wikipedia.org/wiki/Apostrophe for details.)

In line 2530, the − should be a &endash;.

In line 2884, the <span style="font-style: italic;"></span> should rather be be <em></em>.

In line 2884, last paragraph: "it's" -> "its", add a comma after "set to false".

Both "nil" and "nill" seem to be used in the document for a null pointer. Maybe straighten that out globally.

Apart from that, the changes look fine to me.

review: Needs Fixing

[Andrew Johnson (anj)]

Actually Ralph's en dash (the HTML entity name is actually &ndash; BTW) should IMHO be an &mdash; — here it "demarcates a break of thought or some similar interpolation (stronger than the interpolation demarcated by parentheses)" to quote Wikipedia again, from http://en.wikipedia.org/wiki/Dash#Em_dash

There are other <span style="font-style: italic;"></span> sections in addition to the one Ralph pointed out that similarly should be marked up using <em></em>.

Other than that, I agree with all Ralph's points.

[Ralph Lange (ralph-lange)]

But, the same Wikipedia article says further down (http://en.wikipedia.org/wiki/Dash#En_dash_versus_em_dash) that the "spaced en dash" is recommended by a number of style guides as an visually more pleasing replacement for the em dash (which is typically not surrounded by spaces).

The traditional US way is the unspaced em dash (that I personally always consider very strange when reading books printed in the US), while the British style guides and publishers favour the spaced en dash.
Boils down to: how British are you? ;-)

As always in these fuzzy questions: pick a style, and use it consistently.

[lp:~johill-lanl/epics-base/ca-ref-man-maint]

12223. By Jeff Hill on 2013-11-07

responded to Ralph and Andrew's comments

[Jeff Hill (johill-lanl)]

Ok, I believe that I have fixed all of it; now you have bigger changes to review ;-)

[Andrew Johnson (anj)]

Now the original apostrophes (' = 0x27) have been replaced by a back-quote character (` = 0x60) which is just as wrong as the right-single-quote HTML entity was.

Many HTML entities such as &copy; and &uuml; in the original have also been replaced by single character equivalents, which are correct for the iso-8859-1 charset that the HTML head block says that the file uses, but I much prefer that we use entities for all non-ASCII characters so there is no danger of problems if someone edits the file in a UTF-8 editor or using some other code-page. I'm not sure what editor you're using for this, but please try to configure it to use HTML entities in preference to all characters outside of the common 7-bit range.

However I have extracted your changes by hand, undone the apostrope and entity stuff and merged the rest into the 3.14 version of CAref.html. They will appear in the 3.15 version in due course (Bazaar is currently having a little difficulty with merging the 3.14 branch into 3.15). The result also contains a few other changes that we have made to the file since you last worked on it.

review: Approve

=== modified file 'src/ca/client/CAref.html'
--- src/ca/client/CAref.html	2013-07-05 18:26:26 +0000
+++ src/ca/client/CAref.html	2013-11-07 19:43:28 +0000
@@ -7,8 +7,8 @@
   <style type="text/css">
   <!--
 h3 code {
-  background-color: #ddf;
-  font-size: larger;
+background-color: #ddf;
+font-size: larger;
 }
 -->
 
@@ -20,30 +20,30 @@
 
 <h1>EPICS R3.14 Channel Access Reference Manual</h1>
 <address>
-  Jeffrey O. Hill
+  Jeffrey O. Hill 
 </address>
 
 <p><span style="font-size: x-small; font-weight:lighter;">Los Alamos National
 Laboratory, SNS Division</span></p>
 <address>
-  Ralph Lange
+  Ralph Lange 
 </address>
 
 <p><span style="font-size: x-small; font-weight:lighter;">Helmholtz-Zentrum
 Berlin (BESSY II)</span></p>
 
-<p><span style="font-size: xx-small; font-weight:lighter;">Copyright &copy; 2009
-Helmholtz-Zentrum Berlin f&uuml;r Materialien und Energie GmbH.<br>
-Copyright &copy; 2002 The University of Chicago, as Operator of Argonne National
+<p><span style="font-size: xx-small; font-weight:lighter;">Copyright © 2009
+Helmholtz-Zentrum Berlin für Materialien und Energie GmbH.<br>
+Copyright © 2002 The University of Chicago, as Operator of Argonne National
 Laboratory.<br>
-Copyright &copy; 2002 The Regents of the University of California, as Operator of
+Copyright © 2002 The Regents of the University of California, as Operator of
 Los Alamos National Laboratory.<br>
-Copyright &copy; 2002 Berliner Speicherringgesellschaft f&uuml;r Synchrotronstrahlung
+Copyright © 2002 Berliner Speicherringgesellschaft für Synchrotronstrahlung
 GmbH.</span></p>
 
 <p><span style="font-size: xx-small; font-weight:lighter;">EPICS BASE is
-distributed subject to a Software License Agreement found
-in the file LICENSE that is included with this distribution.</span></p>
+distributed subject to a Software License Agreement found in the file LICENSE
+that is included with this distribution.</span></p>
 
 <p><a href="http://www.w3.org/Amaya/"><img
 src="http://www.w3.org/Amaya/Icons/w3c-amaya.gif" alt="W3C-Amaya" height="31"
@@ -107,17 +107,17 @@
 
 <h3><a href="#Troubleshooting">Troubleshooting</a></h3>
 <ul>
-  <li><a href="#When">When Clients Do Not Connect to Their Server</a>
+  <li><a href="#When">When Clients Do Not Connect to Their Server</a> 
     <ul>
       <li><a href="#Broadcast">Client and Server Broadcast Addresses Dont
         Match</a></li>
-      <li><a href="#Client">Client Isnt Configured to Use the Server's
+      <li><a href="#Client">Client Isnt Configured to Use the Server`s
       Port</a></li>
       <li><a href="#Unicast">Unicast Addresses in the EPICS_CA_ADDR_LIST Does
         not Reliably Contact Servers Sharing the Same UDP Port on the Same
         Host</a></li>
-      <li><a href="#Client1">Client Does not See Server's Beacons</a></li>
-      <li><a href="#Server1">A server's IP address was changed</a></li>
+      <li><a href="#Client1">Client Does not See Server`s Beacons</a></li>
+      <li><a href="#Server1">A server`s IP address was changed</a></li>
     </ul>
   </li>
   <li><a href="#Requests">Put Requests Just Prior to Process Termination Appear
@@ -165,7 +165,8 @@
   <li><a href="#ca_pend_io">block for certain requests to complete</a></li>
   <li><a href="#ca_test_io">test to see if certain requests have
   completed</a></li>
-  <li><a href="#ca_pend_event">process CA client library background activities</a></li>
+  <li><a href="#ca_pend_event">process CA client library background
+    activities</a></li>
   <li><a href="#ca_flush_io">flush outstanding requests to the server</a></li>
   <li><a href="#ca_add_exception_event">replace the default exception
     handler</a></li>
@@ -246,7 +247,11 @@
 
 <h3>Why Reconfigure Channel Access</h3>
 
+<<<<<<< TREE
 <p>Typical reasons to reconfigure EPICS Channel Access:</p>
+=======
+<p>Typicall reasons to reconfigure EPICS Channel Access:</p>
+>>>>>>> MERGE-SOURCE
 <ul>
   <li>Two independent control systems must share a network without fear of
     interaction</li>
@@ -363,9 +368,8 @@
 servers that host the channels identified. Likewise CA clients efficiently
 discover that CA servers have recently joined the LAN or disconnected from the
 LAN by monitoring periodically broadcasted beacons sent out by the servers.
-Since hardware broadcasting requires special hardware capabilities, we are
-required to provide additional configuration information when EPICS is extended
-to operate over a wide area network (WAN).</p>
+However, additional configuration is required when EPICS is extended to operate
+over a wide area network (WAN).</p>
 
 <h3><a name="Network">IP Network Administration Background Information</a></h3>
 
@@ -374,7 +378,7 @@
 is determined by the IP netmask. Portions of the IP address corresponding to
 zeros in the netmask specify the hosts address within an IP subnet. Portions of
 the IP address corresponding to binary ones in the netmask specify the address
-of a host's IP subnet. Normally the scope of a broadcasted frame will be
+of a host`s IP subnet. Normally the scope of a broadcasted frame will be
 limited to one IP subnet. Addresses with the host address portion set to all
 zeros or all ones are special. Modern IP kernel implementations reserve
 destination addresses with the host portion set to all ones for the purpose of
@@ -454,6 +458,7 @@
 
 <h3><a name="firewall">Firewalls</a></h3>
 
+<<<<<<< TREE
 <p>If you want channel access clients on a machine to be able to see
 beacons and replies to broadcast PV search requests, you need to permit
 inbound UDP packets with source port EPICS_CA_SERVER_PORT (default is 5064)
@@ -464,8 +469,18 @@
      -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT
      -A INPUT -s 192.168.0.0/22 -p udp --dport 5065 -j ACCEPT
 </pre>
+=======
+<p>If you want channel access clients on a machine to be able to see beacons
+and replies to broadcast PV search requests you need to permit inbound UDP
+packets with source port EPICS_CA_SERVER_PORT (default is 5064) or destination
+port EPICS_CA_REPEATER_PORT (default is 5065). On systems using iptables this
+can be accomplished by rules like</p>
+<pre>     -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT
+     -A INPUT -s 192.168.0.0/22 -p udp --dport 5065 -j ACCEPT</pre>
+>>>>>>> MERGE-SOURCE
 
 <p>If you want channel access servers (e.g. "soft IOCs") on a machine to be
+<<<<<<< TREE
 able to be seen by clients, you need to permit inbound TCP or UDP packets with
 destination port EPICS_CA_SERVER_PORT (default is 5064).
 On systems using iptables this can be accomplished by rules like</p>
@@ -474,6 +489,13 @@
      -A INPUT -s 192.168.0.0/22 -p udp --dport 5064 -j ACCEPT
      -A INPUT -s 192.168.0.0/22 -p tcp --dport 5064 -j ACCEPT
 </pre>
+=======
+able to see clients you need to permit inbound TCP or UDP packets with source
+port EPICS_CA_SERVER_PORT (default is 5064). On systems using iptables this can
+be accomplished by rules like</p>
+<pre>     -A INPUT -s 192.168.0.0/22 -p udp --dport 5064 -j ACCEPT
+     -A INPUT -s 192.168.0.0/22 -p tcp --dport 5064 -j ACCEPT</pre>
+>>>>>>> MERGE-SOURCE
 
 <p>In all cases the "-s 192.168.0.0/22" specifies the range of addresses from
 which you wish to accept packets.</p>
@@ -488,7 +510,7 @@
 resolution (search) request contains a list of Process Variable names.If one of
 the servers reachable by this address list knows the IP address of a CA server
 that can service one or more of the specified Process Variables, then it sends
-back a response containing the server's IP address and port number.</p>
+back a response containing the server`s IP address and port number.</p>
 
 <p>During initialization CA builds the list of server destination addresses
 used when sending CA client name resolution (search) requests. This table is
@@ -497,10 +519,9 @@
 broadcast address of that subnet is added to the list. For each point to point
 interface found, the destination address of that link is added to the list.
 This automatic server address list initialization can be disabled if the EPICS
-environment variable EPICS_CA_AUTO_ADDR_LIST exists and its value is either
-of "no" or "NO". The typical default is to enable network interface
-introspection driven initialization with EPICS_CA_AUTO_ADDR_LIST set to "YES"
-or "yes".</p>
+environment variable EPICS_CA_AUTO_ADDR_LIST exists and its value is either of
+"no" or "NO". The typical default is to enable network interface introspection
+driven initialization with EPICS_CA_AUTO_ADDR_LIST set to "YES" or "yes".</p>
 
 <p>Following network interface introspection, any IP addresses specified in the
 EPICS environment variable EPICS_CA_ADDR_LIST are added to the list of
@@ -511,8 +532,8 @@
 EPICS_CA_ADDR_LIST may be dotted IP addresses or host names if the local OS has
 support for host name to IP address translation. When multiple names are added
 to EPICS_CA_ADDR_LIST they must be separated by white space. There is no
-requirement that the addresses specified in the EPICS_CA_ADDR_LIST be
-broadcast addresses, but this will often be the most convenient choice.</p>
+requirement that the addresses specified in the EPICS_CA_ADDR_LIST be broadcast
+addresses, but this will often be the most convenient choice.</p>
 
 <p>For any IP addresses specified in the EPICS environment variable
 EPICS_CA_NAME_SERVERS, TCP connections are opened and used for CA client name
@@ -560,7 +581,7 @@
 <p>Frequently vxWorks systems boot by default with routes limiting access only
 to the local subnet. If a EPICS system is operating in a WAN environment it may
 be necessary to configure routes into the vxWorks system which enable a vxWorks
-based CA server to respond to requests originating outside it's subnet. These
+based CA server to respond to requests originating outside its subnet. These
 routing restrictions can also apply to vxWorks base CA clients communicating
 with off subnet servers. An EPICS system manager can implement an rudimentary,
 but robust, form of access control for a particular host by not providing
@@ -571,7 +592,7 @@
 
 <p>If the CA client library does not see a beacon from a server that it is
 connected to for EPICS_CA_CONN_TMO seconds then an state-of-health message is
-sent to the server over TCP/IP. If this state-of-health message isn't promptly
+sent to the server over TCP/IP. If this state-of-health message isn`t promptly
 replied to then the client library will conclude that channels communicating
 with the server are no longer responsive and inform the CA client side
 application via function callbacks. The parameter EPICS_CA_CONN_TMO is
@@ -588,7 +609,7 @@
 but does not immediately disconnect the TCP circuit. Instead the CA client
 library postpones circuit shutdown until receiving indication of circuit
 disconnect from the IP kernel. This can occur either because a server is
-restarted or because the IP kernel's internal TCP circuit inactivity keep alive
+restarted or because the IP kernel`s internal TCP circuit inactivity keep alive
 timer has expired after a typically long duration (as is appropriate for IP
 based systems that need to avoid thrashing during periods of excessive load).
 The net result is less search and TCP circuit setup and shutdown activity
@@ -624,7 +645,7 @@
 below).</p>
 
 <p>The CA client library continually estimates the beacon period of all server
-beacons received. If a particular server's beacon period becomes significantly
+beacons received. If a particular server`s beacon period becomes significantly
 shorter or longer then the client is said to detect a beacon anomaly. The
 library boosts the search interval for unresolved channels when a beacon
 anomaly is seen or when <em>any</em> successful search response is received,
@@ -634,7 +655,7 @@
 preexisting unresolved channels. The program "casw" prints a message on
 standard out for each CA client beacon anomaly detect event.</p>
 
-<p>See also <a href="#Client1">When a Client Does not See the Server's
+<p>See also <a href="#Client1">When a Client Does not See the Server`s
 Beacon</a>.</p>
 
 <h3><a name="Configurin3" id="Configurin3">Configuring the Maximum Search
@@ -643,7 +664,7 @@
 <p>The rate at which name resolution (search) requests are sent exponentially
 backs off to a plateau rate. The value of this plateau has an impact on network
 traffic because it determines the rate that clients search for channel names
-that are miss-spelled or otherwise don't exist in a server. Furthermore, for
+that are miss-spelled or otherwise don`t exist in a server. Furthermore, for
 clients that are unable to see the beacon from a new server, the plateau rate
 may also determine the maximum interval that the client will wait until
 discovering a new server.</p>
@@ -652,7 +673,7 @@
 seconds is determined by the EPICS_CA_MAX_SEARCH_PERIOD environment
 variable.</p>
 
-<p>See also <a href="#Client1">When a Client Does not See the Server's
+<p>See also <a href="#Client1">When a Client Does not See the Server`s
 Beacon</a>.</p>
 
 <h3><a name="Repeater">The CA Repeater</a></h3>
@@ -764,7 +785,7 @@
 <p>The CA client library uses EPICS_CA_MAX_ARRAY_BYTES to determines the
 maximum array that it will send or receive. Likewise, the CA server uses
 EPICS_CA_MAX_ARRAY_BYTES to determine the maximum array that it may send or
-receive. The client does not influence the server's message size quotas and
+receive. The client does not influence the server`s message size quotas and
 visa versa. In fact the value of EPICS_CA_MAX_ARRAY_BYTES need not be the same
 in the client and the server. If the server receives a request which is too
 large to read or respond to in entirety then it sends an exception message to
@@ -832,14 +853,14 @@
 
 <p>The server configures its port number from the EPICS_CAS_SERVER_PORT
 environment variable if it is specified. Otherwise the EPICS_CA_SERVER_PORT
-environment variable determines the server's port number. Two servers can share
+environment variable determines the server`s port number. Two servers can share
 the same UDP port number on the same machine, but there are restrictions - see
 a <a href="#Unicast">discussion of unicast addresses and two servers sharing
 the same UDP port on the same host</a>.</p>
 
 <h4>Server Beacons</h4>
 
-<p>The EPICS_CAS_BEACON_PERIOD parameter determines the server's beacon period
+<p>The EPICS_CAS_BEACON_PERIOD parameter determines the server`s beacon period
 and is specified in floating point seconds. The default is typically 15
 seconds. See also <a href="#Disconnect">EPICS_CA_CONN_TMO</a> and <a
 href="#Dynamic">Dynamic Changes in the CA Client Library Search
@@ -865,17 +886,17 @@
 list is not augmented.</p>
 
 <p>The EPICS_CAS_BEACON_PORT parameter specifies the destination port for
-server beacons. The only exception to this occurs when  ports are specified
-in EPICS_CAS_BEACON_ADDR_LIST or possibly in EPICS_CA_ADDR_LIST. If
+server beacons. The only exception to this occurs when ports are specified in
+EPICS_CAS_BEACON_ADDR_LIST or possibly in EPICS_CA_ADDR_LIST. If
 EPICS_CAS_BEACON_PORT is not specified then beacons are sent to the port
 specified in EPICS_CA_REPEATER_PORT.</p>
 
 <h4>Binding a Server to a Limited Set of Network Interfaces</h4>
 
 <p>The parameter EPICS_CAS_INTF_ADDR_LIST allows a ca server to bind itself to,
-and therefore accept messages only over, a limited set of the local host's
-network interfaces (each specified by it's IP address). On UNIX systems type
-"netstat -i" (type "ipconfig" on windows) to see a list of the local host's
+and therefore accept messages only over, a limited set of the local host`s
+network interfaces (each specified by its IP address). On UNIX systems type
+"netstat -i" (type "ipconfig" on windows) to see a list of the local host`s
 network interfaces. Specifically, UDP search messages addressed to both the IP
 addresses in EPICS_CAS_INTF_ADDR_LIST and also to the broadcast addresses of
 the corresponding LAN interfaces will be accepted by the server. By default,
@@ -1054,7 +1075,7 @@
 
 <p>CA server beacon anomalies occur when a new server joins the network, a
 server is rebooted, network connectivity to a server is reestablished, or if a
-server's CPU exits a CPU load saturated state.</p>
+server`s CPU exits a CPU load saturated state.</p>
 
 <p>CA clients with unresolved channels reset their search request scheduling
 timers whenever they see a beacon anomaly.</p>
@@ -1159,7 +1180,7 @@
     </tr>
     <tr>
       <td>-d &lt;type&gt;</td>
-      <td>Request specific dbr type; use string (DBR_ prefix may be omitted)
+      <td>Request specific dbr type; use string (DBR_ prefix may be omitted) 
 
         <p>or number of one of the following types:</p>
 
@@ -1604,7 +1625,7 @@
 stdout.</p>
 
 <p>The -s option allows to specify an interest level for calling Channel
-Access' internal report function ca_client_status(), that prints lots of
+Access` internal report function ca_client_status(), that prints lots of
 internal informations on stdout, including environment settings, used CA ports
 etc.</p>
 
@@ -1646,7 +1667,7 @@
 
 <p>This is an example CA server that is sometimes used for testing purposes. An
 example server can be created with the makeBaseApp perl script, as descibed in
-the application Developer's Guide.</p>
+the application Developer`s Guide.</p>
 
 <table border="1">
   <col>
@@ -1832,21 +1853,21 @@
 <h4><a name="Broadcast">Client and Server Broadcast Addresses Dont
 Match</a></h4>
 
-<p>Verify that the broadcast addresses are identical on the server's host and
-on the client's host. This can be checked on UNIX with "netstat -i" or
+<p>Verify that the broadcast addresses are identical on the server`s host and
+on the client`s host. This can be checked on UNIX with "netstat -i" or
 "ifconfig -a"; on vxWorks with ifShow; and on windows with ipconfig. It is
 normal for the broadcast addresses to not be identical if the client and server
 are not directly attached to the same IP subnet, and in this situation the
 EPICS_CA_ADDR_LIST must be set. Otherwise, if the client and server are
 intended to be on the same IP subnet, then the problem may be that the IP
 netmask is incorrectly set in the network interface configuration. On most
-operating systems, when the host's IP address is configured, the host's IP
+operating systems, when the host`s IP address is configured, the host`s IP
 subnet mask is also configured.</p>
 
-<h4><a name="Client">Client Isn't Configured to Use the Server's Port</a></h4>
+<h4><a name="Client">Client Isn`t Configured to Use the Server`s Port</a></h4>
 
 <p>Verify that the client and server are using the same UDP port. Check the
-server's port by running "netstat -a | grep nnn" where nnn is the port number
+server`s port by running "netstat -a | grep nnn" where nnn is the port number
 configured in the client. If you do not set EPICS_CA_SERVER_PORT or
 EPICS_CAS_SERVER_PORT then the default port will be 5064.</p>
 
@@ -1861,20 +1882,20 @@
 existing CA server then both servers will use the same UDP port, and the 2nd
 server will be allocated an ephemeral TCP port. Clients can be configured to
 use the same port number for both servers. They will locate the 2nd server via
-the shared UDP port, and transparently connect to the 2nd server's ephemeral
-TCP port. Be aware however that If there are two server's running on the same
+the shared UDP port, and transparently connect to the 2nd server`s ephemeral
+TCP port. Be aware however that If there are two server`s running on the same
 host sharing the same UDP port then they will both receive UDP search requests
 sent as broadcasts, but unfortunately (due to a weakness of most IP kernel
 implementations) only one of the servers will typically receive UDP search
-requests sent to unicast addresses (i.e. a single specific host's ip
+requests sent to unicast addresses (i.e. a single specific host`s ip
 address).</p>
 
-<h4><a name="Client1">Client Does not See Server's Beacons</a></h4>
+<h4><a name="Client1">Client Does not See Server`s Beacons</a></h4>
 
 <p>Two conclusions deserve special emphasis. <em>First, if a client does not
-see the server's beacons, then it will use additional network and server
+see the server`s beacons, then it will use additional network and server
 resources sending periodic state-of-health messages.</em> <em>Second, if a
-client does not see a newly introduced server's beacon, then it will take up to
+client does not see a newly introduced server`s beacon, then it will take up to
 EPICS_CA_MAX_SEARCH_PERIOD to find that newly introduced server.</em> Also,
 starting with EPICS R3.14.7 the client library does <em>not</em> suspend
 searching for a channel after 100 unsuccessful attempts until a beacon anomaly
@@ -1882,18 +1903,18 @@
 EPICS and it timed out attempting to find a server whoose beacon cant be seen
 by the client library then the client application might need to be restarted in
 order to connect to this new beacon-out-of-range server. The typical situation
-where a client would not see the server's beacon might be when the client isnt
-on the same IP subnet as the server, and the client's EPICS_CA_ADDR_LIST was
-modified to include a destination address for the server, but the server's
-beacon address list was not modified so that it's beacons are received by the
+where a client would not see the server`s beacon might be when the client isnt
+on the same IP subnet as the server, and the client`s EPICS_CA_ADDR_LIST was
+modified to include a destination address for the server, but the server`s
+beacon address list was not modified so that its beacons are received by the
 client.</p>
 
-<h4><a name="Server1">A Server's IP Address Was Changed</a></h4>
+<h4><a name="Server1">A Server`s IP Address Was Changed</a></h4>
 
 <p>When communication over a virtual circuit times out, then each channel
 attached to the circuit enters a disconnected state and the disconnect callback
 handler specified for the channel is called. However, the circuit is not
-disconnected until TCP/IP's internal, typically long duration, keep alive timer
+disconnected until TCP/IP`s internal, typically long duration, keep alive timer
 expires. The disconnected channels remain attached to the beleaguered circuit
 and no attempt is made to search for, or to reestablish, a new circuit. If, at
 some time in the future, the circuit becomes responsive again, then the
@@ -1905,11 +1926,11 @@
 reattempt to find servers for each channel and connect circuits to them.</p>
 
 <p>A well known negative side effect of the above behavior is that CA clients
-will wait the full (typically long) duration of TCP/IP's internal keep alive
+will wait the full (typically long) duration of TCP/IP`s internal keep alive
 timer prior to reconnecting under the following scenario (all of the following
 occur):</p>
 <ul>
-  <li>An server's (IOC's) operating system crashes (or is abruptly turned off)
+  <li>An server`s (IOC`s) operating system crashes (or is abruptly turned off)
     or a vxWorks system is stopped by any means</li>
   <li>This operating system does not immediately reboot using the same IP
     address</li>
@@ -1937,9 +1958,15 @@
 
 <p>Short lived CA client applications that issue a CA put request and then
 immediately exit the process (return from <code>main</code> or call
+<<<<<<< TREE
 <code>exit</code>) may find that there request isn't executed. To guarantee
 that the request is sent call <code>ca_flush_io()</code> followed by
 <code>ca_context_destroy()</code> prior to terminating the process.</p>
+=======
+<code>exit</code>) may find that there request isn`t executed. To guarantee
+that the request is sent call <code>ca_flush</code> followed by
+<code>ca_context_destroy</code> prior to terminating the process.</p>
+>>>>>>> MERGE-SOURCE
 
 <h3><a name="Problems">ENOBUFS Messages</a></h3>
 
@@ -1952,7 +1979,7 @@
 earlier vxWorks versions is rumored to lead to permanent IP communications
 stalls which are resolved only by a system reboot. IP kernels that use mbufs
 frequently allow the initial and maximum number of mbufs to be configured.
-Consult your OS's documentation for configuration procedures which vary between
+Consult your OS`s documentation for configuration procedures which vary between
 OS and even between different versions of the same OS.</p>
 
 <h4>Contributing Circumstances</h4>
@@ -1965,9 +1992,9 @@
     increase the size of the mbuf pool.</li>
 </ul>
 <ul>
-  <li>The server has multiple connections where the server's sustained event
-    (monitor subscription update) production rate is higher than the client's
-    or the network's sustained event consumption rate. This ties up a per
+  <li>The server has multiple connections where the server`s sustained event
+    (monitor subscription update) production rate is higher than the client`s
+    or the network`s sustained event consumption rate. This ties up a per
     socket quota of mbufs for data that are pending transmission to the client
     via the network. In particular, if there are multiple clients that
     subscribe for monitor events but do not call ca_pend_event() or ca_poll()
@@ -1978,7 +2005,7 @@
   <li>The server does not get a chance to run (because some other higher
     priority thread is running) and the CA clients are sending a high volume of
     data over TCP or UDP. This ties up a quota of mbufs for each socket in the
-    server that isn't being reduced by the server's socket read system
+    server that isn`t being reduced by the server`s socket read system
   calls.</li>
 </ul>
 <ul>
@@ -1992,7 +2019,7 @@
   <li>When sites switch to the vxWorks 5.4 IP kernel they frequently run into
     network pool exhaustion problems. This may be because the original vxWorks
     IP kernel expanded the network pool as needed at runtime while the new
-    kernel's pool is statically configured at compile time, and does
+    kernel`s pool is statically configured at compile time, and does
     <em>not</em> expand as needed at runtime. Also, at certain sites problems
     related to vxWorks network driver pool exhaustion have also been reported
     (this can also result in ENOBUF diagnostic messages).</li>
@@ -2017,8 +2044,8 @@
 <p>If the subscription update producer in the server produces subscription
 updates faster than the subscription update consumer in the client consumes
 them, then events have to be discarded if the buffering in the server
-isn't allowed to grow to an infinite size. This is a law of nature
-- based on queuing theory of course.</p>
+isn`t allowed to grow to an infinite size. This is a law of nature
+&ndash; based on queuing theory of course.</p>
 
 <p>What is done depends on the version of the CA server. All server versions
 place quotas on the maximum number of subscription updates allowed on the
@@ -2040,10 +2067,10 @@
 getting time warped, but also guarantees that intervening events are discarded
 until the slow client catches up.</p>
 
-<p>There is currently no message on the IOC's console when a
-particular client is slow on the uptake. A message of this type used to exist
-many years ago, but it was a source of confusion (and what we will call
-message noise) so it was removed. </p>
+<p>There is currently no message on the IOC`s console when a particular
+client is slow on the uptake. A message of this type used to exist many years
+ago, but it was a source of confusion (and what we will call message noise) so
+it was removed. </p>
 
 <p>There is unfortunately no field in the protocol allowing the server to
 indicate that an intervening subscription update was discarded. We should
@@ -2056,12 +2083,12 @@
 <h3><a name="Flushing">Flushing and Blocking</a></h3>
 
 <p>Significant performance gains can be realized when the CA client library
-doesn't wait for a response to return from the server after each request. All
+doesn`t wait for a response to return from the server after each request. All
 requests which require interaction with a CA server are accumulated (buffered)
 and not forwarded to the IOC until one of ca_flush_io, ca_pend_io,
 ca_pend_event, or ca_sg_pend are called allowing several operations to be
 efficiently sent over the network together. Any process variable values written
-into your program's variables by ca_get() should not be referenced by your
+into your program`s variables by ca_get() should not be referenced by your
 program until ECA_NORMAL has been received from ca_pend_io().</p>
 
 <h3><a name="Status">Status Codes</a></h3>
@@ -2076,22 +2103,22 @@
 validity of the request and whether it was successfully enqueued to the server,
 but communication of completion status is deferred until a user callback is
 called, or lacking that an exception handler is called. An error number and the
-error's severity are embedded in CA status (error) constants. Applications
-shouldn't test the success of a CA function call by checking to see if the
+error`s severity are embedded in CA status (error) constants. Applications
+shouldn`t test the success of a CA function call by checking to see if the
 returned value is zero as is the UNIX convention. Below are several methods to
 test CA function returns. See <a href="#ca_signal">ca_signal() and SEVCHK</a>
 for more information on this topic.</p>
-<pre>status = ca_XXXX(); 
+<pre><code>status = ca_XXXX(); 
 SEVCHK( status, "ca_XXXX() returned failure status"); 
 
 if ( status &amp; CA_M_SUCCESS ) { 
-        printf ( "The requested ca_XXXX() operation didn't complete successfully"); 
+        printf ( "The requested ca_XXXX() operation didn`t complete successfully"); 
 } 
 
 if ( status != ECA_NORMAL ) { 
-        printf("The requested ca_XXXX() operation didn't complete successfully because \"%s\"\n",
+        printf("The requested ca_XXXX() operation didn`t complete successfully because \"%s\"\n",
                 ca_message ( status ) ); 
-}</pre>
+}</code></pre>
 
 <h3><a name="Channel">Channel Access Data Types</a></h3>
 
@@ -2251,7 +2278,7 @@
 href="#dbr_size_n">dbr_size_n</a> function can be used to determine the correct
 number of bytes to reserve when there are more than one value field elements in
 a structured CA data type.</p>
-<pre>#include &lt;stdio.h&gt;
+<pre><code>#include &lt;stdio.h&gt;
 #include &lt;stdlib.h&gt;
 
 #include "cadef.h"
@@ -2314,7 +2341,7 @@
     free ( pTD );
 
     return 0;
-}</pre>
+}</code></pre>
 
 <h3><a name="User">User Supplied Callback Functions</a></h3>
 
@@ -2324,16 +2351,16 @@
 asynchronous completion via this mechanism. The <code>event_handler_args
 </code>structure is passed <em>by value</em> to the application supplied
 callback. In this structure the <code>dbr</code> field is a void pointer to any
-data that might be returned. The <code>status</code> field will be
-set to one of the CA error codes in caerr.h and will indicate the status of the
-operation performed in the IOC. If the status field isn't set to ECA_NORMAL or
-data isn't normally returned from the operation (i.e. put call back) then you
-should expect that the <code>dbr</code> field will be set to a nill pointer
-(zero). The fields <code>usr</code>, <code>chid</code>, and <code>type</code>
-are set to the values specified when the request was made by the application.
-The "dbr" pointer, and any data that it points to, are valid only when
-executing within the user's callback function.</p>
-<pre>typedef struct event_handler_args {
+data that might be returned. The <code>status</code> field will be set to one
+of the CA error codes in caerr.h and will indicate the status of the operation
+performed in the IOC. If the status field isn`t set to ECA_NORMAL or data isn`t
+normally returned from the operation (i.e. put call back) then you should
+expect that the <code>dbr</code>field will be set to a nill pointer (zero). The
+fields <code>usr</code>, <code>chid</code>, and <code>type</code> are set to
+the values specified when the request was made by the application. The "dbr"
+pointer, and any data that it points to, are valid only when executing within
+the user`s callback function.</p>
+<pre><code>typedef struct event_handler_args {
     void            *usr;   /* user argument supplied with request */
     chanId          chid;   /* channel id */
     long            type;   /* the type of the item returned */ 
@@ -2350,13 +2377,13 @@
          const struct dbr_time_double * pTD =
               ( const struct dbr_time_double * ) args.dbr;
     }
-}</pre>
+}</code></pre>
 
 <h3><a name="Channel1">Channel Access Exceptions</a></h3>
 
 <p>When the server detects a failure, and there is no client call back function
-attached to the request, an exception handler is executed in the client.
-The default exception handler prints a message on the console and exits if the
+attached to the request, an exception handler is executed in the client. The
+default exception handler prints a message on the console and exits if the
 exception condition is severe. Certain internal exceptions within the CA client
 library, and failures detected by the SEVCHK macro may also cause the exception
 handler to be invoked. To modify this behavior see <a
@@ -2365,10 +2392,10 @@
 <h3><a name="Server">Server and Client Share the Same Address Space on The Same
 Host</a></h3>
 
-<p>If the Process Variable's server and it's client are colocated within the
+<p>If the Process Variable`s server and its client are colocated within the
 same memory address space and the same host then the ca_xxx() operations bypass
 the server and directly interact with the server tool component (commonly the
-IOC's function block database). In this situation the ca_xxx() routines
+IOC`s function block database). In this situation the ca_xxx() routines
 frequently return the completion status of the requested operation directly to
 the caller with no opportunity for asynchronous notification of failure via an
 exception handler. Likewise, callbacks may be directly invoked by the CA
@@ -2377,10 +2404,10 @@
 <h3><a name="Arrays">Arrays</a></h3>
 
 <p>For routines that require an argument specifying the number of array
-elements, no more than the process variable's maximum native element count may
-be requested. The process variable's maximum native element count is available
+elements, no more than the process variable`s maximum native element count may
+be requested. The process variable`s maximum native element count is available
 from ca_element_count() when the channel is connected. If fewer elements than
-the process variable's native element count are requested, the requested values
+the process variable`s native element count are requested, the requested values
 will be fetched beginning at element zero. By default CA limits the number of
 elements in an array to be no more than approximately 16k divided by the size
 of one element in the array. Starting with EPICS R3.14 the maximum array size
@@ -2391,10 +2418,10 @@
 <p>Application programs should assume that CA servers may be restarted, and
 that network connectivity is transient. When you create a CA channel its
 initial connection state will most commonly be disconnected. If the Process
-Variable's server is available the library will immediately initiate the
+Variable`s server is available the library will immediately initiate the
 necessary actions to make a connection with it. Otherwise, the client library
 will monitor the state of servers on the network and connect or reconnect with
-the process variable's server as it becomes available. After the channel
+the process variable`s server as it becomes available. After the channel
 connects the application program can freely perform IO operations through the
 channel, but should expect that the channel might disconnect at any time due to
 network connectivity disruptions or server restarts.</p>
@@ -2412,7 +2439,7 @@
 that prefer to poll for connection state changes instead of opting for
 asynchronous notification. The <code>ca_pend_io</code> function blocks only for
 channels created specifying a nill connection handler callback function. The
-user's connection state change function will be run immediately from within
+user`s connection state change function will be run immediately from within
 <code><a href="#ca_create_channel">ca_create_channel</a></code> if the CA
 client and CA server are both hosted within the same address space (within the
 same process).</p>
@@ -2423,12 +2450,12 @@
 all OS (in past releases the library was thread safe only on vxWorks). When the
 client library is initialized the programmer may specify if preemptive callback
 is to be enabled. Preemptive callback is disabled by default. If preemptive
-callback is enabled, then the user's callback functions might be called by
-CA's auxiliary threads when the main initiating channel access thread is not
-inside of a function in the channel access client library. Otherwise, the
-user's callback functions will be called only when the main initiating channel
-access thread is executing inside of the CA client library. When the CA client
-library invokes a user's callback function, it will always wait for the current
+callback is enabled, then the user`s callback functions might be called by CA`s
+auxiliary threads when the main initiating channel access thread is not inside
+of a function in the channel access client library. Otherwise, the user`s
+callback functions will be called only when the main initiating channel access
+thread is executing inside of the CA client library. When the CA client library
+invokes a user`s callback function, it will always wait for the current
 callback to complete prior to executing another callback function. Programmers
 enabling preemptive callback should be familiar with using mutex locks to
 create a reliable multi-threaded program.</p>
@@ -2457,10 +2484,10 @@
 database CA links and the sequencer are designed to not use the same CA client
 library threads, network circuits, and data structures. Each thread that calls
 <a href="#ca_context_create">ca_context_create()</a> for the first time either
-directly or implicitly when calling any CA library function for the first
-time, creates a CA client library context. A CA client library context contains
-all of the threads, network circuits, and data structures required to connect
-and communicate with the channels that a CA client application has created. The
+directly or implicitly when calling any CA library function for the first time,
+creates a CA client library context. A CA client library context contains all
+of the threads, network circuits, and data structures required to connect and
+communicate with the channels that a CA client application has created. The
 priority of auxiliary threads spawned by the CA client library are at fixed
 offsets from the priority of the thread that called <a
 href="#ca_context_create">ca_context_create()</a>. An application specific
@@ -2474,9 +2501,10 @@
 It is not possible to attach a thread to a non-preemptive CA context created
 explicitly <em>or implicitly</em> with
 ca_create_context(ca_disable_preemptive_callback). Once a thread has joined
-with a CA context it need only make ordinary ca_xxxx() library calls to use the
-context.</p>
-
+with a CA context it need only make ordinary ca_xxxx()library calls to use the
+context. There is no need to specify the context identifier when invoking the
+CA calls because the context identifier is stored in a thread private variable
+by ca_attach_context().</p>
 
 <p>A CA client library context can be shut down and cleaned up, after
 destroying any channels or application specific threads that are attached to
@@ -2493,14 +2521,14 @@
 ca_sg_block() or alternatively it must call ca_poll() at least every 100
 milli-seconds. In single threaded applications a file descriptor manager like
 Xt or the interface described in fdManager.h can be used to monitor both mouse
-clicks and also CA's file descriptors so that ca_poll() can be called
+clicks and also CA`s file descriptors so that ca_poll() can be called
 immediately when CA server messages arrives over the network.</p>
 
 <h3><a name="Avoid">Avoid Emulating Bad Practices that May Still be
 Common</a></h3>
 
 <p>With the embryonic releases of EPICS it was a common practice to examine a
-channel's connection state, its native type, and its native element count by
+channel`s connection state, its native type, and its native element count by
 directly accessing fields in a structure using a pointer stored in type
 <code>chid</code>. Likewise, a user private pointer in the per channel
 structure was also commonly set by directly accessing fields in the channel
@@ -2530,9 +2558,9 @@
 <ul>
   <li>The vxWorks shell thread runs at the very highest priority in the system
     and therefore socket calls are made at a priority that is above the
-    priority of tNetTask - a practice that has caused the WRS IP kernel
-    to get sick in the past. That symptom was observed some time ago, but we
-    don't know if WRS has fixed the problem.</li>
+    priority of tNetTask. This has caused problems with the WRS IP kernel in
+    the past. That symptom was observed some time ago, but we don`t know
+    if WRS has fixed the problem.</li>
 </ul>
 <ul>
   <li>The vxWorks shell thread runs at the very highest priority in the system
@@ -2547,7 +2575,7 @@
 <ul>
   <li>In EPICS R3.13 the CA client library installed vxWorks task exit handlers
     behaved strangely if CA functions were called from the vxWorks shell,
-    ca_task_exit() wasn't called, and the vxWorks shell restarted. In
+    ca_task_exit() wasn`t called, and the vxWorks shell restarted. In
     EPICS R3.14 vxWorks task exit handlers are not installed and therefore
     cleanup is solely the responsibility of the user. With EPICS R3.14 the user
     must call ca_context_destroy or ca_task_exit to clean up on vxWorks. This
@@ -2565,10 +2593,10 @@
 <h2><a name="Function Call Reference"></a>Function Call Reference</h2>
 
 <h3><code><a name="ca_context_create">ca_context_create()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-enum ca_preemptive_callback_select
-    { ca_disable_preemptive_callback, ca_enable_preemptive_callback };
-int ca_context_create ( enum ca_preemptive_callback_select SELECT );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+enum ca_preemptive_callback_select  
+    { ca_disable_preemptive_callback, ca_enable_preemptive_callback }; 
+int ca_context_create ( enum ca_preemptive_callback_select SELECT );</code></pre>
 
 <h4>Description</h4>
 
@@ -2592,7 +2620,7 @@
       are two implications to consider. </dd>
     <dd><p>First, if preemptive callback mode is enabled the developer must
       provide mutual exclusion protection for his data structures. In this mode
-      it's possible for two threads to touch the application's data structures
+      it`s possible for two threads to touch the application`s data structures
       at once: this might be the initializing thread (the thread that called
       ca_context_create) and also a private thread created by the CA client
       library for the purpose of receiving network messages and calling
@@ -2631,7 +2659,7 @@
 
 <h4>Description</h4>
 
-<p>Shut down the calling thread's channel access client context and free any
+<p>Shut down the calling thread`s channel access client context and free any
 resources allocated. Detach the calling thread from any CA client context.</p>
 
 <p>Any user-created threads that have attached themselves to the CA context
@@ -2647,8 +2675,13 @@
 <p>On many OS that execute programs in a process based environment the
 resources used by the client library such as sockets and allocated memory are
 automatically released by the system when the process exits and
+<<<<<<< TREE
 ca_context_destroy() hasn't been called, but on light weight systems such as
 vxWorks or RTEMS no cleanup occurs unless the application calls
+=======
+ca_context_destroy() hasn`t been called, but on light weight systems such as
+vxWorks or RTEMS no cleanup occurs unless the application call
+>>>>>>> MERGE-SOURCE
 ca_context_destroy().</p>
 
 <h4>Returns</h4>
@@ -2659,27 +2692,42 @@
 
 <p><a href="#ca_context_create">ca_context_create</a>()</p>
 
+<<<<<<< TREE
 <h3><code><a name="ca_create_channel">ca_create_channel()</a></code></h3>
 <pre>#include &lt;cadef.h&gt;
 typedef void ( caCh ) (struct connection_handler_args);
 int ca_create_channel (const char *PVNAME,
         caCh *USERFUNC, void *PUSER,
         capri PRIORITY, chid *PCHID );</pre>
+=======
+<h3><a name="ca_create_channel"><code>ca_create_channel()</code></a></h3>
+<pre><code>#include &lt;cadef.h&gt;
+typedef void ( *pCallBack ) (
+         struct connection_handler_args );
+int ca_create_channel
+(
+        const char     *PROCESS_VARIABLE_NAME, 
+        caCh           *USERFUNC, 
+        void           *PUSER,
+        capri          priority,
+        chid           *PCHID
+);</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
 <p>This function creates a CA channel. The CA client library will attempt to
-establish and maintain a virtual circuit between the caller's application and a
+establish and maintain a virtual circuit between the caller`s application and a
 named process variable in a CA server. Each call to ca_create_channel allocates
 resources in the CA client library and potentially also a CA server. The
 function ca_clear_channel() is used to release these resources. If successful,
-the routine writes a channel identifier into the user's variable of type
+the routine writes a channel identifier into the user`s variable of type
 "chid". This identifier can be used with any channel access call that operates
 on a channel.</p>
 
 <p>The circuit may be initially connected or disconnected depending on the
 state of the network and the location of the channel. A channel will only enter
-a connected state after server's address is determined, and only if channel
+a connected state after server`s address is determined, and only if channel
 access successfully establishes a virtual circuit through the network to the
 server. Channel access routines that send a request to a server will return
 ECA_DISCONNCHID if the channel is currently disconnected.</p>
@@ -2703,7 +2751,7 @@
 
 <p>Due to the inherently transient nature of network connections the order of
 connection call backs relative to the order that ca_create_channel() calls are
-made by the application can't be guaranteed, and application programs may need
+made by the application can`t be guaranteed, and application programs may need
 to be prepared for a connected channel to enter a disconnected state at any
 time.</p>
 
@@ -2723,29 +2771,29 @@
 </dl>
 <dl>
   <dt><code>USERFUNC</code></dt>
-    <dd>Optional address of the user's call back function to be run when the
+    <dd>Optional address of the user`s call back function to be run when the
       connection state changes. Casual users of channel access may decide to
       set this field to nil or 0 if they do not need to have a call back
-      function run in response to each connection state change event.
-      <p>The following structure is passed <em>by value </em>to the user's
+      function run in response to each connection state change event. 
+      <p>The following structure is passed <em>by value </em>to the user`s
       connection connection callback function. The <code>op</code> field will
       be set by the CA client library to <code>CA_OP_CONN_UP</code> when the
       channel connects, and to <code>CA_OP_CONN_DOWN</code> when the channel
       disconnects. See <code><a href="#ca_puser">ca_puser</a></code> if the
       <code>PUSER</code> argument is required in your callback
       handler<code>.</code></p>
-      <pre>struct  ca_connection_handler_args {
-    chanId  chid;  /* channel id */
-    long    op;    /* one of CA_OP_CONN_UP or CA_OP_CONN_DOWN */
-};</pre>
+      <pre><code>struct  ca_connection_handler_args { 
+    chanId  chid;  /* channel id */   
+    long    op;    /* one of CA_OP_CONN_UP or CA_OP_CONN_DOWN */ 
+};</code></pre>
     </dd>
 </dl>
 <dl>
   <dt><code>PUSER</code></dt>
-    <dd>The value of this void pointer argument is retained in
-      storage associated with the specified channel. See the MACROS manual page
-      for reading and writing this field. Casual users of channel access may
-      wish to set this field to nil or 0.</dd>
+    <dd>The value of this void pointer argument is retained in storage
+      associated with the specified channel. See the MACROS manual page for
+      reading and writing this field. Casual users of channel access may wish
+      to set this field to nil or 0.</dd>
 </dl>
 <dl>
   <dt><code>PRIORITY</code></dt>
@@ -2778,9 +2826,9 @@
 
 <p>ECA_ALLOCMEM - Unable to allocate memory</p>
 
-<h3><code><a name="ca_clear_channel">ca_clear_channel()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_clear_channel (chid CHID);</pre>
+<h3><a name="ca_clear_channel"></a><code>ca_clear_channel()</code></h3>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_clear_channel (chid CHID);</code></pre>
 
 <h4>Description</h4>
 
@@ -2808,8 +2856,8 @@
 
 <p>ECA_BADCHID - Corrupted CHID</p>
 
-<h3><code><a name="ca_put">ca_put()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
+<h3><a name="ca_put"><code>ca_put()</code></a></h3>
+<pre><code>#include &lt;cadef.h&gt;
 int ca_put ( chtype TYPE, 
         chid CHID, void *PVALUE ); 
 int ca_array_put ( chtype TYPE, unsigned long COUNT, 
@@ -2820,13 +2868,21 @@
         caEventCallBackFunc PFUNC, void *USERARG ); 
 int ca_array_put_callback ( chtype TYPE, unsigned long COUNT, 
         chid CHID, const void *PVALUE, 
+<<<<<<< TREE
         caEventCallBackFunc PFUNC, void *USERARG );</pre>
+=======
+        pCallBack PFUNC, void *USERARG );</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
 <p>Write a scalar or array value to a process variable.</p>
 
+<<<<<<< TREE
 <p>When ca_put or ca_array_put are invoked the client will receive no response
+=======
+<p>When ca_array_put or ca_put are invoked the client will receive no response
+>>>>>>> MERGE-SOURCE
 unless the request can not be fulfilled in the server. If unsuccessful an
 exception handler is run on the client side.</p>
 
@@ -2838,7 +2894,7 @@
 </p>
 
 <p>If the channel disconnects before a put callback request can be completed,
-then the client's call back function is called with failure status, but this
+then the client`s call back function is called with failure status, but this
 does not guarantee that the server did not receive and process the request
 before the disconnect. If a connection is lost and then resumed outstanding ca
 put requests are not automatically reissued following reconnect.</p>
@@ -2852,8 +2908,8 @@
 
 <h4>Description (IOC Database Specific)</h4>
 
-<p>A CA put request causes the record to process if the record's SCAN field is
-set to passive, and the field being written has it's process passive attribute
+<p>A CA put request causes the record to process if the record`s SCAN field is
+set to passive, and the field being written has its process passive attribute
 set to true. If such a record is already processing when a put request is
 initiated the specified field is written immediately, and the record is
 scheduled to process again as soon as it finishes processing. Earlier instances
@@ -2861,21 +2917,45 @@
 discarded, but the last put request initiated is always written and
 processed.</p>
 
-<p>A CA put <span style="font-style: italic;">callback</span> request causes
-the record to process if the record's SCAN field is set to passive, and the
-field being written has it's process passive attribute set to true. For such a
-record, the user's put callback function is not called until after the record,
-and any records that the record links to, finish processing. If such a record
-is already processing when a put <span
-style="font-style: italic;">callback</span> request is initiated the put <span
-style="font-style: italic;">callback</span> request is postponed until the
-record, and any records it links to, finish processing.</p>
+<p>A CA put <em>callback</em> request causes the record to process if the
+record`s SCAN field is set to passive, and the field being written has its
+process passive attribute set to true. For such a record, the user`s put
+callback function is not called until after the record, and any records that
+the record links to, finish processing. If such a record is already processing
+when a put <em>callback</em> request is initiated the put <em>callback</em>
+request is postponed until the record, and any records it links to, finish
+processing.</p>
 
-<p>If the record's SCAN field is not set to passive, or the field being written
-has it's process passive attribute set to false then the CA put or CA put
+<p>If the record`s SCAN field is not set to passive, or the field being written
+has its process passive attribute set to false, then the CA put or CA put
 callback request cause the specified field to be immediately written, but they
 do not cause the record to be processed.</p>
 
+<h4>Description (IOC Database Specific)</h4>
+
+<p>A CA put request causes the record to process if the record`s SCAN field is
+set to passive, and the field being written has its process passive attribute
+set to true. If such a record is already processing when a put request is
+initiated the specified field is written immediately, and the record is
+scheduled to process again as soon as it finishes processing. Earlier instances
+of multiple put requests initiated while the record is being processing may be
+discarded, but the last put request initiated is always written and
+processed.</p>
+
+<p>A CA put <em>callback</em> request causes the record to process if the
+record`s SCAN field is set to passive, and the field being written has its
+process passive attribute set to true. For such a record, the user`s put
+callback function is not called until after the record, and any records that
+the record links to, finish processing. If such a record is already processing
+when a put <em>callback</em> request is initiated the put <em>callback</em>
+request is postponed until the record, and any records it links to, finish
+processing.</p>
+
+<p>If the record`s SCAN field is not set to passive, or the field being written
+has its process passive attribute set to false then the CA put or CA put
+<em>callback</em> request cause the specified field to be immediately written,
+but they do not cause the record to be processed.</p>
+
 <h4>Arguments</h4>
 <dl>
   <dt><code>TYPE</code></dt>
@@ -2958,7 +3038,7 @@
 requests are not automatically reissued following reconnect.</p>
 
 <p>When ca_get_callback or ca_array_get_callback are invoked a value is read
-from the channel and then the user's callback is invoked with a pointer to the
+from the channel and then the user`s callback is invoked with a pointer to the
 retrieved value. Note that ca_pend_io will not block for the delivery of values
 requested by ca_get_callback. If the channel disconnects before a ca get
 callback request can be completed, then the clients call back function is
@@ -2974,7 +3054,14 @@
 
 <h4>Description (IOC Database Specific)</h4>
 
-<p>A CA get or CA get callback request causes the record's field to be read
+<p>A CA get or CA get callback request causes the record`s field to be read
+immediately independent of whether the record is currently being processed or
+not. There is currently no mechanism in place to cause a record to be processed
+when a CA get request is initiated.</p>
+
+<h4>Description (IOC Database Specific)</h4>
+
+<p>A CA get or CA get callback request causes the record`s field to be read
 immediately independent of whether the record is currently being processed or
 not. There is currently no mechanism in place to cause a record to be processed
 when a CA get request is initiated.</p>
@@ -3042,6 +3129,7 @@
 
 <p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
 
+<<<<<<< TREE
 <h3><code><a name="ca_add_event">ca_create_subscription()</a></code></h3>
 <pre>#include &lt;cadef.h&gt;
 typedef void ( caEventCallBackFunc ) (struct event_handler_args);
@@ -3049,25 +3137,35 @@
         chid CHID, unsigned long MASK,
         caEventCallBackFunc USERFUNC, void *USERARG, 
         evid *PEVID );</pre>
+=======
+<h3><a name="ca_add_event"></a><code>ca_create_subscription()</code></h3>
+<pre><code>#include &lt;cadef.h&gt;
+typedef void ( *pCallBack ) (
+        struct event_handler_args );
+int ca_create_subscription ( chtype TYPE, 
+        unsigned long COUNT, chid CHID, 
+        unsigned long MASK, pCallBack USERFUNC, void *USERARG, 
+        evid *PEVID );</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
 <p>Register a state change subscription and specify a call back function to be
 invoked whenever the process variable undergoes significant state changes. A
-significant change can be a change in the process variable's value, alarm
+significant change can be a change in the process variable`s value, alarm
 status, or alarm severity. In the process control function block database the
 deadband field determines the magnitude of a significant change for for the
-process variable's value. Each call to this function consumes resources in the
+process variable`s value. Each call to this function consumes resources in the
 client library and potentially a CA server until one of ca_clear_channel or
 ca_clear_event is called.</p>
 
 <p>Subscriptions may be installed or canceled against both connected and
 disconnected channels. The specified USERFUNC is called once immediately after
-the subscription is installed with the process variable's current state if the
+the subscription is installed with the process variable`s current state if the
 process variable is connected. Otherwise, the specified USERFUNC is called
 immediately after establishing a connection (or reconnection) with the process
 variable. The specified USERFUNC is called immediately with the process
-variable's current state from within ca_add_event() if the client and the
+variable`s current state from within ca_add_event() if the client and the
 process variable share the same address space.</p>
 
 <p>If a subscription is installed on a channel in a disconnected state then the
@@ -3124,8 +3222,8 @@
 <dl>
   <dt><code>PEVID</code></dt>
     <dd>This is a pointer to user supplied event id which is overwritten if
-      successful. This event id can later be used to clear a specific
-      event. This option may may be omitted by passing a nil pointer.</dd>
+      successful. This event id can later be used to clear a specific event.
+      This option may may be omitted by passing a nill pointer.</dd>
 </dl>
 <dl>
   <dt><code>MASK</code></dt>
@@ -3142,7 +3240,7 @@
       </ul>
       <p>For functions above that do not include a trigger specification,
       events will be triggered when there are significant changes in the
-      channel's value or when there are changes in the channel's alarm state.
+      channel`s value or when there are changes in the channel`s alarm state.
       This is the same as "DBE_VALUE | DBE_ALARM."</p>
     </dd>
 </dl>
@@ -3232,9 +3330,9 @@
 network delays such as Ethernet collision exponential back off until
 retransmission delays which can be quite long on overloaded networks.</p>
 
-<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a></code>, this routine will
-not process CA's background activities if none of the selected IO requests are
-pending.</p>
+<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a></code>, this routine
+will not process CA`s background activities if none of the selected IO requests
+are pending.</p>
 
 <h4>Arguments</h4>
 <dl>
@@ -3303,7 +3401,7 @@
 requests.</p>
 
 <p>Both <code>ca_pend_event</code> and <code>ca_poll</code> return ECA_TIMEOUT
-when successful. This behavior probably isn't intuitive, but it is preserved to
+when successful. This behavior probably isn`t intuitive, but it is preserved to
 insure backwards compatibility.</p>
 
 <p>See also <a href="#Thread">Thread Safety and Preemptive Callback to User
@@ -3329,8 +3427,8 @@
 
 <h4>Description</h4>
 
-<p>Flush outstanding IO requests to the server. This routine might be useful
-to users who need to flush requests prior to performing client side labor in
+<p>Flush outstanding IO requests to the server. This routine might be useful to
+users who need to flush requests prior to performing client side labor in
 parallel with labor performed in the server.</p>
 
 <p>Outstanding requests are also sent whenever the buffer which holds them
@@ -3340,10 +3438,10 @@
 
 <p>ECA_NORMAL - Normal successful completion</p>
 
-<h3><code><a name="ca_signal">ca_signal()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
+<h3><code><a name="ca_signal">ca_signal</a>()</code></h3>
+<pre><code>#include &lt;cadef.h&gt;
 int ca_signal ( long CA_STATUS, const char * CONTEXT_STRING ); 
-void SEVCHK( CA_STATUS, CONTEXT_STRING );</pre>
+void SEVCHK( CA_STATUS, CONTEXT_STRING );</code></pre>
 
 <h4>Description</h4>
 
@@ -3359,8 +3457,8 @@
 code testing the status returned from each channel access call.</p>
 
 <h4>Examples</h4>
-<pre>status = ca_context_create (...); 
-SEVCHK ( status, "Unable to create a CA client context" );</pre>
+<pre><code>status = ca_context_create (...); 
+SEVCHK ( status, "Unable to create a CA client context" );</code></pre>
 
 <p>If the application only wishes to print the message associated with an error
 code or test the severity of an error there are also functions provided for
@@ -3396,7 +3494,7 @@
 information about this type of error is passed from the server to the client in
 an exception message. When the client receives this exception message an
 exception handler callback is called.The default exception handler prints a
-diagnostic message on the client's standard out and terminates execution if the
+diagnostic message on the client`s standard out and terminates execution if the
 error condition is severe.</p>
 
 <p>Note that certain fields in "struct exception_handler_args" are not
@@ -3409,23 +3507,23 @@
 <dl>
   <dt><code>USERFUNC</code></dt>
     <dd>Address of user callback function to be executed when an exceptions
-      occur. Passing a nil value causes the default exception handler to be
-      reinstalled. The following structure is passed by value to the user's
+      occur. Passing a nill value causes the default exception handler to be
+      reinstalled. The following structure is passed by value to the user`s
       callback function. Currently, the <code>op</code> field can be one of
       <code>CA_OP_GET, CA_OP_PUT, CA_OP_CREATE_CHANNEL, CA_OP_ADD_EVENT,
-      CA_OP_CLEAR_EVENT, or CA_OP_OTHER.</code>
-      <pre>struct exception_handler_args {
+      CA_OP_CLEAR_EVENT, or CA_OP_OTHER.</code> 
+      <pre><code>struct exception_handler_args {
     void            *usr;   /* user argument supplied when installed */
     chanId          chid;   /* channel id (may be nill) */
     long            type;   /* type requested */
     long            count;  /* count requested */
-    void            *addr;  /* user's address to write results of CA_OP_GET */
+    void            *addr;  /* user`s address to write results of CA_OP_GET */
     long            stat;   /* channel access ECA_XXXX status code */
     long            op;     /* CA_OP_GET, CA_OP_PUT, ..., CA_OP_OTHER */
     const char      *ctx;   /* a character string containing context info */
     sonst char      *pFile; /* source file name (may be NULL) */
     unsigned        lineNo; /* source file line number (may be zero) */
-};</pre>
+};</code></pre>
     </dd>
 </dl>
 <dl>
@@ -3435,7 +3533,7 @@
 </dl>
 
 <h4>Example</h4>
-<pre>void ca_exception_handler (
+<pre><code>void ca_exception_handler (
     struct exception_handler_args args)
 {
     char buf[512];
@@ -3448,11 +3546,11 @@
         pName = "?";
     }
     sprintf ( buf,
-            "%s - with request chan=%s op=%d data type=%s count=%d",
-            args.ctx, pName, args.op, dbr_type_to_text ( args.type ), args.count );
-    ca_signal ( args.stat, buf );
+        "%s - with request chan=%s op=%d data type=%s count=%d", 
+        args.ctx, pName, args.op, dbr_type_to_text ( args.type ), args.count ); 
+    ca_signal ( args.stat, buf ); 
 }
-ca_add_exception_event ( ca_exception_handler , 0 );</pre>
+ca_add_exception_event ( ca_exception_handler , 0 );</code></pre>
 
 <h4>Returns</h4>
 
@@ -3460,9 +3558,11 @@
 
 <p></p>
 
-<h3><code><a name="ca_add_fd_registration">ca_add_fd_registration()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_add_fd_registration ( void ( USERFUNC * ) ( void *USERARG, int FD, int OPENED ), void * USERARG )</pre>
+<h3><code><a name="ca_add_fd_"
+id="ca_add_fd_registration">ca_add_fd_registration()</a></code></h3>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_add_fd_registration ( void ( USERFUNC * ) ( void *USERARG, 
+                int FD, int OPENED ), void * USERARG )</code></pre>
 
 <h4>Description</h4>
 
@@ -3496,7 +3596,7 @@
 file descriptor was closed.</p>
 
 <h4>Example</h4>
-<pre>int s;
+<pre><code>int s;
 static struct myStruct aStruct;
 
 void fdReg ( struct myStruct *pStruct, int fd, int opened )
@@ -3505,7 +3605,7 @@
     else printf ( "fd %d was closed\n", fd );
 }
 s = ca_add_fd_registration ( fdReg, &amp; aStruct );
-SEVCHK ( s, NULL );</pre>
+SEVCHK ( s, NULL );</code></pre>
 
 <h4>Comments</h4>
 
@@ -3531,9 +3631,15 @@
 
 <h3><code><a name="ca_replace_printf_handler">ca_replace_printf_handler
 ()</a></code></h3>
+<<<<<<< TREE
 <pre>#include &lt;cadef.h&gt;
 typedef int caPrintfFunc ( const char *pFormat, va_list args );
 int ca_replace_printf_handler ( caPrintfFunc *PFUNC );</pre>
+=======
+<pre><code>#include &lt;cadef.h&gt;
+typedef int caPrintfFunc ( const char *pFromat, va_list args );
+int ca_replace_printf_handler ( caPrintfFunc *PFUNC );</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
@@ -3544,28 +3650,34 @@
 <dl>
   <dt><code>PFUNC</code></dt>
     <dd>The address of a user supplied call back handler to be invoked when CA
-      prints diagnostic messages. Installing a nil pointer will cause the
+      prints diagnostic messages. Installing a nill pointer will cause the
       default call back handler to be reinstalled.</dd>
 </dl>
 
 <h4>Examples</h4>
-<pre>int my_printf ( char *pformat, va_list args ) {
+<pre><code>int my_printf ( char *pformat, va_list args ) {
         int status;
         status = vfprintf( stderr, pformat, args);
         return status;
 }
 status = ca_replace_printf_handler ( my_printf );
-SEVCHK ( status, "failed to install my printf handler" );</pre>
+SEVCHK ( status, "failed to install my printf handler" );</code></pre>
 
 <h4>Returns</h4>
 
 <p>ECA_NORMAL - Normal successful completion</p>
 
 <h3><code><a name="ca_replace">ca_replace_access_rights_event()</a></code></h3>
+<<<<<<< TREE
 <pre>#include &lt;cadef.h&gt;
 typedef void ( caEventCallBackFunc )(struct access_rights_handler_args);
 int ca_replace_access_rights_event ( chid CHAN,
         caEventCallBackFunc PFUNC );</pre>
+=======
+<pre><code>#include &lt;cadef.h&gt;
+typedef void ( *pCallBack )( struct access_rights_handler_args );
+int ca_replace ( chid CHAN, pCallBack PFUNC );</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
@@ -3574,9 +3686,9 @@
 
 <p>The callback handler is called in the following situations.</p>
 <ul>
-  <li>whenever CA connects the channel immediately before the channel's
+  <li>whenever CA connects the channel immediately before the channel`s
     connection handler is called</li>
-  <li>whenever CA disconnects the channel immediately after the channel's
+  <li>whenever CA disconnects the channel immediately after the channel`s
     disconnect call back is called</li>
   <li>once immediately after installation if the channel is connected.</li>
   <li>whenever the access rights state of a connected channel changes</li>
@@ -3591,10 +3703,10 @@
 </dl>
 <dl>
   <dt><code>PFUNC</code></dt>
-    <dd>Address of user supplied call back function. A nil pointer uninstalls
+    <dd>Address of user supplied call back function. A nill pointer uninstalls
       the current handler. The following arguments are passed <em>by value</em>
       to the supplied callback handler. 
-      <pre>typedef struct ca_access_rights {
+      <pre><code>typedef struct ca_access_rights {
     unsigned    read_access:1;
     unsigned    write_access:1;
 } caar;
@@ -3603,7 +3715,7 @@
 struct  access_rights_handler_args {
     chanId  chid;   /* channel id */
     caar    ar;     /* new access rights state */
-};</pre>
+};</code></pre>
     </dd>
 </dl>
 
@@ -3611,9 +3723,15 @@
 
 <p>ECA_NORMAL - Normal successful completion</p>
 
+<h4>See Also</h4>
+
+<p>ca_modify_user_name()</p>
+
+<p>ca_modify_host_name()</p>
+
 <h3><code><a name="ca_field_type">ca_field_type()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-chtype ca_field_type ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+chtype ca_field_type ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3634,8 +3752,8 @@
 </dl>
 
 <h3><code><a name="ca_element_count">ca_element_count()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-unsigned ca_element_count ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+unsigned ca_element_count ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3651,13 +3769,13 @@
 <h4>Returns</h4>
 <dl>
   <dt><code>COUNT</code></dt>
-    <dd>The maximum array element count in the server. An element count of
-      zero is returned if the channel is disconnected.</dd>
+    <dd>The maximum array element count in the server. An element count of zero
+      is returned if the channel is disconnected.</dd>
 </dl>
 
 <h3><code><a name="ca_name">ca_name()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-char * ca_name ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+char * ca_name ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3677,8 +3795,8 @@
 </dl>
 
 <h3><code><a name="ca_set_puser">ca_set_puser()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-void ca_set_puser ( chid CHID, void *PUSER );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+void ca_set_puser ( chid CHID, void *PUSER );</code></pre>
 
 <h4>Description</h4>
 
@@ -3696,8 +3814,8 @@
 </dl>
 
 <h3><code><a name="ca_puser">ca_puser()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-void * ca_puser ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+void * ca_puser ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3717,13 +3835,13 @@
 </dl>
 
 <h3><code><a name="ca_state">ca_state()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
+<pre><code>#include &lt;cadef.h&gt;
 enum channel_state {
-    cs_never_conn, /* valid chid, server not found or unavailable */
-    cs_prev_conn,  /* valid chid, previously connected to server */
-    cs_conn,       /* valid chid, connected to server */
-    cs_closed };   /* channel deleted by user */
-enum channel_state ca_state ( CHID );</pre>
+        cs_never_conn, /* valid chid, server not found or unavailable */
+        cs_prev_conn,  /* valid chid, previously connected to server */
+        cs_conn,       /* valid chid, connected to server */
+        cs_closed };   /* channel deleted by user */
+enum channel_state ca_state ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3743,8 +3861,8 @@
 </dl>
 
 <h3><code><a name="ca_message">ca_message()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-const char * ca_message ( STATUS );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+const char * ca_message ( STATUS );</code></pre>
 
 <h4>Description</h4>
 
@@ -3764,8 +3882,8 @@
 </dl>
 
 <h3><code><a name="ca_host_name">ca_host_name()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-char * ca_host_name ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+char * ca_host_name ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3781,13 +3899,13 @@
 <h4>Returns</h4>
 <dl>
   <dt><code>STRING</code></dt>
-    <dd>The process variable server's host name. If the channel is disconnected
+    <dd>The process variable server`s host name. If the channel is disconnected
       the string "&lt;disconnected&gt;" is returned.</dd>
 </dl>
 
 <h3><code><a name="ca_read_access">ca_read_access()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_read_access ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_read_access ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3808,8 +3926,8 @@
 </dl>
 
 <h3><code><a name="ca_write_access">ca_write_access()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_write_access ( CHID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_write_access ( CHID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3830,8 +3948,8 @@
 </dl>
 
 <h3><code><a name="dbr_size[]">dbr_size[]</a></code></h3>
-<pre>#include &lt;db_access.h&gt;
-extern unsigned dbr_size[/* TYPE */];</pre>
+<pre><code>#include &lt;db_access.h&gt;
+extern unsigned dbr_size[/*TYPE*/];</code></pre>
 
 <h4>Description</h4>
 
@@ -3850,8 +3968,8 @@
 </dl>
 
 <h3><code><a name="dbr_size_n">dbr_size_n()</a></code></h3>
-<pre>#include &lt;db_access.h&gt;
-unsigned dbr_size_n ( TYPE, COUNT );</pre>
+<pre><code>#include &lt;db_access.h&gt;
+unsigned dbr_size_n  (  TYPE, COUNT  );</code></pre>
 
 <h4>Description</h4>
 
@@ -3879,8 +3997,8 @@
 </dl>
 
 <h3><code><a name="dbr_value_size">dbr_value_size[]</a></code></h3>
-<pre>#include &lt;db_access.h&gt;
-extern unsigned dbr_value_size[/* TYPE */];</pre>
+<pre><code>#include &lt;db_access.h&gt;
+extern unsigned dbr_value_size[/* TYPE */];</code></pre>
 
 <h4>Description</h4>
 
@@ -3902,8 +4020,8 @@
 </dl>
 
 <h3><code><a name="dbr_type_t">dbr_type_to_text</a>()</code></h3>
-<pre>#include &lt;db_access.h&gt;
-const char * dbr_type_text ( chtype TYPE );</pre>
+<pre><code>#include &lt;db_access.h&gt;
+const char * dbr_type_text ( chtype TYPE );</code></pre>
 
 <h4>Description</h4>
 
@@ -3933,17 +4051,17 @@
 prints diagnostics to standard out.</p>
 
 <h4>Examples</h4>
-<pre>void ca_test_event (); 
+<pre><code>void ca_test_event (); 
 status = ca_add_event ( type, chid, ca_test_event, NULL, NULL ); 
-SEVCHK ( status, .... );</pre>
+SEVCHK ( status, .... );</code></pre>
 
 <h4>See Also</h4>
 
 <p><a href="#ca_add_event">ca_add_event</a>()</p>
 
 <h3><code><a name="ca_sg_create">ca_sg_create()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_sg_create ( CA_SYNC_GID *PGID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_create ( CA_SYNC_GID *PGID );</code></pre>
 
 <h4>Description</h4>
 
@@ -3967,9 +4085,9 @@
 </dl>
 
 <h4>Examples</h4>
-<pre>CA_SYNC_GID gid; 
+<pre><code>CA_SYNC_GID gid; 
 status = ca_sg_create ( &amp;gid ); 
-SEVCHK ( status, Sync group create failed );</pre>
+SEVCHK ( status, Sync group create failed );</code></pre>
 
 <h4>Returns</h4>
 
@@ -3992,8 +4110,8 @@
 <p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
 
 <h3><code><a name="ca_sg_delete">ca_sg_delete()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_sg_delete ( CA_SYNC_GID GID );</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_delete ( CA_SYNC_GID GID );</code></pre>
 
 <h4>Description</h4>
 
@@ -4006,9 +4124,9 @@
 </dl>
 
 <h4>Examples</h4>
-<pre>CA_SYNC_GID gid; 
+<pre><code>CA_SYNC_GID gid; 
 status = ca_sg_delete ( gid ); 
-SEVCHK ( status, Sync group delete failed );</pre>
+SEVCHK ( status, Sync group delete failed );</code></pre>
 
 <h4>Returns</h4>
 
@@ -4020,9 +4138,15 @@
 
 <p><a href="#ca_sg_create">ca_sg_create</a>()</p>
 
+<<<<<<< TREE
 <h3><code><a name="ca_sg_block">ca_sg_block()</a></code></h3>
 <pre>#include &lt;cadef.h&gt;
 int ca_sg_block ( CA_SYNC_GID GID, double TIMEOUT );</pre>
+=======
+<h3><a name="ca_sg_block"><code>ca_sg_block</code></a><code>()</code></h3>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_block ( CA_SYNC_GID GID, double timeout );</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
@@ -4036,7 +4160,7 @@
 are outstanding then ca_sg_block() will return immediately without processing
 any pending channel access activities.</p>
 
-<p>Values written into your program's variables by a channel access synchronous
+<p>Values written into your program`s variables by a channel access synchronous
 group request should not be referenced by your program until ECA_NORMAL has
 been received from ca_sg_block(). This routine will process pending channel
 access background activity while it is waiting.</p>
@@ -4051,9 +4175,15 @@
 </dl>
 
 <h4>Examples</h4>
+<<<<<<< TREE
 <pre>CA_SYNC_GID gid;
 status = ca_sg_block(gid, 0.0);
 SEVCHK(status, Sync group block failed);</pre>
+=======
+<pre><code>CA_SYNC_GID gid; 
+status = ca_sg_block(gid); 
+SEVCHK(status, Sync group block failed);</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Returns</h4>
 
@@ -4072,8 +4202,8 @@
 <p><a href="#ca_sg_reset">ca_sg_reset</a>()</p>
 
 <h3><code><a name="ca_sg_test">ca_sg_test()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_sg_test ( CA_SYNC_GID GID )</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_test ( CA_SYNC_GID GID )</code></pre>
 
 <h4>Description</h4>
 
@@ -4092,8 +4222,8 @@
 completed.</p>
 
 <h4>Examples</h4>
-<pre>CA_SYNC_GID gid;
-status = ca_sg_test ( gid );</pre>
+<pre><code>CA_SYNC_GID gid;
+status = ca_sg_test ( gid );</code></pre>
 
 <h4>Returns</h4>
 
@@ -4102,8 +4232,8 @@
 <p>ECA_IOINPROGRESS - Some IO operations still in progress</p>
 
 <h3><code><a name="ca_sg_reset">ca_sg_reset()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_sg_reset ( CA_SYNC_GID GID )</pre>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_reset ( CA_SYNC_GID GID )</code></pre>
 
 <h4>Description</h4>
 
@@ -4118,8 +4248,8 @@
 </dl>
 
 <h4>Examples</h4>
-<pre>CA_SYNC_GID gid; 
-status = ca_sg_reset(gid);</pre>
+<pre><code>CA_SYNC_GID gid; 
+status = ca_sg_reset(gid);</code></pre>
 
 <h4>Returns</h4>
 
@@ -4127,10 +4257,10 @@
 
 <p>ECA_BADSYNCGRP - Invalid synchronous group</p>
 
-<h3><code><a name="ca_sg_put">ca_sg_array_put()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
+<h3><code><a name="ca_sg_put">ca_sg_put()</a></code></h3>
+<pre><code>#include &lt;cadef.h&gt;
 int ca_sg_array_put ( CA_SYNC_GID GID, chtype TYPE, 
-        unsigned long COUNT, chid CHID, void *PVALUE );</pre>
+        unsigned long COUNT, chid CHID, void *PVALUE );</code></pre>
 
 <p>Write a value, or array of values, to a channel and increment the
 outstanding request count of a synchronous group. The ca_sg_array_put
@@ -4189,11 +4319,11 @@
 
 <p><a href="#ca_flush_io">ca_flush_io</a>()</p>
 
-<h3><code><a name="ca_sg_get">ca_sg_array_get()</a></code></h3>
-<pre>#include &lt;cadef.h&gt;
-int ca_sg_array_get ( CA_SYNC_GID GID,
-        chtype TYPE, unsigned long COUNT,
-        chid CHID, void *PVALUE );</pre>
+<h3><code><a name="ca_sg_get">ca_sg_get()</a></code></h3>
+<pre><code>#include &lt;cadef.h&gt;
+int ca_sg_array_get ( CA_SYNC_GID GID, 
+        chtype TYPE, unsigned long COUNT, 
+        chid CHID, void *PVALUE );</code></pre>
 
 <h4>Description</h4>
 
@@ -4201,7 +4331,7 @@
 synchronous group. The ca_sg_array_get functionality is implemented using
 ca_array_get_callback.</p>
 
-<p>The values written into your program's variables by ca_sg_get should not be
+<p>The values written into your program`s variables by ca_sg_get should not be
 referenced by your program until ECA_NORMAL has been received from ca_sg_block,
 or until ca_sg_test returns ECA_IODONE.</p>
 
@@ -4285,7 +4415,7 @@
 
 <h4>Description</h4>
 
-<p>Returns a pointer to the current thread's CA context. If none then nil is
+<p>Returns a pointer to the current thread`s CA context. If none then nill is
 returned.</p>
 
 <h4>See Also</h4>
@@ -4355,7 +4485,13 @@
 <p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
 
 <h3><code><a name="ca_dump_dbr">ca_dump_dbr()</a></code></h3>
+<<<<<<< TREE
 <code><pre>void ca_dump_dbr (chtype TYPE, unsigned COUNT, const void * PDBR);</pre></code>
+=======
+<pre><code>
+void ca_dump_dbr (chtype TYPE, 
+            unsigned COUNT, const void * PDBR);</code></pre>
+>>>>>>> MERGE-SOURCE
 
 <h4>Description</h4>
 
@@ -4444,7 +4580,7 @@
     <dd>Preemptive callback not enabled - additional threads may not join
       context</dd>
   <dt>ECA_16KARRAYCLIENT</dt>
-    <dd>Client's protocol revision does not support transfers exceeding 16k
+    <dd>Client`s protocol revision does not support transfers exceeding 16k
       bytes</dd>
 </dl>