Skip to main content

This is documentation for Caché and Ensemble. See the InterSystems IRIS version of this content.Opens in a new tab

Please read this important announcement about the future of Caché and Ensemble maintenanceOpens in a new tab. Contact your account team to migrate to InterSystems IRIS.

Upgrading Caché

This chapter is intended for customers who are upgrading from Caché release 4.1 and later. Topics in this chapter include:

Important:

Before upgrading, review the following documents:

Caution:

Prior to beginning an upgrade of a Caché or Ensemble instance, it is essential that the instance be shut down cleanly. To verify that the shutdown was clean, examine the cconsole.log file after the shutdown finishes. If the log contains entries similar to the following, then the shutdown was clean:

...
05/03/11-14:24:13:234 (5204) 0 Journal restore not required at next startup
05/03/11-14:24:13:234 (5204) 0 Transaction rollback not required at next startup
...

If these entries are not present, the instance did not shut down cleanly. Please contact the InterSystems Worldwide Response CenterOpens in a new tab before proceeding with the upgrade.

Note:

If you run Caché MultiValue, some files may be overwritten during upgrade; see the section “Notes on Files Overwritten During Upgrade” in the chapter “Installing Caché” in Using the MultiValue Features of Caché for more information.

Supported Upgrade Paths

You can upgrade directly to this release of Caché from release 2009.1 or any later release. However, if you are upgrading a pre-2012.1 instance containing any 2K block size databases, these must be converted to 8K format before upgrading to version 2012.x or beyond. In this situation, use the following procedure:

  1. Upgrade the instance to version 2011.1, if necessary.

  2. Use the SYS.Database.Copy()Opens in a new tab method to convert all 2K databases to 8K format.

    Note:

    This method requires the database to be mounted. Only versions prior to 2014.1 support mounting 2K databases. Versions 2014.1 and later do not support this operation.

  3. Upgrade the instance from 2011.1 to the current release.

See Configuring Databases in the “Configuring Caché” chapter of the Caché System Administration Guide for information about database block size.

Note:

To upgrade from a version older than 2009.1, you must first upgrade to 2009.1 or later, then upgrade to the current release. Use the procedure for converting 2K block size databases if applicable. For assistance with upgrading from earlier versions, contact the InterSystems Worldwide Response CenterOpens in a new tab (WRC).

Upgrading to a Maintenance Release

Most of the information in this chapter applies to upgrading Caché to a new major version. If you are upgrading to a maintenance release of the installed version of Caché, review the following:

Performing Upgrade Tasks

The following upgrade tasks are necessary regardless of the platform on which you are upgrading and running Caché. Perform these tasks before you run the Caché installation procedures:

  1. Obtain an updated license key — the key structure changed in Caché 5.1; upgrades from Caché 5.0 or earlier require an updated key.

  2. Back up the system — before upgrading, InterSystems recommends that you run a complete backup of your system. Use your customary full operating system backup procedures.

  3. Check system integrity — run a system integrity check on existing directories to ensure there is no corruption in any of the databases.

  4. Save custom classes, routines and globals — on an upgrade, the CACHESYS database is modified. To prevent your own classes, routines and globals in the %SYS namespace from being affected by the upgrade installation, ensure that they have names that begin with “Z”, “z”, “%Z”, or “%z”. All .int and .obj routines (except for Z*, z*, %Z*, and %z*) are deleted from the %SYS namespace when upgrading.

    Similarly, on an upgrade, the CACHELIB, CACHETEMP, DOCBOOK, and SAMPLES databases are completely replaced.

  5. Save user files — to ensure that your user files are not deleted or replaced during upgrades, save them in the install-dir\Mgr\User directory, which is the only directory that is not subject to modification during upgrades (that is, except for the install-dir\Mgr\User directory, any files and directories in the Caché install directory may be deleted or replaced during upgrades).

  6. Review encryption settings — because of a limitation in prior releases, if you are upgrading from release 2010.1 or earlier and have encryption set to interactively ask for the username, password, and key file, you should temporarily change this setting to load encryption information automatically before upgrading (see Configuring Startup with Unattended Key Activation in the “Managed Key Encryption” chapter of the Caché Security Administration Guide for more information). After you perform the upgrade, you should then reenable the interactive setting. (Failure to configure startup with unattended key activation may cause the upgrade to fail; if this happens, start the system normally, change the startup configuration to unattended mode, and then reinstall the new version.)

    If you are upgrading using an .rpm file, you must disable database encryption before upgrading and reenable it when the upgrade is complete.

