NCLHELP.HLB  —  Directory Module, DSA
 A DSA entity enables you to manage a DSA for a given node.
 A DSA entity must be created and enabled before it can receive
 connections from directory applications or other DSAs.

 There is only one DSA entity per node. A DSA entity has four subentities,
 illustrated below:

                               DSA entity
                                    |
             +--------------+-------+------+--------------+
             |              |              |              |
          Naming       Subordinate     Superior        Accessor
          Context      Reference       Reference       entity
          entity       entity          entity

1  –  Accessor

 An Accessor entity can be used to represent a user of the DSA
 such that the DSA can verify the user's identity when they
 attempt to connect.

 Normally, a DSA verifies the identity of a directory user by
 reference to directory information. However, an Accessor entity
 provides a way of giving a DSA information about a user without
 having to represent that user in the directory. This might be useful
 in some problem solving situations. However, it is not the recommended
 way to represent users of the DSA.

 Note that the Accessor entity is a volatile entity. If you delete the
 DSA entity for a given system, then all Accessor entities for that system
 are deleted permanently.

 Note also that an Accessor entity only permits a user to identify
 themselves to this DSA. If the user wants identify themselves to
 another DSA, then that DSA also needs an Accessor entity.

1.1  –  Characteristics

 An Accessor entity has only one characteristic attribute:
 Password. You can use the SET directive on this attribute.

 Syntax:

 	SET  DSA ACCESSOR <name> PASSWORD <value>

 where <name> is the name of the user whose password you want to
 set a new value, and <value> is the new value for the password.
 Specify the password as a Latin1 string. There is no default value.
 The name and the password must both be quoted. The password is
 a case sensitive attribute.

1.2  –  Directives

 You can use the CREATE, DELETE, SET and SHOW directives with the
 Accessor entity.

 The CREATE and DELETE directives are used to create and delete an
 Accessor entity.

 The SET and SHOW directives are used to set and show attributes,
 respectively.

1.2.1  –  CREATE

 Use this directive to create an Accessor entity of the specified name.

 Syntax:

 	CREATE DSA ACCESSOR <name> PASSWORD <value>

 You must quote the name and password. For example:

  > CREATE DSA ACCESSOR "/C=US/O=Abacus/CN=Manager" PASSWORD "mumble"

1.2.1.1  –  Arguments

 The CREATE directive has an identifier and one argument.
 The argument is mandatory. The argument is:

 -	PASSWORD

 The identifier specifies the name of a directory user.
 This is in the form of a distinguished name or AE title.

 The PASSWORD argument identifies the password for the user.
 Specify this argument in the following format:

 	PASSWORD <value>

 where <value> is the password is a Latin1 string of
 between 1 and 128 characters long. The password value must be quoted.

1.2.1.2  –  Errors

 The CREATE directive can return one of the following errors:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 This means that the DSA is in one of the transitional states
 UPDATING, CREATING, ENABLING, or DISABLING. The DSA
 must be in state ON or OFF when you create an Accessor entity.
 The response indicates what state the DSA is in.

 REASON:         Already Exists
 DESCRIPTION:    This Accessor entity already exists.

 This means that the name you specified is already the name of
 an Accessor entity.

 REASON:         Invalid Name
 DESCRIPTION:    The entity name is not a valid directory name.

 This means that the name you specified is not in the
 distinguished name format. The response displays the invalid
 name component.

1.2.2  –  DELETE

 Use this directive to delete an Accessor entity.

 Syntax:

 	DELETE DSA ACCESSOR <name>

1.2.2.1  –  Errors

 The DELETE directive can return the following error:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 This means that the DSA is in one of the transitional states
 UPDATING, CREATING, ENABLING, or DISABLING. The DSA
 must be in state ON or OFF when you delete an Accessor entity.
 The response indicates what state the DSA is in.

1.2.3  –  Examples

 	> CREATE DSA ACCESSOR "/C=US/O=Abacus/CN=Jon Smith" -
 	_> PASSWORD "mumble"

 	> SHOW DSA ACCESSOR "/C=US/O=Abacus/CN=Jon Smith"

 	The first command creates an Accessor entity and the
 	second command displays it.

         Note you cannot use the SHOW directive to display
         the Password attribute of an Accessor entity, because
         it is a read-only attribute.

 	> DELETE DSA ACCESSOR "/C=US/O=Abacus/CN=Jon Smith"

 	This command deletes the Accessor entity.

1.2.4  –  SET

 Use the SET directive to change the value of the Accessor
 Password attribute.

 Syntax:

 	SET DSA ACCESSOR <name> PASSWORD <value>

 where <value> is the value you want to set for the
 Password attribute. The value must be quoted.

1.2.5  –  SHOW

 Use the SHOW directive to display an Accessor entity.
 The Password characteristic attribute is not displayed.

 Syntax:

 	SHOW DSA ACCESSOR <name>

 You can also use the wildcard "*" in a SHOW directive, to display
 a list of all Accessor entities, for example:

 SHOW DSA ACCESSOR *

1.3  –  Identifier

 Each Accessor entity is uniquely identified by a name. This is
 the name of the user that you want to give access to the DSA, and
 must be in same format as a distinguished name or an AE title.
 For example, "/C=US/O=Abacus/CN=Jon Smith".

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE title. Refer to the CREATE directive
 for more information on how to create an Accessor entity.

2  –  Common Datatypes

 Many of the management directives of the DSA entity and its
 subentities require you to specify AE titles, distinguished
 names, and presentation addresses.

 The syntaxes of these commonly used datatypes are described in the
 subtopics listed below.

2.1  –  AE Title

 An AE title is a unique name used in many management directives
 of the Directory Module to identify a DSA.

 The syntax for AE titles supported by the management directives of
 the Directory Module is the same as the distinguished name syntax
 supported by HP's X.500 Information Manager (DXIM).

 For example:

 	AE Title = "/C=US/O=Abacus/OU=Sales/CN=dsa"

 Note that the AE title is quoted.

 Refer to Distinguished_Name for more information on how to specify
 an AE title or distinguished name in a management directive.

2.2  –  Distinguished Name

 A distinguished name uniquely identifies a directory user. The
 syntax of a distinguished name is exactly the same as the syntax
 of an AE title.

 A distinguished name is a sequence of one or more relative
 distinguished names (RDNs) each preceded by a / character.

 Each RDN is a sequence of one or more attribute value statements,
 such as commonName=John. Usually an RDN contains only one attribute
 value statement, but it is possible to specify a sequence of
 attribute value statements separated by commas, for example:

 	commonName=John,organizationalUnitName=Sales

 Many of the attribute types, such as commonName and
 organizationalUnitName, can be abbreviated. For example, the
 commonName can be abbreviated to cn, and organizationalUnitName can
 be abbreviated to ou.

 In management directives, a distinguished name (or AE title) must
 always be enclosed in quotation marks, for example:

 	Distinguished Name = "/C=US/O=Abacus"

 Values in a distinguished name can include commas, equals signs,
 and backslash characters, in which case the value must be quoted.
 For example, commonName='Smith,'

 The following is an example of a distinguished name that has
 three RDNs, the last of which is quoted because it contains an
 equals character:

 	Distinguished Name = "/C=US/O=Abacus/CN='sales=toys'"

 Note the use of two types of quotation mark, "..." to enclose
 the entire distinguished name, and '...' to enclose the value
 sales=toys, which contains an equals sign.

2.3  –  Presentation Address

    The PresentationAddress datatype defines the format that should
    be used for all presentation addresses in OSI applications. It is
    also the format in which presentation addresses are displayed by
    OSI network management.

    This datatype is a Latin1 string. Its values must conform to the
    following syntax (shown in BNF). This syntax is an extension
    of the Internet standard for representing OSI presentation
    addresses.

    Note that the numbers 1 to 12 shown to the right of this
    syntax description are not part of the syntax. They refer
    to explanations which are provided at the end of this syntax
    description.

    <presentation-address> ::= [[[ <psel> "/" ] <ssel> "/" ]
                               <tsel> "/" ] <network-address-list>

    <psel>         ::= <selector>

    <ssel>         ::= <selector>

    <tsel>         ::= <selector>

    <selector>     ::= '"' <otherstring>  '"'           1
                       | "#" <digitstring>              2
                       | "'" <hexstring> "'H"
                       | ""

    <network-address-list> ::= <network-addr> [ "|" <network-addr> ]
                       | <network-addr>

    <network-addr> ::= <network-address> ["," <network-type> ]

    <network-type> ::= "CLNS" | "CONS" | "RFC1006"      3

    <network-address>      ::= "NS" "+" <dothexstring>  4
                       | <afi> "+" <idi> ["+" <dsp>]
                       | <idp> "+" <hexstring>          5
                       | RFC1006 "+" <ip> ["+" <port>]  6

    <idp>          ::= <digitstring>

    <dsp>          ::= "d" <digitstring>                7
                       | "x" <dothexstring>             8
                       | "l" <otherstring>              9
                       | "RFC1006" "+" <prefix> "+" <ip> ["+" <port>
                       ["+" <tset>]]
                       | "X.25(80)" "+" <prefix> "+" <dte>
                       [ "+" <cudf-or-pid> "+" <hexstring> ]
                       | "ECMA-117-Binary"
                       "+" <hexstring> "+" <hexstring>
                       "+" <hexstring>
                       | "ECMA-117-Decimal"
                       "+" <digitstring> "+" <digitstring>
                       "+" <digitstring>

    <idi>          ::= <digitstring>

    <afi>          ::= "X121" | "DCC" | "TELEX" | "PSTN"
                       | "ISDN" | "ICD" | "LOCAL"

    <prefix>       ::= <digit> <digit>

    <ip>           ::= <domainstring>                   10

    <port>         ::= <digitstring>                    11

    <tset>         ::= "TCP" | "IP" |  <digitstring>    12

    <dte>          ::= <digitstring>
    <cudf-or-pid>  ::= "CUDF" | "PID"

    <decimaloctet> ::= <digit> | <digit> <digit>
                       | <digit> <digit> <digit>
    <digit>        ::= [0-9]

    <digitstring>  ::= <digit> <digitstring>
                       | <digit>

    <domainchar>   ::= [0-9a-zA-Z-.]

    <domainstring> ::= <domainchar> <otherstring>
                       | <domainchar>

    <dotstring>    ::= <decimaloctet> "." <dotstring>
                       | <decimaloctet> "." <decimaloctet>

    <dothexstring> ::= <dotstring>
                       | <hexstring>

    <hexdigit>::   ::= [0-9a-fA-F]

    <hexoctet>     ::= <hexdigit> <hexdigit>

    <hexstring>    ::= <hexoctet> <hexstring>
                       | <hexoctet>

    <other>        ::= [0-9a-zA-Z+-.]

    <otherstring>  ::= <other> <otherstring>
                       | <other>

    1  Value restricted to printed characters

    2  US GOSIP requirement

    3  Network type identifier (the default is CLNS)

    4  Concrete binary representation of network (NSAP) address value

    5  ISO 8348 compatibility

    6  RFC 1006 preferred format

    7  Abstract decimal format for domain specific part (DSP)

    8  Abstract binary for DSP

    9  Printable character format for DSP (for local use only)

    10 Dotted decimal notation (e.g. 10.0.0.6) or domain name (e.g.
       twg.com)

    11 TCP port number (the default is 102)

    12 Internet transport protocol identifier (1 = TCP and 2 = UDP)

    Keywords can be specified in either upper case or lower
    case. However, selector values are case sensitive. Spaces are
    significant.

2.3.1  –  Examples

    The following examples illustrate the syntax of presentation
    addresses. Note that some types of presentation address are
    applicable only to specific operating systems. When specifying
    a presentation address in a management directive, always enclose
    it in '' quotation marks. Note that the easiest way to set a
    DSA's presentation address is to use the DSA configuration
    procedure.

    1. "DSA"/"DSA"/"DSA"/NS+490001aa000400d90621,CLNS

       This is a typical presentation address for an HP DSA.

       In a management command, this must be quoted, as follows:

       '"DSA"/"DSA"/"DSA"/NS+490001aa000400d90621,CLNS'

    2. "my_psel"/"my_ssel"/"my_tsel"/LOCAL++x0001aa000400d90621
       "my_psel"/"my_ssel"/"my_tsel"/NS+490001aa000400d90621,CLNS

       These examples both specify the same presentation address. The
       first example uses the LOCAL authority and format identifier
       (AFI), which does not have an initial domain identifier (IDI).
       The two plus signs (++) indicate that the IDI is missing. By
       default, the network type is CLNS. The second example uses the
       value of the LOCAL AFI, which is 49.

    3. "256"/NS+a433bb93c1,CLNS|NS+aa3106,CONS

       This is a presentation address which has a transport
       selector, (no presentation or session selector), and two
       network addresses. The first network address is CLNS (for
       a connectionless network) and the second is CONS (for a
       connection-oriented network). These network addresses are
       specified in concrete binary form. This form can be used only
       when the concrete binary representation of the network address
       is known.

    4. #63/#41/#12/X121+234219200300,CONS

       This presentation address has presentation, session and
       transport selectors, and a single network address which
       consists of an AFI (X121) and an IDI (234219200300). There
       is no domain specific part.

    5. '3a'H/TELEX+00728722+X.25(80)+02+00002340555+CUDF+"892796"

       This is an network address for X.25. Note that, because CONS
       is not specified, the network type defaults to CLNS.

    6. RFC1006+10.0.0.6519,RFC1006

       This is an RFC1006 address. The address is not an ISO network
       address but the combination of an IP address and a TCP port
       number, which is 519 in this example. The IP address can be
       specified as either a DNS domain name or an IP address. For an
       RFC1006 address, the network type can be omitted.

3  –  Characteristics

 Each DSA characteristic attribute is listed below. You can assign
 values (using the SET directive) to all of these attributes except
 for the Version attribute. You can display the current value of
 all of the attributes using the SHOW directive.

 Syntax:

 	SET  DSA <attr> <value> [, ...]
 	SHOW DSA <attr> [, ...]

 where <attr> is the attribute name and <value> is the
 value. You can specify more than one attribute in a single
 directive by separating the attributes with a comma.
 For example:

 	SET  DSA AE TITLE="/C=US/CN=DSA3", PASSWORD="mumble"
 	SHOW DSA AE TITLE, PASSWORD

 You can use the ALL CHARACTERISTICS keywords in a SHOW directive,
 for example:

         SHOW DSA ALL CHARACTERISTICS

 Characteristic attributes can be reset to their default values by
 specifying the characteristic attribute without a value in a SET
 directive. For example, the following command resets the DSA AE
 Title attribute to its default value (no value):

 	SET DSA AE TITLE

3.1  –  Accounting Facility

 The Accounting Facility characteristic attribute controls whether
 the accounting facility is enabled on a DSA. (Note that previous
 versions of the DSA used an Accounting State attribute. The
 Accounting State attribute has been withdrawn.)

 Syntax:

 	SET DSA ACCOUNTING FACILITY <ON/OFF>
 	SHOW DSA ACCOUNTING FACILITY

 When you enable the accounting facility, the DSA generates the
 Accounting Enabled event. If the accounting facility cannot be
 started, the DSA generates the Accounting Start Failure event. When
 you disable the accounting facility, the DSA generates  the
 Accounting Disabled event.

 The setting of this attribute is maintained when you disable
 and re-enable the DSA, and also when you delete and recreate the DSA.

3.2  –  Accounting Options

 The Accounting Options characteristic attribute controls the amount
 of information included in Operation records in the accounting file.
 If this attribute is not set, the DSA provides a summary of user
 requests. The information included in Operation records is described
 in HP Enterprise Directory  - Problem Solving.

 If you set this attribute, in addition to summary information,
 the DSA can include the protocol data unit (PDU) of the user
 request and/or the error returned to the user if the operation is
 not successful. The error PDU and request PDU are described in
 ITU-T Recommendation X.511.

 You can set the attribute such that the DSA includes either the PDU
 of a successful user request, the PDU of an error returned in
 response to a user request, both, or neither.

 Syntax:

 	SET DSA ACCOUNTING OPTIONS {REQUESTPDU}
 	SET DSA ACCOUNTING OPTIONS {ERRORPDU}
 	SET DSA ACCOUNTING OPTIONS {REQUESTPDU, ERRORPDU}
 	SET DSA ACCOUNTING OPTIONS {}
         SHOW DSA ACCOUNTING OPTIONS

 To stop the DSA including either the request PDU or the error PDU in
 Operation records, enter the following command:

 	> SET DSA ACCOUNTING_OPTIONS {}

 This attribute has no effect if the Accounting Facility status
 attribute is set to OFF.

