Caché Release Note and Upgrade Checklist Archive
Caché 2015.1
[Home] [Back] [Next]
InterSystems: The power behind what matters   
Class Reference   
Search:    

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:
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:
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.Semaphore, 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:
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 strongly encourages those who incorporate these items in their software to provide feedback on their experiences.
Enterprise Manager
InterSystems will not release an updated version of the Enterprise Manager with Caché and Ensemble 2015.1. Enterprise Manager 2014.1 continues to be available, as an early adopter application, with Caché and Ensemble 2014.1.
If you would like to participate in the early adopter program for Enterprise Manager to exercise its new capabilities such as namespace service, automatic data movement on mapping changes, multi-stage approvals, export/import, and so on, please contact Andreas Dieckow (Andreas.Dieckow@intersystems.com).
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 here 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 paper.
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:
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
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.SFTP 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).
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:
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.
$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
UNIX®
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
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:
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
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é:
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.HttpRequest 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:
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.Statement, and %Library.ResultSet. 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
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:
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:
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:
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:
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):
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:
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,
Web Services And SOAP Changes
Explicitly Set Default Port Value For %Net.HttpRequest In %XML.Sax.Parser
In this release, %Net.HttpRequest explicitly sets default port value for %XML.SAX.Parser. Prior releases by default used the port for the last request using that %Net.HttpRequest 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 %Binary or %xsd.base64Binary. To make line breaks the default,
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:
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
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:
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
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:
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.