resources


  • Caché
  • Ensemble
  • HealthShare
  • InterSystems IRIS
  • InterSystems IRIS for Health

November 25, 2019 – Alert: Access Violations with Shadowing

InterSystems has corrected a defect that can cause shadowing to fail with an access violation. In rare cases, the defect can cause memory corruption, leading to unpredictable behavior.

Note: The defect does not affect mirroring.

This defect affects:

  • InterSystems IRIS 2019.1.1 and 2019.3
  • IRIS for Health 2019.1.1 and 2019.3
  • HealthShare Health Connect 2019.1.1
  • HealthShare Health Connect (HSAP) 15.032 on 2018.1.3
  • Caché and Ensemble 2018.1.3

In InterSystems IRIS and IRIS for Health, shadowing code is included, but it should not be used; InterSystems recommends using mirroring, which is not affected by this defect.

The defect occurs only on shadow servers (also known as shadow destinations); shadow sources are not impacted. All shadow servers are vulnerable to this defect.

The correction for this defect is identified as HYY2375, which will be included in all future releases of InterSystems IRIS, Caché, and Ensemble, and is available via ad hoc distribution from the Worldwide Response Center.


  • Caché
  • Ensemble
  • HealthShare
  • InterSystems IRIS
  • InterSystems IRIS for Health
  • TrakCare

November 4, 2019 – Alert: Possible Data Integrity Issues with Mirroring and Journal Restore

InterSystems has corrected several critical defects that can result in data integrity issues. These defects were identified and corrected within a short time, so InterSystems has simplified the upgrade process by consolidating them into a single package. The effects of encountering these defects may not always be visible. These defects affect InterSystems IRIS, IRIS for Health, Health Connect, Caché, Ensemble, and HealthShare products. All of these defects relate to the application of journal data.

InterSystems recommends that you review this document. It will help you determine your level of risk and also describes mitigations for each defect. Please contact the Worldwide Response Center if you have any questions regarding this alert.

 

Description of Defects

All references to messages in the descriptions below refer to the cconsole.log (Caché, Ensemble, and HealthShare) or messages.log (InterSystems IRIS, IRIS for Health).

1) Mirror Data Not Applied – Failover Mirror Member Becoming Primary at Instance Startup

This defect affects Caché/Ensemble 2017.2 and 2018.1, all released versions of InterSystems IRIS, and all HealthShare products based on the affected Data Platforms product versions. A list of HealthShare products affected by this issue appears in Appendix A.

If a mirror failover member starts when its failover partner is shut down and it has to retrieve journal data from another mirror member as part of becoming primary, the system may silently fail to apply some journal records. The sequence of messages below indicates that a mirror member retrieved journal data from another mirror member as part of becoming primary:

11/01/19-13:51:59:109 (13062) 0 Mirror manager for <mirname> starting

11/01/19-13:51:59:774 (13062) 0 Retrieving journal file #<#> for mirror <mirname> from <other-mirror-member-address>

… (more files might get retrieved, and data is applied)

11/01/19-14:06:53:165 (13062) 1 Becoming primary mirror server

If your system has encountered this defect, the journal data indicated by one or more of these messages may not have been applied to the databases.

To avoid encountering this defect: If both failover members are down, always start the member that most recently ran as primary before starting the member that most recently ran as backup.

 

2) Mirror Data Not Applied – Async Mirror Member Shutting Down Dejournaling

This defect affects Caché/Ensemble 2017.2 and 2018.1, all released versions of InterSystems IRIS, and all HealthShare products based on the affected Data Platforms product versions. A list of HealthShare products affected by this issue appears in Appendix A.

When a system meets both of the following conditions, it may encounter this defect:

  • An async mirror member has processed more than 2^32 (~4 billion) records in one dejournaling session.
  • Dejournaling was stopped manually.

If these conditions are met, then, when dejournaling restarts, some of the processed journal records may not be applied.

The following message indicates that dejournaling was stopped manually:

11/01/19-17:43:06:754 (436) 1 Dejournaling for <mirname> shutting down and set to manual restart required

To avoid encountering this defect: Stop and restart mirroring before stopping dejournaling on an async member.

 

3) Journal Records Not Restored – Journal Restore Immediately Following Online Backup Restore (^DBREST)

This defect affects Caché/Ensemble 2018.1.2, all released versions of InterSystems IRIS except 2018.1, and all HealthShare products based on the affected Data Platforms product versions. A list of HealthShare products affected by this issue appears in Appendix A.

This defect is specific to journal restores that are performed in conjunction with a database restore that uses online backup. For more information, see the “Online Backup Utilities” section of the Data Integrity Guide for InterSystems IRIS or the “Caché Online Backup” section of the Caché Data Integrity Guide for Caché and Ensemble.

The defect can cause a journal record not to be applied during the journal restore following the backup restore. If your system has encountered this defect, there is an entry in the ^SYS(“JOURNAL”,”RESTORE”) global in the %SYS namespace that includes the timestamp of the restore as well as the “StartAddress” that was used, such as:

^SYS(“RESTORE”,”JOURNAL”,”20191101 16:55:01″,”Files”,1,”StartAddress”) =           9374648

If the global has no entries that include the “StartAddress” node, the system has not been affected by this defect.

To avoid encountering this defect: When restoring from online backup, do not apply journals as part of the database restore; instead, first restore the backup, then run ^JRNRESTO. Do not use the journal marker.

 

4) Journal Records Applied Incorrectly – Mirror Catchup on a Subset of Databases

This defect affects all released versions; however, the likelihood of the defect being triggered is greatly increased in Caché/Ensemble 2018.1.2, all released versions of InterSystems IRIS except 2018.1, and all HealthShare products based on the affected Data Platforms product versions. A list of HealthShare products most likely to be affected by this issue appears in Appendix A.

If a mirror Catchup operation involves one or more of the mirrored databases in a mirror but not all of them, then stale records from a journal file may be applied to the active databases in the mirror, potentially overwriting newer application data.

If Catchup runs, there are messages such as:

11/01/19-13:01:55:057 (17752) 0 Mirror <mirname> catchup started for 1 database.

… (other events can occur while Catchup is running)

11/01/19-13:01:55:207 (17752) 0 Mirror Catchup completed for database <path-to-database>

To avoid encountering this defect, make sure the mirror member is disconnected from the primary before running Catchup on a subset of databases.

5) Other Scenarios