3.3  –  Accounting Rollover Interval

 The Accounting Rollover Interval characteristic attribute controls
 how often the DSA closes the current accounting file and creates a
 new one, that is, rolls over the accounting file. The interval uses
 the accounting rollover start time as its starting point. For
 example, if you set the accounting rollover interval to 6 hours, the
 first accounting file rollover will take place at the time specified
 by the Accounting Rollover Start Time attribute, and the second
 rollover six hours later.

 Syntax:

 	SET DSA ACCOUNTING ROLLOVER INTERVAL <time>
 	SHOW DSA ACCOUNTING ROLLOVER INTERVAL

 where <time> is the required interval specified in binary relative
 time.  For example, to make the DSA  rollover the accounting file
 every twelve and a half hours, enter the following:

 	> SET DSA ACCOUNTING ROLLOVER INTERVAL 12:30:00

 When the DSA rolls over the accounting file, it generates the
 Accounting File Rollover event. You can then process the closed
 accounting files using your decoding and billing utility.

 On Tru64 UNIX systems, accounting files are stored in
 the /var/dxd/accounting directory. On OpenVMS systems, accounting
 files are stored in the directory pointed to by the DXD$ACCOUNTING
 logical.

 Note that accounting files are neither purged nor deleted
 automatically by the DSA.

 The default setting for this characteristic attribute is 12 hours.

 This attribute has no effect if the Accounting Facility
 characteristic attribute is set to OFF.

3.4  –  Accounting Rollover Last Time

 This characteristic attribute is read only. It indicates the most
 recent time at which the accounting file was rolled over, that is,
 the time at which the previous accounting file was closed and the
 current accounting file created.

 Syntax:

 	SHOW DSA ACCOUNTING ROLLOVER LAST TIME

 The time is displayed in binary absolute time.

 If a rollover has not occurred since the DSA was created, then
 this attribute shows the time that the DSA was created.

3.5  –  Accounting Rollover Start Time

 This characteristic attribute indicates the first time at which the
 accounting file is to be rolled over, that is, the time at which the
 accounting file is to be closed and a new one created for the first
 time.

 Syntax:

 	SET DSA ACCOUNTING ROLLOVER START TIME <time>
 	SHOW DSA ACCOUNTING ROLLOVER START TIME

 where <time> is the required time specified in binary absolute time.

 For example, if you want the accounting file to be rolled over for
 the first time at 12:00, enter the following:

 	> SET DSA ACCOUNTING ROLLOVER START TIME 12:00:00

 Subsequent accounting file rollovers occur at the interval specified
 by the Accounting Rollover Interval attribute.

 This attribute has no effect if the Accounting Facility characteristic
 attribute is set to OFF.

3.6  –  Accounting Rollover Window

 The Accounting Rollover Window characteristic attribute defines the
 window for closing the current accounting file and creating a new
 one, that is, for rolling over the accounting file. If the accounting
 facility cannot roll over the accounting file within the time
 specified by the accounting rollover window, it continues to use the
 current accounting file until the next scheduled or unscheduled
 accounting file rollover.

 Syntax:

 	SET DSA ACCOUNTING ROLLOVER WINDOW <time>
 	SHOW DSA ACCOUNTING ROLLOVER WINDOW

 For example, assume the Accounting Rollover Window is set to 30
 minutes, the Accounting Rollover Interval to 6 hours, and the
 Accounting Rollover Start Time to 12:00:00. The accounting facility
 tries to rollover the accounting file at 12:00. If this rollover is
 not started by 12:30:00, the accounting facility abandons the
 attempt and continues to use the current accounting file until the
 next scheduled rollover at 18:00:00.

 When the accounting facility performs a scheduled rollover, that is a
 rollover required by the Accounting Rollover Interval characteristic
 attribute, it checks that no unscheduled rollover has been performed
 within the accounting rollover window. If one has, the scheduled
 rollover is not performed. For example, assume there is a scheduled
 rollover of the accounting file at 12:00:00. Before the scheduled
 rollover is performed, there is an unscheduled rollover at 12:10:00.
 Consequently, the scheduled rollover is not performed.

 The default setting for this characteristic attribute is 1 hour.

 This attribute has no effect if the Accounting Facility characteristic
 attribute is set to OFF.

3.7  –  Accounting Rollover Unscheduled Time

 You can use this characteristic attribute to force the accounting
 facility to immediately rollover the accounting file, that is, close
 the current accounting file and create a new one. Alternatively, by
 specifying the required time as the qualifier to this characteristic
 attribute, you can force the accounting facility to rollover the
 accounting file at any required time. In either case, this is called
 an unscheduled accounting file rollover.

 Syntax:

 	SET DSA ACCOUNTING ROLLOVER UNSCHEDULED TIME <time>
 	SHOW DSA ACCOUNTING ROLLOVER UNSCHEDULED TIME

 where <time> is the time at which you want the unscheduled accounting
 file rollover to take place in binary absolute time. If you do not
 specify a time the DSA performs accounting file rollover immediately.

 This attribute has no effect if the Accounting Facility
 characteristic attribute is set to OFF.

3.8  –  AE Title

 The AE Title attribute specifies the application entity title of
 the DSA. The AE Title is unique to this DSA.

 You specify the AE Title using the SET directive. You cannot
 enable  the DSA until it has an AE title. You must make sure that
 the  AE Title attribute is the same as the distinguished name of
 the  directory entry that represents this DSA in the DIT. Refer
 to HP Enterprise Directory  - Management for further details.

 The DSA must be in state OFF when you set the AE Title attribute.

 Syntax:

 	SET  DSA AE TITLE "<name>"
 	SHOW DSA AE TITLE

 Refer to DSA Common_Datatypes for information on the
 syntax of an AE Title.

3.9  –  Archived Update Log Number

 By default, the DSA will not keep prior versions of the Update Log File that
 it no longer needs. These log files are also used for incremenetal shadowing,
 so removal of earlier update log files may cause some shadowing agreements to
 perform a total update.
 The Archived Update Log Number attribute prevents the DSA from deleting the
 Update Log File. If this attribute is set to a number greater than zero,
 then all update logs files beyond this number will be preserved.

 Syntax:

 	SET  DSA ARCHIVED UPDATE LOG NUMBER <value>
 	SHOW DSA ARCHIVED UPDATE LOG NUMBER

3.10  –  DIT Check Interval

 The DIT Check Interval attribute defines how often the DSA
 writes its database to disk.

 When you modify directory entries, the DSA applies the
 modifications to the copy of the database that it holds in memory.
 It also keeps a log of all modifications in an update log file.

 After every DIT check interval, the DSA writes the database to disk.
 It then opens a new update log file for the next interval.

 In the event of a system problem, the DSA can recover its database by
 reading it from disk and applying the changes logged in the most recent
 update log file.

 Syntax:
 	SET  DSA DIT CHECK INTERVAL "<time>"
 	SHOW DSA DIT CHECK INTERVAL

 The full syntax for specifying a time is as follows: DDD-HH:MM:SS

 where DDD is days, HH is hours, MM is minutes, and SS is seconds.
 If you specify more than 366 days, the DSA uses 366 days as its
 DIT check interval. The DSA displays the value you specified if
 you use the SHOW directive.

 The default value is "12:00:00", indicating 12 hours. If you have a
 DSA that handles a lot of modifications, then you might want to
 specify a shorter interval. This prevents the update log file from
 becoming too large.

3.11  –  DIT Check Last Time

 This attribute records the time of the last DIT check, that is,
 the last time that the DSA wrote its database to disk and
 created a new update log. This is a read-only attribute.

 Syntax:
 	SHOW DSA DIT CHECK LAST TIME

3.12  –  DIT Check Window

 This attribute specifies the duration of the DIT check window.
 If the DSA fails to write its database to disk within this
 window, the attempt is delayed until the next scheduled DIT
 check.

 Syntax:
 	SET DSA DIT CHECK WINDOW "<time>"
 	SHOW DSA DIT CHECK WINDOW

 The full syntax for specifying a time is as follows: DDD-HH:MM:SS

 where DDD is days, HH is hours, MM is minutes, and SS is seconds.
 If you specify more than 366 days, the DSA uses 366 days as its
 DIT check window. The DSA displays the value you specified if
 you use the SHOW directive.

 The default value is 01:00:00, or one hour.

3.13  –  DIT Check Unscheduled Time

 Use this attribute to specify a time when the DSA must write
 its database to disk and create a new update log file. If
 you specify no time or a time in the past, the DSA writes its
 database immediately. This attribute has no effect on the
 normal schedule.

 Syntax: SET DSA DIT CHECK UNSCHEDULED TIME "<time>"
 	SHOW DSA DIT CHECK UNSCHEDULED TIME

 For example:

  	> SET DSA DIT CHECK UNSCHEDULED TIME "1995-01-05-01:12:00"

3.14  –  DIT Check Start Time

 This characteristic attribute indicates the first time at which the
 DSA is to write its database to disk and open a new update log file.

 Syntax:

 	SET DSA DIT CHECK START TIME "<time>"
 	SHOW DSA DIT CHECK START TIME

 where <time> is the required time specified in binary absolute
 time. For example, if you want the DSA to write the database for
 the first time at midday, enter the following:

 	> SET DSA DIT CHECK START TIME "12:00"

 The DSA then writes the database to disk at regular intervals
 after the specified start time. The intervals are defined by
 the DIT Check Interval attribute.

3.15  –  Dereference Aliases On Modify

 The Dereference Aliases on Modify attribute specifies whether
 alias names can be used in modification requests, such as
 the DXIM CREATE ENTRY, MODIFY ENTRY, DELETE ENTRY and
 RENAME ENTRY commands.

 If this attribute is set to TRUE, then alias names can be
 used in modifications if the user so desires. For example, a
 DXIM command line user can use the Dereference Aliases
 control to indicate that they want alias names dereferenced for
 a particular command. This means that the user can refer to the
 entry that they want to modify by means of its distinguished name
 or any valid alias name for that entry.

 If the attribute is set to FALSE, then alias names are never
 dereferenced  for modifications, regardless of user
 specification. This means that  a user must refer to the entry
 they want to modify by means of its  distinguished name. If they
 use an alias name, even a valid one, the command fails.

 The default value is FALSE. (Note that when displaying
 entries, the default behaviour is to dereference aliases.)

 Syntax:

 	SET DSA DEREFERENCE ALIASES ON MODIFY <TRUE/FALSE>

3.16  –  Examples

 	>  SET DSA PRESENTATION ADDRESS -
         _>  '"DSA"/"DSA"/"DSA"/NS+49002aaa0004000aaaaa,CLNS'

 	> SHOW DSA PRESENTATION ADDRESS

 	The first command assigns a presentation address to the DSA
 	and the second command displays this address.

 	> SET  DSA AE TITLE "/C=US/O=Abacus/CN=DSA1"
 	> SHOW DSA AE TITLE

 	The first command assigns an AE title to the
 	DSA and the second command displays it.

 	> SHOW DSA VERSION, AE TITLE, SIZE LIMIT

 	This command displays the value of three
 	characteristic attributes.

 	> SHOW DSA ALL CHARACTERISTICS

 	This command displays the value of all characteristic
 	attributes.

3.17  –  Idle Disconnect Timer

 The Idle Disconnect Timer attribute specifies how long a
 connection can remain unused before timing out. The value
 is specified in seconds.

 This ensures that system resources are not being consumed
 by inactive associations. The default value is 300 seconds.

 Syntax:

 	SET DSA IDLE DISCONNECT TIMER <seconds>
 	SHOW DSA IDLE DISCONNECT TIMER

 A value of 0 seconds indicates that idle connections are never
 disconnected by the DSA. This is not advisable.

3.18  –  Password

 The Password attribute contains the password of the DSA. This
 is used by the DSA to identify itself to another DSA when it
 needs to contact that DSA.

 The Password must match the userPassword attribute of the
 directory entry representing this DSA. If you change the password
 of the DSA, you must do so in both places.

 The password must be between 1 and 128 characters long.
 There is no default value. If a DSA does not have a password,
 it cannot replicate information, and might have difficulty
 passing user requests on to other DSAs.

 Syntax:

 	SET DSA PASSWORD <value>

3.19  –  LDAP Cipher Suites

 The LDAP Cipher Suites attribute specifies which SSL Cipher Suites will
 be available for SSL connections. If this attribute is not set, then the
 DSA will accept any of the ciphersuites in the SSL default list. This
 attribute allows you to restrict the DSA to a subset of the ciphersuites
 available in SSL. The value is a quoted string, listing each ciphersuite
 to be allowed, separated by a ':'.

 The DSA must be in state OFF for you to set this attribute.

 Syntax:
 	SET DSA LDAP CIPHERSUITE "<value>:<value>..."
 	SHOW DSA LDAP CIPHERSUITE

3.20  –  LDAP Port

 The LDAP Port attribute is the port number that the DSA listens on
 for LDAP protocol, when you enable the DSA.

 You must set the LDAP Port to a non-zero integer, while the DSA
 is in the OFF state. If the port number is set to zero, the DSA
 does not listen for LDAP requests.

 Syntax:
 	SET DSA LDAP PORT <value>
 	SHOW DSA LDAP PORT

3.21  –  LDAP Security Protocol

 Specify the security protocol to be used on this port. The DSA must be in
 state OFF, before you can set this attribute.

 Syntax:
 	SET DSA LDAP SECURITY PROTOCOL
 				<"SSLv2"/"SSLv3"/"SSLv23"/"TLSv1">
 	SHOW DSA LDAP SECURITY PROTOCOL

3.22  –  Presentation Address

 You cannot enable the DSA until it has a valid presentation
 address. The DSA must be in the OFF state when you set its
 Presentation Address attribute. Note that the easiest way to
 set a DSA's presentation address is to use the DSA
 configuration procedure.

 Syntax:
 	SET DSA PRESENTATION ADDRESS <address>
 	SHOW DSA PRESENTATION ADDRESS

 Quote the entire presentation address using the ' character.
 Do not attempt to break the presentation address across multiple
 command lines. Either use a wide window, or simply allow the
 presentation address to wrap.

 Refer to HP Enterprise Directory  - Management for
 details of how to use the DSA configuration procedure to set a DSA's
 presentation address.

 Refer to DSA Common_Datatypes for further information
 on the syntax of the Presentation Address attribute.

3.23  –  Private Key Passphrase

 If you want use SSL on LDAP connections to protect the security of the
 authentication phase, you need to obtain a certificate for the DSA.
 The certificate will have a Private Key that the DSA can use to validate
 the certificate exchange. This Private Key is usually encrypted using a
 pass phrase chosen by the user. If you are using SSL, you need to obtain
 a certificate and private key for the DSA in PEM format, either from a
 Certificate Authority or from SSL and store these in the DSA's directory
 area as DSA-certificate.pem and DSA-private-key.pem. You also need to tell
 the DSA what is the passphrase for the private key, by setting the PRIVATE
 KEY PASSPHRASE attribute. This is a password attribute, so you cannot SHOW
 it.

 Syntax:
 	SET DSA PRIVATE KEY PASSPHRASE "<value>"

3.24  –  Prohibit Chaining

 The Prohibit Chaining attribute specifies whether the DSA is
 allowed to communicate with other DSAs when attempting to satisfy
 user requests. Communication between DSAs is called chaining.

 The DSA must be in state OFF when you set this attribute.

 Syntax:
 	SET DSA PROHIBIT CHAINING <TRUE/FALSE>

 To prohibit chaining, specify the value TRUE; otherwise the
 value specified by the user or the user application is used. For
 example,  a user of the DXIM command line interface can use the
 No Chaining control.

 If a DSA is prohibited from communicating with other DSAs, then
 it provides the user or the application with a "continuation
 reference" or a "referral" instead. These identify which DSA(s)
 would have been contacted, and provide the user with the
 information they require to make the connection(s) directly if
 they want to. For ease of use, it is usually preferable not to
 prohibit chaining.

 Note that prohibiting chaining does not prevent DSAs from
 connecting to other DSAs for other reasons, such as replication.

3.25  –  Prohibit DECnet Transport

 The Prohibit DECnet Transport attribute specifies whether the DSA can use
 the DECnet OSI Transport protocol to communicate with DUAs and other DSAs.

 If the use of DECnet OSI Transport protocol is prohibited, then all
 communication will use the DSA's private RFC1006 implementation rather than
 DECnet's transports. If DECnet is running you will most likely not be able
 to use TCP/IP port 102 as DECnet will have allocated it.

 The DSA must be in state OFF when you set this attribute.

 Syntax:
 	SET  DSA PROHIBIT DECNET TRANSPORT <TRUE/FALSE>
 	SHOW DSA PROHIBIT DECNET TRANSPORT

