OpenVMS Notes: "VAX to Alpha" Porting Diaries

Note: this page has become lengthy, in an attempt to document everything that I encountered (so that other poor devils won't have to do the same). To a non-programmer it may look like porting from VAX to Alpha might not be worth the trouble, but nothing could be further from the truth. This conversion was much easier than my usual programming duties and was mostly done in my spare time up to, and including, Christmas through to Y2K. Overall, I'm very impressed with Alpha technology. It requires much less electricity than VAX; it does not require any special air conditioning or power; it is priced much lower than VAX while offering much higher performance.
edit: 2015-06-20 what: chopped out some crud)

Porting Diary #1 (1999-Nov to 2000-Jan)

Week 1 (My first Alpha...)

Our machine looks like this; just a little less full...Our "skunk works in Waterloo" has just (1999-11-30) received an AlphaServer 4100 (with DUNIX 4.1 installed) from a cancelled project and we've been commissioned to port a relatively large business application (consisting of ~ 200 VMS programs) from a dual VAX-8550 cluster to Alpha.

This specific machine is an AlphaServer 4100 5/300 which was manufactured in 1996. It contained a single 21164 (EV5) CPU running at 300 MHz with 2 MB of cache and 256 MB of RAM. Five modules can be installed in the CPU chassis (one for the PCI/EISA interconnect and four for CPU's). Because of the clock speed I thought this machine might be a bit of a dog but it "seems" much faster than my VAX-6430 (at least it boots up five times faster). I always have to remind myself that these pipelined super scalar 64-bit RISC CPUs are usually more powerful than they first seem.

The disk subsystem is based upon MYLEX configurable RAID controllers which connect to five "storage works" arrays (each filled with six 4-GB SCSI drives). Since all RAID functions are handled in hardware, the CPU can pay more attention to running the OS and apps. The controller can be modified with a configuration program to support RAID #1 (mirroring), RAID #0 (striping), RAID 0+1 (a.k.a. RAID #10) and RAID #5 (complete multiple disk redundancy). Note that we chose "RAID 0+1" since this method provides that will tolerate multi-drive failure in a single raid-set.

All the chassis boards (except CPU and memory) are either PCI or EISA based so these machines are considerably less expensive than the VAXs they are about to replace.

Week 2 (We get the CD-ROMs)

We ordered the complete "OpenVMS for Alpha" software distribution library (24 CD-ROMS for just under $1K Canadian) so we'll be prepared when we receive our temporary licenses from Compaq/HP.
(this activity was due to a misunderstanding on our part; apparently ROMs would have been provided free of charge; oops!)

Week 3 (We borrow licenses)

We received our software distribution library this week so we placed a call to Compaq/HP to acquire some temporary licenses (good for 60 days) through their Software Loan program. We ordered licenses for the following:

Week 4 (The fun begins...)

We received our temporary licenses and started to install the new software as follows:

  1. upgraded the AlphaBIOS console firmware from 4.0 to 5.3, and then to 5.5
    Notes: this two step upgrade is recommended by Compaq/HP in their OpenVMS Alpha Installation Manual which is part of their dual format (Windows or OpenVMS) "OpenVMS Version 7.2 Documentation CD-ROM". The firmware CD-ROM came with the OpenVMS binary CD-ROM.
  2. installed OpenVMS 7.2-1
  3. installed the previously mentioned layered products. They installed and verified so quickly that it's scary.
    This machine can completely boot OpenVMS then start DECnet and TCP/IP in under two minutes!
    • DECnet Phase IV looks the same on Alpha but seems much faster.
      • Since my preliminary tests only involved copying files to the Alpha, this speed improvement may be due to the RAID subsystem.
    • FMS looks the same on Alpha
    • Searching large (40K line) programs with the EDT editor is unbelievably fast. Saving changes is even faster.
    • Linking is unbelievably fast
    • Indexed RMS files copied from VAX to Alpha via DECnet can be accessed by DEC-BASIC programs without modification.
      • Note: OpenVMS on Alpha still uses the tried-and-true FILES-11 disk format
    • I had never used Compaq's version of TCP/IP (a.k.a. UCX) but it installed easily on Alpha.
      • UNIX people used to making quick edits of the host file may be surprised to find that that this can only be done by a "DECnet NCP" style interface (e.g. "set host name" adds the entry to "host")
    • DEC-BASIC is a little different from VAX-BASIC
      • no interpreter mode (no loss there)
      • neat optimizer to really show why RISC is better than CISC

Week 4a (VAX-BASIC 3.8 to DEC-BASIC 1.3)

note: DEC-BASIC has been renamed Compaq-BASIC for OpenVMS (and now HP-BASIC for OpenVMS)

  • the developer's process needed to have /PGFLQUO set to 500,000
  • compiling was faster with /WSEXT set to 100,000
  • the compiler defaults to /OPTIMIZE=LEVEL=4 which returns some VERY interesting informational messages about source code quality but takes a real long time depending on how many other people are logged in
  • when /OPTIMIZE=LEVEL=1 was used, compile time dropped to 21 minutes.
  • when /OPTIMIZE=LEVEL=0 was used, compile time dropped to 14 minutes
  • Since the same program would compile in 4 minutes using VAX-BASIC on a VAX-6430 (32-bit CISC), I can only imagine what the compiler now has to do when generating instructions for a pipelined super scalar 64-bit RISC
  • after linking, the resulting executable was more than twice the size of the VAX equivalent (this is to be expected when moving from CISC to RISC)
1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
30010	%include ""	!
30020	%include ""	!
1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
30010	%include ""	!
	! <--- need some text between included functions
30020	%include ""	!
1000	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
	print funct1(1%,2%)
	print funct2(1%,2%,3%)
30000	end
100	%include ""
200	%include ""

So just modify the line numbers to be somewhere between 30001 and 32767.
  1. call "sys$getsyi" with a "syi$_page_size" request. VAX is always 512 but Alpha can be any multiple of 8192 (depends on the individual machine).
    1. Use this data to "boundary align" the addresses in the first quadword passed in the call
    2. Don't use this data to "compute the number of pages requested" since the system call expects 512 byte pagelets
  2. The starting address must be pushed down to the lower page boundary. For example, it the page size is 8192:
    address1 = (address1 and -8192) which clears lower order bits
    Note: this is not necessary if the area to be mapped is in a COMMON AND the COMMON is page aligned in memory via the LINK /OPTION command (where an option file specifies the common name in a PSECT with a PAGE align directive)
  3. The ending address must be pushed up to the upper page boundary. For example, if the page size is 8192:
    address2 = (address2 or (8192-1)) which sets lower order bits
  4. compute the number of requested pagelets:
    pages = (address2 - address1 + 1) / 512

    Note: the preceding fix is not necessary if you map to the section using the "SEC$M_EXPREG" flag

Week5 (BASIC code renovation) - We're still having fun, right?

 Note: you should renovate your code in this way whether you intend to port or not

Program Renovation: Our currently semi-formal method of declaring external functions has made me question whether porting programs "as-is" to a new hardware architecture will always be safe. Everything has worked properly so far but I keep thinking there is room for improvement. After receiving some suggestions from Francois Daigneault in Montreal, I've decided to change to a more formal coding method. Three program examples follow (blank lines have been removed to save space on this page):

1000	!
	! informal example (we never do this but I have seen others who have)
	option type=explicit
	record QuadWord
		long long0
		long long1
	end record
	external long function sys$bintim	! informal (no inbound parameter list)
	declare QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end
1000	!
	! semi-formal example (our current coding practice)
	option type=explicit
	record QuadWord
		long long0
		long long1
	end record
	external long function sys$bintim (string by desc, QuadWord by ref)	! semi-formal
	declare QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end
1000	!
	! formal example (what we will change to)
	option type=explicit
	%include "starlet" %from %library "sys$library:starlet$basic.tlb"	! system services (formal)
	declare Basic$QuadWord QuadBuff
	call sys$bintime("0 ::15", QuadBuff)	! compute delta time 15 seconds from now
30000	end
	%include "starlet"	%from %library "sys$library:starlet$basic.tlb"	!system services
	%include "$ssdef" 	%from %library "sys$library:starlet$basic.tlb"	!ss$ definitions
	%include "$syidef"	%from %library "sys$library:starlet$basic.tlb"	!syi$ definitions
	%include "$jpidef"	%from %library "sys$library:starlet$basic.tlb"	!jpi$ definitions
	%include "lib$routines"	%from %library "sys$library:starlet$basic.tlb"	!lib$ RTL
$libr/list sys$library:starlet$basic.tlb
$libr/extract=starlet      sys$library:starlet$basic.tlb ! we only want book "starlet" (sys$qiow, etc.)
$libr/extract=lib$routines sys$library:starlet$basic.tlb ! we only want book "lib$routines"
$libr/extract=*            sys$library:starlet$basic.tlb ! we want to view the whole library (~5800 blocks)

Week 5a - My "renovation plan" reality check...

1000    option type=explicit
	%let %method=2
	%if %method=1
	  ! this new method crashes at run time
	  %include "lib$routines" %from %library "sys$library:basic$starlet.tlb"
	  ! this old method runs properly at run time and matches published documentation
	  external long function lib$bbcci( long by ref, any by ref)	! from VMS documentation
	  external long function lib$bbssi( long by ref, any by ref)	! from VMS documentation
	%end %if
	! the following stub was adapted from a FORTRAN example found in document:
	!	"OpenVMS RTL Library (LIB$) Manual"
	common(abc)long        states(4)	! could be shared memory
	print "doing set of clear bit"
	if (LIB$BBSSI (42, states())) then
	    print 'State bit 42 was previously set (oops)'
	    print 'State bit 42 was clear'
	end if
	print "doing clear of set bit"
	if (LIB$BBCCI (42, states())) then
	    print 'State bit 42 was set'
	    print 'State bit 42 was previously clear (oops)'
	end if
30000	end
1000    option type=explicit
	%include "lib$routines" %from %library "sys$library:basic$starlet.tlb"
	common(abc)long        states(4)	! could be shared memory
	print "doing set of clear bit"
	if (LIB$BBSSI (42, loc(states()))) then ! address passed by value (not variable passed by reference) 
	    print 'State bit 42 was previously set (oops)'
	    print 'State bit 42 was clear'
	end if
	print "doing clear of set bit"
	if (LIB$BBCCI (42, loc(states()))) then ! address passed by value (not variable passed by reference)
	    print 'State bit 42 was set'
	    print 'State bit 42 was previously clear (oops)'
	end if
30000	end

Compiler Optimizer Fun

Dealing With Unused code:

Detecting Non-sense Code:

<sr> $
<ur> type pos_demo.bas
<sr> 1000	option type=explicit				!
		map(abc) string dev_name$ = 8			! fixed length string
		dev_name$ = "LTA9999"				! insert 7 characters
		if pos(dev_name$,":",1%)>0% then		! if a colon was found here
		    dev_name$ = dev_name$ +":"			! then append a colon (problem line)
     !~~~	    dev_name$ = edit$(dev_name$,128%) +":"	x what the programmer meant
		end if						!
		print dev_name$					!
     30000	end						!
<ur> bas/optim=level=0/warn=all pos_demo
	dev_name$ = dev_name$ +":"
	%BASIC-I-EXPNOTRES, expression does not contribute to result
	at line number 5 in file DKB0:[NEIL]POS_DEMO.BAS;4
<ur> bas/optim=level=1/warn=all pos_demo
<sr> $								! no informational

More Non-sense Code

<sr> $
<ur> type logic_demo.bas
<sr> 1000	option type=explicit
		declare long rc%
		! rc% = sys$qiow(bla...)
     !~~~	if (rc% and 1%) <> 1% then		! <-- what was intended
		if rc% and 1% <> 1% then		! <-- what was entered
		    print "error: ";rc%
		end if
     30000	end
<ur> bas/optim=level=0/warn=all logic_demo 		! <-- produces no messages
<sr> $							!
<ur> bas/optim=level=1/warn=all logic_demo		! <-- produces messages
	if rc% and 1% <> 1% then
	%BASIC-I-UNREACH, code can never be executed at label 
	at line number 5 in file DKB0:[NEIL]LOGIC_DEMO.BAS;2

Week6 (VAX-C to DEC-C )

(note: DEC-C has been renamed Compaq-C; and now HP-C)

More Program Renovation

  1. I have just discovered that approximately 5% of our binaries have been written in VAX-C 3.2 which is a product that Digital replaced with DEC-C 4.0 (for VAX and Alpha) in the early 1990's and has been recently renamed to Compaq-C 6.2
  2. We contacted Compaq/HP to get a temporary license for DEC-C 6.2 and installed it with no problems.
  3. Compiling the old "VAX-C" source code with the new compiler is another story. Even though we compiled with switch "/STANDARD=VAXC" we observed many error, warning and informational messages. At this point it seems that the reason for this problem is the poor quality of the legacy source code.
  • the legacy authors had quite a bit of code that tested for a return value of -1 from C functions "fwrite" and "fread". The compiler humorously informed us that "this may not be what you intended". (we are amazed that the program seemed to work properly for the last 7 years; just luck I guess...)

    We changed the -1 reference to 0 as per the DEC-C-RTL documentation
  • the legacy authors had created many functions of type "int" but had not returned any values.

    We solved this problem by redeclaring these functions as type "void"
  • the legacy authors had enabled access to the VAX instruction set with statement "#pragma builtins" and then referenced _MOVC3 over 60 times to copy data to (and from) an OpenVMS "global section" which was being used for IPC (inter process communication). Since _MOVC3 is not available on the Alpha, these references would not compile properly.

    We solved this problem by writing a macro to redefine _MOVC3 as a call to function "memcpy" (these lines should actually be renovated so the program remains OpenVMS portable)
  • the legacy authors had many programs where functions had not been prototyped which caused quite a few compiler messages. (how where these programs originally compiled? With /STANDARD=NONE perhaps?)

    We solved this problem by properly prototyping the functions before they were referenced
  • the legacy authors called "sys$crmpsc" and "sys$mgblsc" in a unique way that is different than the BASIC example above so renovation is probably not required. However, I think the _ALIGN(OCTAWORD) statement which precedes the variable declarations which get mapped into the "global section" may need to change to __ALIGN(PAGE)
  • the legacy authors was also accessing VAX instructions _MOVC5 and _LOCC which are not available on the Alpha.

    Although _MOVC5 can be replaced with two calls to "memcpy", and _LOCC can be replaced with a call to "memchr", we were able to replace these VAX calls with renovated code that doesn't require them.

 Recently Discovered Online "C" Documentation

 Mid Week Summary

Despite the fact that many system calls were done in both VAX-BASIC and VAX-C, it has been much easier to port BASIC than "C". This seems a little strange to me since "C" is considered the favorite porting tool of industry. Perhaps things would have gone a bit better if our "C" source code had been kept up to date with newer versions of the DEC-C compiler which had been available on VAX for a least 7 years. On a different note, I now believe that porting COBOL and FORTRAN apps would probably be just as easy as porting BASIC.

Tomorrow I'll attempt to recompile the DEC-C programs with switches "/STANDARD=PORTABLE" and "/STANDARD=MIA" just to see what kind of compiler messages are produced.

more to follow...

Executive Summary (port 1)

Miscellaneous Stuff #1 (Public Relations)

Miscellaneous Stuff #2 (Technical)


some free Alpha Migration Tools (AMT) including:

  • DECmigrate for OpenVMS Alpha migrates OpenVMS VAX applications to OpenVMS Alpha.

  • DECmigrate for DIGITAL UNIX migrates ULTRIX RISC applications from MIPS to Compaq's Tru64 UNIX on Alpha
    note: DECmigrate has been renamed OpenVMS Migration Software for VAX to Alpha (a.k.a. OMSVA)

both these tools perform a binary translation so would only be useful if you don't have your original source code (a scary thought...)


I've just discovered a neat little migration tool. From OpenVMS Alpha you can execute the DCL command $Macro/migrate to read a 32-bit VAX MACRO source file (.MAR) but generate a 64-bit Alpha object file. You do not need a license to do this.

However, you do need a license to execute the DCL command $Macro/alpha which reads an Alpha MACRO-64 source file (.M64) and generates a 64-bit Alpha object file. This is strange since the MACRO assembler was previously free with OpenVMS on VAX as well as RT-11 and RSX-11M on PDP.

Update: MACRO-64 is a layered product that can still be found on the latest (Alpha OpenVMS 7.2-1) consolidated software distribution CD-ROMs and requires a license to run. However, if you phone Compaq to purchase a license they won't be able to find it on their price list because this product is now freeware; it's just that they (Compaq) haven't yet done a good job promoting this fact. Anyway, here is the required license information courtesy Compaq:

	/UNITS=0 -

Click if you don't have the access to the consolidated software distribution CD-ROMs.

DEC-BASIC Compiler Benchmarks

Optimizer Level Meaning
0 no optimizations are performed
1 some optimizations (like instruction scheduling) and unused code removal
2 more optimizations (like loop unrolling and split lifetime analysis)
3 more optimizations
4 maximum optimizations

Alpha Family Tree (from news releases, leaks, gossip, and projections)














.68u 3 layer metal



1 / 1 xref1 (DTJ)

1 (2 peak)


200 (400)







1 / 1

1 (2 peak)


300 (600)




.50u 4 layer metal



2 / 2 xref2 (DTJ)

2 (4 peak)


800 (1600)







2 / 2

2 (4 peak)


1000 (2000)







4 / 2

4 (6 peak)


2400 (3600)







4 / 2

4 (6 peak)


2800 (4500)







4 / 2

4 (6 peak)


3600 (6000)

2001 21264C EV69 .125u 15M OOE 2 4 / 2 4 (6 peak) 1200 4000 (7200)






OCL2 3, OCMC 4, Glueless SMP 5

4 / 2

4 (6 peak)


4400 (6600)






OCL2 3, OCMC 4, Glueless SMP 5

4 / 2

4 (6 peak)


4800 (7200)



EV8 10




? / ?





  1. Instruction Issue Rate: Integer only vs. (Integer + Float)
  2. OOE = Out of Order Execution
  3. OCL2 = On Chip Level 2 Cache
  4. OCMC = On Chip Memory Controller
  5. SMP = Symmetric Multi Processing
  6. SMT = Simultaneous Multi Threaded (chip level)
  7. "A" and "B" series parts are usually just a "die shrink" with the exception of EV56 which also had an "instruction set" extension
  8. 21066, 21066A, and 21164PC (PCA56) are not shown
  9. EV6 and EV7 have the same CPU core
  10. Cancelled on June 25, 2001 when Compaq announced that they had been seduced by the dark side (Intel's IA-64)

Alpha 'Chip Head' Links

VAX vs Alpha

Performance Comparisons

The following performance documents use an internal metric called PERF which appears to be "CPU oriented". Previously, Digital used a "CPU plus I/O" metric called VUP (VAX Units of Performance) where a VAX-11/780 had a VUP rating of ONE. In the following charts a VAX-11/780 has a PERF rating of EIGHT.

Sometime in 2001 we'll be moving our "trouble ticket management" application from our VAX-6430 to an AlphaServer 4100 5/300. Documents behind the links above say the VAX-6430 has a PERF rating of 125 while the AlphaServer 4100 5/300 has a PERF rating of 690. While it is true that my Alpha 4100 boots up 5 times faster than my VAX-6430, only live load tests will prove if it's 5.5 times faster in the real world. (but newer technology is usually better, right?)

p.s. Since I first viewed Compaq's performance comparisons in the Spring of 2000, they've renamed "Alpha PERF" to "Tru64 TPS" but the unit values in the chart have stayed the same. Since Tru64 never ran on VAX (or MIPS), a direct comparison between the hardware platforms is even more unclear.

Relative VAX-Alpha Comparisons using SPEC (Standard Performance Evaluation Corporation)


CISC (Complicated Instruction Set Computing) was developed when memory (RAM) was very expensive. Simply described, an instruction was fetched from memory and pulled into the CPU where is was decoded into a sequence of microinstructions (also called microcode). Depending on the instruction (POLY was the worst) or the addressing mode the CPU could be working on a particular operation for much longer than just a few ticks of the clock. The system could potentially start an instruction then need to abort it in order to service an exception (interrupt) then need to restart the aborted instruction thus wasting valuable CPU resources.

RISC (Reduced Instruction Set Computing) was developed as an alternative to CISC when the cost of RAM started to fall rapidly. RISC machines were required to execute each instruction in only one clock cycle (on average) without the necessity of converting to microcode. This meant that complicated addressing modes as well as complicated instructions had to be replaced by simple ones. Some work previously done by one instruction was now done by many which means that a RISC machine in a certain sense is really running microcode out of RAM. Now when exception occurs it is like interrupting a CISC machine between the micro ops.

With microcode out of the way, CPU operation became much more deterministic. This allowed other interesting performance features to be more easily implemented like OOE (Out of Order Execution) and SE (Speculative Execution) along with its cousin Branch Prediction. I won't go into instruction pipelining here except to say that one consequence of it occasionally allows multiple instructions to execute simultaneously.

Programming Task add contents of memory locations 168 and 172 then store the result in 176
VAX (CISC) add3   168, 172, 176 ; many micro-ops are running behind this single instruction
Alpha (RISC) LDL    R0 , 168 ;
LDL    R16, 172 ;
ADDL/V R16, R0, R16 ;
STL    R16, 176 ;

Example CISC Addressing Modes (I've lost my VAX programming card so here are some PDP examples until I find it) 

PDP-11 (CISC) Register Addressing Modes (PC) Symbolic Description
2 immediate #n operand (immediately) follows the instruction
3 absolute @#A address (immediately) follows the instruction
6 relative A instruction address + 4 + X is the address
7 relative deferred @A instruction address + 4 + X is the address of address
PDP-11 (CISC) Register Addressing Modes (GP) Symbolic Description
0 register R register contains the operand
1 register deferred (R) register contains the memory address
2 auto increment (R)+ register contains the memory address
(post increment by 1 (byte) or 2 (word))
3 auto increment deferred @(R)+ register contains the memory address of the address
(post increment by 1 (byte) or 2 (word))
4 auto decrement -(R) register contains the memory address
(pre decrement by 1 (byte) or 2 (word))
5 auto decrement deferred @-(R) register contains the memory address of the address   
(pre decrement by 1 (byte) or 2 (word))
6 index X(R) R + X is the memory address
7 index deferred @X(R) R + X is the address of the address

Note: twelve PDP instructions (including MUL + DIV) supported double operands so the microcode was expected to support every permutation of the addressing modes listed in the above two tables.

Porting Diary #2 (2001-05 to 2001-06)

Our machine looks like this; just a little less full...

Renovation (not required, but desired)

Many of our 200 programs were written using the following form (which means that we re-compile included functions every time we compile the main program):

1000	%title "my_program.bas"
	%ident "version 1.23"
	option type=explicit
	external long function funct1(long, long)
	external long function funct2(long, long, long)
  	%include "[.fil]file_map1.rec"	! file definitions are in [.fil]
	print funct1(1%,2%)		!
	%include "[.inc]"	! in line BASIC code is in [.inc]
	print funct2(1%,2%,3%)		!
30000	end				!
30010	%include "[.fun]"	! BASIC functions are in [.fun]
30020	%include "[.fun]"	! BASIC functions are in [.fun]

So I've written a DCL script to compile all of the BASIC functions in [.fun], then used $LIBRARY/CREATE and $LIBRARY/INSERT to store all the object files in a library. Next, we delete all of the included code that comes after "END" then we compile and link like so:

$bas/optim=level=1	my_program.bas
$link			my_program,					-

Odds 'n Ends (other stuff you shouldn't forget)

File Purpose
sys$library:edtsys.edt required to properly initialize $Edit/edt
sys$library:sysdevctl.tlb required by some print queues
tcpware$ contains LPS print queue definitions
[tcpware.named]named.* DNS server support files (most sites only use client DNS software)
[sys0.decserver]dsvconfig.dat your DECnet definitions for supporting terminal servers from NCP
[sys0.syscommon.decserver]pr0801eng.sys DECserver-200 downloadable image (dropped from consolidated distribution in the mid 1990's)
[sys0.syscommon.decserver]mneng1.sys DECserver-90 downloadable image (install from consolidated distribution along with an new version of etc.)
freeware tools like ZIP, UNZIP, DFU, etc. see the VMS freeware CD-ROM (or )
Mylex DAC960 RAID support1 don't throw away old Alpha firmware CD-ROMS mine have a directory "\utility\swxcsr" which contains the RCU (Raid Configuration Utility) as well a RAID module firmware.
Kermit2 async interface software (for use where $SET HOST/DTE won't do)
new versions are available at

1. Make sure you run the standalone program "swxcrmgr" from either ARC or AlphaBIOS and then use the Tools menu to produce a configuration backup to floppy. One time I powered down the machine to move it 3 meters and, for some reason, the machine came up with both MYLEX DAC960 cards having no configuration.

2. we had a collection of async interface scripts (DCL) which were being used by non-technical people. Our original scripts called a VAX version of kermit-32 which was passed a pre-selected port via logical name "ker$comm". The newer version of kermit (called c-kermit) no longer supports this logical. Instead, you must start the program as a DCL Foreign Command and then pass the desired port on the command line like so:


$ def/user/NOlog sys$input tt
$ if f$getsyi("arch_name") .eqs. "VAX"
$ then
$     def/user/NOlog KER$COMM 'dev_name'
$     run csmis$exe:vms_kermit_33117.exe    ! kermit-32
$ else
$     ckermit == "$csmis$exe:CKV196-AXP-VMS72-NONET.EXE"
$     ckermit -l 'dev_name'
$ endif 

Simple Metrics

Machine Memory CPUs OS Boot Time Storage Avg Disk I/Os
($mon disk)
Max Disk I/Os
($mon disk)
manufactured: 1989
256M 3 OpenVMS-7.2 11.5 min 2 DSSI busses
2 StorageWorks boxes
2 HSD05 adapters
8 RZ26 drives
4 shadow sets (across 2 busses)
23 32
manufactured: 1996
512M 2 OpenVMS-7.2-1 < 2 min 2 Mylex DAC960
24 RZ29 drives
4 RAID-5 sets
1 SCSI adapter
1 StorageWorks box
2 RZ29 drives
312 610

Tape Storage

Our used AlphaServer 4100s were delivered without any built-in tape storage devices and we need to have daily backups of our database. I located a neat "4 mm DAT" ( DS-TLZ10-VA ) which plugs into one slot of our StorageWorks box (Apparently, any device ending in "-VA" can plug into a StorageWorks box) . I ordered one, then installed it while the system was running using the following command:

$ mcr sysman
SYSMAN> io autoconfig
SYSMAN> exit

Very fast...

Executive Summary (Port 2)

Decommissioning VAX (2001-09-05)

After we cutover our application to the AlphaServer-4100, we left our two VAXs (one production VAX-6430 and one DRP VAX-6410) powered up and connected to the corporate network incase we neglected to copy something or needed to cut back for some reason. Well, the cutover was four weeks ago and now it was time to decommission the VAX's.

As the machines were rolled out of our computer room, I decided to remove the gray plastic "Digital" name plate from the front door as well as the very cool digital-branded chrome-plated door key as keep sakes (they now sit on my desk; I intended to hang the plastic logo on my key chain but can't bear to drill the hole). I had installed these machines when Digital Equipment Corporation was still a company and this is truly the end of an era for me.

DEC logo

p.s. This happened the day after HP and Compaq announced they'll merge into the New-HP. Since HP is considered an engineer's company (I've always thought of HP's Bill Hewlett and David Packard as the same kind of people as Digital's Ken Olsen and Gordon Bell), let's hope that the Digital Equipment division of Compaq has found a better home.

You Can't Afford to Delay a VAX-to-Alpha Port

  1. Spare Parts Availability (for VAX)
    Compaq ended VAX hardware manufacturing in December 2000. Since VAX was the Chevy of minicomputers, spare parts on the street will be available for quite some time but I wouldn't want to go shopping during an emergency.
  2. Environmental Costs
    Alpha platforms are much smaller and thus save valuable real estate. They also require much less power and, as a result, generate much less heat which means that air conditioning costs will be lower. (many companies don't even bother with an environmentally controlled computer room)
  3. Platform Costs
    Compared to departmental class VAX machines 10 years ago, departmental class Alphas appear to be 10 times faster but are 10 times cheaper. Compaq allowed us to trade-in our software licenses which made the whole changeover more palatable to the bean counters.
  4. Better Software Tools
    I've noticed a philosophical change in the way Alpha tools produce code. Check out the following program stub:
    1000	option type=explicit	!
    declare long i% !
    for i% = 1 to 100 ! should be "for i% = 1% to 100%" on VAX; Alpha doesn't care
    print i% !
    next i% !
    end program 1 ! return -s- to DCL

    Notice that the programmer forgot to place percent symbols after numeric constants "1" and "100"

    Compaq-BASIC for VAX (a.k.a. VAX-BASIC) will generate floats for these numbers then will convert them to longs at "run time" before using them.

    Compaq-BASIC for Alpha
    is smart enough to realize that longs are required and so builds longs at "compile time".

    I've personally wasted many months of my life make sure that percent symbols are located everywhere they're supposed to be along with a lot of other stuff. Since software is supposed to assist us, features like these are a welcome relief.

    So-called "DEC languages" targeted at Alpha and Itanium are based upon the GEM Optimizing Compiler System. GEM is a project code-name rather than an acronym. Everything coming out of DEC in those days had names like GEM, Emerald, Opal, Prism, Mica, etc.

    A Few GEM links:


Finally, a "NEW" Alpha Server DS20e (2002-01-19)

Management has determined that we've earned our wings with the used Alphas and has decided to replace our primary "Alpha Server 4100" with a brand new "Alpha Server DS20e". BTW, there was no performance reason to change; the AS-4100 will become our DRP (hot standby) machine located in another building.

The new machine is a rocket but I can't post any stats yet because we haven't yet cut over our application software and customer data. But check out the basic differences in the following chart.

Machine CPUs Memory RAID5 Ethernet FDDI1 VGA2 average SETI work unit time
AS-4100 2 @ 300 MHz 0512 MB 2 @ DAC-960 (Mylex) 1 1 1 15 hours/CPU
AS-DS20e 2 @ 833 MHz 1000 MB RA-3000 (HSZ-22)3 2 (100Mb) 1 0  4 hours/CPU

Superscript Notes:

  1. We purchased this option. Alphas in our computer room are connected via DECnet Phase IV running over FDDI (fiber optic lines) to allow a second backup/restore method if we ever loose our tape drive.
  2. We didn't require a VGA terminal on the DS20E (since the RA-3000 is configured via a serial port using PC based software rather than host based software). Yippee! We're back to a VT-510 and can edit startup files in SYS$MANAGER from the console.
  3. Want to make your system really fly? Change the "caching policy" of your HSZ22 to "write-back" ("unchecked" defaults to write-through). One of our "I/O bound" database scan-and-analyze programs required a full 2-minutes to run. Changing the caching policy to "write back" caused the execution time to drop to 20 seconds. But make sure your RAID is connected to a UPS or you might not be able to do the write-back (which will result in "data loss")

(a welcome) Licensing Surprise

All the AS-4100 licenses appear to run as-is on the AS-DS20e. This would not have happened in the VAX days and is probably one good reason (out of many) to buy new Alpha hardware.

Tiny Little Problem (resolved)

Our DS20e was delivered with a modern two port 10/100 Ethernet card. However, my employer required me to connect it to a 10 year old Synoptics Hub which only supports 10 Mb/s. Whenever we would disconnect the 10-base-T connector (a very rare event), the DS20e Ethernet port wouldn't recover after reconnection. The next time down, we used console mode to permanently change the port settings from "AUTO" to "10 Mb/s Full Duplex".

Note that this change on our part was a mistake since "full duplex" is only meant for Ethernet switches but not hubs (it made TCP/IP appear slow while DECnet phase IV was intermittent). We shut down the system ASAP and changed the console setting of the Ethernet ports to just "10 Mb/s" (half duplex is assumed) which returned the system to its ridiculously fast speed.
>>> set eia0_mode twisted

AlphaServer DS20 Console Manuals:

2008-06-17 Update: Our company runs two networks so...

  1. our primary NIC connected to the legacy network (based upon Synoptics hubs) running 10 Mbs half-duplex
  2. our secondary NIC is connected to the newer switched networked (based upon CISCO Ethernet Switches). The second NIC is set to auto-negotiate like so:
    >>> set eia1_mode auto-negotiate
    and is currently running 100 Mb/s full-duplex

AlphaServer DS20e Memory Upgrade (2005-09-xx)

When we purchased our DS20e from Compaq (now HP) back in 2002-01-xx it came with only 1 GB of RAM. Recently a third party vendor ( offered to sell me an additional 1 GB kit at a very attractive price under $1K. Since we do our own maintenance, and because the price was so low, I decided to do the upgrade myself.
Caveat: although there is a detailed layout diagram attached to the inside cover, do not attempt this yourself without the original manual. Also, the technician doing the job must use one, or more, anti-static straps and must be qualified to work on very high density CMOS; the memory area is tight and you must take care not to break the extra long DIMM sockets; Before you order any memory chips, check if you have any spare sockets and remember that you can't pop the lid to peek at the motherboard while the system is running because a magnetic interlock will shut down your internal power supplies.

Criticism targeted at so-called PC technicians: "Why don't you people use anti-static straps?". Just because a system seems to work properly after your work is finished doesn't mean that a small static discharge from your body hasn't weakened a component which will now fail within a few months.

Well you wouldn't believe what happened next. This system became so fast that it was actually scary. It seems that OpenVMS-7.3-2 had cached quite a bit of our RMS database (as well as a lot of other files) in memory which resulted in almost no physical I/Os to disk but an enormous amount of lock activity (which I interpreted as a large amount of work being compressed into a smaller period of time). We immediately went back to our third party vendor and ordered another 1 GB kit which brought up our total memory to 3 GB.

I do not have any before/after measurements to offer but my DS20e feels like it is now 10 times more powerful now than before the memory upgrade.

More Speed Comes to the AlphaServer DS20e (2007)

Installed two more memory kits (we now host 4 GB) then allocated 2 GB to the XFC (extended file cache)

More Speed Comes to the AlphaServer DS20e (2009)

Switched the caching policy of our RA-3000 (raid controller) from write-through to write-back. System performance is now "scary fast"

The Saga Continues (2015)

 Back to Home
Neil Rieck
Waterloo, Ontario, Canada.