• General Announcements
• InterSystems News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• Change Reports for This Maintenance Kit

The most current list can be obtained from the InterSystems Website.

Users should check this list periodically to obtain the latest information on issues that may have an effect on the operation of their site.

• Likelihood: The probability that a user on the affected platform will encounter this issue.
• Risk: An assessment of how likely this change is to introduce additional issues into the application environment.
• Ad Hoc: Whether this change has previously been deployed in an ad hoc release and successfully used by customers in production.
• Enhancement: Whether this change provides new features or capabilities for the product.

In the Management Portal, on the Operations side, a new item, "View Task Schedule", has been added. This page shows a table with all the task schedules.

The operator can create a Task to purge journal at a desired time or frequency. However, when Caché is installed, the purge journal task is already defined and set to run periodically. It may be modified and/or replaced as necessary.

In the Management Portal, Configuration, Shadow Server Settings page, there is an option to "Add New Shadow or Edit an existing shadow." Selecting "Advanced" now shows an additional prompt:

This change modifies the socket delegation to give (rw) access to any job it tries to delegate the socket to. (In prior releases, it had been limited by the umask setting of whoever started the Caché instance).

An ECP client attempts to optimize duplicate globals sent to the server. The optimization caches the last global used across ECP, but the cached information is not invalidated consistently when multiple connections are involved, and the request sequence numbers match.

This issue has been corrected.

This change guarantees that, in the worst case, the database server with dead ECP server sessions may end up in an unexpected long wait.

For example, upgrading from 5.2 to 2007.1, will rebuild the indices. Installing an ad-hoc of 2007.1 on top of an existing 2007.1, will not rebuild the indices. This makes installs of maintenance releases quicker.

This means that the system was unable to perform a pattern match because the pattern was too complex to be applied to the given input string. The pattern should be simplified by reducing the number of alternations and indefinite counts, or the input string should be broken into smaller segments for matching.

The socket is created for a very short time during job creation. The algorithm was modified to use /tmp/ directory in the path instead.

In this situation, "ccontrol stat" may appear to show that the write daemon is unresponsive.

This has been changed so that the system will remain frozen until the write daemon completes the subsequent pass to allow it more time to catch up if it has fallen behind.

The command

Use of the -K option is recorded in the console log and the user is warned that this is dangerous and asked to confirm the operation before continuing.

A note will be generated in the console log when this occurs because it is not healthy for a system to take this long to write a set of blocks to disk, especially if it happens on consecutive passes. Users will not be locked out as long as some progress is being made. The system may eventually run out of free buffers; in this case, users will be locked out.

The correct behavior is to keep the system suspended until all of them complete their pending operations succesfully. It is implemented by this change.

General syntax forms are:

Windows:

Formerly the customer failover script was responsible for deleting the cache.ids file and starting Caché, but if it were accidentally invoked in other than a bona fide failover situation, there could be severe interference with a running instance of Caché on that node.

The current change will not allow startup to proceed if Caché is already running, even if an accidental failover is commanded. To enable this functionality, replace script lines such as:

When the -S option is selected, cstat first attempts to determine if the system is hung in a way that can be self-diagnosed. If it is hung in such a way, then it examines the system state in effort to identify the cause of the hang. Informational messages report the progress of the self-diagnosis and any relevant recommendations to the user. Finally, cstat lists processes which are suspected of causing the hang at that Caché system level.

Each process reported may be in one of several possible states. The states reported and their meanings are as follows:

• SUSPECT:
  Processes in this state are suspected of causing the hang. These processes should be investigated with debugging tools native to the operating system or dumped with user-mode process dumping tools in order to determine their state.
• EXONERATED:
  Processes in this state were suspected of causing the hang, but were determined to be waiting for another process, thus are not likely to be the cause of the hang. Processes in this state typically do not need to be investigated further.
• DEAD:
  Processes in this state are suspected of causing the hang and additionally are believed to have exited at the operating system level. Typically no further investigation of these processes can be done.
• LOSTWAKE:
  Processes in this state are suspected of causing the hang. Additionally, they are believed to be hibernating and have failed to be awoken by another process. These processes should be investigated with native operating system debugging tools like jobs in the SUSPECT state. It may be possible to resume the system by sending a wakeup to these processes using cstat -P<job#>

Note that not all types of hangs necessarily result in having any processes requiring further investigation.

In a Caché cluster, the cstat self-diagnostics should be run on all cluster members. It is possible that one cluster member may appear to be hung before the others. Typically, within 10 minutes the other members become hung because the write daemons time out while trying to synchronize with the other nodes. For this reason, the self-diagnosis may not detect the hang on one or more nodes of the cluster until this timeout has expired.

Additionally, this change adds a new bit 2048 to the cstat -p option. When the 2048 bit is on the sfn and block number of each process's retained buffer (pgbdbsav) is displayed.

This correction does two things. First, Caché now checks that the RLIMIT_FSIZE hard limit is unlimited, and halts the Caché startup (or installation) with an error message if not. Second, it sets the soft limit to the hard limit in the daemons.

See the operating system documentation for each platform for a discussion of how to set the system hard limit for RLIMIT_FSIZE.

As a rule of thumb, if the journal file from the failed cluster node contains big string data ("big" as defined being 128 or more characters long) or BITSET records, the current journal file on the cluster node performing ECP failover may get corrupted.

1. the failed I/O has been tried for a certain period of time;
2. journal buffers are full;
3. available global buffers falls below a minimum.

Prior to this change, the length of the retry period in condition #1 was set at 10 minutes, longer than the time write daemon would wait (5 minutes by default) for journal synchronization to complete before declaring WDSTOP (stop the write daemon). As a result, if neither of the last two conditions was met, the write daemon would declare WDSTOP before journal daemon disabled journaling, causing the system to hang for a while (until journal daemon disabled journaling 5 minutes later).

With this change, the length of the retry period in condition #1 is set at half of write daemon's wait time, therefore guaranteeing that journaling would always get disabled before write daemon's wait timed out, preventing the system from hanging.

• the length of the journal directory to switch to is within the Caché limit (64 prior to 2007.1),
• but the length of the full path of the new journal file (journal directory + journal file prefix (if any) + journal file name in the form of YYYYMMDD.xxx) exceeds the Caché limit.

It would also cause buffer overflow with unpredictable result.

For example,

1. Caché startup will be aborted if journal recovery gets an error locating the next file to restore. Previously, journal recovery would stop without generating any error and startup would continue.
2. Journal recovery will locate the correct next file in alternate journal directory even if there is a bad namesake file in the primary journal directory. The bad file could have been the result of an incomplete journal switch due to disk error. (Normally, journal switch would delete the incomplete file if it failed halfway through writing to it, but there are circumstances where it would be unable to delete it such as the disk becoming inaccessible.)

This change enforces the above behavior in the event of possible loss of journal data resulting from a fatal error in journal switch. If such an error occurs, a message will be written to the console log.

Prior to this change, journal switch aborted with a fatal error <SYSTEM> error would leave behind an incomplete file.

Journal restore at startup or cluster failover were not affected, nor it was affected by the setting of long string support.

As of this change, sorting in journal restore is disabled if cachetemp max size is fixed (as opposed to unlimited, or 0).

Journal switches that activate changes to journal property such as primary and alternate directories are still logged in journal history global (to facilitate searching for journal files).

All forms of journal switches are still logged in cconsole.log.

When an fsync error occurs journal data has probably been lost so switching journal files results in resuming a system where the journal files are not complete. If the system is the server of shadow data, the shadow copy will probably be missing some sets and/or kills. Restarting Caché or stopping journaling is the only way to recover from this situation.

Restarting Caché will ensure that the shadow server and clients remain synchronized as the server that had the fsync problem will not have written any database blocks to disk which do not have their supporting journal records in the journal file.

Stopping journaling will allow the system to continue running with a gap in the journal (that is, if it is later restarted, some information will be missing).