The following release notes are available in the \Docs subdirectory of your installation:

• Late-breaking information about this kit: \relnotes\readme.1st
• Release notes for this kit: \relnotes\cache\relnotes.htm (this document)
• Release notes from prior kits: \relnotes\cache\prenotes.htm

This document provides a list of the changes between Caché 2007.1.2 and Caché 2007.1.3.

Topics include:

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

Since this maintenance kit is based on Caché 2007.1.1, anyone upgrading from a Caché release at or before 5.0 will need a new license key.

From time to time, InterSystems publishes items of immediate importance to users of our software. These include alerts, mission critical issues, important updates, fixes, and release announcements.

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.

As a convenience to our users, InterSystems provides online access to documentation for recent product versions at the InterSystems Website. From the home page choose Support and Education, then Caché Support and on then Caché Documentation. Then select the specific version and type of documentation you are interested in.

To help you assess the impact of this maintenance kit on your applications, the remaining topics in this document describe each modification in detail. The format for this description is a Change Report.

Each Change Report provides a table with the following information:

• 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.

The ECP server may not see roles/privilege changes associated with the IP. Caché has now been modified to flush its privilege cache when there is any change.

On some asynchronous requests (i.e. set and kills), the ECP application server applies the changes to the local cache and then sends the request to the server. In certain rare circumstances, the ECP server fails but the application server cache is left modified.

This change modifies the ECP server to purge the associated cached block on the app-server during unexpected errors.

This change fixes a Caché security hole when a user runs the Caché debugger. Perviously, a non-privileged user can escalate to %All by inserting a ZBREAK at the right spot in a privileged routine application.

A bug has been fixed where duplicates might be returned despite use of DISTINCT. This problem could occur if:

• The DISTINCT was not actually needed because the rows would satisfy the DISTINCT anyway. For example: SELECT DISTINCT <primary key> FROM <table>; and,
• The WHERE clause of the query contained a subquery.

If both of these were true, the query might have returned duplicates.

A bug that produced wrong answers to certain queries has been fixed. The problem occurred when

• more than one index was used for a table,
• at least one of the indexes has data with the index,
• all subscripts before the ID have equality conditions on them,
• there is also a condition on the data with the index.

For example, suppose an index on age with data of salary, and also an index on lastname. The problem would occur for a query like:

SELECT * 
FROM <table> 
WHERE age=21 AND salary > 100000 OR lastname='mellon'

The condition on salary would not be tested.

The same problem can occur if the 'OR' is replaced by 'AND'. However, this case is less likely - the selectivities on the table have to be just right.

In a Windows system installed Normal security. Attempting to run the CSP debugger breakpoints results in errors. In Studio, you will get a pop up indicating error 6707.

The output window in Studio displays:
CSP: STOPPED failed end session

This has been corrected.

A pattern match operation will now release the global block that the process may be retaining from the most recent global operation. This will allow other processes to proceed with access to the global during the possibly long time of the pattern match operation.

The system will limit the recursion depth for its pattern matching algorithm to prevent abnormal process termination. If the pattern can not be resolved within that limit, it will throw a <COMPLEX PATTERN> error.

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.

On some 64-bit platforms, the %ETN error trap was not able to complete normally after a <FRAMESTACK> error. This could cause repeated <FRAMESTACK> errors and filling of the CacheTemp database.

More entries will now be popped from the execution stack before %ETN is run to handle a <FRAMESTACK> error.

A MERGE into an existing local variable node, followed by a KILL of that node should leave $DATA()=0. However, prior to this correction, it would report $DATA()=10, and $ORDER() would return a subscript which did not exist.

In rare conditions (for example, opening a file from an implied name space), when a routine invoked by Caché is not found, the error handler might be invoked with unexpected state. Later when control is returned, the process state is unpredictable.

This has been corrected.

In very rare circumstances, errors that happen during error dispatching halt the process. The halt may do some cleanup (for example, executing %Destruct on open objects). If the cleanup is in the same routine as the cause of the error, it may cause an access violation.

This has been corrected.

The criteria for suspending the system when the write daemon takes more than 5 minutes to complete a pass has been extended. As long as the write daemon is writing some blocks to disk, the system does not get suspended.

A message will be generated in the console log noting this information because it is not healthy for a system to take this long to write a set of blocks to disk, especially if it happens repeatedly. With this change, users will not be locked out as long as some progress is being made.

The system may eventually run out of free buffers at which point users will be locked out.

A rare issue has been resolved for Unix and OpenVMS platforms where, if multiple write daemons enountered I/O errors, the system would be suspended. The system would be unsuspended when any one of them completed their pending operation.

The class %SYS.ProcessQuery has been updated. When <pid> is $J (that is, the process is getting information about the itself) the functions return the values from process private memory which are exactly up to date.

Generally %SYS.ProcessQuery returns information from shared memory to reduce the system impact of extracting information from a different process. To increase performance, certain per-process counters are only "published" to shared memory periodically. %SYS.ProcessQuery on a different process can see a value which is slightly out of date.

This change corrects a situation where more calls than necessary were made to obtain shared memory segments on Solaris. These extra calls wasted memory and could cause a performance problem.

This change fixes a condition that the backup could take a longer time as expected because Write Daemon's delay.

This change will remove the 'Com' value in the [Com] section for non-Windows platforms in the CPF file. This field is only for the Windows platforms.

This change provides a front end interface as part of ^JOURNAL for a couple of options to purge journal files, one of which is to purge all jorunal files except those required for transaction rollback or crash recovery.

For example,

%SYS>DO ^JOURNAL

1) Begin Journaling (^JRNSTART)
2) Stop Journaling (^JRNSTOP)
3) Switch Journal File (^JRNSWTCH)
4) Restore Globals From Journal (^JRNRESTO)
5) Display Journal File (^JRNDUMP)
6) Purge Journal Files (PURGE^JOURNAL)
7) Edit Journal Properties (^JRNOPTS)
8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
9) Display Journal status (Status^JOURNAL)

Option? 6

1) Purge any journal NOT required for transaction rollback or crash recovery
2) Purge journals based on existing criteria (2 days or 2 backups)

Option? 1

The following files have been purged (listed from latest to oldest):

   1. /scratch1/yang/cache/lx4.72u/mgr/journal/20070222.007

1) Begin Journaling (^JRNSTART)
2) Stop Journaling (^JRNSTOP)
3) Switch Journal File (^JRNSWTCH)
4) Restore Globals From Journal (^JRNRESTO)
5) Display Journal File (^JRNDUMP)
6) Purge Journal Files (PURGE^JOURNAL)
7) Edit Journal Properties (^JRNOPTS)
8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
9) Display Journal status (Status^JOURNAL)

Option?

This change includes two parts:

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. Allow journal recovery to locate the correct next file in alternate journal directory even if there is a bad namesake file in 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 (e.g., if the disk is inaccessible).]

When a Caché system is configured to freeze on journal errors, the system could be unfrozen by a subsequent successful journal switch. This is usually a desirable behavior unless the journal error has resulted in the loss of journal data. In this case, user intervention is necessary to bring the system back to an appropriate state. Until then, the system should remain in the frozen state despite journal switch attempts.

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, you should see a message like the following in cconsole.log:

An irreversible error occurred in writing <xxx> to journal file.
Any pending journal data is lost.
You should restart the system and back up databases immediately.

This change addressed various issues with journal restore that, in certain circumstances, could fail or produce incorrect result on Caché systems where cachetemp maximum size is fixed. Journal restore at startup or cluster failover was not affected.

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

A condition has been resolved where Caché would permit switching journal files after an fsync error had occured when the system was set to freeze on journal errors.

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 should be the only way to recover from this situation. Restarting Caché will ensure that the shadow server and clients remain synchronized as the server which 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 (eg. if it is later restarted, some information will be missing).

This change eliminates rare circumstance under which switching journal files manually could alter the maximum journal size.

This change corrects a problem where the adjusted license user limit used for Ensemble licenses is not recognized by the license upgrade procedure.

A problem that caused running license queries in the %SYSTEM.License class required write access to the CacheSys database has been corrected.

This change corrects a situation where a timeout error could occur as the result of stopping a shadow. The Caché stop code now waits a bit longer than the shadow hang interval (default: 10 seconds) and TCP read timeout (10 seconds) to assure all pending activity is finished.

The "ccontrol force instance_name" did not work on Windows Vista unless the user was running as administrator. This change corrects this by using the service to force down the Caché instance before forcing the instance manually.

Note: It is best to be logged in and running administrator when running "ccontrol force" on Windows Vista. You can do this by right clicking on "Command Prompt" in the Windows start menu and selecting "run as administrator".

If an error such as <FILEFULL> happens when the error trap routine is creating the ^ERRORS global entry, Caché has been changed to remove the temporary global that holds the error information instead of leaving it. This will help prevent the CACHETEMP database from growing unnecessarily.

This change fixes a problem when re-activating a non-exist configuration file. This system may get into a state not allowing user to login.

This change fixes a problem that when the cpf syntax is incorrect, Caché will try to regenerate the missing fields on startup. However, when the overview field is also missing, Caché will replace it with "Windows NT" even though the operating system is Linux. This causes sequential restarts to fail.

This correction fixes an issue where when an application uses pipe for I/O of a Caché session, it could get unexpected <ENDOFFILE> error.

This change fixes a problem in the ^DATABASE utility. When a user entered a directory name with '-' at the directory prompt, Caché treated it as a range for directory index. It should be part of the directory name.

This change fixes a problem that happens when the current directory is not the MGR directory (the directory corresponding to CACHESYS). A configuration re-activation in this situation could cause the system prohibit user to login.

In previous versions, when an application error was logged into the error trap using %ET or %ETN, the entries written to the error global were not journaled. This was so that if the application was in a transaction, and the transaction was subsequently rolled back, the error log entries would not get rolled back as well.

This behavior has been changed so that the error global is now journaled, but is marked as not being part of the application user's transaction so it will not get rolled back if the user's transaction is rolled back.

Note: the error global is only journaled if journaling is enabled for the database it is being written to.

This change fixes a case that using ^DATABASE or the Management Portal to delete a Database could cause the Dataset section in the CPF file to be incorrect. This could result in other databases being lost from the configuration file.