Support News Flash

Support News Flash for 2002

November 6, 2002 – DSM DDP use can cause VMS Crash

An architectural limitation has been encountered in DSM that can cause OpenVMS to crash. This is a potential problem for any version of DSM. This limitation affects DSM on both VAX and Alpha systems.

It is possible to ensure that a VMS crash does not occur through configuration parameters and a detailed discussion follows including specific instructions for avoiding a crash of VMS.

InterSystems is not planning to redesign the DDP driver to raise this limit but investigations are underway to modify the configuration tools to prevent the limit from being exceeded.

Discussion:

The DSM DDP driver DSM$AADRIVER uses a structure known as a Connection Block or CNB to describe each DSM environment on a given VMS node. The CNB comprises a fixed portion and two variable length tables, one of which varies in size with the number of Global Vectors used to service remote DDP requests and the second of which varies with the number of DSM users allowed in a configuration, i.e. local users. Due to implementation constraints the DSM CNB is sufficient to support 1,544 local users on each node in an environment given the default of 255 Global Vectors used to service incoming requests.

Exceeding this limit almost always causes a VMS crash, usually an INVEXCEPTN, Exception while above ASTDEL, but also, less often, a PGFIPLHI, Page fault with IPL too high.

The vast majority of DSM environments will only be at risk from system crashes, as described in this article, if they are configured to use DDP and have the value in their running configuration for the "maximum number of users" set to a value greater than 1544. Note: it does not matter if your actual process count never approaches 1544, what is important is what is configured.

This limitation applies on a per configuration per DSM environment basis.

Example 1:
1544 users in environment XXX and 1544 users in environment YYY on the same VMS node will not trigger the problem.

Example 2:
1544 users in environment XXX on VMS node A and 1544 users in environment XXX on VMS node B will not cause the problem.

Example 3:
1545 users in environment XXX on VMS node A can cause the problem.

To precisely determine if your currently running DSM environment is at risk from the problem described in this article, perform the following steps:

Log in to VMS as the DSM environment manager and from DCL, type "DSM/MAN" to enter your currently running DSM environment in manager mode. At the DSM prompt, enter the following:

D CHKDDP^%SYSROU

If this returns the message "DDP is not currently configured", then your current environment is not at risk. If no message is returned, then it means your current environment is using DDP and you therefore need to enter the following code exactly as shown:

W ^[LIB]SYS(ID,"USERS")

This will return the maximum number of DSM users your currently running configuration is configured for.

Now enter the following code:

W 63851-((^[LIB]SYS(ID,"DDP","GLOBAL VECTORS")+1)*8)\40-1

This will return the maximum number of DSM users that it is safe to define as the maximum value for your current configuration (in most cases, this value will be 1544).

If in the above steps, the first value returned is greater then the second, then your DSM environment will suffer from the problem outlined in this article and you need to take appropriate action to reduce the DSM configurations "Maximum number of users". This can be performed via the ^CONOPT utility and you should set the value to no more than the second value returned in the above steps (usually1544). You will also need to restart DSM for the change to take effect.

Below is an example of the steps outlined above

$ DSM/MAN
DSM Vx.x for OpenVMS AXP
DSMMGR
[MGR,GER]

>D CHKDDP^%SYSROU

>W ^[LIB]SYS(ID,"USERS")
2000
>W 63851-((^[LIB]SYS(ID,"DDP","GLOBAL VECTORS")+1)*8)\40-1
1544
>

As can be seen in this example, the first value is greater then the second, so this configuration is susceptible to problems.

You may contact InterSystems Worldwide Response Center at support@intersystems.com if you require more information about this advisory.

October 31, 2002 – DSM, Missing After Image Journal Records

InterSystems has fixed a problem with DSM which can cause missing After Image Journal (AIJ) records. This problem affects all versions of DSM. The problem is limited to mulit-CPU OpenVMS systems, single CPU systems are not at risk.

On DSM systems, typically under heavy loading, it is possible on rare occasions for individual “Set” or “Kill” transactions that should be written to an AIJ file, to be skipped. Tests have shown that this typically affects less than one record per million. In all other respects, affected after image journal files appear normal and can be dejournaled using standard utilities.

If the need arises to recreate a DSM database using AIJ files this problem could result in missing global nodes in the recreated database.

