|
|
 |
Support
Support News Flash
2003,
2002, 2001,
2000, 1999
, 1998, 1997,
1996
Join our mailing lists and have the News
Flashes emailed to you.
Support News Flash for 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.
-
December 13, 1999 - Kill of
a global node whose key is longer than 127 characters can cause a
crash
- Under certain circumstances a KILL of a global node whose key is
longer than 127 characters can cause MSM Server to crash. This occurs
in MSM 4.4.1 and all previous releases on Windows NT and 95/98, and
DEC Unix, HPUX, and DG-UX. MSM may crash when a KILL affects the first
node in a data block and results in a block split in a pointer block.
It can only occur on a node whose key length is greater than 127 characters.
An ad hoc correction is available upon request by contacting InterSystems'
Worldwide Response Center support@intersys.com.
-
- December 8, 1999 - MSM Database Error Following
A Naked Kill
- A database error may occur in MSM if a MERGE command is followed
by a KILL naked-reference command on the same global. For example:
>MERGE VAR=^["APP","ABC"]GLO(1,2,"t",3)
>KILL ^(3)
This problem may occur on any MSM platform, but does not exist in
versions prior to 4.3.2. This problem may be avoided by changing the
NAKED reference to an EXPLICIT reference (e.g. KILL ^["APP","ABC"]GLO(1,2,"t",3)
rather than KILL ^(3) in the example above). An ad hoc correction
is available upon request by contacting InterSystems' Worldwide Response
Center support@intersys.com.
-
- November 30, 1999 - Y2K Alert for ODBC on
ISM 6.4-F.14
- Please refer to our Y2000
support area for more information on this important alert and
patch.or contact InterSystems Worldwide
Response Center for further information.
-
- 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.
-
- April 5, 1999 - OpenVMS/RMS problem can cause
DSM environment hangs - Workaround and ECO information
- InterSystems & Compaq have identified a problem with RMS on
OpenVMS V6.2 through to V7.2 which can potentially lead to a DSM journal
process hanging, which in turn will generally lead to a complete DSM
environment hang. All DSM versions can be affected by this problem.
The problem can occur when the DSM journal process attempts to
perform certain operations on a DSM environments SYS.GBL file. A
problem with OpenVMS's RMS Index Compression code can cause the
DSM journal process to enter a COMpute bound loop at priority 14,
generally causing the entire DSM environment to hang.
This OpenVMS RMS problem is logged on Compaq's IPMT system as
reference CFS.66857
An ECO to fix this problem within OpenVMS is currently available
for Alpha OpenVMS V6.2 in "ALPRMS03_062" and will also
be made available for other VMS versions in the near future.
It is recommended that the following workaround is implemented
on DSM systems until the appropriate ECO's have been applied. The
workaround involves disabling "Index Compression" on an
environments SYS.GBL file and increasing its AREA 0 bucket size
to a value of 12. This will prevent the problem from occurring.
* Shutdown the DSM environment for which you wish to update the
SYS.GBL file for (Note - each DSM environment has a file called
SYS.GBL in the environment managers directory).
* Take a backup/copy of the SYS.GBL file at the VMS level for
security purposes. You can then revert back to this file if any
problems occur during the conversion of the file.
eg $ COPY SYS.GBL SAVE_SYS.GBL
* Produce a FDL file for the SYS.GBL file by entering the following
command:
$ ANALYZE/RMS/FDL SYS.GBL
This will produce a file called SYS.FDL
* Use a VMS editor to modify the following entries in the SYS.FDL
file if index compression is shown as being enabled and the AREA
0 Bucket size is shown as 2 and save the changes.
KEY 0
INDEX_COMPRESSION yes <==Change this to no.
AREA 0
BUCKET_SIZE 2 <==Change this to 12
* Convert the original SYS.GBL file to a new file using the amended
.FDL file.
$ CONVERT/FDL=SYS.FDL SYS.GBL SYS.GBL
* Do an $ANALYZE/RMS of the new SYS.GBL file and check that the
analysis uncovers no errors. If all the above steps go through with
no problems, then you may wish to delete the original version of
the SYS.GBL file from the environments directory. You can now proceed
to restart your DSM environment.
Please contact InterSystems
World Wide Response Center if this newsflash article requires
any further clarification.
March 26, 1999 - [ISM] Use of ZKILL May Degrade
Integrity
A problem was just corrected where the ZKILL command could result
in either database degradation or in more data being deleted than just
the node ZKILLed. In order for this to occur the node being removed
had to be the 1st node in the block and the descendents of the node
needed to span pointer blocks. If the descendents spanned upper level
pointer blocks, a right link pointer would get set to 8388607 or 16777215
which would turn up as a or a error during a subsequent reference. If
the descendents were limited to spanning bottom level pointers, some
of the descendents would be removed as part of the ZKILL but no physical
degradation would occur.
This problem exists in all versions of [ISM] 5.10-F.4 through 6.4-F.12.
The correction, identified as JO1127, will be included in the next releases
of [ISM]. It is also available as an ad hoc, fully supported, correction
to current releases upon request.
Contact the Worldwide Response Center support@intersys.com for further assistance.
- March 1, 1999 - ISM File Expansion Problem
When The Associated Disk is Full
- All [ISM] 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 in Open
M [ISM] 6.5-F.14 .
- 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@intersys.com.
- March 1, 1999 - License Slots Not Relinquished
in Open M [DSM] 7.0, 7.1
-
The Worldwide Response Center (WRC) recently identified a problem
in [DSM] process termination in which a process may fail to relinquish
it's license slot for reuse. This is reported as a "License
Limit Exceeded" message when trying to start additional processes
when license slots should be available. This problem only exist
in [DSM] 7.0 and 7.1.
When a DSM process exits abnormally the license slot which was
allocated to it is not returned to the licensed process count. Abnormal
process termination occurs in such cases as a terminal being turned
off before exiting DSM or a DSM environment crashes in a multiple
environment system.
This problem is addressed in DSM 7.2. The correction is also available
for [DSM] 7.1, upon request.
- January 14, 1999 - InterJob Communication
Device Problems May Lead to Hang
- In [ISM] for Unix releases through 6.4-F.12 and in Caché
for NT and Unix releases through 2.1.6, a process may fail to release
ownership of its exclusively owned resource(s) prior to a READ on
an IJC device. This may result in a hang if the READ fails to complete
and another process attempts to acquire exclusive ownership. This
problem is corrected in future releases of [ISM] and Caché
and it is available upon request from the WRC.
The correction is identified as LFT671. This is not applicable for
Open VMS platforms.
Home
| M Technologies | Support
| Company | Contact
MOVE
TO CACHÉ
©
Copyright 1996-2000 InterSystems Corporation. All Rights Reserved.
email: wwwadmin@intersys.com
|
