Services
& Support

Support Alerts 1999


December 30, 1999 – Caché and ISM File Expansion Problem When The Associated Disk is Full

All Caché releases are susceptible to a problem with file expansion, although there are no harmful effects on platforms other than NT (Intel and Alpha) and Alpha/VMS. This problem was found during customer testing of boundary conditions in Caché 2.1.6, although the problem affects all releases.

The nature of the problem is that if expansion occurs on a disk that is nearly full, the last map block of the database may be overwritten. This does not cause database degradation because the map label is zeroed so the system will not allocate blocks from this map and ignore the map entirely.

However, on NT and VMS there is an additional side effect whereby the operating system also corrupts one database block within the map. When the disk is 100% full and cannot accommodate even one 2K block for expansion, NT may corrupt an existing data block in a previous map. This problem may be easily avoided by setting the “Maximum Number of Maps” to avoid file expansion on a full disk.

The correction for this problem, JO1117, will be included in Caché 3.1 and ISM 6.5 It is also available upon request for Caché 2.1.x and ISM 6.4.


November 18, 1999 – Device Unavailable – COM Port

Device Unavailable when trying to connect a terminal via %COM on com ports greater than COM9: on NT

To fix this, you will need to download the lastest %COM routine (v4.0). This version of %COM is able to utilize com ports beyond COM9:

It is available at ftp://ftp.intersystems.com/pub/cache/old/com.rsa


October 27, 1999 – Netfinity Compatibility with Caché

When Caché 3.1.x and Netfinity are run on the same computer, the netfbase.exe process can get access violations. This can be solved by un-installing and re-installing Netfinity and choosing to enable all the network driver protocols available. After the Netfinity installation is complete, the network driver protocols which are not used may be disabled and Caché 3.1.x and Netfinity will continue to work properly on the same machine. This problem does not affect Netfinity when running with Caché 2.1.x. For more information, contact the InterSystems Worldwide Response Center.


October 12, 1999 – Use $INCREMENT to Speed Up Caché Applications

Caché versions 2.1.6 and higher include a new language feature that can be used to eliminate a common application bottleneck on counters. $INCREMENT is a lock-increment-unlock mechanism that is highly optimized to avoid contention. Consider an example where several processes are simultaneously adding records to an order databases.

The traditional approach would have been to do the following:

NewOrder ;Old Technique

LOCK +^Order(0) ;incremental lock asserted on

; a counter reference

SET id=^Order(0)+1,^Order(0)=id ;acquire the ID

; and increment the

; stored counter value

LOCK -^Order(0) ;give up the lock

SET ^Order(id)=Data ;proceed to store order detail….

In this example, the process holds the lock for a fraction of a second. Other processes attempting to run the same code, are blocked for that fraction of a second. Also, consider that the process owning the lock may not complete the entire operation in it’s timeslice and a waiting process runs through it’s timeslice but can’t acquire the lock. This blocking effect may not be noticeable with a few processes contending for the counter, but will severely impair scalability with hundreds or thousands of processes.

Using the $INCREMENT approach, the same example would be written as:

NewOrder ;New Technique

SET id=$INCREMENT(^Order(0)) ;lock-increment-unlock

; in one operation!

SET ^Order(id)=Data ;proceed to store order detail….

Now, the process is more likely to complete the operation in fewer timeslices and will finish the operation is a fraction of the time. The effect is less blocking, much faster incrementing, and increased scalability!

Another consideration is using this technique in a network configuration. The classical approach would make 3 network round-trips, whereas the $INCREMENT approach would just make one round trip to accomplish the same task.

Caché employs this technique automatically for SQL and Object based applications. We think you should use it, too!


October 6, 1999 – Sequential Files Beyond 4GB

A problem exists writing to sequential files greater than 4GB. Output beyond 4GB will be written to the beginning of the file. Any hardware platform, running a version of Caché prior to 3.2 or a version of ISM prior to 6.5, is susceptible. A correction is available for current releases upon request. Contact InterSystems Worldwide Response Center for further information.


