The NCL director can be used to manage entities on remote systems. This remote management requires the use of DECnet-Plus. If you want to manage a DSA remotely, but your local system does not run DECnet-Plus, you may need to use the following command to make the NCL utility use the TCP/IP protocol instead:

ncl> SET NCL TRANSPORT TCPIP 

To enable OSAK tracing, edit the DSA startup file, DXD$DIRECTORY:DXD$DSA_STARTUP_INPUT.COM, and remove the comment marker (!) from the following two lines:

$ ! define/process osak_trace on 
$ ! define/process osak_trace_file dxd $directory:osak_trace.bin 

Then, rerun the startup file and create and enable the DSA entity.

This enables the OSAK trace. OSAK will now trace all incoming connections and outgoing connections on this node.

To disable OSAK tracing, edit the DXD$DIRECTORY:DXD$DSA_STARTUP_INPUT.COM file, and comment out the two lines that apply to OSAK trace. Then rerun the startup file, and create and enable the DSA entity.

This error only occurs during upgrade installations or reinstallations. It indicates that Enterprise Directory logical names have been found, but that they do not refer to accessible directory specifications.

There can be two errors: one for the Enterprise Directory work directory, and another for the accounting directory.

The installation proceeds, and eventually prompts you for the device that the Enterprise Directory work directory should be created on. The installation creates the work directory on that disk. It also amends SYS$STARTUP:DXD$LOGICALS_STARTUP.COM to make sure that the logical name DXD$DIRECTORY is defined during Directory Service startup. If the accounting directory could not be found, then a new accounting directory is created as a subdirectory of the work directory.

If the installation cannot find the directories because the relevant disk(s) are temporarily unavailable, terminate the installation, and do not run the installation until the disk(s) are available.

The name subset requires that op_sys_version be installed on this system

where name is the name of a subset, and op_sys_version identifies the prerequisite version of the operating system.

The subset cannot be installed because the system is running the wrong version of the operating system. Install the correct prerequisites before attempting to install the Enterprise Directory.

The name subset requires that subset be installed on this system

where name is an Enterprise Directory subset and subset is the prerequisite subset. Install that subset before attempting to install the Enterprise Directory.

Enterprise Directory Base :- DECnet-Plus NCL Dictionary could not be updated - missing DECnet-Plus files

Reinstall DECnet-Plus before attempting to install the Enterprise Directory.

Enterprise Directory Base :- DECnet-Plus help could not be updated - missing DECnet-Plus files

Reinstall DECnet-Plus before attempting to install the Enterprise Directory.

Enterprise Directory Server :- Failed to rename MAILbus 400 MTA snapshot file

Enterprise Directory Server :- Failed to rename MAILbus 400 MTA update file

Enterprise Directory Server :- Failed to rename MAILbus 400 MTA schema file

Enterprise Directory Server :- Failed to rename MAILbus 400 MTA snapid file

The installation has detected the presence of a MAILbus 400 MTA Version 1.0 database, and has failed to rename the file. These errors can only be returned if you have not performed the mandatory upgrade of Version 1.0 of the MAILbus 400 MTA, which was only available on ULTRIX and OpenVMS systems. Refer to the MAILbus 400 MTA documentation for details of the mandatory update tasks.

Enterprise Directory Server :- No valid database found or error occurred - cannot continue

The installation has detected that existing database files are corrupt, and therefore the installation terminates. Delete or move the existing X.500 database files before installing the Enterprise Directory.

Enterprise Directory Server :- file could not be updated - missing DECnet file. This is a fatal error

where file is the name of the CML configuration file. The installation attempts to edit this file so it is possible to use NCL to manage the DSA. If this attempt fails, the installation terminates.

Reinstall DECnet-Plus before attempting to install the Enterprise Directory.

Upgrade your operating system version to that indicated by the installation procedure and rerun the installation.

DECnet software is not installed or you do not have the correct version of DECnet software needed to install the Enterprise Directory product. Upgrade your version of DECnet software to that indicated by the installation procedure and rerun the installation.

You do not have the correct version of OSAK software needed to install the Enterprise Directory product. OSAK software is a component of DECnet software. Upgrade your version of OSAK software to that indicated by the installation procedure and rerun the installation.

If you intend to use the DXIM Motif interface, you must install DECwindows Motif.

Install the version of DECwindows Motif indicated by the installation procedure.

The Enterprise Directory cannot be installed on a node if a DSA is already running on that node. Stop the DSA and rerun the installation procedure.

Stop the DSA by entering the following command:

$ @SYS$STARTUP:DXD$COMMON_SHUTDOWN

There is not enough free disk space available to continue with the installation. Make more space available and rerun the installation procedure or use an alternate working device.

Refer to the setld or VMSINSTAL documentation for more advice about installing software products.

There are insufficient global pages (GBLPAGES) available to install the Enterprise Directory software.

Increase the number of global pages available by the amount indicated by the installation procedure, reboot your system and then rerun the installation. Refer to the OpenVMS system management documentation for information on how to modify the global pages system parameter.

There are insufficient global sections (GBLSECTIONS) available to install the Enterprise Directory product.

Increase the number of global sections available by the amount indicated by the installation procedure, reboot your system and then rerun the installation. Refer to the OpenVMS system management documentation for information on how to modify the global sections system parameter.

The DXD$SERVER account does not exist. This account is needed by the DSA server process.

The installation procedure creates a new DXD$SERVER account and the installation proceeds. No action is necessary.

The Enterprise Directory subsets must be installed in the correct order. The Enterprise Directory Base subset must be installed first. All other subsets are dependent on the Base subset.

When you delete the subsets, the reverse order applies. The Base subset must be deleted last. If you try to delete this subset while other subsets are still installed, you are asked to confirm your actions. If you continue to delete the Enterprise Directory Base subset, the remaining subsets may not operate correctly.

Check that you have the correct license installed by typing the following command:

root> lmf list

Refer to the Software Product Description for more information about licenses.

To install the Enterprise Directory product, you require privileges.

Ensure that the VMSINSTAL utility from a suitably privileged account such as the SYSTEM account

The installation verification procedure (IVP) checks that the files required for the Enterprise Directory components you have installed are present in the correct location and have the correct protection. If the IVP cannot find a file, or finds that the file protection is not correct, it displays a message indicating the problem. It also displays a message if it cannot find a component that has previously been installed.

You can run the IVP at any time, by typing the following command:

$ @SYS$TEST:DXD$IVP*.COM

Note that an IVP failure message indicates that an Enterprise Directory file has changed since installation. This does not necessarily mean that your Enterprise Directory will not work, but you are recommended to investigate any changes reported by the IVP.

Check that the configuration procedure, DXD$DSA_CONFIGURE.COM, is in the correct location and has the correct file protection. See Appendix A, Enterprise Directory Files for details of the correct location and protection.

You have insufficient privileges to run the configuration procedure.

Run the configuration procedure from an account that has the SYSPRV, OPER and BYPASS privileges.

If the DSA is in state ON, it cannot be configured. However, if it is in state ON, it must already have a valid configuration. If you really want to reconfigure the DSA's presentation address, disable the DSA before running the configuration procedure. The procedure will set the DSA's presentation address, but will not reset the DSA's AE Title. The procedure assumes that any existing AE Title is better than the temporary value it would set, and therefore does not change the existing value.

You are not logged in as superuser and so cannot run the configuration procedure.

Check that the DSA component is installed.

The DSA cannot be created or configured. Check DSA resources and configuration.

An error has occurred when configuring the Presentation Address.

Rerun the configuration procedure, or optionally run the appropriate NCL command for checking purposes.

An error has occurred when configuring the LDAP port.

Rerun the configuration procedure, or optionally run the appropriate NCL command for checking purposes.

An error has occurred when configuring the AE Title.

Rerun the configuration procedure, or optionally run the appropriate NCL command for checking purposes.

The DSA cannot be deleted.

Run the appropriate NCL command for checking purposes.

The DSA cannot be configured and a Presentation Address cannot be constructed.

Check the DSA selectors and NSAPs are correctly set.

Check that DECnet-Plus is configured for RFC1006.

This error only occurs if you try to specify a Presentation Address or AE Title for the DSA when the DSA is in state ON. Other attributes can be configured in state ON or state OFF.

The DSA can only be in state ON if it already has a valid Presentation Address and AE Title. If you really mean to reconfigure either of these attributes, use the DISABLE DSA command to set the DSA state to OFF. Then reconfigure the DSA Presentation Address or AE Title as required. Note that the Enterprise Directory provides a DSA configuration utility. Section 2.3.3, “Invalid Attribute Value in Presentation Address” explains how to run the utility. When you have reconfigured the DSA, use the ENABLE DSA command to set the DSA state to ON so that the DSA can receive user requests.

If you have changed the DSA's Presentation Address or AE Title, and other DSAs have knowledge references that specify this DSA, then you need to reconfigure those other DSAs so that their knowledge references reflect the change to this DSA's configuration details. If other DSAs have out of date knowledge references, the operation of your Enterprise Directory will be impaired.

The application entity title (AE Title) is badly formed. An AE Title must conform to the following rules:

For more information on AE Titles, refer to VSI Enterprise Directory Management or the NCL online help.

You have specified an incorrect presentation address. Use the DSA configuration utility to set the presentation address.

You need SYSPRV and OPER privileges to run the configuration utility. To run the utility, type:

$ @SYS$STARTUP:DXD$DSA_CONFIGURE 

If your privileges are insufficient, the utility displays an error message and exits.

This occurs because a CREATE DSA command is issued very quickly after a DELETE DSA command, or because the DSA server process has not been started.

Wait for a few seconds, and then repeat the CREATE DSA command. If this does not work, execute the DSA startup procedure as follows:

$ @SYS$STARTUP:DXD$DSA_STARTUP.COM 

Then issue a CREATE DSA command.

The DSA did not start because it could not read its DIB fragment from disk into memory.

This can be caused by the following problems:

For details of how to backup your database files, see Section 5.7, “You Want to Backup the Database While the DSA is Running”.

If you do not have a usable backup, you must delete the DSA database, and start again.

The DSA failed to read its DIB fragment from disk into memory. This is due to the DIB fragment being incompatible with the software version of the DSA.

This should not happen, because each version of the DSA provides backwards compatibility, and automatically makes any conversions required to its database.

If this error occurs, and you have a backup copy of the database files, restore the database files, and try to start the DSA again. If this still fails, report the problem to VSI.

This error returns one of four diagnostic statements:

where oid is an object identifier, such as { 2 5 4 60}, and n is an integer.

In all cases, the message means that the DIT contains examples of information that is not defined in the schema.

The two most likely explanations for these problems are that:

Old versions of the schema are saved in a subdirectory of DXD$DIRECTORY during every installation. If you have accide ntally deleted some definitions, or you have reinstalled the DSA, you should find that your customized files can be retrieved from that subdirectory.

Check that the Enterprise Directory logicals are correctly defined, and have only one definition. If the Enterprise Directory logicals have multiple definitions, the DSA can report this error when it fails to find the DSA information tree files. To ensure that the Enterprise Directory logicals are correctly defined, run the following startup procedure:

$ @SYS$STARTUP:DXD$COMMON_STARTUP.COM 

Check that the DXD$SCHEMA.DAT file is installed and in the directory defined by the logical name DXD$DIRECTORY and has the correct protection (see Appendix A, Enterprise Directory Files for details of the correct file protection).

If none of the above solves the problem, recompile the schema. If the schema is missing, reinstall the Enterprise Directory.

The schema version differ s from the DSA version. Each version of the DSA includes new schema files and a new schema compiler. If the DSA tries to read a schema that was compiled by an old version of the schema compiler, it can report this error. Recompile the schema and restart the DSA, as follows:

$ SET DEFAULT DXD$DIRECTORY 
$ RUN SYS$SYSTEM:DXD$SCHEMA_COMPILER.EXE

Either the NCL CREATE DSA or the ENABLE DSA directive has failed due to a lack of system resources.

If you are attempting to enable the DSA for the first time, then this error can be caused if you have not created the transport templates required by the Enterprise Directory.

Refer to the installation documentation for details of this mandatory post-installation task.

If the DSA is installed on an OpenVMS system, or the templates have been created, refer to Chapter 7, Problems With Resources for more information.

The unavailability of the DSA's LDAP port will generate this error. Check that another application is not using the TCP/IP port assigned to the DSA for LDAP. You can configure the DSA to use a different TCP/IP port for LDAP.

The DSA could not be enabled because it has not been assigned a valid application entity (AE) title.

Assign the DSA a valid AE title by using the NCL SET DSA directive. For more information on application entity titles, refer to VSI Enterprise Directory Management or the NCL online help.

The DSA could not be enabled because it has not been assigned a valid presentation address.

Use the DSA configuration utility to set a valid presentation address.

The DSA could not be created because a valid Enterprise Directory Server license has not been installed.

Check which licenses you have installed as follows:

root> lmf list 

Install the appropriate license and restart the DSA. Refer to the Software Product Description for more information about licenses.

A DSA could not be created because a DSA is already running on this system. Enable this DSA for communication using the NCL ENABLE directive.

A DSA could not open the database because the database is being used by another DSA on another node on the cluster. Only one DSA can access a

database at any one time. When the DSA loads the database, the database is locked to prevent another DSA accessing it.

To find the DSA in use, look in file DSA_informationtree.lock in the DXD$DIRECTORY directory.

A DSA is already being created.

Wait for the DSA to finish creating.

The DSA does not support the specified option. Upgrade to the latest version of the product.

Check that the configuration procedure, DXD$DUA_CONFIGURE.COM, is in the correct location and has the correct file protection. See Appendix A, Enterprise Directory Files for details of the correct location and protection.

You have insufficient privileges to run the configuration procedure.

Run the configuration procedure from an account that has the SYSPRV and OPER privileges.

The logical name DXD$DIRECTORY is not defined.

To define the logical name, run the DXD common startup file as follows:

$ @SYS$STARTUP:DXD$COMMON_STARTUP.COM 

Rerun the configuration procedure.

The DUA configuration procedure is unable to contact the DSA to obtain the default DUA configuration information. This is due to one of the following problems.

The DUA configuration procedure cannot write the DUA defaults file to disk. This may be because there is insufficient disk space, or because the directory protections are incorrectly set.

The DUA configuration procedure does not recognize the name of the node that you specified. Find out the correct name of the node where the DSA is installed. Rerun the DUA configuration procedure and specify the correct node name.

The DUA configuration procedure is unable to bind to the DSA using RFC1006. This could be due to one of the following problems:

You are not logged in as superuser and so cannot run the configuration procedure.

Configure RFC1006 after the configuration procedure has completed.

Install DECnet-Plus and RFC1006.

The DXIM default startup script file cannot be foun d or the DXIM DCL verb is not recognized by the operating system. Check that:

If the file specified in the error message is DXD$DXIM_CLI.EXE or DXD$DXIM_MOTIF.EXE, an executable image for the DXIM command line interface or the DXIM Motif interface has not been found. Check that these images are installed in the correct directories and have the correct file protection set. See Appendix A, Enterprise Directory Files for information about the file locations and protection.

If the file specified in the error message is DECW$XLIBSHR.EXE, check that the DECwindows Motif is installed correctly.

The schema binary file cannot be foun d or cannot be read.

Check that the logical name DXD$DIRECTORY is defined. If the logical name is not defined, run the DXD common startup file as follows:

$ @SYS$STARTUP:DXD$COMMON_STARTUP.COM 

Check that the DXD$SCHEMA.DAT file is installed and in the directory defined by the logical name DXD$DIRECTORY and has the correct protection. See Appendix A, Enterprise Directory Files for details of the correct file protection.

If the schema file is in the correct location and has the correct file protection, check that it is not corrupt. If necessary, recompile the schema source files and create a new binary file. Refer to VSI Enterprise Directory Management for more information on how to recompile the schema source files.

DXIM cannot read the schema binary file (DXD$SCHEMA.DAT) because it is in an invalid format. The software version of DXIM and the schema binary file do not match.

Recompile the schema source files and create a new binary file. Refer to VSI Enterprise Directory Management for more information on how to recompile the schema source files.

The DXIM Motif user interface definition (UID) DXD$DXIM.UID could not be opened. Check that the UID file is installed in the correct directory and has the correct file protection. See Appendix A, Enterprise Directory Files for details of the correct file location and protection.

This is due to DXIM being unable to bind to the DSA. Refer to Section 3.1, “Applications Cannot Bind to a DSA” for information on how to recover from bind problems.

If you start DXIM, but receive an Unable to Communicate with DSA error, you are not correctly bound to the DSA. See Section 3.1, “Applications Cannot Bind to a DSA”.

DXIM uses two DUA defaults files at startup. One, located in the /usr/etc directory or the directory defined by the system logical name DXD$DIRECTORY, is for system-wide definitions. The other, located in your home or SYS$LOGIN directory, allows you to customize DXIM to suit your own particular needs. The values specified in the DUA defaults file located in your home or SYS$LOGIN directory override the values specified in the system-wide DUA defaults file.

On startup, DXIM requires an initial entry that it can use as the browse base for the Browse window and the search base for the Find window. DXIM looks for the following, using the first entry it finds as the initial entry:

• DUA.InitialEntry in the users local defaults file
• DUA.InitialEntry in the system-wide defaults file
• DUA.DomainRoot in the users local defaults file
• DUA.DomainRoot in the system-wide defaults file

Refer to VSI Enterprise Directory Management for more information on the DUA defaults file.

If the initial entry has invalid syntax, it is still displayed, but an error message is also displayed.

Ensure that either the initial entry parameter or domain root parameter is set to point to a valid directory entry. If neither of these parameters is set, DXIM defaults to the root of the DIT ("/").

If you start DXIM and the browse or search base is not what you expected, check to ensure that you have correctly specified the entry in the DUA.InitialEntry or the DUA.DomainRoot parameter of the DUA defaults file in your home or SYS$LOGIN directory. If you do not have a copy of the

DUA defaults file in your home or SYS$LOGIN directory, or you have not set the parameters in that file, check that the values specified in the system-wide DUA defaults file are correct.

The DXIM command line interface can use an initialization file that contains DXIM comman ds that can be executed when the utility is invoked. The file is called .dximrc and must be in SYS$LOGIN:DXD$DXIM.INI. If DXIM cannot find this file, it simply assumes that there is no file to be foun d, and does not return an error message.

If your initialization file is not being run, check that it is in your home directory and has the correct file protection (see Appendix A, Enterprise Directory Files for details of file protection).

If you have problems running the Lookup Client configuration procedure, check the following:

If you have problems starting the Lookup Client, check the following:

The behaviour of the Lookup Client is defined by the defaults file, which provides a description of the settings available.

If you are running the Lookup Client Motif interface on a remote system, you need to make sure that the display is directed to your local system. If Lookup Client displays an error indicating that it cannot open the display, use the SET DISPLAY command.

The Lookup Client Motif interface uses the Bookreader utility to display its help. If you do not have Bookreader on your system, the help cannot be accessed. Refer to your system manager to get Bookreader installed.

The Lookup Client command line interface on OpenVMS systems reads a help library called SYS$HELP:DXDLU.HLB. If you have problems using the help, check the location and protection of this library (see Appendix A, Enterprise Directory Files for details of the correct protection).