In addition, there are other tasks that may be necessary depending on your environment and the components as described the following sections:

Upgrading a Cluster

This section describes general considerations to take into account when upgrading Caché in a Caché failover cluster.

Note:

The information in this section does not apply to systems in which ECP application servers are deployed. For information about upgrading ECP configurations, see Upgrading ECP Configurations.

Important:

At a general level, it is important to:

  • Ensure that the shared-disk resources are not impacted or taken offline during a Caché upgrade.

  • Prevent cluster failover while Caché is being upgraded in a failover cluster.

  • Prevent Caché from starting automatically while being upgraded in a failover cluster.

In Windows, for example, to prevent cluster failover/automatic Caché startup, always tale the Caché cluster resource offline prior to the upgrade; when ready to resume operation, bring the resource back online. Similar steps should be followed on all other platforms; refer to the failover software product documentation that is relevant to your installation.

For platform-specific information, see the following:

Upgrading Caché on Windows Failover Clusters

On Microsoft Windows clusters, use the following procedure to upgrade Caché.

Important:

Do not start and stop Caché from the Caché Launcher. Instead, using Failover Cluster Management, take the Caché cluster resource offline to stop Caché, and bring the Caché cluster resource online to start Caché.

It is important to upgrade Caché on both systems in a Windows cluster before resuming cluster operation to ensure that the correct registry settings are maintained. For this reason, you cannot upgrade a Windows cluster without making the cluster unavailable for a period of time.

  1. After ensuring that a cluster failover will not occur automatically, shut down on the currently running (primary) system (for example, System A) by taking the Caché cluster resource offline. This step is recommended to quiesce the system prior to an upgrade.

  2. Upgrade Caché on System A. While the upgrade process will start Caché on System A after the upgrade is successful, it is recommended that users (direct-connect, background processes, ECP application servers, etc.) not be allowed back on to the system until the entire upgrade process (cluster-wide) is complete.

  3. Shut down Caché on System A by taking the Caché cluster resource offline.

  4. Fail the cluster over to the secondary system (for example, System B).

  5. Upgrade Caché on System B. While the upgrade process will start Caché on System B after the upgrade is successful, it is recommended that users (direct-connect, background processes, ECP application servers, etc.) not be allowed back on to the system until the entire upgrade process (cluster-wide) is complete.

  6. Fail the cluster over to System A.

  7. Start Caché on System A by bringing the Caché cluster resource online.

  8. Ensure that the cluster resource type (for example, Caché ISCCres2003) is brought online so that automatic failover can occur. Users (direct-connect, background processes, ECP application servers, etc.) can be permitted to reconnect to Caché (on System A) at this point.

Upgrading Caché on UNIX®, Linux, and macOS Failover Clusters

On UNIX/Linux systems clusters, use the following procedure to upgrade Caché:

  1. Gather the list of Caché instances on the two failover nodes. This can be done by using the ccontrol list command. Note the list of systems (and paths, etc.), if any, that are unique to the second (standby) failover node.

  2. After ensuring that a cluster failover will not occur automatically, shut down Caché on the currently running (primary) system (for example, System A).

  3. Upgrade Caché on System A. The upgrade process should start Caché once the upgrade is complete. Users (direct-connect, background processes, ECP application servers, etc.) can be permitted to reconnect to Caché (on System A) at this point.

  4. Copy the /usr/local/etc/cachesys/ directory from System A to System B. Note: please ensure that the permissions and ownership for the cachesys directory as well as the files within that directory remain intact.

  5. If there are any Caché instances that were unique to System B, you must recreate that information manually using the ccontrol create command to add the instance information to the registry. The correct usage of the command can be found by typing ccontrol create help at the OS prompt.

  6. Ensure that the appropriate cluster resource associated with Caché is brought back online so that automatic failover can occur.

