NCLHELP.HLB  —  NCL Introduction, Default Context
    When you wish to perform a series of commands on a particular entity
    (either on your local node or a remote Phase V node), you may choose
    to set your default NCL context.  The SET NCL DEFAULT ENTITY command
    allows you to specify an entity to be used for further NCL commands.
    Similarly, the SET NCL DEFAULT ACCESS command allows you to specify
    access control information.

1  –  OpenVMS

    The NET$EXAMINE right is required to issue SET NCL DEFAULT ENTITY
    and SET NCL DEFAULT ACCESS commands.  Refer to HELP
    NETWORK_MANAGEMENT ACCESS_CONTROL RIGHTS_IDENTIFIERS for
    information on rights identifiers.

    Once established, default entity and access control information
    will remain in effect for the duration of an NCL session until
    it is modified by subsequent SET NCL DEFAULT commands.  When
    supplying access information, both the username and password
    should be provided in a single command.  Here are a few
    acceptable forms of the SET NCL DEFAULT command:

    NCL>SET NCL DEFAULT ENTITY -
    _NCL>NODE nodename"username password" [subentity|subentities]

    NCL>SET NCL DEFAULT ENTITY NODE nodename [subentity|subentities],-
    _NCL>ACCESS BY USER=username, PASSWORD=password

    NCL>SET NCL DEFAULT ACCESS BY USER=username, PASSWORD=password,-
    _NCL>ENTITY NODE nodename [subentity|subentities]

    When a SET NCL DEFAULT command contains new access information but
    lacks a default node entity, as in:

    NCL>SET NCL DEFAULT ACCESS BY USER=username, PASSWORD=password

    NCL>SET NCL DEFAULT ENTITY [subentity|subentities],-
    _NCL>ACCESS BY USER=username, PASSWORD=password

    NCL>SET NCL DEFAULT ACCESS BY USER=username, PASSWORD=password,-
    _NCL>ENTITY [subentity|subentities]

    then the new access information is stored, but it will not be
    used until some subsequent SET NCL DEFAULT ENTITY NODE command
    is issued.  In the following example, new access control
    information is stored:

    NCL>SHOW NCL DEFAULT
    No NCL Default Access has been set
    NCL Default Entity ()
    NCL>SET NCL DEFAULT ACCESS BY USER=user1, PASSWORD=goodpassword
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity ()

    but that access control information remains unused until the
    default node entity is modified.  The following SET command
    would then result in the establishment of a connection to node
    remnod using the user1 account:

    NCL>SET NCL DEFAULT ENTITY NODE remnod
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity Node remnod

    Once you have set a default node entity, all subsequent SET NCL
    DEFAULT ENTITY [subentity | subentities] commands apply to that
    node until the user attempts to modify the default node entity.
    For example, now that the default node entity is remod, in order
    to set the default entity to Session Control on node remnod, you
    can do so without re-specifying the node entity, as in:

    NCL>SET NCL DEFAULT ENTITY Session Control
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity Node remnod Session Control

    To change to another subentity on the remote node, you must
    include (or re-specify) any subentities beneath the node entity.
    Even though the current default entity in this example is Node
    remnod Session Control, you must re-specify the Session Control
    subentity if you want to set default to a lower subentity on
    that node.  In other words, NCL would not parse the following
    command because the Session Control entity needs to be
    re-specified.  Since the command could not be parsed, the NCL
    defaults remained unchanged:

    NCL>SET NCL DEFAULT ENTITY Application fal
    %NCL-E-INVALIDCOMMAND, unrecognized command
    SET NCL DEFAULT ENTITY \Application\ fal
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity Node remnod Session Control

    Instead, this command would be necessary to change the default
    to a lower subentity on node remnod:

    NCL>SET NCL DEFAULT ENTITY Session Control Application fal
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity Node remnod Session Control Application fal

    Note that in the example above the "fal" instance identifier
    specified a particular instance of a Session Control Application.
    But it is also acceptable to use wildcards to specify the default
    entity.  In the example below, the wildcard "*" is used as an
    instance identifier to refer to all session control applications
    on the default node.

    NCL>SET NCL DEFAULT ENTITY Session Control Application *
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user1, Password xxx
    NCL Default Entity Node remnod Session Control Application *

    If default access control information and the default entity
    were then modified, but no node entity was specified, as in:

    NCL>SET NCL DEFAULT ACCESS BY USER=user2, PASSWORD=badpassword,
    _NCL>ENTITY Session Control
    NCL>SHOW NCL DEFAULT
    NCL Default Access by User user2, Password xxx
    NCL Default Entity Node remnod Session Control Application *

    The new default access information would be stored, but contrary
    to the default access information displayed by SHOW NCL DEFAULT,
    the connection to node remnod through the user1 account will
    remain in use until the default node entity is changed.

    This next command would request a new connection to node remnod
    using the latest default access information (through the user2
    account), but the connection would fail because the password
    information provided earlier for the user2 account was incorrect:

    NCL>SET NCL DEFAULT ENTITY NODE remnod
    %NCL-E-REQUESTFAILED, command failed due to:
    -CML-E-SESSPROB, error returned from session control
    -IPC-E-BADUSER, access control rejection
    -NET-F-REMOTEDISCONN, connection disconnected by remote user
    %NCL-E-NOCONNECTION, cannot establish CMIP connection to remote node
    set ncl default entity node remnod

    Whenever a connection to a default entity node fails, the default
    entity will be reset to the local node entity.  Default subentity
    information is cleared as well because subentities are node-
    specific.  The default access information will be left as is, but
    it will remain unused until the default node entity is reset.  For
    example, after the above failure to modify the default node entity,
    the NCL defaults would look like this:

       NCL>SHOW NCL DEFAULT
       NCL Default Access by User user2, Password xxx
       NCL Default Entity ()

2  –  Tru64 UNIX

    When you are using NCL commands to manage one particular
    entity, either set up a default for the entity, access control
    information for the entity, or both. For example:

    ncl> set ncl default entity node .mfg.cadcam session control
    ncl> show ncl default entity
    ncl default entity = node .mfg.cadcam session control

    The set ncl default access command sets up default access
    control independently of the default entity. Once established,
    the default access control is applied to any command where
    an explicit by prepositional phrase is omitted and no user
    information is given with the node name.

    ncl> ! on node .admin.finance
    ncl> set ncl default access by user=j_smith, password=DoNotUse
    ncl> show ncl default access

    ncl Default access = user name=j_smith
           account=
           proxy=false

    ncl> show node .admin.artists session control application -
    _ncl> graphics_exchange all counters

    The set ncl default access overrides an embedded access control
    value in the entity.
Close Help