HP OpenVMS Systems Documentation

HP DECwindows Motif for OpenVMS
Release Notes

V1.3

On New Desktop systems, access to DECwindows Motif can be granted to a predefined set of users by specifying values to the *hostList and *numHosts resources in either the SYS.RESOURCES or DT.RESOURCES file. The *hostList resource specifies the users (by host name or address) who are allowed access, and the *numHosts resource specifies the total number of users in the list.

Typically, these resources are modified automatically when you implement or make changes to user-based security via the Session Manager. However, if you maintain the user-based access lists by modifying *hostList manually, be sure to also set *numHost to the appropriate value.

For additional information on defining global and system level resources, see the Getting Started With the New Desktop manual. For further information on enabling access control, see the Managing DECwindows Motif for OpenVMS Systems manual.

3.3.4 Unknown Code Error Displayed When Enabling Kerberos

V1.3

If the Kerberos logical (KRB$ROOT) has not been set properly, the following error is displayed when you attempt to enable Kerberos from either the DECwindows Motif desktop or the DCL command line using KINIT:

"Unknown code 6 while initializing krb5"

To correct this problem, reconfigure the Kerberos for OpenVMS Security Client software as described in the Kerberos for OpenVMS Installation Guide and Release Notes available from the OpenVMS web site (http://www.hp.com/go/openvms).

3.3.5 Bad Atom Error Displayed When Running Applications Over an Untrusted Connection

V1.3

Any DECwindows Motif application that attempts to run over an untrusted connection without a security policy defined will either not start or will exit after starting. An untrusted connection is created when access is granted to an X server using a cookie generated by SET DISPLAY/GENERATE or XAUTH GENERATE.

In most cases where this problem occurs, the following error message is displayed:

X Error of failed request
BadAtom (invalid Atom parameter)

To reduce the likelihood of application errors over untrusted connections, start the server with the default security policy file by setting the symbol DECW$SECURITY_POLICY to DECW$EXAMPLES:DECW$SECURITY_POLICY.TXT.

Note however, that the following applications do not run cleanly over an untrusted connection, even with the security policy file in place:

Bookreader
CDA Viewer
DECterm
DTPAD
OpenVMS Debugger
Paint
Print Screen
Style Manager

V1.3

Applications connected to the X server using an untrusted, generated cookie may not work when the XC-APPGROUP, SECURITY, and XINERAMA server extensions are both loaded. The problem is caused by the order in which these extensions are initialized when the server is started.

To avoid the problem, always define DECW$SERVER_EXTENSIONS in DECW$PRIVATE_SERVER_SETUP.COM so that if both XINERAMA and SEC_XAG (combined SECURITY and XC-APPGROUP image) are loaded, XINERAMA is listed before SEC_XAG.

For example, define:

$ decw$server_extensions == "XINERAMA,SEC_XAG"

instead of:

$ decw$server_extensions == "SEC_XAG,XINERAMA"

V1.3

When using Kerberos with TCP/IP, providing a node name of 0 (to indicate the local host) does not work correctly. The problem occurs only if Kerberos is initialized from the server X authority file. For example:

$ SET DISPLAY/TRANSPORT=TCPIP/NODE=0
$ RUN DECW$EXAMPLES:ICO

  Xlib: krb5_sname_to_principal failed: Hostname cannot be canonicalized
  Cannot open display
  : non-translatable vms error code: 0x182B2
  %rms-e-rnf, record not found

Instead, provide the TCP/IP address of the local host explicitly:

$ SET DISPLAY/TRANSPORT=TCPIP/NODE=11.22.33.44

V1.3

When initializing the Kerberos setup using the server X authority file, the DECwindows Motif login cannot be used. The reason for this is that DECwindows login is a privileged image and the Kerberos runtime image is not an installed image. Moreover, the clients run by login manipulate the Kerberos setup. Therefore, session management is not supported in this configuration.

To prevent the DECwindows login box from coming up, define DECW$MAINAPP in SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM as follows:

$ DECW$MAINAPP == " "

V1.3

The online help for Revoke Ticket is incorrect. See the HP DECwindows Motif for OpenVMS New Features manual for the correct description.

3.3.10 Do Not Insert Generated Cookies into the Default X Authority File

V1.3

Inserting generated cookies in the default X authority file may interfere with the current session cookie. If you want to propagate a generated cookie value, HP recommends using the /XAUTH qualifier as follows to insert the generated cookie in an alternate X authority file:

$  SET DISPLAY/GENERATE=NOTIMEOUT/XAUTH=disk$:[dir]myauthority.decw$xauth

If you insert a generated cookie into the default X authority file during the current DECwindows Motif session, end the session to restore normal system operation.

If you insert a generated cookie into the default X authority file outside of a DECwindows Motif session, delete the X authority file prior to logging into DECwindows.

3.4 Desktop Management

This section describes important issues and considerations related to managing desktops and their applications.

3.4.1 Trusted Unpause Operations Allowed (Alpha Only)

V1.5

The trusted unpause functionality described in the HP DECwindows Motif for OpenVMS Alpha New Features manual did not function on systems running DECwindows Motif for OpenVMS Alpha Version 1.3--1. This has been corrected with DECwindows Motif for OpenVMS Version 1.5. Note that this correction applies to OpenVMS Alpha systems only; the problem remains on OpenVMS I64 systems due to the lack of support for the Authentication and Credentials Management Extensions (ACME) subsystem in the OpenVMS I64 environment.

3.4.2 ACME Login Features Not Supported (I64 Only)

V1.5

The ACME subsystem available with OpenVMS Alpha is not yet available in the OpenVMS I64 environment. As a result, some features of DECwindows Motif that rely on this mechansim (such as trusted unpause) are not available on OpenVMS I64 systems. For more information about the ACME subsystem, see the HP OpenVMS Guide to System Security.

3.4.3 Color Problem in DECwindows Login Screen

V1.2

A problem may occur on systems that have a customized DECW$LOGIN.DAT file. The Start Session dialog box is the color blue instead of tan. If this condition exists, look for a customized DECW$LOGIN.DAT file in the directory SYS$COMMON:[DECW$DEFAULTS.USER] and move it to SYS$MANAGER. A DECW$LOGIN.DAT file in SYS$COMMON:[DECW$DEFAULTS.USER] prevents the *background: resource from being defined; thus, it will default to the color blue.

HP provides a copy of the DECW$LOGIN.DAT file in the SYS$COMMON:[DECW$DEFAULTS.SYSTEM] directory. Any customized versions of this file should reside only in SYS$MANAGER.

3.5 Font and Keymap Management

The following sections contain release notes pertaining to font and keymap support.

3.5.1 Queries on TrueType Font Properties No Longer Reset the Display Server (Alpha Only)

V1.5

Previously, queries on TrueType font properties by desktop applications or the xlsfonts utility (using the -l option) caused the display server to partially reset and appear to hang. This problem has been fixed with DECwindows Motif for OpenVMS Version 1.5.

3.5.2 Euro Currency Symbol Restrictions

V1.3

The following limitations exist with DECwindows Motif and its support for the euro currency symbol:

• When the euro symbol is pasted or sent to another X window application on a different platform (such as UNIX) using Compound Text format, the character may not be recognized as the euro symbol on the other platform.
• The euro currency symbol is not included as part of the scalable font sets available with DECwindows Motif. Applications using scalable fonts cannot display the euro symbol.
• Although you can use EDT to type the euro character into a file, the symbol may not display correctly on the screen. For example, typing Compose o x displays the A4 character code.

V1.3

When using a traditional DECwindows Motif keymap that implements the Mode_switch modifier, make sure that you first adjust the default Window Manager resource settings to enable window grabbing. Otherwise, you may be prevented from using the mouse to grab the handles of open windows on the desktop.

For example, the AUSTRIAN_GERMAN_LK401AG_TW keymap implements the compose key as a one-shot lockdown modifier. The first time a user presses the compose key with this keymap loaded, the Mode_switch modifier is activated, which prevents the user from grabbing the handles of any application windows currently open on the desktop.

To prevent this from occurring, redefine the default Window Manager resources as follows; then exit and restart your DECwindows Motif session:

• For New Desktop systems:
  Edit the file CDE$USER_DEFAULTS:[APP-DEFAULTS.C]DTWM.DAT, and set the value of Dtwm*ignoreModKeys and Dtwm*ignoreAllModKeys to TRUE. If this file and directory do not already exist, create the directory and copy the DTWM.DAT file from CDE$SYSTEM_COMMON:[APP-DEFAULTS.C] to the directory.
• For Traditional DECwindows Desktop systems:
  Edit the file DECW$SYSCOMMON:[DECW$DEFAULTS.USER]DECW$MWM.DAT, and set the value of Mwm*ignoreModKeys and Mwm*ignoreAllModKeys to TRUE. If this file does not already exist, copy the DECW$MWM.DAT file from DECW$SYSTEM_DEFAULTS to the directory.

The following sections contain release notes pertaining to the management of the Low-Bandwidth X (LBX) proxy server and related proxy applications.

3.6.1 Proxy Servers Do Not Support Use of XC-QUERY-SECURITY-1 Protocol

V1.3--1

The Low-Bandwidth X (LBX) proxy server (and other third-party proxy servers) do not support use of XC-QUERY-SECURITY-1 authentication protocol. This authentication protocol, which is enabled by the SECURITY server extension, is typically used by firewall servers to verify the security configuration of the display server to which they are connecting. Normally, firewall servers connect directly to a display server and do not use a proxy server as an intermediary.

If a client application uses a third-party proxy server to connect to an X display server using the XC-QUERY-SECURITY-1 protocol, the application may loop, block, or crash. The LBX proxy server has been modified to detect whether the protocol is in use, and in this situation, produces the following error message:

Multi-pass authentication not supported by LBX

When using a proxy server to process connections to one or more X display servers, verify that the SECURITY extension is not enabled on the X servers. Do this by scanning the DECW$PRIVATE_SERVER_SETUP.COM file on each server system and checking that the parameter DECW$SERVER_EXTENSIONS does not contain a value of SEC_XAG.

3.6.2 Proxy Manager Process Does Not Restart Automatically

V1.3

The following problems can occur with the proxy manager when DECwindows Motif is configured to restart the proxy manager process automatically and the DECwindows Motif session is restarted manually:

• If the proxy manager was running, a new process is not invoked when DECwindows Motif is restarted.
• If the proxy manager was not running, a new process is started; however, the owner of the process is the user who enters the startup command and not the SYSTEM account.

Note that these problems do not occur when DECwindows Motif is restarted as part of an ordered system shutdown (reboot).

To manually restart the proxy manager, enter the following command for the active proxy manager process before restarting DECwindows Motif:

$ STOP DECW$PROXY

Note that this command not only stops the active proxy manager process, but also terminates all proxy server connections managed by the process.

To ensure that the owner of the proxy manager process is the SYSTEM account, always log in as SYSTEM when restarting DECwindows Motif.

3.6.3 Proxy Manager Configuration File Restriction

V1.3

The proxy manager does not support specifying more then one managed or unmanaged entry for the same proxy service in the configuration file. If there are multiple entries, only the first one will be processed.

3.7 X Display Server Management

The following sections contain release notes pertaining to the management of the DECwindows X11 Display Server.

3.7.1 Adjusting Pixel Depth on Systems with ATI RADEON Graphics Cards

V1.5

The default settings for the ATI RADEON graphics card are 24 bits per pixel (pixel depth) and TrueColor (visual class). These settings can cause DECwindows Motif graphics applications or utilities that assume specific pixel depth or visual type values to fail. For example, DECW$PAINT relies on a pixel depth of 8 bits in PseudoColor mode.

If display issues occur on a system with an ATI RADEON card, HP suggests that you adjust the default settings using the DECW$SERVER_PIXEL_DEPTH or DECW$SERVER_DEFAULT_VISUAL_CLASS system logical, as described in the HP OpenVMS Release Notes.

3.7.2 Performance Degradation May Occur on XINERAMA Multihead Systems

V1.3

In some cases, multihead systems configured to use the XINERAMA extension perform slower than single-head or traditional multihead systems (without XINERAMA enabled). Slowed system performance typically occurs on multihead systems with three or more graphics cards that are also running multiple request-intensive applications simultaneously.

This is expected behavior; the following design issues inherent to the XINERAMA implementation from X.Org contribute to the slowdown in system performance:

• Added layer of processing when rendering drawable items
  Instead of using the typical Proc* functions to render drawable items onscreen (such as windows), XINERAMA uses its own set of functions--inserting an additional layer of processing before the rendering functions are called. For each screen in the configuration, the XINERAMA functions supply the appropriate screen-specific resource values to the rendering functions. This extra layer of processing results in more compute time spent comparing drawable regions, determining the applicable screen, modifying the resources for each screen, and completing the additional calls.
• More complex event handling for secondary screens
  Typically, events are destined for a single screen. On a multihead system, XINERAMA distributes events from the dispatch layer to the individual screens for display. Each time an event originates from a secondary screen (other than screen 0), a reverse lookup is required to locate the appropriate screen resource. XINERAMA then maps the event back to the virtual screen 0, and eventually, to the client.
• Unavailability of graphics optimizations
  Each graphics card maintains a separate framebuffer that can be manipulated to optimize display performance. In single-head and traditional multihead configurations, the display optimization can be controlled with such mechansims as Direct Rendering Infrastructure (DRI) and on-card hardware acceleration.
  With XINERAMA, however, these separate framebuffers are merged to form a single work surface. This merged framebuffer can prevent or impede graphics optimizations, as each card only maintains a segment of the entire framebuffer.

If you have configured a XINERAMA-based multihead system and are experiencing a notable decrease in system performance, HP recommends that you do one or more of the following to improve response time:

• Decrease number of heads in the configuration.
• Limit the number of complex, request-intensive applications running concurrently.
• Use the X server system as a display node only, keeping all clients on different nodes.

If you continue to experience a significant lag in system response, HP recommends that you disable the XINERAMA extension, and configure a traditional multihead system as described in the manual Managing DECwindows Motif for OpenVMS Systems.

3.7.3 Using XINERAMA on New Desktop Systems

V1.3--1

The following restriction exists when using the New Desktop on a multiheaded system based on XINERAMA.

Some DECwindows Motif dialog boxes are designed to display at the center of the screen. If there are an even number of screens in any one direction, the dialog boxes are displayed at the junction of two screens, making them difficult to view. Some dialog boxes can be repositioned on screen; however, the following cannot since they are displayed while the Window Manager is not running:

Login dialog box
Login help dialog box
Login Set Password dialog box
Kerberos Login dialog box
Logout Confirmation dialog box
Workspace Restart Confirmation dialog box
Move/Size coordinates displayed by the Workspace Manager

You can manually reposition the New Desktop login dialog box by setting the following resources in the XRESOURCES.DAT file located in CDE$SYSTEM_DEFAULTS:[CONFIG.C]:

Dtlogin*matte.x: 50
Dtlogin*matte.y: 100

Once you have redefined the Dtlogin*matte resources , restart the login process. The login dialog box will be displayed at the specified (x, y) coordinates. If either position is omitted, or is set to zero, the screen will be centered on that axis.

Note that the vertical position of the screen may be slightly above center if the console window is in use.

3.7.4 Some Combinations of Server Extensions Not Supported

V1.3

Currently, the following combinations of X server extensions are not supported:

XINERAMA and D2DX
DBE and MULTIBUFFERING

Note that these extensions may be enabled concurrently on the same DECwindows Motif system. However, due to resource or function conflicts, concurrent use of these extensions on the same system is not supported.

3.7.5 Extraneous Characters Displayed When Running XMAG in a Vertical Multihead Configuration Using XINERAMA

V1.3

When using XMAG to display an image on a multihead system using XINERAMA, a one-pixel line of extraneous characters might appear between the screens when the screens are configured vertically. This problem does not occur when the screens are configured horizontally.

3.7.6 Incorrect Placement of Cascade Menus in Multihead Configurations Using XINERAMA

V1.3

In some cases, DECwindows Motif cascade menus may not appear on the correct screen in a multihead configuration using XINERAMA. The menu is displayed in the correct position on the wrong screen. Currently, there is no workaround.

3.7.7 XINERAMA Supported in 2D Mode Only

V1.3

Using the XINERAMA extension to the X server with 3D applications, such as OpenGL, is not supported. This extension should be used in a 2D environment only.