Slashdot Mirror
VAX Users See the Writing on the Wall
Snot Locker writes "An informative piece at ComputerWorld talks about how VAX users are anticipating the costly migration to more modern systems. Several noteworthy tidbits, including hints of the port of OpenVMS to Itanium and the tale of VAX systems that have not had a reboot in 6 years!"
I didn't see THAT coming!
Javascript + Nintendo DSi = DSiCade
If any VAXs admins are reading this and are preparing to send their machines to the landfill, why not check to see if your hardware is on OpenBSD's wanted hardware list? They actively maintain a native VAX port (and it's damn good geek karma!)
Trolling is a art,
Seems to me that 6 years of uptime will have most likely saved the company about as much money as it would cost to migrate to an updated system.
Yeah, I worked on campus in the IT department all through college back in the early 90s. We had a VAX that ran pretty much everything, and I don't think it was rebooted a single time the entire time I worked there. When students started demanding shell accounts to access the Internet (remember, we're talking pre-Mosaic here) we just added a couple extra hard drives to the VAX to provide enough space for all the students to have a couple meg of storage, and the system handled the load without a problem. We're talking about a fairly large (10.000 student) system here... it just worked. Nary a hiccup.
These are rock-solid systems that are trouble-free to the point of being kind of silly... but replacement parts were hard to find even back then. (Their VAX had been purchased in the 80s I think.)
The article mentions a VAX emulator that sounds like a much better option than the one chosen by the school I worked for back in the day: an unbeleivably expensive (nearly million-dollar) migration to an Oracle solution that never did really wind up working. (They have since migrated many of the processes to PAPER for crying out loud.)
--- JRJ
jrjBlog
...a computer that has literally run from since before Windows 98 existed until now without being rebooted.
Hell, with the critical-update-du-jour lately, it's probably hard for Windows users to imagine a computer that's been running since the previous week without being rebooted.
ComputerWorld confirms: VAX is dying
In all seriousness, the fact that VAX is still around is a testament to how damn well engineered those machines are.
No reboot in 6 years?
Hahaha....i have a computer that has not had a reboot in almost 10 years.
In fact it's still somewhere in the closet.
I should plug it in sometime....
Slashdot Sig. version 0.1alpha. Use at your own risk.
About a year ago, we switched data centers, and had to power down our rack of x86 machines running Linux. A couple of them had redundancy in hardware (power supplies, RAID arrays, etc.), but the majority of them, working as a load-balanced web farm, had no redundancy at all.
Out of the rack of machines, nearly all of them had been up for the full two years that they'd been in the data center. Of the few that hadn't been up the entire time, *one* had a power supply die, the others were shut down for hardware upgrades.
Now, a year later, all of the machines are still up and running. I really don't have any doubt that a fair number of them would have achieved 6-year uptimes, had they been left in place long enough.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
Lizzie Borden took an axe,
And plunged it deep into the VAX;
Don't you envy people who
Do all the things YOU want to do?
[Unknown]
The article mentions mainly about how they are looking at emulators because HP/Compaq isn't producing any new VAXs. I'm guessing HP will release a new "VAX" that is just a custom emulator running on top of intel's lastest. From a marketing point of view, it's what I'd do.
Dec had a large program back when to move Vax binaries over to the Alpha. The VEST software.
VEST
Is there really an "end of the road" when the binary keeps on living in sort of a Matryoshka
doll fashion?
Hedley
the_VAX_writing_is_on_wall.txt;252
On the bright side, it had enough other POSIX stuff (file I/O, pthreads, etc.) that the rest of the port was pretty easy.
Logicals are actually kind of cool - a bastard cross between environment variables and symlinks, but you could do some neat things with 'em.
PHEM - party like it's 1997-2003!
The US Army is still using VAX systems for the Bradley Fighting Vehicle turret simulator to train crews in gunnery. Most of the simulators that were bought in the early 1980's are still going strong. AFAIK, no plans to replace them anytime soon. The damn things have be set on fire to get them to stop working.
Well, most VMS users run on Alpha and has done so since more than ten years. It's not like all VMS users are stuck on VAX and only now has an alternative with Itanium.
Funny, the article does not mention Alphas. Has HP buried that architecture so well?
)9TSS
The fact that some VAX systems haven't had a reboot in 6 years reminds me of a story my HP/Compaq representative told me about the reliability of their Proliant servers. There was a server in a data center that handled user logons to the Novell client. One year the data center was remodeled but none of the servers could be moved because users still needed to be able to log on. So they finished remodelling the room and accidentally walled in the server. 3 years later someone finally decided that it was time to upgrade that server. When they went to look for it, it was nowhere to be found. It was still running after 3 years and hundreds of thousands of logons later. (They finally contacted the remodeling company and figured it out.)
I don't envy those poor VAX folks having to migrate over to itanium, whose future is very much in question just now. Almost every week now, a report comes out about how disappointing itanium sales are, how software vendors are abandoning it, or not developing fot it in the first place, and how HP and intel keep revising their sales projections and PR fluff. itanium has gone from "going to be the defacto 64-bit standard CPU early in the 21st century offered by all major vendors" to the most widely deployed in 2-way servers and up, to 8-way servers and up, and now it will be regarded as a success if it achieves moderate acceptance in niches at the very high end. itanium was to rely on economies of scale to recoup its R&D expenditure and to become profitable. Now it will have to limp along as a costly, esoteric niche player. How long can intel and HP keep it propped up? When will the money dry up? When will HP cut its losses and move over completely to intel's Opteron clone?
Stick Men
Right.
Show me RMS's heavier and less-well-groomed brother in Birkenstocks, a T-shirt, and suspenders and I'd be a little more likely to believe it.
Dewey, what part of this looks like authorities should be involved?
Uptime of 6 years ?
Pah. My abacus (which has been handed down through 3 generations) has had an uptime of nearly 100 years. And apart from missing a few of the counters (I was a curious child) it still works great.
Them thar 'puters are just new fangled junk.
Sky subscribers are morons. They pay to be advertised at !
Holy crap! Did the phrase "Y2K" mean nothing to these people?!?
What happened to /. today ?
It looks like troll's fest day!
First backup tapes, then Microsoft, now VAX.. what's next BSD, Apple and Sun ?
Oh.. and has Netcraft confirmed it yet?
I learned C on a Vax during my freshman year of college. I also maintained my email account on one for all five years I was there. We had three vax machines grouped in a DecNet cluster. One was the original 11/780 model, and was nearly as old as me. It still worked without a hiccup, and met the mail needs of nearly 20000 students.
It's good to use your head, but not as a battering ram.
It's runs an enitre depratement and we love it.
Most people's problem with the vax is caused by
their reckless disregard for safety.
Always rember to bend at the knee's when you
bang your head against the wall. If you bend at your
waist you'll throw out your back.
1 user at 3 in the afternoon - doesn't sound like a particularly busy machine - consider that the (large) boxes in question have had probably millions of logon/logoff cycles, compilations, test code, patch applications and so forth.
I think there'll be some Vaxen clusters out there until cockroaches are extinct. We had a cluster once where I worked and no one could figure out what it did but were afraid to turn them off. We just moved the boxes around and rebooted them when they got in inconvenient spots. They'd just keep running and running. I'm sure there are factories running Vaxes that would shutdown if they stopped but its been so long they needed attention no one would know what to do if they died. Truly amazing reliability. Nothing's come close to them despite years of trying. VMS is ugly and slow but it's rock solid compared to its bastard step-child Windows.
I remember VAX quite fondly. I wasn't exposed to it until 1995, when I went to college, and haven't really bothered with it then. But now it begs the question: did we ever really -need- to advance?
Sure, now we've got amazing graphics capabilities, and games that can make real life seem dull and colourless by comparison. But you know, games were just as much fun back then too. Who here never played Zork? Who here never played on a MUD? Okay, okay, probably several of you, but still... Even with all the amazing graphics, it seems like games were more fun back then... so games aren't the reason...
Business? Businesses ran fine on the tools available at the time. It did just enough work to get the job done. Sure, people had to do some extra work here and there, but since there weren't a billion pre-packaged automated features, what work the computer saved them was considered a blessing, rather than a hinderence. So business isn't the reason.
Communication? Bah! We communicated just fine. Email worked, BBSes worked, phones worked, fax lines worked. If we needed to make a call away from home, businesses usually let you use the phone, or make change for the payphone. Unless you were a doctor, there wasn't a single phone call or message you just couldn't stand to go without for 10 whole minutes. So communications wasn't the reason.
Was it for the Entertainment Industry? Sure, computer graphics gave us amazing films like Harry Potter and Lord of the Rings, but before that time, directors knew how to make us truly -believe- we were seeing a monster in lieu of some puppets and paper mache. Alien had very little in the way of computer graphics. I don't know that Star Wars (ep 4) had any... yet they remain icons of the Sci-Fi film industry to this day. Their CGI counterparts are often lame in comparison. So it wasn't for movies or TV...
Why then, did we really need to advance so far, so fast, in the realm of computers? And why take a good thing like VAX and cash it in, just because it's old?
-The Libra
"Please be patient--The future will begin momentarily."
You must reboot for the change to take effect."
[ OK ] [ Cancel ]
C:\WINDOWS\Desktop>uname -sr
Bad command or file name
hmmm...
do not read this line twice.
Yup. The end of life for the Alpha was announced a while ago. I belive that the current generation of chips (EV7) is the last, with the EV7z from HP the really last new Alpha.
Now, whilst it's perfectly possible to migrate from a VAX to OpenVMS on an Alpha it's a bit short sighted to migrate from a old platform to one that's about to enter the same state. The sensible stratagy is for something with a longer lifespan. The Alpha was intended to be that, back in the days of DEC, but Compaq basically folded the Alpha into Intels Itanium chips, which are quite different.
HP talks about supporting Tru64 on Alphaservers up to 2011. I read that to mean that after then, if it breaks, that's it, so you'd better be migrated off it by then [0]. So, given about a year to fully migrate, switching to Alpha would only give you 3 years (1 year to switch to, 3 years, then 1 year to move on). That's not a good proposition, at least to me.
So, the short answear was, yup, Alpha is buried, and the turf goes on top in 5 years.
[0] Granted, that's the possibly just the OS side. It's tricky to get hard details out of HP, short of cornering someone.
Remember when you could (vax) mail escape codes to send the recipient's vt100 terminal into hardware-reset-until failure mode?
Six years of uptime is pretty impressive for a computer. But it's even more impressive for the facility. Seriously -- what kind of UPS and equipment redundancy would you need to get that kind of uptime?
Alpha is on life support too. EOL is in 2012, I think. See HPs web site for the whole story.
A previous poster mention emulation on emulation. I've seen it done, and heard of others doing it.
When the PDP-11s were EOLed, we ran RT-11 apps using the RT-11 emulator under the RSX-11m emulator on VAX/VMS.
I've heard of people running IBM 650 apps on an emulator that ran on a 1401 emulator which they ran on OS/360.
--dave
davecb@spamcop.net
The article mentions SRI's Charon VAX. This is very expensive software that requires a USB dongle for licensing.
However, you can also run VAX VMS on a free i386 VAX emulator called SIMH. I don't seem to be able to get very good ethernet performance with SIMH. However, you can run NetBSD/VAX on it out of the box, and OpenBSD will run with a kernel patch. SIMH also has a PDP-11 emulator and includes images of the original UNIX V7 from AT&T (courtesy of SCaldera). SIMH is an interesting way to run both ancient and modern UNIXen without reformatting your PC.
You can also get free VMS licenses for SIMH/VAX. They must be renewed yearly.
Alpha VMS also supported a VAX binary emulator called VEST, which is mentioned in another post here. Support for VEST is dying, however (modern RDB releases have dropped it). The Charon VAX emulator also runs on Alpha VMS.
Don't worry, even if someone erases the writing on the wall, VMS users will be able to see it, along with the 20 previous versions.
To feed an industry that is based on the notion that obosolete hardware is somehow less useful than when it was new. If you and I just bought everything once, they would not be as rich. So we must be enticed to junk still working goods for new ones.
On the bright side, it's a golden age for ebay vultures like myself...Free Mac Mini Yeah, it's
This is an old story but it seems fitting here.
)9TSS
You can't have more than one person using a computer at the same time! They'd fight over the mouse!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
A few answers:
(1) People without significant training and heavy motivation could not learn how to use computers in the "good old days". We only had a market of maybe 30% of the population capable of using them. For computers to spread throughout society, this was not good enough.
The computer industry wanted to spread, for financial reasons if nothing else, and so they made the changes needed to make computers easier to learn and use for non-experts.
(2) Marketing. People want pretty things. People can be convinced to upgrade to something "better" by giving them more pretty things. Even if the old, cerebral games were more fun, the new, slicker graphical games took over the world because they were pretty, and because many of them took advantage of people's natural desire to shoot other people. (I have never understood this, personally, but it's the truth).
I have thought many times that older computers are better, mainly because they were more reliable, and sufficiently simple that a reasonably normal person could understand how they worked, and how to fix things if they broke. Today, I doubt that any single person understands everything going on in a contemporary operating system.
Few people seriously want to go back to the old days, when 24x80 terminal screens that cost as much as a used car were all the computing even well-connected people could have at their homes. I have to admit that I'm nostalgic enough to try and find a good used MicroPDP-11 on eBay, just to say I have one. That being said, I'm not sure how much use I would make of it, and all the weird programming restrictions would surely be archaic. But it would still be nice to have an example of computing history, when we all feltl like elites who might somehow wind up changing the world.
D
You're forgetting one important area; science. Science demands fast processors and large capacity first, and reliability/dependibility second. Sure, scientists love to have dependable machines, and such is the reason most run Linux,BSD,SunOS/Solaris, or other such OSes, but they are much more concerned with number crunching on obscenely large data sets. Most of the current advances in science simply couldn't have been achieved without the powerhouse computers the are currently available.
Although I do agree a lot of our so called "progress" in computers have been steps backwards, it's not fair to say there hasn't been a single important step forwards.
Then install NetBSD on it..
---- Booth was a patriot ----
I'm not an expert in this field, but it seems to me that there are two ways to get six years of uptime.
(1) A single highly-engineered machine (yeah I know VAX/VMS has clusters, whatever they are).
(2) Redundant cluster of many interchangeable parts.
Google has figured out how to do (2) successfully.
I bet that (2) is harder than it looks. How do you protect against a common mode failure in your system software? Do you run a variety of genetically independent OS's and databases's, or do you run identical software on each machine, leaving you open to monoculture failures?
Digression: It's beautiful how eukaryotic organisms solve this problem by having two independent copies of each gene. But if a gene is broken, it generally does nothing rather than produce a lethal result. And the robustness of individual eukaryotes is not enough for the requirements of computers.
A good intermediate step in any migration is to use the SIMH simulator (http://simh.trailing-edge.com). SIMH can simulate quite a few systems (including a VAX) at the CPU level. As you may expect, this involves emulating every single CPU instruction... not a very efficient way to run code! However, its saving grace is that modern processors are very fast and old VAX systems are not. Depending on how old your VAX hardware is, you might find that an emulated VAX running on a newer P4/Xeon/Athlon/Opteron will be faster than the stock VAX!
This doesn't solve the migration problem but it does allow you to run your old code on modern easily-fixable and readily-available hardware. Beats having to get all of your parts off of eBay.
The amazing part about 6-years of uptime is that back in the 1980's we took it for granted! Most mainframes can stay up as long as the power reamins on. Only Windows can make us appreciate the value of perpetual uptime.
One of the reasons we had such uptime was that the software update cycle was very slow by modern standards. Every few weeks, Digital would send us a 9-track tape to update one of our products. VMS was generally once a year between major releases. Anything except an OS update could be installed without rebooting.
Before we had all of this object-oriented programming, the concept of memory leakage was much easier to debug. Also, VMS would exercise tight control over system resources -- a runaway process might cause a slowdown, but processes were limited in their ability to consume memory and page file space.
When there was a crash (it happened), we would call Digital customer support. They would actually read the crash dump and determine hardware or software, and either dispatch field service or send out a patch to be installed. It cost a fortune, but it sure beat the modern concept of calling tech. support and dealing with a semi-literate script reader.
We had three Vaxes in a cluster, attached to a pair of redundant disk/tape controllers. To this day, I hear people talk about the wonderful world of Windows (or even Linux) clusters on Intel boxes. The problem is that without multiple independent paths to your disk drives and something like the distributed lock manager, there is really no protection against the loss of a CPU or a disk controller. Digital had all of this figured out. It must have been quite an accomplishment, because I have seen mostly poor imitations of VMS clusters since that time.
o/~ Join us now and share the software
VMS uses a 64 bit date/time format that rolls over sometime slightly after the Sun runs out of hydrogen, so you're right, Y2K was pretty much a non-event to VMS users, even less than it was to Unix users. Unix users better start worrying about that Y2038 problem pretty soon...
DEC sales guy, to military contractor: "You're not our only customer, you know!"
Military contractor: "No, but we're one of the few with tactical nuclear weapons."
Seriously, VMS is/was great. I started working on VMS systems in the early 80s, did my doctoral research on them, and ended up managing a bunch of them for a while, before our department migrated to Un*x. I like to say that VMS is to Un*x as Python is to Perl. One is the ultimate in organization, the other is the ultimate in freedom.
And you really think you can compare the uptime of an X86/Linux box to that of a VAX?
You had a handful of PCs stay up for two years. That's not bad, but one cannot simply extrapolate uptime - it just doesn't work that way. That's like saying "I lived to be 60 - I'm sure I'll live to 180 if I'm careful".
Besides, in general the effective lifespan of a PC isn't much more than five years. Your PCs are in the second half of their useful life; I'm sure the VAX is too, but its lifespan appears to be about 10X that of the PC.
Not flaming, btw - I think PCs are useful for a number of tasks; however, long life and long uptime are not part of the PC genome. Sorry.
I want to drag this out as long as possible. Bring me my protractor.
We're currently migrating a perfectly good Finance system to ASP.NET. Its been on a VAX for 15 years and works fine, but there is just no support left. The probabilty that we will still be using the same ASP.NET in 15 years is very low...
I'm still partial to the humor that the programmers added to the system. Like variables that are expressed in microfortnights, or an error message that reads, "Shut 'er down Clancy, she's pumpin' mud."
...I worked withVMS... VMS was my friend... and, Windows NT, you're no VMS!
Very seriously, in the early years Microsoft kept saying that Windows NT was "similar" to VMS. So when we ran into various problems, I would look for Windows NT equivalents to familiar VMS utilities.
They weren't there.
And the five-foot-shelf of well-written, comprehensive, accurate documentation in China Red binders wasn't there.
And the source code on microfiche wasn't there.
I have no doubt that in some core internal details the two systems were similar, but at the level of the ordinary user AND the ordinary system manager, VMS was far more mature. I miss VMS, and I miss Digital.
(I knew Digital... Digital was my friend... and Compaq, I mean HP, you're no Digital.)
"How to Do Nothing," kids activities, back in print!
(1) You can put a lot more quality components in something that cost half a million than something costing half a thousand. The ethos was "how can we do this?" not "how can we save $ 0.50 a unit?"
(2) Their operating system didn't have to be compatible with an ancient OS created when computers had a lot less power. Like current Macs, Vaxen had an emulation layer that allowed PDP-11 programs to be run, but they didn't run a crudely-updated version of the PDP-11 OS.
By dramatic contrast, Microsoft took DOS and built Windows on top of that rickety foundation. Even though Windows was rewritten to create NT, 2000 and XP, there are still traces of the old, obsolete technology, because the new operating systems have to be compatible with the ancient programs. These interactions are difficult to manage and wind up causing significant reliability problems.
(3) The market didn't demand it. Consumers and business owners want more features, not something intangible like more reliability. They have accepted the reliability levels of Windows(tm), and therefore it is obviously not that important to them.
(4) As I have said before, VMS and Unix are sufficiently simple that they can be understood by mere mortals. The addition of a GUI and complex backward compatibility hacks makes this impossible for more modern operating systems.
All these factors make new operating systems - especially Windows, but not exclusively - far less reliable than the mainframe/minicomputer systems of old.
Hope that helps.
D
The strange thing is that Windows XP is an indirect descendant of the OS that probably is running on those VAX systems with those giant swinging uptimes. The story goes that back in the day, the Windows NT team had a large number of VMS vetrans on board, and that there was more than a little bit of code in common between VMS and Windows NT. The story is actually kinda interesting; you can read about it here.
The urban legend is that Windows NT is so called because if you "add" one letter to each of VMS, you get WNT (like with HAL and IBM). And then if you're feeling snarky, you say something like "see, you had to know that the NT couldn't stand for new technology." But you probably shouldn't expect anyone to laugh.
Modern systems, eh?
Funny how those obsolete VAX/VMS systems just keep on going. No crashes or reboots, flawless clustering (remember how the Dutch police moved to a new building with ZERO downtime, just by migrating processes from node to node?), rock-solid security, and tools that let admins manage huge networks of servers and workstations with ease. So-called modern systems, like Unix, are now where VAX/VMS was, what, 10 years ago, 15 years ago in some cases. Sun clusters? A joke! The failure of VAX/VMS is one of DEC's marketing department, not their engineers.
When Digital fired most of its VMS team in a cost cutting frenzy, Mirosoft had the good sense to hire them up. David N. Cutler who was the VMS project leader became the NT project leader at MS. Cutler brought most of his team with him. The result was that NT was in many ways a clone of VMS with a Win32 API and Win16 API layer on top. The story is famous and is told here.
I remember working for DEC as a student worker. We had one VAX that supported our entire group (VT-XXX terminals using LSE). Today my laptop is more powerful than that VAX.
I also remember when we got an upgrade to the "new" VAX line. The old ones used to be these big washing machine types of machines, we had them in the 3rd floor, and remember waiting up there to see how they get the new washing machines up there.
I was waiting for a while with a colleague, when suddenly a technician came in, carrying a little box under his arm. He put the box on the old washing machine, reconnected some cables and left... Leaving me a my friend open-mouthed.
If it's got VMS loaded, cracking the root password is no sweat at all. Ya do a converstional boot (this is done differently on different MicroVaxen, usually b/1 or b/r5:1 on themore common ones at the >>> power on prompt). Then, when you get the prompt, SET /STARTUP OPA0:, and SET WRITESYSPARAMS 0,
and then CONTINUE. VMS will boot with the console as the startup file. At the $ prompt, type SPAWN, then at the next prompt, @SYS$SYSTEM:STARTUP. The system will be fully up and you will be logged in as SYSTEM, full privs.
Ya then gotta run sys$system:authorize, and create yerself an account.
This is in the VMS FAQ, so I'm not giving away any secrets here..
If it's running some UNIX variant, I got no idea...
There is no God, and Dirac is his prophet.
VMS was a great operating system (except for I/O throughput). Anyone that was an engineer at DEC would say so. It was COMMON for those systems to stay up for years without a reboot (software upgrades did nto need rebooting), and it had a lot to do with the design of the software and the developers rather than the hardware. The OS had proper protections of resources and privileges, software was released with the constant concern of migration or backward compatibility, and languages all had a common call API -- making it easy to link objects compiled in different languages. Commands were user-friendly, and the GUI (if you wanted it) was X (Motif at that time). Remember that you could also not just control user privs, but about 32 other items such as disk quota, how much memory they could consume, the maximum CPU time before being forced to swap, etc. From a business perspective, a multi-user, time-sharing, reliable, networking (supported TCP/IP, LAT, DECnet, SNA, ...), and popular (DEC was #2 in the world) system was a good choice. The enemy was the mainframe -- a non-dristributed, expensive investment. It's sad developers that did not grow up in this environment will not be able to see it as anything but old technology.
- at -DEC
BTW -- yes, Y2k had little to no impact on VMS. It was designed to be date "correct" from the beginning. Extremely few Y2k patches for VMS appeared, and they were mostly for applications rather than the OS.
What killed VMS was being tied to the expensive hardware it ran on. When support for a sytem costs you 5-6 figures a year compared to buying a Linux/NT server for $1-$5k brand new, plus the VAX hardware was not compatible with other systems (except for the Alpha perhaps), you had to question it's value in your server room. Don't forget the large power consuption of the older systems as well.
If DEC had been allowed to release VMS for Intel as a product (which DID exist as a prototype within DEC), it might still be a viable choice today. I understood this did not happen due to the agreement between Microsoft and DEC when they partnered to port applications to NT and cross-train personnel for PC support -- a smart move on Microsoft's part, as it would certainly have prevented NT from catching on.
Even now Linux and Microsoft strive to achieve the same level of clustering integration VMS enjoyed almost transparently. Unix/Linux is much more flexible and efficient and cost-effective, but this comes at a trade-off of being more technical to use and with less administrative control. Eventually the "lack of applications" problem will fade away.
Hopefully Linux adoption can return us to those "no Microsoft products in use here" days.
Keith-who-was-a-VMS-product-developer-and-admin
---
Keith Barrett (kgb)
Wrong. Rolling upgrades. Don't need to take down the entire cluster to do an upgrade, and that is the uptime stat.
Never answer an anonymous letter. - Yogi Berra
Ha, this brings me back. My first post-graduation job was for a VAX/VMS to Solaris migration. This ancient VAX had spent years processing satellite telemetry data for the U.S. government. I learned a lot about how to migrate old data into a new data structure and just generally how to get an old system to talk to a newer one. The VAX did a great job at storing and processing data but they wanted to upgrade that part of the process so that it would be compatible with some of the newer UNIX software they had built. Of course, since this was government work, the project was scrapped after several years of paying very expensive salaries in favor of supporting the VAX/VMS based system. It would not surprise me in the least to learn that they are still using the old VAX for the exact same purpose today.
Regular Meta Moderators are not more likely to get mod points.
At least internally:
I have a screenie of VMS booting into an Itanium based cluster from May 30th, 2003.
Cant post it, because the "*"'s from the display trigger lameness filter...
Ironic.
Regression testing is not done yet, so it is only in hands of developers, and some customers for testing, like us.
There is a rumour that they have an AMD port as well...
Never answer an anonymous letter. - Yogi Berra
Careful with that VAX, Eugene!
There was originally a water cooled version, but by using heatsinks that look like a bed of nails, and ducting the cooling air from a blower in the bottom of the unit to impinge individually on each heatsink ( the ducting is removed in the pic ) it was possible to ditch all the water cooling hardware.
These systems were meant for raised floor installations where chilled air was blown up thru missing floor panels, right into the fan intake.
And that is not a real service guy... he does not have a static strap!
It's kind of strange that the article makes no mention of HP Remarketing, which still provides parts and support.
I remember working at a university back in 99, when they decommisioned 2 VAX's. These VAX's were purchased in 86 and was giving an uptime around 13 years, no shutdowns, no reboots, no problems. To thing they replaced them with 6 NT 4 systems. The first week they were up, they had to be reboot multiply times and they became infected with a trojen horse. unfortionalty this first week became a normal week! I guess the university should remember the old statement: "If it's not broke don't fix it!"
A site cowboyneal will like http://www.freewebs.com/atpa/
The problem was that in order to crash a VAX, it had to be intentional. Kinda like you were saying.
With the help of a couple of buddies of mine during our CS assembly class, we poured through the documentation and wrote a memory worm, I.E. from straight out of Core Wars, we wrote "IMP" but for VAX-11 assembly. This is where you have the program make a copy of itself and transfer machine operation to the new copy you just made. This ends up filling all of RAM with a copy of itself, unless you have memory protections in place.
Then to make life a little bit more interesting, after running it under normal user mode with boring results like memory access errors, and running it under the VMS debugger utility to make sure it was doing what we wanted it to do, we fiddled with the processor status bits, including the "reserved" bits, changing the software to kernel mode and a couple of other "undocumented" features. We could run it without any software protection at that point. "Accidentily" we pressed the "Run" command in the debugger, then the system went down almost immediately... or at least nobody could get anything else to work.
Immediately we ran to the sysadmin and told the story to him. He thought we were off our rocker, and didn't believe us that we could shut down the system. After about a 1/2 hour, he decided to do a cold reboot of the VAX, after pulling out the manual for trying to figure out just how to do that. It still wouldn't reboot at that point. Finally, he had to re-install the OS from tape and rebuild the hard-drives from scratch, as if it were a fresh out-of-the-box computer (actually, worse than that). Because he was a pretty clueful sysadmin, he got everybody back up and going in about 2 days (regular tape backups of just about everything). This "club" of ours (we did register with college as a formal club... beer napkin, as the club charter, and all) still claimed "credit" for the mishap, but DEC said we were full of it and couldn't have done it. Since the computer was still under warentee at the time with essentially an unlimited service contract from DEC, it really didn't cost the school anything to deal with the issue, other than the downtime of the computer.
Yeah, we had fun with the VAX. I also loved the games of Pong and Breakout we made with the VT100 terminals (These are ASCII-only terminals). Weird glitches that would form every now and again because of time slices to other users, but otherwise pretty fun games. Not to mention Empire tournaments.
Why would anyone want to migrate to the Inanium at this late date? Now that Intel finally caved and cloned AMD's 64-bit machines, the Itanium is clearly on the way out. That's not where you want to be three years from now. The Itanium is headed for the Intel scrap heap of wierd processors, along with the i860, the i960, and the iapx432. All of which were architecturally better than x86.
The "VAX Users See the Writing on the Wall" article brings up some interesting issues. However, it could have dug a bit deeper. The title, all by itself, deserves some comment. Most VAX "users" probably don't even know they are using a VAX. Many of them are likely using character-cell based applications that get the job done day in and day out. It is the whining of the VAX owners and application managers to which the article really dedicates itself.
Speaking of dedication, who can feel sorry for VAX owners who have let the whirlwind of the last decade keep them from paying attention to the critical systems and applications that keep their business going? The applications must be critical since someone noticed when the system finally crashed. The applications must be substantial since they have not already been replaced by some GUI/BlahScript solution whipped out in a couple weeks.
Come to think of it, past efforts have probably been attempted to replace the VAX based applications but have failed for any number of reasons. I am sure you know of at least one multi-million YourCurrency development effort that was slated to replace some legacy application that either failed to deliver or was cut before it could be implemented. For the applications that actually do get replaced, if they have just been simply replaced by some point-n-click poorly designed GUI, they seldomly seem "more efficient" than the past application.
The real issue goes much deeper than just one model of computer, like the VAX. For any organization, there might be some critical function busy spinning on some tough solid box sitting softly in some unseen corner or closet. It might be a VAX, but could also be an HP3000 or a 3B2 or maybe even a 486 clone. In a decade or less, it will be one of the sexy new systems we wish we could afford today.
United States
I had the experience of working on a Digital Vax 11/750 back "in the day" at an organization of about 200 staff.
It was huge. It was the size of several washing machines side by side, it its own room, with its own separate air conditioner.
It had 4 MB *yes, MB* of RAM, and served data to about 50 workstations. (Green on black, Wyze terminals, as I recall)
This sucker had a GB of Disk Space. It's RAM was accessible via these dinner-plate sized memory 'cards' that slid into the monster case.
You could swap RAM without powering down the system. You ran a command to remap everything out of that card, and when the command was done, you pulled the card out.
It would identify bad RAM on the fly and then map around those bad spots, while writing to a log file for the sysadmin. It wouldn't skip a beat when this happened, either.
The Digital VAX was a true machine - one that, despite its refridgerator size and ~ X86 286 clas processing power, was to the 386 computers common at the time that I was there much like a VW Microbus is to an 18-wheeler Semi.
The Air Conditioner failed, one time. Eventually, the computer room got too hot and the system crashed. But, when it did so, it remapped all the memory to disk.
When we brought the disk back up, (after getting the A/C fixed by an HVAC) all the processes running at the time of crash came back up! We had to manually kill them!
I heard about the story of its delivery. It was actually fell out of the back of the truck on the open highway at about 60 MPH. The agent took it back to the shop, put a new panel on the side, threw it back on the truck, (raising the tailgate this time) and delivered it about 2 hours late. It ran fine when they hooked it up!
It's simply a degree of engineering lost to today's Windows and *nix raised lusers.
I will always respect that VAX. It was a machine for and from a different era of computing.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
CHAOS, INSANITY, DESPERATION and GATEWAY.
Maybe your gateway should be called WINDOWS. Given what it leads to and all.
... for fun and profit.
I remember once back in the late 80s when my then employer took part in a local computer show. We used a brand new MicroVAX II (in the Q3 enclosure with wheels) to demo our 'ware on. Myself and an another tech brought the machine to the show, so we made a deal with some cow-orkers in the sales dept. that they would bring it back. Big mistake.
Naturally, my tech friend and I carefully loaded the VAX into a station wagon and drove it to the venue, even though it really wasn't far, all the while going carefully over bumps in the road etc.
The next day, as we were heading out to lunch, we saw (and heard!) a strange spectacle coming up our street. There came the two sales droids happily pushing the VAX ("but it's got wheels so what's the problem!?") over the rough asphalt, over cobblestones and... you get the picture. They were going fast too, the thing was shaking and vibrating so bad we heard it more than saw it.
Did the thing work after this? Yup, it booted right up without a hickup.
A friend of mine once dropped a MicroVAX I (he was carrying it down some stairs). The cabinet looked like a train wreck, but after some industrial adjustment with a hammer and some crazy glue for the plastic bits it worked just fine. The QBUS cards were all fine as they came flying out of the enclosure upon impact.
Oh yeah, and then there was the time at an earlier employer when one of the networking guys accidentaly laid a VAX 11/785 (with UNIBUS cabinet) on its side. He was adding some cable or whatever and removed all the floor tiles (not every second one as he should have) from immediately behind the VAX. This meant the VAX was only resting on some relatively thin metal rods which suddenly didn't have any sideways support anymore so they started giving... you could see the VAX moving slowly backwards and then suddenly crashing into the next VAX (an 8600) behind it.
Here's the thing: Both VAXen kept running.
I once decomissioned a MicroVAX II (Q5) that had an uptime of over 4 years. It had been used heavily almost 24/7 (for compiling) until it was replaced by a 3600. No cluster, no redundant hw, just a lone machine built from the best components the computer industry has ever seen.
You know what they used to say about DEC Engineering? That their motto was: "When in doubt, use the biggest capacitor available". Or what they used to say about DEC Sales? That if you tried to call a DEC salesdriod they would immediately demand: "How did you get this number?!?"
For a top notch engineering company they sure as hell didn't market their stuff very well. Ah well, Sic Transit Gloria Mundi.
G
Actually, I am not quite sure about the timeline here. The Rainbow was quite unique in that it had two CPU's: a Z80 and an Intel 8088. At boot time, you could either enter VT220 mode (using it as a plain terminal) or boot the operating system, CP/M-80/86, a very interesting system, which allowed you to use either Z80 (or 8080) programs or 8086 programs. I believe they called this "soft-sense technology" (it was also patented?), but in reality I guess they simply decided by name whether a program was one or the other, loaded the code into the user area (at 0100h?), then switched the CPU as appropriate before jumping to the program. CP/M-80 programs were suffixed .COM, whereas CP/M-86 programs were suffixed .CMD.
It was only later, when the IBM PC had won, that MS-DOS was ported to the Rainbow.
I remember how I attended a computer fair (MikroData) in Copenhagen in the years 1984 and 1985. In 1984 booths showing secondary equipment (computer tables, printers and other devices, etc) had typically obtained (loaned? rented?) a Rainbow to show. Next year, all machines used for display were IBM PCs.
(Oh, and in 1984 I typed my first "ls" on a Z8000 Cromemco machine, possibly running CROMIX? In 1985 I think they had a huge inflated "Macintosh" at the Apple booth. Also the LISA's from the year before were gone, I think.)
-Lasse
I'm ashamed to realize that I forgot my DEC employee number. :-(
;)
I went to work for DEC as a computer operator in late '89 at the Cupertino, CA. chip plant where they manufacturered the M-sets for the VAX9000. To the guy who mentioned that "they used to be water cooled". Part of the engineering challenge was an air cooled mainframe from the drawing board. Air cooled mainframes of that class was the goal.
DECnet being the VMS system data-bus for peripheral devices, virtually any peripheral device, was for me, the "neato" factor. Washing machine sized "hubs", washing machine sized tape drives and refrigerator sized disk cabinet as far as the eye could see.
I remember using a MicroVAX to "join" a DECnet node cluster so that I could look at certain privileged files on one of bigger nodes. The results? It worked. The outcome? I would have gotten away with it if I had cleanly removed the MicroVAX from the cluster. About a dozen complaints later, the System Managers came looking for the MicroVAX causing a bottleneck. I was able to keep the MicroVAX by letting them know how I did it. Fortunate for me, it wasn't anything more complicated than the fact that DECnet would simply let *any* node join a cluster.
The Alpha was DEC's savior but they insisted on marketing it as a Windows server platform. Olsen never saw the decline of the mainframe market coming and the DEC marketing geeks were too mainframe market oriented (read that as "high margin revenue, long term contract") and rubbed elbows too closely with government types. This developed a "build it and they will buy it" mindset. Change was sluggish at DEC and that is being kind.
Mod me troll, if you must, I can't help it.