DB is a utility with which to create and manipulate an alias
database. Alias databases can either be a personal alias database
(pointed at by the logical PMDF_PERSONAL_ALIAS_DATABASE) or a
system alias database. As the format of PMDF alias database is
used for other PMDF databases (e.g., PMDF_DOMAIN_DATABASE), DB
can also be used to manipulate non-alias databases.
DB is invoked by the command
$ PMDF DB
and can be exited by either typing Control-Z or issuing the quit-
program command.
1 – Aliases
Aliases have multiple uses with e-mail. Individual users
typically use aliases as abbreviations. For instance, rather
than remember John Doe's full e-mail address, an alias JD can
be created so that mail sent to the address JD is properly sent
using John Doe's full address (e.g., JD573@VAXC.EXAMPLE.COM).
System managers often use aliases in order to create valid mail
addresses for non-existent users. For instance, an alias named
Postmaster might be created and equated with the username SYSTEM
so that incoming network mail for the user Postmaster is routed
to the SYSTEM account. These are just two examples of the many
practical uses of aliases.
The process of interpreting an alias is called "alias expansion".
In the two examples above, the aliases JD and Postmaster expand,
respectively, to JD573@VAXC.EXAMPLE.COM and SYSTEM.
In this documentation, the expansion of an alias is represented
with the following notation
alias-name - > alias-value
For example, John - > JD573@VAXC.EXAMPLE.COM.
PMDF alias names are "case insensitive". This means that the
alias names jd, JD, jD, and Jd are all considered to be identical
by PMDF; the case (upper versus lower case) of the individual
characters in an alias name is irrelevant to PMDF. However, PMDF
does preserve the case of alias values.
PMDF aliases can expand to:
- an address: JD - > JD573@VAXC.EXAMPLE.COM,
- a list of addresses: STAFF - >
BOB@EXAMPLE.COM,SUE@EXAMPLE.COM,
- other aliases: JD - > JOHND - > JD573@VAXC.EXAMPLE.COM,
- a list of aliases: COMPANY - > STAFF,ADMIN,FACULTY, or
- a mixture of addresses and aliases: LIST - >
STAFF,BOB@EXAMPLE.COM.
Note that in the above example, it is not clear whether or not
the expanded value of an alias is another alias or not; i.e.,
in "JD - > JOHND", JOHND could have been either an alias or
a legitimate username. PMDF always starts by assuming that an
address without any domain part (e.g., @EXAMPLE.COM) is an alias
and attempts to expand it. When expanding an alias, PMDF first
tries to look up the alias in the user's personal alias database
and, if the alias is not found there, then PMDF consults system-
level alias sources. After expanding an alias once, PMDF then
tries to expand the result (or results in the case of a list).
This expansion process is repeated until no more expansions are
possible at which point the results are all assumed to be real
mail addresses and not aliases.
By default, alias names can be from 1 to 80 characters long and
their expansion values 0 to 252 characters. This corresponds
to a "long" alias database file which is the type of file DB
normally creates. When a "huge" alias database file is used, the
maximum lengths of the alias names and their expansion values
are, respectively, 80 and 1024 characters. When a "short" alias
database file is used, the maximum lengths of the alias names and
their expansion values are, respectively, 32 and 80 characters.
Note that by default the system alias database created with the
CRDB utility is a short alias database.
When specifying mail addresses within VMS MAIL or DECwindows
MAIL, PMDF aliases must be specified using the format IN%alias-
name. For example, mail addressed as follows
MAIL> SEND
To: IN%JD
would use PMDF's alias for JD, if any exists. From PMDF MAIL, you
can simply use JD rather than IN%JD.
System managers can find it useful to establish forwarding for
commonly used system wide aliases. For example,
MAIL> SET FORWARD/USER=POSTMASTER IN%Postmaster
with Postmaster a PMDF alias (in the system alias database) which
points to the user or users who should receive mail intended for
the system's postmaster. When this type of forwarding has been
set up, users can then just send mail to the (fictitious) user
POSTMASTER,
MAIL> SEND
To: POSTMASTER
and PMDF will route it to the proper individuals.
2 – Public Aliases
If you want, other users can use aliases which you establish.
This is particularly useful when you want to set up a mailing
list which you want other people to post messages to. (See the
Mailing lists topic for details on settingup a mailing list.) You
allow other people to use specific aliases of yours by declaring
those aliases to be public. This is done with the "attributes"
parameter of the "set" command described in Set.
For example, let us assume that the user sue@example.com has
already created an alias named PIZZA-ORDER. Then, to declare
PIZZA-ORDER to be a public alias, Sue would use the command
db> set pizza-order public
Other users can then use this alias by sending mail to sue+pizza-
order@example.com.
3 – Mailing Lists
With PMDF DB you can create and maintain your own mailing lists.
A mailing list is merely a collection of e-mail addresses with
which you associate an alias. Or, looked at a little differently,
a mailing list is an alias which expands to a list of e-mail
addresses. When you address a mail message to the alias, it
actually goes to all of the addressees listed in the mailing
list. The act of sending a mail message to a mailing list is
referred to as "posting".
A mailing list is created in three steps:
1. Create a text file containing the list of e-mail addresses
associated with the mailing list. Each address should be on a
separate line in the file. The file itself is referred to as a
"mailing list file"; the addresses in the file are the mailing
list's membership.
2. Set the protection of the mailing list file so that it is
world readable
$ SET PROTECTION=(W:R) filename
Here, FILENAME is the name of the mailing list file created in
Step 1.
3. Choose an alias name, ALIAS-NAME , to associate with the
mailing list. Then, in PMDF DB, issue the commands
db> add alias-name "<filename"
db> set alias-name public
FILENAME should include a full path specification including
the disk and directory name.
After these steps have been taken, the mailing list is set up and
ready to use.
For example, suppose the user sue@example.com wants to set up a
mailing list named sample-list. The members of the mailing list
will be bob@example.com, judy@example.com, ralph@sample.com,
and sue@example.com. Sue first creates the mailing list file
D1:[SUE]SAMPLE.DIS which contains the four lines
bob@example.com
judy@example.com
ralph@sample.com
sue@example.com
She then makes sure the distribution file is world readable by
explicitly setting its protection with the DCL SET PROTECTION
command,
$ SET PROTECTION=(W:R) D1:[SUE]SAMPLE.DIS
Finally, Sue establishes the public alias FOO-LIST as follows:
$ PMDF DB
db> add foo-list "<d1:[sue]sample.dis"
db> set foo-list public
db> show foo-list attributes
Key Value
----------- -----------------------------
foo-list <d1:[sue]sample.dis
Attributes: public,no-expand,block-receipts,mail-address
[1 entries shown]
db>
By declaring the list to be public, Sue is allowing other
people to post messages to this mailing list. They should do
so by addressing their messages to sue+sample-list@example.com.
Messages so addressed will then be received by the members of the
list as specified by the contents of the file D1:[SUE]SAMPLE.DIS.
At any time you can add or remove members from the mailing list.
You do so by simply editing the mailing list file removing or
adding addresses from or to it.
As another example, mailing lists defined in LDAP can also be
used, for example:
db> add ldap_all_users <"""ldap:///dc=example,dc=edu?mail?sub?(cn=*)"""
Note the three double-quotes around the LDAP URL. This is
required.
4 – Advanced Mailing Lists
PMDF DB allows you to control who can or cannot post to mailing
lists as well as associate error return, reply to, and other
special addresses with mailing lists. To use these features,
an extended alias specification must be used when declaring the
alias for the mailing list:
db> add alias-name "<filename, named-parameters, error-return-address,
reply-to-address, errors-to-address, warnings-to-address, comments"
These items are described in the subtopics "Named parameters" and
"Positional parameters".
The two positional parameters ERROR-RETURN-ADDRESS and REPLY-
TO-ADDRESS are two particularly useful items. You are strongly
encouraged to use the ERROR-RETURN-ADDRESS parameter so as to
control where error messages concerning postings to your list are
directed. You can use the REPLY-TO-ADDRESS parameter to make the
preferred reply address the list address (or some other address).
4.1 – Named Parameters
Named-parameters are used to associate options with a mailing
list. There can be zero or more of named parameters, each
separated by commas, and they must appear before any positional
parameters. The general syntax of a named-parameter is:
[name] value
Here NAME is the name of the parameter and VALUE is its
corresponding value. The square brackets are a mandatory part
of the syntax: they do not indicate an optional field.
The available named parameters are:
AUTH_LIST
AUTH_LIST is used to specify a list of addresses that are allowed
to post to the mailing list. The VALUE item must be the full file
path specification for a world readable file containing the list
of addresses allowed to post to the list. When someone attempts
to post a message to the mailing list, PMDF will attempt to match
their address against the addresses in the list; if no match
occurs, the attempted posting will be sent to the owner of the
list.
CANT_LIST has the opposite effect as AUTH_LIST: it supplies the
full file path specification of a world readable file containing
a list of addresses which cannot post to the list.
One common use of this facility is to restrict a list so that
only list members can post. This can be done by specifying the
same file as both the mailing list file and the AUTH_LIST file.
For example, assuming that the mailing list is named foo-list and
the associated file is D1:[SUE]SAMPLE.DIS, the alias declaration
would be
db> add foo-list "<d1:[sue]sample.dis, [auth_list] d1:[sue]sample.dis"
BLOCKLIMIT
The BLOCKLIMIT and LINELIMIT parameters can be used to limit
the size of messages that can be posted to the list. The VALUE
item must be an integer number of PMDF blocks, for [BLOCKLIMIT],
or an integer number of lines, for [LINELIMIT]. The size of a
PMDF block is normally 1024 bytes. The default value for these
parameters is 0, meaning that no limit is imposed on the size of
message that can be posted to the list (apart, that is, from any
system wide limits).
DELAY_NOTIFICATIONS
The DELAY_NOTIFICATIONS named parameter requests that NOTARY
delay notifications be sent for mailing list postings; the
NODELAY_NOTIFICATIONS named parameter requests that NOTARY delay
notifications not be sent for mailing list postings. The VALUE
specification is currently ignored and should always be NONE.
HEADER_ADDITION
HEADER_ADDITION can be used to specify a file of headers to
be added to posted messages. The argument must be a full file
specification for the file containing headers to be added.
In particular this facility can be used to add the standard
mailing list headers defined in RFC 2369. For instance, a
user amy@example.com that has set up a public list named
listname might use a header addition file along the lines of
the following:
List-Help: <mailto:amy@example.com?subject=help%20on%20listname>
List-Subscribe: <mailto:amy@example.com?subject=subscribe%20listname>
List-Unsubscribe: <mailto:amy@example.com?subject=unsubscribe%20listname>
List-Post: <mailto:amy+listname@example.com>
List-Owner: <mailto:amy@example.com?Subject=listname>
List-Archive: <mailto:amy@example.com?subject=request%20listname%20archive>
IMPORTANCE
The IMPORTANCE, PRECEDENCE, PRIORITY, and SENSITIVITY named
parameters are used to generate respective headers on messages
posted to the list; the VALUE specification is inserted on the
respective header line.
MODERATOR_ADDRESS
The MODERATOR_ named parameters are used to establish a moderated
mailing list. All postings to the list not originating from a
moderator are sent to the list's moderator. The address of the
moderator must be specified with the MODERATOR_ADDRESS named
parameter. The moderator address determines where moderator mail
is sent when someone other than the moderator posts. The value of
that named parameter is the moderator's address. For example,
db> add test-list "<d1:[bob]test.dis, [MODERATOR_ADDRESS]
bob@example.com"
When there can be multiple moderator addresses (for instance,
both robert@a1.example.com and bob@example.com) use MODERATOR_
LIST to specify all addresses from which postings should be
passed directly to the list and not sent to the list's moderator.
MODERATOR_LIST specifies the name of a file containing a list of
moderator addresses.
If a MODERATOR_LIST parameter is used, thereby specifying who
can post directly to the list, then a MODERATOR_ADDRESS parameter
should also be present to specify the address to which to send
postings not from any moderator.
The use of the MODERATOR_ADDRESS parameter alone, without the
MODERATOR_LIST parameter, is equivalent to using MODERATOR_
ADDRESS and a MODERATOR_LIST consisting of just the one moderator
address.
Note that one use of MODERATOR_ADDRESS and MODERATOR_LIST is to
set up a list wherein anyone on the list can post directly, but
attempts to post by addresses not subscribed to the list will be
referred to a moderator. For instance,
db> add mem-list "<d1:[bob]mem-list.dis,
[MODERATOR_ADDRESS]bob@example.com,
[MODERATOR_LIST] d1:[bob]mem-list.dis"
SEQUENCE_PREFIX
The SEQUENCE_PREFIX and SEQUENCE_SUFFIX named parameters request
that a sequence number be prepended or appended to the Subject:
lines of messages posted to the list. The VALUE item gives the
full file path specification of a sequence number file. This file
is read, incremented, and updated each time a message is posted
to the list. The number read from the file is prepended, in the
case of SEQUENCE_PREFIX, or appended, in the case of SEQUENCE_
SUFFIX, to the message's Subject: header line. This mechanism
provides a way of uniquely sequencing each message posted to
a list so that recipients can more easily track postings and
determine whether or not they have missed any.
By default, a response to a previously posted message (with a
previous sequence number) retains the previous sequence number
as well as adding a new sequence number to the subject line; the
build up of sequence numbers shows the entire "thread" of the
message in question. However, the SEQUENCE_STRIP named parameter
can be used to request that only the highest numbered, i.e.,
most recent, sequence number be retained on the subject line. The
VALUE item is currently ignored and should always be NONE.
IMPORTANT NOTE
To ensure that sequence numbers are only incremented for
successful postings, a SEQUENCE_PREFIX or SEQUENCE_SUFFIX
named parameter should always appear as the last named
parameter; that is, if other named parameters are also being
used, the SEQUENCE_ named parameter should appear at the end
of the list of named parameters.
Sequence number files are binary files and must have the proper
file attributes and access permissions in order to function
correctly. In particular, sequence number files must be writeable
from the perspective of the PMDF user account. A PMDF user
account must exist for sequence number files in personal alias
databases to work properly. If your system administrators have
not created a PMDF user account, then you will not be able to use
this sequence numbering facility.
To create the file SEQ-FILE-SPEC with the proper attributes and
access permissions for use as a sequence number file, issue the
command:
$ CREATE/FDL=PMDF_COM:sequence_number.fdl seq-file-spec
TAG
The TAG named parameter can be used to prefix specified text to
the Subject: header of posted messages. The VALUE item should be
the string to be added.
USERNAME
The USERNAME named parameter can be used to set the "username"
that PMDF will consider to "own" these mailing list messages.
For instance, the PMDF QM utility will allow that username to
inspect and bounce messages in the queue resulting from expansion
of this mailing list. The VALUE item should be the username of
the account to "own" the mailing list postings. Note that the
username specified will be forced to uppercase.
4.2 – Positional Parameters
With one exception, the positional parameters in a mailing list
specification provide alternate addresses to which certain sorts
of list related activity should be directed (e.g., an address
to which errors should be sent to rather than back to the list
itself).
The positional parameters are so named for a reason: their
position in the comma separated list distinguishes which
parameter is being specified. When more than one parameter
(positional or otherwise) is specified, they must be separated
by commas. If you want to specify a positional parameter but
omit some which come first, then specify asterisks, *, for the
positional parameters which you want to omit. For example,
db> add foo-list "<d1:[sue]sample.dis, *, *, sue@example.com"
Finally, to make the use of a positional parameter conditional,
end the parameter value with an asterisk. In this case the
value associated with the parameter will only be used if the
corresponding message header line is not present in the message
being posted to the list. (The asterisk will not appear in the
message header should the parameter take effect.)
Without further ado, the positional parameters are:
error-return-address
ERROR-RETURN-ADDRESS specifies an address to replace the
message's regular envelope From: address as well as an address
to be inserted into the header as an Errors-to: address. This
header line is not generated if this address is not specified.
reply-to-address
The REPLY-TO-ADDRESS parameter specifies an address to be used as
a Reply-to: address.
errors-to-address
The ERRORS-TO-ADDRESS parameter specifies an address to be placed
on the Errors-to: header, if this address should be different
from the ERROR-RETURN-ADDRESS that is used as the envelope From:
address.
warnings-to-address
The WARNINGS-TO-ADDRESS parameter specifies an address to be
placed on the Warnings-to: header line. This header line is not
generated if this address is not specified.
comments
The COMMENTS parameter specifies a string to be placed in a
Comments: header line. This header line will add to any Comments:
header lines already present in the message being posted to the
list.
4.3 – Examples
In this example, the user sue@example.com sets up a mailing
list named sample-list. The mailing list file is the file
D1:[SUE]SAMPLE.DIS and its contents are shown in below. The
commands used to set up the list are also shown below. Mail is
posted to the list by sending messages to the address sue+sample-
list@example.com.
The use of the AUTH_LIST named parameter in the alias declaration
restricts the list such that only members of the list can post
to it. Two positional parameters, ERRORS-TO-ADDRESS and COMMENTS,
are also specified. The ERRORS-TO-ADDRESS parameter specifies
that error messages associated with the list should be sent to
sue@example.com; the COMMENTS parameter generates a Comments:
header line reading "Sue's sample list". which will appear in
each posting to the list.
Example 2 Sample Mailing list: the Mailing List File
bob@example.com
judy@example.com
ralph@example.com
sue@example.com
Example 3 Sample Mailing List: Declaring the Alias
$ SET PROTECTION=(W:R) D1:[SUE]SAMPLE.DIS
$ PMDF DB
db> add sample-list "<d1:[sue]sample.dis,[auth_list]d1:[sue]sample.dis,
sue@example.com,*,*,*,Sue's sample list"
db> set foo-list public
db> exit
4.4 – Length Restriction on List Definitions
Keep in mind the length limit of alias expansion values of 252
characters when defining a more sophisticated mailing list with
multiple parameters. Most lists can be suitably defined with just
a few of the possible mailing list parameters discussed above.
But if you have a list for which you really want to use a lot of
parameters, then you might need to define the list in stages.
For instance, to define a list friends-list that has MODERATOR_
ADDRESS, MODERATOR_LIST, CANT_LIST, USERNAME, and IMPORTANCE
named parameters, as well as error-return-address and comments
positional parameters, the list can be defined in two stages,
using a subsidiary friends-list-stage2 definition, e.g.,
db> add friends-list "<d1:[alan]friends-list-stage2.dis,
[MODERATOR_ADDRESS] alan@example.com, [MODERATOR_LIST] d1:[alan]friends-list.dis,
[CANT_LIST] d1:[alan]bozos.dis, [USERNAME] ALAN"
db> add friends-list-stage2 "<d1:[alan]friends-list.dis,
[IMPORTANCE] High, alan@example.com, *, *, *, A chatty message list for Alan's
friends - contact Alan at 555-1212 for more information"
db> set friends-list public
where the D1:[ALAN]FRIENDS-LIST-STAGE2.DIS file contains just the
line:
friends-list
and the D1:[ALAN]FRIENDS-LIST.DIS contains all the actual
recipient addresses.
5 – Subaddresses
If you enter a subaddress into your personal alias database as
a public alias, then you can have mail sent to you with that
subaddress automatically forwarded. For example, suppose that
your address is bob@example.com and mail to you from the STAFF
mailing list arrives addressed to bob+staff@example.com. If
you create a public alias for staff then mail to the address
bob+staff@example.com will be forwarded to the address associated
with the alias. For instance, the commands
db> add staff bob+staff@naples.example.com
db> set staff public
cause mail sent to bob+staff@example.com to be forwarded to
bob+staff@naples.example.com.
6 – Operation of DB
DB prompts for input with a "db>" prompt. Typing a control-z at
any point while entering a command will cause DB to immediately
stop execution. The quit-program command will also cause DB to
stop execution.
The rest of the command line after the "PMDF DB" will be scanned
for DB commands separated by backslashes, \; i.e.,
$ PMDF DB command1\command2...
Each command specified will be executed from left to right as the
command line is scanned. Placing commands on the invocation line
is optional; if any are specified DB will terminate after the
last one has been executed. If no commands appear DB will operate
by prompting the user for commands.
When first invoked, DB will open your personal alias database
file which is pointed at by the logical PMDF_PERSONAL_ALIAS_
DATABASE. PMDF establishes this logical at system startup as a
system-wide logical equated with SYS$LOGIN:ALIASES.DAT. Users
wanting to store their alias files elsewhere must redefine this
logical for their process. Note, however, that relocation of this
file will interfere with the proper operation of PMDF's public
alias features.
While entering DB commands to the "db>" prompt, the following
command interaction features are available:
o Command abbreviation: commands can be abbreviated to their
simplest, unambiguous form.
o Command completion: use the <TAB> key to automatically
complete a command. If the command is ambiguous, it will be
completed to the fullest extent possible.
o Command querying: at any point while entering a command, a
question mark, ?, can be entered to obtain immediate help on
what to do next or what options are available.
o Input files: command files can be input and executed by using
the command <INFILE with INFILE the name of the file to input.
When two angle brackets are used, <<INFILE, the commands read
from the input file will not be echoed as they are executed.
o Logging: your session can be logged to an output file by using
the command >OUTFILE with OUTFILE the name of the log file.
All commands you enter and information printed by DB will be
written to the log file. To log only the commands you type,
use the command >>OUTFILE.
o DCL commands: typing a single dollar sign, $, will create and
attach you to a spawned subprocess. To issue a DCL command
from within DB, use the command $ DCL-COMMAND with DCL-COMMAND
the DCL command you want to execute.
7 – Commands
The following sections provide full descriptions of all DB
commands. The syntax of the add and modify commands differs
between DB's default mode of operation and the FAX mode invoked
with the fax-mode command. The FAX mode versions of these
commands are described under the fax-mode command description.
7.1 – Add
Syntax: add alias-name alias-value [attributes[,...]]
With the add command an alias and its expansion value can be
added to the database currently opened. If the alias expansion
value contains any spaces, commas, or upper case characters
which should not be converted to lower case, then the expansion
value must be enclosed in double quotes. Any double quotes in
the expansion value must be "doubled" (i.e., entered as two
consecutive double quotes). Examples of these two cases are:
db> add STAFF "BOB@EXAMPLE.COM,SUE@EXAMPLE.COM,TOM@EXAMPLE.COM"
db> add JOHN-FAX """/FN=x8645/AT=Jo Doe/""@text-fax.EXAMPLE.com"
db> add LDAP-ALL <"""ldap:///dc=example,dc=edu?mail?sub?(cn=*)"""
The first add command establishes the alias
STAFF - > BOB@EXAMPLE.COM,SUE@EXAMPLE.COM,TOM@EXAMPLE.COM
This alias required quoting since it included commas. The second
add command establishes the alias
JOHN-FAX - > "/FN=x8645/AT=John Doe/"@text-fax.example.com
and was enclosed in double quotes because of the space in it, and
the need to not convert John Doe's name to "john doe". Also,
the double quotes present in the alias expansion value were
doubled; that is, each double quote, ", was specified as two
double quotes, "".
The third add command establishes the alias
LDAP-ALL - > <"ldap:///dc=example,dc=edu?mail?sub?(cn=*)"
Which means that PMDF will expand the alias into a mailing list
by performing an LDAP query using the LDAP URL specified.
As another example, consider entering the alias JD with the
simple expansion value JD573@VAXC.EXAMPLE.COM:
db> add JD JD573@VAXC.EXAMPLE.COM
[Entry added to database]
db> show JD
Key Value
---------- -----------------------------
jd jd573@vaxc.example.com
[1 entry shown]
db>
Note that the alias name along with its translation value was
converted to lower case. DB will always translate the name of
an alias to lower case; PMDF does not do case sensitive alias
matching. To prevent the alias translation value from being
converted to lower case, enclose it in double quotes; e.g.,
db> modify JD "JD573@VAXC.EXAMPLE.COM"
[1 entry modified]
db> show JD
Key Value
---------- -----------------------------
jd JD573@VAXC.EXAMPLE.COM
[1 entry shown]
db>
The optional attributes parameter of the add command can be one
or more comma separated keywords selected from the list:
mail-address
Treat this alias as a mail address; i.e., set the mail address
attribute flag for this alias. Default when in either normal or
FAX mode. Not set when an "override on" command has been issued.
non-mail-address
Do not treat this alias as a mail address; i.e., clear the mail
address attribute flag for this alias.
fax-address
Treat this alias as a FAX address; i.e., set the FAX address
attribute flag for this alias. Default when in FAX mode. Not set
when an "override on" command has been issued.
non-fax-address
Do not treat this alias as a FAX address; i.e., clear the FAX
address attribute flag for this alias.
public
Mark this alias as being publicly accessible. Other users can
reference this alias by sending mail to an address of the form
USER+ALIAS@LOCAL-HOST. When this alias is used in outgoing mail
and is not expanded into component addresses, it will appear
in the message in the form USER+ALIAS@LOCAL-HOST. Public is the
opposite of the private attribute described below.
private
Mark this alias as being private. Other users will not be able
to use this alias. If this alias appears in outgoing mail (and
is not expanded into its component addresses) it will appear as
an unexpanded RFC 822 group address: ALIAS: ;. Private is the
opposite of the public attribute described above.
expand
This attribute forces the expansion of the alias into its
component addresses. All of the component addresses will be
listed in the message header as the alias expands.
no-expand
This attribute inhibits the expansion of the alias into its
component addresses. The alias itself will appear in the header
in some form; see the description of the public and private
attributes above for details on the forms the alias can take.
pass-receipts
This attribute enables the passage of requests for delivery and
read receipts through to all recipients as the alias is expanded.
Note that allowing the passage of such a request to a large
distribution list can result in a lot of return mail.
block-receipts
This attribute disables the passage of requests for delivery
and read receipts through to all recipients as the alias is
expanded. Requests for such receipts are honored at the time
the alias expands; in effect the alias is treated as the message
destination.
When an alias is entered with the add command at the "db>"
prompt, the alias will automatically be given the mail address
attribute unless an "override on" command has been previously
issued or the non-mail-address keyword is specified with the add
command.
7.2 – Close
Syntax: close
The close command closes the currently open alias database.
Use the open command to open a different database. DB will
automatically close any open database when the exit-program or
quit-program commands are issued.
7.3 – Copy
Syntax: copy from-alias-name to-alias-name
The copy command creates a new alias with the name to-alias-name
and associates to it the expansion value of the alias with the
name from-alias-name. A subsequent change to the "from" alias
will not affect the "to" alias. Any attributes associated with
the "from" alias will be copied to the "to" alias regardless
of whether or not an "override on" command has been issued
previously.
db> add Postmaster "system@thor.example.com"
[Entry added to database]
db> copy Postmaster Postmast
[1 entry copied]
db> show Post*
Key Value
---------- -----------------------------
postmast system@thor.example.com
postmaster system@thor.example.com
[2 entries shown]
db>
7.4 – Exit-Program
Syntax: exit-program
The exit-program and quit-program commands are identical and each
causes DB to close any open database and then exit. Note that
in FAX mode there is no exit-program command, only an exit-mode
command. To immediately exit DB from FAX mode, use the quit-
program command.
7.5 – Fax-Mode
Syntax: fax-mode
The fax-mode command puts you into FAX mode - a mode which
attempts to simplify the creation and modification of aliases
whose expansion values are FAX addresses. In this mode, the DB
command prompt changes to "db.fax>". To exit this mode use the
command exit-mode. (From this mode there is no exit-program
prompt; to immediately exit FAX mode, use the quit-program
command.)
When in FAX mode, aliases created with the add command are given
the attributes mail-address and fax-address. Only addresses with
both of these attributes can be manipulated with the add, copy,
modify, rename, remove, set, and show commands while in FAX mode.
Note, however, that if the "override on" command has been issued,
then all attribute checking is bypassed and no attributes will be
assigned to aliases created with the add command.
In FAX mode, the add and modify commands have a different syntax
then their counterparts in the normal DB mode. (Recall, you can
always tell which mode you're in by the DB prompt: in normal mode
the prompt is "db>"; in FAX mode the prompt is "db.fax>".)
7.5.1 – Add (FAX Mode)
Syntax: add alias-name fax-number number domain domain-name
[[item value]...]
To add an alias in FAX mode, the alias name, FAX telephone
number, and domain name (e.g., text-fax.example.com) must all
be supplied. If the FAX telephone number contains any spaces or
commas, then it must be enclosed in double quotes.
Additional items of information can be specified. Note that when
specifying a value for an item, the value must be enclosed in
double quotes if it contains any spaces, commas, or characters
you don't want converted to lower case. Furthermore, any double
quotes appearing in the value must be changed to two consecutive
double quotes. The names of the additional items and their
meanings are:
1-address
The recipient's address can be displayed in one to five lines
on the FAX cover page. These items are used to specify each
individual line of the address. If no address lines are
specified, then no address lines will be displayed on the FAX
cover page. If intermediate address lines are omitted (e.g.,
lines 1 and 3 specified, line 2 omitted), then blank address
lines will be displayed in place of the omitted lines.
authorization
Your site might require you to specify an authorization or
access code in order to send FAXes. You can specify any required
authorization or access codes with this item.
fax-modem-number
The telephone number which the transmitting FAX modem should use
when identifying itself to the receiving FAX device. While the
receiving FAX device might print this number across the top or
bottom of received pages, it is not placed on the FAX by PMDF-
FAX (the sending FAX modem). To control the FAX number which is
displayed on the cover page as your FAX telephone number, use the
"my-fax-number" item.
my-fax-number
The FAX telephone number to display on the FAX cover page.
my-organization-name
The name of your organization, group, or department to display
across the top of each transmitted FAX page.
my-telephone-number
The recipient's telephone number to be printed on the FAX
cover page. If not specified, then no telephone number will be
displayed.
For example, to specify a FAX address for John Doe at Example
Company, Inc., the following command can be issued while in FAX
mode:
db.fax> add john-fax fax-number "(714) 555-1212" domain
"text-fax.example.com" recipient "John Doe" 1-address
"Example" telephone "(714) 555-1212"
db.fax> show john-fax
Alias name: john-fax
Recipient's FAX number: (714) 555-1212
Recipient's name: John Doe
Address line 1: Example
Recipient's telephone number: (714) 555-1212
Domain specification: @text-fax.example.com
[1 entry shown]
db.fax>
Note that all of the values entered were enclosed in double
quotes. This is often the safest policy as it avoids having to
worry about spaces or other characters which can appear in the
values to be specified and it prevents values entered from being
converted to lower case.
recipients-name
The name of the recipient as it will appear on the cover page
of the FAX message. Be sure to enclose the recipient's name in
double quotes so as to not have it converted to lower case. If
not specified, then no recipient's name will be displayed on the
FAX cover page.
send-after
Do not send the FAX until after the specified date and time. The
date and time must be given using the standard OpenVMS date-time
specification format. For example, the date-time specification
"3-FEB-2012 22:35:00" requests that the FAX not be transmitted
until after 22:35 (10:35 PM) on February 3, 2012.
setup
A PostScript file to first process before processing your
message. The filename must specify a full path to the file and
the file must be world readable. Text library modules can also be
specified using the format file-spec(module-name); e.g.,
setup D1:[INIT]PSLIB(LETTERHEAD)
where the text library is the file D1:[INIT]PSLIB.TLB and the
module name is LETTERHEAD.
7.5.2 – Modify (FAX Mode)
Syntax: modify alias-name [[item value]...]
With the modify command, various items associated with a FAX
address can be altered or removed, and new items can be added
to the FAX address. To alter or add an item simply specify the
item name and new value. To delete an item, simply give the item
name without any associated value. The domain-name and fax-number
items, described below, cannot be deleted.
In addition to the items which can be specified with the add
command, two additional items can be specified. These items are:
fax-number
The FAX number to send the FAX message to.
domain-name
The domain name associated with the FAX address.
Continuing with the example of the previous subsection, we can
use the modify command to delete the use of the 1-address line
and to change the recipient's telephone phone number:
db.fax> modify john-fax 1-address
[1 entry modified]
db.fax> modify john-fax telephone-number "(714) 555-1212"
[1 entry modified]
db.fax> show john-fax
Alias name: john-fax
Recipient's FAX number: (714) 555-1212
Recipient's name: John Doe
Recipient's telephone number: (714) 555-1212
Domain specification: @text-fax.example.com
[1 entry shown]
db.fax>
7.6 – Modify
Syntax: modify alias-name new-alias-value
The modify command is used to replace the expansion value of an
alias with a new expansion value.
db> add postmaster "system@thor.example.com"
[Entry added to database]
db> show postmaster
Key Value
---------- -----------------------------
postmaster system@thor.example.com
[1 entry shown]
db> modify postmaster "JOHN@example.COM"
db> show postmaster
Key Value
---------- -----------------------------
postmaster JOHN@example.COM
[1 entry shown]
db>
Wild cards can be used when specifying the alias name in order to
modify one or more aliases simultaneously.
7.7 – Open
Syntax: open database-name [huge|long|short]
The OPEN command opens an alias database after first closing
any currently opened database. If the database to be opened
already exists, then DB will automatically determine whether
or not the database is a "huge" (stores 80/1024 character long
alias names/values), or "long" (stores 80/132 character long
alias names/values) or "short" (stores 32/80 character long alias
names/values). If the database does not already exist, then it
will be created. If the SHORT, LONG, or HUGE keyword is specified
after the database file name, then the database created will be
of that type. If no keyword is specified, the created database
will be a long database.
When DB is first invoked, the personal alias database pointed
at by the logical PMDF_PERSONAL_ALIAS_DATABASE is automatically
opened. If it doesn't exist, a long database is automatically
created. Note that because of this, if you want a huge or short
database instead of a long one, you must create a database file
of the desired size either (e.g. for a huge database) using "pmdf
crdb/huge", or by using the DB "open other-file huge" command
then renaming other-file to the PMDF_PERSONAL_ALIAS_DATABASE
name.
7.8 – Override
Syntax: override on|off
The override command is useful when looking at or modifying
databases other than an alias database. Ordinarily the database
manipulation commands, add, copy, modify, rename, remove, set,
and show will only operate on aliases with the mail-address
attribute. When the command "override on" has been issued, these
commands can be used to manipulate any entry in the database
regardless of its attributes (or lack thereof).
The "override off" command negates the "override on" command.
7.9 – Quit-Program
Syntax: quit-program
The exit-program and quit-program commands are identical and each
causes DB to close any open database and then exit. Note that
in FAX mode there is no exit-program command, only an exit-mode
command. To immediately exit DB from FAX mode, use the quit-
program command.
7.10 – Remove
Syntax: remove alias-name
With the remove command, one or more aliases can be removed from
the database. Wild cards can be used when specifying aliases to
be removed. For instance, to remove all aliases from a database,
issue the command "remove *".
7.11 – Rename
Syntax: rename old-alias-name new-alias-name
The rename command is used to rename an alias without altering
its expansion value:
db> add postmaster "system@thor.example.com"
[Entry added to database]
db> show postmaster
Key Value
---------- -----------------------------
postmaster system@thor.example.com
[1 entry shown]
db> rename postmaster post
[1 entry renamed]
db> show post
Key Value
---------- -----------------------------
post system@thor.example.com
[1 entry shown]
db>
7.12 – Set
Syntax: set alias-name attributes[,...]
The set command can be used to grant or remove attributes from
aliases. The alias name specification can include wild cards.
The allowable attribute names are listed in the add command
description described under the "add" command.
7.13 – Show
Syntax: show [alias-name [attributes]]
The show command is used to list the contents of a database. The
optional attributes keyword, when supplied, causes the attributes
associated with each alias to also be displayed:
db> add postmaster "system@thor.example.com"
[Entry added to database]
db> show postmaster attributes
Key Value
---------- -----------------------------
postmaster system@thor.example.com
Attributes: private,expand,block-receipts,mail-address
[1 entries shown]
db>
The alias name specification can contain wild cards. To see
all entries with the mail-address attribute, issue the command
"show"; to see absolutely all entries, first issue the command
"override on" followed by the command "show"
7.14 – Wildcards
Syntax: wildcards ignore|interpret
By default, the characters * and % in alias names are interpreted
as wildcards: an asterisk, *, will match zero or more characters
while each percent sign, %, will match precisely one character.
The command "wildcards ignore" will cause DB to not interpret
asterisks or percent signs as wildcards; the command "wildcards
interpret" will resume interpretation of wildcards.
7.15 – Write
Syntax: write file-name [alias]
The write command is used to create a command file which, when
fed back into DB with the < or << commands, will recreate the
entire database. If the alias keyword is specified, then a PMDF
alias file (using PMDF's alias file format) will instead be
produced.
For instance, the following commands will create a database named
DB2.DAT which duplicates the database DB1.DAT:
db> open db1.dat
db> write make.com
db> open db2.dat
[creating database]
db> <<make.com
db>
The above example presupposes the existence of a database named
DB1.DAT. The file MAKE.COM created with the write command is an
ordinary text file which can be edited with any text editor.
Note that this is not an efficient way to duplicate a database
- the DCL COPY command works much faster. The write command is
intended as a means of creating a textual representation of a
database which can be edited as a text file and later turned back
into a database.