3.26  –  Read Only DSA NSAPs

 The Read Only DSA NSAPs attribute identifies one or more DSAs
 that  are allowed to contact this DSA and perform interrogations
 on behalf of their users. Each DSA is represented by the NSAP
 value of its  presentation address.

 Syntax:

 	SET DSA READ ONLY DSA NSAPS {<address>, ....}

 where <address> is the NSAP address, for example:

 	SET DSA READ ONLY DSA NSAPS {%x49002aaa00040008aa21}

 You can specify the leading characters of an NSAP to indicate
 that read-only access is allowed for any DSA using an NSAP
 beginning with that sequence of characters. For example:

 	SET DSA READ ONLY DSA NSAPS {%x49002a}

 The default value is an empty list of NSAP addresses, indicating
 that all NSAPs are allowed. If the attribute specifies one or more
 NSAPs, then only DSAs using those NSAPs are allowed to perform
 interrogations of this DSA.

 Note that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is treated as a read-only DSA for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.27  –  Read Only DSA Names

 The Read Only DSA Names attribute lists the AE title of each DSA
 allowed to access this DSA to perform interrogations on behalf of
 their users.

 Syntax:
 	SET DSA READ ONLY DSA NAMES {<aetitle>, ....}

 where <aetitle> is the AE title of a DSA. For example:

 	"/C=US/O=Abacus/OU=Sales/CN=DSA1"

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE title.

 The default value is an empty list of AE titles, indicating
 that any DSA is allowed to interrogate this DSA (subject to other
 controls). If one or more AE titles are specified in this
 attribute, then only those DSAs are allowed to interrogate this DSA.

 Note also that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is treated as a read-only DSA for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.28  –  Reader NSAPs

 The Reader NSAPs attribute lists the NSAP addresses
 that directory applications can use to access the DSA and perform
 interrogations.

 Note that this is not the recommended way to implement controls
 on user access to directory information. Refer to HP Enterprise
 Directory  - Management for access control advice.

 Syntax:
 	SET DSA READER NSAPS {<address>, ....}

 where <address> is the NSAP address, for example:

 	SET DSA READER NSAPS {%x49002aaa00040008aa21}

 You can specify the leading characters of an NSAP to indicate
 that read-only access is allowed for any application using an
 NSAP beginning with that sequence of characters. For example:

 	SET DSA READER NSAPS {%x49002a}

 The default value is an empty set of NSAP addresses, indicating
 that applications can use any NSAP.

 Note that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is allowed read access for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.29  –  Reader Names

 The Reader Names attribute lists the distinguished names of
 users permitted to access the DSA and perform interrogations.

 Note that this is not the recommended way to implement controls
 on user access to directory information. Refer to HP Enterprise
 Directory  - Management for access control advice.

 Syntax:
 	SET DSA READER NAMES {<name>, ....}

 where <name> is the distinguished name of a user, for example:

 	"/C=US/O=Abacus/OU=Sales/CN='Jon Smith'"

 Refer to DSA Common_Datatypes for more information
 on how to specify a distinguished name.

 If the attribute contains no names, then all users can
 interrogate the DSA (subject to access controls, and to the
 setting of the Reader NSAPs and the Writer Names and
 Writer NSAPs attributes).

 The default value is an empty list of distinguished names,
 allowing all users to read information, subject to other
 attributes and access controls.

 Note that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is allowed read access for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.30  –  Schema Check On Modify

 The Schema Check on Modify attribute specifies whether the DSA
 checks modifications for conformance with the schema.

 Syntax:
 	SET DSA SCHEMA CHECK ON MODIFY <TRUE/FALSE>

 If you do not want the DSA to use the schema to ensure that
 modifications are valid, set this attribute to FALSE.

 Note that if directory modifications are not checked against
 the schema, you can easily corrupt your directory information.
 It is not advisable to set this attribute to FALSE unless you
 are sure that all requests for modification will be valid.

 One reason to set this attribute to FALSE temporarily might be
 because you want to use a script file to execute a large number
 of commands which you are sure are all valid. The DSA can process
 such a file more quickly, but you must be confident that the file
 contains no invalid commands. For example, if the file contains
 a request to add an attribute to an entry for which it is not
 allowed, then you will have created an invalid entry.

3.31  –  Size Limit

 The Size Limit attribute specifies the maximum number of entries
 that can be returned when satisfying a user request. Most
 directory operations only return one entry, but some, such as
 searches, can return many entries.

 Syntax:
 	SET DSA SIZE LIMIT <number>

 The limit specified using this characteristic attribute overrides
 the value specified by the user application, if the application
 requests a larger number.

 The default value is 0, indicating that there is no limit on the
 number of entries that can be returned unless the application
 specifies one.

3.32  –  SSL LDAP Cipher Suites

 The SSL LDAP Cipher Suites attribute specifies which SSL Cipher Suites will
 be available for SSL connections through the dedicated SSL LDAP port. If this
 attribute is not set, then the DSA will accept any of the ciphersuites in
 the SSL default list. This attribute allows you to restrict the DSA to a
 subset of the ciphersuites available in SSL. The value is a quoted string,
 listing each ciphersuite to be allowed, separated by a ':'.

 The DSA must be in state OFF for you to set this attribute.

 Syntax:
 	SET  DSA SSL LDAP CIPHERSUITES "<value>:<value>..."
 	SHOW DSA SSL LDAP CIPHERSUITES

3.33  –  SSL LDAP Port

 The SSL LDAP Port attribute is the port number of the dedicated SSL LDAP port
 that the DSA listens on for SSL messages, when you enable the DSA.
 Unlike the LDAP port, which can establish LDAP connections with or without
 SSL, the SSL_LDAP_port will refuse all LDAP connections that do not specify
 SSL.

 You must set the SSL LDAP Port to a non-zero integer, while the DSA
 is in the OFF state. If the port number is zero, the DSA does not listen
 for SSL requests.

 Syntax:
 	SET  DSA SSL LDAP PORT <value>
 	SHOW DSA SSL LDAP PORT

3.34  –  SSL LDAP Security Protocol

 Specify the security protocol to be used on the SSL LDAP port. The DSA must
 be in state OFF, when you set this attribute.

 Syntax:
 	SET  DSA SSL LDAP SECURITY PROTOCOL
 				<"SSLv2"/"SSLv3"/"SSLv23"/"TLSv1">
 	SHOW DSA SSL LDAP SECURITY PROTOCOL

3.35  –  SSL State

 The overall policy for SSL is controlled by the setting of the
 DSA characteristic SSL STATE.

 Syntax:

 	SET  DSA SSL STATE <state>
 	SHOW DSA SSL STATE

 Values for this characteristic are:

 "On"  	     SSL is enabled.

 "Off"  	     SSL is not enabled. SSL negotiation on the LDAP port
 	     will be refused.

 "Mandatory"  SSL is enabled and SSL must be negotiated on the LDAP
 	     port before any authenticated bind operation. Only
 	     unauthenticated operations can be performed on the
 	     normal LDAP port before SSL negotiation.

3.36  –  Time Limit

 The Time Limit attribute specifies the time, in seconds, within
 which a directory request must be completed. The value specified
 using this characteristic attribute limits the ability of user
 applications to specify a time limit.

 Syntax:
 	SET DSA TIME LIMIT <seconds>

 The default value is 0, indicating that there is no time
 limit unless the application specifies one.

 The DSA makes frequent checks to see whether it has exceeded the
 time limit, and stops processing a request as soon as one of
 these checks indicates that the time limit has been exceeded. Any
 results that have been found within the time limit are presented
 to the user, with a Partial Results Displayed message.

3.37  –  Trusted DSA NSAPs

 The Trusted DSA NSAPs attribute contains a list of NSAP
 addresses through which DSAs can contact this DSA and perform
 chained read and chained modify operations.

 Syntax:
 	SET DSA TRUSTED DSA NSAPS {<address>, ....}

 where <address> is the NSAP address, for example:

 	SET DSA TRUSTED DSA NSAPS {%x49002aaa00040008aa21}

 The default value is an empty set of NSAP addresses, indicating
 that all NSAPs are allowed.

 You can specify the leading characters of an NSAP to indicate
 that trusted access is allowed for any DSA using an
 NSAP beginning with that sequence of characters. For example:

 	SET DSA TRUSTED DSA NSAPS {%x49002a}

 The default value is an empty set of NSAP addresses, indicating
 that DSAs can use any NSAP.

 Trusted access is required by DSAs that are attempting to chain
 a requested for an authenticated user. This DSA must decide
 whether the calling DSA is to be trusted when it claims to have
 authenticated the user satisfactorily.

 Note that this attribute has no effect on DSA communications
 for other purposes, such as replication.

 Note also that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is treated as a trusted DSA for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.38  –  Trusted DSA Names

 The Trusted DSA Names attribute can contain a list of trusted
 DSAs.

 Syntax:
 	SET DSA TRUSTED DSA NAMES {<aetitle>, ....}

 where <aetitle> is the AE title of a DSA that is to be trusted,
 for example:

 	"/C=US/O=Abacus/OU=Sales/CN=DSA1"

 The list contains the AE title of each trusted DSA.
 Refer to DSA Common_Datatypes for more information
 on how to specify an AE title.

 The default value is an empty list of AE titles, which means
 that this DSA trusts no other DSAs.

 Trust enables this DSA to accept another DSA's claim that
 a user has authenticated satisfactorily. This enables chained
 requests to be satisfied, rather than requiring a user to
 authenticate specifically to the DSA that holds the information
 they want to access.

 Note that this attribute is not the recommended way to implement
 trust between DSAs. Refer to the management guide for details of
 how to create directory entries to represent trusted DSAs.

 Note also that this attribute has no effect on DSA communications
 for other purposes, such as replication.

 Note also that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is treated as a trusted DSA for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.39  –  Version

 The Version attribute displays the version number of the DSA.
 The value is read-only.

 Syntax:
 	SHOW DSA VERSION

3.40  –  Volatile Modifications

 The Volatile Modifications attribute specifies whether the DSA
 writes all modifications to disk immediately, or delays writing
 modifications to disk.

 Syntax:

 	SET DSA VOLATILE MODIFICATIONS <TRUE/FALSE>

 If the attribute is set to FALSE, then the DSA always writes
 modifications to disk immediately after applying them to its
 in-memory database. This ensures that modifications are never
 lost, but reduces DSA performance for modification operations.

 If the attribute is set to TRUE, then modifications are written
 to memory immediately, but may not be written to disk for up to
 fifteen seconds. This means it is possible that some
 modifications may be lost if a DSA exits abnormally. However,
 the DSA can process volatile modifications much faster than
 non-volatile modifications.

 The default value is FALSE. HP suggests that you set the
 attribute to TRUE, unless you have a strong requirement to
 ensure that modifications are never lost. The attribute can be
 set at any time, regardless of the state of the DSA.

3.41  –  Writer NSAPs

 This attribute lists the NSAP addresses that directory
 applications can use to communicate with this DSA and modify
 directory information. Any application attempting to use
 an unlisted NSAP is not allowed to modify information held by
 this DSA. It might be able to read information, subject to
 the Reader_NSAPs attribute. Having write access automatically
 gives read access as well.

 Note that this attribute is not the recommended way to implement
 access control. Refer to HP Enterprise Directory
 - Management for access control advice.

 Syntax:
 	SET DSA WRITER NSAPS {<address>, ....}

 where <address> is the NSAP address, for example:

 	SET DSA WRITER NSAPS {%x49002aaa00040008aa21}

 You can specify the leading characters of an NSAP to indicate
 that access is allowed for any application using an NSAP beginning
 with that sequence of characters. For example:

 	SET DSA WRITER NSAPS {%x49002a}

 The default value is an empty set of NSAP addresses, indicating
 that an application can use any NSAP.

 Note also that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is allowed write access for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

3.42  –  Writer Names

 The Writer Names attribute lists the distinguished
 names of users permitted to modify information held by this DSA.
 Having write access automatically gives read access as well.

 Syntax:
 	SET DSA WRITER NAMES {<name>, ....}

 where <name> is the distinguished name of a user, for example:

 	"/C=US/O=Abacus/OU=Sales/CN='Jon Smith'"

 Refer to DSA Common_Datatypes for more information
 on how to specify a distinguished name.

 Note that this is not the recommended way to implement controls
 on user access to directory information. Refer to HP Enterprise
 Directory  - Management for access control advice.

 If the attribute specifies no names, then the DSA places no
 restriction on access, (subject to access controls, and to the
 settings of Writer NSAPs, Reader Names, and Reader NSAPs
 characteristic attributes). However, if any names are listed,
 then only those users have access to information.

 The default value is an empty set of distinguished names, allowing
 all users to access information, subject to other attributes and
 access controls.

 Note also that the DSA refers to the value of this attribute
 whenever it receives a new connection. Once a connection is
 established, the caller is allowed write access for as
 long as the connection lasts. Changing the value of the
 attribute has no effect on existing connections, only on
 subsequent connections.

4  –  Counters

 Counter attributes provide statistical information concerning the
 activities of the DSA. Typical counters show the number of reads
 and modifies that the DSA has processed and the number of errors
 reported by the DSA.

 All counters are listed below and each described individually.
 All the counters are read-only. You can use the SHOW directive
 to display counters. For example:

 	SHOW DSA <counter>

 You can specify a list of counters to display. For example:

         SHOW DSA <counter1>, <counter2>

 You can use the ALL COUNTERS keyword to display all counter
 attributes  with one directive. For example:

         SHOW DSA ALL COUNTERS

4.1  –  Abandon Failures

 This counter displays the number of Abandon Failed Errors
 generated by the DSA. The Abandon service enables a user to
 indicate that they are no longer interested in the request
 that they sent to the DSA, perhaps because the request is
 taking too long.

 Syntax:
 	SHOW DSA ABANDON FAILURES

4.2  –  Abandon Operations

 This counter displays the number of directory ABANDON operations
 performed by the DSA. A directory ABANDON operation is used only
 to cancel a Read, Compare, List or Search operation.

 Syntax:
 	SHOW DSA ABANDON OPERATIONS

4.3  –  Accounting Disabled

 This counter displays the number of Accounting Disabled events
 generated by the DSA.

 Syntax:

 	SHOW DSA ACCOUNTING DISABLED

4.4  –  Accounting Enabled

 This counter displays the number of Accounting Enabled events
 generated by the DSA.

 Syntax:

 	SHOW DSA ACCOUNTING ENABLED

4.5  –  Accounting File Access Failures

 This counter displays the number of Accounting File Access Failure
 events generated by the DSA. The Accounting File Access Failure event
 indicates why the DSA could not access the accounting file, and what
 type of access the DSA was trying to gain.

 Syntax:

 	SHOW DSA ACCOUNTING FILE ACCESS FAILURES

4.6  –  Accounting File Rollover

 This counter displays the number of Accounting File Rollover events
 generated by the DSA. Each rollover can be either scheduled or
 unscheduled. Accounting file rollover involves closing the current
 accounting file and creating a new accounting file.

 Syntax:

 	SHOW DSA ACCOUNTING FILE ROLLOVER

4.7  –  Accounting Records Discarded

 This counter displays the total number of accounting records that
 have been discarded by the DSA accounting facility.

 Syntax:

 	SHOW DSA ACCOUNTING RECORDS DISCARDED

4.8  –  Accounting Start Failures

 This counter displays the number of Accounting Start Failure events
 generated by the DSA. The Accounting Start Failure event indicates
 that the DSA could not start the accounting facility when requested.

 Syntax:

 	SHOW DSA ACCOUNTING START FAILURES

4.9  –  Add Entry Operations

 This counter displays the number of directory add entry
 operations requested of the DSA. A directory add entry
 operation is used to add a new entry to the directory
 information base. For example, this counter increases with each
 DXIM CREATE ENTRY command. The counter does not distinguish
 between operations performed by this DSA, and operations that
 this DSA passed on to another DSA for processing.

 Syntax:
 	SHOW DSA ADD ENTRY OPERATIONS

4.10  –  Attribute Errors

 This counter displays the number of Attribute Errors generated
 by the DSA. This counter increases when, for example, a user
 attempts to violate an attribute constraint, or attempts
 to show an attribute that does not exist.

 Syntax:
 	SHOW DSA ATTRIBUTE ERRORS

4.11  –  Authentication Failures

 This counter displays the number of Authentication Failure
 events (see EVENTS) generated by the DSA.

 Syntax:
 	SHOW DSA AUTHENTICATION FAILURES

 An Authentication Failure event is issued when the DSA fails
 to authenticate the originator of a Bind request. This
 typically means that the originator specified the wrong
 password, or the password could not be verified by the DSA.

4.12  –  Chained Abandon Operations

 This counter displays the number of CHAINED ABANDON operations
 requested of the DSA. A CHAINED ABANDON requests the DSA to
 cancel a CHAINED READ, CHAINED SEARCH, CHAINED COMPARE or
 CHAINED LIST operation that was requested of it previously.

 Syntax:
 	SHOW DSA CHAINED ABANDON OPERATIONS

4.13  –  Chained Add Entry Operations

 This counter displays the number of CHAINED ADD ENTRY operations
 requested of the DSA. A CHAINED ADD ENTRY operation  involves
 the local DSA receiving an ADD ENTRY operation from another DSA.
 See Add_Entry_Operations for a description of the ADD ENTRY
 operation.

 Syntax:
 	SHOW DSA CHAINED ADD ENTRY OPERATIONS

4.14  –  Chained Binds Accepted

 This counter displays the number of bind requests from other DSAs
 that have been accepted by the DSA. A chained bind enables
 communication between two DSAs.

 Syntax:
 	SHOW DSA CHAINED BINDS ACCEPTED

