OpenVMS Notes: Raxco System Tuning

1. The information presented here is intended for educational use by qualified OpenVMS technologists.
2. The information presented here is provided free of charge, as-is, with no warranty of any kind.

Introduction

Back in 1987, I had the pleasure of attending a multi-day VAX/VMS tuning seminar put on by Raxco. At that time, the lecturer, Clayton J. Prestia, presented the audience with a plethora of VMS tuning information that I didn't know was buried (hidden?) across numerous volumes of DEC's own literature.

At that time, I was a member of a team managing two VAX-11/750's and eight VAX-11/730's distributed across the Canadian province of Ontario (we were also the application developers). The 730's would really bog down whenever there were 10-12 active interactive processes.

1. Raxco-based tuning allowed me to double this number to twenty.
   
2. I was able to use recommendations from the Raxco course notes to convince my peers that a change in our programming techniques would make the system much faster. Our biggest changes resulted in much lower file locking and Lock Manager overhead.

Before my Raxco tuning operation, a pair of VAX-8550s had already been ordered which would be operated as a VAX-Cluster from a central location in Toronto which would replace the ten distributed machines just mentioned. Even though these new machines had been installed with a maximum amount of memory (80 MB which seemed huge at the time), Raxco-based tuning still improved their operation.

In 2010, I still am responsible for several VMS systems including two AS-2100 platforms, one AS-4100 platform, and two AS-DS20e platforms. I still use some of this material to tune these systems as well as educate others.

VMS evolves into OpenVMS

The Raxco seminar was based upon VMS-4.x for VAX in 1987 but VMS has changed for the better with each successive release. In the early 1990's, DEC developed the 64-bit Alpha processor and even though the code base for Alpha was separate from that used by VAX, bugs corrected in the Alpha version of VMS (now called OpenVMS) were back ported to VAX. In the early 2000s the 64-bit code base, which was only meant for Alpha, was adapted to generate code for 64-bit Itanium (which HP named Integrity). HP engineers have told me that the Alpha-to-Itanium port was the first time a new set of eyes were collectively engaged in examining/improving OpenVMS since the previous port from VAX to Alpha.

Life This Side of Y2K

Why does this history matter? Well, in the days of VMS 4.x electronic memory was very expensive (compared to now) which meant there was never enough available. For example, the big VAX-8550 I mentioned previously could only accept a maximum amount of 80 MB although a third party modification would allow you to increase this limit. Today, memory is cheaper and faster (DRAM -> SDRAM -> DDR -> DDR2) which means that Alpha and Itanium systems almost always have access to much more.

Because most memory in 1987 was smaller in size, the default behavior of either "VMS Tuning" (or "Raxco Tuning") involved enabling and using AWSA (automatic working set adjustment) reduction. This meant that processes not actively using memory on a busy system would be required to surrender LRU (least Recently Used) pages to the FREELIST or MODIFIED LIST. Currently faulting processes could SOFT FAULT those pages back unless the system had already reassigned the memory meaning that the SOFT FAULT would need to be converted to a HARD FAULT (involving one, or more, disk I/O's)

Poking around tuning scripts (like AUTOGEN) this side of Y2K will reveal that AWSA will be disabled by default whenever a minimum of 500 MB of memory is present. This means that many Alpha or Itanium system will almost always have AWSA Reduction disabled.

Where I disagree with RAXCO:

• One of the RAXCO tips states "you should remove excess unused memory". Since going to disk was always (at least) 1000 times slower than staying in RAM, you always want more memory AND always want to use it. The fact that HPQ developed XFC (extended file cache) to avoid disk I/O's only proves my point.

Raxco Seminar Notes (1987)

Public Domain Notice

On June 30, 2010 I contacted RAXCO Software president Robert E. Nolan to obtain permission to make these notes freely available to the VMS Community. Permission was granted (verbally) provided the original RAXCO copyright remains in place. On behalf of the VMS community, "thank you Robert".

Unsolicited Advert:

• www.raxco.com (they still sell VMS products)
• www.perfectdisk.com

Raxco sells Perfectdisk for Windows as well as Performance Suite for OpenVMS and RaxcoSupport Suite for OpenVMS so please send them some of your business.

Scanning

• I used a Canon MP-490 to scan the Raxco seminar pages in two sessions.
• Scan Session #2: 300 dpi to produce chapter PDF files (raw files can be found here: https://neilrieck.net/raxco/ )
• I used Readiris Pro 12 to OCR the JPG files to produce XHTML files.
• I used Microsoft Expression Web 4 to merge the XHTML files into HTML files which I posted below.

Contents (Chapters in HTML Format)

• Raxco-0 - Cover Sheet (VMS-4.x)
• Raxco-1 - Introduction
• Raxco-2 - The VAX CPU
• Raxco-3 - VMS Memory Management
• Raxco-4 - Input / Output
• Raxco-5 - Data Gathering
• Raxco-6 - Operations Management
• Raxco-7 - Programming Techniques
• Raxco-8 - Capacity Planning
• Raxco-9 - VMS Memory Management Tuning Procedure
• Raxco-A - Supporting Green-Screen Displays (see the PDFs; I might not produce HTML versions)

VM Definitions

OS vendors have slightly different meanings for the phrases "working set", "resident set", and "balance set" so  are a few official definitions from DEC via official VMS / OpenVMS documentation.

Links:

• OpenVMS Notes
  • OpenVMS Notes: System Tuning
• https://docs.vmssoftware.com/
• www.jcameron.com/vms/tuning.htm

---

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.