NOTE: Parts 1-6 are FCM#105-110 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 (FCM#105), you could migrate from VAX/VMS to Linux, as the way Linux works is largely compatible with OpenVMS. 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 OpenVMS with no apparent replacement in Linux. In this article, I will update you with improvements and experience since my last article. Early retirement? In the conclusion of part 6, I told you that I was going into early retirement. That was a big mistake. Two years later I was approached for a position in Vienna where they had a few 20 year old Alpha’s and now I am working there for three years already. And if I listen to the customer, I get the idea that I will be working there long after my retirement.
NOTE : Les parties 1 à 6 sont dans les FCM n° 105 à 110
Aux premiers temps des ordinateurs, une société appelée Digital Equipment Corporation (DEC) a créé son ordinateur VAX 32-bit en utilisant OpenVMS comme système d'exploitation. Un ordinateur VAX/VMS est si fiable qu'il y en a encore aujourd'hui - après plus de 25 ans - un grand nombre en service. Mais, à terme, même ces ordinateurs fiables devront être remplacés. Comme décrit dans la première partie (FCM n° 105), vous pourriez migrer de VAX/VMS vers Linux, car le fonctionnement de Linux est largement compatible avec OpenVMS. Si vous utilisez le Pascal comme langage de programmation, vous trouverez que Lazarus/Free Pascal est un bon remplacement. Mais il y a des fonctions techniques utilisées dans OpenVMS sans remplacement apparent dans Linux. Dans cet article, je vais vous mettre à jour avec les améliorations et l'expérience depuis mon dernier article.
Retraite anticipée ?
Dans la conclusion de la partie 6, je vous ai dit que j'allais prendre une retraite anticipée. C'était une grosse erreur. Deux ans plus tard, j'ai été approché pour un poste à Vienne où ils avaient quelques Alpha de 20 ans et maintenant je travaille là-bas depuis trois ans déjà. Et si j'écoute le client, j'ai l'impression que je travaillerai là-bas bien après ma retraite.
File version numbers In part 4 of my article, I told you that “If your project is depending on this behavior (the file version, not the crashing), you will have to change your programs. Either by adding a version number to the name or type, or by changing your project in such a way it will no longer depend on the file versions.” My very first potential customer (my current job) was heavily relying on these file version numbers. One job is being started many times with different parameters, so many log files are being created with the same name. So I changed my file handling routines to use version numbers. As Linux does not have an equivalent, I solved it by adding (and expecting) the file version number as a part of the filename in the format “;1234”. As this is a string, and not a 16-bit number, the restriction of the maximum of 32767 is lifted. That might cause problems in a project that relies on that maximum, but that’s something for the future. Another issue with log files of batch jobs is that if you ask the system what the log file of job xxxx is, you will get the filename and location only. You have to use tricks like writing a token in the current log file and search through all versions for that token to find the file version number. This made me change my implementation of the batch by including the file version number as soon as the job starts.
Numéros de version des fichiers
Dans la partie 4 de mon article, je vous disais que « Si votre projet dépend de ce comportement (la version du fichier, pas le plantage), vous devrez modifier vos programmes. Soit en ajoutant un numéro de version au nom ou au type, soit en modifiant votre projet de manière à ce qu'il ne dépende plus des versions de fichiers. » Mon tout premier client potentiel (mon travail actuel) dépendait fortement de ces numéros de version de fichiers. Un travail est lancé plusieurs fois avec des paramètres différents, et de nombreux fichiers journaux sont créés avec le même nom. J'ai donc modifié mes routines de traitement des fichiers pour utiliser les numéros de version. Comme Linux n'a pas d'équivalent, j'ai résolu le problème en ajoutant le numéro de version du fichier comme partie du nom de fichier au format « ;1234 » en m'attendant à ce que cela fonctionne. Comme il s'agit d'une chaîne de caractères, et non d'un nombre de 16 bits, la restriction du maximum de 32767 est levée. Cela pourrait causer des problèmes dans un projet qui s'appuie sur ce maximum, mais c'est quelque chose pour l'avenir.
Un autre problème avec les fichiers journaux des tâches batch est que si vous demandez au système quel est le fichier journal de la tâche xxxx, vous n'obtiendrez que le nom du fichier et son emplacement. Vous devez utiliser des astuces comme l'écriture d'un jeton dans le fichier journal actuel et la recherche de toutes les versions de ce jeton pour trouver le numéro de version du fichier. Cela m'a amené à modifier mon implémentation du batch en incluant le numéro de version du fichier dès le début du travail.
Graphical DCL debugger When trying my first real migration, I ran into difficulties. Not knowing if my implementation of DCL is wrong (yes, I found a bunch of bugs), I needed a way to see what’s going on while a script is being executed. The normal way to debug a DCL script is to put in some write or show commands. But this is very tedious and you have to put the commands in at exactly the right points, which you do not know upfront. If only you could debug a DCL script the same way you would debug a program. I have created exactly that. A graphical application with breakpoints, watchpoints, and a continuous display of symbols, local and global. You can specify a break on exit, to determine which exit point a routine takes (including error exit). So you have the opportunity to see what the value of the local symbols are on exit (or the cause of the error). I wished I had this application years ago.
Débogueur graphique de DCL
En essayant ma première vraie migration, j'ai rencontré des difficultés. Ne sachant pas si mon implémentation de DCL était mauvaise (oui, j'ai trouvé un tas de bogues), j'ai eu besoin d'un moyen pour voir ce qui se passe pendant l'exécution d'un script. La façon normale de déboguer un script DCL est de placer des commandes write ou show. Mais c'est très fastidieux et vous devez placer les commandes exactement aux bons endroits, ce que vous ne savez pas au départ. Si seulement vous pouviez déboguer un script DCL de la même manière que vous déboguez un programme.
C'est exactement ce que j'ai créé. Une application graphique avec des points d'arrêt, des points de surveillance et un affichage continu des symboles, locaux et globaux. Vous pouvez spécifier une pause à la sortie, pour déterminer le point de sortie d'une routine (y compris la sortie par erreur). Vous avez donc la possibilité de voir la valeur des symboles locaux à la sortie (ou la cause de l'erreur). J'aurais aimé avoir cette application il y a des années.
Codasyl database extensions In part 6 I told you about a different kind of database: a network database called DBMS32. In fact I should have called it a Codasyl database. This kind of database has been around longer than relational databases, and even had a normalization committee. My implementation is loosely based on the formalized specification. When my customer was facing the problem that a chain of jobs took way too long (6 – 7 hours), I started a feasibility study to see if I could do it better using my Codasyl database instead of Oracle. And of course I ran into the limitations of a Codasyl database. As it is designed for speed, it is not suitable for large sets of data. But I didn't give up and tweaked my implementation to handle millions of records and introduced indices to keep the speed. Oracle uses special tables for indices that need to be updated. Those tables can get fragmented, so it helps to do a rebuild once in a while. But that can take more than an hour, and the tables that use these indices are blocked during that time (a problem that is very current at my customer). In my implementation, the build is so fast (less than a second) that I decided to do it on-the-fly instead of stored. The end result was a processing time of less than half an hour, so more than 10 times faster. I was also telling you about a graphical application to replace DBQ, the database interface program. I have extended this application with a graphical representation of the interlinked data, with the possibility of moving records (with your mouse) within a list to change the order.
Extensions de la base de données Codasyl
Dans la partie 6, je vous ai parlé d'un autre type de base de données : une base de données réseau appelée DBMS32. En fait, j'aurais dû l'appeler « base de données Codasyl ». Ce type de base de données, qui existe depuis plus longtemps que les bases de données relationnelles, a même eu un comité de normalisation. Mon implémentation est vaguement basée sur la spécification formalisée. Lorsque mon client a été confronté au problème qu'une chaîne de travaux prenait beaucoup trop de temps (6 à 7 heures), j'ai commencé une étude de faisabilité pour voir si je pouvais faire mieux en utilisant ma base de données Codasyl au lieu d'Oracle. Et, bien sûr, je me suis heurté aux limites d'une base de données Codasyl. Conçue pour la vitesse, elle n'est pas adaptée aux grands ensembles de données.
Mais je n'ai pas abandonné : j'ai modifié mon implémentation pour gérer des millions d'enregistrements et j'ai introduit des indices pour conserver la vitesse. Oracle utilise des tables spéciales pour les index qui doivent être mis à jour. Ces tables peuvent être fragmentées, il est donc utile de les reconstruire de temps en temps. Mais cela peut prendre plus d'une heure, et les tables qui utilisent ces index sont bloquées pendant ce temps (un problème très courant chez mon client). Dans mon implémentation, la reconstruction est si rapide (moins d'une seconde) que j'ai décidé de la faire à la volée au lieu de la stocker. Le résultat final est un temps de traitement de moins d'une demi-heure, donc plus de 10 fois plus rapide.
Je vous parlais également d'une application graphique pour remplacer DBQ, le programme d'interface de la base de données. J'ai étendu cette application avec une représentation graphique des données liées entre elles, avec la possibilité de déplacer les enregistrements (avec votre souris) dans une liste pour en changer l'ordre.
Conclusion As you can see, I haven’t been inactive in the last 5 years. My new job is challenging, time consuming (up to 10 hours a day plus on the weekends), and is challenging all of my competences, but can also be boring from time to time. So if you have a new challenge for me, like speeding up your application by using my implementation of a Codasyl database, you can always send me an email or contact me through LinkedIn.
Conclusion
Comme vous pouvez le constater, je n'ai pas été inactif au cours des 5 dernières années. Mon nouveau travail est stimulant, prend beaucoup de temps (jusqu'à 10 heures par jour plus les week-ends) et met à l'épreuve toutes mes compétences, mais peut aussi être ennuyeux de temps en temps. Donc si vous avez un nouveau défi à me proposer, comme accélérer votre application en utilisant mon implémentation d'une base de données Codasyl, vous pouvez toujours m'envoyer un e-mail ou me contacter via LinkedIn.