There is no section for 5.0.6.

This section provides a listing of changes between Caché 5.0.10 and Caché 5.0.11.

This document contains several sections:

• Important Caché News, Alerts and Advisories
• A change report description
• A list of changes considered critical for this release
• A summary of changes to the documentation for this release

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 releases of Caché.

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 versions of Caché at the InterSystems Website.

From the home page choose the "Caché" tab, and on the "Downloads" menu, select "Documentation and Help Updates" or follow this link.

To help you assess the impact of these changes on your applications, each change description contains a more detailed explanation of the modification.

All changes include a table giving pertinent information on the issue's likelihood, impact of the change, and whether this has already been used successfully in production by other customers. In order to make the information easy to assimilate visually, the tabular information has been simplified to a keyword or two and a value. The full explanation of the keyword meanings are:

• Likelihood - The probability that a user on the affected platform will encounter this issue.

• Risks - An assessment of how likely this change is to introduce additional issues into the application environment.

• Ad Hoc - This item indicates whether this change has previously been deployed in an ad hoc release and successfully used by customers in production.

• Enhancement - This notes whether this change provides new features or capabilities.

A new CSP parameter, Hyperevent Implementation, has been added.

New CSP Applications will be created with the Hyperevent Implementation parameter equal to "Select on server". On upgrade, existing CSP Applications whose Hyperevent Implementation parameter is missing will have it created with the value "Use Java applet".

This change introduces the optional use of the XMLHttpRequest Javascript object to implement #server. The actual method used to implement #server is determined by a new Configuration Manager parameter for CSP applications, called "Hyperevent Implementation". "Hyperevent Implementation" has four possible values that determine how #server is implemented:

• Use Java applet for #server
• Use XMLHttpRequest Javascript object for #server
• Select implementation using browser Javascript
• Select implemetation using HTTP_USER_AGENT on server

where:

• "Select on server" means CSP pages that use #server will include either an applet tag OR Javascript to use the XMLHttpRequest object; the selection will depend on the server HTTP_USER_AGENT CGI variable. This option, "Select on server", is the default.
  
  
• "Use Java applet" states CSP pages using #server will always supply an applet tag identifying the CSP Java broker applet; #server will always use this applet.
  
  
• "Use XMLHttpRequest object" indicates CSP pages that use #server will always include Javascript that uses the XMLHttpRequest object to implement #server.
  
  
• "Select in browser" means CSP pages that use #server will include BOTH an applet tag and Javascript to use XMLHttpRequest. The method used will be chosen based on the availability of the XMLHttpRequest object to the Javascript code in the browser.

In &html 3.2 compatibility mode, CSP will ignore < or > within <% ... %>. This is meant to handle constructs like

&html< <% w "first->last" %> >

which are encountered in Cache 3.2 WebLink applications.

This change improves the validation of the session token's fields after a failover (or web server/NSD restart) situation.

Previously, a request could be directed to an incorrect (or unexpected) Caché server after a web server/NSD restart. This issue could also result in requests in Virtual Host configurations being directed to incorrect (or unexpected) Caché servers. The term, 'unexpected' Caché servers, means a Caché server configured as an alternative to the main (or default) server).

Editing the Gateway's server and/or application configuration on web server/NSD startup would make problems of this nature more likely to occur.

This change corrects an issue in the transmission of form data in which CSP* variables (e.g. CSPToken) were placed at the end of a form posting more than 8K of data. The problem manifested itself as such forms failing validation checks on submission ('Illegal CSP Request' errors).

This change ensures that Gateway error messages sent in response to SOAP-based requests are formatted as SOAP fault messages (as opposed to HTML).

For example, if the Gateway is unable to connect to the Caché server for the purpose of servicing a SOAP request, the following SOAP fault will be returned:

HTTP/1.1 200 OK
Content-type: text/xml
Connection: close
Expires: Thu, 29 Oct 1998 17:04:19 GMT
Cache-Control: no-cache
Pragma: no-cache

<?xml version='1.0' encoding='UTF-8' standalone='no' ?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/'xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xmlns:s='http://www.w3.org/2001/XMLSchema'
   SOAP-ENV:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>CSP Gateway Error (version:5.1.0.423.0 build:663.775)</faultstring>
<detail>
<error xmlns='http://tempuri.org' >
<special>
Server Availability Error
</special>
<text>
Server is currently unavailable
</text>
</error>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

