public/html2wiki: test/resources/sysman

comparison test/resources/sysman_handbook.html @ 4:22ed6d93442c

Start modifying transformers to Confluence wiki syntax

author	smith@nwoca.org
date	Tue, 25 Jan 2011 21:59:31 -0500
parents	5da2e67620f9
children

comparison

equal deleted inserted replaced

-:4417b025157e
+:22ed6d93442c
 <html>
 <a name="first_page"></a>
-<!-- This file created using DECdocument  Version V3.3h on 25-JAN-2011 16:09:07.97 -->
+<!-- This file created using DECdocument  Version V3.3h on 25-JAN-2011 20:18:10.51 -->
 <!-- TAG definitions version: V3.3h -->
 <!-- The SDML doctype is: SOFTWARE.REFERENCE -->
 <!-- The output destination was: HTML -->
 <!-- SDML file is: NWB:[SMITH.DEV.SDML]OECN10_SYSMAN_HANDBOOK.SDML -->
 <br>
 Customizing Menus from the Distribution
 <p>
 <hr size=5>
-<a name="menu_intro"><h1>Chapter 1<br>Introduction</h1></a>
+<a name="menu_intro"><h1>Introduction</h1></a>
 <p>
 The OECN Menu processor provides a flexible user menu interface to
 State Software programs. It also can be used to create menus for DCL
 commands, and other layered products. Menu definitions will be provided
 for all state software programs. Individual A-sites will be able to add
 customized menus to the default menu system provided.
-<a name="menu_features_head"><h1>1.1 Features</h1></a>
+<a name="menu_features_head"><h1>Features</h1></a>
 <p>
 The Menu processor provides the following features:
 <ul>
 if the user remains inactive for a specified period.
 </ul>
 <p>
 <hr size=5>
-<a name="menu_theory"><h1>Chapter 2<br>Theory</h1></a>
+<a name="menu_theory"><h1>Theory</h1></a>
 <p>
 The basic theory behind the Menu processor is fairly simple. The menu
 definitions are stored in an RMS indexed file. The menu definitions are
 flexible enough to allow creation of menus containing any combination
 of DCL commands, programs and information.
-<a name="menu_terms_head"><h1>2.1 Definition of Terms</h1></a>
+<a name="menu_terms_head"><h1>Definition of Terms</h1></a>
 <p>
 First, it will be helpful to define some terms that will be used
 throughout the rest of this document. <p>
 <table border=3>
-<caption><a name="menu_terms_tab"><strong>Table 2-1 Menu System Terms</strong></a></caption>
+<caption><a name="menu_terms_tab"><strong> Menu System Terms</strong></a></caption>
 <tr>
 <th align=center>Term </th>
 <th align=center>Meaning </th>
 </tr>
 <tr>
 unique within each menu system.
 </td>
 </tr>
 </table>
-<a name="menu_files_theory"><h1>2.2 How Menu Files Create a Menu System</h1></a>
+<a name="menu_files_theory"><h1>How Menu Files Create a Menu System</h1></a>
 <p>
 <a href="oecn10_sysman_handbook_full.html#menu_system_fig">Figure 2-1</a> displays a graphical representation of a possible menu
 system.
 <a name="menu_system_fig"></a>
 <p>
-<strong>Figure 2-1 Conceptual View of a Menu system</strong>
+<strong>Conceptual View of a Menu system</strong>
 <hr>
 <p>
 <table border=0>
 <tr>
 Also, the menu system may have one local security file. This file is
 optional and created by the OSA utility. See the OECN Software Security
 for VAX/VMS System Manager manual for more information about security
 and the OSA utility.
-<a name="menu_specs_head"><h1>2.3 Menu Specifications</h1></a>
+<a name="menu_specs_head"><h1>Menu Specifications</h1></a>
 <p>
 Throughout this document there are references to <strong>menu
 specifications</strong>. Wherever a menu specification is required the
 following syntax is allowed:
 Goes to the LOCAL menu of the current file.
 </td>
 </tr>
 </table>
-<a name="alias_file_head"><h1>2.4 The Alias File</h1></a>
+<a name="alias_file_head"><h1>The Alias File</h1></a>
 <p>
 Each menu system may have exactly one <strong>alias file</strong>. An
 alias file contains a record for each menu item in the menu system.
 This alias record contains a pointer to the proper menu file that
 <p>
 The alias file is built automatically by the MENUUTL program. See
 <a href="oecn10_sysman_handbook_full.html#build_alias_head">Section 5.2.1, Building the Alias File</a> for more information about creating the alias file.
-<a name="option_exec_sect"><h1>2.5 Option execution</h1></a>
+<a name="option_exec_sect"><h1>Option execution</h1></a>
 <p>
 By default, the menu processor does <em>not</em> spawn subprocesses to
 execute user options. All commands are executed in the user's current
 process. This implies that menu processor image must exit and restart
 (activate) after each option has completed. This is called
 <strong>"terminate and execute"</strong> mode. This mode may provided
 optimal response time for smaller VAX processors, particularly machines
 with small memory configurations.
-<a name="heading_2.5.1"><h2>2.5.1 Spawning Options</h2></a>
+<a name="heading_2.5.1"><h2>Spawning Options</h2></a>
 <p>
 Another mode that may be chosen by the system manager is "spawn and
 execute". In this mode, <em>most</em> commands are executed in a
 subprocess. The menu processor remains running in the main process and
 subprocess. These types of items should be used sparingly and will
 seldom be necessary. The only item in the menu files distributed by
 SSDT that need the "DP" item type was the DETPRT option of the LOCAL
 menu. All other SSDT menu items may be executed in a subprocess.
-<a name="heading_2.5.2"><h2>2.5.2 Selecting Execution Mode</h2></a>
+<a name="heading_2.5.2"><h2>Selecting Execution Mode</h2></a>
 <p>
 To select either "terminate and execute" or "spawn and execute" mode,
 the system manager needs only define a single logical. The logical name
 is OECN$MENU_BEHAVIOR and may be defined in the SYSTARTUP procedure.
 <p>
 This logical also can be defined at the group or process level. If the
 logical is not defined, the default is "TERMINATE".
-<a name="timeout_head"><h1>2.6 Inactivity Timeout</h1></a>
+<a name="timeout_head"><h1>Inactivity Timeout</h1></a>
 <p>
 The menu processor has an optional feature that will cause it to
 automatically exit if the user does not enter a command after a
 specified period of time. This might be a useful security feature for
 </table>
 </center>
 <p>
 <hr size=5>
-<a name="menu_implentation_chap"><h1>Chapter 3<br>Implementation</h1></a>
+<a name="menu_implentation_chap"><h1>Implementation</h1></a>
 <p>
 Several steps are required in order to implement the Menu Processor on
 your system. The steps are briefly outlined below, detailed
 explanations follow:
 <li> Create the OECN_MENU symbol.
 <li> Use the VMS Install utility to make the Menu Processor a known,
 shared image.
 </ol>
-<a name="installation_head"><h1>3.1 Installation</h1></a>
+<a name="installation_head"><h1>Installation</h1></a>
 <p>
 The Menu Processor uses files from the OECN, MENU and HELP packages.
 Install these packages as usual using OECN_INSTALL. For further
 information about OECN_INSTALL see OECN_INSTALL.DOC in the VAX manager
 documentation directory.
