As part of the DECwindows startup process, the display server is invoked as a detached process. Normally, the default quotas assigned to the server process are sufficient. However, in some instances, certain parameters may need to be increased. By defining symbols in DECW$PRIVATE_SERVER_SETUP.COM, server process quotas can be adjusted.

For more information on tuning the DECwindows display server, see Appendix A.

DECW$SERVER_PRIORITY

The DECW$SERVER_PRIORITY parameter controls the priority of the display server process. This parameter enables you to reduce the priority of the server process and improve system performance in request-intensive situations where response time is sluggish.

Estimate the optimal priority for the server process; valid values range from 1 (low) to 15 (high). For the best results, VSI recommends that you use a mid-range value of 4, 5, or 6 (default). Setting the priority too low can reduce the responsiveness of input devices (such as keyboard or mouse actions).

The following symbol definition assigns a priority of 4 to the DECwindows display server:

Example

$ DECW$SERVER_PRIORITY == "4"

DECW$SERVER_WSDEF

This parameter defines the process limits (in pagelets) to be applied to the DECwindows display server process. DECW$SERVER_WSDEF values that are larger than the value of DECW$SERVER_WSQUOTA revert to the value of DECW$SERVER_WSQUOTA. For information about establishing working set sizes, see the Guide to OpenVMS Performance Management.

The following logical definition assigns a working set size of 5000 pagelets for the DECwindows display server:

Example

$ DEFINE DECW$SERVER_WSDEF 5000

DECW$SERVER_WSQUOTA

This parameter defines the maximum amount of physical memory (working set) that can be allocated to the DECwindows server. For information about establishing working set sizes, see the Guide to OpenVMS Performance Management.

The following logical definition establishes the maximum number of pagelets allocated to the DECwindows server as 10000:

Example

$ DEFINE DECW$SERVER_WSQUOTA 10000

DECW$SERVER_WSEXTENT

This parameter defines the absolute limit on physical memory that the DECwindows display server is to be allocated if the server requires more space than the DECW$SERVER_WSDEF value allots. The total number of pagelets allocated to the DECwindows server may exceed the value in DECW$SERVER_WSQUOTA (up to the value of DECW$SERVER_WSEXTENT if the additional pagelets are available). For information about establishing working set sizes, see the Guide to OpenVMS Performance Management.

The following logical definition allocates 20000 pagelets for the DECwindows server on an as-needed basis, not to exceed the value in DECW$SERVER_WSQUOTA:

Example

$ DEFINE DECW$SERVER_WSEXTENT 20000

DECW$SERVER_PAGE_FILE

This parameter defines the maximum amount of virtual memory (in pagelets) that the DECwindows display server can use.

The following logical definition increases the size of the page file to 1000000 blocks:

Example

$ DEFINE DECW$SERVER_PAGE_FILE 1000000

DECW$SERVER_FILE_LIMIT

This parameter defines the maximum number of files the server can open at onetime. It also represents the maximum number of concurrent client connections. The default is 200 files.

The following logical definition increases the maximum number of files the server can open to 275:

Example

$ DEFINE DECW$SERVER_FILE_LIMIT 275

DECW$SERVER_ENQUEUE_LIMIT

This parameter defines the maximum number of outstanding locks that can be used in sharing resources, particularly files, between processes. The default is 512 locks.

The following logical definition doubles the default enqueue limit to 1024locks:

Example

$ DEFINE DECW$SERVER_ENQUEUE_LIMIT 1024

A feature of all the X display servers is the ability to support server extensions. These extensions are additions to the X display server that interpret additional protocol requests and perform new or improved functions.

While some extensions are built-in and always enabled, some require activation through a parameter definition. OpenVMS display servers support dynamically-loaded extensions. These extensions are contained in separate shareable images and are activated on demand. The advantage of dynamically loaded extensions is that the resources required by an extension are not used unless the extension is used.

The display server requires that certain dynamic extensions be loaded at server initialization time. Use the symbol DECW$SERVER_EXTENSIONS to identify which extensions to load.

DECW$SERVER_EXTENSIONS

This parameter is used to define a list of extensions to load at server initialization. The parameter translates to a list of dynamically-loadable extension images (in addition to the built-in extensions).

The following symbol definition specifies the range of server extensions to enable at startup:

Example

$ DECW$SERVER_EXTENSIONS == "XIE,DEC-XTRAP,XINERAMA,SEC_XAG,DBE"

DECW$SERVER_DISABLE_TEST

This parameter controls whether test extensions, XTEST and DEC-XTRAP, are enabled. Valid values for this parameter are T (True-disable) or F (False-enable) The default value is F.

The following symbol definition disables all test extensions:

Example

$ DECW$SERVER_DISABLE_TEST == "T"

Each of these methods provides additional means for defining which clients are authorized to connect to an X display server and what operations they can perform once connected. Use the parameters in this section to specify the location of the files used with these mechanisms (security policy, X authority, access allowed, and access trusted files).

See Section 3.3 for details on implementing an access control scheme for the display server.

DECW$SECURITY_POLICY

When using the Security extension, this parameter specifies the name of the security policy file. By default, no file is specified.

The following symbol definition specifies the security policy file SYS$MANAGER:DECW$SECURITY_POLICY.DAT:

Example

$ DECW$SECURITY_POLICY == "SYS$MANAGER:DECW$SECURITY_POLICY.DAT"

DECW$SERVER_XAUTHORITY

This parameter specifies the name of the X authority file referenced by the display server. This file provides records used to authorize client connections to the server. By default, no file is specified. This allows access to the server from the local SYSTEM account (via DECnet or the Local transport)without requiring additional authentication from the client.

If a file is specified, the values from this file are loaded into the server and can be used by all client connections. To allow a normal login process to occur, trusted access must be explicitly granted using the DECW$SERVER_ACCESS_TRUSTED.DAT file.

Note that the settings in the X authority file specified by DECW$SERVER_XAUTHORITY apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's X authority settings are applied.

The following symbol definition specifies the X authority file SYS$MANAGER:DECW$XAUTH.DAT:

Example

$ DECW$SERVER_XAUTHORITY == "SYS$MANAGER:DECW$XAUTH.DAT"

DECW$SERVER_ACCESS_TRUSTED

This parameter specifies the name of the trusted access file. This file lists those clients who maintain trusted access to the server. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_TRUSTED.DAT.

