Slashdot Mirror
First OpenVMS Boot On IA64
vaxzilla writes "At 3:31pm EST on Friday, January 31st, 2003,
OpenVMS for the Intel IA64
architecture
successfully booted and ran a DIR command.
The Intel Itanium family of processors is the third architecture supported
by OpenVMS in its
25 year
history. Originally it ran on Digital Equipment Corporation VAX
systems; in the early 1990s, support was added for the DEC Alpha
processors. Following the acquisition of DEC by Compaq, and more recently
Compaq by HP, the Itanium and Itanium2 port of OpenVMS is now being
undertaken by HP. Congratulations on a job well done to the folks at
ZK03 in Nashua, NH!"
An itanium based platform can produce a listing of files!!!!
This is truly a breakthrough. Intel is waay ahead in computing than companies like Nike or Coca Cola.
Well...considering the heat which Intel processors tend to generate...you could probably just lay your bread in your case...and next thing you know...
TOAST!
Notice they don't actually show you the directory listing in question?
Because it was PR0N.
I know it's present in some legacy systems, and supported by Compaq for that reason. But why would we want VMS on new hardware? What new stuff runs on VMS these days?
--
There is no hatred more pure and true than that expressed by children.
I used OpenVMS a bit at my universty, and I have to say I never really got into it - getting my solaris account was a great day! I can understand people wanting to maintain legacy apps (big purchasing systems maybe?) but is OpenVMS really good for anything _new_ today? Does it have any real particular advantages that mean you would want to use it for reasons other that "we've already got a stack of Alphas this high on it and gonna keep using it until forever"?
Not to mention bacon, eggs, and hashbrowns. (Ooh, I have a Perl hashing function that a friend designed which would make EXCELLENT hashbrowns)
4GB is still a lot by any standard, but the problem is that the kernel, for example, needs to have some of its structures appear in the process's address space. Shared libraries also need to be in each process's address space, even if it's in memory only once. Even better, you need to leave room for the heap to grow as well as for user-loaded entities (like dlopen()'ed shared objects). In practice, I understand the default restriction for Linux is somewhere in the neighborhood of 1.5GB per process, though you can increase that to 3GB with some libc tweaks. There are a few kernel patches to raise that limit further to 3.5GB, but that's the absolute ceiling (and you are sacrificing what may be important things, like SysV shared memory segments).
Even now, it's not uncommon to see gaming machines with 1GB RAM or more. Even small servers will often have 4GB RAM. In a few years, the number of "high-memory" systems is only going to increase as advances in technology continue to drive down the cost of RAM and drive up the requirements of software. This is especially the case as databases become more important and commonplace in the business world. Everyone uses them now, but we can expect to see them used more often, and in more diverse places, than in the past.
There is also a hope among many of us that Intel and AMD will use this opportunity to create good chips, not just cheap ones. They have the opportunity to fix a lot of the stupid design decisions Intel made 20 years ago and put together a modern, clean system. Unfortunately, it doesn't look like this is going to happen (I don't think anyone at AMD has had an original idea in their entire lives, and Itanium is being designed by committee), but this is the hope. In short, we may not see any immediate performance gains, but in the long term, the design of the chips would enable faster improvements than we're getting with IA32s right now.
Would it help with graphics applications?
No, graphics would use vector operations, which use 64-bit vectors but are not called "64-bit" operations. A "64-bit" operation is typically defined as one that uses a 64-bit number or a 64-bit pointer, not a vector of four 16-bit numbers. Current 32-bit processors are perfectly capable of performing operations on vectors of 16-bit numbers through such instruction set extensions as 3DNow! and AltiVec.
Will I retire or break 10K?
Commodore One successfully executes LOAD FROGGER,8,1!
Bah, this has already been done by some British guy... :D
THIS CHANGES EVERYTHING!!!
No, wait... what the hell does this matter? We're shutting the few remaining vaxes at work off soon...isn't everyone?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Specifically, open in the sense that it complies to POSIX standards.
I grew up on VAX/VMS at school after a highschool exposure to (and part-time job thru the college years using) PDP-11s.
Compared to the various dialects of unix, the VMS environment was so much friendlier and forgiving... I'm only now realizing how much my hands were in mittens using it. I'd still prefer a system that wasn't so case-sensitive.
The chief engineers behind VMS then went to work at Micro$oft to develop NT, so some of the legacy is still there: expensive process starts, but a nice memory model to work with.
Strengths:
Linkers in the early 80s that were easy to cross languages in a single project
A powerful set of run-time libraries, including some excellent flatfile databases
A scripting language that had access to a nice library of "lexical" functions.
But like I said, I wish I still cared. While we still have Alphas around running openVMS at the office, I haven't logged onto one for about three years. Somewhere, I have a huge library of shell routines, login scripts, and ancient forms-oriented code.
Design for Use, not Construction!
Your first iteration was amazing. Your second version was equally amazing. AMD's own successes with the K7 architecture are owed mostly to you. Your latest golden baby was thrown in the garbage because it scared the other babies. Even though no one wants to know, your EV7 is *STILL* the premiere big iron architecture in this day and age. What would have been your crowning jewel was aborted and your womb replaced by something Intel Inside. EV8, you would've been an engineering and design marvel, something that would've taken YEARS to beat. And now, poor DEC Alpha team, where are you? Fragments of your EV7/6 team are higher-ups at AMD, giving the desktop underdog a chance, and the rest of you is at work at Intel/HP, genetically engineering something something truly EPIC, that sadly, only even a mother could love...assuming the mother eventually gives birth to acceptably talented offspring. Oh, whither art thou, Alpha?
------- "From bored to fanboy in 3.8 asian girls" ----------
I must disagree with you.
64 bit does not mean a thing.
It means something important to anybody who ever has to receive a CAT scan or a nMRI scan... VMS/VAX systems run nMRI and CAT scanners... They use 64 bit architecture during Fourier analysis...
99.99999999999999% of software today does NOT run on it
probably because 99% of software today is used for text and graphics processing; not for mission critical apps. that's kind of like saying that 99% of all driving accidents happen within 25 miles of home... well, geeze, 99% of all driving period occurs within 25 miles of home...
performance difference in mhz between 32 bit and 64 bit processors (especially in the north bridge) makes any performance gained by using 64 bit architecture negligible
I disagree with you. The difference between being able to handle 2^32 and 2^64 is worlds apart in performance. I suggest that you compare 16 bit computers, which didn't support true-color, full motion multimedia, and compare to 32 bit computers. They both support text editing; however, one supports WYSIWYG better than the other...
FYI, my day job involves running MRI scans on a VMS/VAX Gyroscan Intera workstation... This 64 bit architecture is the hottest stuff around, for somebody who works with a VMS/VAX workstation... here's why: MRI scanners work just like any other printer/scanner device, in terms of device drivers, and general operation. The difficulty is, because MRI looks at differential angular momentum of hydrogen atoms to obtain it's pictures, it's got to calculate a Fourier wave analysis on each atom it vibrates. Being able to run an algorithm with 64 bits means less data manipulation, higher resolution, faster scan times, and increased diagnostic imaging power to the medical doctors.
Anyhow, for those interested, there currently seems to be a big migration from VMS/VAX/Alpha solutions to Windows/Intel compatibility (for obvious reasons). Philips has introduced an InteraNT product into their Intera Gyroscan line, which runs the MRI scanner on a Windows NT platform, instead of the traditional VMS/VAX platform which they've been using for some time...
As usual, great tool for the server companies, crap for everyone else in the world.
This is slashdot... they cover stuff which is great for server companies, hospital radiology departments, nuclear power facilities, astronautical engineering groups, etc. etc. That's why we love it...
Innovations didn't save DEC from its stupid managment.
Well, it sux but it's not going to kill them any time soon. I wish it would kill them but USA is about Intel and MS and other mediocraties.
HP wants to be in bed with Intel. HP needs to keep OpenVMS only alive enough to avoid jilting its inherited customer base. The same is true with porting HP-UX to the Itanic. Linux on the Itanic is HP's real server "solution". They are getting into Linux clustering in a major way.
The Digital marketeers changed the name from VMS to OpenVMS when the OS got its POSIX branding. The funny thing is that VMS got it before most UNIX systems did.
In those days, there was a lot of fuzz among customers about the need to buy "open" systems and not "proprietary" ones, (meaning that VMS was proprietary and Solaris or HP-UX were open). That's why Digital felt POSIX branding was a good thing.
Then the customers bought lots of M$ Windows stuff instead; so much for wanting "open" systems!
Another fact: VMS came with source code from the start! On microfiche. Not so that you could recompile the OS, but rather learn about it, check bugs, etc.
)9TSS
automatic file versioning!
if you have foo.txt and you save another foo.txt in the same directory, you get foo.txt;2 !
damn, i wish Windows had that.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
Yes you're correct with IA32 you're limited to 4GB per process. I wouldn't call it a "kludge"; basically you have 36 bits to specify a physical address in each PTE, but are still limited to 32 bit linear addressing. This means you can have 2^36 bytes of RAM, and processes can be spread out throughout that whole address space. I'd only consider it to be a kludge if there were "windows" or "partitions" and you could access 4GB of consecutive at once.
Note that this is completely transparent to the process. The OS is responsible for setting up paging. Note also that on a server you typically run a whole lot of processes anyways (e.g. a whole bunch of web server processes) so for most server applications I don't see it as a major limitation (big databases may be one problem)
Note also that theoretically that you could have system where the process could access more than 4GB of linear address space, if you set aside some region of linear address space for this purpose, and had a system call to update where this was going to. This is an ugly, ugly kludge, requires OS modification, and reminds of DOS style memory management but could be done (and would probably be cheaper than moving off of X86...)
Well, I just happened to have these links lying around, as I work on VMS/VAX systems at work (Gyroscan Intera system). These links are sort of the OpenVMS equivalent of gnu.org, gnome.org, redhat.com, and so forth...
n vms_roadmaps.htm
Core OpenVMS
http://www.openvms.compaq.com/
OpenVMS Future Release Contents, Schedules
http://www.openvms.compaq.com/openvms/roadmap/ope
OpenVMS and Core Layered Product Documentation
http://www.openvms.compaq.com/doc/
http://www.openvms.compaq.com:8000/
http://www.openvms.compaq.com/commercial/
Core OpenVMS Support Search Engine URLs, FTP Patch Area http://askq.compaq.com/
http://ftp.digital.com.au/pub/ecoinfo/
ftp://ftp.service.digital.com/public/vms/vax/...
ftp://ftp.service.digital.com/public/vms/axp/...
The OpenVMS Freeware
http://www.openvms.compaq.com/freeware/
Encompas
http://www.encompassus.org/
Tech Help OpenVMS
http://askq.compaq.com/
http://www.openvms.compaq.com/wizard/
ftp://ftp.service.digital.com/public/vms/vax/...
Too late they realized that they had forgotten to implement a shutdown command or even a copy command and the filesystem was corrupted when they turned the power off
Hello!??! This is VMS we are talking about. The filesystem is not corrupted on power failure.
)9TSS
> Well...considering the heat which Intel processors tend to generate...
Funny? Perhaps it was missed sarcasm on my part. While we're at it, maybe we could also use an Athlon processor to keep our beer cold while we watch forthcoming "Itanium 2 powers your eBusiness" commercials?
You must have C3 or Motorola on your desktop. Tell me this: Does your processor underclock itself when it detects it's overheating due to a failed CPU fan?
"If only my toaster was powered by Itanium!"
What, your Athlon processor has disappointed you?
From the perspective of a user in a mis-managed VMS environment, I can understand your sentiment, but it was your sysadmins who were at fault, not VMS.
The fact that VMS HAS options which allow extremely fine-grained selection of user privs is a positive thing about the OS. VMS also had all kinds of login security years (break-in detection and evasion) before other systems, and was designated "trusted" quite early on.
VMS could be mismanaged so that it would crash, if ALL logging options were enabled. But that doesn't make it bad for it to have had so many different logging options.
Diskquotas weren't even enabled by default when I was using VMS. You *could* enable them (and obviously your silly sysadmins both enabled them and put very low limits on you), but you never had to.
VMS is a very flexible tool, and tools can be made to do lots of things, some good, some bad.
By the way, even now there aren't that many systems with the availability and redundancy VMS clusters had in 1985 (automatic failover from one machine to another, separate shared disk controllers, etc. etc.).
Finally VAX/VMS virtual memory worked better than any other such system I've seen. You could actually let things page and they didn't slow down much, since the paging was so intelligent.
*sigh* anyway, that was all a long time ago. I haven't used VMS professionally since 1992 or so...
Regarding your claim that VMS is optimized for Fourier wave analysis, I can't believe that this is unique today. The main impetus behind VAX BSD was ARPA's desire to have a Unix system that would handle the memory demands of computer graphics. We made use of various Unix systems at Pixar and Pixar's predecessors, where there were similar sorts of problems (texture rendering rather than FFT) and Linux is now the darling of those places.
This is a VM and cache issue, not really rocket science these days.
Thanks
Bruce
Bruce Perens.
One of the questions that comes up all the time is: How enthusiastic is our support for UNIX? Unix was written on our machines and for our machines many years ago. Today, much of UNIX being done is done on our machines. Ten percent of our VAXs are going for UNIX use. UNIX is a simple language, easy to understand, easy to get started with. It's great for students, great for somewhat casual users, and it's great for interchanging programs between different machines. And so, because of its popularity in these markets, we support it. We have good UNIX on VAX and good UNIX on PDP-11s. It is our belief, however, that serious professional users will run out of things they can do with UNIX. They'll want a real system and will end up doing VMS when they get to be serious about programming. With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there. That's the difference - - the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there.
Ken Olsen, Chmn&CEO, DEC, 1984
Which just reinforces the parent rant. On a PC, that 100MB would cost ten cents. Maybe instead of rationing disk space, the sysadmins could save more money for the company by scavenging abandoned half-full cups of coffee in the break room and pouring them back into the coffee pots.
Certainly didn't dissapoint me, toasting my bread with an Athlon...
I've seen an Athlon physically melt the solder connections of a motherboard (mine, sadly). Something must've caused the fan to seize momentarily -- then the building I was in had a fire drill -- nothing wrong at all, just a test of the system... I was away about 5 minutes. Walk back to my computer, and notice the odd smell. Turn off the power immediately; open the case... The heat from the Athlon had melted the CPU fan into the CPU heatsink. The (copper) heatsink was quite discolored due to heat. I made the mistake of brushing my hand against the heatsink after I powered the thing off... (but before noticing that it was the melted fan that smelled so awful). It took weeks for the burn to heal; the act of pulling my hand away jarred the case slightly, and a couple of the toroidal cores slid out of their holes (the solder had melted) And, what's more: There were all these surface-mount components oozing downward (with gravity).
Absolutely no overclocking or tweaking was involved.
The thing I couldn't help but think was how close the fire 'drill' had come to being an actual fire... At least everyone was out of the building... All thanks to the nice, cool-running nature of the AMD Athlon.
Interesting note: The AMD Athlon pulls ~75 W of power. The average soldering iron pulls 15-30W. Pentiums aren't much better than the Athlon... Is it any wonder that many people are using these tornado cases, or liquid cooling? That's a lot of heat to be dissipating!
Interesting note II: I replaced that first Athlon with a second one.
Interesting note III: The second Athlon died (not by heat, however) under a year later.
Interesting note IV: I have yet another Athlon, which is getting close to the 6-month mark... Here's hoping it makes it to a full year!!!
Interesting note V: My next computer is going to be a Mac.
-- Sometimes you have to turn the lights off in order to see.
I uses/run a public OpenVMS cluster. There are still somethings that the Unix community could learn from OpenVMS. Cluster, and the security model come to mind. The stablity cannot be beat. It's good stuff. And, yes.. You can run OpenVMS on your little Intel boxes.. Check out.. http://simh.trailing-edge.com/ .. Cool stuff.
Run's great. If you're really interested in OpenVMS, there's a couple of "free access" servers out there. For example:
http://deathrow.vistech.net .... One uVAX, and
Alpha online for public use. We're about to add a SIMH (Intel) box running OpenVMS into the cluster as well.
And you could buy a source license for the OS as well so you could modify the OS if you had sufficient skill.
Much of VMS was written in BLISS-32 whose back-end produced fantastic code - sure it was code no human being would have written - but damn good code just the same.
Being able to pull out the microfiche and check out the BLISS source was often useful when learning to program deep into the OS.
Not to mention the DECUS meetings where you could talk to the developers. I can remember the meeting in LA when at a small session DEC and the guys from MIT revealed the 782 - assymmetric multi-processing. It was exciting stuff. DEC had some really good engineers.
Remember - the VAX was about the ultimate CISC processor. Memory was scarce in those days - having 64MB of RAM was a big deal! The processor was very efficient in the use of memory.
> > And if he was speaking about 15 years ago, 2 MB might have been a very generous disk quota. I know of UNIX shops where you feel lucky to get 100MB even today.
> Which just reinforces the parent rant. On a PC, that 100MB would cost ten cents.
Actually, there was a study about a decade ago that showed that the average PC cost a company $15,000-$20,000 per year to own and operate: $5,000 for the official costs and another $10,000-$15,000 for the run-down-the-hall-and-bother-an-expert cost.
Some companies might reasonably conclude that it's a better bargain to give you less disk space on a server. Especially if your work doesn't require a lot of space in your personal directory.
Sheesh, evil *and* a jerk. -- Jade
The level of security in VMS is what keeps it in circulation. I work for a major european bank and we use VMS for all of the major banking systems (except websites - they use Oracle and ftp their files to VAX - which is just about the only regular problem we have to deal with).
The fact that we can lock the system down as much as we do is why it hasn't been replaced by more "fashonable" OS's
"My parents were strict, but they never pitted me against livestock" - Doug Stanhope
Announcement on GNAT for ia64/OpenVMS on 14Mar2002
This is great and it's the right thing to do!
Laurent