In the early days of computers, a company called Digital Equipment Corporation (DEC) created its 32-bit VAX computer using openVMS as its operating system. Because a VAX/VMS computer is so reliable, there are today - after more than 25 years - still a large number of them in use. But, in the end, even these reliable computers will have to be replaced. As described in part 1, you could migrate from VAX/VMS to Linux, as the way Linux works is largely compatible with VAX/VMS. If you use Pascal as your programming language, you will find that Lazarus/Free Pascal is a good replacement. But there are technical functions used in VMS with no apparent replacement in Linux. In this article, I will describe the migration of the network-type database DBMS32.
Au début des ordinateurs, une société appelée Digital Equipment Corporation (DEC) créa son ordinateur 32-bit VAX avec openVMS comme système d'exploitation. Comme un ordinateur VAX/VMS est vraiment fiable, aujourd'hui, après plus de 25 ans, ils sont encore très nombreux à être en service. Mais, à la longue, mêmes ces ordinateurs fiables devront être remplacés. Comme décrit dans la Partie 1, vous pourriez migrer de VAX/VMS vers Linux, car le fonctionnement de Linux est en grande partie compatible avec VAX/VMS. Si votre langage de programmation est Pascal, vous trouverez que Lazarus/Free Pascal est une bonne alternative. Mais il y a des fonctions techniques dans VMS sans équivalent évident sous Linux. Dans cet article, je décrirai la migration de la base de données de type réseau DBMS32.
Network vs relational database Today you have a choice of different databases, varying from a free MySQL database to the very expensive Oracle database. But they all have one thing in common: they are relational databases. Relational databases have a lot of advantages, but also a big disadvantage: accessing a large database can take quite some time and it can be unpredictable how long it will take. When you are creating some kind of report, this is acceptable. But in a real-time environment this might lead to disruptions. Digital Equipment Corporation (today a part of Hewlett-Packard) created on their VAX/VMS computers a different kind of database: a network database called DBMS32. 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 (records) 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. This is, of course, only true if a set (relation) is defined at database design time. Searching through the database as you would do in a relational database is still possible, but that must be implemented within the application. The advantage of implementation within the application is the control of the flow. If the result of a query is unexpectedly large, there might be problems with allocating memory or with the time it takes when using a relational database. In your application you could specify a limit on the results and abort the action, instead of freezing up or crashing.
Base de données réseau vs base de données relationnelle
Aujourd'hui, vous avez le choix entre différentes bases de données, allant de la base gratuite MySQL jusqu'à la très chère base de données Oracle. Mais elles ont toutes une chose en commun : ce sont des bases de données relationnelles. Les bases de données relationnelles ont de nombreux avantages, mais aussi un gros inconvénient : l'accès à une grosse base de données peut prendre un certain temps et ce délai n'est pas prévisible. Lors de la création d'un rapport, c'est acceptable. Mais dans un environnement temps réel, cela pourrait conduire à des perturbations.
Digital Equipment Corporation (aujourd'hui intégrée dans Hewlett-Packard) a créé sur ses ordinateurs VAX/VMS un genre différent de base de données : une base de données en réseau nommée DBMS32. Dans ce cas-ci, le mot « réseau » ne se réfère pas à un réseau local ou à l'Internet, mais à une organisation interne des données. Les différents types de données (les enregistrements) ne sont pas liés les uns aux autres par une relation mais par une liste à double lien. La recherche du membre premier/suivant/dernier se fait à la vitesse de l'éclair, parce que vous n'avez qu'à suivre le lien, plutôt que de lire tous les enregistrements de la base pour voir si la relation est satisfaite. Bien sûr, ceci n'est vrai que si un ensemble (la relation) a été défini à la conception de la base. Une recherche dans la base à la façon d'une base de données relationnelle est encore possible, mais cela doit être implémenté dans l'application. L'avantage de l'implémentation dans l'application est le contrôle du flux. Si le résultat d'une requête est trop important, il pourrait y avoir des problèmes d'allocation mémoire ou de temps nécessaire pour utiliser une base relationnelle. Dans votre application, vous pourriez préciser une limite pour les résultats et arrêter l'action, plutôt que de bloquer ou planter.
Another advantage of the use of linked lists in comparison to relations, is the order of the items in the linked list. This can be organized and changed, just as you wish, whereas, with a relation, you need to define some attribute to specify the order. When you insert or remove an item somewhere in the middle, the order attribute of ALL following items has to be changed, which is time consuming. In DBMS32 you can also use more than one list with the same set definition, so an item can be assigned to one or the other list or to none at all (but not to two or more lists). To create a network database, you must create a database definition and run a database generation program. This database definition cannot be changed at run time as with a relational database (define table as….). This makes a network database inflexible, but when you create a set of programs with a dedicated task (for exampe, to control a manufacturing machine), speed is more important then flexibility. Another advantage of using a database definition is the possibility of recreating the database in case of corruption (do you remember every change you made to your relational database before it became unusable?). Making a backup of your database will help, but I have witnessed an attempt to restore a backup, only to find the backup was incomplete or the result also was corrupted. No fun there.
Un autre avantage de l'utilisation des listes liées par rapport aux relations, est l'ordre des éléments dans la liste liée. Ceci peut être organisé et changé à souhait, alors qu'avec une relation, vous devez définir un attribut pour spécifier l'ordre. Quand vous insérez ou retirez un élément quelque part au milieu, l'attribut d'ordre de tous les éléments suivants devra être changé, ce qui prend beaucoup de temps. Dans DBMS32, vous pouvez aussi utiliser plus d'une liste avec la même définition du jeu ; ainsi, un élément peut être assigné à l'une ou l'autre liste ou à aucune (mais pas à deux listes ou plus).
Pour créer une base de données réseau, vous devez créer une définition de la base de données et faire tourner un programme de génération de la base. Cette définition de la base de données ne peut pas être modifiée en cours d'usage comme dans une base de données relationnelle (définir la table comme …). Ceci rend la base de données réseau rigide, mais quand vous créez un ensemble de programmes avec une tache dédiée (par exemple, piloter une machine de production), la vitesse est plus importante que la flexibilité.
Un autre avantage d'utiliser une définition de base de données est la possibilité de recréer la base si elle est corrompue (vous souvenez-vous de chaque modification que vous avez faite dans votre base de données relationnelle avant qu'elle ne devienne inutilisable ?). La sauvegarde de la base de données peut aider, mais j'ai été témoin d'une tentative de restauration, où on a constaté que la sauvegarde était incomplète ou que le résultat était corrompu aussi. Ce n'est pas drôle !
And what about a planned change to the database? At execution time, the changes must be implemented manually - which takes time - and what if you make a mistake? What if the entire change has to be rolled back? Using DBMS32 you can already change the database definition, create a new database, and at execution time unload the old and load the new database. The same mechanism can be used to go back to the old database definition in case the entire change must be rolled back. This gives you complete version control. Drawback is that you have to recompile and link all of the programs using the database, as they all have to get aware of the changed layout. But that can be done (and tested!) before the change is executed. When unloading the database, you get the contents of the database in readable form, in a text file. If your database is very large, this text file is also very large and the unload process will take some time. This may be unacceptable, in which case a network database is not suited for your task.
Et pour ce qui est d'un changement planifié dans votre base de données ? En cours d'exécution, les changements doivent être effectués à la main - ce qui prend du temps - et si vous faites une erreur ? Et si vous devez annuler tous vos modifications ? En utilisant DBMS32, vous pouvez déjà changer la définition de la base, créer une nouvelle base, et en cours de fonctionnement, décharger l'ancienne base et charger la nouvelle. Le même mécanisme peut être utilisé pour revenir à l'ancienne définition de la base au cas où toutes les modifications doivent être annulées. Ceci offre un total contrôle de version.
L'inconvénient est que vous devez recompiler et relier tous les programmes utilisant la base de données, car ils doivent tous être avertis du changement de la disposition. Mais cela peut être fait (et testé !) avant d'exécuter la modification.
Quand une base de données est déchargée, vous obtenez le contenu de la base sous une forme lisible, dans un fichier texte. Si votre base de données est très grande, ce fichier texte sera aussi très grand et le processus de déchargement prendra du temps. Ceci peut être inacceptable, ce qui rend l'usage d'une base de données réseau inadaptée à votre besoin.
Because the unload file is plain text, you can modify the contents of your database using a simple text editor. You can cut a large amount of records connected to one record, and paste it to a different record, in one move. This saved my ass last Christmas! For the communication with the application, DBMS32 uses shared memory called the User Work Area (UWA). The application fills a part of the UWA with data, and then calls a database request, specifying what is to be done. A program called DATABASE_MANAGER handles the request, taking the data from the UWA, accessing the physical database, and puts the result back in the UWA. In the UWA there is space for exactly one record of every type, so each request to read the database can have only one result.
Parce que le fichier de déchargement est en texte brut, vous pouvez modifier les enregistrements de votre base en utilisant un simple éditeur de texte. Vous pouvez couper une grande quantité d'enregistrements connectés à un enregistrement, et la coller à un autre enregistrement, d'un seul coup. Ceci a sauvé mon dernier Noël !
Pour la communication avec l'application, DBMS32 utilise de la mémoire partagée appelée User Work Area (UWA - zone de travail de l'utilisateur). L'application remplit une partie de l'UWA avec des données, et ensuite appelle une requête sur la base de données, spécifiant ce qui doit être fait. Un programme appelé DATABASE_MANAGER prend en charge cette requête, en prenant les données dans l'UWA, en accédant à la base de données physique et en mettant le résultat dans l'UWA. Dans l'UWA, il y a la place pour exactement un enregistrement de chaque type, de sorte que chaque requête pour lire la base ne peut avoir qu'un seul résultat.
My implementation DBMS32 was created in the 1980's. Memory and hard-disks were expensive and therefore limited. When you designed a database using DBMS32, you had to think carefully about the distribution of the data over the available hard-disks. Nowadays, we don't care anymore because disk space is cheap and abundant. Some of the specifications in the original database definition file are therefore obsolete. When you are migrating from a VAX/VMS system to Linux, you do not have to remove these items, because in my implementation they will simply be ignored. No changes to the definition file necessary! Modern relational databases use TCPIP for the communication between an application and the database. Besides decoupling of application and database, this also makes it possible to put the database on a different server somewhere on the network. Multiple computers could connect at the same time to such a database. For the use of DBMS32 it was not necessary that TCPIP was installed, and only local hard-disks could be used. In my implementation, I decided to keep it so. In DBMS32, you were assigning groups of records to “AREA”s (files) and, for each “AREA”, specifying on what disk and directory it resides. In my implementation, every record gets its own file, and all files reside in the same disk and directory. There is no DATABASE_MANAGER, and every application accesses the record files itself by mapping them into shared memory (“memory mapped files”). Synchronization and locking are handled through the same shared memory. The use of shared memory makes it possible that the operating system controls the assignment of physical memory and how much of the record files are in fact read and loaded in memory. This allows for the use of very large record files without the use of a huge amount of memory and large access times.
Mon implémentation
DBMS32 a été créée dans les années 80. Les mémoires et les disques durs étaient chers et donc limités. Quand vous conceviez une base de données utilisant DBMS32, vous deviez réfléchir posément à la distribution des données dans les différents disques durs disponibles. Aujourd'hui, nous n'y faisons plus attention car l'espace disque est bon marché et abondant. Certaines spécifications du fichier de définition de la base de données d'origine sont donc obsolètes. Quand vous migrez d'un système VAX/VMS vers Linux, vous n'avez pas à retirer ces éléments, car, dans mon implémentation, ils sont simplement ignorés. Aucune modification du fichier de définition n'est nécessaire !
Les bases de données relationnelles modernes utilisent TCPIP pour la communication entre une application et la base. En plus de désolidariser l'application et la base, ceci permet de mettre la base sur un serveur séparé quelque part dans le réseau. De nombreux ordinateurs peuvent être connectés en même temps à une telle base de données. Pour utiliser DBMS32, il n'était pas nécessaire que TCPIP soit installé, et seuls des disques durs locaux pouvaient être utilisés. Dans mon implémentation, j'ai décidé de le garder tel quel. Dans DBMS32, vous assignez des groupes d'enregistrements à des « AREA » (« zones », en fait des fichiers) et, pour chaque « AREA », vous spécifiez sur quel disque et dans quel répertoire elle réside. Dans mon implémentation, chaque enregistrement a son propre fichier, et tous les fichiers sont sur les mêmes disque et répertoire. Il n'y a pas de DATABASE_MANAGER (gestionnaire de la base) et chaque application accède aux fichiers d'enregistrement eux-mêmes en les modélisant dans la mémoire partagée (« memory mapped files », fichiers modélisés en mémoire). La synchronisation et la préemption sont gérées via la même mémoire partagée. L'utilisation d'une mémoire partagée rend possible le contrôle par le système d'exploitation de l'assignation de la mémoire physique et la quantité de fichiers d'enregistrement qui sont en fait lus et chargés en mémoire. Ceci permet l'utilisation d'un très grand nombre d'enregistrements sans l'utilisation d'une énorme quantité de mémoire et sans temps d'accès démesurés.
Changes to the database are also written to the journal file with a timestamp. When you create a full backup at regular intervals, and incremental backups on a smaller interval (a new journal file is created every time a backup is created), you can restore the database to any point in time on another computer. You would simply copy a set of connected files (full + incremental backup + journal file) to this computer, and restore the database up to time X. This allows for analyzing the data in the database at exactly (within a millisecond) the time a “bad thing happened”. My clone of DBMS32 consists of four programs. The first is the database generator. It reads the database description and creates all type definitions and database access routines for the applications, plus routines for use by the other programs. The second program is a GUI type of replacement for DBQ, the database query program of DBMS32. It can be used to read - and navigate through - the database without intervening with the production applications and to manage the database. Managing the database includes the creation of the record files for a new (empty) database, (un)loading the database, making a full or incremental backup and restoring a backup. The last two actions are executed using the remaining two programs. Because these programs are run separately, they can also be started from the terminal or by a script, allowing for the aforementioned creation of backups at a regular interval.
Les modifications de la base de données sont aussi inscrites dans le fichier journal avec un horodatage. Quand vous créez une sauvegarde complète à intervalles réguliers et des sauvegardes incrémentales sur des intervalles plus réduits ( un nouveau fichier journal est créé chaque fois qu'une sauvegarde est créée), vous pouvez restaurer la base de données à n'importe quel instant sur un autre ordinateur. Vous copieriez simplement un ensemble de fichiers connectés (sauvegarde complète + incrémentales + le fichier journal) sur cet ordinateur, vous restaureriez la base de données à l'instant X. Ceci permet d'analyser les données de la base au moment exact (à une milliseconde près) où un « malheureux événement est arrivé ».
Mon clone de DBMS32 est constitué de quatre programmes. Le premier est le générateur de base de données. Il lit la description de la base et crée toutes les définitions de fichiers et les routines d'accès à la base par les applications, plus les routines utilisées par d'autres programmes. Le second programme est une interface utilisateur graphique en remplacement de DBQ, le programme de requête de base de données de DBMS32. Il peut être utilisé pour lire - et naviguer dans - la base de données, sans interférer avec les programmes de production, et pour gérer la base. La gestion de la base de données inclut la création de fichiers d'enregistrement pour une nouvelle base (vide), le (dé)chargement de la base, la sauvegarde, complète ou incrémentale, et la restauration. Ces deux dernières actions sont exécutées en utilisant les deux programmes restants. Parce que ces programmes tournent séparément, ils peuvent aussi être lancés depuis un terminal ou par un script, permettant la création de sauvegardes à intervalles réguliers, comme mentionné plus haut.
Conclusion This is the last part of my series about the migration of VAX/VMS to Linux. Although I talk about the VAX, this article is in fact valid for all computers using OpenVMS, so also for the Alpha. The most important requirement is that your programs are created with Pascal. Because I am going into early retirement, I have a lot of time to assist you if you still have one or more of these “old girls”. Migration to Linux is not only less expensive, the most important advantage is that the result is predictable. No functionality “lost in translation”, no production loss, no hidden bugs (unless already present…) that will hit you at the worst possible moment, and no intrusion from hackers or viruses to stop your production. I hope you enjoyed reading my series. If you want to know more about VMS, Pascal or DBMS32 (or network databases in general), you can always send me an email: info@theovanoosten.nl.
Conclusion
C'est la dernière partie de ma série sur la migration de VAX/VMS vers Linux. Bien que je parle du VAX, cet article est en fait aussi valable pour tous les ordinateurs utilisant openVMS, et aussi pour l'Alpha. L'impératif le plus important est que vos programmes soient écrits en Pascal. Parce que je prends ma retraite sous peu, j'aurai beaucoup de temps pour vous aider si vous avez encore une ou plusieurs de ces « vieilles filles ». La migration vers Linux n'est pas seulement moins chère, l'avantage le plus important est que le résultat est prévisible. Pas de fonctionnalité « perdue pendant le transfert », pas de perte de production, pas de bug caché (sauf s'il est déjà présent…) qui vous touchera au pire moment et pas d'intrusion de hackers ou de virus pour arrêter la production.
J'espère que vous avez aimé lire ma série. Si vous voulez en savoir plus sur VMS, Pascal ou DBMS32 (ou les bases de données réseau, plus généralement), vous pouvez toujours m'envoyer un mail à : info@theovanoosten.nl.