The following release notes are available in the \Docs subdirectory of your installation:

• Late-breaking information about this kit: \relnotes\cache\readme.1st
• Release notes for this kit: \relnotes\cache\relnotes.htm (this document)
• Release notes from prior kits: \relnotes\cache\relnotes.htm

This document provides a list of the changes between Caché 5.2.2 (Ensemble 4.0.1) and Caché 5.2.3.

Topics include:

• General Announcements
• InterSystems News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• Change Reports for This Maintenance Kit

Since this maintenance kit is based on Caché 5.2, anyone upgrading from Caché 5.0.x to 5.2 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 Website.

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 Website. From the home page choose the Caché tab, and on the Downloads menu, select Documentation and Help Updates or follow this link.

To help you assess the impact of this maintenance kit on your applications, the remaining topics in this document describe each modification in detail. The format for this description is a Change Report.

Each Change Report provides a table with the following information:

• Likelihood: The probability that a user on the affected platform will encounter this issue.
• Risk: An assessment of how likely this change is to introduce additional issues into the application environment.
• Ad Hoc: Whether this change has previously been deployed in an ad hoc release and successfully used by customers in production.
• Enhancement: Whether this change provides new features or capabilities for the product.

The %CSP.Session:Login method in 5.0.x took a username, password and type where the type determined what sort of login to perform.

The use of this type was removed in 5.1 due to the new security model. This has lead to further problems where customer applications wish to trade CSP licenses to user X without having this user 'X' setup in the Caché security database.

To allow these applications to continue to work if you pass 1 as the type parameter to the Login method, CSP will now trade licenses without calling the login code and so restore the behavior to what it was in 5.0.x for this parameter value.

This change properly declares an internal variable so it no longer erroneously overrides one present in the environment.

HP has made some internal changes to the INSTALL program and the version shipped with OpenVMS 8.3 on Itanium (only Itanium, not Alpha) will not work with Caché. A corrected version of this program and instructions on how to install it are available from the ITRC:

as: VMS83I_INSTAL-V0100
at: http://www2.itrc.hp.com/service/patch/mainPage.do

HP predicts that this will be available by 11/7/06.

The /shared=address parameter consumes pages controlled via the IMGREG_PAGES SYSGEN parameter. If you get messages similar to:

%INSTALL-I-NONSHRADR, image installed ignoring '/SHARE=ADDRESS' 
-INSTALL-E-NOSHRADR, insufficient memory for shareable address data.

increase the IMGREG_PAGES parameter via AUTOGEN feedback or by editing MODPARAMS.DAT and running AUTOGEN.

Background:

On OpenVMS, cache.exe is now installed with "/shared=address" rather than simply "/share". This is required starting with OpenVMS 8.3 because cache.exe is both a shareable image to support callin applications. and a "main" program which is executed directly. In this case, "/shared=address" is required to instruct INSTALL to create the global section for the address relocation data.

Caché was reporting the amount of memory allocated as negative on very large memory configurations. The calculation has been corrected.

This change does all buffer element calculations using 'ulong' to prevent overflow when dealing with large memory configurations.

The attempt to allocate large buffer pools on UNIX platforms (~2GB) caused startup to fail due to an internal error in calculating the total number of bytes to allocate for shared memory.

This has been corrected.

As part of 5.2 ECP server optimization, the ECP server was changed so that it might not deliver the answer as soon it completes during light loads. The delay delivery could be as long as one second.

This has been corrected.

The daemon jobs types were not initialized in the proper order. As a result, daemons might hang around on system failure because they were not cleaned up properly. For example, the ECP server reconnection daemon might not go away when the security subsystem disables the ECP service-connections from a host.

This has been corrected.

This change modifies ECP internal algorithms to improve the ECP response time when the journal syncs are very slow. It increases the number of ECP client requests bufs, adds more tracking statistics, and modifies the ECP server journal state notification algorithm to improve notification delivery.

ECP caches blocks locally in CACHETEMP. In very rare conditions when the cached items occupy only a single pointer block, the ECP client read daemon may fail with a system error.

This has been corrected.

This change corrects a problem where all developers could save percent routines into any database, regardless of whether the user had write access to the database.

This change addresses an issue in the case where the flag to encrypt journal files has a value other than 0 or 1. Attempting to correct this through ^DATABASE or the Management Portal resulted in the error

<ILLEGAL VALUE>zGetYesNo+4^%Library.Prompt.1

This change corrects the error.

When the Buttons display was run, the ROLES section would not be displayed because of an undefined error.

This has been corrected.

Previously, when an account became disabled because the last login exceeded the inactive time, the account would be disabled unequivocally. Now Caché also checks to make sure it is NOT the last user with the %All role, so at least one enabled user retains the %All role.

A problem has been corrected that occurred when