Note that the settings in the trusted access file specified by DECW$SERVER_ACCESS_TRUSTED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.

The following symbol definition changes the trusted access file specification to DECW$SERVER1_ACCESS_TRUSTED.DAT:

Example

$ DECW$SERVER_ACCESS_TRUSTED == "SYS$MANAGER:DECW$SERVER1_ACCESS_TRUSTED.DAT"

DECW$SERVER_ACCESS_ALLOWED

This parameter specifies the name of the access allowed file. This file lists those clients who are granted automatic access to the server without requiring additional authentication. The default file is SYS$MANAGER:DECW$SERVER_ACCESS_ALLOWED.DAT.

Note that the settings in the allowed access file specified by DECW$SERVER_ACCESS_ALLOWED apply to server connections made before a user logs into the DECwindows desktop. Once a user logs into the desktop, the user's access settings are applied.

The following symbol definition changes the allowed access file specification to DECW$SERVER1_ACCESS_ALLOWED.DAT:

Example

$ DECW$SERVER_ACCESS_ALLOWED == "SYS$MANAGER:DECW$SERVER1_ACCESS_ALLOWED.DAT"

During startup, the DECwindows startup procedures attempt to identify and activate device-specific server components to manage all graphics devices of which the system is aware. You can use the symbols and logicals in this section to influence how many and which specific devices are used by the display server.

Additionally, there is some information that the server cannot obtain from a device or that you may want to override about the display device. For example, you may need to provide information about a special type of monitor with limited color capabilities or construct a multihead system, which is a system that consists of multiple monitors that function as a single, virtual display.

The XINERAMA (formerly known as Panoramix) enables you to construct a multihead system and has multiple parameters to define and enable the screens in the display, control their order, and set the boundary and shape of the display.

By default, all screens in a multihead display are enabled. You can use DECW$SERVER_ONLYSCREEN, DECW$SERVER_DISABLESCREEN to remove one or more screens from the from the display. Disabled screens are not initialized and are not assigned a screen number.

For instructions on how to configure a multihead display, see Section 3.4.

DECW$MULTI_HEAD

This parameter configures the system for multihead support. The DECW$MULTI_HEAD symbol is already set in the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.TEMPLATE file.

To activate this parameter, copy the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.TEMPLATE to DECW$PRIVATE_SERVER_SETUP.COM.

DECW$PRIMARY_DEVICE

The server uses this parameter to check for a device name by activating a specific DECW$DEVICE_ xx.COM procedure, where xx is the string supplied for the symbol. The following symbol definition assigns GXA0 as the primary device:

Example

$ DECW$PRIMARY_DEVICE == "GXA0"

DECW$DEVICE

This parameter allows you to identify those graphics devices that are used in a simple multihead configuration and specify their order. By default, the DECW$DEVICE values for will be determined based on the graphics devices installed on the system.

The following example shows a list of graphics devices to be controlled by one server, one mouse, and one keyboard:

Example

$ DECW$DEVICE == "GAA0,GAB0"

DECW$DEFAULT_VISUAL_CLASS

The default for a specific device type is dependent on the hardware and is typically PseudoColor for an 8-plane color board, and TrueColor for a 24-plane option. If you have a monochrome display, you can change the default visual class to GrayScale, which causes the system to convert colors to levels of gray. Output for GrayScale is on the green lead. You can assign multiple values to this parameter for each head in a multihead system.

The following symbol definition specifies PseudoColor on head 0, TrueColor on head 1, StaticGray on head 2:

Example

$ DECW$SEVER_DEFAULT_VISUAL_CLASS == "3,4,0"

DECW$MONITOR_DENSITY

The monitor density defines the dots per inch (dpi) value of the monitor so that VSI DECwindows Motif for OpenVMS applications can determine the actual width of the screen.

The default value for the monitor density is the server density. Because few monitors are actually 75 or 100 dpi (the values used for DECW$SERVER_DENSITY with regard to font size), these values cannot be used to calculate accurately the actual width and length of items on the screen. By setting DECW$MONITOR_DENSITY to the actual value, you can obtain correct values for the width and height of the screen using Xlib routines.

By rounding the dpi value to the nearest integer, assign 95 to DECW$MONITOR_DENSITY, as shown in the following example:

Example

$ DECW$MONITOR_DENSITY == "95"

DECW$MONITOR_DENSITY can be set on a per-monitor basis. The following example shows how to set the monitor densities for a dual-head workstation,where screen 0 is set to 95 dpi and screen 1 is set to 75 dpi:

Example

$ DECW$MONITOR_DENSITY == "95,75"

DECW$SERVER_SCREENS

With a multihead system based on XINERAMA, screens are initialized in alphabetical order according to their device name versus their physical position. Use this parameter to change the order in which the screens are initialized.

The following symbol definition changes the initialization order in a four-screen multihead display:

Example

$ DECW$SERVER_SCREENS == "GYB0,GYA0,GYD0,GYC0"

DECW$SERVER_ENABLESCREEN

With a multihead system based on XINERAMA, you can choose tore-enable disabled screens in the display individually. This parameter enables the specified screen(s). The valid value ranges from0 to 15, which represents the maximum number of screens supported by the extension.

The following example enables the second screen (1) in a four-screen (0,1,2,3) multihead display:

Example

$ DECW$SERVER_ENABLESCREEN == "1"

DECW$SERVER_DISABLESCREEN

With a multihead system based on XINERAMA, you can choose to disable each screen in the display individually. This parameter disables the specified screen. The valid value ranges from 0 to 15, which represents the maximum number of screens supported by the extension.

Once a screen is disabled, it is no longer initialized as part of the display and is not assigned a screen number. Note that this changes the existing screen order and alters the display of any predefined edge attachments.

The following symbol definition disables the third screen (2) in a four-screen (0,1,2,3) multihead display:

Example

$ DECW$SERVER_DISABLESCREEN == "2"

DECW$SERVER_ONLYSCREEN

With a multihead system based on XINERAMA, you can choose to enable individual screens in the display at the exclusion of all others. This parameter explicitly enables the specified screen and disables all others. The valid value ranges from 0 to 15, which represents the maximum number of screens supported by the extension.

The following symbol definition enables the second screen (1) and disables all other screens (0,2,3) in a four-screen (0,1,2,3) multihead display:

Example

$ DECW$SERVER_ONLYSCREEN == "1"

DECW$SERVER_EDGE_LEFT

