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

InterSystems advises all users to recompile their applications as part of the upgrade process so as to take advantage of all the performance improvements as well as other changes that may affect them in this release.

This release describes the change made since Caché 5.2.3.

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.

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.

An issue has been corrected where huge config files would cause startup to take more than 10 minutes.

An error has been fixed where the config file was parsed and imported in places other than STU. This could cause odd effects when customers edited the CPF file by hand and their changes made it into Caché before they imported them.

An error has been fixed where entering a subscript–level mapping for a global could cause startup to fail.

An error has been fixed where deleting a database via ^DATABASE would cause an ERROR #642.

An error has been fixed where changes in ECP network properties were not logged in the Audit database.

An error has been fixed where a permission error occurred in a chmod call during startup and shutdown.

An error has been fixed where backup CPF files were created when Caché was restarted, even when there were no changes to the configuration.

UNIX installation will allow users to install both "ppc" and "ppc64" platforms on 64-bit AIX systems regardless of CPU architecture. Prior to this change it would not list ppc64 as a valid platforms for the POWER3 architecture.

Before installing SAX and Basic files, we will clean up the following files from <cachesys>/bin in upgrade installations on UNIX: libCstd.so.1, libCrun.so.1, libicudata.so.21, and libicuuc.so.21.

On Caché startup, the web port will be passed in the form "0.0.0.0:<portnumber>" to force Apache to use only IPv4 sockets. This is done as a work around against a problem in the IPv6 implementation on some Solaris versions; IPv6 sockets would sometimes disappear and Apache would not stop correctly on Caché shutdown.

Deleting of journal files is now done through the Task Manager.

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.

When a namespace and global/routine mappings are created through the Management Portal, and then later the namespace is deleted, creating a new namespace with the same name before restarting the browser would result in the previous mappings appearing in the Management Portal. This has been corrected.

This change adds a shadow parameter to allow the user to specify how old the shadow copy of a source journal file can be before it gets purged.

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:

Days of old copied journals to keep:

This change adds the "Null Subscripts Enabled" option to the Advanced Configuration/ObjectScript section.

If the Management Portal was used to create global mappings, and Caché is restarted, selecting "New Global Mapping" in the portal may erase the previous mappings because the browser was unaware of the Caché restart. This problem has been fixed.

Currently the control process is run/set with a different user id than the super server. If the control process is not root, it cannot accept/import the delegated sockets from the super-server.

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

ECP application servers with multiple connections may encounter this issue in rare conditions—

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.

The ECP server guarantees the associated changes are durable before granting a lock. In rare conditions, the validation did not account for dead ECP server sessions properly.

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

Remote de-locks originated by the dead-job cleanup may fail and leave the ECP client in an unexpected state. This has been corrected.

This change corrects an error where, during an upgrade, the maximum database size could be altered.

In previous versions, whenever Caché was installed on an existing system, all the routine indices were rebuilt for all the user databases. Now Caché only rebuild these indices if it is upgrading from an older version.

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 change alters Studio so that it only saves patterns including '*' for its file list, and the last-used pattern becomes the default for the next attempt to locate files.

This fixes an issue where Studio attempted to lock a document twice.

When a template was used for the first time in a Studio session, it removed any locks Studio currently had open. This would allow other users to edit routines/classes that this Studio should have maintained exclusive access to. This is now fixed.

This change causes Caché to release the global block that the process may be retaining from the most recent global operation when a pattern match operation begins. This allows other processes to proceed with access to the global during the possibly long time of the pattern 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 properly handle a <FRAMESTACK> error.

A MERGE into an existing local variable node, followed by a KILL of that node should leave $DATA() = 0. This change fixes a situation where $DATA() would report 10 and $ORDER() would return a subscript which did not exist.

When a <FRAMESTACK> error occurs, the system attempts to remove some execution levels in order to have enough room to run an error trap. The algorithm that it used was not sufficient to run the entire %ETN error trap, causing incomplete error logging or recursion within error traps. This is now corrected.

Socket delegation uses UNIX domain sockets to pass an open socket to the new job. The UNIX domain socket path is limited to 108 chars (104 on some systems). To create a unique UNIX domain socket name, Caché formerly used <mgr dir>/nti/<job num>. If the manager directory path was long, the path length exceeded that limit.

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 rare circumstances, the cluster master normal shutdown may corrupt the write-image journal header which prevents the system from restarting with journaling enabled. This has been corrected.

This change corrects an issue involving a manual journal switch in "quiet" Caché system — one where no global SETs or KILLs are being done.

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

