Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
The Internet

Revitalizing the Internet and VMS 267

Posted by CowboyNeal from the taste-it-again-for-the-first-time dept.
Da Beave writes "Similar to the "Going Back to the Past of the Internet" /. post, these guys want to not only revitalize the Internet, but the OpenVMS Operating System (Started by Digital, then to Compaq, now to HP....). They have a cluster of VAXen (32 bit) and Alphas (64 bit) for public (non-commercial) usage.... With more compilers than you can shake a stick at, and it's considered one of the most secure OS's around....." VMS was one of the first operating systems I learned to use. This page really brings back some memories, both good and bad.
This discussion has been archived. No new comments can be posted.

Revitalizing the Internet and VMS More

Revitalizing the Internet and VMS

Comments Filter:
  • And the trolls say BSD i dieing.

    • Re:VMS? (Score:3, Funny)

      by evilviper ( 135110 )
      At least the trolls can spell "is dying" correctly.

      • I could never get over the command completion in VMS... get the first three chars of the command correct, and it would usually run. Sometimes I'd swear I only got the first three letters of my password correct, and it would let me in.


        Then there was the campus gripe about the "longest email addresses on the internet": @sitvax.stevens-tech.edu. My gripe is I started too late to get a bang path address...

  • cool! (Score:1)

    by Sk3lt ( 464645 )
    I say we give them all the support they need! If it was stable back then, then revitalizing it can't do any harm can it?
    • that's a bad idea. VMS DCL commnds are much more cryptic than standard unix (or linux) commands. A revitalized [Opsn]VMS could siphon away 3l1te linux users!
      • Yah, they're really cryptic and difficult; about as tricky as MS-DOS. "dir" to see your files, "type" to list a file, "copy" to copy a file, etc. Real obscure syntax since everyone got bit with point-and-click disease!

  • You can only use it if you aren't planning on using it in a business setting.

    The DeathRow OpenVMS Cluster operates under the hobbyist program. If you intend to use these reasources for commerical reasons (for example: porting commercial code, or running a company web page), you will be removed. This would violate our hobbyist agreement/license, and we can't afford to let that happen.

    So, it's useless as a replacement for anything.
    • OpenVMS was named in a time when "open" meant that your OS supported open standard APIs. That would mean ANSI and ISO standards for languages, POSIX APIs, etc. While the core services (file management, process scheduling, etc.) were nothing like Unix, they were equally powerful and had some extra concepts that were rather useful at times.

      While it was quite easy to port well-written code between OpenVMS and Unix systems, OpenVMS just didn't maintain the market share to survive. The world focused on *nix vs. Windows, with a stable core of corporate mainframes, and a few specialist markets (Apple in media content, SGI in CGI editing.) Much like OS/2, it was a victim of poor marketting that didn't show the computing public what the real benefits of their advanced features were.

      While I wouldn't mind seeing OpenVMS on a client site, I really don't expect it will ever happen. Business does not buy orphans, and they're the only market that needs the benefits of OpenVMS features. *nix systems already have add-on packages and projects to address those needs in other ways.

  • Does this mean that all those l33t hax0r txtz I got nocking arround and make out like it runs every computer system on the net can be put to some purpose?
    • When they were written, it did. That's the point of the story at hand. Most of your hacker texts were written in the early to mid 80s.

  • Stupid Contracts (Score:3, Interesting)

    by Zack ( 44 ) on Saturday August 31, 2002 @11:39AM (#4176380) Journal
    I had a job offer from Compaq to work on the OpenVMS kernel. Sounded like a good deal. I got a chance to fly to Nashua, New Hamshire to check out the facilities and meet the people I would potentially be working with. Let me tell you, these guys were incredibly smart.

    Then I got the contract. It had a clause stating that any idea I ever had as well as any ideas I had while I worked for them belonged to them. As well as a non-compete clause. They wouldn't budge on it, so I turned down their offer.

    Oh well. I really would have liked a chance to work on their OS, but they weren't interested. Really too bad.
    • kinda funny that a bunch of "incredibly smart" guys accepted the job, and you didn't.

      • Re:Stupid Contracts (Score:2, Insightful)

        by Querty ( 1128 )
        "Incredibly smart" guys at kernel hacking tend to be incredibly stupid/naive when it comes to things like contracts.

      • Re:Stupid Contracts (Score:3, Interesting)

        by rodgerd ( 402 )
        Most of the incredible smart guys had probably been there since the days of DEC and didn't have crap like that in their contracts.

        It's an interesting social phenomenon in many companies - first and second class employees. The first class ones are the older staff, with older contracts that don't rape them of anything they've ever thought of, have decent redundancy provisions, and so on. The newer employees get the second class contract which make it clear they should consider themselves lucky they aren't ebing used for organ harvesting.
    • Look at it this way: if they'd had a clause like that in their contracts years ago, DEC would have gained ownership of Windows NT. They're probably still kicking themselves over that one at whatever hamburger joint the DEC management of the time is now wielding a spatula...
  • ..also, I would like to ask everyone to think what would they like to be added/enhanced to/in OpenVMS, and publish these requests at openchallenge [openchallenge.org].
  • Whoohoo! Now I can write all them cool apps in VMS Basic like fake logon progs to steal passwords, and leave 'em running on WYSE terminals! Muhahahahah!

    Oops, sorry, it's not 1988 anymore, is it ?

    graspee

    • I was able to break from the login shell by hitting ^something, prob. ^C, a bunch of times.

      It gave me a prompt, which I assume was like a root or single-user-mode prompt. Too bad I didn't know many VMS directives.

      The thing's error message is longer than the DOS one in winshit2k.

      I still think the project should go on, but my time will be spend on more pressing matters. UNIX one the OS war by being superior. It didn't do it by blackmailing other companies to include it(M$). It didn't stay alive by forcing it on users of its hardware(Apple, Sun). Linux survived because anyone could get a hold of it. BSD kept up with the best of them, and would still be going strong if Linux didn't have a cooler name.
      • VMS was/is the most secure operating system ever written. I know, I tried to hack one that I bought at a hamfest. I tried everything. Every hacker text file from the 80's I consulted said "forget it". The ONLY way to hack a VMS system is to social engineer a password or use a dictionary cracker for weak passwords. There are no maint. backdoors, single user mode boot hacks, etc. and believe me, a simple ^C is not sufficent. I have two Micro-VAXen and I wound up having to reload VMS from scratch, just for want of a supervisor password. Also, the error messages were deliberatly long and informative, very helpful if you actually read and act on them (i.e. troubleshoot a problem).


        • "There are no maint. backdoors, single user mode boot hacks, etc. and believe me, a simple ^C is not sufficent. I have two Micro-VAXen and I wound up having to reload VMS from scratch, just for want of a supervisor password. "

          This is untrue. In almost all cases one can use set UAFALT (IIRC, else it is some similiar command ... I'm trying to remember back over a decade here) at boot time, and as long as the system administrator hasn't set up an alternate User Authorization File (UAF), you can get the equivalent of UNIX root as long as you have proximity.
    • Even in 88 all you have to do was to enable the secure attention logon. You then got the logon prompt with a break key and nothing could intercept that.
    • A major feature of my logon faker that I wrote in 1988 was that I logged on as myself, ran the program then went away. If the user hit the break key (whatever that was- it's been so long...) they ended up in my account with a prompt.

      Just goes to show how elite I was in 1988!

      I did steal some passwords from members of staff who logged on though, and nearly got thrown out of university for it. I was only in my 3rd week as a fresher!

      I suppose that's what happens when you meet a multi-user system for the first time when you're used to messing about on ZX-Spectrums- there is a desire to do evil!

      graspee

  • Can somebody please explain to me (or tell me to RTFM/STFW and point me to the relevant resource) what makes VMS better than *NIX? I hear a lot of 'old timers' say this, but having discovered *NIX only five years ago I have no real idea what they're talking about.
    • Just hunt around for references to VMSclusters and the Distributed Lock Manager. There are attempts at copying both but they really aren't as well implemented. SMP was also very good on VMS. The exec (kernel) of VMS was a nvery neat piece of engineering which was positively anal about parameter checking, so not a lot went wrong that way.

      The problem is that although for many years, Digital didn't give sources, but they gave away source listings. Regrettably they stopped after VMS 4.5. However the system was exceptionally well documented and it was possible to write some neat hacks (for example, I did one to fetch somebody elses command line history buffer). It was far from as open as Linux. However, many old VMS people have fallen in love with Linux because it is so accessible.

    • Re:VMS better than *NIX? (Score:4, Informative)

      by Anonymous Coward on Saturday August 31, 2002 @01:59PM (#4176954)
      Off the top of my head...

      VMS was an engineered solution, by engineers, for engineers. UNIX is a organic one, slanted towards experimentation and diversity. In Unix you have a plethora of high level tools to accomplish the same things, in VMS you had one very well though out generic one. Usually a high fidelity implementation taken directly from the core of Computer Science theory that was hard to find fault with. For example, queue management. In Unix you have a dozen print tools, batch tools, etc. each with their own unique configuration nightmare. In VMS you had Queue Manager, a single thought out queueing management tool that didn't press "printness", "batchness", "uucp polling", or whatever, into the equasion. Some of these included...

      Queue Mangement
      Distributed Lock Management
      Object Access Control and Rights Management
      Record Management Services (File structures) (RMS)

      Some question the RMS bit, myself included. Although it was one "well thought out tool" the idea of integrating file structure into the OS simple did not return on the promise. Hey, not everything can be perfect.

      At a lower level, VMS had a number of nice features too. For example, every system call that could, possibly, be interrupted had the ability to complete by calling a function by name (AST). Sorta like sigio but far more powerful since each and every call specified its own handler and parameter block. Noise like Apache's "wake once" event wakeup problem simply could NEVER have been become an issue under VMS. The design flaw that lead to the "Apache problem" didn't exist.

      VMS had some powerful per process management features, which many UNI* types don't even grok, let alone implement, yet. They were, however, complicated -- but most useful when you knew what you were doing and needed to do it. UNI* tries to "just work", but as the VM types in Linux are learning it isn't always that easy.

      Unlike UNI*, VMS has a very powerful scheduler, and it let it's owner call the shots. Unlike UNI*, you had priority and runtime quantum and VMS never confused the two. So, something was priority 0 WOULD NOT run, ever, if something at priority 1 could. Lock your resources if you want, it's was your machine. UNI* takes gargantuan steps to save people from themselves.

      Then, the VMS scheduler was IO sensitive. If you genererated a keyboard interrupt, your process was temporarally bosted a few priority points for a quick burst of responsiveness. Again, like every tool in VMS there was ONE scheduler and it offered a single, complete, and unified, end-user experience that deftly handled batch, timeshare, and real-time programming.

      • I would disagree with you about RMS, but then I would, having used it to coordinate shared access to indexed files across processes and a cluster. The only solution under any Un*x system is to use a DBMS. Oh and recovery unit journalling, you could even have that too! The end result is a lot faster than any DBMS.

        The oneness applied to RMS as well, whichever language you used, you could always access an RMS file. If you really didn't want RMS, you could just open a file on a block level and DIY, which what many DBMS systems did.

  • but VMS lives (Score:3, Troll)

    by g4dget ( 579145 ) on Saturday August 31, 2002 @11:48AM (#4176414)
    The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS, with a DOS-like command line and a Windows GUI.

    And the relationship between VMS and UNIX is analogous to the relationship between Windows NT and Linux. VMS was indeed considered very secure--probably because it had lots of "security features". In real life, however, VMS systems were often a lot less secure than UNIX systems because it was nearly impossible to get all the security setting right. More generally, UNIX was built around a small number of simple ideas and paradigms, while VMS attempted to be the all-singing-all-dancing operating system.

    So, if you want to get that "old VMS feeling", just fire up a Windows NT or XP machine and type at the command line--it's roughly the same.

    • The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS, with a DOS-like command line and a Windows GUI.

      A computer prof I had pointed out the above fact as well as the letters VMS shifted up one is:
      VMS -> WNT (WinNT)
      Interesting...Intended...or accidental?

      • Word games

        Linux shifted up:
        MJOVY

        and down:
        KHMTV

        GNU up:
        HOV

        GNU down:
        FMT

        DEBIAN up:
        EFCJBO

        DEBIAN down:
        CDAHZM

        Nothing good.
      • close but no banana

        NT is named after the NT register in the 386
        where NT stands for Nested Threads.

        of course marketing spin turned it into
        "New Technology"

        so we now get "WindowsXP based on NT Technology"

        or Windows XP based on New Technology Technology

        a bit like PIN Number

        • > or Windows XP based on New Technology Technology

          Actually no...

          Due to FTC regs, they cannot use the "New"
          anymore becuase the underlying OS is not new
          anymore. They can still use "NT" as long as
          they claim it doesn't have a real meaning
          anymore.
    • Sure, the same person may have designed NT, but it was implemented by Microsoft. And that was it's downfall. MS is a production line, like a car production line...with cars, they issue recalls, with MS Operating systems, they issue Service Packs.

      ttyl
      Farrell
    • Actually it was remarkable easy to set up security on VMS. The real issue was monitoring the security alarms.

      Most of the hacks were through social engineering. The others were due to imperfect parameter checking. As the system matured, it got even more tight on the hecks and most of the holes disappeared.

    • The same guy who was responsible for VMS is responsible for Windows NT

      Yes, his name is Dave Cutler. IIRC he quit working for M$ in discust about the time NT 3.5.1 was released (please correct me here).

      So, if you want to get that "old VMS feeling", just fire up a Windows NT or XP machine and type at the command line--it's roughly the same.

      No. The Win cmd shell is nothing like VMS. Not even close. It's really a glorified DOS shell, and has nothing whatever to do VMS. Ever used a logical under a Win cmd shell? I thought not.

      I was a sysadmin on VMS systems for about 1 1/2 years, and right after that I wrote desktop apps that used RDB on VMS as a data source for about 3 years. I have at least a passing familiarity with it. It is without a doubt the most stable OS I've ever used including SunOS, Solaris, Linux, and WinNT*.

      It's really too bad that DEC/Compaq continually bled their VMS/Alpha customers dry. Software, hardware, support were all obscenely expensive, and this more than anything else is what killed VMS and DEC in the long run.

      • On the shells: The NT shell (command.exe) has nothing to do with the VMS one. It was designed to be compatable with the DOS command line. The DOS command line was designed mostly to match CP/M. As far as I can tell, CP/M was mostly influenced by RSX-11M from Dec. DOS version 2.0 also introduced a lot of Unix C-shell like things into the command line. The Unix C-shell was also influenced by RSX-11M and perhaps other companies command lines from the 70's. But there is no way that the NT shell would have been influenced by the VMS one at all.

    • The only real similarity between VMS and NT are the kernels. That's what Dave Cutler worked on.

      DOS command line is more like unix that VMS
    • One of the first things I remember ever being told about Windows NT was that it was a direct rip-off of VMS. In fact, if you ever wondered what NT meant (Network Technology?) it supposedly doesn't really mean anything...
      Microsoft supposedly named it NT because WNT is simply +1ing the letters VMS.
    • So, if you want to get that "old VMS feeling", just fire up a Windows NT or XP machine and type at the command line--it's roughly the same. uhmm... no. It's not. I worked with VMS for a couple of years learning to program FORTRAN back in the late eighties -- the commands are not even close. The only similarities between VMS and NT are due to the fact that Dave Cutler(I think) worked on both -- the interface for NT is mostly copied from DOS.


    • > The same guy who was responsible for VMS is responsible for Windows NT. You can think of NT as an attempt of a next generation VMS

      Except that Windows clustering still hasn't caught up to where VMS was 15 years ago.

    • Re:but VMS lives (Score:3, Informative)

      by quark2universe ( 38132 )
      I disagree about VMS being less secure. In the hands of a novice, ANY system is insecure. VMS is/was one of the most secure operating systems around. That is partially due to the fact that it didn't have a native TCP/IP stack (at least it didn't when I worked with it). How many DECnet hackers are out there, raise your hands. And face it, most security issues now stem from network attacks, not from a file system or process scheduler standpoint. And another thing, compare the authentication mechanism and the options you have with the VMS UAF facility vs. the passwd/shadow files on Unix. VMS wins.

      And, no, you can't just fire up CMD and get that "old VMS feeling". Case in point, type help on Windows and compare that to help on VMS. Light years apart buddy!
  • If Windows NT was built by a bunch of VMS people on top of OS/2, using VMS concepts, why does it suck so badly?
  • Wasn't one or more of the head Engineers of VMS responsible for the mess that is Windows NT/2000?

    Maybe there could be a UNI course OS101 how to turn a secure OS into a virus infested shatered [decepticons.org] mess. Bill can hand out the degrees
    • Yes, Dave Cutler engineered the VMS Kernel and the NT Kernel. He was not responsible for all of VMS so could not bring all the knowhow with him (in the early days, Digital and Microsoft were good friends as NT was also targeted at their Alpha chip). In particular, he didn't bring along the file system or security concepts (Andy Goldstein was responsible for that) and he didn't bring along the distributed lock manager, which was essential to the smooth running of VMS Clusters.

  • VMS++ = WNT (Score:4, Informative)

    by Baldrson ( 78598 ) on Saturday August 31, 2002 @11:52AM (#4176429) Homepage Journal
    No account of VMS would be complete without acknowledging that Dave Cutler [wikipedia.org] took VMS from DEC to Microsoft to create Windows NT. He acknowledges the acronym WNT was a pun on VMS++ [wikipedia.com] (add one to each leter of VMS ala HAL++ => IBM in 2001 a Space Odyssey.
    • Don't forget Dave Kashtan (sp) and the SRI and TGV [Two Guys and a VAX] folks - they added enough Unix-layers to make it possible to avoid DCL and created a decent networking stack as well.

      (TGV was also a contributing source to one of the original two Internet Toasters - yes they really existed - in 1988. The other Toaster was built by John Romkey [FTP Software] [Both Toasters used my SNMP software in their controllers.])

  • Docs, if jumping into the free shell (Score:4, Informative)

    by inkfox ( 580440 ) on Saturday August 31, 2002 @11:52AM (#4176430) Homepage
    If you dive into the free shell accounts they're offering, you might want to spend a little time here [compaq.com]. It's the master documentation site for all your OpenVMS needs.

    This [compaq.com] seems to be the best guide for a user who's never even looked at VMS before.

  • even at the bank I work at and we milk things for a Loooong time. I've a dually alpha, but I loaded debian on it. That was a huge pain...only got it done thanks to MadHack, but man that thing flies.
  • The Rochester Institute of Technology [rit.edu] still uses VMS for a few of it's systems. 100% of class registration runs through the VMS, and students have the option of using VMS for their e-mail. Personally, I think it's one of the most confusing operating systems I've ever had the displeasure of sitting at, but I guess I thought the same thing about Linux at first..

  • VMS was my first OS too (Score:2, Flamebait)

    by Baki ( 72515 )
    And this article brings back bad memories, nightmares. I have always hated this unelegant, bulky and heavy operating system.

    At the time I didn't know better, but had a vague idea that it must be possible to make something better. Luckily other VAX users had thought so a long time ago, and ported UNIX to VAX.

    Then after 1 year of VMS we got our first UNIX machine (a Convex minisuper) and then I saw the light. In my opinion, UNIX and VMS were two opposites in almost any aspect. Using UNIX was a joy, it was elegant, efficient and interesting.

    I have never been able to understand how (later) in a single company two such opposite culters could stay together (in DEC, the UNIX and VMS groups) and it turned out, not surprisingly, they could not.

    Everyone who likes UNIX and who knows both UNIX and VMS well cannot but hate VMS. I bet many, like me, still wake at night sometimes due to a nightmare about VMS. In that respect, WNT is a worthy VMS++ indeed.

    • I find that odd, saying how UNIX was a joy and VMS brings nightmares. Perhaps it's because I went the other way round (of sorts) in terms of experience: Amiga -> UNIX -> VMS.

      Whilst I use and prefer UNIX/Linux, I appreciate that VMS isn't a bad OS at all.
      But perhaps it's simply because the first time I did a 'sh log' on an Alpha at work (which we have only recently switched off after 10+ years of use) a smile can across my face as it took me back to the good ol' 'assign' of my beloved Miggy ;-)
    • Everyone who likes UNIX and who knows both UNIX and VMS well cannot but hate VMS.

      Ok, let me first tell you about my personal collection of computers. I have

      HP-9000 J-210 - 2 processor HP/UX
      RS/6000 J-40 - 8 processor AIX (run *very* hot)
      3 x Sun SS-20 - 2 processor Solaris
      1 x SunBlade 100 - single procssor Solaris
      2 x Sun LX - singal processor Solaris
      2 x Tadpole 3GX - laptops, Solaris
      Alpha 2100 - single processor Tru64
      intel - single processor SuSE 7.1

      I've run Linux since the .99 days, before then I ran Coherent (unix clone, now dead), SCO Unix, SCO Xenix.

      I use unix everyday in my job. I love unix, if it weren't for unix, I probably wouldn't be working in the computer industry.

      My other remaining box is a VAX 7000/90 running OpenVMS.

      I love VMS. It can do everything that unix can do, but it just does it differently. You wouldn't program in lisp the same way you would program in C. You have to think in VMS when using VMS and don't try to apply unix ways of working to it.

      My guess is that you just didn't learn enough about how VMS works to really understand it. Not surprising since you only used it for a year. Maybe if you'd learnt it more and had to do system admin tasks in it, you'd appreciate it better.

      VMS was ahead of unix in so many way - access control list security, VMS had it way before, clustering, VMS had it way before (and it still is bettter than most versions of unix). VMS was set up from the start to monitor and control users and their cpu usage, for unix, you get vendor-created add-ons which do the job and are no way near integrated.

      From a captive end-user perspective, maybe VMS was not so much fun, but from an admin perspective, if was fantastic.

      • Yes, clustering was ahead of its time.

        The other 'features' like ACL and other control-freak tings, they were only an annoyance (in fact ACL still is one of the things I generally despise; they encourage an admin to make a quick permission exception, leading to a mess without concept in a short time).

        I remember end of the 80s, every physics department was dumping VMS and moving to UNIX (sometimes on new hardware, sometimes on VAX hardware). We all were so relieved to get a nice and elegant environment instead.

        For VMS with its lead-heavy process model for example, the "UNIX building box" philosophy is alien. You don't have a shell starting small subprocesses all the time, possibly combining them using pipes. The 'everything is a file' concept doesn't exist, so you have different system calls for handling each kind of device (i.e. multitudes of system calls compared to the small and orthagonal well though out set of UNIX system calls). In short, it is just like WNT :)
    • I have never been able to understand how (later) in a single company two such opposite culters could stay together (in DEC, the UNIX and VMS groups) and it turned out, not surprisingly, they could not.

      I'm not quite sure what you mean by that but HP now have two Unix groups (HP-UX and Tru64) and a VMS one.

      I work for a large software company that sells software on many platforms and I can tell you that there's still a heck of a lot of VMS out there. Until I hear differently I'm assuming HP will be honouring Compaq's commitment to port VMS to Itanium so that VMS users have an upgrade path.
  • I had to use it when I was in college. I found its user interface to be absolutely wretched. Horrid abominations for editors like SOS, EDT and TPU. And the VMS mail client was absolutely bletcherous. A lot of the things other people liked like the versioning file system I found more of an annoyance, if I want version control I'll use something that lets me check things in and out when I want to.
    • Thanks for your comments Linus..

      Former system admin in the VMS Group
    • I had forgotten about EDT - actually it was a huge step up just having a screen editor on RSX-11M, before that we had some horrible line editor. Shortly after that I got into Unix System III and learnt vi, and have never stopped using it...

  • VMS didn't leave (Score:4, Informative)

    by Sivar ( 316343 ) <charlesnburns[ AT ]gmail DOT com> on Saturday August 31, 2002 @12:33PM (#4176569)
    VMS didn't go anywhere. Windows NT is based so closely on VMS that some have called it a new version of VMS with a GUI tacked on.
    David N. Cutler, the chief software architect of NT, worked for DEC in the 70's. He had designed VMS and worked on releasing newer versions. Cutler became bored doing this so DEC gave him several hundred engineers and computer scientists to work on a next generation CPU and OS.
    In 1988, DEC laid many on David N. Cutler's team and nuked both projects. He was fairly ticked off and left Digital only to be hired by Microsoft, bringing quite a few former DEC guys with him.
    Cutler designed NT very similarly to how he designed VMS and Microsoft actually licensed several parts of VMS from DEC in a cross-licensing agreement in which DEC got the chance to use some of the Windows API in pure VMS. (How useful this was to DEC is questionable...)

    So despite Microsoft marketing that NT is a cutting-end OS and even naming it "New technology," like Unix it is still based 1970's ideas and code.

    As for pure VMS, my school uses it for both the C and the Pascal classes.
    DirecTV uses it for their billing system called STMS. (How I found this out has plenty to do with /., ironically) }:>

    I have found that it is very similar to DOS on steroids. It uses very similar commands, uses forward slashes `/' for parameters, uses extentions for file names (the same ones as DOS; .exe, .obj, etc.) but unlike DOS is very good at having a ton of simultaneous users.
    Some differences: Its C compiler sucks, it never overwrites old files but instead makes files of a similar name (foo.c, foo.c;2, foo.c;3 etc.), its memory manager is famous for being fairly slow (though DOS has no memory management to speak of), and it makes a good server OS. Unfortunately if you want to run it, you have the choice between VAX and Alpha, neither of which are particularly common machines.
    You can run quite a bit of Unix software on these things just fine if you compile it letting the make script know that the system is VMS.
    • VMS didn't go anywhere

      This is why the largest electronic derivatives exchange in the world [eurexchange.com] runs on VMS. Many other exchanges also use VMS. They do so for a reason, it takes on a bundle of work and doesn't die. If you have redundant hardware, it will stay up for ever, just failing over between hardware when it craps out.

      Incidentally, Cutler started by writing RSX-11M then 11M+, a 16-bit operating system. He then went onto writing VMS and later the Digital PL/1 compiler before he left.

      Digital got very little from MS apart from the promise to use their hardware platform for NT. The Windows API definitely has no relation to any of the APIs on VMS although some bits may be similar because of the former Digital engineers.

      As the for command language, the original DOS/CPM commands derived from another 16-bit Digital operating system, RSTS/E. Both RSTS/E and M+ eventually started supporting Digital Command Language (DCL) which became fully developed under VMS (much like a Unix shell). The file types go back to the RSTS/E and RSX days.

      The version numbers that you complain about are a feature of the VMS file system. They allow you to keep a few old versions of files around easily so you always have the possibility to revert to a previous version.

      They memory manager is not particularly slow unless there is a high demand for memory and not enough physical memory available, and even Linux has problems there. The real issue of VMS as a platform is the overhead associated with process creation, now partly circumvented with threads.

      • Re:VMS didn't leave (Score:3, Insightful)

        by dhogaza ( 64507 )
        RSTS/E was DEC's 16-bit BASIC operating system. You're probably thinking about RT-11. You could run an RT-11 emulator as an alternative to the BASIC interpreter under RSTS/E, thanks to a group of us in Oregon who made this available in the early 1970s. Perhaps you had the opportunity to do so. But RSTS/E out of the box announced itself as being "Ready", just like any other BASIC interpreter environment at the time (like the one I wrote for the PDP-8). RSTS/E had a relatively modern design, though, with the kernel and shell (if you will) fully separated. This design is what made it possible to dispense with the BASIC interpreter ("shell" in Unix terminology) and replace it with an RT-11 one. It also supported shared read-only executable segments in 8KB chunks (matching the memory mapping hardware of the PDP-11) so one copy of the RT-11 or RSTS/E BASIC "shell" was shared by all users. Not bad for 1970 technology on a 16-bit mini-computer.

        All of these owe the basic structure of the CLI and file naming conventions (forward slash for parameters, 3-letter file extensions, etc) to the older PDP-10 operating system which dates back to the 1960s. The same basic CLI and file naming conventions were also supported by OS/8, DEC's PDP-8 operating system written mostly by Richie Lary.

        OS/8's sources named it the "*bleep*" operating system, otherwise known as the First Upward Compatible Keyboard Monitor, or FUCK'M, operating system for the PDP-8. When Richie first proposed writing a PDP-8 operating system that was command-level compatible with the 36-bit PDP-10 timesharing operating system (thus the "upward compatible keyboard monitor" moniker), he was told "no" so wrote the first version of OS/8 on the sly. The acronym described his personal feelings towards management at the time, and later it became the standard single-user PDP-8 operating system.

        Personally I think all of Dave Cutler's OS's more or less sucked, starting with RSX-11M and still true today with NT.
        • I'm curious as to why you didn't like Cutler's systems. RSTS/E was one gigantic hack and proved as difficult as RSX-11D to support (as reflected in the prices). The M exec was lightweight and was used as the basis of one of the most successful healthcare systems of all time (MUMPS). It was a building block rather than a solution in its own right which was it was much loved by solution providers. I have seen steel mills, ATC systems, chemical plant control systems all based around the 11 and RSX-11M/S.

          M support for paged memory (necessary for the PDP-11/60 and 70) was officially opposed by management because of the RSX-11D system (similarly named but no relation) had the place at the top of the range. Cutler implemented the changes in a weekend "for in-house debugging purposes because Digital had a lot of 11/60s around at one stage". The hack became known outside (the customers had the Exec source code and the SYSGEN tool so it was obviously there) and Digital was pressed to support it. Towards the end RSX had shared libraries, I and D space support and many other neat ideas (including a modularised exec). Many of these concepts didn't travel again to VMS until comparatively recent times.

          Whilst Cutler was a good exec 'hacker', I guess he had problems in larger teams and this is perhaps why NT sucks so much. Many of the issues with NT seem to come down from weak leadership, leading to the API of the month competition. Note that the original NT design had the GUI running in user-space. It was too slow, so MS moved it to kernel space, bugs and all, which then haunted NT up until Win2000.

      • The real issue of VMS as a platform is the overhead associated with process creation, now partly circumvented with threads.

        Which is an issue NT inherited... Hence all the fuss made comparing NT and Linux thread handling.

    • Umm... in a word, "no".

      VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong. Besides, very few people have ever seen the aspects of Windows NT that resembled VMS; it most certainly isn't in the command line.

      "It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense.

      "It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.

      "It's memory manager is famous for being fairly slow..." I don't get this one at all. Are you referring to the system pager? Packet lists and non-dynamic pages? Page files? All of these size parameters are well-known (famous?), but more importantly, all can be tweaked via SYSGEN to your heart's delight. Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.

      "You can run quite a bit of Unix software on these things just fine..." It would be better to say that you can get POSIX compatibility under VMS. If you write for POSIX, yeah, you could get your code going under VMS. But many Linux/*BSD hackers these days neither know nor care about POSIX (not without good reason, I might add, POSIX.1 was seriously flawed in some respects), so I really have to question "quite a bit".

      I don't like to nitpick, but your post does a real disservice to the VMS folks out there. I haven't seriously used VMS since the 4.x days, and am only marginally aware of the current state of OpenVMS, so I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.

      • "VMS is not similar to DOS on steroids; maybe DCL looks like a DOS interpreter to you, but the underlying operating system is vastly different from that toy program loader called DOS. Calling them similar is just wrong."
        That is what I was referring to is the CLI. Regarding the underlying architecture being dissimilar to DOS: My post illustrated that itself. I know. Just the fact that VMS is, as I said, a multiuser OS makes it vastly different underneath.
        Just as many people see little difference between Windows ME and Windows NT and talk about interface similarities, so too was I talking about interface similarities. The difference being I know the differences are more than skin deep.

        "It's C compiler sucks" You must be joking. DEC is famous for having some of the best compiler gurus; historically, their compilers have always been among the best, both in speed and code generation. Tartan was the only company I recall that could beat DEC on a VAX, and no one's yet matched them for code generation on Alpha. That VMS would somehow ship with inferior compilers doesn't make sense."I wasn't referring to the speed of code generated as much as the irritation of using it. Granted, I did not check what version of the C compiler I was using, but it was lacking in some features. It's fflush(); worked erratically (though that has more to do with the libs than the compile I bet) and it didn't even support "//" comments. Granted, "//" was a C++ (not C) standard until C99, but nearly every other compiler I have used supports it perfectly. Looking back these may seem to be very minor but did not leave a good impression about the software. Perhaps saying that the compiler sucks was a bit of an overstatement. :)

        "It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. Yes some people really like this feature--I am sure it has saved many people from a horrible death, but many people including myself actually find it irritating. This would probably not be the case were I more used to it, but I have become accustomed to my own ways of versioning and do not particularly like the extra step. Additionally, the file names generated for versioning are often difficult to associate unless one keeps close mental track of their saves. My foo() function isn't working now, but it was working three days ago. Was that in bar.c;27 or bar.c;39?
        Yes, you can still version yourself, for example simply making copies of files at important points in time and naming them appropriately, but having a default system tends to discourage people from using that, just as a PC coming with Windows 98 discourages use of something better like Win2K or an alternative OS. Human laziness? Probably.

        Nobody who can read a manual suffers from a slow memory subsystem on their VMS box.I can't read. Sorry. :)

        I'm quite willing to be corrected. But, even older versions of VMS say otherwise about your comments.So am I, and no problem here. You clearly know more about VMS than I, and I appreciate your input.

      • Re:VMS didn't leave (Score:4, Interesting)

        by skuenzli ( 169327 ) <stephen_kuenzliNO@SPAMyahoo.com> on Saturday August 31, 2002 @02:48PM (#4177188) Homepage
        "It never overwrites old files..." Many like this feature: by putting those hooks in at the filesystem level, all commands automatically inherit file versioning. When you're certain you don't need the old versions any longer, you can clean up with a single command. And, finally, if you really don't like it, you can turn it off.
        Do you know how the versioning is implemented? I am a 'casual' user of VMS 7.2-1/7.3 at work, and this I think the automatic file versioning is a really cool feature. However, I've always wondered if I make a small change to a large file, does it copy the whole file? I'm guessing there are some configurable limits on file size for what gets versioned and what doesn't. I suppose you could use some sort of diff/patch implementation, but that would get a bit messy if you have (to borrow an example from elsewhere in this thread) foo;1 foo;2 foo;3 and delete foo;2.

        Another feature I really like about VMS is the performance reporting tools that are built (??) into it. Every time I run load tests without telling my admin, he starts sending me graphs about what I did to the machines and do I know anything about it, plus if I can ask him for data from 2 months ago, and he's likely to have it.

        Stephen

        P.S. I say 'casual' because I just can't get into the 'set def mylogical:[sub_dir]' sort of stuff that our applications require.
        • I found this regarding SnapFS, which is a layer that can sit between the Linux VFS and a journaled filesystem to perform (not just) versioning. Copied from LWN.net [lwn.net]:
          Whenever a file is to be modified, and its contents must be preserved in a snapshot, SnapFS creates a new inode in the filesystem to hold the snapshot version. An extended attribute which points to the snapshot inode is then attached to the visible version of the file. The actual blocks of the file are shared between the current file and the snapshot until they are changed;
          at that point the SnapFS "copy on write" mechanism makes copies of the affected blocks . Snapshots are thus relatively efficient in their use of storage, especially in situations where only parts of files are changed. For example, a snapshot of that huge web server log file, which is only appended to, does not duplicate the log entries that are shared between the current and archived versions.
          Unfortunately, I think this project may be stalled as noted in the developer's project notes. [sourcefrog.net]

          I still don't konw what OpenVMS does as I couldn't determine that after over an hour with Google. However, looking at the semantics of the DELETE and PURGE commands it looks like you can get remove arbitrary versions of files. So, I guess each version is a complete copy (or can become one when you delete earlier versions).

          Ok. Ziti and Sopranos time. Let's hear it for season 3!

          Regards,
          Stephen
  • To me VMS was one of the technical best of the proprietary systems. They cost an arm and a leg but you got value for what you paid for. Their OS, compilers, and other software had top notch documentation and were more stable than just about anything out there.
    • Largely, yes. Some of their stuff, frankly, sucked. For example, the early implementations of PL/1 and VAX/C. In the latter case, we just used GCC for VAX/VMS and it worked fine. The docs were excellent and unlike MS, there were very few really internal APIs and they weren't being revised every six months.

      And it is still stable which is why it is being used for electronic trading.

  • * Excellent documentation. Used to fill several shelves. Writtent by engineers, and very well cross referenced.

    * Very good C compiler *for the time*. Used it extensively in early 80s at EDS & GM

    * Excellent system level IPC. The Message Box interfaces were extremely easy to use. Easily built large distributed systems with these.

    * Excellent, multi-layer security model. Much better than the Unix model(s) even today.

    * Good network *at the time*. DecNet beat the pants off IBM SNA for engineering and distributed systems work. Faded gradually with the rise of IP. Don't know if anyone still builds DecNet networks except in the CCIE labs.

  • Michigan's child support system runs on it, or most of it does. Finally last year pieces of it started getting replaced with an Oracle back end and Java (urg) front end. But at this moment most of the state's child support personnel log onto a VMS system via terminal emulators.

    Frankly I find the old application much more responsive and pleasant to use. I'm sure in just 5 or 10 years of bug fixes the new system will be just as good ;)

  • Thevax.org (Score:2, Informative)

    by paranoidia ( 472028 )
    Another great free site is thevax.org [thevax.org] these guys have set up some VAXen machines on the internet for free for people to use. All you need to do is submit a form for a free account. So if you want some alternatives, here they are. Already a lot of users from around the world.

  • If you like VMS, run NT 3.51 SP 5 (Score:3, Informative)

    by Animats ( 122034 ) on Saturday August 31, 2002 @01:57PM (#4176944) Homepage
    NT 3.51, with the last service pack SP5, is the purest expression of the VMS model in NT. That's the last version before Microsoft let the kode kiddies from the Windows 95 group put their stuff in the kernel. In NT 3.x, all the GUI stuff is outside the kernel and untrusted, so there's some hope of securing the thing. In NT 4, all that crap went inside the kernel. A version of NT 3.51 without networking once passed NSA's lowest level of security testing.

  • Test Drive (Score:2, Informative)

    by Compaq Test Drive ( 560243 )
    You can also try out OpenVMS in the HP Test Drive Program (http://www.testdrive.compaq.com/ [compaq.com]), where it has been there for several years now running on a cluster of Alphas. In fact, for most of the past month, we had it running on an EV7 prototype, although unfortunately that system is now offline. If you're interested in VMS, I'd also suggest you check out http://www.openvms.compaq.com/ [compaq.com]. And by all means, if there's something you'd like to see in our program, let us know [compaq.com].
  • This page really brings back some memories, both good and bad.
    Now that comment demands amplification. I'm also frustrated by all the posts talking about NT's VMS roots, but few specifics as to what features and technologies NT inherited from VMS.

    I never used VMS, and I was ignorant of the VMS-NT connection. I lost my chance to use VMS when my school got its first VAX, and decided to run Unix on it instead of VMS. The decision was not universally popular on campus! Unix was still a work in progress. In particular, Bill Joy and his bunch at Berkeley were still hacking out a Unix that could make proper use of the VAX's memory management hardware.

    It's funny. We think of the rivalry between Linux and NT as part of the broader conflict between Microsoft and various anti-Microsoft forces: the open-source community, MS's competitors and detractors, etc. But it seems that it's partly a continuation of the decades-old rivalry between Unix and VMS!

    1. Common calling standard -- a mainline written in, say, Fortran could call subroutines written in C or Cobol or Pascal or Bliss or Basic or Assembler -- or almost any other language; they all used the same method for passing args on the stack. Foresight, or what?
    2. Clusters -- VMS systems have been clustering for longer than any other OS -- and the functionality any VMS cluster had a decade ago far outstrips the capabilities I've seen in any Microsoft or Unix cluster today.
    3. Asynchronous Traps (ASTS) -- man, they made network and I/O programming easy -- just start an I/O operation, and specify the routine to be invoked when the operation completes -- then just forget about it, go and do something else.
    4. DECnet -- VMS was the first DEC O/S to have DECnet built in from the ground up. This meant that copying/reading/writing network files was a trivial exercise -- if you could do it on a local file, it would work over the network without any extra effort. FTP, pfffft!
    5. TECO -- it didn't start on VMS, but hey, now there was a real programmer's editor. Forget about EDT or SOS or VI or even EMACS. TECO ruled.
    6. Documentation -- the doc set weighed more than a lot of the workstations -- and needed a whole lot more shelf space. Good, too. Way, WAY better then Microsoft, or any Unix variant I've come across. IBM's docs were almost as good -- but then, IBM programmers need docs more ;-)
    • I worked at Dec in 1982-4 and part of that time worked with a group on porting the Clu compiler (Clu was an early smalltalk-like OO language) from BSD Unix to VMS. The calling convention really bit bad as it was as much as six times slower than what Clu was using for BSD. You could not use the Clu convention because they wanted to call existing services without a wrapper, also I think the functions relied on register layout different than VMS used, or trapped, or something.

      The project apparently died because it was unreasonably slow due to the fact that the Clu compiler produced lots of function calls, like for every multiply.

      So I'm not sure if the uniform calling convention is a win. Linux actually is doing ok with wrapper libraries around C code like all the Perl and Python wrapper libs.

  • From a button seen sometime and somewhere in late 1980's or early 1990's:

    VAX/VMS - Software for the Sixties.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close