Services
& Support

Support Alerts 2004


December 6 , 2004 – Database Corruption With More than 256 Databases

InterSystems has identified a defect in Caché that could lead to database corruption.

This defect affects all currently released Caché 5.0.x versions. It is present on all platforms EXCEPT OpenVMS and Tru64 UNIX.

Necessary conditions for encountering this problem are:

  1. A Caché instance that mounts more than 256 databases.
  2. Use of Caché online backup (full, cumulative, or incremental)

When Caché online backup (full, cumulative, or incremental) is run on an instance of Caché that has more than 256 databases mounted, the likelihood of corruption occurring is high. The corruption may not be obvious at the time of backup. The results of this problem can include any of the following: corrupted databases, <DATABASE> and <DATABASE MAP LABEL> errors, system hangs, failure of backup, and corrupted backups/restores.

If both necessary conditions are met, InterSystems strongly recommends the following steps:

  • Installation of the correction identified as RJF028
  • A Caché integrity check of databases mounted by the at risk instance
  • An alternate backup strategy until the correction is in place, this could be running backup with 256 or less databases mounted.

The correction, RJF028, is targeted for Caché maintenance kit 5.0.13 scheduled for release in January 2005. The correction can also be requested as an Ad Hoc kit.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


November 19, 2004 – SQL UPDATE statement and %CacheStorage

InterSystems has corrected a problem where an SQL UPDATE statement might not save the data correctly if the class used %CacheStorage and had about 185 fields in the table all stored on the same node in the data (master) map.

The defect is in Caché 5.0.5 and all later versions.

The correction for this defect is identified as DPV2275 and is targeted for release in maintenance kit Caché 5.0.13. It can also be delivered in an Ad Hoc distribution.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


November 4, 2004 – CacheConnect.dll Detected as Spyware

InterSystems has discovered that some tools for detecting spy software are incorrectly reporting a Caché component as a risk.

This advisory applies only to Windows based systems.

The tool reporting this risk is Spybot – Search & Destroy, though other similar tools may make the same mistake.

Two items are reported:

  • CacheConnect.dll
  • The related Windows registry entry HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows\CurrentVersion\SharedDlls\CacheConnect.dll

InterSystems’ policy is to never either obtain information from customers systems without their knowledge or download software to customer systems without their knowledge. The CacheConnect.dll component is not used for either of these purposes.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


October 20, 2004 – Caché and Symbolic Links on UNIX/Linux

InterSystems has identified several cases of database degradation that have been traced to the use of Symbolic Links on UNIX and Linux systems. This problem has been observed on IBM AIX and Red Hat Linux platforms, but it is likely that other UNIX and Linux platforms are susceptible. All Caché versions are at risk.

This issue is being investigated but until a solution is available InterSystems recommends that all symbolic links used to reference directories containing cache.dat files be deleted.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


October 4, 2004 – CacheSQLStorage in Caché 5.0.11

InterSystems has corrected a problem with SQL Code generation that would cause <UNDEFINED> and <SUBSCRIPT> errors when querying a table with CacheSQLStorage.

The Defect is only in Caché 5.0.11 and will happen on all platforms. This defect will cause most SQL statements to fail if they are based on CacheSQLStorage.

There are three changes needed to correct this defect. They are identified as DPV2278, DPV2283 and PVA070. The corrections are included in the upcoming maintenance kit Caché 5.0.12 scheduled to be released during the first half of October. They may also be requested as an Ad Hoc distribution.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


October 1 , 2004 – Caché Clustering in OpenVMS

InterSystems has corrected a defect with shared database clustering that can cause serious problems with performance and recovery.

The defect is present only in Caché 5.0.10 and 5.0.11. It is present on OpenVMS platforms only and is only a concern in clustered environments. The main effect is that when Caché is shutdown or fails on the master node cluster recovery may take an extremely long time (15 minutes or more) or possibly not complete at all. The defect can also cause database updates to pause for long (20 second) periods during normal operation.

Another symptom of this defect is that the following spurious error may appear in the cconsole.log immediately prior to the completion of shutdown. This message is a result of the defect and does not indicate degradation has occurred.

*** SERIOUS CACHE ERROR THAT COULD CAUSE DATABASE DEGRADATION HAS OCCURRED. TO PREVENT DEGRADATION THE WRITE DAEMON WILL NOT RUN ***

