The current maintenance kits are Caché and Ensemble 2010.2.2. This document is only part of the available maintenance kit documentation. The full set of documents is available in the docs subdirectory of the product installation directory. Release notes and related material are available as follows:

• Late-breaking information about the release: <install-dir>\docs\cache\en-us\relnotes\cache\readme.1st or <install-dir>\docs\cache\en-us\relnotes\ensemble\readme.1st
• Release notes for 2010.2.2: <install-dir>\docs\cache\en-us\relnotes\cache\relnotes.htm or <install-dir>\docs\cache\en-us\relnotes\ensemble\relnotes.htm
• Release notes for the previous maintenance kits since 2010.2: <install-dir>\docs\cache\en-us\relnotes\cache\prenotes.htm or <install-dir>\docs\cache\en-us\relnotes\ensemble\prenotes.htm (this document)

This document is a historical archive of changes since the original 2010.2 release, but prior to the current maintenance kit. Changes unique to the current maintenance kit are described in relnotes.htm.

This document includes the following sections:

• General Announcements
• InterSystems News, Alerts, and Advisories
• Online Documentation
• Change Reports for the Previous Maintenance Kit

InterSystems advises all users to recompile their application classes as part of the upgrade process so as to take advantage of all the performance improvements as well as other changes that may affect them in this release.

Anyone upgrading from a Caché release at or before 5.0 will need a new license key.

From time to time, InterSystems publishes items of immediate importance to users of our software. These include alerts, mission critical issues, important updates, fixes, and release announcements.

The most current list can be obtained from the InterSystems Web site.

Users should check this list periodically to obtain the latest information on issues that may have an effect on the operation of their site.

As a convenience to our users, InterSystems provides online access to documentation for recent product versions at the InterSystems documentation Web site.

This correction resolves a potential buffer overrun in the function responsible for deriving the path to the Gateway documentation files and templates.

This issue only affects installations with long paths to the Gateway configuration file. Specifically, it applies to installations with paths greater than 64 characters long.

A particular windows DICOM testing tool IQTEST.exe, sends AET names padded with $C(0), which is not recognized by the InterSystems DICOM Adapter. This change corrects this issue.

Note: The problem can be worked around by making both local and remote AET names 16 characters long. This eliminates the padding and allows successful matching

A prior change fixed the logic of replaceSeparators. This correction changes the internal logic in replaceSeparators and replaceArrayLeftToRight to improve the efficiency of the replacement.

The HL7 Message and other EDI VDoc classes have several standard computed properties whose values are drawn from the document content: [type] Name, Identifier, and TypeVersion. This change modifies the way these values are calculated to bypass the ReplaceSeparators() method that was used to normalize the internal structure of these values; instead it uses a simple local $TRANSLATE function call.

This change also reconciled the separators normalization done for Identifier values between SQL and object getter implementations. Formerly the reconciliation was done only in the object getter.

This change corrects errors in the links present on the message resend page in Ensemble.

This change modifies methods CopyFile() and CopyDir() of class %File to take a new (optional) parameter indicating if the file(s) being copied should be deleted (on OpenVMS all versions will be purged) prior to the copy, and makes %EnsembleMgr use this new parameter.

When attempting to run on Windows 2000 or below, the installer now displays an error message and exits.

This change corrects a problem when doing a reverse search using $ORDER in local arrays when the subscript value being searched for does not exist in the array because it was never used or has been deleted.

This change improves the performance of MV BASIC assignments of the form V<-1>=E; by recognizing and treating them as special cases.

In a very rare condition on UNIX® platforms, when

• a job is doing TCP write or send, and
• at the same time, the connection is in the middle being dropped, and
• the job doing the TCP operation is being poked by some other process (for example, to get the job state and etc),

when the connection is dropped, Caché may not detect the connection failure and wait forever for the write completion.

Thic change adds support for unicode files in FileRead() and FileWrite() in CharStream and BinaryStream.

This change allows the D_timestamp to be initialized with a string containing only the date part of the timestamp.

This change enables Java applications using callin-based eXTreme APIs (XEP, MDS, eXTreme JDBC or eXTreme Dynamic Objects) to be interrupted/terminated using SIGINT (i.e. control C) or SIGTERM (kill -15) on UNIX® platforms, without risk of hanging the Caché instance. This change applies only to the non-threaded versions of the eXTreme APIs, and only to UNIX® platforms.

