Blog

While attending the bootcamp in Malmo this year, I happened to attend the seminar that Homi gave regarding the tool he wrote and maintains, VSI$SUPPORT. If you have time, I suggest you watch the replay of this. The tool can do some interesting things that even I did not know about! As the manager of the support team, I get to hear from customers when they think we could have done something better. More than once, I have heard about our policy to collect an output from the VSI$SUPPORT tool on most calls. When we started this practice, I was also in doubt about the value of this output for calls. But, we adopted the policy and moved forward. Several months later, I can tell you first hand the value of this policy. I am generally a backline resource for some types of calls. When I ask the person seeking my assistance for information about the system or a configuration, they say to me, “I have the vsi$support output, let me look”. Every time I hear a sentence of that nature, I think, thank goodness we are doing this. In the short run, it can seem like overkill when you are logging a call. In the long run, that output can save and has saved a bunch of time when working an issue. We already have a bunch of data! The back and forth emails trying to collect data are cut way down! Time is saved since we already have the data in our hands. Fabulous!

Like many other companies, IT or otherwise, we go through an annual exercise of reviewing our risk assessments. You know the drill: list your resources including people, offices, software, hardware, customers, data centers, contractors, and so on, and then list all the things that can happen to them and color-code risks based on how likely and how bad they are, and then think of how they can be mitigated. And while staring at line 366 of my risk assessment, I thought to myself: I wonder how many people put OpenVMS in their risk assessments?

This question was asked during my Boot Camp presentation last fall in Boston, and over the past 35 years dozens of times people have asked, how big is VMS? That translates into "how many lines of code are in VMS"? I thought it was time to at least make a stab at pursuing some insight into the answer. I wrote some command procedures to count the number of source lines in .B32, .B64, .C, .MAR, .M64, and .S files. Not counted are blank lines and lines beginning with the standard comment characters and miscellaneous directives for the particular language.

As I look back on my journey as a support specialist, I remember fondly those first few calls. I knew the answer to exactly one question. There were many calls on this issue, so it was a great place to start! Some of you can recall the days when we answered questions via the phone and not via email. Those calls opened the door to so many “by the way” or “while I have you on the phone” questions. Back in the day, those words struck terror into my heart. Nowadays, not only are most calls worked by email, but the one call that I could actually answer when I first started has disappeared. I don’t even train the new hires how to work that issue! Although, between us – I get a giggle whenever I see them taking their first calls. It brings back so many memories!

Back in April 2022, I was on a call with a customer that I have had the pleasure of working with for many years. We were talking about a variety of topics, and one of the things they mentioned during the course of conversation was that as a consequence of the HP OpenView Smart Plug-In (SPI) for OpenVMS (VMSSPI) no longer being supported, they were establishing a project to design and build a replacement solution for monitoring their OpenVMS systems that would integrate with Dynatrace, which they had recently adopted as their new enterprise-wide incident management and monitoring solution. I have talked previously about the unfortunate decline in the number of ISV solutions available for OpenVMS, but in this case the situation was perhaps somewhat different, with the customer looking not only to replace the VMSSPI OpenView agent but OpenView as a whole across their entire business, encompassing multiple operating systems, using an arguably more modern monitoring solution.

In my previous post (https://vmssoftware.com/resources/blog/2024-09-30-application-services/) I talked about the unfortunate incremental decline in the number of ISV solutions available for OpenVMS and what can be done about this situation, with my general thesis being that with a little ingenuity and imagination it is invariably possible to devise excellent alternative solutions, often by leveraging open-source products and open standards, such that the resultant replacement solution if done properly may be in some ways superior (and arguably more cost-effective) than its no-longer supported and proprietary counterpart. In this post I will aim to continue with this general theme of "creative modernisation", based around a talk I gave at the recent Bootcamp event in Boston in which I demonstrated the ACMS product working on VSI OpenVMS x86-64, but before launching into the details of what I presented in this session I should just mention how great it was to catch up with old friends at Bootcamp and to see not only many familiar faces but also a good number of new ones. The event was without question a success, and what struck me most was the level of enthusiasm displayed by all those in attendance, which was absolutely great to see.

"There are many OpenVMS customers running large, complex, business-critical custom-written software applications. While these applications continue to serve the business well, many of them now need to interoperate and exchange data with external systems and applications running on other operating systems. The options available are to replace the existing OpenVMS-based system or to modernize it in some way so that it can continue to operate in a modern heterogeneous computing environment."

Following on from the recent webinar in which we briefly introduced VSI Application Services, I thought it might be worth providing a little more information by way of a short blog post. Looking at it very simply, VSI Application Services are a set of services designed to help you get the most out of your OpenVMS application environments, and while the primary aim is to provide services to help you move your OpenVMS applications to VSI OpenVMS x86-64, the overall scope of the services portfolio is much more general than that, ranging from workshops and small consulting engagements to investigate and advise on various modernisation options, through to assistance with major modernisation initiatives (such as porting to x86-64), and application maintenance and support, where we take over the task of looking after your application code. In short, if it’s anything to do with maintaining and enhancing your OpenVMS application environment, we are here to help, and we’d love to hear from you!

As standard support for OpenVMS V8.4-2L1 for Integrity ends in December 2024, we strongly recommend that customers upgrade to V8.4-2L3. While extended engineering support for V8.4-2L1 remains available, the transition to V8.4-2L3 is advised to ensure increased compliance with the latest standards and continued optimal performance. However, some customers have encountered issues with the RTL8 kit on V8.4-2L3, which have hindered their ability to upgrade. This article aims to outline these issues and provide our recommended solutions.

If you go online to order an umbrella, it doesn’t really matter what truck it shows up in: what matters is that it shows up on time and performs as advertised. Technology should work the same way. The hardware you have in place or how your systems are configured shouldn’t even be considerations: everything should just function perfectly every time. This is the promise of virtualization, and over the last three decades, it has gone from a pipe dream to reality. In today’s cloud-enabled world, your hardware should be no more than an afterthought.