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

This chapter provides the following information for Caché 2017.1:

New and Enhanced Features for Caché 2017.1
This section includes:
FIPS 140-2 Validated Cryptography for Caché Data-at-Rest Encryption
This release allows you to configure Caché running on Red Hat Enterprise Linux 64-bit to use a FIPS 140-2 validated library for Caché data-at-rest encryption. For details, see the article FIPS 140–2 Compliance for Caché Database Encryption.
Enhancements to Support for OAuth 2.0 and OpenID Connect
Caché support for OAuth 2.0 and OpenID Connect now includes the following features:
All features that are supported in 2016.2 will interoperate with 2017.1. For example, you can have a client and an authorization server at different Caché versions. The new features, however, will not work with a partner that is at version 2016.2.
In release 2017.1, there are changes in the configuration classes for OAuth 2.0 and OpenID Connect. Caché automatically updates your saved configurations.
DeepSee Improvements
This release includes the following DeepSee improvements:
Mirroring Improvements
This release includes the following Mirroring improvements:
Improved DocBook Search
DocBook search has improvements that can help you find information faster. Search now puts matches found in the most commonly used documents first. The DocBook search page has new options that allow you to limit the scope of your search. To reach the DocBook search page, select Search Page from the documentation home page. It has the following new filters:
Feature Tracker
In 2017.1 we are introducing a safe and trustworthy approach for InterSystems to periodically collect information about the Caché features being used while maintaining the integrity of our relationship with our clients. The Feature Tracker is controlled by a task. By default the task is suspended and Feature Tracker is disabled, but you can easily resume the task. Feature Tracker will help us prioritize which Caché features to enhance based on the features that are used by customers.
The Feature Tracker collects information about instance attributes (product type, version, license, platform, etc.) and use of technology, including ECP, Mirroring, DB Encryption, and SQL. It does not collect information about license utilization, database attributes, applications, errors, authentication, client data, client-specific configuration. Weekly, the Feature Tracker sends the collected data (XML file) to an InterSystems Caché instance using SSL. You may view the most recent collected data to see that this information is trustworthy. If for any reason the Feature Tracker cannot transmit, it fails silently with no impact to the instance.
More information about Feature Tracker can be found in Feature Tracker Collects Usage Statistics, in the Caché System Administration Guide.
Note:
During field test, the Feature Tracker task is active and Feature Tracker is enabled.
iKnow REST API and Other Enhancements
This release introduces a REST API to access iKnow domain information directly from a RESTful client. Many common query API methods are supported through a simple, consistent interface where individual requests can be configured to retrieve rich query results or just the basic data, depending on your application requirements. The iKnow REST API provides reference documentation using the Swagger Specification, which is the foundation of the OpenAPI Specification.
Note:
One method to view the iKnow REST API documentation, is to use Swagger UI, either by directing a web browser to http://petstore.swagger.io/ or by downloading the Swagger UI toolkit. Enter one of the following URLs in the Swagger UI form and then select the Explore button. For a Caché development instance with minimal security, you can enter:
http://localhost:port-number/api/iknow/v1/user/swagger
For a Caché instance with password security, you can enter:
http://localhost:port-number/api/iknow/v1/user/swagger?CacheUserName=user-name&CachePassword=password
In addition, this release includes a significant overhaul of our Knowledge Portal demo interface for exploring your domain’s contents and a number of extensions to the iKnow Architect interface for managing a domain definition.
New Features in Atelier, the Eclipse-Based IDE
Atelier, the Eclipse-Based IDE for Caché, is available on an independent release cycle from Caché. Consequently, new features are described in the Atelier documentation provided with each new Atelier release. The Atelier IDE brings together the powerful and popular Eclipse development environment and the InterSystems Caché database. Atelier allows you to develop Caché applications using a modern file-based IDE on a client system. Atelier handles uploading the application to the Caché server where it can be run and debugged.
The focus of future development will be on the new Eclipse based IDE. Studio will remain an option to install and developers can continue to develop code with it. However, it will be treated as a maintenance product and will not see new functionality added as we move forward with Atelier. Some minor bugs may not be addressed either depending on resources required versus the severity of the issue.
Atelier is available as a separate download in addition to Caché or Ensemble. You can choose to install either a stand-alone Rich Client Platform (RCP) application, or a plug-in that can be added to an existing Eclipse installation. Users of the RCP application can add additional Eclipse plug-ins. Atelier uses the Eclipse auto-update mechanism to help users get the latest changes. For information on downloading Atelier and for the Atelier documentation, see http://www.intersystems.com/atelier, the Atelier home page.
Other Items of Note
In addition, many more minor improvements and corrections are also included. In particular, if you are upgrading an existing installation, please review the detailed list of changes in Caché 2017.1 Upgrade Checklist.”
Areas of improvement include:
Caché 2017.1 Upgrade Checklist
Purpose
The purpose of this section is to highlight those features of Caché 2017.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 2016.2 and 2017.1.
Important:
If you are upgrading from Caché 2008.2 or an earlier version, you cannot upgrade directly to Caché 2017.1, but must first upgrade to an intermediate version. For details, see Supported Upgrade Paths in the Caché Installation Guide.
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 2017.1. The items listed here are brief descriptions. In most cases, more complete descriptions are available elsewhere in the documentation.
Operational Changes
This section details changes that have an effect on the way the system operates.
Increased Default Frame Stack Memory Use on Non-Unicode Systems
In this release, we have increased the frame stack size for non-Unicode instances. This change reduces the possibility that an SQL query that works on a Unicode instance would encounter a frame stack error on a non-Unicode system. This increase typically does not have a large impact on system memory usage, but may cause problems on systems with limited memory. If you encounter problems, you can return to the previous allocation for frame stack size by calling the SetFrameStackSize method during system startup.
On a 64–bit system, enter the following:
 Do $SYSTEM.Util.SetFrameStackSize(1024*112)
