# Compaq ACMS for OpenVMS
Version 4.4 Release Notes

Previous | Contents

## 4.1.14 Cannot Access ACMSSNAP Online Help from the DCL Command Line

In contrast to other ACMS utilities, you can only access online help for ACMSSNAP from inside the utility itself and not from the DCL command line. For example, entering either ACMSSNAP HELP or ACMSSNAP HELP OPEN at the system prompt invokes the ACMSSNAP utility and not online help, as follows:

    $ ACMSSNAP HELP
    ACMSSNAP>

To access online help, invoke the utility and enter HELP and the command prompt to display a list of topics.

## 4.1.15 ACMSSNAP SHOW Commands Display Only One Timestamp Value

ACMSSNAP SHOW commands display only one timestamp even when multiple entities satisfy the selection criteria. The timestamp displayed is for the last record read, regardless of the entity to which the record belongs.

For example, the timestamp in the following ACMSSNAP SHOW EXC/ID command belongs to the last record read, which may or may not be a record for the TAPP application:

    ACMSSNAP> SHOW EXC/ID

    ACMS Remote Management -- Snapshot utility
                    ID
        Node       Class     PID     Process Name         Start Time              Application Name
     ------------ -------- -------- --------------- ----------------------- --------------------------------
     sparks       enabled  5954     ACMS01EXC002000 12-JUN-2001 14:26:49.00 TAPP1
     sparks       enabled  5D53     ACMS01EXC001000 12-JUN-2001 11:33:14.76 TAPP [12-JUN-2001 15:45:02.06 ]

## 4.1.16 ACMSSNAP SHOW Commands May Overlay the Status Message with the Timestamp Value

If you issue an ACMSSNAP SHOW command before any records for the specified entity have been read, the timestamp value will partially overlay the status message, as follows:

    ACMSSNAP>SHOW EXC/CONFIG

    ACMS Remote Management -- Snapshot utility
    [ 5-JUN-2001 09:02:07.26]C data was found for node sparks

## 4.1.17 ACMSSNAP OPEN/SUMMARY Displays an Additional Row for Manager Data

The ACMSSNAP OPEN/SUMMARY command displays an additional row for Manager data (MGR), even though it is not possible to collect or store this data. This row can be safely ignored.

## 4.1.18 Remote Manager Web Agent May Fail with Access Violation if Connection to Remote Host is Terminated Unexpectedly

The Remote Manager web agent process (ACMS$MGMT_HMMO) may fail with an access violation if the connection to Remote Manager host is terminated unexpectedly during execution of one or more of the following operations:

- Stop Application (EXC) (STOP EXC/APPLICATION)
- Start Application (EXC) (START EXC/APPLICATION)
- Set EXC, Application State (SET EXC/APPLICATION)
- Set Server Types (SET SERVER/SERVER)
- Set Remote Manager, Collection (SET COLLECTION)

## 4.1.19 Cannot Set Data Snapshot Storage Times for ID and CONFIG Classes with Remote Manager Web Agent

The following storage time parameters for ID and CONFIG class data snapshot collections cannot be set using the Remote Manager web agent:

> Storage Begin Time (storage_start_time)
> Storage End Time (storage_end_time)

Either use the ACMSMGR utility to set these values, or accept the default values of NOW and NEVER.

## 4.1.20 Remote Manager Web Agent Show Log Commands Display Blank Page

The Show Error Log (ACMSMGR SHOW ERROR) and Show Remote Manager Log (ACMSMGR SHOW LOG) options in the Remote Manager web agent each display a blank log page.

To analyze the source of a problem with the Remote Manager server or web agent, see the web agent log file SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.LOG.

# 4.2 Problems Continued from ACMS Version 4.3

The following known problems have been in effect since ACMS Version 4.3.

## 4.2.1 Incorrect Queue Order with RMS Journaling

When RMS journaling is enabled on an ACMS queue file, elements may be dequeued out of order of insertion. This is due to the way the ACMS$DEQUEUE_TASK service uses the RMS RRL (Ignore Read Lock, RAB$V_RRL bit in the RAB$L_ROP field) to find the next queue element. The queuing service will always attempt to return a queue element or a QUE EMPTY error.

When there are multiple threads in a queue file, there is no guarantee of the order in which queue elements will be dequeued.

