This is the Enterprise Directory help module. It contains help for the DSA entity. A Directory System Agent (DSA) is a component of HP's Enterprise Directory product. It is responsible for holding directory information and satisfying user requests for directory information. The DSA entity represents the X.500 DSA on a given system, and enables you to manage that DSA. You use the entity to turn the DSA on and off, to enable it to receive and make connections to and from other X.500 components. You also use the entity to configure the DSA to perform its intended role as part of your Enterprise Directory.
1 – 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.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.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.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.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.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.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.1.2.2 – DELETE
Use this directive to delete an Accessor entity. Syntax: DELETE DSA ACCESSOR <name>
1.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.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.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.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.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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
1.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.
1.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
1.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.
1.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"
1.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.
1.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>
1.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.
1.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.
1.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>
1.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
1.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
1.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
1.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.
1.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>"
1.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.
1.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
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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
1.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
1.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
1.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.
1.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.
1.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.
1.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.
1.3.39 – Version
The Version attribute displays the version number of the DSA. The value is read-only. Syntax: SHOW DSA VERSION
1.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.
1.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.
1.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.
1.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
1.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
1.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
1.4.3 – Accounting Disabled
This counter displays the number of Accounting Disabled events generated by the DSA. Syntax: SHOW DSA ACCOUNTING DISABLED
1.4.4 – Accounting Enabled
This counter displays the number of Accounting Enabled events generated by the DSA. Syntax: SHOW DSA ACCOUNTING ENABLED
1.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
1.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
1.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
1.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
1.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
1.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
1.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.
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.4.26 – Communication Failures
This counter displays the number of communication failures since the DSA was created. Syntax: SHOW DSA COMMUNICATION FAILURES
1.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
1.4.28 – Creation Time
This counter displays the time and date at which the DSA was created. Syntax: SHOW DSA CREATION TIME
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.4.36 – LDAP Binds Accepted
This counter displays the number of LDAP Binds that the DSA has accepted. Syntax: SHOW DSA LDAP BINDS ACCEPTED
1.4.37 – LDAP Binds Rejected
This counter displays the number of LDAP Binds that the DSA has rejected. Syntax: SHOW DSA LDAP BINDS REJECTED
1.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.
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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
1.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.
1.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
1.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.
1.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.
1.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.
1.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.
1.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
1.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.
1.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.
1.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.
1.6 – Events
When an event occurs, the DSA sends a description of the event to the event sink. The events are described below.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
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
1.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.
1.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.
1.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.
1.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
1.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.
1.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
1.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.
1.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
1.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.
1.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.
1.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.
1.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.
1.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.
1.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>
1.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.
1.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.
1.7.2.3 – DELETE
Use this directive to delete a Naming Context entity. Syntax: DELETE DSA NAMING CONTEXT <name>
1.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.
1.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.
1.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.
1.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.
1.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>
1.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.
1.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
1.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.
1.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.
1.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.
1.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
1.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.
1.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.
1.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
1.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
1.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
1.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.
1.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
1.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.
1.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.
1.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.
1.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.
1.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>
1.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.
1.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.
1.9.2.3 – DELETE
Use this directive to delete a Subordinate Reference entity. Syntax: DELETE DSA SUBORDINATE REFERENCE <name>
1.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.
1.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".
1.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.
1.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.
1.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>
1.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.
1.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.
1.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.
1.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.
1.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.
1.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.
1.10.2.2 – CREATE
Use this directive to create a Superior Reference entity. Syntax: CREATE DSA SUPERIOR REFERENCE <argument> <value>
1.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.
1.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.
1.10.2.3 – DELETE
Use this directive to delete the Superior Reference entity. Syntax: DELETE DSA SUPERIOR REFERENCE
1.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.
1.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.
1.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.
1.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.
1.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