A previous change to the server-side code changed callin so that it does not block these signals, and allows users to set their own handlers for them. However, it required application-level code to explicitly block these signals in any threads that call into Caché (which is not actually possible to do at the Java level); to supply a handler which would call CacheEnd(), in a way guaranteed to be synchronized so that no callin calls were in progress in other threads; and to ensure that there was at least one thread that never called into Caché and didn't block these signals, so that the user-supplied handler would be caught in that thread. If an application did not fulfill these requirements, interrupting it could cause the Caché instance to hang, so that it needed to be shut down, or in worse cases, forced to shut down, or even required to be reinstalled.

The present change transparently implements these requirements within the eXTreme APIs, so that application code is not required to do any signal management, define any signal handlers, or do any explicit cleanup of the Caché connection when one of these signals is caught.

Details of behavior: If the application does supply its own handler for either of these signals, the application's handler will be invoked after the eXTreme handler has terminated the Caché connection. If the application has set either of these signals to be ignored (i.e., to set its action to SIG_IGN or the Java equivalent), eXTreme will not set up a handler, and will leave the signal set to be ignored (in which case, it cannot be used to interrupt the application, and there is no risk that its use will hang Caché). When the application disconnects from Caché, the actions for these signals are returned to their state prior to connecting to Caché; if the application then re-connects to Caché, the actions are again set to the eXTreme handlers.

Note that eXTreme sets SIGINT and SIGTERM to be blocked in any thread that calls into Caché, to ensure that these signals are caught in a thread that is not inside a call into Caché. Once eXTreme blocks these signals in a given thread, it never unblocks them, so it is up to the application to unblock them if it has a reason to do so. The application can safely do so, because eXTreme will re-block these signals in a given thread before each call into Caché. This is probably moot, since Java does not currently provide any API for blocking/unblocking signals in individual threads.

If a transaction is in progress when the application is interrupted, an attempt is made to roll back the transaction. However, it is not possible to guarantee that this attempt will succeed. If it fails, a message is posted to cconsole.log, and the transaction is closed.

NOTE: We do not recommend using Control-C or kill -15 as preferred ways of shutting down production applications, especially not while a transaction is in progress. This change is introduced to allow interrupting applications as a convenience during development and testing, or as a fallback approach if they are hung or sluggish, preventing use of the designed approaches to terminating them. Also note that this change does not make it ever safe or advisable to use kill -9 to terminate any eXTreme application. Signal 9 cannot be caught, ignored, or blocked, so there is no possible way of ensuring that an application can clean up its state properly when killed with signal 9. Because eXTreme APIs connect to Caché within the same process, it is essential to interrupt them, if at all, using signals that can be cleanly caught and handled.

This change corrects an issue introduced in 2010.2 that caused %Delete to fail when the class contained a collection of objects stored in a subnode structure (array collections are stored in a subnode structure by default).

This issue affected only persistent classes using default storage that also contained a collection of objects stored in a subnode structure.

This fixes a problem in $SYSTEM.Encryption.Base64Decode where the process could abort if the string being decoded was at the edge of an internal memory boundary.

This change allows multicore UNIX® systems to use master and slave write daemons to encrypt global buffers from encrypted databases in the WIJ image buffer(s) in parallel. Several slave write daemons will be used so the task can be completed in minimum clock time independent of process scheduling.

This currently is enabled on PowerPC and RedHat Linux 64-bit systems only.

This change resolves a problem where $System.SQL.QueryToTable() could falsely report an erroneous line tag.

This change corrects a defect introduced in 2010.2 that made all the character parameters in linked tables (SQLGateway) fail on 8-bit Caché on Windows.

This corrects an error that reported the value incorrectly for SQLGetInfo option 36, SQL_MULT_RESULT_SETS.

Previously, fixes were made for a special condition in RDO where an EOF (End of File) was not being detected properly when RDO was looking for a single character of data from a column. While this is a defect in RDO, it is a heavily-used application, so a special condition was added to support this situation.

This change consolidates the previous changes to make sure all supported releases have the correct behavior. A request for one character of data with a buffer size of one character will not be null terminated and will not return a truncation error. This only applies to numeric data, and is a work around for RDO EOF issues.

Studio would unexpectedly exit when getting selected text. This has been corrected.

