Skip to main content

Caché 2015.1

This chapter provides the following information for Caché 2015.1:

New and Enhanced Features for Caché 2015.1

The following major, new features have been added to Caché for this release:

Furthermore, this version of Caché has been improved and enhanced in the following areas:

In addition, many more localized improvements and corrections are also included. In particular, if you are upgrading an existing installation, please review the detailed list of changes in the Upgrade Checklist.

Major New Features

Improved Database Scalability

This version of Caché has important changes specifically targeted at improving performance and scalability on large multi-core systems. Initial benchmarks show near-linear scalability from 16- up to 64-core systems. From a performance standpoint, InterSystems has simplified the database engine, and introduced more effective data usage algorithms, improving performance for a variety of application access patterns. Most applications will benefit from these changes, but those who desire to take advantage of scaling from between 16 - 64 cores will experience benefits that previously were out of reach.

Rapid Application Development

Stateless Service Requests

The new Stateless Service Request capability of the Java Gateway enables simple and efficient calls out to any running Java service that implements the new com.intersys.gateway.Service interface. In addition to performance gains, this gateway feature is not dependent on any saved state for the way Ensemble proxies are mapped to their corresponding Java counterparts. Arguments and results are represented as %Strings on the Ensemble side and byte arrays on the Java side. This allows ANY serialized value to be passed to and from the underlying engine; the actual wire format used for data transport is JSON.

Support For XSLT2

In the previous release, InterSystems provided support for XSLT Version 2 as an Experimental Technology Preview feature. This release now provides full support for XSLT Version 2 as a standard part of Caché. XSLT 2 provides a significant advance in capability over XSLT Version 1; among its new features are:

  • A more convenient and expressive transformation language plus support for XPath 2.0 and the new XDM (XPath Data Model).

  • Strong typing, support for XSL schema types, and the ability to define your own (schema) types. XPath 2.0 also includes a new sequence type not present in Version 1.

  • A much more powerful functional language with improved string processing, date and time handling, node-set manipulation, and boolean operators.

  • The ability to define and write functions in pure XSLT via the xsl:function instruction.

These, and many other improvements/new features significantly increase the productivity of any XSLT programmer. Strong typing allows many errors to be caught at compile time and to be corrected immediately.

XSLT Version 2 functionality is available via the classes in the %XML.XSLT2 package. For details, see “Performing XSLT Transformations” in Using Caché XML Tools.

Note:

XSLT2 functionality is not available on the OpenVMS platform.

DeepSee Improvements

This release contains many corrections and improvement to DeepSee. Among the more important are:

  • DeepSee Query Auditing

    DeepSee has always kept a simple log of all MDX queries in ^DeepSee.QueryLog. But for more advanced query auditing, you can now define code that will be executed every time an MDX query is executed. This code has access to the query text and other information about the query. See “Auditing User Activity” in the DeepSee Implementation Guide.

  • New Time Duration Format

    There is a new format for DeepSee measures that represent a span of time. If the measure represents a duration in seconds, then using the format “%time%” will display the value as hh:mm:ss. For example, 3800 seconds would be formatted as 01:03:20 ( 1 hour, 3 minutes, 20 seconds). See “ Specifying a Format String” in Defining DeepSee Models.

  • Expansion of %TIMERANGE Function

    The %TIMERANGE function (an InterSystems extension to MDX) now supports relationships. See the DeepSee MDX Reference.

Soft Modal Dialogs

Caché 2012.2 included a new feature called Soft Modals. Instead of popping up a new window for dialogs, the code instead simply draws a <div> layer on top of the current page DOM and displays the dialog there. Once the dialog is satisfied the <div> is cleared. This feature gives much better behavior especially on tablets and mobile devices where a pop up opens a new tabbed browser instance.

In version 2012.2, this was introduced but not enabled by default. With this release, this switch has been reversed and soft modals is now the default behavior. This can be overwritten by changing the global node at ^%ISC.ZEN.useSoftModals, or by overriding the default behavior of the %OnUseSoftModals() to return false. The change can be done in a base class or on a page by page basis as needed by the customer.

Zen Mojo

Zen Mojo was first released in March of 2014 as a standalone kit that could be installed on 2013.1 and later versions of Cache and Ensemble. Beginning with this version, the latest supported version of Mojo will be shipped pre-installed as well. The standalone kit will continue to be made available and will continue to be updated independently of the major platform releases.

For information on Zen Mojo, see the books Using Zen Mojo and Using Zen Mojo Plugins.

Performance and Scalability

Semaphores

This release introduces semaphores to Caché applications. Semaphores provide a fast, efficient mechanism for signaling, control and synchronization among processes, especially between those running on an ECP system. For more about the use of semaphores, consult the class documentation, %SYSTEM.SemaphoreOpens in a new tab, or the technical article on the subject.

Support For NGINX Web Server

This release includes support for new Web Server platform for CSP, Zen and Zen Mojo: the NGINX Web Server. NGINX is a high-performance, event-driven web server technology and it is available as another option along with IIS and Apache.

Reliability, Availability, Maintainability, Monitoring

More Robust Mirroring

In this release, the mirroring capability now employs a separate system called the arbiter. This significantly increases availability and simplifies configuration by supporting safe, built-in, automatic failover under failure scenarios where it was not previously possible: when the primary’s host has failed completely or become isolated. When this occurs, the backup can take over because the arbiter confirms that it too has lost contact with the primary; the primary, if it is up, stops acting as primary, eliminating the possibility of both failover members acting as primary.

Furthermore, this release contains the following in a series of ongoing improvements to simplify mirror configuration, deployment, and management:

  • The Mirror Architecture and Planning Guide streamlines access to all the details to consider in the planning phase of deployment

  • More comprehensive information available in the Mirror Monitor

  • Better configuration-time detection of problems in SSL setup

Security

Multiple Database Encryption Keys

Starting with this release, InterSystems customers may employ multiple encryption keys. This enhancement enables customers that require different databases to have different encryption keys. This capability will also allow database re-encryption in a future release.

Early Adopter Features

This category intended as a way of introducing and providing access to new software capabilities that InterSystems believes will be useful in enhancing the effectiveness of existing and future applications.

The capabilities listed here are ready for use by customers, but they are not yet complete in functionality and design. Customers who take advantage of these capabilities must understand:

  • InterSystems makes no guarantee that this feature will achieve general availability in it present form;

  • There is no backward compatibility guarantee between this version and future updates, if any;

  • Customers may incorporate these capabilities in deployed applications, but must first check with InterSystems to determine best course of action;

  • Customers who deploy these capabilities in their applications must commit to upgrading to the final released version.

InterSystems strongly encourages those who incorporate these items in their software to provide feedback on their experiences.

Predictive Analytics

This release of Caché introduces runtime support for predictive models defined using the PMML (Predictive Modelling Markup Language) standard, version 4.1. Data scientists or analysts creating predictive models through third-party tools (such as KNIME, R, SAS, SPSS, and others) for data mining and modelling can now import the PMML representation of these models into Caché. Upon compiling them, code will be generated automatically so that applications (or business processes) can invoke the compiled models directly from with Caché without need for a connection or reliance on the third-party tool. The PMML runtime support introduced by Caché enables customers to leverage their existing predictive modelling activities in a Caché-powered production environment.

More about PMML can be found hereOpens in a new tab as well as in the Technical Article accompanying this release.

Text Categorization

Text Categorization allows computers to assign labels or invoke actions based simply on a text fragment. This release of Caché introduces a framework to build and execute Text Categorization models. Users can build categorization models based on a set of already categorized text fragments known as the training set. By selecting key features of the text as identified by iKnow and choosing a model type, they can automatically generate the model. These models can then be deployed to a production environment independently of the training set and subsequently invoked from ObjectScript or SQL from a business process or custom application.

User who wish to learn more about text categorization can begin with this key research paperOpens in a new tab.

Caché 2015.1 Upgrade Checklist

Purpose

The purpose of this section is to highlight those features of Caché 2015.1 that, because of their difference in this version, affect the administration, operation, or development activities of existing systems.

Those customers upgrading their applications from earlier releases are strongly urged to read the upgrade checklist for the intervening versions as well. This document addresses only the differences between 2014.1 and 2015.1.

The upgrade instructions listed at the beginning of this document apply to this version.

Administrators

This section contains information of interest to those who are familiar with administering prior versions of Caché and wish to learn what is new or different in this area for version 2015.1. The items listed here are brief descriptions. In most cases, more complete descriptions are available elsewhere in the documentation.

Version Interoperability

A table showing the interoperability of recent releases is now part of the Supported Platforms document.

Management Portal Changes

Numerous changes have been made in the Management Portal for this release both to accommodate new features and to reorganize the existing material to make it easier to use. Among the more prominent changes are the addition of pages to assist with Caché mirroring and the separation of roles.

Operational Changes

This section details changes that have an effect on the way the system operates.

Change To <STORE> Error Handling

This release changes the way Caché handles low memory conditions to allow an application that experiences a <STORE> error due to exceeding the maximum memory for the process to recover more gracefully without requiring special code in the error handler. From versions 2012.1 through 2014.1, when a process generated a <STORE> error, $ZSTORAGE was automatically increased the maximum memory by 1MB to provide extra memory to handle the error. However, unless the application explicitly reset $ZSTORAGE after cleaning up from the first <STORE> error, the next <STORE> error would not have the benefit of the extra memory.

With this release, when an application frees memory after a <STORE> error, it returns to a mode where future <STORE> errors can take advantage of the same additional 1MB that was available to the first <STORE> error. The specifics of the new approach:

  • $ZSTORAGE no longer changes when the process generates a <STORE> error

  • $STORAGE may now become negative

  • <STORE> errors are thrown based on the value of $STORAGE rather than internal memory counts which makes them more predictable

Application error handling code that was making assumptions about $ZSTORAGE automatically increasing (per the 2012.1-2014.1 behavior) needs to be reviewed. Furthermore, code that depends on $STORAGE being positive needs review. For details on the behavior see Caché Process Memory.

Setting The %-Routine Path Is Now A Privileged Operation

Beginning with this release, changing the process search path for percent routines, with either $ZU(39) or %SYSTEM.Process.SysRoutinePath(), is now a privileged operation. The process must have Write permission for the CACHESYS database. If the percent routine path is set to a non-default value, and ROUTINE^%R is used to operate in a namespace other than the current one, Caché will throw a <PROTECT> error after the operation is complete; the routine path will not be restored.

Any users who are setting a non-standard percent routine path in a non-privileged process will have to provide a secure method for setting the path or change their code to not require a non-standard path.

