eCube Systems Interviews VSI’s Brett Cameron on OpenVMS, Open Source and Developer tools


eCube Systems is interviewing Brett Cameron, Director of Applications & Open Source Services at VMS Software, Inc.  Brett holds a doctorate in Chemical Physics from University of Canterbury and was a long time employee of Hewlett Packard Corporation where he held various positions for 19 years and most recently a Senior Architect in the Cloud Services group. Brett is well known in the OpenVMS community and has made a hobby of porting Open Source tools to OpenVMS, including AMQP, RabbitMQ and Erlang.

eCube: Thanks for giving us some of your valuable time for this interview. You have been developing on OpenVMS for a long time and are the go-to guy when people want high performance and customized software on OpenVMS. There are so many things you have worked on in OpenVMS, so there is a lot of ground to cover. What is your favorite thing to work on?

Answer: The tough questions first! In terms of your comment about me having so many interests, this has always been a problem! I will be working on one thing and will then see something else that looks interesting, and before you know it I’m pushed for time to complete whatever it is that I should be doing in the first place. Maybe there’s some support group I can join. Probably for as long as I have been involved with software development (dating back to the late 1980’s) I have had a keen interest in Open Source software and the potential it provides, and I can recall installing early versions of Linux from some 20 3.5” floppy disks, and if you messed up something on the last disk it was back to square one. Fun times. Even around this time (early 1990’s) I can recall porting small pieces of Open Source code to OpenVMS, initially to help with aspects of my PhD research, and subsequently for customer-related projects when I started work in 1992 with Digital Equipment Corporation as a FORTRAN programmer (who also happened to know a bit of C and Pascal).

But probably my favorite thing to work on would be integration – helping customers to integrate their “legacy” OpenVMS systems with other systems. I don’t know why, but I have always enjoyed playing around with integration software and crafting novel integration solutions. Many organizations seem to think that their old OpenVMS systems are some sort of black box that is unable to communicate with the rest of the world. Possibly they have lost the skills to do this sort of work, or maybe they simply do not know what is possible; however the simple fact of the matter is that there are a myriad of good integration options available to OpenVMS users, and it is invariably possible to craft a good integration solution that will allow them to integrate their trusted OpenVMS-based application environment with the wider computing ecosystem, and more often than not it is possible to do this using Open Source technologies, particularly these days, with more high-quality Open Source solutions being available.

I would also add to this that I enjoy working closely with customers as opposed to always working away in a back room somewhere. Our business is a symbiotic relationship with our customers, and interacting directly with customers is an important part of that relationship. Aside from the work aspect, I enjoy meeting new people and making new friends, and it is often fascinating to learn about the customers’ business – you kind of learn how bits of the world work.

eCube:  Yes, that is something we both share. As you may know from our previous interviews with Sue Skonetski and Eddie Orcutt of VSI, we are trying to get all the perspectives on the future of OpenVMS, now that VSI has taken charge. Can you tell me about the things you have been asked to do? What are you working on and what progress you are seeing?  

Answer:  My main focus is around Open Source, figuring out what Open Source products would be good to have on OpenVMS and figuring out how to get them there, which may involve us doing the work, or possibly working in conjunction with the community. There has been a lot of good work done over the years around Open Source on OpenVMS, and we want to expand on that. From my perspective, whatever we do needs to be relevant to our customers. I suppose that is in some ways an obvious statement; however finding out exactly what is relevant and determining where we are going to expend our energy is not necessarily straightforward, and this comes back to my comments in the previous question about working closely with customers and partners.

Since taking over OpenVMS so to speak, we have obviously had to spend a good deal of time doing somewhat tedious things such as re-branding, getting environments and processes and procedures set up, and so on; however we are largely through this now and going forward it will definitely be all about innovation, adding new features, creating new products, making significant enhancements, and so forth. Clearly the x86 port is of highest priority; however there is plenty more going on across the board, including the new TCP/IP stack, Java 8, and various other significant projects.

Personally, since around late March this year (2016) I have been largely focused on the Java 8 port. Thankfully I have had Camiel helping me, and I am pleased to say that we are just about across the line with this project. I will not bore you with the statistics, but let’s just say that it has been a significant piece of work and while we have certainly had plenty of challenges, things are looking good. I should note that this work has been done in collaboration with HPE, and certainly it would not have been possible without their assistance.

Piggy backing off the Java 8 work we are looking at upgrading some of the Java-based products and potentially introducing a few new ones. For example, we have beta kits for Scala (a popular functional language that uses the JVM) and Maven (a powerful build tool for Java projects).

