Nous, les utilisateurs d'Ubuntu sommes des gens modernes. Nous utilisons des tablettes et des smartphones qui n'existaient même pas il y a dix ans. Nous attendons impatiemment que chaque version successive d'Ubuntu soit plus révolutionnaire que la dernière, parue il y a seulement six mois. N'est-ce pas le progrès ? N'est-ce pas bien là le 21e siècle avec sa vitesse de l'éclair ?

Il peut donc sembler assez bizarre d'écrire à propos d'un langage de programmation tel que le COBOL. Après tout, le Common Business-Oriented Language est né en l'an 1959, c'est-à-dire jadis, où la programmation ne consistait pas à exécuter du JavaScript dans un navigateur d'Internet et où le mot informatique ne se centrait pas encore sur la connexion de téléphones à écran tactile au dernier réseau mobile à haut débit. Dans ce temps-là, même regarder l'ordinateur vous faire des clignotements de lumière devait être toute une expérience. Pour mesurer la distance couverte par l'informatique pendant ces 56 années, disons seulement que je préférerais conduire tous les jours un véhicule construit en 1959 (un Land Rover Series II fera très bien l'affaire, merci) que la combinaison d'ordinateur et d'un compilateur de la même année.

Just before year 2000 and the infamous “year-2k bug” that was supposed to bite us all in the nose (but never quite did – because we were prepared for it!) it came to the attention of many IT department heads that a sizable portion of computer programs used had been originally written COBOL. This was mainly true in the finance industry. Having been passed from one generation of hardware to another and recompiled several times in the process, the programs handled most core processes and were well placed to last longer than the human programmers that had created them in the first place – and who were at that time heading towards retirement, if not already there. A scarcity of programmers of the younger generations able to comprehend, let alone maintain, code written in COBOL seemed to be in the cards. Fifteen years on, this still seems to be a bit of a concern even in year 2015, at least according to some. However, a large part of the programs must have needed to be re-written at some point if only to adapt to the needs of e-banking and e-business, and writing newer programs from scratch in COBOL is less often seen these days. However, the COBOL language still seems to have been maintained, with even an object-oriented version being announced in 2002 and a more advanced standard published in 2014. IBM seems to be a major player on the field, although it also gives active support to other offerings (such as Java) for programming mainframes. On the GNU/Linux side, OpenCOBOL (http://www.opencobol.org/) appeared to give us the possibility of compiling working programs on the most recent Ubuntu systems, which has then been re-branded (superseded) by GNU Cobol since version 1.1. It was mainly from a standpoint of historical interest that I installed this compiler, and managed to get an Euclidian Algorithm program up and running quite easily, with procedure calls and even some invocation of routines written in the C language by the side.

Juste avant l'année 2000 et le fameux « bogue de l'année 2000 » qui devait nous mordre tous (mais qui ne l'a jamais fait, puisque nous y étions préparés !) il est arrivé à l'attention de beaucoup de directeurs d'informatique qu'une proportion non négligeable des logiciels en fonctionnement avaient été écrits originalement en COBOL. Ce fut vrai surtout dans le secteur des finances. Ces programmes avaient été passés d'une génération de matériel à l'autre et recompilés plusieurs fois, mais traitaient la plupart des processus centraux et étaient bien partis pour survivre plus longtemps que les programmeurs qui les avaient conçus au départ, et qui se dirigeaient vers la retraite ou étaient déjà retraités. Il se produisit donc un manque de programmeurs parmi les nouvelles générations qui soient capables de comprendre, et certainement pas de maintenir, du code écrit en COBOL. Quinze ans plus tard, cela est toujours un facteur de préoccupation, du moins d'après certains. Toutefois, une grande proportion des programmes a du être réécrite à un certain moment, notamment pour s'adapter aux besoins des banques et du commerce électroniques ; on voit moins souvent aujourd'hui des logiciels en COBOL développés à partir de zéro.

Cela étant dit, le langage COBOL paraît avoir toujours été maintenu, avec même la parution d'une version orientée objets en 2002 et un standard plus avancé publié en 2014. IBM sembla être toujours un participant important, bien qu'il apporte aussi son appui actif à d'autres options (telles que le Java) pour ce qui est de la programmation d'ordinateurs centraux. Du côté GNU/Linux, OpenCOBOL (http://www.opencobol.org/) est apparu pour nous donner la possibilité de compiler des programmes utiles sur les systèmes Ubuntu les plus récents ; il a été rebaptisé (remplacé par) GNU Cobol depuis la version 1.1.

J'ai installé ce compilateur surtout pour son intérêt historique et suis arrivé à construire assez facilement un programme de Division Euclidienne, avec des appels à procédures et même l'invocation de routines écrits dans le langage C.

Installation Installation is the usual procedure on *buntu systems, since OpenCOBOL is available directly from the repositories. Simply use your favorite software package manager to install package open-cobol:

Son installation suit la procédure habituelle sur des systèmes *buntu, puisque OpenCOBOL est disponible directement depuis les dépôts. Utilisez simplement votre gestionnaire de logiciels préféré pour installer le paquet open-cobol :

# aptitude install open-cobol

When this is installed, we can directly fire up the COBOL compiler in a terminal and investigate which version we are using:

Une fois installé, nous pouvons exécuter le compilateur COBOL directement dans un terminal, et découvrir quelle version nous avons installée :

$ cobc --version 
cobc (OpenCOBOL) 1.1.0 
Copyright (C) 2001-2009 Keisuke Nishida / Roger While 
Built    Nov 02 2013 00:16:01 
Packaged Feb 06 2009 10:30:55 CET 

As can be seen from the dates quoted, development of this compiler is not going along at the supersonic speeds seen in some open-source projects. However, this suits quite well the COBOL mindset that goes more for “steady does it” and “piano, piano si va lontano” than seeking out instant results. The compiler documentation gives us some insight into which COBOL dialects are supported. The ground-breaking 2002 version is there, though the 2014 update is not (yet) there:

Les dates nous montrent que le développement de ce compilateur n'avance pas aux vitesses supersoniques que l'on voit chez certains projets de code Open Source. Mais cela concorde assez bien avec la mentalité de COBOL qui préfère cheminer doucement selon le principe de « qui va piano va sano » plutôt que de chercher à obtenir des résultats immédiats.

La documentation du compilateur nous informe sur les dialectes de COBOL qui sont pris en charge. La version séminale de 2002 y est, mais non (ou pas encore) celle de la mise à jour de 2014 :

 std=<dialect>        Compile for a specific dialect : 
                        cobol2002   Cobol 2002 
                        cobol85     Cobol 85 
                        ibm         IBM Compatible 
                        mvs         MVS Compatible 
                        bs2000      BS2000 Compatible 
                        mf          Micro Focus Compatible 
                        default     When not specified 

Compiling “Hello, world!” A very basic program in traditional, old-style fixed-format COBOL runs like this:

Voici un exemple de programme très basique, dans un COBOL traditionnel à format d'entrée fixe :

     IDENTIFICATION DIVISION. 
     PROGRAM-ID. HELLO-WORLD. 
     PROCEDURE DIVISION. 
         DISPLAY 'Hello, world'. 
         STOP RUN.

Note that this syntax -originally thought out for punched cards- is all about spacing. The first six characters on each line (columns 1 to 6) are reserved to identify each program line with a number – though nowadays numbers are no longer mandatory. Column 7 is an indicator area that can be used to mark a line as a commentary by inserting an asterisk “*” character in this space. Finally, only a maximum of 72 characters may be used in each line, thus leaving just 72 - 7 = 65 characters to write actual code in. Fire up your favorite text editing program, and type or paste in this text. Save the file as “hello.cob” or “hello.cbl” – COBOL source code file extensions vary a bit. Unfortunately, there are not many text editors in Ubuntu that can handle COBOL syntax highlighting. However, the jedit program is available, easily installable from the repositories, and does just that quite well: Once saved, let us compile our first program. We will need to use option “-x” to request the compiler to perform linkage as well as compilation proper, and produce an executable file:

Notez que cette syntaxe - conçue originalement pour les cartes perforées - est basée sur le compte de caractères. Les premiers six caractères de chaque ligne (les colonnes 1 à 6) sont réservés pour la numérotation de chaque ligne du programme, bien que les numéros de ligne ne soient plus obligatoires aujourd'hui. La colonne numéro 7 est utilisée pour indiquer que la ligne est un commentaire, avec le caractère « * ». Enfin, seulement 72 caractères en tout peuvent être utilisés pour chaque ligne, ne laissant que 72-7 = 65 caractères pour l'écriture du code lui-même.

Lancez votre éditeur de textes préféré et tapez ou collez-y ce texte. Enregistrez le fichier comme « hello.cob » ou « hello.cbl »“ – les extensions de fichiers source COBOL varient un peu. Malheureusement, il n'existe guère d'éditeurs sous Ubuntu qui sachent gérer le coloriage de la syntaxe COBOL. Mais le logiciel jedit est disponible, facile à installer depuis les dépôts, et le fait très bien :

Une fois le fichier créé, compilons notre premier programme. Nous indiquerons l'option « -x » pour demander au compilateur de faire le linking en plus de la compilation en soi, produisant ainsi un fichier exécutable :

$ cobc hello.cob -x

Here we have our source code, and the executable program, which can then be executed:

Nous avons ainsi le fichier code source, et le programme exécutable qui peut alors être exécuté :

$ ls 
hello  hello.cob 
$ ./hello 
Hello, world 

It is noteworthy that, since I was doing this on a 64-bit version of Linux Mint, what the compiler produced is in fact a 64-bit executable file! I wonder what the original creators of the language would have thought of that:

Il est intéressant de noter que, puisque je faisais cette compilation sous une version 64-bits de Linux Mint, le compilateur vient en fait de produire un fichier exécutable en code 64-bits ! Je me demande ce que les concepteurs originels du langage en auraient pensé :

$ ldd hello 
[...]
/lib64/ld-linux-x86-64.so.2 (0x00007f277d149000) 

Free-form and procedures The programing world has gone forward a tad since the original specification for COBOL was published. Among other things, writing programs in ALL CAPITAL LETTERS is no longer considered the only true way of getting things done, and modern script-kiddies would have difficulties abiding with the very strict column syntax of earlier versions. This why later COBOL dialects have progressively reduced the constraints on formal program presentation, giving up free-form syntax. Some of the parts, such as the identification division, no longer need to be specified. The same HelloWorld program may be written in free form in the following manner:

Le monde de la programmation a avancé un peu depuis que la spécification originelle de COBOL fut publiée. Parmi d'autres points, il ne considère plus que le fait d'écrire des programmes UNIQUEMENT EN MAJUSCULES soient la seule manière de procéder et les jeunes concepteurs de scripts aujourd'hui auraient quelques difficultés à suivre la syntaxe en colonnes très stricte des versions antérieures. C'est pourquoi les dialectes de COBOL plus récents ont progressivement réduit les contraintes formelles de présentation, allant vers une syntaxe de forme libre. Certaines parties du programme, comme l'Identification division, ne doivent plus être obligatoirement incluses. Le même programme Hello World peut être écrit en forme libre de la manière suivante :

program-id. HelloWorld. 

procedure division. 
 
display "Hello, world". 
stop run. 
 
end program HelloWorld.

From the compiler's point of view, all we need to do is specify that we are going to use free-form, and the very same executable file may be produced:

Du point de vue du compilateur, tout ce que nous devons indiquer est que nous allons utiliser la forme libre et un fichier exécutable identique sera produit :

$ cobc hello.cob -x -free

Let us now complicate things. We are now going to split the program up into two parts: a main procedure that will be invoked on program execution, and a sub-program (procedure) that actually does the dirty work when required by the main procedure. To go a step further, we will declare a variable and initialize it with the text to be displayed. The main program goes as follows:

Compliquons maintenant un peu les choses. Nous allons séparer le programme en deux parties : une procédure principale qui sera invoquée au moment de la mise en route du programme et une sous-procédure qui fera les basses besognes dès son invocation depuis la principale. Pour aller encore plus loin, nous allons déclarer une variable et l'initialiser avec le texte à afficher. Le programme principal est comme suit :

program-id. HelloWorld. 

data division. 
working-storage section. 
01 Greeting PIC X(15) value "Hello, world!". 
 
procedure division. 

call "TestSub" using Greeting. 
stop run. 

end program HelloWorld.

A new data division has appeared before the procedure division. This contains a working-storage section, which is where local variables are declared using the PIC syntax. Variables may be immediately initialized using the value keyword. Now, for the procedure TestSub. This must be written in a new program-id section, that may be inserted within the same file as the main program. For example:

Une nouvelle Data division est apparue devant la Procedure division. Elle contient une section Working-storage, où les variables locales sont déclarées avec la syntaxe PIC. Les variables peuvent être initialisées immédiatement avec le mot-clé value.

Ecrivons maintenant la procédure TestSub. Elle doit être déclarée dans une nouvelle section program-id, mais qui peut se trouver dans le même fichier que le programme principal. Par exemple :

program-id. TestSub. 

data division. 
linkage section. 
01 Grt PIC X(15). 
 
procedure division using Grt. 

display "This is TestSub". 
display "Grt = " Grt. 
exit program. 
 
end program TestSub.

In this case, procedure TestSub will be invoked by the main program using one parameter, the text to be displayed. We have also inserted a data division within the sub-program, declaring this parameter within the linkage section. For clarity, the parameter name is “Grt” within the sub-program, and “Greeting” in the main. Just a word of warning: parameters are called by reference, so if changes were eventually to be made to “Grt” within the sub-program, these changes would then be maintained in Greeting when returning to the main procedure. Programmers should exercise caution, specially if accustomed to C's way of passing parameters (call by value). However, it should also be said that this feature facilitates returning values from a sub-program to the routine that invokes it.

Dans ce cas, TestSub sera invoqué par le programme principal à l'aide d'un paramètre, le texte à afficher. Nous avons aussi inséré une Data division dans le sous-programme, déclarant ce paramètre dans la Linkage section.

Pour être plus clairs, nous avons donné à ce paramètre le nom « Grt » dans le sous-programme, et « Greeting » dans le programme principal. Mais attention : les paramètres seront passés par référence, donc si Grt reçoit des modifications dans le sous-programme, ces modifications seront rapportées sur Greeting dans le programme principal au retour de l'invocation. Les programmeurs doivent être spécialement vigilants sur ce point, surtout s'ils sont habitués à coder suivant les conventions du langage C (passage par valeur). Cependant, il faut bien dire que cette caractéristique facilite le retour de valeurs depuis le sous-programme vers le programme principal.

Let's calculate a GCD To illustrate parameter passing when using a procedure, let us use Euclid's Algorithm to compute the Greatest Common Divisor of two integer numbers. The main program will use three variables: A and B to store the two integers, and G for the result. The main program in itself is rather straightforward, the only noteworthy bit being the way in which parameter G is used to retrieve the result from the procedure back to the main program:

Pour illustrer le passage de paramètres vers et depuis une procédure, utilisons l'Algorithme d'Euclide pour calculer le Plus Grand Commun Diviseur (PGCD) de deux nombres entiers. Le programme principal utilisera trois variables : A et B pour les deux nombres entiers, et G pour le résultat du calcul. Le programme principal lui-même est assez simple. Le seul point notable est la manière dont le paramètre G est utilisé pour ramener le résultat du sous-programme vers le programme principal :

program-id. GCD. 

data division. 
working-storage section. 
01 A PIC 9(15) value 245. 
01 B PIC 9(15) value 135. 
01 G PIC 9(15). 
 
procedure division. 

call "EuclidianAlgorithm" using A, B, G. 
display "GCD of " A " and " B " is " G. 
stop run. 

end program GCD. 

Inside the EuclidianAlgorithm procedure, we will begin by making a copy of the two numbers A and B, into local storage. In this way we make sure no changes are made to their original values back in the main program. We will need both a linkage and a working-storage section in the data division, to keep track of incoming parameters and store local variables respectively. Finally, the COBOL way of constructing a “repeat until” structure may seem a bit weird to programmers using other languages, but it does work.

Dans la procédure EuclidianAlgorithm, nous allons commencer par faire une copie des deux nombres A et B dans des variables locales à la procédure. Nous nous assurons ainsi qu'il ne se produise pas de modifications à leurs valeurs originales dans le programme principal. Nous aurons besoin aussi bien d'une section linkage que d'une working-storage section dans la Data division, respectivement pour pouvoir suivre les paramètres entrants et pour déclarer les variables locales. Enfin, la manière COBOL de construire une structure « repeat until » peut apparaître assez étrange pour des programmeurs habitués à d'autres langages, mais il fonctionne.

program-id. EuclidianAlgorithm. 

data division. 
working-storage section. 
01 A PIC 9(15). 
01 B PIC 9(15). 
01 Q PIC 9(15). 
01 R PIC 9(15). 

linkage section. 
01 IN_A PIC 9(15). 
01 IN_B PIC 9(15). 
01 IN_G PIC 9(15). 
 
procedure division using IN_A, IN_B, IN_G. 

Main. 
move IN_A to A. 
move IN_B to B. 
perform Loop with test after until R = 0. 
move A to IN_G. 
 
Loop. 
divide A by B giving Q remainder R. 
move B to A. 
move R to B. 
end program EuclidianAlgorithm.

Once the file is compiled, we can execute the binary program:

Une fois le fichier compilé, nous pouvons exécuter le programme:

$ cobc gcd.cob -x -free 
$ ./gcd 
GCD of 000000000000245 and 000000000000135 is 000000000000005 

Calling C code from COBOL When generating the result above, I was not entirely satisfied with presentation on screen. All those leading zeros seem rather gauche, to say the least. I would have much preferred a C-style printf function to format output, which unfortunately does not seem to be readily available in COBOL. In the interest of tinkering a bit, instead of writing an equivalent procedure in pure COBOL, let us do so in C and invoke it from the COBOL main program. The C wrapper was built around two functions: prettyNumber takes one of the numbers sent from the COBOL side of things, parses and prints it on-screen. As the numbers are each formatted as an array of 15 characters, a simple for loop is used to traverse the array, combined with the flag leading_zeros to indicate if we are still passing through leading zeros (TRUE) or have come into the main body of the number (FALSE). Print is defined as an external function, and so is accessible from outside the C object file. It simply takes the three parameters A, B and G from the COBOL side, and writes them out using prettyNumber.

En préparant le programme précédent, je n'étais pas tellement convaincu par l'affichage des nombres sur l'écran. Les zéros initiaux semblent pour le moins assez mal venus. Je préférerais donc une fonction printf dans le style de C pour formater le résultats, mais qui ne semble pas être facilement disponible en COBOL.

Dans l'intérêt de l'expérimentation, au lieu d'écrire une procédure semblable en COBOL pur, faisons-le plutôt en C et invoquons la procédure en C depuis le programme principal du COBOL. La fonctionnalité de type wrapper a été écrite en C autour de deux fonctions :

- prettyNumber prend un nombre entier envoyé depuis le COBOL, le transforme et l'affiche à l'écran. Puisque chaque nombre est présenté sous la forme d'un tableau de 15 caractères, une simple boucle for est utilisée pour traverser le tableau, en combinaison avec le drapeau leading_zeros pour indiquer si nous sommes toujours en train de passer les zéros initiaux (valeur: TRUE) ou si nous sommes déjà parmi les chiffres significatifs du nombre (valeur: FALSE).

- Print est déclarée comme une fonction externe, et sera donc accessible depuis l'extérieur du fichier objet correspondant à la procédure en C. Il prend les trois paramètres A, B et G depuis le COBOL, et les affiche en utilisant prettyNumber.

#define TRUE (1 == 1) 
#define FALSE !TRUE 
 
void prettyNumber (char *p) { 

int i, leading_zeros = TRUE; 
 
for (i = 0; i < 15; i++) 
	if ((p[i] != '0') || !leading_zeros) { 
		leading_zeros = FALSE; 
		printf ("%c", p[i]); 
	} 
if (leading_zeros) 
	printf("0"); 
} 

extern int Print (char *a, char *b, char *g) { 
 
printf ("GCD of "); 
prettyNumber(a); 
printf (" and "); 
prettyNumber(b); 
printf (" is "); 
prettyNumber(g); 
printf("\n"); 
 
return(0); 
}

Inside the existing COBOL code, just one line needs to be changed in the main program. We replace

Du côté du programme COBOL existant, il faut changer une seule ligne. Remplaçons

display "GCD of " A " and " B " is " G. 

with

par

call "Print" using A, B, G.

No further modifications need to be made to the code. However, compilation will be a tad more tricky, since we need to compile the C library first, and then give it to the COBOL compiler to link with the COBOL code and produce an executable file. So:

Nul besoin de faire de plus longues modifications au programme. Mais la compilation sera plus complexe, puisque nous devrons commencer par compiler la bibliothèque en C d'abord, pour ensuite l'indiquer au compilateur COBOL pour qu'il puisse en faire l'assemblage avec le code COBOL et produire un fichier exécutable. Ainsi :

$ cc print.c -o print.o -c 
$ cobc gcd-c.cob print.o -x -free 

The ”-c“ flag tells the C compiler to halt once the object code is produced, before linking. The object file may then simply be added to the COBOL compiler's input file list. Execution is then performed in the usual way, producing much nicer visual results:

Le drapeau « -c » indique au compilateur C de s'arrêter une fois que le code objet du sous-programme est produit, et avant l'étape du linking. Le fichier objet peut alors être rajouté à la liste des fichiers d'entrée du compilateur COBOL. On peut alors exécuter le programme final de la manière habituelle, en produisant des résultats beaucoup plus jolis :

$ ./gcd-c 
GCD of 245 and 135 is 5 

Conclusions As stated at the beginning, the aims of this short piece were mostly to go back in time and see how the efforts of a dedicated group of programmers have made a rather ancient (in computer terms) programming language com back to life on a modern GNU/Linux distribution. Neither the hardware (laptop versus 1950's mainframe) nor the operating system (UNIX-like versus proprietary OS) have much to do with what the original COBOL designers were contending with – but this stuff works, and can give us a taste of how things were in the “good old days” of computation.

Although the language itself has seen some evolution since conception, general syntax and conception are visible those of another age. This is not to say that modern trends such as object-oriented design or web service implementation could not be handled through COBOL. On the contrary, if sufficient interest were to be found to implement the necessary intermediate libraries I see no reason why COBOL -and, specifically, Open/GNU COBOL- could hold its own with more modern offerings. However, the necessary code would necessarily be seen as an additional layer on top on what is in essence a language from the 1950's – and so, such attachments may at times seem rather alien to the language's original philosophy. On the other hand, handling communication with databases has always been one of the strengths of the COBOL environment; it was mostly built into the concept starting from day one. So, if or when the interested parties can finish linking up COBOL with existing database systems such as PostgreSQL or MariaBD (some work has already been done with Oracle) -or, even better, a generic SQL extension mechanism- this project could very well find its place in the modern world, at least where database back-end programming in concerned.

Comme il a été dit au début, l'objectif de ce court article a été surtout de regarder un peu en arrière et voir comment les efforts d'un groupe de programmeurs dédiés ont ramené à la vie un langage de programmation assez ancien (en termes d'informatique) dans une distribution GNU/Linux moderne. Ni le matériel (ordinateur portable au lieu d'un ordinateur central des années 1950) ni le système d'exploitation (UNIX-like à la place d'un système propriétaire) ont grand-chose à voir avec ce que les développeurs originaux du COBOL avaient l'habitude de gérer, mais il fonctionne, et peut nous donner un aperçu de comment les choses se passaient dans le « bon vieux temps » de l'informatique.

Bien que le langage lui-même ait vu quelques évolutions depuis sa conception initiale, sa syntaxe en général et sa philosophie sont visiblement celles d'un autre âge. Cela n'exclut nullement que des tendances modernes telles que la conception orientée objets ou l'implantation de services Web puissent être traitées avec le COBOL. Au contraire, si l'intérêt était suffisant pour l'écriture des bibliothèques intermédiaires nécessaires, il n'existerait de mon point de vue aucune raison pourquoi le COBOL - et, plus précisément, Open/GNU COBOL - ne puisse tenir la comparaison avec d'autres langages plus modernes. Mais les pièces nécessaires formeraient nécessairement une couche supplémentaire de logiciel par-dessus ce qui est à la base un langage de programmation des années 1950 et, à ce titre, les additions pourraient sembler assez étrangères à la philosophie originale du langage.

En revanche, la connexion à des bases de données a toujours été un des points forts du COBOL, qui a été conçu surtout dans cet objectif. Donc, si (ou quand) des gens intéressés peuvent arriver à connecter COBOL avec des systèmes de gestion de bases de données tels que PostgreSQL ou MariaBD (une partie du travail a déjà été accomplie avec Oracle), ou, mieux encore, un système générique de connexion avec SQL, ce projet pourrait trouver sa place dans le monde moderne, au moins pour ce qui est de la programmation de dorsales de bases de données.

Author biography: Alan teaches computer science at Escola Andorrana de Batxillerat (high-school). He has previously given GNU/Linux courses at the University of Andorra and taught GNU/Linux systems administration at the Open University of Catalunya (UOC).

Biographie de l'auteur : Alan enseigne l'informatique à la Escola Andorrana de Batxillerat. Il a donné des cours de GNU/Linux à l'Université d'Andorre et, auparavant, avait enseigné l'administration des systèmes GNU/Linux à l'Université ouverte de Catalogne (UOC).