Josep Maria Blasco

Resumen

Entre abril de 1986 y mayo de 1987 desarrollé una aplicación de gestión de discos locales y distribuidos para sistemas VM/CMS en el Centro de Informática de la Universidad de Barcelona (CIUB) utilizando LISTSERV, software para la red EARN. Se describe la prehistoria y la historia de la aplicación, que representaba un uso especialmente creativo de LISTSERV, y permitía superar algunas serias deficiencias del sistema operativo VM/CMS, entonces en uso en el CIUB.

El sistema de ficheros de VM/CMS y sus limitaciones

El sistema operativo VM/CMS (que no solo se utilizaba en el CIUB, sino también en muchos otros ordenadores de la red) disponía de un sistema de ficheros extraordinariamente primitivo: los usuarios podían acceder a diversas "unidades" virtuales de disco llamadas "minidiscos", que se identificaban mediante letras (como en los PCs con Windows en la actualidad); cada uno de estos discos almacenaba ficheros en una estructura plana, es decir, sin subdirectorios o carpetas.

Los ficheros tenían "filename", un nombre de fichero de hasta 8 caracteres, "filetype", más o menos equivalente a las extensiones de fichero actuales, y un "filemode" que constaba de la letra correspondiente a la unidad de disco y un dígito que se utilizaba para otras cosas.

Cada "minidisco" podía ser accedido en modalidad de sólo lectura (Read-only: "R/O") o en modalidad de lectura-escritura (Read-write: "R/W"). Sólo podía haber un usuario a la vez accediendo al mismo disco en modalidad de lectura-escritura; si por alguna causa dos usuarios accedían en modo R/W a la vez, el disco corría el riesgo de destruirse, perdiendo toda la información almacenada.

Esta arquitectura de sistema de ficheros hacía que la gestión de los "minidiscos" (en los que a veces residían cientos, si no miles, de ficheros) fuese muy farragosa, burocrática, ineficiente e insegura.

Por una parte, porque el peligro asociado a la destrucción del disco si dos personas lo accedían a la vez en modalidad de lectura-escritura obligaba a 1) o bien limitar el acceso a una única persona, la única que conocía la contraseña especial de lectura-escritura, en cuyo caso había que ir a molestar a esa persona cada vez que se quería cambiar un fichero, o 2) utilizar mecanismos complejos (y no proporcionados nativamente por el sistema operativo) para acceder en lectura-escritura "sólo un instante", el necesario para actualizar la información, con lo que aparecía la posibilidad de que en el "instante" en que uno precisaba el acceso de lectura-escritura otro usuario estuviese haciendo lo mismo; el disco aparecía entonces como "ocupado", y había que "volverlo a intentar más tarde", etc. El mayor problema asociado a este último mecanismo, sin embargo, no era que fuese un poco chapucero, sino que si se podía modificar un fichero, y dado que para poder hacer eso había que disponer de la contraseña de lectura-escritura del disco, entonces se podían modificar todos. Está claro que esto sólo podía funcionar en ambientes en los que predominaba la confianza, porque era un agujero de seguridad enorme.

Por otra parte, porque al no existir los directorios o carpetas todos los ficheros iban a parar al mismo lugar, con lo que se hacía muy complicada su gestión, especialmente cuando había muchos. Esto se complicaba especialmente cuando varios ficheros formaban una unidad lógica (por ejemplo, los distintos ficheros necesarios para implementar una aplicación): el sistema operativo no ofrecía ninguna manera de manejar colectivamente esos ficheros.

Primeros intentos: PACKAGEs y FITXERS

Algunos programas IBM Internal Use Only que nos llegaban directamente de IBM Barcelona o del Centro Científico UAM/IBM venían acompañados de un fichero de tipo PACKAGE, que unía a una descripción del programa un listado de sus componentes. Siguiendo el ejemplo de IBM, empiezo a agrupar los ficheros de los discos en PACKAGEs; el 29 de abril de 1986 escribo una utilidad ("PACKSEND") que permite enviar el contenido completo de un PACKAGE a un usuario (obviando así la necesidad de mandar los ficheros individualmente, con el consiguiente riesgo de errores, omisiones, etc.), y el 8 de mayo escribo otra utilidad ("PACKMAKE") para facilitar la creación de PACKAGEs.

Por otra parte, el encargado de Sistemas había confeccionado (manualmente) una lista ("DISC_G FITXERS") de los ficheros contenidos en los discos G (disco General, accesible por todos los usuarios del Centro) y otra ("DISC_P FITXERS") de los conenidos en el disco P (disco de Productos). El 14 de abril de 1986 escribo una utilidad ("FITXERS") para visualizar cómodamente esas listas. El 14 de junio anuncio que he desarrollado "una versión muy mejorada", y el 17 de junio envío un correo que da detalles sobre la historia de esos desarrollos.

