Document revision date: 28 June 1999

This appendix suggests ways to recover from difficulties encountered while operating DECdfs for OpenVMS. The following topics are covered in this appendix:

• What to do first (see Section B.1)
• Controlling event and error messages (see Section B.2)
• Using other DECdfs servers and clients to isolate problems (see Section B.3)
• Solving common DECdfs problems (see Section B.4)

If you encounter a problem using DECdfs, first try the following suggestions to correct the problem:

• Retry a procedure, reentering information if necessary, to eliminate possible mistakes in typing. Retrying a procedure may mean completely mounting a partially mounted device (see Section 3.4.6) or gaining access to a name server that has been updated more recently.
• If you are unsure of an access point name, you can check the access points registered in the Digital Distributed Name Service (DECdns) name space by entering the command SHOW ACCESS_POINT. DECdfs lists access points read from a DECdns server and if the local node is a DECdfs server from the DECdfs server's local database.
• Ensure that the DECdfs function you are trying to perform is not obsolete or restricted. Check the list of obsolete command parameters in Appendix D and the list of restrictions in the release notes.
• Ensure that you have the required privileges to perform the desired operation. Required privileges are listed with each applicable command described in Chapter 4.
• Observe the status of the server or Communication Entity by entering a SHOW SERVER or SHOW COMMUNICATION command. One or both entities may have stopped. See Section 2.9 for information about restarting the server and Communication Entity.
• If you receive an error message in response to a DECdfs operation, look up the error message in Appendix A and perform any user action included with the message.

You can set the DECdfs server and Communication Entity to report various event and error messages to OPCOM and to an error log, or you can disable reporting of event and error messages altogether.

The DECdfs SET SERVER and SET COMMUNICATION commands have a /REPORTING qualifier that allows you to enable and disable reporting for server, communication, and network event and error messages. The /REPORTING qualifier also controls whether the DECdfs server sends messages to OPCOM. Figure B-1 shows the event and error message paths for the server and Communication Entity.

The DFS$CONFIG.COM file defines logical names DFS$ERROR_DEVICE and DFS$OUTPUT_DEVICE that allow you to specify a destination device or file for server and communication error messages. The default device for both the DFS$ERROR_DEVICE and DFS$OUTPUT_DEVICE is SYS$MANAGER:DFS$ERROR.LOG.

When you first install DECdfs software, the DECdfs server and Communication Entity report messages to OPCOM. OPCOM is enabled by default with output to the system console. All DECdfs messages (except some that are always enabled) are disabled.

Figure B-1 Event and Error Message Paths

To permanently change the settings for DECdfs messages, edit the SYS$STARTUP:DFS$CONFIG.COM file. You can change the logical name assignments for DFS$OUTPUT_DEVICE and DFS$ERROR_DEVICE. You can also change the settings for the /REPORTING qualifier to the SET SERVER and SET COMMUNICATION commands.

B.3 Using Other DECdfs Servers and Clients to Isolate Problems

You can identify the source of some DECdfs problems by using other DECdfs devices. For example, if you are having trouble reading files from a server disk, try gaining DECdfs access to another disk on another DECdfs server. If that operation succeeds, suspect difficulty with the server you cannot reach.

If you cannot gain access to any other DECdfs devices, suspect problems with the DECdfs client. To confirm a client problem, try gaining access to the DECdfs server device from another DECdfs client. Successful access from a different client suggests a problem with the original client.

If you suspect that a DECdfs server disk is not available, enter some other command directly on the server node, such as the OpenVMS DCL command DIRECTORY, to check disk and file availability. You can also try reading from the DECdfs server disk locally (from the server) to determine that the server's disks are operating correctly.

B.4 Solving Common DECdfs Problems

This section suggests actions you can take to solve some common DECdfs problems. You may also wish to consult Appendix F for information about restrictions on DECdfs support for Extended File Specifications.

B.4.1 DECdfs Fails After Upgrading from an Earlier Version

If DECdfs fails after upgrading from an earlier DECdfs version, reboot the system. This causes the software to start using new versions of DECdfs drivers and shareable images.

B.4.2 Unexpected Error While Opening a File

If you have problems opening a file, you might receive an error code. Table B-1 shows typical error codes you might encounter while opening one or more files and suggests possible causes of the errors.

Table B-1 Error Codes While Opening Files

Error Code	Possible Cause
RMS-E-DNR	DECnet or the Communication Entity is unavailable at the client, or the Communication Entity is unavailable at the server. A SYSTEM-F-DEVNOTMOUNT error code may appear in place of the RMS-E-DNR error code. Restart DECnet or the Communication Entity or both at the client or server.
SYSTEM-F-UNREACHABLE	DECnet is unavailable at the server. Restart DECnet and DECdfs at the server.
SYSTEM-F-NOLISTENER	The server is not running. Restart the server.
SS$_INCVOLLABEL	The server is running but the access point is not in the server database. Add the access point at the server.

B.4.3 Unexpected Error While Accessing an Open File

If you receive an error code or other unexpected response while reading from or writing to an open file, the link might have disconnected or the server node might have failed.

The system returns an SS$_ABORT error code when such problems occur. The application or utility being used might return its own error code with the SS$_ABORT error code.

When DECdfs detects the loss of the server, DECdfs enters the mount verification state (see Section 3.4.5) and tries to reestablish the link. Reestablishing the link allows the next file-open operation to succeed.

B.4.4 Unexpected DECdns Errors when Performing Access Point Operations

When using DECdfs, you might encounter DECdns errors when adding, removing, mounting, or showing access points. You can avoid the most common problems with DECdns by making sure you have met the following DECdns needs:

• To add access points, the DECdfs server manager account requires write access to the DECdns directory where you want to add access points.
• To remove access points, the DECdfs server manager account must have write access to the DECdns directory where you want to remove access points and delete access to the DECdns object that represents the access point.
• To mount or show access points, the DECdfs server manager account or DECdfs client user account requires read access to the appropriate DECdns directories and object.
• Be certain you entered the access point name correctly. See the appropriate command examples in Chapter 4.

If you have all the required privileges and have entered the access point name correctly, you might still receive a DECdns error message. Use the Help Message utility to get more information about the error and perform the suggested recovery action. (For online help about Help Message, enter HELP HELP/MESSAGE at the DCL prompt ($).)

This section suggests ways to recover from problems in accessing server files.

B.4.5.1 New Client User Cannot Access Server Files

A new client user might not be able to access server files after proxy access is added at the server. Access attempts receive the "Insufficient privilege or file protection violation" error message.

Enter the SET SERVER /INVALIDATE_PERSONA_CACHE command on the server. This forces the persona cache to read fresh data from the NETPROXY.DAT, SYSUAF.DAT and RIGHTSLIST.DAT files without waiting for the persona cache update interval to expire.

B.4.5.2 Existing Client User Cannot Access Server Files

User attempts to access server files might result in an "Insufficient privilege or file protection violation" error message from the server.

Try the following actions to diagnose and correct the problem:

1. Enter the SHOW SERVER /USERS command on the server.

   Note To get useful information, you must enter the SHOW SERVER /USERS command within the persona cache update interval that follows the unsuccessful client access.

   
   Look for the following possible problems:
   • If the client (remote node::user) is correct but the local user is DFS$DEFAULT when you expected the client to use an actual user account, be certain you added a default proxy by using the AUTHORIZE Utility's ADD/PROXY command:

     $ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD /PROXY remote_node::remote_user local_user /DEFAULT

   • If the client's node is a cluster member and the local user is DFS$DEFAULT when you expected the client to use an actual user account, be certain you enabled the alias outgoing on the cluster and added a default proxy for the cluster alias by using the AUTHORIZE Utility's ADD/PROXY command:

     UAF> ADD /PROXY cluster_alias::remote_user local_user /DEFAULT

     
     If the outgoing cluster alias cannot be enabled for some reason, be certain you added a default proxy for each cluster member by using the AUTHORIZE Utility's ADD/PROXY command:

     UAF> ADD /PROXY cluster_member::remote_user local_user /DEFAULT

     Note If a DECdfs client cannot find the target proxy account and the server does not have a DFS$DEFAULT account, the SHOW SERVER /USERS command will not produce information about the failed access. In this case, you can create a DFS$DEFAULT account on the server to aid in diagnosing the problem. Then retry step 1.

   • Enter the SHOW COMMUNICATION /CURRENT_CONNECTIONS command on the server.
     Look for the following possible problems:
     • The client node is a cluster member, and you see an incoming connection from the client node name, but the proxy is for the cluster alias.
       To use the cluster alias in the proxy, add the following commands to the DFS$SYSTARTUP.COM file on the client node:

       DECnet Phase IV:
       

       $ MCR NCP SET OBJECT DFS$COM_ACP ALIAS OUTGOING ENABLED

       
       

       DECnet Phase V:
       

       $ MCR NCL CREATE [NODE node-id] SESSION CONTROL APPLICATION DFS$COM_ACP $ SET [NODE node-id] SESSION CONTROL DFS$COM_ACP OUTGOING ALIAS TRUE

       
       Compaq assumes the executor alias node name is already defined on the client node. Otherwise, add proxies for the cluster member node names.

     • The client node is a cluster member, and you see an incoming connection from the client's cluster alias, but the proxy is for the client cluster member name.
       Add a proxy for the cluster alias or disable the outgoing alias on the client node's DFS$COM_ACP object.
     • You see an incoming connection from the the client node, but it is displayed as a numeric DECnet address instead of the node name.
       Make sure the client node is correctly defined in the server node's DECnet node database. If you load the node database in a batch job on the server, make sure DECdfs does not start on the server before all the client nodes are defined on the server.

       Note If you add or modify any proxies, remember to enter the SET SERVER /INVALIDATE_PERSONA_CACHE command before using the new proxy information.

You must use the /SYSTEM qualifier with the MOUNT command when you mount an access point. Otherwise, just as with non--DECdfs disks, the print symbiont cannot access the device. See Section 3.6 for information about using the /SYSTEM qualifier.

On clients that are clusters, you also must ensure that DECdfs device names are consistent on all cluster members. Use the /DEVICE qualifier to the MOUNT command to force the same device name onto each cluster member. See Section 3.6 for information about using the /DEVICE qualifier.

The print symbiont runs under the system account. One of the following conditions must apply to enable users to print files:

• The SYSTEM account on the client needs proxy access to the special printing account on the server (see Section 2.2.4).
• The SYSTEM account on the client needs proxy access to the user account on the server.
• The file must be readable by the DFS$DEFAULT account on the server.

If the client is a cluster and the cluster alias is enabled, the proxy must be from CLUSTER-ALIAS-NAME::SYSTEM. If the cluster alias is not enabled, add proxies on the server from each CLUSTER-MEMBER-NAME::SYSTEM. See Section 2.2.4 for information on adding proxies.

If you experience difficulty in using DECdfs to back up files, make certain you are not using the /IMAGE, /PHYSICAL, or /FAST qualifiers with the BACKUP command.

	privacy and legal statement
6548_CPRO_006.HTML