Caché Release Notes and Upgrade Checklist
Upgrade Checklist for Caché 2018.1
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.
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.
The maintenance release Caché 2018.1.1 introduced the following upgrade checklist items:
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.
Maintenance Release 2018.1.1 provides performance and scalability enhancements for large-scale systems. These enhancements increase the amount of memory allocated for global buffer metadata by 64 bytes per buffer on Intel systems and by 128 bytes per buffer on IBM Power systems. For example, with 8K buffer sizes, the shared memory allocated for a global buffer increases by 0.75% on Intel systems and by 1.5% on IBM Power systems. There is also an increase in per-process memory usage for systems using large numbers of subscript level mappings.
This release contains a new parameter, Target size for the WIJ, in the system configuration journal settings. Setting this target size ensures that disk 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 space 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
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.
This section holds items of interest to users of specific platforms.
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.
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.
No classes have been removed in this release that were present in the previous version.
The following methods were present in the previous version and have been removed in this release:
No properties have been removed in this release that were present in the previous version.
No parameters have been removed in this release that were present in the previous version.
No indices have been removed in this release that were present in the previous version.
The following methods have different signatures in this version of Caché:
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.
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.
After upgrading to Caché 2018.1.1, you must recompile all DeepSee cubes. The 2018.1.1 Maintenance Release contains a fix to the %DeepSee.Generator that requires this recompile. If you build a cube without recompiling, it may cause an error.
In previous releases, a complex MDX query with nested %OR setfunctions could produce erroneous results. This release detects the constructs, blocks them, and issues an error. It is possible to produce the intended logical result with a simpler construct. You should rewrite these queries so that any %OR contains only AND terms.
This release contains a correction to handle listing filters within compound cubes. You must recompile measure-specific listings to get this fix.
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.
In C# classes used for XEP, developers can specify an id annotation. In previous releases, this could cause bulk updates to fail. To avoid this problem, Caché now generates id_property. In some cases, schemas with the generated id annotation may encounter a problem. If you encounter this problem, remove the annotation and the behavior will be unchanged from the previous version.
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.
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
To improve performance of large-scale systems, the statistics reported by the system utilities have changed. In most cases this will not cause any compatibility issues; however, if your code explicitly examines the statistics output for specific data, you may have to update your code to adjust for these changes. The following minor changes are visible:
The ^GLOSTAT utility no longer offers detailed block type statistics and no longer asks the question "Should detailed statistics be displayed for each block type? No =>". Additionally a bug is corrected in ^GLOSTAT which was present since 2016.1.0 and caused remote reads and remote cache efficiency to be incorrect (usually zero).
The Management Portal System Dashboard
is enhanced to show private global references and updates and WIJ writes, in the same way that ^GLOSTAT does. The detailed block type statistics page, 'Disk and Buffer Statistics', is no longer available.
The ability to zero statistics (from ^GLOSTAT and the Management Portal) is not available. This capability is not compatible with the more efficient statistics collection. Most counters are now 64-bit and timed collection is available, so there is no need to zero the counters.
The class SYS.Stats.Disk, which accesses the detailed block type statistics, reports all as zero; the class reference is updated to reflect this. The class SYS.Stats.Global, which accesses the main global statistics, continues to function as before and is enhanced to include write image journal writes as a property called 'WIJWrites'. Additionally, the internal class SYS.Metrics was previously exposed (unintentionally) as a public API; it is now properly marked as internal-only and it no longer reports values for detailed block type statistics.
The WS-Monitoring and BMC Patrol facilities that report the detailed block type statistics, report them zero or null. BMC Patrol, WMI, and SNMP monitoring facilities lock counts (total, success, and fail) also report as zero.
The cstat -g1
is updated to include more fields that were previously only available in ^GLOSTAT displays. Some statistics that were available via the cstat -c
option are no longer available.
%Monitor.Process, MONLBL, PERFMON and similar performance monitoring tools are unaffected by this change and maintain their own counters.