Home

M Technologies

Support

	Overview
	WRC
	FAQs and Related Materials
	Documentation
	Educational Catalog
	User Groups

Company

Contact

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 2000

October 19, 2000 - ^INTEGRIT and the Control Panel's Integrity Check

A problem was discovered in ^INTEGRIT and the Control Panel's Integrity Check where all levels of a global were not being examined. This problem affects ISM and Caché on all platforms. No errors are generated when the problem occurs but you will notice output similar to the below:

Global ^TEMP 
4 Levels in this global 
Level: 1, # ptrs = 41 
Level: 2, # ptrs = 7380, # blks = 41, # ptrs/blk = 180, eff = 89% 
10:58 PM

As you can see, the ^TEMP global is reported to be 4 levels but only 2 levels are examined. InterSystems recommends that you use our ^DIAG utility to check the integrity of your databases. A patch will be available in Caché 4.0 build 110 and later which will warn within ^INTEGRIT and the Control Panel’s Integrity Check when a situation exists where global levels are not being checked. The patch is LFT861 and is available upon request. If you have any questions InterSystems Worldwide Response Center at 617.621.0600 or support@intersys.com.

June 7, 2000 - DSM Small BIJ files slow performance

InterSystems has investigated several performance problems recently that we have traced to undersized BIJ files. Normally DSM flushes the BIJ file every 3 minutes. Should your BIJ file fill due to heavy SETs and KILLs, especially those causing block splits and merges, which will lead extra BIJ file flushes. This will quickly impair performance, and in extreme circumstances will cause an environment run down.

The default size of a BIJ file is 8000 DSM blocks. Many users quickly outgrow this size. InterSystems recommends that you size your BIJ files with this formula:

BIJ_size_in_DSM_blocks = 6 * Peak_Global_Seize_Rate_for_3_min + 4000

Determining the peak global seize rate for a 3 minute period for each volume requires a little work. If you have only one volume or few enough volumes that you are willing to attribute all global seizes to each volume, DO ^GLSSTA on each node in your cluster during a peak usage period. Specify a 180-second (3-minute) period, and ask for statistics ABC (the default). Take the MAX Global Seizes shown, multiply by 180 (for number of seconds per period), and sum results for each node in your cluster.

For more complex configurations, DO ^PMF and schedule a group of collections on all nodes in your cluster (option 2, option 6, or DO ^PMFMON). Use 3-minute collections. Schedule enough collections to cover your peak period. The time needed between collections is enough to allow ^PMF too keep up with whatever performance problems you may already have. Start at 3 to 5 minutes. After the collections run this routine. It will prompt for the first and last collection number taken by ^PMF, a list of which can be obtained with LIST^PMFDAT. Be warned this routine assumes it is working with complete cluster wide 3 minute collections, and doesn't verify those assumptions.

Saved by %RS from [MGR,SYS] on 26-MAY-2000 08:22:48.67
UNSUPPORTED routine to size BIJ files from raw ^PMF data
ZIZEBIJ
ZIZEBIJ	; SRS 25-MAY-2000
	K MAXSV
	R "FIRST COLLECTION: ",FIRST,!
	R "LAST COLLECTION:  ",LAST,!
	F COL=FIRST:1:LAST D
	. K SV
	. S NODE="" F  S NODE=$O(^PMFDAT(COL,NODE)) Q:NODE=""  D
	. . S G="" F  S G=$O(^PMFDAT(COL,NODE,"GLOBALS",G)) Q:G=""  D
	. . . Q:'$D(^PMFDAT(COL,NODE,"GLOBALS",G,2))
	. . . S V=$P(G,",",1),SZ=$P(^PMFDAT(COL,NODE,"GLOBALS",G,2),",",8)
	. . . Q:V=""
	. . . S SV(V)=$G(SV(V))+SZ
	. S V="" F  S V=$O(SV(V)) Q:V=""  D
	. . S:SV(V)>$G(MAXSV(V)) MAXSV(V)=SV(V)
	W "VOLUME",?8,"MAX SEIZE RATE",?25,"RECC MIN BIJ SIZE",!
	S V="" F  S V=$O(MAXSV(V)) Q:V=""  D
	. W V,?8,$J(MAXSV(V)/180,7,2),?25,$J(6*MAXSV(V)+4000,10)," k",!
	Q

Increasing the size of a BIJ file will not lower the global seize rate. You are only increasing the size of the BIJ file to accommodate the global seize rate. You may also wish to explore methods of lowering your global seize rate. You can lower your global seize rate by optimizing you application to SET global nodes in contiguous subscript sort order as much as possible.

You can also split volumes, either by UCI, or removing specific high use globals to their own volumes. Use global translation so that those globals are visible from their original [UCI,VOL], thus avoiding any need to change your applications. You can modify the S V=$P(G,",",1) at line ^ZIZEBIJ+9 to compute the maximum global seize rates for individual UCIs or globals.

March 14, 2000 - Service pack for F.12
InterSystems has a new service pack available for F.12. Below is a list of the changes that have been added. Please contact InterSystems Worldwide Response Center for information on obtaining this service pack.

Changes in F.12 Service Pack 8 Build 002 [04 March 2000]

Add line tag mddcup to %qarsp1 to fix a No Line errors in F12sp7
Fix rare disappearing Computed field problem in M Forms.
Fix MSQL import problems with tables that have exp in MapData
Fix M Pact dates for Y2K
Fix counter problem for M/Pact Data Selection that would prevent you from entering a new Data Selection after doing an import of the report.
Fix No Line errors in Base Table form caused by Service Pack 7.

February 17, 2000 - %datecheck bug in DTM 6.6

InterSystems Customer Support has identified a problem in the DTM utility %datecheck. Dates submitted to %datecheck which are in the 1900 to 1910 range return the wrong $H value. The %datecheck utility is not used by any DTM code, so it can only cause a problem if you are using calls to %datecheck in application code.

This problem is in DTM 6.6 and not in DTM 4.10. A patched version of the routine %datecheck can be found on the ISC ftp server in file ftp://ftp.intersys.com/pub/openm/dtm/DTCHKL66.RSA.

February 15, 2000 - Outer Join Problem with Crystal Reports

InterSystems has identified a minor incompatibility with SeaGate Software Crystal Reports. In the case of an outer join between three tables it is possible that Crystal will generate the wrong SQL code that is passed to the InterSystems ODBC driver. This problem is independent of the version of Caché or SQL Add-On for Open M. Working with Seagate Software we now have a solution.

Symptoms:

If you try to do one outer join from Table A to Table B and a second one from Table A to Table C the generated SQL does not have the correct joins.

Solution:

1. Upgrade Crystal Reports to release 7.

2. Check if the following registry item exists:

HKEY_CURRENT_USER\Software\Seagate Software\Crystal Reports\ Database Options \OuterJoin\

If it does not, download the registry update at ftp://ftp.intersys.com/pub/dbms/outjoin.reg and double-click on the downloaded file to install it. This will set up outer join tailoring options.

3. Modify the string value OpenIngres adding CacheODBC to the value. After editing the string value should look like: "oplodbc, oplodb32,CacheODBC"

4. Bring Crystal Reports down and up again. For existing reports, you must force the SQL to be regenerated.

If you have any questions or problems please contact InterSystems Worldwide Response Center

Home | M Technologies | Support | Company | Contact

MOVE TO CACHÉ

GO TO TOP OF PAGE