-<a name="logicals_head"><h1>3.2 Establish OECN Logicals</h1></a>
+<a name="logicals_head"><h1>Establish OECN Logicals</h1></a>
 <p>
 Several logicals are used by the Menu Processor to locate the menu
 files and VMS Help libraries. <p>
 <table border=3>
-<caption><a name="logicals_tab"><strong>Table 3-1 Menu Logicals</strong></a></caption>
+<caption><a name="logicals_tab"><strong> Menu Logicals</strong></a></caption>
 <tr>
 <th align=center>Logical </th>
 <th align=center>Purpose </th>
 </tr>
 <tr>
 OECN$MENU$FILES and OECN$HELP must be defined in either the SYSTARTUP
 or individual LOGIN.COM files. These logicals may be defined at the
 system, group or process level. For example, the OECN$MENU logical may
 be defined for each user to provide a different default menu.
-<a name="behavior_logical"><h2>3.2.1 Specifying options with OECN$MENU_BEHAVIOR logical</h2></a>
+<a name="behavior_logical"><h2>Specifying options with OECN$MENU_BEHAVIOR logical</h2></a>
 <p>
 This section describes the commands that may be placed in the
 OECN$BEHAVIOR logical. The syntax for the logical definition is:
 multiple commands are specified they must be separated by commas (,).
 This logical can be defined at the system, group, job or process level.
 <p>
 <table border=3>
-<caption><a name="Table_3-2"><strong>Table 3-2 Behavior Options</strong></a></caption>
+<caption><a name="Table_3-2"><strong> Behavior Options</strong></a></caption>
 <tr>
 <th align=center>Command </th>
 <th align=center>Description </th>
 </tr>
 <tr>
 <pre>
 $ DEFINE/SYSTEM OECN$MENU_BEHAVIOR "SPAWN,TIMEOUT=30"
 </pre>
 </table>
-<a name="move_files_head"><h1>3.3 Move Files to Appropriate Directories</h1></a>
+<a name="move_files_head"><h1>Move Files to Appropriate Directories</h1></a>
 <p>
 Move the menu files (OECN$ROOT:[MENU.DIST]*.DAT) to the directory
 referenced by OECN$MENU$FILES.
 </blockquote>
 <p>
 The users must have execute access to these files.
-<a name="add_symbol_head"><h1>3.4 Add Global Symbol</h1></a>
+<a name="add_symbol_head"><h1>Add Global Symbol</h1></a>
 <p>
 Add the following symbol to either your SYLOGIN.COM or each user's
 LOGIN.COM who will be using the system:
 This creates a foreign command that the OECN_MENU.COM procedure uses to
 invoke the Menu Processor. Other symbols may be necessary to make it
 easier for your users to invoke a menu. These symbols will be discussed
 in the <a href="oecn10_sysman_handbook_full.html#invoking_chap">Chapter 4, Invoking the Menu Processor</a>. The OECN_MENU symbol is the only required symbol.
-<a name="install_head"><h1>3.5 Install the Menu Processor</h1></a>
+<a name="install_head"><h1>Install the Menu Processor</h1></a>
 <p>
 Although it is not necessary for proper execution of the Menu
 Processor, it is <strong>strongly</strong> recommended that you install
 the Menu Processor as a known image.
 </pre>
 </table>
 <p>
 <hr size=5>
-<a name="invoking_chap"><h1>Chapter 4<br>Invoking the Menu Processor</h1></a>
+<a name="invoking_chap"><h1>Invoking the Menu Processor</h1></a>
 <p>
 The Menu Processor must be invoked via a command procedure that is
 provided as part of the OECN package. The Menu Processor depends on
 this command procedure to perform several vital functions and to
 <p>
 This command may be defined in a global symbol, invoked from a captive
 login procedure or from inside another procedure. No restrictions are
 placed on the method of invoking the Menu Processor.
-<a name="invoke_example_head"><h1>4.1 Examples</h1></a>
+<a name="invoke_example_head"><h1>Examples</h1></a>
 <p>
 For most users the following symbol definition is sufficient:
 <p>
 not restrict the user to the PAY_MENU, it just starts them out in that
 menu.
 <p>
 <hr size=5>
-<a name="modifying_menus_chap"><h1>Chapter 5<br>Modifying and Creating Menu Systems</h1></a>
+<a name="modifying_menus_chap"><h1>Modifying and Creating Menu Systems</h1></a>
 <p>
 The MENUEDT program is a fully functional maintenance program for
 modifying and creating menu files. Another program, MENUUTL, provides
 several necessary and useful utilities when manipulating the files,
 such as building the alias file and reporting functions. <p>
 <table border=3>
-<caption><a name="menu_type_tab"><strong>Table 5-1 Menu Record Types</strong></a></caption>
+<caption><a name="menu_type_tab"><strong> Menu Record Types</strong></a></caption>
 <tr>
 <th align=center>Record Type </th>
 <th align=center>Function </th>
 </tr>
 <tr>
 what the runtime environment will be for the menu file. Thus, very
 little error checking is performed or even attempted. This means that
 menus that you modify or create should be tested thoroughly before
 being made available to your users.
-<a name="using_edt_head"><h1>5.1 Using MENUEDT</h1></a>
+<a name="using_edt_head"><h1>Using MENUEDT</h1></a>
 <p>
 When you first run the MENUEDT program it will prompt you for the name
 of the menu file to modify. If the file does not exist it will be
 created. <p>
 <table border=3>
-<caption><a name="edt_options_tab"><strong>Table 5-2 MENUEDT Main Menu Options</strong></a></caption>
+<caption><a name="edt_options_tab"><strong> MENUEDT Main Menu Options</strong></a></caption>
 <tr>
 <th align=center>Option </th>
 <th align=center>Function </th>
 </tr>
 <tr>
 Exits MENUEDT.
 </td>
 </tr>
 </table>
-<a name="menu_type_head"><h2>5.1.1 Menu File Record Types</h2></a>
+<a name="menu_type_head"><h2>Menu File Record Types</h2></a>
 <p>
 This section and the following sections show sample screens that are
 used by MENUEDT to modify the various record types. After each screen
 is a detailed explanation of each field and its purpose.
-<a name="file_header_head"><h2>5.1.2 File Header Record</h2></a>
+<a name="file_header_head"><h2>File Header Record</h2></a>
 <p>
 The first record in each menu file must be a File Header record and
 each file must contain exactly one Header record.
 </table>
 <p>
 <table border=3>
-<caption><a name="file_header_fld_tab"><strong>Table 5-3 File Header Record Fields</strong></a></caption>
+<caption><a name="file_header_fld_tab"><strong> File Header Record Fields</strong></a></caption>
 <tr>
 <th align=center>Field </th>
 <th align=center>Description </th>
 </tr>
 <tr>
 information about security identifiers.
 </td>
 </tr>
 </table>
-<a name="menu_header_head"><h2>5.1.3 Menu Header Record</h2></a>
+<a name="menu_header_head"><h2>Menu Header Record</h2></a>
 <p>
 The Menu Header record contains information about each menu in the
 file. There must be exactly one Header record for each menu contained
 in the file.
 </table>
 <p>
 <table border=3>