## 4.2.2 ADU LINK Aborts with %STR-F-INSVIRMEM or %SYSTEM-F-ACCVIO Error

Linking with a large number of tasks may cause the ADU LINK command to abort with one of the following error messages:

    %STR-F-INSVIRMEM, insufficient virtual memory

or

    %SYSTEM-F-ACCVIO, access violation

This error may be the result of the PGFLQUO parameter being set too low. To fix the problem, increase the size of the PGFLQUO parameter.

## 4.2.3 ACMS SWL Process May be Deleted

Under certain circumstances, the ACMS_SWL process causes an access violation and the process is deleted. This causes ACMS processes that are trying to write information to the Software Event Logger (SWL) log to hang in RWMBX state.

A workaround for this problem is to run the following command procedure as a batch job. This command procedure is not available on your system; you will need to copy it from this document. This batch file monitors the ACMS_SWL every minute (timing can be changed), and restarts the process if it is missing. The batch job should be queued to run under the SYSTEM account (from which SWLPROC is first run).

    $ !***************************************************************
    $ begin:
    $ idx = ""
    $
    $
    $ loop:
    $
    $ new_id = f$pid(idx)
    $ if new_id .eqs. "" then goto restart_swl
    $ full_name = f$getjpi(new_id,"PRCNAM")
    $ if full_name .eqs. "ACMS_SWL"
    $ then
    $    write sys$output "SWL is running, PID is ''new_id'"
    $    wait 00:01:00.00   ! wait 1 minute
    $    goto begin
    $ endif
    $ goto loop
    $
    $ restart_swl:
    $ write sys$output "Restarting SWL"
    $ gosub start_swl
    $ exit
    $!***************************************************************
    $START_SWL:
    $ RUN sys$system:SWLPROC -
        /PRIV=(SYSNAM,SYSPRV,WORLD,OPER,GRPNAM,GROUP)-
        /PROC=ACMS_SWL-
        /QUEUE=20-
        /UIC=[1,4]-
        /PAGE_FILE=15360-
        /PRIORITY=8-
        /DUMP -
        /OUTPUT=SYS$MANAGER:ACMSSWL.LOG
    $ RETURN
    $!***************************************************************

## 4.2.4 EXC Process Can Disappear without Writing Error to SWL or ATR Logs

If the BYTLM quota is set too low, the ACMS EXC process can disappear without recording an error in either the SWL or Audit Trail Report (ATR) log file and without producing a process dump file. The SWL log shows the following error message, from the ACC process, indicating that the EXC process terminated:

    %ACMSACC-E-APPLTERM, EXC process for application <application-name>
    terminated
    -Unknown message - error code 00000000

However, the EXC process does not log an error to the SWL log to provide additional details of the failure.

This behavior occurs when the system runs out of BYTLM quota. To correct this problem, raise the system's BYTLM quota and reboot the system.

To find a suitable higher value for the BYTLM quota, try doubling the current value. If there is still a problem when using the resulting value, monitor the system as you try different lower BYTLM values until you can find a suitable value.

Monitoring the BYTLM value may not be a straightforward process. The DCL command ANALYZE/SYSTEM can report a BYTLM value that is lower than the value set during SYSGEN. Processes can appear to have a lower allocation of buffered I/O pool (BYTLM) than originally defined for the process, and the allocation can appear to vary.

An article in the remedial kit describes how BYTLM is set and reported by OpenVMS. For more details about the BYTLM quota and the accounting of BYTLM, refer to the article, identified in the remedial kit as follows:

    Copyright (c) Digital Equipment Corporation 1996.  All rights reserved.

    PRODUCT:    OpenVMS VAX, All Versions
                OpenVMS Alpha, All Versions

    COMPONENT:  Memory Management

    SOURCE:     Digital Equipment Corporation

    QUESTION:

     Why do processes appear to have a lower allocation of buffered
     I/O pool, BYTLM, than originally defined for the process and why
     does the allocation seem to vary?

## 4.2.5 Free Server Count Not Decremented in Remote Manager

If the minimum number of servers for an application is nonzero and a STOP/ID is done on an ACMS server process, the Remote Manager incorrectly reports the number of free servers. The free server count is not decremented for the server process being stopped.

The number of free servers will be one more than there actually is.

## 4.2.6 Hard Coded Restriction of 4095 Application Starts During an ACMS Invocation

