How NXTware Remote helps managers extend the life of their OpenVMS systems

OpenVMS is a very robust Operating system and many OpenVMS users have an application which runs so well on this platform that it is difficult to replace. Accordingly, most managers realize they need to extend the life of the application on this platform because it provides so much value to the company. Paramount to its long term survival is making it easier to modify and maintain, which is one of their biggest needs.

The Common Challenge:
How do you maintain and improve a legacy application when the operating system expertise upon which it is based is disappearing?

The solution:
You solve this by getting “fresh blood” developing on your application and by leveraging environments with which they are familiar.

This can be done by using an Open Source based IDE which can be modified to support your legacy OS infrastructure and the 3GL languages they are written in. With the right tool you can extend the life of the application and ensure it is properly maintained for the future.

  • Enterprise IDEs like NXTware Remote are developed for this need with Eclipse support on legacy systems in a distributed development environment.
  • Integrated tools like source library management, code assist and code templates makes it easier to adapt to a new environment.
  • NXTware Remote leverages a distributed integrated development system for OpenVMS and linux and it solves the problem for managers who can’t find OpenVMS developers for the projects they have.

Time is always an issue and one of the biggest challenges development managers have on mainframes like OpenVMS is finding the expertise in the marketplace to implement on-going development now.

  • Market changes are happening at an increased rate, so changes in your mainframe applications need to address those changes in order to remain relevant.
  • In addition to a need to augment your staff, managers have to worry about eventually replacing their existing staff who are getting older and closer to retirement with quality, trained developers.
  • What managers need are younger, agile developers who can work in SCRUMs and familiar with the latest IDEs that run on Windows, MacOS or linux computers. That expertise is readily available and at competitive prices.
  • For OpenVMS developers, that knowledge and experience is hard to find these days since it is not taught at universities and there are not many in IT that want to learn a legacy system using green screens and line editors.

So in many cases these projects are delayed because the in-house developers just don’t have the bandwidth to keep up with the changes that are being demanded by the user community. Several dynamics tend to happen:

  • The developers you can find to join your team, find it hard to learn enough to help the existing staff (infrastructure training only slows the project down – if you had the time to train them).
  • For legacy applications written in 3GL languages like COBOL, Basic, Fortran, Pascal and C, there are a limited number of consultants or developers available who know OpenVMS and those languages as well.
  • Those that do have that skill set may be very expensive, unwilling to adopt to your infrastructure or unwilling to relocate. Most of the established developers are already working for other companies, making it harder still to recruit the talent you need.

Your best option is to recruit College level 4GL programmers with no OpenVMS experience and teach them how to develop on OpenVMS with NXTware Remote. By minimizing the new interfaces developers have to learn to start developing on the mainframe, you can abstract the OS dependencies so that file editing, compiling, testing and debugging on a mainframe are as familiar as doing it on the workstation.

This is the NXTware Remote solution and we can show how this reduces the time to learn development on a new OS. That is the subject of our next blog.

Intelligent Infrastructure for DevOps: Using a GUI to manage and monitor instead of scripts

Application Performance Management tools have been around in one form or another for many years, mostly operating anonymously and unnoticed. While most of these tools were home grown, there were a few vendors who supplied generic APM tools. These tools addressed application infrastructure needs in the background and were not considered a strategic part of IT; they kept applications running with a series of scripts developed by the architects of the applications. Since this software is neither development nor operations specific, they were often not claimed by either department. Until DevOps became a buzz word, they operated under overhead accounts or were assigned to different departments in spite of the job that they did. However, since Agile Development has become mainstream, the need for an intelligent infrastructure and the unification between Development and Operations (DevOps) has refocused attention on APM tools. Agile infrastructure is now a necessity to ensure the rapid and accurate deployment of newly developed applications as fast as the Agile Development tools that were used to implement the new business logic. For years companies have developed their own script based infrastructure and due to internal changes it has evolved into obsolescence over the years. This has happened for a variety of reasons, but mainly because the scripts were written for one purpose and once the author departed, no one knew exactly how it worked – so it fell into disrepair. Out of this need, many companies have turned to DevOps companies like Chef and Puppetlabs, et. al. that have developed command line, template or script based tools to provide this intelligent infrastructure, primarily focused on the linux platform. Some of these scripts are Ruby based, but in most cases the scripts and templates are a proprietary language. These proprietary scripting languages can perform many different intelligent functions to handle deploying new applications and even creating new systems to deploy them to. The advantages of this approach is that scripting language is very powerful and simple to learn, making the ability to generate intelligent infrastructure easy to implement and deploy.

The problem with using scripts is that they are:

a. written to handle a specific action, requiring constant change whenever the infrastructure changes.

b. written for specific platforms, so one change has to be propagated to the others.

c. requires knowledge of the infrastructure.

d. requires knowledge of the scripting language.

More complex scripts becomes difficult to read and understand beyond a few lines of trivial operations, which makes it hard for maintenance by anyone other than the author. Unlike the goal of DevOps, which is intended to unify Development and Operations as a team with one goal, scripting languages requires an analyst maintain the scripts so that new development can be seamlessly managed or deployed. Operations typically does not have this knowledge and it can be difficult for them to develop this skill (not being programmers as such). In order to facilitate a DevOps environment, the complexity of the scripts required to implement this infrastructure intelligence needs to be abstracted into simple actions so that operations can use it. This is usually accomplished with a Graphical User Interface. Historically, Operation’s goal is to keep everything in system running smoothly and applications are an unknown area: they perform business logic on data, consume resources indiscriminately and typically don’t handle system problems very well. So operations rarely understands the infrastructure of each application; they simply monitor it from the system resources aspect to see if there are any problems. Using scripts to automate this function is helpful, but tools to display the results are arcane. They are more familiar with desktop tools that have menus and displays because they are easy to use, easy to understand, and easy to modify. Operations is familiar the system operations and how it provides resources to applications like CPU, Memory, Disk and Network speed. These are things they can understand using commands for. However, for DevOps to be successful, using command line scripts  or knowledge of the application infrastructure should not be required to manage applications. What is needed is a tool that manages the infrastructure from the application side and notifies operations of any potential problems before they impact the overall system.

Now application management and monitoring tools have been around for many years and a few of these existing tools can be adapted to meet this need. One such tool is a third generation application management tool called NXTmonitor. NXTmonitor’s heritage comes from the Open Environment and Borland tools known as Netminder, Appminder and AppCenter. These tools evolved from simple monitors to a three tier architecture (presentation, business and database layers) to manage applications with a rules-based configuration file to specify each application’s environment. By leveraging middleware to facilitate multi-tier communication for agents and master servers, these tools were built on a fast, scalable infrastructure that enabled UNIX and Windows applications to be managed by an independent middle tier through a GUI presentation layer. The best description of this powerful tool is Application Orchestration: a tool that enables the definition and maintenance of complex applications and powerful monitoring capability with definitions of interdependencies across multiple platforms. This allows a complex structure to be captured in an intelligent, XML based configuration file that is built with the help of a Graphical User Interface (GUI). By recording the structure required to start the applications across multiple nodes to a configuration file, NXTmonitor can replicate the development environment exactly and even scale it up for production use. The use of environment variables enables NXTmonitor to assign variable infrastructure components to values that can be changed, making the tool easy to use in defining and replicating a complex environment. When the environment changes, these variables can be captured in environment variables which are different for each environment.