Check that there is a DSA process running on the node to which you are trying to bind, and that the DSA is enabled for communication.

On the node where the DSA is installed, enter the following command to display the state of the DSA:

NCL> SHOW DSA STATE 

The DSA state must be ON.

If the DSA is OFF, use the ENABLE DSA directive.

If the ENABLE directive is successful, try to rebind to the DSA; otherwise, refer to Section 2.4, “Starting the DSA or DSA Not Running” for information on how to solve problems associated with enabling the DSA.

If you receive a No Such Entity exception, it indicates that the DSA is not running. Check this as follows:

Enter the command $ SHOW SYSTEM

If the DSA process is running, the DXD$DSA_SERVER process is listed. If the DSA process is not running, start it as follows:

$ @SYS$STARTUP:DXD$COMMON_STARTUP 

If your Bind command fails, it may be that the DUA is using an incorrect presentation address in the bind.

The following is a typical example of a DSA presentation address:

Presentation Address = '"DSA"/"DSA"/"DSA"/NS+49002aaa00040008aa21,CLNS'

Use the NCL SHOW DSA PRESENTATION ADDRESS comman d to check the address of the DSA that you want to connect to. Check that you are specifying that address correctly in your command line, or that it is specified correctly in the DUA.KnownDSAs.paddr parameter in the DUA defaults file.

See VSI Enterprise Directory Management for details of how to plan and set a DSA's presentation address.

OSI connections to or from a HP DSA depend on some OSI transport templates being defined on the DSA system and the DUA system. Note that RFC1006 connections do not require transport templates. If the DUA was attempting to connect using an RFC1006 address, there is no need to check the templates.

You can run the following procedure to make sure that the necessary templates are defined on the DSA and DUA systems.

NCL> DO SYS$STARTUP:DXD$TEMPLATE_STARTUP.NCL 

Note that the comman ds for creating the DXD_CONS templates are commented out of the startup file. If your system can use connection-oriented networking, edit the startup file to remove the comment characters from the commands that create and configure the DXD_CONS entity, and amend the commands to reflect the configuration of your connection-oriented system. The commands provided are typical examples, but might not match the configuration of your system. See your system manager for details of what values to set for the attributes of the DXD_CONS entity.

After running the procedure on both the DUA and DSA systems, retry the connection.

Check that the network address specified as part of the DUA's bind address (see Section 3.1.2, “Display DUA Presentation Address Used”), correctly identifies a valid network address of the node which holds the DSA. To do so, on the DSA node, display a list of valid NSAPs using the following NCL command:

NCL> SHOW OSI TRANSPORT LOCAL NSAP * ALL ATTRIBUTES

Ensure that the NSAP address part of the address that the DUA is trying to connect to is one of those displayed by this command.

If the NSAP address being used by the DUA does not match any of the DSA's local NSAPs, amend the NSAP address specified as part of the DUA's presentation address. Do this as follows:

Check the upper layer selectors in the address that DUA is attempting to connect to, as follows:

If the values do not match, repeat the DXIM command with the correct address, or run the DUA configuration procedure to create a new DUA defaults file.

It might be that the DSA is not receiving the Bind request. This can be checked by monitoring the DSA counters.

Check this as follows:

If either counter has increased, then the DUA is using a valid address for the DSA, but the DSA is not accepting the connection. See Section 3.1.8, “Check for Protocol, Resource and Security Events” for a list of DSA events to check. The events may indicate the reason why the Bind request was rejected.

If neither counter increased, then it indicates that the DSA is not receiving the Bind request at all and that there is a network problem. See the DECnet-Plus Problem Solving documentation for information on solving network problems.

If you have a network problem that is preventing connections to a DSA, you can use the network isolation tool to investigate the problem. Section 3.6, “Testing Network Connections” documents the network isolation tool.

If the DSA is rejecting your Bind request, as indicated by the DUA BINDS RE J ECTED counter increasing, then check for the following DSA events (see Section 1.3, “Events” for information on how to log events):

A Fatal Interface Error must be reported to VSI.

Chapter 7, Problems With Resources provides details of how to handle resource problems. Check the event log for other DSA events to see whether they provide additional information about the resource problem.

This should be a temporary problem. If the error happens frequently, check the event log to see whether any other events indicate why the network is unavailable. There should be some DECnet events that provide further information. This problem needs to be reported to your DECnet or network manager.

The presentation address of the DSA is already being used by some other application. Use the NCL SHOW DSA PRESENTATION ADDRESS comman d to check the presentation address, and to verify that you have specified it correctly.

If you find that the address you want to use really does belong to some other application, then you need to choose a different address for your DSA. In this case, you also need to amend any attributes of other DSAs that include this DSA's address. For example, other DSAs might have Subordinate Reference entities that refer to this DSA. If the address specified in those Subordinate References is incorrect, those DSAs will generate errors, and the Enterprise Directory will not work correctly.

This problem can be reported for several reasons, and it is difficult to determine which. Check the event log for other events that occurred shortly before or after the DSA reported this problem.

The DSA event that contains this problem should specify the network address that the DSA was attempting to connect to. Check that this address is correct. If not, you need to amend the address.

If the DSA was attempting a DISP operation or DOP operation, then a Consumer Access Point needs to be amended. The event should specify the name of the Naming Context that was being replicated. Amend the Consumer Access Point of that Naming Context to specify the correct address for the consumer DSA.

If the DSA was attempting to chain a user request, then you need to amend the knowledge reference that the DSA was using. This is usually a Subordinate Reference, but might be a Superior Reference. In order to determine which entity you need to amend, you need to know what entry the DSA was attempting to chain a request for. The user should provide this information.

If the event that contains the problem is a Listen Failure, then you need to check the Presentation Address and AE Title attributes of the DSA entity.

If the error is displayed when you use the UPDATE DSA command, then you need to check the presentation address you specified in the command. If you specified an AE title in the command, then you need to check the presentation address that is contained in the directory entry with the same name as the AE title you specified.

Although these configuration errors might explain an Invalid AEI problem, there are also many other explanations, such as OSAK problems. You need to work with your DECnet manager to determine the real cause of this problem.

Check your DECnet-Plus problem solving documentation for details of how to deal with problems in the transport layer. Check the event log to see whether other applications are also having transport problems.

Report this problem to VSI.

The Enterprise Directory requires some OSI transport templates.

On OpenVMS systems, these templates are defined during the Enterprise Directory startup. Shutdown the Enterprise Directory, and restart it to redefine the templates.

Report this problem to VSI.

Check the event log for other events that indicate communications problems for the local system. Refer to the DECnet-Plus problem solving documentation for details of how to handle ACSE user rejections.

When you invoke both the client and the server, you are asked a series of questions. If you require help about any of the questions asked by either the client or server, then type HELP or a question mark (?) at the prompt. If you type HELP, then the complete online help for the network isolation tool is displayed. If you enter a question mark (?), then only the help relevant to the question is displayed.

The commands to invoke the client and server have two optional qualifiers, -l and -h. Use the -l qualifier to write the output to a file, you also need to specify the name of the file for the output. If you do not specify the -l qualifier, then the output is displayed on your screen. Use the -h qualifier to display the online help for the network isolation tool. Note that you can use only one qualifier in the command.

By default, the server process exits after processing a client connection. However, you can set up the server process so that it remains active after a connection attempt. This means that you can repeatedly rerun the client and test other connections to the server. The client and server can test connections using only one transport service at a time, for example, DECnet-Plus. If you want to test a DECnet-Plus connection and then an RFC1006 connection, you must rerun the server in order to change transport services.

The following sections explain how to use the server (see Section 3.6.1.1, “Running the Server”) and the client (see Section 3.6.1.2, “Running the Client”).

$ RUN SYS$ TEST:DXD$NIT_SERVER.EXE 

$ NIT-SERVER := $SYS$TEST:DXD$NIT_SERVER.EXE 

$ NIT-SERVER [-h] [-l filename] 

Done.

$ RUN SYS$TEST:DXD$NIT_CLIENT.EXE 

Test output is being written to the log file...

Done.

VSI Enterprise Directory does not allow you to create a naming context directly at the root of a DSA (/). A naming context must have a distinguished name that contains at least one relative distinguished name.

Refer to VSI Enterprise Directory Management for more information on how to plan your naming contexts.

You cannot create a naming context at this position in the DIT because the name you have specified has subordinates. You must create naming contexts in a hierarchical order (top down). Refer to VSI Enterprise Directory Management for more information. You have a choice to solutions to this problem:

Of these, the first choice is the easiest to manage. However, if the new naming context must be created on a DSA that already holds subordinate information, you can proceed as described below.

If the existing subordinates are master copies of information, you need to delete them temporarily, create the new naming context, and then recreate the deleted subordinates, as follows:

If the subordinates are shadow copies, they can be more easily deleted while you create the new naming context, as follows:

If the existing subordinates are a mixture of master and shadow copies, then you need to apply a combination of the above tasks.

In all cases, take care not to create naming contexts that overlap with naming contexts held on other DSAs. It is important that all DSAs agree about where one naming context ends and another begins, otherwise distributed operations may not work as expected, and errors will occur. The creation of the required subordinate references is therefore essential to the maintenance of the distributed DIT. If possible, all naming contexts and subordinate references should be created in their hierarchical order, top down, so that you never need to undo parts of your configuration as described in this section.

A naming context already exists at this position in the DIT. You cannot create a naming context where one already exists. You can view this naming context by starting NCL and entering the following command:

NCL> SHOW DSA NAMING CONTEXT identifier ALL ATTRIBUTES 

where identifier is the distinguished name of the naming context you were trying to create, and must be enclosed in quotation marks.

The DSA refused to create the naming context because a superior master naming context has not been terminated. A naming context must be terminated by a Subordinate Reference entity before you can create another Naming Context entity beneath it.