Other, much rarer dejournaling defects have also been corrected as part of this alert that affect mirroring, shadowing, and journal restore. All released versions of InterSystems products are vulnerable to at least some of these. A short summary of each issue is provided below. Each of these issues is extremely rare, even if the necessary conditions are met. For more details about these defects, please see the maintenance release notes for the corrections listed below in Caché/Ensemble 2018.1.3 or IRIS 2019.1.1, or contact the Worldwide Response Center (WRC).

  • If mirror shutdown takes at least 10 seconds while stopping mirroring or shutting down an instance, this can result in the same defect on the same versions as issue #2 above. (Typically, mirror shutdown takes less than a second.)
  • Mirror dejournaling (on all released versions) can either silently apply a journal record incorrectly or exit due to an error.
  • Journal restore (on the same versions as #1 and #2) can either silently apply a journal record incorrectly or exit due to an error.
  • With parallel dejournaling enabled, mirroring can record an incorrect database checkpoint. If a system subsequently crashes or the checkpoint is recorded while manually stopping dejournaling, some journal records are not applied when dejournaling starts again. This affects the same versions as #1 and #2.
  • A backup mirror member can fail to apply a subset of journal records as part of becoming primary, if the original primary was forced down. This affects all released versions.
  • When dejournaling shuts down for any reason, then journal restore, mirroring, and shadowing are vulnerable to the same defect as issue #2. This affects 32-bit platforms for all released versions.
  • If dejournaling gets an error (such as <FILEFULL> or <DATABASE>) while applying a journal record to a specific database, it can then incorrectly mark a different database inactive; it then can continue applying data to the specific database, despite failing to apply the journal record that caused the error. This affects the same versions as #1 and #2.
  • Mirror database Catchup can fail to apply some journal records if a previous database Catchup on that database failed in some way. This affects all released versions.

 

Verifying Current Data Consistency

You can run DataCheck to verify the consistency of globals across mirror members, but it cannot guarantee that your system never encountered any of these defects. Specifically, if DataCheck reports consistent data, this means the systems are consistent now; however, they may not have been in the past, if affected globals were updated after the defect was encountered. For more information on DataCheck, see the “Data Consistency on Multiple Systems” chapter in the Data Integrity Guide or the Caché Data Integrity Guide.

 

Information about the Corrections

The corrections for these defects are identified as SML2776, SML2781, SML2782, SML2783, SML2785, JO2990, JO3117, JO3137, JO3140, JO3141, RJF391, RJF392, HYY2362, HYY2364, and HYY2373, and will be included in all future releases, including Caché/Ensemble 2018.1.3 and InterSystems IRIS data platform 2019.1.1 and 2019.3, and are available via Ad hoc distribution via the Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.

 

Appendix A: Affected HealthShare Products

For issues #1 and #2 the following HealthShare products are affected:

  • Information Exchange 15.03 and 2018.1
  • Unified Care Record 2019.1
  • Patient Index 15.03, 2018.1 and 2019.1
  • Health Insight 15.03, 2018.1 and 2019.1
  • Provider Directory 2019.1
  • Personal Community 12, 2018.1 and 2019.1
  • Health Connect 15.03, if built on Caché/Ensemble 2017.2 or 2018.1
  • Health Connect 2019.1

For issue #3, the following HealthShare products are affected:

  • Unified Care Record 2019.1
  • Patient Index 2019.1
  • Health Insight 2019.1
  • Provider Directory 2019.1
  • Personal Community 2019.1
  • Health Connect 15.03, if built on Caché/Ensemble 2018.1.2
  • Health Connect 2019.1

For issue #4, all versions of all products are vulnerable. The versions listed for issue #3 are particularly vulnerable to issue #4.


  • Caché
  • Data Platform
  • Ensemble
  • HealthShare
  • InterSystems IRIS
  • InterSystems IRIS for Health
  • TrakCare

October 31, 2019 – InterSystems Security Notification

InterSystems has discovered security vulnerabilities that impact Caché, Ensemble, HealthShare, InterSystems IRIS, InterSystems IRIS for Health, and TrakCare. These vulnerabilities impact all versions of InterSystems products.

Remediation steps and additional guidance documentation are available from InterSystems Worldwide Response Center (WRC).  Any InterSystems product distribution that you receive after July 8, 2019 contains the corrections for these vulnerabilities.

Please reference “SV18113R” when discussing this vulnerability.

For assistance with remediation contact your Application Provider or InterSystems Worldwide Response Center.


  • Caché
  • Data Platform
  • Ensemble
  • InterSystems IRIS
  • InterSystems IRIS for Health

October 17, 2019 – Advisory: InterSystems Products and Apple macOS 10.15 (Catalina)

With the recent release of macOS 10.15, Apple has tightened its control mechanism, called Gatekeeper, so that it now requires executables to be notarized.  InterSystems products are not currently supported for use on macOS 10.15 and the executables have not been notarized.  (As a reminder, InterSystems products are supported on macOS as a development platform only.)

InterSystems is working to provide compatibility with macOS 10.15 for future releases of InterSystems IRIS, InterSystems IRIS for Health, Caché, and Ensemble.  Until that time, we recommend not running InterSystems products on macOS 10.15.  Another option is running InterSystems IRIS in a container on macOS including 10.15.

If you have any questions regarding this advisory, please contact the Worldwide Response Center


  • Caché
  • Ensemble
  • HealthShare
  • InterSystems IRIS
  • InterSystems IRIS for Health

September 19, 2019 – Alert: Possible Query, Compilation, and Data Access Issues with Unicode Character 223 (ß)

InterSystems has corrected a defect in applications that use Unicode character 223 (ß). This defect can result in incomplete query results, class compilation errors, and removal of custom SQL privileges.

This problem occurs on systems that are running or have previously run on:

  • Caché and Ensemble 2018.1.0, 2018.1.1, and 2018.1.2
  • HealthShare Health Connect (HSAP) 15.032 on Core versions 2018.1.0, 2018.1.1, and 2018.1.2
  • HealthShare Health Connect 2019.1
  • InterSystems IRIS data platform – all currently released versions
  • InterSystems IRIS for Health – all currently released versions

The defect is triggered by data and component names containing Unicode character 223 (ß). In the versions listed above, an uppercase conversion incorrectly maps that character to Unicode character 7838 (ẞ).  Applications perform this uppercase conversion using features such as $ZCONVERT and %SQLUPPER.

Problems can occur when accessing data or classes created or modified on a product with a different uppercase conversion than the one currently in use.

Mitigating Issues with Incomplete Query Results

This issue can cause problems in applications that use uppercase conversion. Also, InterSystems SQL uses uppercase conversion by default for indices, so queries on a dataset containing this character can return incorrect results.

To address this defect, InterSystems recommends that you rebuild all indices after upgrading from an unaffected version to an affected version, and vice versa.

Mitigating Issues with Class Compilation and Data Access

For classes with names or components that contain the ß character, the defect can also cause class compilation to fail in one of several ways.

In one case, compilation can fail with a message such as:

ERROR #5503: Field name is invalid: Field (Prop1ö) is not unique within Table (ISC.ße). (Prop1ö)

In a second case, compilation can report success but actually delete the table. In this situation, there are messages during compilation such as:

Dropping orphaned table: ISC.ße

Dropping orphaned procedure: ISC.ẞE_EXTENT

These messages indicate that the table has been dropped, though its underlying data is not removed. In this case, any custom SQL permissions on that table will be lost, causing data access issues.

For this situation, InterSystems recommends the following solution: After upgrading to or from an affected version, but prior to compiling any affected classes, export any users and roles that have been granted SQL permissions on any affected tables. To do this, use either the ^SECURITY routine or the Export class methods of the Security.Users and Security.Roles classes. Make sure to include SQL privileges, which are not included by default in the export via either of these methods. (For more information, see the article “Tips on exporting and importing security settings” on the InterSystems Developer Community.)

If the table is dropped during compilation, you can re-import the users and roles after successfully compiling the class, either via ^SECURITY or the corresponding Import class method.

Obtaining an Update and More Information

The correction for this defect is identified as JLC2212, which will be included in all future product releases. It is also available via Ad hoc change file (patch) or full kit distribution from the WRC. If you have any questions regarding this alert, please contact the Worldwide Response Center (WRC).


  • Caché
  • Ensemble
  • HealthShare

September 19, 2019 – Advisory: Windows EnableVSSBackup Setting Disabled on Upgrade

InterSystems has corrected a defect that could lead to invalid backups on Windows platforms. The defect causes upgrades to disable the EnableVSSBackup setting. By default, EnableVSSBackup is enabled (value set to 1) and the upgrade sets its value to 0. Windows VSS backups taken with this setting disabled may contain invalid CACHE.DAT files.

This problem is limited to Windows platforms on the following versions:

  • Caché and Ensemble 2018.1.0, 2018.1.1, and 2018.1.2
  • HealthShare Health Connect (HSAP) 15.032 on Core versions 2018.1.0, 2018.1.1, and 2018.1.2
  • HealthShare 2019.1 (Unified Care Record, Patient Index, Health Insight, Personal Community, and Provider Directory) on Core version 2018.1.2
  • HealthShare 2018.1 (Information Exchange, Patient Index, Health Insight, and Personal Community) on Core versions 2018.1.1 or 2018.1.0

The defect only occurs if you are upgrading to a version listed above. Once you have upgraded to an affected version, you must manually enable the setting; otherwise, it will be disabled on future upgrades, even when upgrading to versions containing the correction.

For customers using Windows VSS backups, InterSystems recommends enabling this setting on any 2018.1 instances of Caché or Ensemble. Once you have enabled the setting, future upgrades (including to affected versions) will preserve its value.

You can enable the EnableVSSBackup setting either in the Management Portal or using the cache.cpf file:

In the Management Portal

  • On the Startup Settings page (System Administration >
    Configuration > Additional Settings > Startup), click the Edit link for EnableVSSBackup. This displays the Edit: EnableVSSBackup page.
  • On this page, select the EnableVSSBackup checkbox and the click the Save button.

This enables the feature immediately.

Using the cache.cpf File

  • In the cache.cpf file in the installation directory, in the [Startup] section, modify the EnableVSSBackup line:
    EnableVSSBackup=1
  • In the Terminal, in the %SYS namespace, activate the CPF changes with the following call:
    %SYS>set status = ##class(Config.CPF).Activate()

For more information on the Activate class method of the Config.CPF class, see the class reference for your instance of Caché or Ensemble.

For More Information

The correction for this defect is identified as STC3008, which will be included in all future releases. If you have any questions regarding this advisory, please contact the Worldwide Response Center.


  • HealthShare
  • InterSystems IRIS
  • InterSystems IRIS for Health

June 25, 2019 – Advisory: Memory Leak in InterSystems IRIS

InterSystems has corrected a memory leak in applications that pass by reference to a formal parameter that accepts a variable number of arguments.

This problem exists for:

  • InterSystems IRIS Data Platform – all currently released versions
  • InterSystems IRIS for Health – all currently released versions
  • HealthShare Health Connect 2019.1.0

If this defect occurs, the process partition will eventually be exhausted, resulting in a <STORE> error.

The defect occurs if application code calls a subroutine passing an argument by reference to a parameter that accepts a variable number of arguments using the … syntax. For background on these topics and more examples of code that uses them, see the “Variable Number of Parameters” and the “Passing By Reference” sections in the “Callable User-defined Code Modules” chapter of Using ObjectScript in the documentation (Docs.InterSystems.com).

Here is an example to demonstrate the defect:

test     // CDS3148 test

set (var1,var2,var3)=0

do sub(var1,.var2,var3)

quit

sub(arg1,args…)

quit

USER>for i=1:1:1000 { do ^test } write $S

268301128

USER>for i=1:1:1000 { do ^test } write $S

268276552

USER>

This subroutine call would also demonstrate the defect:

do sub(var1,var2,.var3)

But this one would not:

do sub(.var1,var2,var3)

The correction for this defect is identified as CDS3148. It will be included in all future product releases. It is also available via Ad hoc distribution from the InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this alert, please contact the Worldwide Response Center.


June 6, 2019 – Alert: Possible Logical Data Integrity Issue after Crash

InterSystems has corrected a defect that can result in application data integrity issues following an abnormal shutdown.

This problem exists for:

  • Caché and Ensemble 2018.1.2
  • HealthShare Health Connect (HSAP) 15.032 on Core version 2018.1.2
  • InterSystems IRIS Data Platform 2019.1
  • InterSystems IRIS for Health 2019.1
  • HealthShare Health Connect 2019.1

The defect breaks the journal sync guarantee that all updates in the journal buffer have been written to the journal file. The failure is silent: it does not generate an error message and there is no entry about it in any log file.

Specifically, an abnormal shutdown that occurs immediately after a journal sync may result in journal updates that cannot be recovered during the subsequent startup because they were never committed to disk in the journal file. An abnormal shutdown results from either:

  • A forced shutdown of the instance
  • An operating system shutdown or crash

The correction for this defect is identified as HYY2350. It will be included in all future product releases. It is also available via Ad hoc distribution from the InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this alert, please contact the Worldwide Response Center.


  • Caché
  • Ensemble
  • InterSystems IRIS

March 14, 2019 – Alert: Data Integrity Issue with Mirror Database Catchup

InterSystems has corrected a defect in our mirroring technology that can result in inconsistency between mirrored databases. This defect exists for currently released Caché and Ensemble versions beginning with 2017.2 and for InterSystems IRIS Data Platform version 2018.1.

When the issue occurs, some journal updates are not applied to a mirrored database on the backup mirror member or an async member that is being caught up. The result is that the database may not be synchronized with the database on the primary mirror member.

This problem can occur only if a mirror member shuts down abnormally during the Catchup operation. The abnormal shutdown can result from either:

  • A forced shutdown of the instance
  • An operating system shutdown or crash

Note that, even when all necessary conditions exist, the likelihood of experiencing the impact of this defect is very low.

Determining if a system has been affected

First, determine if a Catchup operation was ever interrupted by an abnormal shutdown:

  1. Search the chain of cconsole.log files (for Caché and Ensemble) or messages.log files (for InterSystems IRIS) since installing or upgrading to an impacted product version.
  2. Look for the strings “catchup started for” and “Mirror Catchup completed for”, which indicate the start and end of a Catchup operation.

If an abnormal shutdown did not occur between the start and end of a Catchup, the instance has not been affected; if there has been an abnormal shutdown during a Catchup, this means that the instance may have been affected.

Second, if an abnormal shutdown did occur during a Catchup operation, determine if the mirrored databases are currently inconsistent. Run DataCheck to verify the consistency of globals across mirror members. Verification by DataCheck does not guarantee that the data was consistent at all times, as subsequent updates of impacted globals may have brought them back to consistency. For more information on DataCheck, see the “Data Consistency on Multiple Systems” chapter in the Data Integrity Guide.

Information about the correction

The correction for this defect is identified as JO3114. It is included in Caché and Ensemble releases beginning with 2018.1.2 and in InterSystems IRIS Data Platform releases beginning with 2019.1. The correction is also available from the Worldwide Response Center (WRC) via Ad hoc distribution.

If you have any questions regarding this alert, please contact the Worldwide Response Center.


February 26, 2019 – Alert: Possible Data Integrity Issue with Mirrored Database Catchup with Parallel Dejournaling

InterSystems has corrected a defect that can result in data integrity problems in environments that use InterSystems mirroring in conjunction with parallel dejournaling.This problem exists for currently released Caché and Ensemble versions beginning with 2017.2 and for InterSystems IRIS Data Platform version 2018.1.

Ensuring that you are protected from this issue

Your system is at risk only if you have a mirroring environment that supports parallel dejournaling for mirrored database catchup. Hence, if your environment currently supports this feature, InterSystems recommends that you disable it by setting the following global node in the %SYS namespace:

Set ^MIRROR(mirrorname,”Config”,”CatchupNumUpdater”)=1

Where mirrorname is your environment’s mirror. This prevents systems from meeting the necessary conditions to cause this issue; see below for more details. After upgrading to a version with the correction described below, you can safely ‘kill’ this global node.

Determining whether the necessary conditions are present

It is extremely unlikely that this defect would be triggered, even when all necessary conditions are present. If the defect is triggered, database updates are applied out of order – which can result in a data integrity issue.

Because the problem can only occur during mirrored database catchup, the following scenarios cannot trigger it:

  • Journal restore for non-mirrored databases
  • Dejournaling that occurs during reconnection or restart of a mirror member

For the problem to occur, all of the following conditions must be present:

  • Parallel dejournaling must be enabled.
    • For async members, parallel dejournaling must be explicitly enabled in the configuration.
    • For DR async members, it is enabled by default.
    • For failover members, it is always enabled.
  • The host system must have sufficient resources to use parallel dejournaling, or one or more globals in the %SYS namespace have been explicitly set to a value greater than 1. These globals are:
    • ^MIRROR(mirrorname,”Config”,”CatchupNumUpdater”)
    • ^%SYS(“DEJOURNALING”,”NumUpdater”)
    • For more information on this feature, see “Configuring Parallel Dejournaling” in the “Mirroring” chapter of the High Availability Guide.
  • Catchup must be run on multiple databases as a single operation. In order to determine if catchup was ever run on more than one database as a single operation, search the chain of log files since installing or upgrading to an affected release for messages that contain the string “catchup started for”; any message that contains this string also lists the number of databases being caught up. (The log file is log for InterSystems IRIS and cconsole.log for Caché and Ensemble). If you have the full chain of log files and there is no “catchup started for” message for more than one database, your system has not been affected.

If all of the conditions are present, it is possible that the defect has been triggered. Since the nature of the defect is to apply updates out of order, logical data integrity may be compromised. This would be difficult to identify. Please contact the Worldwide Response Centerif you have determined that your environment might be affected.

You can run DataCheck to verify the consistency of globals across mirror members, but it cannot guarantee that the defect was never experienced. Specifically, if DataCheck reports consistent data, this means the systems are consistent now; however, they may not have been in the past, if affected globals were updated after the defect was encountered. For more information on DataCheck, see the “Data Consistency on Multiple Systems” chapter in the Data Integrity Guide.

Information about the correction

The correction for this defect is identified as HYY2332. This correction will be present in all future released versions of Caché, Ensemble, HealthShare, and InterSystems IRIS Data Platform, except InterSystems IRIS 2019.1, which disables parallel dejournaling.

If you have any questions regarding this alert, please contact the Worldwide Response Center.


  • Caché
  • Ensemble

February 26, 2019 – Alert: Failure in Calls That Use X.509 Credentials with Private Keys after Upgrade

InterSystems has corrected a defect that impacts the use of X.509 private keys stored in Caché, Ensemble, and Health Connect, but only in 2018.1.1, on any platform.

This defect does not affect new installations of 2018.1.1, only upgrades to that version. It affects WS-Security, not SSL/TLS Configurations.

If your environment uses X.509 credentials with private keys and has been upgraded to 2018.1.1, some functions and queries that use the private keys will fail. To correct this problem, please contact the Worldwide Response Center (WRC) and request the utility developed to address the issue.

The correction for this defect is identified as CTW014 and is included in all future releases of Caché, Ensemble and Health Connect.

If you have any questions regarding this alert, please contact the Worldwide Response Center.


  • Caché
  • Data Platform
  • Ensemble
  • HealthShare
  • InterSystems IRIS

October 12, 2018 – Advisory: VMWare vSphere and Data Integrity

Clients running vSphere 5.5 or later should review a very important article that VMware published on October 9, 2018.  The article describes the possibility of file system and database corruption, which can lead to outages and possible data loss.  We have confirmed that this has caused data integrity problems for InterSystems clients. Therefore, we encourage you to act on this as soon as possible.

The VMWare knowledge base article is titled:

Virtual Machines running on an SEsparse snaposhot may report guest data inconsistencies (59216)

If you have any questions regarding this advisory, as it relates to InterSystems products, please contact the Worldwide Response Center.


  • Caché
  • Data Platform
  • Ensemble
  • InterSystems IRIS

October 12, 2018 – Alert: Ordering of XML Sibling Elements

InterSystems has corrected a defect that can cause a reordering of sibling elements in an XML document. This issue is limited to sibling elements that are represented in the database as objects in a relationship.

This problem exists on all platforms for the following products:

  • InterSystems IRIS Data Platform 2018.1.0 and above
  • InterSystems IRIS for Health 2018.1.2
  • Caché and Ensemble 2017.2.0 and above
  • Health Connect/HSAP based on Caché/Ensemble 2017.2.0 and above

Note: HealthShare functionality has been reviewed and is not impacted by this defect.This includes pre-built Health Connect functions; only customers that have created their own functions could be affected.

How the Problem Occurs

When an XML document makes a round trip from XML to InterSystems objects and then back to XML, the ordering of sibling elements is not preserved. This is a violation of the XML Infoset specification, which defines elements as being ordered. If your application handles XML documents in this way, you may encounter unexpected results.

Availability of Corrections

The corrections for these defects are identified as TRW1621 and MAK4992. After installing these corrections, it is necessary to recompile all application routines and classes. These corrections are available via Ad hoc distribution from the InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this alert, please contact the Worldwide Response Center.


  • Data Platform

September 24, 2018 – Advisory: VMWare vSAN and Data Integrity

Clients running vSAN 6.6 or later should review a very important article that VMware published on September 21, 2018.  The article describes the possibility of file system and database corruption, which can lead to outages and possible data loss, and we believe that some of our clients have encountered this issue.  Therefore, we encourage you to act on this as soon as possible.

The VMWare knowledge base article is titled:

Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation (58715)

If you have any questions regarding this advisory, as it relates to InterSystems products, please contact the Worldwide Response Center.


  • Caché
  • Data Platform
  • Ensemble
  • HealthShare
  • InterSystems IRIS
  • TrakCare

September 18, 2018 – InterSystems Security Notification

InterSystems has discovered security vulnerabilities in Caché and therefore also in Ensemble, HealthShare and TrakCare. While those vulnerabilities were only recently discovered, they impact all versions of Caché and all versions of Ensemble and HealthShare. The vulnerabilities were corrected in InterSystems IRIS Data Platform before the product was released.

Remediation steps and additional guidance documentation are available from InterSystems Worldwide Response Center (WRC).  The remediation steps might require downtime and do affect customer applications.  Any InterSystems product distribution that you receive after June 11, 2018 contains the corrections for these vulnerabilities.

Please reference “January 2018 SV” when discussing this vulnerability.

For assistance with remediation contact your Application Provider or InterSystems Worldwide Response Center.


  • Caché
  • Data Platform
  • Ensemble
  • InterSystems IRIS

June 25, 2018 – Alert: Outer Join Query Results

InterSystems has corrected two defects that can cause SQL outer joins to return incorrect results. These defects can also impact DeepSeein Caché and Ensemble, as well as InterSystems Business Intelligence in InterSystems IRIS; in these cases, building and synchronizing some analytic models may result in build errors.

These issues exist on all platforms for the following released InterSystems Data Platform products:

  • InterSystems IRIS Data Platform 2018.1.1
  • Caché and Ensemble 2017.2.0 and 2017.2.1
  • HealthShare Health Connect 15.03 on Ensemble 2017.2.0.744.0
  • HealthShare Health Connect 15.03 on Ensemble 2017.2.1.801.0
  • HealthShare Health Connect 15.031 on Ensemble 2017.2.1.801.3.18095

Queries with an OUTER JOIN that Use TOP with ORDER BY

The first defect appears in queries that use an OUTER JOIN together with TOP with ORDER BY. The defect results in either extra rows being returned or the query never completing. A query is susceptible to this defect when there are NULL rows in the outer table. An example of a query that could experience the problem is:

SELECT TOP 1 E.Name, C.Name As CompanyName
FROM Sample.Employee E
LEFT OUTER JOIN Sample.Company C ON E.Company = C.Id
ORDER BY E.Name

Queries with multiple OUTER JOINs that use Read Committed Mode

The second defect appears in queries with multiple OUTER JOINs that use Read Committed Mode. In join conditions where there is no matching data in the outer table the row is erroneously omitted from the results.

For details on Read Committed Mode, please refer to the section “ISOLATION LEVEL in Effect” in the SET TRANSACTION page of the InterSystems SQL Reference.

Either of the following queries could return incorrect results:

SELECT Name, Spouse->Name As SpouseName,
Company->CompanyName As CompanyName
FROM Sample.Employee
WHERE ID = ?

SELECT E.Name, S.Name As SpouseName, C.Name As CompanyName
FROM Sample.Employee E
LEFT OUTER JOIN Sample.Person S ON E.Spouse = S.Id
LEFT OUTER JOIN Sample.Company C ON E.Company = C.Id
WHERE E.ID = ?

Since InterSystems Business Intelligence and DeepSee use Read Committed Mode, this defect may be triggered when building and synchronizing cubes.  In this case, the issue results in the following error:

ERROR #5001: Error fetching row: (100)

 Availability of Corrections

The corrections for these defects are identified as TRW1600, TRW1605, TRW1610, and HSU250.  These will be included in all future releases of InterSystems IRIS, Caché, Ensemble, and HealthShare. These corrections are also available via Ad hoc distribution from InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this alert, please contact the Worldwide Response Center.

 


  • Caché
  • Ensemble
  • InterSystems IRIS

May 22, 2018 – Advisory: Software Defined Data Centers (SDDC) and Hyper-Converged Infrastructure (HCI)

Important Considerations for InterSystems Clients

A growing number of IT organizations are exploring the potential use of SDDC and HCI solutions. These solutions appear attractive and are marketed as simplification of IT management and potential cost reductions across heterogeneous data centers and cloud infrastructure options. The potential benefits to IT organizations are significant, and many InterSystems clients are embracing SDDC, HCI, or both.

These solutions are highly configurable, and organizations can choose from many permutations of software and hardware components. We have seen our clients use a variety of SDDC and HCI solutions, and through those experiences we have realized that it is important to carefully consider solution configurations to avoid risk. In several cases, there have been clients whose implementations did not match the performance and resiliency capabilities required for mission-critical transactional database systems. This resulted in poor application performance and unexpected downtime. Where the goal is to provide mission-critical transactional database systems with high resiliency and consistently low-latency storage performance, component selection and configuration requires careful consideration and planning for your situation, including:

  • Selecting the right components
  • Properly configuring those components
  • Establishing appropriate operational practices

SDDC and HCI offer flexibility and ease of management and they operate within or alongside the hypervisor layer between the operating system and the physical storage layers. This adds varying degrees of overhead. When misconfigured, this can radically affect disk latency – which is disastrous for performance of applications.

Design Considerations for InterSystems IRIS Data Platform, Caché, and Ensemble

The following list of minimum requirements and design considerations is based on our internal testing of SDDC and HCI solutions. Note that this is not a reference architecture, which means that your application-specific requirements will depend on your situation and performance targets.

Networking

  • Two or more 10Gb NIC interfaces per node that are dedicated for the exclusive use of storage traffic.
  • Two local non-blocking line-rate 10Gb switches for switch connectivity resiliency.
  • As an option, 25, 40, 50, or 100Gb instead of 10Gb for future-proofing investment in HCI and the specific benchmarked and measured application requirements.

Computing

  • At least a six-node cluster for higher resiliency and predictable performance during maintenance and failure scenarios.
  • Intel Scalable Gold or Platinum processors or later, at 2.2Ghz or higher.
  • Installing RAM in groups of 6 x DDR4-2666 DIMMs per CPU socket (384GB minimum)

Storage

  • All-flash storage. This is the only recommended option for storage. InterSystems strongly recommends against hybrid or tiered HCI storage for production workloads
  • Minimum of two disk groups per physical node. Each disk group should support at least three capacity drives.
  • Exclusive use of write-intensive 12Gbps SAS SSDs or NVMe SSDs.
  • For all-flash solutions with cache and capacity tiers, it is recommended to use NVMe for the cache tier and write-intensive 12Gbps SAS for the capacity tier.
  • Use of LVM PE striping with Linux virtual machines, which spreads IO across multiple disk groups (contact InterSystems for guidance).
  • Use of the Async IO with the rtkaio library for all databases and write image journal (WIJ) files with Linux virtual machines. This bypasses file-system caching and reduces write latency (see the documentation or contact the WRC for assistance with properly enabling Async IO on Linux).

These minimum recommendations have shown to alleviate the overhead of SDDC and HCI but do not ensure application performance. As with any new technology, testing of your own application for performance and resiliency is paramount to any successful deployment.

If you are considering SDDC or HCI solutions, please contact your Sales Account Manager or Sales Engineer to schedule a call with a Technical Architect. This is important to ensure your success.


January 5, 2018 – Advisory: InterSystems Response to Meltdown and Spectre Vulnerabilities

InterSystems continuously monitors our systems for any evidence of attempts to exploit vulnerabilities such as the newly announced Meltdown and Spectre attack vectors.

At this time, we have seen no indications of attempts to target InterSystems systems or technology using these vulnerabilities.

  • InterSystems is aware of recently reported cyber-security vulnerabilities known as Meltdown and Spectre that affect a wide range of computer processors (See US-CERT Alert TA 18-004A, Meltdown and Spectre Side-Channel Vulnerability Guidance, https://www.us-cert.gov/ncas/alerts/TA18-004A).
  • As is the case with other technology companies, InterSystems is examining our products to assess and understand the direct impact of the vulnerability and what appropriate actions to take to remediate any discovered risk.
  • Same as with many other companies, InterSystems’ corporate operations and infrastructure uses systems that are impacted by these vulnerabilities.
  • InterSystems is working to remediate these operational vulnerabilities as quickly as possible using the applicable patches and firmware updates as they are made available by our vendors.
  • InterSystems is also monitoring any performance impact caused by patches and firmware update to develop a plan of action to address if necessary.
  • InterSystems continues to monitor this issue and will provide updates as appropriate.

If you have any questions regarding this alert, please contact the Worldwide Response Center.

 

 


July 27, 2017 – Alert: Linux Defects Can Corrupt Mirror Copies of Journal Files

InterSystems has encountered defects in Linux which can corrupt copies of journal files that are generated on a mirror backup or async member; this occurs only in certain specific configurations. The original mirror journal file created on the primary member is not affected.

The risk is only exposed in Caché, Ensemble, and HealthShare distributions beginning with version 2017.1.0. The risk only exists on Linux and only if a backup or async mirror member is configured to use the rtkaio library.

The rtkaio library is distributed with Red Hat Enterprise Linux, though it may be possible to acquire it for other Linux distributions. Caché does not use the rtkaio library by default. Therefore, the risk does not exist unless your system has been configured to use rtkaio. Sites most commonly configure Caché to use rtkaio via the LibPath parameter in cache.cpf.

When the problem is triggered, copies of mirror journal files retrieved on a backup or async mirror member may become corrupted. This typically results in errors during dejournaling of the corrupt file and an alert in the cconsole.log similar to:

03/29/17-16:18:12:852 (25129) 2 Dejournal stuck at 7342380 (0x0070092c) cyclejrnend=11141120 in file #9

InterSystems has notified Red Hat about this issue. Until a correction becomes widely available in supported Linux releases, InterSystems offers a workaround for sites that have configured Caché to use rtkaio. This workaround automatically removes any occurrence of rtkaio from the library path for the daemon process that writes these copies of mirror journal files.

Note that the workaround is not effective if rtkaio use was configured by manipulating the library files rather than setting the LibPath parameter.

The workaround is identified as RJF264 and will be included in all future releases of Caché, Ensemble, and HealthShare. The workaround is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this alert, please contact the Worldwide Response Center.


June 26, 2017 – Alert: Data Corruption with Mixed Endian Mirror Shadowing

InterSystems has corrected a defect that may result in corruption of Unicode data on a shadow system whose source is an async mirror member.

This defect affects all currently released Caché, Ensemble, and HealthShare distributions beginning with version 2012.2.0.  All platforms and operating systems are affected.

In order to be exposed to the risk the configuration must include mirror primary and async members, and a shadow of the async member.  Additionally, the async member must be of different endian than both the primary mirror member and the shadow.

Primary (endian X) -> Async (endian Y) -> Shadow (endian X)

In the above configuration, some Unicode strings greater than 255 characters on the shadow member may be corrupt for databases that are shadowed from the async.

If you are unsure of the endianness of your systems, see the InterSystems Supported Platform (ISP) document.

At the time the data is applied to the shadow member there is no indication of a problem.  Depending on the corruption there may also be no error triggered when the corrupt data is accessed.  The only definitive way to detect the corruption is by comparing the data value between the async member and the shadow.

The correction for this defect is identified as HYY2192. It will be included in all future releases of Caché, Ensemble, and HealthShare, including the just released 2016.1.4.  The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.


April 5, 2017 – InterSystems Security Notification

InterSystems has discovered a security vulnerability in Caché and therefore also in Ensemble, HealthShare and TrakCare. While this vulnerability was only recently discovered, it impacts all versions of Caché and all versions of Ensemble and HealthShare.

Remediation steps are available from InterSystems Worldwide Response Center (WRC).  The remediation steps do not require downtime and do not affect customer applications. Any InterSystems product distribution that you receive after March 2, 2017 contains the corrections for this vulnerability.

Please reference “February 2017 SV” when discussing this vulnerability. For assistance with remediation contact your Application Provider or InterSystems Worldwide Response Center.



November 22, 2016 – Alert: Database Integrity on UNIX® and Linux Platforms

 

InterSystems has corrected a defect that may, in rare circumstances, result in database degradation on UNIX and Linux platforms.

This defect affects Caché, Ensemble, and HealthShare distributions beginning with Caché version 2012.1. It is only a possible risk on UNIX and Linux platforms that are using asynchronous I/O for database writes. The following table specifies if asynchronous I/O is always on or optional for the affected platforms and releases:

PlatformVersions 2012.1 to 2015.1Version 2015.2 and later
AIXOptionalAlways on
HP/UXOptionalAlways on
Linux (all)OptionalOptional
MacOSOptionalAlways on
SolarisOptionalAlways on

For platforms where asynchronous I/O is optional, you can determine if it is in use by examining the cconsole.log file. In that file, at instance startup, locate a reference to:

swdwrtmax=

If this is set to a non-zero value, then asynchronous I/O is in use.

It is only possible to trigger this defect when a hardware or OS-level I/O error occurs while writing to storage AND the environment recovered without needing to be restarted (that is, the environment did not hang). Such an I/O error may result in the following corresponding message in the cconsole.log:

****** SERIOUS DISK WRITE ERROR – WILL RETRY ******

However, a write error can occur without triggering the defect. (That is, the presence of an I/O error or a cconsole.log message does not guarantee that the defect has been triggered.)

If a system has experienced the above, check the integrity of databases on the affected storage via the InterSystems integrity check utility.

The correction for this defect is identified as JO2950. It will be included in all future releases of Caché, Ensemble, and HealthShare. The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.


October 11, 2016 – Alert: Caché Online Backup and Journal Restore.

InterSystems has corrected a defect that may result in missing updates when utilizing Caché online backup.

This defect is present in all Caché and Ensemble versions 2015.1.x, 2015.2.x and 2016.1.x, and all HealthShare distributions based on those versions.  It affects all platforms and operating systems except backups of OpenVMS cluster databases.

The risk does not exist for Mirror Catchup applied to mirrored databases restored from Caché online backup.

The risk only exists when restoring from Caché online backup and applying journal files.  You are at risk of having missing updates if the following are all true:

  • The backup was created by Caché online backup in a product version where this defect is present.
  • The journal is restored using the default option to start at the journal marker set by Caché backup.

This applies for all forms of Caché online backup: full, cumulative, incremental and “Legacy Concurrent External”.

The risk can be avoided by applying journals from the beginning of the journal file that was switched to at the start of the backup, rather than accepting the default of starting from the journal marker position.

The correction for this defect is identified as RJF229.  It will be included in all future releases of Caché, Ensemble, and HealthShare.  The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC).  If you have any questions regarding this advisory, please contact the Worldwide Response Center.


August 24, 2016 – Alert: Database Compaction

This is an addendum to the Alert published on October 14, 2015 – Alert: Database Defragmentation.

That alert indicated that the database defragmentation utility in 2014.1 and higher, on all platforms except OpenVMS, could cause database degradation and the correction JO2871 is available to clients upon request and would be included in future releases.  The correction was included in 2015.1.3, 2015.2.2 and 2016.1.

Further investigation has proven that database compaction, in addition to database defragmentation, can cause database degradation in releases that do not have this correction (JO2871).   The only releases with this risk are:

2014.1.x
2015.1.0, 2015.1.1 and 2015.1.2
2015.2.0 and 2015.2.1

The risk is present for all platforms and operating systems except OpenVMS.

Clients on these releases should postpone any database defragmentation or database compaction until applying the correction or upgrading.

The correction is also available via Ad hoc distribution from the Worldwide Response Center (WRC).

If you have any questions regarding this advisory, please contact the Worldwide Response Center.


July 6, 2016 – Alert: Potential Integrity Issue with Mirroring

InterSystems has corrected a defect with Mirroring that can impact data integrity.

The defect is present in all released versions Caché, Ensemble, and HealthShare beginning with 2015.2.0. It is present for all platforms and affects both failover and asynchronous mirroring configurations.

The nature of the defect is that updates may be skipped when journals are applied to a non-primary system. The defect is only triggered under certain unusual conditions when a non-primary mirror member is starting or reconnecting.

InterSystems recommends, in addition to obtaining the correction, that at-risk systems be checked for impact. There are two methods to do this:

  1. A utility, available via FTP here, can be used to scan a series of cconsole.log files and determine that a system has not been impacted. To ensure a complete check the routine must scan all cconsole.log files generated since a system was upgraded to 2015.2+. Load it in any namespace and invoke it interactively with ‘do ^SML2330Alert’.
  2. The ^DATACHECK utility can be used to check that destination and source systems are in sync.

If either check indicates a problem, please contact InterSystems Worldwide Response Center (WRC) for further assistance. The affected mirror member may need to be rebuilt; information on rebuilding a mirror member can be found here.

The correction for this defect is identified as SML2330. It will be included in all future product releases including the upcoming 2015.2.4 and 2016.1.2 maintenance distributions. It is also available via ad hoc distribution as a patched routine. If you have any questions regarding this alert, please contact InterSystems Worldwide Response Center.


June 30, 2016 – InterSystems Security Notification

InterSystems has discovered a security vulnerability in Caché and therefore also in Ensemble, HealthShare and TrakCare. While this vulnerability was only recently discovered, it impacts all versions of Caché and all versions of Ensemble and HealthShare.

Remediation steps are available from InterSystems Worldwide Response Center (WRC).  The remediation steps do not require downtime and do not affect customer applications.

Any InterSystems product distribution that you receive after June 21, 2016 contains the corrections for this vulnerability.

Please reference “May 2016 SV” when discussing this vulnerability.

For assistance with remediation contact your Application Provider or InterSystems Worldwide Response Center.


March 10, 2016 – Advisory: Cross-Protocol Attack on TLS Using SSLv2 (DROWN)

This advisory concerns the recently announced vulnerability CVE-2016-0800, aka DROWN, which is due to weaknesses in SSLv2. For more information, see https://drownattack.com. This vulnerability may be relevant to InterSystems customers as InterSystems products have the capability to utilize SSLv2.

SSLv2 is known to have weak security and it has long been recommended that it be disabled in installations. SSLv2 has always been disabled by default in all released versions of InterSystems products.

If your organization uses the default configuration for its instances, then no action is required. However, if your organization has enabled SSLv2 for any of its instances, then to eliminate this vulnerability you must disable it. This is especially critical if any instances share a private key. (Note that InterSystems always strongly discourages sharing private keys due to its inherent dangers.) Your organization’s administrators can use the Management Portal or the command line utilities to make the required modifications to SSL/TLS configurations of InterSystems product instances.

If you have any questions regarding this alert, please contact the InterSystems Worldwide Response Center.


March 9, 2016 – Alert: Incorrect SQL Results – Update

This is an update to the alerts: “February 25, 2016 – Alert: Incorrect SQL Results” and “March 3, 2016 – Alert: Incorrect SQL Results – Update.”

Updated product distributions are now posted for Caché, Ensemble, and HealthShare. For Caché and Ensemble, the build number is 2015.2.2.811.0, which has been incremented from previous distributions. For HealthShare, there is a new release that is based on 2015.2.2. These distributions all include the required correction for this issue.

If it is not possible to upgrade to 2015.2.2 from an earlier 2015.2 release, please contact InterSystems Worldwide Response Center to receive the update in an Ad Hoc distribution.

After upgrading to a corrected distribution, you must recompile all classes and routines in your application.

If you have any questions regarding this alert, please contact the Worldwide Response Center.


March 3, 2016 – Alert: Incorrect SQL Results – Update

This is an update to the alert: “February 25, 2016 – Alert: Incorrect SQL Results

After further study of this problem, InterSystems has decided to replace all 2015.2.* full kits on the WRC distribution page. We have removed the current kits and will post new 2015.2.* kits as soon as they are available. We will also post an alert announcing that the new kits are available.

If you are using Cache 2015.2.*, Ensemble 2015.2.*, or a HealthShare kit based on 2015.2.*, InterSystems recommends that you get a full-kit Ad Hoc that contains the correction. Once you have upgraded to a new kit containing the correction, you must compile all the classes and routines in your application.

If you have any questions regarding this alert, please contact the Worldwide Response Center.


February 25, 2016 – Alert: Incorrect SQL Results

InterSystems has corrected a defect that can cause incorrect results for certain SQL INSERT, UPDATE, and DELETE statements.

This defect is present only in Caché and Ensemble 2015.2 and HealthShare distributions based on them. The problem affects all platforms.

Incorrect results occur only when two or more of these statements are nested within each other.

The example below demonstrates one possible way for this problem to happen:

  1. The class has an UPDATE trigger that uses embedded SQL to modify a table.
  2. Because the SQL is embedded in the UPDATE trigger, it is a nested statement – the trigger’s UPDATE is called while the UPDATE that initiated the trigger is still being executed. (This is the condition that can lead to incorrect results.)
  3. In this case, the trigger is updating this table but the problem could happen even if a different table were being changed.

Given the following class, User.Test:

Class User.Test Extends %Persistent
 {
   Index idx On (x, y);
 
   Property x As %Integer;
   Property y As %Integer;
   Property z As %Integer;
   Property flg As %Integer;
   Property zz As %String;
 
   Trigger UA [ Event = UPDATE, Time = AFTER ]
   {
     if ({flg}=0) quit 
     &sql( UPDATE SQLUser.Test 
           SET flg=0 
           WHERE x=:{x} and y=:{y} and z=:{z} 
     ) 
     quit
   }
 }

and that User.Test has the following two rows:

  x      y     z    flg   zz 
  123  55  1    0 
  123  55  2    0

In this situation, the following call to UPDATE only modifies one row:

UPDATE SQLUser.Test SET flg=1,zz='done' WHERE x=123 and y=55

This call then has a result of:

 x      y      z     flg   zz 
 123  55   1    1    done 
 123  55   2    0

The correction for this defect is identified as DPV4766. It will be included in all future releases of Caché, Ensemble, and HealthShare. The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.


November 3, 2015 – Alert: Large ODBC Query Results Incomplete

InterSystems has corrected a defect with the Caché ODBC driver that can result in incomplete query results. The problem can occur when the total size of all rows returned would exceed 4KB. There is no indication that the failure has occurred. Results greater than 4KB are truncated.

This defect exists only in the Caché ODBC driver that is distributed with versions 2015.2.0 and 2015.2.1 of Caché, Ensemble, and HealthShare. The risk is present for all platforms and operating systems.

The corrections for this defect are identified as JCN1662 and JCN1665. They will be included in all future releases of Caché, Ensemble, and HealthShare.

Caché ODBC drivers are designed to be upward and backward compatible. Until corrected Caché ODBC drivers for 2015.2 are available, drivers from older versions can be used to avoid this issue. Drivers for older versions are available in the download area of the Worldwide Response Center (WRC) application.

If you have any questions regarding this advisory, or need assistance with obtaining and installing drivers, please contact the Worldwide Response Center.


October 14, 2015 – Alert: Database Defragmentation

InterSystems has corrected a defect with the Caché database defragmentation utility.  The defect has been observed to cause access violations in the defragmentation process, leading to a hung environment.  Other impacts are possible though have not been reported.  These include database degradation (which may occur without warning message) and process failures.

This risk exists in all released versions of Caché, Ensemble, and HealthShare beginning with 2014.1.  The risk is present for all platforms and operating systems except OpenVMS.

InterSystems recommends that you postpone any database defragmentation activities until you apply the correction.

The correction for this defect is identified as JO2871.  It will be included in all future releases of Caché, Ensemble, and HealthShare.  The correction is also available via Ad hoc distribution from InterSystems Worldwide Response Center (WRC).

If you have any questions regarding this advisory, please contact the Worldwide Response Center.


August 31, 2015 – InterSystems Security Notification

InterSystems has corrected a security vulnerability in Caché and therefore also in Ensemble, HealthShare and TrakCare. While this vulnerability was only recently discovered, it impacts versions of Caché beginning with 2007.1 and all versions of Ensemble and HealthShare. All customers who are running these versions are vulnerable.

Corrected software distributions are available from InterSystems. Remediation may require some downtime.

Any InterSystems product distribution that you receive after August 18, 2015 contains the corrections for this vulnerability.

Please reference “July 2015 SV1” when discussing this vulnerability.

For assistance with remediation contact your Application Provider or InterSystems Worldwide Response Center (WRC) by phone (+1 617-621-0700), e-mail (Support@InterSystems.com) or web (WRC.InterSystems.com)


July 28, 2015 – Alert: Ensemble and HealthShare – HL7, X12, ASTM and EDIFACT Segment Sub-Transformations

InterSystems has corrected a defect that causes errors when executing a data transformation of an HL7, X12, ASTM, or EDIFACT message that includes a call to a segment-level sub-transformation.

This alert applies to Ensemble and HealthShare on all platforms. The defect is present only in Ensemble 2015.2 and in HealthShare versions based on Ensemble 2015.2.

Due to the defect, when a segment-level sub-transformation is called, it is probable that a <PARAMETER> error will occur. The error occurs in the CopyValues() method of the relevant segment type (HL7, X12, ASTM, or EDIFACT). If your application employs a routing engine and this error occurs, the corresponding message will not be routed.

The correction for this defect is identified as KDS214. It will be included in all future releases of Ensemble and HealthShare, including the upcoming Ensemble 2015.2.1 maintenance release. If there is an urgent need for the correction, it is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 19, 2015 – Update: OpenVMS 8.4 Incompatibility

This is an update regarding InterSystems prior advisory from May 6:

“May 6, 2015 – Advisory: OpenVMS 8.4 Incompatibility”

InterSystems has confirmed through testing that the incompatibility discussed in the May 6 advisory does not exist for InterSystems products on Integrity platforms.

If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 14, 2015 – Advisory: Yosemite OS X 10.10.3

InterSystems has corrected a defect that causes the Caché ObjectScript JOB command to fail.

This advisory applies to all InterSystems Products running on the recently released Apple OS X version 10.10.3 platform. (Note: OS X 10.10.x first became a supported platform with Caché and Ensemble v2014.1)

InterSystems recommends that this correction be applied prior to upgrading to OS X 10.10.3.

The correction is identified as JLC1866.  It will be included in all future releases of Caché, Ensemble and HealthShare.  The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC).  If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 8, 2015 – Advisory: HL7, X12, ASTM and EDIFACT Message Processing

InterSystems has corrected a defect that causes errors when updating segmented virtual documents such as HL7, X12, ASTM and EDIFACT. The error is triggered by a specific sequence of operations, namely:

1)   Clone an existing message OR create a message using a class method of the form ImportFrom…

2)   Use the method GetSegmentAt to fetch an individual segment of the message.

These steps cause the segment to be incorrectly marked immutable; it cannot be changed. Attempts to modify the segment fail with the message “<ENS>ErrGeneralSegment is immutable”

DTL (Data Transformation Language) usage is not at risk from this defect unless the GetSegmentAt method is explicitly called in a custom code block.

This Advisory applies to Ensemble and HealthShare on all platforms. This defect only exists in versions 2015.1 and 2015.1.1.

The correction for this defect is identified as JGM282. It will be included in all future releases of Ensemble and HealthShare. The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center


May 6, 2015 – Advisory: OpenVMS 8.4 Incompatibility

InterSystems has discovered that an update to OpenVMS 8.4 will cause functionality within InterSystems products to hang indefinitely.  While we have not been able to confirm the specific update we know that the problem is present as of VMS84A_UPDATE-V0500.

This Advisory applies to all released versions of Caché and Ensemble on OpenVMS Alpha, multi-cpu platforms.  We are still investigating whether there is a similar impact for Integrity systems.

InterSystems has discussed the incompatibility with HP and decided to implement a workaround based on their guidance.  Customers who find it necessary to either upgrade Alpha systems to OpenVMS 8.4 or install updates to Alpha systems already running OpenVMS 8.4 should not do so before applying the workaround.

The workaround is identified as LG427; it will be included in all future releases of Caché, Ensemble and HealthShare beginning with version 2015.2.  It is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC).  If you have any questions regarding this advisory, please contact the Worldwide Response Center.


April 28, 2015 – Advisory: Mirroring Default QoS Value Considerations

InterSystems has determined that the default value of the mirroring Quality of Service Timeout (QoS) setting is too small for some environments.  This can result in undesired mirror failovers and/or unnecessary alerts.

This advisory applies to all platforms.  Although the issue exists with any version of Caché, Ensemble or HealthShare that supports mirroring, this advisory is of particular note to deployments using version 2015.1 with the arbiter.

The Quality of Service Timeout (QoS timeout) setting affects failover member and arbiter behavior by defining the range of time, in milliseconds, that a mirror member waits for a response from another mirror member before taking action. The QoS timeout itself sets the maximum waiting time, while the minimum is one-half of that. A larger QoS timeout allows the mirror to tolerate a longer period of unresponsiveness from the network or a host without treating it as an outage; decreasing the QoS allows the mirror to respond to outages more quickly.

InterSystems has observed that virtualized hosts, in particular, often become entirely unresponsive for periods that exceed the default QoS value when operations such as backup or guest migration occur.  Typically, deployments on physical (non-virtualized) hosts with a dedicated local network can operate within the default QoS value continually.

The default QoS timeout is 2 seconds (2000 ms).  In future versions, the default QoS timeout will be 8 seconds (8000 ms) to allow for several seconds of intermittent unresponsiveness that may occur on some hardware configurations.

InterSystems recommends reviewing your hardware configuration and the effects of any operations regularly performed on the virtualization hosts to determine a reasonable setting for QoS.  In deciding whether to increase the QoS timeout, the potential of an undesired failover should be weighed against a slower response time during actual outages.  The timeout can be changed via the System Management Portal ‘Edit Mirror’ page, or via the ^MIRROR utility.  If you have any questions regarding this advisory, please contact InterSystems’ Worldwide Response Center.


March 11, 2015 – Alert: Write Image Journal failure

InterSystems has corrected a defect that may cause data integrity issues following a crash on systems with a certain unusual configuration.  Specifically, the defect can cause application of the WIJ file to fail during startup.

A detailed discussion of the protection provided by the WIJ can be found in the Caché Data Integrity Guide.

This defect is present in all currently released versions of Caché, Ensemble, and HealthShare.  It affects all platforms and operating system versions.

The only systems vulnerable to this defect are those that mount hundreds of databases referenced by long path names.  When the combined length of the path names exceeds approximately 32,000 characters, the defect can occur. The exact condition can be checked for a given system by running the following command:

For Windows:

<install-directory>bincwdimj -d2 -j<wij-directory>

For Unix/Linux

<install-directory>/bin/cwdimj -d2 -j<wij-directory>

For OpenVMS

Define a foreign command

$ cwdimj :== $sys$disk:[-.bin]cwdimj.exe

and from the cachesys manager’s directory issue:

$ cwdimj –d2 –j_<wij-directory>

 

The output of this command will include the value of “Dirlen”.  If Dirlen is less than or equal to 32768, the system is not currently exposed to this defect.  Please note that the value of Dirlen changes as you add or remove databases to your running environment.  If Dirlen is close to the limit of 32768, InterSystems recommends that you request the correction identified below.

If a system exposed to this defect shuts down abnormally, and the abnormal shutdown occurs at a time when there are database blocks pending in the WIJ, startup will fail necessitating manual deletion of the WIJ. This causes database integrity issues. If this occurs, an entry similar to the following will be present in the cconsole log file:

Starting WIJ recovery for ‘<pathname>CACHE.WIJ’.

N>0 blocks pending in this WIJ.

WIJ pass # is 0.

WIJ file does not match expectations: XXXXX

 

The correction for this defect is identified as JPL1675.  It will be included in all future releases of Caché, Ensemble, and HealthShare.  The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC).  If you have any questions regarding this advisory, please contact the Worldwide Response Center.

 


March 4, 2015 – Advisory: FREAK attack SSL/TLS Vulnerability

Yesterday an announcement was made of a new SSL/TLS vulnerability referred to as the “FREAK attack”.  The issue is that the key length of the cipher used to encrypt data can be shortened in export libraries, weakening the encryption.

More information can be found here:

https://freakattack.com/
or
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0204

This advisory applies to all currently released versions of InterSystems products that support SSL/TLS, including Caché, Ensemble, HealthShare and TrakCare.

By default a SSL/TLS configuration created in InterSystems products is not susceptible to this attack.  The default flags for the Cipher Suites include the element !EXP which prevents the shortening of the key length.  It is possible for an administrator to override this default.  As an example the default flags in Caché 2015.1 are:

TLSv1:SSLv3:!ADH:!LOW:!EXP:@STRENGTH

InterSystems recommends that the above default settings be reviewed for the existence of the !EXP element.  If it has been removed it should be re-added.  Customers should follow the recommendations of their OS vendors for obtaining corrections to this vulnerability.

If you have any questions regarding this advisory, please contact InterSystems Worldwide Response Center.


February 13, 2015 – Advisory: “GHOST” Vulnerability

InterSystems products use the glib library on supported platforms in limited fashion, but the library is not shipped as part of any InterSystems product. According the recently announced “GHOST” security vulnerability the glib library is a security risk.

All InterSystems products and versions are at risk.

For more details, please see:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0235

InterSystems recommends that customers follow the library update procedures from their Operating System vendors to address this vulnerability. No changes to InterSystems products are required.

If you have any questions regarding this advisory, please contact InterSystems Worldwide Response Center.


December 11, 2014 – Advisory: TLS Exploit (a.k.a POODLE attack variant)

The SSL 3.0 vulnerability documented recently in Reference: CVE-2014-3566 was expanded on December 8, 2014 to identify some implementations of TLS as being vulnerable too (CVE-2014-8730).

For more details, please see:
https://www.us-cert.gov/ncas/alerts/TA14-290A

InterSystems has verified that the implementation of TLS used in its products – Caché, Ensemble, HealthShare and TrakCare – is not vulnerable.

If you have any questions regarding this advisory, please contact InterSystems Worldwide Response Center.


October 28, 2014 – HealthShare Alert: Potential Unauthorized Data Display

InterSystems has discovered and corrected a defect in our web application technology used by the HealthShare portal and the Clinical Viewer.  In rare circumstances, this defect can result in sharing of data by separate user sessions.  This could lead to (a) a user having a different set of privileges and being able to access patient records they are not permitted to view or (b) being presented with clinical data from a different patient in the Clinical Viewer.

The risk is low in typical configurations, but the defect impacts all currently released HealthShare versions.  It occurs only in environments using Microsoft Internet Information Server (IIS) version 7 and higher as its webserver.

This fault will only occur after IIS has recycled one of its worker processes, and the likelihood of encountering this problem increases with the recycling frequency of IIS worker processes.  As an example, frequent recycling of worker processes can occur in configurations where the ‘Idle Timeout’ defined for the Application Pool is set to a low value and, in particular, when the ‘Idle Timeout’ is set to a lower value than the HealthShare application timeout configured in HealthShare.  The settings controlling the recycling of worker processes can be found in the IIS control panel (Application Pool -> [Select Application Pool] -> Advanced Settings).  If the periodic recycling of worker processes is completely disabled in your IIS configuration then your installation will be unaffected by this issue, with the exception that IIS will always recycle a worker processes that either hangs or causes an unrecoverable error condition.

Please work with your system administrators to ensure IIS is configured to minimize any chance of this defect impacting your system and apply the patch available from InterSystems Worldwide Response Center (WRC).

InterSystems WRC can assist with reviewing the potential for this problem impacting your environment.