If the system becomes marked as frozen while the write daemon is writing to the databases, the write daemon unfreezes the system when it completes writing the databases. But it is immediately frozen again until the write daemon writes the write-image journal for the next pass.

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.

A -K<switch #> option has been added to cstat to clear switches in the corresponding instances of Caché. This is intended to be used only in an emergency, for example, if a process sets a switch and exits. Setting a switch (eg. 13) and exiting may leave Caché in a state where a process cannot get into the system to clear the switch.

The command

..\bin\cstat -s. -K13

will clear switch 13.

If the process which set the switch is actually running it will not notice that the switch was cleared and it may report a successful completion when in fact the results are corrupt.

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.

An error has been fixed which could result in an exception in the write daemon if the journal file is switched twice while the write daemon is busy writing blocks back out to the database files.

A problem with gcompact has been resolved where it would sometimes report a <DATABASE> error which in turn could freeze the system. This occured when starting the compaction in the middle of a global. Sometimes this occurs internally in the gcompact routine as the system code may return to the COS routine periodically to report progress when compacting a large global.

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

Under rare circumstances, when Caché is running on UNIX and OpenVMS platforms, 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. It is implemented by this change.

The command line handling for Caché application mode has been enhanced to permit passing parameter lists consisting of string and/or numeric literals as well as omitted (void) parameters. Routines and procedures can be invoked, and class method calls may also be made.

General syntax forms are:

tag+offset^routine
tag^routine([parameter-list])
##CLASS(package.class).method([parameter-list])

More specific syntax forms are:

^routine
tag^routine
tag+offset^routine
+offset^routine
routine
^routine()
tag^routine()
routine()
^routine(parameter-list)
tag^routine(parameter-list)
routine(parameter-list)
##CLASS(package.class).method()
##CLASS(package.class).method(parameter-list)
##CLASS(package.class).method

A parameter list may appear as:

("string literal",,-+-000123.45600E+07)

where omitted (void) parameters are passed as $Data(parameter)=0 to the target.

Whitespace and shell metacharacters must be quoted in an O.S. dependent fashion. For example:

Windows:

General^^ADMIN(""""%username%"""",,-12.34,""""a b"""")

UNIX:

"General^ADMIN(\"$USER\",,-12.34,\"a b\")"

OpenVMS:

"General^ADMIN("""+F$USER()+""",,-12.34,""a b"")"

The Caché startup script for UNIX has been enhanced to avoid accidental misuse in high availability failover configurations.

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:

rm <directory>/mgr/cache.ids
ccontrol start <instance>

with:

ccontrol start <instance> @failover@

It is important that a properly configured, secure failover filesystem should only permit write access to a single node at any given moment, being switched under exclusive control of the failover software. If the filesystem allows simultaneous write access to multiple nodes, Caché will not be able to block an accidental failover startup should the instance already be running on a different node.

On OpenVMS, there is no way from Caché to determine the record format of a file at all. So when doing an XML import, Caché always assumes the file is not in 'UNK' mode and copies the file to a new file so the record format is known and it can later be imported.

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 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 change introduces a check for a valid cache.ids file in ECP configurations.

An allocated space of 5GB for buffers displays as 948MB (although the full 5GB is actually allocated). This is the result of an overflow during conversion and has been fixed.

If a 2k database has %globals stored in it, an attempt to view them using the Management Portal fails with an error message:

Database, c:\datasets\mdm\, is not available

This does not occur if the 2k database does not have any %globals in it, or if the database is 8k. This has been fixed.

Beginning with Caché 5.1, for all UNIX systems, the hard limit for the maximum file size (RLIMIT_FSIZE) on any system running Caché must be "unlimited".

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.

A Caché running with current limit less than the maximum hard limits for file size could still encounter a serious i/o error if that limit was less than the size of the cache.dat or cache.wij files. The current limit is now set to the hard limit for file size, core dump size, and open files.

This change fixes a problem where the control process crashes while validating the 'cache.ids' file. It happens within a few minutes of pausing the system because the write daemon is not making progress.

Add code to stop the Web server when Caché is forced down on UNIX platform.

Make sure the journal life span maximum is 100 days when upgrading Caché.

This change fixed a condition where the backup could take a longer time as expected because write daemon's delay.

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

This change corrects issues that could cause journal corruption during ECP cluster failover under certain circumstances.

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.

The customer regularly gets a orphaned process stuck in CLOSH status Caché spinning at the AIX level.

In the scenario where Caché is configured NOT to freeze on journal I/O error, journaling will get disabled when one of the following conditions is met:

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.

This change addresses an issue that could cause system to hang after a failed journal switch if

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

This change adds an API for purging all journal files except those required for transaction rollbacks or crash recovery. The method is:

A crash recovery refers to the journal restore performed as part of Caché startup or cluster failover recovery.

A front end interface is provided as part of ^JOURNAL for a couple of options to purge journal files, one of which is to purge all journal 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 has two effects:

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

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 the desired 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 and 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, 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.

This change addresses various issues that, in certain circumstances, could cause journal restore to fail, or produce incorrect result on Caché systems where cachetemp max size is fixed.

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

With this change, simple journal rollovers, regardless of their issuers, are no longer logged in journal history global (^%SYS("JOURNAL","HISTORY")). This is consistent with the behavior of journal daemon.

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.

This change addresses an issue that in certain circumstances could cause a $BITSET operation within a transaction to be journaled with incorrect old value and old bit length. This would cause incorrect values to be restored if the transaction gets rolled back.

This change corrects an issue with shadowing where a Windows source that could cause shadowing to stall if the source journal file path contains uppercase 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

An error has been resolved where Caché would permit switching journal files after an fsync error had occurred 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 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).

With this change, ^JRNOPTS now permits modification of journal options, even when journaling is stopped.

Journal file prefixes are again supported by the configuration utilities. The journal file prefix can be set or modified using the ^JRNOPTS utility (available from ^JOURNAL), or the Management Portal -> System Administration -> Configuration -> Journal Settings page. Any change to the journal file prefix requires a restart of Caché to become active.

Journal restore will now use multiple processes on multi-processor systems when all directories and globals are selected.

A problem has been corrected where running ^JRNSWTCH could, in rare circumstances, reduce the maximum journal size.

The license server has Caché database files open on UNIX. If it remains running after a Caché instance shutdown (as it will if it services multiple instances) the cache.dat files remain open.

This behavior has been changed so that it now closes all file descriptors before calling execl() to execute the program or script.

It was possible for the license monitor of a Caché instance to repeatedly attempt to restart the license server. This would result in hourly messages in cconsole.log noting the restart. With this change, the restart no longer happens unnecessarily.

The temporary CLMANAGER-STARTUP.COM file created by ^LMFMON to start the license server on OpenVMS is not deleted, although it is purged. Eventually this can lead to an overflow of the version number, making it impossible to create a new version of the file. This leaves error reports in ^SYSLOG.

Any residual versions of the file are now deleted before attempting to create a new version.

A problem has been corrected that prevented use of DDP networking with an Entree license.

A problem is corrected where the adjusted license user limit often used for Ensemble licenses is not recognized by the license upgrade procedure.

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

This change fixes a problem where an ECP client job owned many ECP locks and some of them have parent and children relation (e.g. ^node(1) and ^node(1,2)).

An unlock all (or job termination by JOBEXAM) could lead to some locks remaining in the ECP server while they are released in the ECP client.

A possible ECP client job could hang on lock command due to inconsistence of lock table. And this problem exists on Windows AMD and Linux AMD platforms.

This change now permits only a single updater for shadow databases. Prior to this change, the default number of database updaters was determined based on the numbers of CPUs and shadow databases. With multiple database updaters, sets and kills are not necessarily applied in the order they are in the journal file.

The situation on the shadow systems is as follows:

• one copier, which copies source journal files to the shadow (one per source cluster node, if the source is a Caché cluster);
• one journal reader, which reads the shadow copies of source journal files and queues up the sets and kills that need to be applied to shadow databases;
• one or more prefetchers, which fetches the globals involved in the queued sets and kills from shadow databases, hopefully before the database updater does, for optimal performance of database updater;
• one database updater, which applies the queued sets and kills to shadow databases.

This change addresses an issue where the cluster shadow dejournaler would not start dejournaling a current shadow journal file (that is, a file being fetched by one of the cluster shadow copiers) until there is a journal record in the file with offset >= 196608.

As a result, the cluster shadow could remain out of sync indefinitely with the source when there is little journal activity.

This change corrects a situation where, under certain circumstances (such as when the shadow update daemon falls far behind the shadow journal read daemon), the shadow may:

1. fail to apply one or more records at or prior to a checkpoint location, and/or
2. apply the record at the checkpoint location incorrectly.

This could happen only to the last checkpoint created when the shadow is about to suspend or stop.

This change corrects an issue that could have caused a cluster shadowing to suspend, rather than continuing with other nodes of the source cluster, when a source node died.

As of this change, one is allowed to modify the properties of a shadow when it is suspended. However, changes to some properties would not take effect until certain conditions are met. For example,

• Changes to the "Source event to start at" property would not take effect until the shadow is stopped and restarted;
• On a cluster shadow, changes to the "Directory to store copied journals" property does not affect the locations of shadow copies of the journal files from the existing nodes of the source cluster. Only journal files from the new nodes of the cluster will be copied to a subdirectory of the newly specified directory until the shadow is stopped and restarted.

This change corrects an occasional timeout error in stopping a shadow by making stop wait a bit longer than the shadow hang interval (default=10) and TCP read timeout (10).

This change corrects an issue that caused an error like ""<LIST>decomposeStatus+16^%occSystem" to be logged in cconsole.log in place of a real error (or warning) message from shadow or source server.

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

This change alters the way Caché shutdown and startup handle cache.ids. If cforce detects processes still running, it will produce an error message and run freeids to remove all ipc resources, but it will not remove cache.ids. On startup, Caché will detect a shared memory segment marked for deletion and halt.

Permissions on the CSP.ini file in the <install_directory>/csp/bin/ directory were modified during Caché startup on UNIX. Now the permissions are maintained.

If startup fails due to an inability to write out the cache.ids file (for example, the disk is full), then slave write daemons are left behind, a zero-length cache.ids file is left behind, and shared memory is not deallocated. This is now corrected.

If an error such as <FILEFULL> happens when the error trap routine is creating the ^ERRORS global entry, Caché will now 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 validates the subscripts a user enters in Management Portal when configuring subscript-level mapping.

This change corrects a startup problem when the current OS directory in not the MGR directory.

This change corrects an issue where global compact gets a <SYNTAX> error when the subscript contains a ':' character.

This change improve the performance for activating namespace configuration when many namespaces are configured.

This change fixed a problem when SWITCH 13 is turned on the CLRINC^DBACK() would hang. This only occurred on 64-bit Big Endian platforms. This is fixed in 2007.1 and later, so this is only a problem for 5.2 and earlier version.

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

Fixed 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 problem fixed an issue that when a process uses a pipe for I/O of a Caché session, it could get an unexpected <ENDOFFILE> error.

This change corrects an issue in the ^DATABASE utility when a user enters a directory name with '-' at the directory prompt. Caché does not want to treat it as a range for directory index. It should be part of the directory name.

This change fixed a problem when the current directory is not the manager directory, a configuration re-activation could cause the system prohibit user to login.

This change ensures that the following global nodes are set properly:

• ^%SYS("WebServer","Port")
• ^%SYS("WebServer","Name")

This change removes the cache.cpf parameter DefLoginNSP from version 5.0 and older CPF files as it is no longer used. This does NOT cause any problems during startup if it is left there, this change just cleans things up.

Prior to this change, when a Caché system starts up under the following circumstances:

• Cluster recovery
• Starting with NOSTU
• Incomplete or failed startup
• Any installation

Caché can start up without reading the CPF file and setting the systems default $ZU(69) settings. In this case, the system runs with default $ZU(69) settings provided by the system code; usually, these are 0.

In this situation, ^SHUTDOWN writes back to the CPF file the current settings of the $ZU(69) switches which are the system defaults, and not the settings which came from the CPF file. This will cause parameter settings to be "lost".

This change recognizes these situations and does not overwrite the settings in the .cpf file.

When a namespace mapping is reactivated, all old namespaces on the system are removed, before the new map is reactivated. Any implied namespaces which were created "on the fly" by using ZN to change to them are also removed by this process. However, since these implied namespace definitions are not stored in the CPF file, they were not restored when the new namespace map was created. Thus a user who was working in an implied namespace when the system underwent a namespace reactivation, would receive a <NAMESPACE> error.

This change saves all the old implied namespaces which have been defined, activates the new namespaces, then adds the implied namespaces back in.

This changes adds two new parameters (username and password) to the methods ExternalThaw and ExternalFreeze in the class Backup.General. See the class documentation for details.

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 that the error global is only journaled if journaling is enabled for the database it is being written to.

On OpenVMS systems, Backup.General.ExternalThaw called from the command line would get a Database error and loop forever. The problem was caused by trying to call the erase_private_globals function. The thaw routine never initialized the private globals vector, so this call would fail.

We now skip over this if we are calling Thaw from the command line.

If password authentication was enabled for a CSP app, and Unauthenticated access was disabled, a user could log into the CSP application if they specified "UnknownUser" as the username, and then entered anything for a password. This has been fixed to require the correct password for the "UnknownUser". This is only a problem in versions 5.1 and 5.2. It has already been corrected in 2007.1.

This change fixed a case where using ^DATABASE or the Management Portal to delete a Database could cause an error in the Dataset section in CPF file. The index won't be in consecutive sequence. When Caché was then started, the Configured database in the CPF file won't be mounted.

^%PRIO now works consistently across all platforms.