back to article Call off the firing squad: HP grants stay of execution to OpenVMS

In a surprise move, HP has granted OpenVMS a new lease on life, effectively reversing last year's decision to mothball the venerable server OS. HP hasn't changed its mind about its latest OpenVMS roadmap, which has it ending standard support for some versions of the OS next year and pulling the plug completely by 2020. Rather …

Page:

  1. Anonymous Coward
    Anonymous Coward

    Are we sure someone hasn't confused

    Are we sure someone hasn't confused April 1st and August 1st?

    Assuming not, then this decision potentially makes more sense for what remains of the VMS community than any other significant VMS-related decision HP have made since they took over CPQ.

    1. JeffyPoooh
      Pint

      OMG! VMS in some form still exists?

      Yippie! How do I resurrect the greatest Lunar Lander game ever?

  2. druck Silver badge
    Go

    The whole 9 yards

    Why not go the whole 9 yards and bring it over to 64bit ARMv8?

    1. Anonymous Coward
      Anonymous Coward

      Re: The whole 9 yards

      Even after the reworking to get from VMS to OpenVMS, which was mainly to port it from the Vax architecture, I'd imagine that there's an awful lot of code that would need extensive work to run on an ARM architecture.

      Anyone know what languages VMS was principally written in? That could be another hurdle to porting if it's in archaic or non-mainstream languages.

      1. Anonymous Coward
        Anonymous Coward

        Re: The whole 9 yards

        "Anyone know what languages VMS was principally written in? That could be another hurdle to porting if it's in archaic or non-mainstream languages."

        The ports from VAX to Alpha, and then Alpha to "Industry Standard 64bit" Itanium, got rid of significant quantities of arcane VAXisms and VMSisms and resulted in a more portable OS with device and architecture dependencies much better isolated. Device drivers and kernel components etc can largely be written in C, by the OS vendor or by users or hardware or software suppliers.

        Deep inside the OS there'll still be *architecture* dependent stuff - for example there's no universally accepted definition of what a memory management unit should look like or how it should behave, so that piece of the OS would need fiddling with when moving to a completely new architecture. Lots of the OS should recompile without too much issue (not to belittle what lies ahead for VSI).

        1. Anonymous Coward
          Anonymous Coward

          Re: The whole 9 yards

          I'd love to know a bit more about VMS internals. I'm a Unix type, so I'm wondering if there are the equivalents of things like Lion's commentary on the Unix source code, Bach's "Design of the Unix Operations System" or the BSD "Design and Implementation" book.

          1. Anonymous Coward
            Anonymous Coward

            Re: The whole 9 yards

            There was a DEC course on "Internals and Data Structures", and corresponding commercially published books. The details will have changed for Alpha and Itanic (and iirc the publications were updated accordingly, at least for a while) but the principles won't have changed much at all.

            Stick "VMS Internals and Data Structures" into your favourite search engine and see where it leads. If you add the name "Ruth Goldenberg" (one of the book authors) it may get you a more interesting subset.

            Some earlier versions now seem to be freely downloadable from bitsavers, archive.org, etc, e.g.

            https://archive.org/details/bitsavers_decvaxvmstInternalsandDataStructures1984_68312137

            Warning: 800+ pages.

            Do not ever attempt to find anything on HP's own website using the website's search facility. It is utterly useless.

          2. Anonymous Coward
            Anonymous Coward

            Re: The whole 9 yards

            There is! It's the "VMS Internals and Data Structures", and it is a far better read than any other such book I have read.

            <fanboy mode>I got mine signed by Ruth Goldenberg!</fanboy mode>

          3. Tore Sinding Bekkedal

            Re: The whole 9 yards

            There's a hefty tome, "VMS Internals and Data Structures". It's probably the best book of the "OS walkthrough" genre I've read. It doesn't hurt that the OS design itself is so good.

            <fanboy mode>I got mine signed by Ruth Goldenberg!</fanboy mode>

            1. Anonymous Coward
              Anonymous Coward

              Re: The whole 9 yards

              Thanks folks - just ordered a copy of the Goldenberg book second hand from Amazon.

            2. Stoneshop

              Re: The whole 9 yards

              I got mine signed by Ruth Goldenberg!

              $ SET ENVY /COLOR=GREEN

          4. znby

            Re: The whole 9 yards

            "VAX/VMS Internals and Data Structures" by Goldberg and Kenah.

      2. Phil O'Sophical Silver badge

        Re: The whole 9 yards

        Anyone know what languages VMS was principally written in?

        From what I remember of the microcode, the core parts were Bliss32 and Macro32 (essentially VAX structured assembers) with some leftover Macro16 PDP code still there. The utilities were in everything, I remember seeing Fortran and Pascal, even some ANSI Basic. Hopefully the Pascal at least has long gone.

        All that would surely have changed for the Alpha ports, though? I never had a chance to play with it post-VAX.

        1. Stoneshop

          Re: The whole 9 yards

          All that would surely have changed for the Alpha ports, though?

          From what I got to hear, for the VAX to Alpha port a lot of work was in getting rid of VAX-specific features (which must have been everywhere; after all, they were developed as close as can be), and aiming for architecture independence, but the Itanium port wasn't quite that straightforward after all because of the way it dealt with smaller-than-64-bit data structures. But dealing with that is primarily a task of the compiler and linker as long as you're not writing in assembler or doing an OpenSSL with in-memory data.

          1. Anonymous Coward
            Anonymous Coward

            Re: The whole 9 yards

            "the Itanium port wasn't quite that straightforward after all "

            Some additional "not quite that straightforward" irritants apparently included data-alignment issues and differences in the handling of exceptions. These are normally primarily of interest to OS and language runtime developers rather than application developers, but in the wrong circumstances they can become visible to application developers. E.g. this happened with some applications which made significant use of unnaturally aligned data, and consequently messed up performance not just for the application in question but for the system as a whole, till matters were tidied up. This is long since sorted for Itanic and presumably will not be a big issue for the AMD64 port.

    2. mamavms

      Re: The whole 9 yards

      Well VMS Software Inc does have an R&D group and since all we do is VMS Software development who knows what is to come in the future.

      Sue Skonetski

      VMS Software

      Customer Advocacy

    3. mamavms

      Re: The whole 9 yards

      We have a R&D team who are looking at all kinds of options after x86. Who knows what will happen. I do know your ideas are welcome.

      Sue

  3. This post has been deleted by its author

    1. the spectacularly refined chap

      Re: hmm

      Their POSIX compliance was actually fairly good: the problems arise when people don't bother to read the standard - it's a fairly bare bones standard that omits many things you'd take for granted. These days it seems many projects have simply ditched cross-platform awareness without even realising it - there's an awful lot of absolute shit out there that works on Linux but may have difficulties elsewhere. Blind assumptions such as the compiler is called "gcc", make is gmake, or that curses is ncurses come to mind when you are not even using the specifics of those tools.

      1. MacroRodent
        Thumb Down

        Re: hmm

        "Their POSIX compliance was actually fairly good:"

        But if they implemented only the original POSIX standard to the letter, you really could only run programs that read and write text files or interact via a text terminal. Networking, what's that? The Windows NT "POSIX box" was like this, guaranteeing that nobody actually used it (I think it was Vista that finally dropped it and nobody noticed).

        1. Anonymous Coward
          Anonymous Coward

          Re: hmm

          VMS became POSIX'y enough to be able to run an X Window System - the first time I saw X on a VaxStation I assumed it was running Ultrix (Digital's version of Unix), and was quite surprised to find out it was running VMS. I'd always associated VMS with those little VT320 terminals and console only stuff from when I did an evening course at the local tech college.

      2. Tore Sinding Bekkedal

        Re: hmm

        Ironically, the original term for lazy programmers taking too many non-defined aspects of their platform for granted was "all the world's a VAX" :)

      3. Peter Gathercole Silver badge

        Re: hmm POSIX

        I'm constantly infuriated by my Linux colleagues who assume that Linux is a POSIX compliant operating system, and that anything written for Linux can be easily backported to UNIX or other POSIX compliant operating systems.

        I currently work supporting and AIX HPC in an environment where Linux is used extensively for other data manipulation and modelling work. I keep getting questions like "Why is Linux tool X or Y or Z not available on the HPC", and I have to patiently explain that because the tool requires the complete KDE or Gnome environment, or reliance on dbus or udev or KMS, none of which are in the POSIX standard, or any number of cumulative package dependences, a back port is almost impossible.

        They cannot see that Linux has done the Embrace and Extend, and is well down the Extinguish path against UNIX and POSIX in a manner that would make Microsoft proud.

        And I would not mind too much if there was a new POSIX standard that was extended to specify parts of the Linux and GNU tool chain that genetic UNICIES could be extended to include, but there is no such thing! There was the LSB, but that's an unmaintained standard that everybody ignores.

        There is no workable Linux standard! And to cap it all, there is almost no Linux distribution that has even got full POSIX 1003 compliance, much less the more recent UNIX V7 <rant>(FOR GOD SAKE - UNIX V7 ALREADY MEANT SOMETHING! COULD THEY NOT HAVE USED ANOTHER NAME!)</rant> standard.

        UNIX is standardised. Linux is not. Linux should work like UNIX, not the other way round.

        Still I think I approve of the extended lease of life for VMS.

        1. Anonymous Coward
          Anonymous Coward

          Re: hmm POSIX

          Re "Linux and GNU tool chain"

          Readers may or may not be aware that there is an actively developed open source package for VMS called GNV (as in GNU's Not VMS).

          From http://gnv.sourceforge.net/ : "GNV (GNU's NOT VMS) is a GNU based project, delivering a Unix-like environment for OpenVMS. It is intended to provide the important subset of Unix/Linux/POSIX necessary to port Open Source software to OpenVMS. GNV consists of a "Unix-like" shell environment (bash) and many of the tools and utilities common to "Unix" shell environments."

          I imagine after yesterday there may be a few more people who might want to actively contribute (or, in due course, use). It'll be on my "to do" list.

          Re POSIX and Linux: the UK's Lasermoon once produced a POSIX-certified Linux. Lasermoon went bust, Caldera bought the POSIX bits and then... nothing. Mostly-compatible and zero cost generally beat standards-compliant but commercial, because it's usually only ever short term costs that are looked at.

          1. P. Lee

            Re: hmm POSIX

            Ooh, Lasermoon! My first ever purchased Linux distro. Closely followed by Caldera when I discovered they supported my turquoise-green "froggy" adsl modem out of the box, which red hat didn't. I'm still on SuSE, even now.

        2. Anonymous Coward
          Anonymous Coward

          Re: hmm POSIX

          "They cannot see that Linux has done the Embrace and Extend, and is well down the Extinguish path against UNIX and POSIX in a manner that would make Microsoft proud."

          Well said.

          This is why I have ended up with a collection of Linux instances running as virtual machines. This approach certainly involves a management overhead but I prefer that to spending my time trying to make everything fit on one platform.

    2. John Gamble

      Re: hmm

      "Granted its stability is legendary but after seeing the horrible hacks the VMS team basically forced on OpenSSL for all platforms (granted the core OpenSSL team should have pushed back a lot harder)..."

      I put the blame for that squarely on the OpenSSL team. It is possible to have VMS and UNIX code exist peacefully in the same code base (I've done it), and it is possible to do a code review of submitted patches to make sure the patches don't interfere with working code (I've done that too).

      VMS code didn't break OpenSSL, the OpenSSL team broke OpenSSL.

      1. asdf

        Re: hmm

        >VMS code didn't break OpenSSL, the OpenSSL team broke OpenSSL.

        Well said. The horrible hack patches may have been submitted by the VMS folks but someone had to accept them. Thank goodness the OpenBSD (who do understand quite painfully the difference between UNIX and Linux) folks are backing those out. BTW a lot of the reason Linux is making a mockery of POSIX and more becoming nearly impossible to port is due to Red Hat (and everyone else blindly following) IMHO. They are the ones who for commercial interests are pushing that freedesktop.borg and systemd bullshit.

  4. ideapete
    Pint

    Jealousy reigns

    HP via Compaq has always been jealous of VMS when it streaked away from the competition with DEC-Alpha which itself was a black project originally killed by DEC

    1. Steven Jones

      Re: Jealousy reigns

      DEC Alpha didn't streak away from anything. DEC got into trouble as it became greedy and complacent as it took its customer base for granted, charging ridiculous amounts for such basics as TCP/IP stacks. When a whole host of UNIX-based "hot box" companies came along, companies voted with their wallets to what they saw as a more open market where competition drove down pricing. DEC's reaction came too little and too late and VMS became just a legacy products with high costs.

      Of course the independents selling UNIX based kit all gradually succumbed from competition and the impact of commodity hardware and growth of Linux and Windows servers. Only the big-boys survived, and even SUN fell into the hands of Oracle.

      1. Anonymous Coward
        Anonymous Coward

        Re: Jealousy reigns

        even SUN fell into the hands of Oracle.

        That's because Linux started to do to Solaris exactly what Unix had done to VMS, playing on "cheap" and conflating "open" with "free". Sadly Sun's reaction was exactly the same as DECs. It stuck "Open" on the front, tried to diss the new stuff as snake oil, and insisted that Solaris was "better" if only the stupid customers would realise that. Better it was, just as VMS was better than Unix in many ways, but who cares about "better" when "good enough" is cheaper and perfectly adequate for most things.

        Sun could have embraced Linux, pitched it as the Unixy "little brother" of Solaris for the small systems which could be hooked up to big Solaris iron for the big jobs, selling both. Embrace & assimilate in a way. It should have given OpenSolaris systems and technical support away to universities worldwide to get the next generation of students doing their degrees on it, just as AT&T did with Unix. Instead it flip-flopped on Sun Linux/no Linux, the "Campus Ambassador" program was too little, too late. Schwartz drank too much open source internet cool-aid, and waited too long. Just like DEC.

    2. Stoneshop
      FAIL

      Re: Jealousy reigns

      Alpha was killed by Compaq, instigated, they say, by HP, who wanted Compaq, would get VMS with it, and wanted to unify on the Industry Standard (harhar) Itanic.

  5. MacroRodent

    Legacy only

    This is good news for those saddled with legacy VMS systems, but others should steer clear. VMS is a solid system but the trouble is it is too different from the mainstream now, so it is a lot of extra work if you want code that runs on it and also on Windows and *nix. Innumerable times in the various programs I have written or maintained there is one #if branch that does things for Windows and Linux, and other for VMS. I would have preferred the beast to die quietly in its sleep.

    1. Anonymous Coward
      Anonymous Coward

      Re: Legacy only

      "the trouble is it is too different from the mainstream now, so it is a lot of extra work if you want code that runs on it and also on [today's mainstream OSes["

      How old are you?

      Once upon a time, VMS was THE mainstream OS for 32 bit systems. And it stayed that way for a long time.

      But times and circumstances do change. The folk who think a Microsoft setup is and always will be the answer would do well to remember that.

      *IX is a different set of circumstances; it's probably not going away any time soon, but the details behind the name will likely change. I'm old enough to remember when System V and BSD and V7 (?) couldn't even agree on the number of parameters needed to open() a file; fortunately things have got better.

      Sometimes being different brings incompatibilities. Sometimes incompatibilities are the price of something more important.

      VMS hasn't generally passed strings around as null terminated unsized chunks of data (though if you're using VMS C it's easy enough). VMS's own native application data format for that kind of thing is descriptor-based, ie a documented structure that describes the string (how much space is available, and how much of it is used, where it is, etc), and a *separate* item that holds the characters themselves. Plus a documented and extensible set of routines to manipulate such strings. In many VMS languages all of this is hidden from the user; C's K+R-style strings are a rare exception.

      Is this approach slower to manipulate than null terminated? It depends (finding the end of a descriptor string is easy). Is it more robust than vanilla null terminated? Ought to be, if done right. Can VMS use null terminated strings? Absolutely.

      Which is "better"? Depends on what's important to you: e.g. out of the box UNIX source compatibility, or the chance to write relatively robust applications relatively easily (e.g. no buffer overflows here, if done right; the data structures and runtime library do the checking for you, all you have to do is use them right).

      That is obviously a trivial example, just to illustrate that "different" does not immediately mean "worse".

      1. MacroRodent

        Re: Legacy only

        Perhaps you did not notice the "now" in my the trouble is it is too different from the mainstream now. Yes, I am old enough to remember when VMS was mainstream. In fact I had some experience of using and programming on it (and TOPS-20) before I first encountered UNIX. At the time the features in VMS were not unusual, other minicomputer operating systems had similar style. But now OS'es have converged on somewhat "unixy" solutions, so it is VMS that is the odd man out. And this makes supporting it alongside other systems a pain.

        Some examples of what I mean include the baroque file name syntax "drive:[dir1.dir2]filename.ext;version" (with some users preferring <> instead of [] delimiters so you must be prepared for either), and file types, so for example text files are commonly represented in several ways and the C library did not completely hide the distinction (try fwriting or seeking a variable-length record text file). Lots of pitfalls that have wasted my time over the years. Yes, I do know VMS pretty well, and that is why I don't like it!

        1. Anonymous Coward
          Anonymous Coward

          Re: Legacy only

          "the baroque file name syntax "drive:[dir1.dir2]filename.ext;version" (with some users preferring <> instead of [] delimiters so you must be prepared for either)"

          Yes it's baroque. Partitions and drive letters aren't? Anyway VMS's restricted and "unique" filespecs were one of the reasons VMS's ODS5 file system arrived some considerable number of years (and VMS versions) ago - to allow VMS to support the kind of filenames that lots of applications (and users) expected.

          Applications don't HAVE to understand [] and <> as part of filespecs anyway; if applications want to parse that kind of filespec the recommendation has always been to call the VMS-provided routines which do the parsing for you - from a command language script there's f$parse(), and from a real application there's sys$parse. If someone still wants to write their own parser rather than use one supplied by the vendor, then <> vs [] needs to be part of the task, because it's part of the specification.

          You've obviously made your mind up after a painful set of experiences. Sorry about that.

        2. Dirk Munk

          Re: Legacy only

          You didn't get the 'baroque" file name system correct, it is node::drive:[dir1.dir2]filename.ext;version#.

          VMS has networking incorporated in the OS, an application can simply open a file on any other VMS system, or system that has DECnet loaded. For the application it is just like a local file, it isn't even aware that the file is on another computer at the other side of the world. And before you complain, DECnet can use IP as transport stack. And those 32000 versions are grate too, You can have 32000 files with the same name and extension, just the version number differs.

        3. Primus Secundus Tertius

          Re: Legacy only

          @macrorodent re file types

          Yes, the file types distinguished the men from the boys in VMS (and RSX11) programming.

          1. The major distinction between serial, sequential, and indexed files.

          2. Within serial files, the distinction between

          a. first byte is a counter of those remaining in that record.

          b. first two bytes represent a line number. This could increment by more than 1, eg for Basic line numbering, and later lines could be inserted or deleted.

          c. CRLF files, where embedded CRLF characters are line separators.

          3. Then they had various magentiic tape formats: FLX, something they said was ISO, and finally their VMS Backup formats.

          I saw many mistakes made by novice programmers unfamiliar with those file types.

          In unix, of course, a file is a blank sheet to be defiled at will.

    2. Warm Braw

      Re: Legacy only

      Actually, VMS is a lot easier to code for in many respects as it does a lot of things "right" (especially for anything asynchronous...) that various varieties of Unix get horribly wrong. However, if you're looking for something that replicates a typical Unix C programming environment, look elsewhere. The reason VMS survives is precisely because it isn't Unix (or Windows).

      I'd be interested to get a peek at the source code again some time to see how much (if any) of my code might make it to the brave new world of x86. Given that the last time I browsed the source code it was still distributed on microfiche, it's probably not much!

    3. Stoneshop

      Re: Legacy only

      VMS is a solid system but the trouble is it is too different from the mainstream now, so it is a lot of extra work if you want code that runs on it and also on Windows and *nix.

      Why would one want that? VMS may be niche now, but if your requirements fit that niche, it's better to fully use its features instead of aiming for some compatibility with *nix, let alone Windows.

      And there's one area where VMS is still miles ahead of any other OS: clustering. It's been part of the OS for three decades, not some relatively recent development that's been bolted on, as Linux has (in various flavours, neither of which fully covers the VMS cluster feature set)

    4. VMS bigot

      Re: Legacy only

      "Legacy", good stuff that works ....

      Yeah, I borrowed that.

      VMS was never dead, even though HP tried to drive a wooden stake through it's heart. Now, perhaps, it will continue, and when people look for "good stuff", perhaps it will grow. Even if it doesn't grow much, there are still those who count on it, and won't count on anything else.

      As for portable code? Who wants it? When you can use the best, why would you settle for less?

      As for the OpenSSL stuff, I've heard VMS people say that it might be good to get all the old cruft out, and then re-do OpenSSL to include VMS support. Today, that just might not include too many differences.

  6. Hans 1

    VSI will buy HP by 2025

    Invigorate life into this thing, bring the price down to a reasonable level, and you sell it like hotcakes, as long as you keep it stable.

    I do not know VMS very well, shit, I just know how to navigate the file system to inspect/remove some log files - never had to learn more since the beast has been doing its job since I started at the company, we have upgraded the OS and Oracle a few times, but that is about it.

    The help system is 'very' good, from what I remember.

  7. ElReg!comments!Pierre

    Ooooh yeah

    Good good good.

    I'm a bit torn on one point though: an ARM port. On one hand I'd love to have an OpenVMS SD card to slot in my Pi; on the other hand a VMS server kinda has to be heavy, that's part of the package. Or perhaps I could build a tungsten case for my Pi.

    1. Anonymous Coward
      Anonymous Coward

      Re: Ooooh yeah

      " I'd love to have an OpenVMS SD card to slot in my Pi"

      Pi runs Linux.

      SIMH runs on Linux.

      VAX runs inside SIMH.

      VMS runs on VAX.

      Therefore, VMS runs on Pi.

      Lots of folk have tried it, many have blogged etc about it, at least one writeup out there about clustered VMS/Pi system (2012, all software needed was/is zero cost for hobbyist use):

      http://www.rs-online.com/designspark/electronics/blog/a-raspberry-pi-vax-cluster

      1. Tore Sinding Bekkedal

        Re: Ooooh yeah

        At a VMS Boot Camp a few years ago, I got a few laughs by running simh/VMS on my mobile phone. People could telnet in and everything.

        1. Anonymous Coward
          Anonymous Coward

          Re: Ooooh yeah

          "I got a few laughs by running simh/VMS on my mobile phone"

          And before that, people had run SIMH, and hence VAX/VMS, on PDAs such as the Compaq iPAQ (remember them?)

          The VSI people have a twitter account, @VMSsoftware (?), whatever one of those is.

          They have this morning confirmed that the VMS Hobbyist program lives on, and will likely be extended.

          https://twitter.com/VMSSoftware/status/

          It'd be a laugh if VMS for ARM64 (not that I'm sure it makes sense commercially) was pioneered on Hobbyist Ts+Cs.

      2. ElReg!comments!Pierre

        Re: Ooooh yeah

        Not quite the same, but cool link thx.

        Since my old laptop died (last month) one of my Pis is my main desktop, which revived my enthusiasm for fiddling with the lil' guys (which over the years had turned into XBMC media centers only). So I think I'll try this. But I only have one spare at the moment, so I can't try the "cluster" part. Oh noes I'll have to buy yet another one!

    2. VMS bigot

      Re: Ooooh yeah

      VMS may not be as "heavy" as you think. I do believe it's "lighter" than weendoze, not sure if that matters. Keep in mind that while it has support for many devices, you need only the devices present in the system on which you're running.

      The other side of that is, VMS is great as a server. (Today's terminology, perhaps not accurate.) At this time it is not so good as a user interface. Would you be using that Pi as a user interface, or for controlling a steel rolling mill?

  8. Robert E A Harvey

    Metaphor

    re-vitalised VMS on modern hardware would be rather like hving a steam-hauled train go through the channel tunnel.

    It's something I would love to see.

    1. Dirk Munk

      Re: Metaphor

      When VMS was ported from VAX to Alpha, the engineers envisioned that in the future another port could be necessary, so they rewrote VMS in such a way that it is relatively easy to port. When VMS was ported to Itanium, and that moment was defined as 'we can boot the system and do a DIR', it only took six months to port all the layered products and send third party software developers CDs with the operating system plus the layered products. Can you tell me which other OS was ported twice to an other processor architecture?

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like