Merge lp:~jlmuir/epics-appdev/typo-fixes-3.14 into lp:~epics-documenters/epics-appdev/3.16

Proposed by J. Lewis Muir
Status: Merged
Merged at revision: 37
Proposed branch: lp:~jlmuir/epics-appdev/typo-fixes-3.14
Merge into: lp:~epics-documenters/epics-appdev/3.16
Diff against target: 1203 lines (+362/-324) (has conflicts)
3 files modified
tex/errorLogging.tex (+141/-133)
tex/libCom.tex (+1/-1)
tex/recordSupport.tex (+220/-190)
Text conflict in tex/errorLogging.tex
To merge this branch: bzr merge lp:~jlmuir/epics-appdev/typo-fixes-3.14
Reviewer Review Type Date Requested Status
Ralph Lange Needs Fixing
Review via email: mp+87812@code.launchpad.net

Description of the change

Typo fix.

To post a comment you must log in.
Revision history for this message
Ralph Lange (ralph-lange) wrote :

Could you fix the conflict and re-propose?

review: Needs Fixing
38. By Andrew Johnson

Merged Lewis' typo fix.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'tex/errorLogging.tex'
2--- tex/errorLogging.tex 2011-10-28 20:44:28 +0000
3+++ tex/errorLogging.tex 2012-01-06 20:56:29 +0000
4@@ -3,26 +3,25 @@
5
6 \section{Overview }
7
8-Errors detected by an IOC can be divided into classes: Errors related to a particular client and errors not attributable to a
9-particular client. An example of the first type of error is an illegal Channel Access request. For this type of error, a status
10-value should be passed back to the client. An example of the second type of error is a device driver detecting a hardware
11-error. This type of error should be reported to a system wide error handler.
12+Errors detected by an IOC can be divided into classes:
13+Errors related to a particular client and errors not attributable to a particular client.
14+An example of the first type of error is an illegal Channel Access request.
15+For this type of error, a status value should be passed back to the client.
16+An example of the second type of error is a device driver detecting a hardware error.
17+This type of error should be reported to a system wide error handler.
18
19 Dividing errors into these two classes is complicated by a number of factors.
20
21 \begin{itemize}
22-\item In many cases it is not possible for the routine detecting an error to decide which type of error occurred.
23-
24-\item Normally, only the routine detecting the error knows how to generate a fully descriptive error message. Thus, if a
25-routine decides that the error belongs to a particular client and merely returns an error status value, the ability to
26-generate a fully descriptive error message is lost.
27-
28-\item If a routine always generates fully descriptive error messages then a particular client could cause error message
29-storms.
30-
31-\item While developing a new application the programmer normally prefers fully descriptive error messages. For a
32-production system, however, the system wide error handler should not normally receive error messages cause by a
33-particular client.
34+\item In many cases it is not possible for the routine detecting an error to decide which type of error occurred.
35+
36+\item Normally, only the routine detecting the error knows how to generate a fully descriptive error message.
37+Thus, if a routine decides that the error belongs to a particular client and merely returns an error status value, the ability to generate a fully descriptive error message is lost.
38+
39+\item If a routine always generates fully descriptive error messages then a particular client could cause error message storms.
40+
41+\item While developing a new application the programmer normally prefers fully descriptive error messages.
42+For a production system, however, the system wide error handler should not normally receive error messages cause by a particular client.
43
44 \end{itemize}
45
46@@ -37,18 +36,20 @@
47
48 \item errlogThread - A thread that passes the messages to all registered listeners.
49
50-\item console output and message buffer size - Messages can also be written to the console. The storage for the message
51-queue can be specified by the user.
52+\item console output and message buffer size - Messages can also be written to the console.
53+The storage for the message queue can be specified by the user.
54
55 \item status codes - EPICS status codes.
56
57-\item iocLog- A system wide error logger supplied with base. It writes all messages to a system wide file.
58+\item iocLog- A system wide error logger supplied with base.
59+It writes all messages to a system wide file.
60
61 NOTE: Many sites use CMLOG instead of iocLog.
62
63 \end{itemize}
64
65-NOTE: \verb|recGbl| error routines are also provided. They in turn call one of the error message routines.
66+NOTE: \verb|recGbl| error routines are also provided.
67+They in turn call one of the error message routines.
68
69 \section{Error Message Routines}
70
71@@ -64,10 +65,8 @@
72 \index{errlogVprintf}
73 \index{errlogMessage}
74 \index{errlogFlush}
75- \verb|errlogPrintf| and \verb|errlogVprintf| are like \verb|printf| and \verb|vprintf| provided by the standard C library, except
76-that their output is sent to the errlog task; unless configured not to, the output will appear on the console as well. Consult
77-any book that describes the standard C library such as ``The C Programming Language ANSI C Edition" by Kernighan
78-and Ritchie.
79+\verb|errlogPrintf| and \verb|errlogVprintf| are like \verb|printf| and \verb|vprintf| provided by the standard C library, except that their output is sent to the errlog task; unless configured not to, the output will appear on the console as well.
80+Consult any book that describes the standard C library such as ``The C Programming Language ANSI C Edition" by Kernighan and Ritchie.
81
82 \verb|errlogMessage| sends message to the errlog task.
83
84@@ -101,14 +100,14 @@
85 \index{errlogGetSevEnumString}
86 \index{errlogSetSevToLog}
87 \index{errlogGetSevToLog}
88-\verb|errlogSevPrintf| and \verb|errlogSevVprintf| are like \verb|errlogPrintf| and \verb|errlogVprintf| except that they
89-add the severity to the beginning of the message in the form ``sevr=\textless{}value\textgreater{}" where value is one of ``info, minor, major,
90-fatal". Also the message is suppressed if severity is less than the current severity to suppress. If epicsThreadIsOkToBlock
91-is true, which is true during iocInit, errlogSevVprintf does NOT send output to the errlog task.
92-
93-\verb|errlogGetSevEnumString| gets the string value of severity.
94-
95- \verb|errlogSetSevToLog| sets the severity to log. \verb|errlogGetSevToLog| gets the current severity to log.
96+\verb|errlogSevPrintf| and \verb|errlogSevVprintf| are like \verb|errlogPrintf| and \verb|errlogVprintf| except that they add the severity to the beginning of the message in the form ``sevr=\textless{}value\textgreater{}" where value is one of ``info, minor, major, fatal".
97+Also the message is suppressed if severity is less than the current severity to suppress.
98+If \verb|epicsThreadIsOkToBlock| is true, which is true during iocInit, errlogSevVprintf does NOT send output to the errlog task.
99+
100+\verb|errlogGetSevEnumString| gets the string value of severity.
101+
102+\verb|errlogSetSevToLog| sets the severity to log.
103+\verb|errlogGetSevToLog| gets the current severity to log.
104
105 \subsection{Status Routines }
106
107@@ -131,25 +130,23 @@
108 Where status is defined as:
109
110 \begin{itemize}
111-\item 0: Find latest vxWorks or Unix error.
112-
113-\item -1: Don't report status.
114-
115-\item Other: See ``Return Status Values" above.
116+\item 0: Find latest vxWorks or Unix error.
117+
118+\item -1: Don't report status.
119+
120+\item Other: See ``Return Status Values" above.
121
122 \end{itemize}
123
124-\verb|errMessage|, via a call to \verb|errPrintf|, prints the message, the status symbol and string values, and the name of the task
125-which invoked \verb|errMessage|. It also prints the name of the source file and the line number from which the call was
126-issued.
127-
128-The calling routine is expected to pass a descriptive message to this routine. Many subsystems provide routines built on
129-top of \verb|errMessage| which generate descriptive messages.
130-
131-An IOC global variable \verb|errVerbose|, defined as an \verb|external| in \verb|errMdef.h|, specifies verbose messages. If
132-\verb|errVerbose| is \verb|TRUE| then \verb|errMessage| should be called whenever an error is detected even if it is known that the
133-error belongs to a specific client. If \verb|errVerbose| is \verb|FALSE| then \verb|errMessage| should be called only for errors that are
134-not caused by a specific client.
135+\verb|errMessage|, via a call to \verb|errPrintf|, prints the message, the status symbol and string values, and the name of the task which invoked \verb|errMessage|.
136+It also prints the name of the source file and the line number from which the call was issued.
137+
138+The calling routine is expected to pass a descriptive message to this routine.
139+Many subsystems provide routines built on top of \verb|errMessage| which generate descriptive messages.
140+
141+An IOC global variable \verb|errVerbose|, defined as an \verb|external| in \verb|errMdef.h|, specifies verbose messages.
142+If \verb|errVerbose| is \verb|TRUE| then \verb|errMessage| should be called whenever an error is detected even if it is known that the error belongs to a specific client.
143+If \verb|errVerbose| is \verb|FALSE| then \verb|errMessage| should be called only for errors that are not caused by a specific client.
144
145 Routine \verb|errPrintf| is normally called as follows:
146
147@@ -161,28 +158,28 @@
148 Where status is defined as:
149
150 \begin{itemize}
151-\item 0: Find latest vxWorks or Unix error.
152-
153-\item -1: Don't report status.
154-
155-\item Other: See ``Return Status Values", above.
156+\item 0: Find latest vxWorks or Unix error.
157+
158+\item -1: Don't report status.
159+
160+\item Other: See ``Return Status Values", above.
161
162 \end{itemize}
163
164 FILE and LINE are defined as:
165
166 \begin{itemize}
167-\item \_\_FILE\_\_ As shown or \verb|NULL| if the file name and line number should not be printed.
168+\item \_\_FILE\_\_ As shown or \verb|NULL| if the file name and line number should not be printed.
169
170 \item \_\_LINE\_\_ As shown
171
172 \end{itemize}
173
174-The remaining arguments are just like the arguments to the C \verb|printf| routine. \verb|errVerbose| determines if the filename
175-and line number are shown.
176+The remaining arguments are just like the arguments to the C \verb|printf| routine.
177+\verb|errVerbose| determines if the filename and line number are shown.
178
179-An EPICS status code can also be converted to a string. If the supplied status code isn't registered in the status code
180-database then the raw status code number is converted into a string in the destination buffer.
181+An EPICS status code can also be converted to a string.
182+If the supplied status code isn't registered in the status code database then the raw status code number is converted into a string in the destination buffer.
183
184 \begin{verbatim}
185 #include "errMdef.h"
186@@ -198,12 +195,14 @@
187
188 \index{epicsPrintf}
189 \index{epicsVprintf}
190-These are macros that call errlogPrintf and errlogVprintf. They are provided for compatibility.
191+These are macros that call errlogPrintf and errlogVprintf.
192+They are provided for compatibility.
193
194 \section{errlog Listeners}
195
196 \index{errlog Listeners}
197-Any code can receive errlog message. The following are the calls to add and remove a listener.
198+Any code can receive errlog message.
199+The following are the calls to add and remove a listener.
200
201 \begin{verbatim}
202 typedef void(*errlogListener) (void *pvt,const char *message);
203@@ -214,34 +213,39 @@
204 \index{errlogListener}
205 \index{errlogAddListener}
206 \index{errlogRemoveListener}
207-These routines add/remove a callback that receives each error message. These routines are the interface to the actual
208-system wide error handlers.
209+These routines add/remove a callback that receives each error message.
210+These routines are the interface to the actual system wide error handlers.
211
212 \section{errlogThread}
213
214 \index{errlogThread}
215-The error message routines can be called by any non-interrupt level code. These routines pass the message to the errlog
216-Thread. If any of the error message routines are called at interrupt level, \verb|epicsInterruptContextMessage| is
217-called with the message ``errlogPrintf called from interrupt level".
218-
219-errlogThread manages the messages. Messages are placed in a message queue, which is read by errlogThread. The
220-message queue uses a fixed block of memory to hold all messages. When the message queue is full additional messages
221-are rejected but a count of missed messages is kept. The next time the message queue empties an extra message about the
222-missed messages is generated.
223-
224-The maximum message size is by default 256 characters. If a message is longer, the message is truncated and a message
225-explaining that it was truncated is appended. There is a chance that long messages corrupt memory. This only happens if
226-client code is defective. Long messages most likely result from ``\%s" formats with a bad string argument.
227+The error message routines can be called by any non-interrupt level code.
228+These routines pass the message to the errlog Thread.
229+If any of the error message routines are called at interrupt level, \verb|epicsInterruptContextMessage| is called with the message ``errlogPrintf called from interrupt level".
230+
231+\verb|errlogThread| manages the messages.
232+Messages are placed in a message queue, which is read by errlogThread.
233+The message queue uses a fixed block of memory to hold all messages.
234+When the message queue is full additional messages are rejected but a count of missed messages is kept.
235+The next time the message queue empties an extra message about the missed messages is generated.
236+
237+The maximum message size is by default 256 characters.
238+If a message is longer, the message is truncated and a message explaining that it was truncated is appended.
239+There is a chance that long messages corrupt memory.
240+This only happens if client code is defective.
241+Long messages most likely result from ``\%s" formats with a bad string argument.
242
243 errlogThread passes each message to any registered listener.
244
245 \section{console output and message queue size}
246
247-The errlog system can also display messages on the ioc console. It calls \verb|epicsThreadIsOkToBlock| to decide when
248-to display the message. If it is OK to block, the message is displayed by the same thread that calls one of the errlog print
249-routines. If it is not OK to block, errlorThread displays the messages.
250+The errlog system can also display messages on the ioc console.
251+It calls \verb|epicsThreadIsOkToBlock| to decide when to display the message.
252+If it is OK to block, the message is displayed by the same thread that calls one of the errlog print routines.
253+If it is not OK to block, errlogThread displays the messages.
254
255-Normally the errlog system displays all messages on the console. \verb|eltc| can be used to suppress these messages.
256+Normally the errlog system displays all messages on the console.
257+\verb|eltc| can be used to suppress these messages.
258
259 \begin{verbatim}
260 int eltc(int yesno); /* error log to console (0 or 1) */
261@@ -252,11 +256,11 @@
262 \index{eltc}
263 \index{errlogInit}
264 \index{errlogInit2}
265-eltc determines if errlog task writes message to the console. During error messages storms this command can be used to
266-suppress console messages. A argument of 0 suppresses the messages and any other value lets the message go to the
267-console.
268+eltc determines if errlog task writes message to the console.
269+During error message storms this command can be used to suppress console messages.
270+A argument of 0 suppresses the messages, any other value lets messages go to the console.
271
272-errlogInit or errlogInit2 can be used to initialize the error logging system with a larger buffer and maximum message size.
273+\verb|errlogInit| or \verb|errlogInit2| can be used to initialize the error logging system with a larger buffer and maximum message size.
274 The default buffer size is 1280 bytes, and the default maximum message size is 256.
275
276 \section{Status Codes}
277@@ -265,34 +269,34 @@
278 EPICS defined status values provide the following features:
279
280 \begin{itemize}
281-\item Whenever possible, IOC routines return a status value: (0, non-0) means (\verb|OK|, \verb|ERROR|).
282+\item Whenever possible, IOC routines return a status value:
283+0 means OK, non-0 means an error.
284
285-\item The include files for each IOC subsystem contain macros defining error status symbols and strings.
286+\item The header files for most IOC subsystems contain macros defining error status symbols and strings.
287
288 \item Routines are provided for run time access of the error status symbols and strings.
289
290+\index{errVerbose}
291 \item A global variable \verb|errVerbose| helps code decide if error messages should be generated.
292
293 \end{itemize}
294
295-WARNING: During the fall of 1995 a series of tech-talk messages were generated concerning EPICS status values. No
296-consensus was reached.
297-
298-Whenever it makes sense, IOC routines return a status value encoded similar to the vxWorks error status encoding. The
299-most significant short word indicates the subsystem module within which the error occurred. The low order short word is
300-a subsystem status value. In order that status values do not conflict with the vxWorks error status values all subsystem
301-numbers are greater than 500.
302-
303-A file \verb|epics/share/epicsH/errMdef.h| defines each subsystem number. For example the \verb|define| for the
304-database access routines is:
305+IOC routines often return a long integer status value, encoded similar to the vxWorks error status encoding.
306+On some modern architectures a long integer is more than 32 bits wide, but in order to keep the API compatible the status values are still passed as long integers, even though only 32 bits are ever used.
307+The most significant 16 bits indicate the subsystem or module where the error occurred.
308+The least significant 16 bits contain a subsystem-specific status value.
309+In order that status values do not conflict with the vxWorks error status values, all subsystem numbers are greater than 500.
310+
311+\index{errMdef.h}
312+A header file \verb|errMdef.h| defines macros for all the subsystem numbers.
313+For example the database access routines use this module number:
314
315 \begin{verbatim}
316-#define M_dbAccess (501 << 16) \
317-/*Database Access Routines*/
318+#define M_dbAccess (501 << 16) /*Database Access Routines*/
319 \end{verbatim}
320
321-Directory ``\verb|epics/share/epicsH|" contains an \verb|include| library for every IOC subsystem that returns standard status
322-values. The status values are encoded with lines of the following format:
323+There are header files for every IOC subsystem that returns standard status values.
324+The status values are encoded with lines of the following format:
325
326 \begin{verbatim}
327 #define S_xxxxxxx value /*string value*/
328@@ -301,8 +305,7 @@
329 For example:
330
331 \begin{verbatim}
332-#define S_dbAccessBadDBR (M_dbAccess|3) \
333-/*Invalid Database Request*/
334+#define S_dbAccessBadDBR (M_dbAccess|3) /*Invalid Database Request*/
335 \end{verbatim}
336
337 For example, when \verb|dbGetField| detects a bad database request type, it executes the statement:
338@@ -314,53 +317,58 @@
339 The calling routine checks the return status as follows:
340
341 \begin{verbatim}
342-status = dbGetField( ...);
343+status = dbGetField(...);
344 if(status) {/* Call was not successful */ }
345 \end{verbatim}
346
347 \section{iocLog}
348
349 \index{iocLog}
350-NOTE: Many sites use CMLOG instead of iocLog. See the CMLOG documentation for details.
351+NOTE: Many sites use CMLOG instead of iocLog.
352+See the CMLOG documentation for details.
353
354-This consists of two modules: iocLogServer and iocLogClient. The client code runs on each ioc and listens for the
355-messages generated locally by the errlog system. It also reports the messages from the vxWorks logMsg facility.
356+This consists of two modules:
357+iocLogServer and iocLogClient.
358+The client code runs on each ioc and listens for the messages generated locally by the errlog system.
359+It also reports the messages from the vxWorks logMsg facility.
360
361 \subsection{iocLogServer}
362
363 \index{iocLogServer}
364+<<<<<<< TREE
365 This runs on a host. It receives messages for all enabled iocLogClients in the local area network. The messages are written
366 to a file. Epics base provides a startup file ``base/src/libCom/log/rc2.logServer", which is a SystemV init script to start the server.
367+=======
368+This runs on a host.
369+It receives messages for all enabled iocLogClients in the local area network.
370+The messages are written to a file.
371+Epics base provides a startup file ``base/src/util/rc2.logServer", which is a SystemV init script to start the server.
372+>>>>>>> MERGE-SOURCE
373 Consult this script for details.
374
375-To start a log server on a UNIX or PC workstation you must first set the following environment variables and then run the
376-executable ``iocLogServer" on your PC or UNIX workstation.
377+To start a log server on a UNIX or PC workstation you must first set the following environment variables and then run the executable ``iocLogServer" on your PC or UNIX workstation.
378
379 \begin{description}
380
381-\item \index{EPICS\_IOC\_LOG\_FILE\_NAME}EPICS\_IOC\_LOG\_FILE\_NAME
382+\item \index{EPICS\_IOC\_LOG\_FILE\_NAME}EPICS\_IOC\_LOG\_FILE\_NAME
383
384 The name and path to the log file.
385
386 \item \index{EPICS\_IOC\_LOG\_FILE\_LIMIT}EPICS\_IOC\_LOG\_FILE\_LIMIT
387
388-The maximum size in characters for the log file (after which it becomes a circular file and writes new
389-messages over old messages at the beginning of the file). If the value is zero then there is no limit on the
390-size of the log file.
391+The maximum size in characters for the log file (after which it becomes a circular file and writes new messages over old messages at the beginning of the file).
392+If the value is zero then there is no limit on the size of the log file.
393
394 \item \index{EPICS\_IOC\_LOG\_FILE\_COMMAND}EPICS\_IOC\_LOG\_FILE\_COMMAND
395
396-A shell command string used to obtain the log file path name during initialization and in response to
397-SIGHUP. The new path name will replace any path name supplied in EPICS\_IOC\_LOG\_FILE\_NAME.
398-
399-Thus, if EPICS\_IOC\_LOG\_FILE\_NAME is
400-
401-"a/b/c.log" and EPICS\_IOC\_LOG\_FILE\_COMMAND returns ``A/B" or ``A/B/" the log server will be stored
402-at ``A/B/c.log"
403-
404-If EPICS\_IOC\_LOG\_FILE\_COMMAND is empty then this behavior is disabled. This feature is used at
405-some sites for switching the server to a new directory at a fixed time each day. This variable is currently
406-used only by the UNIX version of the log server.
407+A shell command string used to obtain the log file path name during initialization and in response to SIGHUP.
408+The new path name will replace any path name supplied in EPICS\_IOC\_LOG\_FILE\_NAME.
409+
410+Thus, if EPICS\_IOC\_LOG\_FILE\_NAME is ``a/b/c.log" and EPICS\_IOC\_LOG\_FILE\_COMMAND returns ``A/B" or ``A/B/" the log server will be stored at ``A/B/c.log"
411+
412+If EPICS\_IOC\_LOG\_FILE\_COMMAND is empty then this behavior is disabled.
413+This feature is used at some sites for switching the server to a new directory at a fixed time each day.
414+This variable is currently used only by the UNIX version of the log server.
415
416 \item \index{EPICS\_IOC\_LOG\_PORT}EPICS\_IOC\_LOG\_PORT
417
418@@ -368,37 +376,37 @@
419
420 \end{description}
421
422-To configure an IOC so that its messages are placed in the log you must set the environment variable
423-EPICS\_IOC\_LOG\_INET to the IP address of the host that is running the log server, and EPICS\_IOC\_LOG\_PORT to the
424-TCP/IP port used by the log server.
425+To configure an IOC so that its messages are placed in the log you must set the environment variable EPICS\_IOC\_LOG\_INET to the IP address of the host that is running the log server, and EPICS\_IOC\_LOG\_PORT to the TCP/IP port used by the log server.
426
427-Defaults for all of the above parameters are specified in the files \$(EPICS\_BASE)/config/CONFIG\_SITE\_ENV and
428-\$(EPICS\_BASE)/config/CONFIG\_ENV.
429+Defaults for all of the above parameters are specified in the files \$(EPICS\_BASE)/config/CONFIG\_SITE\_ENV and \$(EPICS\_BASE)/config/CONFIG\_ENV.
430
431 \subsection{iocLogClient}
432 \label{iocLogClient}
433
434 \index{iocLogClient}
435-This runs on each ioc. It is started by calling:
436+This runs on each ioc.
437+It is started by calling:
438
439 \begin{verbatim}
440 iocLogInit();
441 \end{verbatim}
442
443-The global variable \verb|iocLogDisable| can be used to enable/disable the messages from being sent to the server. Setting
444-this variable to (0,1) (enables,disables) the messages generation. If \verb|iocLogDisable| is set to 1 before calling
445-\verb|iocLogInit| then \verb|iocLogClient| will not even initialize itself. \verb|iocLogDisable| can also be changed to turn
446-logging on or off.
447+The global variable \verb|iocLogDisable| can be used to enable/disable the messages from being sent to the server.
448+Setting this variable to (0,1) (enables, disables) the messages generation.
449+If \verb|iocLogDisable| is set to 1 before calling \verb|iocLogInit| then \verb|iocLogClient| will not even initialize itself.
450+\verb|iocLogDisable| can also be changed to turn logging on or off.
451
452 \verb|iocLogClient| calls \verb|errlogAddListener| and sends each message to the \verb|iocLogServer|.
453
454 \subsection{Configuring a Private Log Server}
455
456-In a testing environment it is desirable to use a private log server. This can be done as follows:
457+In a testing environment it is desirable to use a private log server.
458+This can be done as follows:
459
460 \begin{itemize}
461
462-\item Add a epicsEnvSet command to your IOC startup file. For example
463+\item Add a epicsEnvSet command to your IOC startup file.
464+For example
465
466 \begin{verbatim}
467 ld < iocCore
468
469=== modified file 'tex/libCom.tex'
470--- tex/libCom.tex 2010-11-15 18:16:16 +0000
471+++ tex/libCom.tex 2012-01-06 20:56:29 +0000
472@@ -1561,7 +1561,7 @@
473 program's main() routine.
474
475 On vxWorks and RTEMS, an alternative test harness can be used to run a series of tests in order and summarize the results
476-from them all at the end just like the Perl harness does. The routine testHarness() is called once a the beginning of the test
477+from them all at the end just like the Perl harness does. The routine testHarness() is called once at the beginning of the test
478 harness program. Each test program is run by passing its main routine name to the runTest() macro which expands into a
479 call to the runTestFunc() routine. The last test program or the harness program itself must finish by calling epicsExit()
480 which triggers the test summary mechanism to generate its result outputs (from an epicsAtExit callback routine).
481
482=== modified file 'tex/recordSupport.tex'
483--- tex/recordSupport.tex 2010-11-15 18:16:16 +0000
484+++ tex/recordSupport.tex 2012-01-06 20:56:29 +0000
485@@ -3,35 +3,37 @@
486
487 \section{Overview}
488
489-The purpose of this chapter is to describe record support in sufficient detail such that a C programmer can write new
490-record support modules. Before attempting to write new support modules, you should carefully study a few of the existing
491-support modules. If an existing support module is similar to the desired module most of the work will already be done.
492-
493-From previous chapters, it should be clear that many things happen as a result of record processing. The details of what
494-happens are dependent on the record type. In order to allow new record types and new device types without impacting the
495-core IOC system, the concept of record support and device support has been created. For each record type, a record
496-support module exists. It is responsible for all record specific details. In order to allow a record support module to be
497-independent of device specific details, the concept of device support has been created.
498-
499-A record support module consists of a standard set of routines which are called by database access routines. These
500-routines implement record specific code. Each record type can define a standard set of device support routines specific to
501-that record type.
502-
503-By far the most important record support routine is \verb|process|, which \verb|dbProcess| calls when it wants to process a record.
504-This routine is responsible for the details of record processing. In many cases it calls a device support I/O routine. The
505-next section gives an overview of what must be done in order to process a record. Next is a description of the entry tables
506-that must be provided by record and device support modules. The remaining sections give example record and device
507-support modules and describe some global routines useful to record support modules.
508-
509-The record and device support modules are the only modules that are allowed to include the record specific include files
510-as defined in \verb|base/rec|. Thus they are the only routines that access record specific fields without going through database
511-access.
512+The purpose of this chapter is to describe record support in sufficient detail such that a C programmer can write new record support modules.
513+Before attempting to write new support modules, you should carefully study a few of the existing support modules.
514+If an existing support module is similar to the desired module most of the work will already be done.
515+
516+From previous chapters, it should be clear that many things happen as a result of record processing.
517+The details of what happens are dependent on the record type.
518+In order to allow new record types and new device types without impacting the core IOC system, the concept of record support and device support is used.
519+For each record type, a record support module exists.
520+It is responsible for all record specific details.
521+In order to allow a record support module to be independent of device specific details, the concept of device support has been created.
522+
523+A record support module consists of a standard set of routines which are called by database access routines.
524+These routines implement record specific code.
525+Each record type can define a standard set of device support routines specific to that record type.
526+
527+By far the most important record support routine is \verb|process|, which \verb|dbProcess| calls when it wants to process a record.
528+This routine is responsible for the details of record processing.
529+In many cases it calls a device support I/O routine.
530+The next section gives an overview of what must be done in order to process a record.
531+Next is a description of the entry tables that must be provided by record and device support modules.
532+The remaining sections give example record and device support modules and describe some global routines useful to record support modules.
533+
534+The record and its device support modules are the only source files that should include the record specific header files.
535+Thus they will be the only routines that access record specific fields without going through database access.
536
537 \section{Overview of Record Processing}
538
539 \index{Overview of Record Processing}
540-The most important record support routine is \verb|process|. This routine determines what record processing means. Before
541-the record specific ``\verb|process|" routine is called, the following has already been done:
542+The most important record support routine is \verb|process|.
543+This routine determines what record processing means.
544+Before the record specific ``\verb|process|" routine is called, the following has already been done:
545
546 \begin{itemize}
547 \item Decision to process a record.
548@@ -57,11 +59,12 @@
549
550 \end{itemize}
551
552-A complication of record processing is that some devices are intrinsically asynchronous. It is NEVER permissible to wait
553-for a slow device to complete. Asynchronous records perform the following steps:
554+A complication of record processing is that some devices are intrinsically asynchronous.
555+It is NEVER permissible to wait for a slow device to complete.
556+Asynchronous records perform the following steps:
557
558 \begin{enumerate}
559-\item Initiate the I/O operation and set \verb|pact| \verb|TRUE|
560+\item Initiate the I/O operation and set \verb|pact = TRUE|
561
562 \item Determine a method for again calling process when the operation completes
563
564@@ -69,7 +72,7 @@
565
566 \item When process is called after the I/O operation complete record processing
567
568-\item Set \verb|pact| \verb|FALSE| and return
569+\item Set \verb|pact = FALSE| and return
570
571 \end{enumerate}
572
573@@ -77,35 +80,36 @@
574
575 \section{Record Support and Device Support Entry Tables}
576
577-Each record type has an associated set of record support routines. These routines are located via the data structures
578-defined in \verb|epics/share/epicsH/recSup.h|. The concept of record support routines isolates the \verb|iocCore| software
579-from the details of each record type. Thus new records can be defined and supported without affecting the IOC core
580-software.
581-
582-Each record type also has zero or more sets of device support routines. Record types without associated hardware, e.g.
583-calculation records, normally do not have any associated device support. Record types with associated hardware normally
584-have a device support module for each device type. The concept of device support isolates IOC core software and even
585-record support from device specific details.
586-
587-Corresponding to each record type is a set of record support routines. The set of routines is the same for every record type.
588-These routines are located via a Record Support Entry Table (\index{RSET}\index{Record Support Entry Table}RSET), which has the following structure
589+Each record type has an associated set of record support routines.
590+These routines are located via the \verb|struct rset| data structure declared in \verb|recSup.h| and defined by the specific record type.
591+This use of a record support vector table isolates the \verb|iocCore| software from the implementation details of each record type.
592+Thus new record types can be defined without having to modify the IOC core software.
593+
594+Each record type also has zero or more sets of device support routines.
595+Record types without associated hardware, e.g. calculation records, normally do not have any associated device support.
596+Record types with associated hardware normally have a device support module for each device type.
597+The concept of device support isolates IOC core software and even record support from device specific details.
598+
599+Corresponding to each record type is a set of record support routines.
600+The set of routines is the same for every record type.
601+These routines are located via a Record Support Entry Table (\index{RSET}\index{Record Support Entry Table}RSET), which has the following structure:
602
603 \begin{verbatim}
604-rset { /* record support entry table */
605- long number; /* number of support routine */
606- RECSUPFUN report; /* print report */
607- RECSUPFUN init; /* init support */
608- RECSUPFUN init_record; /* init record */
609- RECSUPFUN process; /* process record */
610- RECSUPFUN special; /* special processing */
611- RECSUPFUN get_value; /* OBSOLETE: Just leave NULL */
612- RECSUPFUN cvt_dbaddr; /* cvt dbAddr */
613+struct rset { /* record support entry table */
614+ long number; /* number of support routine */
615+ RECSUPFUN report; /* print report */
616+ RECSUPFUN init; /* init support */
617+ RECSUPFUN init_record; /* init record */
618+ RECSUPFUN process; /* process record */
619+ RECSUPFUN special; /* special processing */
620+ RECSUPFUN get_value; /* OBSOLETE: Just leave NULL */
621+ RECSUPFUN cvt_dbaddr; /* cvt dbAddr */
622 RECSUPFUN get_array_info;
623 RECSUPFUN put_array_info;
624 RECSUPFUN get_units;
625 RECSUPFUN get_precision;
626 RECSUPFUN get_enum_str; /* get string from enum */
627- RECSUPFUN get_enum_strs; /* get all enum strings */
628+ RECSUPFUN get_enum_strs; /* get all enum strings */
629 RECSUPFUN put_enum_str; /* put enum from string */
630 RECSUPFUN get_graphic_double;
631 RECSUPFUN get_control_double;
632@@ -119,35 +123,36 @@
633 <record_type>RSET
634 \end{verbatim}
635
636-Any routines not needed for the particular record type should be initialized to the value \verb|NULL|. Look at the example below
637-for details.
638+Any routines not needed for the particular record type should be initialized to the value \verb|NULL|.
639+Look at the example below for details.
640
641 Device support routines are located via a Device Support Entry Table (\index{DSET}\index{Device Support Entry Table}DSET), which has the following structure:
642
643 \begin{verbatim}
644 struct dset { /* device support entry table */
645- long number; /* number of support routines */
646- DEVSUPFUN report; /* print report */
647- DEVSUPFUN init; /* init support */
648+ long number; /* number of support routines */
649+ DEVSUPFUN report; /* print report */
650+ DEVSUPFUN init; /* init support */
651 DEVSUPFUN init_record;/* init record instance*/
652 DEVSUPFUN get_ioint_info; /* get io interrupt info*/
653 /* other functions are record dependent*/
654 };
655 \end{verbatim}
656
657-Each device support module must define its associated DSET. The external name must be the same as the name which
658-appears in \verb|devSup.ascii|.
659+Each device support module must define its associated DSET.
660+The external name must be the same as the name which appears in \verb|devSup.ascii|.
661
662-Any record support module which has associated device support must also include definitions for accessing its associated
663-device support modules. The field"\verb|dset|", which is located in \verb|dbCommon|, contains the address of the DSET. It is given a
664-value by \verb|iocInit|.
665+Any record support module which has associated device support must also include definitions for accessing its associated device support modules.
666+The field \verb|dset|, which is declared in \verb|dbCommon|, contains the address of the DSET.
667+It is given a value by \verb|iocInit|.
668
669 \section{Example Record Support Module}
670
671-This section contains the skeleton of a record support package. The record type is \verb|xxx| and the record has the following
672-fields in addition to the \verb|dbCommon| fields: \verb|VAL|, \verb|PREC|, \verb|EGU|, \verb|HOPR|, \verb|LOPR|, \verb|HIHI|, \verb|LOLO|, \verb|HIGH|, \verb|LOW|, \verb|HHSV|, \verb|LLSV|, \verb|HSV|,
673-\verb|LSV|, \verb|HYST|, \verb|ADEL|, \verb|MDEL|, \verb|LALM|, \verb|ALST|, \verb|MLST|. These fields will have the same meaning as they have for the \verb|ai| record.
674-Consult the Record Reference manual for a description.
675+This section contains the skeleton of a record support package.
676+The record type is \verb|xxx| and the record has the following fields in addition to the \verb|dbCommon| fields:
677+\verb|VAL|, \verb|PREC|, \verb|EGU|, \verb|HOPR|, \verb|LOPR|, \verb|HIHI|, \verb|LOLO|, \verb|HIGH|, \verb|LOW|, \verb|HHSV|, \verb|LLSV|, \verb|HSV|, \verb|LSV|, \verb|HYST|, \verb|ADEL|, \verb|MDEL|, \verb|LALM|, \verb|ALST|, \verb|MLST|.
678+These fields will have the same meaning as they have for the \verb|ai| record.
679+Consult the Record Reference manual for a description.
680
681 \subsection{Declarations}
682
683@@ -208,14 +213,12 @@
684 static void monitor(xxxRecord *pxxx);
685 \end{verbatim}
686
687-\index{RSET - example}The above declarations define the Record Support Entry Table (RSET), a template for the associated Device Support
688-Entry Table (DSET), and forward declarations to private routines.
689-
690-The RSET must be declared with an external name of \verb|xxxRSET|. It defines the record support routines supplied for this
691-record type. Note that forward declarations are given for all routines supported and a \verb|NULL| declaration for any routine not
692-supported.
693-
694-The template for the DSET is declared for use by this module.
695+\index{RSET - example}The above declarations define the Record Support Entry Table (RSET), a template for the associated Device Support Entry Table (DSET), and forward declarations to private routines.
696+
697+The RSET must be declared with an external name of \verb|xxxRSET|. It defines the record support routines supplied for this record type.
698+Note that forward declarations are given for all routines supported and a \verb|NULL| declaration for any routine not supported.
699+
700+The template for the DSET is declared for use by this module.
701
702 \subsection{init\_record}
703
704@@ -246,16 +249,16 @@
705 }
706 \end{verbatim}
707
708-This routine, which is called by \verb|iocInit| twice for each record of type \verb|xxx|, checks to see if it has a proper set of device
709-support routines and, if present, calls the \verb|init_record| entry of the DSET.
710+This routine, which is called by \verb|iocInit| twice for each record of type \verb|xxx|, checks to see if it has a proper set of device support routines and, if present, calls the \verb|init_record| entry of the DSET.
711
712-During the first call to \verb|init_record| (pass=0) only initializations relating to this record can be performed. During the
713-second call (pass=1) initializations that may refer to other records can be performed. Note also that during the second
714-pass, other records may refer to fields within this record. A good example of where these rules are important is a
715-waveform record. The \verb|VAL| field of a waveform record actually refers to an array. The waveform record support module
716-must allocate storage for the array. If another record has a database link referring to the waveform \verb|VAL| field then the
717-storage must be allocated before the link is resolved. This is accomplished by having the waveform record support
718-allocate the array during the first pass (pass=0) and having the link reference resolved during the second pass (pass=1).
719+During the first call to \verb|init_record| (pass=0) only initializations relating to this record can be performed.
720+During the second call (pass=1) initializations that may refer to other records can be performed.
721+Note also that during the second pass, other records may refer to fields within this record.
722+A good example of where these rules are important is a waveform record.
723+The \verb|VAL| field of a waveform record actually refers to an array.
724+The waveform record support module must allocate storage for the array.
725+If another record has a database link referring to the waveform \verb|VAL| field then the storage must be allocated before the link is resolved.
726+This is accomplished by having the waveform record support allocate the array during the first pass (pass=0) and having the link reference resolved during the second pass (pass=1).
727
728 \subsection{process}
729
730@@ -294,18 +297,20 @@
731 }
732 \end{verbatim}
733
734-The record processing routines are the heart of the IOC software. The record specific process routine is called by
735-\verb|dbProcess| whenever it decides that a record should be processed. Process decides what record processing really means.
736-The above is a good example of what should be done. In addition to being called by \verb|dbProcess| the process routine may
737-also be called by asynchronous record completion routines.
738+The record processing routines are the heart of the IOC software.
739+The record specific process routine is called by \verb|dbProcess| whenever it decides that a record should be processed.
740+Process decides what record processing really means.
741+The above is a good example of what should be done.
742+In addition to being called by \verb|dbProcess| the process routine may also be called by asynchronous record completion routines.
743
744-The above model supports both synchronous and asynchronous device support routines. For example, if \verb|read_xxx| is an
745-asynchronous routine, the following sequence of events will occur:
746+The above model supports both synchronous and asynchronous device support routines.
747+For example, if \verb|read_xxx| is an asynchronous routine, the following sequence of events will occur:
748
749 \begin{itemize}
750 \item \verb|process| is called with \verb|pact| \verb|FALSE|
751
752-\item \verb|read_xxx| is called. Since \verb|pact| is \verb|FALSE| it starts I/O, arranges callback, and sets \verb|pact| \verb|TRUE|
753+\item \verb|read_xxx| is called.
754+Since \verb|pact| is \verb|FALSE| it starts I/O, arranges callback, and sets \verb|pact| \verb|TRUE|
755
756 \item \verb|read_xxx| returns
757
758@@ -315,7 +320,8 @@
759
760 \item Sometime later the callback occurs and \verb|process| is called again.
761
762-\item \verb|read_xxx| is called. Since \verb|pact| is \verb|TRUE| it knows that it is a completion request.
763+\item \verb|read_xxx| is called.
764+Since \verb|pact| is \verb|TRUE| it knows that it is a completion request.
765
766 \item \verb|read_xxx| returns
767
768@@ -327,8 +333,8 @@
769
770 \end{itemize}
771
772-At this point the record has been completely processed. The next time \verb|process| is called everything starts all over from
773-the beginning.
774+At this point the record has been completely processed.
775+The next time \verb|process| is called everything starts all over from the beginning.
776
777 \subsection{Miscellaneous Utility Routines}
778
779@@ -359,8 +365,8 @@
780
781 \index{get\_units - .example}
782 \index{get\_graphic\_double - example}
783-These are a few examples of various routines supplied by a typical record support package. The functions that must be
784-performed by the remaining routines are described in the next section.
785+These are a few examples of various routines supplied by a typical record support package.
786+The functions that must be performed by the remaining routines are described in the next section.
787
788 \subsection{Alarm Processing}
789
790@@ -416,13 +422,14 @@
791 }
792 \end{verbatim}
793
794-\index{checkAlarms}This is a typical set of code for checking alarms conditions for an analog type record. The actual set of code can be very
795-record specific. Note also that other parts of the system can raise alarms. The algorithm is to always maximize alarm
796-severity, i.e. the highest severity outstanding alarm will be reported.
797+\index{checkAlarms}This is a typical set of code for checking alarms conditions for an analog type record.
798+The actual set of code can be very record specific.
799+Note also that other parts of the system can raise alarms.
800+The algorithm is to always maximize alarm severity, i.e. the highest severity outstanding alarm will be reported.
801
802-The above algorithm also honors a hysteresis factor for the alarm. This is to prevent alarm storms from occurring in the
803-event that the current value is very near an alarm limit and noise makes it continually cross the limit. It honors the
804-hysteresis only when the value is going to a lower alarm severity.
805+The above algorithm also honors a hysteresis factor for the alarm.
806+This is to prevent alarm storms from occurring in the event that the current value is very near an alarm limit and noise makes it continually cross the limit.
807+It honors the hysteresis only when the value is going to a lower alarm severity.
808
809 Note the test:
810
811@@ -433,30 +440,32 @@
812 }
813 \end{verbatim}
814
815-\index{udf}Database common defines the field \index{UDF}UDF, which means that field VAL is undefined. The STAT and SEVR fields are
816-initialized as though \verb|recGblSetSevr(pxxx,UDF_ALARM,VALID_ALARM)|was called. Thus if the record is never
817-processed the record will be in an INVALID UNDEFINED alarm state. Field UDF is initialized to the value 1, i.e. TRUE.
818-Thus the above code will keep the record in the INVALID UNDEFINED alarm state as long as UDF is not given the
819-value 0.
820-
821-The UDF field means Undefined, i.e. the VAL field has never been given a value. When records are loaded into an ioc this
822-is the initial state of records. Whevever code gives a value to the VAL field it is also supposed to set UDF false. Unless a
823-particular record type has unusual semantics no code should set UDF true. UDF normally means that the field was never
824-given a value.
825-
826-For input records device support is responsible for obtaining an input value. If no input value can be obtained neither
827-record support nor device support sets UDF false. If device support reads a raw value it returns a value telling record
828-support to perform a conversion. After the record support sets VAL equal to the converted value, it sets UDF false. If
829-device support obtains a converted value that it writes to VAL, it sets UDF false.
830-
831-For output records either something outside record/device support writes to the VAL field or else VAL is given a value
832-because record support obtains a value via the OMSL field. In either case the code that writes to the VAL field sets UDF
833-false.
834+\index{udf}Database common defines the field \index{UDF}UDF, which means that field VAL is undefined.
835+The STAT and SEVR fields are initialized as though \verb|recGblSetSevr(pxxx,UDF_ALARM,VALID_ALARM)|was called.
836+Thus if the record is never processed the record will be in an INVALID UNDEFINED alarm state.
837+Field UDF is initialized to the value 1, i.e. TRUE.
838+Thus the above code will keep the record in the INVALID UNDEFINED alarm state as long as UDF is not given the value 0.
839+
840+The UDF field means Undefined, i.e. the VAL field has never been given a value.
841+When records are loaded into an ioc this is the initial state of records.
842+Whevever code gives a value to the VAL field it is also supposed to set UDF false.
843+Unless a particular record type has unusual semantics no code should set UDF true.
844+UDF normally means that the field was never given a value.
845+
846+For input records device support is responsible for obtaining an input value.
847+If no input value can be obtained neither record support nor device support sets UDF false.
848+If device support reads a raw value it returns a value telling record support to perform a conversion.
849+After the record support sets VAL equal to the converted value, it sets UDF false.
850+If device support obtains a converted value that it writes to VAL, it sets UDF false.
851+
852+For output records either something outside record/device support writes to the VAL field or else VAL is given a value because record support obtains a value via the OMSL field.
853+In either case the code that writes to the VAL field sets UDF false.
854
855 Whenever database access writes to the VAL field it sets UDF false.
856
857-Routine recGblSetSevr is called to raise alarms. It can be called by iocCore, record support, or device support. The code
858-that detects an alarm is responsible for raising the alarm.
859+Routine recGblSetSevr is called to raise alarms.
860+It can be called by iocCore, record support, or device support.
861+The code that detects an alarm is responsible for raising the alarm.
862
863 \subsection{Raising Monitors}
864
865@@ -493,14 +502,16 @@
866 }
867 \end{verbatim}
868
869-\index{monitor - example}All record types should call \verb|recGblResetAlarms| as shown. Note that \verb|nsta| and \verb|nsev| will have the value 0 after this
870-routine completes. This is necessary to ensure that alarm checking starts fresh after processing completes. The code also
871-takes care of raising alarm monitors when a record changes from an alarm state to the no alarm state. It is essential that
872-record support routines follow the above model or else alarm processing will not follow the rules.
873+\index{monitor - example}All record types should call \verb|recGblResetAlarms| as shown.
874+Note that \verb|nsta| and \verb|nsev| will have the value 0 after this routine completes.
875+This is necessary to ensure that alarm checking starts fresh after processing completes.
876+The code also takes care of raising alarm monitors when a record changes from an alarm state to the no alarm state.
877+It is essential that record support routines follow the above model or else alarm processing will not follow the rules.
878
879 Analog type records should also provide monitor and archive hysteresis fields as shown by this example.
880
881-\verb|db_post_events| results in channel access issuing monitors for clients attached to the record and field. The call is
882+\verb|db_post_events| results in channel access issuing monitors for clients attached to the record and field.
883+The call is
884
885 \begin{verbatim}
886 int db_post_events(void *precord, void *pfield,
887@@ -517,7 +528,8 @@
888
889 \begin{description}
890
891-\item \index{DBE\_ALARM}DBE\_ALARM - A change of alarm state has occured. This is set by \verb|recGblResetAlarms|.
892+\item \index{DBE\_ALARM}DBE\_ALARM - A change of alarm state has occured.
893+This is set by \verb|recGblResetAlarms|.
894
895 \item \index{DBE\_LOG}DBE\_LOG - Archive change of state.
896
897@@ -526,13 +538,14 @@
898 \end{description}
899
900 \end{description}
901-IMPORTANT: The record support module is responsible for calling \verb|db_post_event| for any fields that change as a
902-result of record processing. Also it should NOT call \verb|db_post_event| for fields that do not change.
903+IMPORTANT:
904+The record support module is responsible for calling \verb|db_post_event| for any fields that change as a result of record processing.
905+Also it should NOT call \verb|db_post_event| for fields that do not change.
906
907 \section{Record Support Routines}
908
909-This section describes the routines defined in the RSET. Any routine that does not apply to a specific record type must be
910-declared \verb|NULL|.
911+This section describes the routines defined in the RSET.
912+Any routine that does not apply to a specific record type must be declared \verb|NULL|.
913
914 \subsection{Generate Report of Each Field in Record}
915
916@@ -540,7 +553,8 @@
917 report(void *precord); /* addr of record*/
918 \end{verbatim}
919
920-\index{report - Record Support Routine}This routine is not used by most record types. Any action is record type specific.
921+\index{report - Record Support Routine}This routine is not used by most record types.
922+Any action is record type specific.
923
924 \subsection{Initialize Record Processing}
925
926@@ -548,8 +562,9 @@
927 initialize(void);
928 \end{verbatim}
929
930-\index{init - Record Support Routine}This routine is called once at IOC initialization time. Any action is record type specific. Most record types do not need
931-this routine.
932+\index{init - Record Support Routine}This routine is called once at IOC initialization time.
933+Any action is record type specific.
934+Most record types do not need this routine.
935
936 \subsection{Initialize Specific Record}
937
938@@ -559,15 +574,15 @@
939 int pass);
940 \end{verbatim}
941
942-\index{init\_record - record support routine}\verb|iocInit| calls this routine twice (pass=0 and pass=1) for each database record of the type handled by this routine. It must
943-perform the following functions:
944+\index{init\_record - record support routine}\verb|iocInit| calls this routine twice (pass=0 and pass=1) for each database record of the type handled by this routine.
945+It must perform the following functions:
946
947 \begin{itemize}
948 \item Check and/or issue initialization calls for the associated device support routines.
949
950 \item Perform any record type specific initialization.
951
952-\item During the first pass it can only perform initializations that affect the record referenced by precord.
953+\item During the first pass it can only perform initializations that affect the record referenced by precord.
954
955 \item During the second pass it can perform initializations that affect other records.
956
957@@ -589,16 +604,20 @@
958 int after);/*(FALSE,TRUE)=>(Before,After)Processing*/
959 \end{verbatim}
960
961-\index{special - Record Support Routine}This routine implements the record type specific special processing for the field referred to by \verb|dbAddr|. Note that it is
962-called twice. Once before any changes are made to the associated field and once after. File \verb|special.h| defines special
963-types. This routine is only called for user special fields, i.e. fields with \verb|SPC_xxx| \textgreater{}= 100. A field is declared special in the
964-ASCII record definition file. New values should not by added to \verb|special.h|, instead use \verb|SPC_MOD|.
965+\index{special - Record Support Routine}This routine implements the record type specific special processing for the field referred to by \verb|dbAddr|.
966+Note that it is called twice.
967+Once before any changes are made to the associated field and once after.
968+File \verb|special.h| defines special types.
969+This routine is only called for user special fields, i.e. fields with \verb|SPC_xxx| \textgreater{}= 100.
970+A field is declared special in the ASCII record definition file.
971+New values should not by added to \verb|special.h|, instead use \verb|SPC_MOD|.
972
973 The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
974
975 \subsection{Get Value}
976
977-This routine is no longer used. It should be left as a NULL procedure in the record support entry table.
978+This routine is no longer used.
979+It should be left as a NULL procedure in the record support entry table.
980
981 \subsection{Convert dbAddr Definitions}
982
983@@ -606,18 +625,20 @@
984 cvt_dbaddr(struct dbAddr *paddr);
985 \end{verbatim}
986
987-\index{cvt\_dbaddr - Record Support Routine}This routine is called by \verb|dbNameToAddr| if the field has special set equal to \verb|SPC_DBADDR|. A typical use is when a field
988-refers to an array. This routine can change any combination of the \verb|dbAddr| fields: \verb|no_elements|, \verb|field_type|,
989-\verb|field_size|, \verb|special,pfield, |and\verb| dbr_type|. For example if the \verb|VAL| field of a waveform record is passed to
990-\verb|dbNameToAddr|, \verb|cvt_dbaddr| would change \verb|dbAddr| so that it refers to the actual array rather then \verb|VAL|.
991+\index{cvt\_dbaddr - Record Support Routine}This routine is called by \verb|dbNameToAddr| if the field has special set equal to \verb|SPC_DBADDR|.
992+A typical use is when a field refers to an array.
993+This routine can change any combination of the \verb|dbAddr| fields:
994+\verb|no_elements|, \verb|field_type|, \verb|field_size|, \verb|special,pfield, |and\verb| dbr_type|.
995+For example if the \verb|VAL| field of a waveform record is passed to \verb|dbNameToAddr|, \verb|cvt_dbaddr| would change \verb|dbAddr| so that it refers to the actual array rather then \verb|VAL|.
996
997 The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
998
999 NOTES:
1000
1001 \begin{itemize}
1002-\item Channel access calls db\_name\_to\_addr, which is part of old database access. Db\_name\_to\_addr calls
1003-dbNameToAddr. This is done when a client connects to the record.
1004+\item Channel access calls \verb|db_name_to_addr|, which is part of old database access.
1005+\verb|db_name_to_addr| calls \verb|dbNameToAddr|.
1006+This is done when a client connects to the record.
1007
1008 \item no\_elements must be set to the maximum number of elements that will ever be stored in the array.
1009
1010@@ -632,11 +653,12 @@
1011 long *offset);
1012 \end{verbatim}
1013
1014-\index{get\_array\_info - Record Support Routine}This routine returns the current number of elements and the offset of the first value of the specified array. The offset field
1015-is meaningful if the array is actually a circular buffer.
1016+\index{get\_array\_info - Record Support Routine}This routine returns the current number of elements and the offset of the first value of the specified array.
1017+The offset field is meaningful if the array is actually a circular buffer.
1018
1019-The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified. It is
1020-permissible for \verb|get_array_info| to change \verb|pfield|. This feature can be used to implement double buffering.
1021+The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
1022+It is permissible for \verb|get_array_info| to change \verb|pfield|.
1023+This feature can be used to implement double buffering.
1024
1025 \index{get\_array\_info - Record Support Routine}
1026 When an array field is being written \verb|get_array_info| is called before the field values are changed.
1027@@ -673,8 +695,9 @@
1028 long *precision);
1029 \end{verbatim}
1030
1031-\index{get\_precision - Record Support Routine}This routine gets the precision, i.e. number of decimal places, which should be used to convert the field value to an ASCII
1032-string. \verb|recGblGetPrec| should be called for fields not directly related to the value field.
1033+\index{get\_precision - Record Support Routine}This routine gets the precision, i.e.
1034+number of decimal places, which should be used to convert the field value to an ASCII string.
1035+\verb|recGblGetPrec| should be called for fields not directly related to the value field.
1036
1037 The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
1038
1039@@ -686,7 +709,8 @@
1040 char *p);
1041 \end{verbatim}
1042
1043-\index{get\_enum\_str - record Support Routine}This routine sets \verb|*p| equal to the ASCII string for the field value. The field must have type \verb|DBF_ENUM|.
1044+\index{get\_enum\_str - record Support Routine}This routine sets \verb|*p| equal to the ASCII string for the field value.
1045+The field must have type \verb|DBF_ENUM|.
1046
1047 Look at the code for the \verb|bi| or \verb|mbbi| records for examples.
1048
1049@@ -714,8 +738,8 @@
1050 char *p);
1051 \end{verbatim}
1052
1053-\index{put\_enum\_str - Record Support Routine}Given an ASCII string, this routine updates the database field. It compares the string with the string values associated with
1054-each enumerated value and if it finds a match sets the database field equal to the index of the string which matched.
1055+\index{put\_enum\_str - Record Support Routine}Given an ASCII string, this routine updates the database field.
1056+It compares the string with the string values associated with each enumerated value and if it finds a match sets the database field equal to the index of the string which matched.
1057
1058 Look at the code for the \verb|bi| or \verb|mbbi| records for examples.
1059
1060@@ -729,8 +753,8 @@
1061 struct dbr_grDouble *p); /* addr of return info*/
1062 \end{verbatim}
1063
1064-\index{get\_graphic\_double - Record Support Routine}This routine fills in the graphics related fields of structure \verb|dbr_grDouble|. \verb|recGblGetGraphicDouble| should be
1065-called for fields not directly related to the value field.
1066+\index{get\_graphic\_double - Record Support Routine}This routine fills in the graphics related fields of structure \verb|dbr_grDouble|.
1067+\verb|recGblGetGraphicDouble| should be called for fields not directly related to the value field.
1068
1069 The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
1070
1071@@ -742,8 +766,8 @@
1072 struct dbr_ctrlDouble *p); /* addr of return info*/
1073 \end{verbatim}
1074
1075-\index{get\_control\_double - Record Support Routine}This routine gives values to all fields of structure \verb|dbr_ctrlDouble|. \verb|recGblGetControlDouble| should be called
1076-for fields not directly related to the value field.
1077+\index{get\_control\_double - Record Support Routine}This routine gives values to all fields of structure \verb|dbr_ctrlDouble|.
1078+\verb|recGblGetControlDouble| should be called for fields not directly related to the value field.
1079
1080 The database access routine, \verb|dbGetFieldIndex| can be used to determine which field is being modified.
1081
1082@@ -762,26 +786,30 @@
1083 \section{Global Record Support Routines}
1084
1085 \index{Global Record Support Routines}
1086-A number of global record support routines are available. These routines are intended for use by the record specific
1087-processing routines but can be called by any routine that wishes to use their services.
1088+A number of global record support routines are available.
1089+These routines are intended for use by the record specific processing routines but can be called by any routine that wishes to use their services.
1090
1091 The name of each of these routines begins with ``\verb|recGbl|".
1092
1093 \subsection{Alarm Status and Severity}
1094
1095-Alarms may be raised in many different places during the course of record processing. The algorithm is to maximize the
1096-alarm severity, i.e. the highest severity outstanding alarm is raised. If more than one alarm of the same severity is found
1097-then the first one is reported. This means that whenever a code fragment wants to raise an alarm, it does so only if the
1098-alarm severity it will declare is greater then that already existing. Four fields (in database common) are used to implement
1099-alarms: \verb|sevr|, \verb|stat|, \verb|nsev|, and \verb|nsta|. The first two are the status and severity after the record is completely processed.
1100-The last two fields (\verb|nsta| and \verb|nsev|) are the status and severity values to set during record processing. Two routines are
1101-used for handling alarms. Whenever a routine wants to raise an alarm it calls \verb|recGblSetSevr|. This routine will only
1102-change \verb|nsta| and \verb|nsev| if it will result in the alarm severity being increased. At the end of processing, the record support
1103-module must call \verb|recGblResetAlarms|. This routine sets \verb|stat = nsta|, \verb|sevr = nsev|, \verb|nsta= 0|, and \verb|nsev = 0|. If \verb|stat|
1104-or \verb|sevr| has changed value since the last call it calls \verb|db_post_event| for \verb|stat| and \verb|sevr| and returns a value of
1105-\verb|DBE_ALARM|. If no change occured it returns 0. Thus after calling \verb|recGblResetAlarms| everything is ready for raising
1106-alarms the next time the record is processed. The example record support module presented above shows how these
1107-macros are used.
1108+Alarms may be raised in many different places during the course of record processing.
1109+The algorithm is to maximize the alarm severity, i.e. the highest severity outstanding alarm is raised.
1110+If more than one alarm of the same severity is found then the first one is reported.
1111+This means that whenever a code fragment wants to raise an alarm, it does so only if the alarm severity it will declare is greater then that already existing.
1112+Four fields (in database common) are used to implement alarms:
1113+\verb|sevr|, \verb|stat|, \verb|nsev|, and \verb|nsta|.
1114+The first two are the status and severity after the record is completely processed.
1115+The last two fields (\verb|nsta| and \verb|nsev|) are the status and severity values to set during record processing.
1116+Two routines are used for handling alarms.
1117+Whenever a routine wants to raise an alarm it calls \verb|recGblSetSevr|.
1118+This routine will only change \verb|nsta| and \verb|nsev| if it will result in the alarm severity being increased.
1119+At the end of processing, the record support module must call \verb|recGblResetAlarms|.
1120+This routine sets \verb|stat = nsta|, \verb|sevr = nsev|, \verb|nsta= 0|, and \verb|nsev = 0|.
1121+If \verb|stat| or \verb|sevr| has changed value since the last call it calls \verb|db_post_event| for \verb|stat| and \verb|sevr| and returns a value of \verb|DBE_ALARM|.
1122+If no change occured it returns 0.
1123+Thus after calling \verb|recGblResetAlarms| everything is ready for raising alarms the next time the record is processed.
1124+The example record support module presented above shows how these macros are used.
1125
1126 \begin{verbatim}
1127 recGblSetSevr(
1128@@ -790,7 +818,7 @@
1129 short nsevr);
1130 \end{verbatim}
1131
1132-\index{recGblSetSevr}Returns: (\verb|TRUE|, \verb|FALSE|) if (did, did not) change \verb|nsta| and \verb|nsev|.
1133+\index{recGblSetSevr}Returns \verb|TRUE| if it changed \verb|nsta| and/or \verb|nsev|, \verb|FALSE| if it did not change them.
1134
1135 \begin{verbatim}
1136 unsigned short recGblResetAlarms(void *precord);
1137@@ -800,9 +828,10 @@
1138
1139 \subsection{Alarm Acknowledgment}
1140
1141-Database common contains two additional alarm related fields: \verb|acks| (Highest severity unacknowledged alarm) and
1142-\verb|ackt| (does transient alarm need to be acknowledged). These field are handled by \verb|iocCore| and \verb|recGblResetAlarms|
1143-and are not the responsibility of record support. These fields are intended for use by the alarm handler.
1144+Database common contains two additional alarm related fields:
1145+\verb|acks| (Highest severity unacknowledged alarm) and \verb|ackt| (does transient alarm need to be acknowledged).
1146+These field are handled by \verb|iocCore| and \verb|recGblResetAlarms| and are not the responsibility of record support.
1147+These fields are intended for use by the alarm handler.
1148
1149 \subsection{Generate Error: Process Variable Name, Caller, Message}
1150
1151@@ -815,8 +844,8 @@
1152 char *pcaller_name); /* calling routine name */
1153 \end{verbatim}
1154
1155-\index{recGblDbaddrError}This routine interfaces with the system wide error handling system to display the following information: Status
1156-information, process variable name, calling routine.
1157+\index{recGblDbaddrError}This routine interfaces with the system wide error handling system to display the following information:
1158+Status information, process variable name, calling routine.
1159
1160 \subsection{Generate Error: Status String, Record Name, Caller}
1161 SUGGESTION: use errlogPrintf instead of this for new code.
1162@@ -829,8 +858,8 @@
1163
1164 \index{errlogPrintf}
1165 \index{recGblRecordError}
1166-This routine interfaces with the system wide error handling system to display the following information: Status
1167-information, record name, calling routine.
1168+This routine interfaces with the system wide error handling system to display the following information:
1169+Status information, record name, calling routine.
1170
1171 \subsection{Generate Error: Record Name, Caller, Record Support Message}
1172 SUGGESTION: use errlogPrintf instead of this for new code.
1173@@ -844,8 +873,8 @@
1174
1175 \index{errlogPrintf}
1176 \index{recGblRecsupError}
1177-This routine interfaces with the system wide error handling system to display the following information: Status
1178-information, record name, calling routine, record support entry name.
1179+This routine interfaces with the system wide error handling system to display the following information:
1180+Status information, record name, calling routine, record support entry name.
1181
1182 \subsection{Get Graphics Double}
1183
1184@@ -900,8 +929,8 @@
1185 \index{recGblGetTimeStamp}This routine gets the current time stamp and puts it in the record It does the following:
1186
1187 \begin{itemize}
1188-\item If TSEL is not a constant link and TSEL refers to the TIME field of a record, the time is obtained from the record
1189-reference by TSEL and this put in field TIME. The routine then returns.
1190+\item If TSEL is not a constant link and TSEL refers to the TIME field of a record, the time is obtained from the record reference by TSEL and this put in field TIME.
1191+The routine then returns.
1192
1193 \item If TSEL is not a constant link dbGetLink is called and the value put in field TSE.
1194
1195@@ -929,5 +958,6 @@
1196 void *pdest);
1197 \end{verbatim}
1198
1199-\index{recGblInitConstantLink}Initialize a constant link. This routine is usually called by \verb|init_record| (or by associated device support) to initialize
1200-the field associated with a constant link. It returns(FALSE, TRUE) if it (did not, did) modify the destination.
1201+\index{recGblInitConstantLink}Initialize a constant link.
1202+This routine is usually called by \verb|init_record| (or by associated device support) to initialize the field associated with a constant link.
1203+It returns(FALSE, TRUE) if it (did not, did) modify the destination.

Subscribers

People subscribed via source and target branches