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 files: \relnotes\cache\prenotes.htm and/or \relnotes\ensemble\prenotes.htm

This document provides a list of the changes between versions 2008.2.2 and 2008.2.3 for Caché and Ensemble.

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 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

Under some infrequent circumstances, a race condition could occur between a queue being deleted and the insertion of an entry into that queue resulting in an <UNDEFINED> error.

This has been corrected.

This change corrects a problem where a request for job summary information could result in a <STORE> error when there were many (>1000) unfinished business processes.

This change increases the amount of time allowed for a lock attempt to succeed. It also improves the job cleanup when the lock attempt fails which assure that future jobs will always have properly initialized global data.

This change assures that the various parts of the Ensemble scheduler use the same time resolution. A failure to do so in prior releases caused some Alarms to be ignored as already having been acted on because they were being measured against a clock with lower resolution.

This change fixes a condition that would cause an invocation of Queue:EnQueue to exit without properly releasing a lock.

This change adds an option to do SearchTable RemoveIndex() operations with the %NOLOCK SQL option. This prevents the table lock threshhold from being reached on the SearchTable when a virtual document instance is deleted that has many SearchTable entries associated with it.

When the table lock threshhold is exceeded during an SQL DELETE operation, the whole table is locked. For HL7 services, this prevents new SearchTable entries from being stored during the time it takes for the DELETE to complete.

In order to ensure that new SearchTable entries don't fail to insert when a Purge operation is executed during normal operation of the Production, this change also makes the delete triggers in the document classes invoke the SearchTable's RemoveIndex method using this new option

The File Passthrough Service (unlike the FTP passthrough service) moves the file to the ArchivePath (if any) after ProcessInput() returns. If ProcessInput does an Async call forwarding the filename, then a race condition would occur where the target Operation would look for the file in the WorkPath while the Service was moving it to the ArchivePath.

This change fixes the behavior of the EnsLib.File.PassthroughService to use the correct determination of when to use an Async call and when to use a Sync call, in order to avoid this race condition.

This change also modifies the File Inbound Adapter to make it skip renaming the file to ArchivePath if ArchivePath=FilePath. This avoids a problem where the renamed archive file is picked up by the adapter as if it were a new file because it appears in the FilePath input directory.

This change also adds the stream size to the trace messages in both the FTP and File Passthrough Services.

This change removes an expensive internal check for specific properties in the DTL target class. The check has been replaced with an error trap that is more efficient than the check.

This change allows the method EnsLib.EDI.X12.Document.buildRuntimeIndexFromPath() to successfully parse segment paths that include a required key field (e.g. HL!3=22-12) for content-sensitive segment map parsing.

In particular, this affects field 3 of HL (Hierarchical Level) segments. Depending on the value in field 3, an HL segment can identify any of several different possible loop structures within a document schema. When attempting to assign or save documents that are constructed in "PathMap" mode, e.g. by an ordinary DTL transform, this allows documents that contain HL segments to be created.

This change also strips the 'key field' specifier (e.g. !3=22) out of the segment type declaration stored as part of the node data in the segment map array that gets created when a new X12 schema is imported from a SEF file into Ensemble.

An X12 HL segment (Hierarchical Level) is used to distinguish nested loops that may contain similar types of segments. To do this it requires a fixed value in field 3 (Hierarchical Level Code). However, there is no ambiguity when an X12 document structure contains only a single loop with an HL segment; therefore, it is OK for a SEF file to have an HL segment specified without specifying a specific value for HL:3.

This change also prevents a possible crash should this circumstance occur.

This change fixes the behavior of the X12 Service classes when ReplyMode=Immediate. This mode requires that child documents not be forwarded until the entire inbound document is received and parsed. Otherwise, it could be rejected while portions of it have already entered the Ensemble system.

This change also fixes a condition where this class would lose the assignments of DocType to each child document based on the value of the DocSchemaCategory setting.

