December 18, 2001 – Caché Advisory for Tru64 5.1A UNIX

InterSystems has not yet qualified Caché on Compaq Tru64 UNIX version 5.1A. We have found a significant problem with the release and are advising customers not to move to this version until we complete our qualification.

The Tru64 bug we have encountered causes processes to be reported as consuming 100% of CPU. In our instance it was the Caché control process but the potential is there for any process. If you have already deployed on version 5.1A we have workaround available, which is identified as LRS569 and requires a new Caché executable.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

December 3, 2001 – Caché Alert for Release 4.1.x (all platforms)

A problem was recently experienced by one customer that could affect any Cache’ 4.1.x installation running a release prior to 4.1.3 and with databases configured with an 8kb block size. The symptom reported was that many processes were encountering spurious errors (<PROTECT>, <WIDECHAR>,<BLOCKNUMBER>, , core dump) just after a CACHE.DAT was deleted using MSU. This problem may occur if a database is dismounted, which normally causes other running processes to reset an internal structure. In some cases this is not occurring properly. Processes would only be exposed to this problem if they are referencing 8kb databases. We have reproduced this problem, corrected it, and tested the correction.

The correction, identified as JO1493, is incorporated in 4.1.3 and which now supercedes 4.1, 4.1.1, and 4.1.2. All clients running 4.1, 4.1.1 and 4.1.2 must install the 4.1.3 update as soon as possible to avoid this problem.

Dismounting of databases may occur under the following circumstances:

  2. MSU or Control Panel/Database Tab – deleting a database (other functions do not dismount)
  3. DBREST (restores backup files)
  4. Journal recovery on VMS clusters only
  5. $zu(3,directory)

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

November 26, 2001 – Cache’ Server Pages (CSP) Security Improvement

The mechanisms used by CSP and Documatic to serve out data via port 1972 can allow malicious users access to the operating system file structures. We have created a patch to safeguard Cache 4.0 and 4.1 systems. The patch does require that you are running either Cache 4.0.3 or the CSP Service Pack 1. You can download the patch at:

The patch contains an .OBJ only distribution of the %cspServer.rtn file. Load this routine into the %CACHELIB namespace using %RIMF.

You may have to change the protection on the %CACHELIB database:

  1. do ^%MGDIR
  2. do ^PROTECT
  3. for a dataset choose path to Caché install /mgr/cachelib
  4. change the protection on the global ^rOBJ to “RWD”
  5. Exit the utility

To install the patch just:

  1. do ^%CD go to %CACHELIB
  2. do ^%RIMF
  3. point to the patch file after unzipping
  4. Load and compile

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

October 16, 2001 – Database Degradation on IBM AIX

The Worldwide Response Center has recognized a pattern of database degradation occurring at 4 PowerPC sites running Caché 3.x or 4.0 on AIX 4.3.3. The problem has been isolated to Caché’s use of asynchronous IO for database updates. Disabling asynchronous IO, which is the default in 4.0.3 and higher on AIX has proven to eliminate the problem without affecting performance. Thus far, only sites running AIX 4.3.3 have been affected, but we cannot assume that the problem is limited only to that version of AIX. In order to protect your AIX production environment, the WRC is recommending that you install a new or replacement version of Caché that has asynchronous IO disabled.

Caché release 4.0.3 and beyond are not exposed. Sites running 4.0, 4.0.1 or 4.0.2 on PowerPC should upgrade to 4.0.3 or 4.1.1. Kits for these released versions are available on our FTP server or from Order processing



Sites running 3.x of Caché should install a replacement (ad hoc) build of Caché 3.2.3 that is available at:

Note that these files require a password that is available to supported customers only. If you do not have the password you can obtain it by contacting the InterSystems Worldwide Response Center.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

October 2, 2001 – Caché – VMS Cluster Tuning Recommendation


Caché would periodically pause anywhere from a few seconds to a couple of minutes.  It was found through looking at CSTAT reports that the ENQBLK list would grow to having more than 20 entries in it.


Caché makes use of the VMS Distributed Lock Manager to manage access to blocks across the cluster. VMS masters these locks on a specific node and if a benefit is detected in having another machine in the cluster be the lock master then the lock tree is remastered (passed to another node). Caché will pause until the remastering completes. VMS decides to do remastering based on it’s perceived access pattern to the lock. During a benchmark where all machines are equally busy you probably won’t see it. In a production environment where one machine may get busier than another for some periods of time, then you may see it.


A quick gauge of how many Caché locks are in the system can be obtained from SDA. Enter “SHOW RESOURCE/NAME=BLOCK” and look at the “Sub-RSB count”. This is the # of block locks in the Caché lock tree. PE1 should be set to 80%-90% of this on all cluster nodes. On the other hand, it’s probably not a good idea to remaster large lock trees so you could just set PE1 to something like 50000-80000. The exact value would depend on how fast trees can be remastered which probably relates to the version of VMS, the speed of the CPU’s and the speed of the cluster interconnect.

The PE1 SYSGEN parameter is described as the following:

The OpenVMS Distributed Lock Manager has a feature called lock remastering. A lock remaster is the process of moving the lock mastership of a resource tree to another node in the cluster. The node that masters a lock tree can process local locking requests much faster because communication is not required with another node in the cluster. Having a lock tree reside on the node doing the most locking operations can improve overall system performance.
Prior to OpenVMS Version 7.3, lock remastering resulted in all nodes sending one message per local lock to the new master. For a very large lock tree, it could require a substantial amount of time to perform the lock remastering operation. During the operation, all application locking to the lock tree is stalled.   Starting with OpenVMS Version 7.3, sending lock data to the new master is done with very large transfers. This is a much more efficient process and results in moving a lock tree from 3 to 20 times faster.  Only nodes running Version 7.3 or later can use large transfers for lock remastering. Remastering between OpenVMS Version 7.3 nodes and prior version nodes still requires sending a single message per lock.  If you currently use the PE1 system parameter to limit the size of lock trees that can be remastered, Compaq recommends that you either try increasing the value to allow large lock trees to move or try setting the value to zero (0) to allow any size lock tree to move.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

August 6, 2001 – Caché Journal Replay with Transaction Processing Causes Missing Data

InterSystems has fixed a bug that could cause a replay of journal files to result in missing data. The nature of the problem is such that during shutdown data can be written to the database and not written to the journal file – this problem can only exist during a normal shutdown. When using transaction processing, transactions that are incomplete at the time of shutdown will trigger a replay of a portion of the journal file and could lead to this problem. Data at risk for this problem includes data modified by Cache direct, ODBC, MSM-activate, object servers, and job servers. Data modified via terminal connections, normal user background jobs and CSP is not at risk. This problem is present in Caché 2.x, 3.x and 4.0x versions. The fix for this problem is identified as STC276.

The fix is limited to the SHUTDOWN routine. Routines containing the fix for the following versions are available from the InterSystems FTP server. Please contact InterSystems WRC for versions of Caché not listed here:

Caché 3.2.1

Caché 3.2.3

Caché 4.0 and 4.0.x

To install the fix load the routine into the %SYS namespace of your Caché configuration and compile it.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

May 21, 2001 – Caché Direct Client Licensing and Windows Terminal Server

A problem has been corrected with the facility of Caché licensing which allows multiple Caché Direct client connections from a single client system to share a license token. In a three-tier architecture with clients connecting through a Windows Terminal Server (WTS) system to a Caché database server the IP address of the client system would not be passed to the database server correctly. Instead the database server would receive the IP address of the WTS box. This meant that twelve Caché Direct client connections total through the WTS box would be allowed to share one license slot instead of twelve connections from each client sharing a license slot. This problem occurs both with and without Citrix being installed.

This fix is referenced as RAW204 and is introduced in Caché 4.0.1.

A second problem has been corrected – this one occurs in a two-tier architecture. If Caché Direct client connections were attempted from a system with WTS installed the connections would fail. In cconsole.log on the Caché database server the message “Client address invalid in license request” would appear. At the same time, remote clients connecting through the WTS system would connect normally.

This fix is referenced as RAW212 and is not yet in a released version.

A new VisM.ocx file containing both fixes is available. The same file is compatible with both Caché 3.x and 4.x. It can be downloaded from the InterSystems FTP site at:

To install the file simply replace the current VisM.ocx file in \cachesys\bin on the WTS system with the file from the ftp server and register it. The file can be registered from the DOS prompt with the following syntax:

\> regsvr32 VisM.ocx

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

May 10, 2001 – Caché ‘ 3.x Unicode – VMS on EVn chips – Process Loop

InterSystems has recently repaired a problem where a Cache’ process can loop consuming 100% of a CPU. This problem only affects Cache’ 3.x Unicode distributions running on Alpha VMS on SMP systems using EVn chips. If your installation matches all of these criteria a fix is available from InterSystems. Please contact the WRC and reference JO1188. Please have your version string ($ZV) available.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

May 9, 2001 – Caché – Reverse $O may be incorrect with SLM

A problem has been fixed with reverse $O. The problem can appear when working with a global which is Subscript Level Mapped (SLM) and the global name node has a value (i.e. ^glo=123). This problem exists in all currently released Caché versions. A fix is available and is identified as JO1403.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

April 30, 2001 – CSP Service Pack 1

This e-mail is to announce the availability of a critical patch for CSP applications running on 4.0 or 4.0.1. We have identified and repaired some major flaws in the CSP Session mechanism.

Symptoms include:

  1. Non unique session ID generation
  2. Timed out sessions not releasing LU’s or timing out properly
  3. Session corruption where an existing session ran in someone elses’ Session.
  4. Sessions appearing to time out sooner then they should. This is caused by them falling into an older session due to Item 3.
  5. Many minor flaws have been repaired as well. Please consult the readme documentation.

These flaws could critically circumvent the security or stability of CSP based applications. We have placed a kit on the public FTP server:

The kit is in the form of a self-extracting executable. Within the files is a readme with installation instructions, a complete list of all CSP related dev changes including public descriptions and all the required files for Windows and Linux based web servers. Other Web server components can be generated on request.

