Programando en COBOL para DOS

Corrían los comienzos de la década de los 1990s, auténtica edad primitiva si hablamos de informática. Estudiaba Ingeniería Técnica en Informática y teníamos aquella asignatura de COBOL. COBOL es en realidad una sigla, que significa: Lenguaje [de programación] orientado a negocios comunes (Common Business-Oriented Language).

COBOL es un lenguaje de programación curioso. Es posterior a Fortran, pero aún mantiene la influencia de las tarjetas perforadas dentro de sí: los comentarios deben comenzar en una columna determinada, el código fuente en otra... etc.

Columna	Uso
1 a 6	Números de línea
7	* -> comentario
8 a 11	Cabeceras como section
12	Código ejecutable

Además, si esperas empezar a programar como con Python, algo así como print("¡Hola, mundo!")... es que estás muy perdido. El siguiente código sería equivalente.

IDENTIFICATION DIVISION.
PROGRAM-ID. hello-world.
PROCEDURE DIVISION.
    DISPLAY "Hello, world!"
    STOP RUN.

COBOL es un lenguaje de programación muy, muy peculiar. Las secciones y divisiones declaraban variables o estructuras de archivos. Buscaba parecerse más a un lenguaje natural (en inglés, claro), basculando hacia utilizar multitud de palabras clave, en lugar de símbolos. Por ejemplo, 4 * 5 se escribía como 4 times 5, o x > 0 como x greater than 0. Esto fue corregido modernizado con el tiempo, hasta dejar buena parte de la sintaxis en algo parecido a lo que utilizaríamos hoy en día en C o Java.

Si conoces COBOL, ¡estás de enhorabuena! Hay muchos sistemas bancarios que todavía se ejecutan con programas en COBOL, pero que no mucha gente entiende realmente cómo funcionan. (En realidad, tampoco es tan difícil)... ¿Java, C#, Rust...? ¡Olvídalos! ¡COBOL al poder! ¡Los bancos se van a dar de bofetadas por ti!

En aquella época, utilizábamos Microsoft COBOL 4.5. Aún puede descargarse Microsoft COBOL 4.5 de algunos archivadores de Internet.

Aunque en aquella época no lo sabía, empleábamos un compilador que en realidad Microsoft había licenciado de otra empresa, llamada Micro Focus. Esta empresa había desarrollado un depurador, llamado Animator (?? a mi siempre me recordó a Re-animator), y un editor de textos integrado con el compilador, Workbench. Muy interesante... si funcionaran. Bueno, supongo que funcionaban. Me explico: en los 8088 que tenían nuestros PC clónicos, no funcionaban. Se arrastraba, lanzaba errores extraños... Supongo que en un PC alto de gama de la época (no quiero calcular cuánto costaría), iría como la seda.

El caso es que en aquella época estaba acostumbrado a utilizar un editor de textos muy liviano, el Norton Editor, (o, ne), mientras que este entorno era una especie de Visual Studio completo (en modo texto, eso sí). Solo lo digo para hacernos una idea. La cuestión es que desarrollar en un lenguaje de programación, normalmente, se podía hacer en cualquier PC, pues era una tarea no demasiado exigente.

Me puse a investigar. Realmente, ¿qué era necesario para compilar un programa en COBOL, es decir, un archivo con extensión CBL?

$ cobol hola.cbl
$ link hola.obj

El problema era que, normalmente, con un solo archivo no era suficiente. De hecho, lo típico era que fuera necesario compilar todos los archivos en código fuente que hubiera en un directorio. Así que, para dos archivos, era necesario algo así como lo siguiente:

$ cobol prog1.cbl
$ cobol prog2.cbl
$ link prog1.obj prog2.obj

Cuando intentabas utilizar Workbench, aquel editor integrado que era como el primigenio Turbo Pascal, pero que no funcionaba nada bien, fallaba, pero antes generaba un archivo... Makefile.

Mmm... Sí, entre el compilador, el Animator, el enlazador, había un prometedor make.exe. En aquella época yo no sabía nada de make, más allá de que era evidente que permitía generar ejecutables.

$ make

¡Hurra! ¡Tenía el ejecutable! Y la ventaja es que aquel Makefile incluía las posibles librerías que se pudiesen necesitar. La cuestión real era... ¿en qué se diferenciaba un Makefile para un proyecto del Makefilepara otro?

Te lo creas o no, en lo único en lo que se diferenciaban era en un pequeña sección en la que se listaban los archivos CBL con código fuente en COBOL.

Así que agarré mi Python de la época (es decir, C), que tomaba la parte inicial del Makefile, incluía los archivos con extensión CBL en el directorio, y después volcaba la parte final del Makefile. Así, el programa, del que apenas solo recuerdo su nombre, makH, constaba de tres archivos:

makh.com
makh1.h
makh2.h

Sí, los archivos de extensión h eran ambas partes del Makefile. Es que a mi aquello me recordaba los archivos de cabecera de C. De ahí, makH como nombre de aquella herramienta. Después de aquello, me echaron de la asociación de ponedores de nombres. No se puede tener todo.

El proceso para compilar era tal que así:

$ makh
$ make

makh no tenía que ser ejecutado cada vez que se compilaba la aplicación, pero sí cada vez que se creara un nuevo archivo CBL. Total, que la mayor parte de las veces, con hacer un make era más que suficiente.

Por cierto, que no lo he dicho, o al menos no lo había hecho explícito. Algunos ya teníamos un disco duro (40 MB a cambio de 240€ de la época), pero lo más normal era que todo se metiera (herramientas necesarias, y el proyecto en sí) en un diskette. Por si acaso, voy a poner una referencia a un diskette. Aunque ya casi siempre se utilizaban diskettes de 3.5", aún había diskettes de 5.25" por ahí.

Esto era lo que motivaba que makh fuese un archivo COM (es decir, el tamaño menor posible), en lugar de EXE. La diferencia es que un ejecutable COM no necesitaba un segmento de memoria de 64k específico de datos, sino que todo se cargaba en el mismo segmento, con punteros de 16 bits. Era lo que se conocía como compilar con el modelo de memoria TINY en Borland Turbo C.

¿Qué habría hecho hace 10 años? ¿Preguntar en StackOverflow? ¿Y ahora, preguntarle a CHATGpt? ¿No es mucha más entretenida la exploración que hice en aquel momento? Bueno, a mi me lo parece.