With a multihead system based on XINERAMA, edge controls are used to define the boundaries of the virtual display. This parameter determines to what screen(s) the left boundary of the display is attached. The values are determined by screen number, for example:

left-screen , index-screen , right-screen 

where index-screen represents the number of the screen to which you want the boundary attached, left-screen indicates the number of the screen directly to the left of the index, and right-screen indicates the number of the screen directly to the right of the index. Repeat this pattern for each screen to which you want the border attached. A value of -1 equates to none.

where the left edge of the second and fourth screens (indices 1 and 3) are attached to the first and third screens (0,2):

Example

$ DECW$SERVER_EDGE_LEFT == "-1,0,-1,2"

DECW$SERVER_EDGE_RIGHT

With a multihead system based on XINERAMA, edge controls are used to define the boundaries of the virtual display. This parameter determines to what screen the right boundary of the display is attached. The values are determined by screen number, for example:

right-screen , index-screen , left-screen 

where index-screen represents the number of the screen to which you want the boundary attached, right-screen indicates the number of the screen directly to the right of the index, and left-screen indicates the number of the screen directly to the left of the index. Repeat this pattern for each screen to which you want the border attached. A value of -1 equates to none.

where the right edges of the first and third screens (indices 0 and 2) are attached to the second and fourth screens (1,3):

Example

$ DECW$SERVER_EDGE_RIGHT == "1,-1,3,-1"

DECW$SERVER_EDGE_TOP

With a multihead system based on XINERAMA, edge controls are used to define the boundaries of the virtual display. This parameter determines to what screen the top boundary of the display is attached. The values are determined by screen number, for example:

top-screen , index-screen , bottom-screen 

where index-screen represents the number of the screen to which you want the boundary attached, top-screen indicates the number of the screen directly above the index, and bottom-screen indicates the number of the screen directly below the index. Repeat this pattern for each screen to which you want the border attached. A value of -1 equates to none.

where the top edges of the third and fourth screens (indices 2 and 3) are attached to the first and second screens (0,1):

Example

$ DECW$SERVER_EDGE_TOP == "-1,-1,0,1"

DECW$SERVER_EDGE_BOTTOM

With a multihead system based on XINERAMA, edge controls are used to define the boundaries of the virtual display. This parameter determines to what screen the bottom boundary of the display is attached. The values are determined by screen number, for example:

bottom-screen , index-screen , top-screen 

where index-screen represents the number of the screen to which you want the boundary attached, bottom-screen indicates the number of the screen directly below the index, and top-screen indicates the number of the screen directly above the index. Repeat this pattern for each screen to which you want the border attached. A value of -1 equates to none.

where the bottom edges of the first and second screens (indices 0 and 1) are attached to the third and fourth screens (2,3):

Example

$ DECW$SERVER_EDGE_BOTTOM == "2,3,-1,-1"

The transport is the link between DECwindows client applications and the display server. Use the symbols in this section to control the types of available network transport links and the timing characteristics of the link.

DECW$SERVER_TRANSPORTS

You can specify which network transports your server monitors for incoming connections. Valid values for DECW$SERVER_TRANSPORTS are "DECNET", "LOCAL", "TCPIP", and "LAT". The default value for this parameter depends on the value of the DECW$INSTALL_TCPIP system logical. If the logical is set to True, the default value is "DECNET,LOCAL,TCPIP"; if the logical is not set, the default value is "DECNET,LOCAL."

The following example shows how to specify DECnet, local, and TCP/IP as the transports you will use:

Example

$ DECW$SERVER_TRANSPORTS == "DECNET,LOCAL,TCPIP"

DECW$XPORT_SYNC_TIMEOUT

This parameter defines the transport timeout value (in milliseconds). The default is 30000 milliseconds (30 seconds). If the client does not take action to empty its buffers before the timeout, the server disconnects the client.

The following logical definition extends the timeout value to 60000milliseconds (1 minute):

Example

$ DEFINE/SYSTEM DECW$XPORT_SYNC_TIMEOUT 60000

Displaying text is one of the major tasks of the display server. To display text, the display server is given a font name and a set of characters to be drawn. Usually, the font name corresponds to a particular font file resident on a server system (either display server or font server). When trying to match a font name with a font file, the display server searches the font path, which is an ordered list of directories. Each valid font directory contains a font directory file (DECW$FONT_DIRECTORY*.DAT) that lists font file names and corresponding font names. The display server searches each directory file, in order, until it finds a matching font name.

In addition, DECwindows Motif supports font alias files (DECW$FONT_ALIAS*.DAT),which can reside in any valid font directory. These files map one font name to a different font name. After the display server checks the font directory file in a given font directory without finding a match, it will then search the font alias file, if it exists. If it finds a match in the alias file, the translated font name is substituted and the search is restarted from the beginning of the font path.

$ DECW$SERVER_DENSITY == "100"

$ DECW$CURSOR_SIZE == "16"

$ DECW$FONT_SERVERS == "DECNET/ASHFLD::FONTSRV"

$ DECW$IPV6_FONT_SUPPORT == TCP_IS_INET6

DECW$SYSCOMMON:[SYSFONT.DECW.100DPI]HELVETICA12_100DPI.DECW$FONT

$ DEFINE/SYSTEM DECW$SERVER_FONT_CACHE_SIZE 512

$ DEFINE/SYSTEM DECW$SERVER_FONT_CACHE_UNIT 512

$ DEFINE/SYSTEM DECW$SERVER_SCALE_BITMAP_FONTS TRUE

Some default characteristics of the keyboard attached to the server system can be modified. These include keyboard operations, such as keyclick and bell volume and autorepeat, as well as how the keyboard keys are mapped to keyboard independent symbols used by client applications.

Additionally, the X Keyboard extension (XKB) provides enhanced capabilities for defining the keyboard layout and audio feedback. Use the parameters in this section when using XKB to specify the settings for the X Keyboard layout files. See Section 3.5 for instructions on how to load custom key map and keyboard layout files.

Some of the keyboard settings in this section can be overridden by the Session Manager. Setting these symbols takes effect before the user logs in or if you are not using DECwindows Session Manager.

DECW$KEYMAP

The DECW$KEYMAP parameter translates to the directory specification where keyboard mapping files reside. It is provided for your reference only. Do not modify its value.

DECW$DEFAULT_KEYBOARD_MAP

