Compaq ACMS Version 4.3 for OpenVMS
Release Notes

Chapter 7
Guidelines for Reporting an ACMS Problem

The following sections discuss the kinds of information you should have available when reporting an ACMS problem.

7.1 Calling in a Problem to Your Compaq Support Representative

When you call your Compaq support representative to report a problem, the telephone support specialist will most likely ask you for the following information:

Which versions of OpenVMS, ACMS, network, forms product, and programming language are you using?
Obtain the version information as follows:

OpenVMS version
1. Identify the hardware type by logging in to the system and looking at the output of this statement:
  $ WRITE SYS$OUTPUT F$GETSYI("ARCH_NAME")
  The output will be either Alpha or VAX.
2. Get the OpenVMS version from the first line of this command:
  $ SHOW SYSTEM
Network and firmware version and information
1. DECnet version number and ECO level
2. Firmware version
3. TCP/IP product name, version and ECO level
ACMS version
Log in to the system experiencing the problem and type this file using the following command:
$ TYPE SYS$SYSTEM:ACMS_ECO_LEVEL.DAT
This file always contains the most accurate version identification information. Version IDs are not always updated throughout the ACMS system. This file is the most reliable source of ACMS version information.

DECforms version

Get the image file identification of the FORMS$MANAGER image:

$ ANALYZE/IMAGE SYS$SHARE:FORMS$MANAGER.EXE Image Identification Information image name: "FORMS$MANAGER" image file identification: "FORMS V1.4-12" link date/time: 25-JUN-1993 11:46:59.70 linker identification: "05-13" Patch Information

Get the image file identification of the FORMS$CIOSHR image:

$ ANALYZE/IMAGE SYS$SHARE:FORMS$CIOSHR.EXE Image Identification Information image name: "FORMS$CIOSHR" image file identification: "FORMS V1.4-5" link date/time: 8-APR-1992 21:04:07.36 linker identification: "05-05" Patch Information

Report both of these image versions when reporting a problem with a system where DECforms is being used.

TDMS version
Get the image file identification of the TSSSHR image:

$ ANALYZE/IMAGE SYS$SHARE:TSSSHR.EXE Image Identification Information image name: "TSSSHR" image file identification: "TDMS V1.9A-0" link date/time: 29-APR-1991 16:59:21.21 linker identification: "05-05" Patch Information

Programming language version
The programming language version is usually visible in the header of compiler listing files.
For example:
APPL_PROGRAM Source Listing 22-NOV-1993 DEC COBOL V1.1-747 Source Listing 12-OCT-1995 DEC C V4.1-001

A clear statement of the problem, and why you feel this is an ACMS problem.
What commands or process caused the problem?
What were the exact error messages you received?
What additional information appeared in either the ACMS Audit Trail Log file or the ACMS Software Event Logger (SWL)? Be sure to have these logs on hand when you place your call. Refer to Compaq ACMS for OpenVMS Managing Applications for details about these files.

The support specialist may also ask for the following information:

The version number of other products you are using with ACMS.
A description of the application and, if necessary, a small example of code that duplicates the problem.
Whether you are running a distributed application.
If you have a distributed environment, please report the clock time on both systems and note any time difference.
Whether you are running with multiple submitter platforms (that is, whether the logical name ACMS$MULTIPLE_SUBMITTER_PLATFORMS is defined to true).
Whether the problem affects all users or only specific users.
Whether the problem affects all applications or only specific tasks.
Whether the tasks use remote requests.
The types of devices being accessed.
The ACMS system state at the time the problem occurred.
Whether the problem is reproducible.
Whether you can reproduce the problem running your application in the ACMS Task Debugger environment.
Whether this command, statement, or application has worked before. If you answer yes to this question, the specialist will want to know what might have caused the change. For example, such changes might include updates to the operating system or layered products, bringing new production applications online, and adding new users.

After listening to your responses, the specialist might be able to provide immediate help or might have to call you back after doing some testing and research. For problems that the specialist cannot reproduce or resolve, you might be asked to supply additional detailed information.

7.2 Additional ACMS Information You Can Collect

This section provides additional information that you may be asked to collect to assist in analyzing a problem. It would be helpful if, for very large log files, you extract and forward only the portion of the log file that represents the time of the error.