Las funciones de servidor de ficheros de LISTSERV

El 12 de noviembre de 1986 instalo la versión 1.5c de LISTSERV, que contiene una versión beta de sus funciones de servidor de ficheros. Las funciones de servidor de ficheros estaban pensadas para poder ofrecer software presentado mediante FILELISTs, listados estructurados y comentados; ignoro si su uso se extendió mucho o no, pero durante el tiempo en que estuve activamente vinculado a EARN (es decir, hasta abril de 1989) no tengo la impresión de que eso haya sucedido, excepto para la distribución de productos vinculados al propio LISTSERV.

Un FILELIST era un listado estructurado y comentado de ficheros; esto permitía agrupar los ficheros de un modo lógico (es decir, juntando los que tuviesen relación, describiendo cada fichero, creando una cabecera de documentación antes de cada grupo lógico, etc.) en vez de físico (los listados producidos por el sistema operativo, que sólo podían ordenarse por los métodos habituales: alfabético, por tamaño, por fecha de modificación, etc., y no admitían comentarios ni descripciones). Pero quizá lo más interesante de los FILELISTs eran los llamados FAC, los "File Authorization Code" o Códigos de Autorización de Ficheros, que permitían asignar derechos separados de lectura y escritura de forma individual a cada uno de los ficheros gestionados por un determinado FILELIST. Esto permitía resolver de un plumazo la mayoría de las deficiencias del sistema de ficheros de VM: bastaba con generar un FILELIST para un disco entero (pero esto ya lo teníamos medio hecho con los listados de FITXERS), asignar códigos de autorización para cada uno de los ficheros, según quien fuese el responsable de su mantenimiento, y confiar la gestión de los discos compartidos a LISTSERV.

Otras funciones, que hoy pueden parecer curiosas, eran FUI (de "File Update Informacion"), un mecanismo que avisaba (mandando un email) cada vez que un determinado archivo cambiaba, y AFD (de "Automatic File Distribution"), que enviaba el propio archivo modificado cada vez que se cambiaba.

DISCOS

El 9 de noviembre de 1986 describo "una versión muy mejorada de PACKAGE" y propongo que todos los discos no estrictamente privados del Centro sean mantenidos mediante FILELISTs. El 13 de noviembre pongo el disco interno del CIUB bajo control de LISTSERV. El 16 de noviembre he desarrollado una utilidad para comparar FILELISTs y el contenido real de un disco. El mismo día escribo otra utilidad ("ALINTERN") para modificar ficheros en el Disco Interno utilizando LISTSERV; el 17 de noviembreinstalo una versión modificada, adaptada a los cambios introducidos por la version 1.5d de LISTSERV, la primera que soporta oficialmente las funcionalidades de servidor de ficheros.

Este uso creativo de LISTSERV no era completamente trivial, sino que requería un buen conocimiento de su arquitectura interna y la escritura de software complementario ("user exits"). El 26 de noviembre informo a LSTSRV-L (la lista internacional sobre LISTSERV) de los pasos necesarios para poder ofrecer esta funcionalidad.

Más adelante (en 1987), el disco G pasará también a estar controlado por LISTSERV, así como parte del disco de HELPs, y quizás también otros discos (no conservo los emails de la Lista Interna para 1987; el detalle sobre el disco de HELPs lo he encontado aquí).

Una consecuencia extraordinariamente util de realizar el mantenimiento de los discos mediante LISTSERV era que, al ser LISTSERV un servidor distribuido, resultaba muy sencillo configurar dos LISTSERVs situados en máquinas distintas para que almacenasen el mismo FILELIST. De este modo, se podía asegurar que dos máquinas distintas tuviesen copias perfectas del mismo disco (si esto se intentaba hacer manualmente, siempre se cometían errores y las copias nunca estaban perfectamente sincronizadas, con los consiguientes errores y pérdidas de tiempo). Debido a la importancia que estaba adquiriendo este uso imprevisto de LISTSERV, y también para protegernos de posibles cambios debidos a actualizaciones de software, creo una copia de LISTSERV llamada DISCOS y dedicada únicamente a la gestión de los discos del Centro; sendas instalaciones de DISCOS en los tres ordenadores de que disponía el CIUB en ese momento permitían asegurarse de que la colección de software y utilidades ofrecidas a los usuarios, aparte de estar excelentemente documentada, era exactamente la misma. Y, además, el mantenimiento de cada fichero lo podía realizar la persona responsable desde cualquiera de los tres ordenadores, sin importar cual: la cooperación de las máquinas DISCOS aseguraba que la actualización se distribuiría sin demora a los tres ordenadores.