 |
 |
|
|
 |
|
| Support Support News Flash2003, 2002, 2001, 2000, 1999 , 1998, 1997, 1996Support News Flash for 1997
Users of an optional DSM routine called SATCHKN
The supplementary routine SATCHKN, was produced to prevent such hangs from occurring and could be optionally implemented by DSM users. The routine was never part of the standard DSM distribution kit and could only be obtained by being downloaded from Digital's Support databases or on contacting Digital's Customer Support Centers. Several DSM sites are known to have implemented this routine. The SATCHKN routine works satisfactorily on all releases of DSM between V6.0 and V6.4A inclusive. However, if the routine is used on versions of DSM above and including V6.5, unpredictable problems may occur (for example phantom DKOVER errors). Therefore the routine as previously supplied must NOT be used on versions of DSM above and including V6.5. A new version of the SATCHKN routine has now been produced and made available by InterSystems which has been designed to work correctly on ALL versions of DSM for OpenVMS between V6.0 and V7.0 inclusive. The new SATCHKN routine can be downloaded from our FTP site or can be obtained by contacting the Worldwide Response Center. Below is a brief technical description of the overall issue For each volume set mounted by a DSM environment, a bitmap is maintained of maps that have zero free blocks available in them. This bitmap is used when allocating a new block so that fully allocated map blocks are not constantly read. When a DSM environment is first started, the bitmap is initially set to indicate that all maps may contain free blocks. This bitmap gets updated as blocks are allocated to reflect a maps true state. When volume sets contain very large spans of entirely used maps, some initial allocates can take several minutes to scan the map blocks, searching for free blocks. This can cause the DSM environment to hang for this entire period as the map blocks are read in and the bitmaps are updated. Once the bitmaps are updated, further such hangs do not occur. The SATCHKN routine can be optionally executed after a DSM environment is first started up inorder to validate the bitmaps before any allocations are required, hence preventing such system hangs from occurring. How to obtain the IP address of the Client using the M Initialization Code in Relational Server It is possible to obtain the IP address of the client connected to the Relational Server in F.11 and F.12 version of the Cache' RDBMS. In the "M Initialization Code" field of the "System Defaults" form of the "Server Management" insert: D ^%ZLogCliId Then create a new routine:
%ZLogCliId ;
N zio,res,i,ip
S $ZT="Err"
S ip=""
S zio=$IO
U 0 S res=$ZU(111,0)
U zio
F i=1:1:3 S ip=ip_$A($E(res,i))_"."
; The following line Logs the IP address in ^%ZCliId($J)
S ^%ZCliId($J)=ip_$A($E(res,4))
Q
Err S $zt=""
U zio
Q
You may modify this program to suit your application. December 1, 1997DSM 7.0 Announcement Update
Update concerning DSM ^FIX Utility handling of globals with string length of 256 to 512 characters.
There is now an improved version of ^FIX available that makes it possible to perform these repairs. To obtain these changes, please download them from: ftp://ftp.intersys.com/pub/openm/dsm/fixfix.txt The file is in ^%RS format, and can be loaded with ^%RR. It will replace the routines named FIXDATA, FIXDAT1, and FIXPTR1. A documentation containing suggestions and limitations is also available. To obtain the documentation, please download from: ftp://ftp.intersys.com/pub/openm/dsm/dsmfixfix.doc Database repair is a complex operation that should be attempted only after one has a thorough understanding of the details of the database structure. We encouraged you to seek help from InterSystems whenever a database repair is necessary. License Server or Bootloader issues with Windows 95
If you are using Win95 and are only using a Dialup Adapter, you may expierence the following issues: Download Caché Utilities
If you are a licensed Caché user, and would like to have access to this, please send a message to our Worldwide Response Center at In your request, please include Your Name: Please note: We will post useful Caché-only utilities and patches in this area. Limitations in the use of the ^FIX utility on DSM volumesets with expanded string length support enabled.
Users of DSM configurations that incorporate volume sets with expanded string length support, should be aware of limitations that restrict the effectiveness of the ^FIX utility to perform database repairs on such volume sets. Specifically, the ^FIX utility currently cannot be used to manipulate the global structure extensions used to support expanded globals, i.e. globals consisting of more than 255 bytes of data. InterSystems plans to address this restriction in a future release of DSM. Intersystems recommends that DSM users currently utilizing expanded string length support protect their databases from degradation by implementing Before Image Journaling (BIJ) for each database set. Use of Before Image Journaling reduces the risk of block-level database corruption and, with After Image Journaling (AIJ) and a thorough BACKUP regime, greatly reduces the risk of database degradation in any DSM configuration thereby reducing the overall likelyhood of needing to use the ^FIX utility to recover from database corruption. This is most important with regard to databases using expanded global string lengths, as ^FIX currently may be limited in it's usefulness in repairing such databases. If you are in any way concerned with the limitations discussed in this article, or require further clarification on how they could possibly effect you, then please contact InterSystems World Wide Response Center for further advice. Background: DSM provides support for expanded string length globals by internally appending special control characters to the subscripts of certain expanded nodes, these control characters are transparent to DSM applications, but internally guarantee sequential collation. An expanded string global can consist of up to three such related nodes which make up the expanded string node, these nodes are given the term `composite nodes'. DSM uses this sequential collation behaviour and strips off such control characters when returning data to applications to provide transparent support for data nodes of up to 512 bytes. It is therefore quite possible that the first subscript of a DSM database data block may contain the second or third part of such a composite node (i.e. a subscript that contains a special control characters). Such a subscript may be identified by using the ^FIX utility to list out a data block and seeing output similar to the following:
OFFSET: x RIGHT LINK POINTER: x:Sx
0: GLOBAL("SUBSCRIPT","") = "DATA"
.
.
.
The "" represents the special control character.
The ^FIX utility does not currently allow you insert pointers into
pointer blocks that contain subscripts with such control characters,
which can therefore limit the utilities effectiveness in repairing
certain types of degradation. Other limitations may also become apparent
when dealing with such globals.
September 12, 1997
Beta level support of DigiPort C/X
This software can be found in a self decompressing ZIP file, available with Anonymous ftp. It can be obtained at: ftp://ftp.intersys.com/pub/openm/dtm/65dos/DIGICX65.EXE Instructions on how to install and use this software can be found in a READ.ME file contained in the ZIP (.EXE) file. F.11 build for DSM
o "urconv.dsm" u "urconv.dsm" r line x line After loading this routine you should be able to run all^%urconv without getting a noline error. August 25, 1997 Full Screen Editor (Open M[ISM] version 6.3) does not correctly
save .MAC sources in some cases.
For Open M[ISM] 6.3 %rde.int To install the patch, download /pub/openm/ism/unix/rde63f11.romf,
and in the Manager's Directory, use the %RIMF utility to install
the replacement object routines For Open M [ISM] 6.x, OPEN M NEXTGEN 7.x, Caché 2.x
versions which use DBMS F.11 %rde.int To install the patch, download /pub/openm/ism/unix/rdef11ism.ro,
and in the Manager's Directory, use the %RI utility to install and
compile the replacement routines. For Open M[DSM] all versions which use DBMS F.11 %rde.int To install the patch, download /pub/openm/dsm/rdef11dsm.ro
into the Manager's UCI. Install the routines by opening
the file and executing the header (first line) of the file. For example: s file="rdef11dsm.ro" o file u file r hdr x hdr c file Caché 2.0 Correction for Thin Client License Management
ftp://ftp.intersys.com/pub/visualm/mvblic_nt.enc
and ftp://ftp.intersys.com/pub/visualm/mvblic.enc
You may load this file by typing DO rload^%encrypt("mvblic_nt.enc") in the %SYS namespace. This problem is corrected permanently in Caché 2.1.
DDP Packets May Crash VMS
Additional changes to Open M[ISM] Incremental Backup Users who have previously downloaded and installed new copies of DBACKA and HIGH32 on Open M[ISM] 5.10, Open M[ISM] 6.1, or Open M[ISM] 6.2 rel-01 or rel-02 (but not rel-03) have continued to notice occasional corruption of data blocks that lie in the last 32 of each group of 65536 blocks after a restore from an incremental backup. The problem results when copies of the bitmaps used to drive backups are incomplete, and as a result, blocks in the above ranges are not backed up during the incremental backup. A correction has been made to fix this problem. Users can obtain the new version from InterSystems ftp site ftp.intersys.com. The new versions of the software are available in the following locations: For Open M[ISM]5.10 on all Unix platforms: For Open M[ISM]6.1, 6.2 rel-01 or rel-02 on all Unix platforms: For Open M[ISM]5.10 on AlphaVMS platform: For Open M[ISM]6.1, 6.2 rel-01 or rel-02 on AlphaVMS platform: Change to Open M[ISM] BACKUP and DBREST utilities. On systems running Open M[ISM] 6.1 or 6.2, the BACKUP utility corrupts the active NAMESP translations. This problem is especially noticeable on Digital ALPHA systems. Although the problem is not usually noticed on other platforms, it is present on all hardware platforms. In revision 6.1, a counter was added to Open M to keep track of buffers when performing multivolume backups. Resetting the count overwrites part of the system common data area. Updated copies of DBACK.INT and DBREST1.INT containing an change to fix this problem are available on the InterSystems ftp site in ftp.intersys.com/pub/openm/ism/unix/dback6x.ro. DSM RTHIST and PMF utilities provide incorrect response time histogram Two errors have been discovered in RTHIST and PMF that cause both utilities to provide incorrect response time histograms. The first error is a roundoff error, which causes the total time reported for all responses to be 25/10000 ths of a second too small on average for each event reported. The second is a binning error. It causes events to be recorded in the wrong bin of the histogram. Both problems will be fixed in a future revision of DSM. Important Alpha/VMS patch for users of Open M[ISM] When setting a global node equal to a string value with fourteen (14) to thirty (30) bytes, users have occasionally observed instances when four consecutive bytes of the data are lost. This can occur on Alpha/VMS systems if another process uses the RT device and causes an incomplete I/O to be handled by the operating system at the same time the global node is being set. The problem has been traced to a failure to correctly save and restore R9/R10 in SYS$CTDRIVER. Digital has announced that a patch for Alpha/VMS is available to fix this problem. InterSystems recommends that users install this patch to avoid data corruption that can occur. Information about the patch is available on the Digital web site www.digital.com. Please look at Training & Services, Software Patches. There are three patches, corresponding to VMS versions 6.1, 6.2, and 7.0, named ALPRTPA01-061, ALPRTPA01-062, and ALPRTPA01-070. Other subsequent versions of VMS already include the change.
BIJ (Before Image journalling) file full BIJ (Before Image journalling) file full can cause loss of data This problem has been observed in DSM 6.4A and is believed to affect
all more recent versions. It has not been determined if earlier
versions are at risk. A workaround is provided The Problem: A customer recently experienced a loss of data due to a BIJ file which was to small to handle the volume of work being done. A process doing a large global copy received an glsinternal error, and did a register dump to the screen. It failed to exit DSM and run down the configuration as it should have and instead remained in a tight loop eating CPU time. Work was able to continue but later on the write demon was STOP/ID'd to bring down the configuration and free up the looping process. When the environment was restarted recovery occurred as it should have but the BIJ roll backs were much larger than normally would have been expected. It was noticed that in volume sets where AIJ (After Image Journalling) was not implemented data was missing. In one volume set data was missing back to the point where the glsinternal error had occurred which meant the entire day. The volume sets with missing data were not where the glsinternal error had occurred. InterSystems has recreated the problem on our internal machines
and are working on a fix. The Workaround: In order to protect against data loss, you are STRONGLY RECOMMENDED
to implement AIJ on any volume set which contains important data.
AIJ will be rolled forward during normal recovery and restore any
data that BIJ has rolled back. Also find below information on proper BIJ sizing: You are using Before Image Journalling (and you should be). Analysis: Before Image Journal files that are too small can degrade the performance of a VAXDSM database. VAXDSM incurs significant overhead whenever the BIJ cache is checkpointed (written to disk). Therefore, you want to make the BIJ file big enough so that only the system is responsible for the checkpointing when the BIJ checkpoint timer runs down. Normally the checkpoint timer fires approximately every 3 minutes, however a checkpoint can occur prematurely if the BIJ file becomes full. When the BIJ file becomes full, the BIJ cache must be flushed so that the BIJ file can be reused from the beginning. The number of blocks needed in the BIJ file is determined by the number of blocks that are modified during a volume seize. As it turns out, the average number of blocks per transaction is 6 (5 + 1 "termination" block). Solution: Therefore the formula for determining the size of a BIJ file is:
BIJ file size (in DSM blocks) = seizes_per_sec *
blocks_modified_per_seize (6) *
checkpoint_time (60_seconds*3_minutes) *
cluster_members + 4000.
The only difficult parameter to determine in this formula is the number of seizes_per_sec. To obtain this value, run MONITOR^GLSSTA on your busiest system at the busiest time. Even then, this is the TOTAL number of seizes. To get the number for a specific volume set you have to approximate what proportion to attribute to each volume set. The safest method is to just use the number ^GLSSTA gives you and call it overkill. It's up to you. The cluster_members parameter is used because ^GLSSTA only shows you seizes on the current node. The 4000 at the end of the formula is for the effective end of file which is 4000 DSM blocks less than the allocated amount (so that even a very large KILL will fit in the BIJ file). So, for example, lets say you have 3 systems, all doing 5 seizes a second. The BIJ file size (in DSM Blocks) should be:
size = seizes_per_sec * blocks_modified_per_seize (6) *
60_seconds * 3_minutes * cluster_members + 4000.
= 5 * 6 * 60 * 3 * 3 + 4000
= 20,200 DSM BLOCKS.
= 40,400 VMS blocks.
This is probably conservative (ie., slightly larger than it needs
to be), but probably not unreasonable.
June 20, 1997 A new version of Open M/WebLink is now available. This version (2.00.248) contains several bug fixes. It is very important to upgrade from build 247 to build 248. Build 247 was compiled with a wrong switch setting resulting in a performance defect. This has been corrected in build 248. Versions for Netscape and Microsoft web servers on NT (Intel & Alpha), Windows 95 and Netscape UNIX based web servers are currently available from our web site at: http://www.intersys.com/m-weblink Any current users of the M/WebLink product version 2.0 should upgrade to this version 2.00.248. Current owners of Open M/WebLink licenses should contact their InterSystems account representitive for information upgrading their license. Contact information is available at http://www.intersys.com/contactus/index.html June 4, 1997 There is a possibility of label re-def errors on Open M F.10 servers while using MS Access. If Access is using the Jet engine, frequently a query similar to the following is sent
select fld_a, fld_b, fld_c from table where rowid = :1 or rowid = :2 or rowid = :3 or rowid = :5 or rowid = :6 or rowid = :7 or rowid = :8 or rowid = :9 or rowid = :10 This may very likely cause a label re-def error trying to compile on the server. The problem described above has been corrected in future versions and is available for F.10 systems via the InterSystems ftp server in ftp://ftp.intersys.com/pub/dbms. The file is named f10pk6497a.wnt and is loadable using %RI. It contains two routines that should be loaded into the manager's directory. If you have experienced this problem and are loading the file,
it is imperative that all stored procedures are deleted before re-running
any queries after loading the file.
June 3, 1997 I am pleased to announce that InterSystems now has a new web page, called Documentation Action Form, to allow you to send direct feedback to our Documentation department. This form will accept comments on all of our documentation, printed books, CD, on-line help, and web based. Access to this page is through the following link: http://www.intersys.com/contactus/doc_action_form.html I encourage you to use the form whenever you encounter an issue with the documentation - it is the fastest and most direct method of reaching us for corrections to documentation issues. Additionally, starting with the April 1997 printing of the Technical Information CD, an integrated search function has been incorporated in to the CD. This highly useful functionality should enable you locate information quicker and easier. If you are interested in the April 1997 Technical Information CD, please contact our Order Processing department at orderproc@intersys.com or your InterSystems salesperson for more information.
F.9 and F.10 view definition An issue with the view definition form has been corrected. In F.9 and F.10 if you have a table appear more than once in a view any field that was selected the first time the table was add will not be shown the second time. The file, viewfx.* found in ftp://ftp.intersys.com/pub/dbms on the ftp server can be used to correct this problem. The file contains one % routine that should be loaded into the managers directory. After loading this routine all the fields should be displayed for both entries of the table. If the operating system you need is not on the ftp server please contact InterSystems Technical Support at support@intersys.com or (617) 621-0700. May 5, 1997
This problem occurs when attempting to use repair to INSERT a global
node using the REPAIR utility. The News Flash of February 28 provides
a way to modify the REPAIR utility to allow it to correctly insert
new nodes collated as either new ANSI or old ANSI, but only one
or the other is allowed. To receive the fix, download REP1U62INT.RO from ftp://ftp.intersys.com/pub/openm/ism/unix. April 2, 1997
$JOB is used for only one process while one journal file is active. Only one journal file at a time is recovered. No network (non-local) processes make changes to the datasets. Detail: %jrecover only recognizes incomplete transactions when recovering one and only one journal file. In effect, the program stops paying attention to transactions when more than one journal file is recovered at the same time. %jrecover does not account for processes stopping and the job number being reused. The information needed for this is currently unavailable in the journal file. %jrecover cannot identify different client processes for transactions. Transactions are tracked by job number. The journal file records datasets changes using the job number of the local process making the change. Because all network activity appears as a local activity of the network process, the only job number recorded in the journal file for transactions from clients will be the network process job number. March 28, 1997 Open M [ISM] releases 5.10 through 6.2-F.9 and NextGen 7.0.x have
an unenforced journal file limit of 2.0GB. Journal entry addresses
beyond 2.0GB will appear as large negative integers which will then
impede proper journal file restoration. Example: If a journal file exceeds 2.0GB and Open M is stopped
abnormally, by mforce for example, a complete journal restore can
occur during mstart resulting in hours of journal file restoration.
This is a result of large negative journal file address store in
the write-image-journal file that points to the last valid journal
entry. Furthermore, the journal restoration will stop at 2.0GB without
reporting any errors. A correction which enforces the journal file limit of 2.0GB is
available, upon request. This correction will stop journalling when
the file reaches 2.0GB and alert the operator to switch to a new
journal. The next planned maintenance release, Open M [ISM] 6.3-F.10,
will include this correction and possibly increase the enforced
limit to 4GB. This problem does not exist the imminent release of
NextGen 2.0 which has an automated journal rollover capability. There are several acceptable approaches, listed in order of preference,
to avoid problems that may result from this unenforced limitation. February 28, 1997 A serious problem exists with the REPAIR Utility under Open M[ISM] 6.1 and Open M[ISM] 6.2 (all releases). This problem is NOT present in Open M[ISM] 5.10 or in any previous release. Any attempt to use the REPAIR utility to do an Insert of a Node
to a Global of Collation Type 1 with Numeric Index or Indices, will
result in an error. The internal representation of the Node is miscalculated,
causing it to collate incorrectly. Users should avoid any attempt
to perform such an operation using the REPAIR Utility under Open
M[ISM] 6.1 or Open M[ISM] 6.2. Four conditions are necessary for this problem to occur: Users who wish to may fix this problem by editing the routine
REPAIR1.INT as follows: Replace the two lines: INA I +A=A,NCOL G INNEG:A<0 S B=$S(A="0":1,A<1:2,1:$L($P(A,".",1))+1) February 25, 1997
A copy of the workaround specific to Alpha/VMS is now available
to work in conjunction with Rev 6.1. You can obtain the workaround
for UNIX or Alpha/VMS systems by downloading from the locations
indicated below. For Rev 5.10 UNIX -- ftp://ftp.intersys.com/pub/openm/ism/unix/bkpfx510.ro
For Rev 6.1 UNIX -- ftp://ftp.intersys.com/pub/openm/ism/unix/bkpfx61.ro
For Rev 6.1 Alpha/VMS -- ftp://ftp.intersys.com/pub/openm/ism/unix/vbkpfx61.ro
(Note: You may need to press the shift key while clicking on the
above links to perform a "save as" function to save the
.ro files on your local disk.)
February 25, 1997
The utility can be downloaded from the InterSystems FTP Server.
Look in the locations described below, and download the .RO files.
For Open M[ISM] Rev 6.1 for UNIX --
ftp://ftp.intersys.com/pub/openm/ism/unix/vollabel.ro For Open M[ISM] Rev 6.1 for Alpha/VMS --
ftp://ftp.intersys.com/pub/openm/ism/unix/vmslabel.ro The utility is invoked as follows: D ^VOLLABEL The utility prompts for the name of the file or device that you
wish to examine. The utility displays all available volume label
data, which includes: February 25, 1997
February 25, 1997
January 17, 1997
Users who attempted to install and run the previous workaround
encountered additional problems if the database they attempted to
back up exceeded 131040 blocks. A new workaround is now available to work in conjunction with
Rev 5.10 and Rev 6.1. You can obtain the workaround by downloading
from the locations indicated below. For Rev 5.10 - ftp://ftp.intersys.com/pub/openm/ism/unix/bkpfx510.ro
For Rev 6.1 - ftp://ftp.intersys.com/pub/openm/ism/unix/bkpfx61.ro
(Note: You may need to press the shift key while clicking on the
above links to perform a "save as" function to save the
.ro files on your local disk.)
Home | M Technologies | Support | Company | Contact ©
Copyright 1996-2000 InterSystems Corporation. All Rights Reserved. |