In addition to the Java work, I’ve been working on various other projects, including the new version of CSWS (Apache), a new Ruby port with a pile of interesting extensions, a new version of PHP, and various other such projects. We also have a partial git implementation and a reasonably functional Subversion client, although both of these items need further work. I’ve also managed to fit in a bit of consulting here and there, so all up it has been a busy year, and I don’t think things will be much different next year!

eCube:  Since you are the first VSI person we have spoken to with a focus on developers, and VSI has said that the future of OpenVMS depends on the developers, what do you think it take to get developers on OpenVMS ready for the future?

Answer:  There’s no short answer to that question, I suppose in part because everyone’s needs are somewhat different. However, if I am to look at things from the perspective of getting new or younger developers onto OpenVMS, clearly we need to be able to provide the sorts of environments and tools that they are used to using on other platforms. For example, further enhancing GNV will make it easier for developers familiar with Linux to work on OpenVMS, and providing powerful IDE’s such Eclipse is also vitally important, as indeed are more Open Source solutions, and the ability to hook into facilities such as GitHub and continuous integration tools such as Jenkins.

To some degree, modern developers don’t much care what the underlying operating system is, so long as they have the tools to do their job and those tools work well. While we do have available some good tools in this space (such as your NXTware Remote and Eclipse-based IDE), there is still a lot that needs to be done.

I should also add that in parallel we need to continue to support and enhance existing toolsets, as these are critical to many of our customers. One big item that comes to mind here would be bringing the C++ compiler up to current standards.

eCube:  We have heard a few comments on the OpenVMS events like the Technical Update Days and the Bootcamp have the primary focus on hardware and operating systems topics. Developers say they don’t want to attend because there is no focus on developer issues. Is this a fair assessment? If not, what can be done to change this perception? If so, will VSI change its focus to a more developer oriented event? Are there any plans to change?

Answer:  I am not so sure that this is an entirely fair assessment. Certainly some of the material presented at these events would not be of much interest to developers (it’s not of much interest to me J); however I would like to think that at Boot Camp in particular there should be more than enough of interest to everybody (the committee do a great job of selecting a nice balance of presentations). But I do appreciate the problem. As to what can be done to address this matter, I am not sure. I think it can also be that developers will sometimes simply miss out on getting to attend these events, which is one thing. Another thing is that there is a lot of diversity to consider here, and what might be highly relevant to developers from one organization may be of absolutely no relevance to developers from another organization. I have done many talks over the years around reasonably general topics such as web services and integration, and possibly we could look to expand on this, but it is not really possible to go into much detail at a conference. If developers are interested in a particular topic, we could certainly see about facilitating custom workshops or training sessions. Another thing that comes to mind might be to organize a larger number of smaller events. Such events do not necessarily need to be formal events organized by VSI; they could just be meetups arranged by OpenVMS users to share their experiences with others (standard meetup practice being to provide pizza and beer). It would be great if we (VSI) could get along to all such events, but practically this could be a challenge; however I’ve been to meetups where speakers will call in via Skype, Hangouts, or whatever. Webinars are another possibility. A few years back my good friend John Apps and I did a series of OpenVMS development-related webinars that were well-received, and feedback from these sorts of events can be used to better guide future activities. We did the talks at two different times to cover most time zones; it worked very well, although I didn’t much enjoy getting out of bed at 2am or 3am in the middle of winter!

eCube:  Well, I just figured you never slept very much! Continuing with development topics, the programming language support on OpenVMS is one of its strengths, because it supports so many different languages. You mentioned your work on Java 8 – it is expected to have current version support on OpenVMS in Q1 2017. Is that on schedule? How important do you think this is and where do you see new Java ports in the priority list for VSI?

Answer:  I’ve talked a little about the Java 8 port already. This has been (still is) a major project, and we are generally very happy with how it has gone.  As of this moment we are coming to the end of a two month field test, and we have been very pleased with the results: bugs were found (and fixed), and testing coverage has been comprehensive. The intention is to release in Q1 2017, and this is looking achievable (there certainly should be no technical impediments).

Java is clearly an important language, and we are factoring future Java ports into our planning. We will for example need to repeat the Java 8 port for x86, and will also need to start looking at Java 9 I suppose. It is also important to appreciate that there are now quite some number of other languages that use the JVM (Java Virtual Machine). I mentioned Scala previously, and Clojure would be another one that comes to mind. With Java 8 we are able to better support some of these other languages, which gives developers more options on OpenVMS, and makes it possible to port Open Source projects written in such languages across to OpenVMS (often without too much difficulty).

However, there are a number of other new languages that we also need to think about. For example, languages such as Rust and Google’s Go language are becoming more popular and widely used, and it would be great to have these available on OpenVMS. Interestingly these languages leverage the Open Source LLVM compiler backend, which we are porting to OpenVMS as part of the x86 work, so in theory it would be possible to do something with these other languages; however this would not be a small job and it is just an idea at this stage.