NXTmonitor is the next evolution of DevOps infrastructure tools – managing the deployment of a multi-tier application with a GUI console which can define the intelligent infrastructure needed for agile development. Unlike other DevOps tools, NXTmonitor provides a full featured APM that supports application orchestration across multiple platforms like IBM i-series, z-series, OpenVMS, Windows, and UNIX in addition to Linux. Application Orchestration is a relatively new term: it is the ability to start a complex application consisting of multiple, discrete components that are interdependent in a concise manner so that the application can be ready to process information in an orderly manner. In essence, Application Orchestration captures the developer’s knowledge of the infrastructure in a configuration file that can be used as a playbook for starting up applications. It is intended to be displayed and monitored by operations staff, with mouse actions that allow them to easily inspect or modify the configuration for scaling or performance purposes. Action scripts and Timers enable custom execution of actions designed to resolve runtime problems and increase performance. The definition of Performance groups makes scalability simple and easy to modify capacity, failover and service levels.

One of the key benefits of using NXTmonitor is that the NXTmonitor Console GUI is designed to appear the same across all platforms and perform in the same manner regardless of the desktop software or the nodes upon which the applications are being managed. Once you understand the operation of managing applications on linux, you can do the same operations on Windows or OpenVMS, for instance. With this in mind, the Console is designed for maximum efficiency and understanding and includes these features:

  • Multiple node login capability from one console.
  • Short cut buttons at the top for quick reference and use.
  • Navigation panel to display nodes and components being managed.
  • Content panel provides complete application configuration and status information.
  • Audit function provide history of the process restarts, failures, starts and stops
  • System statistics for each node includes, CPU, memory bar chart, devices, and errors.
  • Operator access to the process table now includes the ability to stop or kill an individual process in case of deadlock or runaways
  • Performance groups can now have actions associated with state changes so that changes in status can be propogated to operations or development.
  • SNMP support for other tools like HP OpenView and BMC Patrol.


The benefits of using a Graphical User Interface (GUI) to monitor and maintain your infrastructure instead of creating scripts is as follows:

  • All Application sub-components are easily displayed in a console window.
  • Infrastructure rules are easy to change in a GUI.
  • Console GUI displays all application statuses in one, easy to understand display.
  • GUIs don’t require operations to learn a scripting language.
  • A GUI console can provide management, monitoring and configuration tools all with the click of a mouse.
  • Focuses interaction with the application performance and application monitoring.
  • A mobile device can display the GUI making management more dynamic.
  • Simple, pro-active health scripts prevent outages, increase performance.
  • Mouse click operations speed up scalability functions with copy and paste.
  • Configuration files capture application infrastructure for easy deployment to additional machines.



The difference in DevOps tools today is usability. Do you want to manage scripts for infrastructure intelligence, or would you rather use a Graphical User Interface? Is it easier to teach operations how to maintain scripts or learn an Operations console? It is faster to capture the developer knowledge in a script or in a configuration file read by a GUI console?

NXTmonitor, which has evolved application performance management for decades, has advanced the creation of this intelligence with a rich GUI console, making it easier to define, modify and monitor application configurations in Development, Test, QA and Production. Once you have the developer knowledge captured in an XML configuration file, you can monitor and maintain it easily in the NXTmonitor Console.

For more information, go to:

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.


Eddie Orcutt Interview

eCube’s Interview with Eddie Orcutt


eCube Systems is interviewing Eddie Orcutt, Vice President Software Engineering at VMS Software, Inc.  Eddie was a long time employee of Hewlett Packard/Compaq/Digital Equipment Corporation where he held field engineering positions for 23 years.  Eddie was the person who approached HP with the idea that a company could take over development and support of OpenVMS.

eCube: Thank you for giving us some of your valuable time for this interview. You are very well known in the OpenVMS community and I am sure everyone knows, you started the ball rolling to start VMS Software and getting the software team together. How is it going so far?

Answer: Thank you Kevin, it is always great to meet with you and eCube to talk about OpenVMS.  It is going very well.  Since our inception 2 years ago, VSI has delivered 2 OpenVMS releases, V8.4-1H1 and V8.4-2, with a soon to be 3rd release planned for July/August 2016.  This does not include the 34 BOE products, 6 HAOE products, 23 layered products, and 9 Open Source products that have also been released.   We are well on our way of porting OpenVMS to X86, which as you know, is a multi year effort.  We are also actively recruiting ISV partners for supporting their application(s) on OpenVMS and we have started our hardware certification lab, for certifying 3rd party hardware, to make OpenVMS even more multivendor capable.

As you can tell, we are very busy adding new functionality, enhancing stability and ensuring the continued high security and availability of OpenVMS and associated products in addition to building the application base and multivendor hardware base to satisfy existing and future customer’s computing requirements.


eCube:  Let’s start with following up on Sue Skonetski’s interview in March. She deferred some of the more technical questions in our previous interview to you and engineering, so I’d like to start with VSI’s technical expertise. Can you tell me about your engineering team and if you think your team can stack up against the major OS vendors that are currently out there?

Answer:  Yes, VSI has a world class OS development team.  Some of our software engineers are the original developers of OpenVMS.  We average 25+ years of operating system development experience, mostly in OpenVMS.  In addition a number of software engineers also have experience in UNIX and/or Linux development.  This cross OS experience allows us a unique look into these operating systems, giving us ideas on how OpenVMS can incorporate other technologies within our framework of high security and availability.  Another aspect of operating system development not mentioned is our QTV (Quality, Test, Validation) capabilities.  VSI takes a “mindful approach” to testing validation and qualification where we follow practices and methods developed and honed over the past 30+ years including the IEEE 730 standard.  Our test suite, run daily, includes User Environment Test Package, Cluster Test Manager, System Integration Test Package, Faulty Towers, Alignment Tests, and Regression suites.  In all we put OpenVMS through over 3000 different tests.  These test suites are enhanced and expanded as new features and functionality are added to OpenVMS. It is our attention to quality that helps set OpenVMS apart from other operating systems.




eCube:  Sue also mentioned planned enhancement to the OpenVMS filesystem; can you tell us about VSI’s plans in this area?

Answer:  We are in the process of developing an advanced file system on OpenVMS.  The new advanced file system will eliminate the 32-bit boundaries, 2TB volume and file limit, in addition to addressing some performance limitations of the current file system.  The advanced file system is 64-bit based, which provides Exabyte scalability, about 2x file create/delete performance improvements, about 2x file open/read/write performance improvements for small files.  It solves the performance problem of deleting directories with a large number of files and provides for easier manageability since customers will be able to create fewer larger volumes instead of creating large multivolume bound sets.



eCube:  For many years HP didn’t seem to promote the virtues of OpenVMS and instead favored NonStop. After all those years, what are the challenges now and how do you think VSI needs to address them or do differently?

Answer:  OpenVMS is VSI’s only product and hence is our only focus.  Our organization is centered around OpenVMS from product development, testing, support, professional services, marketing to sales.  A major goal is to let everyone, not just our OpenVMS installed base, but the computing market as a whole know that there is a highly secure, highly available and high quality operating system option, namely OpenVMS.  The OpenVMS competitive advantages allow customers, old and new, to realize huge savings in operational costs during the lifecycle of their system in addition to reducing their security vulnerability risk by up to 81X (that’s 8,100 %), which reduces the chance of a break-in or a data breach and its associated costs.  Our job is to get the technical advantages and the business advantages of OpenVMS out to the market.  How do we do that? We have a multi-prong plan going forward to:

  1. Issue regular press releases on OpenVMS’ competitive advantages to increase awareness.
  2. Release White Papers to industry sources outlining OpenVMS’ advantages and how using OpenVMS actually reduces costs.
  3. Publicize our Integrity and X86-64 migration plan for VAX and older Alpha architectures.
  4. Engage our existing installed base to realize even more competitive advantages over Linux and Windows.
  5. Provide Open Source interoperability with Linux and Windows to tout OpenVMS costs, security and availability advantages.
  6. Make porting Linux/Windows applications to OpenVMS more seamless, which ties in to the next point.
  7. Work with our ISVs to increase the number of commercially available applications available on OpenVMS.



eCube: OpenVMS is often viewed as a legacy OS that does not support modern features by neophytes or upper management. What do you say to that? Maybe you can give us a quick history lesson on the major innovations of VMS and its virtues that differentiate it compared to contemporary Operating Systems in use today?

Answer:  Well, technically speaking, “legacy OS” just means it is in production mode currently. By that measure, Windows, Linux and Unix are all legacy systems; some are better designed than others. Unfortunately, “legacy” also denotes a connotation of being buggy, out-dated, antiquated or incapable of modern performance. That is not the case here. OpenVMS is far from antiquated as OpenVMS is run in the most demanding environments that require a high degree of security, availability and disaster tolerance.  You find OpenVMS systems around the world in banks, stock exchanges, healthcare, oil and gas production and distribution, power stations, railways, governments and so on.  One of the features of OpenVMS, that provides a buffer to becoming legacy, is forwards and backwards compatibility.  This means a customer can take an application that was originally built on OpenVMS V8.2 Integrity and they can run it unmodified on a VSI OpenVMS V8.4-2 Integrity system.  The reason is OpenVMS provides binary compatibility between older versions and the latest versions on Integrity.  In addition, a customer can take the latest release of VSI OpenVMS and run it on old Itanium server models. This is unique with OpenVMS, as commodity operating systems do not provide this level of investment protection.

OpenVMS has built-in enterprise class system management tools, rather than having to purchase add-ons.  It has a rich development environment, which includes programming languages, debug facilities, run time libraries and system service routines for taking advantage of the enterprise level capabilities of OpenVMS.  These features combine to reduce the complexity of applications.  Applications developers can focus on the application alone and not worry about having to account for security or high availability capability.  OpenVMS provides these services automatically.  OpenVMS also provides a calling standard that allows programs written in one language to call a program written in another 3G language.  This greatly improves application portability and code debugging which reduces development costs.

OpenVMS includes stable versions of commonly used Open Source software such as Java, Python, Perl, Lua, Apache, cURL, XML, Ruby, git, Subversion, ZeroMQ and etc.

OpenVMS is the standard by which all other “cluster” solutions are measured. OpenVMS clusters provide an active – active shared everything cluster environment where applications on different nodes in the cluster can share the same disks, local or on a shared interconnect, and can also share the same files and the records within the files.  This saves infrastructure costs, as peripheral devices and their resources can be shared across all nodes of an OpenVMS cluster.   Commodity operating systems cannot do this.

OpenVMS has unsurpassed security mechanisms that are built into OpenVMS and not added or layered on as with commodity operating systems.  A proof point of the OpenVMS advantage is that OpenVMS has an average, over its 39-year history, of 1.03 security vulnerabilities per year where commodity operating system vulnerabilities average in the hundreds.  This alone is a game changer in terms of total cost of ownership and one of the reasons OpenVMS can provide 5 nines of availability when appropriately configured.




eCube:  Wow – that is impressive. One of the things we hear is that OpenVMS clients say their upper management isn’t willing to spend money on OpenVMS since the HPE announcement, and yet some are willingly spending hundreds of thousands to migrate to Linux. What can change that dynamic?

Answer:  Number one is that VSI had to prove itself in having the expertise and ability to develop, release and support new versions of OpenVMS.  We have done that.  Number two, as previously stated, is to make the market aware that there is a highly secure, highly available and high quality operating system option; OpenVMS.  The competitive advantages OpenVMS provides is a game changer in the operational lifecycle costs, 50% less expensive than competitive products and is 81X less likely to be infected with a virus or to have a break-in or a data breach.  These are real tangible risk reduction OpenVMS features and it offers a huge cost advantage.  Our job is to get this message out to the market.  We, as OpenVMS professionals need to shed that complacency that comes with taking OpenVMS advantages for granted. We need to inform other IT professionals, managers and organizations that these features are a minimum requisite for safe and reliable computing for the future.



eCube: What changes when OpenVMS is supported on the X86/64 platform?

Answer:  OpenVMS is OpenVMS whether it is on Integrity or X86.  Having said that, there are features we are putting in OpenVMS to make it scale to support larger core and larger memory x86 systems.  In addition we plan to support OpenVMS on a virtual machine like Xen, KVM and/or VMware.  With the introduction of new X86 platform support for OpenVMS, we will support a wider array of I/O options that are available.



eCube: We keep hearing that one of the options available to OpenVMS customers is to migrate to Linux. How does Linux compare head to head with OpenVMS in total cost of ownership, performance, compilers, hardware compatibility and functionality?

Answer:  Not very well.  I’ve mentioned previously that OpenVMS has the lowest total cost of ownership of any commonly used OS on the market.  The OpenVMS cost advantages are not just a few percentage points but by 50% better than the competition.  Windows and Linux systems not only cost significantly more to operate than OpenVMS, but the risk of infection and a data breach is significantly increased by 81 times on those other platforms.

OpenVMS performance on the Integrity Poulson (HPE i4 server line) is very good.  Integer and floating point performance is 20% – 57% better, model dependent, than on previous server models.  Memory performance is 2X faster and Oracle 11g performance, compared to Oracle 10G, is 10X faster on newer i4 servers running VSI OpenVMS than on previous server models.

OpenVMS has a range of commonly used Open Source languages available, like R, RUST, Erlang, Lua, Python, Ruby, Perl, etc. in addition to third generation languages like ADA, BASIC, C, C++, COBOL, Fortran, Pascal, Bliss and macro.


eCube:  The other hardware vendors (HP, IBM and Oracle) seem to be jettisoning their proprietary versions of UNIX in favor of Linux. Why would a company want to stay with OpenVMS and not follow this trend?

Answer:  Great question Kevin.  The answer is because OpenVMS provides real tangible benefits to the customer in terms of significantly lower costs of ownership, (over 5 years, the typical mission critical system lifecycle), significant reduction in the risk of security vulnerabilities (by 81X), reduced risk of a data breach, reduced staffing costs due to reduced OpenVMS security patch rate, 5 nines of availability (99.999%) and business continuity support.

OpenVMS was designed to be crash proof and virus proof.  OpenVMS “firewalls” system components to limit the impact of a bug, it isolates trusted system code from untrusted user code.  It does this by using 4 access modes (kernel, executive, supervisor and user), using a descriptor (a data structure) for passing data between OpenVMS modes and providing fine grain privilege levels (39) to name a few.  There are over 54 technical features in OpenVMS that provide OpenVMS its competitive advantage in the market.

It is these unique OpenVMS features and benefits that companies are trying to build by layering various point solutions on to Linux, however it is the deficiencies in the OS itself that diminishes its effectiveness.  With OpenVMS, these features are built in to the OS.


eCube: Can you mention the White Paper on the comparison between OpenVMS, Linux and Windows on Operating Systems maintenance. Can you give us the highlights of that paper?

Answer:  That paper and its follow-on presentation focus on the cost of security for operating systems most commonly used (Linux and Microsoft Windows) in comparison to OpenVMS.  These other operating systems are woefully short of providing a stable, highly available or a secure environment for data that must be available 24×7 and secured.  These commonly used operating systems today may have the lowest initial costs, but their total cost of ownership is the highest.  The OpenVMS advantages include:


  • Reduced OS security patch rate by >10X
  • Reduced daily OS security vulnerabilities by 66X – 81X
  • Reduced yearly per system OS patch costs by ~30X
  • Reduced system management costs by 20% – 60%
  • Reduced yearly & 5 year lifecycle operational costs by 70% – 90%
  • Reduced wasted system management time by 12X – 15X
  • Reduced TCO by 44% – 50% (1.78X-2.0X OpenVMS systems for 1 Microsoft Windows/Linux)
  • Reduced data breaches (at the OS level) and their associated costs


eCube: With the constant pressure from the business people to change the business logic, enterprise developers are using Agile Development and Agile Infrastructure on Linux systems to roll out new versions quicker.  How can OpenVMS keep up with Linux in this area?

Answer:  By offering multiple ways to develop code on OpenVMS to fit the particular needs of a developer.  The goal is to make the developer as efficient in development as possible.  For more experienced developers, OpenVMS has a rich set of editors like EDT, EVE and EMACS accessible through a GUI or a text terminal interface.  OpenVMS also has a language sensitive editor with other tools for source code profiling and performance and coverage analyzing.

Kevin, as you know, for the more windows oriented developers and agile development environments, OpenVMS has partnered with eCube Systems for including NXTware Remote, a modern cross-platform Eclipsed based IDE.  NXTware remote, which is included in the OpenVMS software distribution kit for customer convenience, brings remote agile development and continuous delivery capability to OpenVMS.  This simplifies remote development for multiple languages like BASIC, C, C++, COBOL, Fortran, Java, Pascal, and even scripting languages like DCL, TDF, IFDL, GDF, as well as SQL and SQLMOD.



eCube: OpenVMS has tackled integration with Open Source tools many years ago with tools like GNV and WSIT. What are the plans for Open Source in OpenVMS in the future?

Answer:  VSI is expanding the role and reach of Open Source software in OpenVMS environments.  VSI is actively updating the versions of Open Source software supported on OpenVMS in addition to porting Open Source software that is new to OpenVMS as well.  To make it easier for VSI and our Open Source community to port software to OpenVMS, we are updating the C run-time library to make porting UNIX/Linux based software to OpenVMS easier and more transparent.  VSI has also provided direct access to git and Subversion, Open Source repositories, making it easier to build and support Open Source software on OpenVMS.



eCube: Oracle is releasing Java 1.9 this year and Java 1.7 will go into maintenance mode. Since OpenVMS on Integrity only supports Java 1.6, what are the plans to support new Java platforms in the future?

Answer:  VSI is in the process of porting Java 1.8 to OpenVMS.  We expect to release in the Q4 calendar year 2016 to Q1 calendar year 2017 timeframe.  We are also providing newer versions of Java related products.



eCube: What about modernization tools? Can modernizing the development environment help OpenVMS grow in the future?

Answer:  Yes, it can definitely help.  VSI has put together a series of training classes for customers and our ISV partners that develop applications for OpenVMS, to not only introduce them to modern tools but to make them proficient on OpenVMS using these modern tools.  Modern tools allow developers to code from their local desktop device where they can compile, debug and deploy the application on remote OpenVMS systems.  The advantage of using modern tools is reduced development and support time, which saves development costs.



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

Answer:  Complacency in the market place, meaning that customers will continue to use lowest common denominator operating systems in terms of security, availability and total cost of ownership.  VSI OpenVMS is a better and lower cost solution.  Our job is to get the word out to customers so they can make a more informed decision.



 eCube: OpenVMS is extremely stable and durable platform. In today’s market where young kids hack together operating systems with no regard to memory, CPU or IO usage, are these features of OpenVMS an advantage or disadvantage?

Answer:   There is a price to pay on commodity systems, in terms of speed and efficiency, when you waste CPU and memory and it becomes apparent when you have large-scale applications.  OpenVMS has huge competitive advantages in terms of security, availability and total cost of ownership, which all users of computers desire whether you are a corporate entity or young kids looking for an application development platform.  The disadvantage is that people forget what they have, the function it is performing and why they have it.  OpenVMS is truly lights out computing where OpenVMS systems receive little attention, due to its inherent high availability and security features.

eCube Systems Announces DevOps Visual Solution NXTmonitor at DevOps Summit/Cloud Expo in New York

eCube Systems is attending its first DevOps Summit at the Cloud Expo and will give a presentation on NXTmonitor, the APM Visual tool for DevOps.

eCube Systems, a leading provider of middleware modernization, integration, and management solutions, announces the release of NXTmonitor, a full featured Application Performance Management tool with extended capability for DevOps. NXTmonitor, which inherited the code base of NXTminder, has been extended to support multi-discipline processes and will act as a DevOps utility in a heterogeneous enterprise environment. Previously, NXTminder was packaged with NXTera middleware to configure and manage Entera and NXTera RPC servers.

“Since its first incarnation as Netminder, this solution is perfectly adapted to DevOps, but has never been marketed for that capability. In addition to its ability to monitor and resolve application runtime issues, NXTmonitor has the ability to capture application dependencies and infrastructure in a portable configuration file that can be exported from Development to Production,” says Kevin Barnes, President of eCube Systems.

NXTmonitor will provide immediate benefits to operations as a distributed application configuration, deployment, testing, and monitoring tool. It will aid in the migration and deployment of an application throughout its entire life cycle as it progresses from development to testing to production environments.

As a DevOps utility, NXTmonitor can:

• Proactively detect, report and fix problems (whenever possible)
• Notify operations of current application state
• Provide audit logs for problem resolution
• Manage application dependencies
• Monitor application health
• Perform intelligent restarting and capacity planning

To learn more, come see us at SYS-CON’s DevOps Summit at Cloud Expo, on June 7-9, 2016 at the Javits Center in New York City, NY.

About NXTmonitor:

NXTmonitor is a platform-independent process control and application management tool designed to simplify the runtime operation and dependability of web, cloud, and enterprise applications built on distributed processes, services, and scripts.

About eCube Systems

eCube systems offers a family of middleware evolution products and services that maximize return on technology investment by leveraging existing technical equity to meet evolving business needs. Fortune 1000 companies and government agencies turn to eCube Systems to reduce risk, extend ROI, and increase productivity as they consolidate existing capabilities and evolve legacy systems to contemporary SOA platforms.

eCube Systems Extends NXTware Remote Development Platform to Linux

NXTware Remote, a distributed development platform using Eclipse developed for OpenVMS, now works for the Linux platform.

eCube Systems, a leader in legacy systems evolution, today announced the addition of the Linux platform to its NXTware product line, NXTware Remote Server and NXTware Remote Studio.

The products, marketed jointly as NXTware Remote, work together to make it easier for teams of developers to develop code on local workstations running Eclipse — to compile, debug and deploy on a remote OpenVMS or Linux server.

Previously, NXTware Remote development wizards and tools were only available on OpenVMS – taking advantage of a distributed development environment, where they could offload development resources to a workstation. Now with NXTware Remote for Linux, advanced development functions on OpenVMS can now be used for Linux so that developers on both platforms can share the same interface, saving time, reducing costs and speeding development. Customers continue to look for simpler and faster means to develop and deploy applications. The new NXTware Remote suite of tools for Linux servers help customers, who have standardized on Eclipse, to gain the benefits of the distributed development on Windows, linux or Mac.

“Until now, OpenVMS customers migrating to Linux had to train their developers on different skills,” said Kevin Barnes, Professional Services Manager, eCube Systems. “Now with NXTware Remote, OpenVMS and Linux can share the same development platform, saving time, reducing costs and speeding delivery.”

NXTware Remote allows developers to follow their usual Eclipse-based development processes to complete tasks on either OpenVMS or Linux. No changes are required to their routine. Users can quickly, compile, debug and deploy code remotely on OpenVMS from their local workstation, while easily integrating with source code management systems.

The server component of NXTware Remote, NXTware Remote Server, executes all of the operations called from Eclipse and returns results instantaneously. The same technologies that made this distributed environment successful on OpenVMS will enable remote development for Linux. NXTware Remote for Linux supports all its existing functions including remote login, browsing, editing, debugging and advanced developer tools in COBOL, Fortran and C/C++.

About NXTware
NXTware is an Enterprise Evolution technology platform that enables legacy assets to be enhanced, maintained and integrated from within Eclipse. NXTware Enterprise Platform include the NXTware Integrated Maintenance Environment IME, NXTware Server and NXTware Remote. The entire NXTware Enterprise Platform is available for all major operating systems including Unix, Linux, and OpenVMS.
About eCube Systems

eCube Systems offers a family of legacy evolution products and services that maximize return on technology investment by leveraging existing technical equity to meet evolving business needs. Fortune 1000 companies and government agencies turn to eCube Systems to reduce risk, extend ROI, and increase productivity as they consolidate existing capabilities and evolve legacy systems to contemporary SOA platforms, such as ESB and Web Services.

eCube Systems, LLC, is headquartered in Montgomery, Texas, with marketing offices in Boston, MA and R&D in Montreal Canada. For more information, contact eCube Systems by email, on the World Wide Web at or by calling +1-(866) 493-4224.

VMS Software, Inc. Bundles Agile Development Environment with Latest Release of OpenVMS Operating System

VMS Software, Inc. includes eCube’s NXTware development software as part of the OpenVMS 8.4-2 media kit.

VMS Software, Inc. (VSI) today announced the worldwide availability of eCube System’s (eCube) NXTware Remote Server and Client software as part of the software media kit for VSI’s newly released OpenVMS Version 8.4-2 (Maynard Release) operating system for HPE Integrity servers. This initiative continues VSI’s commitment to modernizing the OpenVMS platform, by availing the OpenVMS development community of leading edge, OpenVMS 3GL and Java Remote development tools, based on the Eclipse IDE client, with distributed services on OpenVMS.

“We are thrilled with our alliance with eCube,” said Duane P. Harris, CEO of VMS Software. “The bundling of their best-of-breed software development environment is a major boon to the entire community of OpenVMS developers. It means added flexibility for experienced OpenVMS veterans, while lowering the barrier to entry for newer developers who are more comfortable developing in a GUI environment. For our customers, adopting an agile development environment will lower the cost of development and reduce time to market. It’s a win for the entire platform.”

Both VSI and eCube are dedicated to the long-term future and viability of the OpenVMS platform. In support of this commitment, eCube, the leading provider of modern development tools and best practices for Continuous Delivery on OpenVMS, has agreed to align its offerings with VSI’s new releases of OpenVMS on modern chipsets, including x86-64.

“eCube Systems and its clients are pleased to see that the future of OpenVMS is being handled with such a progressive and dynamic fashion,” says Peter John Marquez, EVP at eCube Systems. “Organizations that run strategic applications on OpenVMS now have long-term options they can build business plans around. We look forward to working with our clients and VMS Software, Inc., to deliver powerful, secure and easily maintainable enterprise solutions.”

NXTware Remote, eCube’s modern Eclipse-based Integrated Development Environment, provides developers the tools to simplify and integrate their software engineering. It will be certified to work with all new releases of VSI’s OpenVMS. The IDE’s suite of tools and best practices for Continuous Delivery, which automates much of the development process on OpenVMS, will leverage eCube’s close relationship with VSI to ensure users get the most out of their OpenVMS investment.

