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

Proposed by Jeff Hill on 2011-03-16
Status: Merged
Merge reported by: Andrew Johnson
Merged at revision: not available
Proposed branch: lp:~johill-lanl/epics-base/ca-ref-man-maint
Merge into: lp:~epics-core/epics-base/3.15
Diff against target: 1757 lines (+413/-277) (has conflicts)
1 file modified
src/ca/client/CAref.html (+413/-277)
Text conflict in src/ca/client/CAref.html
To merge this branch: bzr merge lp:~johill-lanl/epics-base/ca-ref-man-maint
Reviewer Review Type Date Requested Status
Andrew Johnson Approve on 2013-11-07
Ralph Lange 2011-03-16 Needs Fixing on 2011-03-16
Review via email: mp+53647@code.launchpad.net

Description of the change

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

To post a comment you must log in.
Ralph Lange (ralph-lange) wrote :

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) wrote :

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) wrote :

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.

12223. By Jeff Hill on 2013-11-07

responded to Ralph and Andrew's comments

Jeff Hill (johill-lanl) wrote :

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

Andrew Johnson (anj) wrote :

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

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/ca/client/CAref.html'
2--- src/ca/client/CAref.html 2013-07-05 18:26:26 +0000
3+++ src/ca/client/CAref.html 2013-11-07 19:43:28 +0000
4@@ -7,8 +7,8 @@
5 <style type="text/css">
6 <!--
7 h3 code {
8- background-color: #ddf;
9- font-size: larger;
10+background-color: #ddf;
11+font-size: larger;
12 }
13 -->
14
15@@ -20,30 +20,30 @@
16
17 <h1>EPICS R3.14 Channel Access Reference Manual</h1>
18 <address>
19- Jeffrey O. Hill
20+ Jeffrey O. Hill
21 </address>
22
23 <p><span style="font-size: x-small; font-weight:lighter;">Los Alamos National
24 Laboratory, SNS Division</span></p>
25 <address>
26- Ralph Lange
27+ Ralph Lange
28 </address>
29
30 <p><span style="font-size: x-small; font-weight:lighter;">Helmholtz-Zentrum
31 Berlin (BESSY II)</span></p>
32
33-<p><span style="font-size: xx-small; font-weight:lighter;">Copyright &copy; 2009
34-Helmholtz-Zentrum Berlin f&uuml;r Materialien und Energie GmbH.<br>
35-Copyright &copy; 2002 The University of Chicago, as Operator of Argonne National
36+<p><span style="font-size: xx-small; font-weight:lighter;">Copyright © 2009
37+Helmholtz-Zentrum Berlin für Materialien und Energie GmbH.<br>
38+Copyright © 2002 The University of Chicago, as Operator of Argonne National
39 Laboratory.<br>
40-Copyright &copy; 2002 The Regents of the University of California, as Operator of
41+Copyright © 2002 The Regents of the University of California, as Operator of
42 Los Alamos National Laboratory.<br>
43-Copyright &copy; 2002 Berliner Speicherringgesellschaft f&uuml;r Synchrotronstrahlung
44+Copyright © 2002 Berliner Speicherringgesellschaft für Synchrotronstrahlung
45 GmbH.</span></p>
46
47 <p><span style="font-size: xx-small; font-weight:lighter;">EPICS BASE is
48-distributed subject to a Software License Agreement found
49-in the file LICENSE that is included with this distribution.</span></p>
50+distributed subject to a Software License Agreement found in the file LICENSE
51+that is included with this distribution.</span></p>
52
53 <p><a href="http://www.w3.org/Amaya/"><img
54 src="http://www.w3.org/Amaya/Icons/w3c-amaya.gif" alt="W3C-Amaya" height="31"
55@@ -107,17 +107,17 @@
56
57 <h3><a href="#Troubleshooting">Troubleshooting</a></h3>
58 <ul>
59- <li><a href="#When">When Clients Do Not Connect to Their Server</a>
60+ <li><a href="#When">When Clients Do Not Connect to Their Server</a>
61 <ul>
62 <li><a href="#Broadcast">Client and Server Broadcast Addresses Dont
63 Match</a></li>
64- <li><a href="#Client">Client Isnt Configured to Use the Server's
65+ <li><a href="#Client">Client Isnt Configured to Use the Server`s
66 Port</a></li>
67 <li><a href="#Unicast">Unicast Addresses in the EPICS_CA_ADDR_LIST Does
68 not Reliably Contact Servers Sharing the Same UDP Port on the Same
69 Host</a></li>
70- <li><a href="#Client1">Client Does not See Server's Beacons</a></li>
71- <li><a href="#Server1">A server's IP address was changed</a></li>
72+ <li><a href="#Client1">Client Does not See Server`s Beacons</a></li>
73+ <li><a href="#Server1">A server`s IP address was changed</a></li>
74 </ul>
75 </li>
76 <li><a href="#Requests">Put Requests Just Prior to Process Termination Appear
77@@ -165,7 +165,8 @@
78 <li><a href="#ca_pend_io">block for certain requests to complete</a></li>
79 <li><a href="#ca_test_io">test to see if certain requests have
80 completed</a></li>
81- <li><a href="#ca_pend_event">process CA client library background activities</a></li>
82+ <li><a href="#ca_pend_event">process CA client library background
83+ activities</a></li>
84 <li><a href="#ca_flush_io">flush outstanding requests to the server</a></li>
85 <li><a href="#ca_add_exception_event">replace the default exception
86 handler</a></li>
87@@ -246,7 +247,11 @@
88
89 <h3>Why Reconfigure Channel Access</h3>
90
91+<<<<<<< TREE
92 <p>Typical reasons to reconfigure EPICS Channel Access:</p>
93+=======
94+<p>Typicall reasons to reconfigure EPICS Channel Access:</p>
95+>>>>>>> MERGE-SOURCE
96 <ul>
97 <li>Two independent control systems must share a network without fear of
98 interaction</li>
99@@ -363,9 +368,8 @@
100 servers that host the channels identified. Likewise CA clients efficiently
101 discover that CA servers have recently joined the LAN or disconnected from the
102 LAN by monitoring periodically broadcasted beacons sent out by the servers.
103-Since hardware broadcasting requires special hardware capabilities, we are
104-required to provide additional configuration information when EPICS is extended
105-to operate over a wide area network (WAN).</p>
106+However, additional configuration is required when EPICS is extended to operate
107+over a wide area network (WAN).</p>
108
109 <h3><a name="Network">IP Network Administration Background Information</a></h3>
110
111@@ -374,7 +378,7 @@
112 is determined by the IP netmask. Portions of the IP address corresponding to
113 zeros in the netmask specify the hosts address within an IP subnet. Portions of
114 the IP address corresponding to binary ones in the netmask specify the address
115-of a host's IP subnet. Normally the scope of a broadcasted frame will be
116+of a host`s IP subnet. Normally the scope of a broadcasted frame will be
117 limited to one IP subnet. Addresses with the host address portion set to all
118 zeros or all ones are special. Modern IP kernel implementations reserve
119 destination addresses with the host portion set to all ones for the purpose of
120@@ -454,6 +458,7 @@
121
122 <h3><a name="firewall">Firewalls</a></h3>
123
124+<<<<<<< TREE
125 <p>If you want channel access clients on a machine to be able to see
126 beacons and replies to broadcast PV search requests, you need to permit
127 inbound UDP packets with source port EPICS_CA_SERVER_PORT (default is 5064)
128@@ -464,8 +469,18 @@
129 -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT
130 -A INPUT -s 192.168.0.0/22 -p udp --dport 5065 -j ACCEPT
131 </pre>
132+=======
133+<p>If you want channel access clients on a machine to be able to see beacons
134+and replies to broadcast PV search requests you need to permit inbound UDP
135+packets with source port EPICS_CA_SERVER_PORT (default is 5064) or destination
136+port EPICS_CA_REPEATER_PORT (default is 5065). On systems using iptables this
137+can be accomplished by rules like</p>
138+<pre> -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT
139+ -A INPUT -s 192.168.0.0/22 -p udp --dport 5065 -j ACCEPT</pre>
140+>>>>>>> MERGE-SOURCE
141
142 <p>If you want channel access servers (e.g. "soft IOCs") on a machine to be
143+<<<<<<< TREE
144 able to be seen by clients, you need to permit inbound TCP or UDP packets with
145 destination port EPICS_CA_SERVER_PORT (default is 5064).
146 On systems using iptables this can be accomplished by rules like</p>
147@@ -474,6 +489,13 @@
148 -A INPUT -s 192.168.0.0/22 -p udp --dport 5064 -j ACCEPT
149 -A INPUT -s 192.168.0.0/22 -p tcp --dport 5064 -j ACCEPT
150 </pre>
151+=======
152+able to see clients you need to permit inbound TCP or UDP packets with source
153+port EPICS_CA_SERVER_PORT (default is 5064). On systems using iptables this can
154+be accomplished by rules like</p>
155+<pre> -A INPUT -s 192.168.0.0/22 -p udp --dport 5064 -j ACCEPT
156+ -A INPUT -s 192.168.0.0/22 -p tcp --dport 5064 -j ACCEPT</pre>
157+>>>>>>> MERGE-SOURCE
158
159 <p>In all cases the "-s 192.168.0.0/22" specifies the range of addresses from
160 which you wish to accept packets.</p>
161@@ -488,7 +510,7 @@
162 resolution (search) request contains a list of Process Variable names.If one of
163 the servers reachable by this address list knows the IP address of a CA server
164 that can service one or more of the specified Process Variables, then it sends
165-back a response containing the server's IP address and port number.</p>
166+back a response containing the server`s IP address and port number.</p>
167
168 <p>During initialization CA builds the list of server destination addresses
169 used when sending CA client name resolution (search) requests. This table is
170@@ -497,10 +519,9 @@
171 broadcast address of that subnet is added to the list. For each point to point
172 interface found, the destination address of that link is added to the list.
173 This automatic server address list initialization can be disabled if the EPICS
174-environment variable EPICS_CA_AUTO_ADDR_LIST exists and its value is either
175-of "no" or "NO". The typical default is to enable network interface
176-introspection driven initialization with EPICS_CA_AUTO_ADDR_LIST set to "YES"
177-or "yes".</p>
178+environment variable EPICS_CA_AUTO_ADDR_LIST exists and its value is either of
179+"no" or "NO". The typical default is to enable network interface introspection
180+driven initialization with EPICS_CA_AUTO_ADDR_LIST set to "YES" or "yes".</p>
181
182 <p>Following network interface introspection, any IP addresses specified in the
183 EPICS environment variable EPICS_CA_ADDR_LIST are added to the list of
184@@ -511,8 +532,8 @@
185 EPICS_CA_ADDR_LIST may be dotted IP addresses or host names if the local OS has
186 support for host name to IP address translation. When multiple names are added
187 to EPICS_CA_ADDR_LIST they must be separated by white space. There is no
188-requirement that the addresses specified in the EPICS_CA_ADDR_LIST be
189-broadcast addresses, but this will often be the most convenient choice.</p>
190+requirement that the addresses specified in the EPICS_CA_ADDR_LIST be broadcast
191+addresses, but this will often be the most convenient choice.</p>
192
193 <p>For any IP addresses specified in the EPICS environment variable
194 EPICS_CA_NAME_SERVERS, TCP connections are opened and used for CA client name
195@@ -560,7 +581,7 @@
196 <p>Frequently vxWorks systems boot by default with routes limiting access only
197 to the local subnet. If a EPICS system is operating in a WAN environment it may
198 be necessary to configure routes into the vxWorks system which enable a vxWorks
199-based CA server to respond to requests originating outside it's subnet. These
200+based CA server to respond to requests originating outside its subnet. These
201 routing restrictions can also apply to vxWorks base CA clients communicating
202 with off subnet servers. An EPICS system manager can implement an rudimentary,
203 but robust, form of access control for a particular host by not providing
204@@ -571,7 +592,7 @@
205
206 <p>If the CA client library does not see a beacon from a server that it is
207 connected to for EPICS_CA_CONN_TMO seconds then an state-of-health message is
208-sent to the server over TCP/IP. If this state-of-health message isn't promptly
209+sent to the server over TCP/IP. If this state-of-health message isn`t promptly
210 replied to then the client library will conclude that channels communicating
211 with the server are no longer responsive and inform the CA client side
212 application via function callbacks. The parameter EPICS_CA_CONN_TMO is
213@@ -588,7 +609,7 @@
214 but does not immediately disconnect the TCP circuit. Instead the CA client
215 library postpones circuit shutdown until receiving indication of circuit
216 disconnect from the IP kernel. This can occur either because a server is
217-restarted or because the IP kernel's internal TCP circuit inactivity keep alive
218+restarted or because the IP kernel`s internal TCP circuit inactivity keep alive
219 timer has expired after a typically long duration (as is appropriate for IP
220 based systems that need to avoid thrashing during periods of excessive load).
221 The net result is less search and TCP circuit setup and shutdown activity
222@@ -624,7 +645,7 @@
223 below).</p>
224
225 <p>The CA client library continually estimates the beacon period of all server
226-beacons received. If a particular server's beacon period becomes significantly
227+beacons received. If a particular server`s beacon period becomes significantly
228 shorter or longer then the client is said to detect a beacon anomaly. The
229 library boosts the search interval for unresolved channels when a beacon
230 anomaly is seen or when <em>any</em> successful search response is received,
231@@ -634,7 +655,7 @@
232 preexisting unresolved channels. The program "casw" prints a message on
233 standard out for each CA client beacon anomaly detect event.</p>
234
235-<p>See also <a href="#Client1">When a Client Does not See the Server's
236+<p>See also <a href="#Client1">When a Client Does not See the Server`s
237 Beacon</a>.</p>
238
239 <h3><a name="Configurin3" id="Configurin3">Configuring the Maximum Search
240@@ -643,7 +664,7 @@
241 <p>The rate at which name resolution (search) requests are sent exponentially
242 backs off to a plateau rate. The value of this plateau has an impact on network
243 traffic because it determines the rate that clients search for channel names
244-that are miss-spelled or otherwise don't exist in a server. Furthermore, for
245+that are miss-spelled or otherwise don`t exist in a server. Furthermore, for
246 clients that are unable to see the beacon from a new server, the plateau rate
247 may also determine the maximum interval that the client will wait until
248 discovering a new server.</p>
249@@ -652,7 +673,7 @@
250 seconds is determined by the EPICS_CA_MAX_SEARCH_PERIOD environment
251 variable.</p>
252
253-<p>See also <a href="#Client1">When a Client Does not See the Server's
254+<p>See also <a href="#Client1">When a Client Does not See the Server`s
255 Beacon</a>.</p>
256
257 <h3><a name="Repeater">The CA Repeater</a></h3>
258@@ -764,7 +785,7 @@
259 <p>The CA client library uses EPICS_CA_MAX_ARRAY_BYTES to determines the
260 maximum array that it will send or receive. Likewise, the CA server uses
261 EPICS_CA_MAX_ARRAY_BYTES to determine the maximum array that it may send or
262-receive. The client does not influence the server's message size quotas and
263+receive. The client does not influence the server`s message size quotas and
264 visa versa. In fact the value of EPICS_CA_MAX_ARRAY_BYTES need not be the same
265 in the client and the server. If the server receives a request which is too
266 large to read or respond to in entirety then it sends an exception message to
267@@ -832,14 +853,14 @@
268
269 <p>The server configures its port number from the EPICS_CAS_SERVER_PORT
270 environment variable if it is specified. Otherwise the EPICS_CA_SERVER_PORT
271-environment variable determines the server's port number. Two servers can share
272+environment variable determines the server`s port number. Two servers can share
273 the same UDP port number on the same machine, but there are restrictions - see
274 a <a href="#Unicast">discussion of unicast addresses and two servers sharing
275 the same UDP port on the same host</a>.</p>
276
277 <h4>Server Beacons</h4>
278
279-<p>The EPICS_CAS_BEACON_PERIOD parameter determines the server's beacon period
280+<p>The EPICS_CAS_BEACON_PERIOD parameter determines the server`s beacon period
281 and is specified in floating point seconds. The default is typically 15
282 seconds. See also <a href="#Disconnect">EPICS_CA_CONN_TMO</a> and <a
283 href="#Dynamic">Dynamic Changes in the CA Client Library Search
284@@ -865,17 +886,17 @@
285 list is not augmented.</p>
286
287 <p>The EPICS_CAS_BEACON_PORT parameter specifies the destination port for
288-server beacons. The only exception to this occurs when ports are specified
289-in EPICS_CAS_BEACON_ADDR_LIST or possibly in EPICS_CA_ADDR_LIST. If
290+server beacons. The only exception to this occurs when ports are specified in
291+EPICS_CAS_BEACON_ADDR_LIST or possibly in EPICS_CA_ADDR_LIST. If
292 EPICS_CAS_BEACON_PORT is not specified then beacons are sent to the port
293 specified in EPICS_CA_REPEATER_PORT.</p>
294
295 <h4>Binding a Server to a Limited Set of Network Interfaces</h4>
296
297 <p>The parameter EPICS_CAS_INTF_ADDR_LIST allows a ca server to bind itself to,
298-and therefore accept messages only over, a limited set of the local host's
299-network interfaces (each specified by it's IP address). On UNIX systems type
300-"netstat -i" (type "ipconfig" on windows) to see a list of the local host's
301+and therefore accept messages only over, a limited set of the local host`s
302+network interfaces (each specified by its IP address). On UNIX systems type
303+"netstat -i" (type "ipconfig" on windows) to see a list of the local host`s
304 network interfaces. Specifically, UDP search messages addressed to both the IP
305 addresses in EPICS_CAS_INTF_ADDR_LIST and also to the broadcast addresses of
306 the corresponding LAN interfaces will be accepted by the server. By default,
307@@ -1054,7 +1075,7 @@
308
309 <p>CA server beacon anomalies occur when a new server joins the network, a
310 server is rebooted, network connectivity to a server is reestablished, or if a
311-server's CPU exits a CPU load saturated state.</p>
312+server`s CPU exits a CPU load saturated state.</p>
313
314 <p>CA clients with unresolved channels reset their search request scheduling
315 timers whenever they see a beacon anomaly.</p>
316@@ -1159,7 +1180,7 @@
317 </tr>
318 <tr>
319 <td>-d &lt;type&gt;</td>
320- <td>Request specific dbr type; use string (DBR_ prefix may be omitted)
321+ <td>Request specific dbr type; use string (DBR_ prefix may be omitted)
322
323 <p>or number of one of the following types:</p>
324
325@@ -1604,7 +1625,7 @@
326 stdout.</p>
327
328 <p>The -s option allows to specify an interest level for calling Channel
329-Access' internal report function ca_client_status(), that prints lots of
330+Access` internal report function ca_client_status(), that prints lots of
331 internal informations on stdout, including environment settings, used CA ports
332 etc.</p>
333
334@@ -1646,7 +1667,7 @@
335
336 <p>This is an example CA server that is sometimes used for testing purposes. An
337 example server can be created with the makeBaseApp perl script, as descibed in
338-the application Developer's Guide.</p>
339+the application Developer`s Guide.</p>
340
341 <table border="1">
342 <col>
343@@ -1832,21 +1853,21 @@
344 <h4><a name="Broadcast">Client and Server Broadcast Addresses Dont
345 Match</a></h4>
346
347-<p>Verify that the broadcast addresses are identical on the server's host and
348-on the client's host. This can be checked on UNIX with "netstat -i" or
349+<p>Verify that the broadcast addresses are identical on the server`s host and
350+on the client`s host. This can be checked on UNIX with "netstat -i" or
351 "ifconfig -a"; on vxWorks with ifShow; and on windows with ipconfig. It is
352 normal for the broadcast addresses to not be identical if the client and server
353 are not directly attached to the same IP subnet, and in this situation the
354 EPICS_CA_ADDR_LIST must be set. Otherwise, if the client and server are
355 intended to be on the same IP subnet, then the problem may be that the IP
356 netmask is incorrectly set in the network interface configuration. On most
357-operating systems, when the host's IP address is configured, the host's IP
358+operating systems, when the host`s IP address is configured, the host`s IP
359 subnet mask is also configured.</p>
360
361-<h4><a name="Client">Client Isn't Configured to Use the Server's Port</a></h4>
362+<h4><a name="Client">Client Isn`t Configured to Use the Server`s Port</a></h4>
363
364 <p>Verify that the client and server are using the same UDP port. Check the
365-server's port by running "netstat -a | grep nnn" where nnn is the port number
366+server`s port by running "netstat -a | grep nnn" where nnn is the port number
367 configured in the client. If you do not set EPICS_CA_SERVER_PORT or
368 EPICS_CAS_SERVER_PORT then the default port will be 5064.</p>
369
370@@ -1861,20 +1882,20 @@
371 existing CA server then both servers will use the same UDP port, and the 2nd
372 server will be allocated an ephemeral TCP port. Clients can be configured to
373 use the same port number for both servers. They will locate the 2nd server via
374-the shared UDP port, and transparently connect to the 2nd server's ephemeral
375-TCP port. Be aware however that If there are two server's running on the same
376+the shared UDP port, and transparently connect to the 2nd server`s ephemeral
377+TCP port. Be aware however that If there are two server`s running on the same
378 host sharing the same UDP port then they will both receive UDP search requests
379 sent as broadcasts, but unfortunately (due to a weakness of most IP kernel
380 implementations) only one of the servers will typically receive UDP search
381-requests sent to unicast addresses (i.e. a single specific host's ip
382+requests sent to unicast addresses (i.e. a single specific host`s ip
383 address).</p>
384
385-<h4><a name="Client1">Client Does not See Server's Beacons</a></h4>
386+<h4><a name="Client1">Client Does not See Server`s Beacons</a></h4>
387
388 <p>Two conclusions deserve special emphasis. <em>First, if a client does not
389-see the server's beacons, then it will use additional network and server
390+see the server`s beacons, then it will use additional network and server
391 resources sending periodic state-of-health messages.</em> <em>Second, if a
392-client does not see a newly introduced server's beacon, then it will take up to
393+client does not see a newly introduced server`s beacon, then it will take up to
394 EPICS_CA_MAX_SEARCH_PERIOD to find that newly introduced server.</em> Also,
395 starting with EPICS R3.14.7 the client library does <em>not</em> suspend
396 searching for a channel after 100 unsuccessful attempts until a beacon anomaly
397@@ -1882,18 +1903,18 @@
398 EPICS and it timed out attempting to find a server whoose beacon cant be seen
399 by the client library then the client application might need to be restarted in
400 order to connect to this new beacon-out-of-range server. The typical situation
401-where a client would not see the server's beacon might be when the client isnt
402-on the same IP subnet as the server, and the client's EPICS_CA_ADDR_LIST was
403-modified to include a destination address for the server, but the server's
404-beacon address list was not modified so that it's beacons are received by the
405+where a client would not see the server`s beacon might be when the client isnt
406+on the same IP subnet as the server, and the client`s EPICS_CA_ADDR_LIST was
407+modified to include a destination address for the server, but the server`s
408+beacon address list was not modified so that its beacons are received by the
409 client.</p>
410
411-<h4><a name="Server1">A Server's IP Address Was Changed</a></h4>
412+<h4><a name="Server1">A Server`s IP Address Was Changed</a></h4>
413
414 <p>When communication over a virtual circuit times out, then each channel
415 attached to the circuit enters a disconnected state and the disconnect callback
416 handler specified for the channel is called. However, the circuit is not
417-disconnected until TCP/IP's internal, typically long duration, keep alive timer
418+disconnected until TCP/IP`s internal, typically long duration, keep alive timer
419 expires. The disconnected channels remain attached to the beleaguered circuit
420 and no attempt is made to search for, or to reestablish, a new circuit. If, at
421 some time in the future, the circuit becomes responsive again, then the
422@@ -1905,11 +1926,11 @@
423 reattempt to find servers for each channel and connect circuits to them.</p>
424
425 <p>A well known negative side effect of the above behavior is that CA clients
426-will wait the full (typically long) duration of TCP/IP's internal keep alive
427+will wait the full (typically long) duration of TCP/IP`s internal keep alive
428 timer prior to reconnecting under the following scenario (all of the following
429 occur):</p>
430 <ul>
431- <li>An server's (IOC's) operating system crashes (or is abruptly turned off)
432+ <li>An server`s (IOC`s) operating system crashes (or is abruptly turned off)
433 or a vxWorks system is stopped by any means</li>
434 <li>This operating system does not immediately reboot using the same IP
435 address</li>
436@@ -1937,9 +1958,15 @@
437
438 <p>Short lived CA client applications that issue a CA put request and then
439 immediately exit the process (return from <code>main</code> or call
440+<<<<<<< TREE
441 <code>exit</code>) may find that there request isn't executed. To guarantee
442 that the request is sent call <code>ca_flush_io()</code> followed by
443 <code>ca_context_destroy()</code> prior to terminating the process.</p>
444+=======
445+<code>exit</code>) may find that there request isn`t executed. To guarantee
446+that the request is sent call <code>ca_flush</code> followed by
447+<code>ca_context_destroy</code> prior to terminating the process.</p>
448+>>>>>>> MERGE-SOURCE
449
450 <h3><a name="Problems">ENOBUFS Messages</a></h3>
451
452@@ -1952,7 +1979,7 @@
453 earlier vxWorks versions is rumored to lead to permanent IP communications
454 stalls which are resolved only by a system reboot. IP kernels that use mbufs
455 frequently allow the initial and maximum number of mbufs to be configured.
456-Consult your OS's documentation for configuration procedures which vary between
457+Consult your OS`s documentation for configuration procedures which vary between
458 OS and even between different versions of the same OS.</p>
459
460 <h4>Contributing Circumstances</h4>
461@@ -1965,9 +1992,9 @@
462 increase the size of the mbuf pool.</li>
463 </ul>
464 <ul>
465- <li>The server has multiple connections where the server's sustained event
466- (monitor subscription update) production rate is higher than the client's
467- or the network's sustained event consumption rate. This ties up a per
468+ <li>The server has multiple connections where the server`s sustained event
469+ (monitor subscription update) production rate is higher than the client`s
470+ or the network`s sustained event consumption rate. This ties up a per
471 socket quota of mbufs for data that are pending transmission to the client
472 via the network. In particular, if there are multiple clients that
473 subscribe for monitor events but do not call ca_pend_event() or ca_poll()
474@@ -1978,7 +2005,7 @@
475 <li>The server does not get a chance to run (because some other higher
476 priority thread is running) and the CA clients are sending a high volume of
477 data over TCP or UDP. This ties up a quota of mbufs for each socket in the
478- server that isn't being reduced by the server's socket read system
479+ server that isn`t being reduced by the server`s socket read system
480 calls.</li>
481 </ul>
482 <ul>
483@@ -1992,7 +2019,7 @@
484 <li>When sites switch to the vxWorks 5.4 IP kernel they frequently run into
485 network pool exhaustion problems. This may be because the original vxWorks
486 IP kernel expanded the network pool as needed at runtime while the new
487- kernel's pool is statically configured at compile time, and does
488+ kernel`s pool is statically configured at compile time, and does
489 <em>not</em> expand as needed at runtime. Also, at certain sites problems
490 related to vxWorks network driver pool exhaustion have also been reported
491 (this can also result in ENOBUF diagnostic messages).</li>
492@@ -2017,8 +2044,8 @@
493 <p>If the subscription update producer in the server produces subscription
494 updates faster than the subscription update consumer in the client consumes
495 them, then events have to be discarded if the buffering in the server
496-isn't allowed to grow to an infinite size. This is a law of nature
497-- based on queuing theory of course.</p>
498+isn`t allowed to grow to an infinite size. This is a law of nature
499+&ndash; based on queuing theory of course.</p>
500
501 <p>What is done depends on the version of the CA server. All server versions
502 place quotas on the maximum number of subscription updates allowed on the
503@@ -2040,10 +2067,10 @@
504 getting time warped, but also guarantees that intervening events are discarded
505 until the slow client catches up.</p>
506
507-<p>There is currently no message on the IOC's console when a
508-particular client is slow on the uptake. A message of this type used to exist
509-many years ago, but it was a source of confusion (and what we will call
510-message noise) so it was removed. </p>
511+<p>There is currently no message on the IOC`s console when a particular
512+client is slow on the uptake. A message of this type used to exist many years
513+ago, but it was a source of confusion (and what we will call message noise) so
514+it was removed. </p>
515
516 <p>There is unfortunately no field in the protocol allowing the server to
517 indicate that an intervening subscription update was discarded. We should
518@@ -2056,12 +2083,12 @@
519 <h3><a name="Flushing">Flushing and Blocking</a></h3>
520
521 <p>Significant performance gains can be realized when the CA client library
522-doesn't wait for a response to return from the server after each request. All
523+doesn`t wait for a response to return from the server after each request. All
524 requests which require interaction with a CA server are accumulated (buffered)
525 and not forwarded to the IOC until one of ca_flush_io, ca_pend_io,
526 ca_pend_event, or ca_sg_pend are called allowing several operations to be
527 efficiently sent over the network together. Any process variable values written
528-into your program's variables by ca_get() should not be referenced by your
529+into your program`s variables by ca_get() should not be referenced by your
530 program until ECA_NORMAL has been received from ca_pend_io().</p>
531
532 <h3><a name="Status">Status Codes</a></h3>
533@@ -2076,22 +2103,22 @@
534 validity of the request and whether it was successfully enqueued to the server,
535 but communication of completion status is deferred until a user callback is
536 called, or lacking that an exception handler is called. An error number and the
537-error's severity are embedded in CA status (error) constants. Applications
538-shouldn't test the success of a CA function call by checking to see if the
539+error`s severity are embedded in CA status (error) constants. Applications
540+shouldn`t test the success of a CA function call by checking to see if the
541 returned value is zero as is the UNIX convention. Below are several methods to
542 test CA function returns. See <a href="#ca_signal">ca_signal() and SEVCHK</a>
543 for more information on this topic.</p>
544-<pre>status = ca_XXXX();
545+<pre><code>status = ca_XXXX();
546 SEVCHK( status, "ca_XXXX() returned failure status");
547
548 if ( status &amp; CA_M_SUCCESS ) {
549- printf ( "The requested ca_XXXX() operation didn't complete successfully");
550+ printf ( "The requested ca_XXXX() operation didn`t complete successfully");
551 }
552
553 if ( status != ECA_NORMAL ) {
554- printf("The requested ca_XXXX() operation didn't complete successfully because \"%s\"\n",
555+ printf("The requested ca_XXXX() operation didn`t complete successfully because \"%s\"\n",
556 ca_message ( status ) );
557-}</pre>
558+}</code></pre>
559
560 <h3><a name="Channel">Channel Access Data Types</a></h3>
561
562@@ -2251,7 +2278,7 @@
563 href="#dbr_size_n">dbr_size_n</a> function can be used to determine the correct
564 number of bytes to reserve when there are more than one value field elements in
565 a structured CA data type.</p>
566-<pre>#include &lt;stdio.h&gt;
567+<pre><code>#include &lt;stdio.h&gt;
568 #include &lt;stdlib.h&gt;
569
570 #include "cadef.h"
571@@ -2314,7 +2341,7 @@
572 free ( pTD );
573
574 return 0;
575-}</pre>
576+}</code></pre>
577
578 <h3><a name="User">User Supplied Callback Functions</a></h3>
579
580@@ -2324,16 +2351,16 @@
581 asynchronous completion via this mechanism. The <code>event_handler_args
582 </code>structure is passed <em>by value</em> to the application supplied
583 callback. In this structure the <code>dbr</code> field is a void pointer to any
584-data that might be returned. The <code>status</code> field will be
585-set to one of the CA error codes in caerr.h and will indicate the status of the
586-operation performed in the IOC. If the status field isn't set to ECA_NORMAL or
587-data isn't normally returned from the operation (i.e. put call back) then you
588-should expect that the <code>dbr</code> field will be set to a nill pointer
589-(zero). The fields <code>usr</code>, <code>chid</code>, and <code>type</code>
590-are set to the values specified when the request was made by the application.
591-The "dbr" pointer, and any data that it points to, are valid only when
592-executing within the user's callback function.</p>
593-<pre>typedef struct event_handler_args {
594+data that might be returned. The <code>status</code> field will be set to one
595+of the CA error codes in caerr.h and will indicate the status of the operation
596+performed in the IOC. If the status field isn`t set to ECA_NORMAL or data isn`t
597+normally returned from the operation (i.e. put call back) then you should
598+expect that the <code>dbr</code>field will be set to a nill pointer (zero). The
599+fields <code>usr</code>, <code>chid</code>, and <code>type</code> are set to
600+the values specified when the request was made by the application. The "dbr"
601+pointer, and any data that it points to, are valid only when executing within
602+the user`s callback function.</p>
603+<pre><code>typedef struct event_handler_args {
604 void *usr; /* user argument supplied with request */
605 chanId chid; /* channel id */
606 long type; /* the type of the item returned */
607@@ -2350,13 +2377,13 @@
608 const struct dbr_time_double * pTD =
609 ( const struct dbr_time_double * ) args.dbr;
610 }
611-}</pre>
612+}</code></pre>
613
614 <h3><a name="Channel1">Channel Access Exceptions</a></h3>
615
616 <p>When the server detects a failure, and there is no client call back function
617-attached to the request, an exception handler is executed in the client.
618-The default exception handler prints a message on the console and exits if the
619+attached to the request, an exception handler is executed in the client. The
620+default exception handler prints a message on the console and exits if the
621 exception condition is severe. Certain internal exceptions within the CA client
622 library, and failures detected by the SEVCHK macro may also cause the exception
623 handler to be invoked. To modify this behavior see <a
624@@ -2365,10 +2392,10 @@
625 <h3><a name="Server">Server and Client Share the Same Address Space on The Same
626 Host</a></h3>
627
628-<p>If the Process Variable's server and it's client are colocated within the
629+<p>If the Process Variable`s server and its client are colocated within the
630 same memory address space and the same host then the ca_xxx() operations bypass
631 the server and directly interact with the server tool component (commonly the
632-IOC's function block database). In this situation the ca_xxx() routines
633+IOC`s function block database). In this situation the ca_xxx() routines
634 frequently return the completion status of the requested operation directly to
635 the caller with no opportunity for asynchronous notification of failure via an
636 exception handler. Likewise, callbacks may be directly invoked by the CA
637@@ -2377,10 +2404,10 @@
638 <h3><a name="Arrays">Arrays</a></h3>
639
640 <p>For routines that require an argument specifying the number of array
641-elements, no more than the process variable's maximum native element count may
642-be requested. The process variable's maximum native element count is available
643+elements, no more than the process variable`s maximum native element count may
644+be requested. The process variable`s maximum native element count is available
645 from ca_element_count() when the channel is connected. If fewer elements than
646-the process variable's native element count are requested, the requested values
647+the process variable`s native element count are requested, the requested values
648 will be fetched beginning at element zero. By default CA limits the number of
649 elements in an array to be no more than approximately 16k divided by the size
650 of one element in the array. Starting with EPICS R3.14 the maximum array size
651@@ -2391,10 +2418,10 @@
652 <p>Application programs should assume that CA servers may be restarted, and
653 that network connectivity is transient. When you create a CA channel its
654 initial connection state will most commonly be disconnected. If the Process
655-Variable's server is available the library will immediately initiate the
656+Variable`s server is available the library will immediately initiate the
657 necessary actions to make a connection with it. Otherwise, the client library
658 will monitor the state of servers on the network and connect or reconnect with
659-the process variable's server as it becomes available. After the channel
660+the process variable`s server as it becomes available. After the channel
661 connects the application program can freely perform IO operations through the
662 channel, but should expect that the channel might disconnect at any time due to
663 network connectivity disruptions or server restarts.</p>
664@@ -2412,7 +2439,7 @@
665 that prefer to poll for connection state changes instead of opting for
666 asynchronous notification. The <code>ca_pend_io</code> function blocks only for
667 channels created specifying a nill connection handler callback function. The
668-user's connection state change function will be run immediately from within
669+user`s connection state change function will be run immediately from within
670 <code><a href="#ca_create_channel">ca_create_channel</a></code> if the CA
671 client and CA server are both hosted within the same address space (within the
672 same process).</p>
673@@ -2423,12 +2450,12 @@
674 all OS (in past releases the library was thread safe only on vxWorks). When the
675 client library is initialized the programmer may specify if preemptive callback
676 is to be enabled. Preemptive callback is disabled by default. If preemptive
677-callback is enabled, then the user's callback functions might be called by
678-CA's auxiliary threads when the main initiating channel access thread is not
679-inside of a function in the channel access client library. Otherwise, the
680-user's callback functions will be called only when the main initiating channel
681-access thread is executing inside of the CA client library. When the CA client
682-library invokes a user's callback function, it will always wait for the current
683+callback is enabled, then the user`s callback functions might be called by CA`s
684+auxiliary threads when the main initiating channel access thread is not inside
685+of a function in the channel access client library. Otherwise, the user`s
686+callback functions will be called only when the main initiating channel access
687+thread is executing inside of the CA client library. When the CA client library
688+invokes a user`s callback function, it will always wait for the current
689 callback to complete prior to executing another callback function. Programmers
690 enabling preemptive callback should be familiar with using mutex locks to
691 create a reliable multi-threaded program.</p>
692@@ -2457,10 +2484,10 @@
693 database CA links and the sequencer are designed to not use the same CA client
694 library threads, network circuits, and data structures. Each thread that calls
695 <a href="#ca_context_create">ca_context_create()</a> for the first time either
696-directly or implicitly when calling any CA library function for the first
697-time, creates a CA client library context. A CA client library context contains
698-all of the threads, network circuits, and data structures required to connect
699-and communicate with the channels that a CA client application has created. The
700+directly or implicitly when calling any CA library function for the first time,
701+creates a CA client library context. A CA client library context contains all
702+of the threads, network circuits, and data structures required to connect and
703+communicate with the channels that a CA client application has created. The
704 priority of auxiliary threads spawned by the CA client library are at fixed
705 offsets from the priority of the thread that called <a
706 href="#ca_context_create">ca_context_create()</a>. An application specific
707@@ -2474,9 +2501,10 @@
708 It is not possible to attach a thread to a non-preemptive CA context created
709 explicitly <em>or implicitly</em> with
710 ca_create_context(ca_disable_preemptive_callback). Once a thread has joined
711-with a CA context it need only make ordinary ca_xxxx() library calls to use the
712-context.</p>
713-
714+with a CA context it need only make ordinary ca_xxxx()library calls to use the
715+context. There is no need to specify the context identifier when invoking the
716+CA calls because the context identifier is stored in a thread private variable
717+by ca_attach_context().</p>
718
719 <p>A CA client library context can be shut down and cleaned up, after
720 destroying any channels or application specific threads that are attached to
721@@ -2493,14 +2521,14 @@
722 ca_sg_block() or alternatively it must call ca_poll() at least every 100
723 milli-seconds. In single threaded applications a file descriptor manager like
724 Xt or the interface described in fdManager.h can be used to monitor both mouse
725-clicks and also CA's file descriptors so that ca_poll() can be called
726+clicks and also CA`s file descriptors so that ca_poll() can be called
727 immediately when CA server messages arrives over the network.</p>
728
729 <h3><a name="Avoid">Avoid Emulating Bad Practices that May Still be
730 Common</a></h3>
731
732 <p>With the embryonic releases of EPICS it was a common practice to examine a
733-channel's connection state, its native type, and its native element count by
734+channel`s connection state, its native type, and its native element count by
735 directly accessing fields in a structure using a pointer stored in type
736 <code>chid</code>. Likewise, a user private pointer in the per channel
737 structure was also commonly set by directly accessing fields in the channel
738@@ -2530,9 +2558,9 @@
739 <ul>
740 <li>The vxWorks shell thread runs at the very highest priority in the system
741 and therefore socket calls are made at a priority that is above the
742- priority of tNetTask - a practice that has caused the WRS IP kernel
743- to get sick in the past. That symptom was observed some time ago, but we
744- don't know if WRS has fixed the problem.</li>
745+ priority of tNetTask. This has caused problems with the WRS IP kernel in
746+ the past. That symptom was observed some time ago, but we don`t know
747+ if WRS has fixed the problem.</li>
748 </ul>
749 <ul>
750 <li>The vxWorks shell thread runs at the very highest priority in the system
751@@ -2547,7 +2575,7 @@
752 <ul>
753 <li>In EPICS R3.13 the CA client library installed vxWorks task exit handlers
754 behaved strangely if CA functions were called from the vxWorks shell,
755- ca_task_exit() wasn't called, and the vxWorks shell restarted. In
756+ ca_task_exit() wasn`t called, and the vxWorks shell restarted. In
757 EPICS R3.14 vxWorks task exit handlers are not installed and therefore
758 cleanup is solely the responsibility of the user. With EPICS R3.14 the user
759 must call ca_context_destroy or ca_task_exit to clean up on vxWorks. This
760@@ -2565,10 +2593,10 @@
761 <h2><a name="Function Call Reference"></a>Function Call Reference</h2>
762
763 <h3><code><a name="ca_context_create">ca_context_create()</a></code></h3>
764-<pre>#include &lt;cadef.h&gt;
765-enum ca_preemptive_callback_select
766- { ca_disable_preemptive_callback, ca_enable_preemptive_callback };
767-int ca_context_create ( enum ca_preemptive_callback_select SELECT );</pre>
768+<pre><code>#include &lt;cadef.h&gt;
769+enum ca_preemptive_callback_select
770+ { ca_disable_preemptive_callback, ca_enable_preemptive_callback };
771+int ca_context_create ( enum ca_preemptive_callback_select SELECT );</code></pre>
772
773 <h4>Description</h4>
774
775@@ -2592,7 +2620,7 @@
776 are two implications to consider. </dd>
777 <dd><p>First, if preemptive callback mode is enabled the developer must
778 provide mutual exclusion protection for his data structures. In this mode
779- it's possible for two threads to touch the application's data structures
780+ it`s possible for two threads to touch the application`s data structures
781 at once: this might be the initializing thread (the thread that called
782 ca_context_create) and also a private thread created by the CA client
783 library for the purpose of receiving network messages and calling
784@@ -2631,7 +2659,7 @@
785
786 <h4>Description</h4>
787
788-<p>Shut down the calling thread's channel access client context and free any
789+<p>Shut down the calling thread`s channel access client context and free any
790 resources allocated. Detach the calling thread from any CA client context.</p>
791
792 <p>Any user-created threads that have attached themselves to the CA context
793@@ -2647,8 +2675,13 @@
794 <p>On many OS that execute programs in a process based environment the
795 resources used by the client library such as sockets and allocated memory are
796 automatically released by the system when the process exits and
797+<<<<<<< TREE
798 ca_context_destroy() hasn't been called, but on light weight systems such as
799 vxWorks or RTEMS no cleanup occurs unless the application calls
800+=======
801+ca_context_destroy() hasn`t been called, but on light weight systems such as
802+vxWorks or RTEMS no cleanup occurs unless the application call
803+>>>>>>> MERGE-SOURCE
804 ca_context_destroy().</p>
805
806 <h4>Returns</h4>
807@@ -2659,27 +2692,42 @@
808
809 <p><a href="#ca_context_create">ca_context_create</a>()</p>
810
811+<<<<<<< TREE
812 <h3><code><a name="ca_create_channel">ca_create_channel()</a></code></h3>
813 <pre>#include &lt;cadef.h&gt;
814 typedef void ( caCh ) (struct connection_handler_args);
815 int ca_create_channel (const char *PVNAME,
816 caCh *USERFUNC, void *PUSER,
817 capri PRIORITY, chid *PCHID );</pre>
818+=======
819+<h3><a name="ca_create_channel"><code>ca_create_channel()</code></a></h3>
820+<pre><code>#include &lt;cadef.h&gt;
821+typedef void ( *pCallBack ) (
822+ struct connection_handler_args );
823+int ca_create_channel
824+(
825+ const char *PROCESS_VARIABLE_NAME,
826+ caCh *USERFUNC,
827+ void *PUSER,
828+ capri priority,
829+ chid *PCHID
830+);</code></pre>
831+>>>>>>> MERGE-SOURCE
832
833 <h4>Description</h4>
834
835 <p>This function creates a CA channel. The CA client library will attempt to
836-establish and maintain a virtual circuit between the caller's application and a
837+establish and maintain a virtual circuit between the caller`s application and a
838 named process variable in a CA server. Each call to ca_create_channel allocates
839 resources in the CA client library and potentially also a CA server. The
840 function ca_clear_channel() is used to release these resources. If successful,
841-the routine writes a channel identifier into the user's variable of type
842+the routine writes a channel identifier into the user`s variable of type
843 "chid". This identifier can be used with any channel access call that operates
844 on a channel.</p>
845
846 <p>The circuit may be initially connected or disconnected depending on the
847 state of the network and the location of the channel. A channel will only enter
848-a connected state after server's address is determined, and only if channel
849+a connected state after server`s address is determined, and only if channel
850 access successfully establishes a virtual circuit through the network to the
851 server. Channel access routines that send a request to a server will return
852 ECA_DISCONNCHID if the channel is currently disconnected.</p>
853@@ -2703,7 +2751,7 @@
854
855 <p>Due to the inherently transient nature of network connections the order of
856 connection call backs relative to the order that ca_create_channel() calls are
857-made by the application can't be guaranteed, and application programs may need
858+made by the application can`t be guaranteed, and application programs may need
859 to be prepared for a connected channel to enter a disconnected state at any
860 time.</p>
861
862@@ -2723,29 +2771,29 @@
863 </dl>
864 <dl>
865 <dt><code>USERFUNC</code></dt>
866- <dd>Optional address of the user's call back function to be run when the
867+ <dd>Optional address of the user`s call back function to be run when the
868 connection state changes. Casual users of channel access may decide to
869 set this field to nil or 0 if they do not need to have a call back
870- function run in response to each connection state change event.
871- <p>The following structure is passed <em>by value </em>to the user's
872+ function run in response to each connection state change event.
873+ <p>The following structure is passed <em>by value </em>to the user`s
874 connection connection callback function. The <code>op</code> field will
875 be set by the CA client library to <code>CA_OP_CONN_UP</code> when the
876 channel connects, and to <code>CA_OP_CONN_DOWN</code> when the channel
877 disconnects. See <code><a href="#ca_puser">ca_puser</a></code> if the
878 <code>PUSER</code> argument is required in your callback
879 handler<code>.</code></p>
880- <pre>struct ca_connection_handler_args {
881- chanId chid; /* channel id */
882- long op; /* one of CA_OP_CONN_UP or CA_OP_CONN_DOWN */
883-};</pre>
884+ <pre><code>struct ca_connection_handler_args {
885+ chanId chid; /* channel id */
886+ long op; /* one of CA_OP_CONN_UP or CA_OP_CONN_DOWN */
887+};</code></pre>
888 </dd>
889 </dl>
890 <dl>
891 <dt><code>PUSER</code></dt>
892- <dd>The value of this void pointer argument is retained in
893- storage associated with the specified channel. See the MACROS manual page
894- for reading and writing this field. Casual users of channel access may
895- wish to set this field to nil or 0.</dd>
896+ <dd>The value of this void pointer argument is retained in storage
897+ associated with the specified channel. See the MACROS manual page for
898+ reading and writing this field. Casual users of channel access may wish
899+ to set this field to nil or 0.</dd>
900 </dl>
901 <dl>
902 <dt><code>PRIORITY</code></dt>
903@@ -2778,9 +2826,9 @@
904
905 <p>ECA_ALLOCMEM - Unable to allocate memory</p>
906
907-<h3><code><a name="ca_clear_channel">ca_clear_channel()</a></code></h3>
908-<pre>#include &lt;cadef.h&gt;
909-int ca_clear_channel (chid CHID);</pre>
910+<h3><a name="ca_clear_channel"></a><code>ca_clear_channel()</code></h3>
911+<pre><code>#include &lt;cadef.h&gt;
912+int ca_clear_channel (chid CHID);</code></pre>
913
914 <h4>Description</h4>
915
916@@ -2808,8 +2856,8 @@
917
918 <p>ECA_BADCHID - Corrupted CHID</p>
919
920-<h3><code><a name="ca_put">ca_put()</a></code></h3>
921-<pre>#include &lt;cadef.h&gt;
922+<h3><a name="ca_put"><code>ca_put()</code></a></h3>
923+<pre><code>#include &lt;cadef.h&gt;
924 int ca_put ( chtype TYPE,
925 chid CHID, void *PVALUE );
926 int ca_array_put ( chtype TYPE, unsigned long COUNT,
927@@ -2820,13 +2868,21 @@
928 caEventCallBackFunc PFUNC, void *USERARG );
929 int ca_array_put_callback ( chtype TYPE, unsigned long COUNT,
930 chid CHID, const void *PVALUE,
931+<<<<<<< TREE
932 caEventCallBackFunc PFUNC, void *USERARG );</pre>
933+=======
934+ pCallBack PFUNC, void *USERARG );</code></pre>
935+>>>>>>> MERGE-SOURCE
936
937 <h4>Description</h4>
938
939 <p>Write a scalar or array value to a process variable.</p>
940
941+<<<<<<< TREE
942 <p>When ca_put or ca_array_put are invoked the client will receive no response
943+=======
944+<p>When ca_array_put or ca_put are invoked the client will receive no response
945+>>>>>>> MERGE-SOURCE
946 unless the request can not be fulfilled in the server. If unsuccessful an
947 exception handler is run on the client side.</p>
948
949@@ -2838,7 +2894,7 @@
950 </p>
951
952 <p>If the channel disconnects before a put callback request can be completed,
953-then the client's call back function is called with failure status, but this
954+then the client`s call back function is called with failure status, but this
955 does not guarantee that the server did not receive and process the request
956 before the disconnect. If a connection is lost and then resumed outstanding ca
957 put requests are not automatically reissued following reconnect.</p>
958@@ -2852,8 +2908,8 @@
959
960 <h4>Description (IOC Database Specific)</h4>
961
962-<p>A CA put request causes the record to process if the record's SCAN field is
963-set to passive, and the field being written has it's process passive attribute
964+<p>A CA put request causes the record to process if the record`s SCAN field is
965+set to passive, and the field being written has its process passive attribute
966 set to true. If such a record is already processing when a put request is
967 initiated the specified field is written immediately, and the record is
968 scheduled to process again as soon as it finishes processing. Earlier instances
969@@ -2861,21 +2917,45 @@
970 discarded, but the last put request initiated is always written and
971 processed.</p>
972
973-<p>A CA put <span style="font-style: italic;">callback</span> request causes
974-the record to process if the record's SCAN field is set to passive, and the
975-field being written has it's process passive attribute set to true. For such a
976-record, the user's put callback function is not called until after the record,
977-and any records that the record links to, finish processing. If such a record
978-is already processing when a put <span
979-style="font-style: italic;">callback</span> request is initiated the put <span
980-style="font-style: italic;">callback</span> request is postponed until the
981-record, and any records it links to, finish processing.</p>
982+<p>A CA put <em>callback</em> request causes the record to process if the
983+record`s SCAN field is set to passive, and the field being written has its
984+process passive attribute set to true. For such a record, the user`s put
985+callback function is not called until after the record, and any records that
986+the record links to, finish processing. If such a record is already processing
987+when a put <em>callback</em> request is initiated the put <em>callback</em>
988+request is postponed until the record, and any records it links to, finish
989+processing.</p>
990
991-<p>If the record's SCAN field is not set to passive, or the field being written
992-has it's process passive attribute set to false then the CA put or CA put
993+<p>If the record`s SCAN field is not set to passive, or the field being written
994+has its process passive attribute set to false, then the CA put or CA put
995 callback request cause the specified field to be immediately written, but they
996 do not cause the record to be processed.</p>
997
998+<h4>Description (IOC Database Specific)</h4>
999+
1000+<p>A CA put request causes the record to process if the record`s SCAN field is
1001+set to passive, and the field being written has its process passive attribute
1002+set to true. If such a record is already processing when a put request is
1003+initiated the specified field is written immediately, and the record is
1004+scheduled to process again as soon as it finishes processing. Earlier instances
1005+of multiple put requests initiated while the record is being processing may be
1006+discarded, but the last put request initiated is always written and
1007+processed.</p>
1008+
1009+<p>A CA put <em>callback</em> request causes the record to process if the
1010+record`s SCAN field is set to passive, and the field being written has its
1011+process passive attribute set to true. For such a record, the user`s put
1012+callback function is not called until after the record, and any records that
1013+the record links to, finish processing. If such a record is already processing
1014+when a put <em>callback</em> request is initiated the put <em>callback</em>
1015+request is postponed until the record, and any records it links to, finish
1016+processing.</p>
1017+
1018+<p>If the record`s SCAN field is not set to passive, or the field being written
1019+has its process passive attribute set to false then the CA put or CA put
1020+<em>callback</em> request cause the specified field to be immediately written,
1021+but they do not cause the record to be processed.</p>
1022+
1023 <h4>Arguments</h4>
1024 <dl>
1025 <dt><code>TYPE</code></dt>
1026@@ -2958,7 +3038,7 @@
1027 requests are not automatically reissued following reconnect.</p>
1028
1029 <p>When ca_get_callback or ca_array_get_callback are invoked a value is read
1030-from the channel and then the user's callback is invoked with a pointer to the
1031+from the channel and then the user`s callback is invoked with a pointer to the
1032 retrieved value. Note that ca_pend_io will not block for the delivery of values
1033 requested by ca_get_callback. If the channel disconnects before a ca get
1034 callback request can be completed, then the clients call back function is
1035@@ -2974,7 +3054,14 @@
1036
1037 <h4>Description (IOC Database Specific)</h4>
1038
1039-<p>A CA get or CA get callback request causes the record's field to be read
1040+<p>A CA get or CA get callback request causes the record`s field to be read
1041+immediately independent of whether the record is currently being processed or
1042+not. There is currently no mechanism in place to cause a record to be processed
1043+when a CA get request is initiated.</p>
1044+
1045+<h4>Description (IOC Database Specific)</h4>
1046+
1047+<p>A CA get or CA get callback request causes the record`s field to be read
1048 immediately independent of whether the record is currently being processed or
1049 not. There is currently no mechanism in place to cause a record to be processed
1050 when a CA get request is initiated.</p>
1051@@ -3042,6 +3129,7 @@
1052
1053 <p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
1054
1055+<<<<<<< TREE
1056 <h3><code><a name="ca_add_event">ca_create_subscription()</a></code></h3>
1057 <pre>#include &lt;cadef.h&gt;
1058 typedef void ( caEventCallBackFunc ) (struct event_handler_args);
1059@@ -3049,25 +3137,35 @@
1060 chid CHID, unsigned long MASK,
1061 caEventCallBackFunc USERFUNC, void *USERARG,
1062 evid *PEVID );</pre>
1063+=======
1064+<h3><a name="ca_add_event"></a><code>ca_create_subscription()</code></h3>
1065+<pre><code>#include &lt;cadef.h&gt;
1066+typedef void ( *pCallBack ) (
1067+ struct event_handler_args );
1068+int ca_create_subscription ( chtype TYPE,
1069+ unsigned long COUNT, chid CHID,
1070+ unsigned long MASK, pCallBack USERFUNC, void *USERARG,
1071+ evid *PEVID );</code></pre>
1072+>>>>>>> MERGE-SOURCE
1073
1074 <h4>Description</h4>
1075
1076 <p>Register a state change subscription and specify a call back function to be
1077 invoked whenever the process variable undergoes significant state changes. A
1078-significant change can be a change in the process variable's value, alarm
1079+significant change can be a change in the process variable`s value, alarm
1080 status, or alarm severity. In the process control function block database the
1081 deadband field determines the magnitude of a significant change for for the
1082-process variable's value. Each call to this function consumes resources in the
1083+process variable`s value. Each call to this function consumes resources in the
1084 client library and potentially a CA server until one of ca_clear_channel or
1085 ca_clear_event is called.</p>
1086
1087 <p>Subscriptions may be installed or canceled against both connected and
1088 disconnected channels. The specified USERFUNC is called once immediately after
1089-the subscription is installed with the process variable's current state if the
1090+the subscription is installed with the process variable`s current state if the
1091 process variable is connected. Otherwise, the specified USERFUNC is called
1092 immediately after establishing a connection (or reconnection) with the process
1093 variable. The specified USERFUNC is called immediately with the process
1094-variable's current state from within ca_add_event() if the client and the
1095+variable`s current state from within ca_add_event() if the client and the
1096 process variable share the same address space.</p>
1097
1098 <p>If a subscription is installed on a channel in a disconnected state then the
1099@@ -3124,8 +3222,8 @@
1100 <dl>
1101 <dt><code>PEVID</code></dt>
1102 <dd>This is a pointer to user supplied event id which is overwritten if
1103- successful. This event id can later be used to clear a specific
1104- event. This option may may be omitted by passing a nil pointer.</dd>
1105+ successful. This event id can later be used to clear a specific event.
1106+ This option may may be omitted by passing a nill pointer.</dd>
1107 </dl>
1108 <dl>
1109 <dt><code>MASK</code></dt>
1110@@ -3142,7 +3240,7 @@
1111 </ul>
1112 <p>For functions above that do not include a trigger specification,
1113 events will be triggered when there are significant changes in the
1114- channel's value or when there are changes in the channel's alarm state.
1115+ channel`s value or when there are changes in the channel`s alarm state.
1116 This is the same as "DBE_VALUE | DBE_ALARM."</p>
1117 </dd>
1118 </dl>
1119@@ -3232,9 +3330,9 @@
1120 network delays such as Ethernet collision exponential back off until
1121 retransmission delays which can be quite long on overloaded networks.</p>
1122
1123-<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a></code>, this routine will
1124-not process CA's background activities if none of the selected IO requests are
1125-pending.</p>
1126+<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a></code>, this routine
1127+will not process CA`s background activities if none of the selected IO requests
1128+are pending.</p>
1129
1130 <h4>Arguments</h4>
1131 <dl>
1132@@ -3303,7 +3401,7 @@
1133 requests.</p>
1134
1135 <p>Both <code>ca_pend_event</code> and <code>ca_poll</code> return ECA_TIMEOUT
1136-when successful. This behavior probably isn't intuitive, but it is preserved to
1137+when successful. This behavior probably isn`t intuitive, but it is preserved to
1138 insure backwards compatibility.</p>
1139
1140 <p>See also <a href="#Thread">Thread Safety and Preemptive Callback to User
1141@@ -3329,8 +3427,8 @@
1142
1143 <h4>Description</h4>
1144
1145-<p>Flush outstanding IO requests to the server. This routine might be useful
1146-to users who need to flush requests prior to performing client side labor in
1147+<p>Flush outstanding IO requests to the server. This routine might be useful to
1148+users who need to flush requests prior to performing client side labor in
1149 parallel with labor performed in the server.</p>
1150
1151 <p>Outstanding requests are also sent whenever the buffer which holds them
1152@@ -3340,10 +3438,10 @@
1153
1154 <p>ECA_NORMAL - Normal successful completion</p>
1155
1156-<h3><code><a name="ca_signal">ca_signal()</a></code></h3>
1157-<pre>#include &lt;cadef.h&gt;
1158+<h3><code><a name="ca_signal">ca_signal</a>()</code></h3>
1159+<pre><code>#include &lt;cadef.h&gt;
1160 int ca_signal ( long CA_STATUS, const char * CONTEXT_STRING );
1161-void SEVCHK( CA_STATUS, CONTEXT_STRING );</pre>
1162+void SEVCHK( CA_STATUS, CONTEXT_STRING );</code></pre>
1163
1164 <h4>Description</h4>
1165
1166@@ -3359,8 +3457,8 @@
1167 code testing the status returned from each channel access call.</p>
1168
1169 <h4>Examples</h4>
1170-<pre>status = ca_context_create (...);
1171-SEVCHK ( status, "Unable to create a CA client context" );</pre>
1172+<pre><code>status = ca_context_create (...);
1173+SEVCHK ( status, "Unable to create a CA client context" );</code></pre>
1174
1175 <p>If the application only wishes to print the message associated with an error
1176 code or test the severity of an error there are also functions provided for
1177@@ -3396,7 +3494,7 @@
1178 information about this type of error is passed from the server to the client in
1179 an exception message. When the client receives this exception message an
1180 exception handler callback is called.The default exception handler prints a
1181-diagnostic message on the client's standard out and terminates execution if the
1182+diagnostic message on the client`s standard out and terminates execution if the
1183 error condition is severe.</p>
1184
1185 <p>Note that certain fields in "struct exception_handler_args" are not
1186@@ -3409,23 +3507,23 @@
1187 <dl>
1188 <dt><code>USERFUNC</code></dt>
1189 <dd>Address of user callback function to be executed when an exceptions
1190- occur. Passing a nil value causes the default exception handler to be
1191- reinstalled. The following structure is passed by value to the user's
1192+ occur. Passing a nill value causes the default exception handler to be
1193+ reinstalled. The following structure is passed by value to the user`s
1194 callback function. Currently, the <code>op</code> field can be one of
1195 <code>CA_OP_GET, CA_OP_PUT, CA_OP_CREATE_CHANNEL, CA_OP_ADD_EVENT,
1196- CA_OP_CLEAR_EVENT, or CA_OP_OTHER.</code>
1197- <pre>struct exception_handler_args {
1198+ CA_OP_CLEAR_EVENT, or CA_OP_OTHER.</code>
1199+ <pre><code>struct exception_handler_args {
1200 void *usr; /* user argument supplied when installed */
1201 chanId chid; /* channel id (may be nill) */
1202 long type; /* type requested */
1203 long count; /* count requested */
1204- void *addr; /* user's address to write results of CA_OP_GET */
1205+ void *addr; /* user`s address to write results of CA_OP_GET */
1206 long stat; /* channel access ECA_XXXX status code */
1207 long op; /* CA_OP_GET, CA_OP_PUT, ..., CA_OP_OTHER */
1208 const char *ctx; /* a character string containing context info */
1209 sonst char *pFile; /* source file name (may be NULL) */
1210 unsigned lineNo; /* source file line number (may be zero) */
1211-};</pre>
1212+};</code></pre>
1213 </dd>
1214 </dl>
1215 <dl>
1216@@ -3435,7 +3533,7 @@
1217 </dl>
1218
1219 <h4>Example</h4>
1220-<pre>void ca_exception_handler (
1221+<pre><code>void ca_exception_handler (
1222 struct exception_handler_args args)
1223 {
1224 char buf[512];
1225@@ -3448,11 +3546,11 @@
1226 pName = "?";
1227 }
1228 sprintf ( buf,
1229- "%s - with request chan=%s op=%d data type=%s count=%d",
1230- args.ctx, pName, args.op, dbr_type_to_text ( args.type ), args.count );
1231- ca_signal ( args.stat, buf );
1232+ "%s - with request chan=%s op=%d data type=%s count=%d",
1233+ args.ctx, pName, args.op, dbr_type_to_text ( args.type ), args.count );
1234+ ca_signal ( args.stat, buf );
1235 }
1236-ca_add_exception_event ( ca_exception_handler , 0 );</pre>
1237+ca_add_exception_event ( ca_exception_handler , 0 );</code></pre>
1238
1239 <h4>Returns</h4>
1240
1241@@ -3460,9 +3558,11 @@
1242
1243 <p></p>
1244
1245-<h3><code><a name="ca_add_fd_registration">ca_add_fd_registration()</a></code></h3>
1246-<pre>#include &lt;cadef.h&gt;
1247-int ca_add_fd_registration ( void ( USERFUNC * ) ( void *USERARG, int FD, int OPENED ), void * USERARG )</pre>
1248+<h3><code><a name="ca_add_fd_"
1249+id="ca_add_fd_registration">ca_add_fd_registration()</a></code></h3>
1250+<pre><code>#include &lt;cadef.h&gt;
1251+int ca_add_fd_registration ( void ( USERFUNC * ) ( void *USERARG,
1252+ int FD, int OPENED ), void * USERARG )</code></pre>
1253
1254 <h4>Description</h4>
1255
1256@@ -3496,7 +3596,7 @@
1257 file descriptor was closed.</p>
1258
1259 <h4>Example</h4>
1260-<pre>int s;
1261+<pre><code>int s;
1262 static struct myStruct aStruct;
1263
1264 void fdReg ( struct myStruct *pStruct, int fd, int opened )
1265@@ -3505,7 +3605,7 @@
1266 else printf ( "fd %d was closed\n", fd );
1267 }
1268 s = ca_add_fd_registration ( fdReg, &amp; aStruct );
1269-SEVCHK ( s, NULL );</pre>
1270+SEVCHK ( s, NULL );</code></pre>
1271
1272 <h4>Comments</h4>
1273
1274@@ -3531,9 +3631,15 @@
1275
1276 <h3><code><a name="ca_replace_printf_handler">ca_replace_printf_handler
1277 ()</a></code></h3>
1278+<<<<<<< TREE
1279 <pre>#include &lt;cadef.h&gt;
1280 typedef int caPrintfFunc ( const char *pFormat, va_list args );
1281 int ca_replace_printf_handler ( caPrintfFunc *PFUNC );</pre>
1282+=======
1283+<pre><code>#include &lt;cadef.h&gt;
1284+typedef int caPrintfFunc ( const char *pFromat, va_list args );
1285+int ca_replace_printf_handler ( caPrintfFunc *PFUNC );</code></pre>
1286+>>>>>>> MERGE-SOURCE
1287
1288 <h4>Description</h4>
1289
1290@@ -3544,28 +3650,34 @@
1291 <dl>
1292 <dt><code>PFUNC</code></dt>
1293 <dd>The address of a user supplied call back handler to be invoked when CA
1294- prints diagnostic messages. Installing a nil pointer will cause the
1295+ prints diagnostic messages. Installing a nill pointer will cause the
1296 default call back handler to be reinstalled.</dd>
1297 </dl>
1298
1299 <h4>Examples</h4>
1300-<pre>int my_printf ( char *pformat, va_list args ) {
1301+<pre><code>int my_printf ( char *pformat, va_list args ) {
1302 int status;
1303 status = vfprintf( stderr, pformat, args);
1304 return status;
1305 }
1306 status = ca_replace_printf_handler ( my_printf );
1307-SEVCHK ( status, "failed to install my printf handler" );</pre>
1308+SEVCHK ( status, "failed to install my printf handler" );</code></pre>
1309
1310 <h4>Returns</h4>
1311
1312 <p>ECA_NORMAL - Normal successful completion</p>
1313
1314 <h3><code><a name="ca_replace">ca_replace_access_rights_event()</a></code></h3>
1315+<<<<<<< TREE
1316 <pre>#include &lt;cadef.h&gt;
1317 typedef void ( caEventCallBackFunc )(struct access_rights_handler_args);
1318 int ca_replace_access_rights_event ( chid CHAN,
1319 caEventCallBackFunc PFUNC );</pre>
1320+=======
1321+<pre><code>#include &lt;cadef.h&gt;
1322+typedef void ( *pCallBack )( struct access_rights_handler_args );
1323+int ca_replace ( chid CHAN, pCallBack PFUNC );</code></pre>
1324+>>>>>>> MERGE-SOURCE
1325
1326 <h4>Description</h4>
1327
1328@@ -3574,9 +3686,9 @@
1329
1330 <p>The callback handler is called in the following situations.</p>
1331 <ul>
1332- <li>whenever CA connects the channel immediately before the channel's
1333+ <li>whenever CA connects the channel immediately before the channel`s
1334 connection handler is called</li>
1335- <li>whenever CA disconnects the channel immediately after the channel's
1336+ <li>whenever CA disconnects the channel immediately after the channel`s
1337 disconnect call back is called</li>
1338 <li>once immediately after installation if the channel is connected.</li>
1339 <li>whenever the access rights state of a connected channel changes</li>
1340@@ -3591,10 +3703,10 @@
1341 </dl>
1342 <dl>
1343 <dt><code>PFUNC</code></dt>
1344- <dd>Address of user supplied call back function. A nil pointer uninstalls
1345+ <dd>Address of user supplied call back function. A nill pointer uninstalls
1346 the current handler. The following arguments are passed <em>by value</em>
1347 to the supplied callback handler.
1348- <pre>typedef struct ca_access_rights {
1349+ <pre><code>typedef struct ca_access_rights {
1350 unsigned read_access:1;
1351 unsigned write_access:1;
1352 } caar;
1353@@ -3603,7 +3715,7 @@
1354 struct access_rights_handler_args {
1355 chanId chid; /* channel id */
1356 caar ar; /* new access rights state */
1357-};</pre>
1358+};</code></pre>
1359 </dd>
1360 </dl>
1361
1362@@ -3611,9 +3723,15 @@
1363
1364 <p>ECA_NORMAL - Normal successful completion</p>
1365
1366+<h4>See Also</h4>
1367+
1368+<p>ca_modify_user_name()</p>
1369+
1370+<p>ca_modify_host_name()</p>
1371+
1372 <h3><code><a name="ca_field_type">ca_field_type()</a></code></h3>
1373-<pre>#include &lt;cadef.h&gt;
1374-chtype ca_field_type ( CHID );</pre>
1375+<pre><code>#include &lt;cadef.h&gt;
1376+chtype ca_field_type ( CHID );</code></pre>
1377
1378 <h4>Description</h4>
1379
1380@@ -3634,8 +3752,8 @@
1381 </dl>
1382
1383 <h3><code><a name="ca_element_count">ca_element_count()</a></code></h3>
1384-<pre>#include &lt;cadef.h&gt;
1385-unsigned ca_element_count ( CHID );</pre>
1386+<pre><code>#include &lt;cadef.h&gt;
1387+unsigned ca_element_count ( CHID );</code></pre>
1388
1389 <h4>Description</h4>
1390
1391@@ -3651,13 +3769,13 @@
1392 <h4>Returns</h4>
1393 <dl>
1394 <dt><code>COUNT</code></dt>
1395- <dd>The maximum array element count in the server. An element count of
1396- zero is returned if the channel is disconnected.</dd>
1397+ <dd>The maximum array element count in the server. An element count of zero
1398+ is returned if the channel is disconnected.</dd>
1399 </dl>
1400
1401 <h3><code><a name="ca_name">ca_name()</a></code></h3>
1402-<pre>#include &lt;cadef.h&gt;
1403-char * ca_name ( CHID );</pre>
1404+<pre><code>#include &lt;cadef.h&gt;
1405+char * ca_name ( CHID );</code></pre>
1406
1407 <h4>Description</h4>
1408
1409@@ -3677,8 +3795,8 @@
1410 </dl>
1411
1412 <h3><code><a name="ca_set_puser">ca_set_puser()</a></code></h3>
1413-<pre>#include &lt;cadef.h&gt;
1414-void ca_set_puser ( chid CHID, void *PUSER );</pre>
1415+<pre><code>#include &lt;cadef.h&gt;
1416+void ca_set_puser ( chid CHID, void *PUSER );</code></pre>
1417
1418 <h4>Description</h4>
1419
1420@@ -3696,8 +3814,8 @@
1421 </dl>
1422
1423 <h3><code><a name="ca_puser">ca_puser()</a></code></h3>
1424-<pre>#include &lt;cadef.h&gt;
1425-void * ca_puser ( CHID );</pre>
1426+<pre><code>#include &lt;cadef.h&gt;
1427+void * ca_puser ( CHID );</code></pre>
1428
1429 <h4>Description</h4>
1430
1431@@ -3717,13 +3835,13 @@
1432 </dl>
1433
1434 <h3><code><a name="ca_state">ca_state()</a></code></h3>
1435-<pre>#include &lt;cadef.h&gt;
1436+<pre><code>#include &lt;cadef.h&gt;
1437 enum channel_state {
1438- cs_never_conn, /* valid chid, server not found or unavailable */
1439- cs_prev_conn, /* valid chid, previously connected to server */
1440- cs_conn, /* valid chid, connected to server */
1441- cs_closed }; /* channel deleted by user */
1442-enum channel_state ca_state ( CHID );</pre>
1443+ cs_never_conn, /* valid chid, server not found or unavailable */
1444+ cs_prev_conn, /* valid chid, previously connected to server */
1445+ cs_conn, /* valid chid, connected to server */
1446+ cs_closed }; /* channel deleted by user */
1447+enum channel_state ca_state ( CHID );</code></pre>
1448
1449 <h4>Description</h4>
1450
1451@@ -3743,8 +3861,8 @@
1452 </dl>
1453
1454 <h3><code><a name="ca_message">ca_message()</a></code></h3>
1455-<pre>#include &lt;cadef.h&gt;
1456-const char * ca_message ( STATUS );</pre>
1457+<pre><code>#include &lt;cadef.h&gt;
1458+const char * ca_message ( STATUS );</code></pre>
1459
1460 <h4>Description</h4>
1461
1462@@ -3764,8 +3882,8 @@
1463 </dl>
1464
1465 <h3><code><a name="ca_host_name">ca_host_name()</a></code></h3>
1466-<pre>#include &lt;cadef.h&gt;
1467-char * ca_host_name ( CHID );</pre>
1468+<pre><code>#include &lt;cadef.h&gt;
1469+char * ca_host_name ( CHID );</code></pre>
1470
1471 <h4>Description</h4>
1472
1473@@ -3781,13 +3899,13 @@
1474 <h4>Returns</h4>
1475 <dl>
1476 <dt><code>STRING</code></dt>
1477- <dd>The process variable server's host name. If the channel is disconnected
1478+ <dd>The process variable server`s host name. If the channel is disconnected
1479 the string "&lt;disconnected&gt;" is returned.</dd>
1480 </dl>
1481
1482 <h3><code><a name="ca_read_access">ca_read_access()</a></code></h3>
1483-<pre>#include &lt;cadef.h&gt;
1484-int ca_read_access ( CHID );</pre>
1485+<pre><code>#include &lt;cadef.h&gt;
1486+int ca_read_access ( CHID );</code></pre>
1487
1488 <h4>Description</h4>
1489
1490@@ -3808,8 +3926,8 @@
1491 </dl>
1492
1493 <h3><code><a name="ca_write_access">ca_write_access()</a></code></h3>
1494-<pre>#include &lt;cadef.h&gt;
1495-int ca_write_access ( CHID );</pre>
1496+<pre><code>#include &lt;cadef.h&gt;
1497+int ca_write_access ( CHID );</code></pre>
1498
1499 <h4>Description</h4>
1500
1501@@ -3830,8 +3948,8 @@
1502 </dl>
1503
1504 <h3><code><a name="dbr_size[]">dbr_size[]</a></code></h3>
1505-<pre>#include &lt;db_access.h&gt;
1506-extern unsigned dbr_size[/* TYPE */];</pre>
1507+<pre><code>#include &lt;db_access.h&gt;
1508+extern unsigned dbr_size[/*TYPE*/];</code></pre>
1509
1510 <h4>Description</h4>
1511
1512@@ -3850,8 +3968,8 @@
1513 </dl>
1514
1515 <h3><code><a name="dbr_size_n">dbr_size_n()</a></code></h3>
1516-<pre>#include &lt;db_access.h&gt;
1517-unsigned dbr_size_n ( TYPE, COUNT );</pre>
1518+<pre><code>#include &lt;db_access.h&gt;
1519+unsigned dbr_size_n ( TYPE, COUNT );</code></pre>
1520
1521 <h4>Description</h4>
1522
1523@@ -3879,8 +3997,8 @@
1524 </dl>
1525
1526 <h3><code><a name="dbr_value_size">dbr_value_size[]</a></code></h3>
1527-<pre>#include &lt;db_access.h&gt;
1528-extern unsigned dbr_value_size[/* TYPE */];</pre>
1529+<pre><code>#include &lt;db_access.h&gt;
1530+extern unsigned dbr_value_size[/* TYPE */];</code></pre>
1531
1532 <h4>Description</h4>
1533
1534@@ -3902,8 +4020,8 @@
1535 </dl>
1536
1537 <h3><code><a name="dbr_type_t">dbr_type_to_text</a>()</code></h3>
1538-<pre>#include &lt;db_access.h&gt;
1539-const char * dbr_type_text ( chtype TYPE );</pre>
1540+<pre><code>#include &lt;db_access.h&gt;
1541+const char * dbr_type_text ( chtype TYPE );</code></pre>
1542
1543 <h4>Description</h4>
1544
1545@@ -3933,17 +4051,17 @@
1546 prints diagnostics to standard out.</p>
1547
1548 <h4>Examples</h4>
1549-<pre>void ca_test_event ();
1550+<pre><code>void ca_test_event ();
1551 status = ca_add_event ( type, chid, ca_test_event, NULL, NULL );
1552-SEVCHK ( status, .... );</pre>
1553+SEVCHK ( status, .... );</code></pre>
1554
1555 <h4>See Also</h4>
1556
1557 <p><a href="#ca_add_event">ca_add_event</a>()</p>
1558
1559 <h3><code><a name="ca_sg_create">ca_sg_create()</a></code></h3>
1560-<pre>#include &lt;cadef.h&gt;
1561-int ca_sg_create ( CA_SYNC_GID *PGID );</pre>
1562+<pre><code>#include &lt;cadef.h&gt;
1563+int ca_sg_create ( CA_SYNC_GID *PGID );</code></pre>
1564
1565 <h4>Description</h4>
1566
1567@@ -3967,9 +4085,9 @@
1568 </dl>
1569
1570 <h4>Examples</h4>
1571-<pre>CA_SYNC_GID gid;
1572+<pre><code>CA_SYNC_GID gid;
1573 status = ca_sg_create ( &amp;gid );
1574-SEVCHK ( status, Sync group create failed );</pre>
1575+SEVCHK ( status, Sync group create failed );</code></pre>
1576
1577 <h4>Returns</h4>
1578
1579@@ -3992,8 +4110,8 @@
1580 <p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
1581
1582 <h3><code><a name="ca_sg_delete">ca_sg_delete()</a></code></h3>
1583-<pre>#include &lt;cadef.h&gt;
1584-int ca_sg_delete ( CA_SYNC_GID GID );</pre>
1585+<pre><code>#include &lt;cadef.h&gt;
1586+int ca_sg_delete ( CA_SYNC_GID GID );</code></pre>
1587
1588 <h4>Description</h4>
1589
1590@@ -4006,9 +4124,9 @@
1591 </dl>
1592
1593 <h4>Examples</h4>
1594-<pre>CA_SYNC_GID gid;
1595+<pre><code>CA_SYNC_GID gid;
1596 status = ca_sg_delete ( gid );
1597-SEVCHK ( status, Sync group delete failed );</pre>
1598+SEVCHK ( status, Sync group delete failed );</code></pre>
1599
1600 <h4>Returns</h4>
1601
1602@@ -4020,9 +4138,15 @@
1603
1604 <p><a href="#ca_sg_create">ca_sg_create</a>()</p>
1605
1606+<<<<<<< TREE
1607 <h3><code><a name="ca_sg_block">ca_sg_block()</a></code></h3>
1608 <pre>#include &lt;cadef.h&gt;
1609 int ca_sg_block ( CA_SYNC_GID GID, double TIMEOUT );</pre>
1610+=======
1611+<h3><a name="ca_sg_block"><code>ca_sg_block</code></a><code>()</code></h3>
1612+<pre><code>#include &lt;cadef.h&gt;
1613+int ca_sg_block ( CA_SYNC_GID GID, double timeout );</code></pre>
1614+>>>>>>> MERGE-SOURCE
1615
1616 <h4>Description</h4>
1617
1618@@ -4036,7 +4160,7 @@
1619 are outstanding then ca_sg_block() will return immediately without processing
1620 any pending channel access activities.</p>
1621
1622-<p>Values written into your program's variables by a channel access synchronous
1623+<p>Values written into your program`s variables by a channel access synchronous
1624 group request should not be referenced by your program until ECA_NORMAL has
1625 been received from ca_sg_block(). This routine will process pending channel
1626 access background activity while it is waiting.</p>
1627@@ -4051,9 +4175,15 @@
1628 </dl>
1629
1630 <h4>Examples</h4>
1631+<<<<<<< TREE
1632 <pre>CA_SYNC_GID gid;
1633 status = ca_sg_block(gid, 0.0);
1634 SEVCHK(status, Sync group block failed);</pre>
1635+=======
1636+<pre><code>CA_SYNC_GID gid;
1637+status = ca_sg_block(gid);
1638+SEVCHK(status, Sync group block failed);</code></pre>
1639+>>>>>>> MERGE-SOURCE
1640
1641 <h4>Returns</h4>
1642
1643@@ -4072,8 +4202,8 @@
1644 <p><a href="#ca_sg_reset">ca_sg_reset</a>()</p>
1645
1646 <h3><code><a name="ca_sg_test">ca_sg_test()</a></code></h3>
1647-<pre>#include &lt;cadef.h&gt;
1648-int ca_sg_test ( CA_SYNC_GID GID )</pre>
1649+<pre><code>#include &lt;cadef.h&gt;
1650+int ca_sg_test ( CA_SYNC_GID GID )</code></pre>
1651
1652 <h4>Description</h4>
1653
1654@@ -4092,8 +4222,8 @@
1655 completed.</p>
1656
1657 <h4>Examples</h4>
1658-<pre>CA_SYNC_GID gid;
1659-status = ca_sg_test ( gid );</pre>
1660+<pre><code>CA_SYNC_GID gid;
1661+status = ca_sg_test ( gid );</code></pre>
1662
1663 <h4>Returns</h4>
1664
1665@@ -4102,8 +4232,8 @@
1666 <p>ECA_IOINPROGRESS - Some IO operations still in progress</p>
1667
1668 <h3><code><a name="ca_sg_reset">ca_sg_reset()</a></code></h3>
1669-<pre>#include &lt;cadef.h&gt;
1670-int ca_sg_reset ( CA_SYNC_GID GID )</pre>
1671+<pre><code>#include &lt;cadef.h&gt;
1672+int ca_sg_reset ( CA_SYNC_GID GID )</code></pre>
1673
1674 <h4>Description</h4>
1675
1676@@ -4118,8 +4248,8 @@
1677 </dl>
1678
1679 <h4>Examples</h4>
1680-<pre>CA_SYNC_GID gid;
1681-status = ca_sg_reset(gid);</pre>
1682+<pre><code>CA_SYNC_GID gid;
1683+status = ca_sg_reset(gid);</code></pre>
1684
1685 <h4>Returns</h4>
1686
1687@@ -4127,10 +4257,10 @@
1688
1689 <p>ECA_BADSYNCGRP - Invalid synchronous group</p>
1690
1691-<h3><code><a name="ca_sg_put">ca_sg_array_put()</a></code></h3>
1692-<pre>#include &lt;cadef.h&gt;
1693+<h3><code><a name="ca_sg_put">ca_sg_put()</a></code></h3>
1694+<pre><code>#include &lt;cadef.h&gt;
1695 int ca_sg_array_put ( CA_SYNC_GID GID, chtype TYPE,
1696- unsigned long COUNT, chid CHID, void *PVALUE );</pre>
1697+ unsigned long COUNT, chid CHID, void *PVALUE );</code></pre>
1698
1699 <p>Write a value, or array of values, to a channel and increment the
1700 outstanding request count of a synchronous group. The ca_sg_array_put
1701@@ -4189,11 +4319,11 @@
1702
1703 <p><a href="#ca_flush_io">ca_flush_io</a>()</p>
1704
1705-<h3><code><a name="ca_sg_get">ca_sg_array_get()</a></code></h3>
1706-<pre>#include &lt;cadef.h&gt;
1707-int ca_sg_array_get ( CA_SYNC_GID GID,
1708- chtype TYPE, unsigned long COUNT,
1709- chid CHID, void *PVALUE );</pre>
1710+<h3><code><a name="ca_sg_get">ca_sg_get()</a></code></h3>
1711+<pre><code>#include &lt;cadef.h&gt;
1712+int ca_sg_array_get ( CA_SYNC_GID GID,
1713+ chtype TYPE, unsigned long COUNT,
1714+ chid CHID, void *PVALUE );</code></pre>
1715
1716 <h4>Description</h4>
1717
1718@@ -4201,7 +4331,7 @@
1719 synchronous group. The ca_sg_array_get functionality is implemented using
1720 ca_array_get_callback.</p>
1721
1722-<p>The values written into your program's variables by ca_sg_get should not be
1723+<p>The values written into your program`s variables by ca_sg_get should not be
1724 referenced by your program until ECA_NORMAL has been received from ca_sg_block,
1725 or until ca_sg_test returns ECA_IODONE.</p>
1726
1727@@ -4285,7 +4415,7 @@
1728
1729 <h4>Description</h4>
1730
1731-<p>Returns a pointer to the current thread's CA context. If none then nil is
1732+<p>Returns a pointer to the current thread`s CA context. If none then nill is
1733 returned.</p>
1734
1735 <h4>See Also</h4>
1736@@ -4355,7 +4485,13 @@
1737 <p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
1738
1739 <h3><code><a name="ca_dump_dbr">ca_dump_dbr()</a></code></h3>
1740+<<<<<<< TREE
1741 <code><pre>void ca_dump_dbr (chtype TYPE, unsigned COUNT, const void * PDBR);</pre></code>
1742+=======
1743+<pre><code>
1744+void ca_dump_dbr (chtype TYPE,
1745+ unsigned COUNT, const void * PDBR);</code></pre>
1746+>>>>>>> MERGE-SOURCE
1747
1748 <h4>Description</h4>
1749
1750@@ -4444,7 +4580,7 @@
1751 <dd>Preemptive callback not enabled - additional threads may not join
1752 context</dd>
1753 <dt>ECA_16KARRAYCLIENT</dt>
1754- <dd>Client's protocol revision does not support transfers exceeding 16k
1755+ <dd>Client`s protocol revision does not support transfers exceeding 16k
1756 bytes</dd>
1757 </dl>
1758

Subscribers

People subscribed via source and target branches