Make sure that the naming context you tried to create is consistent with the plan of your Enterprise Directory. See VSI Enterprise Directory Management for information about planning naming contexts.

To create the proposed naming context, perform the following:

The DSA refused to create the naming context because a superior shadow naming context has not been terminated. A naming context must be terminated by a Subordinate Reference entity before you can create another Naming Context entity beneath it.

To create the proposed naming context, you must first terminate its superior shadow naming context.

To create the naming context, perform the following:

An entry already exists with the same name. You cannot create a naming context where a directory entry already exists.

If you wish to create the naming context, you must first delete the existing directory entry.

An alias entry already exists with the same name. You cannot create a naming context where an alias entry already exists.

If you wish to create the naming context, you must first delete the existing alias entry.

The name of the Naming Context entity you tried to create is incorrect.

Check this name. The name must be in the form of a distinguished name, for example, "/c=US/o=Abacu s/ou=Sales/ou=Accounts".

For more information, refer to VSI Enterprise Directory Management or the NCL online help.

The distinguished name of the naming context contains an alias and this is not allowed. The alias name may be a portion of the name, or the complete name. The name of the alias entry is returned.

To create the naming context, you must replace the distinguished name of the alias entry with the distinguished name of the entry the alias is pointing to (the target entry) and then reissue your command, using the new distinguished name. Do this as follows:

A subordinate reference already exists at this location in the DIT. Check this by starting NCL and entering the following command:

NCL> SHOW DSA SUBORDINATE REFERENCE name ALL ATTRIBUTES

where name is the distinguished name of the subordinate reference you tried to create. If the entity exists and has the correct attributes, no action is necessary.

A naming context already exists at this location in the DIT. A subordinate reference cannot be created if a naming context already exists at the location. A subordinate reference is used to terminate a naming context.

You cannot create a subordinate reference on a shadow entry or with a parent that is a shadow.

You must create the subordinate reference on the master DSA and then replicate that particular naming context. Do this as follows:

VSI Enterprise Directory does not allow you to create a subordinate reference directly on the root of a DSA (/). A subordinate reference must have a name that contains at least one relative distinguished name.

Refer to VSI Enterprise Directory Management for more information on how to plan subordinate references.

An entry already exists with the same name. Therefore, there is no need for a subordinate reference of this name.

An alias entry already exists with the same name. Therefore, there is no need for a subordinate reference of this name.

Subordinate entries exist below the proposed location of the subordinate reference. To create a subordinate reference in the proposed position would leave these entries beyond the termination point of the naming context.

To create the subordinate reference, you must first delete the subordinate entries.

A subordinate reference exists further up the DIT on the same naming path from the root, and is the closest hierarchical superior to the reference you are trying to create. The DSA does not allow subordinate references to be created in such a position.

The purpose of a subordinate reference is to mark the termination of a naming context. If the DSA detects that the closest hierarchically superior entity to the subordinate reference you are trying to create is another subordinate reference, then this error is displayed. The normal hierarchical superior to a subordinate reference is a naming context.

It is possible, though unusual, for a subordinate reference to be created with no hierarchically superior entity. You might choose to create such a subordinate reference to provide knowledge of a naming context that does not connect to any part of the DIT held by this DSA. This allows directory requests to access parts of the DIT that do not connect together structurally.

The distinguished name of the subordinate reference contains an alias, and this is not allowed. The alias entry is returned.

To create the subordinate reference, you must replace the distinguished name of the alias entry with the distinguished name of the entry the alias is pointing to (the target entry) and then reissue your command, using the new distinguished name. Do this as follows:

The name of the Subordinate Reference entity you tried to create is incorrect. Check this name. The name must be in the form of a distinguished name, for example, "/C=US/O=Abacu s/OU=Sales/CN=Accounts".

A distinguished name must conform to the following rules:

For more information on distinguished names, refer to VSI Enterprise Directory Management or the NCL online help.

The naming context does not exist. Check that you have supplied the correct distinguished name. You can display a list of naming contexts held by a DSA by starting NCL and entering the following command:

NCL> SHOW DSA NAMING CONTEXT *

If the naming context is not displayed, it means that the naming context is not held by this DSA.

You cannot remove a naming context if that naming context has subordinate entries or Subordinate Reference entities. Check that the naming context has subordinates as follows:

Start the DXIM command line interface and bind to the relevant DSA. Enter the following command:

dxim> SEARCH name NO CHAINING 

where name is the distinguished name of the naming context you tried to delete. If the entry has subordinate entries, these are displayed. If a Subordinate Reference entity exists, a referral is returned.

If you wish you to continue with the deletion, you must first delete all subordinate entries and any Subordinate Reference entities.

You can use the NCL DELETE command to delete a shadow naming context from a DSA but the preferred method is to remove the details of the consumer DSA from the Consumer Access Point attribute of the supplier DSA. This causes the supplier and consumer to terminate replication formally, and the consumer DSA deletes the shadow information automatically.

The naming context coexists with a directory entry. You cannot delete the naming context until you have deleted the directory entry.

Delete the directory entry and then reissue your command.

The naming context coexists with an alias entry. You cannot delete the naming context until you have deleted the alias entry.

Delete the alias entry and then reissue your command.

You have tried to delete a naming context using a distinguished name that contains an alias. The name of the alias entry is returned.

To delete the naming context, you must replace the distinguished name of the alias entry with the distinguished name of the entry the alias is pointing to (the target entry) and then reissue your command, using the new distinguished name. Do this as follows:

The subordinate reference does not exist. Check that you have supplied the correct distinguished name. You can display a list of subordinate references held by this DSA and their distinguished names by starting NCL and entering the following command:

NCL> SHOW DSA SUBORDINATE REFERENCE *

If the subordinate reference is not displayed, it means that it is not held by this DSA.

You cannot delete the subordinate reference because a naming context coexists with the subordinate reference. To delete the subordinate reference would leave the DIT improperly structured.

To delete the subordinate reference, you must first remove the naming context.

You cannot delete the subordinate reference because a shadow naming context coexists with the subordinate reference.

Before you can delete the subordinate reference, you must remove the shadow naming context. See Section 4.3.3, “Cannot Delete a Shadow Naming Context” for information about how to remove a shadow naming context.

The Subordinate Reference entity is a shadow copy that has been created through replication. The DSA does not own this Subordinate Reference entity and therefore cannot delete it.

To delete this Subordinate Reference entity, you must delete the Subordinate Reference entity on the master DSA and then retry the replication process. Do this as follows:

The Subordinate Reference entity has subordinates and therefore cannot be deleted. You must delete the subordinate entries or entities before you delete the Subordinate Reference entity.

You have tried to delete a subordinate reference using a distinguished name that contains an alias. The name of the alias entry is returned.

To delete the subordinate reference, you must replace the distinguished name of the alias entry with the distinguished name of the entry the alias is pointing to (the target entry) and then reissue your command, using the new distinguished name. Do this as follows:

If you use the UPDATE DSA directive when the DSA is not in state ON, the Wrong State error is displayed. Enable the DSA and repeat the UPDATE DSA directive.

If replication does not seem to be working, but there are no error events indicating that replication has failed, then it is possible that the supplier DSA is configured incorrectly. In this case, replication can complete without error, but without replicating any information, or only a subset of the information you expect, and the DSA can generate the Shadow Update Complete event.

If you find that all or some of the information you expected to consume is not present on the consumer DSA, then you need to check that the Consumer Access Point attribute has been correctly configured on the relevant Naming Context entity on the supplier DSA.

The supplier DSA only provides naming contexts that list the consumer DSA's access point in the Consumer Access Point attribute. VSI Enterprise Directory Management describes how to implement replication. When you have configured the supplier correctly, replication should succeed at the next attempt.

The UPDATE DSA directive requires you to specify either the presentation address of the supplier DSA, or its AE title. If you specify the AE title, you must use the correct syntax. You can check the AE Title of the supplier DSA by starting NCL and entering the following command:

NCL> SHOW NODE node-name DSA AE TITLE 

where node-name is the name of the node containing the supplier DSA. Specify the AE title exactly as displayed by this NCL command.

The UPDATE DSA directive requires you to specify either the presentation address of the supplier DSA, or its AE title. If you specify the AE title, the DSA attempts to look up the directory entry of that name, to determine the presentation address. If there is no entry with the same name as the specified AE title, or if the entry is inaccessible, then the UPDATE DSA command fails. In this case, the Cannot Read Supplier Address message is displayed.

To solve this problem, you can either specify a presentation address instead, or make sure that the entry of the relevant name exists, and is accessible to this DSA. VSI recommend that all DSAs are represented by decDSA entries with the same name as their AE titles, and that you use replication to ensure that copies of these entries are held by every DSA.

If a supplier DSA receives a replication request from another DSA, but that DSA has not specified a password, then the supplier DSA rejects the request because the Consumer cannot be authenticated. It is a security risk to accept replication requests from a DSA whose identity cannot be verified by means of authentication.

The only reason this can happen is if the consumer DSA does not have a Password characteristic attribute, and replication was initiated using the UPDATE DSA command. The consumer DSA will have generated a Shadow Update Failure with the Unexpected Failure reason. The consumer may also generate some Internal Error events in this case. The Internal Error events can be ignored.

Inform the manager of the consumer DSA that they must use the NCL SET DSA PASSWORD command. The password specified for the DSA must match the password in the decDSA entry that represents it. Alternatively, the supplier DSA can have an Accessor entity representing the consumer DSA, although this is not the preferred method. The supplier DSA can then verify the password by reference to the decDSA entry or the Accessor entity, such that the Consumer Not Authenticated message never recurs.

