Caché Release Notes and Upgrade Checklist
Upgrade Checklist for Caché 2018.1
[Home] [Back] 
InterSystems: The power behind what matters   
Class Reference   

The purpose of this chapter is to highlight those features of Caché 2018.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 2017.2 and 2018.1.

If you are upgrading from Caché 2008.2 or an earlier version, you cannot upgrade directly to Caché 2018.1, but must first upgrade to a version between Caché 2009.1 and Caché 2016.2. For details, see Supported Upgrade Paths in the Caché Installation Guide.
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 2018.1. The items listed here are brief descriptions. In most cases, more complete descriptions are available elsewhere in the documentation.
Operational Changes
Mirroring: Allocating Space for Write Image Journaling (WIJ) Files
This release contains a new parameter, Target size for the wij, in the system configuration journal settings. Setting this target size ensures that space is allocated for the WIJ early in the start-up process. If sufficient space is not allocated early and there is not enough available memory for the WIJ, the system may encounter problems. Allocating space for WIJ is an advanced configuration setting. If you encounter issues with this, contact the InterSystems Worldwide Resource Center.
Mirroring: Changes to JRNDUMP Utility Navigation
The JRNDUMP utility has improved navigation. If you have a script that responds to JRNDUMP prompts, you should check the script to ensure that it handles the changed navigation.
Platform-Specific Items
This section holds items of interest to users of specific platforms.
Windows Upgrade Installation Does Not Create USER Namespace if Previously Deleted
In previous releases, if, on a Windows system, you upgraded Caché where the USER namespace had been deleted, the installation would create a new USER namespace. In this release, the installation will not create a USER namespace if it was previously deleted from the instance. This is typically the desired behavior, but, if you have a script that automatically deletes the USER namespace after an upgrade, you may need to modify the script. The Windows install now matches the behavior of Caché installations on other platforms, that is, if the instance does not have a USER namespace, the upgrade does not create one.
Debugging Changes
Debugger on AIX Breaks After True Post-Conditional
When you are stepping through a routine on an AIX system and a command post-conditional is true, the debugger generates an additional <BREAK> before executing the command.
Terminal Changes
The cterm application now accepts terminal input directly as Unicode instead of ANSI characters. This change should not impact terminal usage and behavior, but it is possible that there may be differences in some locales. This change allows Caché to support additional languages.
DeepSee Changes
Recompile Measure-Specific Listings
This release contains a correction to handle listing filters within compound cubes. You must recompile measure-specific listings to get this fix.
GetCubeMeasures Changes
The %DeepSee.Utils:%GetCubeMeasures() method should return the caption as the second item in the output list. For calculated measures it was returning the name. In this release, it correctly returns the caption. If your code depended on the previous incorrect behavior, you should modify it.
Language Binding Changes
Issue Using C++ Binding with Output Redirection
In order to perform output redirection, the C++ binding stores and resets the $ZR value. If $ZR points to a database that the user does not have write access, this encounters a protect error.
Security Changes
Changes to HttpRequest Security
In this release, %Net.HttpRequest is enhanced to support SPNEGO, Kerberos and NTLM authentication, as well as Basic authentication, for HTTP clients. This new authentication process for %Net.HttpRequest changes the existing %Net.HttpRequest support for Basic authentication. In previous releases, setting the Username property will as a side-effect return a Basic Authorization header. This behavior will only continue for HTTP 1.0 responses. For HTTP 1.1 responses an unsolicited Authorization header will never be sent unless the InitiateAuthentication property is set. If the current Basic authentication support is used, it will result in a 301 status response with a WWW-Authenticate header indicating Basic and possibly other schemes. HttpRequest then sends another request with the proper Authorization header. Existing code will continue to work but there will be an extra round-trip