On a 32–bit system, enter the following:
Do $SYSTEM.Util.SetFrameStackSize(1024*72)
Must Purge Journal Log if Re-Adding Failover Member to Mirror Set
In previous releases, when a failover member was removed from a mirror set, the journal.log was deleted for the failover member. In this release, this file is not deleted. Consequently, you must run the purge utility before adding the failover member back to the same mirror set. This situation is very unusual for production systems, but you may encounter it on a test system.
Change to Stop Mirroring behavior
Mirroring provides a capability to Stop Mirroring on this member, which causes a non-primary member to temporarily disconnect from the primary, stop dejournaling, etc.
In previous versions mirroring also implicitly restarts (reconnects) if the Caché instance restarts. With this version we change this behavior and users would have to manually start mirroring (reconnect) using either ^MIRROR or the management portal.
Changes in Console Log Messages
In this release the console log contains messages when databases are mounted and unmounted. In addition, some messages have had their wording changed.
Change in How Ensemble Compiles HL7.2 Schemas
In Ensemble 2016.2, Ensemble changed the way it imported and compile HL7.2 schemas. In previous versions, if you imported an HL7.2 schema while the schema was actively being used by a business host, the host could encounter an error during the period between when the old schema was deleted and the new one compiled. The 2016.2 change avoided this error, but, unfortunately, the 2016.2 change caused other problems and Ensemble 2017.1 reverts it. With Ensemble 2017.1 and future versions of Ensemble, the existing HL7.2 schema is first deleted and then the new one is compiled.
With this release the HL7.2 compilation behavior reverts to its behavior in Ensemble 2016.1 and earlier. That is, you must stop any host items that use the HL7.2 schema before replacing the HL7.2 schema with a new version. You can replace a schema either by compiling the schema or by using the Management Portal HL7 schema editor.
Changes in Location of Java JAR Files
The location and organization of the JAR files has changed in this release. See Java and Gateway Changes for details on these changes.
/csp/user Application Settings are Left Unchanged by Upgrade
In previous releases, installing a Caché upgrade would overwrite custom /csp/user application settings and you would have to reapply the settings. In this release, the upgrade does not change these custom settings. If you have automated the process of re-applying these settings after an upgrade, you can remove this part of the process.
Platform-Specific Items
This section holds items of interest to users of specific platforms.
UNIX®
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.
Class Changes
Class Deletions
The following classes were present in the previous version and have been removed in this release:
Removed Methods
The following methods were present in the previous version and have been removed in this release:
Removed Properties
The following properties were present in the previous version and have been removed in this release:
Removed Parameters
The following parmeters were present in the previous version and have been removed in this release:
Removed Indices
The following indices were present in the previous version and have been removed in this release:
Modified Methods
The following methods have different signatures in this version of Caché:
Backup and Restore Changes
DBREST Restores CACHE.DAT Even If the File is Deleted
In previous releases, when you restored a database, EXTALL^DBREST would only restore files that were present in the database directory. Consequently, if you had done a backup and then deleted the CACHE.DAT file or another database from the directory, restoring the backup would not restore the deleted CACHE.DAT or other deleted database. With this release, all databases in the backup will be restored even if the files have been deleted from the directory. If you have a script or code that depends on the previous behavior and assumes that these databases will not be restored, you must modify it.
Class Compiler Changes
Report Error when Noncompiled Class Is Deployed
In this release calling $SYSTEM.OBJ.MakeClassDeployed on a class which is not compiled reports an error. In previous releases, it did not report an error but left the class in a state where it could not be compiled. Any subsequent attempt to use or compile this class would cause an error. However, it you have code that calls MakeClassDeployed and does not attempt to access this class, the code will now encounter an error, while it would have continued executing in previous releases.
Change to Journaling Default Behavior for Class Compiler
In this release if you call the class compiler, the compiler respects the process’s default journaling environment. In previous releases, the class compiler would always journal the change unless you explicitly specified the /journal=0 qualifier. In this release, the default behavior depends on the process environment setting. You can override this setting by specifying the /journal=0 or /journal=1 qualifier.
CSP Changes
Changes to %CSP.REST DispatchRequest and AccessCheck Return Status
In previous releases errors in the AccessCheck and DispatchRequest methods could be ignored. They will now result in an Http500 response.
Handling Hyperevent Status of 0
In this release CSP ignores a return status of 0 after a hyperevent completes. In most cases this condition is usually caused by a page being reloaded before the hyperevent completes. It is possible that CSP may skip displaying a dialog box indicating a network error. In many cases the network error will repeat on the next page load.
DeepSee Changes
Dashboard Widgets Now Required to Have Names
As of 2017.1, DeepSee require each dashboard widget to have a name.
When a developer with editing privileges opens the dashboard, an alert will notify them of the fact that this auto-assign of widget names has taken place and the Modified indicator will appear on the toolbar. Once the dashboard is saved with all of its widgets named, this message will not appear again.
Pivot Table Displays Results in Correct Order
In previous versions, if you specified a crossjoin with a calculated measure in the first position and a setting in the second, CROSSJOIN(M,S), DeepSee would reverse them and display the results as if you had specified CROSSJOIN(S,M). This had the correct values but displayed them in the wrong order. With this change, the values will be displayed in the correct order.
Note:
Since this change alters how the axes are stored in the axis cache, you should clear any queries containing %MDX or %KKPI from the cache. You can clear the cache by using:
Do $SYSTEM.DeepSee.Reset() 
Action Required to Benefit from DeepSee Task Licensing Improvements
In previous releases, the two tasks created for the cube registry consumed a Caché license each. In this release, these tasks do not consume a license, but you must save the Cube Registry to enable this change. To do this, open the Cube Registry page and select Save.
If you have not yet saved the Cube Registry, DeepSee writes a message to the DeepSee log reminding you to save the Cube Registry for the namespace.
Dynamic Object Changes
Changes in How %ToJSON Handles Illegal Numeric Values
To conform to the JSON standard, this release changes the way %ToJSON handles illegal numeric values. In this release, if the dynamic object contains the value $DOUBLE("INF"), $DOUBLE("-INF") or $DOUBLE("NAN"), the %ToJSON method signals the <ILLEGAL VALUE> error. In the previous release, these values would have contained INF, —INF, or NAN in the JSON output. If the %ToJSON() method encounters the value $DOUBLE(-0), the JSON output contains —0.0. In the previous release, the value $DOUBLE(-0) would correspond to the JSON numeric literal 0.
Ensemble Changes
Virtual Document Search Tables Replace | (Vertical Bar) with + (Plus Sign)
In this release, Ensemble replaces | (vertical bars) with + (plus signs) in Virtual Document search tables, such as EnsLib.HL7.SearchTable. When searching for data that contains a vertical bar, you must specify a plus sign in its place. The SearchTable class is implemented using an index that does not allow vertical bars in values. In previous releases, Ensemble did not make this substitution and SearchTable instances that contained a vertical bar could cause SQL errors.
If you have any custom search tables, you must recompile them to get this correction.
Ensemble SFTP Adapter Now Uses Connect Timeout
In previous releases, the SFTP adapter did not have a timeout and could wait indefinitely. In this release, it uses the Connect Timeout setting, which has a default of 5 seconds. If your production is encountering timeout errors, increase the value of the Connect Timeout setting.
Ensemble TCP Duplex Adapter No Longer Uses Private TCP Sockets by Default
The TCP duplex adapter now uses a mechanism other than private TCP adapters. This will be a transparent change to most custom code; however, if your custom code depends on the use of private TCP sockets, pass a parameter of 1 in a call to the adapter’s OpenEventDevice() method. This causes the TCP duplex adapter to use a private TCP socket.
Change in how Ensemble Transformations Handle Missing Source Properties in XML Virtual Documents
In previous releases XML VDoc transformations handled missing source properties by creating a target property with an empty string value, but in this release the target property is omitted and will be missing to match the state of the source property. Both the previous and current behavior returned a missing tag error to the transformation, and both behaviors are ignored if the specify IGNOREMISSINGSOURCE.
If you want the transformation to have the previous behavior, you can insert a DTL action that replaces a missing property with a property with an empty string in the source. One way to do this is with a code action in the form:
$S(source.{propertypath}'="":source.{propertypath},1:"")
Change in How Ensemble Parses XSD with Single Repeating Child
In previous releases when Ensemble parsed an XSD whose root element had a single repeating child element, it collapsed the structure and you could only access the first child. In this release the structure is not collapsed. For example, if the XSD contains:
<schema ...>
  <element name="root">
     <complexType>
       <sequence>
         <element name="outer" minOccurs="1" maxOccurs="unbounded">
           <complexType>
             <sequence>
               <element name="inner" minOccurs="1" maxOccurs="unbounded" type="string"/>
             </sequence>
           </complexType>
         </element>
       </sequence>
     </complexType>
  </element>
</schema>
In this release, to reference the inner element, specify outer().inner(). In previous releases, the reference would have been inner(). If you have code that references an element in this way, you must update your code.
Global Mapping Changes
Report Errors for Subscripts after BEGIN
In a global mapping definition, the BEGIN keyword should not be followed by any subscripts. In previous releases, any following subscripts were ignored. In this release, a BEGIN followed by a subscript fails validation, which may cause errors for mappings. For example GLOBAL("TST",BEGIN):("TST",10000) is valid, but GLOBAL(BEGIN,"xyz"):(END) is not and fails validation.
Java and Gateway Changes
Jar File Name Changes and Removal of Duplicate Location
In this release, we are renaming the jar files as part of a transition to using the Apache Maven repository to distribute jar files. In this and future releases, the file names will include a version number. We recommend that you use Maven (or another build tool such as Ant) to manage file names and paths in your application. The following files have new names:
In previous releases, these jar files were provided in two locations in the install, but in this release they are installed in only a single location:
Ensemble Java Gateway Defaults to JDK 1.8
In previous versions, the Ensemble Java Gateway defaulted to JDK 1.7, but in this release it defaults to JDK 1.8. If you need to continue using JDK 1.7, specify that version in the Java Gateway settings.
Java, DotNet Object, and XLST 2.0 Gateways Support Validated Connections
In this release, you can start the Java, DotNet Object, and XLST 2.0 gateways and require passphrases. If you are connecting from the same Ensemble instance as the gateway and use the %Connect API, %Connect automatically uses the gateway’s passphrase. If you have custom code that accesses a gateway and does not use %Connect, you should modify the code to provide the passphrase or change it to use %Connect. If the gateways do not require passphrases, then your code will run correctly without any changes.
For information on specifying the passphrase parameters when starting a gateway, see the class reference. For example, see EnsLib.JavaGateway.Service.StartGateway() or %Net.Remote.Java.XSLTGateway.StartGateway().
If you are starting the gateway using a command line, you need to do the following to provide a passphrase to the gateway:
  1. Get the passphrase list. For example, if the port is 53912, you can get the passphrase list with:
    Set tPassList=##class(%Net.Remote.Utility).GeneratePassphrase(53912)
  2. Get the HEX passphrase from the list with:
    $LISTGET(tPassList,2)
  3. Run the command line to start the gateway.
  4. Register the passphrase with:
     Do ##class(%Net.Remote.Utility).RecordPassphrase(53912,tPassList) 
Address Setting Changes for Java, XSLT2, and Java-Based Object Gateways Used in Ensemble Productions
In previous releases, in the Java, XSLT2, and Java-based Object Gateways, you could specify the address in any one of three ways:
In this release, specifying local-machine-name can prevent the gateway from being started if local-machine-name resolves to an address other than 127.0.0.1. In that case, you must modify the gateway business service settings to use the 127.0.0.1 or localhost address.
Starting a Java, XSLT2, or Java-Based Object Gateway for Use by Another System
If you will be using a Java, XSLT2, or Java-Based Object Gateway that uses the Java Gateway from another system, you now must explicitly start the gateway and cannot rely on the default start mechanism. For example, you could use the following command line to start the Java gateway. (The command line is broken into multiple lines because it is very long, but should be entered as a single line.)
java.exe -Xrs -classpath 
.;H:\intersystems\EnsLibMaint\dev\java\lib\xml\saxon9.jar;H:\intersystems\EnsLibMaint\dev\java\lib\JDK18\cache-gateway-2.0.0.jar;H:\intersystems\EnsLibMaint\dev\java\lib\JDK18\cache-jdbc-2.0.0.jar
com.intersys.gateway.JavaGateway "61785"  "" "" "192.168.224.100" 2>&1
JAR Directory Set Automatically from the JVM Version
In previous versions, the JDKVersion was set by a property and other properties specified the location of the JAR files. In this version, we detect the Java version by examining the system default Java based on the $PATH value and use its version number to locate the correct Caché JAR file directory. Consequently, we have deleted some settings and moved related settings. If you have any code that directly accesses these properties or script that assumes a location for the JAR files, you will have to update it.
Language Bindings .NET Changes
Generate Exception for Mismatched Quotation Marks
In previous releases, the ADO.NET binding would allow a string to be started with a single quote and terminated with a double quote. In this release, this is considered an error and will fail. For example the statement
"update PL31359T set VC = VC || 'qwerty\" where VC is null"
will fail.
Migration
Must Re-run FM2Class Utility for files with computed fields or some word processing list collections
The structures generated the FM2Class for certain structures have changed in this release. If you have generated classes with the FM2Class utility to select data from computed fields or word-processing that are mapped as list collections, you have to re-run the FM2Class mapper to generate the correct code. If you only mapped word processing fields as child tables, the structures have not changed and you do not have to regenerate the classes.
Object Changes
OnRollBack Method is now called Even if Serialization Fails
If you implement %OnRollBack() method, it is now called during a transaction rollback on objects that were serialized during the transaction even if the serialization failed. In previous releases, the %OnRollBack() method was called only for objects which were successfully serialized. If your %OnRollBack() implementation assumes that the object was successfully serialized, you should modify it to handle the case where the serialization failed. In addition, if VERSIONPROPERTY was updated during the transaction, the rollback restores VERSIONPROPERTY to its pre-transaction value.
The %BuildIndices Method Rebuilds Bitmap Extent Index
In this release %BuildIndices rebuilds the bitmap extent index in some circumstances that previous releases would not have rebuilt. This ensures that the index data is current, but may use additional resources if the bitmap extent index is not needed.
Compiler Catches SQL Undefined Conditional Map
In this release the compiler catches classes with a conditional map and a null condition and produces a descriptive error message. In Caché 2015.1, 2015.2, 2016.1, and 2016.2, this compile would fail but there would not be a useful error messages. In Caché 2014.1 and earlier releases, the class compiled without an error but created invalid .int code.
ObjectScript Changes
Allow Proxy to Add By-Reference Arguments to List
If an intermediate routine receives arguments using the args... syntax and passes those arguments on to another routine using args... any new entries added to the args array will now be passed by reference. In previous releases the added entry was always passed by value so any subnodes were ignored and any change by the lower level routine did not affect the caller's arguments. If the intermediate routine is sensitive to changes made in the added arguments you will have to change the code.
Change in Length of Bit String after Rollback
In prior versions, when a $bit set was rolled back, an attempt was made to restore the old length of the bit string if possible. In some cases this would kill the global node. In this version, Caché does not attempt to restore the old length, as this could not be done consistently in all cases. Applications using $bit and related function to access the bit string global nodes do not depend on this behavior. The exception is using $bitcount function to count zero bits. It is unusual not recommended for an application to count zero bits of a bitstring, but such applications may see a change in behavior. For details, see Bit Strings in Using Caché ObjectScript
Security
LDAP Security Controlled on System-Wide Basis
LDAP cached credentials are now on or off on a system-wide basis. In previous releases, you could apply them on a per service or per application level.
SQL Changes
Correction to INSERT and UPDATE Compiled in Display Mode
In rare cases, INSERT and UPDATE can be compiled in DISPLAY mode. In previous releases, Caché was not correctly converting values for INSERT and UPDATE compiled in DISPLAY mode. This has been corrected. If you use #SQLCompile Select=DISPLAY mode in your embedded SQL for INSERT or UPDATE and your input values are in Logical mode, you should update your application code to change the mode to logical or to supply display values as input.
JDBC Return Value Change for Auto Generated Key Value for Multi-Property IDKEY Index
JDBC can automatically generate a key value if any of the IDKEY values is system assigned. For example, if JDBC inserts into a child table with a childsub counter field, it can auto generate a key value. In previous releases, JDBC returned the auto-generated ChildID, the childsub counter field value. This was not sufficient to identify the row just inserted. In this release, JDBC returns a string consisting of the ParentID followed by “||” and then the ChildID. This is sufficient to identify the newly inserted row. However, if you have code that is processing the return value consisting of just the ChildID, you should modify your code to use the new return value.
Make Child Table Read-only If Some Indexes Are Not Projected
In this release if a child table has any indexes that are not projected, the table is read-only and you cannot perform an insert, update, or delete on the table. In previous releases, it was possible to perform these actions, but that action could corrupt an index. If a table projected from the MVSASSOCIATION includes an indexed property, it will be marked as read-only.
New SQL.JDBC Parser
We have replaced the SQL.JDBC parser with one that has significant performance improvements. We believe that it should produce the same results as the parser in previous releases, but there is the possibility that some unusual SQL statements will produce different results.
SQL JDBC UpdatableResultSet Reports Deletions More Consistently
In previous releases, Caché did not adhere to the JDBC specification on how our metadata reports updateable resultsets behavior when records are deleted. In this release, Caché handles these deletions more consistently and follows the behavior described in the specification.
SQL JDBC SysList and SysListProxy Deprecated
The SysList and SysListProxy classes are deprecated. They are included in this release, but we recommend that you replace them with the CacheList, CacheListBuilder and CacheListReader classes.
Do Not Recalculate Computed Field When Field Is Updated But Value is Unchanged
In previous releases an SqlComputeOnChange field computation would be triggered even if the value for the field updated was the same as the previous value. In this release, the computation is done only if one of the field values changes.
Corrective Action for Frozen Plans Created with Earlier Versions of Caché
If you created a plan with Caché 2016.2 and the plan contains any INSERT ... SELECT statements, you need to take actions to correct an error in the plan data.
If you upgrade from Caché 2016.2 to Caché 2017.1 or a later version, these plans will exhibit the following behavior:
System Changes
Correction to $BitLogic xor Operator Can Change Results
In previous releases undefined bits in the highest byte of the $BitLogic xor operator could produce incorrect results. This problem has been corrected.
Performance Improvements with Large Routines Increase Memory Usage
In this release, Caché has improved performance handling large routines with many public variables. This change increases the amount of memory Caché uses. In rare instances if you have a memory-constrained system, the increased memory requirements may cause other performance issues.
Changes Handling Named TCP Pipes on Windows System
In previous releases if the server opened a named pipe and attempted to write before the client opened the same pipe, the write operation caused an error. In this release, the write operation waits for the client to open the pipe.
Studio Changes
Change in Key Combination for Formatted Paste
In previous releases, you could do a formatted paste Ctrl/Alt/V using either the left or right Alt key. To avoid a conflict with another key combination on Czech keyboards, in this release you can only use the left Alt key.
Unit Test Changes
Routines Are Not Preserved Between Suites in a Test Run
In previous releases, the Unit Test Manager did not delete routines between suites in a test run. In this release, the manager deletes .MAC, .INT, .INC, .OBJ, and .BAS routines that it loaded. It does not delete .MVB or .MVI routines. If you have code that depends on routines being preserved, you should modify your code.
Unit Test Manager Supports UDL Files
In this release the unit test manager supports UDL files exported by Atelier, as well as XML files from Studio. UDL files have file types .cls, .mac, .int, and .inc. By default the Unit Test Manager will look for and load both UDL and XML files in the test directory. The new qualifiers /loadxml=0 and /loadudl=0 may be used to prevent the loading of either type.
Web Services Changes
Support Use of HTTPS Protocol for WS-Policy Bindings
In this release SOAP web services supports WS-Policy symmetric and asymmetric bindings. These bindings require an SSLConfiguration. If you specify a symmetric and asymmetric binding without an SSLConfiguration, you will encounter an error. In previous releases, the HTTPS protocol would have been downgraded to an HTTP protocol and would have not encountered an error from the missing SSLConfiguration.
XML Changes
SendRequestToGateway Method Signature Changes
In this release the %Net.Remote.Java.XSLTGateway.SendRequestToGateway() signature has changed. The method now requires an instance of Net.Remote.Java.XSLTGatewayRequest, which encapsulates all of the previous arguments, as well as some additional ones, in a single object. If you have custom code that calls SendRequestToGateway(), you must modify the code.
XML Processing Encounters Error from Buffer Overrun
In this release, the %XML.SAX and %XML.XLST parsers prevent a buffer overflow and throw an exception if one would occur. In previous releases this overflow was not detected and could cause serious problems. However, in some cases the buffer overflow would not cause problems and the operation would appear to execute correctly. Under these circumstances, an operation that appeared to work correctly in the previous version will encounter an exception and fail. If you encounter a length error exception reading a stream, it indicates an error in the stream Read method, which should be corrected.
Memory Changes Handling XML
This release of Caché contains changes in how XPATH is processed for XML. Under most circumstances, these changes reduce the memory required, but under some circumstances, they increase the memory required. In memory-constrained systems, this change may cause performance problems.
Zen Changes
White-space Setting Removed from <pre> Element
In previous releases, setting white-space to normal was always done for the <pre> element. This was a side-effect of a previous fix and caused problems in some Zen pages. In this release, this white-space setting is no longer applied to <pre> elements. If you have CSS definitions that rely on this white-space: normal; setting, you should modify the CSS and explicitly set the white-space to normal.