If the consumer DSA has a password, but it does not match the password in the decDSA entry or the Accessor entity, then the supplier DSA generates an Authentication Failure event rather than a Shadow Update Failure event.

Replication may fail due to the supplier DSA being unavailable. This could be due to any of the following:

The information provided by the supplier DSA is incompatible with the information at the consumer DSA. After this has occurred, the consumer DSA is automatically deleted to ensure that the consumer DSA's database is not corrupted by the attempted replication operation.

Replication between the two DSAs is not possible and should not be subsequently attempted until the incompatibility has been resolved.

The supplier DSA may provide incompatible information for one of the following reasons:

Refer to Section 7.3, “Replication Fails with No Resources Available”.

This message can appear in Shadow Update Failure events if replication fails between two DSAs. It means that the information received by the con sumer DSA clashes with the information it already holds.

This indicates that there is a fault in your Enterprise Directory configuration.

Use the SHOW DSA NAMING CONTEXT * and SHOW DSA SUBORDINATE REFERENCE * to see what information is already present on the consumer DSA. Check that none of the information that is to be replicated will clash with information already held. For example, if the replicated naming context is hierarchically subordinate to an existing naming context, check that the existing naming context is correctly terminated by a Subordinate Reference entity.

VSI Enterprise Directory Management describes the restrictions that apply to configuring naming contexts, and explains the need for Subordinate Reference entities to mark the end of a naming context as well as to provide a reference to the immediately subordinate naming context.

This message can appear in Shadow Update Failure events if replication fails between two DSAs. It means that the information received by the consumer DSA depends on schema definitions that are not defined in the consumer DSA's schema.

VSI recommends that all DSAs have the same schema. Find out what schema differences there are between the two DSAs, and make the necessary amendments to ensure that the two sets of schema are aligned. In particular, make sure that the consumer DSA has the schema that describes the entries in the naming context that you want it to consume. See VSI Enterprise Directory Management for full details of how to customize the schema.

Section 10.1.18, “Shadow Update Failure” provides a list of DISP errors that can occur during replication. Most of these errors are self correcting. However, if any DISP error occurs frequently, it may be that the DSAs cannot correct the problem automatically.

To resolve this problem, use the UPDATE DSA command on the consumer DSA, specifying its AE title. For example:

ncl> UPDATE DSA SUPPLIER "/C=US/O=Abacus/CN=DSA1"

If the supplier DSA is not represented by a decDSA entry in the Directory, then you have to specify the presentation address of the supplier DSA instead of its AE title. For example:

ncl> UPDATE DSA SUPPLIER '"DSA"/"DSA"/"DSA"/RFC1006+mynode,RFC1006'

The UPDATE DSA command makes the supplier DSA give the consumer DSA a full update of the information that it is configured to consume. The consumer and supplier DSAs also update their shadowing agreements. This should mean that the DISP errors stop happening.

With this version of the Enterprise Directory, the documentation explains how you can customize shadowing agreements. For example, you can change the replication schedule, or specify that changes are replicated as soon as they occur, rather than after certain intervals.

It is possible that managers will change a shadowing agreement incorrectly if they do not understand agreements fully, and they do not follow the documented instructions. For example, a manager might specify an inappropriate combination of shadowing flags, such that a consumer DSA believes that it is a supplier DSA, or such that each DSA thinks the other will initiate replication. Such configuration errors might not be resolvable automatically, and replication may fail or malfunction as a result.

If replication of a given naming context stops working, or works incorrectly, after you have customized an agreement, there are two solutions:

If a Shadowing Update Agreement Failure event specifies the Invalid Agreement problem, this indicates one of two problems. Both of the problems indicate that your Enterprise Directory is incorrectly configured.

The causes of the Invalid Agreement problem are:

If a Shadow Agreement Update Failure event specifies the Currently Not Decidable problem, this might require manual intervention. If the problem only occurs infrequently, then you need take no action. However, if the problem occurs frequently, it indicates that there is something wrong with the agreement, and that replication is unlikely to function correctly for that agreement.

If the problem occurs frequently, refer to the event to identify the supplier DSA for this agreement. Both of the DSAs should have created corresponding events, each indicating which is the consumer and which is the supplier.

Remove the details of the consumer DSA from the Consumer Access Point attribute of the relevant naming context on the supplier DSA. The AE title and presentation address of the consumer DSA are listed in the event, as is the name of the naming context. For example, you might use the following command to remove the details of the consumer DSA from the attribute:

ncl> REMOVE DSA NAMING CONTEXT name CONSUMER ACCESS POINT -
_ncl> {[AE TITLE=aetitle, PRESENTATION ADDRESS=paddr]}

Where name is the naming context name, aetitle is the AE title of the consumer DSA, and paddr is the presentation address of the consumer DSA.

Removing the details of the consumer DSA from the attribute causes the supplier DSA to terminate the agreement. The supplier DSA inform s the consumer DSA that the agreement is terminated, and the consumer DSA deletes its copy of the agreement, and of the relevant naming context. When this has succeeded, you can then add the consumer DSA details back to the Consumer Access Point attribute. This creates a new agreement, and should solve the problem.

If this does not solve the problem, and the new agreement also causes the Currently Not Decidable problem, report the problem to VSI.

Replication of naming contexts within the directory means there is no guarantee that the information you get from the directory is up to date, unless you specify that the Enterprise Directory should only return information from master entries.

By default, the Enterprise Directory returns the requested information from the first instance of the entry it finds, which might be a shadow copy. The DXIM command line interface uses an asterisk (*) in the left margin to mark information that was obtained from a copy of an entry.

By setting the appropriate service control in DXIM, you force the directory to return the requested information from the master copy of the directory entry only. This ensures that you get the most up-to-date information.

If you need to be sure that all information displayed has been obtained from master copies, use the Master Information control, as follows:

dxim> SHOW name ALL ATTRIBUTES MASTER INFORMATION 

where name is the distinguished name of an entry.

If you always want master information, you can use the DXIM SET DEFAULT command to specify the control for all subsequent commands.

If your users consistently receive information that is out of date, try increasing the frequency of updates between your supplier DSAs and your consumer DSAs.

If a user receives information that is wrong, it may be that the entry specified is an alias entry that is not defined correctly.

Check whether the entry is an alias or not, by typing the following commands:

dxim> SHOW ENTRY name ALL ATTRIBUTES
dxim> SHOW ENTRY name ALL ATTRIBUTES DONT DEREFERENCE ALIASES

where name is the name of the entry.

If both commands return the same response, the name specified is not an alias.

If the last RDN of the name is an alias, the response to the second command includes the Aliased Object Name attribute, which contains the distinguished name of the target entry. If any other portion of the name is an alias, the response to the second command includes the matched portion of the name.

If the entry is not an alias, repeat this command for the parent entry by removing the last RDN from the distinguished name. Continue this operation until all RDNs have been checked, or an alias entry has been located.

If an alias entry exists, ensure that the value of the Aliased Object Name attribute points to the correct target entry.

The DSA characteristic attribute Prohibit Chaining overrides the setting of any service controls specified by the user as part of a DXIM command.

Check the setting of the DSA Prohibit Chaining attribute by running NCL and entering the following command:

NCL> SHOW DSA PROHIBIT CHAINING

If the attribute is set to TRUE, it indicates that this DSA will not perform chaining. To enable chaining, enter the following commands:

NCL> SET DSA PROHIBIT CHAINING FALSE

Re-execute the command.

A DSA may not chain a request to another DSA if it cannot maintain the

user's level of authentication. See VSI Enterprise Directory Management for information about the service controls that determine whether a DSA chains a request. If, at any point, the DSA cannot continue to chain the request because of authentication, it will return a referral and generate a Distributed Access Failure event with a reason of DSA Not Trusted. Check for this event.

If this event is being generated, check that the DSAs trust each other (see Section 6.2, “Cannot Replicate Between DSAs”).

If the DSAs are not intended to trust each other, the user must do one of the following:

If the remote DSA cannot be reached, it may be that its node is unavailable. This is indicated by a Distributed Access Failure event being generated with a reason of Association Establishment Failure.

Check that the node is present on the network. See Chapter 3, Problems with Communications for information about communications problems.

This is indicated by a Distributed Access Failure event being generated with a reason of Association Establishment Failure.

Check that the DSA is ready for communication by running NCL and entering the following command:

NCL> SHOW NODE node-name DSA STATE 

where node-name is the name of the node you are trying to contact.

The DSA must be in state ON.

If the DSA is currently unreachable, this is indicated by a Distributed Access Failure event being generated with a reason of Association Establishment Failure.

Use the information contained within the referral and attempt to bind directly to the DSA. If the Bind request fails, refer to Chapter 3, Problems with Communications.

The most likely reason for being unable to retrieve information from the directory is that the user has insufficient access rights to access that information. Refer to Section 6.1, “User Cannot Access Directory Information As Expected” for information on how to solve access control problems.

If a DSA cannot satisfy a directory request and has no specific knowledge of where to chain to, it passes the request to its superior DSA, in an attempt to locate the required entry. It does this on the assumption that a DSA with a naming context located nearer the root may have knowledge information about other parts of the DIT. Note that if you configure your Enterprise Directory as recommended in VSI Enterprise Directory Management , no DSA requires a superior reference.

Check that your DSA has a superior reference by running NCL and entering the following command:

NCL> SHOW DSA SUPERIOR REFERENCE ALL ATTRIBUTES

This displays your DSA's Superior Reference. If a superior reference is undefined, define it using the following command:

NCL> CREATE DSA SUPERIOR REFERENCE name ACCESS POINT address 

where access-point is the access point of the superior DSA.

See VSI Enterprise Directory Management for information about setting up knowledge information.

A subordinate reference is used to identify a DSA that holds a naming context that is subordinate to the naming contexts held by this DSA.