4.15  –  Chained Binds Rejected

 This counter displays the number of Bind requests from other DSAs
 that have been rejected by the DSA. A chained bind enables
 communication between two DSAs. A DSA can reject a chained bind
 if it is not ready for communication.

 Syntax:
 	SHOW DSA CHAINED BINDS REJECTED

4.16  –  Chained Compare Operations

 This counter displays the number of CHAINED COMPARE operations
 requested of the DSA. A CHAINED COMPARE operation involves the
 local DSA receiving a COMPARE operation from another DSA. See
 Compare_Operations for a description of the COMPARE operation.

 Syntax:
 	SHOW DSA CHAINED COMPARE OPERATIONS

4.17  –  Chained List Operations

 This counter displays the number of CHAINED LIST operations
 requested the DSA. A CHAINED LIST operation involves the local
 DSA receiving a LIST operation from another DSA. See
 List_Operations for a description of the LIST operation.

 Syntax:
 	SHOW DSA CHAINED LIST OPERATIONS

4.18  –  Chained Modify Entry Operations

 This counter displays the number of CHAINED MODIFY ENTRY
 operations requested of the DSA. A CHAINED MODIFY ENTRY
 operation involves the local DSA receiving a MODIFY
 ENTRY operation from another DSA. See Modify_Entry_Operations for
 a description of the  MODIFY ENTRY operation.

 Syntax:
 	SHOW DSA CHAINED MODIFY ENTRY OPERATIONS

4.19  –  Chained Modify RDN Operations

 This counter displays the number of CHAINED MODIFY RDN operations
 requested of the DSA. A CHAINED MODIFY RDN operation involves the
 local DSA receiving a MODIFY RDN operation from another DSA. See
 Modify_RDN_Operations for a description  of the MODIFY RDN operation.

 Syntax:
 	SHOW DSA CHAINED MODIFY RDN OPERATIONS

4.20  –  Chained Operation Referrals

 This counter displays the number of times the DSA has sent a
 referral to another DSA. The referral contains information about
 one or more DSAs that might have the information that satisfies
 a user request.

 Syntax:
 	SHOW DSA CHAINED OPERATION REFERRALS

4.21  –  Chained Read Operations

 This counter displays the number of CHAINED READ operations
 requested of the DSA. A CHAINED READ operation involves
 the local DSA receiving a READ operation from another DSA.
 See Read_Operations for a description of the READ operation.

 Syntax:
 	SHOW DSA CHAINED READ OPERATIONS

4.22  –  Chained Remove Entry Operations

 This counter displays the number of CHAINED REMOVE ENTRY
 operations requested of the DSA. A CHAINED REMOVE ENTRY
 operation involves the local DSA receiving a REMOVE
 ENTRY operation, from another DSA. See Remove_Entry_Operations
 for a description  of the REMOVE ENTRY operation.

 Syntax:
 	SHOW DSA CHAINED REMOVE ENTRY OPERATIONS

4.23  –  Chained Search Operations

 This counter displays the number of CHAINED SEARCH operations
 requested the DSA. A CHAINED SEARCH operation involves
 the local DSA receiving a SEARCH operation from another DSA.
 See Search_Operations for a description of the SEARCH
 operation.

 Syntax:
 	SHOW DSA CHAINED SEARCH OPERATIONS

4.24  –  Changes of State

 This counter displays the number of State Change events (see EVENTS)
 generated by the DSA.  The event is generated when, for example,
 you use the ENABLE DSA directive. In this case, the DSA changes
 from state OFF to state ENABLING and then to state ON, causing two
 State Change events.

 Syntax:
         SHOW DSA CHANGES OF STATE

4.25  –  Compare Operations

 This counter displays the number of directory COMPARE operations
 performed by the DSA. A directory COMPARE operation is used to
 compare a given entry with a specified directory entry.

 Syntax:
 	SHOW DSA COMPARE OPERATIONS

4.26  –  Communication Failures

 This counter displays the number of communication failures since
 the DSA was created.

 Syntax:
 	SHOW DSA COMMUNICATION FAILURES

4.27  –  Create Failures

 This counter displays the number of Create Failure events (see
 EVENTS) generated by the DSA. A Create Failure event is generated
 when the DSA fails to create the DSA entity. However, because a
 successful creation is required before you can see the counter,
 the value of this counter is always 0.

 Syntax:
 	SHOW DSA CREATE FAILURES

4.28  –  Creation Time

 This counter displays the time and date at which the DSA was
 created.

 Syntax:
 	SHOW DSA CREATION TIME

4.29  –  DISP Binds Accepted

 This counter displays the number of DISP binds the DSA has
 accepted from other DSAs. The DISP protocol is used by DSAs
 to replicate information.

 Syntax:
         SHOW DSA DISP BINDS ACCEPTED

4.30  –  DISP Binds Rejected

 This counter displays the number of DISP binds the DSA has
 rejected. The DISP protocol is used by DSAs to replicate
 information. A DISP bind can be rejected due to, for
 example, authentication failure.

 Syntax:
         SHOW DSA DISP BINDS REJECTED

4.31  –  DOP Binds Accepted

 This counter displays the number of DOP binds the DSA has
 accepted from other DSAs. The DOP protocol is used by the
 DSAs to manage shadowing agreements.

 Syntax:
        SHOW DSA DOP BINDS ACCEPTED

4.32  –  DOP Binds Rejected

 This counter displays the number of DOP binds the DSA has
 rejected from other DSAs. The DOP protocol is used by the
 DSAs to manage shadowing agreements. A DOP bind can be
 rejected due to, for example, authentication failure.

 Syntax:
         SHOW DSA DOP BINDS REJECTED

4.33  –  DUA Binds Accepted

 This counter displays the number of Bind requests from directory
 applications that have been accepted by the DSA. For example,
 each successful DXIM BIND command causes this counter to increase
 by one.

 Syntax:
 	SHOW DSA DUA BINDS ACCEPTED

4.34  –  DUA Binds Rejected

 This counter displays the number of Bind requests from directory
 user applications (DUAs) that have been rejected by the DSA.
 For example, each unsuccessful DXIM BIND command causes this
 counter to increase by one.

 A DSA can reject a Bind request if, for example, it cannot
 authenticate the user of the application.

 Syntax:
 	SHOW DSA DUA BINDS REJECTED

4.35  –  Distributed Operation Failures

 This counter displays the number of Distributed Operation Failure
 events (see EVENTS) generated by the DSA. A DSA generates a
 Distributed Operation Failure event when it fails to establish
 communication with another DSA for any reason. For example,
 network problems or authentication problems might cause
 the DSA to generate this event.

 Syntax:
 	SHOW DSA DISTRIBUTED OPERATION FAILURES

4.36  –  LDAP Binds Accepted

 This counter displays the number of LDAP Binds that the DSA
 has accepted.

 Syntax:
 	SHOW DSA LDAP BINDS ACCEPTED

4.37  –  LDAP Binds Rejected

 This counter displays the number of LDAP Binds that the DSA
 has rejected.

 Syntax:
 	SHOW DSA LDAP BINDS REJECTED

4.38  –  Examples

 	> SHOW DSA CHAINED BINDS

 	This command displays the current value of the
         CHAINED BIND counter.

 	> SHOW DSA CHAINED BINDS ACCEPTED, CHAINED BINDS REJECTED

 	This command displays the current values of the
         CHAINED BINDS ACCEPTED and the CHAINED BINDS REJECTED counters.

 	> SHOW DSA ALL COUNTERS

 	This command displays the current value of all DSA counters.

4.39  –  Exhausted Resource

 This counter displays the number of Resource Exhausted events
 (see EVENTS) generated by the DSA. A Resource Exhausted event is
 generated when a DSA detects that a critical resource is
 exhausted, preventing it from processing a requested operation.

 Syntax:
 	SHOW DSA EXHAUSTED RESOURCE

4.40  –  Internal Errors

 This counter displays the number of Internal Error events (see
 EVENTS) generated by the DSA. An Internal Error event is
 generated when the DSA detects an internal error.

 Syntax:
 	SHOW DSA INTERNAL ERRORS

4.41  –  List Operations

 This counter displays the number of directory LIST operations
 performed by the DSA. A directory LIST operation is used to
 obtain a list of the immediate subordinates of a specified
 directory entry. For example, this counter increases with
 each DXIM SHOW SUBORDINATES command.

 Syntax:
 	SHOW DSA LIST OPERATIONS

4.42  –  Listen Failures

 This counter displays the number of Listen Failure events
 (see EVENTS) generated by the DSA. The DSA generates this
 event when something prevents it from setting up its own
 presentation access point for receiving communications.

 Syntax:
 	SHOW DSA LISTEN FAILURES

4.43  –  Modify Entry Operations

 This counter displays the number of directory modify entry
 operations performed by the DSA. A directory modify entry
 operation is used to amend an existing directory
 entry. For example, this command increases with each
 DXIM MODIFY ENTRY and DXIM SET ENTRY command. The counter
 does not distinguish between operations performed by this DSA,
 and operations that this DSA passed on to another DSA for
 processing.

 Syntax:
 	SHOW DSA MODIFY ENTRY OPERATIONS

4.44  –  Modify RDN Operations

 This counter displays the number of directory modify RDN
 operations requested of the DSA. A directory modify RDN
 operation is used to modify the relative distinguished
 name (RDN) of a directory entry. For example, this counter
 increases with each DXIM RENAME ENTRY command. The counter does
 not distinguish between  operations performed by this DSA, and
 operations that this DSA  passed on to another DSA for
 processing.

 Syntax:
 	SHOW DSA MODIFY RDN OPERATIONS

4.45  –  Name Errors

 This counter displays the number of Name Errors generated by
 the DSA. This counter increases when, for example, a
 user specifies a name which is not the name of an entry.

 Syntax:
 	SHOW DSA NAME ERRORS

4.46  –  Read Operations

 This counter displays the number of directory READ operations
 performed by the DSA. A directory READ operation is used to
 extract information from a specified directory entry. For
 example, this counter increases with each DXIM SHOW ENTRY
 command.

 Syntax:
 	SHOW DSA READ OPERATIONS

4.47  –  Referrals

 This counter displays the number of Referrals generated by the
 DSA. A referral occurs when a DSA cannot satisfy an operation
 itself and therefore returns to the application, a reference
 to another DSA which it believes can process the operation.

 Syntax:
 	SHOW DSA REFERRALS

4.48  –  Remove Entry Operations

 This counter displays the number of directory remove entry
 operations requested of the DSA. A directory remove entry
 operation is used to remove a specified entry from
 the directory information base. For example, this counter
 increases with each  DXIM DELETE ENTRY command. The counter does
 not distinguish between  operations performed by this DSA, and
 operations that this DSA  passed on to another DSA for
 processing.

 Syntax:
 	SHOW DSA REMOVE ENTRY OPERATIONS

4.49  –  Results

 This counter displays the number of results generated by the
 DSA. A result is the successful completion of a directory
 operation.

 Syntax:
 	SHOW DSA RESULTS

4.50  –  Search Operations

 This counter displays the number of directory SEARCH operations
 performed by the DSA. A directory SEARCH operation is used to
 search a section of the directory information base for specific
 information.

 Syntax:
 	SHOW DSA SEARCH OPERATIONS

4.51  –  Security Errors

 This counter displays the number of security errors detected
 by the DSA. A security error occurs when for example, an end
 user tries to perform an operation for which they are not
 authorized.

 Syntax:
 	SHOW DSA SECURITY ERRORS

4.52  –  Service Errors

 This counter displays the number of Service Errors generated by
 the DSA. A Service Error is issued when an error occurs related
 to the provision of a service (Read, Compare, and so on).

 Syntax:
 	SHOW DSA SERVICE ERRORS

4.53  –  Shadow Agreement Update Failures

 This counter displays the number of Shadow Agreement Update
 Failure events generated by the DSA. The event is generated
 when a DSA fails to create, modify, or delete a shadowing
 agreement.

 Syntax:
         SHOW DSA SHADOW AGREEMENT UPDATE FAILURES

4.54  –  Shadow Agreement Updates Completed

 This counter displays the number of Shadow Agreement Update
 Complete events generated by the DSA. The event is generated
 every time a DSA successfully creates, modifies, or deletes
 a shadowing agreement.

 Syntax:
         SHOW DSA SHADOW AGREEMENT UPDATES COMPLETED

4.55  –  Shadow Update Failures

 This counter displays the number of Shadow Update Failure events
 (see EVENTS) generated by the DSA. The Shadow Update Failure
 event is generated when the DSA fails to update its copy of a
 naming context. If the DSA fails to copy two or more naming
 contexts from another DSA, then the failure to copy each naming
 context causes an event.

 Syntax:
 	SHOW DSA SHADOW UPDATE FAILURES

4.56  –  Shadow Updates Completed

 This counter displays the number of Shadow Update Complete events
 (see EVENTS) generated by the DSA. The DSA generates the Shadow
 Update Complete event when it succeeds in copying or updating a
 naming context from another DSA. If the DSA copies two or more
 naming contexts from another DSA, then the successful copying of
 each naming context causes an event.

 Syntax:
 	SHOW DSA SHADOW UPDATES COMPLETED

4.57  –  Update Errors

 This counter displays the number of Update Errors generated by
 the DSA. This counter increase when, for example, a user attempts
 to create an entry that already exists.

 Syntax:
 	SHOW DSA UPDATE ERRORS

5  –  Directives

 You can use the ADD, CREATE, DELETE, ENABLE, DISABLE, REMOVE, SET,
 SHOW and UPDATE directives with the DSA entity.

 The CREATE and DELETE directives are used to create and delete a DSA.

 The ENABLE and DISABLE directives are used to enable or disable the
 DSA for communication with directory applications and other DSAs.

 The SET, SHOW, ADD and REMOVE directives are used to manage DSA
 attributes.

 The UPDATE directive is used to initiate replication between
 DSAs.

 To use any directives other than the SHOW directive, you require
 privileges.

5.1  –  ADD

 Use the ADD directive to add additional values to a DSA
 multi-valued characteristic attribute. The DSA multi-valued
 characteristic attributes are:

 -	READ ONLY DSA NSAPS
 -	READ ONLY DSA NAMES
 -	WRITER NAMES
 -	WRITER NSAPS
 -	READER NAMES
 -	READER NSAPS
 -	TRUSTED DSA NAMES
 -	TRUSTED DSA NSAPS

 Syntax:

 	ADD DSA <characteristic> {<value>,...}

 where <characteristic> is the name of the Characteristic attribute
 and <value> is the value you want to add to the attribute. Note
 the use of {} to enclose the values of a multivalued attribute.
 These must be used even if only one value is actually specified.

5.2  –  CREATE

 Use this directive to create a DSA. On completion of this directive,
 the state of the DSA is OFF. You can then create subentities
 of the DSA entity, and manage the attributes of the DSA entity and
 its subentities.

 Syntax:
 	CREATE DSA

 When the DSA is being created, it reads its database into memory.
 If the DSA does not have a database yet, it creates a new one
 automatically.

 DSAs on Tru64 UNIX systems use memory image files instead
 of the snapshot files since V3.0.  The DSA can read and write memory
 image files much faster, especially for large databases.  By default,
 the DSA always reads a memory image file, if a valid one is
 available. If not, it reads a snapshot file, if one is available, or
 creates a new database if not.

 You can use arguments to the CREATE DSA command to specify
 which type of database file you want the DSA to read during
 creation. If you use these arguments, the DSA only attempts to
 read the specified type of database file, and does not fallback
 to the other type or create a new database. See the Arguments
 topic for further details.

 After you have created the DSA for the first time, using the
 CREATE DSA command with no arguments, you must set values for
 the AE Title and Presentation Address attributes of the
 DSA entity. You cannot enable a DSA that does not have these two
 attributes set. This version provides a DSA configuration utility
 that simplifies the setting of these attributes.

 After creation for the first time you are also advised to set the
 Volatile Modifications attribute to TRUE. Refer to the help for
 this characteristic attribute for further details.

 During subsequent DSA creations, the DSA refers to its own database
 and configures itself automatically.

5.2.1  –  Arguments

 DSAs on Tru64 UNIX systems support arguments to the CREATE DSA
 directive.  The arguments are as follows:

 Syntax:

         CREATE DSA [FROM MEMORY IMAGE | FROM SNAPSHOT]

 If you use the FROM MEMORY IMAGE argument, the DSA attempts to
 read a memory image file, and returns a DSA Information Tree
 Corrupt error if none is available. The DSA does not attempt
 to read a snapshot file or create a new database. If the DSA
 can find a valid memory image file, it returns a message
 indicating that is has successfully read the memory image file.

 The memory image file contains a copy of the schema. This means
 that the DSA does not read the schema during creation. However,
 the DSA displays a warning message if its copy of the schema
 is not the same as the schema file. If the schema has been
 changed, use the following commands to force the DSA to read it:

   > DELETE DSA TO SNAPSHOT
   > CREATE DSA FROM SNAPSHOT

 If you use the FROM SNAPSHOT argument, the DSA attempts to read
 a snapshot file, as in previous versions, and returns a DSA
 Information Tree Corrupt error if none is available. The DSA does
 not attempt to read a memory image file or create a new database.
 If the DSA can find a valid snapshot file, it returns a message
 indicating that is has successfully read the snapshot file.

 Do not use the FROM SNAPSHOT argument unless a management
 tasks specifically requires it. A snapshot file is
 significantly less efficient than a memory image file, and if
 you create a snapshot file that is more recent than a memory
 image file, you invalidate the memory image file. The FROM
 SNAPSHOT argument is supported for a small number of management
 tasks only. Forcing the DSA to read a new schema is one of those
 tasks.