ACMS allows only 4095 application starts during an ACMS invocation. This restriction is hard coded. There is a check in the ACMS Central Controller (ACC) (ACCPACKAGES.LIS) for the package ID to be less than or the same as 4095. This is also used as part of the process name for the Application Execution Controller (EXC). The name is ACMS01EXCxxx000, where xxx is between 0 and FFF (hexadecimal).

## 4.2.7 ACMS Task Debugger May Display Incorrect Information on OpenVMS Version 7.x

On OpenVMS VAX and OpenVMS Alpha Version 7.1, the debugger was changed so that it cached the data. When an EXAMINE command was issued, the cached data was displayed.

In the ACMS environment, there are multiple subprocesses. Each subprocess has its own copy of the debugger, and each copy has the ability to deposit or examine memory. Because of this, the debugger in one subprocess does not know that the memory has been changed by another subprocess and, therefore, displays the incorrect data from cache.

## 4.2.8 ACMS May Fail to Start with %SYSTEM-F-NOSUCHNODE Error

If ACMS is used in a mixed-network environment (Compaq DECnet Phase IV for OpenVMS and Compaq DECnet-Plus for OpenVMS), an ACMS Phase IV DECdtm transaction will fail with a '%SYSTEM-F-NOSUCHNODE, remote node is unknown' error message when it attempts to add the transaction from the DECnet-Plus system.

This problem is a result of the translation of the logical name SYS$DECDTM_NODE_NAME on the DECnet-Plus system. ACMS translates this logical name and returns it to the Phase IV system, which is unable to use the long name.

The workaround is to redefine this logical name to its Phase IV equivalent.

## 4.2.9 Disabling Id and Config Classes Using CLASS=*

It is possible to add a collection record with class of * and a collection state of DISABLED. If the record includes either an entity type or entity name, it overrides the defaults for Id and Config class for that entity.

The applicable processes always populate the Id and Config classes when they start, but subsequent changes to the Config class are not updated.

The following example demonstrates this behavior:

    SPARKS> ACMSMGR SHOW COLL

    ACMS Remote Management -- Command line utility

    ACMS V4.3 Entity/Collection Table Display       Time: 29-SEP-1999 11:51:34.04

     Node         Wt
    Entity
    Collect  Collect
                     Type     Entity
    Name                                                  Class    State
     ---------------------------------------------------------------------
     SPARKS           2        *                           id      enabled
     SPARKS           2        *                         config    enabled

    SPARKS> ACMSMGR SHOW PROC

    ACMS Remote Management -- Command line utility

    ACMS v4.3 Process Table Display                 Time: 29-SEP-1999 11:51:38.27

     Server
    Entity
         Collection States
                                     Process Name -or-
                                     Application.[server_name,
     Node         Type     PID       task_group_name]          Id  Cfg RT  POOL
     ------------ -------- -------- ----------------------------------------------
     SPARKS       acc      202037E0  ACMS01ACC001000            1   1   0   0
     SPARKS       tsc      202037E2  ACMS01TSC001000            1   1   0   0
     SPARKS       qti      20203566  ACMS01QTI001000            1   1   0   0
     SPARKS       cp       20203663  ACMS01CP001000             1   1   0   0
     SPARKS       cp       20203564  ACMS01CP002000             1   1   0   0
     SPARKS       cp       20203565  ACMS01CP003000             1   1   0   0

    SPARKS> ACMSMGR ADD COLL/ENT=EXC/CLASS=*/COLL_S=DISABLED

    ACMS Remote Management -- Command line utility
    Call to add collection on server SPARKS was executed
    %ACMSMGMT-S-SUCCESS, Operation completed
    SPARKS> ACMSMGR SHOW COLL

    ACMS Remote Management -- Command line utility

    ACMS V4.3 Entity/Collection Table Display       Time: 29-SEP-1999 11:52:27.70

     Node         Wt
    Entity
    Collect  Collect
                     Type     Entity
    Name                                                  Class    State
     ------------ -- --------------------------------------------------------
     SPARKS       2   *         *                          id      enabled
     SPARKS       2   *         *                          config  enabled
     SPARKS       3  exc        *                           *      disabled

    SPARKS> ACMSMGR START EXC/APPL=TAPP

    ACMS Remote Management -- Command line utility
    Call to start ACMS application tapp on server SPARKS was executed
    %ACMSMGMT-S-SUCCESS, Operation completed
    SPARKS> ACMSMGR SHOW PROC

    ACMS Remote Management -- Command line utility

    ACMS V4.3 Process Table Display             Time: 29-SEP-1999 11:54:40.82

     Server
    Entity
         Collection States
                                     Process Name -or-
                                     Application.[server_name,
    Node          Type      PID      task_group_name]         Id  Cfg RT  POOL
     ------------ -------- -------- -------------------------------------------
     SPARKS       acc      202037E0  ACMS01ACC001000           1   1   0   0
     SPARKS       tsc      202037E2  ACMS01TSC001000           1   1   0   0
     SPARKS       qti      20203566  ACMS01QTI001000           1   1   0   0
     SPARKS       cp       20203663  ACMS01CP001000            1   1   0   0
     SPARKS       cp       20203564  ACMS01CP002000            1   1   0   0
     SPARKS       cp       20203565  ACMS01CP003000            1   1   0   0
     SPARKS       exc      20201668  ACMS01EXC002000           0   0   0   0
     SPARKS       server             TAPP.TSERVER              1   1   0   0
     SPARKS       group              TAPP.T_GROUP              1   1   0   0