To aid OpenVMS developers in the adoption of an Agile Development Environment, eCube is offering a jumpstart program. The program will help customers evaluate and deploy NXTware Remote for their OpenVMS development needs. Find out more information at:

About eCube Systems
eCube Systems offers a family of middleware evolution products and services that maximize return on technology investment, by leveraging existing technical equity to meet evolving business needs. Fortune 1000 companies and government agencies turn to eCube Systems to reduce risk, extend ROI and increase productivity as they consolidate existing capabilities and evolve legacy systems to contemporary SOA platforms. eCube Systems, LLC, is headquartered in Montgomery, Texas with marketing offices in Boston, MA and R&D in Montreal, Canada. For more information, go to

eCube Systems

About VMS Software, Inc.
VMS Software, Inc. develops, sells and supports innovative and advanced releases of OpenVMS, the most secure operating system on the planet. The company’s core motivation is to support and enable customers to run their mission critical applications at the legendary uptime levels OpenVMS is known for, at maximum performance levels, today and into the future. VMS Software Inc. is headquartered in Bolton, MA. For more information, go to

VMS Software, Inc.

NXTmonitor 8.5 has been released!

  • Graphics for CPU, memory consumption
  • Portable evironment paths save subsets of log files
  • Provides SNMP reporting on application level events like start, aborts, and errors
  • Advanced debugging functionality with log files: Save log to log file directory, Mail actions can attach log file
  • Scalability features based on configuration performance groups
  • Support for Windows, Linux, OpenVMS and UNIX OS
  • Visit the NXTmonitor product page for more information

eCube’s interview with Sue Skonetski

sue skonetski interview

eCube Systems is interviewing Sue Skonetski, Customer Advocate with VMS Software, Inc. Sue was a long time employee of Hewlett Packard/Compaq/Digital Equipment Corporation and held a similar job for 25 years. Sue knows the OpenVMS community quite well and is very attuned to their needs and the future of the OpenVMS operating system.

eCube: Thank you for giving us some of your valuable time for this interview. You are most likely the most famous person in the OpenVMS community; everyone knows you. How does it feel to be part of such a vibrant technical community?

Answer: Thank you Kevin, It is a pleasure to talk with eCube. I am not sure about famous but I am fortunate that the community has included me. And yes it is absolutely a wonderful feeling to be associated with some of the most intelligent people in the World!  The VMS community is a very loyal, diverse, and passionate community I can honestly say that I really love this group.  Every day I am thankful that I have the best job in the world.  I am able to work with the VMS Customers, Partners and Engineers and those who sell and support VMS.  It really is an honor to be part of the VMS Community.

eCube: Since VMS Software Inc. launched in May of 2014, there have been a lot of expectations that this event would signal the renaissance of OpenVMS. You are right in the middle of this effort – how do you see this happening?

Answer:  I am seeing so much in interest in VMS of course from our valuable installed base but also from new customers and partners.  I think one of the major draws is the fact that we have solid long range plans for VMS.  What the team is doing now will affect our future as well not just on Integrity platforms but other hardware platforms in the future.  I see this not only as a solid future for VMS but a game changer in Mission Critical and Secure computing environments.  VSI has a roadmap that goes far into the future. Part of this strategy includes significant enhancements to VMS and a port to x86.  We already have an R&D team working on this port and we see advancement every week. In order for VMS to compete as a platform going forward, we can’t be satisfied with the niche we have; we have to aspire to be a mainstream Mission Critical and Secure operating system on a variety of hardware.  We need to embrace newer kinds of systems that are sometimes foreign to us. This means we as a community need to adopt new ways of computing, newer languages like Java, expand support for important languages like JavaScript and Python, and new development techniques like NOSQL. The combination of these capabilities and the platform’s existing strengths will attract new users and use cases, enabling future growth. . We have to enrich the platform to make way for the VMS generation that follows us.

2 examples of new customers

  1. VSI has partnered with a brand new company (Stark Gaming). This is an amazing story since this is an entire new concept around online gaming and they chose VMS. Here is the URL; I promise it is worth your time.

  1. I received a phone call from a gentleman that was a customer in local government. He said that he would like to talk to VSI about VMS. So I asked him what kind of VMS environment he was currently using.  His response was “none”. They needed to upgrade their environment and he researched what operating system was the most secure and reliable and decided that VMS running HP i4 systems was the best solution for their needs

eCube:  Some say that the VSI announcement came too late and companies already started plans to migrate away from OpenVMS since HP announced their end of life plan for OpenVMS. What do you think the risks are? What do we say to those that say VMS is in inevitable decline?

Answer: Well, only time will tell; however, on the day we announced VSI and the future development of VMS, I heard from many of the VMS Customers who, on that day, put their migration plans on hold. When customers take a serious look at leaving VMS it can be a huge task. Over the years, customers have become dependent on the performance, reliability, availability and security and of course the clustering that VMS offers. They have built their infrastructure around the knowledge that VMS gives them this.  Customers depend on their VMS environment to always be up, to automatically fail over and not be hacked. And while there are very few labs with only one vendor I am really pleased to see so many customers have realized migrating to another operating system is so risky and you may not get the same benefit you enjoy with VMS.  As an example when VMS was originally developed, 38 years ago, continuing until today security was written into the multiple layers of VMS.  This means that security is not a layered product or an application you add to VMS, it is part of the design of VMS; secure, stable and highly resistant to malicious attacks.  Our customers can depend on this and in fact many customers have up time in the double digit years, and they are proud of this and so are we.

So let’s talk about the challenges in VMS, because that is our next opportunity. In the last 24 years VMS only had three major issues

  1. Lack of strategic support from the parent corporation – As time went on VMS was no longer considered strategic with each merger reducing that commitment to strategic direction. With VSI, VMS is not only strategic to us, it is our raision d’etre and is essential for our continued growth as a company; so needless to say, this problem has been resolved.
  2. New blood in the VMS space in both the systems and applications areas. In the systems area, one of the things that I have noticed is that there are two mind sets here.  The first being that companies want to pay for junior engineers and train them on VMS vs. recruiting experienced VMS people. The first option is attractive to those who have senior staff today and are willing to train for an extended time. Other options include developing your own training program either internally or with the help of companies like CDL in the UK that has developed a process to bring in junior people and have the senior folks mentor and train. For those willing to learn the OS, VSI  offers a complete training program with a large portfolio of training classes, and I have been surprised at how many VMS novices are taking VMS training (local to Bolton MA or remote).