It should be noted that this facility can only work if the Gateway can identify the incoming HTTP request as a SOAP-based request for information. This may not be possible if a request for a SOAP-based response is made via the HTTP GET method. It is, however, recommended that requests for SOAP-based services be made through HTTP POST (or related) methods. If the HTTP POST method is used, the Gateway can identify SOAP-based requests by the associated content type.

A message is displayed when a HyperEvent method's argument length is > 32000 characters. With this change, the argument will not be displayed since it detracts from the clarity of the error message.

This changes corrects a situation where the packet-driver for Windows 2000/XP and 2003 Server did not properly report all the network cards it had bound to.

When $ORDER didn't find an answer across ECP, it sometimes left the global vector naked reference invalid. This caused a subsequent $ZREFERENCE to fail with wide character error.

This change prevents that from happening.

Prior to this change, the Caché packet driver would cause a fatal Windows error when invoked on systems containing more the two processors. This no longer happens.

This change corrects a problem where attempting to define an index involving the %ID token would fail.

The maximum routine size has been changed from 40k to 32k. This will result in smaller OBJ routines and, for large source files, more routines generated. This adjustment was necessary in order to load files with methods with more than 32k of source code.

This corrects an oversight where the status code from the compile was only being returned if the compiler flag to display errors was set. Now the status code is always returned.

If you write a generator method the compiler was not making sure that any variables you create in this generator do not end up in the partition. Now an exclusive new is done before running generators for a class to prevent this possibility.

If you open an existing file stream stored in a directory other than the current default directory (the one with the CACHE.DAT file in it for this namespace) then the MoveToEnd method would fail to work correctly. This change corrects the problem.

The default global name generator used by the default storage class has been improved.

• First, the package definition 'package prefix' is retrieved. If it is empty then the package name is used for the package prefix. A default global name is generated by taking the package prefix, class name and adding a suffix character.

  If the resulting string is less than the maximum global name length then it is used.
  
  

• Otherwise, the class name is hashed into a string that is one half the maximum global name length. The package prefix is hashed into a string that is one character shorter (to allow for a '.') than the remaining maximum global name length.

This change corrects an issue in the class compiler. In constructing the initial expression for stream properties, it did not properly handle values that contained quote characters. This has been corrected.

This change corrects a problem in the FindAt method in %Stream.Object. The method would not calculate the correct position when it had read in two or more 20,000-byte chunks of data.

If the global ^%SYS("TempDir") is defined, this is now used as the temporary location for stream data.

If this is not defined, then Caché will use "" as the directory. This puts the stream data in the current directory which is normally the location of the CACHE.DAT file.

This change introduces a new class %GTWConnection. Its %OnClose method disconnects an active connection if the gateway is terminated.

The Caché ODBC driver has been externally thread-safe for quite some time now. For example, if two threads were simultaneously operating on the same statement object, Caché ODBC driver guarantees there will be no conflicts.

This change fixes the instances internally where there were thread-related issues that could result in "message sequence errors".

This change improves error handling in cases where ODBC terminates abnormally and error recovery actions by the application override the default actions taken by the operating system.

A problem has been fixed in ODBC/JDBC. The first time a query is Prepared, if

• a Cached Query exists for the statement, and
  
  
• the user is privileged for the statement,

an <UNKNOWN ERR> would get passed back to the client under some conditions.

This changes corrects a situation where a decimal literal in the first column of a SELECT statement, for example,

SELECT 0.1, F1  FROM TESTCASE1234

would prevent parameter replacements from being made.

This change corrects an error that caused compile-time <UNDEFINED> errors in SELECT statements with OUTER JOINs when certain CacheSqlStorage "general mapping" features were used.

This change optimizes streamless (sub)expressions (i.e. expressions without any fields) in SELECTs and a few other places by evaluating them only once at the beginning of the query.

This change corrects an error in optimization where certain query conditions were "pushed down" and applied within the evaluation of a view that has a GROUP BY clause. This occurred in cases where the condition included a unary operator or a {d ...} date expression.

This change remedies a situation which caused incorrect processing or a likely run-time <UNDEFINED> error when

• there were a large (more than 250) number of expressions, and
  
  
• these expressions had to be evaluated at the beginning of the query.

An example of this is an IN condition on a collated field with more than 250 constants.

Caché SQL now supports a datepart of "ms" or "milliseconds" for the DATEADD and DATEDIFF functions.

We also now support SQL_TSI_FRAC_SECOND for the ODBC Scalar functions