-<caption><a name="menu_header_fld_tab"><strong>Table 5-4 Menu Header Fields</strong></a></caption>
+<caption><a name="menu_header_fld_tab"><strong> Menu Header Fields</strong></a></caption>
 <tr>
 <th align=center>field </th>
 <th align=center>Description </th>
 </tr>
 <tr>
 security identifiers.
 </td>
 </tr>
 </table>
-<a name="menu_item_head"><h2>5.1.4 Menu Item Record</h2></a>
+<a name="menu_item_head"><h2>Menu Item Record</h2></a>
 <p>
 One menu item record must be specified for each desired item on a menu.
 A menu can contain a maximum of 50 item records. If there are less than
 8 items then the menu will be double spaced, otherwise the menu will be
 Action field is determined by the Item Type field. The four possible
 types and the meaning of the Action field are defined in <a href="oecn10_sysman_handbook_full.html#item_types_tab">Table 5-5</a>.
 <p>
 <table border=3>
-<caption><a name="item_types_tab"><strong>Table 5-5 Menu Item Types</strong></a></caption>
+<caption><a name="item_types_tab"><strong> Menu Item Types</strong></a></caption>
 <tr>
 <th align=center>Item Type </th>
 <th align=center>Interpretation of Action Field </th>
 </tr>
 <tr>
 </table>
 <p>
 <table border=3>
-<caption><a name="menu_item_tab"><strong>Table 5-6 Menu Item Fields</strong></a></caption>
+<caption><a name="menu_item_tab"><strong> Menu Item Fields</strong></a></caption>
 <tr>
 <th align=center>Field </th>
 <th align=center>Description </th>
 </tr>
 <tr>
 <sup>1</sup>Key fields of the menu file. However the MENUEDT program
 allows these fields to be changed.
 <br>
 <hr>
-<a name="action_values_head"><h3>5.1.4.1 Values for Action Field</h3></a>
+<a name="action_values_head"><h3>Values for Action Field</h3></a>
 <p>
 Much of the Menu Processor's flexibility is provided by the values that
 may be placed in the Action field. The Action field and the Item Type
 field together determine what will happen when the user chooses an item
 If Type = "T" then the action line is ignored. Text items are used to
 put information or subheadings on a menu. For text items, the
 Description field is simply displayed on the menu without a label or an
 option number.
-<a name="secur_id_screen_head"><h2>5.1.5 Menu Security Screen</h2></a>
+<a name="secur_id_screen_head"><h2>Menu Security Screen</h2></a>
 <p>
 The <strong>Modify Security Identifier</strong> screen allows you to
 require that the user has specific VMS identifiers before they are
 allowed access to certain menu elements.
 <p>
 If four identifiers are not enough for your site, you may add new ones.
 Up to 16 identifier positions have been reserved for use at the A-site
 level. See OECN_IDS.LIB in OECN$LIB: for instructions.
-<a name="security_ids"><h3>5.1.5.1 Security Identifiers</h3></a>
+<a name="security_ids"><h3>Security Identifiers</h3></a>
 <p>
 The security identifiers that appear on the Security Identifier screen
 are the &quot;standard&quot; identifiers. Three possible identifiers
 exist for each standard identifier, which are used to specify three
 <p>
 The following table lists the three access levels, in order of lowest
 level access to the highest. <p>
 <table border=3>
-<caption><a name="security_level_tbl"><strong>Table 5-7 Security Access Levels</strong></a></caption>
+<caption><a name="security_level_tbl"><strong> Security Access Levels</strong></a></caption>
 <tr>
 <th align=center>Access Level </th>
 <th align=center>Suffix </th>
 <th align=center>Description </th>
 </tr>
 <p>
 It also should be noted that the access levels will be applied to the
 A-site specific identifiers. That is, there will also be OECN_USER1_RO
 and OECN_USER1_GM identifiers available for use at the A-site level.
-<a name="menuutl_head"><h1>5.2 Using MENUUTL</h1></a>
+<a name="menuutl_head"><h1>Using MENUUTL</h1></a>
 <p>
 The MENUUTL program provides some necessary functions for building,
 maintaining and documenting a menu system. The options provided are:
 <li>Simulated Menu Listing
 <li>Detailed Menu Report
 <li>Hierarchical Menu Listing
 </ol>
-<a name="build_alias_head"><h2>5.2.1 Building the Alias File</h2></a>
+<a name="build_alias_head"><h2>Building the Alias File</h2></a>
 <p>
 The first and the most important option of MENUUTL is the alias file
 build option. The alias file contains a pointer for each menu item in
 the system. Therefore, whenever you add or remove menu items from a
 that the alias file is always up-to-date. </td>
 </tr>
 </table>
 </center>
-<a name="simulate_list_head"><h2>5.2.2 Simulated Menu Listing</h2></a>
+<a name="simulate_list_head"><h2>Simulated Menu Listing</h2></a>
 <p>
 This option will read through the specified menu file and create a
 simulated menu listing. The listing will display the menu in as close
 an approximation as possible on a hardcopy printer. The option will
 only report on one menu file at a time and will be sorted in
 alphabetical order by menu name.
-<a name="detailed_list_head"><h2>5.2.3 Detailed Menu Listing</h2></a>
+<a name="detailed_list_head"><h2>Detailed Menu Listing</h2></a>
 <p>
 The detailed menu report lists all available information about the
 specified menu file. This report is particularly useful for double
 checking the action fields and security.
-<a name="hier_list_head"><h2>5.2.4 Hierarchical Listing</h2></a>
+<a name="hier_list_head"><h2>Hierarchical Listing</h2></a>
 <p>
 This report will display the structure of the menu system. The menus
 are listed in the proper order as they appear on the menu. This option
 will prompt for the top level menu file and menu where the listing is
 to start. You need not necessarily start at the top of the entire menu
 system.
-<a name="osa_head"><h1>5.3 OSA</h1></a>
+<a name="osa_head"><h1>OSA</h1></a>
 <p>
 The OSA, OECN Security Authorization, Utility may be used in
 conjunction with the OECN Menu Processor to fine tune security access.
 OSA can be used to enable user's access to individual programs to be
 A-site and is maintained separately from the menu system included on
 the OECN distribution. (See also VMS Manager's Guide)
 <p>
 <hr size=5>
-<a name="custom_chap"><h1>Chapter 6<br>Customizing Menus from the Distribution</h1></a>
+<a name="custom_chap"><h1>Customizing Menus from the Distribution</h1></a>
 <p>
 This chapter describes the recommended procedure for customizing the
 menu files from the distribution. Following this procedure will ensure
 that you can install future releases with minimum effort and maintain a
 manual for information about the OSA utility and local security. </td>
 </tr>
 </table>
 </center>
-<a name="local_head"><h1>6.1 Modifying a Local Menu File</h1></a>
+<a name="local_head"><h1>Modifying a Local Menu File</h1></a>
 <p>
 Following is the recommend procedure for modifying one or more menu
 files.
 <li>Modify the Menu Files
 <li>Build a New Alias File
 <li>Redefine OECN$MENU$FILES permanently
 </ol>
-<a name="redefine_logical_head"><h2>6.1.1 Redefine the OECN$MENU$FILES logical</h2></a>
+<a name="redefine_logical_head"><h2>Redefine the OECN$MENU$FILES logical</h2></a>
 <p>
 The first step is to redefine OECN$MENU$FILES as a search list. For
 consistency with other customized files, it is recommended that you use
 OECN$CUSTOM. However, you may use any directory that you wish. The rest
 will prevent any users from getting into a half completed menu. </td>
 </tr>
 </table>
 </center>
-<a name="heading_6.1.2"><h2>6.1.2 Modify the Menu Files</h2></a>
+<a name="heading_6.1.2"><h2>Modify the Menu Files</h2></a>
 <p>
 Copy the *_LCL.DAT menu files that you want to modify from the
 distribution into OECN$CUSTOM. Then use MENUEDT to make the desired
 modifications. By making all modifications in OECN$CUSTOM: will insure
 <p>
 Use the Menu Processor and MENUUTL to test the new menus as needed. If
 you're creating new menus, be sure that the users have read access to
 the new files.
-<a name="heading_6.1.3"><h2>6.1.3 Build a New Alias File</h2></a>
+<a name="heading_6.1.3"><h2>Build a New Alias File</h2></a>
 <p>
 After all desired changes have been made, use MENUUTL to rebuild the
 alias file. You may put the alias file in OECN$CUSTOM or simply replace
 the current alias file in OECN$ALIAS. If you change the location of the
 <p>
 You may build the alias file manually by running MENUUTL, or you may
 use the BUILD_ALIAS.COM procedure in the OECN$ directory.
-<a name="heading_6.1.4"><h2>6.1.4 Redefine OECN$MENU$FILES Permanently</h2></a>
+<a name="heading_6.1.4"><h2>Redefine OECN$MENU$FILES Permanently</h2></a>
 <p>
 If you have not already done so, define the logical OECN$MENU$FILES to
 be a search list as above at the SYSTEM level.
 <p>
 At this point your users should have access to the customized menus.
-<a name="heading_6.2"><h1>6.2 After a Distribution</h1></a>
+<a name="heading_6.2"><h1>After a Distribution</h1></a>
 <p>
 If you modify the local menu files in this way, your changes will not
 be affected by any future releases. Changes made by SSDT will
 automatically be installed when you copy the distribution menu files to
 have other menu systems on your system, you can pass parameters to
 BUILD_ALIAS to indicate the location and names of the menu and alias
 files. See the comments in BUILD_ALIAS.COM for more information about
 using this procedure.
-<a name="intercept_head"><h1>6.3 Intercepting Menu Actions</h1></a>
+<a name="intercept_head"><h1>Intercepting Menu Actions</h1></a>
 <p>
 Sometimes it is desirable, or necessary, to redefine the action
 associated with a menu item. For instance, you may want to force
 certain actions prior to running a particular program or force certain
 </pre>
 </table>
 <p>
 <hr size=5>
-<a name="batch_mail_chap"><h1>Chapter 7<br>Batch Mail Message System Manager  Guide</h1></a>
+<a name="batch_mail_chap"><h1>Batch Mail Message System Manager  Guide</h1></a>
-<a name="heading_7.1"><h1>7.1 Overview</h1></a>
+<a name="heading_7.1"><h1>Overview</h1></a>
 <p>
 The command procedure BATCH_MAIL_MESSAGE.COM can be used to send a VMS
 mail message via a batch job. This is useful for messages with large
 audiences where the user does not wish to tie up their terminal for an
 extended period of time.
-<a name="heading_7.2"><h1>7.2 Sending a Mail Message via Batch</h1></a>
+<a name="heading_7.2"><h1>Sending a Mail Message via Batch</h1></a>
 <p>
 To use the command procedure for generic mail messages:
 <p>
 </ul>
 <p>
 <hr size=5>
-<a name="oecn_view_chap"><h1>Chapter 8<br>OECN VIEW Utility</h1></a>
+<a name="oecn_view_chap"><h1>OECN VIEW Utility</h1></a>
-<a name="heading_8.1"><h1>8.1 Overview</h1></a>
+<a name="heading_8.1"><h1>Overview</h1></a>
 <p>
 The OECN_VIEW utility allows users to view text files on the screen. It
 can be used for report files produced by OECN state software or other
 text documents. OECN_VIEW is a TPU based product, layered on DEC/EVE.
 Each entry in the search list must refer to OECN_VIEW_DIRECTORY.
 <p>
 Examples of the logicals are given below:
-<a name="heading_8.2"><h1>8.2 OECN_VIEW.COM</h1></a>
+<a name="heading_8.2"><h1>OECN_VIEW.COM</h1></a>
 <p>
 The OECN_VIEW.COM command procedure is found in OECN$. It is used to
 define the two logicals, OECN_VIEW_DIRECTORY and OECN_VIEW_FILES.
 Observe the following notes from this procedure.
 </pre>
 </table>
-<a name="heading_8.2.1"><h2>8.2.1 Customizing OECN VIEW</h2></a>
+<a name="heading_8.2.1"><h2>Customizing OECN VIEW</h2></a>
 <p>
 The following sample command file shows how to customize the
 directories and the file extensions to be viewed.
 </pre>
 </table>
-<a name="heading_8.2.2"><h2>8.2.2 Creating a DCL Command</h2></a>
+<a name="heading_8.2.2"><h2>Creating a DCL Command</h2></a>
 <p>
 The VIEW utility works automatically from the MENU. However, you could
 define a symbol to execute VIEW from DCL.
 </table>
 <p>
 Then use the LOOK command from the $ prompt.
-<a name="heading_8.2.3"><h2>8.2.3 OECN_EDIT</h2></a>
+<a name="heading_8.2.3"><h2>OECN_EDIT</h2></a>
 <p>
 The OECN_VIEW utility uses a special editor called OECN_EDIT. Its
 purpose is to provide I/O routines to allow TPU to automatically read
 and translate VFC files into text. Please see <a href="oecn10_sysman_handbook_full.html#oecn_edit_chap">Chapter 9, OECN EDIT Utility</a>, for more
 details.
 <p>
 <hr size=5>
-<a name="oecn_edit_chap"><h1>Chapter 9<br>OECN EDIT Utility</h1></a>
+<a name="oecn_edit_chap"><h1>OECN EDIT Utility</h1></a>
-<a name="heading_9.1"><h1>9.1 Overview</h1></a>
+<a name="heading_9.1"><h1>Overview</h1></a>
 <p>
 OECN_EDIT is a foreign command replacement for the EDIT/TPU DCL
 command. It is completely command line (qualifier and parameter)
 compatible with EDIT/TPU. Its purpose is to provide I/O routines to
 This is different from the default TPU editor, which ignores VFC
 formatting. OECN_EDIT is used by the OECN_VIEW.COM procedure to allow
 VFC files to be viewed correctly. However, it may also be used with any
 TPU section file as an editor.
-<a name="heading_9.2"><h1>9.2 Using OECN_EDIT</h1></a>
+<a name="heading_9.2"><h1>Using OECN_EDIT</h1></a>
 <p>
 In order to use OECN_EDIT as your interface to TPU, define the
 following symbol:
 EDIT/TPU, such as /SECTION, /UNIT, etc. OECN_EDIT will use the normal
 EVE section and initialization files by default.
 <p>
 <hr size=5>
-<a name="oecn_keymap_chap"><h1>Chapter 10<br>OECN KEYMAP Utility</h1></a>
+<a name="oecn_keymap_chap"><h1>OECN KEYMAP Utility</h1></a>
-<a name="heading_10.1"><h1>10.1 Overview</h1></a>
+<a name="heading_10.1"><h1>Overview</h1></a>
 <p>
 The OECN_KEYMAP utility allows users to select a terminal emulator,
 such as REFLECTIONS, EXCURSIONS, or PERSONA. Using this utility defines
 the logical OECN$KEY_MAP to point to a .INI file containing the desired
 keys. That is, from the programs point of view, the user is required to
 press a VT200 F11 for the "Find" function. However, you can assign F11
 to any PC key you wish in the emulator and then relabel F11 on the
 screen to match the PC keyboard.
-<a name="heading_10.2"><h1>10.2 Using KEYMAP</h1></a>
+<a name="heading_10.2"><h1>Using KEYMAP</h1></a>
 <p>
 Upon selecting the KEYMAP option from the OECN menu the user is given a
 list of keymapping options to select from. This menu of options is
 built by searching for all files named OECN$KEYMAP*.INI in either the
 to something meaningful to the user as this is what they will see in
 the KEYMAP menu.
 <p>
 <hr size=5>
-<a name="oecn_setupenv_chap"><h1>Chapter 11<br>OECN SETUPENV Utility</h1></a>
+<a name="oecn_setupenv_chap"><h1>OECN SETUPENV Utility</h1></a>
-<a name="heading_11.1"><h1>11.1 Overview</h1></a>
+<a name="heading_11.1"><h1>Overview</h1></a>
 <p>
 SETUPENV is a general purpose utility for establishing or switching to
 user environments. The goal of the utility is to provide a single place
 to configure the software environment (primarily logicals) for given
 ability to find and establish contexts.
 <li>To provide support for common OpenVMS configuration methods in use
 by DA Sites, including group tables and shared logical tables.
 </ol>
-<a name="heading_11.2"><h1>11.2 Getting Started</h1></a>
+<a name="heading_11.2"><h1>Getting Started</h1></a>
 <p>
 The SETUPENV utility is very flexible allowing the capability to deal
 with the variety of possible setups in use at the OECN DA Sites. This
 flexibility leads to a significant number of options in both the DCL
 To get started with SETUPENV it is recommended that a simple OECN$SETUP
 file with a minimal set of options for just a few entities be created.
 Starting small will give the opportunity to experiment with the utility
 to see how, or if, it can fit into your environment.
-<a name="heading_11.2.1"><h2>11.2.1 Entity Types</h2></a>
+<a name="heading_11.2.1"><h2>Entity Types</h2></a>
 <p>
 SETUPENV manages a user's context by assuming that any given process
 will have one context in each of the four entity "types". The current
 types of entities are:
 switched automatically. SETUPENV can handle these relationships using
 the PARENT attribute in the OECN$SETUP file. Please refer to the PARENT
 attribute for more information.
 <p>
-<a name="heading_11.2.2"><h2>11.2.2 DCL Command Syntax</h2></a>
+<a name="heading_11.2.2"><h2>DCL Command Syntax</h2></a>
 <br>
 <p>
 SETUPENV must be defined as a foreign command:
 <br>
 <p>
 Likewise, when /EMIS is specified, EMIS_SELECT_EPILOGUE and
 EMIS_SWITCH_FY will be invoked after successfully selecting a database.
-<a name="heading_11.3"><h1>11.3 Logicals Created By SETUPENV</h1></a>
+<a name="heading_11.3"><h1>Logicals Created By SETUPENV</h1></a>
 <p>
 After successfully selecting an entry, SETUPENV establishes a series of
 logicals (OECN$SETUP_*) to describe the current context and to maintain
 it's own context for subsequent invocations of SETUPENV. These logicals
 <p>
 Any of the logicals that do not apply to an entry will not be defined
 (e.g. for a parent entry, the siblings logical will not be defined).
-<a name="heading_11.4"><h1>11.4 OECN$SETUP.INI</h1></a>
+<a name="heading_11.4"><h1>OECN$SETUP.INI</h1></a>
 <p>
 The OECN$SETUP initialization file defines the environment for various
 entities which use OECN (or other) software products. The default
 filename is OECN$CUSTOM:OECN$SETUP.INI. OECN$SETUP may be defined as a
 </tr>
 </table>
 </center>
 </ul>
-<a name="heading_11.4.1"><h2>11.4.1 Special "Reset" Entries</h2></a>
+<a name="heading_11.4.1"><h2>Special "Reset" Entries</h2></a>
 <p>
 Prior to setting any given entry, SETUPENV will attempt to process
 special sections named "$RESET_type". If a $RESET section of the
 appropriate type exists in the INI file, it will be processed prior to
 The above entry would cause SETUPENV to deassign OECN$DTA and define
 OECN$OUT to the default directory prior to setting any valid entry. In
 general, you should explicitly deassign any logicals in the reset
 section that are defined in any entry of the same type.
-<a name="heading_11.4.2"><h2>11.4.2 Sample OECN$SETUP File</h2></a>
+<a name="heading_11.4.2"><h2>Sample OECN$SETUP File</h2></a>
 <p>
 Below is a very simple OECN$SETUP.INI file which defines entries for
 one district and two buildings. The setup file can contain many such
 entries for as many districts and buildings provided that the entry
 <p>
 The special $RESET_DISTRICT section is provided to ensure that the
 district logical get reset appropriately prior to setting an entry.
-<a name="heading_11.4.3"><h2>11.4.3 Special "APPLICATION" Entries</h2></a>
+<a name="heading_11.4.3"><h2>Special "APPLICATION" Entries</h2></a>
 <p>
 If an entry is defined with one or more APPLICATION attributes, then
 SETUPENV will search for an entry named "$APP_app", where "app" is the
 application code. This allows logicals, symbols or tables that are
 <p>
 Application entries do not have a corresponding "reset" section.
 Logicals defined in this manner may need to be included in the
 appropriate "$RESET_type" section to ensure they are reset.
-<a name="heading_11.4.4"><h2>11.4.4 Special "INCLUDE" Section</h2></a>
+<a name="heading_11.4.4"><h2>Special "INCLUDE" Section</h2></a>
 <p>
 A special section may be specified in any INI file called $INCLUDE.
 This section may specify other INI files to be included and processed
 with the primary INI file. The $INCLUDE section may only contain "FILE"
 processing the next file. Therefore, included INI files will always be
 processed after the file that included it (although perhaps not
 immediately after). In general, you should not depend on files being
 processed in any particular order.
-<a name="heading_11.4.5"><h2>11.4.5 Limits</h2></a>
+<a name="heading_11.4.5"><h2>Limits</h2></a>
 <p>
 Certain limits which apply to the OECN$SETUP.INI file are shown in the
 table below. Limits are 'per entry' unless otherwise noted. <p>
 <table border=3>
-<caption><a name="Table_11-1"><strong>Table 11-1 wide</strong></a></caption>
+<caption><a name="Table_11-1"><strong> wide</strong></a></caption>
 <tr>
 <th align=center>Attribute </th>
 <th align=center>Maximum Length </th>
 <th align=center>Limit </th>
 </tr>
 logicals or symbols may exhaust virtual memory. </td>
 </tr>
 </table>
 </center>
-<a name="heading_11.5"><h1>11.5 EMIS_SELECT Compatibility</h1></a>
+<a name="heading_11.5"><h1>EMIS_SELECT Compatibility</h1></a>
 <p>
 The /EMIS qualifier provides functional compatibility with the
 EMIS_SELECT.COM procedure. In this mode, SETUPENV will read the
 existing OECN$EMIS_DBS file and convert it to equivalent setup entries.
 work around. </td>
 </tr>
 </table>
 </center>
-<a name="heading_11.5.1"><h2>11.5.1 Converting OECN$EMIS_DBS to OECN$SETUP</h2></a>
+<a name="heading_11.5.1"><h2>Converting OECN$EMIS_DBS to OECN$SETUP</h2></a>
 <p>
 It is possible to completely convert from using the OECN$EMIS_DBS file
 to corresponding entries in OECN$SETUP.INI. To do so, simply create
 sections in the OECN$SETUP file as shown in the previous section. The
 instead of the current DCL procedure. </td>
 </tr>
 </table>
 </center>
-<a name="heading_11.6"><h1>11.6 NOACSC Compatiblity</h1></a>
+<a name="heading_11.6"><h1>NOACSC Compatiblity</h1></a>
 <p>
 SETUPENV is similar to the USE, BUNNY, and FROG utilities provided by
 NOACSC. In some respects SETUPENV is based on these utilities. While
 SETUPENV is not 100% compatible with these utilities, it does attempt
 <p>
 This should allow SETUPENV to be used without modifying any existing
 command procedures.
-<a name="heading_11.6.1"><h2>11.6.1 USE Compatibliity</h2></a>
+<a name="heading_11.6.1"><h2>USE Compatibliity</h2></a>
 <p>
 If /USE is specified as the first qualifier to SETUPENV, then the
 original USE qualifiers are accepted. The table below lists the USE
 qualifiers and the corresponding qualifier/behavor for SETUPENV.
 </pre>
 </table>
 </ul>
-<a name="heading_11.6.2"><h2>11.6.2 BUNNY Compatibility</h2></a>
+<a name="heading_11.6.2"><h2>BUNNY Compatibility</h2></a>
 <p>
 If /BUNNY is specified as the first qualifier to SETUPENV, then the
 original BUNNY qualifiers are accepted.
 to set an entry based on the value of an existing logical.
 <li>If /ARCHIVE is specified without a value, the default is the first
 ARCHIVE attribute for the selected entry.
 </ul>
-<a name="heading_11.6.3"><h2>11.6.3 FROG Compatibility</h2></a>
+<a name="heading_11.6.3"><h2>FROG Compatibility</h2></a>
 <p>
 If /FROG is specified as the first qualifier to SETUPENV, then the
 original FROG qualifiers are accepted.
 global procedure.
 </ul>
 <p>
-<a name="heading_11.7"><h1>11.7 OECN$SETUPENV API</h1></a>
+<a name="heading_11.7"><h1>OECN$SETUPENV API</h1></a>
 SETUPENV provides a callable API which can be used by programs to
 select entries. The API parallels the qualifier functions and syntax.
-<a name="heading_11.7.1"><h2>11.7.1 Working Storage Field(s)</h2></a>
+<a name="heading_11.7.1"><h2>Working Storage Field(s)</h2></a>
 <p>
 <center>
 <table border=0 width=75%>
 <tr>
 </pre>
 </table>
 <p>
-<a name="heading_11.7.2"><h2>11.7.2 COBOL Call Arguments</h2></a>
+<a name="heading_11.7.2"><h2>COBOL Call Arguments</h2></a>
 <table border=0>
 <tr>
 <td>
 <br>
 is, the caller should explictly include the OMITTED keyword. </td>
 </tr>
 </table>
 </center>
-<a name="heading_11.7.3"><h2>11.7.3 Argument Descriptions:</h2></a>
+<a name="heading_11.7.3"><h2>Argument Descriptions:</h2></a>
 <blockquote>
 <strong>WS-FUNCTION (read)</strong>
 <blockquote>
 <blockquote>
 Contains code of archive if one was selected.
 </blockquote>
 </blockquote>
-<a name="heading_11.7.4"><h2>11.7.4 Return Status</h2></a>
+<a name="heading_11.7.4"><h2>Return Status</h2></a>
 <p>
 OECN$SETUP returns one of the following conditions:
 <table border=3>
 specify a starting entry or valid select type.
 </td>
 </tr>
 </table>
-<a name="heading_11.7.5"><h2>11.7.5 Description</h2></a>
+<a name="heading_11.7.5"><h2>Description</h2></a>
 <p>
 The OECN$SETUPENV routine does basically everything that the SETUPENV
 DCL interface does; however, there are some notable exceptions. Here is
 a list that the callable interface does NOT provide:
 </ol>
 <p>
 <hr size=5>
-<a name="sysman_ump_chap"><h1>Chapter 12<br>Installing and Using UMP - User Mail Profile  System</h1></a>
+<a name="sysman_ump_chap"><h1>Installing and Using UMP - User Mail Profile  System</h1></a>
-<a name="heading_12.1"><h1>12.1 Overview</h1></a>
+<a name="heading_12.1"><h1>Overview</h1></a>
 <p>
 The UMP package provides a means for DA-sites to maintain user e-mail
 profiles in a standard way. This will provides an efficient means of
 sending mail to a large variety of users across the state. It will also
 allows for the creation of an electronic "white pages phone directory"
 which permits an easy way to lookup an e-mail address for any user on
 the OECN network.
-<a name="heading_12.1.1"><h2>12.1.1 Feature List</h2></a>
+<a name="heading_12.1.1"><h2>Feature List</h2></a>
 <p>
 UMP provides the following features:
 <ul>
 <li>Tracks whether the user has modified/updated their own profile.
 Optionally, users who have not updated their own profile will be asked
 if they wish to update their user mail profile during login.
 </ul>
-<a name="heading_12.1.2"><h2>12.1.2 Web Attachments for OECN state-wide mail</h2></a>
+<a name="heading_12.1.2"><h2>Web Attachments for OECN state-wide mail</h2></a>
 <p>
 A special feature of the OECN state-wide lists is the ability to
 "web-ify" attachments send to the OECN lists. As messages addressed to
 the OECN lists pass through the central OECN mail server, they are
 attachments for their users. Converting existing users to web
 attachments may cause confusion or concerns. Therefore, DA Sites are
 encouraged not to switch existing users to web attachments without
 training or notification.
-<a name="heading_12.1.2.1"><h3>12.1.2.1 Enabling Web Attachments</h3></a>
+<a name="heading_12.1.2.1"><h3>Enabling Web Attachments</h3></a>
 <p>
 Web attachments are only enabled for each DA Site upon request. If you
 wish your users to have the ability to request web attachments, you
 must set ENABLE_OECN_WEBATTACH to "YES" and send mail to
 set for your domain. If this parameter is set, then web attachments are
 already enabled. Note: You can not change OECN$UMP_STANDARD.INI
 yourself. Only the OECN listmaster can make the change that affects the
 OECN mail server.
-<a name="heading_12.1.3"><h2>12.1.3 Files</h2></a>
+<a name="heading_12.1.3"><h2>Files</h2></a>
 <p>
 The following sections describe the files used and produced by the UMP
 system.
 <p>
 database.
 </td>
 </tr>
 </table>
-<a name="heading_12.2"><h1>12.2 UMP Menu and Profile Screen</h1></a>
+<a name="heading_12.2"><h1>UMP Menu and Profile Screen</h1></a>
 <p>
 The program may be executed by typing:
 <p>
 </pre>
 </table>
-<a name="heading_12.3"><h1>12.3 Startup Procedure</h1></a>
+<a name="heading_12.3"><h1>Startup Procedure</h1></a>
 <p>
 Follow the steps below to install UMP on your system:
 <ol start=1 >
 protections on the *.IDX files to W:RW.
 </ol>
 <p>
-<a name="heading_12.4"><h1>12.4 Loading Initial Data</h1></a>
+<a name="heading_12.4"><h1>Loading Initial Data</h1></a>
 Load existing distribution lists. If using NM style distribution lists,
 then use:
 <br>
 $ @OECN$:IMPORT_NM_LISTS
 Unique usernames will only be added once, and a user will not be
 assigned to the same list more than once. Running both imports
 essentially "merges" the NM and PMDF lists. This might be useful if you
 are uncertain which of your lists is more correct.
-<a name="heading_12.5"><h1>12.5 Importing Other Lists</h1></a>
+<a name="heading_12.5"><h1>Importing Other Lists</h1></a>
 <p>
 The IMPORT_NM_LISTS.COM and IMPORT_PMDF_LISTS.COM only import the
 standard NM lists or lists created by SWOCA's OECN$MAIL utilities. If
 you have other local lists which contain users you want to assign to a
 OECN$UMP_LOCAL.INI. The final parameter is the file to import. See
 either IMPORT_NM_LISTS.COM or IMPORT_PMDF_LISTS.COM for examples of
 using UMPIMPORT.EXE.
 <p>
-<a name="heading_12.6"><h1>12.6 INI File Commands</h1></a>
+<a name="heading_12.6"><h1>INI File Commands</h1></a>
 The following INI commands are used in either the OECN$UMP_LOCAL.INI or
 the OECN$UMP_STANDARD.INI files. The following is a summary of these
 commands. See either of these files for more examples of their use. <p>
 <table border=3>
-<caption><a name="Table_12-1"><strong>Table 12-1 Table of INI File Commands</strong></a></caption>
+<caption><a name="Table_12-1"><strong> Table of INI File Commands</strong></a></caption>
 <tr>
 <th align=center>&nbsp;</th>
 <th align=center>Command </th>
 <th align=center>&nbsp;</th>
 <th align=center>Fields </th>
 * This command can appear at most one time in the Local INI file.
 </blockquote>
 <hr>
 <p>
-<a name="heading_12.7"><h1>12.7 Export NM and PMDF Style Lists</h1></a>
+<a name="heading_12.7"><h1>Export NM and PMDF Style Lists</h1></a>
 A procedure called OECN$:EXPORT_LISTS.COM to is used to create the NM
 and PMDF style distribution lists and associated aliases. It is
 recommended that each DAS write a custom DCL procedure which invokes
 EXPORT_LIST.COM which also contains any local commands to add aliases,
 etc. This procedure should be scheduled to run nightly to keep the
 Alternatively, you can specify the DEFER option in EXPORT_LIST and
 write procedure which adds additional aliases prior to moving the
 databases into PMDF_TABLE:.
 </ul>
-<a name="heading_12.7.1"><h2>12.7.1 Centralized Naming</h2></a>
+<a name="heading_12.7.1"><h2>Centralized Naming</h2></a>
 <p>
 This section describes several ways in which UMP can be used to provide
 centrialized naming in a PMDF configuration. Centralized naming
 provides means to provide stable user email addresses regardless of
 where the users mail is actually being delivered. This section assumes
 you are already familar with the basic concepts of centralized naming
 in PMDF.
-<a name="heading_12.7.1.1"><h3>12.7.1.1 Remote Mail Boxes</h3></a>
+<a name="heading_12.7.1.1"><h3>Remote Mail Boxes</h3></a>
 <p>
 UMP can provide centralized naming for users who have "remote"
 mailboxes. Using UMP's centralized naming, a user can have an address
 such as USER@das.org even if thier mail is being delivered to a
 the appropriate file into either PMDF_ALIAS_DATABASE or your directory
 channel. An address rewritten in this manner will be rewritten back to
 the username or alias on the UMP profile (not the username in the
 mailbox field).
-<a name="heading_12.7.1.2"><h3>12.7.1.2 User Aliases</h3></a>
+<a name="heading_12.7.1.2"><h3>User Aliases</h3></a>
 <p>
 UMP provides the ability to create a user-specific alias independent of
 the username or actual mailbox. For example, a username of
 "SMITH@nwoca.org" could have an alias of "dave.smith@nwoca.org".
 Since the DAS must take additional configuration steps in PMDF to
 implement aliases and address reversal, the 'Alias' and 'From' fields
 are disabled by default. The DAS must take explicit action (see below)
 to implement this feature.
-<a name="heading_12.7.1.2.1"><h4>12.7.1.2.1 Implementing User Aliases</h4></a>
+<a name="heading_12.7.1.2.1"><h4>Implementing User Aliases</h4></a>
 <p>
 The following steps must be performed in order to activate the user
 alias and address reversal using UMP:
 USER_ALIASES.TXT and USER_REVERSE.TXT files to be loaded into the
 appropriate database. See <a href="oecn10_sysman_handbook_full.html#exam_build_proc">Section 12.18, Example Procedure for Periodic Rebuilds</a> for an example procedure which
 invokes EXPORT_LISTS.COM.
 </ol>
-<a name="heading_12.8"><h1>12.8 Distribution List Codes</h1></a>
+<a name="heading_12.8"><h1>Distribution List Codes</h1></a>
 <p>
 Each distribution list code has a "type" prefix. The type value allows
 distribution lists to be organized into subsets independent of the
 list's name and allows restrictions to be placed on lists so users only
 <p>
 This will restrict all type 11 lists to users who are also subscribed
 to the standard DAS staff list.
-<a name="heading_12.9"><h1>12.9 Auto Conversion of Distribution List Codes (Optional)</h1></a>
+<a name="heading_12.9"><h1>Auto Conversion of Distribution List Codes (Optional)</h1></a>
 <p>
 Because of the features provided by the distribution list types, it may
 be desirable for DAS's to change their existing distribution list
 codes. By default, during the conversion, all distribution list codes
 If you are creating locally written programs to update or report on
 user's distribution list codes, it may be confusing to have both the
 old and new codes on file. In this case, you may run the UMPUPDATE
 program to force the conversion on all records.
-<a name="heading_12.10"><h1>12.10 Defining Local Distribution Lists</h1></a>
+<a name="heading_12.10"><h1>Defining Local Distribution Lists</h1></a>
 <p>
 To define a local distribution list, you need to add several additional
 lines to the OECN$UMP_LOCAL.INI file.
 one of these sublists will be delivered to anyone on this list and
 anyone on the master list, but not to users on any of the other
 sublists. Also, mail addressed to the master list will be delivered to
 everyone on any of the sublists.
-<a name="heading_12.11"><h1>12.11 Profile Group Management</h1></a>
+<a name="heading_12.11"><h1>Profile Group Management</h1></a>
 <p>
 UMP provides the ability to segregate profiles into <strong>management
 groups</strong> and delegate responsibility for the groups to selected
 individuals. Once delegated, the group manager has nearly complete
 of the UMP 'Internet Host/Mailbox' field is critical to ensure proper
 mail delivery. Likewise, if the DAS uses the 'User Type' field to
 control which profiles are sent to the OECN White Pages, then the
 correct values must be provided to the group manager.
-<a name="heading_12.12"><h1>12.12 Export DIRECTORY DAEMON File (optional)</h1></a>
+<a name="heading_12.12"><h1>Export DIRECTORY DAEMON File (optional)</h1></a>
 <p>
 You have the option of exporting to a DIRECTORY DAEMON database.
 Executing the EXPORT_DD.COM file will produce a file suitable for
 loading into a PMDF DIRECTORY-DAEMON data file. The procedure only
 <p>
 See the PMDF System Adminstrators Guide for more information about the
 directory daemon, channels and pseudo-domains.
-<a name="heading_12.13"><h1>12.13 Submit UMP Data to OECN CSO Database</h1></a>
+<a name="heading_12.13"><h1>Submit UMP Data to OECN CSO Database</h1></a>
 <p>
 The CSO nameserver is a public domain software system which allows a
 single database to be built containing name and address information.
 The CSO is much flexible and allows client/server access to the
 <p>
 This line would cause all of NWOCA's users to have an email address of
 username@po.nwoca.org regardless of their real host. In this way,
 remote users will not learn the real host name (which may change).
-<a name="heading_12.14"><h1>12.14 Master List/Sub-list Handling</h1></a>
+<a name="heading_12.14"><h1>Master List/Sub-list Handling</h1></a>
 <p>
 Starting with the 29-Aug-95 version of UMPEXPORT, the master lists are
 handled differently than in the past. Previously, there were master
 lists which pointed to the respective sub-lists. But this caused
 will be received by all users who are on the SPT or SJV lists. </td>
 </tr>
 </table>
 </center>
-<a name="heading_12.15"><h1>12.15 UMPCHECK - Verifying UMP Profiles against SYSUAF (Optional)</h1></a>
+<a name="heading_12.15"><h1>UMPCHECK - Verifying UMP Profiles against SYSUAF (Optional)</h1></a>
 <p>
 UMPCHECK is a utility which reads the UMP profiles and compares the
 usernames to the SYSUAF file. It reports usernames which do not exist,
 have been disusered or dismailed. Optionally, UMPCHECK can delete
 The second parameter indicates the node names of the users to be
 validated against the current SYSUAF. By default, the node names used
 are the current values of the SYS$NODE and SYS$CLUSTER_NODE logicals.
 <p>
-<a name="heading_12.16"><h1>12.16 UMP_LOGIN - To Prompt Users to Enter Profiles During Login (Optional)</h1></a>
+<a name="heading_12.16"><h1>UMP_LOGIN - To Prompt Users to Enter Profiles During Login (Optional)</h1></a>
 UMP_LOGIN.COM may be run during login to determine if the user has ever
 modified their own profile. If they have not entered their profile,
 UMP_LOGIN will ask them if they would like to do so immediately and
 place them in the UMP profile.
 <p>
 If you use UMP_LOGIN.COM you may wish to use the VMS INSTALL utility to
 install OECN$:UMPMODIFIED.EXE as a known image to speed up the login
 process.
-<a name="heading_12.17"><h1>12.17 UMPID2DIS - Creating Distribution Lists from VMS Identifiers (Optional)</h1></a>
+<a name="heading_12.17"><h1>UMPID2DIS - Creating Distribution Lists from VMS Identifiers (Optional)</h1></a>
 <p>
 UMPID2DIS.EXE is an optional utility which builds PMDF style
 distribution lists containing all users who hold a specified
 identifier. This may be used by sites who wish to build distribution
 add "nwoca_usps-list" "&lt;oecn$ump:nwoca_usps.dis,*,*,postmaster,*,
 USPS"
 <br>
 $ EXIT
-<a name="exam_build_proc"><h1>12.18 Example Procedure for Periodic Rebuilds</h1></a>
+<a name="exam_build_proc"><h1>Example Procedure for Periodic Rebuilds</h1></a>
 <p>
 Periodically, each site should run EXPORT_LISTS.COM to update the
 distribution lists from the UMP data. Most likely you will want to run
 EXPORT_LISTS nightly. You should also run it anytime that you recreate
 </pre>
 </table>
 <p>
-<a name="heading_12.19"><h1>12.19 Multiple Non-Clustered Systems</h1></a>
+<a name="heading_12.19"><h1>Multiple Non-Clustered Systems</h1></a>
 DAS's with a single VMS system, or a single VMS cluster, need not be
 concerned with this section.
 <p>
 The UMP system is currently designed assuming that each A-site will
 UMP files, and you will end up with a central DAS-wide database to
 build your distribution lists from. The server node will be the only
 one that needs to run the EXPORT_LISTS.COM to produce the mail_ and
 oecn_ for your DAS.
-<a name="heading_12.20"><h1>12.20 Programming Considerations</h1></a>
+<a name="heading_12.20"><h1>Programming Considerations</h1></a>
 <p>
 DAS programmers may wish to use DTR, COBOL or other high level language
 to query or manipulate the UMP data files. This section contains a
 brief description of the UMP data files and special considerations. DTR
 Distribution_list_code
 </td>
 </tr>
 </table>
-<a name="heading_12.20.1"><h2>12.20.1 Field Requirements</h2></a>
+<a name="heading_12.20.1"><h2>Field Requirements</h2></a>
 <p>
 Some fields in UMP may display to the user differently than is
 physically stored in the file. Other fields have specific requirements.
 Please note the following:
 </ul>
 <p>
 <hr size=5>
-<a name="vfc2pdf_chap"><h1>Chapter 13<br>VFC2PDF - Converting Text Files to PDF Format</h1></a>
+<a name="vfc2pdf_chap"><h1>VFC2PDF - Converting Text Files to PDF Format</h1></a>
 <p>
 VFC2PDF converts VFC or plain text files into PDF (Portable Document
 Format) files. After a report is converted to PDF format, it can be
 transferred to a PC or a MAC. It can also be viewed or printed using

Mercurial > public > html2wiki

comparison test/resources/sysman_handbook.html @ 4:22ed6d93442c