You can specify the language for which your keyboard is designed. Valid values for DECW$DEFAULT_KEYBOARD_MAP are the file names (without file type) in the SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM] and SYS$COMMON:[SYS$KEYMAP.DECW.USER] directories.

For a list of valid key map names, see Appendix B.

The following symbol definition changes the keyboard layout to a Dutch typewriter layout:

Example

$ DECW$DEFAULT_KEYBOARD_MAP == "DUTCH_LK201LH_TW"

DECW$SERVER_BELL_BASE_VOLUME

This parameter determines the volume of the bell sound in a keyboard. Values are from 0 to 100, with 100 being the loudest. The default volume level is 50.

The following logical definition sets the volume to one quarter of full volume:

Example

$ DEFINE/SYSTEM DECW$SERVER_BELL_BASE_VOLUME 25

DECW$SERVER_ENABLE_ACCESSX

This parameter enables the AccessX keyboard features for disabled users,such as sticky keys or slow keys. The valid values are 0 (disabled) or 1 (enabled). The default is 0.

The following example enables the AccessX features:

Example

$ DECW$SERVER_ENABLE_ACCESSX == "1"

DECW$SERVER_ENABLE_KB_AUTOREPEAT

Keyboard autorepeat is an option that causes a character to repeat itself automatically while that character key is pressed. You can enable this option by specifying True for this parameter.

The following logical definition enables keyboard autorepeating of typed characters:

Example

$ DEFINE/SYSTEM DECW$SERVER_ENABLE_KB_AUTOREPEAT T

DECW$SERVER_KEYCLICK_VOLUME

This parameter determines the volume of the click sound in a keyboard.Values are from 0 to 100, with 100 being the loudest. The default is 0.

The following symbol definition sets the volume to one quarter of fullvolume.

Example

$ DEFINE/SYSTEM DECW$SERVER_KEYCLICK_VOLUME 25

DECW$SERVER_KEY_REPEAT_DELAY

When using XKB, this parameter specifies the number of milliseconds before a keystroke is first repeated. The valid values for this parameter are 0 to 1000.The default is 660.

The following symbol definition specifies the delay for keystroke repetition:

Example

$ DECW$SERVER_KEY_REPEAT_DELAY == "800"

DECW$SERVER_KEY_REPEAT_INTERVAL

When using XKB, this parameter specifies the number of milliseconds between repeated keystrokes. The valid values for this parameter are 0 to 1000. The default is 40.

The following symbol definition specifies the interval for keystroke repetition:

Example

$ DECW$SERVER_KEY_REPEAT_INTERVAL == "20"

DECW$SERVER_XKEYBOARD_COMPILED_DIR

When using XKB, this parameter specifies the default directory for all compiled X keyboard files. This directory is also where the server places any keymap files that it compiles on demand. The default is SYS$COMMON:[SYS$KEYMAP.XKB.COMPILED].

The following symbol definition changes the root directory to SYS$COMMON:[SYS$KEYMAP.XKB.SERVER1]:

Example

$ DECW$SERVER_XKEYBOARD_COMPILED_DIR == "SYS$COMMON:[SYS$KEYMAP.XKB.SERVER1]"

DECW$SERVER_XKEYBOARD_DIRECTORY

When using XKB, this parameter specifies the default root directory for all X keyboard files. All component source X keyboard files are stored in subdirectories under this root directory. The default is DECW$SYSCOMMON:[SYS$KEYMAP.XKB].

The following symbol definition changes the root directory to SYS$COMMON:[SYS$KEYMAP.XKB]:

Example

$ DECW$SERVER_XKEYBOARD_DIRECTORY == "SYS$COMMON:[SYS$KEYMAP.XKB]"

DECW$SERVER_XKEYBOARD_LOAD_MAP

When using XKB, this parameter loads the X keyboard layout specified by DECW$SERVER_XKEYBOARD_MAP. The valid values for this parameter are 0 (disabled)or 1 (enabled). The default is 0. When this parameter is disabled, the DECwindows keyboard maps are used.

The following symbol definition loads the default DECwindows keyboard map file:

Example

$ DECW$SERVER_XKEYBOARD_LOAD_MAP == "1"

DECW$SERVER_XKEYBOARD_MAP

When using XKB, this parameter specifies the default X keyboard layout file for your keyboard. The default is DIGITAL_US_LK201. If the compiled layout file is not available in the area specified by DECW$SERVER_XKEYBOARD_COMPILED_DIR, the display server will attempt to compile the file on-demand based on data in the X keyboard components database.

The following symbol definition changes the X Keyboard layout to an alternate keyboard layout:

Example

$ DECW$SERVER_XKEYBOARD_MAP == "DIGITAL_US_LK401"

Use the symbols in this section to modify mouse pointer characteristics. All the mouse pointer settings in this section are overridden by the Session Manager. Setting these symbols takes effect before the user logs in or if you are not using DECwindows Session Manager.

DECW$SERVER_MOUSE_ACCELERATION

The following logical definition causes the pointer to move at the fast speed in relation to your mouse movements:

Example

$ DEFINE/SYSTEM DECW$SERVER_MOUSE_ACCELERATION 2

DECW$SERVER_MOUSE_THRESHOLD

This parameter defines the minimum motion of the mouse (in pixels) at which the DECwindows server is notified of the motion. The default is 4 pixels.

The following logical definition causes the mouse to be very sensitive to movement, resulting in the report of movement to the DECwindows server:

Example

$ DEFINE/SYSTEM DECW$SERVER_MOUSE_THRESHOLD 1

The display server uses a color database file to translate color names passed to the server from client applications into RGB values. Use the symbols in this section to modify color database characteristics.

DECW$RGBPATH

This parameter defines the RGB database filename to be used with the display server. The default name is SYS$MANAGER:DECW$RGB.DAT.

The following symbol definition changes the filename value to DECW$RGBPATH.DAT:

Example

$ DECW$RGBPATH == "SYS$MANAGER:DECW$RGBPATH.DAT"

The screen saver causes the monitor to go blank after a specified length of time (10 minutes by default) during which no user input occurs. Note that the actual value is specified in seconds.

DECW$SERVER_SCREEN_SAVER_PREFER_BLANKING

This parameter determines the method by which screen saver is performed. When the value is True (the default), the DECwindows server causes the video device driver to turn off the video signal when the Screen Saver timeout expires. When the value is False, the DECwindows server blanks the screen when the timeout expires.