^cspRule Relocated

In this release, the location of ^cspRule is moved from the default global database to the routine database. Customers will need to recompile their CSP rules as part of the upgrade from earlier versions to 2015.1.

Default Memory Used For Routine Cache Increased

This release, when automatic configuration of memory is selected, the amount of memory allocated to the routine cache is increased by approximately 12MB. As a result of this change, configurations that do not specify this explicitly will consume more shared memory for routines.

Change To %SYS.SYSTEM.GetNodeName()

The method, %SYS.System.GetNodeName(1) is documented to return the operating system defined node name for the system it runs on. In previous releases, it would get the node name, and then convert it to uppercase. It now returns the node name as defined by the system, and does not change its case.

Terminal Control-C Input Handling Changes

In previous releases, some terminal input operations dismissed any pending control-C signal before reading from the terminal. Other terminal input operations directly acted on any control-C that was pending before reading from the terminal. Now all terminal read operations will dismiss any pending control-C before reading from the terminal.

If a user was previously used to doing type-ahead for interactive input, that user will have to type a second control-C after the read is commenced; the control-C in the type-ahead buffer is now ignored by an input operation. Any operation that clears the contents of the terminal type-ahead buffer (using, for example, WRITE *-1 or WRITE *-10) will now also dismiss any pending control-C at the same time the type-ahead buffer is emptied.

Note:

There is no change in behavior if the user types a control-C directly in response to a terminal input operation.

Argumentless QUIT Command Error Reporting Change

If a function ends with an argumentless QUIT when it should instead return a value, the <COMMAND> error will now report the location of the QUIT (which may be implied at the end of a routine or procedure). $ZERROR and the error exception object will have a Data field that says that the function must return a value.

If a routine is detecting this condition by checking for <COMMAND> within itself, that check will fail because the routine name in $ZERROR will be different. The test can be changed to look for the text “*Function must return a value”.

$INCREMENT Now Signals An Error On Failure

In previous releases, $INCREMENT could fail to signal an error when an expression such as

$INCREMENT(X, Y)

with a non-zero Y value failed to change the value of X. Such situations were possible, for example, when X was an integer value and Y was a small decimal fraction (less than around 5E-19*X); or when X contained a decimal value and Y was a small $DOUBLE binary fraction (less than around $DOUBLE(1E-16)*X).

Now, a failure to change the value of X when Y is non-zero will always result in a <MAXINCREMENT> error.

Note:

A Y value of zero (no increment of X) is valid and no error will ever be signalled in such a case.

Mirroring Changes
  • Mirror Database Names Must Pass Validation For Config.Database Dataset Names

    Mirror database names are now stored in uppercase although they can still be entered in either case for compatibility with existing databases from older systems. Existing mirror database names are not affected by this change. This means that it is no longer possible to create two mirrored databases with names that differ only in case. In addition, the only characters valid for mirror database names are the same characters used in dataset names. The leading character must be an alphabetic or an underscore and the rest must be a sequence of alphanumerics, hyphens and underscores.

  • Remove Mirror Sync Rules Other Than syncrule_ack

    Starting in this release, mirroring no longer supports multiple acknowledgment modes: Sync, Acked, Committed. The advanced mirroring configuration option, Acknowledgement Mode, has been removed. In previous versions, choosing the non-default value of “Committed” could introduce unwanted side effects and does not provide any improvement in reliability or robustness.

  • Agent Contact Replaced By Arbiter

    A new mirroring feature employs a separate system called the arbiter to significantly increase availability and simplify configuration by supporting safe, built-in, automatic failover under failure scenarios in which it was not previously possible: when the primary’s host has either failed completely or become isolated. When this occurs, the backup can take over because the arbiter confirms that it too has lost contact with the primary; the primary, if it is up, stops acting as primary, eliminating the possibility of both failover members acting as primary.

    In prior versions, when one of these failure scenarios occurred, the backup had no way to distinguish between primary failure and network isolation, and thus could not ensure that the primary would no longer act as primary; by default, the backup could not take over automatically in this situation. Under special conditions, automatic failover could be enabled in this situation by adding a user-provided IsOtherNodeDown entry point to the ^ZMIRROR routine and clearing the Agent Contact Required for Failover setting. However, implementing a completely reliable mechanism for confirming the primary down was difficult, if not impossible in most environments. As a result, most users of this method accepted some risk that both failover members could simultaneously act as primary in certain cases, however rare.

    Starting in 2015.1, this mechanism is eliminated and replaced by arbiter-based failover mechanics. The built-in arbiter feature generally provides better response to failure scenarios, in a completely safe manner, and without custom coding. In 2015.1, the Agent Contact Required for Failover setting is removed and the IsOtherNodeDown entry point of ^ZMIRROR will no longer be used. Sites using IsOtherNodeDown^ZMIRROR must enable the arbiter in order for automatic failover on primary host failure to occur in 2015.1.

    Upgrading an existing mirror to 2015.1 and enabling the arbiter requires the following steps:

    1. Identify a system to act as arbiter, as described in Locating the Arbiter to Optimize Mirror Availability in the Caché High Availability Guide. (A single arbiter can be shared by multiple mirrors.)

    2. Install and configure an arbiter as described in Installing the Arbiter in the same document. This involves minimal software installation and does not require that Caché be installed.

    3. Upgrade the mirror members as described in Minimum Downtime Upgrade with Mirroring in the Caché Installation Guide.

    4. Configure the mirror to use the arbiter as described in Editing or Removing a Failover Member in the Caché High Availability Guide.

  • Corrections For Selecting Async Members When Managing Names And Promoting

    The code in ^MIRROR which shows a numbered list of mirror names as part of promoting and managing authorized IDs for async members has been modified. It now works properly when there are mirror members with numeric names. Previously, there could be confusion about whether the numeric name was a numbered choice in the list or the name of a member. When managing Authorized IDs, adding a member is now a separate operation triggered by entering Add (and a valid name) when prompted for a member name to manage. Otherwise, the response is first treated as a member name, and then as (potentially) an choice from the numeric list.

  • Changes Made To Mirror Monitor Status Reporting

    In the Mirror Monitor, there are several reporting changes:

    • in the section titled “Mirror Member Status”, there are new values reported for “Journal Transfer Latency” and for “Dejournal Latency”.

    • the “Mirrored Databases” section now shows new values for “Status”.

    • the “Latency” column of “Mirrored Database Status” has been renamed to “Next Record To Dejournal”.

    • the renamed column contains the Timestamp, File Name and Journal Offset position in the mirrored database. The fields are separated by commas (,).

    Please refer to the High Availability Guide for detailed explanations of the status values.

  • Remove Encrypted Communication Setting From ^MIRROR Utility

    In previous versions, individual mirror members could be configured to use SSL independently of other members by using the Encrypt Communication setting on each mirror member. In this release, this setting is removed from the mirror configuration screens.

    InterSystems instead recommends configuring the mirror to require SSL for all members by setting the Use SSL option. The Encrypt Communication setting is preserved on members during upgrade and can be managed via the Config.MapMirrorsOpens in a new tab class, but systems using this option should change to the recommended Use SSL option as soon as practical.

  • Prevent Logins To Failover Mirror Members At Startup

    On failover mirror members, the system wide security parameter, Inactive Limit, is set to zero each time the mirror member starts up. This parameter controls the interval during which unused accounts are marked as disabled. To prevent accounts from getting disabled on the backup mirror member, this is set to zero to disable the feature. If a disaster recovery member is promoted to a failover member, it will be set to zero at that time as well.

    Sites depending on this to clean up idle accounts must employ a different strategy in a mirror.

  • Maximum Mirror Members Is Now 16

    With this release, the maximum number of mirror members within each mirror set is increased from 8 to 16.

    Important:

    In order to properly implement this change, all the members of a mirror set must upgrade to this version.

Journaling Changes

Before this release, the system was set to freeze on a journal error after 10 seconds of journal inactivity while there is pending journal I/O. In this version, the time limit is increased from 10 seconds to 30 seconds. At the 10-second mark, this warning message is generated in cconsole.log:

Journal Daemon has been inactive with I/O pending for x seconds

Customers expecting the previous, shorter timeout need to adjust the threshold.

Remove %Service_Object:U From Public Permission In A Normal Security Install

For security reasons, %Service_Object:U is no longer a public permission in a normal security installation. %Service_Bindings clients will need a role with %Service_Object:U to use %Service_Object. %Developer and %Manager have this permission, and others can be added as needed. Users of Studio on a normal security installation must have a role with %Service_Object:U.

Rename <NOCATCH> Error To <THROW>; Change Exception Object Handling

The <NOCATCH> error that happens when there is a THROW and no matching TRY/CATCH to catch it has been renamed to <THROW>. Furthermore, the object will now be saved in the special variable $THROWOBJ instead of being immediately closed. This will allow an error trap to access the object to determine how to proceed.

An uncaught exception object is now persistent until $THROWOBJ is cleared. If the exception object holds resources that need to be released, there could be an issue with the longer life of the object. The error trap should set $THROWOBJ to the empty string to close the exception object (and release resources) when it no longer needs it.

Disallow DO/GOTO With +Offset In CACHESYS % routines

It is now illegal to attempt to enter %-routines in the CACHESYS database using the +offset syntax of DO and GOTO. A <NOLINE> error will be thrown when this is detected.

SYS.Agent.VerifyConnection Now Returns A %Status Value

The return value for a failed VerifyConnection() call has changed. Instead of “0”, the result will be a %Status value. This should only cause an incompatibility if application code is comparing the return value of this method directly to “0” instead of using a boolean operator. For example:

If ##class(SYS.Agent).VerifyConnection() = 0 

will now not work if VerifyConnection fails. Successful verifications will return $$$OK; that is identical with the value 1, so unchanged.

CacheSSH Return Value Changes

The %Net.SSH.SFTPOpens in a new tab class has a method Dir() that will enumerate the contents of the remote directory. In previous releases, the default behavior was to return directory entry names beginning with “.”, such as “.”, “..”, and “.rc”. Now, following the convention of the SFTP interface, these files are excluded by default. The prior behavior can be restored by setting the new, optional 4th argument to Dir() to true.

Note:

If the application supplies a specific pattern for matching names, that will take precedence over the default behavior.

Class Descriptor Cache More Carefully Managed

Previously, Caché set the maximum size of the shared class cache to a percentage of the number of the routines in the system. If this number was set too large, it could use all of the shared heap for class caching when a lot of unique classes were called. In this release, the shared class limit is set to 900.

