Cosas que dicen que no han pasado: el efecto 2000


Hoy han transcurrido veinte años desde la entrada en el siglo XXI (bueno, vale, fue en el 2001, pero no viene de un año). Veinte años del llamado efecto 2000, ese que nunca ocurrió.

Ante tal celebración, y habiendo colaborado activamente en impedir aquel desastre, permitid que os explique qué fue eso que nunca ocurrió, y lo cerca que estuvo la sociedad de un colapso de los grandes ordenadores, que hubiese llevado con seguridad a un colapso del propio sistema que gestiona la sociedad.


El 1 de enero de 2000, sábado, salí de trabajar de las oficinas de una compañía internacional de software a media mañana. Había entrado a las ocho de la mañana del día anterior, y no había detenido el trabajo más que el tiempo necesario para brindar por el año nuevo, y de vez en cuando comerme un sándwich. No mencionaré otros imperativos fisiológicos imprescindibles. Yo era, entonces, el responsable del servicio de soporte técnico de la multinacional para España y Portugal.

Todo el equipo había estado sentado delante de sus ordenadores y con los sistemas preparados desde que Australia celebró la entrada en el Año Nuevo, más o menos a la hora de comer española. Nos empezaron a llegar reportes de problemas, por suerte de menor calado, que el resto de los equipos técnicos nos apresuramos a procesar. Tan pronto estaban definidos y documentados – esa era la misión de nuestro primer nivel – los enviábamos a los equipos desarrolladores para que generasen una solución, que debíamos distribuir y aplicar en todos los demás clientes antes de que les llegase el Año Nuevo a ellos. Siguieron reportando incidencias, en este orden, los centros de Japón, India, Israel, y por fin Europa. Cada vez los problemas reportados eran de menor importancia. Cuando por fin la costa Este de EEUU dio por válido los sistemas, nos fuimos a dormir. Se cerraba así el último día de trabajo de un período de más de cinco años dedicados a prevenir el llamado efecto 2000.

Bajé al garaje y salí con mi coche hacia casa con un cansancio infinito. Puse la radio y escuché a un tertuliano diciendo algo así como “¿Veis? Si no ha pasado nada. Ya os decía yo que eso del efecto 2000 era un montaje.” Le dediqué a ese ñu intelectual insultos que ni siquiera sabía que sabía.

Resultado de imagen de ñu
Variedad más inteligente de ñu.

¿Por qué cuento esto? Porque, siempre en relación con el atentado que estamos cometiendo contra el clima, he leído a varios ñus como el que escuché veinte años atrás diciendo cosas como esta (pero hay muchos más, los ñus siempre van en rebaño):

“Estos “expertos” [del cambio climático] deben ser primos de los que hablaban del “efecto 2000”, por el cual, al llegar al año dos mil y cambiar de siglo, y por cuestión de la configuración de las fechas, los ordenadores del planeta iban a colapsar y crear un caos apocalíptico. Todo iba a fallar.”

Comentario #6 en Hablan los expertos de la COP: “Hay suficiente información científica para que no se pueda negar el cambio climático”. Fuente: https://www.eldiario.es/sociedad/cop25/Hablan-COP-suficiente-informacion-cientifica_0_973253493.html

Vamos con la explicación de la parte técnica.

¿Cuál era el problema teórico?

Cuando se extendieron los grandes sistemas de gestión de datos, allá por los años 70, los dispositivos de almacenamiento de información en línea – discos – eran extremadamente voluminosos y caros, muy caros. Otro tanto ocurría con la capacidad de proceso. Por tanto, ahorrar espacio almacenado y memoria de trabajo era una prioridad para programadores y analistas. ¿Tenía sentido almacenar fechas completas? El consenso era que no se necesitaba guardar, por ejemplo, el siglo, de modo que el formato de las fechas era de seis dígitos: DDMMAA, o MMDDAA para los norteamericanos. Es decir, dos dígitos para el día, el mes y el año. Como además el fin de siglo quedaba muy lejos, en lugar de codificar estados o acciones en espacios separados, se utilizaban fechas en los últimos cinco años del siglo. Así, una fecha de 311299 en un registro podía indicar que debía ser mantenido indefinidamente, y 010195 que ese registro podía eliminarse cuando conviniese.

La solución para incorporar el cambio de siglo parecía ser sencilla para cualquier lego en la materia: habida cuenta de que el almacenamiento se había abaratado hacia finales de siglo, bastaba con incluir en cada fecha de todos y cada uno de los programas y de los datos almacenados uno o dos dígitos más que indicasen el siglo, y crear campos nuevos de datos para los códigos de acción. ¿Verdad que parece fácil? Pues no lo era.

¿Cuáles eran los problemas reales?

Resumiendo mucho, eran tres los principales.