Scripting languages such as Ruby, Lua, and Python are also very important. I mentioned previously that we have a new Ruby port available, and we are actively considering exactly what else we want to do in this space. We also have a version of Lua available. Something like Node.js would also be nice; however this is another thing that we might want to hold off on until OpenVMS is up and running on x86 (for various reasons). I have also talked a lot about Erlang in the past, and we might look to formalize some of this work. As things stand we have a couple of working ports of slightly older versions of Erlang; however I would like to see us have available a more current release. The older versions are reasonably stable and functional; however there are one or two limitations that I’d like address before I would consider them to be fit for use in a production environment.

eCube: What are the development features of OpenVMS that make it a good operating system for developers? How important are tools like SCA and PCA for developers these tools are absent from newer OSes like Linux. What can be done to attract young developers to the virtues of OpenVMS development?  

Answer:  All operating systems have their good and bad points. OpenVMS was designed by engineers for engineers, and this resulted in good 3GL language support, a very comprehensive set of library functions and system services, and various developer tools such as those you’ve mentioned that all work together seamlessly. Most OpenVMS developers are familiar with the RTL LIB$ routines; however there are a whole load of other useful routines in the RTL, many of which (such as the parallel processing PPL library) seem to have been somewhat forgotten about. Other operating systems also have such functionality, although it may be a separate library that needs to be installed, as opposed to something that comes bundled with the operating system. The key point is that OpenVMS was designed with all of these sorts of things in mind, as opposed to evolving (in a somewhat ad-hoc fashion) to accommodate them, and accordingly things seem (to me anyway) somewhat more logical on OpenVMS – it’s like it all goes together logically, because it does – it was designed that way.

But getting back to your question about what can be done to draw attention to the virtues of OpenVMS development, I am really not sure. I don’t think that you are ever going to convince a staunch Linux developer or a staunch Windows developer that OpenVMS has better facilities; it is simply an argument that (most of the time) you are not going to win; people like what they like, and you’re just not going to shift them; you start entering religious war territory. Obviously some people will be more open to the matter than others, but in general I think this is probably the wrong approach (initially at least). I suppose that ultimately it comes back to the comment I made previously about ensuring that we have the sorts of tools available on OpenVMS that “modern” developers are used to using on other platforms (irrespective of the relative merits of such tools), and ensuring that those tools work well. Once people are using the platform, it is easier to have a discussion with them about all of this other goodness.

The other side of things I suppose is giving existing OpenVMS developers more that they can use; there is a lot that we can do with the existing development stack, both ourselves and working with partners.

eCube:  I agree; unless you can offer them something they can’t get elsewhere. Moving on, there are a lot of new technologies that have developed since the 70’s and 80’s, like 4GLs, client/server architecture, object oriented languages and web-services. How is OpenVMS adapting to these technologies?

Answer:  I’m not sure that there’s a short or easy answer to that question. If we go back in time, I think it could be argued that for a period (maybe the mid to late 80’s and possibly into the early 90’s) OpenVMS was easily at the forefront of operating system technology, and it was one of the first platforms that the sorts of technologies you refer to were made available on. Times change and large corporations do strange things; new trendy looking kids arrive on the block; fashion changes. However, through all of this change and in spite of going through two major acquisitions (Compaq and HP), OpenVMS has in one way or another for the most part managed to adapt to these changes in fashion. It is possibly only in the last decade where things have slipped somewhat; however this is a recoverable situation, and we are working on making that recovery happen, with help and support from the community.

If I wanted to cite a few examples relating to your original question, I have fond memories of implementing DCE-based client-server solutions for several customers back in the mid 1990’s. At that time DEC had the best DCE implementation, and for that matter OpenVMS arguably also had the best CORBA implementation. CORBA is still in fairly common usage, but to some extent neither CORBA nor DCE ever really achieved their perceived potential and lost out to the next wave of fashion, which for the most part centered around web-based applications and leveraging HTTP in all manner of strange ways, leading up to the advent of web services and the myriad of web services standards surrounding them. Implementing web services-based solutions on OpenVMS is not particularly problematical and several good solutions exist; however one common problem that I have encountered many times is that OpenVMS users will have business-critical applications written in languages other than C or Java that they do not necessarily know how to integrate with the likes of C and Java, and this will often be an impediment to progress, or will result in some quite fascinating (and unnecessarily complicated, and often very brittle) workaround solutions.

I am not sure that I’ve adequately answered the question, but I think the bottom line is that to some degree OpenVMS has managed to adapt to changes in fashion and it’s our job to accelerate this.

 eCube: I want to keep this focused on software development, but there is an important aspect that hardware plays in the future. What do you see as the major change which will occur when OpenVMS is supported on the X86/64 platform?