• {fn TIMESTAMPADD()},
  
  
• {fn TIMESTAMPDIFF()}.

This corrects an instance where a query can return incorrect results when

• there is a WHERE clause condition selecting attribute values less than a negative value, for example, f < -5,
  
  
• there is an index on that column, and
  
  
• some of the rows are null in that column.

An error has been corrected where a field value that used the SPACE collation compared against NULL was not returning the correct results. For example, a query like:

SELECT count(*) FROM SQLUser.MyTable WHERE MyField IS NULL

return the incorrect results if MyField's collation was SPACE.

This change adds a new feature. Previously, you could never use <viewcolumn>->x syntax. Now, if view column maps to a base table column that supports arrow syntax, the view column will support it as well. Note that arrow syntax referring to a child table from a parent table is still not supported for views because there is no way to specify whether the child table pseudo column is 'selected' by the view. In addition, this new feature will not work for views defined by SELECT DISTINCT, or aggregated views, or UNION views.

Another new feature is that special columns %ID, %CLASSNAME, %TABLENAME now work with arrow syntax. Thus ref->%CLASSNAME will return the name of the referenced class.

Addressed a problem where $SORTEND may generate a <STRINGSTACK> error when there are many SETs (hundreds of thousands of, or even millions) to sort.

Under some circumstances $SORTEND would generate an access violation or <SYSTEM> error.

A problem has been resolved which could cause access violations on OpenVMS from certain block split operations in 8KB databases when more than 2GB of global buffers have been allocated.

A small problem in the internal mailbox code on VMS systems has been corrected. This could have caused corruption of data being returned on Caché's internal string stack in certain rare circumstances, particularly during reads from TCP/IP devices.

Under some circumstances, when a sufficient number of KILLs have been done to reduce the number of global directory blocks needed by 1, the consolidation of directory blocks can cause a <DATABASE> error during dismount.

ECP is more likely to provoke this rare problem but it can occur without any ECP.

This change rectifies that possibility.

This change addresses a situation with journal restore when using a journal filter where SETs may not get applied to the destination databases.

the wait time in Caché backup, and other places where the system waits for quiescence, has been extended. If, after the timeout period has expired, the system is quiet except for the write daemon, the timeout is extended for up to 2 minutes to wait for the write daemon to finish its current pass.

Previously on systems where the write daemon routinely took more than the allowed timeout, a backup might never succeed.

This change corrects a situation where Wndows startup would take a long time whenever

• the Caché configuration was marked as automatically starting service in the system, and
  
  
• a recent (i.e. after TTS031) packet-driver had been installed.

^%GCMP didn't work across ECP. It was looking for a legacy net connection id

NET(1,"ACTIVE","CPNU",<connection name>)

which wasn't set.

This change corrects a problem where globals in the ISM pre-6.2 collation that had a particular data pattern (final subscript of any global node ending with $C(1)) could cause problems. The particular symptom that was reported is a failure to convert the node properly when using GBLOCKCOPY.

The content of the Caché documentation evolves from release to release in response to editorial improvements, updates to existing material, and addition of new information. The following is a summary of the most noteworthy changes to the Caché documentation since the previous release:

• High Availability Guide
  • Reorganized the material and added a chapter called "Cluster Journaling" which covers cluster restore, recovery, and shadowing
  • Reorganized ECP information by removing a large amount of material from the GHA ECP chapter and moving it to the Distributed Data Management book, including a new appendix of guarantees and limitations
  
  
• Supported Platforms and Windows Installation
  • Added SP2 for XP
  
  
• Cache ObjectScript Reference
  • Added time formats 5, 6, 7, & 8 to $ZDATETIME, $ZDATETIMEH
  • Rewrote $ZTIMESTAMP special variable for local time variants (Daylight Savings, etc.) and Time/Date interactions.
  • Added class info section to $JOB special variable
  
  
• Cache SQL Reference
  • Rewrote and expanded CREATE TRIGGER, DROP TRIGGER, Triggered Action pages
  • Rewrote and expanded UNION page
  • Rewrote Identifiers page, with updated character & length restrictions
  • Added naming conventions/name conversions sections to CREATE TABLE (table name & field name), CREATE VIEW, CREATE INDEX, CREATE TRIGGER
  • In SELECT specified naming conventions for AS clause values
  • Added features to GRANT command
  • Added note to SELECT on use of asterisk option
  • Expanded the material on the UPDATE command, the Symbols table, and the SQLCODE error code list
  • Documented schema names, package names, and Configuration Manager schema default in CREATE TABLE and CREATE VIEW.
  • Completely rewrote Table page, renamed as Table Reference with new syntax and description.
  • Improved the clarity of the examples illustrating the difference between the HAVING and WHERE clauses.
  
  