A change identified as EHB008D has been created to correct this problem.

Kits containing this fix are available for DSM 7.2.1 and DSM 7.3. These kits also contain the fix for the problem documented in the alert from February 12, 2002 – “Potential Problems with DSM Configurations that make use of DCP”. In addition the DSM 7.3 kit contains the fix for the problem documented in the alert from September 5, 2002 – “DSM 7.3 Runaway process problem”

The new kits, along with installation notes (approx 84 Mbytes in size) can be requested from the InterSystems Worldwide Response Center (WRC). The preferred method of delivery will be to place a VMS save set in a customer specific directory on the InterSystems FTP server. The WRC can help with directory and password info if required. The save set name names are:

DSMV73_AH1.SAV
DSMV721_AH1.SAV

Important:
Please note, a kit on the ftp server is in the form of an OpenVMS backup saveset and should be FTPed in Binary/Image mode onto an OpenVMS system. The file is stored on our FTP site with a logical record length of 512 bytes to ensure a successful download. Once the file has been FTPed to a VMS system, please issue the following command to restore the files original logical record size.

$ SET FILE DSMV73_AH1.SAV/ATTR=LRL=32256

Performing the above will ensure that the OpenVMS BACKUP utility will recognize the file format. Once the kit has then been restored via the OpenVMS backup utility, please read the file *_README.TXT for installation notes.

Once installed successfully, the kit can be identified as follows:

>W $ZV
VAX DSM V7.3 +AH1

> W $ZV
VAX DSM 7.2.1 +AH1

Please note, as with all current versions of DSM, the string returned always includes the word VAX, whether installed on a VAX or Alpha platform, for backward compatibility reasons.

You may contact InterSystems Worldwide Response Center at support@intersystems.com if you require more information about this advisory.

September 5, 2002 - DSM 7.3 Runaway process problem

InterSystems has recently identified & fixed a problem that exists with the standard DSM 7.3 release. The problem, which only affects DSM 7.3, has the potential of causing runaway processes and also DSM environment hangs.

A change referred to as MEB071D was introduced into DSM V7.3 to correct a problem that could occasionally occur when a process tried to enter DSM baseline mode after a previous DSM environment shutdown. Unfortunately this change could cause runaway processes and hung environments to occur more frequently than the problem it was originally designed to resolve.

InterSystems have now produced a DSM 7.3 kit, which removes the MEB071D change as a solution to the issue. The kit also contains the fix for the problem of using DCP with DSM as documented in the Feb. 12, 2002 newsflash “Potential Problems with DSM Configurations that make use of DCP”. Please note, in regards to the DCP issue, RFD022D has superseded RFD021D. RFD021D was valid for Alpha systems only.

The new DSM V7.3 kit, along with installation notes (approx 84 Mbytes in size) can be requested from the InterSystems Worldwide Response Center (WRC). The preferred method of delivery will be to place a VMS save set in a customer specific directory on the InterSystems FTP server. The WRC can help with directory and password info if required. The save set name is DSMV73_RFD022_NOMEB071.SAV

Important:
Please note, the kit is in the form of an OpenVMS backup saveset and should be FTPed in Binary/Image mode onto an OpenVMS system. The file is stored on our FTP site with a logical record length of 512 bytes to ensure a successful download. Once the file has been FTPed to a VMS system, please issue the following command to restore the files original logical record size.

$ SET FILE DSMV73_RFD022_NOMEB071.SAV/ATTR=LRL=32256

Performing the above will ensure that the OpenVMS BACKUP utility will recognize the file format. Once the kit has then been restored via the OpenVMS backup utility, please read the file DSMV73_RFD022_NOMEB071_README.TXT for installation notes.

Once installed successfully, the kit can be identified as follows:

>W $ZV
VAX DSM V7.3 +RFD022,-MEB071

Please note, as with all current versions of DSM, the string returned always includes the word VAX, whether installed on a VAX or Alpha platform, for backward compatibility reasons.

You may contact InterSystems Worldwide Response Center at support@intersystems.com if you require more information about this advisory.

February 12, 2002 - Potential Problems with DSM Configurations that make use of DCP