If a subordinate reference is missing, the DSA will not realize that there is a subordinate naming context, and returns the error message The entry does not exist for any of the entries held by that naming context.

Check your subordinate references by running NCL and entering the following command:

NCL> SHOW DSA SUBORDINATE REFERENCE ALL ATTRIBUTES

NCL> CREATE DSA SUBORDINATE REFERENCE name ACCESS POINT address
NCL> CREATE DSA SUBORDINATE REFERENCE name COPY ACCESS POINT address 

A knowledge reference used while processing a user request is incorrectly defined. For example, the information in the reference does not refer to a DSA, or it refers to a DSA that does not hold the relevant part of the DIT. If the invalid reference was a Superior Reference, the error can mean that the specified DSA does not hold superior information to the DSA that used the reference. If the reference was a Subordinate Reference, then the error can mean that the specified DSA does not hold the relevant subordinate naming context.

The invalid reference could be held on any of the DSAs that were trying to process the user request, not necessarily the user's local DSA.

An invalid knowledge reference causes the DSA to generate a Distributed Operation Failure event with the reason argument set to Invalid Reference and the following error message being returned to the user:

DSA Error: Enterprise Directory is Unable to Perform this Command Invalid Reference Supplied

Refer to Section 9.2, “DXIM Error Messages” for a description of this DSA error message and the solution to the problem.

If you have designed your DIT as described in VSI Enterprise Directory Management, you should have one DSA that holds an entry representing your organization as a whole. This DSA should have knowledge of all other DSAs in your organization and of the naming contexts held by them.

If the knowledge information held by this DSA is incomplete, some of your DSAs will be unaware of the existence of other DSAs, and of parts of the DIT held by those DSAs.

Check that the DSA that holds the entry representing your organization has knowledge of all the other DSAs in your organization. A DSA should also have subordinate references for all immediately subordinate DSAs.

See VSI Enterprise Directory Management for information about configuring a distributed DIT.

The Local Scope service control enables you to limit the parts of the DIT that are used to satisfy a request. If the Local Scope service control is in operation, a DSA will only return information from within the part of the DIT it holds. If it cannot satisfy the request, it returns a message indicating that the information does not exist. The default, and recommended, value for the Local Scope service control is FALSE.

The Local Scope service control is specified in the DUA.LocalScope parameter of the DUA defaults file. You can also specify a scope in a DXIM command, to override the value set in the defaults file. See the online help for DXIM for more information.

If the information the user requests is not held by this DSA, the DSA needs to contact other DSAs in order to satisfy the request. The DSA will return a referral instead in any of the following cases:

The DSA characteristic attribute Prohibit Chaining overrides the setting of any service controls specified as part of a DXIM command.

Use the NCL SHOW DSA PROHIBIT CHAINING command to check the setting of the DSA Prohibit Chaining attribute. If the attribute is set to TRUE, it indicates that this DSA will not perform chaining. To enable chaining, enter the following commands:

NCL> SET DSA PROHIBIT CHAINING FALSE

Check whether the Allow Chaining, Prefer Chaining or Chaining Prohibited service controls are defined in the DUA defaults file.

Retry your command.

Refer to Section 5.2, “User Continually Receives Referrals”.

The entry that cannot be foun d is present in the master naming context but not in the shadow. See Section 5.1.1, “User Is Using Copy Entries”.

The schema is installed as a number of text files with the file extensions ".sc". On an OpenVMS system, they are installed in the directory defined by the system logical name DXD$DIRECTORY. The files are called:

• dec.sc
• dit.sc
• dua.sc
• DXD$SCHEMA.SC
• mts.sc
• x400.sc
• x500.sc
• cosine.sc
• quipu.sc
• entrust.sc

Check that you have all the necessary source files, including any additional files created specifically for your Enterprise Directory. Check that all the necessary files are included by dxd_schema.sc or DXD$SCHEMA.SC.

Every attribute stored in the Enterprise Directory must be defined in the directory schema. Therefore, if you have defined a new auxiliary class, for example, ensure that each of the attributes belonging to that class is defined in the directory schema. Refer to VSI Enterprise Directory Management for more information on defining attributes.

The directory schema defines the hierarchy for object classes.

Ensure that all referenced object classes in a class definition actually exist.

Name form s are defined in the directory schema and are referenced by structure rule definitions. If you have created a new structure rule, ensure that the name form you refer to is defined in the schema.

The directory schema defines structure rules related to some object classes used within the Enterprise Directory. Structure rules define the relationships between different structural classes. If you have created a new structure rule, ensure that any superior structure rules are defined.

When you define an attribute, you specify which matching rules apply to that attribute's values. It is possible to specify each of equality, ordering, substring, and approximate matching rules. However, the choice of matching rule is constrained by the choice of syntax for the attribute.

If the schema compilation fails, and states that a matching rule is not applicable to the syntax, refer to VSI Enterprise Directory Management for details of which matching rules may be applied to which syntaxes. That book contains an appendix which details which matching rules can be used for each syntax for the various types of matching. Choose an appropriate rule, amend your schema, and recompile.

Every structure rule must have a unique numeric identifier. If you see this error, then you have defined a structure rule with an identifier that is also assigned to some other structure rule.

Change the structure rule identifier and recompile.

When defining a new subclass, you must specify whether the class is structural, auxiliary, alias, or abstract.

If you see this error, then you have defined a new class to be a subclass of the wrong type of class. For example, you might have specified that a new alias definition is a subclass of the person class. The person class is a structural class, and therefore not a valid superclass of the new alias definition.

Refer to VSI Enterprise Directory Management for details of customizing the schema, and defining new classes.

A structural class can be derived from multiple superclass chains, but only one of those superclass chains can include structural classes. All but one of the superclass chains must be a chain of abstract classes.

This rule is enforced because a structural class is intended to characterize an object, and it would be illogical for an object to be characterized as, for example, both a person and a printer.

Amend your class definition so that only one of the superclasses listed is a structural class, all the rest being abstract classes. Then recompile the schema.

Name form s can only be defined for structural classes and alias classes. This error indicates that you have defined a name form for an auxiliary or abstract class. Remove the specified name form, and recompile.

You can customize the keywords that the DXIM command line interface accepts in commands to refer to attributes, classes, and syntaxes. These keywords must be unambiguous. If the schema compiler finds that a keyword is assigned to more than one definition, it displays an error.

Change the schema to remove duplicate keywords, and recompile.

The schema has detected that more than one window definition has been specified for a given name form. Remove all but one of the window definitions, and recompile.

Check for the existence and file protection of the file that cannot be opened.

Check the existence and protection of the directory into which the output file should be written, and check that there is sufficient disk space for the file.

Some schema definitions, such as attribute sets, involve nested definitions. For example, an attribute set definition can list another attribute set. The schema compiler only allows ten levels of nested definition. If this limit is exceeded, the compilation fails and displays this error, indicating which definition contained too many levels of nesting.

Amend the relevant definition so that it uses fewer levels of nesting. For example, instead of referring to an attribute set, refer to the individual attributes within the set. When the nesting is no greater than ten levels deep, recompile the schema.

On OpenVMS systems, do the following to backup the database:

If you have implemented access controls, then a user might receive an error message when trying to access some types of information in certain ways.

Note that an error message is only returned if the entire request is denied to the user. If part of a user request is satisfied, then no error message is displayed. For example, if a user attempts to display all attributes, but succeeds in displaying only a few attributes, no error is displayed. The user might, nevertheless, complain that the Enterprise Directory has failed to give the access that they expect.

If a user receives the Unwilling to Perform error, then their access was prevented because the DSA that holds the relevant information has one or more characteristic attributes configured. See Section 6.5, “Directory Returns an Unwilling to Perform Error” for details of those attributes.

If a user receives the Insufficient Access Rights error message when trying to access information, or that they have been denied access to certain information, do the following:

If all this is true, then it is likely that the access controls for the information are denying access, rather than one of the preceding problems. Therefore, you need to look at the access controls for the naming context that contains the information the user attempted to read.

If you have kept a record of the access controls you implemented, then refer to those records, and analyze them as described in Section 6.1.1.2, “Analyzing Access Controls” to try to determine what is wrong with the access controls.

If you are not sure what access controls have been implemented, then you need to interrogate the Enterprise Directory to find that out, as described in Section 6.1.1.1, “Finding Out What Access Controls Are Implemented”.

If a user requests a service that requires communication between DSAs, then this can interfere with the user's level of authentication.

When a user authenticates to the Enterprise Directory, by supplying a name and password, they are actually authenticating to the particular DSA to which they are bound. If that DSA needs to get information from other DSAs, the other DSAs do not necessarily assume that the authentication claimed by the first DSA is reliable.

Whenever two DSAs communicate they determine whether they trust each other. If they trust each other, then they both assume that any user who has authenticated to one DSA can be considered to have authenticated to both. If two DSAs do not trust each other, then they do not assume that each other's users are adequately authenticated. Thus, if a user attempts to access information that requires communication between DSAs, they might find that they can access less information than they expected.

VSI recommends that you configure all DSAs to trust each other, as described in VSI Enterprise Directory Management. If you do not configure this trust, then you severely limit the ability of your users to have consistent access to directory information. Users will get different responses depending on which particular DSA they are bound to.

To determine whether two DSAs trust each other, do the following:

A consumer DSA specifies its AE title and password when it contacts the supplier DSA. The values specified by the consumer DSA are the AE Title and Password characteristic attributes of its DSA entity.

The supplier DSA attempts to compare the specified password with the userPassword of the entry that has the same name as the specified AE title.

If the supplier DSA finds no such entry, or finds that the passwords do not match, then it does not supply any directory information to the consumer DSA, and the consumer DSA displays the following error:

Supplier DSA is unavailable.

