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

If your database or application servers hold local transaction information until the transactions are completed, or 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 evaluating 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

This change will ensure that the values assigned to configuration parameters in CSP.ini are always expressed in English (7-bit ASCII range). It has always been the convention that text held in the Gateway configuration file should be in English, even though the corresponding text in the Management forms may be localized in some other language.

This change fixes a problem that could lead to the Gateway Management form for Application Access not displaying properly. This was caused by a local buffer overrun in the part of the form that deals with the 'Response Size Notification' parameter.

This change corrects the session status information in the Gateway connection table where state-changes are made in the form footers and, as a result, are not projected through to the form content. This problem only affects applications that are configured to not use cookies to project the session token.

This change corrects a mis-routing issue with state-aware applications where the Gateway and the Caché service processing a request could get out of agreement on whether a session was state-aware and trigger a security violation.

This modification will protect against a potential memory violation in the function responsible for reading data block headers from Caché. The error happens as a result of the Gateway caretaker daemon responding to (perhaps transient) connectivity issues to a previously operational Caché instance.

In previous versions, all session tokens (either as cookies or as form/URL variables) embedded in cached pages would be replaced with the current session token for the user. This presents a problem for cases where the very first form in the application is returned from the cache. In this case there is no incoming session token to replace the original value held in the cached version of the page.

This change now correctly handles that situation.

This change only affects users who have user-defined functions in their Rules. In this case, such Rules would not be properly recompiled during an in-place upgrade; in an upgraded system, "Unknown Function" errors would be seen in all Rules that made use of custom functions.

Compilation of Rules will succeed even if the classes containing utility functions are in an uncompiled state. However, if the user opens the Rule in the editor, the function will be highlighted in red as an error, with the hint "Function 'name' does not exist or is not compiled". If the Rule is evaluated, it will throw a runtime error when trying to evaluate the function.

This change modifies the way that the functions are retrieved at compile time, fixing this problem.

Since Rules were introduced in Ensemble, they may extend the built-in set of functions, creating their own user-defined custom functions.

However, there was never a check or warning about duplicate function names existing in more than one class. The current behavior is to silently ignore the duplicates and select the first definition found.

Starting with this change, Ensemble will now report such errors during upgrades in file ensinstall.log, and offer a method that users can invoke to check for such duplicates so they can resolve these conflicts:

Write $system.OBJ.DisplayError(##class(Ens.Rule.Utils).GetAllFunctions(.func))

After an upgrade, users should now check the file ensinstall.log, under subdirectory mgr, and ensure that the rules upgrade went without error.

This change corrects a situation where if GCOMPACT was run on a database while it was experiencing <FILEFULL> errors, the resulting database had a corrupted pointer block with loss of data.

A problem has been fixed that could lead to an invalid name in the global directory in the specific case of using indirection for the global name with the same local variable which is also set in a subscript expression using $DATA, $ORDER, or $QUERY. For example,

SET ^X(3)=4, n="^MyGlobal", @n@($DATA(^X(3),n))="data"

The UNION/OR optimization requires certain "cloning" operations to be performed on the internal representation of a SQL query that are not available when using collection predicates. In this case, the UNION/OR opt is disabled for a query block when collection fields are referenced within that query block. The function that checked for this condition had an error that has now been fixed.

A routine invocation allocated and left the frame stack uninitialized, and if there was an error which required cleanup during the current namespace search, the result was unpredictable.

This has been corrected.

If system fails on journal error and FreezeOnError is set, MONITOR does not report the error via email.

This change fixes that omission.

This change fixes a situation where the clean daemon might fail to clean up a dead job if its resource is used by the clean daemon itself.

In versions previous to 2009.1, when the parameter JoinCluster was set to 1 in the CPF file, Caché would increase the parameter MaxServerConn to 14 so other cluster members would be able to connect. This change restores that behavior that had been removed in 2009.1.

An error has been corrected where a lock was not taken out while editing a CSP page. Thus, if two people were editing the same page, then when one user changed it, the other user would immediately be presented with a message: