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.