5.2.2  –  Responses

 The CREATE DSA directive can return one of the following
 responses:

 New DSA database created. Configure the DSA.

    This means that the DSA has been created for the first time.
    Use the DSA configuration utility to give the DSA a basic
    configuration.

 DSA created successfully from memory image file.

    This means that the DSA has been created from a valid memory
    image file.

 DSA created successfully from memory image file.
 Schema Warning: The memory image file does not use
 the current schema.

    This means that the DSA has been created from a valid memory
    image file. However, the DSA detected that the copy of the
    schema in its memory image file is not the same as the one
    in /var/dxd. If the schema has been customized, you should
    force the DSA to read the new schema. Use the following
    commands:

    > DELETE DSA TO SNAPSHOT
    > CREATE DSA FROM SNAPSHOT

    This forces the DSA to read the schema during creation.

 DSA created successfully from snapshot file.

    This means that the DSA has been created from a valid
    snapshot file. On Tru64 UNIX systems, you should only
    use a snapshot file for management tasks that specifically
    require it. On the first occasion that you start the DSA
    after an upgrade, the DSA reads the existing snapshot file.
    After the first DIT check interval, or when you delete the
    DSA, the DSA creates a memory image file. It then reads
    and writes memory image files unless specifically instructed
    to read or write a snapshot file.

5.2.3  –  Errors

 The CREATE directive can return one of the following errors:

 REASON:         Already Exists
 DESCRIPTION:    The DSA entity already exists.

 REASON:         Communication Failure
 DESCRIPTION:    There has been a failure in communication.

                 This means that communication has not been successful.
 		The response gives more information about the failure.

 REASON:         DSA Information Tree Corrupt
 DESCRIPTION:    The DSA Information Tree is corrupt.

                 The copy of the DSA database stored on disk
                 is corrupt and consequently not loaded into memory.
                 On Tru64 UNIX systems, this error is also used
                 if you specify the FROM MEMORY IMAGE or FROM
                 SNAPSHOT argument on the CREATE DSA command, but
                 there is no memory image or snapshot file available.
                 If this is the case, repeat the command without
                 the argument.

 REASON:         DSA Information Tree Incompatible
 DESCRIPTION:    The DSA Information Tree is incompatible with
                 this version of the DSA.

                 This can only happen after an upgrade of the
                 Enterprise Directory software.

 REASON:         DSA Information Tree Schema Incompatible
 DESCRIPTION:    The DSA Information Tree and Schema are incompatible.

                 The DSA Information Tree contains information that
                 is not defined in the schema. The missing definition
                 is identified in a supplementary message.

 REASON:         License Check Failed
 DESCRIPTION:    The license check has failed for this product.

                 A valid HP X.500 Directory Server license has not
                 been installed.

 REASON:         Schema Corrupt
 DESCRIPTION:    The schema file is unreadable. Recompile the schema.

 REASON:         Schema Incompatible
 DESCRIPTION:    The schema file is of a different version from the
                 DSA. Recompile the schema.

 REASON:         Database Loading
 DESCRIPTION:    The DSA is currently being created.

                 Two CREATE directives have been issued in quick
                 succession. No action is necessary.

5.3  –  DELETE

 Use this directive to delete a DSA. The DSA must be in state OFF when
 you delete it. For more information on a DSA's state, refer to STATUS
 attributes.

 Syntax:
 	DELETE DSA [TO MEMORY IMAGE | TO SNAPSHOT]

 The DSA writes its directory information to disk when you use
 the DELETE directive. This means that all DSA information is saved,
 with the exception of any Accessor entities. When you next create
 the DSA, it will reconfigure itself automatically by reading its
 database files.

 The DELETE DSA options are only available on Tru64 UNIX. On OpenVMS
 systems, the directive DELETE DSA always produces a snapshot file.

 DSAs on Tru64 UNIX systems use memory image files instead of the
 snapshot files, by default. The DSA can read memory image files
 much faster, especially for large databases.

 Snapshot files are only supported on Tru64 UNIX systems for a
 small number of management tasks. These are documented in HP
 Enterprise Directory  - Management. You are advised
 not to use the TO SNAPSHOT argument unless performing one of the
 tasks that specifically requires it.

5.3.1  –  Errors

 The DELETE directive can return the following error:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 The DSA is not in state OFF. The error indicates what
 state the DSA is in.

5.4  –  DISABLE

 Use this directive to disable a DSA. This means the
 DSA is unable to accept communications from DUAs or other DSAs. On
 completion of this directive, the DSA is in state OFF. For more
 information on the state of a DSA, refer to STATUS attributes.

 Syntax:
 	DISABLE DSA

5.4.1  –  Errors

 The DISABLE directive can return the following error:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 The error indicates what state the DSA is in.
 The DSA must be in state ON for the ENABLE directive to
 succeed.

5.5  –  ENABLE

 Use this directive to enable the DSA for communication with directory
 applications and other DSAs. On completion of this directive, the DSA
 is set to state ON.  The DSA listens for DOP, DSP, DAP, and DISP bind
 requests, depending on your setting for Presentation Address.  In
 addition, if you have set LDAP Port to a non-zero value, the DSA
 listens for LDAP requests.  For more information on a DSA's state, refer to
 STATUS attributes.

 Syntax:

 	ENABLE DSA

5.5.1  –  Errors

 The ENABLE directive can return one of the following errors:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 If the DSA is in state CREATING, ENABLING or UPDATING, wait for
 the DSA to complete the relevant task. The response indicates the
 current state of the DSA.

 REASON:         No AE Title
 DESCRIPTION:    The DSA's AE Title attribute has not been set.

 Use the SET DSA AE TITLE directive to set a valid AE Title.
 Refer to DSA Common_Datatypes for details of how to
 specify a valid AE Title attribute. Remember that the AE Title
 attribute should match the distinguished name of the directory
 entry that represents this DSA.

 REASON:         No Presentation Address
 DESCRIPTION:    The DSA's Presentation Address attribute has not
                 been set.

 Use the DSA configuration procedure to set a presentation address.
 See HP Enterprise Directory  - Management for
 details of how to use the DSA configuration procedure.

5.6  –  Examples

 	> CREATE DSA
         > SET DSA AE TITLE "/C=US/O=Abacus/CN=DSA"
         > SET DSA PRESENTATION ADDRESS -
         _> '"DSA"/"DSA"/"DSA"/NS+48909090AA001122,CLNS'

 	> SHOW DSA ALL ATTRIBUTES

 	> ENABLE DSA

 	This command enables the DSA for communication with
 	directory applications and other DSAs.

 	> DISABLE DSA
 	> DELETE DSA

 	The first command disables the DSA from communication. This
 	means that it cannot communicate with a DUA or another DSA.
 	The state of the DSA changes from ON to OFF and it is no
 	longer available for communication. The DSA can now be
 	deleted. This is performed by the second command.

 	> UPDATE DSA SUPPLIER -
         _> '"DSA"/"DSA"/"DSA"/NS+48909100aa006712121,CLNS'

 	This command starts the replication of naming contexts from
 	the DSA with the specified presentation address to this DSA.
         DSAs only require the UPDATE DSA command to be used
 	once. Subsequent replication should be automatic, if you
 	follow HP's recommendations, as documented in HP
 	Enterprise Directory  - Management. By default,
 	DSAs communicate with their shadowing partners every 12 hours
 	to make sure that shadow copies of information are up to
 	date.

5.7  –  REMOVE

 Use the REMOVE directive to remove a value from a DSA
 multi-valued characteristic attribute. The DSA multi-valued
 characteristic attributes are:

 -	READ ONLY DSA NSAPS
 -	READ ONLY DSA NAMES
 -	WRITER NAMES
 -	WRITER NSAPS
 -	READER NAMES
 -	READER NSAPS
 -	TRUSTED DSA NAMES
 -	TRUSTED DSA NSAPS

 Syntax:

 	REMOVE DSA <characteristic> {<value>,...}

 where <characteristic> is the name of the Characteristic attribute
 and <value> is the value you want to remove from the attribute.

5.8  –  SET

 Use the SET directive to set the value of an attribute.

 You can set all the characteristic attributes of the DSA entity
 with the exception of the Version attribute. This attribute is a
 read-only characteristic attribute.

 Syntax:
 	SET DSA <attr> <value>

 where <attr> is the name of the attribute and <value> is
 the value you want to assign to the attribute.

 When you use the SET directive, any existing value of the attribute
 is removed, leaving only the value that you now specify. To specify
 a new value in addition to any existing values, use the ADD directive.

5.9  –  SHOW

 Use the SHOW directive to display the attributes of a DSA
 entity.

 You can use the SHOW directive on all Characteristic, Status and
 Counter attributes of the DSA entity.

 Syntax:

 	SHOW DSA <attr>

 where <attr> is the name of the Characteristic, Status
 or Counter attribute you want to display.

 You can display the values of multiple attributes using
 one SHOW directive by separating the attributes with a comma,
 for example:

 	SHOW DSA <attribute1>, <attribute2>

 You can also show all attributes, or all attributes of a given
 type, as follows:

 	SHOW DSA ALL ATTRIBUTES
 	SHOW DSA ALL CHARACTERISTICS
 	SHOW DSA ALL STATUS
 	SHOW DSA ALL COUNTERS

5.10  –  UPDATE

 Use the UPDATE directive to initiate replication. On issuing
 this directive, the DSA specified in the SUPPLIER argument
 provides copies of one or more naming contexts (see the
 Naming Context entity) to this DSA.  You can only use the
 UPDATE directive when the DSA is in state ON.

 Syntax:
 	UPDATE DSA SUPPLIER <supplier>

 Refer to Arguments for details of <supplier>.

 You should only need to use the UPDATE DSA directive when you implement
 replication for the first time. Once replication has been established,
 the DSAs continue to replicate automatically according to a 12 hour
 schedule. This assumes you follow HP's recommendations, as
 documented in HP Enterprise Directory  - Management.

5.10.1  –  Arguments

 The UPDATE directive has one argument: SUPPLIER.  The SUPPLIER
 argument specifies either the AE title or the presentation address
 of the DSA which will supply copies of naming contexts.

 If you use the AE title argument, the directive only succeeds if
 a directory entry of the same name is accessible to this DSA and
 contains a valid presentation address for the supplier DSA.

 Specify the argument as follows:

 	UPDATE DSA SUPPLIER '<ae title>'
         UPDATE DSA SUPPLIER '<presentation address>'

 Refer to DSA Common_Datatypes for information on how
 to specify an AE title or a presentation address.

5.10.2  –  Errors

 The UPDATE directive can return one of the following errors:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

                 The error indicates what state the DSA is in.
                 The DSA must be in state ON when you use the
                 UPDATE DSA directive.

 REASON:         Invalid Address
 DESCRIPTION:    The Supplier argument is not a valid presentation
                 address.

                 Check the presentation address of the DSA that is
                 to be the supplier DSA, and specify that address
                 correctly.

 REASON:         Invalid Supplier Name
 DESCRIPTION:    The Supplier argument is not a valid directory name.

                 Check the AE title of the DSA that is to be the
                 supplier DSA, and specify that AE title correctly.

 REASON:         Supplier Unavailable
 DESCRIPTION:    The Supplier DSA is unavailable.

                 This error usually means that the supplier DSA
                 cannot verify the identity of the consumer DSA.
                 Refer to HP Enterprise Directory
                 - Management for details of replication, and its
                 prerequisite tasks.

                 The error can also mean that the supplier DSA  is
                 unavailable temporarily, and a later attempt to
                 replicate will succeed.

                 The error can also mean that the supplier DSA has
                 insufficient diskspace to write the shadow
                 information  to disk before sending it to the
                 consumer DSA. Check  the events generated on the
                 supplier DSA to see  whether they explain the
                 failure of replication.

 REASON:         Schema Incompatible
 DESCRIPTION:    Supplied update incompatible with the DSA.

                 The two DSAs have different schema, and the
                 information in the supplied naming context does not
                 conform to the schema of this  DSA.

                 The consumer DSA needs schema that supports all of
                 the attribute types, syntaxes, and structure rules
                 used in the shadowed naming context. HP
                 recommends that all of your DSAs have identical
                 schema files.

 REASON:         DIT Incompatible
 DESCRIPTION     Supplied update incompatible with the DSA.

                 The consumer naming context clashes with the DIT
                 of the consumer DSA. For example, the consumer
                 DSA might have a naming context that overlaps
                 with the consumed naming context.

                 This indicates that you have a problem with your
                 DSA configuration, and you should check all DSAs
                 to ensure that they have a consistent understanding
                 of the division of your DIT.

 REASON:         Update Incompatible
 DESCRIPTION:    Supplied update incompatible with the DSA.

                 The supplied naming context contains information
                 that is incompatible with this DSA.

 REASON:         Insufficient Resources
 DESCRIPTION:    There are insufficient resources to perform the
                 update.

                 This usually means that the consumer DSA has
                 insufficient diskspace to write the shadow
                 information to disk before applying it to its
                 database. It can also mean that the consumer DSA
                 has insufficient memory to add the shadow
                 information to whatever information it already
                 holds.

 REASON:         Insufficient Resources DSA Deleted
 DESCRIPTION:    Failed in performing the Update due to insufficient
                 resources. DSA deleted.

                 This is similar to the Insufficient Resources
                 problem, but the DSA has already made changes to
                 its database. It therefore deletes itself to
                 prevent corruption of its existing data. When you
                 recreate the DSA, it recovers the data that it
                 held prior to the failed update.

 REASON:         No Address
 DESCRIPTION:    Cannot read address for specified DSA.

                 You specified an AE title for the supplier DSA.
                 The consumer DSA looked the AE title up in the
                 directory, but found that the entry representing
                 the supplier DSA does not have a  presentation
                 address attribute, or that it could not read the
                 presentation address attribute.

                 Check that the entry representing the supplier DSA
                 has a presentation address attribute, and that it
                 is accessible to the consumer DSA. Otherwise
                 specify the presentation address of the supplier
                 DSA on the UPDATE command, so that a lookup is not
                 required.

 REASON:         Bad Update
 DESCRIPTION:    Invalid data received from Supplier.

                 This means that there is a problem with the
                 protocol passed between the supplier DSA and
                 consumer DSA. The consumer DSA therefore does not
                 apply any changes to its database.  Try the update
                 again, to see whether the error recurs. If so,
                 report this error to HP.

 REASON:         Bad Update DSA Deleted
 DESCRIPTION:    Invalid data received from Supplier. DSA deleted.

                 This is similar to the Bad Update error. However,
                 the consumer DSA has already started applying
                 changes to its database before detecting the
                 error. It therefore deletes itself to prevent
                 corruption of its data. When you recreate the
                 consumer DSA, it recovers the database that it
                 held prior to the failed update.

 REASON:         Unexpected Failure
 DESCRIPTION:    Unexpected failure.

                 Check the events generated by the supplier DSA and
                 the consumer DSA to see whether they explain the
                 failure.

 REASON:         Comms Failure
 DESCRIPTION:    The update failed due to a communications problem.

                 See HP Enterprise Directory - Problem Solving for
                 information about fixing communications problems.

6  –  Events

 When an event occurs, the DSA sends a description of the event
 to the event sink. The events are described below.

6.1  –  Accounting Disabled

 This event is generated when the DSA disables the accounting
 facility. When the DSA disables the accounting facility, it closes
 the accounting file. The event contains the filename of the closed
 accounting file.

6.2  –  Accounting Enabled

 This event is generated when the DSA successfully enables the
 accounting facility. The event contains the filename of the
 accounting file.

6.3  –  Accounting File Rollover

 This event is generated when the DSA rolls over the accounting file,
 that is, closes the current accounting file and creates a new
 accounting file. The event contains the following information:

 -   The filename of the closed accounting file.
 -   The filename of the new accounting file.

6.4  –  Accounting File Access Failure

 The event contains the following information:

 -   What type of access the DSA was trying to make to the accounting
     file. This can be one of WRITE, OPEN, or CLOSE access.

 -   A system message that indicates why the DSA failed to access the
     accounting file. The system messages are described in the
     documentation for your operating system.

 -   The filename of the accounting file that the DSA failed to open.

6.5  –  Accounting Records Discarded

 This event is generated when the DSA is forced to discard records
 without writing them in the accounting file. The reasons why the DSA
 may be forced to discard accounting files are described in HP Enterprise
 Directory  - Problem Solving. The event indicates the number of
 records discarded since the last record was successfully written in
 the accounting file.