The following logical definition causes the screen to be cleared when the screen saver timeout expires:

Example

$ DEFINE/SYSTEM DECW$SERVER_SCREEN_SAVER_PREFER_BLANKING F

DECW$SERVER_SCREEN_SAVER_TIMEOUT

This parameter defines the initial time (in minutes) before the screen saver is activated, after which the screen saver interval takes effect. The default is 600 seconds (10 minutes).

The following logical definition causes the initial screen saver time to be 5 minutes:

Example

$ DEFINE/SYSTEM DECW$SERVER_SCREEN_SAVER_TIMEOUT 5

DECW$SERVER_SCREEN_SAVER_INTERVAL

This parameter defines the number of minutes the server waits before repainting the screen background. The screen saver rearranges the screen pixels to avoid burning the screen phosphor. Some servers use nonblanking screen savers, such as swimming fish or logos. The default is 600seconds (10 minutes).

The following logical definition causes the background screen to be repainted in 7-minute intervals:

Example

$ DEFINE/SYSTEM DECW$SERVER_SCREEN_SAVER_INTERVAL 7

In general, it is the responsibility of the client application to restore occluded regions of the screen once they are exposed. However, the display server has several techniques available to perform this operation on behalf of the client. These are the backing store and save under options.

Backing store saves portions of windows in server memory just before they are obscured. Later, when the portions are exposed, the server can repaint them without involving the client. This can drastically reduce the time required to repaint, particularly for windows containing complex graphics or for environments where the client/server link is slow.

Save under is a similar mechanism where just prior to painting a window, the server saves the portion of the screen that is about to be obscured.

DECW$SERVER_DEFAULT_BACKING_STORE

A True value for DECW$SERVER_DISABLE_BACKING_STORE causes the backing store option not to be used. The value for DECW$SERVER_DEFAULT_BACKING_STORE can be overridden in applications on a per-window basis.

The following logical definition causes the server to save and restore windows when the windows are mapped to the screen:

Example

$ DEFINE/SYSTEM DECW$SERVER_DEFAULT_BACKING_STORE 1

DECW$SERVER_DISABLE_BACKING_STORE

Use this parameter to disable backing store support. The default value is False so that backing store is enabled by default.

When DECW$SERVER_DISABLE_BACKING_STORE is set to True (disable backing store),restart the server, at which time the backing store option is disabled. Thereafter, to reenable backing store, deassign or redefine DECW$SERVER_DISABLE_BACKING_STORE and restart the server.

If your application window comes up blank, then the application is requesting backing store incorrectly and waiting for an expose event to begin processing. Either modify your application so that it does not request backing store, or set DECW$SERVER_DISABLE_BACKING_STORE to True, and restart the DECwindows display server.

The following symbol definition disables backing store:

Example

$ DECW$SERVER_DISABLE_BACKING_STORE == "T"

DECW$SERVER_DISABLE_SAVE_UNDER

The save under option records window information that may be hidden when another window is placed on top. You can disable this option by specifying True for this parameter.

The save under option is similar to the backing store option, but only the occluded portions of windows are saved by the server so that when that portion of the window becomes visible, the server redraws that portion of the window.

The following symbol definition disables the server's save under option:

Example

$ DEFINE/SYSTEM DECW$SERVER_DISABLE_SAVE_UNDER T

The display server creates a log file into which it writes informational and error messages to aid in troubleshooting problems. The log file is called SYS$MANAGER:DECW$SERVER_ n_ERROR.LOG, where n is the server number (usually 0).

The display server uses a condition handler to trap error conditions (such as an access violation) that might otherwise cause the display server to stop. If the condition handler detects a nonfatal error, it tries to allow the display server to continue. The condition handler always records the error in the error log file. If the condition handler detects errors for a single client (2 by default), it disconnects the client.

When the condition handler recovers from an error, the display server may lose track of some resources, such as memory. Therefore, after a number of these exceptions (10 by default), the condition handler broadcasts a message to all users on the system indicating that the display server may be running in a degraded mode and suggests that the display server should be restarted. If you see a message like this, restart the display server at the next convenient opportunity. See Section 2.2 for instructions for restarting the server.

DECW$SERVER_AUDIT_LEVEL

The default value is 0.

The following symbol definition enables minimal audit logging:

Example

$ DECW$SERVER_AUDIT_LEVEL == "1"

DECW$SERVER_BUG_COMPATIBILITY

Inconsistencies between pre–X11R4 servers and the X11 protocol allowed some undefined bits to be set in some X requests. By strictly enforcing this part of the protocol, however, some applications that set undefined bits no longer worked. By setting bug compatibility to True (default), the server will continue to allow these applications to work; however, the applications should be recoded to comply with the X11 protocol.

The following symbol definition allows pre–X11R4 servers and X11 protocol applications to function correctly:

Example

$ DECW$SERVER_BUG_COMPATIBILITY == "T"

DECW$SERVER_DUMP

Setting this parameter to True adds the /DUMP qualifier to the DCL RUN command, which causes a process dump if the server crashes. Specifying True also automatically disables the server condition handler (sets DECW$SERVER_DISABLE_CH to True).

The following logical definition adds the /DUMP qualifier to the DCL RUN command and disables the server condition handler:

Example

$ DEFINE DECW$SERVER_DUMP T

DECW$SERVER_ERROR_LOG_TO_KEEP

This parameter defines the number of versions of the error log file to save. The default is two versions.

The following symbol definition causes the DECwindows server to save the three most recent versions of the error log file:

Example

$ DECW$SERVER_ERROR_LOG_TO_KEEP == "3"

DECW$CLIENT_ERROR_THRESHOLD

This parameter defines the number of protocol errors generated by a single client above which the client will be terminated. The default is one protocol error.

The following logical definition causes the DECwindows display server to terminate a client after 10 or more protocol errors have been generated:

Example

$ DEFINE/SYSTEM DECW$CLIENT_ERROR_THRESHOLD 10

DECW$SERVER_ERROR_THRESHOLD

Server internal runtime error threshold exceeded (code =
%x),server performance may be degraded.

The symbol %x is replaced by the condition code (in hexadecimal) that forced the error. The most typical value is “c”, specifying an access violation.

DECW$SERVER_ERROR: internal runtime error threshold exceeded.
Performance may be degraded, restart DECwindows software when
convenient by @SYS$MANAGER:DECW$STARTUP RESTART.

Server performance still degrading...