This change corrects and simplifies the logic used to determine when to show a non-separator character in field ISA:11 (defined as InterchangeControlStandardsIdentifier/"U" under Control Versions before 00403, Repetition Separator in later versions).

When the value of field 11 is a character or number, that value is displayed. Otherwise, the display value is the repeat separator in effect for the current display of the segment. The control version is not taken explicitly into account in this determination; any character that is not a number or a digit or a different separator is a valid Repeat Separator.

For documents input with a "U" or other alphanumeric character in field 11, there is an implied Repeat Separator equal to the default X12 repeat separator which is Ascii 30 (RS/Record Separator), an invisible control character.

This change fixes mapping of X12 schemas that use HL (Hierarchical Level) segments containing key values to distinguish different loops in the document structure. The schema importer generates special decorated segment names of the form such as "HL!3=22-12" where HL is the segment name, !3=22 means that field 3 of this HL segment is required to contain the value 22, and -12 denotes its ordinal position in the schema.

This change allows the segment type name to match in the buildRuntimePath... method by stripping out the ! clause from the segment path name.

This change fixes ASTM parsing of M (Manufacturer) message types, that is, message types that contain manufacturer-defined M segments with field 2 containing the type of manufacturer segment (and by implication the type of manufacturer message). Formerly, this type of message would get a schema error.

This change makes sure that numeric values are converted to $DECIMAL before being stored. In prior releases, it was possible to store a double value in a %Numeric field.

This change makes it possible for someone with read access to the CACHESYS database to run %SS. In previous versions, write access or %Admin_Manage:USE were required.

A problem has been corrected where a single-field IDKEY field defined in a Map Subscript expression, for example,

$$Tag^Routine({MyIDKeyField})

specified for the map subscript expression in a child table would cause an <UNDEFINED> error.

This change corrects a problem where, in certain rare cases, a syntax error would be generated for a SELECT query. The occurrence of the error depended on what names were used in the variable list of the INTO phrase.

This change fixes a problem in cstat in Caché 2008.2.x versions where the list of processes waiting for a resource would not be shown.

This change corrects a situation where multiple processes examining the JOB queue at the same time could cause system degradation, and continually get NOJOB errors.

This change corrects a situation where a simple routine to exhaust memory, for example,

f i=1:1 s a(i)=$zu(188)

will cause a JobServer to loop forever.

Addressed an issue where $ZDATEH() with date format 3 (ODBC format) and a two-digit year would return an error result instead of the correct value.

A problem has been corrected where in certain rare cases a code generated syntax error would occur on a SELECT query depending on what names were used in the INTO variable list.

InterSystems internal testing uncovered a small window in OpenVMS clusters where the failure of a cluster member within a minute or two of a new member joining could result in a cluster crash. This change resolves that issue.

The problem was introduced in 2007.1 and can be recognized because there will be a message in the console log of the cluster master that the wdpass values in the write-image journal files differed by more than 1, or there were more than 2 distinct values found.

This change corrects an error that could cause the write daemon to hang. The circumstances triggering the error include frequent journal file switches, heavy journal activity, and a system interruption.

This changes corrects a situation where routines that need to start a transaction (for example, to modify an object or execute an SQL query) would hang if called via %ZSTOP during shutdown.

A problem has been corrected that could cause starting a Caché instance from the cube to fail with an "Access Denied" error message. The problem occurred on Windows Vista and possibly Windows Server 2008 with a non-English locale. The problem was reported with Brazilian Windows Vista.

This problem was present on all Windows Vista capable versions of Caché (2007.1 forward).

This change corrects an issue during an upgrade where the upgrade code was referencing the wrong version value.

This change corrects three issues with upgrades from Caché version 5.0:

1. The code was checking for version 1.4 not 1.3
2. The code was not returning a %Status value
3. The code was not properly handling an old bug where tasks could get miscategorized

Upgrades from 5.0 to 2008.2 require that the Task Manager be upgraded before new tasks can be created. This change ensures that the Task Manager is upgraded before the installation creates the system Inventory task.