InterSystems has recently discovered a potential problem that can arise with all versions of DSM that are configured to make use of DCP (Distributed Cache Protocol).

The problem occurs when DCP and DSM data structures (global sections) inadvertently overlap in memory. Many parameters in your DSM configuration determine if your DSM environment is susceptible to this problem, for example, the number of DSM disk buffers & volume sets defined have a direct influence.

The following simple DSM code can be typed in at the DSM prompt to check if your currently running configuration is susceptible to problems:

> W $V($ZK(GLS$SMSTART)+4)

If the value returned by this code is greater than "67,108,863" AND your DSM environment is configured to use DCP, then your configuration is susceptible to problems and we recommend that you contact InterSystems WRC for further advice.

Examples of possible problems that can occur, include, but are not restricted to:

- DSM applications reporting "phantom" database degradation errors
- Cache' to DSM DCP links intermittently failing.

The fix for this problem is referenced as "Dev change RFD021D" and a DSM V7.2.1 adhoc kit is currently available from InterSystems that corrects this problem. Adhocs for other versions of DSM can be produced as and when required.

Please contact InterSystems Worldwide Response Center support@intersystems.com or +1.617.621.0600 if you require any further information about this notice

January 11, 2002 - Information regarding the use of DSM V7.3 & DASL

This newsflash provides information primarily for the attention of DSM sites that intend to install or upgrade to DSM V7.3 and make use of DASL (DSM Application Software Library) software. It may also be useful for DSM sites that have developed applications that use an unsupported technique of checking for DSM qualifiers by $VIEWing DSM's JSTAT_L_OPTION bit mask.

DASL makes use of the following code to check if a user has entered DSM with the /DASL_CUSTOMIZE qualifier.

$V($ZK(JSTAT_L_OPTION))\$ZK(JSO_M_DASL)#2

Starting with DSM V7.3, all 32 bits in the JSTAT_L_OPTION longword bitmask can now be allocated by DSM qualifiers, which can potentially result in the $VIEW command used in the above code returning a negative number and hence resulting in the overall code returning an incorrect result. The code should be replaced with the following, which will always result in the $VIEW command returning an unsigned Integer, which can then be processed correctly by the rest of the command and will always return correct results.

$V($ZK(JSTAT_L_OPTION),-1,0)\$ZK(JSO_M_DASL)#2

The above code sample can be found in the following two standard DASL routines:

%DARPDRV+425
. I $V($ZK(JSTAT_L_OPTION))\$ZK(JSO_M_DASL)#2 S X=X_"/DASL_CUSTOMIZE"

Replace the code with

. I $V($ZK(JSTAT_L_OPTION),-1,0)\$ZK(JSO_M_DASL)#2 S X=X_"/DASL_CUSTOMIZE"

and

%DAZCALL+60
I $$VERSION^%DAZCALL["OpenVMS" Q $V($ZK(JSTAT_L_OPTION))\$ZK(JSO_M_DASL)#2

Replace the code with

I $$VERSION^%DAZCALL["OpenVMS" Q $V($ZK(JSTAT_L_OPTION),-1,0)\$ZK(JSO_M_DASL)#2

All supported DSM utilities supplied with DSM V7.3 (such as %SYSUTL) already take account of this internal change and hence work correctly. However, Some sites may use a variation of the above code in their own software to check for particular DSM qualifiers of interest to them and should therefore also consider making similar changes where necessary to their software.

The following example demonstrates the use of the original & new code, with the differing results.

$DSM/DASL_CUSTOMIZE

DSM V7.3 for OpenVMS AXP
SYSTEM
[Baseline]

>W $V($ZK(JSTAT_L_OPTION))\$ZK(JSO_M_DASL)#2

0 (This value returned by the original code is incorrect)

>W $V($ZK(JSTAT_L_OPTION),-1,0)\$ZK(JSO_M_DASL)#2

1 (This value returned with the new code is correct)

Please note - InterSystems discontinued providing support for DASL on the 31-Dec-1997.

If you have any questions, please contact the InterSystems Worldwide Response Center at 617.621.0600 or support@intersys.com.

Home | M Technologies | Support | Company | Contact

MOVE TO CACHÉ

© Copyright 1996-2000 InterSystems Corporation. All Rights Reserved.
email: wwwadmin@intersys.com