Ceci est une ancienne révision du document !
In the early days of computers, a company called Digital Equipment Corporation (DEC, first bought by Compaq, today part of Hewlett-Packard) created their 32-bit VAX (Virtual Address eXtention) computer as an upgrade from the 16-bit PDP/11 (Programmable Data Processor) computer. It uses openVMS as its operating system. In the steel-making company where I work, a large number of these computers were used to control the manufacturing process. We use (VAX-) Pascal as the standard programming language, and a home-brew computer interconnection program called HDN.
We are not the only manufacturing company that used these computers. There are thousands of VAX's sold all over the world. Because a VAX/VMS computer is so reliable, there are today, after more than 25 years, still a large number of them in use, including some in the company where I work. But after more than 25 years, the number of people knowing their way around in VMS is quickly diminishing, and it is getting harder to find replacement parts for failing hardware. The hardware could be replaced with emulators like Charon-VAX (although, I have bad experiences with frequent, but random, errors on Charon-VAX, I will explain these in one of the following articles), but expert programmers cannot be emulated. So, in the end, even these reliable computers will have to be replaced. But replacing these computers will take a lot of time and money, as the functionality must be migrated to another operating system.
Windows?
Because most people are familiar only with Windows, this would be the logical choice. But the migration from VAX/VMS to Windows is time-consuming, expensive and complex, due to the different way the operating system works, and despite the fact that Windows NT is based, loosely, on the VMS predecessor, RSX, as used on the PDP/11. This complexity increases the chance of disruption of the manufacturing process during the migration, which will cost even more money, not to mention the damage to the reputation if you fail to deliver in time, or at a lower quality than the customer is used to. Also the reliability of Windows is questionable: most programs delivered with the operating system are an integrated part of it, which might lead to a complete system breakdown if just one component fails, and viruses are a problem in itself. Protection against them takes a huge part of the systems resources, and, in our case, on one occasion, was even itself the cause of a total system breakdown. Mandatory updates of the operating system to patch security leaks require a frequent reboot of the computer, causing a loss of production time. And finally, some experts are quietly admitting that they are slowly losing the battle against the flood of new viruses….
What about the database?
Besides the different way programs are written for Windows, there is another problem: DEC created on their VAX/VMS computers another type of database compared to the relational databases used today, a network database named DBMS32 (DataBase Management System 32-bit). In this case, the word 'network' does not refer to a LAN or the Internet, but to the internal organization of the data. The different types of data are not linked to each other through a relation, but by a double-linked list. Finding the first/next/last member of a set is lightning fast, because you only have to follow the link – instead of reading all records in the database to see if the relation is satisfied. When you migrate a VAX/VMS system to Windows, you also have to migrate from network databases (if you are using it) to relational databases.
Linux!
As I was thinking about an alternative way to migrate, it appeared to me that VAX-Pascal is largely compatible with Free Pascal. And the way Linux works is largely compatible with VAX/VMS. So I decided to try to convert our programs to Lazarus/Free Pascal, but found that there is no replacement for DBMS32. So…. I created one. It’s written in Lazarus/Free Pascal, and includes a GUI replacement for DBQ – the database client interface program used to read or enter data. Not entirely up to spec yet, but that will improve over time. I replaced the interconnection program HDN by a set of programs: one to send and one to receive the data, operating system independent, and with the data in readable form, formatted in XML-style, while using folders as send and receive buffers. To be used by our applications, I created an API equal to that of HDN, so the applications remain untouched. This causes less risk of failure, because they just needed to be linked to another library.
It is not going to be easy…
The way I state this might suggest that migrating a VAX/VMS system to Linux (in my case Linux Mint 17) is a walk in the park. This is, unfortunately, not true. There are third party programs used on VMS systems which have no Linux replacements. You would have to rewrite those programs based on their functional/technical description, or find another way to deal with the functions they perform. There are libraries offered by DEC included in VMS with no counterpart in Linux, such as FDMS (Forms Display Management System). And then there are technical functions used in VMS with no apparent replacement in Linux, such as eventflags and logicals. In the following articles, I will go more in depth to describe how I replace these, and other functionality such as mailboxes (IPC), and how to deal with Asynchronous System Traps, DCL and file version numbers.
If you need help…
Because my company is not the only one that wants to migrate away from VAX/VMS, I am willing to provide DBMS32 and the other replacements as open source under the GPL license to anyone who needs it. And I am offering to assist in the conversion of your VAX/VMS programs. This will be magnitudes cheaper than a complete re-engineering and conversion to Windows and there is a much smaller chance of disruption of the manufacturing process during the migration, as the conversion is almost 1-on-1.
I think the advantages of a network database would be interesting for new projects as well. If there are enough people who would like to know more about using network databases and their (dis)advantages, I will write some articles on how a network database is organized and how it can be used in comparison to a relational database.
Next month
In the next article, I will explain what eventflags are, what they are used for, and why they are so important to dedicate an article to them.