This should not be a problem if a small and fixed set of classes are actually used in the system. If larger set of classes is used, the system may not cache all of the classes. This instance may affect performance. If so, the cached class limit can be adjusted manually; please contact the InterSystems Worldwide Customer Support (WRC)Opens in a new tab.

ZSAVE In XECUTE Does Not Switch To New Routine

When run from a command prompt, the ZSAVE switches the current routine to the one named in the command. In prior releases, it was possible to execute the statement

XECUTE "ZSAVE SomeRoutine"

and switch to a new routine. However, when this is done inside an XECUTE, it frequently caused crashes because of uninitialized variables.

Beginning with this release, the command does not switch to the new routine.

Error Purge Task Uses Local Databases, Not Namespaces

The ^ERRORS global is purged periodically by a system task. In prior releases, when the task ran, it purged the ^ERRORS global for each namespace where the default database was local to the machine on which the task ran. This caused issues in the case when databases existed but there was no namespace defined for it. In this case, the ^ERRORS global would not get purged, and could grow large.

In this release, the task now loops through each database defined on the local system (as defined by the [Databases] section in the .cpffile. For each database which is defined, the following conditions are checked:

  • The database is an ECP database.

  • The database is mirrored, and the system running the task is not the primary.

  • The database is read only.

  • The database is dismounted.

If any of these condition are true, the purge is skipped for that database. For the last condition, if the database has not yet been mounted by the system, then Caché will attempt to mount it so the condition can be tested.

Shared Libraries Now Managed With Reference Count

In previous releases, a single call to $ZF(-4, 2, <LibraryHandle>) would unload the library immediately, even if more than one class had loaded the library with $ZF(-4, 1, <PathToLibrary>) or if the library had been loaded by a call to $ZF(-6, <index>, <Function>, <arg1>, <arg2>, ...).

Now, a reference count of the number of times a library has been loaded with $ZF(-4, 1) is maintained. Each call to $ZF(-4, 1, <PathToLibrary>) increases the reference count. Each call to $ZF(-4, 2, <LibraryHandle>) decrements the reference count, and unloads the library if the reference count goes to zero.

The behavior of $ZF(-4, 2) with no library handle argument, which unloads all libraries, is unchanged. All libraries are unloaded immediately without regard to the reference count.

There is now a degree of independence between loading libraries by $ZF(-4, 1, <PathToLibrary>) and by $ZF(-6, <index>, <function>, <args>) where the library index was previously established by a call to $ZF([-4, 5 or 7], <index>, <path>). Libraries loaded with $ZF(-4, 1, <path>) are not unloaded by a call to $ZF(-4, 4, <index) and libraries loaded implicitly with $ZF(-6, <index>, <function>, <args>) are not unloaded by $ZF(-4, 2, <LibraryHandle>). However $ZF(-4, 2) with no <LibraryHandle> argument will unload all libraries regardless of how they were loaded.

%SYS.ProcessQuery – ClientNodeName, StartupClientNodeName, And Current Device Lengthened

In previous releases, the value for ClientNodeName, and StartupClientNodeName were truncated to 32 characters, and the value for Current Device was truncated to 24 characters. In this release, all three can now be to 64 characters in length before truncation occurs.

Clarification For Unified Trigger Mechanism

Unified trigger support for Objects and SQL was introduced in version 2014.1. When a field or property that is a stream is referenced in a trigger definition, the value of the reference is the OID of the stream.

  • For a trigger designated as BEFORE INSERT or UPDATE, if a new value is specified by the INSERT, UPDATE or %Save operation, {StreamField*N} will be either the OID of the temporary stream object, or the new literal stream value.

  • For a BEFORE UPDATE trigger, if a new stream value is not specified for the field or property, {StreamField*O} and {StreamField*N} will both be the OID of the current field or property stream object.

$SYSTEM.TSQL Validation Added

The “Set” methods in $SYSTEM.TSQL now validate the parameter values passed to them. The “Get” methods no longer take parameters because they were redundant.

^%SYSMONMGR Menu Change

Option #4, “Manage Sensor Readings” in ^%SYSMONMGR has been relabeled as “Manage Debug Data”.

The Character Sequence || Is Not Allowed In Global Mappings

When defining global mappings, the character sequence “||” is not allowed anywhere in the mapping.

Java Virtual Machine (JVM) Version Requirements

As of this release, Caché functions that depend on the Java Virtual Machine require a JVM version of 1.7 or later.

Docserver Application Now Disabled

Beginning with this release, the application /csp/samples/docserver will be disabled by default on upgrades and new installations.

Platform-specific Items

This section holds items of interest to users of specific platforms.

Windows
  • Make Instance Values Consistent With UNIX®

    Instance status values displayed by “ccontrol all” have been changed on Windows to be consistent with the values displayed on UNIX®. Specifically, the status text “ab” has been changed to “ ”. The space value indicates the instance is probably partly up without ^STU completing and logins are disabled. (The complete set of instance status values are displayed by “ccontrol help”).

    Instance status values displayed by “ccontrol list” have also been changed on Windows to be consistent with the values displayed on UNIX® and OpenVMS. Specifically, the status abbreviated text has been expanded to full words. The status text is documented in the web page displayed by “ccontrol help”.

  • Change To Pattern-Matching For 8–Bit Locales

    In prior versions, the undefined characters in the Windows Code Pages (CP12xx) which lay in the range 128-159 were matched only by the pattern code, “1E” (match any character). Beginning with this release, they will also be matched by “1C” (match a control character). The purpose of this change is to allow programs to easily filter these characters in order to avoid garbled terminal output. By code page, the specific character affected are:

    • CP1250: 129, 131, 136, 144, 152

    • CP1251: 152

    • CP1252: 129, 141, 143, 144, 157

    • CP1253: 129, 136, 138, 140, 141, 142, 143, 144, 152, 154, 156, 157, 158, 159

    • CP1255: 129, 138, 140, 141, 142, 143, 144, 154, 156, 157, 158, 159

    • CP1257: 129, 131, 136, 138, 140, 144, 152, 154, 156, 159

    CP1256 has no undefined characters in the range 128-159; and CP1250 already had its undefined characters marked as non-printing (but not as control characters). For information on pattern-matching, see the pattern-matching operators in Using Caché Objectscript guide.

  • Caché Service Account Need Not Be In Windows Administrator Group

    The Caché service account, in which most Caché processes run on Windows, no longer needs to be a member of the Windows Administrators group. The account designated as the Caché service account during installation will be made a member of a "CacheServices" group. The CacheServices group grants its members a limited set of rights needed to start, stop and control the Caché instance. Membership in the group is also granted when the Caché service account is changed with the

    cinstall setserviceusername <InstanceName> <username> <password>
    

    This change should have no effect if you choose to run Caché as the local system account or as an administrative user account. If you elect to run Caché under a non-administrative user account, you may need to insure that the Caché service account (or the CacheServices group) has been granted sufficient (read/write/execute) access to all directories where databases, journal, and log files reside, and has appropriate access to the files themselves.

UNIX®
  • Recommendation to Set TZ Environment Variable for Linux Platforms

    On Linux platforms, InterSystems recommends that you set the TZ environment variable, which indicates the time zone. If this variable is not set, there can be significant degradation of the performance of Caché time-related functions. For details on setting this variable, see the man page for tzset.

  • Non-Root Installation No longer Permitted

    Beginning with this release, Caché installation must be done by the root userid.

Red Hat Enterprise Linux 7 for Power System-64

This operating system version on this platform does not currently support Perl or Python.

SUSE Linux 12 Linker Change Affects Light C++ Binding

A change in the linker on SUSE 12 systems prevents Light C++ binding applications from building. The SUSE 12 linker now requires application makefiles to explicitly specify dependent libraries of other libraries with which they link, even if those other libraries specified the dependent libraries when they were linked. In this case, libcachet.so depends on libpthread.so, so starting with SUSE 12 Linux, both libraries must be explicitly specified. Therefore, one of the following changes is needed to successfully build the application:

  1. Add –lpthread to the library specifications in the ld or g++ command line in the makefile used to build the application. For example, if using a makefile based on one of the Master.mak files installed with Light C++ Binding sample applications, change the line:

    CACHETLIB = -L$(CACHETPATH) -lcachet 
    

    to

    CACHETLIB = -L$(CACHETPATH) -lcachet –lpthread
    
  2. Set the environment variable MULTITHREADED to 1 in the environment in which make is invoked. In the Bourne shell, the syntax is:

    export MULTITHREADED=1
    

Either option resolves the issue; they do not conflict with each other, so both options can be used together.

OpenVMS
  • Change Naming Of JOBs In OpenVMS

    In OpenVMS, the JOB command allows you to specify a process name. If this process name already exists, the JOB command would throw a <SYSTEM> error, and as a result also produce a stack dump log (a CERRSAVE-pid.LOG file). Beginning with this version, the error has been changed to an <INVALID ARGUMENT> error; no log file is produced.

    This is an incompatible change for those applications that check for a specific return code.

  • Java-Dependent Facilities Now Unavailable

    This release stipulates that the minimum required version for Java is 1.7. Since the last Java release for OpenVMS is version 1.6, all capabilities (such as Zen Reports) that depend on access to a Java Virtual Machine (JVM) are no longer available.

Mac OS X

InterSystems has followed the Apple switch from the use of GCC to Clang/LLVM; however, it was not clear which C++ Standard Library should be used. So Caché supports the use of two versions:

  • libc++ – LLVM's newer, C++11 compliant version

  • libstdc++ – The GNU version

Applications can use both versions in the same program, but cannot mix and match them; that is they cannot pass a std::string from one to a function in the other. Because Caché uses custom char types it explicitly uses the older GNU libstdc++

Any C++ users linking with ODBC, or any Objective-C users using ObjectiveCache, should see no differences; however C++ binding users may need to add “-stdlib=libstdc++” to their build flags if they use any of the C++ binding APIs that handle classes from the std:: namespace (such as std::string).

Developers

This section contains information of interest to those who have designed, developed and maintained applications running on prior versions of Caché.

The items listed here are brief descriptions. In most cases, more complete descriptions are available elsewhere in the documentation.

Routine Changes

Rename %SYS.GSIZE to %GSIZE

Applications that called %SYS.GSIZE will need to go back to calling the original name, %GSIZE, making it again part of CACHELIB. Users that do not have privileges for a database should not be able to see what globals are present, or their sizes.

Routine Compiler Changes

Changes To Handling Of Comments Inside Statements

Consider the following two statements:

          _________A________      _________B________

Line 1    If (i = 1) {}           If (i = 1) {}
Line 2    ElseIf (i = 2) {}       ElseIf (i = 2) {}
Line 3    // comment              ;;  comment
Line 4    Else Set I = 5          Else Set I = 5


The “A” statement sequence is illegal and will not compile because it contains a Caché IF...ELSEIF statement followed by a legacy ELSE statement; the comment on Line 3 of A is ignored, so combining Caché IF syntax with a legacy, line-oriented IF syntax is illegal.

Prior to this release, the “B” sequence would compile because the “;;” comment on line 3 terminated the syntax analysis of the Caché IF statement which allowed the legacy ELSE syntax to be accepted as legal.

Now “;;” comments are accepted following a close bracket and the “B” statement sequence is analyzed just like the “A” sequence. This will now generate a syntax error if it is compiled.

Class Changes

Class Deletions

The following classes were present in the previous version and have been removed in this release

  • %CSP.UI.Portal — UsersParameters

  • %CSP.UI.Portal.Dialog — DatabaseWizardEMS, ServiceConnections

  • %CSP.UI.System — AuditPane, AuditSearchPane, ManageAuditPane

  • %DeepSee.DomainExpert.components — MetadataValues

  • %Net.Remote.Java — JDBCGateway

  • %SYS — Monitor

  • %iKnow.Classification — ClassifierProjection, LinearBuilder, NaiveBayesBuilder

  • %iKnow.Classification.Definition — Term, Transformation

  • %iKnow.Compiler — LexrepIdeographicStateOutputFunction, MetadataTable, PreprocessOutputFunction

  • %iKnow.Objects.tfidf — MetadataAnalyzer

  • %iKnow.Queries — EquivAPI

  • %iKnow.UI — ITablesLoadingWizard

  • %iKnow.UI.Dialog — Classifier

  • %iKnow.ont — SourceMatches, TableGenerator, TableManager

  • SYS — Volume

  • Security — Common

Class Component Deletions

The following class components have been moved or removed in this version from the class where they were previously found.

Class Type Name(s)
%CSP.Documatic.CubeInfo method DrawOverLvl, DrawOverProp
%CSP.Portal.Template method ZStripW
%CSP.Portal.standardDialog method ZStripW
property EMSGroupName, IsEMSGroup
%CSP.UI.Component.RoleMemberTab property SelectedItems, emsGroupName
%CSP.UI.Component.SQLPrivileges property emsGroupName
%CSP.UI.Component.SQLTables property emsGroupName
%CSP.UI.Component.abstractRoleTab property emsGroupName
%CSP.UI.Portal.Applications.Web property PermittedClassTitle
%CSP.UI.Portal.Database property isMirror
%CSP.UI.Portal.DatabaseTemplate method LoadErrorMessage
property OldReadOnly, RestartMessage
%CSP.UI.Portal.Dialog.EncAddAdmin method ZStripW
%CSP.UI.Portal.Dialog.RemoteDatabase method ServerIsManaged, changeServerEMS
property MsgNotManaged
%CSP.UI.Portal.Dialog.Service method showConnections
%CSP.UI.Portal.EncryptionDatabase method doSetDefault
property lblSetDefault
%CSP.UI.Portal.Mirror.Dialog.AsyncEdit method DrawEncrypt, SaveData, doSave
%CSP.UI.Portal.Mirror.EditFailover method DrawMemberInfoTable
property OtherMemberECP, OtherMemberName, OtherMemberPrivateAddress, ThisMemberECP, ThisMemberName, ThisMemberPrivateAddress
%CSP.UI.Portal.Mirror.JoinAsync method changeSSL
%CSP.UI.Portal.NLS method saveLocale
%CSP.UI.Portal.SQL.Home property FILTER
%CSP.UI.Portal.Shadow method refreshTable
%CSP.UI.Portal.Template property EMSGroupName, IsEMSGroup
%CSP.UI.Portal.ViewLog property FILENAME
%CSP.UI.Portal.iKnow.Dialog.AddDomainConfig method browseSelect, changeLang
%CSP.UI.System.MappingsAPI method DrawMapJS, PrepareInsert
%CSP.UI.System.Mirror property MemberStatusList, MirroredDatabaseList
%DeepSee.DomainExpert.queries.IK method %DefAtuiClassName
%DeepSee.PMML.Builder.AbstractBuilder method GeneratePMMLAsString, GeneratePMMLClass
%DeepSee.PMML.UI.ModelTester method BuildRowDetailsQuery, CheckSQL, DrawCategorizedText, DropTestResults, ExportToCubeDefinition, GetConfusionMatrix, GetTestResults, OnGetSQLAccuracy, OnGetSQLCatValDetails, OnGetSQLErrors, OnGetSQLScatter, changeModel, export, launchExport, onCatValElementClick, onTestModel, setConfusionMatrixValue, showText, test, updateCatValDetails
property currentActualValue, currentPredictedValue, currentRowId, customSQL, definitionClass, highlightedSentencesOnly, mode, modelType, testId, verParamPrecision, verParamZeroThreshold
%DeepSee.Report.UI.BuildLIDR method reallySaveDCR
%DeepSee.Report.UI.abstractIconBar property titleList, valueList, widgetList
%DeepSee.Report.UI.alignIconBar property titleList, valueList, widgetList
%DeepSee.Report.UI.arrangeIconBar property titleList, valueList, widgetList
%DeepSee.Report.UI.editIconBar property titleList, valueList, widgetList
%DeepSee.Report.UI.layerIconBar property titleList, valueList, widgetList
%Installer.InstallerWizard method ZStripW
%Library.CacheSQLStorage method %BuildIndices
%Library.CacheStorage method %BuildIndices
%Library.Persistent method %CheckUnique
%Net.Remote.Gateway method %PopDeviceStack, %PushDeviceStack
property DeviceStack
%Net.Remote.Java.XSLTGateway method ConnectGateway
%Net.Remote.ObjectGateway method GatewayState
%SYS.Monitor method RefreshSensors, SaveSensors
%SYS.Task.PurgeZENReports property FileLifeTime
%SYSTEM.Process method KillAllPrivateGlobals
%SYSTEM.WorkMgr method SignalAll, StopWorkers
%UMLS.Utils method getLanguges
%ZEN.Portal.assistedText method ServerCallOnUpdateDataServer
%ZEN.Template.AddInWizard.Template method ZStripW
%ZEN.Template.WebServiceWizard method ZStripW
%iKnow.Classification.Builder method %AddTerm, %GetCategoryPosition, %GetTermPosition
property Categories, Terms
%iKnow.Classification.Definition.ClassificationMethod property localTermMetric
%iKnow.Classification.Definition.Term property value
%iKnow.Classification.IKnowBuilder method %GetCategoryFilters
%iKnow.Classification.LinearBuilder property CategoryGlobalTermWeights, CategoryLocalTermMetric, CategoryLocalTermWeights, CategoryNormalization
%iKnow.DeepSee.UI.Analysis.Entities method AnalyzeString, GetChartData, GetLabelX, RemoveEntity, UpdateCharts, getChartDataClient, getLabelXClient, onChangeMetricClient
property termIndex
%iKnow.ont.Matcher method GetATUI
Config.ComPorts parameter EMSLISTQUERY
Config.CommonMapMethods parameter EMSLISTQUERY
Config.CommonMethods parameter EMSCHANGEBIT, PROPERTIESMAYBEINCPF
Config.CommonMultipleMethods parameter EMSLISTQUERY
Config.Databases parameter EMSLISTQUERY
Config.Debug parameter EMSLISTQUERY
Config.DeviceSubTypes parameter EMSLISTQUERY
Config.Devices parameter EMSLISTQUERY
Config.ECPServers parameter EMSLISTQUERY
Config.LicenseServers parameter EMSLISTQUERY
Config.MapGlobals parameter EMSLISTQUERY
Config.MapPackages parameter EMSLISTQUERY
Config.MapRoutines parameter EMSLISTQUERY
Config.MapShadows parameter EMSLISTQUERY
Config.Mirrors property ACKRequirement, AgentContactRequiredForTakeover, TroubleTimeout
Config.Namespaces parameter EMSLISTQUERY
Config.Shadows parameter EMSLISTQUERY
Config.SqlSysDatatypes parameter EMSLISTQUERY
Config.SqlUserDatatypes parameter EMSLISTQUERY
Ens.Enterprise.Portal.MonitorStatus method DrawMsgBankLinks, showDetails
Ens.Util.Documentation method BuildVMSFileURL
SYS.Monitor.Health.SensorObject property MaxValue
Security.Applications property HyperEvent
Method Return Changes

The following methods have different return values in this version of Caché:

  • %iKnow.Utils.MaintenanceAPI — BlacklistContainsElement

  • %iKnow.Utils.MaintenanceQAPI — BlacklistContainsElement

  • %iKnow.Utils.MaintenanceWSAPI — BlacklistContainsElement

  • SYS.Agent — VerifyConnection

Method Signature Changes

The following methods have different signatures in this version of Caché:

Class Name Method Name(s)
%CSP.UI.Component.ApplicationRoles AssignRole, RemoveAllRoles, RemoveRole
%CSP.UI.Component.RoleMemberTab AssignRoles, RemoveAllRoles, RemoveRole, doRemoveAllRoles, doRemoveRole
%CSP.UI.Component.SQLPrivileges AssignPrivs, RemoveAllPrivs, RemovePriv
%CSP.UI.Component.SelectBoxUtils DrawArrows, DrawAvailableList, DrawSelectList
%CSP.UI.Component.UserRoles AssignRoles, RemoveAllRoles, RemoveRole
%CSP.UI.Portal.Applications.PrivRoutine AddRoutine, RemoveRoutine
%CSP.UI.Portal.Applications.Utils Delete
%CSP.UI.Portal.Applications.Web BuildAutheArray, CopyApp
%CSP.UI.Portal.Audit.EventsTemplate ChangeStatus
%CSP.UI.Portal.Audit.UserEvents Delete
%CSP.UI.Portal.Config.Advanced SaveData
%CSP.UI.Portal.Config.AdvancedList DeleteData
%CSP.UI.Portal.Config.ValueEditor SaveData
%CSP.UI.Portal.Database changeJournal, changeReadOnly
%CSP.UI.Portal.Dialog.DatabaseDelete DisableEnsNamespace
%CSP.UI.Portal.Dialog.DatabaseWizard validateSize
%CSP.UI.Portal.Dialog.EncAddAdmin SaveData
%CSP.UI.Portal.Dialog.LicenseActivate Activate, DrawCurrent, PrepareActivate
%CSP.UI.Portal.Dialog.RemoteDatabase CheckDBName
%CSP.UI.Portal.Dialog.SQLView SaveData
%CSP.UI.Portal.Dialog.ShadowDBMapping MapShadowExists
%CSP.UI.Portal.Domains Delete
%CSP.UI.Portal.ECPDataServers DeleteServer
%CSP.UI.Portal.EncryptionDatabase SetDefaultKey
%CSP.UI.Portal.EncryptionManage doAdd
%CSP.UI.Portal.License.Utils DrawFile, DrawLicense, GetLicenseInfo
%CSP.UI.Portal.LicenseServers DeleteData
%CSP.UI.Portal.NLS CopyNow, DeleteNow, GetLocaleDesc, GetLocaleDescription, ReloadDefault, SaveNow
%CSP.UI.Portal.Namespace doNew
%CSP.UI.Portal.PhoneProviders Delete
%CSP.UI.Portal.Resources Delete
%CSP.UI.Portal.Roles Delete
%CSP.UI.Portal.SQL.Home SaveFilter, updateTreeItems
%CSP.UI.Portal.Shadow DeleteMap
%CSP.UI.Portal.Shadows DeleteData
%CSP.UI.Portal.Users Delete
%CSP.UI.Portal.iKnow.Configurations doClose, doDelete, doSave
%CSP.UI.Portal.iKnow.Dialog.AddDomainConfig SaveConfig
%CSP.UI.System.ExpResultPage CopyMapsFrom
%DeepSee.Component.pivotTable GetCurrentQueryText
%DeepSee.PMML.Model.NaiveBayes GetLikelihoods
%DeepSee.Report.UI.QueryBasedDSS updateGroupings
%DeepSee.Report.UI.schemaEditPanel addDBItemFromDrag, autopopulateDBItem, makeNode
%DeepSee.TermList %ImportCSV, %WriteCSVRecord
%DeepSee.extensions.modelling.Processor applyModel, applyOperation
%Dictionary.ClassDefinition %LockId
%Dictionary.CompiledClass %LockId
%Dictionary.CompiledConstraint %LockId
%Dictionary.CompiledConstraintMethod %LockId
%Dictionary.CompiledForeignKey %LockId
%Dictionary.CompiledIndex %LockId
%Dictionary.CompiledIndexMethod %LockId
%Dictionary.CompiledIndexProperty %LockId
%Dictionary.CompiledInstanceVar %LockId
%Dictionary.CompiledMethod %LockId
%Dictionary.CompiledParameter %LockId
%Dictionary.CompiledProjection %LockId
%Dictionary.CompiledProperty %LockId
%Dictionary.CompiledPropertyMethod %LockId
%Dictionary.CompiledPropertyUDLText %LockId
%Dictionary.CompiledQuery %LockId
%Dictionary.CompiledQueryMethod %LockId
%Dictionary.CompiledStorage %LockId
%Dictionary.CompiledStorageData %LockId
%Dictionary.CompiledStorageDataValue %LockId
%Dictionary.CompiledStorageIndex %LockId
%Dictionary.CompiledStorageProperty %LockId
%Dictionary.CompiledStorageSQLMap %LockId
%Dictionary.CompiledStorageSQLMapData %LockId
%Dictionary.CompiledStorageSQLMapRowIdSpec %LockId
%Dictionary.CompiledStorageSQLMapSub %LockId
%Dictionary.CompiledStorageSQLMapSubAccessvar %LockId
%Dictionary.CompiledStorageSQLMapSubInvalidcondition %LockId
%Dictionary.CompiledTrigger %LockId
%Dictionary.CompiledUDLText %LockId
%Dictionary.CompiledXData %LockId
%Dictionary.ForeignKeyDefinition %LockId
%Dictionary.IndexDefinition %LockId
%Dictionary.MethodDefinition %LockId
%Dictionary.ParameterDefinition %LockId
%Dictionary.ProjectionDefinition %LockId
%Dictionary.PropertyDefinition %LockId
%Dictionary.PropertyUDLTextDefinition %LockId
%Dictionary.QueryDefinition %LockId
%Dictionary.StorageDataDefinition %LockId
%Dictionary.StorageDataValueDefinition %LockId
%Dictionary.StorageDefinition %LockId
%Dictionary.StorageIndexDefinition %LockId
%Dictionary.StoragePropertyDefinition %LockId
%Dictionary.StorageSQLMapDataDefinition %LockId
%Dictionary.StorageSQLMapDefinition %LockId
%Dictionary.StorageSQLMapRowIdSpecDefinition %LockId
%Dictionary.StorageSQLMapSubAccessvarDefinition %LockId
%Dictionary.StorageSQLMapSubDefinition %LockId
%Dictionary.StorageSQLMapSubInvalidconditionDefinition %LockId
%Dictionary.TriggerDefinition %LockId
%Dictionary.UDLTextDefinition %LockId
%Dictionary.XDataDefinition %LockId
%Library.CacheSQLStorage %LockId
%Library.EnsembleMgr EnableNamespace, createMappings
%Library.FunctionalIndex SegmentFinalize, SegmentInitialize, SegmentInsert
%Library.GlobalEdit GetGlobalSizeBySubscript
%Library.GlobalStreamAdaptor Read
%Library.ListOfDataTypes DisplayToLogical, LogicalToDisplay
%Library.Persistent %BuildIndices, %LockId
%Library.RoutineMgr getPackageList
%Net.Remote.Proxy %Constructor
%SOAP.WST.BinarySecret Create
%SQL.CustomResultSet %OnNew
%SYSTEM.Encryption MD5HashStream, SHA1HashStream, SHAHashStream
%SYSTEM.SQL SetSQLStats, SetSQLStatsJob
%SYSTEM.Util GetSessionId
%Stream.TmpCharacter Read
%Studio.General Execute
%Studio.Project InstallFromGbl
%Studio.SourceControl.Change DisplayUncommitted
%UMLS.Utils GetChildrenAsRS
%ZEN.Auxiliary.jsonSQLProvider %WriteJSONStreamFromSQL
%ZEN.Component.dateText showDateSelector
%ZEN.Component.tablePane executeQuery
%ZEN.Report.Display.call %DrawToHTML
%ZEN.Report.Display.callsvg %DrawToHTML
%ZEN.Report.Display.category %DrawToHTML
%ZEN.Report.Display.class %DrawToHTML
%ZEN.Report.Display.cssinclude %DrawToHTML
%ZEN.Report.Display.fo %DrawToHTML
%ZEN.Report.Display.group %DrawToHTML
%ZEN.Report.Display.html %DrawToHTML
%ZEN.Report.Display.img %DrawToHTML
%ZEN.Report.Display.init %DrawToHTML
%ZEN.Report.Display.inline %DrawToHTML
%ZEN.Report.Display.line %DrawToHTML
%ZEN.Report.Display.list %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.masterreference %DrawToHTML
%ZEN.Report.Display.node %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.p %DrawToHTML
%ZEN.Report.Display.pagebreak %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.pageendsidebar %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.pagefooter %DrawToHTML
%ZEN.Report.Display.pageheader %DrawToHTML
%ZEN.Report.Display.pagemaster %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.pagestartsidebar %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.report %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.section %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.table %DisplayTableByRowsFO
%ZEN.Report.Display.write %DrawToHTML, %DrawToXSLFO
%ZEN.Report.Display.xslinclude %DrawToHTML
%ZEN.Report.Display.xslt %DrawToHTML, %DrawToXSLFO
%ZEN.Report.RenderServer GetState
%ZEN.Report.SplitAndMerge %DisplayPDF
%ZEN.SVGComponent.treeMapChart plotItems
%iFind.Find.Basic ResolveCompCombArray, ResolveStemmedCombArray
%iKnow.Classification.Builder %GenerateClassifier, %LoadFromDefinition, %OnGenerateClassifier, %PopulateTerms
%iKnow.Classification.IKnowBuilder %TestClassifier
%iKnow.Filters.ContainsEntityFilter %OnNew
%iKnow.Filters.ExternalIdFilter %OnNew
%iKnow.Filters.GroupFilter %OnNew
%iKnow.Filters.RandomFilter %OnNew
%iKnow.Filters.SourceIdFilter %OnNew
%iKnow.Matching.DictionaryAPI CreateDictionaryItem, CreateDictionaryItemAndTerm
%iKnow.Matching.DictionaryQAPI CreateDictionaryItem, CreateDictionaryItemAndTerm
%iKnow.Queries.SourceAPI GetSummaryForText
%iKnow.Queries.SourceWSAPI GetSummaryForText
%iKnow.UI.AbstractSourceViewer ProcessInput
Ens.DataTransformDTL Transform
Ens.Deployment.Utils GetItemContentsByItemNumber
Ens.Director IsProductionRunning
Behavior Change For ##class(%Library.%File).ParentDirectory()

This release modifies ##class(%Library.%File).ParentDirectory() so that, if you supply it a filename rather than a directory name, it will return “”. Previously it returned the parent directory of the caller which was confusing.

%Net.HttpRequest Now Honors charset Values For All Types

The %Net.HttpRequestOpens in a new tab class will now honor the CharSet value in an HTTP response even if the Content-Type is not “text/”. This allows the type “application/json” to be decoded correctly even if it specified the “utf-8” charset. Also according to RFC2616, there is no restriction to applying the charset only for text content.

Note:

This is a slight change in behavior and is correct according to the standard. You can revert to old behavior by setting the ReadRawMode property to 1.

Allow Tasks To Continue After An Error

In this release, there is a new property, SuspendOnError in Tasks. Previously, all Tasks were suspended if they returned an error status. Now, by default, Tasks will be rescheduled and continue to run after an error. To revert to the old behavior, users can mark SuspendOnError as “Yes” in either the management portal or ^TASKMGR.

New Return Value From $SYSTEM.Lock.ReturnCode()

This change adds a new return code for the method, $SYSTEM.Lock.ReturnCode(). It can now return a value of 4 indicating that the lock has already been escalated. This new value indicates the lock node has been escalated in an earlier lock command, whereas a value of 2 indicates the lock escalation was triggered by the lock command.

Class Compiler Changes

This version of Caché continues the work begun in earlier releases of improving the class compiler. The changes that may require changes to applications are detailed in this section.

Recursive Property Types Explicitly Illegal In Serial Classes

The type of a property in a serial class cannot be recursive, meaning the type class cannot be the container class or any primary super or sub class of the container class. For example, it is invalid to define a property in Sample.Address whose type is Sample.Address.

This change should not cause significant issues since this model would not previously have worked at runtime. Caché never supported SQL projection of recursive serial types. This change does report a new error at compile time while earlier versions allowed such classes to successfully compile.

Correct Handling Of Optimized Method Calls In DataType Classes

The release corrects an error in resolving a method call of the form “DO ..otherMethod()” when the target method is defined in both the local class and a declared datatype class.

Consider a data type class defined roughly as

Class User.DataType Extends %String
{
    Parameter PARAM = "HELLO";

    ClassMethod someMethod()
    {
        Write ..#PARAM,! 
        Do ..otherMethod()
    }

    ClassMethod otherMethod()
    {
        Write ..#PARAM,!
    }
}

It has a parameter defined with a default value of “HELLO”,and a classmethod (someMethod) that calls otherMethod which just writes out this parameter value.

Now consider a normal class the uses this datatype class:

Class User.User 
Extends %RegisteredObject 
{
    Property Prop As DataType(PARAM = "MYVAL");
}

In previous releases, the sequence of statements

SET A = ##class(User).%New()
DO A.PropsomeMethod()

would display

MYVAL
HELLO

This is wrong because it should write out MYVAL twice. However, the normalization of the “Do ..otherMethod()” was calling into the User.DataType class itself rather than calling the 'PropsomeMethod' member method declared locally.

In this release, the compilation of this call now correctly invokes the local member method so running the compiled code will now output MYVAL twice as it should. This also allows a classmethod member method to call a different private classmethod because it would be in the same class context, whereas today this generates an error.

While it is unlikely someone wants the existing behavior, there is a chance someone expects the method in the member class to be called rather than the local method. To accomplish this, replace the “Do ..otherMethod()” with “Do ##class(User.DataType).otherMethod()” and it will behave as before.

Simplify Work Queue Handling

In this release, the class compiler no longer signals its worker jobs using the SignalAll function because, in very busy systems, not all worker jobs may be involved in the current compilation. This release also removes the StopWorkers call for the same reason.

Language Binding Changes

Objective C Binding For Caché Uses New Runtime

A newer runtime for Objective-C necessitates the following changes in Caché –

ISCConnection

The new way to construct an ISCConnection is:

ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" user:@"sys" password:@"system"];

and for a secure connection:

ISCConnection* conn = [ISCConnection connectionTo:@"127.0.0.1[1972]:SAMPLES" principal:@"principal" level:1];

ISCDatabase

The new way to construct an ISCDatabase is:

ISCDatabase* database = [ISCDatabase databaseWithConnection:conn];

where conn is a previously established connection.

ISCConnectionPool

The new method for setting up a connection pool is:

ISCConnectionPool* pool = [ISCConnectionPool pool];
CacheProvider Omits Code Generation For System Classes

In previous releases, the generated proxy classes for .NET contained many APIs that are not really meant to be used from the client (for example, ODBCToLogical and LogicalToODBC conversions). This change adds a way to remove these APIs from the generated code. The dotnet_generator now has an option -skip-system-apis (true|false). If set to true (the default), only the user's APIs are generated which results in generated code that takes one–third the space as before.

Support For Typed Collections Of Object Properties

This release allows groups of Caché Objectscript objects to be projected as collections of types. For example, a class property defined as a %Library.ListOfObjects of type T is projected as CacheListOfObjects<T>. Similary, a %Library.ArrayOfObjects of T is projected as CacheArrayOfObjects<T>. This change removes the need for most casts related to projection of collections.

This change also deprecates the recursive version of ListOfObjects.OpenAllObjects() because this call may force the client to instantiate the generic (not template) versions of CacheListOfObects or CacheArrayOfObjects for server objects where the generated code now requires CacheListOfObjects<T> or CacheArrayOfObjects<T>.

Note:

One limitation of this change is that if a collection is instantiated in a context where the type of its elements is unknown (for example, if the collection is returned from a method), the proxy class will be CacheListOfObects or CacheArrayOfObjects (without a template). If the same object is used later in a context where the element type is known and expected, it will cause an exception because by then the “wrong” proxy object is already in use and cannot be automatically replaced. Such cases should be very rare.

CacheProvider Adds Overloaded Methods For Open() And OpenId()

Code such as

Prop = obj.Property
...
Prop.Close()

which intended to unswizzle a property will now cause subsequent calls of obj.Property to return the null value even if the value on the server is not null. This is because obj owns the property and the property is automatically closed when obj is closed. A more correct way to accomplish this is to use the call to the new UnswizzleProperty(<PropertyName>) method.

Make CacheADOConnection Public For Direct ADO .NET Use

CacheConnection inherits from the CacheADOConnection class that provides all the ADO.Net functionality. CacheConnection allows an application to use both ADO and the DotNet Object binding via the same connection. While this is useful for many applications, it adds overhead in terms of extra messages to the server and the creation of internal objects inside the provider.

The XEP and Entity Framework connections each only relies on CacheADOConnection and the functionality it provides. DbConnection is the generic way used for DbFactory connections in ADO.Net, and is fully supported within CacheADOConnection. CacheConnection object adds no additional value when these generic ADO APIs are used, only overhead.

This change ensures that CacheConnection continues to function as it always has, but now ADO applications can just use CacheADOConnection directly if they do not use the object binding side of CacheProvider. In addition, CacheFactory will return CacheADOConnection objects with less overhead. ADO functionality will continue to work with either CacheConnection or CacheADOConnection, so users do not need to change their applications.

There are some public APIs of CacheConection that will not be present in CacheADOConnection. All of the required ADO.Net APIs will be contained within CacheADOConnection, but application writers may have taken to mixing APIs supplied by the object side of the CacheProvider. In that case, they may just continue using the CacheConnection class has they have been.

SQL Changes

Replace OIDs For $LISTs In Streams With $LIST Contents

Beginning with this version, it is now possible to store $LIST values in stream fields via SQL. This change also corrects a problem where the insertion of binary data into a binary stream field might fail if the binary data resembled a $LIST value (that is, $LISTVALID(value) was True).

In previous versions, if a $LIST value was inserted or updated as a stream value, Caché assumed the $LIST value was the OID of a another stream that would be copied into the target stream. This is because, by default, select queries that include stream fields in non-external tables return the OID of the stream object. An application that wanted to insert/update the value of a stream field with a value it selected from another stream field, would just open the given stream OID and copy the stream value.

Now, an SQL INSERT or UPDATE of a stream field with a value that is a $LIST value will no longer treat the $LIST value as the OID of a source stream for the value of the new stream. You must open the source stream and insert/update the field using the value of the OREF of the source stream. This does present a backwards incompatibility if applications are inserting or updating stream fields with the OID of a stream source. The compatibility issue is necessary in order to insert binary data that mimics a stream value or store $LIST data into a stream.

Require Parentheses Around Tables In FOR SOME Predicate

The syntax for the little used FOR SOME predicate has been changed to avoid ambiguity in the Caché SQL syntax. Previously, the syntax for the predicate was:

FOR SOME <tables> (<search condition> ...)

and now it will be necessary to express it as

FOR SOME (<tables>) (<search condition> ...)

Any application using the older FOR SOME <tables> syntax will need to add parentheses.

Note:

This has no effect on the commonly used FOR SOME %ELEMENT syntax..

New SQL System Privileges

With this version, there are four new general SQL privileges that can be assigned to users or roles on a per namespace level:

  • %NOCHECK — allows the user to run INSERT or UPDATE or DELETE commands with %NOCHECK.

  • %NOTRIGGER — allows the user to run INSERT or UPDATE or DELETE commands with %NOTRIGGER.

  • %NOINDEX — allows the user to run INSERT or UPDATE or DELETE commands with %NOINDEX.

  • %NOLOCK — allows the user to run INSERT or UPDATE or DELETE commands with %NOLOCK.

These privileges only apply to the usage of the respective keywords in the restriction clause of the INSERT, UPDATE, or DELETE statements. It does not apply to the use of %NOINDEX as a preface to a predicate condition. Like all other SQL privileges, this is only enforced through ODBC, JDBC, %SQL.StatementOpens in a new tab, and %Library.ResultSetOpens in a new tab. You must have the appropriate privilege to use the restriction clause when preparing the statement.

Since TRUNCATE TABLE <tablename> performs a delete of the rows from the table with %NOTRIGGER behavior, TRUNCATE TABLE <tablename> now also requires the %NOTRIGGER privilege in order to run.

Important:

This change may cause backward compatibility issues with current applications, but since these restriction clauses can lead to logically corrupt data, InterSystems has decided to move forward with this feature to better protect the integrity of customer data.

Correct Queries With Multiple JOINs Of <Column>=<Constant> Conditions

This release contains a correction for queries such as

SELECT t . test_code 
FROM test . person p , test . test_result t 
WHERE p . hospital_id = ? 
AND    p . person_id = ? 
AND    t . hospital_id = p . hospital_id 
AND    t . person_id = p . person_id

where there is

  • a join between two tables with 2 or more join conditions;

  • and, for each such join, there is also <column>=<constant> condition on one of the columns of the join.

In previous releases, the SQL parser generated incorrect query plans for such requests. That error has ben corrected in this release.

Correction To Query Processing Using Timestamps

Prior to this release, an application that executed a query where:

  • it included a filter in the WHERE clause like “TimeStampField > CURRENT_TIMESTAMP”

  • TimeStampField was not a typical %Library.TimeStampOpens in a new tab value

  • the class instance of TimeStampField implemented LogicalToTimeStamp and TimeStampToLogical methods to convert from its logical format to the %TimeStampOpens in a new tab logical format

may have received incorrect results from the query. This error has been corrected in this release.

Changes To Query Plans

In this release, the query processor will produce more accurate plans due to improved selectivity accounting in cases where some conditions imply other conditions. A typical instance of this is a query such as:

SELECT *
FROM T1, T2 
WHERE T1.k = T2.k AND T1.k > 5

In this case, the optimizer derives the fact that T2.k > 5 is also true. It also notes that if conditions are tested in the order (T1.k > 5, T1.k = T2.k, T2.k >5), the last condition is redundant and does not add extra selectivity. Similarly, if the order of condition testing is: (T2.k > 5, T1.k = T2.k, T1.k > 5), a similar situation applies. However, if the order of condition testing is (T1.k > 5, T2.k > 5, T1.k=T2.k) then the last condition does need testing, but it adds less selectivity than it would in the other orders of testing. Prior to this release, there was no way for selectivity to be handled properly for this last case.

The result of this change is that plan changes will be somewhat common; most will be better, but some may be worse.

SQL Reserved Words Updated

The following words have been reserved in Caché SQL in prior releases, but not reported as such by $SYSTEM.SQL.IsReservedWord():

%CLASSNAME, %ID, %KEY, %MINUS, %MVR, %ODBCIN, %PLUS, 
%RUNTIMEIN, %RUNTIMEOUT, %SQLSTRING, %SQLUPPER, 
%TABLENAME, %TRUNCATE, %VALUE, %VID

This release adds them to the list; and removes CATALOG as a reserved word.

DELETE %NOINDEX Changes

In prior releases, the SQL directive DELETE %NOINDEX has always been a no-op. Beginning with this release it will no longer delete the index entries defined for the deleted rows.

Changes To %SYS.PTools.UtilResults

Previously, the Index Analyzer page in the Management Portal would recalculate the different options every time you clicked on the radio button. Now the table can hold results for all four options and the data is only cleared when new SQL Statements are gathered. The first time you click on an option, the system generates the data, but thereafter just redisplays it.

If an application is querying the data, it can now limit the results returned by setting the value of the new property, OptionName. The four allowed values are:

  • “IU” — Index usage

  • “TS” — Table scans

  • “TI” — Table indices

  • “JI” — Join indices

Improved Checking When Connections Specified

When linked tables are defined as part of a class, the SQL processor now checks to make sure that all the values necessary to make the connection to the table are supplied as well. If this is not the case, then SQL error –162 (“SQL Connection is not defined”) will be produced.

Changes To Locale And I/O Translation Tables

Change In Default Collation For Spanish Locales

Spanish4 is now the default collation in the Spanish locales (espw, esp8, esi8, esw8) for local arrays and new databases. This new collation orders upper and lower-case letters separately; the characters follow this order:

a, á, à, b, c, ç, d, e, é, è, f, g, h, i, í, j, k, l

m, n, ñ, o, ó, ò, p, q, r, s, t, u, ú, ü, v, w, x, y, z
Note:

The previous Spanish collation tables are still available, and the collation for previously existing databases remains unchanged.

New Maltese Collations Created
Maltese1

A Maltese Unicode locale (mltw) and collation (Maltese1) are now available in this release. The collation has the following characteristics:

  • Cases are ordered separately, all uppercase precedes all lowercase

  • The main ordering is (in lowercase, uppercase is correspndingly similar):

    a b &cdot; c d e f &gdot; g g&hstrok; h &hstrok; i ie j k l m n o p q r s t u v w x  z ż
    
  • The letters with a dot above (c, g and z) are equivalent to the non-dotted versions but all else being the same they collate before the same letter without the dot

  • “g&hstrok;” collates as a single character between “g” and “h”

  • “ie” collates as a single character between “i” and “j”

  • “&hstrok;” is equivalent to “h” but collates after

Although not present in the Maltese alphabet, latin letters “c” and “y” collate in their respective positions as in English; all other accented letters (such as “á”, “é”, “ã”, and so on) not in Maltese collate after the alphabet (same as in Caché standard).

Maltese2

A new collation, Maltese2, is also available in the Maltese Unicode locale. It has the same encoding as Maltese1 but doesn't include the double-letter characters “għ” and “ie”.

New I/O Translation Tables For Unicode ↔ CP437, CP850, and CP852

This release contains new I/O translation tables between Unicode and locales CP437, CP850 and CP852. These tables were added to the Unicode locales whose 8-bit versions are based on Latin1 or Latin2. More specifically, the following Unicode locales have the new tables:

  • csyw – Czech, Czech Republic

  • danw – Danish, Denmark

  • deuw – German, Germany

  • engw – English, UK

  • enuw – English, US

  • espw: Spanish, Spain

  • finw – Finnish, Finland

  • fraw – French, France

  • hunw – Hungarian, Hungary

  • itaw – Italian, Italy

  • nldw – Dutch, Netherlands

  • plkw – Polish, Poland

  • ptbw – Portuguese, Brazil

Upgraded Collations For Some Locales

The default collation in the following 8-bit locales has been upgraded to a new version that fixes minor problems in the older version (such as failing to account for some character sequences collate as a single character – “ll” in Spanish, and “ss” in German):

  • csw8: Czech2/CP1250 → Czech3

  • huw8: Hungarian1/CP1250 →Hungarian2

  • esw8: Spanish2/CP1252 → Spanish3

  • esi8: Spanish2/Latin9 → Spanish3

The German4 Locale Is Removed

The German4 locale has been removed from the system in this release since it proved to be functionally equivalent to German3.

Magnetic Tape Translation Table Changed For Russian Locale

The default translation for the magnetic tape device has been changed from RAW to UTF8 in the Russian Unicode locale (rusw). This is allows the labels of backups to tape to contain Cyrillic characters without further modifications.

Translation Table For Latin9 ↔ Unicode Updated

The tables that translate between Latin9 and one of the Unicode encodings (UnicodeBig, UnicodeLittle, and UTF8) incorrectly mapped $CHAR(128) to U+20AC (the Euro sign). This mapping is used in many of the Windows CP tables, but not in Latin9, in which the Euro sign is $CHAR(164). In these Latin9 translation tables $CHAR(128) now passes unchanged.

New JSON Translation Tables Added

This release adds two new NLS translations: JSON and JSONML. They are similar to JS and JSML respectively, but have the following differences on the output side:

  • Characters with codes 0 to 7, 11 and 14 to 31 are escaped as \uXXXX.

  • Characters with codes 39 and 47 pass unchanged.

Update Handling Of Unicode LINE SEPARATOR And PARAGRAPH SEPARATOR

On Unicode systems, the characters LINE SEPARATOR ($CHAR(8232) = U+2028) and PARAGRAPH SEPARATOR ($CHAR(8233) = U+2029) are now escaped as "\u2028" and "\u2029", respectively, when passed through one of the JavaScript translations (JS, JSON, JSML, and JSONML) when used for example in $ZCONVERT.

iKnow Changes

Correct Handling Of Coded Dictionary Terms

If a Dictionary Term is composed of multiple elements, and these include both format and non-format elements (through use of the “coded” description of the format for adding composite terms), the dictionary term was not correctly saved in the internal data structures when the dictionary was optimized. This led to matching against the format and non-format parts separately, which could in turn lead to separate matches for the same term on the same CRC or path.

Customers who have used the advanced “coded” description feature to insert mixed terms (consisting of both format-based and non-format-based elements) must recreate these dictionary terms for this correction to take effect.

Changes To ( Previously Experimental) PMML Modeling

Model-building capabilities were added as an experimental feature in 2014.1. Users who built applications to take advantage of this will find that some helper methods for generating PMML models have moved to the PMML model class from the Builder class. In addition,

  • Generation of PMML “along the way” by different operators now happens where appropriate, resulting in a PMML file representing all operators executed

  • A “Call” operator to execute arbitrary code as part of a modelling sequence is now present

  • A “TypeColumn” property has been added in the Attributes configuration element to enable per-attribute specification of the datatype

  • When instantiating a new row as part of a Sequence operation, a PMML model will no longer explicitly set all attributes to 0, but rely on InitialExpressions to populate initial values (0 for %IntegerOpens in a new tab and %DoubleOpens in a new tab columns in the TableGenerator operation)

  • A new “InsertOnly” property is present in the Sequence configuration element, allowing to append to a table already containing data. This means separate Sequence operations can be used to populate different columns of the same data set, as when part of the data comes from an iKnow domain and other parts can be retrieved straight from other sources (metadata)

Web Services And SOAP Changes

Explicitly Set Default Port Value For %Net.HttpRequest In %XML.Sax.Parser

In this release, %Net.HttpRequestOpens in a new tab explicitly sets default port value for %XML.SAX.ParserOpens in a new tab. Prior releases by default used the port for the last request using that %Net.HttpRequestOpens in a new tab object.

XML Changes

Set Character Stream Import LineTerminator Implicitly To $CHAR(10)

This release set the LineTerminator of character streams imported from XML document to $CHAR(10) implicitly, if XMLSTREAMMODE="block" (the default). This makes the import compatible with any traditional newline sequence ($CHAR(10), $CHAR(13), $CHAR(13,10)).

MultiValue Changes

ULTIMATE Emulation Changed Default Setting For STR.ONEISONE

When compiling a MultiValue BASIC program, the $OPTIONS STR.ONEISONE flag now defaults to OFF except for emulations of the legacy IN2 or ULTIMATE systems. Previously STR.ONEISONE only defaulted to ON for the legacy IN2 system. Only the emulation setting at compile-time affects this default; changing the CEMU setting at run time will not override the compile-time emulation setting.

The STR.ONEISONE flag is an alias for the $OPTIONS flags IN2.SUBSTR and T. These three $OPTIONS flags change the behavior of a substring reference of the form StringVar[N]. With any one of these flags, a reference to StringVar[N] is a reference to the single character at position N inside the string contained by variable StringVar. Without any of these flags, a reference to StringVar[N] is a reference to all the string characters starting at position N and extending to end of the contents of the string variable StringVar.

Any customer who uses the CEMU ULTIMATE compile-time setting (or $OPTIONS ULTIMATE in a MV BASIC source routine) and who also depends on the STR.ONEISONE flag being off must now explicitly include a

  $OPTIONS -STR.ONEISONE

statement in their MV BASIC source programs which are affected by this change.

Remove Line Breaks From Base64 Encoded XML As The Default

Beginning with this release, the default is to omit line breaks from base64 encoded XML output in all properties of type %BinaryOpens in a new tab or %xsd.base64BinaryOpens in a new tab. To make line breaks the default,

  • In XMLExport, append “base64linebreaks” to the format argument.

  • In %XML.WriterOpens in a new tab, set the BaseLineBreaks property to 1 (the default is 0).

  • For SOAP web service or web client binary output, set the Base64LineBreaks property to 1 or the BASE64LINEBREAKS parameter to 1. If both the parameters are set, the property overrides the parameter.

BASIC And MVBASIC Changes

Immediately Release MultiValue Process Locks

MultiValue Process Locks (created and released by the MVBASIC LOCK and UNLOCK commands) are supposed to be independent of transactions. However, in previous releases, an UNLOCK command during a transaction would not free the Process Lock until the end of the outermost transaction. Now, a MV BASIC UNLOCK command will release its corresponding Process Lock immediately, regardless of whether there is an active transaction or not.

Any application that depends on the fact that an UNLOCK command would not free the Process Lock until the end of the outermost active transaction will experience a change in behavior. The workaround to restore a semblance of the prior behavior is to replace the Process Lock with a File Lock taken out on a dummy file with a file name related to the name of the Process Lock. Process Locks are now released immediately, even when inside a transaction, but the FILEUNLOCK command inside a transaction will delay the release of the File Lock until the outermost transaction terminates.

WRITEV With Field Number 0 Appends To Beginning Of Record

In prior releases, the behavior of a WRITEV statement specifying an update to attribute number 0 of a record was undefined. Beginning in this release, The MVBasic run-time has been modified so that a WRITEV to attribute number 0 of a dynamic array record appends the new data as a new attribute at the beginning of the record. This new data becomes the leading attribute of the dynamic array and all previous attributes will be moved up one position. This is exactly analogous as assigning a string value to attribute 0 of a dynamic array variable.

xDBC Changes

ODBC 2.5 APIs Removed

The following APIs are no longer exported by the InterSystems ODBC 3.5 driver to address an error where both version 2.5 and version 3.5 APIs were being invoked by the Microsoft Driver Manager:

  • SQLAllocConnect

  • SQLAllocEnv

  • SQLAllocStmt

  • SQLErrorW

  • SQLFreeConnect

  • SQLFreeEnv

  • SQLSetParam

  • SQLTransact

  • SQLGetConnectOptionW

  • SQLGetStmtOption

  • SQLSetStmtOption

Change Of Default C Type In Version 3.5 Driver For Date Time And Timestamp

The ODBC C type SQL_C_DEFAULT (99) can be used in calls to SQLBindColumn and the ODBC driver determines the proper C type based on the SQL_TYPE specified. The ODBC 3.5 standard changed the SQL_TYPES for Date, Time and Timestamp from 9, 10, and 11 to 91, 92, and 93, respectively. When SQL_C_DEFAULT(99) is specified as the C type, Caché internally calls SetDefaultType(sql_type) which returns the correct C type.

Previously, for the ODBC 3.5 version of the InterSystems driver, Caché did not detect the SQL Types for date,time and timestamp with values of 91, 92, and 93, and returned the C type as SQL_C_CHAR. This caused an error at runtime. Now SetDefaultType(sql_type) is changed to detect SQL_TYPES for Date, Time and Timestamp from 91, 92, and 93, respectively and to return the corresponding C types: SQL_C_TYPE_TIME, SQL_C_TYPE_DATE, SQL_C_TYPE_TIMESTAMP (91, 92, 93).

DeepSee Changes

Meaning Of NOW Relative To Time Offset Redefined

Time levels in DeepSee can be configured with a date offset using the "timeOffset" attribute. This feature is explained in the documentation. Prior to this fix, the NOW special member would behave strangely.

Consider the case where years are defined with an offset of “-6m”. This means that

  • 2014 = July 2013 to June 2014

  • 2015 = July 2014 to June 2015

Prior to this clarification, the meaning of "NOW" would change based on the offset. So for the same example, DeepSee would find out that NOW is July 2014, then apply the -6m offset to get January 2014, and then determine which year with a -6m offset January 2014 belongs to, which is 2014. To summarize, selecting NOW will now return the time period that the current date belongs to.

With this correction, if the current date is July 2014, the year level returns 2015 because “NOW” lies in the range of the year 2015 once a negative six month offset is applied to the start of 2015.

Enforced Distinction Between Calculated Members and Calculated Measures

MDX does not make a distinction between calculated measures and calculated members that are not measures. It is practical, however, to make this distinction. In this release, DeepSee distinguishes these items when they appear in crossjoins. Now, of the two sets used in a crossjoin, no more than one of them can contain measures (or items that behave like measures). One set (or both sets) can contain members (or items that behave like members). In this context:

  • A calculated member is considered a measure if it uses AGGREGATE, SUM, MAX, MIN, AVG, or any other function that returns a number.

  • A calculated member is considered a member if it uses %OR.

In previous releases, the following query was valid:

WITH  MEMBER [ColorD].[DEMO] AS 
'AGGREGATE({[COLORD].[H1].[FAVORITE COLOR].&[Blue],
[COLORD].[H1].[FAVORITE COLOR].&[Red],
[COLORD].[H1].[FAVORITE COLOR].&[Yellow]})' 
SELECT NONEMPTYCROSSJOIN([COLORD].[DEMO],[Measures].[Test Score]) ON 1 FROM [Patients]