Under certain conditions when available partition memory is low, there could be an error in the symbol table leading to a <SYSTEM> error. This change prevents that situation.

This change corrects an issue in isolated cases whereby $ORDER with a reverse search could occasionally return an incorrect subscript key if the subscript key in the $ORDER function did not exist.

This change corrects a situation where, in an attempt to set the priority of a job that did not supply the priority value, the null argument would be interpreted as an argument of zero.

This corrects a situation where an attempt to use FileCompact would fail if the last allocated block of the file matched the number of blocks in the file.

This corrects a situation where attempting to run FileCompact on mirrored databases would sometimes cause an exit with an access violation, thereby producing a core file.

This corrects a situation where a failed attempt to allocate memory for the subscript-level map table was incorrectly handled.

This change avoids a clean daemon access violation while cleaning dead job. This prevents the clean daemon from being terminated by the <ACCVIO>.

This change fixes a problem that occurs when the lock memory is seriously defragmented. Under this condition, it might take a long time to complete the defragmentation and his could hang the system because some some global cache block might be owned by the job doing the defragmentation.

This change corrects a data corruption issue resulting from writing to a file with compression enabled (/GZIP[=1]) on UNIX® platforms.

A necessary condition for the problem to occur is that the file is opened in stream mode explicitly or implicitly. This means that it was NOT opened explicitly in a format that is mutually exclusive to stream mode, such as fixed-length (/FIXED), undefined (/UNDEFINED), variable record (/VARIABLE), and so on.

Under these conditions, there is an approximately 40% possibility that a 32K output (compressed) file will be corrupted.

This change addresses an issue that could cause unexpected behavior from a process switching journal files. The situation is rare and involves journaling being disabled at a certain stage while the journal switch is being done.

This change addresses an issue on Windows and OpenVMS that could cause the current journal file to expand by a fraction of 64KB (a partial journal block) under conditions of disk space shortage. Consequences of this issue include journal daemon spinning on a CPU lock, and/or the system not recovering from the frozen state, when system is set to freeze on errors.

This fixes a problem in ECP lock recovery when server restart or mirror failover. Some lock nodes might still exist in server's lock table while they don't exist in the clients' lock table.

This change addresses timing issues related to the startup of mirrored systems. Under some circumstances, a mirror configuration failed to recover properly if the backup failed to create the ack channel to the primary and the backup restarted before it could join the mirror.

Under others, the MIRRORMGR job on the primary might exit with a <SUBSCRIPT> error due to a timing issue when a backup connects. The primary would need to be restarted before it would accept any subsequent connections.

A problem has been fixed with instances configured with a journal file prefix where a system which failed to become the primary mirror member after switching to a mirror journal file would switch back to a non-mirror journal file which did not include the configured journal file prefix.

A problem has been resolved where the mirror journal log could get out of sync with the actual journal files on disk. This can happen if a journal file is retrieved but the disk becomes full and because of this the file ends up getting stored in the alternate journal location.

This corrects an issue where, in some instances, a failover attempt could transmit an incorrect SuperServer to its partner.

This fixed a problem on mirror failover while an ECP client connected to the mirror and mounted non- mirrored DBs (e.g. :ds:DBNAME or cachetemp directory path) on the mirror primary. If the two mirror members happened to be in the same machine, then the other member might not be restarted if the cachetemp was mounted.

On a Caché system used as source of shadow data, if the total length of the mounted database paths is near or over 16KB, the shadow copy of a source journal file would miss the path of any source database mounted after the shadow copy is created.

This change addresses that issue. The source of shadowing will be updated with subsequent changes.

During a system shutdown, if any process is "jammed", so that it does not shutdown normally, cforce is supposed to be called to clean up the process. This was not happening, so that the process that was "jammed" was left behind after a shutdown. If the process is one of the WD or JD, restart will fail; but in any case, it could cause shared memory to not be released, so that there is not sufficient shared memory to restart at the desired level.

This change prevents that situation.

This change corrects an error in the cstat self-diagnostic facility. If TRACEPGSHARED was enabled, the cstat self-diagnosis for system hangs (cstat -S option) may falsely detect a job as one of the shared owners of a buffer that the job does not actually own.

A change has been made so that on OpenVMS, multiple versions Caché only preserves one version of the file.

© 2010, InterSystems Corporation. All rights reserved.