DEC: The best of systems, the worst of systems Which were the greatest DEC computers and why? Which were the worst - and why? Everyone has their own definition of greatest and worst, and exemplars of each, but I'm looking at the machines that had the most or the least influence. Since DEC under Olsen got a lot of things right, it's quicker and easier starting from the …
Who could guess where I studied ...
Main computer facilities were PR1MEs (yay !) and Norsk Data (running SINTRAN). However, tucked away in our faculty were two gems, a VAX 730 running VMS and a PDP-11. The year I started they had stopped using the PDP-11, so it was open season ... I got myself setup as an Admin, and taught myself sysadmin skills ...
Wonderful machine, for what it was.
Thames Polytechnic had Norsk Data and PR1ME machines in the 1980s, so I'd guess you studied there. I did too. We used the PDP-11 for cross compiling stuff for 8085 boards, so it was either the same faculty or they had more than one PDP-11. One of my mistakes used enough punched tape to go right around my room in the halls of residence. I also got the badge of honour on the PR1ME, which was to get it to respond "fatal error in crawl out". In my first year there the PR1MES didn't have a full screen editor, so there wasn't much "yay" about them.
My first real taste of industrial scale software development - writing a compiler, no less! Using 300b/s thermal printer terminals over dial-up. Learned a lot about s/w development, and even started investigating the chapter structure of GIII. Was probably quite hackable if I had spent more time on it, but we moved off that and on to PDP11s & VAXen on another project. RSX-11 device drivers in assembly code... Learned a lot on that project too.
.
.
PDP-15 -- like half a Dec-10, with an 18-bit word. Almost the same instruction set. Used 5/7 Ascii (5 7-bit characters) but stored in two words (with the unused bit in the middle).
Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on).
My first real programming job was on a PDP-15. It had core memory and the assembly language manual had a big red warning not to use the: "JMP ." (jump to this location) instruction as it caused thermal damage to the memory. Back then DECUS would give you a LISP interpreter that ran in 8KB or something minuscule.
Then I moved on to Dec-10s and 20s for a while.
I've gone all misty eyed. Time for a beer or three.
"Decsystem-20 -- the poor man's Dec-10, running Tops-20 (Tops-10 with a different hat on)."
There was of course considerable rivalry between the supporters of the two (mainstream) operation systems for the "PDP-10" family. (Other operating systems were available - but not from DEC). There is a recorded view that the DECSYSTEM-20 was indeed marketed at a smaller customer than the equivalent -10, and the -20 never evolved to support multiprocessing as the -10 did in the 1088/1099 models (two KL10As back to back). Where identical hardware (1091/2060 KL10-E) was deployed, you could probably attach more terminals to a TOPS-10 system. But perhaps that was the blue paint.
However, the two operating systems were significantly different. TOPS-20 was perhaps one of the most interesting Operating Systems of its generation and the internals were completely different from TOPS-10. TOPS-20 was perhaps even more thread and process driven than UNIX, and exploited virtual memory and mapping techniques that were not seen in other systems for another 20 years. There are a number of accounts available of the evolution of early versions of TOPS-10 into TENEX (with the addition of university developed paging hardware for the KA-10), and then ultimately into TOPS-20 at the hands of Digital themselves with the introduction of the early KL-10 - but -10 and -20 models ran different microcode to provide the different virtual memory management required (-10s were an evolution of the KI-10, -20s had the full native mode).
What is true is that many utilities and applications (including many DEC products) were shared between the two platforms and the availability of a compatibility package (PA1050) provided with TOPS-20 allowed aspects of the TOPS-10 stack to run under TOPS-20. To the best of my knowledge, native TOPS-20 code could never run under TOPS-10.
Both TOPS-10 and TOPS-20 were however evolutionary dead ends, sad to say. My memory is beginning to fail, but my recollection of TOPS-20 was that the bulk of the OS code was written in MACRO-20 and was highly tailored to the unique PDP-10 architecture with its 36-bit word structure. Extending memory addressing beyond the 18 bits provided in pre-KL and on the KS models always appeared to me to be a real kludge. (I generally found extended sections to be more trouble than they were worth.) It was this dependence on the hardware architecture that would have really prevented movement to other hardware architectures - as was proven as UNIX developed. It is perhaps sobering to recall that VMS went through several major re-writes during its lifetime, and that the OpenVMS that was ported across to originally the Alpha architecture by Digital and later to Itanium under HP (I'm still waiting to hear if it evers makes it to x64) bears little source code resemblance to the V1.0 version VMS that shipped for the VAX-11/780 in 1977.
(mines the one with 36 pockets)
TOPS-20... sob... I get all misty-eyed...
Over the years I've worked with/on these systems:
ICL 1903/George II
PDP-8 (assembler programming in PAL)
ICL 29xx/VME (I think... the memory isn't what it... erm...)
DEC/Tops-20
IBM VM/SP, VM/HPO, VM/SF, VM/XA, z/VM
IBM OS/VS1, MVS, DOS
various Vaxen
DR DOS, MS DOS, MS Windows 3/3.11, 95, 98SE, ME, 2000, XP, Vista
Apple Mac OS 8, 9, X
GNU/Linux (various distros, my favourite's Debian but don't ask me about the organization)
various others like BeOS, Symbian, the BSD variants, ReactOS, PETs, Zillog m/cs etc.
and there still isn't anything (not even my beloved VM) that can hold a candle to TOPS-20! Decades ahead of its time!
Sob, sob, sob...
Slag the Alpha as much as you will, it was still a performance leader until poor management killed it.
Much of the architecture used today in X86-64 cpu's have DEC engineers to thank for getting them to where they are today.
Let's also not forget DEC's contribution to storage. They had pioneering work in SCSI systems and created what is today's Storageworks division in HP.
Had the company had better leadership and marketing the current lineup of vendors may have been somewhat different..
Its the single best chip I've used[*].
We used an AlphaServer 1000 (a PC minitower sized box with a single 150 MHz alpha chip and I forget how much RAM, but probably 255 or 512 MB) to support an 18 strong development team, writing a system in C that sat on a RedBrick data warehouse. Members of the team used PCs running eXceed as terminals with a copy of RedBrick for everybody. Despite this load response times were excellent - editing and trivial commands were instant. I don't remember ever waiting longer than I expected to for a system build or a test run. The Alphaserver's only draw-back was the rather uninspiring Mach-based DEC UNIX.
[*] I say this despite the fact that I was and still am a 6809/88020 fan. I still have an OS-9/68000 v2.4 system that gets used several times a week. I've had it for almost 20 years and never fallen over a bug in the OS or utilities. IME only OS/400 can come near that record.
Yes, many interesting memories over the years. Here's one that few people may have realised was possible. Back in the late 1980s a certain large British (nay imperial) chemicals company was implementing a 'market intelligence' system based around the ALL-IN-1 products. Availability was wanted fairly much 24x7 (yes, it was on a VAXcluster) however as anyone who has designed infrastructure to support ALL-IN-1 will recall, it was necessary to ensure that the whole of the file store was backed up while fully consistent. That really meant shutting down the system and trowing all the users off while the backups were performed. Our solution was to use the (RA8x) disk mirroring capability of the HSC storage controllers to break out a member of the mirror-set(s), mount it up and run the backups against those volumes ... then of course re-sysnc them back into the mirror sets. EMC BCVs eat your hearts out - this was when EMC2 (remember the 2 superscript?) was still a bit player selling add on RAM and other boards. I still have the glass tankard given me by an EMC2 salesperson to prove it!
I guess that alongside the other great Digital systems I've worked on from DECsystem-10 and DECSYSTEM-20 of various flavours (including having a Jupiter order canceled under my future employer when the LCG part of DEC was killed in 1983 - does any body in the UK remember the York meeting when this was commincated?), a number of PDP-11 hardware variants and operating systems, virtually all types of VAX system (save the 9000 which ought to be explicitly called out in the list of DEC super-losers) and through into many flavours of Alpha with both VMS and Unix, I stayed an advocate of Digital storage through to the end of the true StorageWorks era and participated in the Digital Storage Fellowship programme.
So, like many others on this and other threads I too owe a considerable debt to Digital Equipment Company. Although I have never worked for the company, the skills and attitudes have left me well positioned to meet many career challenges. Even today, working in an outsourcing business it is still fun to run through asset lists from contracts to see how many VAX and Alpha boxes are still running out there. It's far more than many people might expect.
I deployed and administered Alpha systems for years. I like several things about this system
- speed
- clean 64 bit. There was never any 32 bit baggage lying about, and so no worrying about which friggin' kernel you're running, or if the correct libraries are installed.
- Tru64 Unix - Compared to other mainstream vendors, this kicked ass. One great example - fiber channel storage just worked. Another - ethernet link aggregation.
- TruCluster - Version 1.5 was administered from a single command - asemgr. The problem with so many clustering solutions today is that they are so complicated that they undermine uptime. Version 5.x featured "single root" clusters. No other Unix system could do that.
- Tech support, forums, and support in the open source community. Mostly, I could just build open source software and it would just work.
What I hated, was DEC's licensing program. If your licenses expired, you were dead in the water with a non-functional system. Not so good for national systems.
It was my way of circumventing procurement rules during dot.boom
In the company I worked at the time procurement and someone from engineering located in the higher layers of atmosphere set a rule: "Only Sun Solaris allowed". So the choice was between Netras and later Netra T1s which the deployment team stacked by the lorry load into racks and left powered down until needed (usually never). Both sucked performance wise and both ran only Solaris in those days.
So I circumvented both suckage by saying "I need 64 bit for my stuff, sorry, get lost" and ordered the Samsung Alpha PC clones and put Debian on them. 64 bit linux in 1999. It rocked. They could run circles around a contemporary dotbomb netra any day of the week performancewise. It is a pity that it died a slow death during all the mergers DEC/Compaq/HP executed in those days.
assembler, I have to say I loved the VAX architecture, reminding me immensely of the Motorola 68000 architecture.
The debug tool for VAX/VMS languages (all VAX/VMS languages, from MACRO-32 to C/C++ to COBOL) was also years ahead of many similar tools found on other operating systems.
"Don't get me started on the Alpha…"
Maybe I am sick but I really liked the Alpha. They were my first introduction to DEC/Digital and the great support and approach to their technical users that they provided at the time. I kind of worked my way backwards from Digital UNIX to OpenVMS, then VAX VMS in a kind of weird collecting responsibility for systems that began with 'D'. I still miss my AlphaServers.
Memories...
The thing about the VAX is probably a sacrilege - this was the system which brought 32-bit computing to the masses, after all... I started on a 730, well built but slow; then a few 750s, 780, 785 and ended with 8800 (and some 4000 as far as I remember). And also a few MicroVAXen, had one beside my desk, real object of pride (it was actually a VAXstation).
The Rainbow wasn't *that* bad when it arrived - comparing to the other similar pieces of crap we had at the time; one could run either CP/M or PC/DOS, but what killed it for us was the weird pre-formatted floppies we had to use. Anyway, I think we had only two of these.
You've missed the Professional 350 and 380 workstations - again something to behold... The 8800 VAX I worked with had one of these as its console... still remember how to turn the VAX on - wellm the command was 'POWER ON', given at the console prompt of the Professional ... all the fans then came together...
To this list I'd add a few 11/40s, a single 11/45 and several 11/70s, which I liked a lot. Got my first UNIX on one of these, although don't remember the exact edition.
As far as the PDP-15, at one stage I was about to start doing my master thesis (in interactive computer graphics, that was 1980...) on one of these - actually an XVM - so I went through the manuals and especially the assembly, but was lucky - the machine was deemed too sensitive for a student to use (it was used to design PCBs at the time), so my experience with these is nowadays limited to playing with SIMH - still have a few virtual machines running DOS/15. The master thesis had to be done on an early HP - 2637A, called "Intelligent Terminal" - had to program a lot of linear algebra, matrix analysis and differential geometry to get the thing running - in BASIC...
SIMH is also what I run when I want to remember the VMS days (the VAX machine running under OpenSolaris on a quad-Opteron is faster than anything I've seen in metal...). As far as the LISP machine mentioned, I got the interpreter running on a SIMH PDP-1 machine - weird... computes the S-exp after you close the bracket, no returns.
Memories...
It was sometime in the early 80s and I was more interested in what could be done with it.
We had some fine kit in the next few years. I seem to recall an Evans and Sutherland colour vector graphics display run by a bit-slice processor and with a PDP11 as its file store.
By the time I retired we had stereo-graphics equipped dual xeon workstation running Linux with access to 1024 machine Linux clusters for the 'hard' stuff. Some of the easier protein modeling took a weekend to run on dual xeon machines
Remember DEC's funny turn with the DEC-10 and DEC-20? They were a little bit cool.
As the the VAX.. I used to run a VAX 11/750 which had the innovation of running on single phase supply, which meant that you didn't have to rewire your office for three phase. Yes, that kind of thing actually helped to sell it in the old days..
No sorry, the KL-10 was by no means 'cool'. How many times did we find our DEC on-site Field Services rep curled up having a kip in the KL-10E (2060 ie an orange one) expansion cabinet? Very nice warm comfortable spot if I remember correctly among all that ECL logic!
Talking of KL-10's, was the 'Massbus' replacement CI and Ethernet option the most expensive NIC ever? My memory is of the order of $36K (Thirty Six Thousand US dollars) in the late 1980s.
BRIAN: I haven't got anything against the VAX. Consider the Alpha.
ARTHUR: He's having a go at the Alpha now !
------%<------
BTW what do you have against the Alpha ? My only personal memories were of a 500MHz Alpha Firestorm workstation I used that was the fastest thing I saw for years... and they seem very well respected in the HPC community.. so what gives ?
I still have a rosy glow about the day when, as an apprentice, I was shown how to put together a small programme on an PDP11( but don't recall the variant) then switch off the power, move the core store card to another machine and start it up and run my programme.
After that came the history lesson in bootstrapping with three way switches to feed in the commands...that was when summer where always sunny and big companies still hosted hog-roasts on open days.
"(Be prepared for an extended performance. Earplugs are recommended. So is a fire extinguisher.)"
I would also recommend a full nomex firesuit, down to the underpants. :D
Too young to have seen a PDP or a VAX, but I do remember the alpha- interesting chunk of hardware, that was.
I spent a lot of time working on DEC PDP-11 and VAX, even a PDP-10 system at one location. I was an accomplished RSX system programmer at one time, and I still admire features of that operating system that Windows has never gotten right.
I still remember the day that the local DEC sales staff came to our shop (a major DEC account) to put on a seminar on how Unix was the future (DEC having seen the light), after bashing Unix and promoting the advantages VMS for years. They seemed lost and uncertain, and in retrospect that was the end of DEC. The failure to launch a successful microcomputer, and the subsequent purchase by upstart microcomputer maker Compaq were just the nails in the coffin.
Had huge rooms of these to do satellite command & control, telemetry processing, etc., when I was a mission controller in the 70's & 80's. The PDP's just ran and ran 24/7 and virtually never failed. Even after the VAX was introduced, the 11/70's were kept to do the real-time stuff.
The only pervasive problem that I recall was when the techs took the systems down every 6 months or so for "preventative maintenance". Upon re-powering, more often than not, some of the "boxer" fans used for cooling failed to spin up again and had to be replaced.
Have to agree, that was *the* PDP, but I disagree about the VAX. Maybe not so simple, but clean and elegant. Macro32 was a joy to program in, what wouldn't I give for a MOVC5 occasionally :)
Nova? Can't comment, closest I got to DG was "Soul of a New Machine".
For a real flamewar, though, you'll have to go to OSes. Nothing compares to VMS, which was perhaps the last real OS to be *designed*, rather than to have simply evolved from a hacked prototype...
<nomex on>
"The" Boston Computer Museum was the result of Gordon Bell's personal project, the Digital Computer Museum, outgrowing its quarters at DEC's Marlboro facility (itself a relic of technological advancement: it used to be an RCA facility):
http://en.wikipedia.org/wiki/The_Computer_Museum,_Boston.
PDP-11 blew the Nova away. There was a reason Bell chose the 11 over the Nova architecture. The 11 architecture and the concept of auto increment/decrement general purpose registers which could be used as either data or address registers lives on in the Motorola (Freescale) 68000 CPU design (disclaimer: I used to work for DG designing comms boards)
//mine's the one with the (pocket sized) PDP-11 hardware manual in the pocket
TTY terminals with paper tape readers, machine code patches via computer front panel switch register entry, Mylar tape for "Golden" delivery. Magnetic Tape OS, Real Time OSs, even hybrid analog/digital computers using linear analog circuits for computing transcendentals because digital math was too slow. Rivalry between DEC, Data General, Prime and even HP.
Fond memories, all.
The DEC engineer said it would do no harm to move our 11/23 upstairs as long as we removed the disks first. What he didn't mention, and we didn't discover until several hernias later, was that the cabinet (about 5 ft high by 2 ft wide) contained huge lead weights for stability.
The company bought the 11/23 with a turnkey accounting package, but the MD haggled the price down so far that the suppliers went bust before they could implement it properly so the machine just gathered dust up a corner. I taught myself to program in Dibol on it.
I won't hear a word against the VAX or VMS. Exploring the amazing system sevices and run-time library was an unending source of fascination - and the results were often actually useful. It would make my day when I could find an excuse to use LIB$TPARSE, a finite-state parser. (What a saddo!)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