The SWLUP log file. This file is most important. It is located in SYS$ERRORLOG:SWL.LOG or in the directory pointed to by the logical ACMS$SWL_LOG. Send the binary log file rather than an output report.
The Audit Trail Log file. This file is located either in SYS$ERRORLOG:ACMSAUDIT.LOG or in the directory pointed to by the logical ACMS$AUDIT_LOG. Send the binary log file rather than an output report.
Any ACMS dump files. These files are located in the SYS$ERRORLOG directory, the default directory for the associated process user name, or in the directory pointed to by the logical SYS$PROCDMP. The dump file names are in the form of ACMxxxx.DMP.
Use the following commands to analyze the dump file:
$ ANALYZE/PROCESS/OUTPUT=<<emphasis>(file-name)>.DMP_INFO DBG> SHOW CALLS DBG> SHOW IMAGE DBG> SHOW STACK

All ACMSGEN parameters. Use the following commands to obtain this information:

$ RUN SYS$SYSTEM:ACMSGEN ACMSGEN> USE_ACTIVE ACMSGEN> WRITE ACMSGEN.LOG ACMSGEN> EXIT

All OpenVMS SYSGEN parameters. Use the following commands to obtain this information:

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET /OUT=SYSGEN.LOG SYSGEN> SHOW /ALL SYSGEN> SHOW /SPECIAL SYSGEN> EXIT

Memory on all systems involved. Use the DCL command SHOW MEMORY to obtain this information:
$ SHOW MEMORY/ALL/FULL/OUT=MEMORY.LOG
The authorization data for all OpenVMS accounts used by ACMS. Run the OpenVMS Authorize Utility and then obtain a full listing (SYSUAF.LIS file) for each account:
$ RUN SYS$SYSTEM:AUTHORIZE UAF> LIST/FULL <<emphasis>(account-name)> UAF> EXIT
All logical name tables. Use the DCL command SHOW LOGICAL to obtain this information:
$ SHOW LOGICAL/FULL/TABLE=*/OUT=ALL_LOG.LOG

7.2.1 Reporting Problems with ACMS Utilities

In addition to the information listed in Section 7.2, it may be helpful to collect the following information for problems with ACMS utilities:

A listing of the definitions (including record, form, request, request library, task, task group, application, and menu) and procedures that may have caused the problem.
The SWLUP log file. This file is very important. It is located in SYS$ERRORLOG:SWL.LOG or in the directory pointed to by the logical ACMS$SWL_LOG. Send the binary log file rather than an output report.
The Audit Trail log file. This file is located either in SYS$ERRORLOG:ACMSAUDIT.LOG or in the directory pointed to by the logical ACMS$AUDIT_LOG. Send the binary log file rather than an output report.

All ACMSGEN parameters. Use the following commands to obtain this information:

$ RUN SYS$SYSTEM:ACMSGEN ACMSGEN> USE_ACTIVE ACMSGEN> WRITE ACMSGEN.LOG ACMSGEN> EXIT

The authorization data for all OpenVMS accounts used by ACMS. Run the OpenVMS Authorize Utility, and obtain a full listing (SYSUAF.LIS file) for each account using the following commands:
$ RUN SYS$SYSTEM:AUTHORIZE UAF> LIST/FULL <account-name> UAF> EXIT
All logical name tables. Use the DCL command SHOW LOGICAL to obtain this information:
$ SHOW LOGICAL/FULL/TABLE=*/OUT=ALL_LOG.LOG

7.2.2 Reporting Problems with the ACMS Run-Time System

In addition to the information listed in Section 7.2, it may be helpful to collect the following additional information for problems with the ACMS run-time system:

Process dump files. These files are located in the SYS$ERRORLOG directory, the default directory for the associated process user name, or the directory pointed to by the logical name SYS$PROCDMP, if the error occurred in the Command Process (CP), the Application Execution Controller (EXC), the ACMS Central Controller (ACC), the Audit Trail Log (ATL), or the Terminal Subsystem Controller (TSC). The dump file names are in the form of ACMxxxx.DMP.
Use the following commands to analyze the dump file on VAX systems:
$ ANALYZE/PROCESS/OUTPUT=<file-name>.DMP_INFO DBG> SHOW IMAGE DBG> SHOW CALLS DBG> SHOW STACK
On Alpha systems, the dump files should be analyzed on the system where they were created. This should be done before the system is rebooted or modified in any way. Please provide the support specialist with the output file.
Use the following commands to analyze the dump file on Alpha systems:
$ ANALYZE/PROCESS_DUMP/OUTPUT=<file-name>.DMP_INFO- _$ /IMAGE=SYS$SYSTEM:ACMSEXC
The /IMAGE= qualifier is sometimes necessary to access the DEBUG.
$ DBG SHOW IMAGE DBG> SHOW CALLS DBG> SHOW STACK

All OpenVMS SYSGEN parameters. Use the following commands to obtain this information:

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> SET /OUT=SYSGEN.LOG SYSGEN> SHOW/ALL SYSGEN> SHOW/SPECIAL SYSGEN> EXIT