## 4.2.10 Remote Manager May Lose Some Collection Table Update Messages

Under some circumstances, dynamic changes to the collection table are not always communicated to all ACMS processes. When this occurs, the ACMS processes that did not receive the update messages will not be synchronized with the collection table. This is most likely to occur for a short period of time (approximately 1 minute or less) whenever the ACMS Trace process (process name ACMS$TRACE_MON) is started.

The Trace process is started under the following conditions:

- Automatically by the Remote Manager when it starts up
- Automatically by the Remote Manager when it needs to communicate with ACMS and the Trace process is not running
- When the Trace process is started manually using a DCL command
- When the Trace process is started manually using the ACMSMGR START TRACE command.

The workaround is to delay updating the collection table for 30 seconds to 1 minute after the Trace monitor is started.

For example, with the following set of commands, collection messages will be lost if the commands are executed serially with little or no time between commands, as in a command procedure:

    $ ACMS/START SYS
    $ @SYS$STARTUP:ACMS$MGMT_STARTUP
    $ ! WAIT FOR THE rm TO STARTUP
    $ WAIT 00:00:05
    $ !
    $ ACMSMGR ADD COLL/ENT=*/NAME=*/CLASS=RUNTIME/COLL_S=ENABLED

The problem is uncovered by displaying the process collection states, as in the following example:

    $ ACMSMGR SHOW PROCESS

    ACMS Remote Management -- Command line utility

    ACMS T4.3-1  Process Table Display                 Time: 24-SEP-1999 14:45:37.75

     Server  Entity
     Node    Type   PID      Process Name -or-
                             Application.
                             [server_name, task_group_name]  ID Cfg RT  POOL
     -------- ----- -------- ------------------------------------------------
     SPARKS  acc   20200D4F  ACMS01ACC001000                  1  1   0   0
     SPARKS  tsc   20200D51  ACMS01TSC001000                  1  1   0   0
     SPARKS  cp    20200D52  ACMS01CP001000                   1  1   0   0
     SPARKS  cp    20200D53  ACMS01CP002000                   1  1   0   0
     SPARKS  cp    20200D54  ACMS01CP003000                   1  1   0   0

In this example, all processes have the run-time class disabled even though a collection table entry was just added to enable them all.

You can take one of two possible actions. First, you can prevent this situation from occurring by delaying slightly before issuing the command to update the collection table. For example:

    $ ACMSMGR START SYS
    $ @SYS$STARTUP:ACMS$MGMT_STARTUP
    $ ! WAIT FOR THE RM TO STARTUP
    $ WAIT 00:00:05
    $ ! NOW WAIT FOR TRACE TO GET CONNECTED
    $ WAIT 00:00:40
    $ ACMSMGR ADD COLL/ENT=*/NAME=*/CLASS=RUNTIME/COLL_S=ENABLED

Alternatively, you can correct the situation by applying a change to the collection table. This forces the Remote Manager to evaluate and synchronize the collection states of each process, as in the following example:

    $ ACMSMGR SET COLLECTION/ENT=*/NAME=*/CLASS=RUNTIME/COLL_S=ENABLED.

Previous | Next | Contents