Skip to end of metadata
Go to start of metadata


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.

Feature List

UMP provides the following features:

  • Ability to add/modify user profiles.
  • Allows end-user to modify their own profile.
  • Permits 'group managers' to manage other user profiles within their group
  • Imports an existing distribution list and creates a basic user profile (NM or PMDF style distribution lists).
  • Ability to provide complete 'centralized naming' facility for both local and remote addresses, including ability to create user aliases independent of username or mailbox address.
  • Exports user profiles into the following formats:

    • NM
      - PMDF style distribution lists
  • Handles OECN standard distribution lists and allows local
    distribution lists to be added.
  • Includes a utility to create distribution lists based on VMS
  • Includes a utility to check UMP profiles against SYSUAF.
  • Includes a utility to run during login to determine if user has
    modified their own profile.


  • 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.

Web Attachments for OECN state-wide mail

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 inspected for certain attachment types. If a suitable attachment type is discovered, it is placed on a public web site and the original attachment is replaced by a web link (URL) pointing to the documents location. Thus, only a single copy of each attachment must be stored on the OECN web server and will not be delivered to each user's mailbox.

Each user subscribed to UMP has the option of receiving the original message with the attachments or the version containing web links instead of attachments. Most users will benefit from receiving web links instead of attachments (reduced local storage, shorter download times and reduce risk of viruses. However, some users may prefer the original attachments, especially if they download their mail for disconnected (off-line) reading.

The benefit of web attachments to DA Sites can be signficant. Without web attachments, any message containing a large attachment must be delivered to each user's mailbox separately consuming considerable disk space and computer resources to deliver.

However, each DA Site may decide how, and if, to implement OECN web 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.

Enabling Web Attachments

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 The listmaster will verify the correct configuration of your UMP configuration and enable web attachments if appropriate. Your request may be denied if you have a non-standard UMP configuration. In that case, the listmaster will explain the problem(s) with your configuration.

To see if web attachments are enabled for your site, look for the SITE command in OECN$UMP_STANDARD.INI and see if the "webatt" parameter is 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.


The following sections describe the files used and produced by the UMP system.

Files and Procedures Used



File/Procedure Use


Contains A-site specific information and list codes.


Contains OECN_wide list codes and definitions.


Used to import data from NM style distribution lists into user profiles.


Used to import data from PMDF style distribution lists into user profiles.


Used to generate both NM and PMDF style distribution lists.


Used to generate a file suitable for loading into a PMDF DIRECTORY DAEMON database.

Files Created

The table below describes the files created by UMP. Unless otherwise specified, the files are created in OECN$UMP:.

File Description


One file for each distribution list. This file contains addresses of users who have requested to receive original attachments sent to an OECN list..


One file for each distribution list. This file contains addresses of user who have requested web links to attachments sent to the an OECN lists.


Alias file defining aliases for UMP generated lists. This file is intended to be loaded into the PMDF alias database or included into the PMDF alias file.


Alias file defining aliases for UMP remote users to create centralized naming. This file is intended to be loaded into the PMDF alias database.


File containing reversing entries for users to create centralized naming. This file is intended to be loaded into the PMDF reverse database.

UMP Menu and Profile Screen

The program may be executed by typing:


at the $ prompt or from the menu system, type:


The Main UMP Menu

The following menu will appear:

|                                                                 | 
|  UMP - User Mail Profile Maintenance                            |
|  -------------------------------------------------------------  |  
|     1. PERSONAL   - Modify Personal Profile                     |
|     2. MAINTAIN   - Maintain User Profiles                      | 
|     3. EXIT       - Exit program                                |
|                                                                 |
|                                                                 |
|                                                                 |
|                                                                 |
|                                                                 |
|                                                                 |
|                                                                 |
|                                                                 |
|     Menu: UMP Option>                                           |
|                                                                 |
|   XXX Accept       XX  Help        XX  Exit        XXX Next     |

Profile Screen

When you execute the UMP program and select the MAINTAIN option, a User Mail Profile screen similar to the following will appear:

|                                                                         | 
|                                             Updated  12-DEC-1995 16:26  | 
|                                                                         |  
| Username  DOE     Group         Node  NWOCAC   User Type  STAFF         | 
| Internet Host/Mailbox    NWOCA.ORG                                      | 
| Name   Doe, John                               Phone                    |  
| Title  NBEC/NWOCA    SSDT Documentalist/Supp   Fax                      |   
| Position Code                                  Cell/Pager               | 
|                                                Alternate                | 
| District IRN                                                            | 
| Building IRN                                                            | 
| County   Henry                                                          | 
| District/Organization  NBEC/NWOCA                                       |   
| Street Address                                                          |   
| City, State, Zip                                                        |   
| Comment                                                                 |   
| URL                                                                     | 
| Site information                                                        |   
| Management Groups                                                       | 
|                                                                         | 
|                                                                         |   
|  UMP: User Mail Profile for OECN Users                                  |   
|   XX  Top             XXX  Find            XXX  Lockmode                |    
|   XX  Help            XXX  Add             XXX  Set Defaults            |    
|   XX  Exit            XXX  Delete          XXX  Email Lists             |    
|   XXX Next            XXX  Modify                                       |   


In order to view the Email lists you currently subscribe to, press the
[Email Lists] key. A screen similar to the following will
appear giving both OECN statewide and local distribution lists.

| User  DOE        Name  Doe, John                                        | 
|                                Subscribe by name _________________      | 
| Receive OECN attachments as web links?  Y                               | 
|Subscribed?  --  Subscribed Distribution Lists --                        | 
|   -- OECN lists --                                                      | 
|    Y   MAIL_STAFF           DAS Staff   [Restricted]                    | 
|    Y   MAIL_SUPT_PUB        Superintendents-Pub   [Restricted]          |   
|    Y   MAIL_TREAS           Treasuere    [Restricted]                   | 
|   -- NWOCA lists --                                                     | 
|    Y   MAIL_SSDT            SSDT Staff                                  | 
|    Y   MAIL_STAFF_EMIS      EMIS Staff                                  | 
|    Y   MAIL_STAFF_FIS       Fiscal Staff                                | 
|                                                                         | 
|                                                                         | 
|                                                                         | 
|                                                                         | 
|                                                                         | 
|  Press <Show All Lists> to see all available lists                      | 
|                                                                         | 
|  UMP: E-mail Distribution Lists                              1 of   1   | 
|   XXX Accept (Resort)       XX  Cancel                XX  Prev Screen   |  
|   XX  First Screen          XXX Last Screen           XX  Next Screen   | 
|   XX  Help                  XXX Show All Lists                          |  
|   XX  Exit Dist Lists       XXX Exit Dist Lists                         | 
|                                                                         | 

The field "Receive OECN attachments as web links?" indicates if the user wishes to receive links, instead of attachments, for files sent to the OECN state-wide lists.

You may subscribe or unsubscribe to any unrestricted list by entering the name of the list in the indicated field at the top of the screen and pressing the [Accept] key.

Table of Email Distribution Lists

In order to see the available distribution lists, press the [Show All Lists] key. A set of screens such as the following will appear:

|                                                                         | 
| User  DOE        Name  Doe, John                                        | 
|                                Subscribe by name _________________      |                   
| Receive OECN attachments as web links?  Y                               | 
| Subscribed?  --  All Available Distribution Lists --                    |        
|   -- OECN lists --                                                      |       
|        MAIL_CSTAFF          C-site staff (obsolete)                     |       
|        MAIL_EMIS            EMIS Coordinators   [Restricted]            |       
|    _   MAIL_LIBRARIAN       Librarian                                   |       
|        MAIL_PRINC_NONPUB    Principals-Nonpublic   [Restricted]         |       
|        MAIL_PRINC_PUB       Principals-Public   [Restricted]            |       
|           MAIL_PRINC_ELEM      Principals-Elementary   [Restricted]     |       
|           MAIL_PRINC_SEC       Principals-Secondary   [Restricted]      |       
|    _   MAIL_SPECED          Special Education                           |       
|    Y   MAIL_STAFF           DAS Staff   [Restricted]                    |       
|        MAIL_SUPT_NONPUB     Superintendents-Nonpublic   [Restricted]    |       
|    Y   MAIL_SUPT_PUB        Superintendents-Pub   [Restricted]          |       
|           MAIL_SUPT_CITY       Superintendents-City   [Restricted]      |  
|           MAIL_SUPT_COUNTY     Superintendents-County   [Restricted]    |   
|  This is the first screen                                               |    
|                                                                         |  
|  UMP: E-mail Distribution Lists                              1 of   6   | 
|   XXX Accept (Resort)       XX  Cancel                XX  Prev Screen   |  
|   XX  First Screen          XXX Last Screen           XX  Next Screen   |   
|   XX  Help                  XXX Show Subscribed                         | 
|   XX  Exit Dist Lists       XXX Exit Dist Lists                         |   

Startup Procedure

Follow the steps below to install UMP on your system:

  1. Create the system logical OECN$UMP to point to the device and directory where profile and distribution lists will be created. You should NOT use the same directory as your NM: or OECN$MAIL directories. You should create a new directory to contain these files.
  2. Use OECN_INSTALL and INSTALL PACKAGE as usual to install the OECN package.
  3. If installing for the first time, copy OECN$UMP_LOCAL.INI to OECN$UMP with world:read protection.

    Modify OECN$UMP_LOCAL.INI to contain A-site specific information. You must specify A-site name, DECnet node, and internet host names, etc. See the .INI file for more information.

  4. Run the UMP.EXE program and choose the MAINTAIN option. Then exit the program. This will create empy .IDX files in OECN$UMP. Set the protections on the *.IDX files to W:RW.

Loading Initial Data

Load existing distribution lists. If using NM style distribution lists,
then use:


If using PMDF style lists created by SWOCA's PUBDOM OECNMAIL utilities, then use:


Then run OECN$:UMP/MAINTAIN to review the user profiles. It should have set, at least, the username, DECnet node, and host/domain. If the NM lists were loaded, it will also have the name, district and county from the NM lists. If a user was on more than one list, the user profile will have multiple list codes.

After running the import, the protection on the UMP*.IDX files should be set to W:RW.

You may, if desired, import from both the NM and PMDF style 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.

Importing Other Lists

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 list (either a standard list or a local list), you can use the UMPIMPORT.EXE utility directly.

The UMPIMPORT utiltiy can read an existing list (either NM or PMDF format) and assign the users to the distribution list code you specify. The UMPIMPORT utility takes three parameters in the following form:

$ UMPIMPORT \{NM|PMDF\} \{code\} \{file\} 

The first parameter indicates if the list to be imported is a NM list or a PMDF list. NM style lists must contain at least the DECnet address. PMDF style lists must contain internet addresses. The second parameter is the distribution list code to assign to the users. The code must be defined in either OECN$UMP_STANDARD.INI or 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.

INI File Commands

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.

<caption>* Table of INI File Commands*</caption>

  Command   Fields Explanation





A-site acronym. Required field.





Default DECnet node, cluster prefered. Required field.





Default domain. Used as default for user profile and PMDF aliases. For
example, SET_DOMAIN = "NWOCA.ORG". Required field.





Default for "User Type" field.





Alias prefix for local distribution lists. Example, LOCAL_LIST_PREFIX =
"Local_". May be null if local lists are not to be prefixed.





This parameter defines host name(s) which should be considered "local"
to the current system. You may include multiple LOCAL_HOST lines if
needed. If a users "internet mailbox/host" field contins a local
address, then a user alias will not be created for them. Use this
parameter if you change the domain specified by SET_DOMAIN but you
still have user profiles which refer to the old address. Without this
parameter, UMP will consider profiles with the old domain to be remote
users and will create aliases for them.





This parameter may be used to set the name of the reprocess channel to
be used for processing UMP distribution lists. By default, UMPEXPORT
will assume the reprocess channel is named reprocess.domain_name where
domain_name is the domain from the SET_DOMAIN parameter.





This parameter may be used to specifically set the name of the
directory daemon domain, if any. If this parameter is not specified
then UMPEXPORT will assume that the directory daemon is named
PO.domain_name where domain_name is the deomain from the SET_DOMAIN





Used by the UMPEXPORT to rewrite a particular domain to a
"pseudo_domain" for address
reverals. The pseudo_domain may be name of your directory channel or an
alias for the local host. For example, REWRITE = *,"". In
this example, the command would cause all of NWOCA's users to have an
email address of "" regardless of their real host
name. In this way, remote users will not learn the real host name
(which may change). REWRITE supports full wildcarding on the "From"
domain portion of the parameter. The user@host may be a wildcard
pattern which matches user email address from the UMP profiles. The
new_host is the domain that the address will be rewritten to.




Synonym for REWRITE






Address for "errors-to" parameter on mailing lists. If not preset, the
"errors_to" address defaults to "postmaster".





Email address to place in any empty distribution list to prevent
bounces to mail sent to an empty list. Defaults to "empty@bitbucket"
which is suitable if the default "bitbucket" channel is defined.





Enables users to request and receive "web attachments" sent to the OECN
lists. Default is "YES". Set to "NO" to prevent users from requesting
web attachments.





Specifies the "web attachment" default for new users. By default, new
users will receive web links instead of attachments. Set this to NO if
you wish new users to recieve the original attachments.





Indicates whether the 'Alias' and 'From' fields should be activated.
When set to NO (the default), the alias and from fields will be
disabled. When set to YES, the fields will be active. Note: When set to
YES, the DAS must customize thier procedures to load the
USER_ALIASES.TXT and USER_REVERSE.TXT file into the appropriate PMDF




"{named parameter}"

Specifies named parameter(s) to added to the MAIL_ and local aliases
created by UMP. Multiple named parameters may be specified using
multiple LISTPARMS lines. The named parameters will be included on all
MAIL_* and local UMP aliases. See the PMDF Managers Guide for
information about named parameters. Note: Too many named parameters may
prevent the alias from fitting in the PMDF Alias database. In that
case, the MAIL_ALIASES.DAT file must be included into the PMDF alias
file and the configuration compiled nightly.





Protect "Site Info" field in UMP. The default is "YES".





Defines a distribution list type. Types 01---0z are reserved for OECN
use. Types 10---zz are available for DAS use. Types must be defined
prior to using a DEFINE_CODE line.




[Type-],{Code},"{Description}", {List_Name},[User_Modifiable],

Type is a two digit no., considered above. Code is a 1 to 8 character
code used in the UMP maintenance program. List_Name is the file name
suffix used to create the distribution list filename. User_Modifiable
(Y,N) allows the user to subscribe or unsubscribe to the list. The
default is "NO", which means that the list is restricted. Master_Code
contains the master list code to which a sublist refers. In the case of
a master list, this field also contains the master list code. See the
section, Defining Local Distribution Lists, for more details.
The default list type for codes in the OECN - wide file is 01. e.g.
in the OECN$UMP_STANDARD.INI file, DEFINE_CODE=COUN,... is equivalent
If the first character of the distribution codes is a hyphen (--),
the distribution list is obsolete and should be phased out. This means
that the export routines will not force creation of an alias pointing
to empty distribution lists and will not assign these empty lists as a
sub-list of a master list.





For example, TYPE_RESTRICT= 02,SUBSCRIBED,01-STF, restricts type 02
lists to users who are also subscribed to the list 01-STF. See the
section below on Restricting Types, for more information and kinds of





This command will automatically convert an "old" distribution list code
to a "new" one. For example, CONVERT = 01-PM,02-PM. The "From_Code" is
the old (original) distribution list code, and "To_Code" is the new
distribution list code. Note, that codes must specify both the type and
code (e.g. 01-PM). You should NOT rely on the default prefix when
specifying conversions. See the section below for more information on





The command causes codes to be mapped to produce a single old-style NM
distribution list for compatibility with NM_SEARCH.





This command defines the OECN DAS host name. Each SITE in this section
will be included in the OECN_xxxx distribution lists. It also specifies
each site's CSO white pages identifiers. A range of CSO ids has been
allocated to each site. These fields should not be modified. This
command should not be placed in the OECN$UMP_LOCAL.INI file.

  • = This command can appear at most one time in the Local INI file.

Export NM and PMDF Style Lists

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
aliases and distributions lists up to date. See Section 12.18 for an
example procedure which takes advantage of most of UMP's features.

To run the procedure:

$ @OECN$:EXPORT_LISTS  "\{options\}" 

The P1 parameter should specify one or more of the following options separated by commas:

Option Description


Rebuild the PMDF alias database from scratch using the alias file(s) from UMPEXPORT. Use REBUILD if you allow UMP to control all the aliases in your database, or if you add additional aliases after EXPORT_LISTS.COM is executed.


(Default) Merge the UMP aliases with the existing PMDF_ALIAS_DATABASE. Use this option if you control/rebuild the alias files prior to executing EXPORT_LISTS.COM Note: If this option is used then UMP will always add aliases and old UMP aliases will not be deleted unless you are rebuilding the database yourself elsewhere.


Note: REBUILD and MERGE are mutually exclusive.


Indicates that the USER_ALIASES.TXT and USER_REVERSE.TXT should be loaded into PMDF_ALIAS_DATABASE and PMDF_REVERSE_DATABASE, respectively. This should option should be specified if the DAS is using remote addresses or user alias features of UMP.


Defers placing updated PMDF databases back into the PMDF production directories. This permits the DAS procedure to add additional aliases to the database before being used by PMDF. If this option is specified then the DAS's procedures are responsible for moving the databases back into the PMDF production directories. The PMDF database files created are: OECN$UMP:ALIASES.DAT (Alias database) OECN$UMP:REVERSE.DAT (reverse database).

If you are using UMP as your only source of PMDF database aliases, you should specify REBUILD. This will ensure that any old or obsolete aliases are not retained in your database.

However, if you have other aliases which you are building into your local PMDF alias database, you must take local action to periodically rebuild the PMDF alias database using your own aliases. This is necessary to ensure that old aliases are not retained in your PMDF alias database.

If you are unfamilar with how aliases work in PMDF and how the alias database (PMDF_ALIAS_DATABASE) and the alias file (PMDF_ALIAS_FILE) interact, we recommend that you do the following:

  • Allow UMP's EXPORT_LISTS.COM to rebuild the alias database from scratch (by specifying the REBUILD option). This will give UMP complete control over the aliases and ensure that no obsolete aliases are retained.
  • Place any local aliases (those not created by UMP) in your PMDF_ALIAS_FILE. This file is not used by UMP and will allow you to create local aliases without them being wiped out by UMP. 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:.

Centralized Naming

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.

Remote Mail Boxes

UMP can provide centralized naming for users who have "remote" mailboxes. Using UMP's centralized naming, a user can have an address such as even if thier mail is being delivered to a different address (mailbox), regardless of where that mailbox resides. The centralized naming may be used to deliver mail to remote systems on behalf of the user, or simply as a means of forwarding mail without resorting to VMS Mail forwarding.

Examples of "remote" users include:

  • Users who wish to have thier OECN mail delivered to a different account (e.g. on the same system or on a third-party ISP)
  • Users who's mailbox exists on a school district mail server or another DAS mail server.
  • Users who's mailbox is in PMDF popstore

The primary benefit of centralized naming is that it permits a user to have a stable mailing address even if the actual mailbox changes in the future. Everyone with an DAS can have the same host name in thier address regardless of where the mailbox reside.

UMP determines if a user requires an alias based on the "Internet Host/Mailbox" field on the profile. If the "Internet Host/Mailbox" field contains a different mailbox or a "remote" hostname, then the user is considered "remote" and an alias is generated. The definition of "remote" is if the host name portion of the address does not match the value of SET_DOMAIN or any LOCAL_HOST in the OECN$UMP_LOCAL.INI. For each user which UMP determines requires an alias, an line is written to USER_ALIASES.TXT. A line is also written to USER_REVERSE.TXT. USER_REVERSE.TXT contains the appropriate "address reversal" entry which allows PMDF to adjust the user's "From:" address for outgoing mail.

Both USER_ALIASES.TXT and USER_REVERSE.TXT are suitable for loading into the PMDF_ALIAS_DATABASE and PMDF_REVERSE_DATABASE, respectively. The use of these files is optional and is up to each DAS to determine if they are useful in their configuration. EXPORT_LIST will not load the files into PMDF by default. You must either set the USER option in EXPORT_LISTS or write a custom procedure to load these files after EXPORT_LISTS is executed.

Please note, the USER_REVERSE.TXT is only effective if mail sent by the user is routed through your system. For remote systems running mailers which send internet mail directly (such as a remote VMS system running PMDF), you must use that system's mechanisms for rewriting "From" address lines. For instance, on a remote PMDF system, adding a REVERSE mapping to the PMDF_MAPPING_FILE may be appropriate. Alternatively, you could take steps to ensure that all outgoing mail is routed through the system containing the UMP reversing entries..

User Aliases

UMP provides the ability to create a user-specific alias independent of the username or actual mailbox. For example, a username of "" could have an alias of "". Furthermore, the user alias may optionally be used as the user's backward pointing (From: ) address. This permits the user to have an easier to remember address as well as obscuring the actual username for security purposes.

The user aliases in UMP are implemented as two fields on the UMP profile called "Alias" and "From". The alias is a 32 character field which may consist of letters, digits or dots (.). The alias is required to have a least one dot to avoid duplicates with VMS usernames. The 'From' field is a flag indicating if the alias should be used as the profile's official "From:" address. If the "From" flag is set to 'N', then the alias is merely an alternative address for the user. If the flag is set to 'Y', then an entry will be added into the USER_REVERSE.TXT to reverse the backward pointing addresses for any mail sent by the user.

The 'Alias' and 'From' fields may only be modified by a system or group manager. That is, end-users cannot specify thier own alias or reversal. This allows the appropriate manager to control the alias standards. It also prevents users from changing thier alias or 'From:' address frequently without understanding the implications or attempting to forge mail messages.

Group managers are required to specify an "alias prefix" which matches one of the group codes they are responsible for. For example, if a group manager is responsible for the groups "AA,AB", then they may only specify aliases beginning with "aa." or "ab.". This helps ensure uniqueness in the mailbox namespace when multiple group managers are responsbile for different groups of profiles.

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.

Implementing User Aliases

The following steps must be performed in order to activate the user alias and address reversal using UMP:

  1. Configure PMDF to use the 'reverse database' on the appropriate channels. This feature is enabled by default in a standard PMDF configuration. See the PMDF documentation for more information.
  2. Set ALLOW_USER_ALIAS to YES in OECN$UMP_LOCAL.INI. This flag enables the 'Alias' and 'From' fields in UMP.
  3. Invoke EXPORT_LISTS.COM using the USER option to cause the USER_ALIASES.TXT and USER_REVERSE.TXT files to be loaded into the appropriate database. See Section 12.18, Example Procedure for Periodic Rebuilds for an example procedure which invokes EXPORT_LISTS.COM.

Distribution List Codes

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 see lists that may apply to them. The type codes also ensure that lists defined by the OECN do not conflict with those created by the DAS.

This version uses an 8 character code in the following format:


Where TT is the distribution list "type" (or category) and CCCCCC is the distribution list code. The following types are predefined by UMP:



OECN-wide user distribution lists



OECN DAS staff-only lists



Default type for lists defined by DAS

Types beginning with "0" are reserved for OECN use. All other types (any type not starting with "0) are available for use by the DAS. Currently, a maximum of 100 types can be defined.

Type 10 is predefined and available for DAS use. To add additional types add a line to the local ini file, like:


For example:

TYPE=11,"NWOCA Staff Lists"

Once a type has been defined, you may use the type in subsequent DEFINE_CODE lines, for example:



This creates two lists called MAIL_STAFF_RECIPIES and MAIL_STAFF_JOKES. When displayed in UMP, they will be sorted and displayed under a subheading called "NWOCA Staff lists".

Restricting Types to Particular Users

Using types allows you to organize your lists into categories for presentation to the user. But it may also be useful to restrict categories of lists to particular types of users. UMP allows you to apply several types of restrictions based on the user's profile information.

Note that type restrictions do NOT affect whether or not a user can subscribe or unsubscribe from a given list. Each DEFINE_CODE line determines whether a list is user-subscribable. The type restrictions only limit whether the user can see a list or not.

Please note that the type restrictions are not intended as rigid security. Since some of the criteria is based on user modifiable fields, it is possible for a user to enter incorrect information and get assigned to the wrong lists. For example, a user might enter another district's IRN which allows them to subscribe to another districts lists. However, if the user changes the IRN back to the correct value, UMP will remove them from any incorrectly assigned lists.

To apply a restriction to a type value, use one of the following commands in the local ini file:


Restricts type tt to users who are also subscribed to list tt-ccccc.


Restrict type to users who have a district or building IRN matching nnnnnn


Restrict type to users with a 'user type' field matching xxxxx.


Restrict type to users with a 'county' field matching xxxx.


Restrict type to users with a 'username' field matching wildcard mask.

Multiple TYPE_RESTRICT lines may be added for a single list type. In this case, the restrictions form a logical OR operation. That is, if the user matches any one of the criteria, they will have access to the type.

For example, to restrict the type 11 lists (from the example in the previous section) to DAS staff members, the following restriction could be applied:


This will restrict all type 11 lists to users who are also subscribed to the standard DAS staff list.

Auto Conversion of Distribution List Codes (Optional)

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 in the LOCAL INI file are prefixed with type 10. For instance, if a DAS has defined several "staff" lists, you may wish to separate these into a separate type and restrict them to staff members only.

To help facilitate this, an optional command is available for the LOCAL INI file called CONVERT. The CONVERT command takes the following form:


For example, to convert an existing code of 10-SEM (Staff EMIS) to 11-STFEMS, place the following line in the LOCAL.INI:


Note that the prefix is required even if you did not use the prefix when defining the code originally. Remember that any codes defined by the local ini file default to type 10, so if a code was defined without a type, it's type is 10.

When changing a existing code using a CONVERT line, you should change the DEFINE_CODE line to reflect the new code at the time you add the CONVERT line. You should not reuse old codes until you are certain they no longer exist in the UMDDAT file. After you are certain the old code no longer exists in the UMDDAT file, you may remove the CONVERT line from your INI file.

Adding the CONVERT line and revising the DEFINE_CODE line, is all that must be done to convert an existing list. UMP and it's utilities will automatically convert the code as needed "on-the-fly". If you look at the UMDDAT.IDX file after making a conversion, you may notice that some users have the new code and others still have the old code. This is the expected behavior. The new code will not be physically written to the file until the record is changed with UMP's Modify function.

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.

Defining Local Distribution Lists

To define a local distribution list, you need to add several additional lines to the OECN$UMP_LOCAL.INI file.

You will probally need to use the ini commands:


Example 1

The following example illustrates how to define a local distribution list for payroll clerks.

Add the following lines to the OECN$UMP_LOCAL.INI file:

TYPE = 12,"Local Payroll Clerks" 

In order to actually subscribe to this distribution list, a user or DAS person, will have to access the user's UMP profile, bring up the list of available distribution lists, and subscribe the person.

Example 2

As another example, suppose you wish to set up a distribution list for staff jokes, restrict the list to just those users who have access to DAS staff lists, create sublists for fiscal, programming, and EMIS jokes, and set a prefix for local lists.

Add the following lines to the OECN$UMP_LOCAL.INI file:

TYPE = 11, "Local Staff Lists" 

Then those users who are subscribed to the 01-STF list will see the following entry when they access the table of available lists in the UMP program.






Users who are not subscrbed to the list 01-STF would see not entries for "Local Staff Lists" including the heading itself.

Note that the three sublists point to the master list, 11-STFJOK in the DEFINE_CODE lines. This makes these sublists, so that mail addressed to 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.

Profile Group Management

UMP provides the ability to segregate profiles into management groups and delegate responsibility for the groups to selected individuals. Once delegated, the group manager has nearly complete control over the content of the profiles in the groups they are responsible for. They may add, change or delete profiles within their group and assign profiles to unrestricted distribution lists.

Group managers may not add or remove profiles from the restricted distribution lists. These lists (MAIL_STAFF, MAIL_SUPT_PUB, etc.) are the responsibility of the DA-site and may not be delegated.

User profiles are assigned to groups simply by placing a value in the 'Group' field on the UMP profile. If desired, the field may be massed changed using Datatrieve by modifying the GRP field in the UMP_HEADER domain or UMP view. This value is a protected field and may only be changed by DAS personnel or a group manager associated with the group.

A user may be granted management rights to one or more groups by entering a comma separated list of groups in the 'Management Groups' field. A limit of ten comma separated groups may be included. The following standard wildcards are supported in the management groups field:


Any sequence of zero or more characters


Exactly one character


Exactly one numeric character


Exactly one alphabetic character

The user with any value in the 'Management Groups' field will be permitted access to the MAINTAIN option in UMP. No special security identifiers are required. The user will be able to view any profile on the system, but will only be permitted to modify or delete profiles associated with one of their groups. If a group manager adds a profile, they must enter a group which matches their group management field.

The value of the group field is entirely arbitrary. The DAS may assign the groups in any fashion desirable. Most likely, a group would be created for all users in a district and one or more group managers would be assigned to manage that district's profiles. However, groups could be further defined by building, or perhaps by classes of users (teachers, administrators, etc.). Since wildcards are supported, it is possible to devise complex hierarchies of groups which permit different users various levels of access.

Group managers should be carefully instructed regarding local conventions for the various UMP fields. In particular, if the DAS uses the USER_ALIAS.TXT to route mail to remote mailboxes, then proper use 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.

Export DIRECTORY DAEMON File (optional)

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 produces a DIRECTORY-DAEMON.TXT file in the OECN$UMP directory. You must execute the appropriate PMDF CRDB command to create the indexed file database and place it in the PMDF_ROOT:[DIRECTORY] with the appropriate filename for your pseudo-domain.

EXPORT_DD creates several aliases for each user. For example, the following aliases would be created for username "SMITH" and a profile name "Dave Smith":










Notice that the first alias (the username alias) sends directly to the user's "real" address. The other aliases (dotted names) send to the username at the directory channel. Since the username should be unique, the first alias should never cause a bounce. The other addresses may cause a bounce if they are not unique (the sender is notified of the duplicates and their addresses). Since only dotted names and their addresses are returned to the sender, the sender never learns the "real" address. This helps isolate remote users from knowning the real host names of the recipient.

The directory channel for the DAS is assumed to be "po." plus the value of the SET_DOMAIN line from the OECN$UMP_LOCAL.INI file. For instance, for, the directory channel is assumed to be If the DAS is using a different name for the directory channel, you may place the following line in the OECN$UMP_LOCAL.INI file:


See the PMDF System Adminstrators Guide for more information about the directory daemon, channels and pseudo-domains.

Submit UMP Data to OECN CSO Database


The OECN CSO ("OECN Whitepages") is defunct.  ITC's should no longer be submitting CSO data.



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 database anywhere on the network. Users can use GOPHER, LYNX or other web browsers to perform queries. A utility called PH is also available to perform direct queries against the central database.

To transmit UMP data for loading into the CSO database, each DAS should run the UMP_SEND_CSO.COM command procedure once per week. This command procedure will extract the UMP database into CSO format and send it to NWOCA.ORG for loading into CSO.

Unless instructed otherwise, please do not routinely run UMP_SEND_CSO more than once per week. In general, a single weekly run is sufficient to keep the OECN White Pages up to date. However, situations will arise where an extra run of UMP_SEND_CSO is necessary or desirable. For example, if you change domain names, or load a large number of new users or make significant changes to the the profiles. In these cases, feel free to make a special run of UMP_SEND_CSO.

NWOCA's system will run an update routine at approximately midnight each night to load any files submitted during the day. Therefore, the CSO data on file at the server will be updated the day after you run UMP_SEND_CSO. This schedule means that your CSO data will be at most one week behind when compared to your current UMP database.

If you are also using EXPORT_DD.COM to build a DIRECTORY-DAEMON database, you may wish to have the email addresses in the CSO database reflect your directory daemon address, rather than your user's real addresses. In this case, you may add the following line to your OECN$UMP_LOCAL.INI file:


Where "pseudo_domain" is the domain name of your directory channel, for example, NWOCA uses the following line:


This line would cause all of NWOCA's users to have an email address of regardless of their real host. In this way, remote users will not learn the real host name (which may change).

Master List/Sub-list Handling

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 duplicate messages if the user was on more than one sub-list. With this version, the master lists will contain the actual email addresses of the users who are on the master list or any of the sub-lists.

There were also "compatibility" codes which were used for the original NM distribution list codes. This proved too cumbersome and confusing. Therefore, a new method of handling the master lists was implemented which essentially combines the master lists with the NM-compatibilty lists.

The codes PRN, SPT and TRS were previously indicated as "Obsolete-NM" codes. This is no longer the case. These codes are now "master list" codes (and indicated as such on the UMP help screen). If a user is coded as having a "master list" code, they will placed on the master list and will also be placed on all of the sub-lists for that code.

If a user is coded on one of the sub-lists, they will be placed on that sub-list and the corresponding master list.

These changes provides two advantages:

  1. It provides a simple way of placing a single user on all sub-lists using a single code. For example, if a DAS staff member wishes to be placed on all the MAIL_TREAS_xxx lists, they may simply be given the TRS master code. This will cause them to be placed on the master list and all of TRS's sub-lists.
  2. Users which have not yet been recoded to one of the more specific lists will automatically be placed on the master and all sub-lists. This ensures that users who have not been recoded to the appropriate list will still receive mail sent to any of the lists.

This change means that it is somewhat less important to get your users migrated off of the old distribution list codes. However, if you leave users on the master list codes, they may receive mail that was not intended for them. For example, if mail is sent to mail_supt_jvsd, it will be received by all users who are on the SPT or SJV lists.

UMPCHECK - Verifying UMP Profiles against SYSUAF (Optional)

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 profiles for such usernames. By default, UMPCHECK only checks profiles when the user's DECnet node name matches the values of the SYS$NODE or SYS$CLUSTER_NODE logicals. Other users are considered to be remote users and are not verified against the current node's SYSUAF. UMPCHECK must be run as a foreign command and accepts the following syntax:


The first parameter is the function to perform:


Verify the UMP profiles against the SYSUAF and report usernames which are invalid, disusered or dismailed.


Unconditionally deletes local usernames which are invalid, disusered or dismailed.


Same as DELETE but prompts whether each username should be deleted or not.

The function must be specified exactly as shown above without abbreviation and there may not be spaces between DELETE and /CONFIRM.

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.

UMP_LOGIN - To Prompt Users to Enter Profiles During Login (Optional)

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.

You may invoke UMP_LOGIN.COM at any point during login when appropriate for your users. For example, SYLOGIN or other procedure appropriate for your system. If you want UMP_LOGIN to be invoked automatically by OECN_LOGIN, you may create a file in OECN$CUSTOM called OECN_LOGIN_EPILOGUE.COM and execute OECN$:UMP_LOGIN from there.

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.

UMPID2DIS - Creating Distribution Lists from VMS Identifiers (Optional)

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 lists for all users of a given package. These distribution lists are not standard OECN-wide lists.

UMPID2DIS will only work correctly on your system if your UIC's are unique. That is, each user (holder of an identifier) has their own unique UIC. If two users hold the same UIC identifier, only one of them will be output to the lists.

To create a distribution list for users holding a given identifier, use the following commands:


$ ID2DIS {identifier},... {distribution_list_file}

where "identifier" is the identifier. If you specify an OECN_
identifier, users who hold the standard identifier or the _RO and _GM
variants will be included in the list. You may specify multiple
identifiers separated by commas (no spaces). If a user holds more than
one of the identifiers, they will only be included on the list once.

"distribution_list_file" is the filename to contain the
distribution list. If a device and extention are not included, the
default is OECN$UMP:.DIS.

Only users that meet the following criteria will be output to the list:



The user holds one or more of the specified identifiers.



The UAF flags DISUSER and DISMAIL are not set.



The username has a valid UMP profile.

Note that UMPID2DIS does NOT create the PMDF alias to point to the distribution list. If aliases are desired for the list you must use PMDF CRDB or PMDF DB to create the PMDF aliases.

For example, NWOCA could use the following commands to create a distribution list for all NWOCA USPS users:






open pmdf_alias_database

override on

add "nwoca_usps" ""

add "nwoca_usps-list" "<oecn$ump:nwoca_usps.dis,,,postmaster,*,


Example Procedure for Periodic Rebuilds

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 your PMDF alias database from scratch or make significant modifications to the UMP profiles.

If you have PMDF's directory channel configured, you should run EXPORT_DD.COM and build a new directory daemon database. You may also to use UMPID2DIS to create distribution lists based on VMS identifiers.

You will most likely want to write a DCL command procedure to execute all of the appropriate steps in a single batch job, and then schedule it with DECscheduler. Attached is a sample of such a procedure which is currently in use at NWOCA. You may wish to use this as a starting point for your own procedure.

$!  This procedure run the UMP routines to export distribution list, build 
$!  aliases, etc. 
$! - 
$! Temporarily suspend mail processing while lists are being 
$! created and datbases rebuilt. 
$! Export distribution lists and rebuild PMDF databases. 
$ ! 
$ ! Merge aliases for mail addressed to former MAVCA users.  
$ ! May be removed after MAVCA.OHIO.GOV goes away. 
$ ! 
$ pmdf crdb /long/nofast/nodup/strip OECN$UMP:MAVCA_ALIASES.DAT oecn$ump:aliases.dat 
$! Create directory daemon text file. 
$! Build new directory daemon database.  Build into a temp file in case 
$! someone attempts to use database while in progress. 
$ pmdf crdb/duplicate/stat oecn$ump:directory_daemon.txt - 
$ copy oecn$ump:directory_daemon.tmp - 
$ set prot=w:re pmdf_root:[directories]PO$NWOCA$ORG.DAT 
$ purge pmdf_root:[directories]PO$NWOCA$ORG.DAT 
$ delete/nolog oecn$ump:directory_daemon.tmp;* 
$! Build distribution list based on VMS identifiers 
$ COPY OECN$UMP:nm_*.dis/sinc NM:/PROT=W:R 
$! Create aliases for NWOCA's identifier lists 
open oecn$ump:aliases.dat 
override on 
add "mail_hs_counselors" "mail_counselor_sec" 
add "nwoca_usps" "" 
add "nwoca_usps-list" "<oecn$ump:nwoca_usps.dis,*,*,postmaster,*, USPS" 
add "nwoca_PPS" "" 
add "nwoca_PPS-list" "<oecn$ump:nwoca_PPS.dis,*,*,postmaster,*, PPS" 
add "nwoca_USAS" "" 
add "nwoca_USAS-list" "<oecn$ump:nwoca_USAS.dis,*,*,postmaster,*, USAS" 
add "nwoca_EMIS" "" 
add "nwoca_EMIS-list" "<oecn$ump:nwoca_EMIS.dis,*,*,postmaster,*, EMIS" 
add "nwoca_EIS" "" 
add "nwoca_EIS-list" "<oecn$ump:nwoca_EIS.dis,*,*,postmaster,*, EIS" 
add "nwoca_VIS" "" 
add "nwoca_VIS-list" "<oecn$ump:nwoca_VIS.dis,*,*,postmaster,*, VIS" 
add "nwoca_SECIMS" "" 
add "nwoca_SECIMS-list" "<oecn$ump:nwoca_SECIMS.dis,*,*,postmaster,*, SECIMS" 
add "nwoca_INFOHIO" "" 
add "nwoca_INFOHIO-list" "<oecn$ump:nwoca_INFOHIO.dis,*,*,postmaster,*, INFOhio" 
$! Create VMS Mail forwarding addresses for same aliases 
$ mail := mail 
$ mail 
set forward/user=nwoca_usps in%nwoca_usps 
set forward/user=nwoca_pps in%nwoca_pps 
set forward/user=nwoca_usas in%nwoca_usas 
set forward/user=nwoca_emis in%nwoca_emis 
set forward/user=nwoca_eis in%nwoca_eis 
set forward/user=nwoca_vis in%nwoca_vis 
set forward/user=nwoca_secims in%nwoca_secims 
set forward/user=nwoca_infohio in%nwoca_infohio 
$! Create a MAIL_ALL distribution list.  Will contain all user profiles 
$! which are subscribed to one or more distribution list (non-duplicated 
$! addresses). 
$ delete /nolog/noconfirm mail_all.*;* 
$ append mail_*.dis/sinc mail_all.tmp/new 
$ sort/nodupli mail_all.tmp mail_all.dis 
$ set prot=w:r mail_all.dis;* 
open oecn$ump:aliases.dat 
override on 
add "mail_all" "" 
add "mail_all-list" "<oecn$ump:mail_all.dis,*,*,postmaster,*, All NWOCA users" 
$ mail := mail 
$ mail 
set forward/user=mail_all in%mail_all 
$ purge oecn$ump:*.* 
$! All local aliases have been added to databases.  
$! Place the new databases back into PMDF production 
$! directory. 
$ copy/nolog oecn$ump:aliases.dat PMDF_ALIAS_DATABASE 
$ set file pmdf_alias_database/prot=w:re 
$ purge/keep=3/nolog pmdf_alias_database 
$ copy/nolog oecn$ump:reverse.dat PMDF_REVERSE_DATABASE 
$ set file pmdf_reverse_database/prot=w:re 
$ purge/keep=3/nolog pmdf_reverse_database 
$! All done.  Restart dispatcher to ensure services open 
$! the fresh databases. 

Multiple Non-Clustered Systems

DAS's with a single VMS system, or a single VMS cluster, need not be
concerned with this section.

The UMP system is currently designed assuming that each A-site will have a single set of UMP files regardless of how many independent (non-VMSclustered) systems. This provides a single point of adminstration for DAS personnel and makes building the PMDF distribution lists and aliases easier. At present, there are no plans to implement multiple UMP files on multiple systems while still being able to produce a single set of distribution lists for the entire DAS. This may be added in the future if a well defined need arises.

However, it would be useful if remote users could modify their own user profiles without having to log into the system which contains the UMP files. This section describes a secure way of providing remote users access to their own UMP profiles.

Use the following procedure to establish remote access to the UMP system.

  1. Choose a system to contain the UMP files. This would normally be your cluster or the system primarily responsible for mail delivery. This will be called the "server" system.
  2. Put UMP on the server normally as described in the "Setup" section. Users on this system will use the UMP program directly from this system.
  3. Create a username on the server called UMP_SERVER. This should be non-prived, network-only access. The login directory for this account can be the OECN$UMP directory, or it can have a separate login directory.
  4. On the server define the OECN$UMP logical as normal.
  5. On the server use AUTHORIZE to define network proxies into the server for each remote system. For example:

    Where "node" is the DECnet node name of the remote node.
    This will give any user on one of your non-server nodes proxy access to the UMP_SERVER.

  6. On each node (client) that you want to have access to the server, define OECN$UMP as follows (assuming MAIN:: is the server):

    Also, copy the UMP.EXE file to the OECN$: directory on the client node. Set up the users to run the local copy of the .EXE.

  7. Copy the *.INI files from the server to the client system. and define the following logicals:


    Modify the OECN$UMP_LOCAL.INI file to contain the local system's DECnet node name and internet host. This will ensure that each user's profile is built using the local system's node names.

If you do the above, each node will appear to have local access to the 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.

Programming Considerations

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 and COBOL definitions are provided with the software release for this purpose. The COBOL definitions are contained in UMPDAT.LIB and UMDDAT.LIB in OECN$LIB. The DTR definitions are in the domains OECN$CDD_OECN.UMP_HEADER and OECN$CDD_OECN.UMP_DIST. OECN$CDD_UMP.UMPS is a view which joins the header and distribution list code.

The UMP data is stored in two files in OECN$UMP:


Contains profile information. Keys:

  • Primary: Group + Username
  • Secondary: Username (no duplicates)
  • Secondary: Alias (no duplicates)


Contains the distribution lists the user is subscribed to. Each record represents a single distribution list assignment. The distribution lists are stored as a code value defined by the OECN$UMP_STANDARD.INI or OECN$UMP_LOCAL.INI files. Primary key: Username + Distribution_list_code

Field Requirements

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:

  • The ALIAS field must always contain a value. If the user does not have a specific alias, then the ALIAS must be set equal to the USERNAME field.
  • A number of fields are calculated by UMP as needed and may or may not be stored physically in the field. For example, if the ORGANIZATION field is blank, but the DISTRICT_IRN is not, then UMP will calculate the ORGANIZATION name using the OEDS file. However, UMP will not necessarily store the calculated value. If you are developing programs which depend on these values being stored on the file, you may run UMPUPDATE.EXE prior to your program. UMPUPDATE will calculate the files and store them on the file.
  • Distribution list codes are always stored in internal format (ttxxxx) as defined by the INI files. In order to manipulate distribution codes, you must know the lists internal value.
  • The LAST_UPDATE field is a VMS quadword date.
  • MODIFIED_FLAG contains "Y" if the user has modified their own profile. Any other value indicates the profile is new and has not been modified by the user.
  • No labels