Memory on all systems involved. Use the DCL command SHOW MEMORY to obtain this information:
$ SHOW MEMORY/ALL/FULL/OUT=MEMORY.LOG

Output from the SDA utility for any ACMS processes that appear to be hung. Use the following commands to obtain the information:

$ ANALYZE/SYSTEM SDA> SET PROCESS/ID=pid-of-hanging-process SDA> SHOW PROCESS SDA> SHOW PROCESS/CHANNEL SDA> SHOW PROCESS/IMAGES SDA> SHOW PROCESS/PHD SDA> SHOW CALL SDA> SHOW CALL/NEXT SDA> SHOW CALL/NEXT !repeat this until there are no more calls Call Frame Information ----------------------- %SDA-E-NOTINPHYS, 00000000 : not in physical memory SDA> EXIT

Collection of current PCs and other information from any process that may be hung. Use the following process to capture this information:
$ SET HOST/LOG=output-file NODE::
After logging in:
$ SET TERM/UNKNOWN $ SHOW PROCESS/ID=pid/CONTINUOUS
Let this run for 15 to 20 minutes, then press CTRL/Z.
$ LOGOUT
Submit the output file with the problem report.
A machine-readable copy of the OpenVMS SYSGEN parameter values. This may be useful if there is an unexpected process dump. Use the following commands to obtain these values:
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE ACTIVE SYSGEN> WRITE <file-spec>
The USE ACTIVE command copies the current parameter values into your work area. The WRITE command creates a machine-readable version of this information in the output file you specify.
A listing of the ACMSGEN parameters.
A listing of the definitions (including form, request, request library, task group, task, record, application, and menu) and procedures for the task that may have caused the problem.
A listing of the parameter settings of the various user names under which the ACMS components were running when the problem occurred. Use the OpenVMS Authorize Utility to obtain this information:
$ RUN SYS$SYSTEM:AUTHORIZE UAF> LIST/FULL <user-name>
The LIST/FULL command writes the information to a file called SYSUAF.LIS in your default directory. The file includes the user name, the user identification code (UIC), the default OpenVMS directory, privileges, and a list of the OpenVMS quotas and values assigned for that user name.
Information about the user names for the ACMS Central Controller (ACC), the Terminal Subsystem Controller (TSC), the Application Execution Controller (EXC), and the Command Process (CP) is useful in determining the events surrounding a problem with the ACMS system.
A listing of the Audit Trail Report for the error.
A listing of the ACCOUNTING log report.
A listing of the hardware error log (Error Log Utility).

Appendix A
Error Messages

This appendix contains the ACMS error messages.

A.1 Remote Manager Messages

The following error messages pertain to the ACMS Remote Manager.

SUCCESS, operation completed

Explanation: The ACMS Remote Manager service completed without error.
User Action: No action is required.

INFO, operation completed with information message

Explanation: The ACMS Remote Manager service completed without error but has logged an informational message. Informational messages are for debugging and auditing purposes.
User Action: No action is required.

NOMORE_DATA, no more data is available

Explanation: There is no more data that satisfies the query. This message is provided on list RPCs that can return more than one buffer of data. If a list RPC is called and this status is not returned, then more data is available that satisfies the query criteria. If this status is returned, then there is no more data to retrieve for this query.
User Action: No action is required. The query is complete.

WARN, operation completed with warning, Not all operations completed successfully

Explanation: The ACMS Remote Manager service did not complete successfully; some of the actions requested could not be completed. This status is returned in the following situations:

Multiple fields were specified on an update function, at least one of which failed. For example, a call may have been made to the set parameters function (acmsmgmt_set_param_1) to update more than one parameter, and one of the values specified was invalid. For these functions, a list of fields is returned with status codes for each field.
A call to start or stop an ACMS process was executed, and a warning was returned. Starting or stopping ACMS processes is performed by ACMS OPER, which may return warning messages. In this case, a set of messages is returned describing the cause for the warning.
A call to display ACMS process information was made, and old (stale) data was returned. This can occur when an ACMS process is no longer running, and a show function requests data for that process. For instance, if the TSC was running and then had been stopped, and the acmsmgmt_get_tsc_1 function is called, the tsc record is returned with WARN status.

User Action: No action is required; however, the record_state field of any record returned should be checked. The Remote Manager flags old data with a record_state of MGMT$K_INACTIVE.

If this status is returned as the result of an ACMSMGR command, old (inactive) records are flagged with an asterisk (*) preceding the node name.

FAIL, operation failed

