There is no section for 5.0.6.

This document provides a listing of changes between Caché 5.0.19 and Caché 5.0.20.

For detailed information on getting started, see the Caché 5.0 Release Notes (located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 5.0 maintenance kits, see the file prenotes.htm, located in the same directory as this file.

This document contains several sections:

• Important Caché News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• A list of changes considered critical 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 - 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.

If the default direction of 1 was specified on $BITFIND, a <FUNCTION> error resulted. This has been corrected.

The changes corrects several coding errors in CacheHung that interfered with the proper checking on MUltiNet.

An internal function was used to pause for a specified number of seconds. On OpenVMS, it released retained blocks before waiting. This change modified it to not release the retained blocks on all platforms; and release the retained block where necessary.

This change supports ethernet device names that have two trailing digits, so Caché could handle the ethernet cards in the machine with more than 10 ethernet cards.

In prior releases, ECP recovery didn't track partially processed request buffers accurately, and on server failure it could resend a process lock request, or not send a synchronous request when it should have. The side effects are: a lock could hang/loop the ECP client daemon after recovery; or that some client jobs may hang forever waiting for answer.

This change corrects that situation

A problem has been fixed where

• multiple SQL insert/update actions occur within a single method or procedure
  
  
• and the method or procedure is enclosed within a transaction in AUTO_COMMIT mode.

In this situation, the method or procedure could commit a transaction that was started by the application code and not the filer. This caused mismanagement of the transaction level.

It is now fixed.

This change corrects an error where an UPDATE statement with an implicit JOIN in the WHERE clause using arrow syntax could result in an <UNDEFINED> error running the query, or no rows being updated when there should have been. This problem was introduced in version 5.0.18.

Under some conditions a QUIT command from the terminal that should clean up after a <FRAMESTACK> error would instead halt the process. A <STORE> error could also halt the process.

This change corrects that situation.

If a routine issues a callout ($ZF), and the called routine in turn issues a callin to another routine that ends up editing the routine making the original callout while it is still active, a memory access violation may occur when the callout returns to the modified routine. This fix will detect that condition and throw an <EDITED> error instead.

The write daemon (WD) stores the previous check point journal index in the WIJ header.

Before shutdown signals a clean exit, it checks if the WIJ header journal index is the same as the journal index. If they are not, the shutdown script modifies a dummy global and then forces a write daemon pass, expecting the write daemon to store the latest journal index in the WIJ header when it is finished.

If the dummy global is journaled, the modification increments the journal index, and then the write daemon stores the previous journal index in the WIJ. This causes the two indices to be out of synch again.

This change modifies shutdown to disable journaling in current/shutdown process during this activity.

On OpenVMS systems, IP validation failed when the IP address had no associated DNS entry. This has been corrected.

This changes disables manual ECP session registration to prevent a circumstance that resulted in the registration being performed twice.

This change addresses an issue where a change to the journal state of an subscript-level mapped global might not take effect immediately in existing processes.

This change addresses an issue affecting Linux on Itanium and AMD64 systems that might cause concurrency problems in multiprocessor machines.

This change adds a new routine, SYSWATCH, in CACHESYS to monitor the various Caché daemons and report if one of them terminates. This is not started by default when the system comes up. To start this add

JOB ^SYSWATCH

to ^ZSTU or SYSTEM^%ZSTART. SYSWATCH makes a console log entry if a daemon terminates. The ^%MONITOR utility can be configured to generate an email when this occurs.

DO ^SYSWATCH

in a terminal brings up the control menu. This lets you start/stop the daemon, display any messages it has logged or reconfigure the interval between cycles. The default interval is 120.

SYSWATCH records a little bit of information in ^SYS("SYSWATCH"). When it starts up, it purges any records which are more than 30 days old.

During shutdown, Caché will record whether there are open transactions and whether journal restore is required during the next startup.

When it next starts up, if Caché cannot determine the last journal file from the WIJ, or if a required journal file cannot be opened, and shutdown did not signal that journal restore/transaction rollback were not required, the system will not enable logins.

The -B command line flag can be used (with csession on UNIX/OpenVMS or with ..\bin\cache -s. on Windows) to login to Caché to resolve the problem. ^STURECOV can be used to retry certain operations or to force Caché to start up with logins enabled regardless of any problems which may be present.

Care should be taken when forcing Caché to start up if journal restore/transaction rollback cannot be run because the application data may be inconsistent in the globals.

In addition to the above, if the transaction rollback process queues pending ECP transactions for later in the startup process, and if ECP fails to properly deal with the pending transactions (either roll them back or re-establish the transaction context), logins will not be allowed until the problem is resolved.

Change JO1836 changed the product so that during startup if Caché does not find a WIJ and/or journal file, it will not allow users on the system. However, in the case of a clean, normal shutdown this check is overly-cautious and counterproductive.

This change alters ^JRNSTOP so that it leaves behind the same information as ^SHUTDOWN to tell ^STU that journal and transaction processing recovery are not required at startup.

This modifies Caché DDP networking for clusters so only the master will send out advertisements. Getting advertisements from multiple nodes from the same cluster was confusing DSM machines.

Avoid creating multiple versions of the PATROL.DAT file on OpenVMS.

This change fixes a possible hang in SHUTDOWN that can occur while trying to deallocate memory for PERFMON.

The cconsole log now contains a field denoting the severity of the message information: 0 means informational, 1 is warning, 2 is severe, 3 is fatal.

Prior to this the severity code was being treated as loglevel. This change corrects that error and properly displays the output severity.

This change supplies a severity code for significant system errors. Severity codes range from 0 (informational) to 3 (fatal). They are logged in cconsole.log as a number following the date/time and before the message.

This summarizes several changes and improvements to the Monitor facility:

SAP234

This provides a management console for Monitor. The console allows the operator to start and stop Monitor, set various parameters, and define email settings.

SAP235

The system Monitor is started at system startup. If email options are not configured, it enters a wait state until email options are configured and the monitor is refreshed via the management console. Otherwise, it begins its monitoring of the cconsole log immediately.

SAP238

Allows the cconsole.log to be deleted while Cache is running.

SAP246

Allows the scan interval to be set. Upon setting email options for the first time and restarting Monitor, it will have a high cpu usage because it has to scan the entire log.

This change MQmake creates MQInterface.so for use on AIX 64-bit platforms.

This change corrects a situation that could case an access violation during View operations.

This change allows a process to have more classes active at any one time, and more efficiently deals with classes that are not in active use by the process.

The Caché cluster code has been enhanced so that a cluster member is no longer allowed to fully join a cluster while a switch (10/13/14) which disables database access is set cluster-wide.

Previously this was allowed and the new system would be allowed to cluster mount and read/write from databases. If the cluster was in the process of performing a backup, this could cause problems.

Now the new cluster member will detect the switches which have been set cluster-wide and set those switches locally while it starts up. This may mean that the Caché startup process will hang if a switch is set which blocks global access. A console log message will be generated if this occurs.

This version can interoperate with older versions but the new functionality will not be present unless the master and the system joining the cluster have been upgraded to a version with this correction.

With this change, Caché now remembers the journal index of open transactions. In prior versions, it was possible for a dead ECP server session to leave an invalid journal index.

Console messages for shadowing now come with severity levels (INFO, WARNING and SEVERE).

During journal restore at startup a monitor will be started to record the progress of the journal restore in the console log. Messages will be generated every 5 minutes so that if the process takes a substantial amount of time, the system manager can verify that it is working properly.

The console log messages look like:

10/04-10:12:09:760 (17976) 0 Write daemon started.
10/04-10:12:11:042 (17400) 0 Clean Daemon Started
10/04-10:12:11:192 (13288) 0 Performing Journal Recovery
10/04-10:17:41:366 (18012) 0 Monitoring journal restore process pid 13288
10/04-10:17:41:616 (18012) 0 Journal restore progress.
     File: c:\cache42\mgr\journal\20041004.015 Address: 102827040
10/04-10:17:44:881 (13288) 0 Performing Transaction Rollback
10/04-10:17:49:568 (13288) 0 Max Journal Size: 1073741824
10/04-10:17:49:588 (13288) 0 START: c:\cache42\mgr\journal\20041004.016
10/04-10:17:50:038 (13288) 0
Journaling selected globals to c:\tmpcache42\mgr\journal\20041004.016 started.
10/04-10:17:50:068 (13288) 0 Rolling back transactions ...
10/04-10:18:11:629 (18012) 0 Journal restore monitor exiting

(The entry of 17:50:038 has been placed on two separate lines.)

On Caché for Windows, a new option is added to the css program that allows a user to start only the system daemons without doing any of the normal recovery steps. This option to the css program looks like

css startnostu [<config>]

This functionality is required to resolve the occasional customer crisis. One example of such a case is when journal recovery errors or hangs the system because of filefull conditions or database errors. You need to force down, start with NOSTU, enter Caché with the -B option, fix the problem, and then restart. Starting with the NOSTU option does not zero any journal recovery pointers in the WIJ. That way, when you restart normally, you will still do the same recovery that was pending.

This section provides a listing of changes between Caché 5.0.18 and Caché 5.0.19.

For detailed information on getting started, see the Caché 5.0 Release Notes (located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 5.0 maintenance kits, see the file prenotes.htm, located in the same directory as this file.

This document contains several sections:

• Known Regressions In Functionality
• Important Caché News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• A list of changes considered critical for this release

The following regressions in functionality are known to exist in this release and may adversely affect applications. If you need an immediate correction for any of these defects, please contact the InterSystems Worldwide Response Center.

They will be fixed in a future maintenance release.

• A problem has existed since Caché 5.0.16 when calling Stored Procedures. If an application using ODBC or JDBC issues a Close Statement call, Caché incorrectly removes all server side information about the statement. If the application tries to execute the same Stored Procedure a second time, Caché will return an <UNDEFINED> error from the server.

  There is no workaround for this error.
  
  

• A defect has been identified that was introduced in Caché 5.0.11. If you use the follow SQL syntax

  SELECT PatID, Name, SSN
  INTO :array()
  FROM Sample.Patient
  

  where PatID was defined as the IDKey, the node where the value of PatID is stored could change. In releases before 5.0.11, you would have an array that looked like:

  array(2)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  while in Caché 5.0.11 and later the array would look like:

  array(1)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  The value of PatID had moved from array(2) to array(1).

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

This change corrects a problem that was slowing down routine searches using the character-oriented utilities.

This corrects a problem where Caché Basic did not correctly handle the case where a Replace() function results in a string longer than 32K. Before this, it resulted in a <SYSTEM> error and/or an access violation; now it correctly reports a <MAXSTRING> error.

CacheCOM keeps a cache of shared library handles which it has loaded. Due to a bug on certain versions of AIX, second and subsequent calls to unload the library may indicate it is not present, even though the library remains loaded.

This change does not attempt to cache these library handles on AIX avoiding a potential infinite loop.

In ECP clusters, when a cluster database is unmounted and then remounted on the cluster master, subsequent $INCREMENTs from the cluster slaves may fail with a <Directory> error. This corrects the problem so the error no longer occurs.

On some 64-bit platforms (i.e. alpha VMS), when the number of ECP connections was greater than 32, ECP did not handle various internal states (i.e. pending transactions, client cache) properly. This is now fixed.

This change corrects a compile-time <SUBSCRIPT> error when a WHERE clause contains any of:

• The constants: 'NVL', 'CASE', 'IFNULL', 'ISNULL', 'COALESCE', 'NULLIF', or 'DECODE'
  
  
• The host variables :NVL, :CASE, :IFNULL, :ISNULL, :COALESCE, :NULLIF, or :DECODE.

This corrects a circumstance where OUTER JOIN could produce an incorrect answer. If there is complex condition (for example, an OR condition) on a column of the right table of a LEFT OUTER JOIN, and an index containing this column as a subscript is chosen by the optimizer, then an incorrect result may be delivered.

Before this change, a ZLOAD command would get the number of source lines from the current object code of the routine. If more lines had been added and saved by Studio without recompiling the routine, those lines would be lost with a subsequent ZLOAD and ZSAVE. If lines had been removed, a subsequent ZSAVE would get a <NOSOURCE> error.

With this change, the ZLOAD will get the number of source lines from the current value in the ^ROUTINE global, thus correctly using the current source.

A fix introduced in 5.0.16 had an unintended side effect of terminating the process after a <FRAMESTACK> error when it should have gone into a debug prompt. This fix provides correct handling after a <FRAMESTACK> error.

A process which is exiting and running %HALT, or any of its subroutines such as %ROLLBACK, will no longer respond to RESJOB. The process issuing the RESJOB will not receive any notification that the target ignored it. Shutting down the system with

ccontrol stop

will terminate these processes as it has in the past.

Additionally, direct calls to $ZUtil(4) will no longer terminate a daemon on UNIX or Windows. These will return an error status of 0.

This change also adds a new return code from $ZUTIL(4); a -4 means the target is running %HALT so the RESJOB was ignored.

$ZUTIL(4,<pid>,-65) can be used to force the job to exit anyway although an open transaction will not be rolled back even though the locks which protected it will be released.

This resolves a rare problem which could result in process dumps in cases where routines switch and one or more of the namespaces involved in the routine call stack is an implied namespace (^^<directory reference>). This is a rare problem because implied namespaces are not generally used in applications. This is more likely to be seen in a development environment.

The error handling cases of functions which manipulate namespaces has been improved to avoid possible access violations. The affected command and functions are:

• ZNSPACE command
• $ZUTIL(5)
• $ZUTIL(20)
• $ZUTIL(39)
• $ZUTIL(45)
• $ZUTIL(46)

Previously if one of these failed, certain internal structures would be left in a not quite coherent state which could lead to subsequent memory exceptions.

This change corrects a rare circumstance resulting in database degradation could occur during the addition of a secondary database volume. The error occurs if the current size of the database ends on a map block and the addition of the new volume requires setting incremental backup bitmap bits. If this occurs, the write daemon will encounter a serious disk write error because it tries to write the new bitmap blocks past the end of the prior volume set member.

This change corrects that situation where sending a broadcast to the CONTROL process with

$zu(94,<pid of CONTROL>,"test",2)

causes the CONTROL process to core dump.

This fixes an error where terminal output stopped by Control-S or XOFF while the job is inside lock module could result in backup failing.

This change fixed an online backup quiesce problem on cluster platforms with ECP channel. When there are jobs in slave systems waiting for an answer from the master, the online backup will fail on quiescing the cluster systems.

A very rare condition which can result in a hung Caché cluster on VMS has been resolved. The symptom is that the ENQDMN misses a wakeup call and is hibernating while it has work queued up. When this happens, the entire cluster will hang.

The hang can be diagnosed by examining the output from

cstat -"E"4

and looking for a list of work waiting for the ENQDMN. In

cstat -p2

the ENQDMN will say idle (job #6). A

cstat -"P"6

will send a wakeup to the ENQDMN and should resolve the hang.

This change addresses a problem with multi-job journal restore on Windows where JOBbed restore jobs may hang in ^%Wprim or ^%CDCalBk (as shown in ^JOBEXAM). It affected only Windows platforms due to the way a JOBbed job is determined whether to be in GUI mode when %UI is not set. While it mainly arises from the multi-job restore feature introduced in 5.0.5, the problem may affect any user-implemented, jobbed off journal restore if local variable %UI is not explicitly set.

This change corrects an issue in journal restore where too many concurrent global sorts could exhaust the page file quota of the process on OpenVMS, resulting in a <STORE> error.

This fixed an error in identifying the lock owner in an ECP server for locks owned by remote ECP client. If the locks were granted inside a transaction of the ECP client job, the server showed the wrong lock owner.

This corrects a problem introduced in 5.0.13 where SETs and KILLs applied to shadow databases were journaled despite that the "journal applied transaction" property was not enabled.

Two new class methods have been added to %SYS.Namespace: GetGlobalDest and GetRoutineDest.

GetGlobalDest

Returns the system^directory where ^[Namespace]Global(Subscript) is mapped to. If Subscript is missing, it returns the location for ^[Namespace]Global. If Global is missing, it returns the default global location for Namespace.

GetRoutineDest

Returns the system^directory where Routine is mapped to in this Namespace. If Routine is missing, it returns the default routine location for Namespace.

This fixes an error in searching for Basic routines using the CHUI utilities. Only routine names with dots in them are affected by this bug, and even in that case, only names where the second piece after the dot begins with something that collates before "BAS". Prior to the change, Basic routines named x.ABC or x.999 or x.1.y were not being found.

The free space calculations of the %FREECNT utility were incorrect for larger databases. As a result, %FREECNT could report more than 100% of the space as free.

This has been corrected.

This section provides a listing of changes between Caché 5.0.17 and Caché 5.0.18.

For detailed information on getting started, see the Caché 5.0 Release Notes (located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 5.0 maintenance kits, see the file prenotes.htm, located in the same directory as this file.

This document contains several sections:

• Known Regressions In Functionality
• Important Caché News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• A list of changes considered critical for this release

The following regressions in functionality are known to exist in this release and may adversely affect applications. If you need an immediate correction for any of these defects, please contact the InterSystems Worldwide Response Center.

They will be fixed in a future maintenance release.

• A problem exists in Caché 5.0.16 when calling Stored Procedures. If an application using ODBC or JDBC issues a Close Statement call, Caché incorrectly removes all server side information about the statement. If the application tries to execute the same Stored Procedure a second time, Caché will return an <UNDEFINED> error from the server.

  There is no workaround for this error.
  
  

• A defect has been identified that was introduced in Caché 5.0.11. If you use the follow SQL syntax

  SELECT PatID, Name, SSN
  INTO :array()
  FROM Sample.Patient
  

  where PatID was defined as the IDKey, the node where the value of PatID is stored could change. In releases before 5.0.11, you would have an array that looked like:

  array(2)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  while in Caché 5.0.11 and later the array would look like:

  array(1)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  The value of PatID had moved from array(2) to array(1).

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

A new switch has been added which allows processes connected to a Windows system via telnet to receive a <DSCON> disconnected error asynchronously at the time the disconnect occurs. The default behavior is to give the error only on the next READ command. This switch has no effect unless disconnect errors are enabled with $ZU(68/69,15,1). The new switch is $ZU(68/69,60,1).

This change adds the parameter, AsyncDisconnectErr, to the Miscellaneous section of the .cpf file.

If a user CSP application

• is using %session.Preserve=1 mode,
• and it issues a 'Lock' command.
• and then releases the lock this process has on the CSP session,

it was possible for the CSP daemon to clean up this license just before the process running this connection exited. In fact, the license and session information would get cleaned up twice.

With this change, the end session code gets another lock on the CSP session before doing anything with this in case the user code released this lock. If the session global is empty, then it knows someone else has removed the session so it has nothing to do. Also the CSP daemon will time the session out just slightly slower than the process exiting so the actual process gets to close the session properly first before the daemon tries to close it.

This change adds code to handle the case where the characters $c(13) and $c(10) occur inside the #server directive.

This change always forces JavaScript conversion of #server arguments to strings which will always use periods in a decimal number. Previously, when using the Java applet, #server relied on Java LiveConnect conversion of a number to a string. Internet Explorer used the current locale for this conversion (for example, ",", for non-English locales) and Mozilla used JavaScript conversion (always "."). Now all browsers consistently use JavaScript conversion.

This changes the default behavior of %Net.SMTP to not write Bcc headers into the email message.

The ShowBcc property has been added to %Net.SMTP which, if set to 1, will keep the old (incorrect) behavior of sending the Bcc headers.

In prior versions, the logic in DriveListFetch caused the last item not to be returned. This is fixed.

This fixes a bug that occurred when or'ing two bitlists, where one was in bit list format (as opposed to bit map format), and the other one had a shorter logical length and was all ones and had no body.

This change alters the optimization which determines the optimal number of open files for network daemons by eliminating it for OpenVMS. The optimization addressed a performance problem on NT only and is not an issue on OpenVMS.

Applications can only view global directory blocks across ECP, other blocks may fail or not arrive completely. This change modifies the view across ECP to protect ECP and application from buffer overruns.

When a remote class is in use and there is an ECP server failover, sometimes the method invocation fails with an unexpected remote class recompiled error. This has been corrected.

Sometimes the ECP client read daemon didn't exit on shutdown. This is now fixed.

This changes the NWDS master to preserve ECP client configuration after master reactivation. Without this fix any reference to a remote DB via ECP may cause an access violation.

Activate did not properly discriminate between interface-based and enumerated user-defined types. This led to access violations when attempting to use some ActiveX Objects. The situation has been corrected to treat these types appropriately.

Additionally, to help identify those ActiveX objects which cannot be handled by Activate, the classes %Activate.SafeArray and %Activate.UserDefined (which are subclasses of %Activate.Unsupported) have been introduced. Those ActiveX objects that have method/property parameters or return values of these types are not supported.

Some classes have recursive references that allow simple structures such as linked lists to be represented. Under some circumstances, a relatively small number of objects that are linked can cause a <FRAMESTACK> error when triggers fire during a save if all objects have been swizzled. A change has been made to %Save() that recognizes simple recursive references and chooses a different mechanism for including each swizzled reference to the save set.

This change, originally introduced in Caché 5.0.17, had issues related to importing OBJ code stored in an XML file. These have been addressed.

Some object references result in a circularly linked list. This structure caused an infinite loop. This change detects that situation and prevents the loop.

This change adds an OutputTypeAttribute property to %SOAP.WSDL.Reader class. If OutputTypeAttribute = 1 when the Process method is called, then the OUTPUTTYPEATTRIBUTE will be added to the Web Client which is created.

The variable, %msg, is now set to the error text when an ID counter validation check failure occurs. This makes object behavior consistent with SQL error reporting.

An error was fixed where an <INVALIDOREF> error is reported when a property that originates in a superclass is subsequently inherited from a different superclass.

%BuildIndices and %PurgeIndices is now supported for classes using %CacheSQLStorage. Previously these methods were only implemented for classes using %CacheStorage. %CustomStorage does not implement these methods.

Caché Objects use transactions during filing. If the user initiates a transaction outside of a call to %Save(), then some in-memory structures might not be updated if the user transaction is subsequently rolled back. There is no mechanism available to rollback the state of the in-memory objects in this situation. The problem is that object persistence might improperly dispatch to an update when the object does not exist in storage. Classes using %CacheStorage do not experience this problem because of an internal existence check that is performed prior to dispatching to insert or update. %CacheSQLStorage does not perform this check so it is possible that an object will be dispatched to update which will subsequently fail with SQLCODE = 100.

%CacheSQLStorage will now check for an update failure with SQLCODE=100. In that case it will attempt to save the object with an insert.

If the idkey definition includes the parent reference then, with this change, it will not be automatically added to the idkey by the class compiler.

Previously, it was possible for an infinite loop to occur when saving an object that contained a reference to a self-referencing object (also known as a reflexive object); this loop occurred in %AddToSaveSet. This has been addressed.

Background:

A recursive class is a class that has a property whose type is that same class. A recursive object is an instance of a recursive class such that one instance of the recursive class has reference to another instance. A self-referencing or reflexive object is a special type of recursive object — one that has a reference to itself.

Prior to this change, if a stream is saved as part of a transaction, and the transaction is rolled back because another object in this transaction failed to save, the stream was not rolling back its internal state and so would lose the stream data. This is now fixed.

Some Java tool kits require the xsi:type attribute to be specified for all elements even when the type can be determined from the WSDL document.

This change adds the property OutputTypeAttribute to the %XML.Writer class which forces the xsi:type attribute to be added to elements that are output based on object properties.

It also adds the parameter OUTPUTTYPEATTRIBUTE to SOAP Web service classes that forces the xsi:type to be used for all elements in the response; and the parameter OUTPUTTYPEATTRIBUTE to SOAP Web client classes that forces the xsi:type to be used for all elements in the request.

The SQL Scalar functions TO_DATE and TO_CHAR now accept %TimeStamp values as input. In addition, support for some time-related formats have been added.

For TO_DATE and TO_CHAR, the expression passed to the function may now be a valid %Library.TimeStamp logical value.

For TO_DATE and TO_CHAR, the following format codes have been added for support of TimeStamp values:

   HH     Hour of Day (1-12)
   HH12   Hour of Day (1-12)
   HH24   Hour of Day (0-23)
   MI     Minute (0-59)
   SS     Second (0-59)
   SSSSS  Seconds past midnight (0-86399)
   AM     Meridian indicator
   PM     Meridian indicator

TO_DATE now supports the following two formats: 'YYYYMMDD' and 'DDMMYYYY'

With this change, when an application

• uses %CacheSQLStorage,
• has two or more subscript levels of Access Type $Piece, and
• has specified Data Access expressions for those subscript levels,

it needs to specify a valid Row Reference in your map definition rather than try letting the system generate one for you.

A problem has been fixed where a table that could not generate filing code due to a non-filable %CacheSQLStorage mapping might get a <NULL VALUE> error during the compilation of the table.

A correction has been made to the SQL Manager. If TuneTable was invoked from SQL Manager and ended up with a very small Selectivity, first 5 decimal places all 0, the SQL Manager would file the wrong value.

A previous change (AND453) made parameter resetting impossible. This caused issues when SQLExecDirect was called. Hence, the behavior has been reversed, so that Caché now pays attention to user-supplied parameter types.

This change corrects a problem that occurs in child table when the parent table rowid has more than 10 physical components, for example, more than 10 generations of parents/grandparents. This problem exists in all versions of the product.

This is an enhancement to the header info that is stored in ^mtemp0. The change adds Name Space info the header of ^mtemp0. This is used by generated SQL code for sorts during query runs. The info can be used to track down problem queries.

The structure looks like:

^mtemp(8,0)=$H^Job #^UserName^Server Name^Client IP^Routine Name^Name Space

for example:

^mtemp0(8,0)=58953,29117^1984^TestUser^TESTLAB2^127.0.0.1^CacheSql1^User

SQL UPDATE, DELETE, and INSERT...SELECT statements are now atomic in nature; the statement either completes successfully or no rows in the table are modified.

For example, assume you execute an update statement that will update 20 rows in the table. The new value for a field in the 17th row fails validation. Prior to this change, the first 16 rows would have been updated and the statement would return an SQLCODE=-104 error. It was up to the application to catch the error and role back the update of the previous 16 rows (if desired). Now, if any row fails to update, none of the rows in the table will be updated by the statement. The same is true for DELETE and INSERT ... SELECT statements.

A bug has been fixed where a statement like:

UPDATE MyTable
   SET MAXID = MAXID + 1
 WHERE MyField = ?

might not update any rows due to concurrency issues if multiple processes where attempting the update at the same time.

This change, originally introduced in Caché 5.0.17, had issues related to importing OBJ code stored in an XML file. These have been addressed.

If a routine being debugged by one process is updated by another process, the system could attempt to use an invalid address to resume execution in the debugger. This gives invalid results or an access violation for the process being debugged. The situation is now corrected.

The ECP client sends its connection name to the server. Currently the name is

<cli sys name - default is host name>.<ECP connection name>

This change alters the order and the separator; the new format is:

<ECP connection name>:<cli sys name - host name>

If the cli sys name is too long it will not prevent ECP from recovery, (The server identifies the connection by the connection name + the client GUID). Also, the server entry in the control panel will have the connection name followed by the host name; it makes the connection name be more useable since most sites are configuring multiple connections to the same server.

This change adds a console log msg with the destination host IP when an ECP client establishes a connection

This change makes TCP disable x/y calculation when a process's $zu(68,55,1) switch is set.

A rare problem which can result in memory exceptions has been resolved. The problem is most likely to be seen in application which reference more than 8 namespaces (often) or rarely when the system reloads the namespace configuration.

This fixes a problem on the import side of $zobjexport when using function 13 and UTF8.

A new switch has been added which allows processes connected to a Windows system via telnet to receive a <DSCON> disconnected error asynchronously at the time the disconnect occurs. The default behavior is to give the error only on the next READ command.

This switch has no effect unless disconnect errors are enabled with $ZU(68/69,15,1). The new switch is $ZU(68/69,60,1).

This change addresses an issue where an invalid (incomplete) global reference name may be passed to the filter (^ZJRNFILT) used in journal restore. This occurred if the character "]" appears in a subscript of the global reference.

The problem was present in all released Caché products.

If the source of cluster shadowing has a CACHEJRN.LOG whose last entry for a particular cluster system number is a journal file that doesn't exist, a message like the following message would be logged repeatedly to the cconsole.log:

JRNINFO SERVER ERROR: Information about _$101$DKA200:[JANUS.RJF5.MGR.JOURNAL]200
30917.001 cannot be updated as the file is gone

The most common reason for this situation would be if a former member of a cluster has been removed from the cluster. With this correction, the message will be logged only once.

Corrects a problem where shadow processes would consume excessive cpu on client systems because of excessive polling. This problem was most evident on AIX.

Addressed an issue where running journal utilities (such as JRNDUMP or JRNINFO) might result in an access violation (accvio) or a core dump in some circumstances. It affected mainly clustered Caché systems.

This change avoided a possible dead lock on the ECP client. For example:

• A job on ECP Client locked ^TEST(1,0) on server.
• A job on ECP server lock ^TEST(1,0) and wait.

If the client job then did the following:

F i=1:1:10000 l +^TEST(1) l -^TEST(1) w !,i

When a job owned locks to more than 8 remote server through any network (ECP,DCP,DDP), a non-incremental lock (L ^a) or argumentless lock (L ) command will leave the lock to 9th remote server in 'delock pending' state in lock table. Furthermore, the lock won't be released on the remote server either.

This change corrects that situation.

This change addresses a concurrency issue in cluster shadow that could cause an <ACCVIO> error.

This change corrects a problem in 5.0.13 and later where, under some rare circumstances, shadow processes might terminate unexpectedly for no obvious reason (i.e., no error message indicating what went wrong).

A problem that could cause the shadow set/kill process to get a <DIRECTORY> error during namespace reactivation has been corrected. The error had caused shadow dejournaling to stop on the shadow client.

This fixes a problem using REPAIR to allocate and free blocks in a map. The problem occurs if the database has more than one map and the block number is not in the first map.

Prior to this change, Caché would try to access $D(^|NS|foo) to validate the input namespace. This caused the system to slow down if the namespace were mapped to remote ECP.

Because the reference won't be cached in the client's buffer, there is an unnecessary round trip network for every use of it. This change removed this unnecessary checking.

When LOCKTAB is run on a cluster, this change will now add a line to the headed identifying this node as a cluster member, whether or not this node is the lock-master and, if not, the name of the node that is the lock-master. Attempting to free a lock on a cluster that was taken out on a node other than the originating node will display a warning message before allowing the user to proceed.

The change also adds a new, non-interactive utility to provide information about the cluster.

Manually freeing a single lock through LOCKTAB will add a message to the console log.

An issue was introduced with Caché 5.0.17 where the free space calculations of the %FREECNT utility and the Caché Control Panel's Local Databases display caused all free block values to be displayed as zero. This has been corrected.

This section provides a listing of changes between Caché 5.0.16 and Caché 5.0.17.

For detailed information on getting started, see the Caché 5.0 Release Notes (located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 5.0 maintenance kits, see the file prenotes.htm, located in the same directory as this file.

This document contains several sections:

• Known Regressions In Functionality
• Important Caché News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• A list of changes considered critical for this release

The following regressions in functionality are known to exist in this release and may adversely affect applications. If you need an immediate correction for any of these defects, please contact the InterSystems Worldwide Response Center.

They will be fixed in a future maintenance release.

• A problem exists in Caché 5.0.16 when calling Stored Procedures. If an application using ODBC or JDBC issues a Close Statement call, Caché incorrectly removes all server side information about the statement. If the application tries to execute the same Stored Procedure a second time, Caché will return an <UNDEFINED> error from the server.

  There is no workaround for this error.
  
  

• A defect has been identified that was introduced in Caché 5.0.11. If you use the follow SQL syntax

  SELECT PatID, Name, SSN
  INTO :array()
  FROM Sample.Patient
  

  where PatID was defined as the IDKey, the node where the value of PatID is stored could change. In releases before 5.0.11, you would have an array that looked like:

  array(2)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  while in Caché 5.0.11 and later the array would look like:

  array(1)=12345
  array(3)="Doe,John"
  array(4)="111223333"

  The value of PatID had moved from array(2) to array(1).

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

Prior to this change, it was possible for cstat to show a dead process as alive (that is, no "D" indicator in the pid table display) if the process Id had been reused by the operating system for a new process.

Cstat now performs further tests to insure that the process is running cache.exe from the configuration's bin directory before considering it a valid Caché process in the current configuration.

This change corrects a situation where, under certain circumstances, an attempt to send a broadcast message to all mailboxes could result in an access violation error.

A correction has been made for the situation where an object ID based on a simple integer property might be inappropriately detected as modified when set to itself. For example, 'set obj.Prop=6' would report the object as modified when the original value of obj.Prop had previously been 6.

Prior to this change, if you had a class on your system, and then an attempt to import another version of that class failed, Caché would delete the existing class. Now it correctly leaves the existing class present if there during import.

A prior change discarded the value of the EXTENTSIZE parameter when loading a class from XML or CDL. This change reverses that. If you are replacing an existing class with XML or CDL that does NOT contain EXTENTSIZE the EXTENTSIZE of the replaced class will be retained.

A new configuration option now makes it possible to validate system-assigned ID values for new instances of objects. The option is activated by

SET ^%SYS("dbms","validate system-assigned id") = 1

Classes using default storage and system-assigned IDs do not normally check for the existence of an object with the newly assigned ID value. That check is, under normal circumstances, not necessary as the global reference used for the system ID counter is updated each time a new object is inserted into the extent. However, in very rare cases, it is possible for this counter to contain an incorrect value. This can happen if the user modifies the value manually; if objects are inserted into the extent without using the object or SQL filer; or system recovery efforts modify this value and are subject to errors.

By setting the configuration option, the class compiler will generate a uniqueness check on insert for the ID value. If at runtime the uniqueness constraint fails, an error, IDKeyCounterNotValid, will be returned to the caller and a message will be written to the console log. Each failure will also cause the ID counter to be incremented so it is possible that the problem will correct itself over time. It is important to review the console log when this error is reported .

In certain deeply nested object models, it is possible that the underlying error message will not be reported. Rather, a cyclical dependency error could be reported from %Save(). This is not the usual case but, when a cyclical dependency error is reported, one possible cause might be the IDKeyCounterNotValid condition.

When an IDKeyCounterNotValid error message is reported it will be necessary to bring the ID counter back into sync with the data. It is the responsibility of the application developer or administrator to determine how the counter became invalid (manually set by a user or by code not using object encapsulation, bad recovery of a journal file, disk failure, etc.). The correction for the error condition depends on how the data and counter were caused to be out of sync.

During SQL INSERT, if the SQL filer needs to start a transaction, the transaction will now start earlier in the filer than it used to. The transaction will now start before any default values are assigned, including the $Increment(^glo) default value of the RowID field (if applicable). This allows the $Increment of any globals in default values to be recorded in the journal file.

This is the SQL counterpart to DLP1319. Please see that item for details.

The condition will be reported as an error code of -119.

The default file parameters when sending the output of %r to a file are now "WNS".

A problem has been corrected where under certain rare circumstances the same cached query routine could be associated with and invoked by two different SQL statements.

An error has been fixed where certain queries could return the wrong answer. The type of query affected contains these phrases:

• col1 IN (?,?,...)
• col2 IN (?,?,...)

and also the condition, col1 = col2, is true.

The problem may occur whether col1 and col2 come from the same table or different tables. Also, the IN condition could also be "(col1=? or col1=? or ...)" and similarly for col2.

Other conditions can occur before or after these, or in between them. However, if the join condition occurs before at least one of the IN conditions, the problem doesn't happen.

The Studio COS parser now colors legacy list functions: $ZLENGTH, $ZLIST, $ZELEMENT, and $ZSUBLIST.

Added Tools->Source Control->Add to the Source Control menu item which will cause to add the active document to source control.

A previous change introduced support for the new #[]# syntax, which allows ObjectScript commands to be embedded. This adds it to the &html(...) processor.

In prior versions, importing a routine from Studio was not working correctly because Studio lost the extension type of the item it had imported. The item would be imported correctly but it would not get compiled. This is now fixed.

When an attempt to lock an item calls the studio hook in the 'GetStatus' method, Caché now uses more information in returning an error code to the caller.

Prior to this, Caché would always report that the item was not checked out of source control. Now it only reports this is if the 'isinsourcecontrol' argument is true; otherwise it just reports that this item is not editable.

Also if a username is returned from the GetStatus call, this is displayed as part of the error text.

This change fixes a problem importing and compiling a BAS routine. It also improves support for importing large numbers of items into Studio.

The Studio Open dialog displays items sorted case insensitively. When a user opens up a namespace with a huge number of routines, Studio must scan the whole list to find the correct order to place these routines in. This can cause delays when there are hundreds of thousands of routines in a namespace. In order to allow these namespaces to be usable you can now set a flag:

Set ^SYS("Studio","CaseInsensitive")=1

This will force Studio in this namespace to work in a case insensitive manner which allows it to list the items as they are found rather than having to sort them all first. The routines are all listed at the root level rather than the standard approach which is the list routines from a class compile along with that class.

This change modifies the import/export functions so that they will also call the source control hooks when a user imports items. This permits the source control hooks to export them to a source control system.

When a process has set $HALT, it should be effective only for normal process termination. This fix corrects a problem that caused the system to attempt to locate and run the $HALT routine in situations such as RESJOB and system errors when the process should be halted immediately without attempting the $HALT.

The %STACK debugger utility could display unprintable characters if the routine object code is modified while the routine is being debugged. This is no longer the case.

If a routine sets $HALT to an entry point in a different routine, and the halt trap returns back to the original routine because of a QUIT command or a trapped error, the original routine context is not restored correctly. Prior to this change, this situation could cause invalid execution results or memory access violations.

A memory access violation could occur during error processing if there was an unexpected additional error while trying to read the routine source. With this fix, the system will continue without providing source information about the original error.

This changes corrects a rare problem where Caché may get suspended in a system function while holding database blocks under a lock.

A problem which could cause an exception (core file, dump file, etc) where an <EDITED> error should have been generated has been resolved. This involved cases where the program is returning after evaluating the result of an indirection that involved invoking another routine and the routine it is returning to has been recompiled. An example of where this could occur is a reference of the form:

 Set str="name($$ent(123))"
 Set x=@str

where $$ent goes off to another routine which causes the calling routine to be recompiled.

This fixes possible access violations during shutdown in situations where the process table has been expanding. This is on Windows only.

This correct a problem in $zobjexport with exporting long strings in a Unicode encoding.

New $System.Device class methods have been implemented. Descriptions are available in the %SYSTEM package class documentation. In summary:

• GetRightMargin() - returns the right margin setting for the current device. This only applies to terminals.
  
  
• GetReadTerminators() - returns the read terminator string for the current device. Does not apply to some devices.
  
  
• GetMnemonicRoutine() - returns the write mnemonic space routine name for the current device.
  
  
• GetMnemonicDirectory() - returns the write mnemonic space routine directory for the current device.
  
  
• GetClearScreen() - returns the Clear Screen (Form Feed) string for the process principal device.
  
  
• GetBackSpace() returns the Back Space string for the process principal device.<.LI>

A problem with the Caché node name recognition has been fixed. This only affected UNIX/Linux systems which connect to a DHCP name server. After an abnormal system shutdown, Caché startup could believe the instance was still in use by another node.

Correct utilization of the unique node name mechanism requires that the 'ccontrol nodename <name>' command be used to assign a unique name to the local node/machine, and that no instance of Caché should be active when the node name is assigned or modified.

Allow users to select "0" process count for less overhead in collection.

This change corrects issues with interactions between ^PATROL and ^PERFMON (MONITOR), and also removes unnecessary overhead (STATISTICS resource locking) when running PATROL.

This change adds ECP operations to the MONITOR (i.e. ^PERFMON and $System.Monitor) network statistics.

This change displays the correct client name for server statistics in MONITOR. ECP shows the name of client, as opposed to the address for DCP statistics.

This change corrects network MONITOR statistics, including proper display of ECP and DCP node names.

This change adds all network related counters (total requests, cache hits/misses for client, etc.) to the ECP MONITOR metrics. They now parallel DCP metrics.

This corrects a situation where, on Windows XP after the Control Process has crashed, the system can not be cleanly halted, even by cforce.

A process performing %SS or any mailbox send may hang forever if the destination process has gotten in a state where the mailbox lock is permanently held. With this change, the calling process will exit the mailbox code after trying and failing to get the mailbox lock 10 times (total wait of 1 second).

This corrects a situation where, if you change the priority of one process other than the current one, using $SYSTEM.Util.SetPrio(prio, processid), then all process priorities may be changed by the same amount. This will not happen if the current process priority is changed, using ^PRIO or $system.Util.SetPrio(n).

This corrects a problem where a fault could occur during use of the $VIEW function to view data in the process partition.

This change adds a new daemon called the 'Clean Daemon' (CLNDMN). This daemon wakes up every 10 minutes to scan the system pid table to see if any dead jobs are pending. It will reclaim any dead job pid slot it finds. This daemon takes over the duty used to be done by Control Daemon.

This change fixes a potential problem on 64-bit platforms where trying to load a user DLL or shared library via $ZF(-4)/$ZF(-5) might result in an error depending on previous memory allocations.

This change adds an option to remove default directories (for searching for journal files to dejournal) when setting up noncluster journal restore. (The mechanism/interface for locating journal files in cluster journal restore is different.)

Prior to this change, the prompt for specifying journal directories along its help text looked like this:

Files to dejournal will be looked for in:
d:\Cache51\mgr\journal\

Specify other directories to search: <return when done>

There was no way to remove "d:\cache51\mgr\journal\" from the list of directories to search for journal files.

With this change, the prompt looks like this:

Files to dejournal will be looked for in:
     d:\cache51\mgr\journal\
in addition to any directories you are going to specify below, UNLESS
you enter a minus sign ('-' without quotes) at the prompt below,
in which case ONLY directories given subsequently will be searched

Directory to search: <return when done> -
     [Directory search list is emptied]
Directory to search: <return when done> d:\cache51\mgr\journal\
Directory to search: <return when done>
Here is a list of directories in the order they will be searched for files:
     d:\cache51\mgr\journal\

Note that there must be at least one entry on the directory search list or Caché will issue a warning:

** WARNING ** Directory search list must NOT be empty

and the setup will keep prompting.

Directory to search: <return when done>

unless one hits Ctrl-C to abort journal restore.

A new sequential file OPEN option has been added, to provide exclusive write access to a file. This provides a way of blocking simultaneous updates of a given file by various processes. The "L" option may be combined with "R" and "W" options as follows:

• "WL" - exclusive/write mode
• "RL" - shared/read mode
• "WRL" - exclusive read and write mode

Under Caché/Windows, shared access for read and write is the default, so "RL" does not alter the behavior. Exclusive mode interacts with file accesses by non-Caché applications on the system.

Under Caché/UNIX, the share mode mechanism employs file locks, so "RL" is necessary to coordinate with "WL" usages. If the "L" option is not specified on OPEN, file locking neither affects nor is affected by processes that do not employ it.

Under Caché/OpenVMS, files opened for write access use exclusive mode (no sharing), and those opened for read use shared GET mode. This behavior is not affected by the current change, hence the "L" option is not used.

To avoid accidental deletion of a sequential file due to incorrect keyword syntax specification in the OPEN command, this change nows causes a syntax error to be reported if there is a "/" (slash) anywhere in the mode parameter string (the first positional device parameter).

In previous releases, if one of the extensions after the first volume of a multi-volume DB fails to mount during startup, then those extensions that successfully mounted before the failure are not cleared, and are assigned instead to the next DB in the list of databases in the config file.

For example, suppose there are two databases, "Multi" and "Single". Multi has primary and 3 extensions stored in these files:

• c:\cache5012\mgr\
• c:\cache5012\mgr\v2
• c:\cache5012\mgr\v3
• c:\v4

Further suppose that the cache.ext in c:\v4 is deleted and Caché is started.

In this case, the DB Multi is not mounted because extension v4 fails to mount. But the DB Single will be started as a multi-volume DB, with extensions in

• c:\cache5012\mgr\v2
  
  and
  
  
• c:\cache5012\mgr\v3

An error was corrected in %Buttons where the cstat output and/or cconsole.log files were being deleted even if they were not copied to the HTML output file.

%Buttons does not include these two files if they are larger than 5MB or if appending either one of them will make the HTML output file larger than 5MB. In this case, a pointer to the original location of the cstat and/or cconsole.log is written to the HTML file.

In calculating free space, this change causes Caché to examine secondary map blocks first to determine which maps are full maps. This avoids the need to read in those blocks for maps that are known to be full.

This change allows $$RebuildIndex^%R(impliednamespacereference) to work correctly. Prior to this, it would return an error.

This changes corrects errors in looking at the bitmaps on big-endian databases.

With this change, WebLink is now fully compliant with HTTP v1.1 response headers.

In particular it is possible to take advantage of v1.1 KeepAlive connectivity in WebLink applications. Unlike HTTP v1.0, KeepAlive connectivity is 'on' by default in v1.1. If KeepAlive connectivity is not required the 'Connection: close' header directive must be added. For example:

HTTP/1.1 200 OK
Content-type: text/html
Connection: close

If KeepAlive is used, a 'content length' header field must be supplied. If the response header generated by the application indicates that KeepAlive should be used but does not contain a 'content length', WebLink will automatically buffer the response content, determine its size, and insert the length header before dispatching the whole response to the client.

This change allows HTTP 'Keep-Alive' connectivity to be used in WebLink applications, for example,

Minimal HTTP/1.0 response header without keep-alive:

HTTP/1.0 200 OK
Content-Type: text/html

Minimal HTTP/1.0 response header with keep-alive:

HTTP/1.0 200 OK
Content-Type: text/html
Connection: keep-alive

Minimal HTTP/1.1 response header without keep-alive:

HTTP/1.1 200 OK
Content-Type: text/html
Connection: close

Minimal HTTP/1.1 response header with keep-alive:

HTTP/1.1 200 OK
Content-Type: text/html

Note that the default behavior is for keep-alive to be 'off' in HTTP v 1.0 but 'on' for HTTP v1.1.

When Keep-Alive connectivity is used it is necessary to include a 'Content-Length' response header. If the application does not include this field in a response for which keep-alive is required (as is the case in the examples above), WebLink will cache the response data to determine its size and add the length field before dispatching the final response headers. However, better performance will be achieved if the application is able to add this field. For example:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 123

This document provides a listing of changes between Caché 5.0.15 and Caché 5.0.16.

For detailed information on getting started, see the Caché 5.0 Release Notes (located off the Caché installation directory in the file Docs/GCRN/GCRN.html); for information on previous 5.0 maintenance kits, see the file prenotes.htm, located in the same directory as this file.

This document contains several sections:

• Important Caché News, Alerts, and Advisories
• Online Documentation
• Description of a Change Report
• A list of changes considered critical 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 - 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.

This changes fixes a race condition in the initialization procedures for the UNIX Apache API modules which could result in the Gateway not correctly reading and initializing its configuration.

This build fixes a problem that resulted in the PATH_INFO CGI environment variable not being correctly set for Apache-based installations.

Originally the hidden fields were inserted just after FORM tag. Then the hidden fields of a form were moved to just before the ending <FORM> tag to make scanning certain pages easier. However, this change introduced problems with uploading large files. Therefore, the hidden fields will be moved back to just after the <FORM> tag.

To control placement of the hidden fields, this change introduces a new CSP:CLASS attribute, FormHiddenFieldsAtEnd. If set to other than "0", the hidden fields will be placed just before the closing <FORM> tag. Default is to have the fields after the opening <FORM> tag.

This change makes CSP pages used for studio templates compliant with HTML 4.0.

This change corrects a circumstance where attempting to invoke the $BITLOGIC() function with more than 16 bitstrings in the argument could result in a memory access violation when the routine is compiled or incorrect results when it is executed. $BITLOGIC() will now correctly handle up to 31 bitstrings as documented.

This corrects a problem where incorrect code was being generated under certain circumstances for expression involving the EQV, IMP, and XOR operators.

This fixes a bug in the CacheBasic XOR and EQV operators where they were being handled as bitwise and not logical operators.

During startup, before finishing system initialization, ECP connections are accepted to be recovered. If the ECP client connection is accepted before the initialization is complete, the ECP daemons are started with incorrectly enabled NullSubscripts values.

This change enables clean up of temporary stream globals in %Dictionary classes; an %OnClose() method calls the Clear() method for each stream property.

Early incarnations of OLE objects in Caché defined properties as variables in the type library. This technique is almost obsolete and as such the Activate Wizard (type library reader) did not recognize them. The reader has been updated to recognize these variables as properties.

This change corrects an error where multi-level dependencies among classes where not detected by the class compiler. The compiler now correcting interprets the dependencies and compiles all the affected classes/

This change adds a new method keyword, ReturnTypeParams. This can contain a comma separated list of parameters for the return type of the method.

Previously, Caché supported parameters on arguments to the method. Now this is extended to the return type as well. A change to the parser in Studio will follow that takes advantage of this new method level keyword to store this information. Here is an example of a method definition that has parameters on the return type:

Method Test() As %String(MAXLEN=100)

This corrects a problem where trailing zeroes after fractional parts of seconds prevented correct comparison for %Timestamp values.

The specific problem this change resolves is that Rational Rose does not allow a class and a package share the same name, but Caché does. This means, if you select all the classes in Caché, some of them will generate an error on importing into Rational Rose.

The old behavior in RoseLink is that it quits once it encounters an error creating a class or creating the package of the class. This is fixed to allow it to continue so that it can finish the rest of the classes.

With this change, the old form continues to work. A new (instantiable) form now generated by the web service wizard is recommended, and will also work.

Since web services (subclass of %SOAP.WebService) are now a subclass of %RegisteredObject, the web service wizard will now create instance methods for the specified web methods. Class methods will continue to work for web methods.

Change the SOAP web client (SOAP.DemoProxy) and web service (SOAP.Demo) samples in the SAMPLES namespace to be instantiable, i. e. to use Methods instead of ClassMethods.

This fix corrects an issue where the ReturnFault method of web service was not properly preventing creation of SOAP body after a fault was generated.

This adds a KeepEmptyClasses property to %XML.Utils.SchemaReader.

If KeepEmptyClasses is true (1), then do not remove unused classes with no properties. The default is to remove them.

This change causes .NET to escape the URL in the SOAPACTION header that is sent to a web service. For example, "%Studio" becomes "%25Studio". We need to URL unescape the SOAPACTION when it is received.

Soap:binding element is specified by WSDL schema to be the first element contained in the wsdl:binding element. However, JAX makes it last. This change adjusts the WSDL reader to handle this difference.

This change has two parts:

• If style=rpc and a part name contains an _, then we need to generate XMLNAME parameter for the method argument.
  
  
• Expand error checking for soap:body parts attribute to handle list of parts that has more than one part.

Errors during web method execution were not returned correctly in HTTP test page. This is now fixed.

This change adds a GetListByName query to SOAP.Demo which returns a query result as a list of objects.

This corrects the message returned to the SOAP web client when the message contains an empty body.

This change adds properties to %SOAP.WebClient that it in turn will set in the %Net.HttpRequest instance that it uses to make the SOAP request. The %SOAP.WebClient property is the same as the %Net.HttpRequest property with "Http" as a prefix. The following properties are implemented:

• Username -> HttpUsername
• Password -> HttpPassword
• ProxyServer -> HttpProxyServer
• ProxyPort -> HttpProxyPort
• ProxyHTTPS -> HttpProxyHTTPS
• RequestHeaderCharset -> HttpRequestHeaderCharset

In addition, headers may be set in %Net.HttpRequest by calling the

SetHttpHeader(name As %String, value As %String)

method of %SOAP.WebClient.

An earlier change added support in web methods for parameters for the method return type.

This upgrades the SOAP Client wizard to create returned lists as %ListOfObjects or %ListOfDatatypes return type with ELEMENTTYPE parameter.

Normally web clients (subclasses of %Web.Client) and web services (%SOAP.WebService) should not be made persistent. In the rare case when they are, the properties of the base SOAP classes should be transient. This change implements that position.

The SendSOAPBody method of %SOAP.WebRequest will send an XML document as the body of a SOAP request and return the response body as an XML document.

This method is defined as