On the application side, eCube Systems has an excellent approach to solving this problem with their product suite designed to help non-VMS developers remotely develop on VMS with Eclipse (an Open Source  tool college students are familiar with) on their workstation aided by NXTware Remote.

  1. This is a tie between more applications and a new file system. First, let’s focus on the issue of a lack of new applications on VMS. This is the area where we need the most help: we need new applications to replace those which over the course of time have become obsolete or are retired. When VMS was a part of HP, there were about 5,000 applications from approximately. 2,000 vendors running on VMS which is a significant amount. That amount is likely to change in the coming years as customers migrate away or the applications age or are no longer needed. Our existing applications need to be made more agile and we need to adopt Continuous Delivery like the mainstream computing world does. We need partners to fill in those gaps in functionality and support where possible and make VMS more modern. VSI is talking to partners every day to make sure they are still committed to their VMS products. We have been able to talk to some and get them re-engaged.  Going forward, support of older applications will be no problem for new versions of VMS because binary compatibility will still be supported.

Regarding the file system, I am not an engineer, but I do know that customers have requested a larger file systems for some time now.  If you want to know more about what we are doing in this area, I’ll refer your request to engineering. I do know that at VSI this is on our priority to-do list for engineering.

eCube:  What do you see as the future of OpenVMS going forward?

Answer:  Whew this is a tough one.  Let me think about this. If you look at our existing customer base – based on what we have seen so far I think that these customers are still committed to VMS and they want to see VMS and VSI succeed.  I do see a great potential for an expanded customer base on Integrity systems and especially as VMS becomes available on x86.  Prior to x86 we need to prove that VSI can deliver a VMS product that customers and ISV’s have come to respect.

If you want more information on our technical prowess, you should talk with Eddie Orcutt. He is the largely the reason VSI is here now. Eddie knows the talent we have and has the technical knowledge of where we are and what our vision is for the future. That would make an interesting follow up interview, don’t you think?

In my opinion, I think the key to our future is how we can leverage the existing customer base’s needs and grow VMS into areas of new technology. If VMS can adopt new software development techniques, integrate Open Source products and the latest technology, I think we could compete with anybody. Imagine if we could support mainframe, mid-range, desktop, laptop and mobile platforms – then companies could turn to us for their new technology products. We need that for us to flourish; we need to start thinking that way.  It is important to the VMS community’s future for all of use to work to grow the platform base.

eCube: What can the community do to enhance and extend the life of OpenVMS?

Answer: Come to the 2016 Connect VMS Boot Camp the last week in September at the Radisson in Nashua, NH and commit to having the most up to date OpenVMS environment.

Talk to everyone about the value of VMS.  Share success stories with VSI.

Become involved with the VSI Social Media sites.

Sign up for the VMS SIG

Let your company be aware of your VMS uptime and how much value that is to them.  Sometimes I think that because VMS works so well management forgets about the value VMS provides.  If you are working with VMS it is on a mission critical system you need to be proud of that.

If there is a problem it’s better to address it sooner than later, let us know quickly.

Based on the experiences over the last few years, it’s important to not give up. Ever!

eCube: There have been some concerns from the user community and vendors that VSI hasn’t done enough to market OpenVMS since the announcement. What can VMS Software do better to promote OpenVMS?

Answer:  Yes, I have heard that too. We do understand that folks may feel this way and we are going to address it. Our CEO, Duane Harris has outlined a plan of continuous press releases to raise the awareness of OpenVMS and share with the world our progress as it happens. We are working with eCube and other vendors to increase awareness and provide content. If you have contacts with media outlets that could promote our message, please contact VSI and let us know.

Let me also re-iterate the work we have done to get us to this point: .

The first and foremost is that we have been focused on developing a product that meets the VMS customer’s expectations and achieve the goals of sustainability and feature growth.

The second is the team members that are not working in engineering are focused on developing a relationships with the customers and partners focusing on their needs to the exclusion of everything else. If you are reading this and think you can help, have input for press releases, publishing success stories, or just haven’t heard from us lately, contact me and we will bring you up to speed on what we want to do and where we are going.

eCube: What is the biggest problem in the OpenVMS community?

I see two main problems:

  1. Negative Apathy – What I mean by Negative Apathy is that many in the community do not want to get involved unless it’s a negative situation. In this day and age of constant change, we need to be pro-active in our actions with building enterprise systems on VMS.
  2. Fear of the Unknown – it is easy to get comfortable with the knowledge you have acquired using VMS and its powerful, leading edge computing environment. Learning how to reach the newer generation is critical to our survival; we have to bridge the gap between the new engineers out of school who don’t know anything about this platform and the highly skilled analysts I know we have in this community. It is up to us to bridge that gap because the newbies just out of college won’t.

eCube: How can we solve it?

Well, there are many problems we can solve, but VMS Software can’t address every problem that has occurred in the history of VMS (3 major ports, 3 mergers, countless databases and reorganizations) in a year or two. First, we need time and help from the community to determine what problems are a priority to address first. Part of that is realizing the magnitude of the work ahead of us and the limited time we have. Next, we need your help to promote VMS; we need folks to talk about VMS on social media, share their success stories on the web or do press releases articles and post articles like this that eCube is doing.  And if you have a lead please forward it to us, we will follow up.  If you are part of a Connect LUG please go to their meetings.  If you need to meet with the people at VSI just let us know.

eCube: What about modernization tools? Can modernizing the development environment put OpenVMS back up with mainstream OSes?

Answer:  Absolutely, modernization tools are critical to the successful evolution of VMS and the success of the VMS community.  VMS has to be an equal player on the enterprise stage with unfettered integration points to other systems. As technology advances we need to focus on leading edge tools that enable folks to work on VMS without having to know the OS. We have to realize that our future lies with those that may not have such a rich VMS heritage.  This is especially true of college new hires that have no VMS knowledge and need an effective way to develop software with VMS.

eCube: What do you say to Senior OpenVMS programmers and analysts who are concerned for their job security when upper management wants a modernization plan?

Answer: Once again a two part answer.

Modernization tools for VMS developers are one of the best things that can happen for your career.  While there is a learning curve, this will ultimately make your job easier: this will allow you to collaborate with developers in other areas of the company, to expand the breadth of your knowledge in two critical areas, while providing valuable knowledge to junior engineers who can now perform the entry level tasks of maintaining the code, recompiling and testing and ensuring the long term survival of VMS and what it represents.  Embracing and learning this hybrid system will allow your company to bring in new people who can immediately start work on VMS vs. moving off of VMS because they cannot find new VMS developers or it takes too long to train new ones. This will allow for the development of new products on VMS which I see as being pivotal to moving ahead into the future.

Secondly, don’t fear for your job; you are a precious commodity in VMS and we need you to learn the modern ways to develop, integrate and operate these new applications using newer technology on VMS. We need your experience with VMS to make these interfaces even better. Your knowledge of the OS can help the newbies understand the rich computing environment VMS brings to the table (clustering, automation, failover, security, etc.). You will be needed more than ever and your job importance will more than double your worth to your company.

Lastly, think about this: what kind of legacy do you want your career to embody when you retire? Is it after 30 years, you retire with no one to take your place and your boss can’t find anyone else who knows VMS, so he hires a bunch of consultants to migrate your system to SAP or Windows?