Explanation: The function requested could not be performed.
User Action: The appropriate action depends on the function being called. In general, additional information is displayed by the ACMSMGR command in conjunction with this error code. That information should be more indicative of the reason for failure. If this status was returned by an RPC, the failure occurred in the Remote Manager process; a second-level error code is returned in the output record.

NOMEM, memory allocation failed

Explanation: An internal memory allocation by the Remote Manager failed. This can occur during a request for data, a call to add a record to a table, or during server initialization while it is loading initial configuration information. In the first two instances, the Remote Manager continues to run; in the third, the Remote Manager exits.
User Action: Increase the amount of memory available to the Remote Manager. If the problem is due to insufficient physical or virtual memory, try allocating more page or swap space. If physical and virtual memory are not exhausted, try increasing the memory quotas for the account in which the Remote Manager is running. Be sure to check SYSGEN PQL quotas to ensure that the quotas you grant to the Remote Manager are allowed by the system.

After making more memory available to the Remote Manager, you must restart the Remote Manager process.

LOGIN_EXPIRED, login credentials have expired, please log in again

Explanation: The credentials you used to log in to the Remote Manager have expired. Credentials are granted when the user logs in and are valid for a period of time equal to the value of the login_creds_lifetime parameter at the time of login. After that time, the credentials expire and must be re-created by logging in to the Remote Manager again.

Note that while proxy credentials also expire, they are automatically re-created at the end of the expiration period. Therefore, this status is never returned to proxy users.
User Action: The user must log in to the Remote Manager again.

2MANY_USERS, the maximum number of users has been reached

Explanation: The user could not be logged in because the maximum number of concurrent users has been reached. This maximum is determined by the max_logins parameter, which is a dynamic parameter (that is, it can be changed dynamically).
User Action: Either log some users out, or increase the value of the max_logins parameter. You can use the ACMSMGR SHO USERS command to determine which users are already logged in to the Remote Manager. Note that in order to issue that command or to increase the max_logins parameter, you must be logged in.

NO_NODELOGICAL, cannot translate logical UCX$INET_HOST to get node name

Explanation: The logical name UCX$INET_HOST could not be translated by the client process. This logical is used to determine the current host name, which is used during client authentication. It is defined by the UCX or TCP/IP layered product when it is started. If this logical is not defined, UCX or TCP/IP is not started; either a different TCP/IP networking package is being used, or something has gone wrong with the logical name.
User Action: Verify that the UCX or TCP/IP layered product is started. If it is not, start it and then reissue the command. If it is started, contact your system administrator to determine why the logical is not defined.

NO_CREDS_FILE, credentials file not found

Explanation: The credentials file for the user either could not be found or could not be opened by the client process. The credentials file is created when a user explicitly logs in to the Remote Manager (that is, when the user supplies a user name and password). A separate credentials file is created for each node to which a particular process logs in. The logical name ACMS$MGMT_CREDS_DIR is used to point to the directory containing credentials files.
User Action: Verify that the ACMS$MGMT_CREDS_DIR logical is pointing to a valid disk and directory in which a credentials file has been created; verify that the process has read access to the files in the directory. If necessary, the process may have to log in to the Remote Manager again to create a new credentials file.

CREDS_DATA_ERR, credentials file is corrupt

Explanation: The credentials file for this user has been corrupted. The file has been opened, but the client process cannot parse the contents of the file.
User Action: The user should log in to the Remote Manager again. This will create a new credentials file.

WRONG_PID, current pid does not match pid in credentials file!

Explanation: The PID stored in the credentials file does not match that of the current process. Either the file is corrupt, or it has been tampered with.
User Action: The user should log in to the Remote Manager again. This will create a new credentials file.

WRONG_NODE, current node does not match node in credentials file!

Explanation: The node name stored in the credentials file does not match the node name on which the current process created it. Either the file is corrupt, or it has been tampered with.
User Action: The user should log in to the Remote Manager again. This will create a new credentials file.

BADHOUR, network access is prohibited for this hour for this account

Explanation: This status is returned during user login if the UAF record for this user does not allow network access during this time of day. Time-of-day restrictions on network access are set by system administrators or security personnel.
User Action: Either wait until an authorized hour to access the Remote Manager, or modify the network access portion of the UAF for this user.

BADDAY, network access is prohibited for this day of week for this account

Explanation: This status is returned during user login if the UAF record for this user does not allow network access on this day of the week. Day-of-week restrictions on network access are set by system administrators or security personnel.
User Action: Either wait until an authorized day of the week to access the Remote Manager, or modify the network access portion of the UAF for this user.

PWDFAIL, invalid password

