4 \section*{Bacula Developer Notes}
5 \label{_ChapterStart10}
6 \index{Bacula Developer Notes }
7 \index{Notes!Bacula Developer }
8 \addcontentsline{toc}{section}{Bacula Developer Notes}
12 \addcontentsline{toc}{subsection}{General}
14 This document is intended mostly for developers and describes the the general
15 framework of making Bacula source changes.
17 \subsubsection*{Contributions}
18 \index{Contributions }
19 \addcontentsline{toc}{subsubsection}{Contributions}
21 Contributions from programmers are broken into two groups. The first are
22 contributions that are aids and not essential to Bacula. In general, these
23 will be scripts or will go into and examples or contributions directory.
25 The second class of contributions are those which will be integrated with
26 Bacula and become an essential part. Within this class of contributions, there
27 are two hurdles to surmount. One is getting your patch accepted, and two is
28 dealing with copyright issues. The rest of this document describes some of the
29 requirements for such code.
31 \subsubsection*{Patches}
33 \addcontentsline{toc}{subsubsection}{Patches}
35 Subject to the copyright assignment described below, your patches should be
36 sent in {\bf diff -u} format relative to the current contents of the Source
37 Forge CVS, which is the easiest for me to understand. If you plan on doing
38 significant development work over a period of time, after having your first
39 patch reviewed and approved, you will be eligible for having CVS access so
40 that you can commit your changes directly to the CVS repository. To do so, you
41 will need a userid on Source Forge.
43 \subsubsection*{Copyrights}
45 \addcontentsline{toc}{subsubsection}{Copyrights}
47 To avoid future problems concerning changing licensing or copyrights, all code
48 contributions more than a hand full of lines must be in the Public Domain or
49 have the copyright assigned to Kern Sibbald as in the current code. Note,
50 prior to November 2004, the code was copyrighted by Kern Sibbald and John
53 Your name should be clearly indicated as the author of the code, and you must
54 be extremely careful not to violate any copyrights or use other people's code
55 without acknowledging it. The purpose of this requirement is to avoid future
56 copyright, patent, or intellectual property problems. To understand on
57 possible source of future problems, please examine the difficulties Mozilla is
58 (was?) having finding previous contributors at
60 http://www.mozilla.org/MPL/missing.html}
61 {http://www.mozilla.org/MPL/missing.html}. The other important issue is to
62 avoid copyright, patent, or intellectual property violations as are currently
63 (May 2003) being claimed by SCO against IBM.
65 Although the copyright will be held by Kern, each developer is expected to
66 indicate that he wrote and/or modified a particular module (or file) and any
67 other sources. The copyright assignment may seem a bit unusual, but in
68 reality, it is not. Most large projects require this. In fact, the paperwork
69 associated with making contributions to the Free Software Foundation, was for
72 If you have any doubts about this, please don't hesitate to ask. Our (John and
73 my) track records with Autodesk are easily available; early
74 programmers/founders/contributors and later employees had substantial shares
75 of the company, and no one founder had a controlling part of the company. Even
76 though Microsoft created many millionaires among early employees, the politics
77 of Autodesk (during our time at the helm) is in stark contrast to Microsoft
78 where the majority of the company is still tightly held among a few.
80 Items not needing a copyright assignment are: most small changes,
81 enhancements, or bug fixes of 5-10 lines of code, and documentation.
83 \subsubsection*{Copyright Assignment}
84 \index{Copyright Assignment }
85 \index{Assignment!Copyright }
86 \addcontentsline{toc}{subsubsection}{Copyright Assignment}
88 Since this is not a commercial enterprise, and I prefer to believe in
89 everyone's good faith, developers can assign the copyright by explicitly
90 acknowledging that they do so in their first submission. This is sufficient if
91 the developer is independent, or an employee of a not-for-profit organization
92 or a university. Any developer that wants to contribute and is employed by a
93 company must get a copyright assignment from his employer. This is to avoid
94 misunderstandings between the employee, the company, and the Bacula project.
96 \subsubsection*{Corporate Assignment Statement}
97 \index{Statement!Corporate Assignment }
98 \index{Corporate Assignment Statement }
99 \addcontentsline{toc}{subsubsection}{Corporate Assignment Statement}
101 The following statement must be filled out by the employer, signed, and mailed
102 to my address (please ask me for my address and I will email it -- I'd prefer
103 not to include it here).
107 Copyright release and transfer statement.
108 <On company letter head>
111 Concerning: Copyright release and transfer
113 <Company, Inc> is hereby agrees that <names-of-developers> and
114 other employees of <Company, Inc> are authorized to develop
115 code for and contribute code to the Bacula project for an
116 undetermined period of time. The copyright as well as all
117 other rights to and interests in such contributed code are
118 hereby transferred to Kern Sibbald.
120 Signed in <City, Country> on <Date>:
122 <Name of Person>, <Position in Company, Inc>
127 This release/transfer statement must be sent to:
131 \subsubsection*{Developing Bacula}
132 \index{Developing Bacula }
133 \index{Bacula!Developing }
134 \addcontentsline{toc}{subsubsection}{Developing Bacula}
136 Typically the simplest way to develop Bacula is to open one xterm window
137 pointing to the source directory you wish to update; a second xterm window at
138 the top source directory level, and a third xterm window at the bacula
139 directory \lt{}top\gt{}/src/bacula. After making source changes in one of the
140 directories, in the top source directory xterm, build the source, and start
141 the daemons by entering:
145 ./startit then in the enter:
149 ./gnome-console to start the Console program. Enter any commands for testing.
150 For example: run kernsverify full.
152 Note, the instructions here to use {\bf ./startit} are different from using a
153 production system where the administrator starts Bacula by entering {\bf
154 ./bacula start}. This difference allows a development version of {\bf Bacula}
155 to be run on a computer at the same time that a production system is running.
156 The {\bf ./startit} strip starts {\bf Bacula} using a different set of
157 configuration files, and thus permits avoiding conflicts with any production
160 To make additional source changes, exit from the Console program, and in the
161 top source directory, stop the daemons by entering:
163 ./stopit then repeat the process.
165 \subsubsection*{Debugging}
167 \addcontentsline{toc}{subsubsection}{Debugging}
169 Probably the first thing to do is to turn on debug output.
171 A good place to start is with a debug level of 20 as in {\bf ./startit -d20}.
172 The startit command starts all the daemons with the same debug level.
173 Alternatively, you can start the appropriate daemon with the debug level you
174 want. If you really need more info, a debug level of 60 is not bad, and for
175 just about everything a level of 200.
177 \subsubsection*{Using a Debugger}
178 \index{Using a Debugger }
179 \index{Debugger!Using a }
180 \addcontentsline{toc}{subsubsection}{Using a Debugger}
182 If you have a serious problem such as a segmentation fault, it can usually be
183 found quickly using a good multiple thread debugger such as {\bf gdb}. For
184 example, suppose you get a segmentation violation in {\bf bacula-dir}. You
185 might use the following to find the problem:
187 \lt{}start the Storage and File daemons\gt{}
190 run -f -s -c ./dird.conf
191 \lt{}it dies with a segmentation fault\gt{}
193 The {\bf -f} option is specified on the {\bf run} command to inhibit {\bf
194 dird} from going into the background. You may also want to add the {\bf -s}
195 option to the run command to disable signals which can potentially interfere
198 As an alternative to using the debugger, each {\bf Bacula} daemon has a built
199 in back trace feature when a serious error is encountered. It calls the
200 debugger on itself, produces a back trace, and emails the report to the
201 developer. For more details on this, please see the chapter in the main Bacula
202 manual entitled ``What To Do When Bacula Crashes (Kaboom)''.
204 \subsubsection*{Memory Leaks}
205 \index{Leaks!Memory }
206 \index{Memory Leaks }
207 \addcontentsline{toc}{subsubsection}{Memory Leaks}
209 Because Bacula runs routinely and unattended on client and server machines, it
210 may run for a long time. As a consequence, from the very beginning, Bacula
211 uses SmartAlloc to ensure that there are no memory leaks. To make detection of
212 memory leaks effective, all Bacula code that dynamically allocates memory MUST
213 have a way to release it. In general when the memory is no longer needed, it
214 should be immediately released, but in some cases, the memory will be held
215 during the entire time that Bacula is executing. In that case, there MUST be a
216 routine that can be called at termination time that releases the memory. In
217 this way, we will be able to detect memory leaks. Be sure to immediately
218 correct any and all memory leaks that are printed at the termination of the
221 \subsubsection*{Special Files}
222 \index{Files!Special }
223 \index{Special Files }
224 \addcontentsline{toc}{subsubsection}{Special Files}
226 Kern uses files named 1, 2, ... 9 with any extension as scratch files. Thus
227 any files with these names are subject to being rudely deleted at any time.
229 \subsubsection*{When Implementing Incomplete Code}
230 \index{Code!When Implementing Incomplete }
231 \index{When Implementing Incomplete Code }
232 \addcontentsline{toc}{subsubsection}{When Implementing Incomplete Code}
234 Please identify all incomplete code with a comment that contains {\bf
235 ***FIXME***}, where there are three asterisks (*) before and after the word
236 FIXME (in capitals) and no intervening spaces. This is important as it allows
237 new programmers to easily recognize where things are partially implemented.
239 \subsubsection*{Bacula Source File Structure}
240 \index{Structure!Bacula Source File }
241 \index{Bacula Source File Structure }
242 \addcontentsline{toc}{subsubsection}{Bacula Source File Structure}
244 The distribution generally comes as a tar file of the form {\bf
245 bacula.x.y.z.tar.gz} where x, y, and z are the version, release, and update
246 numbers respectively.
248 Once you detar this file, you will have a directory structure as follows:
254 |- mtx (autochanger control program + tape drive info)
255 |- sqlite (SQLite database program)
257 |- pthreads (Native win32 pthreads library -- dll)
258 |- zlib (Native win32 zlib library)
259 |- wx (wxWidgets source code)
260 |- bacula (main source directory containing configuration
261 | and installation files)
262 |- autoconf (automatic configuration files, not normally used
264 |- doc (documentation directory)
265 |- home-page (Bacula's home page source)
266 |- html-manual (html document directory)
267 |- techlogs (Technical development notes);
268 |- intl (programs used to translate)
269 |- platforms (OS specific installation files)
270 |- redhat (Red Hat installation)
271 |- solaris (Sun installation)
272 |- freebsd (FreeBSD installation)
273 |- irix (Irix installation -- not tested)
274 |- unknown (Default if system not identified)
275 |- po (translations of source strings)
276 |- src (source directory; contains global header files)
277 |- cats (SQL catalog database interface directory)
278 |- console (bacula user agent directory)
279 |- dird (Director daemon)
280 |- filed (Unix File daemon)
281 |- win32 (Win32 files to make bacula-fd be a service)
282 |- findlib (Unix file find library for File daemon)
283 |- gnome-console (GNOME version of console program)
284 |- lib (General Bacula library)
285 |- stored (Storage daemon)
286 |- tconsole (Tcl/tk console program -- not yet working)
287 |- testprogs (test programs -- normally only in Kern's tree)
288 |- tools (Various tool programs)
289 |- win32 (Native Win32 File daemon)
290 |- baculafd (Visual Studio project file)
291 |- compat (compatibility interface library)
292 |- filed (links to src/filed)
293 |- findlib (links to src/findlib)
294 |- lib (links to src/lib)
295 |- console (beginning of native console program)
296 |- wx-console (wxWidget console Win32 specific parts)
297 |- wx-console (wxWidgets console main source program)
298 |- regress (Regression scripts)
299 |- bin (temporary directory to hold Bacula installed binaries)
300 |- build (temporary directory to hold Bacula source)
301 |- scripts (scripts and .conf files)
302 |- tests (test scripts)
303 |- tmp (temporary directory for temp files)
307 \subsubsection*{Header Files}
308 \index{Header Files }
309 \index{Files!Header }
310 \addcontentsline{toc}{subsubsection}{Header Files}
312 Please carefully follow the scheme defined below as it permits in general only
313 two header file includes per C file, and thus vastly simplifies programming.
314 With a large complex project like Bacula, it isn't always easy to ensure that
315 the right headers are invoked in the right order (there are a few kludges to
316 make this happen -- i.e. in a few include files because of the chicken and egg
317 problem, certain references to typedefs had to be replaced with {\bf void} ).
319 Every file should include {\bf bacula.h}. It pulls in just about everything,
320 with very few exceptions. If you have system dependent ifdefing, please do it
321 in {\bf baconfig.h}. The version number and date are kept in {\bf version.h}.
323 Each of the subdirectories (console, cats, dird, filed, findlib, lib, stored,
324 ...) contains a single directory dependent include file generally the name of
325 the directory, which should be included just after the include of {\bf
326 bacula.h}. This file (for example, for the dird directory, it is {\bf dird.h})
327 contains either definitions of things generally needed in this directory, or
328 it includes the appropriate header files. It always includes {\bf protos.h}.
331 Each subdirectory contains a header file named {\bf protos.h}, which contains
332 the prototypes for subroutines exported by files in that directory. {\bf
333 protos.h} is always included by the main directory dependent include file.
335 \subsubsection*{Programming Standards}
336 \index{Standards!Programming }
337 \index{Programming Standards }
338 \addcontentsline{toc}{subsubsection}{Programming Standards}
340 For the most part, all code should be written in C unless there is a burning
341 reason to use C++, and then only the simplest C++ constructs will be used.
342 Note, Bacula is slowly evolving to use more and more C++.
344 Code should have some documentation -- not a lot, but enough so that I can
345 understand it. Look at the current code, and you will see that I document more
346 than most, but am definitely not a fanatic.
348 I prefer simple linear code where possible. Gotos are strongly discouraged
349 except for handling an error to either bail out or to retry some code, and
350 such use of gotos can vastly simplify the program.
352 Remember this is a C program that is migrating to a {\bf tiny} subset of C++,
353 so be conservative in your use of C++ features.
355 \subsubsection*{Do Not Use}
358 \addcontentsline{toc}{subsubsection}{Do Not Use}
361 \item STL -- it is totally incomprehensible.
364 \subsubsection*{Avoid if Possible}
365 \index{Possible!Avoid if }
366 \index{Avoid if Possible }
367 \addcontentsline{toc}{subsubsection}{Avoid if Possible}
370 \item Returning a malloc'ed buffer from a subroutine -- someone will forget
372 \item Using reference variables -- it allows subroutines to create side
374 \item Heap allocation (malloc) unless needed -- it is expensive.
375 \item Templates -- they can create portability problems.
376 \item Fancy or tricky C or C++ code, unless you give a good explanation of
378 \item Too much inheritance -- it can complicate the code, and make reading it
379 difficult (unless you are in love with colons)
382 \subsubsection*{Do Use Whenever Possible}
383 \index{Possible!Do Use Whenever }
384 \index{Do Use Whenever Possible }
385 \addcontentsline{toc}{subsubsection}{Do Use Whenever Possible}
388 \item Locking and unlocking within a single subroutine.
389 \item Malloc and free within a single subroutine.
390 \item Comments and global explanations on what your code or algorithm does.
393 \subsubsection*{Indenting Standards}
394 \index{Standards!Indenting }
395 \index{Indenting Standards }
396 \addcontentsline{toc}{subsubsection}{Indenting Standards}
398 I cannot stand code indented 8 columns at a time. This makes the code
399 unreadable. Even 4 at a time uses a lot of space, so I have adopted indenting
400 3 spaces at every level. Note, indention is the visual appearance of the
401 source on the page, while tabbing is replacing a series of up to 8 spaces from
404 The closest set of parameters for the Linux {\bf indent} program that will
405 produce reasonably indented code are:
409 -nbad -bap -bbo -nbc -br -brs -c36 -cd36 -ncdb -ce -ci3 -cli0
410 -cp36 -d0 -di1 -ndj -nfc1 -nfca -hnl -i3 -ip0 -l85 -lp -npcs
411 -nprs -npsl -saf -sai -saw -nsob -nss -nbc -ncs -nbfda
415 You can put the above in your .indent.pro file, and then just invoke indent on
416 your file. However, be warned. This does not produce perfect indenting, and it
417 will mess up C++ class statements pretty badly.
419 Braces are required in all if statements (missing in some very old code). To
420 avoid generating too many lines, the first brace appears on the first line
421 (e.g. of an if), and the closing brace is on a line by itself. E.g.
431 Just follow the convention in the code. Originally I indented case clauses
432 under a switch(), but now I prefer non-indented cases.
449 Avoid using // style comments except for temporary code or turning off debug
450 code. Standard C comments are preferred (this also keeps the code closer to
453 Attempt to keep all lines less than 85 characters long so that the whole line
454 of code is readable at one time. This is not a rigid requirement.
456 Always put a brief description at the top of any new file created describing
457 what it does and including your name and the date it was first written. Please
458 don't forget any Copyrights and acknowledgments if it isn't 100\% your code.
459 Also, include the Bacula copyright notice that is in {\bf src/c}.
461 In general you should have two includes at the top of the an include for the
462 particular directory the code is in, for includes are needed, but this should
465 In general (except for self-contained packages), prototypes should all be put
466 in {\bf protos.h} in each directory.
468 Always put space around assignment and comparison operators.
479 but your can compress things in a {\bf for} statement:
483 for (i=0; i < del.num_ids; i++) {
488 Don't overuse the inline if (?:). A full {\bf if} is preferred, except in a
489 print statement, e.g.:
493 if (ua->verbose \&& del.num_del != 0) {
494 bsendmsg(ua, _("Pruned %d %s on Volume %s from catalog.\n"), del.num_del,
495 del.num_del == 1 ? "Job" : "Jobs", mr->VolumeName);
500 Leave a certain amount of debug code (Dmsg) in code you submit, so that future
501 problems can be identified. This is particularly true for complicated code
502 likely to break. However, try to keep the debug code to a minimum to avoid
503 bloating the program and above all to keep the code readable.
505 Please keep the same style in all new code you develop. If you include code
506 previously written, you have the option of leaving it with the old indenting
507 or re-indenting it. If the old code is indented with 8 spaces, then please
508 re-indent it to Bacula standards.
510 If you are using {\bf vim}, simply set your tabstop to 8 and your shiftwidth
513 \subsubsection*{Tabbing}
515 \addcontentsline{toc}{subsubsection}{Tabbing}
517 Tabbing (inserting the tab character in place of spaces) is as normal on all
518 Unix systems -- a tab is converted space up to the next column multiple of 8.
519 My editor converts strings of spaces to tabs automatically -- this results in
520 significant compression of the files. Thus, you can remove tabs by replacing
521 them with spaces if you wish. Please don't confuse tabbing (use of tab
522 characters) with indenting (visual alignment of the code).
524 \subsubsection*{Don'ts}
526 \addcontentsline{toc}{subsubsection}{Don'ts}
541 They are system dependent and un-safe. These should be replaced by the Bacula
546 char *bstrncpy(char *dest, char *source, int dest_size);
547 char *bstrncat(char *dest, char *source, int dest_size);
548 int bsnprintf(char *buf, int32_t buf_len, const char *fmt, ...);
549 int bvsnprintf(char *str, int32_t size, const char *format, va_list ap);
553 See src/lib/bsys.c for more details on these routines.
555 Don't use the {\bf \%lld} or the {\bf \%q} printf format editing types to edit
556 64 bit integers -- they are not portable. Instead, use {\bf \%s} with {\bf
557 edit\_uint64()}. For example:
562 uint64_t num = something;
564 bsnprintf(buf, sizeof(buf), "Num=%s\n", edit_uint64(num, ed1));
568 The edit buffer {\bf ed1} must be at least 27 bytes long to avoid overflow.
569 See src/lib/edit.c for more details. If you look at the code, don't start
570 screaming that I use {\bf lld}. I actually use subtle trick taught to me by
571 John Walker. The {\bf lld} that appears in the editing routine is actually
572 {\bf \#define} to a what is needed on your OS (usually ``lld'' or ``q'') and
573 is defined in autoconf/configure.in for each OS. C string concatenation causes
574 the appropriate string to be concatenated to the ``\%''.
576 Also please don't use the STL or Templates or any complicated C++ code.
578 \subsubsection*{Message Classes}
579 \index{Classes!Message }
580 \index{Message Classes }
581 \addcontentsline{toc}{subsubsection}{Message Classes}
583 Currently, there are five classes of messages: Debug, Error, Job, Memory,
586 \subsubsection*{Debug Messages}
587 \index{Messages!Debug }
588 \index{Debug Messages }
589 \addcontentsline{toc}{subsubsection}{Debug Messages}
591 Debug messages are designed to be turned on at a specified debug level and are
592 always sent to STDOUT. There are designed to only be used in the development
593 debug process. They are coded as:
595 DmsgN(level, message, arg1, ...) where the N is a number indicating how many
596 arguments are to be substituted into the message (i.e. it is a count of the
597 number arguments you have in your message -- generally the number of percent
598 signs (\%)). {\bf level} is the debug level at which you wish the message to
599 be printed. message is the debug message to be printed, and arg1, ... are the
600 arguments to be substituted. Since not all compilers support \#defines with
601 varargs, you must explicitly specify how many arguments you have.
603 When the debug message is printed, it will automatically be prefixed by the
604 name of the daemon which is running, the filename where the Dmsg is, and the
605 line number within the file.
607 Some actual examples are:
609 Dmsg2(20, ``MD5len=\%d MD5=\%s\textbackslash{}n'', strlen(buf), buf);
611 Dmsg1(9, ``Created client \%s record\textbackslash{}n'', client->hdr.name);
613 \subsubsection*{Error Messages}
614 \index{Messages!Error }
615 \index{Error Messages }
616 \addcontentsline{toc}{subsubsection}{Error Messages}
618 Error messages are messages that are related to the daemon as a whole rather
619 than a particular job. For example, an out of memory condition my generate an
620 error message. They should be very rarely needed. In general, you should be
621 using Job and Job Queued messages (Jmsg and Qmsg). They are coded as:
623 EmsgN(error-code, level, message, arg1, ...) As with debug messages, you must
624 explicitly code the of arguments to be substituted in the message. error-code
625 indicates the severity or class of error, and it may be one of the following:
627 \addcontentsline{lot}{table}{Message Error Code Classes}
628 \begin{longtable}{lp{3in}}
629 {{\bf M\_ABORT} } & {Causes the daemon to immediately abort. This should be
630 used only in extreme cases. It attempts to produce a traceback. } \\
631 {{\bf M\_ERROR\_TERM} } & {Causes the daemon to immediately terminate. This
632 should be used only in extreme cases. It does not produce a traceback. } \\
633 {{\bf M\_FATAL} } & {Causes the daemon to terminate the current job, but the
634 daemon keeps running } \\
635 {{\bf M\_ERROR} } & {Reports the error. The daemon and the job continue
637 {{\bf M\_WARNING} } & {Reports an warning message. The daemon and the job
638 continue running } \\
639 {{\bf M\_INFO} } & {Reports an informational message. }
643 There are other error message classes, but they are in a state of being
644 redesigned or deprecated, so please do not use them. Some actual examples are:
647 Emsg1(M\_ABORT, 0, ``Cannot create message thread: \%s\textbackslash{}n'',
650 Emsg3(M\_WARNING, 0, ``Connect to File daemon \%s at \%s:\%d failed. Retrying
651 ...\textbackslash{}n'', client-\gt{}hdr.name, client-\gt{}address,
654 Emsg3(M\_FATAL, 0, ``bdird\lt{}filed: bad response from Filed to \%s command:
655 \%d \%s\textbackslash{}n'', cmd, n, strerror(errno));
657 \subsubsection*{Job Messages}
658 \index{Job Messages }
659 \index{Messages!Job }
660 \addcontentsline{toc}{subsubsection}{Job Messages}
662 Job messages are messages that pertain to a particular job such as a file that
663 could not be saved, or the number of files and bytes that were saved. They
666 Jmsg(jcr, M\_FATAL, 0, "Text of message");
668 A Jmsg with M\_FATAL will fail the job. The Jmsg() takes varargs so can
669 have any number of arguments for substituted in a printf like format.
670 Output from the Jmsg() will go to the Job report.
672 If the Jmsg is followed with a number such as Jmsg1(...), the number
673 indicates the number of arguments to be substituted (varargs is not
674 standard for \#defines), and what is more important is that the file and
675 line number will be prefixed to the message. This permits a sort of debug
678 \subsubsection*{Queued Job Messages}
679 \index{Queued Job Messages }
680 \index{Messages!Job }
681 \addcontentsline{toc}{subsubsection}{Queued Job Messages}
682 Queued Job messages are similar to Jmsg()s except that the message is
683 Queued rather than immediately dispatched. This is necessary within the
684 network subroutines and in the message editing routines. This is to prevent
685 recursive loops, and to ensure that messages can be delivered even in the
686 event of a network error.
689 \subsubsection*{Memory Messages}
690 \index{Messages!Memory }
691 \index{Memory Messages }
692 \addcontentsline{toc}{subsubsection}{Memory Messages}
694 Memory messages are messages that are edited into a memory buffer. Generally
695 they are used in low level routines such as the low level device file dev.c in
696 the Storage daemon or in the low level Catalog routines. These routines do not
697 generally have access to the Job Control Record and so they return error
698 messages reformatted in a memory buffer. Mmsg() is the way to do this.