In this release, the same query results in the error:

ERROR #5001: Two measures cannot be crossjoined

As a consequence of this change, you should review any calculated members and consider how they are intended to be used. If a calculated member is intended for use as a member, use %OR. If it is intended for use as a measure, use AGGREGATE or another numeric function. Also, review any queries that use NONEMPTYCROSSJOIN or CROSSJOIN to ensure that you are not inadvertently crossjoining two measures.

Query Change When Excluding Multiple Members of List Level

In this release, DeepSee generates a different query than before, in the case when the user excludes multiple members of a list level. The new form of the query is more expected and is consistent with the query that DeepSee generates when a user excludes a single member of a list level. This change is not a change to the DeepSee engine, but solely a change to how DeepSee generates a query when a user interacts with a filter dropdown (in either the Analyzer or in a dashboard).

For example, consider the Diagnosis level in SAMPLES, which is a list level. In previous releases, if a user selected the asthma and CHD members of this level and clicked the Exclude option, in previous releases, DeepSee added the following filter to the query:

%FILTER EXCEPT([DIAGD].[H1].[DIAGNOSES].Members,{[DIAGD].[H1].[DIAGNOSES].&[asthma],[DIAGD].[H1].[DIAGNOSES].&[CHD]})

This filter removes records for patients that have only the asthma diagnosis and patients that have only the CHD diagnosis. If the pivot table displays the Diagnosis level as rows, the result is as follows:

Diagnosis Patient Count
None 831
asthma 7
CHD 4
diabetes 48
osteoporosis 24

The patients that have only asthma are not included anywhere in this pivot table, nor are the patients that have only CHD. In this pivot table, the asthma row represents the patients that have the asthma diagnoses in addition to some other diagnosis. Similarly, the CHD row represents the patients that have the CHD diagnoses in addition to some other diagnosis. This is a valid MDX query, but is not the query that the users expected to generate.

In the current release, when a user selects the asthma and CHD members of this level and clicks the Exclude option, DeepSee now adds the following filter to the query:

%FILTER ([DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT,[DIAGD].[H1].[DIAGNOSES].&[CHD].%NOT)

This filter removes records for patients with the asthma diagnosis and patients with the CHD diagnosis. If the pivot table is currently displaying the Diagnosis level as rows, the result is as follows:

Diagnosis Patient Count
None 831
diabetes 37
osteoporosis 18

In past releases, DeepSee used the %NOT function when a user excluded a single member of a list level, and DeepSee still does this. For example, when a user selects asthma and clicks the Exclude option, DeepSee adds the following filter to the query:

%FILTER [DIAGD].[H1].[DIAGNOSES].&[asthma].%NOT

This filter removes records for patients with the asthma diagnosis.

Export Of Zero-Padded Numbers Changed To Be Strings

Beginning in this release, DeepSee allows a format attribute of property in KPI to be defined as a “%string%” and the Excel export of such a property will be in accord with the format. That is, a property definition such as

<property name="EnfUnit" displayName="EnfUnit" columnNo="3" format="%string%"/>

will now export a number of the form 0008 to Excel as a string and not a number.

Cube Registry Now Requires A Name

Beginning with this version, there is now a dialog that opens on the first load of the Cube Registry. This will prompt the user to enter a class name that will be used for registry storage, along with options for the top-level, registry-wide settings. If a registry had been created in an earlier release, you can

  • Reopen the one that existed by entering the default class name, DeepSee.CubeManager.CubeRegistryDefinition, as the new active registry class; or,

  • Define a new registry with the name of your choice, and copy the contents of the Registry XData block of the previous DeepSee.CubeManager.CubeRegistryDefinition.

Separate Save And Task Scheduling Functions

This change removes the scheduling code from the call to %DeepSee.CubeManager.Utils:WriteToRegistry() and places it in %DeepSee.CubeManager.Utils:ScheduleUpdaterTasks(). The return of the latter will now allow for confirming success status of the task scheduling. With this channge, WriteToRegistry() is only responsible for validating and saving a cube registry while ScheduleUpdaterTasks() is responsible for calculating the scheduling requirements and communicating the resulting parameters to the relevant tasks.

CSP Changes

Improve The Parsing Of Individual Component Headers For Multi-Part Request Payloads

In previous versions, it is possible that the Caché streams holding individual components might have been named using the generic CSP Gateway-assigned name of “CONTENT” rather than the name assigned in the hosting form.

This release improves the parsing of individual component headers for multi-part request payloads. More data is now packed into the header lines, and further processing is done on the individual header lines so that the payload (and the associated type information) is accurately transmitted to Caché.

Zen Reports Changes

Table Width Default Changed

Prior to this release, if a table did not have a width specified, Zen Reports supplied a default value of “auto”. Now it supplies a new default value, “100%”. Those reports that relied in the old default must now set it explicitly.

Process Templates In Composite Items

Prior to this release, when templates were included in a composite they were ignored. Now they will be defined. This can lead to conflicts with templates defined in the report.

The work-around when there is a conflict is to remove the template from either the composite or report so it is only defined in one place. Since composites did not support templates before, the easiest fix when such conflicts arise on old report-composite combinations is to delete them from the composite.

The idea is that now XData in a custom class or composite can include XSLT template or variable definitions and these can be referenced in the report. Note that the generation point of the XData is not where the class or composite is included. This is because templates must be defined at the top level of XSLT source.

xyChart Does Not Include Point In Dataset If Y-Value Does Not Exist

In previous releases, if there was a missing y-Value Caché would assign a value of 0 to y, draw the marker point, and lines would go through the marker point if connecting lines were defined in the xyChart. Now, if the y-value is “” or not defined, the (x,y) pair in an xyChart is skipped; there will be no marking point.

Support Configurable Memory For All Batch/Command Files And Java Commands

Beginning with this release, new batch files for producing reports introduce a requirement that one accept the default maximum memory size (-Xmx 512m) or specify an environment variable. Before this, the server scripts contained such argument which means the memory allocated depended on the amount of physical memory on the machine. A better practice is to enforce the specification of a memory size.

In addition, the following environmental variables have been defined:

  • EXCELMEMSIZE, EXCELSERVERMEMSIZE

  • FOPMEMSIZE, RENDERSERVERMEMSIZE

  • PRINTSERVERMEMSIZE

  • SAXMEMSIZE

  • PDFMERGEMEMSIZE

These default to 512m. For servers, the default used to be determined by the amount of physical memory on the machine; this was a bad practice and now servers default to 512m. To get larger memory size, use the environment variables.

Note:

This change is not implemented on OpenVMS.

FeedbackOpens in a new tab