September 20, 1999 – The Viewpoint DSC Data Collector Process Crashes

When running Viewpoint with Caché 2.x and 3.1.x, there is a condition that can cause the DSC Data Collector process to crash. This occurs when there are numerous processes (over 600-700) on the Caché system so the 32kb limit on our TCP buffer is exceeded. This will not occur on systems without enough processes to surpass the 32kb limit on our TCP buffer.

This problem has been fixed by the following patches.

The patch for Caché 2.x is available at:
ftp://ftp.intersystems.com/pub/cache/old/VPSERVE.2x.ROMF

The patch for Caché 3.1.x is available at:
ftp://ftp.intersystems.com/pub/cache/old/VPSERVE1.31x.ROMF

To apply the patch in Caché 2.x, save a copy of the current VPSERVE.OBJ file for backup purposes. Then load in the new VPSERVE.OBJ routine. To apply the patch in Caché 3.1.x, save a copy of the current VPSERVE1.OBJ routine for backup purposes and then load in the new VPSERVE1.OBJ routine. The fix will be included in future releases of Caché.
Contact the Worldwide Response Center support@intersystems.com for further assistance.


September 7, 1999 – Direct Connection TCP/IP Problem in Caché 3.1

A problem has been discovered in Caché versions 3.1 and 3.1.1 that may cause TCP/IP connections to be broken. This problem affects the Object Architect as well as applications that use Caché Direct or the Caché Object factory.

We have narrowed down the problem to a bug in the new concurrent server mechanism. If the server fails, Cache Direct, WebLink, Object Server, and Caché Utilities clients are disconnected. The Studio, Explorer, Control Panel, and WebLink stateless-mode clients handle this error and continue to operate after it occurs. But the Architect, Object factory, and Caché Direct clients fail immediately on the next request to the server.

Correction

This problem is corrected in Caché version 3.1.2.

The correction is also available as a patch which can be applied to Caché 3.1.1 (and NOT 3.1) systems. This patch is available on InterSystems FTP site at

ftp://ftp.intersystems.com/pub/cache/old/CDSRV_311.exe

This self-extracting zip file contains a readme and a two patch files, one for Unicode systems and one for 8-bit systems. Please read the readme file carefully before installing the patch. It is necessary to restart Caché after installing this patch.

For additional information or assistance, contact InterSystems Worldwide Response Center.


August 23, 1999 – Important Installation Information for Caché Workgroup

A problem has been found when installing Caché version 3.1.1 using a Workgroup license. (This problem does not occur with any other Caché license type.) Depending on the speed of the machine on which Caché is being installed, one of the following symptoms may occur:

  1. The installation hangs during the Updating Caché Databases Phase.
  2. The installation seems to proceed normally, but <NOROUTINE> errors occur when running the System utilities or the FDBMS.
  3. The installation seems to proceed normally, but <UNDEFINED> errors occur when running the System utilities or the FDBMS.

This occurs because the System Manager database or the FDBMS database is not fully initialized during the installation. If this problem has occurred on your system, the CBOOT.DEV file will exist in the \CACHESYS\MGR directory after the installation.
To work around this problem, follow one of these procedures described below.

If this is a new installation of Caché:

  1. When you are asked (during installation) whether you want to enter a license key, answer no.
  2. After the installation has completed, use the License Wizard in the Configuration Manager to enter your key.
  3. After you have entered your key, restart Caché.

If you are upgrading an existing Caché system:

  1. Before upgrading, rename the cache.key file to cachekey.sav in the \CACHESYS\MGR directory.
  2. Perform the upgrade. When you are asked (during installation) whether you want to enter a license key, answer no.
  3. After the upgrade completes, rename the cachekey.sav file back to cache.key.
  4. Restart Caché.

If you have already installed Caché 3.1.1 and are experiencing these symptoms, re-install Caché by performing the steps described above for upgrading an existing system.


August 2, 1999 – Caché 3.1 May Hang if Global Buffers Depleted

Recently, development code review revealed a problem with a recent global-buffer requeuing optimization that may cause Caché to hang. This problem only exists in the Caché 3.1 release but it may occur on any platform.

This problem can only occur on systems that utilize the batch process feature. This feature can be enabled for a process directly via $ZU(68,25) or by executing LOW^%PRIO. If a batch process tries to dequeue the global buffer which is currently at the head of the batch section of the global buffer queue, the queue becomes broken with the result that many of the systems global buffers become invisible to the system. The effect of this can be a “run away” process which consumes 100% of the CPU time, Write Daemon Panic modes due to the low # of global buffers or degraded performance. A given system may see one or all of these symptoms. cstat -l1 (lowercase letter L) will display the LRUQ which is where the problem occurs. The number of buffers in the LRUQ should agree with the number of buffers reported in “AVAILBUF” later in the cstat display. If they disagree, or if you see a loop in the LRUQ (the last buffer will be displayed over and over) then you have encountered the problem.

This problem is corrected in Caché 3.1.1 which will be available for all Caché 3.1 platforms within the next 30 days. Expected availability for all platforms are always up-to-date.


July 6, 1999 -Caché 3.1 Startup Problem When Relying on Caché 2.1 License Server

A problem was found by internal inspection and it could impede Caché 3.1 from starting when relying on a license server on a Caché 2.x machine. A patch for Caché 3.1 is available at ftp://ftp.intersystems.com/pub/cache/old/lmfcli.obj and this may be installed in the following manner:

  1. Disable the License Server in the Caché 3.1 Configuration Manager
  2. Restart Caché
  3. Load the patch into %SYS using %RIMF, or the routine load utility in Explorer
  4. Enable the License Server again and restart Caché

June 29, 1999 – Now use Caché Studio to edit routines on Caché 2.x systems.

A new version of the CStudioUpd.exe is available which will allow Caché Studio users to edit routines on Caché 2.x systems.

The file is available by contacting InterSystems Support at:
617.621.0700 | support@intersystems.com

This file contains a set of routines which need to be installed on the desired server. Please follow the readme.txt file for installation instructions.


June 29, 1999 -Caché Database Expansion Problem

RELEASES 2.0 THROUGH 2.1.7 AND 3.0 (ALL PLATFORMS)

In very rare instances a problem with database expansion may lead to database degradation. This problem exists in Caché releases 2.0 through 2.1.7 on all platforms. It also exists in Caché 3.0, which was distributed in UNICODE character geographies, such as Japan.
This problem may only affect Caché installations which satisfy ALL of the following minimal requirements:

ALL REQUIREMENTS NECESSARY TO BE SUSCEPTIBLE

  1. At least one multi-volume database (CACHE.EXT file)
  2. File expansion is allowed in the multi-volume database
  3. Data is updated in more than one database since restarting Caché
  4. A multi-volume database has expanded at least once since restarting Caché and, subsequently, any database expands (Note: on some platforms, such as AIX, several dozen expansions may be required to become susceptible to this problem.)

Please note that satisfying these requirements does not guarantee that the problem will occur, but without the above requirements the problem will definitely not occur. Once all of these requirements have been met the potential for this problem exists. If your configuration meets all of these requirements, please take the following actions immediately:

RECOMMENDATION FOR SUSCEPTIBLE CONFIGURATIONS

  1. Download a revised CHECKMAP utility from ftp://ftp.intersystems.com/pub/cache/old/checkmap.ro which includes validation of incremental backup bitmap structures. Install checkmap.ro using %RI in the %SYS namespace.
  2. Run CHECKMAP on all databases. This may be done while Caché processes are active. If an error is detected, a specific error message such as ‘Map 123 has an error’ will be displayed. Report any errors to InterSystems or your Caché provider.
  3. Run DIAG or INTEGRIT on all databases while Caché processes are inactive. Active processes may lead to false reports of database errors since they modify the structures being scanned. If an error is detected, a specific message such as *******DATABASE ERROR********* will be reported. Contact InterSystems or your Caché provider if any errors are detected.

