November 25, 2002 – Serious Risk with Caché GCOMPACT Utility

A problem with the GCOMPACT utility was found and immediately corrected. When GCOMPACT is used to compact globals in databases with 8K format, database degradation can occur. This problem exists in Caché versions 4.1 through 4.1.9 on all platforms. The correction, identified as TR954, will be introduced in releases 4.1.10 and 5.0. It is also available as an ad hoc correction, in the form of a new set of executables, from the Worldwide Response Center. Our immediate recommendation is to avoid GCOMPACT on databases with 8K formats.

We also encourage all Caché System Administrators to journal and run the Integrity Check periodically, as a best practice.

InterSystems apologizes if this problem has caused you any inconvenience. We have made the necessary improvements to our Quality Development procedures to ensure that this type of problem does not exist in future releases. Please contact the Worldwide Response Center if we can assist you further.

September 26, 2002 – Caché for Windows process shutdown hang

A problem has been identified in Caché process shutdown which could occasionally result in a process becoming stuck just prior to complete termination. This problem only exists on Windows platforms. It has been encountered in Caché 3.x and 4.x. From the perspective of the user the logoff or job termination appears to finish. However, a shell process remains behind which holds a license slot. These shell processes can be recognized in ^%SS in that they always:

  • Have no open devices
  • Are in the %SYS namespace
  • Show no running routine
  • Show no code location
  • Have static (unchanging) CPU and Global counts

An additional symptoms is that utility ^JOBEXAM shows %HALT as the routine being run.

Because the process never releases its license slot it may eventually become necessary to reboot Caché in order to free license resources.

The fix is identified as RJW652 and will be available in a future release of Caché.

Alternatively, an adhoc version containing the fix may be requested for a current Caché maintenance release.

You may contact InterSystems Worldwide Response Center at if you require more information about this advisory.

September 6, 2002 – New evidence logging tool for Caché

Aimed at making the life of Caché VARs, Solution Providers and End Users easier when it comes to collecting technical information for problems, InterSystems has developed a new tool, nicknamed “The Buttons”. The reasoning for the name is based on its extreme ease of use (even for inexperienced users); therefore its activation is almost like pressing a button.

The utility has two options: the “little button” (the basic option) provides most of the information required for InterSystems Technical Support to analyze a medium complexity problem. The data this option generates should be present on every problem logged into InterSystems’ support system. The “big button” (the more advanced option) is sometimes required on complex problems where Support needs more in-depth information about a system’s behavior. It includes all the information contained in the basic option and adds a lot more. All the information is stored in a single HTML-formatted file.

The whole process should not take more than 5 minutes to complete. The Buttons tool is written in Caché ObjectScript and is available for all Windows platforms (9x, ME, NT, 2000 and XP), all brands of UNIX supported by Caché and OpenVMS. It runs on all Caché versions starting from 3.2.1 on supported Operating System platforms. It does not run on Caché 2.x.

For the rare instances where Caché is completely down, making it impossible for the Caché ObjectScript-based Buttons to run, there are Operating System-level scripts that can be run to collect all the system information available outside of Caché. These scripts are an integral part of the Buttons tool and are available for 32-bit Windows (NT, 2000 and XP), several UNIX platforms and OpenVMS.

Once the report has been run you may zip the output up into a single file and then submit the report, along with a problem description using the WRC. Just login using your customer account and then “Open New Problem”. Once the problem description has been saved you will see a link called “Add File” in the problem detail view. Clicking on this will bring up a screen that allows you to upload a file over HTTP. This will “tie” your report file to the problem. This can also be done to an existing issue. This process can take a long time and for very large files greater than 5 MB it may be more efficient to FTP them to the machine and just provide the name of the file in the problem description. If you are under maintenance and don’t have an account to use the WRC feel free to e-mail and we will gladly assist you.

You may contact InterSystems Worldwide Response Center at if you require more information about this advisory.

September 5, 2002 – Caché 4.0.3 Garbage Collector Failure

Two sites have recently encountered a rare problem that causes the Garbage Collector system process to fail with an access violation during expansion of a multi-volume database. This problem exists for all Caché platforms but only for Caché 4.0.3.

Possible effects of this problem are database degradation and <DISKHARD> errors for user processes.

Sites running Caché 4.0.3 are advised to upgrade to Caché 4.0.4 or Caché 4.1.6. If an upgrade is not possible an adhoc build of 4.0.3 can be produced. The fix for this problem is referenced as JO1510.

You may contact InterSystems Worldwide Response Center at if you require more information about this advisory.

August 12, 2002 – DSM to Caché Conversion utility

Two problems have recently been identified and fixed with the DSM to Caché conversion utility ^%DSMCVT. These issues affect all currently released versions of Caché on all platforms.

The first problem only occurs when using ^%DSMCVT to import globals from DSM to Caché which have nodes containing data longer than 255 bytes. The resulting globals in Caché may be missing data. Extra globals may also be created which have invalid names. The fix for this problem is referenced as SAP022.

The second problem only occurs when using ^%DSMCVT to import globals which are using Subscript Level Mapping (SLM) in Caché. The import may not follow the SLM correctly so that global nodes can be placed in incorrect Caché databases. The fix for this problem is referenced as JO1577.

Both fixes are available from InterSystems Worldwide Response Center (WRC) and require a new set of Caché executables. If these fixes are needed, please be prepared to provide the Caché version ($ZV string) as well as the OS version.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 or if you require more information about this advisory.

August 7, 2002 – Caché process hang in VMS cluster

