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

Late-breaking information about this kit can be found in: \relnotes\readme.1st

Release notes from prior kits are combined in the file: \relnotes\cache\relnotes.htm

This document provides a list of the changes between Caché 2008.1.2 and Caché 2008.1.3.

Topics include:

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

Customers running on any prior released version of Caché may upgrade to this version of Caché during installation. When upgrading across multiple versions, intermediate upgrade steps may be necessary depending on the inter-release compatibility requirements. The release notes for the intervening releases will contain that information.

After each upgrade step, the following conditions apply:

The following guidelines apply to the process of upgrading ECP configurations:

If you have questions or concerns about how to upgrade your ECP configuration, please contact InterSystems Worldwide Customer Support.

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.

When acquired by the Government, commercial computer software and related documentation bearing this legend are subject to the following:

1. Title to and ownership of the software and documentation shall remain with the Contractor.
2. Use of the software and documentation shall be limited to the facility for which it is acquired.
3. The Government shall not provide or otherwise make available the software or documentation, or any portion thereof, in any form, to any third party without the prior written approval of the Contractor. Third parties do not include prime contractors, subcontractors and agents of the Government who have the Government's permission to use the licensed software and documentation at the facility, and who have agreed to use the licensed software and documentation only in accordance with these restrictions. This provision does not limit the right of the Government to use software, documentation, or information therein, which the Government has or may obtain without restrictions.
4. The Government shall have the right to use the computer software and documentation with the computer for which it is acquired at any other facility to which that computer may be transferred; to use the computer software and documentation with a backup computer when the primary computer is inoperative; to copy computer programs for safekeeping (archives) or backup purposes; and to modify the software and documentation or combine it with other software. Provided that the unmodified portions shall remain subject to these restrictions.

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 Support & Education tab, then choose the Support menu item for the product you are interested in, for example, Caché Support. Links to the available documentation can be found on the support page for each product.

To help you assess the impact of this maintenance kit on your applications, the remaining topics in this document describe each modification in detail.

If you need assistance evaulating the effect on your application(s), system(s), or related plans, please contact the InterSystems Worldwide Support Center:

• Phone:  +1  617  621-0700
• Fax:  +1  617  734-9391
• Email:  support@intersystems.com

There were some unusual cases where it was possible for the CSP Gateway and the Caché server to disagree on whether the Preserve setting was 0 or 1. The failure to keep these values in sync would result in either of two conditions:

• a server process only serving requests from one session when this was a Preserve=0 session and so causing this server process to serve many more requests, or
• more seriously, a server process in Preserve=1 mode getting a request for another sessionId.

This change now checks for any potential inconsistency in the Preserve state of the session and makes sure the gateway is updated with the correct state and the cookie is reset to the correct value.

This change allows CSP Gateway to properly handle modifications to "Preserve" mode. Such changes can be made anywhere in the code responsible for delivering the session response. Changing a session from state-less (preserve mode 0) to state-aware (preserve mode 1) and vice versa results in changes to the data held in the session cookie/token. The Gateway needs to be made aware of these changes so that it can manage its connection pool appropriately.

This change eliminates a problem where an argumentless ZLOAD with an immediate end of file left the partition empty, and a subsequent DO command could cause an access violation.

When ECP daemon is started by the job server, ECP will now job a non job-server daemon, and abandon the original.

ECP may accept connection(s) for recovery during system startup. This change modifies the ECP server to wait for logins to be enabled before the ECP requests are processed.

This change modifies the ECP server shutdown to cleanup any queued pending pre-fetch requests. If these are not cleared properly, in very rare conditions the ECP server may receive a message while the write daemon of that same session is shutting down. This event leaves the background pre-fetcher in an undefined state.

To provide its guarantees, the ECP server depends on the durability of its activities. Durability tracking was previously dependent on the journal file number, which is not updated and tracked in parallel with the journal offset.

This change modifies the durability logic not to depend on the journal file number.

Caché connections were failing in random ways due to a Microsoft bug that corrupts memory when GetUserName() is called inside the initialiuzation code of a dll. The details of the bug are described at http://support.microsoft.com/kb/942234.

This change alters CacheODBC.dll so it no longer calls GetUserName() during initialization.

These methods were projected by the prior CacheObject bindings. The classes modified are:

• %Boolean
• %Char
• %Collate
• %Currency
• %Date
• %Decimal
• %Double
• %EnumString
• %FilemanDate
• %FilemanTimeStamp
• %Float
• %Integer
• %Name
• %Numeric
• %String
• %StringTimeStamp
• %Time
• %TimeStamp
• %MV.Date

Independent of the SoapBindingStyle for a web client or web service, the WS-Security and WS-Addressing headers should always be in literal format (that is, not SOAP encoded).

Because of the use of SOAP encoding, the WS-Security header for SoapBindingStyle=encoded web client had the wrong header element name. This change fixes that problem.

The XMLFORMAT parameter (value of literal or encoded) in a %SOAP.Header subclass determines if the header should always be in the specified format. If XMLFORMAT is "" or not specified, then the header is output in the same format as the Body which is specified by SoapBindingStyle.

This change fixes a rare problem on Itanium Unicode platforms that could cause a <STRINGSTACK> error if a variable was assigned a small literal string repeatedly without any other command following, for example:

For i=1:1:25000000 Set x="12345" 

This change corrects a condition where, in certain rare conditions, database corruption could occur on an ECP Client if the write daemon is in the process of writing a bottom pointer block for the ECP Client cache to disk while a user job is deleting a node from the block because the user job found a data block which is marked as "purged from the local cache".

The symptom of this degradation is that the indication of the space in use in the bottom pointer block will be larger than the size of the block itself.

The 'margin' parameter of the terminal USE command (for example, USE 0:(270) ) was handling values >255 differently on OpenVMS Alpha and OpenVMS Itanium.

The documentation says, "Values from 1 to 255 set the right margin for output; any other value disables the right margin", but on OpenVMS Alpha, Caché properly handled values only up to 511. On OpenVMS Itanium, Caché internally truncated the value to one byte, essentially acting as a #256 on values between 255 and 512.

This change corrects a situation that can result in an installation failure for DECUNIX cluster platforms.

This change fixes a potential database security hole where a user who had no access to a global could still use $ORDER in the reverse directtion on its subscripts.

Caché had been previously modified so it was careful to not use any more space on the frame stack than necessary if it was processing a <FRAMESTACK> error.

This change modifies that logic so it does not do this processing until after if checks that a <FRAMESTACK> error has occurred.