No podemos parar para acomodar el nuevo formato.

¿Cómo convertir una base de datos con millones de dígitos de información mientras se sigue trabajando en el día a día? Para algunos tipos de empresas la cosa era más o menos sencilla, como por ejemplo Hacienda, o la Seguridad Social, porque podían desconectarse los ordenadores durante las noches o fines de semana. Sin embargo, este esquema estaba fuera de lugar para los ordenadores que controlan el tráfico – semáforos de grandes ciudades, aeropuertos, ferrocarriles – o centros en los que el soporte era vital – hospitales, por ejemplo -.  

La pesadilla de los programadores COBOL.

El lenguaje en el que se escribieron la mayoría de los programas de gestión fue COBOL (siglas en inglés de Lenguaje Común Orientado a Negocios), que no se enseñaba en las universidades. Lo conocíamos quienes habíamos entrado en la profesión por el método clásico del aprendizaje en el trabajo, o habíamos conseguido formación directa en las grandes compañías de ordenadores, siendo IBM la principal fuente. Éramos programadores autodidactas más que ingenieros. Esto sucedía porque COBOL no era un lenguaje guay para las mentes científicas que lideraban las universidades técnicas, y que preferían otros lenguajes como FORTRAN, más apropiados para calcular datos chulos, y no cosas tan aburridas como intereses o impuestos. Lo mismo ocurría con los sistemas operativos, en los que el OS/360 y su sucesor OS/370 de IBM, mayoritario en las grandes empresas, no existía para los centros de formación, mientras que los futuros ingenieros informáticos se formaban en UNIX, que apenas empezaba a entrar en el mundo empresarial por entonces.

Así nos veían los ingenieros informáticos recién salidos de la universidad. Prefiero no decir cómo los considerábamos nosotros a ellos.

Es decir, que en los años 90 la última generación de programadores COBOL ya no cumplía los cuarenta años, y las primeras generaciones, quienes escribieron aquellos programas en funcionamiento, estaban en su mayoría muertos o jubilados. Una pesadilla para las compañías, y una buena oportunidad de empleo para los más jóvenes, aunque ya fuésemos cuarentones.

¿El protocolo? Que le den.

Un programa COBOL escrito en lenguaje humano – por decir algo – no es ejecutable. Primero debe ser compilado, posteriormente ensamblado, y los tres elementos – fuente, objeto y ensamblado – almacenados por separado en distintos tipos de librerías. Os lo explico. Supongamos que me piden que escriba un nuevo módulo para un programa que calcule el rendimiento diario de una cuenta corriente . No tengo que preocuparme de escribir el código de acceso a la base de datos, ni el de impresión, ni nada por el estilo porque eso ya existe, así que escribo el programa CURENT01 en lenguaje COBOL legible – código fuente – y lo envío a compilar.

Ejemplo de inicio de programa COBOL en formato fuente.

Así en la librería fuente tendré un fichero CURENT01, y en la librería de compilados – código objeto – una entrada del mismo nombre. Ese código objeto tiene algunas palabras legibles, pero en general su apariencia una vez impreso es de un batiburrillo escrito en base hexadecimal. Un montón de caracteres sin sentido de 0 a 9, y de A a F.

Y ahora viene lo complicado. Ese módulo objeto tiene que ensamblarse con todos los demás módulos ya existentes y relacionados lógicamente. Es decir, que mi CURENT01 debe ensamblarse con el acceso a base de datos DBUSUA15, el módulo de impresión DBIMPR27, el… y así, siempre con la última versión de cada módulo. Una vez todo ensamblado – código ejecutable – forma un único bloque en la librería de ejecutables que se llamará, por ejemplo, CUGEST65 y reemplazará a CUGEST64.

Imagen relacionada
Ejemplo de visualización de un módulo ejecutable. Había gente con la capacidad de leer esto con la misma facilidad con que leían el periódico, pero eran pocos, y gente muy rara en general. En 1995 yo no era uno de ellos, sí a finales de 1999.

Cuando finalmente este programa se ponga en ejecución, un montón de técnicos mantendrán los dedos cruzados y el ojete cerrado para evitar la cagada, si la hay, y en ese caso que les salpique.

¿Os parece complicado? No lo es tanto si cumples con los protocolos y documentas tu módulo a la perfección, lo registras en la documentación general de programas de la empresa, lo añades a las listas de sentencias de control de ensamblaje, mantienes el control de versiones, etc. Es engorroso, pero no complicado.

