Caché 4.1.16 Change Summary

This document is the Caché 4.1.16 change summary. It provides an overview of changes in this maintenance release. For detailed information on getting started, see the Caché 4.1 Release Notes (also located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 4.1 maintenance kits, see the previous change summary document (also located off the Caché installation directory in the file Docs/GCRN/prenotes.htm).

This document has several sections:

• Security Vulnerability Notice
• Special Notes (Including Possible Compatibility Issues)
• General List of Changes
• Using the New Journal Restore Interface

Security Vulnerability Notice - 27 June 2003

Caché and write permissions on UNIX systems

Default installations of Caché for UNIX systems are configured with write permission on the Caché bin and csp directories enabled for all UNIX users. In addition, Caché can be installed in a configuration that allows UNIX users (other than “root”) in a specified group to start and stop Caché. This can result in certain vulnerabilities if hostile users have access to the system. The following example assumes that Caché has been installed in /cachesys and that members of the “cachemgr” group are allowed to start and stop Caché.

• Vulnerability #1:
  Caché startup utilizes a setuid-root wrapper program, cuxs. A hostile user who is a member of the “cachemgr” group could overwrite /cachesys/bin/cache with arbitrary code, and cause that code to be executed as “root” by invoking /cachesys/bin/cuxs.

• Vulnerability #2:
  Caché Server Pages (CSP) technology is for building and deploying Web applications. Caché executes CSP content using the UID of the user that started Caché, which could be “root”. A hostile user could insert arbitrary code into subdirectories under /cachesys/csp and cause that code to be executed by Caché by accessing it using a Web browser (or other user agent).

Present Status

The installation defaults have been changed for Caché 4.1.16 and 5.0.3. For more information, please contact the InterSystems Worldwide Response Center.

Workaround for earlier releases

Log on as “root”, change to the directory where Caché is installed, and issue the command:

chmod go-w bin

If Caché is not being used for CSP programming, and is not running in conjunction with a local Apache web server, issue the command:

chmod -R go-w csp

Special Notes (Including Possible Compatibility Issues)

Change permissions on csp and bin subdirectories

[ LRS697 ]

Category: Installation.UNIX

Platform(s): UNIX

Description: A new script is distributed with Caché, CSP_protect. This script, located in the <cachesys>/csp directory, allows you to disable or enable write access to the CSP directory and files after installation. For a description of the issues, please see the "Security Vulnerability Notice - 27 June 2003" that appears earlier in this document. The issues are a consequence of the permissions on directories created by the installation scripts for the Caché engine, and for the CSP network daemon, browser, and other files. Prior to this release, the installation used to create

• <cachesys>/bin with default -rwxrwxrwx
• <cachesys>/csp with -rwxrwxrwx (0777)
• csp subdirectories and files with -rwxrwxr-x (0775)

The script does change the groupid and permissions on various scripts and executables that are intended for use only by the Caché manager, but has not previously restricted directory access. The CSP_protect script is meant to be run at any time, for any UNIX version of Caché.

If you disable write access, for security purposes, currently available CSP applications and pages may be used, but no modifications are permitted. For this to be effective, you should start Caché as a non-root user but start the CSP Network Services Daemon as root.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
High	Low	No	No

Special Note Regarding Clustered Databases on OpenVMS

Category: Clusters

Platform(s): OpenVMS

Description: In OpenVMS cluster configurations, 8-KB formatted databases are preferred to 2-KB formatted databases. 8-KB formatted databases have additional recoverability in the event of a cluster node crash while multiple nodes are updating the same block simultaneously.

Special Note Regarding Linux ODBC

Category: ODBC

Platform(s): Linux

Description: The Caché ODBC client driver for Linux is not automatically installed. For detailed instructions on how to install the client ODBC component on Linux, see the provided ODBC Configuration document (odbcconf.txt, which is located on the installation media for Linux in the /dist/ODBC/ directory). This does not affect configurations in which Caché on Linux is serving ODBC requests from other clients.

Special Note Regarding Mag Tape Backup Performance Upgrade for Windows

[LRS675]

Category: System.Backup/Restore

Platform(s): Windows

Description: This Caché maintenance kit includes a revision in the backup utility that significantly improves performance for certain tape devices on Windows platforms. This may, however, render Caché unable to read backups from previous maintenance kits and versions.

For tape drives such as a DLT4, the backup block was being written out as a series of much smaller blocks. This revision significantly improves performance by ensuring that a single contiguous block is written, but it also means that a backup generated on the same hardware before this fix cannot be restored by a version of Caché with this fix.

Caution: Backups made on certain kinds of tape drives on previous versions under Windows might not be able to be restored by a version with this revision. Customers should make a new backup immediately after upgrading and/or retain a Caché instance of the prior production version.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Medium	Medium	Yes	Yes

Special Note on Class Compiler Optimizations

[ DLP689 ]

Category: Object.Class Compiler

Platform(s): ALL

Description: Optimized the class compiler by removing redundant internal tabular information, improving inheritance management, and other features. Any class or routine that looks at the compiled class metadata will need to be recompiled.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

General Changes

This section contains a list of the general changes between 4.1.15 and 4.1.16. These are listed by category in alphabetical order.

Add ClusterCommAddr parameter to Configuration Manager

[ CFL932 ]

Category: Config Mgr

Platform(s): OpenVMS

Description: Added the new parameter to the Cluster section. Its prompt and description depend on the value of NetworkType.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Optionally prevent creation of 2-KB databases

[ CFL933 ]

Category: Config Mgr

Platform(s): ALL

Description: The Configuration Manager now supports a parameter (in the General area of the Advanced tab) that allows users to specify if the creation of 2-KB databases is allowed. On upgrades from previous versions, this parameter is set to “Yes”, that is, 2KB databases are allowed. For new installs, the creation of 2KB databases is not allowed by default. If needed, the user can switch the parameter on.

Similarly, the Database Wizard has changed. The block size selection is now buried at a deeper level (via Advanced button) which is enabled only if multiple sizes are allowed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Inadvertent deletion of locks via the Control Panel is now more difficult.

[ CFL930 ]

Category: Control Panel

Platform(s): ALL

Description: Caché now prompts for confirmation when a request is made to delete a lock from the Control Panel, making it more difficult to inadvertently delete locks via the Control Panel.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Fix PID Hex display in lock list

[ CFL944 ]

Category: Control Panel

Platform(s): ALL

Description: Previously, the Control Panel's formatting would sometimes inadvertently convert certain strings to decimal numbers. This has been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Prevent potential loop in error trap in CSP server process

[ MAK769 ]

Category: CSP.Web Server

Platform(s): ALL

Description: Previously, if a process depleted its partition, then a call to BACK^%ETN to log an error could fail with a <STORE> error. In CSP-based applications, this could further result in a tight loop in the CSP server error handler. Now, %ETN logs some information and the CSP server process halts.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Fix endless loop in Explorer (rtn compare)

[ CFL927 ]

Category: Explorer

Platform(s): ALL

Description: An issue has been addressed that caused an endless loop in Explorer when comparing a routine from a sequential file with the one in the database.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Delete stale journal lock files during install

[ LRS686 ]

Category: Installation

Platform(s): ALL

Description: Previously, upgrade installations from a version of Caché prior to 4.0 could fail to start journaling due to a change in the format of the cache.lck file, which is used for locking. The current change fixes the problem by removing stale cache.lck files from the chain of journal directories.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

<NOLINE> compile error will not overlay previous error

[ CDS422 ]

Category: Languages

Platform(s): ALL

Description: An issue in the ObjectScript compiler could prevent the proper splitting of large object routines into proper-sized smaller routines. This has been corrected, so that some large routines that failed to compile now do so.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Improve DDP error messages for invalid configurations

[ DAS457 ]

Category: Networking

Platform(s): ALL

Description: When DDP is not configured properly, error messages are more informative during startup.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Added multiple NIC support for clusters

[ GK228 ]

Category: Networking

Platform(s): ALL

Description: This change improves reliability of cluster failover with multiple NICs by solving two issues with multiple NICs.

• A cluster member may not register a proper IP and port in the PIJ file, and slaves cannot locate/ communicate with the master.
• Slaves may not locate a correct net port to communicate with the master, and may not join the cluster.

It is recommended to define and use this when the cluster node has multiple/ambiguous local addresses.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Bind cluster IP to DCP cluster daemon

[ GK229 ]

Category: Networking

Platform(s): OpenVMS

Description: With multiple NICs on OpenVMS, the DCP daemon previously communicated with the cluster member using the wrong IP address. This has been corrected.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Corrected cluster IP address validation

[ GK231 ]

Category: Networking

Platform(s): ALL

Description: Previously, the “Cluster” configuration CLusterCommAddr value was parsed inconsistently. This has been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Place DDPMASTER in %SYS rather than implied namespace

[ TCS002 ]

Category: Networking

Platform(s): ALL

Description: Previously, the process DDPMASTER was starting in an implied namespace when Caché was started. This bypassed the mapping of temporary globals to CacheTemp. As a result, several temporary globals were created and stored in the MGR directory rather than CacheTemp. In some cases, at least one of these globals could grow very large and would not get cleaned out. DDPMASTER has been modified to wait until the %SYS namespace is defined; it then switches to run in %SYS.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Address Issue in %ClassDefinition to avoid losing Storage definitions

[ MC414 ]

Category: Object

Platform(s): ALL

Description:

When using %ClassDefinition to edit storage, some parts of the storage definition were lost. This change addresses that and thereby provides improved reliability for application development.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Unicode-Multibyte conversion on a Unicode system

[ DVU361 ]

Category: Object.ActiveX

Platform(s): ALL

Description: Previously, if a user connected to Unicode server and received information as an syslist type 1, this information was converted to multibyte according to user's locale.  As a result, characters not supported by the current locale could be corrupted. This change forces type 1 syslist strings to be treated as an packed Unicode, not a multibyte.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Modify Tru64 UNIX 5.1 CDL link procedures

[ LRS559 ]

Category: Object.CDL

Platform(s): ALL

Description: Previously, due to a runtime library binding error, the CDL compiler might fail to compile syntactically correct Caché ObjectScript routines.  This has been corrected. Note that this change only applies to the C++ v6.3 compiler with Tru64 UNIX 5.1 or later.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

SUBSCRIPT error in %SaveData method

[ DLP1075 ]

Category: Object.Class Compiler

Platform(s): ALL

Description: Addressed an issue in the recursive %Save() algorithm affecting saves for parent objects in parent-child relationships that have validation errors.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

%IsModifed is set because of Relate code

[ BJB266 ]

Category: Object.Relationships

Platform(s): ALL

Description: A rare issue with %IsModified has been corrected. If you had a class that had an independent pointer to a parent class and a child class of the parent and you swizzled in both, then the child would think some values had changed and it would call the %Save code.
%IsModified behavior improved in certain cases.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Fix <NULL VALUE> error in table compiler mapping to local array

[ DPV1989 ]

Category: SQL

Platform(s): ALL

Description:

Certain read-only tables could not be compiled due to issues with locking. This change addresses those issues.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

DDL: Fix ALTER TABLE Create Foreign Key does not check existing rows

[ DPV1976 ]

Category: SQL.DDL

Platform(s): ALL

Description: The sequence:

create table P(a integer primary key, b varchar(20))
create table F(one integer primary key, two integer)

insert into F(one,two) values (1,1)
alter table F add constraint toP foreign key(two) references P(a)

works up to Caché 4.1.6, but fails to properly return an error in Caché 4.1.9. This now returns an error -127 <FOREIGN KEY Constraint failed referential check upon creation of the constraint>.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Dropping a primary key did not delete a global

[ DPV2032 ]

Category: SQL.DDL

Platform(s): ALL

Description: Calls to the internal routine to purge an index was not operating properly. This has been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Drop Foreign Key should rebuild the Primary Key Index if collation changes

[ DPV2035 ]

Category: SQL.DDL

Platform(s): ALL

Description: Prior to this change, when a Foreign Key is added to a table through DDL and the Foreign Key constraint references a key in the referenced table which is also the IDKEY, Caché turned the field specified in the Foreign Key constraint into a reference to the referenced table. Now Caché will no longer turn the field into a reference if there is already data in the table when the foreign key is added through DDL.

Also, when a Foreign Key is dropped from a table through DDL and the Foreign Key constraint references a key in the referenced table which is also the IDKEY, Caché turned the field specified in the Foreign Key constraint into a regular field, not a reference to the referenced table. In the case where the field was a %Library.String type, this might result in the field suddenly getting a new collation. This occurred because the default collation for a string field is SQLUpper, but the collation of an IDKEY string field is always EXACT. Now, if this reference is dropped because the foreign key is dropped through DDL and there is data in the table, Caché SQL retains the EXACT collation setting for the field.

Hence, changes which affect index ordering now cause indexes to be rebuilt.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Changes for WTS (Windows Terminal Server) licensing in ODBC

[ JCN397 ]

Category: SQL.ODBC

Platform(s): ALL

Description: WTS license was using too many slots because there is no IP address for the client to match up with. This has been corrected. This results in better license detection for Windows Terminal Server and ODBC.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Set lockref only when needed

[ AK536 ]

Category: SQL.Query Processing

Platform(s): ALL

Description: Improved locking for

SELECT %ID INTO :temp FROM Sample.Person WHERE Name = :K1

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Apply correct processing to IN parameters

[ AK562 ]

Category: SQL.Query Processing

Platform(s): ALL

Description: Applied to IN the same logic used for binary operators such as '=', regarding when one argument is a field and the other is a constant/ host-variable. This normally applied only to fields of type %Date/%Time, but resulted in string operations sometimes giving incorrect results when attempting to find substrings.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Medium	No	No

Do not add "GROUP BY 1" to Query

[ BJB271 ]

Category: SQL.Query Processing

Platform(s): ALL

Description: With the SQL Gateway on Caché 4.1.15, if you sent a query such as

SELECT COUNT(*) query from Table

it would be sent as

SELECT COUNT(*) FROM Table GROUP BY 1

The GROUP BY should not be added to the query and has now been removed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Studio (version 4) could shut down if a server ID had a space in its name

[ DVU837 ]

Category: Studio

Platform(s): ALL

Description: Previously, an attempt to open a server with a space in its name could cause Studio to shut down unexpectedly. This has been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Studio creates extra server connections when security checking enabled

[ MAK826 ]

Category: Studio

Platform(s): ALL

Description: Previously, if you enabled security checking in the Caché Control Panel, then starting Studio would challenge the user for a password; regardless of whether or not the user entered the correct password, an extra ^%cmtP0 process was created, which would run until the user finally exits Studio. Studio now correctly closes these extra processes.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Avoid invalid NEW frame following a <STORE> error

[ CDS418 ]

Category: System

Platform(s): ALL

Description: If a <STORE> error happened while executing a NEW command, an access violation could happen during the subsequent error processing. This no longer occurs in this situation, thereby improving reliability.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Catch process "abend" signals on UNIX and clean up like Windows and OpenVMS

[ JO1444 ]

Category: System

Platform(s): UNIX

Description: If a Caché process on UNIX gets a segmentation fault, Caché performs appropriate clean-up tasks in a manner analogous to the already existing functionality for Windows and OpenVMS. This eliminates ghost processes.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Count of available buffers could get out of sync in panic mode

[ JO1694 ]

Category: System

Platform(s): All

Description: In the unlikely event that a system runs out of global buffers and enters panic mode, it was possible for the count of available buffers to get out of sync. In even rarer circumstances, this could possibly have lead to a system hang but most likely would go unnoticed. A notation is made in the console log file each time a system enters panic mode.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Change the generation of the network shared memory section name on OpenVMS

[ JO1699 ]

Category: System

Platform(s): Alpha OpenVMS

Description: The method for generating the shared memory section names on OpenVMS has been changed to avoid problems when OpenVMS allows multiple processes to have the same process name. The prior method used the conflict in process names to detect that another instance of Caché was running. A limitation which arises from this change is that name the device which Caché is installed on (eg. where the manager directory resides) cannot be longer than 16 bytes excluding the trailing “:” but including a leading “_”. This should not pose a problem for any sites but Caché will refuse to start up after displaying an error message if this is the case. Caché must be installed on a device with a name of 16 bytes or less (OpenVMS only).

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Address multiple installation issue

[ JO1700 ]

Category: System

Platform(s): Alpha OpenVMS

Description: An issue has been resolved on OpenVMS systems which install multiple copies of Caché where each copy of Caché starts up under a different UIC group and both installations have networking configured or attempt to use a performance monitoring facility such as ^PERFMON.

Previously, the second installation to start up would not detect that the first installation was running and there would be confusion about the name of the network shared memory section. The result would be that the second installation would not start up properly and would delete the network shared memory section of the first installation upon shutdown.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Rolling journal restores for clusters & new backup jrn restore dialogue

[ JO1717 ]

Category: System

Platform(s): ALL

Description: There is a new interface for performing cluster journal restores to perform some specific operations. To use it, run CLUMENU^JRNRESTO; more details on it appear below.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Address display for 4 digit years in showdata and test for starting journal file in findfiles

[ JO1719 ]

Category: System

Platform(s): ALL

Description: The display of the journal files which will be restored for a cluster journal restore has been changed to prevent lines from wrapping with 4 digit years. The code that finds the starting place during a cluster journal restore following a cluster backup restore has been corrected to work in the case where the journal files are not in the same place as when the backup was performed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	Yes

Add access mode so Caché can use the correct exit handler

[ JO1720 ]

Category: System

Platform(s): ALL

Description: The OpenVMS exit handler code has been changed to avoid logging system service exceptions in certain circumstances when a Caché process exits on systems running OpenVMS 7.3-1.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Add code to exit handler to shut down process when it's invoked

[ JO1721 ]

Category: System

Platform(s): Alpha OpenVMS

Description: The Caché exit handler on OpenVMS has been updated to simulate a RESJOB if the exit handler decides not to exit. This generally relates only to batch jobs which are terminated with delete/entry.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	Yes

checkpid() for OpenVMS now only checks whether pid exists (like UNIX and Windows)

[ JO1735 ]

Category: System

Platform(s): ALL

Description: The function $ZU(67,1,pid) releases a job table slot in use by a “dead” job, will not consider a job dead as long as the process id exists on the system. Caché has been updated to handle this situation on OpenVMS in the same way as on Windows and UNIX.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Resolve long global subscript issues in 2-KB databases

[ JO1742 ]

Category: System

Platform(s): ALL

Description: An issue has been addressed which could result in database degradation for 2-KB databases. In certain circumstances, a global reference which would otherwise generate a <SUBSCRIPT> error (because it was too long) would get applied to the database resulting in corrupted indexes.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Medium	Low	No	No

Fix $ZHOROLOG calculation on fast Windows machines

[ LRS678 ]

Category: System

Platform(s): ALL

Description: An issue that caused the $ZHorolog special variable to return negative values on a Windows machine with a 2.1GHz processor or faster has been addressed. As $ZHOROLOG is generally used in internal application timing, it is unlikely this will affect a production application.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Avoid accvio in $ZIO if the principal device can't be identified

[ LRS705 ]

Category: System

Platform(s): ALL

Description: A change has been made that minimizes the potential for an unexpected shutdown when LOGIN^%ZSTART is unable to identify the principal device.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

INTEGRIT does not find a <DATABASE> error

[ LFT1113 ]

Category: System

Platform(s): ALL

Description: This improves integrity checking by checking the consistency of data blocks that have no right link.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Avoid possible hang with JOB command

[ NGA109 ]

Category: System

Platform(s): All

Description: A possible hang caused by a job holding a global buffer while trying to job off another process has been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Let network daemon keep list of locks granted by it so it could handle some deadlock issues

[ SML331 ]

Category: System

Platform(s): ALL

Description: The network daemons (DCP, DDP and DTM) now keep the list of locks granted by the daemon for the remote client system. This improves overall lock management.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Let network daemon keep list of locks granted by it so it could handle some deadlock issues

[ SML331 ]

Category: System

Platform(s): ALL

Description: The network daemons (DCP, DDP and DTM) now keep the list of locks granted by the daemon for the remote client system. This improves overall lock management.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Fix for DDPDMN crash over DCP cluster connection when the cluster DCP connection is down

[ SML370 ]

Category: System

Platform(s): ALL

Description: This change addresses an issue for DCP clusters. When a DSM or MSM system locks a global in a clustered database on a slave node, and when the DCP connection to the master is down, then the DDP daemon on the slave node could get an access violation. This no longer happens.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Fix possible stranded lock in DELOCK_NEED state.

[ SML376 ]

Category: System

Platform(s): ALL

Description: This prevents a possible stranded lock in DELOCK_NEED state on a DCP client after a DCP connection is re-established.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Expand DDP Lock Table Size for 64-Bit Platforms

[ SML393 ]

Category: System

Platform(s): OpenVMS, Tru64

Description: On 64-bit platforms, the table of pending lock requests can become too small to contain all the lock requests from nodes in the cluster. This caused interference among nodes trying to manipulate the table and resulted in some requests for locks being ignored. This change addresses the situation.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Backup restore information is now saved in a global for future retrieval by journal restore

[ HYY597 ]

Category: System.Backup/Restore

Platform(s): ALL

Description: The following information about backup restore is now saved in the global node ^SYS("RESTORE","BACKUP",<time>,...): the backup device to restore from; the backup time in $Horolog format; the database target(s); the database mount state; and the offset.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Fix minor performance bug in Unicode cluster routine purge

[ JO1686 ]

Category: System.Cluster Specific

Platform(s): ALL

Description: Previously, having a cluster-mounted database with certain kinds of names would cause other cluster members remove some routines from their buffer pool unnecessarily. This has been addressed, thereby improving performance.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Treat a cluster member as a remote system in dispatch_method_or_property

[ JO1693 ]

Category: System.Cluster Specific

Platform(s): All

Description: In a cluster, if one cluster member recompiles a class then the other cluster members need to invalidate the class if it is loaded so that they can reload the (new) class descriptor.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Medium	Low	Yes	No

Possible hang if there are no buffers available

[ JO1696 ]

Category: System.Cluster Specific

Platform(s): All

Description: Previously, there was a problem which, under particular and unusual circumstances, could cause a system hang on a Caché cluster. This occurred when the write daemon entered panic mode because there were zero free buffers. This has been resolved.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Increase the timeout in JRNMARK for cluster operations from 10->30 sec

[ JO1724 ]

Category: System.Cluster Specific

Platform(s): ALL

Description: The timeout for switching journal files and writing markers during a cluster backup has been increased to avoid <READ> errors from the JRNMARK routine.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Removed inconsistent behavior reading the NULL device

[ SAP026 ]

Category: System.I/O Device

Platform(s): OpenVMS

Description: Previously, on Caché on OpenVMS, reading the NULL device ("NL:") would generate a <COMMAND> error. It now returns a string with zero length, making it consistent with Caché on UNIX and Windows.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

Newly Created Journal File Names Are Now Stored in Canonical Form.

[ HYY592 ]

Category: System.Journaling

Platform(s): ALL

Description: Previously, there were <ENDOFFILE> errors during block-mode shadowing; these have been addressed.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

Making journal markers on cluster systems act like cluster journal sequence barriers

[ HYY600 ]

Category: System.Journaling

Platform(s): ALL

Description: To set a journal marker effective cluster wide, use the following routine

$$CLUSET^JRNMARK(id,text,swset)

where

• id: the marker ID (e.g., -1 for backup)
• text: the marker text (e.g., timestamp for backup)
• swset: 1 if switch 10 has been set cluster wide (and locally) by the caller and the caller will be responsible for clearing it afterwards, otherwise 0 and the routine will take care of setting and clearing the switch properly. Note that switch 10 must be set locally and cluster wide to ensure the property of the journal marker.

If successful, the routine returns the location of the marker, i.e., the offset of the marker in the journal file and the journal file name, delimited by comma (','). Otherwise, it returns an error code (<=0) and error message, also delimited by comma.

To set a journal marker on a non-clustered system, use

$$ADD^JRNMARK(id,text)

with similar parameters and return values.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Improve user interface to cluster dejournal

[ JFP073 ]

Category: Utilities

Platform(s): ALL

Description: There have been enhancements to the cluster dejournaling user interface.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

GBLOCKCOPY translates collation into an subscript-level-mapped destination (such as ROUTINE global)

[ PWC746 ]

Category: Utilities

Platform(s): ALL

Description: An issue was corrected that caused GBLOCKCOPY to corrupt a global. For the issue to occur,

1. the GBLOCKCOPY must be translating the global from one collation to another, and
2. the destination of the GBLOCKCOPY must be a namespace where the global uses subscript-level mapping.

In particular, this addresses an issue with copying the ^ROUTINE global from an ISM system to a Caché namespace.

It eliminates a possibility for data corruption.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	Yes	No

WRC Caché “Buttons” Now Available

[ RFA009 ]

Category: Utilities

Platform(s): ALL

Description: The Caché Buttons are a set of tools that make it easier for users to collect technical information to include with questions sent to InterSystems Worldwide Response Center. They are available at http://www.intersystems.com/support/utilities/buttons.html.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	No

interface improvements to Journal Restore utility

[ TCS004 ]

Category: Utilities

Platform(s): ALL

Description: The journal restore utility, mainly for cluster journal restores, has been enhanced to recognize “^” at a prompt as meaning back up to the prior question. Some prompts also accept ? to display additional help. When ^ or ? are available they are displayed after the default response in []'s as in [^] or [^?]. The YES/NO questions support ^ although they do not display [^].

The correct starting sequence number for a dejournal is the highest number among the starting sequence number for each journal file (not the default).

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Prompt on next line for JRNSTART and JRNSWTCH

[ TCS005 ]

Category: Utilities

Platform(s): ALL

Description: The prompts in Journal Start (JRNSTART) and Journal Switch (JRNSWTCH) now accept user input on a separate line from their prompt. This improves readability.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Enhancements to %GD, %GDOLD, and %GSET

[ TCS007 ]

Category: Utilities

Platform(s): ALL

Description: These routines now include pagination and some on-line help describing how to select/de-select globals.

Likelihood of happening	Risk this change introduces new problems	Distributed in ad hoc release and installed in production	This change is an enhancement
Low	Low	No	Yes

Using the New Journal Restore Interface

This maintenance kit includes a new interface for performing cluster journal restores to perform some specific operations. This interface is accessed by running CLUMENU^JRNRESTO in the %SYS namespace of the Caché Terminal. This invokes a menu that includes the following options:

1. Perform a general-purpose journal restore (clustered or non-clustered)
2. Generate common journal file from specific journal files
3. Perform a cluster journal restore after backup restore
4. Perform a rolling cluster journal restore by dates
5. Perform a rolling cluster journal restore by backups
6. Generate a rolling common journal file by dates
7. Generate a rolling common journal file by backups
8. Enable saving journal information from backups

Option 1: Perform a General-Purpose Journal Restore (Clustered or Non-Clustered)

This allows you to run the “classic” cluster journal restore. This is the same as running ^JRNRESTO. The user specifies the information required to find the journal files for all the cluster members, the starting and ending journal file for each cluster member, the starting and ending sequence number for the restore, and all the databases/globals to be processed, as well as any redirection information if some/all databases are not going to be restored to the same location as is recorded in the journal. This interface assumes that the system that is running ^JRNRESTO as one of the “sources” of data for the restore.

Option 2: Generate Common Journal File from Specific Journal Files

Produce a single common format output file from the cluster journal files. JCONVERT takes a journal file from a single system and writes it out in a common format which lets it be read by %JREAD. This is useful for restoring journal files across versions of Caché where the journal files are not compatible (for example, as part of an “almost rolling” upgrade) or as part of failing back to an earlier release. It can also be used to write out the journal file in a way that it can be loaded into another platform such as DSM. The user interface for this is the same as option 1 above with some additional questions related to what to include in the output file, the output file format, etc.

Option 3: Perform a Cluster Journal Restore after Backup Restore

Restore the journal files after a Caché backup restore. This is the same as the restore performed by DBREST after a cluster backup restore but there was no way to run it independently of restoring a backup (for example, in case something goes wrong and you need to restart the journal restore). One difference between this option and restoring using ^DBREST is that this option does not start with the list of databases contained in the backup; the database list must be entered by the user. It will offer to include all currently cluster-mounted databases in the restore but if this is really being run after restoring a backup then the databases restored by the backup are going to be privately mounted unless the mount state was changed by the user (for example, the restore mounts them privately and leaves them privately mounted when its done).

Options 4 - 8: Rolling Journal Restore Actions

Options 4 through 8 relate to a new type of operation termed a “rolling journal restore.” This is an operation that is performed on a regular basis such as daily, weekly, etc... to replay the journal of the main system against another system to keep it up to date. This is similar to the functionality provided by the Caché shadowing technology. Rolling operations can either restore the journal directly to the system or they can produce a common format journal file for replaying with %JREAD.  None of these operations assume that the current machine is supplying data for the operation (although it can). This means that there are no questions “about this system” and “about the other systems”; it simply asks you to describe the cluster, where to find the files, etc.

Two types of rolling operations are supported:

• Date-based rolling operations where the data to be moved is selected based on the date it was created. One day is the smallest interval that can be selected.
• Backup-based rolling operations where the data to be moved is the data created between two backups.
  
  

The basic process of rolling operations is:

1. If you want to work from backup files, enable saving journal information from those files (Option 8)
   
2. Generate journal file (Option 6 or 7)
   
3. Restore the file (Option 4 or 5)
   

Part of the goal of the user interface for this functionality is to simplify the dialogue to prevent any mistakes since the operation is going to be performed on an ongoing (for example, daily) basis. After going through the operation the first time — as long as the configuration of the cluster does not change (for example, where the journal files live, the number of cluster members, etc) — pressing return to all the questions should perform the “next” operation. To allow this simplified interface to locate the necessary files this feature requires that each cluster member is assigned a unique journal file prefix and the prefix must not be changed “within” an operation. If the prefix must be changed then it needs to be changed at a point such that the change is at the "start" of an operation and not an end or the middle. This means that the system should be shut down during the operation prior to the change (for example, prior to making the backup or before the end of the day) and then started up with the new prefix name to be included in the next operation (after the backup or so the first journal file created is the first file of the day). Additionally, the answers to the questions required to perform the next operation are stored in the ^SYS global in the CACHESYS database. Thus, they are only available to the system which ran the operation last time so if the operation is run on a different cluster member, all of the questions will have to be answered again (which is the first time for that cluster member).

A backup-based rolling operation is the somewhat simpler of the two. Each backup provides the end point of one operation and the starting point of the next. It doesn't matter what kind of backup is performed. The cluster backup code puts a marker into the journal file which separates the data included in the backup from the data which follows the backup. This is where a journal restore following backup restore starts. The rolling restore by backup runs from one set of markers to the next. To support this, you need to keep the backup file and the journal files that represent the end point on the system until the next operation is run. At that point the files can be removed up to the end point of that operation. In order to use backups as the basis for rolling operations, you must enable the collection of some information used to locate the journal files that contain the backup markers. Option (8) enables and disables the collection of this information. The information is stored in a in ^|"^^CACHESYS"|SYS("JRNMARK") so the rolling operation must be run on the same system which performed the backups (note that the storage location is subject to change).  When you disable collecting this information, you are given the opportunity to delete the information collected so far. If you delete it, you will not be able to do another backup-based operation until you enable it and perform a new backup.

A date-based operation is slightly more complex than backup-based operation. A date-based operation works on a “day's” worth of journal data. The journal files have a name of the form yyyymmdd.nnn where <nnn> is a number that starts at 001 and goes up as the journal files roll over; a rollover can be the result of a manual journal switch, a backup, or a reaching a user-specified maximum size. A date-based operation asks for the starting date and then the number of days to process. The number of days does not have to be the same every time so (for instance) on Monday you can include all of the weekend's work in one operation. The default number of days for an operation is the number of days since the last operation was performed (for example, you can specify that the operation bring all of the available information over). The ending point of a date-based operation is in the first journal file of the first day not included in the operation. So, if you are processing two days starting on 5/13/2003, then this includes the files named: <prefix>20030513.*, <prefix>20030514.*, and <prefix>20030515.001. This .001 file is also the starting point of the next operation. It is fine if a cluster member is not running and does not have a “.001” file that represents the start or end point (assuming that the file doesn't really exist somewhere). The system warns you that the file is missing and asks if that is okay.

There are two special situations to note:

• The first is when you perform a rolling operations for the first time. In this case, you are not starting with the end of a prior operation, so you have to modify some assumptions the system is going to make.
  
  
  • For a backup-based operation, when you're asked whether this operation starts with a backup, you say “no.” The system then starts with the earliest journal files it can find. These should have been created by a system startup.
    
    
  • For a date-based operation, the system doesn't ask if you're starting for the first time or continuing from a prior operation. To start a date-based operation, you enter the starting date but when it displays the information for the restore and asks you if the information is correct you want to say no. It asks you if you want to edit the starting and ending journal file offsets and you say yes. Now you set the starting journal file offset to 0 and leave the ending journal file offset alone.
    
  
  
• The other special case is when something happens and you want to do a rolling operation that ends at the end of the current data rather than at a prior point (normally rolling operations end sometime earlier than “right now”). This might be because the cluster has failed and you're restoring its journal files to a stand by system or for some other reason.
  
  
  • To do this with a backup-based operation when the system asks if you want have a backup to end the operation with you say no. It will end with the most current data it can find. The next time you do a backup-based operation, you want to start with the same backup file you started with here to pick up the same information again plus the information that gets added before the next backup.
    
    
  • To do this with a date-based operation is similar to starting from a point other than the last date-based operation. When the summary of the files to be restored is displayed and you are asked if the list is correct say no and then say yes to changing the starting and ending sequence numbers. Change the ending sequence to -1 which means “to the end of the data.” Like with the backup, if you want to perform the rolling operation later when you have the “real end point,” restart from the same starting point to capture the information added before the next end point. You need to do this even if the next end point is the next day (for example, there are no more journal files from the last day being captured) because a date-based restore does not end at the start of the journal files from the ending day, it ends inside them. Thus if you simply start with the next day you will miss some of the information at the start of those journal files.

© 2003, InterSystems Corporation. All rights reserved.

Change summary for earlier Caché 4.1.x versions

Copyright © 2001-2003, InterSystems Corporation.
All Rights Reserved.

Please contact InterSystems Worldwide Response Center at support@intersystems.com if you would like to know more about any of these items.