This kit can be installed on any 4.0 or 4.0.1 system. It contains Object Build 834. It includes changes that are not in 4.0.1 and will not be included in 4.0.2 either. If you patch your 4.0 system to 4.0.1 you will have to re-apply this patch.


This is a critical patch for CSP users only. Object updates will be forthcoming in later 4.0.x maintenance releases.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

April 6, 2001 – Caché 2.x – Day Light Savings Time Update

Based on testing, InterSystems recommends the same course of action for Caché 2.x as recommended earlier today for Caché 3.x and 4.x. That is we recommend a restart of Caché before 2 AM on Sunday, April 8th. This applies to Caché on NT. See the news flash of April 2 for more detail.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

April 6, 2001- Caché 3.x & 4.x – Daylight Savings Time Problem Update

A loophole has been discovered in the recommended workaround for the Caché issue with April 1 Daylight Savings Time adjustment (see news flash of April 2).

The problem is with any Caché process which was started before and running at the time the “Automatically adjust clock for daylight savings time changes” box in the NT control panel was unchecked. The internal time for these processes will jump ahead an hour at 2 AM on Sunday, April 8th, so that they are out of synch with the NT system time. Any Caché process which was started after the box was unchecked will stay in synch with the system time. If Caché has been running since before unchecking the box this means the Caché system processes will be at risk for this problem.

InterSystems recommends restarting Caché before Sunday morning at 2 AM. This will ensure that all Caché processes have been started after the box was unchecked. It is not necessary to restart NT.

It is also not necessary to re-enable the NT automatic adjustment. If you wish to take advantage of the automatic adjustment it can be re-enabled at sometime before Daylight Savings Time ends in the fall.

This announcement applies to Caché 3.x and 4.x. We believe Caché 2.x is exposed to the same loophole but are still confirming this. An announcement will be made shortly concerning Caché 2.x

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

April 2, 2001- Caché – Daylight Savings Time Problem

Caché has been found to be affected by a bug in Microsoft Visual C++ which affects the way that daylight savings time is calculated during years when April 1 falls on a Sunday. The problem is seen in Caché as the Caché time being one hour behind the system time – essentially still reporting EST instead of EDT. This bug only affects the first week of April, starting April 8 Caché and NT time will be in synch again. This problem is present for Cache 2.x, 3.x and 4.x under both Alpha and Intel flavors of NT.

As a workaround for Caché 3.x and 4.x InterSystems WRC suggests disabling the automatic daylight savings time adjustment of Windows NT This can be done through the NT control panel.

In Control Panel => Date/Time => Time Zone tab, uncheck the “Automatically adjust clock for daylight saving changes” box, and click apply.

Then under Control Panel => Date/Time, manually correct the time and click apply.

Caché 2.x needs a different workaround. Use the tzedit program from Microsoft to edit the time zone to be treated as EST. This utility is found in the Windows NT 4.0 Resource Kit.

If you have any questions please contact InterSystems Worldwide Response Center (WRC) at 617.621.0700 or

March 9, 2001 – Caché 3.x/4.0.x fails to start correctly on Windows NT

A problem has been discovered with Caché 3.x and 4.0/4.0.1 installations on Windows platforms. After a number of shutdowns and restarts Caché will fail to start correctly. The cube will appear but will be greyed out and unusable. This problem is fixed by a new cservice.exe program. The new cservice.exe is available for download via anonymous ftp from:

Caché must be shutdown before the new file can be copied in to the cachesys\bin directory replacing the old copy.

If you have any questions please contact InterSystems Worldwide Response Center at 617.621.0700 or

March 9, 2001 – ^%RCMP and ^%RCOPY spanning namespaces in Caché 4.0

A problem was discovered in Caché 4.0 – all platforms – with the routine compare (^%RCMP) and routine copy (^%RCOPY) utilities. When attempting to reference a routine in a namespace other than the current namespace an “[Invalid routine name]” message will be generated. This problem is present only in Caché 4.0. The fix is referenced as STC267 and is available in a new version of the ^%R routine on the InterSystems FTP server at:

Import the new version of ^%R into the %SYS namespace using the ^%RIMF utility. Choose the options to overwrite existing version and recompile.

If you have any questions please contact InterSystems Worldwide Response Center at 617.621.0700 or

February 7, 2001 – Caché maintenance release information on the web

InterSystems periodically releases maintenance releases with a small number of important fixes. The Caché current releases table now includes links to release notes for all Caché maintenance releases. In addition, there is a list of public fixes included in each maintenance release. This list is intended to give a quick overview of fixes that are included in each version, and many are discussed at greater length in the release notes.

Please contact InterSystems Worldwide Response Center at or +1.617.621.0700 if you have any questions.

January 31, 2001 – Getting started with Caché 4.0 for Alpha VMS

A new document is now available for users of Caché 4 and Alpha VMS. This document covers some very useful information about installing Caché on an Alpha VMS system. A highly suggested read.

If you have any questions please contact InterSystems Worldwide Response Center at 617.621.0700 or