Ahora bien, si recordáis lo que dije antes, los programadores COBOL eran de origen autodidacta, y en aquellos felices años 60 y 70 la mayoría de ellos trabajaba artesanalmente. No siempre había documentación de programas, o cuando la había, con frecuencia no era fiable. Por otra parte, llegar a saber qué objeto se había ensamblado en el ejecutable era una tarea digna de Sherlock Holmes, y luego relacionar cada objeto con un código fuente, que por fin se podía modificar, la búsqueda del tesoro. Era el momento final de dos décadas de modificaciones mal documentadas, llevando el control de versiones de memoria, en el mejor de los casos. Imaginaos el puzzle de un millón de fichas mostrando un oso blanco corriendo sobre la nieve, pues eso.

En definitiva, muchas grandes compañías – bancos, telefónicas, energéticas, aeropuertos, administraciones públicas, etc. – descubrieron con sorpresa que nadie sabía exactamente qué demonios estaban ejecutando, y mucho menos qué había que modificar, ni qué efectos tendría una vez modificado.

¿Cuáles serían las consecuencias si no se hacía nada?

Alguna consultora ha dejado caer que el coste de resolver el problema fue muy superior a las repercusiones que hubiese tenido la entrada en el año 2000, de no hacer nada. La única deducción cierta de esta afirmación es que ñus los hay en todas partes.

Básicamente, se sabía que entre 1995 y 1999 ocurrirían cosas raras con acciones individuales debido a los códigos de acción en forma de fechas concretas. Es decir, que un día podrías recibir la reclamación de una deuda importante por una cuenta que cancelaste hace diez años, que apareciesen de pronto aviones fantasma en las listas de despegue del aeropuerto, o que la administración tributaria te diese por muerto. Impactos importantes a nivel personal, masivo en ocasiones, pero no globales.

Pero lo que era evidente es que al 31 de diciembre de 1999 le iba a seguir… el 1 de enero de 1900. Según el sector la catástrofe era distinta, pero catástrofe al fin. ¿Qué pasaría en las Bolsas si una cotización se retrotraía a al valor de la acción un siglo antes? Adiós finanzas. ¿Y las cuentas corrientes bancarias, generando deudas de intereses de un siglo? Adiós confianza bancaria. ¿Cómo reaccionarían los programas de gestión del tráfico aéreo si un avión que había despegado en 1999 trataba de aterrizar en 1900? Pues si tenemos en cuenta la complejidad de cálculo de, por ejemplo, un vuelo transoceánico, y el volumen de tráfico de un aeropuerto grande, la respuesta más probable era el suicidio masivo de controladores aéreos.

En este aspecto, al analizar las posibles consecuencias se entraba frecuentemente en una singularidad, Terra Incógnita para entendernos, pero eran previsibles efectos entre muy desagradables y desastrosos. Y parar los ordenadores durante semanas o meses para resolver problemas cuando surgiesen no era una opción, porque equivalía a un colapso total del sistema que gestiona la sociedad a partir del 1 de enero de 1900… Perdón, de 2000. Imaginad la vida en una ciudad sin ordenadores: sin poder utilizar los bancos, con las bolsas financieras suspendidas, sin transporte de ningún tipo, sin tarjetas de crédito, … y todo eso por tiempo indefinido. Divertido, ¿verdad?

¿Cómo se resolvió?

Los trabajos se iniciaron a principios de los años 90, lo que implicó, para hacer aún más complicado el tema, incorporar el desarrollo de Internet, y, por ejemplo, el euro para los países de Europa occidental. Porque en paralelo al trabajo que había que realizar para actualizar todo lo existente, había que integrar nuevas tecnologías a medida que iban surgiendo, más los cambios en las diversas áreas del sistema.

El primer paso para las empresas fue construir laboratorios de desarrollo con mayor potencia de procesamiento y almacenamiento que los existentes, para probar los nuevos ejecutables con datos modelados. Es decir, sistemas capaces de soportar muestras representativas de datos sobre los que se aplican los programas actualizados, pudiendo corregir errores internamente sin afectar al negocio diario.

Igualmente, fue necesario desarrollar nuevas tecnologías de administración de bases de datos para realizar modificaciones masivas en paralelo con cambios en tiempo real. Es decir, gestionando las peticiones de los programas de modificación de fechas y de los usuarios al mismo tiempo, sin que se perdiesen transacciones reales. O sea, sin interrumpir, por ejemplo, despegues y aterrizajes en los aeropuertos, o movimientos de cuentas bancarias. Todo ello en paralelo con la incorporación de objetos multimedia – sonido, imágenes, vídeo, … – como exigían las nuevas tecnologías de Internet.

Pero lo más significativo fue la aparición de herramientas para la identificación de riesgos y desencriptación de ensamblajes. Los primeros analizaban los códigos ejecutables y avisaban de la existencia de fechas en formatos DDMMAA, o de fechas ddmm9a que podían implicar códigos de acción. Los segundos tomaban como entrada el código ensamblado, ilegible, lo desensamblaban y lo transformaban en un código fuente aproximado.

