OpenVMS "VAX to Alpha" Porting Diaries * Porting Diary #1 <#diary1> (1999.11 to 2000.01) o Week 1 <#week1> my first (used) Alpha o Week 2 <#week2> we get the CR-ROMs o Week 3 <#week3> we borrow licenses from Compaq/HP o Week 4 <#week4> the fun begins o Week 4a <#week4a> VAX-BASIC to DEC-BASIC o Week 5 <#week5> a little BASIC Source Code Renovation o Week 5a <#renovation> renovation and library routines: *lib$bbcci* and *lib$bbssi* o Week 6 <#week6> VAX-C to DEC-C o Executive Summary #1 <#p1executive> * Miscellaneous 1 <#misc1> Public Relations * Miscellaneous 2 <#misc2> Technical Stuff (binary translators, etc.) o Macro-64 <#macro64> o 'OpenVMS BASIC' Compiler Benchmarks <#compiler_benchmarks> o Alpha Roadmap <#alpha_roadmap> o Alpha Family Tree <#alpha_family_tree> o Alpha 'Chip Head' Links <#alpha_chip_head_links> o <#alpha_chip_head_links>VAX vs. Alpha <#vax_vs_alpha> (CISC o vs. RISC) DEC Alpha Info (Wikipedia) * Porting Diary #2 <#diary2> (2001.05 to 2001.06) o Renovation #2 <#renovation2> optional maintenance o Odd 'n Ends <#odds_n_ends> including Mylex DAC960 RAID support o Simple Metrics <#metrics> (comparing my VAX to my Alpha) o adding Tape Storage <#tape> o Executive Summary #2 <#p2executive> * Decommissioning VAX <#decommissioning_vax> (2001.09.05) * You Can't Afford to Delay an Alpha Port <#you-cant-afford-to-delay> * Finally, a new Alpha Server DS20e <#a-new-alpha> (2002.01.19) o Licensing Surprise <#licensing-surprise> very good news! o solving a Tiny Little Problem <#tiny_little_problem> (edit: 2005-10-22 what: updated a few hyperlinks *Note:* this page has become rather 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. In fact, this porting job was much easier than my usual programming duties and was mostly done in my spare time (but thank God for the Christmas slow period). Over all, I'm very impressed with Alpha technology and it's priced much lower than VAX while offering much higher performance. ------------------------------------------------------------------------ Porting Diary #1 (1999.11 to 2000.01) Our machine looks like this; just a little less full...Week 1 (My first Alpha...) Our skunk works has just (1999.11.30) received an AlphaServer 4100s (with DUNIX 4.1 installed) from a cancelled project within our company and we've been commissioned to port a relatively large app from a dual VAX-8550 cluster to Alpha. This specific machine is an AlphaServer 4100 5/300 which was manufactured in 1996. It contains 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. * Click here <#alpha_family_tree> to see where the 21164 (EV5) is located on the Alpha family tree * Click * here <#vax_vs_alpha>* to view an " VAX vs. Alpha CPU" chart as well as some charts comparing VAX and Alpha performance in units called PERFs (I guess they don't use VUPs any more). 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). 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. 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: * OpenVMS 7.2-1 * DEC-BASIC our applications were written using VAX-BASIC because this was one of the languages that offered "built in" RMS file support * TCP/IP (UCX) Services for OpenVMS so visitors from other parts of the company can check out the compiler and help test the ported applications etc. * DECnet services so we can copy indexed RMS (Records Management System) files from our VAX to the Alpha * Forms Management System (FMS) - developer version our VAX-BASIC applications were written with FMS calls; Compaq/HP suggests using DECforms for new program development 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 (Windows95/98/NT 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 and start up both 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/HP'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 bit different from VAX-BASIC Week 4a (VAX-BASIC 3.8 to DEC-BASIC 1.3) note: DEC-BASIC has been renamed Compaq-BASIC (and then HP-BASIC) * Compiling large (40K line) programs takes an unbelievable amount of resources and time. The release notes state that this is due to the optimizer which defaults to the highest setting of 4. * 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, I can only imagine what the compiler now has to do when generating instructions for a pipelined super scalar 64 bit RISC CPU * 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) * Compiling small (< 5K line) programs is faster on the Alpha than VAX when optimization is disabled * Almost all programs compiled with VAX-BASIC also compile with DEC-BASIC except for a few little caveats * make sure you convert all HFLOAT declarations to either DOUBLE or GFLOAT because HFLOAT is not available on Alpha. (DOUBLE offers 3 more bits of precision while GFLOAT allows a larger mantissa) * the following VAX-BASIC 3.8 program will not compile under DEC-BASIC 1.3 (you'll get a duplicate line number error at line 30010): 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 "funct1.fun" 30020 %include "funct2.fun" * the following modified program will compile under DEC-BASIC 1.3: 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 "funct1.fun" ! <--- need some text between included functions 30020 %include "funct2.fun" * the following VAX-BASIC 3.8 program will not compile under DEC-BASIC 1.3 (you'll get a "line numbers out of order" error message): 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 "funct1.fun" ! 200 %include "funct2.fun" * a program that calls "sys$crmpsc" (and another that calls "sys$mgblsc") to set up a memory area for "inter process communication" runs on the VAX but will not run on the Alpha. To fix these calls so that they will work properly on both platforms, you must do four things: 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). Notes: 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? *Program Renovation:* Our currently semi-formal method of declaring external functions has made me question whether porting programs to a new hardware architecture will always be safe. Everything has worked properly so far but I keep thinking that 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): * This method is the least formal. * If you accidentally use a "32 bit long" instead of a "64 bit quad" in the sys$bintim system call, no compile time error will be seen. The system call will actually work at run time, but it will overwrite a neighboring variable causing unpredictable results. 1000 ! informal example (we never do this) option type=explicit record QuadWord long long0 long long1 end record external long function sys$bintim ! informal declare QuadWord QuadBuff call sys$bintime("0 ::15", QuadBuff) ! compute delta time 15 seconds from now 30000 end * This method is mediocre. * The compiler will pick up any "data type" or "passing mechanism" errors. The problem here is that every external function and constant needs to be declared. You can save time by putting all often used externals in an "include file" but you're in trouble if Compaq/HP decides to make a change. 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 * This method is the best way. All externals come from text library "sys$library:starlet$basic.tlb". Also note that this library creates a Basic$QuadWord data type which we must use in the system call to keep the compiler happy. If you have a special condition that requires passing a customer data type, set up a record with a variant clause which will overlay a quad type over the custom type. 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 * If you need external constants like SS$_Normal, just add another %include statement to pull in that book from the library. For example: %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 * To view the books in the library, execute the following DCL command: $libr/list sys$library:starlet$basic.tlb * To produce a searchable text file version(s) of the library, execute one of the following DCL commands: $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... * *The Problem...* I've just discovered a bug in module "LIB$ROUTINES" from library "SYS$LIBRARY:BASIC$STARLET.TLB" which affects both VAX-BASIC and DEC-BASIC up to, and including, OpenVMS 7.2-1 . This only affects routines LIB$BBCCI and LIB$BBSSI. I've proved (to my satisfaction) that the library is incorrect while the manual "OpenVMS RTL Library (LIB$) Manual" is correct. A demo follows. 1000 option type=explicit ! %let %method=2 %if %method=1 %then ! this new method crashes at run time %include "lib$routines" %from %library "sys$library:basic$starlet.tlb" %else ! this old method runs properly at run time 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)' else 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' else print 'State bit 42 was previously clear (oops)' end if 30000 end * *The Fix...* In January of 2000 I discussed my problem with people at Compaq/HP and was told it was probably a documentation error associated with OpenVMS-7.2-1 (follow up note: this was finally fixed with the documentation associated with OpenVMS-7.3-1) In library BASIC$STARLET the second argument of these affected LIB$ROUTINE calls are declared to be an address PASSED BY VALUE rather than a variable PASSED BY REFERENCE (e.g. address), the fix requires us to use BASIC's LOC() function to determine the address and then let the compiler use the "library declared" passing mechanism as follows: 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)' else 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' else print 'State bit 42 was previously clear (oops)' end if 30000 end *Compiler Optimizer Fun.* Dealing With Unused code: * When variables aren't used, program lines that access them are removed by the optimizer. * If the following example is compiled with optimize level 1 or higher, no run time error occurs because the compiler "knows" that the variables aren't used so the generating lines are discarded. 1000 option type=explicit declare long a,b,c a = 4 + 5 ! optimizer removes this second b = a / 0 ! optimizer removes this first 30000 end * In this example a run time error occurs when variable "a" is divided by zero. 1000 option type=explicit declare long a,b,c a = 4 + 5 b = a / 0 print b ! this line stops code removal 30000 end Detecting Non-sense Code: * In this example the compiler realizes that appending a character onto a fixed length string will produce no result. This stub was found in a working program! I'm not sure why "optimizer level 1" doesn't produce an informational and the print statement was added just to make sure the optimizer wasn't removing code. $ type pos_demo.bas 1000 option type=explicit map(abc) string dev_name$ = 8 ! fixed length string dev_name$ = "LTA9999" if pos(dev_name$,":",1%)>0% then dev_name$ = dev_name$ +":" ! the problem line !~~~ dev_name$ = edit$(dev_name$,128%) +":" x the fixed line end if print dev_name$ 30000 end $ 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 $ bas/optim=level=1/warn=all pos_demo $ ! no informational More Non-sense Code * In this example the informational is only seen when the optimizer is on. *note:* since expression order of precedence indicates that AND will be evaluated after <>, the DEC-BASIC compiler has detected something we didn't intend. $ type logic_demo.bas 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 print "error: ";rc% end if 30000 end $ bas/optim=level=0/warn=all logic_demo <-- produces no messages $ bas/optim=level=1/warn=all logic_demo 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 * Compaq C (DECC) Language Home Page * VAXC to DECC Migration Guide for VAX (contains valuable info for people needing to renovate while porting to Alpha) * Click RISCy C/C++ Code to read a DECUS article discussing problems that might arise when writing C/C++ programs for RISC architectures 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... Port #1 Executive Summary * starts with a trial port of two large VAX-BASIC apps (with system calls sys$crmpsc and sys$mgblsc) previously running under VMS 6.2 (dorking around with these new calls took up more time then I expected) * finished with a port of ~200 VAX-BASIC apps and ~10 VAX-C apps previously running under VMS 5.5-2 * more time than usual was spent renovating VAX-C programs to run under DEC-C (if ongoing code maintenance had been done on these apps then this wouldn't have been necessary) * total work time was one person working <8 weeks in my spare time ------------------------------------------------------------------------ Miscellaneous Stuff #1 (Public Relations) * So far, this "VAX to Alpha" port has been simpler than we first imagined and is more of a transfer than port. I'm certain this has much more to do with OpenVMS engineering than any skills that I may have. *Kudos to Compaq/HP* * Paul Mifsud of HP Canada (Markham, Ontario, Canada) has been very helpful and prompt in supporting us. Thank you Paul. * Many people believe that Alpha systems are more expensive than the VAXs they are about to replace. Alphas are actually much cheap. Remember that the VAX architecture was totally designed and manufactured by Digital while the Alpha architecture is based on industry standard components like PCI boards and SCSI drives. If you don't believe me then down load Compaq's Windows-based Alpha Configuration Utility and check for yourself. (Oops. The ACU is no longer available. Try this new tool: HP Configurator ) o select "Express SERVER" o select "OpenVMS" (this is a two user base license) o select "Cabinet" o select "DS20E" (this is a departmental class system) o select "ES40 Model 1" o select 1000 MB of memory (yes; one gig of SDRAM) o select 100 Gig of disk storage o select 2 CPUs o select RAID Disk/Tape connection o click "Configure" o resultant price calcs as of 2001-04-25 System CPU(s) Price (US$) DS20E 500 2 x 500 MHz 53k DS20E 667 2 x 667 MHz 59k ES40 500 Model 1 2 x 500 MHz 68k ES40 667 Model 1 2 x 667 MHz 70k ES40 883 Model 1 2 x 883 MHz 85k * Some people think that the Alpha will be eclipsed by Intel's IA-64 (a.k.a. Itanium; Itanic; Un-obtanium) when it appears on the market in the spring of 2002. This may not happen for a number of reasons which include the following: * Intel drove away many industrial customers when it brought out its patented "SLOT 1" and "SLOT 2" interface technology accompanied by sky-high royalty fees Note: "SLOT 1" is for non-Celeron Pentium-II (and up) while "SLOT 2" is for Xeon class Pentiums used in servers. * Compaq countered by bringing out patented "SLOT A" and "SLOT B" technology accompanied by very low royalty fees. (check out AMD's Athlon product) * Compaq needed to drop the cost of Alpha chips as well as get a foot hold on the Pacific rim so they signed deals with both Samsung Semiconductor and Mitsubishi to produce second source components * Compaq and Samsung joined together to form an alliance which will produce Alpha systems and motherboards. The name of this company is API (Alpha Processor Inc.) and their web address is www.alpha-processor.com I should point out that API only deals in Linux and Tru64 solutions, not OpenVMS. *Oops!* API went of of business in 2002-04 after Compaq sold the Alpha design to Intel and Samsung ended their funding of API * Compaq recently asked IBM to produce a copper Alpha to get the clock speed over 1 GHz and IBM succeeded (is this IBM's revenge on the Wintel alliance?) * Alpha technology has been on the scene since 1992 which means it's had a 10 year jump on Itanium. If Compaq keeps the price down and continues to advance the technology, Itanium may become a foot note in history just like the Intel iAPX-432 which was cancelled in 1983. Miscellaneous Stuff #2 (Technical) TOOLS * 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...) * MACRO-64 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: $ LICENSE REGISTER MACRO64 - /ISSUER=DEC - /AUTHORIZATION=OPENVMSFREEWARE - /PRODUCER=DEC - /UNITS=0 - /ACTIVITY=CONSTANT=100 - /CHECKSUM=2-JHNL-LJEJ-CIMA-DOOI $ LICENSE LOAD MACRO64 Click www.openvms.compaq.com/freeware/freeware40/MACRO64/ if you don't have the access to the consolidated software distribution CD-ROMs. DEC-BASIC Compiler Benchmarks * The following test compiles were done on my AlphaServer 4100 which contains a single 21164 (EV5) CPU running at 300 MHz. with a 2MB cache and 256 MB of RAM. Listing was enabled and no other interactive or batch processes were running. I'm sure that newer machines would run faster and later generation Alpha CPUs would be capable of more sophisticated optimizations. * The following results came from a compile of a _2400 line_ program with 5 external functions and many system calls. Optimizer Level Elapsed Time Resultant Object File Size 0 10 seconds 702 blocks 1 14 seconds 702 blocks 2 18 seconds 702 blocks 3 18 seconds 731 blocks 4 18 seconds 770 blocks * The following results came from a compile of a _40,000 line monster_ program (which should be broken up) with 20 external functions and many system calls. Optimizer Level Elapsed Time Resultant Object File Size 0 11 minutes 13,558 1 19 minutes 13,562 2 42 minutes 13,562 3 42 minutes 13,148 4 42 minutes 14,616 BTW, the following system changes were made in order to allow the "monster" program to compile in a reasonable amount of time: AUTHORIZE/my account WSQUO 20,000 AUTHORIZE/my account WSEXT 200,000 AUTHORIZE/my account PGFLQUO 2,000,000 SYSGEN WSMAX 100,000 * The DEC BASIC for OpenVMS Systems "User's Manual" contains the following descriptions for optimizer settings 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 Roadmap (2000.11) * EV56* * EV6* * EV67* * EV68* * EV7* * EV8* * Schedule* *Ship Date* June 1996 Dec. 1998 Q2 1999 2000 2001 2003 * Technology* *CMOS* .35um .35um .28um .18um .18um .125um *Vdd(V)* 2.5 2.2 2 1.5 1.5 1.2 *Packaging* WP/P GA WP/P GA WP/P GA FC/SCP FC/SCP ? * Chip Characteristics* *Frequency (MHz)* 600 575 ~750 ~1000 ~1250 ~2000 *Performance (SPECint95)* 18.8 32 ~45 ~60 ~75 ~140-200 *Performance (SPECfp95)* 29 61 ~67 ~100 ~160 ~300-400 * oops... it looks like there will be an EV7 (a.k.a. EV78) and EV79 but no EV8. It's too bad that Compaq brass believed all that Intel hype about Itanium and then killed EV8 because there was probably much more market life in Alpha than those execs believed. * oops... it looks like EV79 will not happen but a less powerful EV7z will be the end-of-the-line for Alpha. * DEC Alpha Info (Wikipedia) Alpha Family Tree (populated from news releases, leaks, gossip, and projections) Year Product Name Internal Name CMOS Trans- istors Notes Issue Units (Integer/FP) Issue Rate*^1 * Clock Speed (MHz) Instruction Rate (MIPS) 1992 21064 EV4 .68u 3 layer metal 1.7M 1 / 1 xref1 1 (2 peak) 200 200 (400) 1993.5 21064A EV45 .50u 1.7M 1 / 1 1 (2 peak) 300 300 (600) 1995 21164 EV5 .50u 4 layer metal 9.3M 2 / 2 xref2 2 (4 peak) 400 800 (1600) 1996.5 21164A EV56 .35u 9.3M 2 / 2 2 (4 peak) 500 1000 (2000) 1998 21264 EV6 xref3 .35u 15M OOE*^ 2 * 4 / 2 4 (6 peak) 600 2400 (3600) 1999 21264A EV67 .28u 15M OOE^* 2* 4 / 2 4 (6 peak) 750 2800 (4500) 2000 21264B EV68 .18u 15M OOE*^ 2 * 4 / 2 4 (6 peak) 1000 3600 (6000) 2001 21264C EV69 .125u 15M OOE*^ 2 * 4 / 2 4 (6 peak) 1200 4000 (7200) 2001 21364 EV7 xref4 .18u? 100M OCL2*^ 3 *, OCMC*^ 4 *, Glueless SMP*^ 5 * 4 / 2 4 (6 peak) 1100 4400 (6600) 2002 21364A EV79 .125u? 100M OCL2*^ 3 *, OCMC*^ 4 *, Glueless SMP*^ 5 * 4 / 2 4 (6 peak) 1200 4800 (7200) 2003 21464 EV8*^ 10 * .18u? 250M SMT^* * *^6 * ? / ? 8 2000 16000 *Notes:* 01. Instruction Issue Rate: Integer only vs. (Integer + Float) 02. OOE = Out of Order Execution 03. OCL2 = On Chip Level 2 Cache 04. OCMC = On Chip Memory Controller 05. SMP = Symmetric Multi Processing 06. SMT = Simultaneous Multi Threaded (chip level) 07. "A" and "B" series parts are usually just a "die shrink" with the exception of EV56 which also had an "instruction set" extension 08. 21066, 21066A, and 21164PC (PCA56) are not shown 09. 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 * Real World Technology's Silicon Insider o A Tale of Two Chips Alpha vs. Itanium. This chart compares "McKinley to EV7" and "Madison to EV8" o Compaq Sacrifices Alpha and why they did it o The Battle in 64 bit land (revisited) o Alpha EV8 (part 1) includes a chart with *21064*/*EV4*, *21164*/*EV5*, *21264*/*EV6*, *21364*/*EV7*, *21464*/*EV8* o Alpha EV8 (part 2) o Alpha EV8 (part 3) o The Battle in 64 bit land * Advanced info for 21464 (EV8) and 21364 (EV7) o Microprocessor Forum: Designers cut fresh paths to parallelism o Simultaneous Multi Threading Project at the University of Washington (many articles in PDF format) including: + Simultaneous Multithreading: Multiplying Alpha Performance (in PPT format) o www.research.compaq.com/wrl/projects/Database/ including: + www.research.compaq.com/wrl/projects/Database/isca00.pdf Piranha: A Scalable Architecture Based on Single-Chip Multiprocessing (in PDF format) + www.research.compaq.com/wrl/projects/Database/hpca00.pdf Impact of Chip-Level Integration on Performance of OLTP Workloads (in PDF format) * 21264 overview and 21264 product brief (includes EV6, EV67 and EV68) * www.compaq.com/hpc/ref/ref_booth4/sld024.htm Advanced info about 21364 (EV7) * www.compaq.com/hpc/news/news_sc_announce_p4.html o Connect up to 512 667-MHz Alpha 21264a (EV67) Microprocessors at launch o Connect up to 16,000 planned Alpha 21364 (EV7) Microprocessors within two years of launch o www.compaq.com/hpc/ref/ref_sc_announce.pdf * www.openvms.compaq.com/wizard/alpha-techdoc-lib.html Hardware Manuals (EV6, EV67, EV68) * www.openvms.compaq.com/wizard/alpha-techdoc-libarchive.html Hardware Manual Archive (EV4 and EV5) * Compaq High Performance Computing white papers and HPC news * Click RISCy C/C++ Code to read a DECUS article discussing problems that might arise when writing C / C++ programs for RISC architectures * Compaq free Math libraries including CPML (Compaq Portable Math Library) and CXML (Compaq Extended Math Library) * ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html Alpha Console Firmware documentation * Recently rediscovered old issues of *Digital Technical Journal* (DTJ): (this is only a partial list) Digital Technical Journal - Index Digital Technical Journal Volume 3, Number 1, Winter 1991 - first on-line issue of DTJ Digital Technical Journal Volume 4, Number 4, Special Issue 1992 - describes the 21064 (*EV4*) Digital Technical Journal Volume 6, Number 1, Winter 1994 - evolution of 21066 (AXP PC) Digital Technical Journal Volume 6, Number 2, Spring 1994 - evaluation kit for the 21064 Digital Technical Journal Volume 7, Number 1, Special Edition 1995 - describes the 21164 (*EV5*) - AlphaServer 2100 systems Digital Technical Journal Volume 8, Number 4 - describes the AlphaServer 4100 - Instruction Execution on Alpha Processors Digital Technical Journal Volume 10, Number 1, Winter 1999 - last on-line issue of DTJ * Digital Semiconductor Literature FTP area including 21264 (*EV6*). Click here for an html index * Digital Technical Journal (DTJ) has been reincarnated as *Compaq Technical Journal* (CTJ) (note that this is only a partial list) Compaq Technical Journal - first on-line issue of CTJ Compaq Technical Journal #35 (February 2000) - describes the 21364 (*EV7*) - AlphaServer 8400 systems 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. * http://h18002.www1.hp.com/alphaserver/performance/ Alpha Systems Performance * http://h18002.www1.hp.com/alphaserver/performance/perf_tps.html AlphaServer, VAX, and MIPS performance comparison Sometime in 2001 we'll be moving our "trouble ticket management" application from our VAX-6430 to an Alpha Server 4100 5/300. Documents behind the links above say the VAX-6430 has a PERF rating of *125* while the Alpha Server-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* (*S*tandard *P*erformance *E*valuation *C*orporation) * click www.spec.org for more information about SPEC benchmarks *CISC vs. RISC* *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 1. add contents of memory locations 168 and 172 then store the result in 176 VAX (CISC) 1. add3 168, 172, 176 ; many micro-ops are running behind this instruction Alpha (RISC) 1. LDL R0 , 168 ; 2. LDL R16, 172 ; 3. ADDL/V R16, R0, R16 ; 4. 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 skunk works has just (2001.04) received three AlphaServer 4100s (with DUNIX 4.1 installed) from a cancelled project within our company and we've been commissioned to port a relatively large app from a VAX-6430 to Alpha. * Since the second machine will be used as a combination "hot standby" and "development platform", we moved the CPU and memory from the third machine to the first (using the old VAX terminology, the first machine would now be an AlphaServer-4120). An SMP license is required for each additional CPU, and is a little cheaper than a VMS base license. * We ordered the production TCPware license from Process Software (many of our VAX/VMS programs directly call their "FTP Library" and/or "TELNET Library", which means we can't use Compaq's "TCPIP Services 5.1 for OpenVMS") * We ordered the production licenses from Compaq (we already owned some development licenses and used them to get us going while the paper work ran its course) * We started to port the VAX-BASIC code in a way almost identical to Diary #1. The only thing different is that DEC-BASIC 1.3 is now Compaq-BASIC 1.4 for Alpha. * Our VAX-6430 has some services (like a real-timer pager) running from a DMB-32 eight port async mux. Since a similar mux didn't exist on any of the Alphas, we had to acquire a DS-90TL+ terminal server and then moved the async based apps to it, prior to cutover. This was much easier than it sounds. * The production licenses arrived and installed without a hitch (thanks to Stephen Dow of Compaq Canada ). Since the BACKUP, RESTORE, and RECOMPILE scripts were all written and tested twice, we attempted a permanent transfer the following Sunday. * I transferred (and merged) SYSUAF.DAT and RIGHTSLIST.DAT but forgot to transfer VMSMAIL_PROFILE.DATA (which meant that mail messages sent to VMS accounts were not forwarded to our corporate mail server). Oops! * The new machine is so fast that my clients thought the system was buggy when they first logged in. The reason for this was the "node identification page" (from sys$announce) would usually be visible on the VAX while syslogin.com checked the terminal type. Now all that stuff fly's by so fast that we'll either delete it, or add WAIT statements to syslogin.com to slow it down :-) * Since we're on a very tight budget, we were forced to purchase a "concurrent use" DEC-BASIC compiler license (the price is about 1/3 of a "full use" license). This means that ongoing development by 3 programmers may be delayed by lack of license resources, so I decided to start a "long needed" source code renovation to reduce complier time. See the next section for details. * 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_line1.inc" ! in line BASIC code is in [.inc] print funct2(1%,2%,3%) ! 30000 end ! ! 30010 %include "[.fun]funct1.fun" ! BASIC functions are in [.fun] ! 30020 %include "[.fun]funct2.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, - current_dir:my_library/library/selective * 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$tcpware_configure.com 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 dsvconfig.com etc.) freeware tools like ZIP, UNZIP, DFU, etc. see the VMS freeware CD-ROM (or http://www.openvms.compaq.com/download/ ) Mylex DAC960 RAID support^1 don't throw away old Alpha firmware CD-ROMS because all the ones I've seen have directory "\utility\swxcsr" which contains the RCU (Raid Configuration Utility) as well a RAID module firmware. Check out the following link for more firmware: http://ftp.digital.com/pub/Digital/Alpha/firmware/ Kermit^2 async interface software (for use where $SET HOST/DTE won't do) new versions are available at www.columbia.edu/kermit *Notes: * 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 the logical "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: ...snip $ 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) VAX-6430 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 AlphaServer-4100 (EV5@300MHz)^1 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 Notes: 1. a new AlphaServer with EV68 (or 69) technology would make this Alpha look like a VAX (and the VAX look like a PDP) **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. Using this link I found 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 cool (and very fast)...* Port #2 Executive Summary * port of ~400 VAX-BASIC apps (with system calls sys$crmpsc and sys$mgblsc) previously running under VMS 6.2 * total work time was one person working 8 weeks in my spare time * time included source code renovation to cleanup problems created by junior programmers (the old stuff worked but one wonders how? I'm glad we caught this stuff before it bit us on the butt) Decommissioning VAX (2001.09.05) After we cutover our application to the AlphaServer-4120, we left our two VAXs (one production VAX-6430 and one DRP VAX-6410) powered up and connected to the corporate network (with temporary addresses) 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 had installed these machines when Digital Equipment Corporation was still a company and this is truly the end of an era for me. 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. Who knows; maybe Carly Fiorina will revive the Alpha Microprocessor Division. You Can't Afford to Delay an 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 will be available for quite some time, but I wouldn't want to go shopping during an emergency. Link: The End of VAX Hardware Production 2. *Environmental Costs* Alpha platforms are much smaller and thus save valuable real estate. Also, they draw much less power and generate less heat which means that air conditioning costs will be lower. 3. *Platform Costs* Compared to departmental class VAXs 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 are built. Check out the following stub. 1000 option type=explicit declare long i% for i% = 1 to 10 print i% next i% end Notice that the programmer forgot to place percent symbols after numeric constants "1" and "10". The Compaq-BASIC complier for VAX (a.k.a. VAX-BASIC compiler) will generate floats for these numbers then will convert them to longs at "run time" before using them. The Compaq-BASIC complier 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. 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 4120" with a brand new "Alpha Server DS20E". BTW, there was no performance reason to change; the AS-4120 will become a 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 FDDI^1 VGA^2 average SETI work unit time AS-4120 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) 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 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. * (a welcome) Licensing Surprise* All the licenses used to run the AS-4120 appear to run as-is on the AS-DS20. This would not have happened in the VAX days and is probably a good reason to buy new Alpha hardware. * Tiny Little Problem (resolved)* Our DS-20E 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 DS-20 Ethernet port wouldn't recover after reconnection. The next time down, we used console mode to change the port settings from "AUTO" to "10 Mb/s Full Duplex". This change was a mistake since the full duplex setting wasn't compatible with the old hub (it made TCPware appear slow while DECnet phase IV was very flaky). 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* ------------------------------------------------------------------------ Click for the latest reality check from our hero Join the OpenVMS WebRing OpenVMS WebRing Previous SkipPrevious SkipNext Next List Random Next5 * <../index.html>Back to Home <../index.html> Neil Rieck Kitchener - Waterloo - Cambridge, Ontario, Canada. *