• Cache Class Reference
  • Corrected EXTENTQUERYSIZE and EXTENTSIZE
  
  
• Organizational Changes
  • Re-ordered the sequence of book collections on the documentation home page and also re-ordered the sequence of books with each group. Prior to this, they had been sorted alphabetically; now they appear with the more important topics first.
  • Changed the title of the short articles section from "Caché Knowledge Base" to "Technical Articles" to make it more explanatory.
  • Reworded the page headers to say "InterSystems Online Documentation" instead of "Caché Online Documentation".
  • Added a new home page item called "Documentation List" which provides a list of the titles for all the books and all technical articles sorted alphabetically.

These are in addition to minor enhancements in examples, as well as corrections and improvements to grammar and spelling.

This section provides a listing of changes between Caché 5.0.9 and Caché 5.0.10.

This document contains several sections:

• Important Caché News, Alerts and Advisories
• A change report description
• A list of changes considered critical for this release
• A summary of changes to the documentation for this release

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 releases of Caché.

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 versions of Caché at the InterSystems Website.

From the home page choose the "Caché" tab, and on the "Downloads" menu, select "Documentation and Help Updates".

To help you assess the impact of these changes on your applications, each change description contains a more detailed explanation of the modification.

All changes include a table giving pertinent information on the issue's likelihood, impact of the change, and whether this has already been used successfully in production by other customers. In order to make the information easy to assimilate visually, the tabular information has been simplified to a keyword or two and a value. The full explanation of the keyword meanings are:

• Likelihood - The probability that a user on the affected platform will encounter this issue.

• Risks - An assessment of how likely this change is to introduce additional issues into the application environment.

• Ad Hoc - This item indicates whether this change has previously been deployed in an ad hoc release and successfully used by customers in production.

• Enhancement - This notes whether this change provides new features or capabilities.

ECP can survive server restarts and crashes without any client application involvement. During startup, if there were any ECP client open transactions, the open transaction journal offset got stored in the ^%SYS("ECPDELAYTR") global in case the system crashed again. The global was never killed after successful ECP recovery.

So after many hours or days, if the system is restarted (for any reason) it scanned from that remembered journal offset, which could be many journal records. This would cause the next system restart to take a long time, and some of the journal files may possibly have been deleted, which will abort the rollback because of missing journal file.

With this change, the information will be maintained in the WIJ file.