Please note that there are other circumstances unrelated to this defect that may cause this message to validly appear in the cconsole.log.

There are two changes needed to correct this defect. They are identified as SML475 and GK324. The corrections are included in the upcoming maintenance kit Caché 5.0.12 scheduled to be released during the first half of October. They may also be requested as an Ad Hoc distribution

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


August 16, 2004 – Advisory, Solaris 9 Patch Addresses Poor Caché Journaling Performance

InterSystems has found that Caché journaling performance is impacted by a bug recently fixed by Sun Microsystems for the Solaris 9 Operating System.

This advisory applies to any version of Caché running on the Solaris 9 OS without the documented patch.

The Sun Microsystems BugID is 4336082 and the fix is delivered in Patch-ID 112233-12.

A simple test can be run from the Caché command line before and after applying the patch to illustrate the performance improvement provided by the patch:

Assuming that ^scratch is an unused global and is journalled and that there is enough disk space to run this test.

USER>s str="",$p(str,".",174)="." w $l(str)
174
USER>s beg=$zh f i=1:1:10000 ts  s ^scratch=str tc  i $zu(78,29)

USER>w $zh-beg

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


August 2, 2004 – Caché 5.0.x on OpenVMS and 2 GB Buffer Pools

InterSystems has addressed an issue that can cause individual Caché process to exit with an access violation and lead to the Caché instance hanging. This problem can only occur when a Caché instance has 2GB or more of global buffers configured.

This issue affects all Caché 5.0.x kits and only affects Caché on OpenVMS.

If this problem occurs an error similar to the following entry may appear in the cconsole.log file:

*** SERIOUS CACHE ERROR THAT COULD CAUSE DATABASE DEGRADATION
HAS OCCURRED. TO PREVENT DEGRADATION THE WRITE DAEMON WILL NOT RUN ***
ERROR: <HALTED> (55) FILE: 4 (_DSA2:[DATABASE.PRD]) GLOBAL: PAT PID: 2874
ERROR MODULE: SALEM$DNFS4:[*.common.src]crtnbuf.c;1,line 2132

Please note that this message does not indicate that database degradation has occurred, only that the Write Daemon has been stopped to prevent degradation.

InterSystems strongly urges that all Caché 5.0.x instances running on OpenVMS be configured to use less than 2GB of global buffers until the correction for this issue is installed.

The change to address this issue is identified as JO1811 and is targeted for release in maintenance kit 5.0.11 at the end of August. This change may also be requested in an Ad Hoc distribution.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


June 15, 2004 – $SORT Functions Return Incorrect Values – Journal Restore Affected

InterSystems has corrected a defect in sorting using $SortBegin and $SortEnd that could return incorrect data. This defect affects Caché only on 64 bit platforms, see the table below for all at risk Caché/OS combinations.

Even if application code does not utilize the $Sort functions, data values can still be at risk through CacheSQL or journal restore.

  • Beginning with Caché 5.0.5 the $Sort functions are used by journal restore.
  • CacheSQL makes use of the $Sort functions to optimize some operations.

The following Caché/OS combinations are at risk:

OS Version(s)

Caché Version(s)

Open VMS 7.x Caché 5.0.x
Tru64 5.1x Caché 4.1.x, 5.0.x
AIX 5.1 & 5.2 (64-bit only) Caché 5.0.x
HP-UX 11i (64-bit only) Caché 4.1.x, 5.0.x
HP-UX 11i v2 (64 bit Itanium) Caché 5.0.x
Red Hat Linux (Intel) AS 3.0 (64 bit for Itanium) Caché 5.0.x
Sun Solaris (Ultra SPARC) 8, 9 Caché 4.1.x, 5.0.x
SuSE Linux (Intel) Enterprise Server 8 (64 bit for Itanium) Caché 5.0.x

The problem is that values processed by the $Sort functions may be incorrect. As an example:

s rc=$sortbegin(^testsort)

s ^testsort(0)=9876543211-9876543210

s rc=$sortend(^testsort)

After $sortend returns success, ^testsort(0) would have an incorrect value (something other than 1).

The correction for this defect is identified as HYY932 and is targeted for release in maintenance kit Caché 5.0.9 at the end of June.  It can also be delivered in an Ad Hoc distribution.