1. the MINLEN parameter is specified for a property using the %String or %Text datatype,
2. the MINLEN value is 1, and
3. the value being validated is the SQL empty string ("").

The length of the empty string is 0, but the value was not rejected as being invalid by the %String and %Text type's validation code.

A problem has been fixed that caused queries to occasionally produce invalid code when:

• the query selected the ROWID
• there was a single-field IDKey index defined in the class
• the table had one or more index maps defined where the ID field was only defined in the map data of the index map definition.

The problem first appeared in version 5.2

An issue has been fixed where the compilation of an ALTER VIEW statement might fail if the new view query references a view column in another view that is not based on a table column.

After creating a large number of streams (more than 127), the stream OID contained values that were not transmitted correctly. They were translated based on the character set of the client.

This has been fixed.

The following constructs have identical semantics in SQL:

x <> ALL (SELECT y ...) <=> x NOT IN (SELECT y ... WHERE p)
                        <=> NOT (x = ANY (SELECT y ... WHERE p))

prior to this change, however, treatment of NULL was not the same in these two cases. In particular, if x and/or y are nullable and NOTs have been fully optimized, then the equivalent expression in both cases is:

NOT EXISTS (SELECT 1 ... WHERE p AND (x=y OR x IS NULL OR y IS NULL))

If either x or y is not nullable, then the corresponding IS NULL tests will be optimized away; if both x and y are not nullable then this change will have no net effect.

If either x or y is nullable, and some values of x or y in the database are null, then results returned by the query above will now comply with the SQL standard, but could be different than those returned in previous versions of Caché.

If execution of a "NOT IN (SELECT ...)", "NOT EXISTS", or similar query is performing slower after upgrading from a pre-5.2 version to version 5.2 or later, the first thing to try would be to mark the properties corresponding to x and y above as REQUIRED, if this is possible.

Because of an optimization involving nulls introduced in Caché 5.2, a subquery such as

... x NOT IN (SELECT y ...) ...

might return the wrong result when the "SELECT" returned no rows. This has been corrected.

When the scope of a SQL NOT includes a CASE expression, the CASE returns incorrect values. The negation logic should not be applied to the predicates inside the CASE expression. This is now fixed.

Comparison of two null strings on AMD64 systems will give an incorrect result in cases where the ObjectScript compiler can tell from the source code that the arguments are strings, and neither argument is the explicit literal null string. For example,

$E(a,b,c)=n

will fail if n="" and the $E result is a null string, but

$E(a,b,c)=""

will give the correct result.

This has been corrected.

This change fixes a problem that could cause a process running %SS or JOBEXAM to fail with a memory exception.

In some rare circumstances, the ODBC server process could get a memory access exception. This has been fixed.

On Windows, " CSTAT -q1" checks the semaphore state by checking the event state. Checking resets the state but it did not restore the state back. This may cause CSTAT to intercept a job wakeup intended for another process causing the process to hang.

This change corrects the problem.

This change fixes a problem where the reporting of invalid subscripts in multiple SETs involving array nodes could result in an access violation instead of the <SUBSCRIPT> error message.

A problem has been resolved affecting clusters which would sometimes prevent them from queiscing for a backup.

Under some circumstances. failure to allocate a temporary buffer during process-private global deletion could result in global buffers not being deallocated properly.

This has been resolved.

After a clean system shutdown Caché leaves information in the CACHESYS database which indicates to the system that it went down cleanly and no journal recovery is required at system startup. This is used in cases where the WIJ is missing to indicate that it is ok for the system to start up. The information in the WIJ regarding recovery did not always agree exactly with the information in the CACHESYS database; sometimes the WIJ would indicate that recovery was required when in fact it was not. The recovery indicated by the WIJ was minimal and did not add an appreciable amount of time to system start up but it did lead to confusion in some cases.

This change corrects the system so that a clean system shutdown should leave the WIJ marked that no journal recovery is required and the internal offset for where to start searching for open transactions should be at the end of the journal file. Starting a system when no recovery is required should result in these messages in the console log:

       Performing Journal Recovery
       WIJ indicates no open transactions

During shutdown you will see some new messages:

       Updating Journal File [existing message]
       Journal restore not required at next startup
       Transaction rollback not required at next startup

Caché shared memory was reorganized in version 5.2, providing for larger buffer pools, and ability to map shared memory to different addresses in different processes. However, the organization placed the gmheap after the shared buffer pools. Because of this, with large buffer pools, offsets in the gmheap sometimes overflowed integer values.

This fix reorganizes shared memory, placing the gmheap before the shared buffers, guaranteeing that offsets into the gmheap will never overflow an integer.

Startup and install were beginning the second phase of startup before the initial Caché startup process had completed allocating and initializing shared memory. The result was that the second phase of startup was failing, causing start (or install) to fail.

