Access can be established using an explicitly specified
    account, a default proxy account, an application-specific
    default account, or a nonprivileged default account.  The
    following steps are used to determine if a remote user
    will be granted access.  (Note that access control checking
    is handled in the same fashion for a local user who specifies
    the local node or 0 in a command.)

    1.  If explicit access control information is provided, this
        information is evaluated first.

        When an empty access control string is provided, as in:

        $ DIR PRKCHP""::
        $ DIR 0""::

        No proxy checking is performed.  Instead, access checking
        is continued at Step 3.

        When both a username and password are explicitly provided,
        as in the following examples:

        $ DIR PRKCHP"PRKCHP_USER PASSWD"::
        $ DIR 0"PRKCHP_USER PASSWD"::
        $ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER PASSWD" ALL

        that account must be accessible using that password (even if
        a valid proxy exists), in order for access to succeed.  If
        this fails (say, for example, the password is wrong or the
        account does not exist), then no further checking is
        performed and access is denied.

        When only the username is explicitly provided, as in:

        $ DIR PRKCHP"PRKCHP_USER"::
        $ DIR 0"PRKCHP_USER"::
        $ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER" ALL

        the local proxy database is searched for one proxy record
        matching source_node::username_on_source.  An exactly
        matching proxy record is preferred over a wildcard match.
        (Refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL PROXIES
        for more information if a wildcard proxy is present.)
        If a match is not found, then no further checking is
        performed and access is denied.

        If a match is found, the selected proxy record is examined
        to determine if access should be attempted using this
        explicitly specified local username.  It does not
        matter if this local username is specified in the proxy
        record as the default account or not.  As long as that
        username is included somewhere in that proxy record, then
        access will be attempted via that account.

        For example, if the following command were issued by SYSTEM
        on LAMCHP:

        $ DIR PRKCHP"PRKCHP_USER"::

        And PRKCHP had one of the following proxy records in its
        database:

        LAMCHP::SYSTEM
           PRKCHP_USER

        LAMCHP::SYSTEM
           PRKCHP_USER (D)

        LAMCHP::SYSTEM
           SYSTEM (D)    PRKCHP_USER

        Then access would be attempted using the explicitly
        specified PRKCHP_USER account.

        If this access succeeds, the remote user is mapped into the
        specified account and granted the rights and default
        privileges for that account.  If there is a problem (say,
        for example, the directory for that account does not have
        the correct owner), then no further checking is performed
        and access is denied.

    2.  If no access control information was provided at all (not
        even an empty string), as in:

        $ DIR PRKCHP::
        $ DIR 0::
        $ MCR NCL SHOW NODE PRKCHP ALL

        The proxy database is scanned for a proxy record matching
        source_node::username_on_source.  (A default wildcard proxy
        may not be sufficient. Refer to HELP NETWORK_MANAGEMENT
        ACCESS_CONTROL PROXIES for more information.)

        If no matching proxy record is found, then access
        control checking proceeds to Step 3.

        If a matching proxy record is found, but it does not
        specify a default account, then access will NOT be
        attempted using that proxy.   Instead, access checking
        proceeds to Step 3.

        If the matching proxy record specifies a default account,
        then access is attempted using that account.  If this
        succeeds, the user is granted the rights and default
        privileges of this default account.  If this fails (say,
        for example, the directory for that account does not
        have the proper owner), then no further checking is done
        and access is denied.

    3.  If an application-specific default is present, as
        indicated by the session control application user name
        attribute, then access will be attempted using that
        account.  If this access fails (say, for example, the
        specified account is non-existent), then no further
        checking is performed and access is denied.

        If no default was specified for that particular
        application, access checking is continued with Step 4.

                            --- NOTE ---

        The CMIP Management Listener (CML) application
        uses this method of access to allow remote users to
        perform NCL SHOW commands.  This is why the session
        control application CML user name is usually set to
        CML$SERVER, and this account is generally granted
        the NET$EXAMINE right.  Even if a remote user does
        not include explicit access control information in
        an NCL command, and even if he does not possess a
        default proxy account with NET$EXAMINE or BYPASS,
        his NCL SHOW requests will still be permitted via
        the CML$SERVER account.

    4.  If a non privileged default has been established,
        as indicated by the session control non privileged
        user attribute, then access will be attempted using
        that account.  If this access fails, or if the
        session control non privileged user attribute has
        not been set, then access is denied.