As a temporary workaround for the Journal Restore problem the following routine can be downloaded from the InterSystems FTP site and installed in the %SYS name space. This routine is compatible with Caché 5.0.5, 5.0.7 and 5.0.8 and addresses only the journal restore issue.

ftp.intersystems.com/pub/cache/patches/jrnrestb-nosort.rsa

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center.


May 17, 2004 – Caché Configuration Manager Journaling Option Incorrect

InterSystems has corrected a defect with the Configuration Manager that leads to unintended journaling results. This defect exists in Caché 5.0.3 and later versions and for all platforms and operating systems.

The affected Configuration Manager option is:

Configuration Manager -> Advanced -> Miscellaneous ->Exclude ^z* and ^Z* globals from being journaled

In versions where this defect is present, modifying the option leads to the opposite of the expected behavior.

The defect is in the Configuration Manager. This means that upgrading a pre-Caché 5.0.3 system to Caché 5.0.3 or higher will not change the existing behavior. In order to be affected by this defect it is necessary to modify this configuration parameter after upgrading to Caché 5.0.3 or higher.

Until receiving the correction for this defect it is recommended that modifications to this option be made by updating the configuration file (.cpf) directly to avoid being misled by the Configuration Manager. The corresponding field in the .cpf file is JournalZGlob in the [Miscellaneous] section. If this field is set to 0, all globals beginning with the letter ‘z’ or ‘Z’ will be explicitly excluded from journaling. If set to 1, globals beginning with the letter ‘z’ or ‘Z’ will be journaled according to normal journal rules. Note that the meaning and use of this field is unaffected by the defect documented here, only the use of the Configuration Manager to edit this field is incorrect.

The correction for the Configuration Manager is identified as CFL962 and is targeted for release in the Caché 5.0.9 maintenance kit at the end of June. It can also be requested as an Ad Hoc distribution.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


May 3, 2004 – Restoring a Caché Full Backup: Wasted Space

InterSystems has corrected a defect in backup restore that can cause wasted space in a database and in rare cases cause Caché to hang.

This defect is present in all currently released Caché 4.1.x and 5.0.x versions and affects all supported OS and platform combinations.

Necessary conditions for the problem to occur are that a Caché full backup be restored into a larger, pre-existing database. This defect causes all additional blocks in the larger pre-existing database to be unusable, meaning there will be wasted space in the resulting database. Incremental backups are not susceptible to this problem.

In rare cases, this defect can also cause processes to receive <DATABASE MAP LABEL> errors when accessing the restored database. These errors can hang Caché.

This defect can be avoided by choosing the option to have the Caché restore process create the database file instead of using an existing file.

The correction for this defect is identified as HYY921 and is targeted for release in maintenance kit Caché 5.0.9. It can also be delivered as an adhoc.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


April 28, 2004 – Insufficient Memory Configuration: GMHEAP

Several issues have been reported to InterSystems’ Worldwide Response Center that are the result of under-configuration of ‘Generic Memory Heap’ (GMHEAP). GMHEAP is a Caché Configuration Parameter that can be modified in Configuration Manager -> Advanced -> Memory -> Generic Memory Heap.

Several enhancements in Caché 4.1 and Caché 5 result in increased use of GMHEAP compared to earlier versions. As a result, issues can be encountered after upgrading to Caché 5.0.x versions and to a lesser extent after upgrading to Caché 4.1.x versions. The issues can occur on any supported operating system or hardware.

Problems related to insufficient GMHEAP include but are not limited to:

  • Inability to support the licensed number of users
  • Lock Table not large enough or can’t be expanded
  • Caché failing to start
  • Inability to compile a large number of object classes at once
  • Inability to have a desired number of datasets, namespaces, routine mappings, subscript level mappings (SLM), or locale tables

InterSystems has developed the utility ^GMHEAPREQ that will provide a minimum recommended value based on your active configuration (.cpf) file. The minimum recommended value produced is for Caché 5.0.x requirements and since Caché 4.1.x requirements are slightly less the value also serves as a minimum for 4.1.x. Regardless of the Caché version the utility is run for (it is compatible with Caché 3, 4 & 5) it will produce a minimum value for Caché 5.0.x.

This utility only reports a minimum recommended value. It does not change any parameter settings within your configuration.