Answer:  I suppose the obvious answer is that we’ll be able to run OpenVMS on a much wider range of hardware! Somewhat less obvious perhaps is that it also opens up the potential to more readily port some interesting Open Source products to OpenVMS. For example, I mentioned previously how languages such as Rust and Go leverage LLVM. I think that I also mentioned how the V8 JavaScript engine used by Node.js makes extensive use of just in time compilation (JIT) in pretty much the same way as Java does. Implementing a just in time compiler for V8 on Itanium would not be a trivial exercise; however x86 is supported. In short, I think it is fair to say that x86 provides more options and opens up an interesting array of opportunities to bring some new technologies to the OpenVMS platform. It will also make us start thinking about a few things. For example, people running OpenVMS on their x86 laptops are probably going to want a decent GUI, and we therefore need to look at improving the current state of play in this space.

Virtualization is probably also going to be a big one, and I can see many OpenVMS users being interested in the notion of running OpenVMS as a guest operating system in their corporate clouds. This in turn could have some interesting ramifications from a licensing perspective, and there are a few other things that we will need to consider, such as how to deal with shared storage and how OpenVMS might need to interact with core cloud services such as provisioning, and so forth.

eCube: You have been involved with Open Source tools for many years. What are the most important tools in your mind?

Answer:  It really depends on the problem that you are trying to solve. For example, we’ve talked a lot about integration and some of the Open Source integration technologies and programming languages that I have used and hold in considerable regard. If I was to look at it from a software development perspective, I would probably say that two little tools I have used successfully time and time again on multi-million dollar projects would be flex and bison (essentially lex and yacc). I have used these tools to create grammars for custom RPC-style middleware solutions, and I have used them to develop parsers for language conversion projects. I would not claim to be an expert with these things by any means, but all of the projects in question were successful (and quite a lot of fun).

eCube: What about modernization tools? Do you use a modern IDE when you develop? Does that help OpenVMS grow in the future?

Answer: I fully appreciate the benefits of a modern IDE, and I believe that a modern IDE is essential for software development on OpenVMS, particularly if we want to attract younger developers, who have grown up with such things. Aside from just looking nice, IDE’s provide many other features that are expected (taken for granted) by younger developers, such as integration with source code control systems, integrated debugging facilities, hooks into continuous integration tools, unit testing facilities, and so forth. Seamless cross-platform development is also anything key aspect here.

eCube: What are the obstacles that VMS Software faces down the road and how can that be resolved?

Answer: It is always difficult to say what the future might hold, but there are certainly several things that we need to be cognizant of and put in place strategies to address. As is well known, the OpenVMS business prior to the advent of VSI had for various reasons been in steady decline, with users moving to alternative platforms and so forth. Some of the reasons for this were not necessarily related to anything that HP or Compaq or DEC had or had not done, but where down things like corporate initiatives to standardize (or try to standardize) on a particular and more widely used operating environment. In some cases skills had been lost, effectively forcing the need for change. In some cases OpenVMS with its reliability and stability just ended up being its own worst enemy! From a VSI perspective, it is important not only to look after the needs of existing loyal OpenVMS users but also to put in place mechanisms that will ideally see increased use of the operating system, and there are many ways by which this may be achieved, including training, marketing, introduction of new technologies (as discussed previously), and so on. It may also entail working with partners to develop specific solutions in which the OpenVMS system is essentially an appliance. It should be noted that looking after existing OpenVMS users also entails many of these same activities. We are providing either directly or in conjunction with partners a range of consulting services, which extend to include the likes of hosting and application maintenance and support services.

 eCube: What do you think is the key for OpenVMS for the future?

Answer: I think that I’ve covered most of this in my answers to some of the previous questions, but in general terms I believe it comes down to a few things. Looking after existing OpenVMS users is paramount, and this does not mean preserving the status quo; it means enhancing the operating system and layered products; introducing new technologies; providing training; regular information-sharing events; providing a range of services; and so on. We need to listen to our customers and continue to provide them with quality products and services. We also need to make the platform more appealing and relevant to a wider audience. With the plans we have and the team that we have in place, I am sure we are in good shape with all of these things.

As our web site says, all we do is OpenVMS, and the bottom line is that the operating system is now receiving more attention from an engineering perspective than it has for quite some considerable time. We will continue to advance the operating system, enhancing existing features, adding new features, provide support for new software technologies, and potentially port it to other architectures (not only x86). There’s no value in thinking small here, as if you think small you only ever achieve small. We have an opportunity to do big things with OpenVMS, and this is likely to involve taking it to places that might previously not have been even considered. We’re a crazy bunch!

You might want to talk to our CEO Duane Harris about the plans VSI has for the future. He can tell you that our goal is return OpenVMS to prominence as a leading operating system platform.


Leave a Reply