The current maintenance kit is Caché 2007.1.5. This document is only part of the available maintenance kit documentation. The full set of documents is available in the \Docs subdirectory of your Caché installation as follows:

• Late-breaking information about the release: \relnotes\cache\readme.1st
• Release notes for Caché 2007.1.5: \relnotes\cache\relnotes.htm
• Release notes for the previous maintenance kits since 2007.1: \relnotes\cache\prenotes.htm (this document)

This document is a historical archive of changes in Caché since the original 2007.1 release, but prior to the current maintenance kit. Changes unique to the current maintenance kit are described in relnotes.htm.

This document includes the following sections:

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

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

This document includes the change reports from:

• Version 2007.1.4
• Version 2007.1.3
• Version 2007.1.2 and earlier

This build corrects a fault that could lead to CGI environment variables not being removed from the cache when no longer defined. The fault corrected with this change could occasionally result in environment variables left over from previous requests.

The hash function used to manage global mappings might cause data validation errors in worst case scenarios due to a high number of collisions.

This change installs an improved hashing function and increases the size of the hash buckets.

Previously, the %IsModified method was available only on the server. This correction changes %IsModified() to be available on client-side systems too.

The arguments in the job command include the specification of an operating system directory to which a child job should switch as part of its startup. However, this is not necessarily the directory the child job will use; it may be overridden by the default directory associated with the namespace for the child job.

Furthermore, errors switching to the directory in the child job were not treated consistently across platforms. On Windows and OpenVMS, errors were ignored. On UNIX systems, the behavior varied depending on the platform and Caché version.

With this change, all platforms have now been changed to return a <DIRECTORY> error to the original job command if the child fails to switch to the specified directory.

This change alters the permissions on the shared library, /usr/lib/hpux64/dld.so, to allow Caché to access it at startup time.

Under rare circumstances, ECP server initialization can fail while partway through leaving a state that may prevent later ECP recovery or clean up. When this happens, a Caché restart is required to recover.

This change prevents the initialization failure from occurring.

In very rare conditions, when the ECP Server fails unexpectedly, and an ECP client connects after dead job cleanup, a race condition can cause confusion about the job identifiers and prevent successful recovery. This correction eliminates that race condition.

The ECP server guarantees that database changes are durable before granting a lock. In rare conditions, the validation did not ignore dead ECP server sessions properly.

This change corrects that behavior. Now, in the worst case, a database server with dead ECP server sessions may end up in an unexpectedly long wait.

Remote de-locks originated by the cleanup of failed jobs may itself fail and leave the ECP client in an unexpected state. This has been corrected.

When an ECP application server is shutting down, the ECP read daemon may not detect and cleanup the dead process daemon, and may end up waiting for it go away forever. This is now fixed.

This fixes an error that occurs when ECP clients execute $DATA() with 2 arguments to get value of the global node. If the global contains a string longer than 4000 characters, the system internal argument stack could become misaligned causing various error afterwards.

This change provides a workaround for an issue in the Xerces XML parser that incorrectly reports namespace prefixes. Details of the issue can be found at the Apache website.

In practice, this is most visible in the %XML.TextReader class where the endelement node types have the wrong name. This workaround addresses the issue by internally fixing up the name when the node is accessed.

This fix corrects a concurrency error caused by multiple Java threads attempting to validate the cached data for a class while fetching the class definition metadata.

This corrects a problem where the Light C++ Binding incorrectly stored 0 rather than null for null properties of types %Double, %Float, and %Currency.

This corrects a problem where the use of blocking io on some UNIX platforms would cause problems when the Xerces parser tried to access data over a network (such as trying to get the document DTD).

This corrects an issue where a UNIX user could bypass privilege checking and become a member of the "cacheusr" group. The permissions on Caché have been changed to -rwx--x---.

This change prevents a user from entering a "" (null) username and password when logging into a Visual Basic Cache Direct application, thereby authenticating as the UnknownUser when Unauthenticated access is not enabled for Cache Direct applications.

A change has been made to the SQL filer to help reduce the number of locks acquired for large updates on tables with foreign key constraints. When a table is updated, a lock is acquired on the referenced table row for every foreign key. In the event the update is rolled back, this insures old referenced rows are still valid. This logic previously locked all the rows referenced by foreign keys, if the foreign key field values did not change.

Now the system will only lock referenced rows where the foreign key field(s) have actually changed. This will reduce the number of locks required for this situation in large transactions involving updates where not all fields are updated with new values.

This change corrects an issue with multibyte character streams when characters containing more than one byte occur exactly at the end of an internal buffer byte location that splits the character. This caused a conversion error on character sets like those used in Japan, China, Korea.

When closing multiple objects (for example, via $SYSTEM.OBJ.CloseObjects), under some circumstances the system could get an access violation error.