This fix lets cstart and install wait on an indicator that the first phase is complete, before starting phase 2.

This is an enhancement to display wdsuspd, gbackupreq and gbackupsfn in CSTAT along with SWITCH and other system global info.

This change fixed a CVENDIAN failure to convert some blocks due to the map block not being up-to-date during conversion, especially when the database is accessed via an NFS file system.

This change eliminates the use of fflush() for file handling. It improves the performance of CVENDIAN in converting the database, for example.

This change fixes a CacheHung.sh failure on SUN systems.

This change added CSTAT -W option to free up a suspended Write Daemon.

This change fixed a problem where 'W #' would not clear the screen under some circumstances.

The AIX compiler version 6 generated different AL codes from version 5. Its optimization re-arranged code generation that caused lock structure corruption.

This change fixes this.

This change corrects a problem where the password change routine was incorrectly changing the password for a user, ignoring the permission that the caller had to do so.

This change fixes a Caché Backup hang when lots of global blocks are modified during backup.

This change addresses an issue with noncluster journal restore where under certain circumstances journal restore would abort upon a missing journal file (a desirable behavior) without giving an error message (an undesirable behavior). With the change, journal restore generates an error message when it detects some file or files are missing.

This change corrects an issue where journal switch could hang under the circumstances that

• the old journal file is inaccessible; and
• there are journal records that are yet to be written to disk at the time of journal switch (typically on a busy system).

The journal switch hang would eventually lead to system hang.

This change corrects an issue that caused the backup portion of the journal purging parameter (i.e., how many backups should occur before a journal file can be purged) to be cleared at Caché startup. As a result of that, once Caché is restarted, journal files would be purged on the basis of days only (i.e., how many days should go by before a journal file can be purged), until the user specifies the journal purging parameter again.

A problem has been corrected that caused CSTAT to display journal header information incorrectly in version 5.2 and later.

When locking with S and X mode within a transaction, there is a chance that the lock counter in lock table could be out of synch and eventually corrupt the lock memory.

This change corrects that situation.

This problem only occurred when the lock table is full, no buffer can be freed, and there is incoming network lock request on a global name lock which is owned by another job.

It has been corrected.

This change adds a shadow parameter to allow the user to specify how long the shadow copy of a source journal file can be kept before it gets purged. A similar option existed in 5.0.

By default, when the parameter is left unspecified or evaluated to 0, the shadow copy is purged as soon as it is no longer in use. That is, it has been completely dejournaled and contains no part of the existing open transactions on the shadow. This was the the standard, non-configurable behavior in 5.1 and 5.2. A positive value of the parameter is interpreted as the age, in days, that a file must reach in order to qualify for purging, before its in-use status (as described above) is taken into account.

For example, if the parameter has a value of 2, the shadow copy of a source journal file is eligible for purging if the source journal file is at least 2 days old and it is not still being dejournaled or contains part of one or more existing open transactions on the shadow.

This change corrects an issue that could cause a shadow to hang shortly after starting, resuming or retrying (for example, after a network error). As a result, source journal files would fail to get copied to the shadow.

Other symptoms may include <ZREAD> errors at or around line SNDB+5^SHDWSBLK (depending on the Caché version) on the source (that is, database server) side.

The problem is present in version 5.1 and version 5.2.

This change eliminates a defect present in Caché 5.1. The defect resulted in a failure to recreate a missing CACHETEMP database during startup on OpenVMS.

In 5.2, the cache.ids file is created with only read permissions. However, sometimes it must be rewritten. The result is that the following message may occasionally appear in the cconsole.log, or during upgrade.

02/22-06:40:56:454 (745560) 0 Warning: Error writing cache.ids

The fix makes the permissions on the cache.ids file:

rw-rw----

This change corrects an issue where attempting to allocate memory for a large number of globals (more than 4GB worth) caused an ACCVIO failure.

On OpenVMS, if the initial allocation for a large number of buffers fails, and the buffers are reduced, then startup may sometimes fail with another error. The symptoms are the following displayed in the log:

11/02-09:32:25:165 (2241236e) Control process exited due to a Cache error: 
11/02-09:32:25:185 (2241236e) 3 Freezing system due to daemon abnormal exit
11/02-09:32:25:289 (2241236f) 0 Write daemon started.

This has been corrected.

When importing a CSP file from an XML file the device that the output was written to was reset to the principal device due to the CopyFile method of the %CSP.Routine class. This is now corrected not to change the current device.

Previously, when SYS.Lock.DeleteAllLocks() was passed a non-numeric process ID, the system would remove all the locks in the system instead of just the locks owned by the process. This change fixes this problem.

This change implements a guaranteed locking mechanism in all UNIX environments and file systems and thereby excludes concurrent startup issues.