Upgrading Mirroring with Minimum Downtime

This section provides instructions for upgrading Caché or Ensemble instances, an application, or both on the members of a Caché mirror.

As noted in the “Mirroring” chapter of the Caché High Availability Guide, all failover and DR async members of a mirror must be of the same Caché version, and can differ only for the duration of an upgrade. Once an upgraded member becomes primary, you cannot make use of the other failover member and any DR async members (and in particular cannot allow them to become the primary) until the upgrade is completed.

Mirroring does not require reporting async members to be of the same Caché version as the failover members, although application functionality may require it; see the “Supported Version Interoperability” chapter of the online InterSystems Supported PlatformsOpens in a new tab document for this release for information about reporting async version requirements.

There are four mirror upgrade procedures, as follows. The first three procedures are designed to let you perform the upgrade you need with the shortest possible application downtime; they differ to accommodate different upgrade circumstances. The last, which is a bit simpler, can be used for any type of upgrade when minimizing downtime is not a priority.

Choosing Mirror Upgrade Procedure provides an overview of the factors that determine which procedure you should use. Your circumstances may call for additional steps and details in a given procedure. If you are unsure which procedure is appropriate for you or whether a particular procedure is appropriate as stated, please contact the InterSystems Worldwide Response CenterOpens in a new tab (WRC).

To avoid repetition, Minimum Downtime Upgrade Terms defines the terms that are used in multiple procedures.

Important:

On Linux systems supporting systemd, although it is possible to use either systemctl commands or the /etc/init.d/ISCAgent script to manage the ISCAgent, you must choose one method and use it exclusively; the ISCAgent should always be stopped using the method with which it was started (see Starting the ISCAgent on Linux Systems in the “Mirroring” chapter of the Caché High Availability Guide).

When you upgrade Caché on such a Linux system, a running ISCAgent is automatically restarted using systemd. If you are using the /etc/init.d/ISCAgent script to manage the ISCAgent, stop the agent before performing the upgrade so that it is not automatically restarted, then restart it using the script after the upgrade.

Choosing Mirror Upgrade Procedure

There are two primary factors to consider in choosing the procedure appropriate for your mirror upgrade:

  • Are you upgrading to a maintenance release of the installed version of Caché (for example, from 2015.1.0 to 2015.1.1), or to a new major version of Caché (such as 2014.1.0 to 2015.1.0)?

  • Does the upgrade involve changes to mirrored databases?

Whenever you upgrade to a maintenance release and are not making any application upgrades, you do not have to consider the second question; you can always use the simple Maintenance Release Upgrade procedure, which renders the mirror unavailable only for the time it takes to execute a planned failover.

However, when you upgrade from one major Caché version to another, perform application upgrades, or both, there is the possibility that your upgrade will involve changes to mirrored databases. Such changes must occur on the functioning primary failover member as part of the upgrade procedure, while application access is disabled. As a result, the upgrade requires more downtime than if you are not making any mirrored database changes. (The changes will then be replicated by the mirror on the backup and any async members.)

Following a major upgrade, InterSystems recommends that you recompile all classes in all application namespaces on the instance, including Ensemble namespaces, and some routines must also be recompiled (see Upgrade Specifics in the chapter General Upgrade Information in the Caché Release Notes and Upgrade Checklist). Any application upgrade you perform may require changes to application data. In either of these situations, your upgrade may result in changes to mirrored databases. Therefore, if you are upgrading to a major release, are performing application upgrades, or both, you must determine whether any of the following conditions apply:

  • Classes and routines are stored in mirrored databases that also contain application data; these must be recompiled on the primary (even if the application has not been upgraded).

  • Data in mirrored databases must be upgraded due to an application upgrade; these changes must take place on the primary.

  • Mirrored databases are used with Ensemble or DeepSee; all classes in all namespaces mapped to these databases must be recompiled on the primary.

If your major upgrade and/or application upgrade involves any of these conditions, use the Major Upgrade (Mirrored Database Changes) procedure, which renders the mirror unavailable only for the time it takes to execute a planned failover and make the required mirrored database changes.

If your upgrade does not involve any of the listed mirrored database changes, consider the Major Upgrade (No Mirrored Database Changes) procedure, which renders the mirror unavailable only for the time it takes to execute a planned failover.

If you have a significant planned maintenance window and minimizing mirror downtime is not a major concern, you may choose to use the simpler Major Upgrade with Planned Downtime procedure instead.

In the case of major upgrades, the general sequence of each procedure applies to upgrades of the mirror’s Caché instances, application code, or both; adapt individual steps depending on what you are upgrading.

Adding Mirror Members During an Upgrade

If you plan to add members to a mirror, you may want to defer this until you plan to perform one of the upgrades described in this section and add members of the new version during the upgrade, so that you will not have to upgrade them later. You can always add members of a newer version to a mirror during an upgrade, provided you immediately continue with and complete the upgrade as described, with one restriction: once a member of the newer version becomes primary, it must remain primary until all other members have been upgraded.

Adding new members during an upgrade can be very helpful when migrating a mirror to new hardware. Rather than upgrading one of the failover members before failing over to it, you can install a new instance of the new version on the target system, add it to the mirror as a DR async member, promote it to backup and then fail over to it, thus migrating the mirror primary to the new system. By repeating this technique you can then migrate the remaining failover member. The procedures in this section include steps for adding a new backup of the new version as an alternative to upgrading the existing backup, to illustrate this approach.

Minimum Downtime Upgrade Terms

In the procedures in this section, the following terms are used:

  • Upgrade classes and routines refers to the recompilation of all classes in all application namespaces on the instance after a Caché major version upgrade (as described in Post-Installation Upgrade Tasks) and/or application upgrade, which may involve one or more of the following operations, depending on your situation:

    • As noted in the foregoing, when classes and routines exist in any mirrored database that also contains application data, they must be recompiled locally on the functioning primary failover member (regardless of whether they are modified by an application upgrade).

    • Classes and routines stored in non-mirrored routine databases that are separate from application data can be recompiled on a mirror member regardless of whether it is the current primary.

    • Classes and routines stored in separate non-mirrored routine database can also be “precompiled” by recompiling a copy of the database on a system that has already been upgraded to the target Caché release, then distributed to each mirror member following the upgrade.

    The methods you use to upgrade classes and routines will depend on your circumstances, the procedure you are using, and the member on which you are recompiling.

  • The name system A refers to the mirror member that is initially the primary failover member, and system B to the mirror member that is initially the backup failover member. System C refers to a newly-added DR async of the new Caché version that has been promoted to failover member.

  • Set no failover refers to the use of the ^MIRROR routine to set the no failover state so that failover cannot occur; see Avoiding Unwanted Failover During Maintenance of Failover Members in the “Mirroring” chapter of the Caché High Availability Guide for instructions.

  • Perform a graceful shutdown refers to the use of the ccontrol stop command (see Controlling Caché Instances in the “Using Multiple Instances of Caché” chapter of the Caché System Administration Guide).

  • Promote to failover member refers to the procedure for promoting a DR async mirror member to failover member as described in Promoting a DR Async Member to Failover Member in the “Mirroring” chapter of the Caché High Availability Guide.

  • Viewing the Mirror Monitor refers to using the Mirror Monitor page in the instance’s Management Portal to review the status of the mirror and its members; see Using the Mirror Monitor in the “Mirroring” chapter of the Caché High Availability Guide for more information.

Upgrading to Caché Maintenance Release

If you are upgrading to a Caché maintenance release rather than a new major Caché version and are not making any application changes, use the following procedure, which renders the mirror unavailable only for the time required to execute a planned failover:

  1. To prevent failover from occurring until the backup is fully upgraded, set no failover.

  2. Perform one of the following two operations:

    • Upgrade the existing backup:

      1. Perform a graceful shutdown of the backup (B).

      2. Upgrade the backup (B) with the new version of Caché. System B becomes backup.

    • Add a new backup of the new version:

      1. Install the new version of Caché on system C.

      2. Add system C to the mirror as a DR async member.

      3. Promote system C to failover member. System C becomes backup and System B becomes a DR async.

  3. Ensure that the backup (B or C) has become active by viewing the Mirror Monitor.

  4. Clear no failover.

  5. Perform a graceful shutdown of the primary (A). The mirror fails over and the backup (B or C) takes over as primary.

  6. Upgrade system A with the new version of Caché. System A becomes backup.

  7. If system C became primary and system B was demoted to DR async, upgrade system B.

Upgrading to Major Caché Version with Mirrored Database Changes

If you are upgrading to a new major Caché version and/or performing an application upgrade and have determined that changes to mirrored databases are required (as described in Choosing a Mirror Upgrade Procedure), use the following procedure, which renders the mirror unavailable only for the time it takes to execute a planned failover and make the required mirrored database changes:

  1. To prevent failover from occurring until the backup is fully upgraded, set no failover.

  2. Perform one of the following two operations:

    • Upgrade the existing backup:

      1. Perform a graceful shutdown of the backup (B).

      2. Upgrade the backup (B) with the new version of Caché. System B becomes backup.

      3. Upgrade non-mirrored classes and routines on system B, if any.

    • Add a new backup of the new version:

      1. Install the new version of Caché on system C.

      2. Add system C to the mirror as a DR async member.

      3. Promote system C to failover member. System C becomes backup and System B becomes a DR async.

  3. Ensure that the backup (B or C) has become active by viewing the Mirror Monitor.

  4. Disallow new user access to the mirror using established practices at your site. Additionally, you must disable any application jobs that would normally start on system B when it becomes primary. If using Ensemble, disable production auto-start.

  5. Clear no failover.

  6. Perform a graceful shutdown of the primary (A). The mirror fails over and the backup (B or C) takes over as primary

  7. Upgrade mirrored classes and routines on the new primary (B or C). If an application upgrade requires further changes to mirrored databases, make these changes.

  8. Restore user access to the mirror. If using Ensemble, enable production auto-start and start productions.

  9. To prevent system A from taking over as primary until fully upgraded, set no failover

  10. Upgrade system A with the new version of Caché. System A becomes backup.

  11. Upgrade non-mirrored classes and routines on system A, if any.

  12. Clear no failover.

  13. If system C became primary and system B was demoted to DR async, upgrade system B and upgrade non-mirrored classes and routines on system B, if any.

Upgrading to Major Caché Version with No Mirrored Database Changes

If you are upgrading to a new major Caché version and/or performing an application upgrade and have determined that changes to mirrored databases are not required (as described in Choosing a Mirror Upgrade Procedure), you may be able to use the following procedure.

This procedure is simplest for static applications where separate non-mirrored routine databases are always maintained. It can, however, be used even if the separate routine databases are normally mirrored by removing these databases from the mirror for the duration of the upgrade.

Important:

If the routine databases are normally mirrored, ensure that they do not contain any application data before removing them from the mirror.

This procedure cannot be used with normally mirrored routine databases if ECP application servers connect to the mirror.

  1. Enact a code freeze and application configuration freeze to disallow application changes during the upgrade, using established procedures at your site, to ensure that routine databases are not modified during the upgrade.

  2. To prevent failover from occurring until the backup is fully upgraded, set no failover.

  3. Perform one of the following two operations:

    • Upgrade the existing backup:

      1. If the routine databases are mirrored, remove them from the mirror on system B.

      2. Ensure that the backup (B) has become active by viewing the Mirror Monitor.

      3. Perform a graceful shutdown of the backup (B).

      4. Upgrade the backup (B) with the new version of Caché. System B becomes backup.

      5. Upgrade classes and routines on system B.

    • Add a new backup of the new version:

      1. Install the new version of Caché on system C.

      2. Add system C to the mirror as a DR async member.

      3. Promote system C to failover member. System C becomes backup and System B becomes a DR async.

      4. If the routine databases are mirrored, remove them from the mirror on systems C and B.

      5. Ensure that the backup (C) has become active by viewing the Mirror Monitor.

  4. Clear no failover.

  5. Perform a graceful shutdown of the primary (A). The mirror fails over and the backup (B or C) takes over as primary.

  6. To prevent system A from taking over as primary until fully upgraded, set no failover,

  7. Upgrade system A with the new version of Caché. System A becomes backup.

  8. Upgrade any non-mirrored classes and routines on system A.

  9. If system C became primary and system B was demoted to DR async, upgrade system B and upgrade non-mirrored classes and routines on system B, if any.

  10. For any mirrored routine databases that you removed from the mirror on backup (B or C) before it became the new primary, do the following:

    1. Remove the routine databases from the mirror on system A.

    2. Add the databases to the mirror on the new primary (B or C), then back them up and restore them on the backup (A) and DR async (B, if C is the primary), using the procedures for adding an existing database to a mirror provided in Adding Databases to a Mirror in the “Mirror” chapter of the Caché High Availability Guide. Retain these backups, as they represent the first backups of newly-added mirrored databases; older backups made prior to the upgrade cannot be used to restore these databases in the event of disaster.

  11. Clear no failover.

Upgrading to Major Caché Version with Planned Downtime

If you are upgrading to a new major Caché version and/or performing an application upgrade and have a significant planned maintenance window that obviates the need to minimize mirror downtime, you may prefer to use the following simpler procedure, regardless of whether changes to mirrored databases on the primary are required:

  1. Disallow all user access to the mirror using established practices at your site. Additionally, you must disable any application jobs that would normally start on instance startup. If using Ensemble, disable production auto-start.

  2. Perform a graceful shutdown of the backup (B).

  3. Perform a graceful shutdown of the primary (A).

  4. Upgrade system A with the new version of Caché. System A becomes primary.

  5. Upgrade mirrored classes and routines on system A. If an application upgrade requires further changes to mirrored databases, make these changes.

  6. Upgrade non-mirrored classes and routines on system A, if any.

  7. Perform one of the following two operations:

    • Upgrade the existing backup:

      1. Upgrade system B with the new version of Caché. System B becomes backup.

      2. Upgrade non-mirrored classes and routines on system B, if any.

    • Add a new backup of the new version:

      1. Install the new version of Caché on system C.

      2. Add system C to the mirror as a DR async member.

      3. Promote system C to failover member. System C becomes backup.

      4. Upgrade system B with the new version of Caché. System B becomes a DR async.

      5. Upgrade non-mirrored classes and routines on system B, if any.

  8. If system C became primary and system B was demoted to DR async, upgrade system B and upgrade non-mirrored classes and routines on system B, if any.

  9. Restore user access to the mirror.

Upgrading ECP Configurations

In general, ECP application servers should be upgraded before the data servers they connect to. Application servers must have either local routines databases to recompile following upgrade or access to “precompiled” routines database (previously recompiled on a separate system running the target Caché version) on the data server.

Downtime can be minimized using rolling upgrades with users connecting to both upgraded and unupgraded application servers as well as the database server if one of the following is true:

  • There are no application changes.

  • There are application changes, but the new code does not generate any new data structures, meaning that old code can work with data generated by new code.

If the new application code can work against old data, but can generate new data structures not understood by the old code, follow this procedure:

  1. Upgrade the application servers on a rolling basis, but do not allow users to connect to an application server once it is upgraded. (Application server capacity will be gradually reduced.)

  2. When enough application servers have been upgraded, restore user access to the upgraded application servers and end all user connections to the remaining (not upgraded) application servers and the data server (if need be), ensuring that users have no access to these systems until you enable it.

  3. Upgrade the remaining application servers, restoring user access to each application server after it is upgraded.

  4. Upgrade the data server and restore user access as needed. (Upgrading the data server will cause a pause in application activity, the length of which will depend on the amount of downtime involved in the upgrade.)

If you have questions or concerns about how to upgrade your ECP configuration, please contact InterSystems Worldwide Customer Support (WRC)Opens in a new tab.

Post-installation Upgrade Tasks

The post-installation tasks required depend on whether you have upgraded to a new major version of Caché or to a maintenance release of the installed version.

Major Version Post-Installation Tasks

After upgrading Caché to a new major version, for example, from 2014.1.0 to 2015.1.0, or 2016.1 to 2016.2, you must perform the following tasks (if you have not already done so as part of one of the previous procedures in this chapter):

  • Recompile Classes and Routines — InterSystems recommends that customers recompile all classes contained in each namespace. Some routines also require recompilation. You may have your own tools and procedures for this purpose, taking into account any dependencies and other needs particular to the instance that was upgraded. If you do not, and are upgrading to version 2014.1 or later, see Upgrade Specifics in the chapter General Upgrade Information in the Caché Release Notes and Upgrade Checklist for full information and instructions. (If you are upgrading to an earlier version, see the “Pre-2014.1 Upgrade Information” appendix in Caché Release Note and Upgrade Checklist Archive information and instructions.)

  • Regenerate Proxy Classes — You must regenerate any proxy classes you had generated in the upgraded instance by following the instructions in the appropriate guides in the Caché Language Bindings set. For more information, see Upgrade Specifics in the chapter General Upgrade Information in the Caché Release Notes and Upgrade Checklist.

    This item does not apply to web services and web clients; it is not necessary to reimport any Web Service Definition (WSDL) files.

  • Clear browser cache — Your browser cache may contain JavaScript files that are no longer compatible with the installed version of Caché and will cause errors; clear your browser cache immediately after completing the upgrade.

The following tasks may be necessary depending on your environment and the components you use:

  • Update web server files — If you are using Zen, recompilation generates external files; in addition, you may have your own external Zen and CSP files in place. Following upgrades you must deploy these using established practices at your site.

  • Upgrade CSP Gateway — If your CSP Gateway is on a separate machine from the Caché server you are upgrading, you must also upgrade the CSP Gateway on that separate machine. You accomplish this by performing a custom Caché install (see the CSP Gateway Installation section of the “Installing Caché on Microsoft Windows” chapter of this book) on your web server machine and choosing only to install the CSP Gateway. See the “Connecting to Remote Servers” chapter of the Caché System Administration Guide for details.

  • Upgrade Studio Clients — The Studio version on a client must be the same or later than the Caché server version to which it connects; this also applies to maintenance releases. See the “Introduction to Studio” chapter of Using Studio for details.

Maintenance Release Post-Installation Tasks

After upgrading to a maintenance release of the installed version of Caché—for example, from 2015.1.0 to 2015.1.1—you are not required to recompile any classes or routines. However, if you choose to recompile, it is important to follow the guidance provided in Upgrade Specifics in the chapter General Upgrade Information in the Caché Release Notes and Upgrade Checklist.

Typically, no changes to external files or clients are required following a maintenance release upgrade.

Creating and Using an Installation ManifestNext section
Previous sectionInstalling Caché on UNIX®, Linux, and macOS
FeedbackOpens in a new tab