| <<< disk$spex:[leslie.hack]dw.note >>>
-< DECWindows Standard Pgm Environment: REBORN >-
================================================================================
Note 38.0 the VMS 5.1 SPD No replies
CSSE32::MERMELL "Tastevin en Main" 2009 lines 26-JAN-1989 18:57
--------------------------------------------------------------------------------
(note 13.0 is write locked so I couldn't reply to it)
From: STAR::BECKER "Amy Becker ZK3-4/T61 381-1077 06-Jan-1989 1628" 6-JAN-1989 16:31
To: CSSE32::MERMELL,CSSE32::DORSEY,CSSE32::FRAZIER,CSSE32::BATES
CC: BECKER
Subj: Here is a copy of the VMS 5.1 SPD
PRODUCT NAME: VMS Operating System, Version 5.1 SPD 25.01.31
DESCRIPTION
System Overview
VMS is a general purpose multiuser operating system which supports VAX,
MicroVAX, and VAXstation series computers. It works reliably and
efficiently in both development and production environments. VMS can be
tuned to perform well in a wide variety of applications, including
compute-intensive, I/O-intensive, real-time, and combinations of those and
other environments. (The actual amount of work supported with good
performance depends upon the processor type, available physical memory, and
secondary storage operations.)
VMS has well-integrated networking, distributed computing, multiprocessing
and windowing capabilities. VMS contains extensive features that promote
ease-of-use, improve the productivity of programmers and facilitate system
management.
User Environment
General Access
Users may access VMS by using the English-like DIGITAL Command Language
(DCL), the standard command language for VMS which is supplied with the
system. DCL commands take the form of a command name followed by parameters
and qualifiers.
DCL commands can be entered from a terminal or can be included in command
procedures. Command procedures may be invoked directly in an
interactive session of may be submitted to a batch queue for deferred
execution. DCL commands provide information about the system, initiate
system utilities, and initiate user programs.
DCL and VMS Utilities have a consistent integrated help subsystem to provide
summary operational information on all aspects of system operation.
Tools and Utilities
VMS provides a number of tools and utilities for general users, programmers
and system managers. This section briefly describes each group of tools
and utilities.
General User
Text processing - The Extensible VAX Editor (EVE) is one of several text
editors supplied by DIGITAL and it permits the user to quickly insert and
delete text. EVE is a full screen editor that allows the text to be scrolled
on the screen of an interactive terminal. EVE is written in the Text
Processing Utility (TPU) language. EVE provides an EDT-style keypad.
Mail facility - The Mail facility permits a user to send messages to any
other user by typing the recipient's name, the subject of the message, and the
text of the message. Multi-node operation is available if DECnet-VAX is
installed.
Command-level programming - Command-level programming allows the user to
create special files called command procedures that contain a series of
DCL commands. When a user invokes a command procedure, the system processes
the commands in the command procedure. The user can also use special DCL
commands to assign symbolic names, evaluate numerical and logical expressions,
accept parameters, communicate interactively with the user invoking the
command procedure, perform conditional (IF-THEN-ELSE) and branching (GOTO)
logic, and handle error conditions.
User Environment Tailoring - VMS allows user tailoring of their environment,
including user specific login command files, shorthand commands, binding
of commands to function keys, and command recall and editing.
Other utilities include Sort/Merge, DIRECTORY, COPY, DELETE, TYPE, PRINT,
PURGE, RENAME and SET/SHOW status.
Programmer
Librarian utility - The Librarian utility permits efficient storage of
object modules, macros, help text, or any general record-oriented information
in central, easily accessible files. Object module libraries are searched
by the linker when the linker finds a reference it cannot resolve in one
of its input files. Macro libraries are searched by the assembler when the
assembler finds a macro that is not defined in the input file.
Symbolic debugger - The symbolic debugger helps the user trace program
execution and allows a user to display and modify register contents using
the same symbols that are in the source code.
RMS file utilities - RMS file utilities allow the user to analyze the
internal structure of an RMS file. They can help the user determine the most
appropriate set of parameters for an RMS file, and how to create,
efficiently load, and reclaim space in an RMS file. (Refer to ``VMS Record
Management Services'' section of this SPD for more information on RMS.)
File differences utility - This utility compares the contents of two
files and lists those records that do not match.
Terminal Fallback Facility (TFF) - This facility allows DEC 7bit terminals,
such as the VT100, to input and output the DEC Multinational Character Set
(MCS). Specific tables allow conversion for a number of different
7bit National Replacement Character sets, such as French, German, Spanish
and Swedish, to MCS. TFF also allows character composing on terminals
without use of the compose key.
National Character Set (NCS) utility - This utility allows the user to
define non-ASCII standard string collating sequences and to define
conversion functions. Conversion functions use conversion algorithms
to change an input string, for example, change lower case characters to
upper case. NCS also allows RMS indexed files to be collated via
user-specified collating sequences.
System Manager
Backup - This utility provides full volume and incremental file backup for
file-structured, mounted volumes and volume sets. Individual files, selected
directory structures, or all files on a volume set can be backed up and
restored using standard file naming conventions and can be selected by date.
Files can be backed up to magnetic tape or to another disk. You can back
up and restore selected files using on-line backup or entire volumes
using standalone backup.
Analyze disk structure - This utility compares the structure information on
a disk volume with the contents of the disk, prints the structure
information, and permits changes to that information.
MONITOR - This utility permits the system manager to monitor different
classes of systemwide performance data (for example, process activity, I/O
activity, and memory management activity) at user-specified intervals. The
data may be displayed as it is gathered or saved in a file for later use.
License Management Facility (LMF) - This facility allows the system manager
to easily determine which software products are licensed and installed on
a standalone VAX and on each of the VAX systems in a VAXcluster System.
It allows the system manager to limit use of the software products to a
subset of systems in a VAXcluster and it provides an audit trail which
allows the system manager to track license changes that occur within a
VAXcluster system. Refer to the section entitled ``VAXcluster Support ''
for more information on VAXcluster Systems.
VMS System Management (SYSMAN) Utility - This utility allows the system
manager to define a system management environment so that operations
performed from the local VAX system are executed on all other
VAX systems in the defined environment. The environment may include VAX
systems in a DECnet-VAX network or in a VAXcluster System.
Program Development
VMS provides a comprehensive set of tools for developing programs including
editors (such as EVE for editing source programs), a linker, a librarian,
and a symbolic debugger. The assembly-level VAX MACRO language is supplied
with VMS.
The VMS Run-Time Library provides general string manipulation, Input/Output
(I/O), I/O conversion, terminal independent screen handling, date and time
formatting routines, common mathematical functions, signaling and condition
handling, and other general purpose functions. These routines can be called
from programs written in VAX MACRO or from VAX Ada, VAX BASIC, BLISS-32
Implementation Language, VAX C, VAX COBOL, VAX DIBOL, VAX FORTRAN,
VAX PASCAL, VAX PL/I, VAX RPG, and VAX SCAN.
Major VAX languages (including those listed above adhere to the VAX
common calling standard, meaning that routines written in any of
these languages may directly call routines written in any other
language. Development of applications using multiple languages is
simple and straightforward.
All routines in the run-time library follow standard call and condition
handling conventions and most are contained within a shareable image.
At a lower level, programs can call system services directly for security,
event flag, asynchronous system trap, logical name, record and file I/O,
process control, timer, time conversion, condition handling, lock
management, and memory management services. Again, system services use
standard call and condition handling conventions.
VMS supports execution of non-privileged images created on earlier versions
of VMS. Recompiling and relinking are in general not required.
System Management
Security and Control
VMS provides privilege, protection, and quota mechanisms to control
user access to system-controlled structures in physical structures in
physical memory, system-structured files and volumes, and certain devices.
The system maintains information about user accounts in the user
authorization file (UAF), which can be modified by the system manager.
When creating user accounts with the Authorize Utility, the system manager
assigns the privileges and quotas associated with each user account. The
system manager also assigns a unique user name, password, and user
identification code (UIC) to each account. Optionally, additional
identifiers may be assigned to each account, permitting users to
belong to multiple overlapping groups or projects. Account use may be
limited by time of day, day of week and type of access, such as local
vs. remote vs. batch.
To log in and gain access to the system, the user must supply the
user name and password. The password is encoded and does not appear on
terminal displays. Users can change their password voluntarily, or the
system manager can selectively enforce password length, change
frequency, and generation of pronounceable nonsense passwords.
Login security includes breakin detection, which allows terminals
to be disabled when password guessing is detected. When a user
logs in, the system displays a message stating when the last
login for the account occurred.
A UIC consists of two fields, the unique user field and a group field.
Every file, device, queue, or other system object is labeled with the
UIC of its owner (normally the user who created the object).
Files, devices, queues, and other system objects are assigned a
protection mask which allows read, execute, write, and delete access
to be selectively granted to the object's owner and group, to
privileged system users, and to all other users. In addition, files,
devices, queues, and some other system objects may be protected with
access control lists to allow access to be selectively granted or
denied to a list of individual users, groups or identifiers.
Scavenge protection may be selectively enabled in the form of file
high-water marking, erase on allocate, and erase on delete, to ensure
that file contents cannot be read after the file has been deleted.
Security alarms are provided to allow selective auditing of security
related events, including
^ Login and logout
^ Login failures and breakin attempts
^ Authorization changes
^ File access, selectable by use of privilege, type of access, and by
individual file
Note that DIGITAL does not warrant that the system is secure, although
DIGITAL will fix security problems brought to our attention as
promptly as circumstances warrant.
Tailoring Facility
Tailoring allows users to have access to the entire VMS operating system
while providing a compact version of the operating system on the system
disk that is tailored to the users' needs. Tailoring is supported on
processors with small disk configuration. VMS upgrade procedures are not
supported in tailored environments.
Due to space constraints, there is no guarantee that products can be
installed if user code and data reside on the system disk. Application
programs will execute as long as the layered products or optional
software DO NOT DEPEND on optional software run-time components that are
not supported in the tailored environment. Refer to the product's
System Support Addendum (SSA) for the optional products supported in
the tailored environment.
Installation
VMS is distributed as binary kits on tape, disk, or CDROM. Procedures
for setting up the system disk from a kit and for preparing the system
for day-to-day operations are simple and straightforward. The procedures are
described in the installation and operation guide for each processor.
Batch/Print Facility
VMS provides an extensive batch/print facility which allows the creation
of queues and spooled devices in order to process non-interactive workloads
in parallel with timesharing or real-time jobs.
The system queues batch jobs for execution. The system manager
can regulate the number of queues and the number of streams per
queue (that is, the number of batch jobs in the queue that can
execute concurrently).
Different batch job queues may have different attributes such as
the maximum CPU time permitted, working set size, and priority.
Facilities are provided for starting and stopping queues, as well
as the jobs in a queue.
Print queues, both generic and specific (with forms recognition)
together with queue management facilities give the user versatile
print capabilities.
Accounting
For accounting purposes, VMS keeps records of the use of system resources.
These statistics include processor and memory utilization, I/O counts,
print symbiont line counts, image activation counts, and process
termination records.
Autoconfigure/Autogen
VMS provides utilities to automatically configure the available
devices into the system tables, and to set system operational
parameters based on the detected peripheral and memory configuration.
There is no need for a traditional "system generation" process
when the hardware configuration is expanded or otherwise modified.
VMSINSTAL
VMS includes an facility to automate operating system software
updates, as well as handle the installation of optional DIGITAL-supplied
software products.
System Environment
Process and Scheduling
The basic unit of execution in VMS is the process which consists of
individual address space and registers known as ``context'' and code
called an ``executable image.'' The context identifies the process
and describes its current state. Executable images consist of system
programs and user programs that have been compiled and linked.
The maximum number of concurrent processes is 8192 per VAX system.
Processes receive processor time to execute their images based on the
priority of the process. Thirty-two priorities are recognized:
Priorities 0-15 are for time-sharing processes and applications
that are not time critical (four is the typical default for time-sharing
processes) and priorities 16-31 are for real-time processes.
Each time an event such as an I/O interrupt occurs, the system first services
the event then passes control to the highest priority process ready to
execute. The system automatically adjusts priorities of processes whose base
priority is in the range of 0 to 15 to favor I/O-bound processes, but the
system will not adjust the priority of a process in the range of 16 to 31.
Real-time processes can be assigned higher priorities to ensure that they
receive processor time whenever they are ready to execute. Real-time
processes are scheduled pre-emptively; that is, if a real-time process is
ready to execute, it is given the processor immediately, unless
a real-time process with a higher priority is ready to execute.
VMS uses paging and swapping mechanisms to provide sufficient physical memory
for both multiple concurrently executing processes and for processes whose
memory requirements exceed available physical memory. The maximum working
set size is 100,000 pages of memory.
Processes can, however, exercise control over memory management. A real-time
process, for example, can inhibit paging or swapping of critical code and data.
Peripheral devices can be managed by the system or allocated by individual
processes. At least one disk must be a system disk. Other disks can be
designated as data disks for the general use of all users logging into the
system or for a group of users. Interactive terminals are controlled by the
system, and the system normally controls one or more printers.
Interprocess Communication
VMS provides a number of facilities for application that consist of
multiple cooperating processes:
^ Mailboxes are virtual devices that allow processes to communicate
with queued messages.
^ Shared memory sections permit multiple processes concurrent access
to shared address space.
^ Common event flags provide simple synchronization.
^ The lock manager provides a more comprehensive enqueue/dequeue
facility with multi-level locks, values, and ASTs.
Symmetric Multiprocessing
VMS provides symmetric multiprocessing (SMP) support for multiprocessor
VAX systems. SMP is a form of tightly coupled multiprocessing in which
all processors perform operations simultaneously. The processors can
perform operations in all VAX access modes (user, supervisor,
executive, and kernel).
VMS SMP configurations consist of multiple central processing units
executing code from a single shared memory address space. Users and
processes share a single copy of VMS. SMP also provides simultaneous shared
access to common data in global sections to all processors. VMS SMP
dynamically balances the execution of all processes across all available
processors based on process priority.
SMP support is an integral part of VMS and is provided transparently to
the user. Because an SMP system is a single system entity, it is configured
into a network and VAXcluster systems as a single node.
VAXcluster Support
A VAXcluster system is formed by coupling a VAX processor with mass-storage
servers or with other VAX systems, and, optionally, with mass storage
servers known as ``Hierarchical Storage Controllers'' (HSCs). These
cooperating, independent processors may share a single disk-resident copy of
VMS, RMS data down to the record level, and locally attached or HSC-based
disks. VAXcluster systems provide data sharing and easy incremental growth,
and may be configured to provide high availability computing environments.
Refer to VAXcluster Software (SPD 29.78.xx) for more information.
Networking Facilities
VMS provides device drivers for all DIGITAL Ethernet adapters listed below.
Application programmers can use the QIO system service to communicate with
other systems connected via the Ethernet using either Ethernet or IEEE 802.3
packet format. Simultaneous use of DIGITAL Ethernet and IEEE 802.3 protocols
are supported on any DIGITAL Ethernet adapter. Refer to the DECnet-VAX
Software Product Description (SPD 25.03.xx) for further information on
supported communications devices.
DIGITAL's terminal server products can be used for terminal access to VMS.
When used in a VAXcluster System environment, terminal servers automatically
distribute users, at login time, across the available VAX systems.
VMS can also establish a connection to other devices (such as printers)
attached to such terminal servers.
DECnet-VAX offers task-to-task communications, file management, downline
system and task loading, network command terminals, and network resource
sharing capabilities using the DIGITAL Network Architecture (DNA) protocols.
Refer to DECnet-VAX (SPD 25.03.xx) for more information on this product.
Reliability
The system handles errors as transparently as possible while maintaining
data integrity and providing sufficient information to diagnose the
errors. The system limits the effects of an error by first attempting
to recover from the error; then if recovery fails, by reporting the error
to the current process for action; and finally (if the error cannot be
clearly bounded), by shutting down and restarting the system. VMS will
shut itself down rather than continue operating with a condition that
could propagate undetected bad data. The types of errors possible
are as follows:
^ Processor errors (machine checks)
^ Operating system errors (system errors or undetected hardware failures)
^ User errors
^ Memory errors (The system examines memory at start-up time and does
not use any pages found to be bad. During system operation, the
hardware transparently corrects all single-bit memory errors, for
those systems with ECC memory. An unrecoverable error causes the memory
page on which the error occurred to be added to the bad page list; if
the page has not been modified, system operation continues with a
new copy of the page.)
^ I/O errors
The system logs all processor errors, all operating system errors detected
through internal consistency checks, all double-bit memory errors (and a
summary of corrected single-bit errors), and all I/O errors. (Double-bit
errors are detected only on those VAX and MicroVAX systems with ECC memory.)
If the system is shut down because of an unrecoverable hardware or software
error, a dump of physical memory is written; the dump includes the contents
of the processor registers. The VMS System Dump Analyzer utility is
provided for analyzing dumps.
If power fails, the system shuts down automatically. When power is restored,
the system restarts automatically and resumes processing at the point of
interruption if the system has a time-of-day clock and a memory battery
back-up unit, if the contents of memory are still valid and if the system
is set to permit automatic re-booting. The system restarts devices and
communications lines. All I/O operations i
|
| Final draft of DECwindows sales update article. (Permission to post given
by Paul Steeves)
V M S P R O D U C T M A N A G E M E N T
VMS V5.1
Lynn Moore Amy Becker
DTN: 381-0615 DTN: 381-1077
ZK3-4/T61 ZK3-4/T61
+---------------------------------------------------------------
VMS V5.1 will be shipped to all Software Product Service
Customers in February
VMS Decwindows is an integral part
VAX 6300 Series support is included
VMS includes the VAX Rdb/VMS Run-time license
+-----------------------------------------------------------------
VMS V5.1 will be shipping to Software Product Services
customers in February. This is the first major
update to VMS Version 5.0. Integral to VMS Version 5.1
is support for the VMS DECwindows desktop environment,
and support for the new VAX 6300 series systems.
VMS DECwindows
The VMS DECwindows desktop environment provides a new
user interface to VMS and promotes the establishment
of a consistent style of graphical VMS user interface.
A new set of integrated desktop applications promotes
the establishment of a consistent style of graphical
VMS user interface by including a new set of integrated
desktop applications, providing tools and routines which
allow developers to create applications which follow that
style, and by having made available a "DECwindows Style
Guide" which assists developers in creating consistent
applications.
[See Sales Update Jan 9,1989]
A separate article on VMS DECwindows performance also
appears in this issue of sales update.
VAX 6300 SERIES
The VAX 6300 series systems support is included with
VMS V5.1. The VAX 6300 series is the follow-on to the
VAX 6200 series. The TK50 is the only distribution media
for the VAX 6300 series. The order numbers are:
QA-001AC-H5 VMS media and Extended Documentation kit
QA-09SAD-H5 VMS media and Base Documentation Kit
MicroVAX 3300/3400
The MicroVAX 3300/3400 systems are supported with the same
TK50 distribution kits as the VAX 6300 series (QA-001AC-H5
and QA-09SAD-H5). In addition, the MicroVAX 3300/3400
support is distributed on magnetic tape (16MT9). The
order numbers are:
QA-001AK-HM VMS Media and Extended Documentation Kit
QA-09SAK-HM VMS Media and Base Documentation Kit
MULTIPLE VERSION CLUSTERS
Multiple version clusters will be supported for customers
running CI based VAXcluster configurations. This means a CI
based VAXcluster configuration may run VMS V4.7, VMS V5.0,
VMS V5.0-1, VMS V5.0-2 and VMS V5.1 concurrently for upgrade
purposes. This is documented in the VMS documentation as
the 'rolling upgrade'. Please note that running a multiple
version cluster is intended to be a temporary state and that
a complete upgrade is recommended.
UPDATING
Updating to VMS Version 5.1 requires that system are
running VMS Version 5.0-2. If any other version of VMS
is running the system needs to be updated to VMS Version
5.0-2 before proceeding with the installation of Version 5.1.
(Note: VMS V5.0-1, V5.0-2 and V5.1 are included on the
the large media, see MEDIA KITS)
VMS and VAX Rdb/VMS Run-time (license)
Beginning with the first customer ship of VMS V5.1, customers
no longer need to purchase a license for VAX Rdb/VMS Run-time
System. The license for VAX Rdb/VMS Run-time is now automatically
granted under the VAX/VMS license at no additional charge. The
VAX Rdb/VMS Run-time software is a subset of the full VAX Rdb/VMS
product, providing the ability to execute previously developed
applications which use VAX Rdb/VMS. It is intended for customers
who buy ready-made solutions built on Rdb/VMS.
The VAX Rdb/VMS Run-time Software, Documentation, and Software
Product Services are ordered separately.
DOCUMENTATION
VMS Version 5.1 documentation includes the following
new documentation:
o The VMS Version 5.1 Installation Guide, which de-
scribes how to update your system to VMS Version 5.1
and how to install the VMS DECwindows software.
o The VMS Version 5.1 Release Notes, which supple-
ments the VMS Version 5.0 Release Notes and the VMS
Version 5.1 New Features Manual, which describes
enhancements to VMS to support VMS DECwindows and the
Compound Document Architecture (CDA).
o The VMS DECwindows User Documentation Kit, which
describes how to use the new graphical worksta-
tion interface to VMS and is now part of the VMS
Documentation Base Set. It contains the following books:
QA-09SAB-GZ Decwindows User's Doc Kit
o Overview of VMS DECwindows
o VMS DECwindows User's Guide
o VMS DECwindows Desktop Applications Guide
o An optional VMS DECwindows Programming Documentation
Kit that provides reference and tutorial descrip-
tions of the VMS DECwindows programming libraries
and the CDA programming library. This optional kit
must be ordered separately. It contains the following
books:
Volume 1
o VMS DECwindows Guide to Application Programming
o VMS DECwindows User Interface Language Reference Manual
o VMS DECwindows Toolkit Routines Reference Manual
o XUI Style Guide
Volume 2
o VMS DECwindows Guide to Xlib Programming: VAX Binding
o VMS DECwindows Guide to Xlib Programming: MIT C Binding
o VMS DECwindows Xlib Routines Reference Manual
Volume 3
o VMS DECwindows Device Driver Manual
o VMS Compound Document Architecture Manual
Ordering information:
QA-001AM-GZ Decwindows Programming Doc Kit
QA-001A5-GZ Decwindows Prog Doc Kit Vol. 1
QA-001A6-GZ Decwindows Prog Doc Kit Vol. 2
QA-001A7-GZ Decwindows Prog Doc Kit Vol. 3
Online Documentation
The VMS DECwindows Online Documentation Set is available on
compact disc. The online documentation files are for use with
the Bookreader application, which is included as part of the
VMS DECwindows software. The compact disc includes both the
VMS DECwindows User Documentation Kit and the VMS DECwindows
Programming Documentation Kit. The order number for the VMS
DECwindows Online Documentation on compact disc is:
QA-VP4AA-G8 VMS DECwindows Online Documentation
MEDIA KITS
The VMS Version 5.1 kit includes:
o VMS Version 5.0 Media and Documentation Kit
o VMS Version 5.1 Media and Documentation Major Update
o This major Update is being shipped on large media
and RX33s.
Note: The large media (RA60, compact disc,
magnetic tape, TK50, RK07, and RL02)
contains VMS Versions 5.0-1, 5.0-2,
and 5.1 as well as VMS DECwindows
software. However, these releases are
provided on multiple RX33s.
DECwindows Packaging
VMS DECwindows is packaged as an integral part of VMS.
As such, it is distributed as a separate saveset on
the VMS 5.1 distribution media.
No license other than the VMS license is required, and
no extra cost is incurred by the customer.
There are two packaging corrections to the January 9th Sales Update
that pertain to Software Product Service (SPS) customers:
1.) Software Product Service customers WILL receive user
documentation.
The January 9 Sales Update incorrectly states that they
will not.
2.) The DECwindow software is only distributed on CDROM , TK50
RA60 and Magtape distributions due to size constraints.
Customers under SPS service contract for other media types
received either a Magtape or TK50 with the DECwindows software.
The size of the 5.1 update with DECwindows software
makes distributing on certain media types, such as RL02,
RK07, RX33 unfeasible.
The 5.1 software without the DECwindows saveset will be
distributed to service customers with RL02, RK07, and
RX33 media types on these media types.
However, RL02, RK07, and RX33 distribution customers will
also AUTOMATICALLY receive a magtape or TK50 containing
the DECwindows software. (These tapes contain the entire
5.1 distribution --- 5.0-1, 5.0-2, 5.1, and DECwindows).
The January 9 Sales Update incorrectly states that customers
must request this extra tape.
|
| Final draft of sales update article on DECwindows performance. Permission
to post given by Paul Steeves, VMS Product Management.
VMS DECWINDOWS PERFORMANCE
The purpose of this article is to present an overview of some of the key
performance characteristics of VMS DECwindows. It is oriented toward system
configuration issues rather than toward measurements and timings of graphics
and user interface primitive operations. Using a question-and-answer format,
it will help you to understand the performance differences between workstations
with different CPU's and different memory configurations.
WHAT IS DECWINDOWS?
DECwindows is Digital's new computing environment based on the industry
standard X Window System (tm) developed at MIT by several vendors including
Digital. DECwindows provides software developers with the ability to develop
and run distributed graphical applications in a heterogenous network
environment. This is accomplished by implementing the server-client model
defined by the X standard. In addition to providing a programming environment
for building applications, the DECwindows product includes a number of
so-called "out of the box" applications.
This article assumes that the reader has read the "Overview of VMS DECwindows".
HOW DOES THE PERFORMANCE OF VMS DECWINDOWS COMPARE TO THAT OF THE MIT VERSION?
The DECwindows server has implemented many performance improvements over
the standard X system available from MIT. Comparisons were done between
a field test version of VMS DECwindows and the MIT X11 (Release 2) software.
It showed significant improvements in the VMS version in almost all important
graphics and windowing primitives.
HOW DO THE VMS AND ULTRIX VERSIONS COMPARE?
Best case user-interface performance of DECwindows is very similar on
Ultrix and VMS, when run on identical hardware platforms. This conclusion
is based on data gathered on a recent DECwindows field test version. However,
this does not include page-faulting activity, disk I/O, and other operating
system-specific activities, which will impact user perceptions of performance.
HOW IMPORTANT IS MEMORY TO VMS DECWINDOWS PERFORMANCE?
Memory is the most significant hardware resource in a VMS DECwindows
workstation. With sufficient memory, applications will perform reasonably
with either a VAXstation-2000 class machine or a VAXstation-3000 class
machine. But with insufficient memory, application performance can become
unacceptable on either type of machine.
The vast flexibility and common "look and feel" of the DECwindows user
interface comes at a price -- it costs memory. For example, VMS DECwindows
has a richer user interface than VWS (UIS), but it requires more memory to
achieve comparable performance. DECwindows is built upon the X server-client
model and the X toolkit programming interface. This object-oriented design
is inherently expensive in its memory consumption, particularly for dynamic
data structures. These structures contain the data necessary to represent
objects and their characteristics. In DECwindows, these objects are "widgets"
and windows. The more capabilities an application has, the more widgets and
windows it is likely to use, and, hence, the more memory it will require.
Even in spite of significant engineering effort to conserve memory, its
utilization by DECwindows applications remains high.
The table below shows that the 4-megabyte (MB) configuration and the 6 MB
configuration are bare minimums for non-clustered and clustered operation,
respectively. These systems are supported but not recommended. Since many
of our VAXstation-2000 customers now own such systems, it is important to
understand how to make the best use of the limited memory they have available.
The best technique for dealing with this problem is to take advantage of the
DECwindows capability which allows applications to be run remotely. When an
application is run in this mode, most of its memory requirement is satisfied
on a remote network node. This is discussed in more detail later in this
article.
MEMORY CONFIGURATION GUIDELINES
Use the following table as a guideline to determine which memory configurations
to recommend.
DECwindows Memory Configurations
Memory Standalone Network (DECnet) VAXcluster
------ ---------- ---------------- ----------
4 MB Supported Supported Not Supported
(Remote Apps Only)
6 MB Minimum Minimum Supported
Recommended Recommended
8 MB Recommended + Recommended + Minimum
Recommended
10 MB Recommended ++ Recommended ++ Recommended +
-------------------------------------------------------------------------------
Legend:
NOT SUPPORTED -- This configuration of memory and software is not supported.
SUPPORTED -- This configuration is supported, to the extent that the system can
be booted and a user can be logged in. No claims are made about
performance. In the case of the 4 MB (megabyte) networked
system, it is supported only when set up to run all applications
remotely.
MINIMUM RECOMMENDED -- This configuration represents the minimal amount of
memory recommended for good performance of local applications.
The number of applications that can be run concurrently without
degrading performance is also considered to be minimal. See
the section below entitled "How many Applications?"
RECOMMENDED -- This configuration can be expected to deliver good
performance for a greater number of applications than the
minimum (the greater the number of "+" signs, the greater
the number of applications). See the section below entitled
"How many Applications?"
Configurations with more memory than that listed here will provide good
performance for an even greater number of applications.
Additional memory generally buys you the capability to run more applications
while retaining good performance for all applications. If an application
already has sufficient memory, additional memory will not necessarily increase
its performance appreciably. If, however, performance of that application has
been lacking due to insufficient memory, its performance will improve when
memory is added.
HOW MANY APPLICATIONS?
The question of how many applications can be run concurrently while maintaining
a good level of performance has no simple answer. It depends on the memory
requirement of each application and on each individual's definition of "good
performance." The following guidelines, while not answering the question
completely, will help you to develop your own impressions of performance
on a given configuration with a given number of applications.
Consider the following rules of thumb taken from the VMS Version 5.1
Software Product Description (SPD) for determining supported memory
configurations. (Note that we will use these rules as guidelines in
estimating how many applications to run on a given memory configuration.
If you have questions about whether a particular configuration is supported,
please see the SPD.)
Rule of thumb for calculating memory used by various components
(in megabytes)
VMS 2.0
DECnet .5 (required for remote applications
or VAXclusters)
VAXclusters 1.5
DECwindows 2.0 (1.5 if set up to run all
applications remotely)
Further, consider the following characterization of application memory
requirements for DECwindows applications.
Rule of thumb for estimating application memory requirements
(in megabytes)
Small applications .25
Medium applications .5
Large applications 1.0 (and above)
The two sets of rules above can be used to estimate the number of applications
that can be run with good performance on any given configuration. The rules
indicate, for example, that an 8-megabyte standalone configuration requires
4 megabytes for the system (2 for VMS and 2 for DECwindows) and has 4 megabytes
available for applications. These could be used to provide good performance
for 2 large (1-megabyte) applications, 3 medium applications and 2 small
applications, running concurrently. Note also, that adding 2 megabytes to
an existing configuration allows the addition of, for example, one large
(1-megabyte) application and two medium applications, with no appreciable
loss of performance.
The actual memory requirement of any given application depends on many
factors. It is very heavily dependent upon the application features invoked
by a given user, and varies with time. Techniques involving the use of
working set adjustment and various VMS DCL commands such as MONITOR and
SHOW can be used to classify an application as small, medium or large.
The SPD's of certain layered applications may also include guidelines about
memory requirements.
Certainly, more applications than those indicated by these guidelines could
be run, with varying degrees of performance loss. If such additional
applications are run remotely, the effect on performance is minimal.
Alternatively, if they are run locally, but not concurrently with other
applications, the effect on performance may be confined to a transitory
period, after which the expected good level of performance will return.
But, if additional local applications are run concurrently, in excess of the
recommendations above, a noticeable reduction in performance will result.
WHAT PROBLEMS WILL I HAVE IF MY WORKSTATION DOES NOT HAVE THE RECOMMENDED
AMOUNT OF MEMORY?
Problems typical of memory-constrained workstations include an increased overall
page fault or swapping rate, or an increased rate of hard page faults (those
requiring disk I/O). When switching around from application to application,
performance can degrade if paging and/or swapping occurs. This can be seen
in longer window draw and re-paint times and delays in building and activating
menus and dialog (customization) boxes. However, the longer you stay in one
application, the better performance will become, as that application's working
set grows to its WSQUOTA (see guidelines below for setting WSQUOTA).
HOW IMPORTANT IS THE CPU IN DETERMINING DECWINDOWS PERFORMANCE?
After memory, the workstation CPU is the next most critical resource. Most
things that the typical workstation user does are CPU-intensive operations.
Given sufficient memory, you will notice some differences between DECwindows
on a VAXstation-3000 series machine and DECwindows on a VAXstation-2000 series
machine. Although the ratio of raw CPU speed between the machines is closer
to 3:1, in practice we have seen that most CPU-intensive operations are about
twice as fast on a VAXstation-3000 series machine as on a VAXstation-2000, when
applications are run locally. You will notice this in things such as
application startup, the pulling down of menus and the bringing up of dialog
boxes. Cursor tracking also benefits from the speed advantage of the 3000
series machines. This can be seen in things such as the highlighting of menu
items, the dragging of objects such as the window outline, and all the things
you do in a typical paint application. Finally, applications which do a lot of
writing to the screen will see improvement on the 3000 series. Anything which
does not depend significantly on disk or network I/O should be faster. One
would not expect to see big differences between the 3000 series and the 2000
series in an application with a lot of font-switching or hard page faulting,
both of which would require a significant amount of disk I/O. Similarly,
applications run remotely are usually more dependent on the characteristics
of the remote node and the network than they are on the speed of the
workstation.
In general, user actions on a 3000 series workstation with sufficient memory
will feel "crisper" than on a 2000 series workstation with the same amount of
memory.
WHAT IS THE "TRANSPORT" AND HOW DOES IT AFFECT PERFORMANCE?
The transport is the layer of software which controls the transmission
of X protocol messages between the server and its clients. A significant
performance feature of VMS DECwindows is the use of the local transport.
When the server and its client are on different nodes, the transport software
uses DECnet to pass messages back and forth. But, when the server and client
are on the same node, the local transport is used by default. The local
transport uses a very efficient shared memory scheme to effect the exchange
of messages. In applications which are "message-intensive", such as in cursor
tracking applications, the local transport provides a significant speedup over
the DECnet transport.
WHAT CAN I DO IF MY WORKSTATION LACKS THE AMOUNT OF MEMORY AND/OR CPU
RESOURCES NECESSARY FOR THE PERFORMANCE LEVEL I DESIRE?
One of the most powerful features of the X windowing system is its network
transparency. This means it is possible to run your DECwindows applications
on any node on the network and to display the results on your workstation.
It enables you to run your application wherever there are resources that it
needs. Since all user inputs and outputs are still handled by the workstation,
such clients appear as if they are running locally on your workstation.
This is significant from a performance perspective in that it admits a
much broader set of hardware resources for the workstation to draw upon.
Presuming that you have access to the resources of other nodes in a DECnet
network, you can run one or more of your application clients on one or more
of those remote nodes. Since most of the memory required by the application
is located on the remote node, this mode of operation can be particularly
beneficial to a workstation with a limited memory configuration. In addition,
further memory savings can be achieved on the remote node by installing
applications with the shared attribute. Finally, the faster CPU of a larger
remote processor may have the effect of speeding up application startup time
and certain aspects of CPU-intensive applications.
Applications which have minimal communication with the workstation server
generally run very well remotely. Applications that communicate frequently
with the server to track cursor movement (such as DECwindows Paint), or that
transmit very large blocks of information to the server, generally do not
perform as well. Local execution with sufficient local memory provides the
best and most predictable performance for these types of application.
Refer to Appendix A of the "VMS Version 5.1 Release Notes" and Chapter 8 of
of the "VMS DECwindows User's Guide" for more information on the performance
advantages of remote application execution.
WHAT ELSE CAN I DO TO IMPROVE DECWINDOWS PERFORMANCE?
Other suggestions for improving the performance of DECwindows
include:
o Experiment with larger WSQUOTA and WSEXTENT values in the user
authorization file. Values that you now use may be
insufficient for DECwindows. It is recommended that WSQUOTA
be set to the most common application size used. For most
users, this will be the small (512 pages) or medium
(1024 pages) application. It is recommended that WSEXTENT
then be set much larger than WSQUOTA.
o In a VAXcluster, consider the use of a local disk for paging
and swapping, particularly if your memory configuration
is below the minimum recommended.
o If you write your own applications, refer to the "VMS DECwindows
Guide to Xlib Programming" for tips on writing efficient
DECwindows programs.
o Consider hardware upgrades.
As with any VMS system, the "Guide to VMS Performance Management" should be
consulted for both an overall performance management strategy and specific
suggestions.
WHAT ABOUT SYSGEN PARAMETER CHANGES?
Again, as with any VMS system, SYSGEN parameter changes are not likely
to yield large improvements in performance. AUTOGEN does a reasonable
job of selecting initial SYSGEN values for a VMS DECwindows workstation.
With the FEEDBACK option, AUTOGEN can also refine those values based on
actual workstation usage. Any experimentation with parameters should
be done using AUTOGEN and MODPARAMS.DAT, and then backed out if the desired
improvement is not realized. Several experiments with memory management
parameters were conducted by the VMS performance group during DECwindows
field test. While we saw some success in certain instances, there was
no single clear strategy to recommend for all installations. There are,
however, two memory management changes built into an AUTOGENed DECwindows
system which are new for VMS Version 5.1. By default, you will come up with a
value of 500 for SWPOUTPGCNT. The effect of having SWPOUTPGCNT set to this
relatively high value is that, during a period of peak demand for memory,
swapping will be favored over paging. This behavior is appropriate in a
single-user workstation in order to purge memory of applications which
are idle. The other change involves the FREEGOAL parameter. This parameter
also has a higher value than it did in previous workstation versions. The
effect of this higher value is that, when memory demand is high, VMS will
reclaim many more pages at one time, thereby minimizing the number of times
that reclamation must occur.
--------------------------- END OF ARTICLE ------------------------------------
|