The correction for this defect is identified as CMT1273.  It will be included in upcoming HealthShare 2013.1 and 2014.1 maintenance releases, and is also available via Ad Hoc distribution from InterSystems WRC. If you have any questions regarding this advisory, please contact the Worldwide Response Center.


October 28, 2014 – Alert: CSP Session ID Reuse with IIS 7+

InterSystems has discovered and corrected a defect that can result in CSP session IDs being shared by two users. More specifically, there are situations where a new user for an application will be allocated a CSP session ID that has already been allocated to, and in use by, another user. The impact of this defect is application-dependent, but one possible consequence is the incorrect display of application data belonging to the session of another user.

The defect is present in all currently released Caché, Ensemble, and HealthShare versions. It occurs only in environments with Microsoft Internet Information Server (IIS) version 7 and higher.

This fault will only occur after IIS has recycled one of its worker processes, and the likelihood of encountering this problem increases with the recycling frequency of IIS worker processes. As an example, frequent recycling of worker processes can occur in configurations where the ‘Idle Timeout’ defined for the Application Pool is set to a low value. The settings controlling the recycling of worker processes can be found in the IIS control panel (Application Pool -> [Select Application Pool] -> Advanced Settings). If the periodic recycling of worker processes is completely disabled in your IIS configuration then your installation will be unaffected by this issue, with the exception that IIS will always recycle a worker processes that either hangs or causes an unrecoverable error condition.

The correction for this defect is identified as CMT1273. It will be included in upcoming Caché, Ensemble, and HealthShare 2013.1 and 2014.1 maintenance releases, and is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center.


October 17, 2014 – Advisory: SSL 3.0 Exploit (a.k.a POODLE attack)

In response to the recently documented SSL 3.0 vulnerability (Reference: CVE-2014-3566), InterSystems advises customers to switch from using or requiring SSL 2.0 or SSL 3.0 and instead use only TLSv1.

InterSystems products support TLSv1, SSL 3.0 and SSL 2.0 for SSL/TLS. The SSL/TLS configuration can be controlled through the Management Portal (System > Security Management > SSL/TLS Configuration)

Furthermore, beginning with version 2014.2, InterSystems products will default for newly defined SSL/TLS configurations to only include TLSv1; SSL 3.0 will still be available as an option.

If you have any questions regarding this advisory, please contact the Worldwide Response Center.


July 16, 2014 – Alert: Dejournaling Problem May Result in Missing Updates

InterSystems has corrected a defect that can impact data integrity. The defect is present in Caché, Ensemble, and HealthShare version 2013.1.0 and later.

This defect may cause some database modifications to be missed when journal files are applied to a database. The problem may occur on systems that are the target of data replication (via mirroring or shadowing), on systems recovering after an unplanned outage, or when databases are being restored from journal files.

The problem occurs rarely and exact circumstances are dependent on internal “race conditions” between several processes, so are not easily characterized externally. There is no way to tell if a system has been affected by this defect. However, on systems using mirroring or shadowing, the DATACHECK utility can be used to see if the destination system accurately reflects the source.

The correction for this defect is identified as HYY1943. It will be included in all future releases of Caché, Ensemble, and HealthShare. The first release to include the correction will be 2014.1.2 which will be available no later than July 31st. The correction is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center.


June 17, 2014 – Advisory: OpenSSL Security Advisory

The OpenSSL Project http://www.openssl.org recently released a security advisory on vulnerabilities in the OpenSSL product.

These vulnerable OpenSSL products are included in the distribution of and used by most InterSystems products from version 2007.1 through the present, 2014.1. OpenVMS and Mac OSX are the exceptions to this; InterSystems products on these platforms use the libraries installed with the operating system.

InterSystems strongly recommends that customers move to OpenSSL versions containing the corrections to the vulnerabilities as soon as possible. To ease this transition for our partners, InterSystems is taking the following steps:

  1.  We have posted updated distributions of the latest maintenance release of all versions since 2011.1. The updated distributions include the corrected version of OpenSSL.
  2. We have posted versions of the corrected OpenSSL libraries, again for all versions since 2011.1, along with instructions that will install them in existing deployments. The list below shows the compatibility between corrected OpenSSL version and InterSystems version.
    OpenSSLInterSystems
    1.0.0m2011.1 through 2014.1
    0.9.8za 2007.1 through 2010.2

Installation of InterSystems products can result in OpenSSL libraries being placed in multiple locations. For example, the CSP Gateway uses SSL and the Gateway is often installed on a server separate from the primary InterSystems installation. The installation instructions detail the locations that need to be considered.

Distributions and instructions can be found at:
https://wrc.intersystems.com/wrc/Distribution.csp

Installation instructions are named: openssl_installation_instructionspatch-all.txt

Distributions of updated libraries are named according to the convention: openssl-version-platform.extension; for example, “openssl-2014.1.1.702.1-lnxsuse10x64.tar.gz”.

Note that distribution files are named for the most recent ISC maintenance release for a major version. These distributions are compatible with all releases for that major version. i.e. 2011.1.6.1001.4 is compatible with 2011.1.0 through 2011.1.6
If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 21, 2014 – Alert: Incorrect $BIT Rollback over ECP

InterSystems has corrected a defect that can lead to $BIT operations over ECP being rolled back incorrectly.

This defect is present on all releases of Caché, Ensemble, and HealthShare prior to 2013.1.6. This defect only affects deployments that use ECP; other deployments are not affected.

As a result of this defect, if a $BIT operation originates on an ECP application server and occurs in a transaction, it may, on rollback under rare conditions, be rolled back to the wrong value. This can impact bitmap indices as well as any application-specific use of $BIT.

The correction for this defect is identified as SJ2941 and is included in Caché, Ensemble, and HealthShare as of 2013.1.6 and 2014.1.0, and is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.


May 21, 2014 – Advisory: Calculation Error in InterSystems Optimization (Itanium Platforms only)

InterSystems has corrected a defect that causes incorrect calculation on Itanium platforms. The defect is present in InterSystems assembly optimizations targeted to Itanium platforms.

This defect is present on all currently released versions of Caché, Ensemble, and HealthShare. It is limited to Itanium platforms.

Specifically, the problem can occur when adding to a local or global variable that has the value 2147483647 (that is, 2**31-1). The problem does not occur for every such operation but depends on preceding activity. See the following example:

>set test=2147483646
>write test set test=test+1
2147483646
>write test set test=test+1
2147483647
>write test
6917529029788565504

Furthermore, it is adding to the value that fails so even an operation such as

>if test+1>xyz …

may experience the failure.

The correction for this defect is identified as JLC1792 and will be included in upcoming release 2014.1.2 of Caché, Ensemble, and HealthShare. It is also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 20, 2014 – Alert: Data Integrity Problem in Dejournaling

InterSystems has corrected several defects that can only occur in rare circumstances but can impact data integrity.

The defects are present in Caché, Ensemble, and HealthShare from version 2012.2.0 through 2013.1.4, on all platforms and operating systems.

These defects can, in rare circumstances, lead to data inconsistency or database corruption when data from journal files is applied to a database. This impacts systems that are the destination of replication via shadowing or mirroring, or databases being restored from journals. The risk to journal recovery following a system crash is believed to be negligible, and transaction rollback is not affected.

InterSystems recommends upgrading systems to a product version that includes the corrections listed below.
The corrections for these defects are HYY1881, HYY1902, and HYY1904. They are included in Caché, Ensemble, and HealthShare as of 2013.1.5 and 2014.1.0, and are also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this advisory, please contact the Worldwide Response Center.


May 20, 2014 – Alert: Locking and Shared Memory Corruption

InterSystems has corrected two defects with locking that, in rare circumstances, can cause shared memory corruption of lock structures. This condition can potentially lead to process failures and hung environments. These defects exist for Caché, Ensemble, and HealthShare.

All platforms and operating systems are at risk. These defects have existed in releases of Caché beginning with version 5.0.

The corrections, identified as SML1819 and SML1847, are both included in Caché, Ensemble and HealthShare as of 2013.1.6 and 2014.1.1 (to be released shortly). To address the risk of these defects, InterSystems recommends upgrading to these versions.

The corrections are also available via Ad Hoc distribution from InterSystems Worldwide Response Center (WRC). If you have any questions regarding this alert, please contact the Worldwide Response Center.


April 9, 2014 – InterSystems Security Notification: Heartbleed Bug

A security vulnerability in OpenSSL identified as CVE-2014-0160 and popularly known as “The HeartBleed Bug”, was made public on April 8, 2014 and has since been widely publicized. More information is available at http://heartbleed.com.

InterSystems products do ship with and use OpenSSL*, but no InterSystems product or version of Caché, Ensemble, or HealthShare include any of the vulnerable versions of OpenSSL*.
NO corrective steps are needed to protect InterSystems products against this vulnerability.

If you have any questions regarding this, please contact InterSystems WRC by phone (+1 617-621-0700), e-mail
(Support@InterSystems.com), or web (WRC.InterSystems.com)

*OpenSSL versions 1.0.1 through 1.0.1f are vulnerable to this attack. The latest version of OpenSSL InterSystems distributes is 1.0.0e, which is not vulnerable to this attack.