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 …

  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?

      1. Peter Gathercole Silver badge

        Re: Metaphor

        Ummm, off the top of my head.

        UNIX.

        Linux.

        Solaris.

        MacOS/OSX.

        Windows.

        BeOS (may be stretching things here)

        VxWorks.

        It's more common that you might think.

        1. Anonymous Coward
          Anonymous Coward

          Re: Metaphor

          You could also have added HP's very own (and formerly Tandem's very own) NonStop OS whose official name I forget. When it was finally admitted that Itanium had died (when HP realised how much they were paying to Intel?), HP quickly committed to ongoing support for this product, and to it being duly made available on x86.

          HP seem to have finally realised that there's a potential market for doing the same with VMS, and also that if HP were to make such an announcement themselves, their credibility in the VMS market would be basically nil. So they've got some people with some VMS credibility to deliver it for them. Win-win?

          1. mamavms

            New release of VMS

            Dear Group,

            This is Sue Skonetski previously from DEC/CPQ/HP and now part of VMS Software Inc. The very proud home of OpenVMS. In case folks are not aware we released VMS v8.4-1h1 in June (early delivery). If you want to look at the roadmap on our website you will notice that we are working on a new port in addition to continued development on the integrity servers. vmssoftware.com if you have any questions just let me know.

            Sue

        2. Stoneshop

          Re: Metaphor

          MacOS/OSX.

          MacOS went from 68k to Power, and OSX went from Power to X86, but the only thing OSX and MacOS share is that they're written by Apple (plus maybe a few minor bits, and OSX borrowing heavily from FreeBSD), so close, but no cigar there.

          Windows.

          That would be NT only, and while it was ported from x86 to PPC and Alpha, those were parallel ports, not serial, like VMS (VAX->Alpha->IA64).

          Linux

          Again, originated on x86, ported to several architectures, but they're all one port away from the original.

          1. Chris King

            Re: Metaphor

            "That would be NT only, and while it was ported from x86 to PPC and Alpha, those were parallel ports, not serial, like VMS (VAX->Alpha->IA64)."

            VMS wasn't ported serially. VAX and Alpha overlapped (with "functional equivalence") from 6.1 to 7.3, Alpha and Itanium were built from a common code base starting from 8.0, with 8.2 being the first stable Itanium release.

            I'm guessing that 8.4 will be the final Alpha release, unless HP have something waiting in the wings.

            1. Anonymous Coward
              Anonymous Coward

              Re: Metaphor

              "VMS wasn't ported serially."

              The timeline was indeed parallel as you say (I forget the exact details), but the sequence of porting was indeed serial.

              The Alpha code started from the VAX code, and included a great many changes to remove dependencies on VAX-specific stuff, and to acknowledge that there was a new world which was sometimes wider than 32 bits, whilst continuing to maintain the traditional compatibility which the VMS world had come to expect.

              The Itanic code didn't start from the VAX code, it started from the Alpha code, because the Alpha code already had much processor-independence, and already had much 64bitness.

              I'm thinking that's what the "serial porting" reference meant. ICBW.

              1. Stoneshop

                Re: Metaphor

                I'm thinking that's what the "serial porting" reference meant. ICBW.

                "zacktley.

          2. Dirk Munk

            Re: Metaphor

            Actually 64 bit Windows was developed on Alpha workstations, since at that time there were no 64 bit x86 cpus.

            1. Anonymous Coward
              Anonymous Coward

              Re: Metaphor

              "there were no 64 bit x86 cpus."

              And at that time, the folks at Intel were still telling the world outside that 64bit x86 would actually be impossible, and therefore Intel were developing something radically different that would become "industry standard" for the world of 64bit computing.

              Thank you AMD for saving the world from IA64.

              No thanks at all to the people in HP HQ (and predecessors) for believing the IA64 hype and wasting so much of so many people's time and money on a white elephant - a huge on-chip cache with a weird VLIW processor attached.

              HP's long overdue decision to farm out VMS to people with a clue hints that maybe there are now a few people with a clue in HP HQ.

          3. Peter Gathercole Silver badge

            Re: Metaphor @Stopeshop

            The original question was "Can you tell me which other OS was ported twice to an other processor architecture?"

            It said nothing about serial ports.

            I admit I got it wrong about MacOS. Maybe I should have said NeXTstep(68000)->OSX(powerpc)->OSX(x86-64)!

            I think that if you look at the myriad of Linux ports out there, you will find one that is not one port away from x86 anyway.

            And I know there are a lot of UNIX ports out there, but how about AIX(ROMP)->AIX(POWER)->AIX(IA64 - although did not last long), and along the way there were s370 and x86 ports as well.

  9. James 100

    "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."

    Internally, the Windows NT kernel does much the same - there's a UNICODE_STRING structure, containing a pointer to a string, the length of the string and the size of buffer it's contained in. You can do interesting things there, including embedded NULLs inside filenames - giving a file which can't then be accessed or deleted using the regular Windows APIs, which use C-style null-terminated strings. Not entirely surprising, given where the original NT team came from...

  10. Canecutter

    While I'm hopeful, I am not holding my breath.

    I really haven't seen anything in the cited information to indicate to me that VMS has a solid future. In particular, I don't see anything that suggests VMS will be safe from an eventual M&A&K (merge and acquire, then kill).

    HP still retains all rights to VMS. VSI does not appear to be particularly robust against a possible takeover attempt by a company like Oracle who will waste no time killing it off. The stubborn refusal of the owners of OpenVMS to either popularise or open-source the operating system only serves to make it more likely that should something bad happen, the users will be forced to look for another operating system.

    I'll believe it when I see it.

  11. Lapun Mankimasta

    What I would like to see

    I would like to see HP release the VAX VMS source trees under the GPL v3 for several reasons, the first and foremost being one of making some sort of sense out of the massive threat posed to world IT by patent trolls in the US and the US govt's insane wish to infect other countries with the software patent legal malware. The second one of course is it would be nice to read the VAX VMS source trees to see where DEC's programmers got it right, without the threat of legal action if, heaven forbid, one decides to adopt best practices in the raw, and use the same or similar algorithms. The third is of course it would make running the VAX VMS hobbyist licenses so much easier on SIMH and the like - you would be released from the onerous necessity of applying for a yearly license and the hobbyist organization would be freed from the onerous necessity of maintaining records on their fellow hobbyists.

    (Of course, to really extinguish the software patents legal malware one would need to get Microsoft (Windows NT aka VMS under Microsoft and MS OS/2) and IBM (IBM OS/2) to do the same with their segments of the unholy mess that came from the IBM/MS OS/2 which then turned into MS WinNT through VAX VMS with Cutler midwifing, and IBM OS/2 with the breakup between IBM and MS. But one can dream.)

    1. Anonymous Coward
      Anonymous Coward

      Re: What I would like to see

      "it would be nice to read the VAX VMS source trees to see where DEC's programmers got it right, without the threat of legal action"

      You can readily find many of the *principles*, if not all of the implementation details, from the VMS documentation, both as supplied with VMS iself and as available separately.

      For example, there were courses on VMS Internals and Data Structures. Books too. Mentioned earlier in the thread, some of the older books are now freely downloadable from archive.org, bitsavers, etc.

      If you really want "the VMS source", the listings used to be available (originally on microfiche). A fiche set turned up on the ClassicCMP mailing list earlier this year, they are probably elsewhere too, for not very much money. Note that the listings are *not* the complete source, and even if they were, there were pieces missing that stopped outsiders building a complete VMS from scratch (build tools etc).

      Have a lot of fun.

  12. Anonymous Coward
    Anonymous Coward

    To x86 And Beyond!

    Some bloke called Tim Prickett Morgan has a reasonably detailed article at

    http://www.enterprisetech.com/2014/08/01/upstart-breathe-new-life-venerable-openvms/

    which may interest those reading/writing comments here.

  13. mamavms

    VMS Software Inc.

    Dear Register readers,

    Thank you for all your comments. I don't know if folks remember me from the OpenVMS engineering group at DEC, Compaq and HP and now VMS Software Inc. I just wanted to let you know that in addition to the web site there is also a face boot, twitter and Linkedin group. And of course if there is anything we can do to help you please just let us know.

    Warm Regards,

    Sue

    1. Stoneshop

      Re: VMS Software Inc.

      I don't know if folks remember me

      Sure, though we never met in person.

  14. mamavms

    What is a sad day for a VMS system mgr?

    I received an email from a customer who had taken a day off from work (names changed to protect the guilty) . As you know most VMS folks try to keep their VMS systems up for as long as possible. His environment had been up for 18 year 5 months and some odd days. However on vacation day a non VMS person whom we shall call "Mr. I can use a mouse and text on a phone hence I am a computer genius" bought the environment down. Our friend comes back to day one. I can only imagine the words that were spoken. While this is not the longest uptime, it is certainly an honorable mention.

    sue

    1. hammondreg48

      Re: What is a sad day for a VMS system mgr?

      I also remember a guy out in Iceland (or somewhere else quite cold) whom I met whilst teaching a Macro-11 course whose PDP-11 running RSX had been up and running for over a decade. He was asking me questions about startup and shutdown 'cos he'd never done either in living memory! Makes Microshit 'operating systems' look like the rubbish they are ...

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