An XML file such as this example

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE note [
 <!ELEMENT note (to, from, heading, body)>
 <!ELEMENT to (#PCDATA)>
 <!ELEMENT from (#PCDATA)>
 <!ELEMENT heading (#PCDATA)>
 <!ELEMENT body (#PCDATA)>
]>
<note>
 <to>Tova</to>
 <from>Bill</from>
 <heading>Reminder</heading>
 <body>Don't forget the party this weekend!</body>
</note>

containing a DOCTYPE but no SYSTEM or PUBLICID caused

ERROR #6301: SAX XMLParser Error: Unknown Error.

This change accommodates the missing information.

An error has been fixed which prevented the creation of a view against a table linked via the SQL Gateway. With this change, SQL can now create such a VIEW. Previously, this operation would report that the table had no Master Map definition.

A deficiency has been fixed in which the insert/update of a serial field's values through SQL might not be stored properly in the database. The error occurred when the serial field was stored in a global node by itself (without any other fields stored in the same node).

In previous versions of Caché, fields using a Space collation in a CacheSQLStorage subscript expression of the form " "_{FieldName} were treated as expressions rather than collated field values. This made the SQL Query Optimizer less likely to use the index.

This is now corrected.

A problem was fixed where an OUTER JOIN could sometimes behave like an INNER JOIN. This occurred when the join column of the left side of the left join is an IDKEY, while the join column from the right side is an indexed column that has a collation different from EXACT.

This change corrects a problem in SQL Manager's export and import class methods, %SQL.Export.Mgr.DeleteExportRoutine and SQL.Import.Mgr.DeleteImportRoutine, that prevented generated routines from being later deleted.

This change resolves a problem that could cause access violations in OpenVMS during certain block split operations in 8KB databases. The problem occurred when more than 2GB of global buffers had been allocated.

This fixes an error in $BITLOGIC where empty strings would not get negated correctly if there were a length present and only one argument, i.e. $BITLOGIC(~x,len).

This fixes a problem with $BITLOGIC(X) for certain values of X. A spurious error would be reported when the following conditions were met:

• X was stored as a bitmap whose last byte was 1
  
  
• (($BITCOUNT(X)-1)/8+5)=$LENGTH(X)

This change corrects a condition that resulted in the generation of an invalid bit string from $BITLOGIC(u ^ v) (i.e. XOR operation). The error occurred on Unicode databases when one of the operands was compressed and the other was not.

This change corrects an error where, under circumstances requiring conversion from bitlist to bitmap, an incorrect result could occur using the & (AND) $BITLOGIC operator. This only occurred on Unicode installations.

When the DCP daemon is shut down, it will roll back all opened transactions by remote client jobs. However, it intermittently failed to record the restored globals into journal file. This caused the globals set be back to the pre-rollback value when the server is restarted.

This change corrects that occurrence.

This change addresses a problem with journal restore involving a CACHETEMP database of specified max size (i.e., max explicitly set to a value greater than zero). Under some circumstances, users could experience a <SUBSCRIPT> or <UNDEFINED> error during journal restore.

This change corrects the following problems with cluster failover (after a node crash) or cluster recovery at startup (after cluster crash):

• <NOTOPEN>main+1^JRNCLFOR, an error that would result in cluster hanging (in the case of cluster failover) or startup aborting (in the case of cluster recovery);
  
  
• incorrect data, as the result of journal records being restored in the wrong order.

A problem which could cause a pause in the write daemon cycle on a Tru64 cluster system has been resolved. Since global updates are locked out during this phase of the write daemon cycle, this appeared to an application as a global module pause.

A problem with clusters where the write daemon would get stuck in an infinite loop if it encountered a problem completing its portion of cluster startup has been resolved.

This was found during internal testing, it has never been seen in the field.

A problem has been fixed that could lead to file handle and memory leaks with JOB servers, mostly on Windows platforms.

Journal start used to abort when the name for the new journal file was taken by an existing file other than a valid journal file. The new behavior of is to skip the non-journal file and use the next available name for the new journal file.

A warning message is also displayed in cconsole.log.

In previous versions, some settings affecting globals may not have taken immediate effect in existing processes. This was due to the fact that global vectors were cached locally in the process.

The system setting that dictates whether all or selected globals are journaled fell into this category.

This change enables the change of the system setting of journaling to take immediate effect, even in existing processes.

This change corrects a problem where incomplete transactions involving databases redirected elsewhere in the journal restore were not rolled back properly.

The problem is present in all Caché releases.

There was a problem introduced by a change to version 5.0.5.

If a clustered system crashes shortly after journaling switches/rolls-over to a new file, open transactions may not be properly rolled back during the subsequent cluster recovery or failover.

This change corrects that circumstance.

This changes corrects a problem in 5.0 where the descendants of a KILL of a global node are journaled if the global is marked for journaling, even though the KILL is NOT part of a transaction. It would be the correct behavior if the KILL is part of a transaction, but in this case it is not.

Cstat has been enhanced with the “-j16” option to display jobs, if any, queued for synchronous journal I/O. For example,

Sync I/O queue (job:iowake:nextjob): 16
   15:0:   13,   16:0:   15

The job # at the end of the line "Sync I/O queue" is the head of the queue. It is followed by a list of jobs on the queue (not necessarily in their order on the queue) that are NOT the last entry on the queue. The nextjob field is the job # following this entry. In the example above, the actual queue is:

head = job #16 -> job #15 -> job #13 = tail

Job #13 is not shown in cstat because it is the last entry on the queue.

This addresses a potential problem that might cause jobs to hang while waiting for journal I/O to complete.

This correction prevents the journal daemon from hanging in an infinite loop in some situations involving a job (or jobs) waiting in a synchronous journal operation (e.g., synchronous TCOMMIT).

Under some circumstances an attempt to manually switch the journal file via ^JRNSWTCH or the GUI equivalent could hang indefinitely. This has been corrected.

In previous versions, the journal info in the wij was not updated when there was no database update. This could become a problem in some situations where the journal grew indefinitely (e.g., with TS/TC or NN records) without any database update, resulting in stale journal info in the wij. If Caché aborted while in this state, users would see a time-consuming journal restore and transaction rollback at startup.

With this change, the journal info is updated in the wij as long as journal has grown, even if there