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 corrects a a problem that could result in some NSD child processes failing to close on receiving the termination signal (SIGTERM) from the parent process. Child processes are usually signalled to stop when the parent/master NSD process is instructed to close down by the 'CSPnsd stop' command.

This issue is particularly relevant to IBM AIX but the same problem could affect other UNIX systems.

This change addresses two issues relating to HL7 messages which reference the same segment object multiple times.

The first issue resolved by this change relates to the behaviour when deleting such an HL7 message still stored in the older segment format. Previously, deleting the segment data would succeed for the first reference to the segment, but errors would be encountered when attempting to remove later references to now non-existent data. This situation is now handled gracefully.

The second issue resolved by this change relates to the automatic conversion of segments created in versions older than 2009.1 to the updated storage format introduced Ensemble 2009.1. The conversion code now takes into account the possibility that a single HL7 message may contain multiple references to a single segment.

This change uses SQL_C_CHAR instead of SQL_C_NUMERIC as the default character type for binding all non-floating-point, non-BigInt parameters in the Ensemble SQL Adapters.

It turns out that many ODBC drivers including the Cache ODBC driver do not support SQL_C_NUMERIC. This change uses SQL_C_CHAR because all non-floating-point numeric values can be correctly handled as strings by the Cache ODBC gateway without loss of precision.

Users may add a supplementary group list to cache user ids (owner-of-instance, cacheusr), and this group list will be added to processes begun during instance startup.

Some customers actually make use of the fact that the supplementary group list for the system manager that starts caché was being transferred to the startup jobs (e.g., superserver, jobservers, etc.). This gives a controlled way of duplicating this functionality. All the desired supplementary groups can be explicitly added to cacheusr, and the startup jobs will have these groups.

When using a SQL Function call in an SQL query, if the function defines a collation in the return type, that collation will now be used by SQL. For example, assume the following class method definition:

Class SQLUser.FunctionTest Extends %Persistent
{

Property myString As %String(COLLATION = "SQLSTRING(100)", MAXLEN = 500);

ClassMethod Reverse(Arg1 As %String) 
As %String(COLLATION="SQLSTRING(100)",MAXLEN=500)
[SqlName = Reverse, SqlProc ]
{
	quit $reverse(Arg1)
}

}

Now suppose this query:

SELECT myString, SQLUser.Reverse(Prop1) gnirtSym 
FROM SQLUser.FunctionTest
ORDER BY 1, 2

Prior to this change, the execution of the query would result in a <SUBSCRIPT> error when the length of the data in myString approached 500 characters. This is due to a well known subscript length restriction in Caché. Now the SQL query processor will recognize the collation of the return value for the function as SQLSTRING(100) and the ORDER BY will be performed on the collated value of the function return value.

A problem has been corrected when a query stored procedure specified a ROWSPEC for the result columns and one or more of the columns were type %Numeric, the scale was not properly sent to the xDBC client for the column.

This change prevents a Studio crash when saving an .int routine with a large number of lines highlighted.

This change corrects a situation where references to a multi-dimensional property were not able to be evaluated out of context. For example,

$N(..ArrayProp(1))

returned from a method was only usable from the same sub-class; it raised a <function> error when it was evaluated out of context.

This modfication addresses a situation where, in rare circumstances, a system configured with too few routines buffers that also referenced many classes or routines could miscalculate the reference count of a class. This could result in unpredictable effects: system crash, hang due to unavailable routine buffers, system slow down, and so forth.

This change corrects an error that miscalculated the sizes of routines leading to inefficiency in the allocation of routine buffers and therefore in Caché.

This change corrects an error where, in rare conditions when the system is running with a limited number of routine buffers and all routine buffers are in use, Caché may choose the wrong size routine buffer to use.

This change corrects an issue in cluster journal restore or convert that could leave the utility in an unexpected state if one selected the first menu item of "Cluster Journal Restore - Setup - Main Settings".

This corrects an issue in journal restore where blank lines in journal.log could get reported as "missing files", resulting in failures in journal restore.

There is a potential issue in upgrading from 2009.1 or earlier to 2010.1 or later on VMS. The newly created journal log may contain a journal file name with a trailing version number (for example, "20100722.001;1"). This change ensures that the journal file names in the journal log do not contain trailing version numbers.

Under some conditionas, Caché backup could indicate failure (message: [Backup failed.]) while it in fact succeeded. This change corrects that possibility.

This change corrects a situation where a shadow server generated a <FRAMESTACK> error after having processed thousands of journal files without an error.

This change corrects a problem where DataCheck would skip checking globals that only existed on the source.