This has been fixed.

This change corrects a problem where a MERGE of array nodes into a local variable, V, followed by KILL of all the array nodes, would result in $DATA(V) having a value of 10 or 11 when it should have been 0 or 1.

This change fixes a <NOLINE> error that occurred when a label with Unicode characters was used.

When changing namespaces, the routine target cache is cleaned up, since it is namespace-specific. This modifies the order of the target cleanup to avoid process routines encountering cache corruption and/or access violations.

If a routine switches its namespace and invokes some other routine(s) and a later invocation finds the original routine in the cache, the references to the routine source may fail (i.e. errors, debugger, or $text). This change preserves the invoking namespace when the routine is invoked from the routine cache.

This corrects a rare error where, if a journal switch occurred with no pending journal data to write, the journal synchronization position could be set to the wrong value.

This change fixes an error in the 4 argument version of $PIECE() on Itanium platforms. The problem would manifest itself only when:

Before this fix, on Itanium platforms the following would return the null string:

USER>Set data="ABC^XYZ^123",x=0,y=1
USER>Write $P(data,"^",x,y)
ABC

This changes corrects a situation where, if the write daemon could not process a directory or a database lock request within its preset timeout, the operation was treated as a success. It will now be considered a failure.

Attempts to create a database when the write daemon is unable to respond to lock requests for 60 seconds or longer will now fail. Previously they would succeed but this would cause errors if two systems tried to create a database in the same directory at the same time.

A situation which could lead to priority inversion hangs on AIX platforms has been resolved. This appeared on systems which use ^%PRIO (or other mechanism) to adjust the process priority. A symptom of the error is that the system would appear to be hung yet consuming lots of CPU time and cstat would show several (20 or more) jobs in the LOCK module, not in a WAIT state.

The following changes have been made to improve cluster recovery:

• The maximum path length for Caché databases and other files has been decreased from the prior limit of 232 characters to 227. For a database, this refers to just the directory portion of the path. For other files, it can include the final file name. As a general rule, the path name of the root (or home) directory for a Caché instance should be approximately 195 characters to allow for the subdirectories and databases within its structure.

• A long standing cluster failover problem has been resolved where the journal restore was not correctly synchronized across the cluster members. If a cluster member failed while it was in the process of writing to the WIJ file, its journal would be restored from an earlier point in time (one write cycle) than the other cluster members. If, during the prior write cycle, the other cluster members have sets or kills which came after the items restored from the failed system, these would be missing from the database after cluster recovery completed.

This change fixes the formatting of ":D" flag for dead jobs in the cstat PIDTAB display by placing the marker in its proper column.

cstat has been enhanced to allow it to perform self-diagnostics for many types of system hangs.

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 that way, then it examines the system state in effort to identify the cause of the hang.

Informational messages are output reporting the progress of the self-diagnosis and any relevant recommendations to the user. Finally, a list of processes is reported 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#>

As an example a hang with IJULOCK set and an updater waiting for a global buffer would produce self diagnostic output like this:

Beginning hang self-diagnosis
Updates are blocked because ijulock is set
System is waiting for the WD (job 2)
  WD (job 2) has set ijulock and is waiting for updaters to finish
    Updater job 27:
     Job 27 is waiting for bdb #9411
     bdb #9411 is in use by job 13
     Job 13 is suspect
     Job 27 is exonerated
     Job 2 is exonerated