Any of the following preventive measures are recommended to avoid this problem:

CHOICES FOR PREVENTION

  1. Disallow expansion in the multi-volume database by setting the Maximum-Number-of-Maps value to equal to Current-Number-of-Maps value
  2. Restart Caché then force expansion by setting the Current-Number-of-Maps value to the Maximum-Number-of-Maps value and then restart Caché again
  3. Reduce the frequency of expansion, by increasing the Expand-By value (Note: this may reduce the opportunity for this problem). Contact InterSystems and request Caché 2.1.8, which includes the correction for this problem. Be sure to provide your version ($zv).

This problem is corrected in Caché 2.1.8 and 3.1 and beyond. Please contact InterSystems Worldwide Response Center (WRC) if you need assistance or require any further information.


May 20, 1999 -Configuring ^MTDEV To Retain Device Table Entries On Restart

Configuring ^MTDEV To Retain Device Table Entries On Restart. In Caché 2.1.6 (build019) and earlier, the ^MTDEV table did not retain device entries upon restart of Caché.

To change this behavior, refer to the following procedure:

  1. EXPORT STUCNFG2.INT: Before editing the routine, it should be backed up.
    %SYS>d ^%RO
    Routine output (please use %ROMF for object code output)
    Routine(s): STUCNFG2.INT
    Routine(s):
    Description:
    Output routines to
    Device: /usr/cachesys/stucnfg2.rsa Parameters: “WNS”=>
    Printer Format? No => No
    STUCNFG2.INT
  2. EDIT STUCNFG2.INT
    Add the line d STU^MTDEV just above the QUIT of the MagTape tag. Then Save and Compile.
    MagTape(Section) ;
    s $ZT=”STUERR^STU”
    d MSG^STU(“Processing MagTape section”,QUIETLY,0)
    n Index,TapeAddr,SystemDevice,Sep
    s Index=””,Sep=”~”
    k ^SYS(“MTDEV”)
    f s Index=$o(Config(Section,Index)) q:Index=””
    d:$p(Index,”_”)=”Drive”
    . s TapeAddr=$p(Config(Section,Index),Sep,1)
    . s SystemDevice=$p(Config(Section,Index),Sep,2)
    . s ^SYS(“MTDEV”,TapeAddr)=SystemDevice
    d STU^MTDEV
    Q
  3. ADD DEVICES TO CONFIG.DEF
    Now use ^MTDEV to add your Magnetic Tape Devices. Please double check the text file config.def to be sure the entries have been added to the [MagTape] section of the file. If the entry is not there, you can manually enter it in the following format:
    [MagTape]
    Drive_<#>=~
    The Drive # is nothing more than a sequential number for your magnetic tape device.
    i.e. If you want to assign Device 50 to a tape device called DAT, enter the following line:
    Drive_3=50~/dev/DAT /* For UNIX
    Drive_3=50~\\.\DAT /* For NT
    Drive_3=50~sys$DAT: /* For VMS>
  4. Restart Caché. The device should now be in the ^MTDEV table.

April 27, 1999 -Caché 2.1.7 Missing %qsn* Routines

Caché 2.1.7 comes with M/SQL F.14 and is missing three routines. The three routines are using for ODBC connections from other databases and report writing tools.
If you would like to use ODBC with this product you need to contact InterSystems Support at:
617.621.0700
support@intersystems.com

Extract the .obj file and us %RIMF to load it into %SYS.

DO qsnlib^%qarsp1

DO init^%convdat

You should then be able to start your server master, DO Start^%qsnstart(5001), and connect for a client application.


March 26, 1999 – Caché and Digital UNIX 4.0e

Caché 2.1.6 for Digital UNIX 4.0E Requires Separate Distribution Due to significant modifications in Digital UNIX 4.0E, as compared to prior releases, a Caché distribution kit specifically for 4.0E is required to operate properly. Caché distributions may be ordered from your Caché supplier or by contacting Order Processing – orderproc@intersystems.com

We expect that Digital UNIX 4.0F will also require a separate distribution. Stay tuned at the current products table or subscribe for automatic notification.


March 1, 1999 – Caché and ISM File Expansion Problem When The Associated Disk is Full

All Caché releases are susceptible to a problem with file expansion, although there are no harmful effects on platforms other than NT (Intel and Alpha). This problem was found during customer testing of boundary conditions in Caché 2.1.6, although the problem affects all releases.
The nature of the problem is that if expansion occurs on a disk that is nearly full, the last map block of the database may be overwritten. This does not cause database degradation because the map label is zeroed so the system will not allocate blocks from this map and ignore the map entirely.

However, on NT there is an additional side effect whereby the operating system also corrupts one database block within the map. When the disk is 100% full and cannot accommodate even one 2K block for expansion, NT may corrupt an existing data block in a previous map. This problem may be easily avoided by setting the “Maximum Number of Maps” to avoid file expansion on a full disk. Again, there are no harmful effects on UNIX or VMS platforms.

The correction for this problem, JO1117, will be included inCaché 3.1 and it is also available upon request for Caché 2.1.x.


March 1, 1999 – WRC Direct now available!

InterSystems Worldwide Response Center (WRC) is pleased to announce the availability of our new WRC Direct web-based application. WRC Direct allows supported customers to access the WRC’s problem tracking database for their list of open issues – complete with a log of all actions taken to date toward problem resolution.

Features include:

  • On-line Web-based New Problem Entry
  • Access To and Updating Of Existing Problems and All Actions Taken
  • Searchable Database of Known Problems
  • Statistical Monitoring of How Well We Are Meeting Your Needs

These features, we believe, will facilitate communications between customers and the WRC, allowing for easier problem entry and updating, and faster problem solution. This is already in use by many customers. If you would like access please contact InterSystems WRC at 617-621-0700 or email us at support@intersystems.com.


March 1, 1999 – Caché (NT) TCP Process May Crash or Runaway

Caché versions 2.0 through 2.1.7 are susceptible to a problem when a process closes a TCP socket more than once.

This problem only exists on NT (Intel and Alpha) and W9x platforms. The problem occurs as the TCP socket device is closed, it’s receive buffer is deallocated in the process partition but the pointer to it is not cleared.

When the socket is subsequently opened and closed again, the errant pointer may corrupt the process symbol table structure. Since the nature of the corruption is not predictable, the affected process may crash with a Dr. Watson or enter a tight spinloop and consume the CPU.

The only reliable workaround is to initiate a new process when reusing a TCP socket, if possible. This is corrected by LFT683, which is included in Caché 3.1 and higher. It is also available upon request.


January 20, 1999 – Write-Image Journal Recovery May Cause Database Corruption on NT Platforms

InterSystems has identified and corrected a serious problem in Caché releases prior to 2.1.6-build30. This problem exists only on NT platforms. The problem will occur if the Write-Image Journal recovery mechanism is activated upon startup and it recovers blocks which were stored beyond 4GB in a CACHE.DAT or CACHE.EXT. For further clarification, a CACHE.DAT or CACHE.EXT must be greater than 4GB in size and only blocks restored beyond the 4GB threshold will be restored in the wrong location. WIJ recovery only occurs if the system crashes or Caché is forced down while database updates are occuring.

We recommend that all NT sites check if any CACHE.DAT or CACHE.EXT files are greater that 4GB (5242 maps) in size. Evidence of WIJ recovery, including restored block information, may be found in cconsole.log.

The correction, identified as LFT648, will be made available in Caché 2.1.6-build30, 2.1.7 (NT only) for supported customers by contacting InterSystems Support at:
617.621.0700 | support@intersystems.com