HP OpenVMS Systems Documentation

V1.2

When the 7-Bit Printer button is selected in the Options/Printer dialog box, DECterm modifies printed text to be compatible with printers that do not support 8-bit characters. This includes modifying control sequence introducer (CSI) strings to use the format Escape-Left Bracket rather than the single 8-bit CSI character.

When the 8-Bit Printer button is selected, DECterm allows the use of 8-bit characters when printing. This mode can cause problems for older printers if they can not interpret 8-bit characters.

The default is 8-Bit.

2.5.4.8 Automatic Window Positioning

V1.1

A resource has been defined to manage repositioning a DECterm window when a resize operation forces part of the window off the screen. If a DECterm window is enlarged by using the Options/Window dialog box or by entering a SET TERMINAL/PAGE=nn or SET TERMINAL/WIDTH=nn command, the controller moves the newly resized DECterm window so that it can be viewed in its entirety. If you prefer DECterm not to move, add the following line to your DECW$TERMINAL_DEFAULT.DAT file:

DECW$TERMINAL.main.terminal.autoAdjustPosition: off

The following sections describe new features related to specific X Window System utilities ported to DECwindows Motif.

2.6.1 AccessX Keyboard Utility (accessx)

V1.3

The AccessX Keyboard utility (accessx) is a client application that enables you to set one or more AccessX keyboard enhancements available with the X Keyboard extension (XKB). These enhancements make it easier for users with disabilities to interact with workstation input devices (keyboard and mouse).

Specifically, AccessX enhancements for XKB offer the following capabilities:

• Sticky Keys -- Allows you to perform multikey operations with one hand, one finger, or a mouth stick. You can use this feature to enter certain uppercase letters and punctuation characters without having to hold down the Shift key. This feature also makes it easier to enter control sequences, such as Ctrl/C.
• Mouse Keys (also known as Dead Mouse) -- Lets you map actions that you would perform with a mouse to keys on the numeric keyboard or other keys that you specify. With this feature, you can use one finger or a mouth stick to move the cursor to different areas of the screen, manipulate menus, and select, cut, and paste text.
• Toggle Keys -- Provides audio feedback when the Shift Lock (Caps Lock) key is pressed. This feature helps users who might have difficulty seeing the keyboard light indicator for the Shift Lock key or users who are using a keyboard that does not provide light indicators for any keyboard settings.
• Repeat Keys -- Allows you to adjust the auto-repeat keyboard mechanism speed or to turn it off entirely. With this feature turned on, you can set your keyboard so that holding down a key for a longer than average time does not cause a repeat entry of that character.
• Slow Keys -- Makes the keys less likely to respond when brushed accidentally. With this feature turned on, the computer accepts only keystrokes that are held for a certain length of time. The computer ignores light keystrokes that are held only for a moment.
• Bounce Keys -- Eliminates the problem of pressing a key and then accidentally pressing it again before moving to another key. You can set this feature to tell the computer not to process a second pressing of a key unless a certain length of time elapses between each pressing.
• Time Out -- Shuts off the AccessX features (except for Repeat Keys) on a workstation after a specified period of time. If you are sharing a workstation and have set AccessX features, the settings are turned off automatically before the next use. To retain the AccessX settings at all times, you can turn off the Time Out feature.

The settings for these capabilities are stored as X resource specifications available from an AccessX configuration file. This utility reads the appropriate file (either for the client or server) and adjusts the resource settings depending upon the changes you make. See Section 2.6.1.1 and Section 2.6.1.2 to learn more about the configuration file and its default values.

To run this utility, define accessx as a foreign command, and copy the UID file to DECW$USER_DEFAULTS:

$ accessx :== "$DECW$EXAMPLES:ACCESSX.EXE"
$ COPY DECW$EXAMPLES:ACCESSX.UID DECW$USER_DEFAULTS:ACCESSX.UID

The command format for accessx is as follows:

$ accessx [-options...]

You can run accessx by entering the command at the DCL prompt, with or without options. The options, described in Table 2-5, allow you to specify which configuration file to load and choose whether to display the status of the editing session. If no options are specified, the client configuration file is loaded by default.

Once invoked, the accessx dialog box is displayed, which lets you select the AccessX features that you want to enable. It also provides a test area that allows you to preview your settings before applying them to a DECwindows Motif session.

For detailed information on the controls and menu options in the dialog box, see the online help available from the Help menu option.

2.6.1.1 The AccessX Configuration File

The AccessX configuration file is an X resource file used to store and load specific AccessX settings for the client. The default client configuration file is located in DECW$USER_DEFAULTS:ACCESSX.DAT and is created the first time you choose Save Settings.

You can choose to edit the file directly or use the accessx utility (with the -client or -server option) to modify the settings. Note that any comments inserted in this file are deleted when you perform a save settings action.

The format for entries in this file follow the standard X resource specification format, which is:

*resource:value

For example:

*BounceKeysToggle.set:False

Since an application can consist of a combination of input widgets (such as, push buttons and a scroll bar), you can use the widget class and name identifiers to create additional resource specifications to control these widgets.

2.6.1.2 Default Resource Settings