Summary of Job States: {state: [job#:pid[|tid] [...]]}
SUSPECT: 13:5353
EXONERATED: 2:5298 27:5357
DEAD:
LOSTWAKE:

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 file number and block number of each process's retained buffer is displayed.

There are two general types of tools native to the operating system that can be used to investigate the suspect processes: user-mode process dumping tools and user-mode debuggers. To gather comprehensive information about a suspect process, use a user-mode process dumping tool. The resulting dump file can be very large, but contains the entire state of the suspect process. Other debugging tools can gather key information without needing to produce a large output file. Often using multiple tools in conjunction is desired.

User-mode process dumps by platform:

• Windows:
  The Userdump utility is provided and documented by Microsoft http://support.microsoft.com/kb/241215

• UNIX:
  For Solaris, Linux,and HPUX: use gcore
  For AIX: use gencore
  kill -11 may be used to cause the process to terminate and core (invasive)

• OpenVMS:
  SET PROCESS /DUMP=NOW /ID=

The cstat problem analysis program should be run as administrator on Windows Vista when the Caché Service is running as SYSTEM. If it is not, the status of processes in the PID table cannot be determined.

With this change, Caché will print a warning to the user when this situation occurs.

A problem is corrected that caused job servers to exit with an access violation in Caché.

When a job is terminated abnormally, there is a chance that the job could get into a CPU loop. This change prevents that possibility.

This change corrects an error that occurred when a job exhausts its heap memory space while trying to set up its cache of recently-used global subscripts.

This change fixes an access violation that can occur on Caché when using a MERGE command with two local arrays.

This change fixes a situation where Caché shutdown on OpenVMS could hang because a job's terminal output was suspended by Control-S.

This change extends the allowed length of an OpenVMS terminal device name from 7 to 10 characters.

This change fixes a possible <STRINGSTACK> error when exporting an object that contains large arrays.

During an upgrade, Caché would erroneously enable some services that would have been disabled during the initial install. This has been fixed; Caché only updates the capability properties of these services (i.e. types of authentication allowed for the service.)

This change makes Backup.General.ExternalThaw() return OK, if no prior Backup.General.ExternalFreeze() has been called.

OpenVMS could close a Caché terminal session because of inactivity/timeout. This change now properly handles that situation.

If a cluster slave crashes or is forced down when the master has one or more active ECP connection, cluster recovery may leave the cluster in a partially recovered state and prevent the slaves from restarting and joining the cluster. Slave restart may assume the master is middle of ECP recovery, and wait forever for the master to finish the recovery.

This change corrects the issue.

This affects systems which support clusters (for example, all OpenVMS versions and the Tru64 version with cluster support) regardless of whether the Caché instance is part of a Caché cluster or not.

An error has been fixed where, in very rare circumstances, an attempt to expand the database could get an access violation or could enter an infinite loop syslogging errors during the expansion of a non-cluster mounted database. The error code syslogged is 8484 (0x2124) in module #16.

This change fixes a cluster journal sequence number out of synch with ECP cluster connection.

This change addresses an issue where a manually initiated journal switch could block journal daemon from rolling to a new journal file.

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 resulted in the loss of journal data, in which 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, the operator 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.

Prior to this change, journal switch would get a <SYSTEM> error.

This change addresses a performance issue in scanning a journal file for open transactions in journal recovery (at Caché startup, cluster failover, and so on). With this change, the time spent in the scanning operation has been cut by half.

The phrases "primary/secondary journal directory" and "current/alternate journal directory" are not interchangeable; there are subtle difference between them.

Primary and secondary journal directories are persistent journal properties that are created and modified by the user only; current and alternate journal directories are transient journal properties that are used by journal daemon. The current journal directory, by definition, is where current (i.e., the latest) journal file is located. The alternate journal directory is "the other" directory that journal files should go to when a problem with current directory arises.

Journaling always starts in the primary directory. The primary directory is the current directory and the secondary, the alternate. That remains the case until journaling encounters an error (for example, disk full) in current (primary) directory and fails over to the alternate (secondary) directory. At this point the secondary directory becomes current directory and the primary, the alternate.

Journaling will alternate between primary and secondary directories upon an I/O error in current journal directory.

cstat -j1 shows the current and alternate journal directories. When the user creates or edits journal directory properties (via ^JRNOPTS or MgtPortal), any default values given for these properties affect the primary and secondary directories.

Prior to this change, after the journal failover, a journal switch performed by the user (via GUI or CHUI or API such as ^JRNSWTCH) or task manager (at midnight by default) caused the alternate directory to be set to the current directory and, as a result, there would be no alternate directory for journaling to fail back to if there should be a problem with the current directory.

All journal switches are still logged in cconsole.log.

This change corrects an issue that occurs when a system is set to freeze on journal error and journaling fails to start at startup. Prior to this change startup continued; with the change it now aborts.

This correction addresses an issue where, in certain circumstances, a $BITSET occurring in a transaction would be journaled with incorrect old value and old bit length. A rollback of this $BITSET would restore incorrect data to the database.

This change corrects an issue with shadowing a Windows source that could cause shadowing to stall if the source journal file path contains upper-cased characters. On the Windows source side, one may see errors like the following in cconsole.log (and shadow source error log):

NEXTJRN: -98,'D:\CacheSys\Mgr\Journal\20071221.003' appears to be
the next file of 'D:\CacheSys\Mgr\Journal\20071221.002' but
contains a pointer to a different previous file from
'D:\CacheSys\Mgr\Journal\20071221.002' and thus couldn't be the next file

This change corrects a potential journal performance issue on AIX 6 systems where Caché was unable to determine the type of the filesystem hosting the journal files. As a result, Caché was unable to use the optimal settings for journal I/O performance, even if the underlying filesystem was mounted with the recommended optionns (for example, cio for JFS2).

This corrects a situation where a process (synchronous TCOMMIT, ECP daemon, write daemon, etc.) waiting for the journal daemon to commit the journal up to a certain offset could get stuck indefinitely (depending on the journal activity volume on the system).

This occurred in rare circumstance that involved a journal switch before the wait. The problem affected only Caché systems that saw very little journal activity and used small-sized journal files (as a result of either journal file max size being set to very small or journal files being switched frequently by the user).

This change addressed an issue that could cause rollback of a SET whose new and old values are strings of significant lengths (that is, close to 32KB), to fail.

This change corrects the following limitations regarding the affect of TROLLBACK on TCP devices:

• TROLLBACK could clear the user-specified line terminators of current TCP device

• It would suppress the <DISCONNECT> error during rollback only if current device is TCP and has the D mode turned on. It would not suppress the <DISCONNECT> error during rollback
  • if the current device is NOT TCP, or

  • the current device is TCP but doesn't have the D mode turned on

This fixes an error in Caché cluster shutdown when there are three or more cluster nodes in operation. In some cases, when the cluster master shut down, the new master node could get a corrupted lock table.

When a multi-item LOCK command contains duplicate items, for example,

L (^a,^b,^c,^b))

and those locks are mapped to remote ECP server, there is a possibility that the ECP daemon on the client side could get an access violation error, < ACCVIO>.

This change fixes a problem on an ECP/DCP network which could leave a shared mode lock on the ECP/DCP server while there is no lock entry in client node.

This change fixes a network lock problem where a ECP/DCP client job could hang when it has a node locked and another job locked the parent node of the one it had locked.

This change corrects an issue that caused a spurious error to be logged in cconsole.log in place of a real error (or warning) message from shadow or source server.

This change reworks the prefetching algorithm to improve performance of shadow dejournaling.

On OpenVMS, sometimes the process that shuts down Caché (executing cforce()) hangs forever.

This change prevents that situation.

In a TCP server process whose current (TCP) device has disconnect detection (the "D mode") turned on, TROLLBACK might fail after the TCP client disconnects, leaving databases in an uncertain state. This change allows TROLLBACK to finish regardless of the state of client connection.

This change fixes a transaction error that can occur when a pending transaction does SET or KILL over multiple remote ECP systems. Under these circumstances, the ECP daemon on a remote ECP remote system may fail, or cause the transactions to be out of synch on the ECP server.

This problem only occurred when set/kill is done on two different ECP remote system.

This change disables the quick integrity checking on globals restored from the WIJ. This could take a long time when the global happened to contain large amounts of data.

This change fixes a problem in Backup.General.ExternalThaw for OpenVMS. When it was called from a command line, the process would hang. This is not a problem on Windows or UNIX.

This change makes the MGR directory the assumed default directory in cstat. It is not necessary to add "-s." on the command line.

This change correctly associates the "wdphase" column in mgstat with the underlying data value. It also adds columns for "wdpass", "ijucnt" and "ijulock".

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 both of the following conditions were met:

• The DISTINCT was not actually needed because the rows would satisfy the DISTINCT anyway, such as in:
  
  

  SELECT DISTINCT <primary key> FROM <table>;
  

• The WHERE clause of the query contained a subquery

Under these circumstances, 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 had data with the index,
  
  
• all subscripts before the ID had equality conditions on them,
  
  
• there was 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 correct behavior is to keep the system suspended until all of them complete their pending operations succesfully. This change modifies the behavior so that Cacheé now waits until all the daemons succeed in writing their values.

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.

When you login CSP will normally automatically redirect you have to the original page so you do not see the login username/password in the URL and you can refresh this page without getting a 'To refresh the browser will resubmit your data to this page' dialog.

Due to how this redirect was done if you created an encoded page and then brought it up in the browser you were presented with the login page. If on this login page you enter a parameter value %quot;MONEY=9999999", for example, and then login, this parameter value was being automatically encoded so it appeared this value came from the server when it was really entered by the user.

This could be a fairly serious security issue for any CSP application that relies on encoded parameter values. This problem was first introduced in 2007.1.

Now we make sure we do not encode these user values on the server which avoids this problem.

The application server checks and converts the requests to the server's endian. Previously, requests with Unicode strings were NOT converted to the server's endian. This caused serious problems when the application server and the database server were of differing endianness.

This change fixes a problem in the Light C++ Binding. When storing C++ double values in %Float or %Currency properties, Caché performed bad conversions for certain numeric values. This resulted in wrong values (usually zero or near-zero values) being stored in the database.

The problem occurred for approximately 0.3% of possible numeric values. Any given value would either always be converted correctly, or always incorrectly.

A problem on Unix and OpenVMS which prevented the job command from succeeding when a process slot had been used too many times has been resolved. This was introduced in 2007.1 and is now fixed.

On AIX platforms, if a Cache instance is owned by someone other than root but startup is done by root, inter-process signals may not be received. This affects commands like JOBEXAM or RESJOB.

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