Con esto, el trabajo se centraba únicamente en los programas de riesgo, y además se permitía ver, aunque fuese con lagunas porque el desensamblaje es un proceso muy complejo, cómo era la fuente que se había compilado. Esto, a su vez, permitía buscar el fichero adecuado en las librerías incluso cuando se escondía bajo nombres estrafalarios. Gracietas de programadores veteranos que, probablemente, tenían sus razones para fastidiar a la empresa en la que trabajaban por la escasa valoración que tenía su profesión en los centros de cálculo. Eso no ha cambiado mucho, me temo.

Resultado de imagen de programador cobol

Y todo ello, aplicado a millones de programas en todo el mundo, no siempre probados en los sistemas de laboratorio porque la carga de trabajo en ocasiones no es replicable. No es de extrañar, por tanto, que a medida que se acercaba el fin del siglo fuese creciendo la presión sobre los especialistas en resolución de problemas informáticos y los maduros, cuando no ancianos, programadores COBOL. Todavía me duelen las jornadas de doce, o más, horas de trabajo diarios, sin festivos, en el otoño e invierno de 1999.

En cuanto al importe de la inversión, El País da una cifra de coste de 240.000 millones de euros a nivel mundial. Me parece razonable.

Concluyendo.

Circulaba entre informáticos un chiste:

Dicen que un programador COBOL, al que habían sacado de su retiro para trabajar en la prevención del efecto 2000, prefirió congelarse y despertar pasado el cambio de año 2000 para librarse de aquél caos. Pero algo falló debido, precisamente, al efecto 2000. El hombre se durmió, y cuando despertó vio a unos individuos muy extraños que lo miraban con mucha atención.

  • Buenos días, me alegro de que haya despertado. ¿Se encuentra bien?
  • Sí, perfectamente.
  • Si no me equivoco, usted es Mike Smith, y era programador COBOL.
  • Sí, eso es, ¿Por qué lo pregunta?
  • Por nada, por nada.
  • ¿Podrían decirme al menos qué día es hoy?
  • Claro, hoy es 1 de enero de 9999.

Es bastante probable que a vosotros no os haga gracia, pero nosotros lo entendíamos perfectamente. De hecho, aún hoy se hacen camisetas con este chiste.

Nota: en código abreviado, el efecto 2000 se escribía Y2K.

Resumiendo, que me desvío. Si el uno de enero de 2000 el sistema global no colapsó fue por el trabajo ímprobo de mucha gente en todo el mundo. Un trabajo que se distribuía entre especialistas ubicados en distintos lugares del mundo. Y todo eso se coordinaba en equipos de soporte técnico que compartían su información a nivel planetario, pero al mismo tiempo debían preservar la privacidad de cada cliente. Fue un caos organizado de casi una década para las empresas, y de seis o siete años para los proveedores de servicios informáticos, con un fuerte sprint en los últimos cinco años, y agónico en el último. Pero funcionó.

Si se me perdona la inmodestia, creo que hicimos un trabajo prácticamente perfecto.


Comprenderéis y, por tanto, espero que disculpéis mi escasa valoración de quienes, desde la ignorancia más supina, se atreven a opinar que el efecto 2000 fue un montaje, y mi desprecio hacia la capacidad intelectual de quienes se atrevan a usarlo para negar el calentamiento global.

Saludos, y feliz año 2020.

NB: Ahora se habla de otro efecto 2038 que afectaría a los sistemas basados en arquitecturas de 32 bits. Entre nosotros: si no están en el ajo los programadores COBOL y sus metodologías paleoinformáticas, no hay color.

Gracias por dejar un comentario. Nota que no se aprobarán aquellos que superen las 250 palabras, o contengan afirmaciones no demostradas. Por ejemplo, si afirmas que la madre de algún personaje público ejerce la prostitución, tendrás que aportar pruebas.

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .

Crea un sitio web o blog en WordPress.com

Subir ↑

Blog del Gran Baladre

Bacineamos de to lo que se menea

Florent Marcellesi

Blog del eurodiputado de EQUO

BlogSOStenible: Noticias medioambientales y datos... aportando soluciones

Ecología, Economía, y Sostenibilidad, desde los países ricos: Aprender, Ayudar y Disfrutar... desde Málaga (España).

Autonomía y Bienvivir

Bacineamos de to lo que se menea

La proa del Argo

Bacineamos de to lo que se menea

Salva Solano Salmerón

Bacineamos de to lo que se menea

Joven Furioso

Escritos, divagaciones y un chancletazo al libre albedrío.

Vota y Calla

No te metas en lo que SÍ te importa

Blog de Gregorio López Sanz

Bacineamos de to lo que se menea

A %d blogueros les gusta esto: