HP OpenVMS Systems Documentation

The Audit Trail Logger (ACMSATL) attempts to translate the following logical names and uses the values specified when the Audit Trail Log file is created:

• ACMS$ATL_DEQ_BLOCKS --- The default extension quantity (DEQ) specifies the number of blocks to be added when the file is extended. Valid values are 0 through 65535.
• ACMS$ATL_ALQ_BLOCKS --- The allocation quantity (ALQ) specifies the number of blocks to be initially allocated when the log is created. Valid values are 0 through 4,294,967,295.

See the OpenVMS Record Management Services Reference Manual for additional information on these fields.

6.11 New Logical Name Must be Defined for RI Agents and User-Written Agents

During the initialization of a CP process or a user-written agent, ACMS determines the following two conditions: whether CMA is in the process and the version of DECforms being used. Depending on these two conditions, the ACMS agent with respect to DECforms operates in either SINGLE-USER mode or MULTI-USER mode.

SINGLE-USER mode is defined as one (1) user at a time executing an ACMS task. A single-threaded user-written agent is an example of SINGLE-USER mode.

MULTI-USER mode is defined as more than one (1) user at a time executing an ACMS task. A CP process is an example of MULTI-USER mode. If you use a MULTI-USER user-written agent with DECforms Version 2.2, the agent must be linked with CMA.

ACMS provides the logical name ACMS$DECFORMS_IN_AGENT. This logical name must be defined as a process logical name when a user-written agent uses DECforms in ACMS tasks. The following values are valid for defining the logical name to a TRUE value: 1, "T", "t", "Y", "y". For example:

$ DEFINE/PROCESS ACMS$DECFORMS_IN_AGENT "Y"

ACMS Version 4.1 used the logical name ACMS$CMA_USER_AGENT for essentially the same purpose, but the name was confusing. Later versions of ACMS still support this logical name, but it is undocumented.

Compaq recommends that you use settings for the logical name based on the version of DECforms that the agent uses, as follows:

• DECforms Version 1.4 is used. Defining the logical name ACMS$DECFORMS_IN_AGENT is not required but has no harmful effects. Defining the logical name causes ACMS to load the FORMS$MANAGER forms manager during initialization, rather than when the first DECforms call is made.
• DECforms Version 2.1B is used. The logical name ACMS$DECFORMS_IN_AGENT must be defined to the TRUE value. Doing so ensures that ACMS brings CMA into the process if CMA is not already there.
• DECforms Version 2.2 or later is used. If the agent is intended to run in SINGLE-USER mode, defining the logical name ACMS$DECFORMS_IN_AGENT has no effect, because CMA is not in the process. Defining the logical name causes ACMS to load the FORMS$MANAGER forms manager during initialization, rather than when the first DECforms call is made.

Define the logical name ACMS$DECFORMS_IN_AGENT only when using DECforms Version 2.1B or when using DECforms Version 2.2 or later in MULTI-USER mode.

6.12 Cache Directories for Application and Forms Files Should Not Be Write Protected

The directories used for caching the application and forms files should not be write protected. Write protecting the caching directories will cause the task to fail when caching of the application or forms files to the submitter node is performed.

6.13 No Longer Necessary to Store ACMS Definitions in CDD

In previous versions of ACMS, after ACMS definitions were checked for syntax errors they were always stored in CDD. When all the definitions were processed, the definitions were read out of the dictionary, and a database file to be used by the ACMS run-time software was created. With ACMS Version 4.3 and later, the ACMS definitions no longer have to be stored in CDD. The ADU COMPILE command can be used to compile ACMS definitions and store the results in an OpenVMS file. Once all the definitions are processed, the ADU LINK command can be used to create the runtime database files.

CDD record definitions must continue to be stored in the dictionary. When determining whether to store definitions in CDD or to compile the definitions into OpenVMS files, keep in mind the following:

• All ACMS definitions that are going to be transformed for inclusion into a database file must be processed the same way.
  For example, if you store a task group definition in the CDD, all task definitions referenced in the task group must also be stored in the dictionary. If, instead, you compile the task group definition, all referenced task definitions must be compiled.
• File-based processing requires that the files that are the compilation results of all referenced ACMS definitions be in the same directory with the same file extension. That is, the compilation results of all tasks required by a task group must be in the same directory with the same file extension. The same is true for all submenus required by a menu.

For more information about the ADU COMPILE and LINK commands, refer to the Compaq ACMS for OpenVMS ADU Reference Manual.

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
    1. 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

    2. 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=<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 <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

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

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).

If you encounter problems with the Remote Manager web agent process (ACMS$MGMT_HMMO), refer to the following files for error information specific to the web agent:

SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.LOG;*
SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.ERR;*.
SYS$SPECIFIC:[WBEM]*.DMP;*

If the problem is with WBEM$SERVER process, supply your Compaq support representative with the dump file. If the problem is with the Remote Manager web agent process, please have the following files ready for analysis in addition to a procedure which reproduces the error condition:

SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.LOG;*
SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.ERR;*
SYS$SPECIFIC:[WBEM]*.html;*
SYS$SPECIFIC:[WBEM]*.txt;*
SYS$SPECIFIC:[WBEM]SYS$OUTPUT.*;
SYS$SPECIFIC:[WBEM]*.DMP;*