Explanation: The password entered for the user during user login does not match the one stored in the UAF for this user on the server node.
User Action: Resubmit the login request for the user with the correct password.

PWDEXP, password has expired

Explanation: The password entered by the user has expired in the UAF on the server node.
User Action: The user must either change the password or have it unexpired by a system or security administrator.

DISUSER, account is disusered

Explanation: This status is returned during user login if the account associated with the user name has the DISUSER flag set.
User Action: Clear the DISUSER flag on the UAF record for the account.

ACCTEXP, account is expired

Explanation: This status is returned during user login if the account associated with the user name has expired.
User Action: Either remove or modify the account expiration.

NONETACCESS, network access is prohibited for this account

Explanation: This status is returned during user login if the account associated with the user name has not been granted network access. Network access is required, even if the user is logged in to same node on which the Remote Manager is running.
User Action: Grant network access to the account.

NOPROXY, proxy access is not enabled

Explanation: This status is returned when a user attempts to access a Remote Manager function without explicitly logging in, and proxy access has not been enabled on the Remote Manager node. Proxy access is enabled on the node by defining the system logical ACMS$MGMT_ALLOW_PROXY_ACCESS to be TRUE, true, T, t, Y, y, or 1. The translation of this logical is cached by the Remote Manager when the RPC thread is started.
User Action: If proxy access is not supposed to be enabled, then there is no action to perform. If proxy access is to be allowed, define the ACMS$MGMT_ALLOW_PROXY_ACCESS system logical, with a translation value of TRUE, true, T,t, Y, y or 1. Then restart the Remote Manager and resubmit the RPC.

INV_CLNTID, client id is invalid

Explanation: A request was made to the Remote Manager with an invalid client id. The client id is a unique value assigned to each client and used to verify client authorization. If the client id is not known to the Remote Manager, it either belongs to an old log in that has expired and been purged, or it was never valid.
User Action: The user should log in to the Remote Manager again.

PROXY_FAILED, proxy access attempt failed

Explanation: An attempt to verify proxy information for this client failed. A more specific message indicating why the proxy failed is written to the Remote Manager log. Reasons for proxy authentication failure include:

No proxy record is in the ACMSPROXY.DAT file.
The proxy account is disusered.
There is a problem with the network access for the account (does not have network access allowed, is outside of the allowed network access days or times).
The proxy account has expired.
An internal error occurred during processing.

User Action: First check the Remote Manager log for any additional information related to the login attempt. Then verify that none of the conditions listed are preventing the login from succeeding.

NORIGHT, user does not hold the proper rights identifier

Explanation: Access to Remote Manager functions is restricted by a set of rights identifiers; the account being used to access the function must have the appropriate rights identifier. If this status code is returned, the account does not have the appropriate rights identifier.
User Action: Grant the appropriate rights identifier to the user's account. If a proxy account is being used, the rights identifier must be granted to the proxy account.

NOT_MAPPED, ACMSMGMT global section is not available

Explanation: This status code is returned if a Remote Manager function was requested that requires access to the ACMSMGMT global section, but the global section does not exist. The global section is created by the ACMS ACC during system startup. This status code indicates that the ACMS ACC is not running or that it has not yet created the global section.
User Action: Start the ACMS run-time system in order to create the global section. The ACMS run-time system can be started by using either the ACMSMGR START SYSTEM command or the ACMS/START SYSTEM command.

INVVAR, invalid variable value was provided

Explanation: This status code is obsolete.
User Action: No action required.

NOT_VALID, entity data is stale, please resubmit query or wait until later

Explanation: The entity record in the global section is not valid. If this status code is returned, it means that the entity has never been started on the Remote Manager node. If the entity had been running at one time but no longer is, a severity level of WARN is returned and the record_state is set to INACTIVE.
User Action: No action is required. However, if the entity is started on the Remote Manager node, the data will become available.

DUPLICATE_ROW, table row exists

Explanation: An attempt was made to add a row to either the Trap or the Collection table, but the row already exists.
User Action: Either modify the existing row, or add a new row with unique data.

TABLE_FULL, collection table is full. Non dynamic parameter total_entity_slots controls size

Explanation: An attempt was made to add a row to the Collection table, but there are no empty slots. The maximum number of rows in the Collection table is determined by the nondynamic parameter total_entity_slots.
User Action: To make the table bigger, modify this parameter in the configuration file (using the ACMSCFG command), and restart the ACMS run-time system. The Remote Manager can be left running.

Contents

Compaq ACMS Version 4.3 for OpenVMSRelease Notes

Chapter 7Guidelines for Reporting an ACMS Problem