The PMDF MOVEIN utility migrates mailboxes from one message
    store to another, or from one account to another. The supported
    message stores are: VMS MAIL (the "native" message store), the
    PMDF MessageStore, and the PMDF popstore. When moving from
    or to the popstore, only messages in the inbox are migrated.
    For migrations from VMS MAIL to msgstore, or from one msgstore
    account to another, messages in all folders are moved.

    Forwardings from the source message store account to the
    destination message store account are automatically established
    for each migrated user. Note, however, that use of the -
    NOFORWARDING switch can compromise this robustness.

    As it is not possible to temporarily block delivery of mail to
    a user by VMS MAIL, when migrating mail from a VMS MAIL account,
    the PMDF MOVEIN utility should not be run on an active system.
    Running it on an active system can lead to loss of mail when the
    migration utility migrates a user's NEWMAIL folder and, at the
    same time, VMS MAIL delivers a new message to that same folder.
    Depending upon the timing, that new message can be left behind
    and not migrated. To prevent this from happening, ensure that
    PMDF's local delivery channel is not running (e.g., stop the
    MAIL$BATCH queue or whatever queue the l channel runs in) and
    that any other VMS MAIL applications are not running (e.g., no
    login users using VMS MAIL, no Pathworks users, DECnet MAIL-11
    shutdown, etc.).

    When migrating mail from a popstore or msgstore account, and to
    a popstore or msgstore account, the PMDF MOVEIN utility performs
    all of the necessary locking so as to allow migrations to be
    carried out on an active system without loss of mail.

    The basic inputs to the utility are: the names of the source and
    destination message store; the names of the source store user
    accounts to migrate; optionally, the names of the destination
    store user accounts to create; and, also optionally, passwords
    to set for these new accounts. The source store username is
    assumed for the destination store if a desintation username is
    not specified. That is, by default, the name of the account in
    the destination store is the same as that in the source store.

    When a username is supplied on the command line, then just that
    one user account is migrated. To migrate multiple accounts,
    do not specify a username on the command line and instead use
    the /INPUT qualifier. Each line of the input file specifies
    the username of a single source store account to migrate. In
    addition, a line can specify a password to associate with the new
    account in the destination store, and the username to create in
    the destination store. The password and destination username, if
    supplied, must be on the same input line following the username
    with one or more white space characters separating each of the
    three. If the password contains a space itself, it must be
    enclosed in double quotes. To specify a destination username
    without specifying a password, the password must be specfied as
    an empty string (two double-quotes next to each other).

    Comment lines can appear in the input file: a comment line is any
    line which begins with a # or ! character. Leading and trailing
    white space characters on lines are ignored. The following sample
    input should give the flavor of input files:

    ! A comment line
    !
    ! to supply a password and destination username:
    angel "alex's password" alex
    bailey blakes-password blake
    !
    ! to supply a destination username, but no password:
    chris "" casey
    !
    ! to supply a password but no destination username:
    dana danas-password
    !
    ! to supply neither a password nor a destination username:
    emile

    When no username or input file is specified, input lines are read
    from SYS$INPUT. The format of those input lines is identical to
    that of lines read from an input file. Input is terminated by
    typing a CTRL/Z.

    When migrating to a msgstore or popstore account, the destination
    account is automatically created. If a password is supplied,
    then the password is set in the new account. If no password is
    supplied, then the new account is marked with the PWD_ELSEWHERE
    flag. Normally, that causes authentication to then be performed
    against the SYSUAF database. See the popstore documentation for
    further information. When migrating from VMS MAIL, the owner
    field in the new account is set using the owner field from the
    SYSUAF. When migrating between a popstore and msgstore account,
    the owner field of the destination account is set from the source
    account.

    If there already is an pre-existing MessageStore or popstore
    account-such as when migrating from the popstore to MessageStore-
    then the migration fails unless /USE_EXISTING is specified.
    Moreover, if the existing account has the MIGRATED flag set,
    then the migration fails unless /FORCE_MIGRATE is specified. When
    the account is successfully migrated, the MIGRATED flag is set in
    the account.

                                   NOTE

       After a successful migration, the account in the source
       message store is left intact with its mail in place. In
       the case of migration from a popstore to MesageStore store
       type with the same username (or vice-versa), the account is
       changed in place from the one store type to the other.

    The PMDF MOVEIN utility is extremely careful to back out of a
    failed migration, leaving the user account in the source message
    store in its original state. When multiple accounts are migrated,
    a failure to migrate an account does not terminate the utility.
    Instead, the utility backs out of the migration for the failed
    account and continues on to the next account. Failures are
    reported to SYS$ERROR. The /EXCEPTION_FILE qualifier can be used
    to log errors in an exception file. The format of the exception
    file is suitable for re-use as an input file.