6.6  –  Authentication Failure

 This event is generated when the DSA fails to authenticate the
 originator of a Bind request.  The event returns the following
 information:

 -    The reason why authentication failed. This may be one
      of the following:

      -  Unknown User.
         The distinguished name supplied in the Bind request does not
         identify an entry within the directory.

      -  Incorrect Password.
         The password supplied in the Bind request does not match the
         password stored in the directory entry identified by the
         supplied distinguished name.

      -  Inaccessible Password.
         The DSA could not verify the supplied password because the
         DSA containing the directory entry is not accessible. This
         might be a temporary problem, for example, the connection to
         that DSA cannot be made, or it might be a more permanent
         problem, where the DSA holding the directory entry is not
         a trusted DSA.

      -  Password Verification Loop.
         When a DSA attempts to verify a password, it might need to
         communicate with another DSA to access the directory entry
         that contains the password. This communication might also
         require the specification of a password, which must be
         verified by the second DSA. It is therefore possible that
         two DSAs will find themselves in a situation where each is
         waiting for the other to verify a password. If this happens,
         one of the DSAs detects the problem, and the authentication
         fails.

 -    Information on the application or user that requested the
      operation. This comprises:

      - The application entity title of the DSA from which the Bind
        request was received.

      - The presentation address of the DSA from which the Bind
        request was received.

      - The distinguished name that was supplied in the Bind request,
        if any.

      - The directory protocol in use, that is DAP, DSP, DISP, or DOP.

 The DAP protocol is used by directory applications to bind to the DSA.
 The DSP protocol is used by other DSAs to chain requests to the DSA.
 The DOP protocol is used by other DSAs to manage shadowing agreements.
 The DISP protocol is used by other DSAs to replicate information to
 or from this DSA.

6.7  –  Create Failure

 This event is generated when the DSA fails to create the DSA entity
 in response to the CREATE DSA directive. The event provides the
 following information:

 -    The reason why the DSA entity could not be created. This is
      one of the following:

      -	Database already in use by another DSA.
 	The DSA is trying to connect to a database that is being
 	used by another DSA.

      -  DIT Incompatible.
         The DSA database is incompatible with this version
         of the DSA. This can only occur after an upgrade of the
         DSA software.

      -  DIT Corrupt.
         The DSA database is corrupt.

      -  DIT and Schema Incompatible

         The DIT contains information that is not defined in the
         schema. Fix your schema files, recompile them, and restart
         the DSA.

      -  Schema Incompatible.
         The directory schema is incompatible with this version of
         the DSA.  Both the schema compiler and the DSA contain
         internal revision numbers that define the revision level
         of the software.  The most likely cause of this event
         message is that an old version of the schema compiler has
         been used to compile the schema files. This can only happen
         after an upgrade of the DSA software.

      -  Schema Corrupt.
         The directory schema is corrupt. Recompile the schema.

      -  License Check Failure.
         The license check for the product has failed.

      -  System Error.
         An unexpected system error has occurred.

 -    Additional information that assists in diagnosing the reason
      for the failure.  For example, if the reason is set to System
      Error, the diagnostic string might provide the actual reason,
      such as insufficient memory.

6.8  –  Distributed Operation Failure

 A Distributed Operation Failure event is issued when the DSA
 cannot connect to another DSA.

 The event returns the following information:

 -    Reason.
      This is one of the following:

      -  Communications Failure.
         The DSA could not establish an association for one of the
         following reasons stated in the event:

         -  Fatal Interface Error
         -  Insufficient Resources
         -  Network Unavailable
         -  Address Already In Use
         -  Invalid AEI
         -  Transport Error
         -  System Error
         -  Invalid Transport Template
         -  Unknown Error

      -  DSA Not Trusted
         The target DSA does not trust this DSA, and considers that
         the connection requires trust.

      -  Authentication Failure.
         The target DSA could not verify this DSA's password.
         Refer to HP Enterprise Directory  - Problem Solving.

      -  Invalid Reference.
         The target DSA does not hold the part of the DIT that this
         DSA expects it to. The knowledge information of this DSA is wrong.
         See HP Enterprise Directory  - Problem Solving.

      -  Remote Operation Rejected.
         The target DSA has rejected the remote operation. This is
         normally due to a protocol error.

 -    Diagnostic.
      This may be, for example, an internal system error code.

 -    Target DSA.
      The access point of the target DSA with which this DSA was
      attempting to communicate when the failure occurred.

 -    Requestor.
      Information on the application or user that requested the
      operation. This comprises:

      -  The application entity title of the DSA from which the Bind
         request was received.

      -  The presentation address of the DSA from which the Bind
         request was received.

      -  The distinguished name that was supplied in the Bind request,
         if any.

      -  The directory protocol in use, that is, DAP, DSP or the DEC
         Shadow Protocol.

6.9  –  Failure To Start Accounting Facility

 The event indicates the reason why the DSA failed to start
 the accounting facility. The reason can be either of the following:

 -   There was insufficient disk space for the accounting facility.
     In this case, you need to release extra disk space on the
     disk that the accounting facility uses, and then start the
     accounting facility. Moving or deleting accounting files
     might be the simplest solution.

     HP recommends that you store accounting files on a
     different disk to the DSA files, as follows:

     -   On Tru64 UNIX systems, create a softlink in the /var/dxd
         directory so that the /var/dxd/accounting directory is on
         a different disk.

     -   On OpenVMS systems, define the logical DXD$ACCOUNTING to
         point to a directory on a different disk to the one that
         contains DXD$DIRECTORY.

 -   The DSA failed to create an accounting thread.

     Restart the accounting facility. If this problem happens
     frequently, report it to HP.

6.10  –  Internal Error

 An Internal Error event is generated when the DSA detects an internal
 error. Report this error to HP.

 Each occurrence of this event results in the Internal Errors counter
 being incremented by 1.

6.11  –  Listen Failure

 This event is generated when the DSA fails to set up its own
 presentation address for receiving communications.  The event
 provides a diagnostic message, and one of the following reasons:

         -  Fatal Interface Error
         -  Insufficient Resources
         -  Network Unavailable
         -  Address Already In Use
         -  Invalid AEI
         -  Transport Error
         -  System Error
         -  Invalid Transport Template
         -  Unknown Error

6.12  –  Resource Exhausted

 A Resource Exhausted event is generated when the DSA detects that
 a critical resource is exhausted, preventing it from performing an
 operation.

 Each occurrence of this event results in the Exhausted Resource
 counter being incremented by 1.

 The event identifies the resource which is exhausted. This is one
 of the following:

 -    Insufficient Memory.
      Insufficient memory remains to process the operation.

 -    Fatal Memory Exhaustion
      The DSA has run out of memory during an essential operation.
      The DSA exits to avoid corrupting the database. The event
      indicates how many bytes of memory were not available.
      You should take steps to increase the amount of memory
      available to the DSA.

 -    Insufficient License Capacity.
      The DSA contains more entries than its licenses permit.
      Reduce the DSA's entry count, or load more licenses.

 -    Insufficient Associations.
      Insufficient resources are available to process a BIND operation.

 -    Insufficient Disk Space.
      Insufficient disk space remains to perform a backup of the
      DSA's DIB fragment.

 -    Insufficient Threads.
      Insufficient processor threads remain to perform the requested
      operation.

 -    Miscellaneous Resource Exhausted.
      A miscellaneous resource is exhausted.

6.13  –  Shadow Agreement Update Complete

 This event is generated when a DSA successfully creates, modifies,
 or deletes a shadowing agreement. A shadowing agreement describes
 how and when a DSA must replicate a given naming context to or
 from another DSA. The event provides the following information:

 -    The name of the naming context to which the agreement applies

 -    Whether this DSA is the supplier or consumer DSA

 -    The access point of the other DSA that the agreement applies to

 -    The identifier of the agreement that was successfully updated

 Note that updating an agreement does not mean that replication
 has taken place. The success or failure of replication
 is indicated by the Shadow Update Complete and Shadow Update
 Failure events. This event indicates only that the DSA has
 successfully managed an agreement, for example, to reschedule
 replication.

6.14  –  Shadow Agreement Update Failure

 This event is generated when a DSA fails to create, modify,
 or delete a shadowing agreement. The event provides the
 following information:

 -    One of the following Shadowing Agreement Problems:

      -  Communications Problem
      -  DOP error received
      -  DOP error sent

 -    The name of the naming context to which the agreement applies

 -    Whether this DSA is consumer of supplier DSA

 -    The access point of the other DSA that the agreement applies to

 -    If the Shadowing Agreement Problem was a Communications Problem,
      a diagnostic message is provided, and one of the following reasons;

      - Fatal Interface Error
      - Insufficient Resources
      - Network Unavailable
      - Address Already In Use
      - Invalid AEI
      - Transport Error
      - System Error
      - Invalid Transport Template
      - Unknown Error
      - ACSE User Reject

 -    If the Shadowing Agreement Problem was either DOP error received
      or DOP error sent, one of the following reasons;

      -  Invalid ID
      -  Duplicate ID
      -  Unsupported Binding Type
      -  Not Allowed For Role
      -  Parameter Missing
      -  Role Assignment
      -  Invalid Start Time
      -  Invalid End Time
      -  Invalid Agreement
      -  Currently Not Decidable
      -  Modification Not Allowed

 -    The identifier of the agreement that was not updated.

 Most of the DOP problems are self correcting. For example, the
 Duplicate ID problem leads to the proposal of a different
 agreement identifier. The Invalid Agreement and the Currently
 Not Decidable problems may require manual intervention. See
 HP Enterprise Directory  - Problem Solving for
 details of how to handle those problems.

6.15  –  Shadow Update Complete

 This event is generated when the DSA has successfully updated a
 shadow naming context. Either the consumer DSA or the supplier DSA,
 or both, may generate this event. The event provides the following
 information:

 -    The name of the naming context that was updated.

 -    Whether this DSA is the supplier DSA or the consumer DSA.

 -    The access point of the other DSA.

 -    The identifier of the shadowing agreement relating to the
      replication that completed successfully.

 -    The type of update that took place, which is one of:

      -  No changes
      -  Incremental
      -  Total

6.16  –  Shadow Update Failure

 This event is generated when the DSA fails to update a shadow naming
 context. This event can be generated by both the supplier and the
 consumer of the naming context. The event provides the following
 information:

 -    The reason for the failure, which is one of the following:

      -  Supplier DSA Unavailable
      -  Cannot Save Updates
      -  Update Incompatible
      -  Failed to Apply Updates
      -  Invalid Arguments
      -  Cannot Read Supplier Address
      -  Invalid Protocol
      -  Unexpected Failure
      -  Consumer Not Authenticated
      -  Communications Failure
      -  DISP error received
      -  DISP error sent
      -  Schema incompatible
      -  DIT incompatible

 -    The name of each naming context that failed to be updated.

 -    Whether the DSA generating the event was the supplier
      DSA or the consumer DSA.

 -    The access point of the DSA with which the update was processed.

 -    If the reason was DISP error received or DISP error sent, then
      the agreement identifier is displayed, and one of the following
      problems:

       -  Invalid Agreement ID
       -  Inactive Agreement
       -  Invalid Information Received
       -  Unsupported Strategy
       -  Missed Previous
       -  Full Update Required
       -  Unwilling To Perform
       -  Unsuitable Timing
       -  Update Already Received
       -  Invalid Sequencing

 Most of the DISP problems are self correcting. In some cases, a
 DISP problem causes a total (or full) update to occur. This makes
 sure that the consumer DSA has a complete, up-to-date copy of the
 relevant naming context.

 Some of the DISP problems can only be generated if an HP DSA
 is interworking with another vendor's DSA.

 If any of these problems happen frequently, refer to HP Enterprise
 Directory  - Problem Solving.

6.17  –  State Change

 This event is generated when the state of the DSA changes, either as
 a result of a management directive, or as a result of an operational
 problem. The event provides the following information:

 -    The old state of the DSA
 -    The new state of the DSA

7  –  Naming Context

 A Naming Context entity represents a part of the directory
 information tree which is held by this DSA. A naming context
 is a subtree of the DIT. It extends from the entry that has
 the same name as the Naming Context entity, down to a
 subordinate reference, or to entries that have no subordinates.

7.1  –  Characteristics

 A Naming Context entity has three characteristic attributes:

 -	Master Access Point
 -	Supplier Access Point
 -	Consumer Access Point

 You can use the ADD, SET, and REMOVE directives on the Consumer
 Access Point attribute only. The remaining two attributes are
 read-only attributes and have values set for them during
 replication (see HP Enterprise Directory  - Management).

 You can display the current value of all attributes by specifying
 them in a SHOW directive.

 Syntax:

 ADD     DSA NAMING CONTEXT <name> <attr> {<value>,...}
 REMOVE  DSA NAMING CONTEXT <name> <attr> {<value>,...}
 SET     DSA NAMING CONTEXT <name> <attr> {<value>,...}
 SHOW    DSA NAMING CONTEXT <name> <attr>

 where <name> is the name of the naming context, specified
 in quotes, <attr> is a characteristic attribute name and
 <value> is the value.

 You can display the values of many attributes in one SHOW directive
 by separating the attributes with a comma, for example:

 SHOW DSA NAMING CONTEXT <name> <attribute1>, <attribute2>

 Also, you can use the ALL CHARACTERISTICS qualifier with the
 SHOW directive, for example:

 SHOW DSA NAMING CONTEXT <name> ALL CHARACTERISTICS

 You can also use the wildcard "*" in a SHOW directive, to
 show details of all naming contexts; for example:

 SHOW DSA NAMING CONTEXT * ALL CHARACTERISTICS

7.1.1  –  Consumer Access Point

 The Consumer Access Point attribute contains the access point
 of the DSA to which this DSA can supply a copy of this naming
 context. You can set the Consumer Access Point attribute using
 the SET directive, add new values using the ADD directive, or
 remove values using the REMOVE directive. You can also display
 the current contents of the attribute using the SHOW directive.

 There is no default value.

 Syntax:

 ADD DSA NAMING CONTEXT <name> CONSUMER ACCESS POINT {<value>,...}

 SET DSA NAMING CONTEXT <name> CONSUMER ACCESS POINT {<value>,...}

 REMOVE DSA NAMING CONTEXT <name> CONSUMER ACCESS POINT {<value>,...}

 SHOW DSA NAMING CONTEXT <name> CONSUMER ACCESS POINT

 where <value> is the access point of the DSA and is
 specified as follows:

    [ae title = "<distinguished name of DSA>",
      presentation address = '<presentation address>']

 The AE Title and Presentation Address attributes are both mandatory.
 Note that you must specify the AE Title and Presentation
 Address in the order shown above.

 Specify all valid NSAPs for a consumer DSA. This improves the
 network efficiency of this DSA, because it ensures that any
 existing connection to that DSA will be re-used. It also ensures
 the success of the documented method of implementing replication
 for the first time.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

7.1.2  –  Master Access Point

 The Master Access Point attribute contains the access point of
 the DSA which holds the master of this naming context. If
 the attribute has a value, then the naming context is a
 shadow naming context, that is, a naming context that has been
 replicated to this DSA. If the attribute has no value, then this
 DSA is the master DSA for the naming context.

 The Master Access Point attribute is read-only and single-valued.

 Syntax:
 	SHOW DSA NAMING CONTEXT <name> MASTER ACCESS POINT

 where <name> is the identifier of a Naming Context entity.

7.1.3  –  Supplier Access Point

 The Supplier Access Point attribute contains the access point of
 the DSA which supplied a copy of this naming context to this DSA.
 If the attribute has a value, it indicates which DSA supplied the
 shadow naming context. The Supplier Access Point attribute
 is read-only and single-valued.

 Syntax:
 	SHOW DSA NAMING CONTEXT <name> SUPPLIER ACCESS POINT

 where <name> is the identifier of a Naming Context entity.

7.2  –  Directives

 You can use the ADD, CREATE, DELETE, REMOVE, SET, and SHOW
 directives with the Naming Context entity.

 The CREATE and DELETE directives are used to create and delete
 a Naming Context entity.

 The SET and SHOW directives are used to set or display
 Naming Context attributes, respectively.

 The ADD and REMOVE directives are used to add or remove
 additional values to a Naming Context characteristic
 attribute.

7.2.1  –  ADD

 Use the ADD directive to add value(s) to a
 Naming Context characteristic attribute.

 You can use the ADD directive on the Consumer Access
 Point characteristic attribute only. The other attributes
 of this entity are read-only.

 Syntax:

 	ADD DSA NAMING CONTEXT <name>
 	    CONSUMER ACCESS POINT {<value>,...}

 where <value> is the value you want to add to the
 attribute.

7.2.2  –  CREATE

 Use this directive to create a Naming Context entity of the
 specified name at the specified position in the DIT.

 Syntax:
 	CREATE DSA NAMING CONTEXT <name> <argument> <value>