Table 2-6 lists the AccessX resources and their default values. These are default settings maintained by the server and also represent the initial settings in the client configuration file, prior to modification.

V1.3

The X Authority utility (xauth) enables you to manage the contents of one or more X authority files. The X authority file contains information used to authorize client connections to the X server.

This utility is typically used to extract authorization records from one system and combine them with the records on another system, such as when granting access to additional users or enabling remote logins. The actual record entries vary depending on the authentication scheme currently in use.

In contrast to other X Window System utilities that are available with DECwindows Motif, xauth is included as a part of OpenVMS Alpha operating system. The xauth commands are case-insensitive and available directly from the DCL command line, xauth command line, or from a batch file.

The command format for xauth is as follows:

$ xauth [-f authfile] [-options...] [command]

Table 2-7 defines the available options.

Table 2-8 defines the available commands.

The X authority file is a binary data file that contains information used to authorize connections to the X server on a system running DECwindows Motif for OpenVMS Alpha Version 1.3 or higher.

Each time an X Window System client application attempts to connect to an X server system that uses an authorization protocol, it references the current X authority file to determine the appropriate authorization key to apply in order to authenticate the connection. Each authorization key consists of the protocol name and token, which can be one of the following depending on the protocol in use:

• MIT-MAGIC-COOKIE-1 + random numeric code
• MIT-KERBEROS-5 + encrypted string (cached separately)

By default, an X authority file is created automatically the first time a user logs into a desktop on a system configured for MIT-MAGIC-COOKIE-1 or MIT-KERBEROS-5 authentication. The file is stored in that user's OpenVMS login directory (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH). Each time the user subsequently logs into a desktop on that system, a new authorization key is generated, passed to the X server, and written to the user's X authority file. This key controls access to the X server during the DECwindows Motif session.

A separate X authority file can be manually defined on a server level (using the DECW$SERVER_XAUTHORITY symbol) for those client applications that require access to the X server outside of the normal DECwindows Motif login process.

If the SECURITY extension is enabled, authorization keys can also be manually generated. Manually-generated keys can be used to further restrict server access. The generated key is stored in the X authority file on the client system overwriting any value already present for the specified display server. The key can be distributed to different client systems to allow connections to a specific server and can be revoked to stop subsequent connections.

Generated keys are assigned an authorization ID that associates the key with the user who generated the key. As a result, only the user who generated the key can revoke the key.

2.6.2.1.1 Format of an X Authority File Entry

Each entry in an X authority file corresponds to a particular X display server and is composed of three main components:

display-name protocol token

display-name

Identifies the name of the X display to which you are authorizing access. The display name follows the format used by the X Window System:

[transport/][host][:]:server[.screen]

This format enables you to use a single X authority file to grant varying levels of access to different X display servers and connection families.

For example, the following entries grant access to the local display server on node HUBBUB and the remote display server on node ZEPHYR via the DECnet transport:

local/HUBBUB:0 MIT-MAGIC-COOKIE-1 cfcc5ef98f9718f90154f355c0ae9f62
decnet/ZEPHYR::0 MIT-MAGIC-COOKIE-1 cfcc5ef98f9718f90154f355c0ae9f62

• transport/
  Identifies the network transport used to connect to an X display server. Valid values are TCPIP/, DECNET/, or LOCAL/. If a transport value is not specified, the default value is interpreted from the format of the remaining portions of the display-name entry, for example:
  • Host address and one colon (116.94.24.187:0) (TCP/IP)
  • Two colons (::0 or ZEPHYR::0) (DECnet)
  • No host name or address and one colon (:0) (local)
• host[:]
  Identifies the name of the host system where the X display server is located. A value of 0 is interpreted as the local host, which is the default. The type of host is determined by the transport value. The host name can be in the format of a recognized IP address, DECnet node specification, or local host identifier, as follows:
  • HUBBUB.COMPANY.COM (IP host)
  • 116.94.24.187 (IP address)
  • ZEPHYR: (DECnet node)
  • 25.54: (DECnet address)
  • HUBBUB (local)
• :server
  Identifies the server. This value is required and must be preceded by a single colon (:). Typically the value for a single-server system is :0. If you are specifying a display on a multi-server system (such as when using a proxy server), additional values may apply depending on the number of servers in the configuration. If you have specified a display device (with the SET DISPLAY command), the server portion of the entry is assumed from the device specification.
• .screen
  Identifies the screen. On OpenVMS Alpha systems, the screen value is not held in the X authority file and is ignored when included in a command. All screens on a single server have the same authorization.

protocol

Indicates the authentication protocol in use. Valid values are MIT-MAGIC-COOKIE-1 and MIT-KERBEROS-5.

token

A random alphanumeric string that functions as a password authorizing a server connection. The format of the token depends on the authorization scheme in use. MIT-MAGIC-COOKIE-1 uses a 128-bit string known as a magic cookie. MIT-KERBEROS-5 uses an encrypted string to authorize server connections. This string is stored separately. The token entry in the X authority file represents the encoded location of the Kerberos keytab file and associated principal name, which is referenced by the server to locate the encrypted string.