The following logical definition causes the DECwindows server to report a system degradation message after 20 server errors have accumulated:

Example

$ DEFINE/SYSTEM DECW$SERVER_ERROR_THRESHOLD 20

You can use the DCL SHOW LOGICAL command to display all of the logical names in the server logical name table that are defined from symbols specified in the DECwindows startup process.

$ SHOW LOGICAL/TABLE=DECW$SERVER0_TABLE
(DECW$SERVER0_TABLE)

  "DECW$COLOR" = "TRUE"
  "DECW$DEFAULT_FONT" = "FIXED"
  "DECW$DEFAULT_KEYBOARD_MAP" = "NORTH_AMERICAN_LK401AA"
  "DECW$FONT" = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_CURSOR32]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR32]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_CURSOR16]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR16]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_100DPI]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.100DPI]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_75DPI]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.75DPI]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_COMMON]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.COMMON]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.SPEEDO]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.TYPE1]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_TYPE1]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.TRUETYPE]"
        = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_TRUETYPE]"
  "DECW$KEYBOARD" = "OPA2:"
  "DECW$KEYMAP" = "DECW$SYSCOMMON:[SYS$KEYMAP.DECW.USER]"
        = "DECW$SYSCOMMON:[SYS$KEYMAP.DECW.SYSTEM]"
  "DECW$MONITOR_DENSITY" = "100"
  "DECW$POINTER" = "TTA0:"
  "DECW$RGBPATH" = "SYS$MANAGER:DECW$RGB.DAT"
  "DECW$SERVER_AUDIT_LEVEL" = "4"
  "DECW$SERVER_BUG_COMPATIBILITY" = "Y"
  "DECW$SERVER_DISABLE_BACKING_STORE" = "FALSE"
  "DECW$SERVER_DISABLE_CH" = "N"
  "DECW$SERVER_DISABLE_TEST" = "F"
  "DECW$SERVER_ENABLE_ACCESSX" = "0"
  "DECW$SERVER_EXTENSIONS" = "Xie"
        = "Multi-Buffering"
        = "Sec_Xag"
  "DECW$SERVER_KEY_REPEAT_DELAY" = "660"
  "DECW$SERVER_KEY_REPEAT_INTERVAL" = "40"
  "DECW$SERVER_SCREENS" = "GYA0"
  "DECW$SERVER_TRANSPORTS" = "DECNET"
        = "LOCAL"
        = "TCPIP"
        = "LAT"
  "DECW$SERVER_XKEYBOARD_COMPILED_DIR" = "SYS$COMMON:[SYS$KEYMAP.XKB.COMPILED]"
  "DECW$SERVER_XKEYBOARD_DIRECTORY" = "DECW$SYSCOMMON:[SYS$KEYMAP.XKB]"
  "DECW$SERVER_XKEYBOARD_LOAD_MAP" = "0"
  "DECW$SERVER_XKEYBOARD_MAP" = "DIGITAL_US_LK201"
  "DECW$SYSCOMMON" = "SYS$SYSROOT"
  "DECW$XPORT_LRP_SIZE" = "32768"
  "DECW$XSIZE_IN_PIXELS" = "1280"
  "DECW$YSIZE_IN_PIXELS" = "1024"

You can use the X Display Information utility (xdpyinfo) to query the server directly and report various server parameters.

Before running this utility, make sure you have the correct display selected by using the SET DISPLAY command.

$ SET DISPLAY/CREATE/NODE=node_name
$ RUN DECW$UTILS:XDPYINFO

name of display:    _WSA1:
version number:    11.0
vendor string:    DECWINDOWS Hewlett-Packard Development Company OpenVMS
vendor release number:    8002
maximum request size:  65535 longwords (262140 bytes)
motion buffer size:  0
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    6
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 12, bits_per_pixel 32, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
number of extensions:    17
    DEC-Server-Mgmt-Extension
    ServerManagementExtension
    SHAPE
    MIT-SHM
    Extended-Visual-Information
    XTEST
    BIG-REQUESTS
    MIT-SUNDRY-NONSTANDARD
    MIT-SCREEN-SAVER
    SYNC
    XC-MISC
    TOG-CUP
    Xie
    DEC-XTRAP
    Multi-Buffering
    SECURITY
    XC-APPGROUP
default screen number:    0
number of screens:    1
screen  0:
  dimensions:    1280x1024 pixels (325x260 millimeters)
  resolution:    100x100 dots per inch
  depths (1):    8  root window id:    0x2e
  depth of root window:    8 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x21
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 1
  options:    backing-store YES, save-unders YES
  current input event mask:    0x0
  number of visuals:    10
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    PseudoColor
    depth:    8 planes
    size of colormap:    256 entries
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x23
    class:    PseudoColor
    depth:    8 planes
    size of colormap:    256 entries
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x24
    class:    DirectColor
    depth:    8 planes
    size of colormap:    8 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x25
    class:    GrayScale
    depth:    8 planes
    size of colormap:    256 entries
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x26
    class:    StaticGray
    depth:    8 planes
    size of colormap:    256 entries
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x27
    class:    StaticColor
    depth:    8 planes
    size of colormap:    256 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x28
    class:    TrueColor
    depth:    8 planes
    size of colormap:    8 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x29
    class:    TrueColor
    depth:    8 planes
    size of colormap:    8 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x2a
    class:    TrueColor
    depth:    8 planes
    size of colormap:    8 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits
  visual:
    visual id:    0x2b
    class:    TrueColor
    depth:    8 planes
    size of colormap:    8 entries
    red, green, blue masks:    0xe0, 0x1c, 0x3
    significant bits in color specification:    3 bits

Use the X Set utility (xset) to query the server directly for parameter settings. Running xset is a good method to determine the current font path.

Before running this utility, make sure you have the correct display selected by using the SET DISPLAY command.

$ SET DISPLAY/CREATE/NODE=node_name
$ MCR DECW$UTILS:XSET Q

Keyboard Control:
  auto repeat:  on    key click percent:  25    LED mask:  00000000
  auto repeating keys:  0000000000000000
                        0000c0ffffffffff
                        ffffffffff27f8ff
                        ffffffffffffffff
  bell percent:  0    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  7/1    threshold:  3
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600
Colors:
  default colormap:  0x21    BlackPixel:  0    WhitePixel:  1