We recommend that this utility be run prior to upgrading to Caché 4.1.x or 5.0.x versions and GMHEAP be increased to the minimum recommended value.

The utility is available on our FTP server. The file name is gmheapreq.rsa.

ftp://ftp.intersystems.com/pub/cache/patches/gmheapreq.rsa

To install, please use %RI from within Caché programmer mode. It can be installed into any namespace. To run, issue D ^GMHEAPREQ and it will display the recommended value. For example:

USER>D ^GMHEAPREQ

This utility will examine you current/active configuration file, and will provide a minimum recommended value.

*** Using configuration file name:
$1$DKA300:[CACHESYS.NEELIX.C50]CACHE.CPF

Current GMHEAP size = 2816 KB
Recommended minimum GMHEAP size: 3199 KB

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


April 27, 2004 – Caché Backup, failure during restore of large archive

InterSystems has corrected a defect in Caché backup that could result in inability to restore from a backup archive. This defect exists in all Caché 4.1.x and later versions and for all platforms and operating systems.

This problem can only occur in backup archives with 16 or more databases. The likelihood of encountering this problem is low but increases with the number of databases in an archive. Existing backup archives can be checked with the following procedure without actually restoring any databases:

Use option 3 of the ^BACKUP utility “Restore Selected or Renamed Directories” and mark every database with an “X” to be skipped. If the restore reads through the entire archive without a “missing blocks” error then the archive is not affected by this defect.

Please note that a clean check of one archive with the above procedure does not guarantee that the next backup will not encounter the problem.

The correction for this defect is identified as LRS757 and is targeted for release in maintenance kit Caché 5.0.8. It can also be delivered as an adhoc.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


April 22, 2004 – Caché processes incorrectly removed on Windows

InterSystems has corrected a defect that can cause Caché processes to be incorrectly deleted from Caché. This defect is present on Windows platforms only and applies to currently released Caché 5.0.x versions.

Only processes that call out of Caché using $ZF() and modify their Windows security profile are at risk of encountering this defect. The likelihood of encountering this problem is low but the effects could be severe including causing Caché to hang. To determine if your system has encountered this defect check the cconsole.log file for a message indicating that a dead process has been “cleaned”:

04/20-17:28:33:734 ( 4184) cleaned dead job, pid: 4224

If the PID that has been cleaned still exists as a Windows process then the problem may have occurred. Please note that the “cleaned” message is evidence that normal Caché functionality has been triggered to protect against dead processes, it is not, by itself, evidence of the defect. Also, please remember that PIDs are quickly reused in a running Windows system so unless you find the PID in existence at the Windows level very shortly after the timestamp on the “cleaned” message you have likely not encountered the defect.

The correction for the defect is referenced as JO1799 and can be delivered in an adhoc build.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


March 10, 2004 – Updated Security Alert – %template

This alert contains updated instructions. If you followed the instructions from the March 9th alert, you will still need to follow the updated instructions below.

InterSystems has encountered a critical issue with a number of Caché classes which could allow an attacker to access data on a Caché server. This vulnerability is in classes that are not required on production systems and are only used during development. Removing them will have no impact on a production system.

These classes are included in all releases of Caché 5.0.

InterSystems recommends you remove them by using Terminal.  Once connected using Terminal, enter the following commands:

zn “%cachelib”
do $system.OBJ.DeletePackage(“%template”, “ps”)

In addition please remove all .csp files from the following directories (if installed):

\Dev\studio\templates
\Devuser\studio\templates

of your Caché installation (default: cachesys).

InterSystems is working on a solution to remove this vulnerability from future versions.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


March 9, 2004 – Security Alert – %template

This alert has been updated. Please see the alert issued March 10, 2004.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


March 5, 2004 – Updated Security Alert – XML.Utils.SchemaServer

This alert has corrected information.

The second option has been corrected to read

2. From Terminal, enter the following commands:

zn “%cachelib”
do $system.OBJ.Delete(“%XML.Utils.SchemaServer”)
The complete and corrected security alert is listed below.

InterSystems has encountered a critical issue with a Caché class which could allow an attacker to access any file on a Caché Server. This vulnerability is in a class which is not required on production systems. This class is included in all releases of Caché 5.0.

InterSystems recommends that this class be removed using one of the following methods:

1. From Explorer
select “Namespaces–>%CACHELIB–>Classes”
Right-click on “%XML.Utils.SchemaServer”
select “Delete”

or

2. From Terminal, enter the following commands:

zn “%cachelib”
do $system.OBJ.Delete(“%XML.Utils.SchemaServer”)

InterSystems is working on a solution to remove this vulnerability from future versions.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


March 4, 2004 – Backup .cpf file versions were deleted on VMS

InterSystems has corrected a defect that causes backup versions of the .cpf file to be deleted when the configuration is edited with the Configuration Manager. This problem affects Caché 5.0.5 for OpenVMS only.

The correction for this defect is identified as CFL1011 and will be present in all post Caché 5.0.5 versions. An updated routine containing the correction is available on the InterSystems FTP server at ftp://ftp.intersystems.com/pub/cache/patches/

WPRIM_CFL1011.OBJ – Contains routine %Wprim.OBJ

Please use binary mode file transfer to download the routine and load the routine into the %SYS namespace using ^%RIMF

If you have any questions regarding this, please contact InterSystems Worldwide Response Center.


March 3, 2004 – HIGH^%PRIO on OpenVMS (Alert Superseded)

This alert supersedes the alert dated February 27, 2004  – “HIGH^%PRIO on OpenVMS”

InterSystems has corrected a defect, which results in calls to %PRIO setting process priority incorrectly.

The information in this alert only applies to Caché running on OpenVMS.  It applies to Caché versions 5.0.2 through 5.0.5.

On OpenVMS, priority is based on the base priority of the process.  Base priority of a process is the user’s base priority when the job is started. The base priority for a Caché user process under OpenVMS is usually 4.  The defect causes priority to be set as documented in the second column below.

<tdwidth=”15%”>NORMAL^%PRIO

5.0.2 – 5.0.5
Incorrect Behavior
Temporary Patch Routine Correct behavior
LOW^%PRIO No Effect on Priority No Effect on Priority No Effect on Priority
Priority = 0 Priority = 4 Reset to base priority
HIGH^%PRIO Priority = 2 Priority = 6 Base priority +2

The correction to this defect is identified as SAP150 and will be present in all post 5.0.5 versions of Caché.  It can also be ordered as an adhoc that will require installation of a new Caché executable.

On a system that is using a base priority of 4 the routine listed below can be used as a
temporary patch, however on a system that is not using the default value the routines can result in the calls (LOW, NORMAL and HIGH) setting priority incorrectly relative  to the base.  If a new Caché executable is installed to implement SAP150 it will override the behavior of the patch routine so that the patch routine does not need to be replaced.

The temporary patch routine is available on the InterSystems FTP server at
ftp://ftp.intersystems.com/pub/cache/patches/

PRIO.INT          – versions 5.0.2 – 5.0.5

Download the file in ASCII mode and use %RI to input the corrected routine to the %SYS namespace. This should be done at time when application processes are not running on the system.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


March 3, 2004 – Security Alert – XML.Utils.SchemaServer

This announcement has been corrected. Please see March 5, 2004 announcement above.


February 27, 2004 – HIGH^%PRIO on OpenVMS

This Caché News Alert has been superseded by the March 3 Caché Alert

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at support@intersystems.com.


February 24, 2004 – Global Mapping and %SYS Namespace

InterSystems has corrected a defect that causes user-defined global mappings in the %SYS namespace to be ignored. This issue only exists in Caché 5.0.5. It affects Caché 5.0.5 on all platforms and operating systems.

Globals referenced (read or written) from %SYS which have been explicitly mapped to an alternate location via a user-defined global mapping, will instead be resolved to the CACHESYS database. The result is that the application may be unable to find old data in these globals, and new data added will be stored in a different location (CACHESYS database). This problem exists in Caché 5.0.5 only and affects all platforms.

The correction for this defect is identified as CFL981 and will be present in all post Caché 5.0.5 versions. An updated routine containing the corrections is available on the InterSystems FTP server at ftp://ftp.intersystems.com/pub/cache/patches/

adhoc1296_STU1.rsa – contains the updated routine
adhoc1296_readme.txt – contains detailed installation instructions

Please use ASCII mode file transfer to download the routine. The routine can be loaded on Caché 5.0.5 for any platform.

If you have any questions regarding this, please contact the InterSystems Worldwide Response Center at: support@intersystems.com.