Or, do you want to leave an active, growing VMS system in good health with a staff of highly trained engineers knowing not only VMS, but the understanding the latest development techniques and new technology that will take your systems well into the future?


Next Up: an interview with Eddie Orcutt


eCube’s Interview with John Egolf

Nxtware Remote Bootcamp 2015 booth2At the OpenVMS Bootcamp this past September, eCube Systems spoke with HP’s John Egolf about a variety of topics. John is a specialist in OpenVMS and the following is our conversation with him. Since the VSI announcement in June, John has become the primary contact with VSI from HP. With a focus on the relationship between HP and VSI, John communicates and resolves issues between the various HP teams, including Technical Services (TS), Supply Chain, the Business and Marketing teams, and the R&D engineering group.


On trends in the OpenVMS Community:

  1. Customers are happy and optimistic about VSI and the future of OpenVMS.

John Egolf: Prior to the VSI announcement, a lot of customers were concerned about the end of HP’s OpenVMS roadmap. The HP i2 Integrity Server sales were extended till end of 2015. They did not want to use after market servers and saw the lack of new hardware as the beginning of the end for OpenVMS. Now, customers look at VSI and HP i4 Integrity Servers and see a brighter future for OpenVMS.

  1. Customers have more time to think about their next steps.

J.E. Companies are considering how long they will stay on OpenVMS. The VSI announcement lessened some of the urgency.

On common customer questions: 2 questions he is commonly asked:

Q: Concerns with VSI staying in business?

J.E. Customers that I talk with want assurance that VSI will be around for a long time. Because VSI is only focused on VMS, some customers are concerned about the long-term future and business longevity of VSI. HP and VSI have a very good partnership. HP wants to do anything they reasonably can to ensure VSI is successful and stays in business. HP is the primary sales channel (reseller) for the VSI products. In addition, HP is a worldwide sales force, and the customers that will buy VSI (at least initially) are install-based customers, meaning we don’t expect any truly brand new customers. These are customers who are growing or refreshing their base.

I4 servers, which VSI runs on, are actually very good servers based on price performance. They are very cost effective. Since VSI software’s availability this past June, we are seeing customers showing interest with purchase orders of HP i4 servers with VSI software, meaning business is off to a good start. While the concern is valid, don’t let that be the factor holding you back.

*When addressing this question, John tells customers Duane Harris, the CEO of VSI, has worked the numbers and sees a strong business opportunity and is confident of VSI’s longevity.

Q: When will the x86 port be available?

J.E. The port is being worked on and should be available in a couple of years. VSI will communicate updates and roadmap deliverables about this. VSI feels that the x86 port is a key part of the overall OpenVMS strategy. However, there are customers who need additional integrity servers and additional computing power now and cannot wait. Customers who are doing hardware refresh or running on older integrity servers (which are not efficient based on power, cooling, and services) need new servers as soon as possible. Some customers will wait on the x86 and that will have some impact, but if VSI delivers on their roadmap, they will buy now.

On the role of open source technology in the future of OpenVMS:

J.E. Open source is software that is contributed to by a community (the world at large). By having open source software, you have many people doing development and support. Customers can choose to get the source of the product that they’re using. Innovation happens much more quickly because you are not dependent on HP or VSI or any ISV for capability since you are working with the overall community. Having more products available on open source gives customers more choices in what they’re looking for and reduces dependency on HP or any single vendor or partner. For these reasons, open source technology is an advantage for customers and the OpenVMS Community. For example, regarding the need for more Unix compatibility, developers could take an open source Unix product, drop it on OpenVMS, and then run it without making major changes. I think close to 100% Unix compatibility with a set of libraries needs to happen.

On the role of integrated development environments (IDEs) in the OpenVMS space:

 J.E. One of the biggest complaints we hear from our customers is that it’s difficult for them to find VMS developers, testers, or systems managers. Many years ago, we had VMS in many of the universities around the world. The students would learn development and computing on a VMS system and when they got out of school, they already had hands-on experience with how to compile, link, run, and debug on OpenVMS. There were lots of potential OpenVMS developers, system managers, etc. Today, students do programming on their phones and laptops. While some still run OpenVMS, the majority of universities have Windows, Linux, and Macintosh as default platforms for students. On the development and testing side, having an IDE that works on multiple platforms and makes OpenVMS a common ground for operating systems reduces the amount of OpenVMS expertise required. Developers can focus on the business problem and not worry about learning a new system. Additionally, IDEs can improve the development environment and make it easier for customers to maintain and develop systems. This is especially true for customers who manage Unix or Linux and aren’t familiar with OpenVMS.

On the impact of virtualization:

J.E. There are two types of virtualization: 1.) HPVM (HP Virtualization Manager), HP’s virtual capability for OpenVMS, and 2.) Hardware virtualization.

HP Virtualization Manager allows multiple virtual machines to be created to run OpenVMS integrity (i64) on a single server. As far as the users are concerned, they’re on one single server and this isolates one user from another from an environmental point of view. Each user can run different versions of OpenVMS.

Although there are not a lot of customers using HPVM, hardware virtualization is popular. There is virtualization of the hardware, either Alpha or VAX, on x86. We have customers who cannot migrate off of Alpha or VAX. However, their Alpha hardware is getting older and new Alpha hardware is not available anymore. One option is to buy an Alpha emulator (virtualized environment) from one of our partners (i.e Stromasys) and run it on an x86 system like Windows or Linux. There are no changes to their code. You basically back up your physical Alpha and restore it on to the virtual Alpha. I run Alpha VMS on my laptop. Customers run this on production environments. The hardware virtualization for VAX and Alpha is quite popular and an option for some customers with aging hardware.

If their concern is about the Alpha hardware breaking or costly support contracts, I would strongly recommend the alpha emulator. While it is not cheap, once you factor in all other costs such as lab space conditioning or maintenance, the alpha emulator makes sense and you can cover the cost within 12-24 months. If the concern is administration, meaning they don’t have system managers or programmers, then they need to reach out into the community or directly with HP or VSI.

Ultimately, for customers running Integrity, virtualization does not have a large impact. Customers who use Alpha/Vax can see a significant impact from virtualization.

On the possibility of a Cloud in the future:

J.E. There is not a demand for cloud computing from VMS customers and it is not currently included in HP’s cloud strategy. I don’t see a future for cloud computing at this time. Customers could use it, but they aren’t asking for it. There is no business need to run OpenVMS on a cloud.


 J.E. From everything I’ve read or heard about, the concept of the cloud is pretty cool. I just don’t think there is a demand for VMS in the cloud. One of the main reasons customers buy VMS is security. No matter how secure you make the cloud, the perception, if not reality, is that it won’t be as secure as having the server in your own lab. Because VMS is bought for high security, the cloud is not typically seen as the right environment.

 What news headline would you like to see for OpenVMS in 5 years?

 J.E. “OpenVMS installations surpass Linux installations for the first time”