Font Path:
DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR32],DECW$SYSCOMMON:[SYSFONT.DECW.CURSOR16],
DECW$SYSCOMMON:[SYSFONT.DECW.100DPI],DECW$SYSCOMMON:[SYSFONT.DECW.75DPI],
DECW$SYSCOMMON:[SYSFONT.DECW.USER_COMMON],DECW$SYSCOMMON:[SYSFONT.DECW.COMMON],
DECW$SYSCOMMON:[SYSFONT.DECW.SPEEDO],DECW$SYSCOMMON:[SYSFONT.DECW.TYPE1],
DECW$SYSCOMMON:[SYSFONT.DECW.TRUETYPE],CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.100DPI],
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.75DPI],CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C]
Bug Mode: compatibility mode is enabled

Magic Cookie was designed to provide a more secure alternative to the host-based security mechanism available in previous releases of the X Window System. The first protocol to use a token-based approach, it provided the initial, standard means for restricting access to the X display server on a user level.

Magic cookie authorizes connections to a server based on a client presenting a binary numeric value, known as a cookie, to the server. Normally, the client obtains this cookie value from an X authority file; however, some programs may use alternate mechanisms.

When Magic Cookie is used to authorize connections during a VSI DECwindows Motif for OpenVMS session, a cookie is generated each time a user successfully logs into their local VSI DECwindows Motif for OpenVMS desktop. The magic cookie authorizing the local connection, along with the device,transport, and protocol name is passed to the X display server and stored in the current X authority file (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH).

Each time a client application attempts to connect to the display server during the session, the application must present a valid cookie to the server along with the connection request. If the cookie matches any one of the cookies maintained by the X display server, the connection is authorized, access is granted, and the display is opened. When the user logs out of the VSI DECwindows Motif for OpenVMS session, the server is reset, and the cookie is discarded.

Due to the use of a randomly-generated value, Magic Cookie provides a more secure form of access control than the user-based scheme. However, the cookies are sent across the network unencrypted, leaving them prone to interception. As a result, this form of access control is recommended for authorizing connections across local area networks (LANs), limited DECnet environments, across TCP/IP networks that have been secured using another form of protection.

Kerberos credentials, or tickets, are a set of electronic information that can be used to verify the identity of a principal.These principals are stored in an Authorized Principals list kept on the server system. With Kerberos, client applications run by a valid principal send requests for a ticket from the Kerberos Key Distribution Center (KDC) each time they attempt to connect to the Kerberos-protected X display server.

Once Kerberos access control is enabled on the server, a new ticket is requested from the KDC automatically each time a user logs into their local desktop. The KDC creates a ticket-granting ticket (TGT) associated with the user's principal name, encrypts it using the password as the key, and returns the encrypted TGT.

If the TGT is decrypted successfully, the user is authenticated and the TGT is cached. The TGT permits the authenticated principal to obtain additional tickets. These additional tickets grant access to specific services, in this case, access to the X display server from other client applications. The requesting and granting of these additional tickets happens transparently.

With VSI DECwindows Motif for OpenVMS, user-to-user authentication is employed. In this model, both the client and server use a Kerberos client at each end of the connection to verify the identify of the user (principal). Once the principal is authenticated at both ends of the connection, access is granted to the server.

By default, each TGT expires at a specified time. If a TGT has expired or been compromised, you can choose to revoke the current TGT and generate a new TGT by forcing a Kerberos login.

Enabling access control outside of a VSI DECwindows Motif for OpenVMS desktop session allows authorized OpenVMS users to run client applications on systems without a login process. This type of access control is used typically for systems that function as a standalone X display server, rather than an interactive VSI DECwindows Motif for OpenVMS workstation.

Use the server customization parameters and either the access allowed file or X authority file to set access control.

Use the Security Options dialog box to set the access control scheme in effect inside a VSI DECwindows Motif for OpenVMS session. The options in the dialog box enable you to set the access control scheme used by the local X display server,to authorize other users access to the display server, and to specify the scheme local client applications use when connecting to a display server.

$ decw$server_extensions == "SEC_XAG"

Save the file and restart the server.

The security policy file enables you to configure the server to allow certain actions (at the X atom level) to be performed over untrusted network connections. This file establishes one or more site policies that specify the set of allowable actions through a series of field definitions.

A sample file has been provided with VSI DECwindows Motif for OpenVMS and is located in DECW$EXAMPLES:DECW$SECURITY_POLICY.TXT. Use this file as a template when creating a policy file. Security policies are described in the Security Extension Specification published by the X. Org Foundation. Refer to this specification for details regarding the use and definition of security policies.

XINERAMA is supported only in a homogeneous graphics environment. Each multihead configuration must consist of common video cards, bit depths, visual classes, screen resolutions, and monitors of a similar size. The monitors must also be arranged into a rectangle–without gaps in between.

See the VSI DECwindows Motif for OpenVMS Software Product Description for a list of the currently supported video graphics cards; see Section 3.1.2.4 for a description of the logicals you can use to change the default values for these graphics settings.

The display server supports up to 16 monitors in a multihead configuration. Note that the actual number of monitors you can use may be further limited by the number of available option card slots.

Although this extension is part of the X display server, it is not enabled by default.

$ DECW$SERVER_EXTENSIONS == "DEC-XTRAP,XINERAMA"

Save the file and restart the server.

By default, the system uses the physical location of the video cards on the system bus to assign the device names (such as, GYA0, GYB0, etc.). The devices are subsequently assigned screen numbers and initialized in alphabetical order according to device name.

For example in a four-monitor multihead configuration, if you have connected the cables to the video cards in the proper order and placed the monitors side-by-side, the screens should be numbered in either ascending (0, 1, 2, 3) or descending (3, 2, 1, 0) order.

These parameters control where each edge of the virtual display is attached.

When the setup process is complete, all the monitors should be active and organized in the proper arrangement. Once you restart VSI DECwindows Motif for OpenVMS,the login dialog box for the session is displayed at the center of the virtual display, and you should be able to open application windows and drag them from screen to screen.

The X display server maintains a database of X keyboard components and common keyboard mappings. When combined, these components provide a complete description of a keyboard and its behavior.

The server loads the database from the compiled keymap file specified by the DECW$SERVER_XKEYBOARD_MAP parameter. This file is located in the directory defined by the DECW$SERVER_XKEYBOARD_COMPILED_DIR parameter. If the compiled keymap file does not exist, the server runs the xkbcomp utility to compile the file from its component sources.

