MULTICS ADMINISTRATIVE BULLETIN MAB-058-01 To: MAB Distribution From: Paul Dickson Date: September 2, 1986 Subject: Multics Technical Bulletin (MTB) Publication Abstract: This MAB describes the approval, publication, and distribuation process used for MTBs. Revision 1 describes a significant change in automating the process of publishing the MTBs. Revisions: Rev0) 1982-12-22 John Gintell, Robert Coren Document the new procedures for publication and distribution of MTBs using the MTB exec_com. _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics Project. - i - MAB-058-01 MTB Publishing CONTENTS Page 1: Overview of the MTB Publication Process . . . . 1 | 1.1: The Developer's Part . . . . . . . . . . . . 1 | 1.1.1: Preparation . . . . . . . . . . . . . . . . 1 1.1.2: Review . . . . . . . . . . . . . . . . . . 1 1.1.3: Approval . . . . . . . . . . . . . . . . . 2 1.1.4: Obtaining an MTB Number . . . . . . . . . . 2 1.1.5: Publication of the MTB . . . . . . . . . . 2 1.2: The MTB Administrator's Part . . . . . . . . 2 1.3: Miscellaneous Details . . . . . . . . . . . . 3 1.4: Developer's MTB exec_com . . . . . . . . . . 4 mtb.ec . . . . . . . . . . . . . . . . . . . . . 5 get_id . . . . . . . . . . . . . . . . . . . . . 6 submit_mtb_request (submit) . . . . . . . . . . 7 2: The MTB Administrator . . . . . . . . . . . . . 9 2.1: Overview of the Administrator's Functions . . 9 2.1.1: Processing Mail Request . . . . . . . . . . 9 2.1.2: Maintaining the MTB Library . . . . . . . . 10 2.1.3: Generating the MTB Index . . . . . . . . . 10 2.2: Administrator's MTB exec_com . . . . . . . . 11 mtb.ec . . . . . . . . . . . . . . . . . . . . . 12 assign_id . . . . . . . . . . . . . . . . . . . 13 append (app, a) . . . . . . . . . . . . . . . . 14 imft . . . . . . . . . . . . . . . . . . . . . . 16 mtb_index (index) . . . . . . . . . . . . . . . 17 replace (rp) . . . . . . . . . . . . . . . . . . 18 delete (dl, d) . . . . . . . . . . . . . . . . . 20 unreplace (urp) . . . . . . . . . . . . . . . . 21 Appendix A: Compose Macros for MTBs . . . . . . . 22 MTB_HEADING.compin . . . . . . . . . . . . . . . 23 - ii - MTB Publishing MAB-058-01 1: OVERVIEW OF THE MTB PUBLICATION PROCESS The following section describes procedures for publishing an MTB. These procedures are implemented by: the developer who writes the MTB; and by the MTB Administrator who installs the MTB into the MTB Library (>udd>Multics>mtbs), distributes a hardcopy abstract of the MTB to each MDC developer, and produces hardcopies of the entire MTB for posting purposes. | | | 1.1: The Developer's Part | | The list of the developer's responsibilities. | | | 1.1.1: PREPARATION | | The developer should prepare the MTB using compose. The first page of the MTB must be formatted using the MTB macros that can be found in >udd>m>mtbs>macros. See appendix A for more info. These macros allow the MTB exec_com to extract information from your MTB in a straightforward manner. The first page contains the MTB number and revision number (eg 741-05), MTB title (the Subject line), an abstract of the MTB, and the preferred method for commenting upon the MTB. The abstract should summarize the purpose of the MTB and its major conclusions. Of the possible methods for receiving comments (ie, forum pathname, mailbox path to which comments should be sent, phone number of the author, etc), a forum meeting is the preferred method. Since MTBs are not public documents, be sure to choose a forum meeting with participation limited exclusively to MDC developers. A hardcopy of this first page will be distributed to all MDC personnel. Therefore, the first page should contain enough information to allow the reader to decide whether to read the rest of the document. 1.1.2: REVIEW Each MTB should be written and circulated in draft form to interested and knowledgeable peers and managers. It will likely go through many drafts before being ready to enter the next stage. - 1 - MAB-058-01 MTB Publishing The review stage is most important part of the process. The | purpose is to resolve any obvious omissions, controversial | issues, etc. prior to full publication. For many MTBs, all interested parties have already seen and contributed to the MTB, and will not need to see the published copy. 1.1.3: APPROVAL Each MTB must be formally reviewed and approved by the author's immediate manager prior to publication. 1.1.4: OBTAINING AN MTB NUMBER Once the manager has approved MTB publication, the developer (author) should obtain an MTB number from the MTB Administrator, using the following command line: ec >udd>m>mtbs>mtb get_id "mtb_title" | Where "mtb_title" is the title of the proposed MTB. The MTB Administrator will reply back via mail with the MTB number that is assigned. The author will then use this number to | complete the formatting of the MTB by including the number in the | MTB_HEADING.compin macro call on the first page of the MTB, and | recomposing the MTB. 1.1.5: PUBLICATION OF THE MTB When the MTB is ready for publication, the author uses the mtb exec_com again to submit the MTB. ec mtb submit The MTB compout file must be stored in a segment named mtbNNN (where NNN is the MTB number). It should be in a format suitable for printing on a line printer or on the Xerox 9700 without the use of special controls (such as variable fonts). Since this copy will also be used for online perusal, it should be formatted without global indentation. 1.2: The MTB Administrator's Part The MTB Administrator will process the submit request by performing the following steps. o Install the MTB into the MTB Library, into a segment named >udd>Multics>mtbs>mtbNNN on System M. - 2 - MTB Publishing MAB-058-01 o Transfer the MTB to MIT and place it in >udd>Multics>mtbs>mtbNNN there. o Enter a transaction in the forum meeting MTB_Summaries (>udd>m>mtgs>MTB_Summaries) on System M. This meeting will be read-only to all members of the Multics project who are entitled to see MTBs, and writeable only to the MTB Administrator. o Distribute Xerox copies of the first page of the MTB to all members of the project. o Print several copies of the MTB. These are posted in prominent MDC locations, stored in the MTB hardcopy library, and provided for several individuals who are designated as keepers of all MTBs. 1.3: Miscellaneous Details Users can print their own copies of the MTB on the MIT page printer (i.e., the 9700). This facility is not free and excessive use of it ties up a valuable resource so you are requested to print copies of only those MTBs that you really need. Distribution to persons who do not have access will continue to controlled by the Director. Occasionally an MTB contains material such as diagrams that cannot be conveniently included in an online version. This is a rare occurrence, and inclusion of such material is discouraged. If it is unavoidable, the author should leave space in the online version for the hardcopy material and provide the administrator with a copy of said material. The administrator will then try to include copies of it in the posted copies of the MTBs, and distribute copies to the librarians. - 3 - MAB-058-01 MTB Publishing 1.4: Developer's MTB exec_com This section describes the exec_com used by the developer to publish Multics Technical Bulletins. This exec_com has only two operations that are usable to the developer. It resides in >udd>Multics>mtbs>admin, with a link to it placed in >udd>Multics>mtbs. There is an online help facility for the MTB exec_com by typing: help >udd>Multics>mtbs>info>mtb - 4 - ______ ______ mtb.ec mtb.ec ______ ______ NAME: MTB.EC SYNTAX AS A COMMAND ec mtb operation {args} FUNCTION Controls the Multics Technical Bulletins (MTB) library. ARGUMENTS operation designates the operation to be performed. See "List of Operations" below. Descriptions of each operation follow this one. | LIST OF DEVELOPER OPERATIONS: | | get_id sends Multics mail to the MAB Administrator requesting a new MTB identification number assignment. submit_mtb_request, submit invokes a question and answer session that attains and verifies information about a new MTB, then submits a request to the MTB Administrator to add the new MTB to the MTB library. - 5 - ______ ______ get_id get_id ______ ______ NAME: GET_ID SYNTAX AS A COMMAND ec mtb get_id "subject" FUNCTION requests the assignment of a unique MTB identification number for the specified subject. ARGUMENTS get_id the get MTB identification number request type. subject a subject for use by the author of the MTB to identify it. EXAMPLES ec mtb get_id "Pascal Symbol Tables" - 6 - __________________ __________________ submit_mtb_request submit_mtb_request __________________ __________________ NAME: SUBMIT_MTB_REQUEST, SUBMIT SYNTAX AS A COMMAND ec mtb submit FUNCTION prompts the MTB developer for the pathname of the MTB, verifies that the MTB segment and the .compin exists, and send a message to the MTB Administrator requesting that the MTB be added to the MTB library. PROMPTS: Pathname of the new MTB (dir>mtbNNN): >udd>m>pwd>t>t>mtb716 The MTB is identified as MTB716 with a revision number of 02 Is this correct ? y Will MTB716 replace any previously published MTB numbers ? yes Enter replaced MTBs by identification number. to finish sequence. mtb 1 mtb 50 where the identification number is from 1 to 999. mtb mtb.ec: requested load of segment: >udd>m>pwd>t>t>mtb716 NOTES 1) The MTB text segments may reside anywhere the developer desires. The submit operation requires that the author of the MTB give the designated MTB administrator status access to the directory which contains the MTB text segments and read access to the segments themselves. 2) The text segments may be named at the authors discretion, but there are two constraints that are required by the MTB library. First, the MTB .compin segments should exist as either a single .compin segment, or if the MTB is composed of many .compin segments, they must be archived into one archive segment. Second, the .compin segment must have the - 7 - __________________ __________________ submit_mtb_request submit_mtb_request __________________ __________________ same name as the formatted text segment. For example: mtb716 or mtb716 mtb716.compin mtb716.archive 3) 3) The submit operation requires that the MTB to be added to the library be formatted in a standard way. The exact format of an MTB is detailed elsewhere in the MAB (see MTB_HEADING.compin). Please be familiar with these macros prior to running the submit operation. - 8 - MTB Publishing MAB-058-01 2: THE MTB ADMINISTRATOR This section deals with the responsibilities associated with the | MTB Administrator. | 2.1: Overview of the Administrator's Functions The MTB administrator has three items of responsibility for maintaining the MTB libraries. These responsibilities are: 1) Processing requests that arrive in the mtb_admin mailbox. 2) Maintaining the MTB database using the MTB exec_com for | such operations as delete and unreplace. 3) Generating an up to date mtb_index. | 2.1.1: PROCESSING MAIL REQUEST Requests that need to be processed will appear in the mailbox, >udd>m>mtbs>admin>mtb_admin.mbx. Processing these request request are relatively easy. You only need to use read_mail's apply command. apply exec_com >udd>m>mtbs>mtb or ap ec mtb The exec_com will then extract the function from the text of the | mail and process it. After the command has completed correctly, | the message that was processed should be deleted. A sample | script follows: | cwd >udd>m>mtbs>admin r 15:51 218.855 4012 rdm mtb_admin There is one message in >udd>m>mtbs>admin>mtb_admin.mbx. read_mail: pr #1 (1 line in body): Date: Tuesday, 12 August 1986 14:41 mst From: Paul Dickson Subject: MTB append request To: {mbx >udd>Multics>mtbs>admin>mtb_admin} - 9 - MAB-058-01 MTB Publishing append >udd>m>pwd>t>t>mtb716 716 ---(1)--- | read_mail: apply ec mtb read_mail: dl read_mail: q r 15:58 155.694 5504 The commands in this category are assign_id, append, and replace. 2.1.2: MAINTAINING THE MTB LIBRARY There are other commands that the MTB Administrator needs to use inorder to maintain the MTB library and database. These commands are imft, unreplace, and delete. EXAMPLES ec mtb unreplace 315 2.1.3: GENERATING THE MTB INDEX Because of the size of the MTB database, regenerating the | mtb_index takes a long time. This is especially true if there are many requests to be processed. For this reason, the | mtb_index command must be called explicitly after processing of | all request are complete, rather than being automatically invoked | as part of each request. EXAMPLES ec mtb mtb_index - 10 - MTB Publishing MAB-058-01 2.2: Administrator's MTB exec_com This section describes the exec_com used by the administrator to publish Multics Technical Bulletins. This exec_com has seven operations that are usable by the administrator and it resides in >udd>Multics>mtbs>admin. There is an online help facility for the MTB exec_com by typing: help >udd>Multics>mtbs>info>mtb - 11 - ______ ______ mtb.ec mtb.ec ______ ______ NAME: MTB.EC SYNTAX AS A COMMAND ec mtb operation {args} FUNCTION Controls the Multics Technical Bulletins (MTB) library. ARGUMENTS operation designates the operation to be performed. See "List of Operations" below. Descriptions of each operation follow this one. LIST OF ADMINISTRATOR OPERATIONS: assign_id checks the library database for a matching title; if not found, it assigns the next highest MTB identification number to the new MTB title and author. append, app, a adds the specified MTB to the MTB library. imft submits a request to move a copy of a segment to the Multics System at MIT. mtb_index, index regenerates the mtb_index from the MTB database and sends a copy to MIT. replace, rp updates the library to indicate that an MTB has been replaced by another MTB. delete, dl, d deletes all formated text segments matching the specified number from the MTB library. unreplace, urp updates the library to indicate that an MTB which was replaced is to be activated. - 12 - _________ _________ assign_id assign_id _________ _________ NAME: ASSIGN_ID SYNTAX AS A COMMAND ec mtb assign_id "subject" author SYNTAX AS A READ_MAIL REQUEST: apply ec mtb FUNCTION Checks access to the MTB library directories and segments. If the checks are successful, the library database is checked for a subject which duplicates the requested subject. If found, a warning is displayed and no update takes place, otherwise the database is checked for the highest numeric MTB identification number. The number is then incremented by one and then stored in the database a long with the subject and the author of the MTB. The mtb_index is then updated to include the new MTB. The operation finishes by sending the MTB identification number to the requesting author via Multics mail. ARGUMENTS assign_id the operation request type. subject the chosen subject of the uninstalled MTB document which is being prepare for publication. author the user name and project of the person who entered the mtb get_id request. ACCESS REQUIRED: sma on all MTB library directories. rw on the MTB database, packet, and index segments. EXAMPLES ec mtb assign_id "Kermit File Transfer Protocol" user.Multics - 13 - ______ ______ append append ______ ______ NAME: APPEND, APP, A SYNTAX AS A COMMAND ec mtb a path mtb_number mtb_revision SYNTAX AS A READ_MAIL REQUEST: apply ec mtb FUNCTION checks access of path and access of all necessary MTB library segments. Checks for existence of the segment specified by path and path.compin (or path.archive as the case may be) under the containing directory. If all checks are successful, the formatted text segment is copied to the MTBs directory and the .compin segment is copied to the MTB source directory. Then the MTB database and index are updated to include the new MTB and a transaction is added to the MTB_Summaries forum meeting to announce the addition. Finally, a request is submitted to the Inter-Multics File Transfer (IMFT) system to transfer the MTB to the MTB library at MIT. ARGUMENTS append, app, a the append operation request type. path is the pathname of the MTB formatted text segment to be operated on by the append operation. The star convention cannot be used. mtb_number the identification number to be assigned to the MTB. mtb_revision optional revision number of the MTB. ACCESS REQUIRED: sma on all MTB library directories. rw on the MTB database and packet segments. s on the directory containing path and path.compin. r on path and path.compin - 14 - ______ ______ append append ______ ______ EXAMPLES ec mtb a >udd>Multics>user>mtb663 663 03 ec mtb a mtb716 716 - 15 - ____ ____ imft imft ____ ____ NAME: IMFT SYNTAX AS A COMMAND ec mtb imft mtb_identifier FUNCTION Submits an Inter-Multics File Transfer (IMFT) request to move a copy of a selected segment to the MTB library located on the Multics computer on MIT. ARGUMENTS imft the imft operation request type. mtb_identifier the number of the MTB to be transferred to MIT (the revision is not necessary), or the the literal "mtb_index". ACCESS REQUIRED: sma on the MTB library directories. r on the segment to be transferred. EXAMPLES ec mtb imft 716 ec mtb imft mtb_index - 16 - _________ _________ mtb_index mtb_index _________ _________ NAME: MTB_INDEX, INDEX SYNTAX AS A COMMAND ec mtb mtb_index FUNCTION checks access to the MTB library segments and the library directories. If the checks are successful, the mtb_index is regnerated from the data in the MTB database. Then a copy of mtb_index is IMFT to the Multics system at MIT and printed. ARGUMENTS mtb_index, index the mtb_index operation request type. ACCESS REQUIRED: sma on the MTB library directories. r on the MTB library database. EXAMPLES ec mtb index ec mtb mtb_index - 17 - _______ _______ replace replace _______ _______ NAME: REPLACE, RP SYNTAX AS A COMMAND ec mtb rp mtb_number1 mtb_number2 SYNTAX AS A READ_MAIL REQUEST: apply ec mtb FUNCTION checks access to the MTB library segments and the directories | containing MTB database and the MTB sources. If the checks are successful, an update is made to the MTB database to indicate that mtb_number1 has been replaced by mtb_number2. Then the formatted text segment of mtb_number1 is moved from the >udd>Multics>mtbs directory to the >udd>Multics>mtb>compin_dir with the suffix .obsolete added to the segment name, and a transaction is added to the MTB_Summaries forum announcing the replacement. ARGUMENTS replace, rp the replace operation request type. mtb_number1 the number of the MTB to be replaced. mtb_number2 the number of the MTB that is to replace mtb_number1. ACCESS REQUIRED: sma on the directory containing the MTB library database. rw on the MTB library files. EXAMPLES ec mtb replace 001 534 ec mtb rp 2 003 - 18 - _______ _______ replace replace _______ _______ NOTE: The MTB number to be replaced must be numerically less than the MTB number that is to replace it. - 19 - ______ ______ delete delete ______ ______ NAME: DELETE, DL, D SYNTAX AS A COMMAND ec mtb detete mtb_number FUNCTION checks access to the MTB library segments and the library directories. If the checks are successful, deletes all text segments which the mtb_number from the >udd>Multics>mtbs and the >udd>Multics>mtbs>compin_dir directories, updates the MTB database and index to remove any references to the MTB specified by mtb_number and adds a transaction to the MTB_Summaries forum announcing the deletion of the MTB. ARGUMENTS delete, dl, d the delete operation request type. mtb_number the numeric portion of the MTB identifier. ACCESS REQURIED: rw on the MTB library database. m on the MTB directory conatining the formatted text file. EXAMPLES ec mtb d 005 ec mtb delete 5 ec mtb dl 05 - 20 - _________ _________ unreplace unreplace _________ _________ NAME: UNREPLACE, URP SYNTAX AS A COMMAND ec mtb urp mtb_number FUNCTION checks access to the MTB library segments and the library directories. If the checks are seccessful, the formatted text segment of the MTB is moved from the >udd>Multics>mtbs>compin_dir directory to the >udd>Multics>mtbs directory with the suffix .obsolete removed from the segment name. Then the MTB database is updated to remove the indication that the MTB specified has been replaced by another MTB, and the transaction announcing the replacement is removed from the forum meeting. ARGUMENTS unreplace urp the unreplace operation request type. mtb_number the number of the MTB to be activated. (the revision number is unnecessary) ACCESS REQUIRED: sma on the MTB library directories. rw on the MTB library database. EXAMPLES ec mtb urp 01 ec mtb unreplace 1 - 21 - MAB-058-01 MTB Publishing APPENDIX A: COMPOSE MACROS FOR MTBS This appendix decribes the macros necessary to create the title | page of the MTB. Additional macros are available to help with | formatting the rest of the MTB. But it's only manditory that you the use the macros for creating the first page. After that, it's unimportant as to how you go about formatting your MTB. Notes about the abstract: The abstract is considered to be any text between the ..BEGIN_ABSTRACT and ..END_ABSTRACT. This text is placed in the | MTB database directly. Please don't place any unnecessary text | between the abstract macros. - 22 - __________________ __________________ MTB_HEADING.compin MTB_HEADING.compin __________________ __________________ NAME: MTB_HEADING.COMPIN List of first page macros: In >udd>Multics>mtbs>macros are the following macros. MTB_HEADING.compin 1) Formats the MTB heading, up to the subject line. 2) Sets page headers, footers, and the footnote at the bottom of the first page. 3) Supports automatic creation of a table of contents and a list of tables. BEGIN_MTB_ABSTRACT.compin | Provides a separator between the heading and the abstract. This is necessary for automatic insertion of the abstract into the MTB database. END_MTB_ABSTRACT.compin | Inserts a separator for termination of the abstract. END_MTB_HEADING.compin Ends the abstract page by inserting the standard Multics distribution limitation footnote; begins the table of contents and list of tables, if these are to appear in the MTB. Syntax: ..MTB_HEADING mtb_number brief_title authors pub_date {init {toc_on}} Subject: full_subject ..BEGIN_MTB_ABSTRACT ..END_MTB_ABSTRACT ..END_MTB_HEADING WARNING: You must use >unb>compose with these macros if you make use of the table-of-contents generation capabilities of these macros. >exl>e>compose produces TOC entries using new compose controls; these macros do not yet support this new mechanism. Example 1: ..MTB_HEADING "631-01" "Normal Installation Procedures" "Richard Holmstedt" .+ "August 23, 1983" init Subject: Procedures for Normal Installations of Multics Software ..BEGIN_MTB_ABSTRACT ..END_MTB_ABSTRACT ..END_MTB_HEADING - 23 - __________________ __________________ MTB_HEADING.compin MTB_HEADING.compin __________________ __________________ Example 2: .ur .ifi MTB_HEADING "DRAFT" "Critical Fixes" .+ "Gary C. Dixon, Frank W. Martinson" "%[long_date]%" init toc_on Subject: Policies and Procedures for Critical Fixes ..BEGIN_MTB_ABSTRACT ..END_MTB_ABSTRACT ..END_MTB_HEADING Function: In >udd>m>mtbs>macros>MTB_HEADING.compin is a macro which: 1) formats the MTB heading, up to the Subject line; 2) sets page headers and footers, and the footnote at bottom of first page; 3) takes an argument to produce just the abstract page; 4) supports automatic creation of an MTB table of contents, using the standard MPM macros (eg, ..l1h, ..l2h, etc), or through special macros described below which automatically number the section titles (eg, ..MHn, ..MHn.n, etc). Similarly, END_MTB_HEADING in the same directory ends the abstract page by inserting the standard Multics footnote, and begins the table of contents, if one appears. For MTBs in which no abstract or table of contents is needed, END_MTB_HEADING must still be used, immediately after the subject line. Arguments: mtb_number is the publication number assigned to the MTB. Before a publication number is assigned, this value can be set to " " (3 blanks), or to an alphabetic string "DRAFT", etc. The revision number must be included here if this MTB is to be a revision. The format of the mtb_number is "NNN" or "NNN-RR", where NNN is the mtb_number and RR is the revision number ("716-03" or "663"). brief_title is a short title to be placed in the heading line for all but the first page (the first page already has a Subject field in the header). author, a comma-separated list of the names of the MTB's author(s). pub_date is the publication date of this version. It is recommended that each version have a different publication date. The %[long_date]% - 24 - __________________ __________________ MTB_HEADING.compin MTB_HEADING.compin __________________ __________________ active function can be used for this. init is the name of a compose macro to be executed as part of formatting of the header. The macro is executed before any heading lines are emitted. The standard MPM macro init is recommended. This produces 8.5x11 inch pages. toc_on turns on automatic table-of-contents generation, when the standard MPM section title macros are used. full_subject is the full subject or title of the MTB. Invoking compose: To get a complete document include the table-of-contents inserted immediately after the abstract page, you must compose using 2 passes: compose mtb_file -of -passes 2 When writing the MTB, you can compose with only 1 pass. The table-of-contents from a previous composing of the MTB will be used (thus making the table-of-contents one draft behind the draft being composed). This lag is often adequate when making only small typographical changes, etc. List of other MTB Compose Macros (found in >udd>Multics>mtbs>macros): ..BEGIN_MTB_ABSTRACT | Delimits the beginning of the abstract so that is may be extracted by the mtb exec_com. ..END_MTB_ABSTRACT | Marks the end of the abstract as started by BEGIN_ABSTRACT. ..MH1 section title words creates a numbered section title for a major (level 1) section of the document. Example: ..MH1 Description of the Problem ..MH2 section title words creates a level 2, numbered section title. ..MH3 section title words creates a level 3, numbered section title. ..MH4 section title words creates a level 4, numbered section title. ..MH5 section title words creates a level 5, numbered section title. ..MHA - 25 - __________________ __________________ MTB_HEADING.compin MTB_HEADING.compin __________________ __________________ divides numbered sections from MTB Appendices. Subsequent MHn macros create a level 1, lettered appendix section title. Letters run from A through Z. ..RESET_MTB_HEADING resets the MTB heading information after standard compose macros have been used to create command or subroutine writeups in the MTB. List of Standard Compose Macros: These are described in detail in info segments in >doc>info. A brief list of useful macros follows: ..p1h begins an indented paragraph that starts an undented line. p1h stands for paragraph at indentation level 1, with a hanging (undented) first line. Similar macros exists for indentation levels 2, 3 and 4, each indented by 4 chars from the previous level. NOTE: with hanging undents, the entire contents of the line following ..p1h appears on the next line of the document. This is IS NOT FILLED. If the line is longer than the page width of the document, then it will extend into the right margin of the document. To avoid this, put only the words which must appear on the undented line on the line following ..p1h and put only text on subsequent lines. For example, to have a numbered paragraph: ..p1h 1) .* the .* keeps emacs from filling the text onto the same line as 1) | when esc-q is used. Or, more compactly: | | ..p1h;.ur 1) | | ..p1h;..bullet begins an indented paragraph that starts with a bullet. ..p0f ends a series of indented paragraphs. p0f stands for paragraph at indentation level 0, with flush first line (ie, not indented or undented/hanging). Similar macros exist for flush paragraphs at indentation levels 1, 2, 3 and 4. ..l0h section title words defines a major section of the document (eg, an appendix). The section can be number via .srv section 1 .srv section A - 26 - __________________ __________________ MTB_HEADING.compin MTB_HEADING.compin __________________ __________________ where the latter names appendix A. The new section begins on a new page. ..l1h section title words defines a named set of paragraphs. The section title words should be capitalized as they are to appear in the Table of Contents. In the actual text, they will be shifted to uppercase and underlined. The title can begin with a section title number. For example: ..l1h 1 Introduction ..l2h section title words like l1h, but the title in the text will simply be underlined. For example: ..l2h 1.3 Goals and Requirements ..l3h section title words like l1h, but title is only shifted to uppercase (no underlining). ..l4h section title words like l1h, but title appears exactly as given. - 27 -