You need to find out exactly why the supplier DSA refused to supply a copy of its naming contexts. To analyze and solve this problem, do the following:

If your analysis of the problem is that the password specified by the consumer DSA does not match the userPassword of the DSA entry in the DIT, then take the following steps:

If a user complains that some of the information they requested was not returned from the directory, then there are two likely causes.

Firstly, the request might have been satisfied by a DSA that has an incomplete copy of the information. This is not a security problem; see Chapter 5, Problems With Data Management.

The second reason is that access controls are preventing the DSA from returning all of the information requested. See Section 6.1, “User Cannot Access Directory Information As Expected” for a full description of how to diagnose and solve this problem.

You can define a default username to be used by DXIM on Bind requests to the DSA. This is defined in the DUA defaults file in your home directory, in the parameter DUA.Requestor.

The name defined in the DUA.Requestor parameter acts as the default distinguished name for the following:

A user can also specify a name explicitly if they do not want to use the default.

In any case, if the username provided during binding and authentication is not a valid name of an existing directory entry, then the bind and authentication fails. This is indicated by an Authentication Failure event being issued with the Unknown User reason (see Section 10.1.16, “Shadow Agreement Update Failure”).

The bind and authentication also fails if the DSA to which you are binding cannot access the entry that you specify to compare passwords.

If a user reports that they are having problems authenticating, check that they are using a valid distinguished name, and check that the distinguished name actually names an entry.

If the user is using the default name, and the name is invalid, edit the DUA defaults file to specify a valid distinguished name.

When a user authenticates to the directory, they can specify a password. If the DSA to which they are binding can verify that the password supplied matches the userPassword attribute of the user's directory entry, then the DSA gives the user greater access to directory information.

The user can specify a password when authenticating, either by typing the password into the password field of the Authenticate... window, or by using the PASSWORD argument in a DXIM BIND command.

If the password specified by the user does not match the password in the user's entry, then the authentication fails.

If a user reports that their password is being rejected by the Enterprise Directory, use the DXIM COMPARE command to check the password against the user's directory entry. For example, if a user has a directory entry called /c=us/o=abacus/ou=sales/cn"Jon Low", and claims to have the password "mumble", use the following DXIM command:

dxim> compare /c=us/o=abacus/ou=sales/cn"Jon Low" with userpassword=mumble

Remember that the password attribute is case sensitive, so make sure that you use the same combination of upper case and lower case letters as the user.

The COMPARE comman d confirm s whether the password is correct. If not, use the DXIM SET PASSWORD command to change the user's password. They should then be able to use their new password to authenticate.

If the password is correct, then it is possible that the DSA cannot access the user's entry in order to do the password comparison. To verify this, bind to the DSA, and attempt to show the user's entry. If the command fails, this indicates that at least one of your DSAs has incomplete knowledge information. See Chapter 4, Problems With Distributed Operations for details of solving knowledge information problems.

If the command succeeds, it is possible that the access controls specified for the userPassword attribute are preventing the DSA from doing the password comparison. To verify this, see Section 6.1, “User Cannot Access Directory Information As Expected” for details of solving access control problems.

If both the name and the password supplied by the user are correct, then the authentication might fail because the DSA cannot find the user's entry. This indicates one of the following problems:

The only reason a HP DSA ever returns the Unwilling to Perform error message (reported by DXIM as The Directory is Unable to Perform the Command) is because that DSA has one or more of the following DSA characteristic attributes configured using NCL:

• Writer Names
• Reader Names
• Writer NSAPs
• Reader NSAPs
• Trusted DSA Names
• Read Only DSA Names
• Trusted DSA NSAPs
• Read Only DSA NSAPs

To solve the problem, you must first identify which DSA returned the error, as follows:

VSI suggests that you remove all eight of these attributes completely from all of your DSAs. They are not the recommended way of controlling access to directory information, and overrule the recommended access control functionality. They are also difficult to troubleshoot. See VSI Enterprise Directory Management for details of the recommended way to implement access controls, and for a discussion of the disadvantages of using these characteristic attributes.

This problem highlights the difficulties of tracing a user request across multiple DSAs. If you have distributed and replicated your DIT as recommended by VSI, then most user requests can be satisfied with minimal DSA interworking. You should find that the DSA that caused the problem was contacted directly by the user's default DSA, rather than being the last DSA in a complicated chain of communication.

If there is insufficient memory available for the DSA to load its DIB fragment, the NCL No Resource Available error message is issued. The error can also mean that the transport templates required by the Enterprise Directory do not exist.

If the DSA is installed on an OpenVMS system, or the problem occurs even after the templates have been created, read the rest of this section.

Check the memory available by entering the following command:

/sbin/swapon -s 

This shows you how much swap space is available and how much is currently being used. The DSA will start to use the swap space as soon as it runs out of physical memory. If necessary, allocate more memory to the DSA.

Check the Buffered I/O byte count and Paging file quotas available to the DSA. Increase the quotas if necessary. See Section 7.1, “DSA Process Quotas” for details.

Check that there is not another application using the DSA's LDAP port.

The shadowed DIB fragment is stored on disk at both the supplier and consumer DSAs. Check that there is sufficient disk space available at both systems. The disk requirements for the supplier and consumer are different.

The supplier DSA creates a file in the SYS$SCRATCH area. The DSA writes all information for all naming contexts that are to be supplied into that file, and maintains the file until replication is complete. It is therefore the disk space of SYS$SCRATCH that you need to check and increase if necessary. Also, check that those directories exist and are accessible to the DSA.

The consumer DSA also uses the SYS$SCRATCH area, but the file only ever contains details of a single naming context. If the consumer is to receive many naming contexts, each one is received and written to the temporary file individually.

You can edit the command line in DXD$DSA_STARTUP_INPUT.COM that defines the SYS$SCRATCH logical for the DSA process.

Replication fails if there is insufficient memory available to carry out the operation on either the supplier DSA or the consumer DSA.

Check the Buffered I/O byte count and Paging file quotas available to the DSA. Increase the quotas if necessary. See Section 7.1, “DSA Process Quotas” for details.

If you have insufficient memory available on the consumer DSA system, consider reconfiguring the supplier so that fewer or smaller naming contexts are supplied.

Check that there is sufficient memory to create or enable the DSA.

Check the Buffered I/O byte count and Paging file quotas available to the DSA. Increase the quotas if necessary. See Section 7.1, “DSA Process Quotas” for details.

Check that the OSI Transport entity is enabled and ready for communication as follows.

Run NCL and enter the following command:

NCL> SHOW OSI TRANSPORT STATE

The OSI Transport entity must be in state ON for the DSA to be created or enabled, unless the DSA is configured to use RFC1006 connections only.

There are insufficient process quotas to create or enable the DSA. See Section 7.1, “DSA Process Quotas” for information about the quotas required by the DSA process.

The DSA cannot use its configured presentation address. Check for the Local Access Point Establishment Failure event.

This is returned under two circumstances:

There is an internal software error. Contact VSI.

Consider moving to a different device.

Follow the instructions outlined in the DXD$LOGICALS_STARTUP.COM file, which is located in the SYS$STARTUP directory.

If your DSA is a consumer of information for too many supplier DSAs, or the information that it is consuming suddenly increases in size, you may run into resource problems.

Reduce the number of shadow naming contexts held by the DSA.

The DSA can maintain indexes of attribute values to improve performance. However, an index requires additional memory and disk space. A typical indexed attribute requires approximately 20 bytes of memory more than if it is not indexed.

If a given DSA has resource problems, and you cannot solve them using either Section 7.6.1, “Increase Disk Space” or Section 7.6.2, “Reduce Shadowing”, then you might consider reducing the DSA's use of indexes.

The DSA creates indexes in accordance with two lists in the schema. The two lists contain the names of attribute types for which the DSA should maintain an index. By removing attributes from those lists, you can save some memory and disk space. However, reducing the DSA's use of indexes will reduce its performance, especially for search requests.

See VSI Enterprise Directory Management for details of the schema files, and how to control indexing. Note that the decision to use indexes can vary from one DSA to another. If you have a particular DSA that has resource problems, you can consider reducing its use of indexes without impacting other DSAs that hold the copies of the same directory entries.

If you change the schema for this reason, you need to recompile the schema and then delete and recreate the DSA. During recreation, the DSA will discard the unwanted indexes.

To enable accounting, enter the following command:

NCL> SET DSA ACCOUNTING FACILITY ON

To disable accounting, enter the following command:

NCL> SET DSA ACCOUNTING FACILITY OFF

The value of the Accounting State attribute is maintained when you delete and re-create the DSA.

There are five characteristic attributes of the DSA entity that you can use to configure the DSA accounting facility, and one read-only attribute that displays information about the accounting facility:

For more detailed information on these characteristic attributes, see the Directory Module online help.

The DSA creates a new accounting file when you enable accounting. Accounting files are stored in the directory pointed to by the DXD$ACCOUNTING logical. VSI recommends that you store these directories on a different disk to the one that contains the DSA's data files. To do so, define the logical DXD$ACCOUNTING to point to a directory on a different disk to the one that contains DXD$DIRECTORY.

Each accounting file is named according to the following convention:

dxd_YYYYMMDDhhmmss.dat 

where YYYYMMDDhhmmss is the date and time in universal time at which the accounting file was created, for example, dxd_20001015122530.dat. This accounting file was created at 12:25:30 on the 15th of October, 2000.

Accounting file rollover is the process by which the accounting facility closes the current accounting file and creates a new one. You can then decode and process the closed accounting file using your decoding and processing utilities. Accounting file rollover can be either a scheduled accounting file rollover or an unscheduled accounting file rollover.