A problem has been discovered that can lead to Caché process hangs on non-master nodes in an OpenVMS cluster environment. The problem affects all 4.1.x versions of Caché. It occurs once database activity has resumed after quiescence, which is most commonly during backup.

In a Caché cluster environment DCP is used to obtain locks on a global in a cluster mounted database. When Caché is quiesced (using switch 10 or 13) processes hang until the quiescence is cleared – this is expected behavior. Processes requiring DCP (for locking) may go into a network hardening (NH) state – this is also expected behavior. When quiescence is cleared the processes should exit the NH state and continue normal activity. If the problem described in this alert occurs the processes never exit the NH state and access violations can occur on non-master nodes of the cluster. Processes in the NH state can be identified by the “NH” appended to their state in ^JOBEXAM or the Control Panel.

ISC is working to diagnose and fix this problem. In the meantime it is recommended that sites implement the following workaround to avoid this problem: modify the value of the network timeout in Configuration Manager -> Advanced Tab -> Network -> Timeout. It is necessary to restart Caché for this change to take effect. A dialog box incorrectly indicates that the change can be activated without restarting. This value should be set to longer than the longest period that a system is expected to be quiesced. In most cases 30 second should be sufficient.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 or if you require more information about this advisory.

August 6, 2002 – Caché Security

A customer reported a concern about security that may be of concern to Caché sites utilizing DCP (Distributed Cache Protocol) to network Caché systems. This affects all current Caché releases, but not DSM, and only if Caché is configured to utilize DCP. This alert describes the issue and suggested safeguards. We are grateful to the customer who brought this to our attention and we hope this is of interest to you.

Processes started via the remote job command, using DCP, are started on the remote system with full privileges. The security concern is that such a process is not prevented from calling out to the OS level in a fully privileged mode. In this situation, the concern is realized only if the application routine on the remote system provides arbitrary access to the OS, via $ZFunction for example.

This concern can be resolved easily by disabling the ability to start remote jobs through configuration manager -> Advanced Tab -> Remote Jobs. This parameter controls whether remote jobs can be started on the server where the parameter is set. Be aware that disabling remote jobs also disables the ability of the client to do a global display of namespaces with remote mapping.

Since the remote job command can only invoke compiled routines on the target system, an alternative workaround is to secure application directories to prevent unauthorized users from saving routines.

On Windows platforms only it is possible to eliminate the concern by not starting Caché as administrator. The remote jobbed process takes its privileges from the Caché network demon and the network demon takes it’s privileges from the account that starts Caché.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 if you require more information about this advisory.

August 6, 2002 – CSP hooks into Dreamweaver/UltraDev/MX

We have placed on our public ftp server at a zip file called containing the mxp extension files for plugging CSP hooks into Dreamweaver, UltraDev or Dreamweaver MX. These hooks will work with Caché 4.x and all the current Caché 5.0 betas. These files will be included in future Caché 4.1.x maintenance releases. This addresses problems users have had with the extensions running under UltraDev or MX.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 or

July 16, 2002 – Journal switching resets alternate journal directory

A problem has been discovered with the journal switching mechanism INT^JRNSWTCH() which is used by Caché’s ^BACKUP utility as well as the BACKUP^DBACK entry point for automated backups and the JRNSWCH^JRNUTIL() API. The result of this problem is that the alternate journal directory is reset to point to the same location as the primary journal directory, leaving the system vulnerable to hangs if the primary journal directory fills up or encounters an error. This problem affects all current versions of Caché on all operating systems. If you have previously defined an alternate journal directory you can check the value of ^%SYS(“JOURNAL”,”ALTDIR”) in the %SYS namespace to determine if your backup/journal switching strategy leads to this problem. ^%SYS(“JOURNAL”,”ALTDIR”) should contain the path to your alternate journal directory, not the primary journal directory.

A patch to the ^JRNSWTCH routine, identified as HYY660, is available here:

Caché 4.x

Caché 3.2.x

This patch consists of one routine ^JRNSWITCH and can be restored into the %SYS namespace using the Caché Explorer or ^%RI.

The patch changes the behavior of INT^JRNSWTCH(curdir,altdir) such that if altdir=”” or is undefined or null it is set to the current alternate journal directory rather than the primary journal directory.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 or

July 9, 2002 – TP rollback problem with 8K Databases

InterSystems has discovered and fixed a problem with transaction processing in 8K databases. In some cases a kill that is part of a transaction will not get rolled back when a TROLLBACK occurs.

The necessary conditions for this problem are to be using transaction processing on an 8K block database and to be running a Caché 4.1.x version prior to build 185 (Caché 4.1.6 is build 184).

The fix is available from InterSystems WRC and is referenced as TR917.

You may contact InterSystems Worldwide Response Center at: 617.621.0700 or

June 13, 2002 – Recommendation for Caché sites with custom spin-count threshold settings

In the past, InterSystems staff may have suggested custom settings for spin-count thresholds for very specific customer situations. These thresholds can only be changed with help from InterSystems support staff (WRC) or the Performance Team in Development. Moreover, the default setting for spin-count thresholds was generally appropriate.

As these clients have moved to Caché 4.1.x from older releases, there is growing evidence that spin-count adjustments are no longer necessary and, in some cases, adversely affect performance. Due to radical performance and scalability improvements in 4.1.x, the performance characteristics have changed and we are finding that the default threshold settings in Caché 4.1.x are more appropriate.

We recommend that you discontinue use of custom spin-count threshold settings. Alternatively, you may contact InterSystems Worldwide Response Center at 617.621.0700 or for reevaluation of these settings on your system.