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 terminal interface DCL and ASTs.
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 les interfaces de terminal DCL et AST.
DCL When you log on to a Linux system (or start the terminal), a program is started to prompt you for commands. This is called the shell, and in my case this program is Bash. When you log on to a VMS system, the same happens. On VMS, this program is called DCL (Digital Command Language). For the user, it looks like there is no difference, but the way these programs work is quite different. As mentioned in part 3, there is one big difference: DCL is a real shell, it wraps around a process and every time an executable (“image” in VMS) is started, it runs within this shell, within the same memory, with the same logicals and symbols (environment variables), and with the same process ID. Bash is called a shell, but it is NOT! It is a CLI (Command Line Interpreter). Every time an executable is started in Linux, it's started in a new subprocess with a different PID.
DCL
Quand vous vous identifiez dans un système Linux (ou ouvrez un terminal), un programme est lancé pour vous demander les commandes. Il est appelé le « shell » et, dans mon cas, le programme est Bash. Quand vous entrez dans un système VMS, c'est identique. Sur VMS, le programme s'appelle DCL (Digital Common Language - Langage commun de Digital).
Pour l'utilisateur, il semble qu'il n'y a pas de différence, mais la façon dont les deux programmes fonctionnent est très différente. Comme indiqué dans la partie 3, il y a une grosse différence : DCL est un vrai shell, qui enveloppe un processus et chaque fois qu'un exécutable (une « image » dans VMS) est démarré, il tourne dans ce shell, avec la même mémoire, avec les mêmes logicals et symboles (variables d'environnement) et avec le même identifiant (ID) de processus. On dit que Bash est un shell, mais c'est FAUX ! C'est un interpréteur de ligne de commande (CLI - Command Line Interpreter). Chaque fois qu'un exécutable est démarré dans Linux, il est lancé dans un nouveau sous-processus avec un PID (ID de processus) différent.
Another difference is the use of the “$”-character. In VMS, it has no meaning and is frequently used in names of logicals (like SYS$SYSTEM), system calls (like $QIOW) and internal DCL functions (like F$ELEMENT). In Bash, it denotes the translation of variables, even if in between double quotes. This - and the fact that Free Pascal has a similar problem - is the reason why the migration tool replaces the dollar with an underscore. DCL has a powerful set of built-in commands and functions. These are so versatile that entire programs have been written in DCL functions. When you migrate a VMS system to Linux, you will have to include these “programs”. The functions of bash to replace the functions of DCL are so different in syntax and working, that the migration of DCL “programs” is a lot of work and some will simply fail to migrate as there might be no substitution for one or more DCL functions. An example - to read a file is shown below. In DCL every line must start with a “$”, or it will not see it as a command.
Une autre différence est l'utilisation du caractère « $ ». Dans VMS, il n'a pas de signification et est fréquemment utilisé dans les noms des logicals (comme SYS$SYSTEM), des appels système (comme $OIOW) et des fonctions internes DCL (comme F$ELEMENT). Dans Bash, il marque la translation de variables, même entre guillemets anglais doubles. Ceci - et le fait que FreePascal a le même problème - est la raison pour laquelle l'outil de migration remplace le dollar par un trait de soulignement.
DCL a un jeu puissant de commandes et fonctions intégrées. Elle sont si variées que des programmes entiers ont été écrits avec des fonctions DCL. Quand vous migrez un système VMS vers Linux, vous devrez inclure ces « programmes ». La syntaxe et l'exécution des fonctions de bash qui remplaceraient les fonctions de DCL sont si différentes que la migration des « programmes » DCL représente beaucoup de travail et la migration de certains pourrait échouer puisqu'il n'existerait éventuellement pas de remplacement pour l'une ou l'autre des fonctions DCL. Un exemple : la lecture d'un fichier est présentée ci-dessous.
Dans DCL, chaque ligne commence par un $ ; sinon, elle n'est pas vue comme une commande.
In Linux, the first parameter on a command-line is denoted as 1, while the same parameter in VMS is denoted as P1. The translation of a variable in Linux is done by prefixing with a $; in VMS by enclosing in single quotes, hence $1 in Linux is 'P1' in VMS. “echo” writes a line to the terminal in Linux; in VMS, “write sys$output” is used. “sys$output” is a process-logical (for explanation of logicals see part 3), so, by redefining “sys$output”, you can influence where the output is going. “file_var” in the above example is also a logical. As a consequence, this means that, if the file is not closed, it will still be open if the same script (command file) is executed again in the same session. That might be intentional if two scripts have to be executed consecutively, but it's usually a big problem when a script crashes and you start it again after fixing the problem. Then the file is still open and continues from the point where the script crashed, giving unexpected results. In this case, after a crash, you have to close the file manually by deleting the logical.
Dans Linux, le premier caractère d'une ligne de commande est noté 1, alors que le même paramètre dans VMS est noté P1. La translation d'une variable dans Linux est faite en préfixant avec un $ ; et dans VMS, en l'entourant de guillemets anglais simples, d'où, ce qui est $1 dans Linux est 'P1' dans VMS. « echo » écrit un ligne sur le terminal dans Linux ; dans VMS, on utilise « write sys$output ». « sys$output » est un logical processus (pour des explications sur les logicals, voir la partie 3) ; ainsi, la redéfinition de « sys$output » peut avoir des conséquences sur la destination de la sortie.
« file_var », dans l'exemple ci-dessus, est aussi un logical. Par conséquence, cela signifie que, si le fichier n'est pas fermé, il sera encore ouvert si le même script (fichier de commande) est exécuté à nouveau dans la même session. Ça peut être intentionnel si deux scripts successifs doivent être exécutés l'un après l'autre, mais c'est en général un gros problème quand un script plante et que vous le redémarrez après avoir résolu le problème. À ce stade, le fichier est encore ouvert et continue à partir du moment où le script a planté, donnant des résultats imprévisibles. Dans ce cas, après un plantage, vous devez fermer le fichier manuellement en effaçant le logical.
I cannot imagine how a migration tool would be able to create a working bash script from a DCL script (in VMS this is called a command-file, default file type is .COM). So I started working on the creation of a DCL clone. It will be able to process DCL command-files while accepting commands from the command-line using DCL syntax. An example: To get the list and translation of the group logicals in Linux, I must execute the case-sensitive command: /VMS/show log -g “*” . My DCL program will accept the standard case-insensitive command: show log /group * . This way, every existing DCL “program” will behave the same with only small adaptations.
J'ai du mal à imaginer comment un outil de migration serait capable de créer un script bash fonctionnel à partir d'un script DCL (dans VMS, c'est appelé un fichier de commande, avec type de fichier par défaut .COM). Aussi, j'ai commencé à travailler sur la création d'un clone de DCL. Il sera capable d'exécuter des fichiers de commande DCL tout en acceptant des commandes à partir de la ligne de commande en utilisant la syntaxe DCL. Un exemple : pour obtenir la liste et la transladtion des logicals group dans Linux, je dois exécuter la commande sensible à la casse :
/VMS/show log -g “*” .
Mon programme DCL acceptera la commande standard sensible à la casse :
show log /group * .
De cette manière, chaque « programme » DCL existant se comportera de la même façon avec seulement de petites adaptations.
ASTs In VMS, all communication with the terminal goes through the driver “TTDRV”. When the user gives a special command using control characters (mostly ^C, ^Y, ^T and ^Z), the driver will issue an AST (Asynchronous System Trap). Essentially, an AST is a system callback routine. As it is unknown when this callback routine is called, you must take special precautions. In VAX-pascal you signal this to the compiler through the attribute “[ASYNCHRONOUS]” for the procedure that is called, and the attribute “[VOLATILE]” for any variable accessed from within this procedure. The attribute “[VOLATILE]” prevents the compiler from doing any optimization that would make the variable inaccessible, like using a CPU register for it. ASTs can be compared to signal catching in Linux.
Les AST
Dans VMS, toutes les communications avec le terminal passent par le pilote « TTDRV ». Quand l'utilisateur donne une commande spéciale en utilisant des caractères de contrôle (principalement ^C, ^Y, ^T et ^Z), le pilote sortira un AST (Asynchronous System Trap - Piège système asynchrone). Essentiellement, un AST est une routine de rappel système. Comme on ne sait pas quand cette routine de rappel sera appelée, vous devez prendre des précautions particulières. Dans Pascal VAX, vous le signalez au compilateur par l'attribut « [ASYNCHRONOUS] » pour la procédure qui est appelée et l'attribut « [VOLATILE] » pour toute variable utilisée dans cette procédure. L'attribut « [VOLATILE] » empêche le compilateur de réaliser toute optimisation qui rendrait la variable inaccessible, comme utiliser un registre du CPU pour elle. L'AST peut être comparé à la capture de signal dans Linux.
The best equivalent of these ASTs is the use of the method “Synchronize” of the class “tthread”. To get the same behavior as in VMS, the DCL process is used to process all input from the terminal and output to the terminal. The DCL process communicates through pipes with a separate thread created at program start using the class “tthread”. When the user presses any of the special control characters, this thread will call a dedicated procedure - defined in the class, but executed in the main thread - using “Synchronize”. On ^C, the process will terminate; on ^Y, the main thread will be suspended; on ^T, status information will be sent to the terminal (if specified in the main thread), and on ^Z, a controlled termination will take place. When the main thread is suspended after ^Y, two things can happen: • If “continue” is typed in the DCL process, the main thread will be resumed. • If a new command is given, resulting in the start of another process, the suspended process will be terminated.
Le meilleur équivalent de ces AST est l'utilisation de la méthode « Synchronize » de la classe « tthread ». Pour obtenir le même comportement que dans VMS, Le processus DCL est utilisé pour exécuter toutes les entrées depuis le terminal et toutes les sorties vers le terminal. Le processus DCL communique à travers des tubes (« pipes ») avec un fil (« thread ») séparé, créé au début du programme en utilisant la classe « tthread ». Quand l'utilisateur appuiera sur l'un des caractères spéciaux de contrôle, ce fil appellera une procédure dédiée - définie dans la classe, mais exécutée dans le fil principal - en utilisant « Synchronize ». Sur ^C, le processus sera terminé ; sur ^Y, le fil principal sera mis en attente ; sur ^T, l'information d'état sera envoyée au terminal (si c'est spécifié dans le fil principal) et, sur ^Z, une fin contrôlée sera réalisée. Quand le fil principal est mis en attente, deux choses peuvent arriver : • Si « continue » est saisi dans le processus DCL, le fil principal reprendra. • Si une nouvelle commande est donnée, démarrant un autre processus, le processus suspendu sera terminé.
To get this behavior, DCL must be aware of the control characters and act upon them. Something like the attribute “[VOLATILE]” is not necessary as I have not seen Free Pascal doing any optimization (unfortunately). On activation of a QIO(W) (see part 2) or timer, it is also possible to specify an AST to be called on termination. These are implemented the same way, as both work through the creation of a new thread.
Pour obtenir ce comportement, DCL doit être averti des caractères de contrôle et agir s'ils sont utilisés.
Quelque chose comme l'attribut « [VOLATILE] » n'est pas nécessaire, car je n'ai pas vu Free Pascal faire de l'optimisation (malheureusement).
Sur l'activation d'un QIO(W) (voir partie 2) ou d'un temporisateur, il est possible de spécifier qu'un AST soit appelé à la fermeture. Ceux-ci sont implémentés de la même façon, car tous les deux fonctionnent via la création d'un nouveau fil.
Detached process: If you start a detached process (a process without a parent) in VMS, it is started without DCL as a shell. Some programs depend on the existence of DCL - if they call an internal function. To run such a program, you must create a command-file stating: “$run program_name”, and start DCL as a detached process with this command file as input. This proves that DCL itself is just a program which is called “LOGINOUT.EXE” . The most common use of this is to execute a script (command-file) as a detached program, for example once a day to clean up, back up, or trigger an event. Next month In the next article I will go more in depth about the network database DBMS32 and its (dis)advantages.
Processus détaché :
Si vous démarrez un processus détaché (un processus sans parent) dans VMS, il démarre sans DCL comme un shell. Certains programmes dépendent de l'existence de DCL, s'ils appellent une fonction interne. Pour lancer un tel programme, vous devez créer un fichier de commande déclarant « $run program_name » et démarrer DCL comme un processus détaché avec le fichier de commande comme entrée. Ceci démontre que DCL lui-même n'est qu'un programme qui est appelé « LOGINOUT.EXE ».
L'usage le plus classique de celui-ci est pour l'exécution d'un script (fichier de commande) comme programme détaché : par exemple, une fois par jour pour nettoyer, sauvegarder ou déclencher un événement.
Le mois prochain
Dans le prochain article, j'approfondirai le sujet de la base de données de réseau DBMS32 et ses (dés)avantages.