7.2.2.1  –  Arguments

 The CREATE directive has an identifier and one argument:

 -	CONSUMER ACCESS POINT

 The identifier specifies the name of this Naming Context
 entity. This is in the form of a distinguished name.

 The CONSUMER ACCESS POINT argument is optional and
 identifies the DSA to which this DSA can supply a copy
 of this naming context. Specify this argument in the
 following format:

         CONSUMER ACCESS POINT <access point>

 where <access point> is the access point of the DSA and is
 specified as follows:

    {[ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']}

 You can specify multiple access points as follows:

    {[ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>'] ,
     [ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']}

 The AE Title and Presentation Address attributes are both mandatory.
 Note that you must specify the AE Title and Presentation
 Address in the order shown above.

 Specify all valid NSAPs for a consumer DSA. This improves the
 network efficiency of this DSA, because it ensures that any
 existing connection to that DSA will be re-used. It also ensures
 the success of the documented method of implementing replication
 for the first time.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

7.2.2.2  –  Errors

 The CREATE directive can return the following errors:

 REASON:         Already Exists
 DESCRIPTION:    This Naming Context entity already exists.

                 A Naming Context entity already exists at this
                 position in the DIT. You cannot create a Naming
                 Context entity where one already exists.

 REASON:		Cannot open the database
 DESCRIPTION:	The DSA cannot open the database as it is being
 		used by another DSA.

 REASON:         Invalid Name
 DESCRIPTION:    The entity name is not a valid directory name.

                 The name must be in the form of a distinguished
                 name. The response shows the invalid name component.

 REASON:         Has Subordinates
 DESCRIPTION:    The DSA already holds entries or entities
                 subordinate to the entity being created.

                 You cannot create a Naming Context entity at
                 this position in the DIT because the name you
                 have specifed has subordinates. You must create
                 entities in a hierarchical order (top down).

 REASON:         Incomplete Naming Context
 DESCRIPTION:    A superior Naming Context that is not correctly
                 terminated by a Subordinate Reference prevents
                 creation.

                 The DSA failed to create the Naming Context entity
                 because a superior master Naming Context entity has
                 not been terminated. A Naming Context must
                 be terminated by a Subordinate Reference entity if
                 want to create a further Naming Context entity
                 beneath it.

                 The response shows the name of the incomplete naming
                 context.

 REASON:         Incomplete Shadow Naming Context
 DESCRIPTION:    A superior shadow Naming Context that has not been
                 correctly terminated by a Subordinate Reference
                 prevents creation.

                 The DSA failed to create the Naming Context entity
                 because a superior shadow Naming Context entity has
                 not been terminated. A Naming Context must
                 be terminated by a Subordinate Reference entity if
                 you want to create a further Naming Context entity
                 beneath it. Because the superior entity is a shadow,
                 you need to create a Subordinate Reference entity
                 on the master DSA for the superior naming context,
                 and then initiate replication so that this DSA
                 has a copy of the new Subordinate Reference entity.

                 The response shows the name of the incomplete naming
                 context, and the name of the master DSA for that
                 naming context.

 REASON:         DIT Root
 DESCRIPTION:    Cannot create a Naming Context at the root of the
                 DIT.

                 You cannot create a Naming Context entity directly
                 on the root entry of the DIT (/).  A Naming Context
                 entity must have a distinguished name that contains
                 at least one relative distinguished name.

 REASON:         Entry Already Exists
 DESCRIPTION:    The DSA already holds an entry of the same name.

                 An entry already exists with the same name. You
                 cannot create a Naming Context entity where a
                 directory entry already exists. That entry must
                 already be part of a naming context, so it would
                 be inappropriate to create one at this point in
                 the DIT.

 REASON:         Alias Entry Already Exists
 DESCRIPTION:    The DSA already holds an alias entry of the
                 same name.

                 An alias entry already exists with the same name.
                 You cannot create a Naming Context entity where
                 an alias entry already exists. That alias entry
                 must already be part of a naming context.

 REASON:         Alias Entry
 DESCRIPTION:    Alias entry prevents creation.

                 The identifier you specified for the Naming
                 Context entity is an alias name, not a
                 distinguished name. The DSA does not support the
                 use of alias names when managing entities. Specify
                 the distinguished name of the entry that is to
                 be at the top of the new naming context.

                 The response shows the name of the alias entry.

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

                 The DSA must be in state ON, OFF, ENABLING,
                 or DISABLING when you create a Naming Context
                 entity.

                 The response shows the current state of the DSA.

7.2.3  –  DELETE

 Use this directive to delete a Naming Context entity.

 Syntax:

 	DELETE DSA NAMING CONTEXT <name>

7.2.3.1  –  Errors

 The DELETE directive can return one of the following errors:

 REASON:         Has Subordinates
 DESCRIPTION:    The DSA has entries or entities subordinate
                 to the entity being deleted.

                 You cannot remove a Naming Context entity if it
                 contains directory entries or further entities, such
                 as Subordinate Reference entities. You must delete
                 everything beneath the Naming Context entity first.

 REASON:         Not Empty
 DESCRIPTION:    You cannot delete a Naming Context that contains
                 entries.

                 The Naming Context entity coexists with a directory
                 entry. You cannot delete the entity until you have
                 deleted the directory entry.

 REASON:         Contains Alias
 DESCRIPTION:    The alias entry with the same name must be deleted
                 before the Naming Context can be deleted.

                 The Naming Context entity coexists with an alias
                 entry. You cannot delete the entity until you
                 have deleted the alias entry using DXIM, or another
                 directory application.

 REASON:         Alias Entry
 DESCRIPTION:    Alias entry prevents deletion.

                 The identifier you specified for the Naming Context
                 entity is an alias name, not a distinguished name.
                 The DSA does not support the use of alias names
                 when deleting entities. Specify the distinguished
                 name of the entry that is at the top of the naming
                 context. The response indicates the name of the
                 alias entry.

 REASON:		Wrong State
 DESCRIPTION: 	The DSA entity is not in the correct state.

                 The DSA entity must be in state ON or OFF when you
                 delete a Naming Context entity. If the DSA is in
                 any other state, such as ENABLING or UPDATING, the
                 command fails. The response indicates the current
                 state of the DSA.

7.2.4  –  Examples

 	>  CREATE DSA NAMING CONTEXT "/C=US/O=Abacus/OU=Sales" -
 	_>	CONSUMER ACCESS POINT  -
 	_>	 {[AE Title = "/C=US/O=Abacus/CN=DSA4", -
 	_>         Presentation Address = -
 	_>         '"DSA"/"DSA"/"DSA"/NS+11002aaa00040008aa21']}

 	> SHOW DSA NAMING CONTEXT "/C=US/O=Abacus/OU=Sales" -
 	_>   ALL ATTRIBUTES

 	The first command creates a Naming Context entity and the
 	second command displays the Naming Context entity.

 	> DELETE DSA NAMING CONTEXT -
 	_>	"/C=US/O=Abacus/OU=Sales"

 	This command deletes the Naming Context entity.

7.2.5  –  REMOVE

 Use the REMOVE directive to remove a value from a
 characteristic attribute.

 You can use the REMOVE directive on the Consumer Access Point
 characteristic attribute only. The other characteristic attributes
 of this entity are read-only.

 Syntax:

 	REMOVE DSA NAMING CONTEXT <name>
 	       CONSUMER ACCESS POINT {<value>,...}

 where <value> is the value you want to remove from the
 attribute.

7.2.6  –  SET

 Use the SET directive to change the value of a Naming Context
 characteristic attribute.

 You can use the SET directive on the Consumer Access Point
 characteristic attribute only.  The remaining attributes
 are read-only characteristic attributes.

 Syntax:

 	SET DSA NAMING CONTEXT <name>
 	    CONSUMER ACCESS POINT  {<value>,...}

 where <value> is the value you want to set for the Consumer
 Access Point attribute.

 Specify all valid NSAPs for a consumer DSA. This improves
 the efficiency of the DSA, and ensures the success of the
 documented method of implementing replication.

7.2.7  –  SHOW

 Use the SHOW directive to display the characteristic attributes
 of a Naming Context entity.

 You can use the SHOW directive on all Characteristic attributes
 of the Naming Context entity.

 Syntax:

 	SHOW DSA NAMING CONTEXT <name> <attr>

 where <attr> is the name of the Characteristic attribute
 you want to display.

 You can display the values of multiple attributes using
 one SHOW directive by separating the attributes with a comma,
 for example:

 SHOW DSA NAMING CONTEXT <name> <attribute1>, <attribute2>

 You can also use the wildcard "*" in a SHOW directive, to
 show details of all naming contexts; for example:

 SHOW DSA NAMING CONTEXT * <attr>

7.3  –  Identifier

 Each Naming Context entity is uniquely identified by the
 distinguished of the highest entry within the naming context,
 for example, "/C=US/O=Abacus/OU=Sales/CN=accounts".

 Refer to DSA Common_Datatypes for more information
 on how to specify a distinguished name.  Refer to the CREATE
 directive for more information on how to create a Naming
 Context entity.

8  –  Status

 Status attributes provide you with information about a specified
 DSA. Status attributes are read only.

 All status attributes can be displayed using the SHOW directive.

 Syntax:
                 SHOW DSA <attr>

 You can display the value of multiple status attributes as part
 of one SHOW directive by separating the attributes with a comma.
 For example:
                 SHOW DSA <attribute1>, <attribute2>

 Similarly, you can display all status attributes using the ALL
 STATUS qualifier. For example:

                 SHOW DSA ALL STATUS

8.1  –  Accounting State

 The Accounting State status attribute is no longer used by the DSA.
 Refer to the help for the Accounting Facility characteristic
 attribute.

8.2  –  Attribute Count

 The Attribute Count status attribute specifies the total
 number of attributes in all of the entries in the DSA's
 database. This attribute is set by the DSA.

 Syntax:
 	SHOW DSA ATTRIBUTE COUNT

 By dividing the number of attributes by the Entry Count,
 you can estimate the number of attributes per entry.

8.3  –  DIT Memory Occupancy

 The DIT Memory Occupancy attribute specifies approximately the
 number of bytes of memory currently needed to hold the DSA
 database. This attribute is set by the DSA.

 Syntax:
 	SHOW DSA DIT MEMORY OCCUPANCY

 By dividing the DIT memory occupancy by the Entry Count,
 you can estimate the amount of memory required by a typical
 entry. This may enable you to estimate how many more entries
 the DSA could hold before memory resources are exhausted. It
 may also indicate how much memory would be required by a
 DSA that takes a shadow copy of this DSA's information.

 Memory occupancy may vary for different operating systems.

8.4  –  Entry Count

 The Entry Count status attribute specifies the number of
 entries in this DSA's database. This attribute is set and
 maintained by the DSA. The number is the total number of
 entries and shadow entries held by the DSA.

 Syntax:
 	SHOW DSA ENTRY COUNT

8.5  –  Entry Limit

 The Entry Limit status attribute specifies the number of
 entries that the DSA's license allows you to create. If
 the DSA exceeds its entry limit, the Resource Exhausted
 event is generated stating Insufficient License Capacity.

 As long as the entry limit is exceeded, you will be unable
 to create new entries in the DSA. However, if the DSA is
 a consumer DSA, its ability to receive entries from its
 supplier DSAs is unaffected.

 Refer to HP Enterprise Directory  - Problem Solving
 for details of the entry limit.

8.6  –  Examples

 	> SHOW DSA ALL STATUS

 	This command displays the value of all status attributes.

 	> SHOW DSA DIT MEMORY OCCUPANCY

 	This command displays the amount of memory in bytes,
 	currently used to store the DSA database.

8.7  –  State

 The State status attribute indicates the current state of a DSA
 entity. A DSA may be in one of the following states at any one
 time:

 -       CREATING     The DSA has received a CREATE directive,
                      and is in the process of creating.
 -	OFF	     The DSA has either been disabled or just
                      created. It is unavailable for communication
                      with applications or other DSAs. It is available
                      for most management directives.
 -	ENABLING     An ENABLE directive has been issued and the DSA
 	 	     is making itself available for communication.
                      It is the transition between the OFF and ON
                      states.
 -	ON	     The DSA has been enabled and is ready for use.
                      The DSA can now communicate with
                      applications and other DSAs.
 -	DISABLING    A DISABLE directive has been issued and the DSA
                      is disabling itself from service. It is the
                      transition between the ON and OFF states.
 -       UPDATING     The DSA is in the processing of replicating
                      information with another DSA. The DSA is either
                      supplying or consuming naming contexts.

 Syntax:
 	SHOW DSA STATE

8.8  –  UID

 The UID status attribute contains the unique identifier of a DSA
 entity. The UID is created and assigned when the DSA entity is
 created (See the CREATE directive). Use of this attribute is
 deprecated, and the attribute will be removed in a future version.

 Syntax:

 	SHOW DSA UID

8.9  –  Unique Value Count

 The Unique Value Count status attribute specifies the number
 of unique attribute values present in the DSA's database. This
 attribute is set by the DSA. A DSA stores a given attribute
 value only once, to save space and improve the performance of
 user requests.

 Syntax:
 	SHOW DSA UNIQUE VALUE COUNT

9  –  Subordinate Reference

 A Subordinate Reference entity provides a reference to a
 Naming Context entity that is beneath a Naming Context entity
 held by this DSA. The subordinate Naming Context entity might
 also be held by this DSA; it is not necessarily on a remote DSA.

 A subordinate reference enables a DSA to redirect requests for
 information that it does not hold. It also marks the point
 at which one naming context ends, and another begins.

9.1  –  Characteristics

 Each Subordinate Reference entity has two characteristic attributes:

 -	Access Point
 -	Copy Access Point

 You can use the ADD, SET, SHOW and REMOVE directives on both these
 attributes.

 Syntax:

 ADD    DSA SUBORDINATE REFERENCE <name> <attr> {<value>,...}
 REMOVE DSA SUBORDINATE REFERENCE <name> <attr> {<value>,...}
 SET    DSA SUBORDINATE REFERENCE <name> <attr> {<value>,...}
 SHOW   DSA SUBORDINATE REFERENCE <name> <attr>

 where <attr> is the characteristic attribute name and
 <value> is the value.

 The Access Point attribute is single-valued.

 You can display the value of both attributes in one SHOW
 directive by separating the attributes with a comma. For example:

 SHOW DSA SUBORDINATE REFERENCE <name> <attribute1>, <attribute2>

 Similarly, you can achieve the same result by using the ALL
 CHARACTERISTICS qualifier with the SHOW directive. For example:

 SHOW DSA SUBORDINATE REFERENCE <name> ALL CHARACTERISTICS

9.1.1  –  Access Point

 This specifies the Access Point of the DSA which holds the master
 copy of a directory entry subordinate to the current entry. There
 is no default value.

 Syntax:

 ADD    DSA SUBORDINATE REFERENCE <name> ACCESS POINT {<value>,...}
 REMOVE DSA SUBORDINATE REFERENCE <name> ACCESS POINT {<value>,...}
 SET    DSA SUBORDINATE REFERENCE <name> ACCESS POINT {<value>,...}
 SHOW   DSA SUBORDINATE REFERENCE <name> ACCESS POINT

 where <value> is the access point of the DSA and is
 specified as follows:

    {[ae title = "<distinguished name of DSA>",
      presentation address = '<presentation address>']}

 The AE Title and Presentation Address attributes are both mandatory.
 Note that you must specify the AE Title and Presentation
 Address in the order shown above.

 Specify all valid NSAPs for a DSA in an access point. This
 improves the network efficiency of the DSA, ensuring that if
 a connection to the relevant DSA already exists, it is always
 re-used.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

9.1.2  –  Copy Access Point

 This specifies the DSA which holds a copy of a directory
 entry subordinate to the current entry. There is no default
 value.

 Syntax:

 ADD DSA SUBORDINATE REFERENCE <name> COPY ACCESS POINT {<value>,...}

 REMOVE DSA SUBORDINATE REFERENCE <name> COPY ACCESS POINT {<value>,...}

 SET DSA SUBORDINATE REFERENCE <name> COPY ACCESS POINT {<value>,...}

 SHOW DSA SUBORDINATE REFERENCE <name> COPY ACCESS POINT

 where <value> is the access point of a DSA to which the
 Subordinate Reference refers, and is specified as follows:

    [ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']

 The AE Title and the presentation address are both mandatory.
 Note that the order of the AE Title and presentation
 address must be the same as that shown above.

 Specify all valid NSAPs for a DSA in an access point. This
 improves the network efficiency of the DSA, ensuring that if
 a connection to the relevant DSA already exists, it is always
 re-used.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

9.2  –  Directives

 You can use the ADD, CREATE, DELETE, REMOVE, SET and SHOW
 directives with the Subordinate Reference entity.

 The CREATE and DELETE directives are used to create and delete a
 Subordinate Reference entity.

 The SET and SHOW directives are used to set or show Subordinate
 Reference characteristic attributes, respectively.

 The ADD and REMOVE directives are used to add or remove
 values to or from a characteristic attribute.

9.2.1  –  ADD

 Use the ADD directive to add value(s) to a characteristic
 attribute of the Subordinate Reference entity.

 You can use the ADD directive on all characteristic attributes of
 the Subordinate Reference entity.

 Syntax:

 ADD DSA SUBORDINATE REFERENCE <attr> {<value>,...}

 where <attr> is the name of the Characteristic
 attribute and <value> is the value you want to add to
 the attribute.

9.2.2  –  CREATE

 Use this directive to create a Subordinate Reference entity
 of the specified name.

 Syntax:

    CREATE DSA SUBORDINATE REFERENCE <name> <argument> <value>

9.2.2.1  –  Arguments

 The CREATE directive has an identifier and two arguments:

 -	ACCESS POINT
 -	COPY ACCESS POINT

 The identifier specifies the name of this
 Subordinate Reference entity.  This is in the form of a
 distinguished name.

 The ACCESS POINT argument identifies the DSA holding the master copy
 of the naming context for which this entity provides a reference.
 The attribute is single-valued. Specify the ACCESS POINT argument
 in the following format:

 	ACCESS POINT <access point>

 where <access point> is the access point of the DSA and is
 specified as follows:

    {[ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']}

 The AE Title and Presentation Address attributes are both mandatory.
 Note that you must specify the AE Title and Presentation
 Address in the order shown above.

 Specify all valid NSAPs for a DSA in an access point. This
 improves the network efficiency of the DSA, ensuring that if
 a connection to the relevant DSA already exists, it is always
 re-used.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

 The COPY ACCESS POINT is optional and specifies one or more DSAs
 that hold a copy of the naming context to which this entity
 provides a reference. Specify the COPY ACCESS POINT argument
 in the following format:

 	COPY ACCESS POINT <access point>

 where <access point> is the access point of the DSA and is
 specified as shown in the preceding description of the
 ACCESS POINT argument.

9.2.2.2  –  Errors

 The CREATE directive returns one of the following errors:

 REASON:         Already Exists
 DESCRIPTION:    This Subordinate Reference entity already exists.

 REASON:         Invalid Name
 DESCRIPTION:    The entity name is not a valid directory name.

                 The name of the entity must be in the form of a
                 distinguished name. The response shows the
                 invalid name.

 REASON:         Not Master
 DESCRIPTION:    Cannot create a Subordinate Reference in a
                 shadow Naming Context.

                 You cannot create a Subordinate Reference entity
                 within a shadow Naming Context. You must
                 create a Subordinate Reference entity on the DSA
                 that is listed as being the master DSA for the
                 naming context that should contain this	reference,
                 and then replicate the new reference to all
                 shadow DSAs for that naming context. The response
                 identifies the master DSA for the naming context.

 REASON:         Entry Already Exists
 DESCRIPTION:    The DSA already holds an entry with the specified
                 name.

                 If an entry already exists with the name that
                 you specify, then it would be inappropriate to
                 create a Subordinate Reference entity of the same
                 name. The Subordinate Reference entity marks the
                 termination of a naming context, but the existence
                 of an entry already in that place indicates
                 that some naming context extends beyond the
                 proposed termination point.

 REASON:         Alias Entry Already Exists
 DESCRIPTION:    The DSA already holds an alias entry with the
                 specified name.

                 An alias entry already exists with the same
                 name. An alias entry cannot have subordinate
                 entries, so it is inappropriate to create a
                 reference downwards from this position in the DIT.

 REASON:         Naming Context Already Exists
 DESCRIPTION:    The DSA already holds a Naming Context entity
                 with the specified name.

                 A Naming Context entity already exists at this
                 position in the DIT.  A Subordinate Reference
                 entity cannot be created if a Naming Context
                 entity already exists at that location. If a
                 Subordinate Reference entity is really required
                 at this position, to terminate some higher
                 naming context, then it must be created before the
                 creation of the Naming Context entity with which
                 it might then coexist. To reduce the chances of
                 invalid configurations, the DSA requires you to
                 create entities in a logical order, marking the
                 termination of one context before allowing the
                 creation of another.

 REASON:         Has Subordinates
 DESCRIPTION:    The DSA already holds entries or entities
                 subordinate to the entity being created.

                 Subordinate entries exist below the proposed
                 location of the Subordinate Reference entity.
                 To create a Subordinate Reference entity in
                 the proposed position would leave these entries
                 beyond the termination point of whichever naming
                 context they are part of.

 REASON:         Below Subordinate Reference
 DESCRIPTION:    The directly superior entity is another Subordinate
                 Reference.

                 There is already a Subordinate Reference entity
                 higher up the DIT. You cannot create consecutive
                 Subordinate Reference entities.

 REASON:         DIT Root
 DESCRIPTION:    Cannot create a Subordinate Reference at the root of
                 the DIT.

                 You cannot create a Subordinate Reference entity
                 directly on the root entry of a DIT (/).  A
                 Subordinate Reference entity must have a
                 distinguished name that contains at least one
                 relative distinguished name.

 REASON:         Alias entry
 DESCRIPTION:    Alias entry prevents creation.

                 The identifier you specified for the Subordinate
                 Reference entity is an alias name, not a
                 distinguished name. The DSA does not support the
                 use of alias names when creating entities. Specify
                 the distinguished name of the entry at the top
                 of the naming context to which this entity
                 provides a reference. The response shows the name
                 of the alias entry.

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

                 The DSA must be in state ON, ENABLING, DISABLING
                 or OFF when you create a Subordinate Reference
                 entity. The response shows the current state of
                 the DSA.

9.2.3  –  DELETE

 Use this directive to delete a Subordinate Reference entity.

 Syntax:

 	DELETE DSA SUBORDINATE REFERENCE <name>

9.2.3.1  –  Errors

 The Delete directive returns one of the following errors:

 REASON:         Also a Naming Context
 DESCRIPTION:    The Naming Context entity of the same name
                 must be deleted first.

                 You cannot delete the Subordinate Reference
                 entity because it coexists with a Naming
                 Context entity. To delete the Subordinate
                 Reference entity first would leave the DIT
                 improperly structured.

 REASON:         Also a Shadow Naming Context
 DESCRIPTION:    The shadow Naming Context with the same name
                 must be removed first.

                 You cannot delete the Subordinate Reference
                 entity because it coexists with a shadow
                 Naming Context entity. You need to reconfigure
                 the supplier DSA for the shadow naming context
                 so that this DSA is no longer a consumer DSA for it.
                 Then initiate replication so that this DSA removes
                 its copy of the naming context. You can then remove
                 the Subordinate Reference entity. The response
                 identifies the name of the shadow naming context
                 and its master DSA.

 REASON:         Not Master
 DESCRIPTION:    Cannot delete a shadow Subordinate Reference.

                 The Subordinate Reference entity is a shadow
                 copy that has been created by replication.
                 The DSA does not own the entity and cannot
                 therefore delete it. You need to reconfigure
                 the supplier DSA so that this DSA is no longer
                 a consumer DSA for the specified naming context.
                 Then initiate replication so that this DSA removes
                 its copy of the Naming Context, including
                 the Subordinate Reference entity. The response
                 identifies the name of the shadow naming context
                 and its master DSA.

 REASON:         Has Subordinates
 DESCRIPTION:    The DSA holds entries or entities
                 subordinate to the entity being deleted.

                 The Subordinate Reference entity has
                 subordinates and therefore cannot be deleted.
                 You need to delete all subordinate entries
                 and entities first.

 REASON:         Alias Entry
 DESCRIPTION:    Alias entry prevents deletion.

                 The identifier you specified for the Subordinate
                 Reference entity is an alias name, not a
                 distinguished name. The DSA does not support the
                 use of alias names when deleting entities. The
                 response shows the name of the alias entry.

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

                 The DSA entity must be in state ON, ENABLING,
                 DISABLING or OFF when you delete a
                 Subordinate Reference entity.

9.2.4  –  Examples

  >  CREATE DSA SUBORDINATE REFERENCE "/C=US/O=Abacus/OU=Sales" -
  _>   ACCESS POINT {[AE Title="/C=US/O=Abacus/CN=DSA4", -
  _>     Pres Addr='"DSA"/"DSA"/"DSA"/NS+49002aaa000400083221']} -
  _>   COPY ACCESS POINT {[AE Title="/C=US/O=Abacus/CN=DSA6", -
  _>     Pres Addr='"DSA"/"DSA"/"DSA"/NS+49002aaa000400081222']}

  > SHOW DSA SUBORDINATE REFERENCE "/C=US/O=Abacus/OU=Sales" -
  _>   ALL ATTRIBUTES

 	The first command creates a Subordinate Reference entity
    	and defines the access points of the master DSA and a
 	shadow DSA of the subordinate naming context to which
 	this entity provides a reference. The second command
 	displays the Subordinate Reference entity.

  > DELETE DSA SUBORDINATE REFERENCE "/C=US/O=Abacus/OU=Sales"

 	This command deletes the Subordinate Reference entity
         with the identifier "/C=US/O=Abacus/OU=Sales".

9.2.5  –  REMOVE

 Use the REMOVE directive to remove value(s) from a
 characteristic attribute.

 You can use the REMOVE directive on all Subordinate
 Reference characteristic attributes.

 Syntax:

 REMOVE DSA SUBORDINATE REFERENCE <name> <attr> {<value>,...}

 where <name> is the identifier of a Subordinate Reference entity,
 <attr> is the name of the characteristic attribute and <value> is
 the value you want to remove from the attribute.

9.2.6  –  SET

 Use the SET directive to change the value of a Subordinate
 Reference characteristic attribute.

 You can use the SET directive on all characteristic attributes
 of the Subordinate Reference entity.

 Syntax:

 SET DSA SUBORDINATE REFERENCE <name> <attr> {<value>,...}

 where <name> is the name of the Subordinate Reference entity,
 <attr> is the name of the Characteristic attribute and
 <value> is the value you want to set for the attribute.

9.2.7  –  SHOW

 Use the SHOW directive to display the characteristic attributes
 of a Subordinate Reference entity.

 You can use the SHOW directive on all Characteristic attributes
 of the Subordinate Reference entity.

 Syntax:

 SHOW DSA SUBORDINATE REFERENCE <name> <attr>

 where <attr> is the name of the Characteristic attribute
 you want to display.

 You can display the values of multiple attributes using
 one SHOW directive by separating the attributes with a comma,
 for example:

 SHOW DSA SUBORDINATE REFERENCE <name> <attr1>, <attr2>

 You can also use the wildcard "*" in a SHOW directive,
 to show details of all subordinate references; for example:

 SHOW DSA SUBORDINATE REFERENCE * <attr>

9.3  –  Identifier

 The identifier of a Subordinate Reference entity is the
 distinguished name of the entry to which the entity provides a
 reference, for example, "/C=US/O=Abacus/OU=Accounts".

 The identifier of a Subordinate Reference entity is the
 same as the identifier of a Naming Context entity held by some
 other DSA.  Thus the entity provides a reference to the remote
 naming context. It is possible for the Subordinate Reference
 entity to be on the same DSA as the Naming Context entity to
 which it provides a reference.

 Refer to DSA Common_Datatypes for more information on
 how to specify a distinguished name.  Refer to the CREATE
 directive for more information on how to create a Subordinate
 Reference entity.

10  –  Superior Reference

 A Superior Reference entity provides a reference to a DSA that
 holds a naming context that is higher in the DIT than all of
 the naming contexts held locally.

 The DSA that holds superior information should have further
 knowledge information that enables the user request to be
 redirected to the relevant DSA. Such a DSA might have
 knowledge about parts of the DIT that this DSA does not know
 about.

10.1  –  Characteristics

 A Superior Reference entity has one characteristic attribute:
 Access Point.

 You can use the ADD, SET, SHOW and REMOVE directives on this
 attribute.

 Syntax:

 ADD DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 REMOVE DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 SET DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 SHOW DSA SUPERIOR REFERENCE ACCESS POINT

 where <value> is the value. The Access Point attribute is
 single-valued.

10.1.1  –  Access Point

 This specifies the Access Point of the DSA which holds
 a naming context which is superior to all of the naming
 contexts held within this DSA. There is no default value.
 The attribute is single-valued.

 Syntax:

 ADD    DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 REMOVE DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 SET    DSA SUPERIOR REFERENCE ACCESS POINT {<value>}
 SHOW   DSA SUPERIOR REFERENCE ACCESS POINT

 where <value> is the access point of a DSA that holds a master
 copy of a naming context that is higher than all naming contexts
 on this DSA, and is specified as follows:

    [ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']

 The AE Title and Presentation Address attributes are both
 mandatory. Note that you must specify the AE Title and
 Presentation Address in the order shown above.

 Specify all valid NSAPs for the DSA in the access point. This
 improves the network efficiency of the DSA, ensuring that if
 a connection to the relevant DSA already exists, it is always
 re-used.

 Refer to DSA Common_Datatypes for more information
 on how to specify an AE Title and a Presentation Address.

10.2  –  Directives

 You can use the CREATE, DELETE, SET and SHOW directives
 with the Superior Reference entity.

 The CREATE and DELETE directives are used to create and delete a
 Superior Reference entity.

 The SET and SHOW directives are used to set or display the Superior
 Reference characteristic attribute, respectively.

 Note that the only characteristic attribute of the Superior Reference
 entity is single valued. The ADD and REMOVE directives can therefore
 only be used to remove the single value, or to add a value if there is
 no existing value.

10.2.1  –  ADD

 Use the ADD directive to add value to the
 Access Point attribute if it does not already have one.

 Syntax:

 ADD DSA SUPERIOR REFERENCE <attr> {<value>}

 where <attr> is the name of the Characteristic
 attribute and <value> is the value you want to add to
 the attribute. Note that the Access Point attribute
 is single-valued, so you can only use the ADD directive
 if the Access Point currently has no value.

10.2.2  –  CREATE

 Use this directive to create a Superior Reference entity.

 Syntax:

 	CREATE DSA SUPERIOR REFERENCE <argument> <value>

10.2.2.1  –  Arguments

 The CREATE directive has one argument: ACCESS POINT. This argument
 is optional, although a Superior Reference entity without an
 Access Point attribute serves no purpose. You can specify the
 Access Point attribute using the SET directive instead.

 The ACCESS POINT argument identifies a DSA holding a naming context
 which is superior to all the naming contexts contained within this
 DSA. Specify the ACCESS POINT argument in the following format:

 	ACCESS POINT  <access point>

 where <access point> is the access point of the DSA and is
 specified as follows:

    {[ae title  = "<distinguished name of DSA>",
      presentation address = '<presentation address>']}

 The AE Title and Presentation Address attributes are both mandatory.
 Note that you must specify the AE Title and Presentation
 Address in the order shown above.

 Specify all valid NSAPs for the DSA in the access point. This
 improves the network efficiency of the DSA, ensuring that if
 a connection to the relevant DSA already exists, it is always
 re-used.

 Refer to DSA Common_Datatypes for more information on
 how to specify an AE Title and a Presentation Address.

10.2.2.2  –  Errors

 The CREATE directive returns one of the following errors:

 REASON:         Already Exists
 DESCRIPTION:    The Superior Reference entity already exists.

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 The DSA entity must be in state ON, ENABLING, DISABLING
 or OFF when you create a Superior Reference entity.
 Any other state causes a failure. The response indicates the
 current state of the DSA.

10.2.3  –  DELETE

 Use this directive to delete the Superior Reference entity.

 Syntax:

 	DELETE DSA SUPERIOR REFERENCE

10.2.3.1  –  Errors

 The Delete directive returns one error only:

 REASON:         Wrong State
 DESCRIPTION:    The DSA entity is not in the correct state.

 The DSA entity must be in state ON, ENABLING, DISABLING or
 OFF when you delete a Superior Reference entity. Any other
 state causes a failure. The response indicates the current
 state of the DSA.

10.2.4  –  Examples

  >  CREATE DSA SUPERIOR REFERENCE  -
  _>  ACCESS POINT {[AE Title="/C=US/O=Abacus/CN=DSA5", -
  _>   Pres Addr='"DSA"/"DSA"/"DSA"/NS+49002aaa000400888888']}

  > SHOW DSA SUPERIOR REFERENCE ALL ATTRIBUTES

 The first command creates a Superior Reference entity and
 defines the access point of the DSA which holds a naming
 context superior to all naming contexts contained within
 this DSA. Note that the command specifies no identifier
 for the Superior Reference entity.

 The second command displays the Superior Reference entity.

  > DELETE DSA SUPERIOR REFERENCE

 This command deletes the Superior Reference entity.

10.2.5  –  REMOVE

 Use the REMOVE directive to remove a value from
 the Access Point attribute.

 Syntax:

 REMOVE DSA SUPERIOR REFERENCE <attr> {<value>}

 where <attr> is the name of the Characteristic
 attribute and <value> is the value of the attribute.
 Note that the Access Point attribute is single-valued,
 so there is only ever one value for you to remove.

10.2.6  –  SET

 Use the SET directive to change the value of the Superior
 Reference characteristic attribute.

 Syntax:

 SET DSA SUPERIOR REFERENCE ACCESS POINT  {<value>}

 where <value> is the value you want to set for the attribute.

10.2.7  –  SHOW

 Use the SHOW directive to display the characteristic attribute
 of a Superior Reference entity.

 Syntax:

 SHOW DSA SUPERIOR REFERENCE ACCESS POINT
Close Help