You can then load the modified, compiled keymap file as described in Section 3.5.2.3.

Once euro support is enabled on your system, you can display the euro sign with any ISO8859-1 bitmap font on your workstation, with no additional setup. VSI DECwindows Motif for OpenVMS applications that use standard ISO Latin-1 fonts to display text will display the euro sign for character 0xA4. The character set portion of the X Logical Font Description (XLFD) name for these fonts is ISO8859-1.

When the proxy server connects to an X server, the proxy server undergoes authentication in the same manner as a client. How the proxy server obtains its authentication information depends on the type of proxy server.

A managed proxy server obtains its authentication information from the proxy manager. The proxy manager in turn receives the authentication information from the client. The client's default authentication information is contained in the client's X authority file. The client can control which X authority file is used by using the /XAUTHORITY qualifier to the SET DISPLAY command. The client can supply explicit authentication information on the SET DISPLAY command using the /LBXAUTHENTICATE and /LBXDATA qualifiers. The client also has the option of using the /NOLBXAUTHENTICATE qualifier to specify that the authentication information come from the proxy server's current X authority file. For more information about the SET DISPLAY command qualifiers for LBX, see VSI OpenVMS DCL Dictionary: N-Z.

A standalone proxy server obtains its authentication information from the information present in the current X authority file.

LBX MANAGED COMMAND SYS$MANAGER:DECW$LBXPROXY_SUB ["qualifiers"]

After the proxy manager is configured, no specific action is required to start the proxy server; the proxy manager starts the server when the manager receives the first client request.

LBXPROXY [qualifiers]

$ LBXPROXY /DISPLAY="REMOTE1.CMP.COM:0"/SERVER=50/FIXED_SERVER

@SYS$MANAGER:DECW$LBXPROXY ["lbxproxy-qualifiers"] ["run-qualifiers"]

$ @SYS$MANAGER:DECW$LBXPROXY "/DISPLAY=""REMOTE1.CMP.COM:0""" + -
_$ "/SERVER=50/FIXED_SERVER"

Use the run-qualifiers parameter to pass any qualifiers to the RUN command used to invoke the LBXPROXY image. One use of this parameter might be to override the default LBXPROXY process characteristics or any values set by the logicals provided to modify these defaults.

To stop an LBX proxy server automatically, use the /ONEXIT=TERMINATE qualifier when you start the server. For standalone proxy servers, specify this qualifier either on the LBXPROXY command line or in the lbxproxy-qualifiers parameter of the SYS$MANAGER:DECW$LBXPROXY command procedure.

To stop an LBX proxy server manually, use the DCL STOP command.

To start the proxy manager at VSI DECwindows Motif for OpenVMS startup, edit the SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM file. For more information on customizing the Session Manager environment, see Chapter 4.

XPROXYMANAGER [qualifiers]

$ XPROXYMANAGER/CONFIGURATION=SYS$MANAGER:DECW$LBXPROXY.DECW$PMCFG -
_$ /LOG=SYS$MANAGER:DECW$PM.LOG

See the online help for the XPROXYMANAGER command to learn more about the available qualifiers and their values.

These logicals can be defined system-wide by adding them to the SYS$MANAGER:SYLOGICALS.COM file, or defined on a per-user basis by adding them to each user's DECW$LOGIN.COM or LOGIN.COM file.

To force the File Selection dialog box to return selected filenames in OpenVMS format while displaying them in UNIX format, define the logical DECW$XM_UNIX_NAMES_TO_VMS. This enables other applications that rely on filenames in OpenVMS format to interact successfully with the File Selection dialog box while still displaying filenames in UNIX format.

To enable the display of UNIX-style filenames in the File Manager,set the logical CDE$DTFILE_UNIX_NAMES to a non-zero value.

This logical can be defined system-wide by adding it to the SYS$MANAGER:SYLOGICALS.COM file, or defined on a per-user basis by adding it to each user's DECW$LOGIN.COM or LOGIN.COM file.

You can define the global symbol DECW$SESSIONCOM in the SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM file so that when a user logs in, LOGINOUT runs a command file other than DECW$STARTSM.COM. This action bypasses Session Manager altogether.

In Example 4.1, DECW$SESSIONCOM is defined in DECW$PRIVATE_APPS_SETUP.COM to point to the private command procedure SYS$MANAGER: PRIVATE_SESSIONCOM.COM. The default command file is SYS$MANAGER:DECW$STARTSM.COM.

You can define DECW$SESSIONMAIN in the SYS$MANAGER: DECW$PRIVATE_APPS_SETUP.COM file so that DECW$STARTSM.COM runs the specified command file instead of DECW$SESSION.EXE. Session Manager reads resource files and runs login command files but does not display the Session Manager menu bar. With this method, ensure that the End Session command does not prompt for confirmation.

When DECW$STARTSM.COM starts (that is, if DECW$SESSIONCOM has its default value), it starts Session Manager by running the DCL command that is stored in the logical name DECW$SESSIONMAIN. To define this logical name, edit SYS$MANAGER: PRIVATE_APPS_SETUP.COM so that it defines the global symbol DECW$SESSIONMAIN as the DCL command to execute.

This method is similar to the one described in the Section 4.4.7.1except that, with this method, DECW$STARTSM.COM executes the SYLOGIN.COM,LOGIN.COM, DECW$SYLOGIN.COM, and DECW$LOGIN.COM command procedures. Also, DECW$STARTSM.COM executes DECW$WSINIT.EXE, so the private command procedure does not need to do so.

After entering the user name and password of the dedicated account,Bookreader starts and the Session Manager menu bar is not displayed. When the user exits Bookreader, the PRIVATE_SESSIONMAIN.COM procedure performs an End Session operation and then logs out. The End Session command displays a DECwindows Start Session screen.

This method starts Session Manager normally, but the system manager customizes its menus to remove any applications that are not started automatically. By removing certain applications, you can limit user access to applications.

With this method, the Session Manager menu bar is displayed, and the user can interact with whatever dialog boxes the system manager does not disable.

To test your changes, log in to the dedicated account from the DECwindows login box. Bookreader and Session Manager should start up by default, and you should not be able to start any other application. To log out, choose End Session from the Session Manager menu.

If you decide to make the account non dedicated again, or if you want to make changes in a dialog box that you have removed from the system menu bar,delete or rename the file VUE$PROFILE.VUE$DAT in the dedicated account's SYS$LOGIN directory.