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!
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"?
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?
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?"
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!
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.
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/...
"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...
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.
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.