A scheduled accounting file rollover is one that is forced by the settings of the Accounting Rollover Start Time or Accounting Rollover Interval characteristic attributes of the DSA entity. You need to decide how often you want to process accounting files and set the DSA to perform scheduled accounting file rollovers accordingly.

An unscheduled accounting file rollover is one that is forced by the use of the Accounting Rollover Unscheduled Time characteristic attribute.

These attributes are described in more detail in the Directory Module online help.

The accounting files can be backed up using the normal backup procedure. To ensure that the backup is up to date, either perform an unscheduled accounting file rollover or disable accounting before you back up the accounting file.

There are six types of record that can be written to the accounting file by the DSA. Each type is explained in more detail in Section 8.2.3, “The Information Included in Accounting Records”.

This section describes the ASN.1 definition of the elements of information included in accounting records. Sections Section 8.2.3.1, “Session Start Record” to Section 8.2.3.6, “Discard Record” describe the ASN.1 definitions of the different types of accounting record. The ASN.1 definitions of accounting records include the elements defined in this section.

Each record in the accounting file consists of a set of elements of information. The set is different for each different type of record.

The ASN.1 definitions of the elements are as follows:

Local Accounting Serial Number

The Local Accounting Serial Number element (LASN) uniquely identifies each accounting record within the accounting file. It consists of a session-number and request-number.

LASN is defined as follows:

LASN ::= SEQUENCE {
        session-number INTEGER,
        request-number INTEGER }

Directory Instance Identifier

The Directory Instance Identifier element (DII) uniquely identifies the DSA that created the accounting file.

DII is defined as follows:

DII ::= SEQUENCE {
        dsa-name            DistinguishedName,
        dsa-creation-stamp  GENERALIZED TIME}

Results Summary

The Results Summary element (ResultsSummary) gives brief information about the results of a read, search, or list operation. You can use the Accounting Options characteristic attribute (see the Directory Module online help for more information) to include more detailed information about the results of a user request in the Result PDU and Error PDU elements.

ResultsSummary ::= SEQUENCE {
        size     INTEGER,
        entries  INTEGER }

Operation Status

The Operation Status element (OperationStatus) describes whether an operation succeeded or failed. If the operation failed, OperationStatus also describes the reason why it failed. For example, an OperationStatus with a value of 5 indicates that an operation failed because of a security problem.

OperationStatus is defined as follows:

OperationStatus ::= INTEGER {
        Success (1),
        Abandoned (2),
        RequestError (3),
        Referral (4),
        SecurityProblem (5),
        IncompleteResult (6),
        ServiceError (7) }

An OperationStatus of 2 to 7 indicates an error or problem. The following list indicates what X.500 errors are represented by each Operation Status code. Each error is defined in ITU-T Recommendation X.511.

If you need more information about the errors, set the Accounting Options characteristic attribute to include the ERRORPDU value.

If no OperationStatus is indicated in the record, the operation was a success.

Operation Type

The Operation Type element (OperationType) indicates the type of user request for which this accounting record was created. The operation types are defined in the ITU-T X.500 Recommendations.

OperationType is defined as follows:

OperationType ::= INTEGER {
        READ (1),
        COMPARE (2),
        ABANDON (3),
        LIST (4),
        SEARCH (5),
        ADD (6),
        REMOVE (7),
        MODIFY (8),
        MODIFYRDN (9) }

Session Status

The Session Status element (SessionStatus) describes why a session ended, and is defined as follows:

SessionStatus ::= ENUMERATED {
        Unbind (1),
        IdleDisconnect (2),
        TransportDisconnect (3) }

Protocol Type

The Protocol Type element (ProtocolType) indicates whether the connection was from a DUA or a DSA. A ProtocolType of DAP indicates that the connection is between a DUA and a DSA. A ProtocolType of DSP indicates that the connection is between two DSAs. If the protocol type is not specified in the record, the protocol of the connection is DAP.

ProtocolType is defined as follows:

ProtocolType ::= ENUMERATED {
        DAP (1),
        DSP (2) }

Authentication Level

The Authentication Level element (AuthenticationLevel) indicates the amount of authentication supplied by the user who made the request. If no authentication level element is specified in the record, the authentication level is none.

AuthenticationLevel is defined as follows:

AuthenticationLevel ::= ENUMERATED {
        none (0),
        simple (1),
        strong (2) }

Request PDU

The Request PDU element (RequestPDU) is the PDU of a user request. The structure of the PDU is defined in the ITU-T X.500 Recommendations. This information is only included if the Accounting Options characteristic attribute is set to include the request PDU. See the Directory Module online help for information about how to set this characteristic attribute.

RequestPDU is defined as follows:

RequestPDU ::= OCTETSTRING 

The person responsible for managing the accounting facility needs to decide whether this information is necessary for the accounting policy. If the information is needed, the Accounting Options characteristic attribute needs to be set accordingly. Note that including this information increases the size of the accounting records and therefore means that the accounting file will consume extra disk space.

Error PDU

The Error PDU element (ErrorPDU) is included when the Operation Status of a user request is anything other than a success. The structure of the error PDU is defined in ITU-T Recommendation X.511. This information is only included if the Accounting Options characteristic attribute is set to include the error PDU. See the Directory Module online help for information on how to set this characteristic attribute.

ErrorPDU is defined as follows:

ErrorPDU ::= OCTETSTRING 

The person responsible for managing the accounting facility needs to decide whether this information is necessary for the accounting policy. If the information is needed, the Accounting Options characteristic attribute needs to be set accordingly. Note that including this information increases the size of the accounting records and therefore means that the accounting file will consume extra disk space.

Each record in the accounting file is identified by a context specific constructed tag, called the AccountingRecord. The ASN.1 definition of the AccountingRecord is as follows:

AccountingRecord ::= CHOICE {
        [0]SessionStartRecord,
        [1]SessionEndRecord,
        [2]OperationRecord,
        [3]FileStartRecord,
        [4]FileEndRecord,
        [5]DiscardRecord }

For example, each Session End record in the accounting file is given a context- specific constructed tag of [1].

The following subsections describe the ASN.1 definitions of each type of accounting record in the accounting file.

[0]SessionStartRecord ::= SEQUENCE {
        request-id      LASN,
        start-time      GENERALIZED TIME,
        calling_NSAP    OCTET STRING,
        protocol        ProtocolType DEFAULT {DAP},
        originator      DistinguishedName OPTIONAL,
        authentication  [0] AuthenticationLevel DEFAULT {none} }

[1]SessionEndRecord ::= SEQUENCE {
        request-id       LASN,
        start-time       GENERALIZED TIME,
        calling_NSAP     OCTET STRING,
        protocol         ProtocolType DEFAULT {DAP},
        originator       DistinguishedName OPTIONAL,
        authentication   [0] AuthenticationLevel DEFAULT {none},
        session-end-time GENERALIZED TIME,
        session-elapsed  INTEGER,
        session-status   SessionStatus }

[2]OperationRecord ::= SEQUENCE {
        request-id       LASN,
        start-time       GENERALIZED TIME,
        elapsed          INTEGER,
        operation-type   OperationType,
        protocol         ProtocolType DEFAULT {DAP},
        originator       DistinguishedName OPTIONAL,
        authentication   [0]AuthenticationLevel OPTIONAL,
        status           [1]OperationStatus DEFAULT Success,
        results          [2]ResultsSummary OPTIONAL,
        request-pdu      [3]RequestPDU OPTIONAL,
        error-pdu        [4]ErrorPDU OPTIONAL }

[3]FileStartRecord ::= SEQUENCE {
        dsa-instance       DII,
        start-time         GENERALIZED TIME,
        current-file       IA5String,
        previous-file      IA5String OPTIONAL }

[4]FileEndRecord ::= SEQUENCE {
        dsa-instance     DII,
        end-time         GENERALIZED TIME,
        current-file     IA5String }

[5]DiscardRecord ::= SEQUENCE {
        time              GENERALIZED TIME,
        discarded-count   INTEGER }

This section contains information about accounting files that you need to be aware of:

This event is generated when the DSA disables the accounting facility. The event contains the filename of the closed accounting file, that is, the accounting file that the DSA was using when the accounting facility was disabled.

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

This event is generated when the DSA perform s either an unscheduled or scheduled accounting file rollover. Accounting file rollover is the process by which the DSA closes the current accounting file and creates a new accounting file. A scheduled accounting file rollover is one that is initiated by the setting of the Accounting Rollover Interval attribute. An unscheduled accounting file rollover is one that is initiated by the Accounting Rollover Unscheduled Time attribute.

The event contains the following information:

This event is generated when the DSA fails to access the Accounting file for any reason. The event contains the following information:

When the DSA fails to access the Accounting file, it continues to process user requests but does not record any accounting information about those requests. Instead the DSA generates an Accounting Records Discarded event and, when it can access the accounting file again, creates a Discard record that indicates how many accounting records were discarded while the DSA could not access the accounting file.

This event is generated when the DSA is forced to discard records without writing them to the accounting file. The reasons why the DSA may be forced to discard accounting files are described in Chapter 8, The DSA Accounting Facility. The event indicates the number of records discarded since the last record was successfully written to the accounting file.

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

Refer to Chapter 6, Problems with Access Control and Security for information on how to recover from security problems.

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:

No action is necessary.

This event is generated for communication failure. The event has three arguments.

The Protocol is one of the following:

Directory Access Protocol
Directory System Protocol
DISP Protocol
DOP Protocol
LDAP Protocol

The CommsInterface informs you what network interface failed.

The Diagnostic text gives further information about the Communication Failure.

This event is generated when the DSA fails to create the DSA entity in response to the NCL CREATE DSA directive. The event indicates the reason why the DSA entity could not be created, and provides additional diagnostic information where possible.

The reason is one of the following:

This event is generated when a distributed operation fails. The event message includes the following information: