Este problema es harto complejo como para tratar de abordarlo en unas pocas páginas WEB, pero nada se pierde con al menos intentarlo. Uma buena forma de abordar el problema es dividirlo en pedacitos pequeños y ver en que lugar del rompecabezas se encaja la necesidad de cada usuário.
Hay un importante sector que será afectado por el Bug del Milenio pero que no me atrevo a enfocarlo aqui por falta de experiencia, y es el caso de los micro-procesadores que llevan algun tipo de programación de fechas en Assembly guardados en memorias ROM. Estos pequeños dispositivos son utilizados en los lugares mas dispares posibles, desde muñecas parlantes para niñas hasta ojivas nucleares de multiplas cabezas. Sinceramente no se lo que sucederia si uno de estos chips ha sido programado mucho tiempo atras y tiene una rutina de fecha incorrecta. Uno podria pensar en lo peor, y lo único que nos resta es esperar que estos profesionales no se hayan peleado con el jefe (o la esposa/marido) en el momento en que estaban trabajando hace muchos años.
Solo como anecdota sobre lo que podria suceder, comento que algunas versiones de sistemas UNIX enloquecerán a las 3:14:08 (hora universal) del dia 19 de Enero de 2038 pasando a marcar seguidamente las 20:45:52 del dia 13 de Diciembre de 1901. Por que?, por que la fecha inicial en estos sistemas toma como referencia el 1 de Enero de 1970, y el registrador interno de la máquina tiene 32 bits. Como el registrador usa un bit para signo, y marca un "tic" por segundo, estos sistemas UNIX son como bombas de tiempo que deben detonar a los 2^31 = 2147483648 segundos (traducido para Cristiano esto significa unos 68 años, 0 mes, 19 dias, 3 horas, 14 minutos y 8 segundos - contando los años bisiestos , como pueden verlo aqui.
Si en lugar de maquinas UNIX pensamos en otros artefactos con cronómetros internos que tienen solo dos lugares para poner el año, nos haremos una idea de la complejidad del problema.
En los sistemas informáticos convencionales, el problema puede ser dividido en:
A) SISTEMAS OPERATIVOS (OS)
B) SISTEMAS PROPIETARIOS ORIENTADOS A "MAINFRAMES" (máquinas de gran porte)
C) SISTEMAS COMPRADOS/ALQUILADOS ORIENTADOS A "MAINFRAMES"
D) SISTEMAS PROPIETARIOS ORIENTADOS A "MICROS" (generalmente IBM-PC compat.)
E) SISTEMAS COMPRADOS/ALQUILADOS ORIENTADOS A "MICROS"
Aqui "propietario" significa "desarrollado en casa", al contrario de los sistemas comerciales comprados o alquilados cuyos fuentes no se encuentran en poder del usuário.
En cualquiera de estas categorías puede aparecer un problema relativo al cambio de fecha para el año 2000, y cuanto más antiguo es un sistema, mas probable es que una falla se presente.
A) SISTEMAS OPERATIVOS
No hay mucho que se pueda hacer aqui si existe una falla, a no ser prever que el problema VA a sudecer y cambiar lo antes posible para una versión más actualizada del sistema.
Como los sistemas operativos están desarrollados por empresas especializadas (a veces por los mismos fabricantes del hardware), el usuário nada puede hacer para corregir el problema por via de la re-programación, pues no dispone generalmente de los códigos fuente.
Como detectar un posible error del sistema?, la respuesta mas sencilla es: ponga el reloj de la máquina en el dia 31 de Diciembre de 1999 a las 23:59:30 y espere 30 segundos (experimente con el MS-DOS). Si el reloj automáticamente pasa para el 1 de Enero de 2000, Ud. está probablemente a salvo de ESTE error.
Y por que un error en el reloj de la máquina podria afectar a los sistemas comerciales o administrativos?. Por que la mayor parte de los sistemas "presta" del reloj de la máquina la informacíon sobre el calendario através de rutinas internas. Como un sistema de cuentas por cobrar sabe que un crédito fue realizado y registrado en la caja automática el dia 5 de Marzo a las 12:23:55 si nadie se lo ha dicho?, pues se lo ha preguntado al Sistema Operativo através de alguna rutina interna del tipo "call", luego es posible imaginar lo que sucedería si el reloj del sistema se desajusta el 1 de Enero de 2000. A partir de ese momento todas las transacciones (y pueden ser millones) realizadas por la máquina comenzarán a tener fechas incorrectas. No cuesta imaginar lo trabajoso que sería corregir luego estas fechas.
B) SISTEMAS PROPIETARIOS ORIENTADOS A "MAINFRAMES"
Aqui el usuário cuenta con la ventaja de poseer los códigos fuente del sistema, y en este caso puede detectar Y corregir el error a tiempo, aunque a veces esta corrección sea costosa y demorada. El porque y por cuanto esta corrección es a veces dificil puede verlo en la sección Que es el Bug del Milenio?.
Como detectar algun posible error en sistemas altamente complejos compuestos de millares de programas y ficheros?. Lamentablemente no hay una respuesta sencilla a esta pregunta. Sistemas orientados a "mainframes" a veces ejecutan pocas transacciones "on-line" (aquellas en que una persona se la pasa teclando frente a un terminal), y mas bien se dedican a procesar grandes volúmenes de datos en sistemas "por lote". Muchos de estos sistemas no encontrarán aqui el clásico problema de "poner mas dos lugares en la pantalla para escribir 2000", pero en lugar de esto encontrarán otros problemas ocultos en forma de rutinas de tratamiento de fecha escondidas en grandes bibliotecas publicas, lotes de proceso (JOBs) hace mucho creados y cuyas fechas permanecen intocadas, o talvez en la forma de campos para fecha en ficheros que por olvido no fueron alterados para recibir al año con cuatro dígitos.
Algunos pasos básicos pueden por lo menos ayudar a detectar el problema:
- Si su empresa cuenta con un Diccionario de Datos activo (aquellos que guardan tanto la informaçión sobre el dato asi como los lugares en que es utilizado) tendrá la tarea muy facilitada. Es cuestión de preguntar al diccionario en que ficheros están guardadas las fechas que tienen solo dos lugares para el año y a seguir cuales son los programas que leen o escriben en estos ficheros (hagan uso o no de las fechas). De pose de esta lista de ficheros y programas (que puede ser monumental), es posible al menos saber sobre lo que se debe trabajar, cuanto va a demorar y cuanto va a costar la modificación. (A veces sale más barato hacer el sistema totalmente de nuevo).
- Si su empresa NO cuenta con un Diccionario de Datos, solo el hecho de SABER lo que se debe alterar o corregir es una tarea de por si solo asustadora. Probablemente necesitará hacer un levantamiento sección por sección dentro de la empresa verificando cuales ficheros y programas deben o no ser corregidos. Esta es una tarea manual posiblemente sujeta a errores que pueden resultar caros.
- Una vez que ha localizado los ficheron cuyos campos tienen fechas, verifique si es posible re-escribir la nueva fecha con 4 digitos para el año sin necesidad de hacer deslocamiento en los campos. Muchas veces una fecha vieja está en la forma de "dd/mm/aa" pero en formato NO compactado (es decir se utiliza un byte para cada número de 0 a 9). Verifique si es posible guardar en ese mismo espacio los números en formato compactado (dos dígitos 0 a 9 en cada byte). Si este es el caso, adopte la solución de guardar la fecha en formato compactado usando el mismo espacio, pues así evitará tener que modificar por entero el fichero a causa del deslocamiento (y todos sus programas asociados).
- Haga un censo de todas las rutinas específicas que se dedican a tratar fechas. Normalmente las rutinas de uso público están siempre en un directorio global, de manera que todos los programas hacen referencia a ellas en el momento de la compilación o link-edición. Probablemente encontrará dentro deste directorio rutinas para calcular la diferencia entre dos fechas, rutinas para calcular el dia de la semana, para computar los feriados por región o país, o mismo rutinas para ordenar registros por fechas.
- Una vez detectadas las rutinas, escriba específicamente un paquete de programas que llame a estas una y otra vez con diferentes fechas, verificando en cada caso si las respuestas son convincentes. Por ejemplo, en las rutinas que calculan diferencias de fechas haga un "colador fino" llamandola para cada dia del año 1999 y calculando la diferencia con el mismo dia del año 2000 (1 de Enero de 2000 menos 1 de Enero de 1999 = 365 dias, 2 de Enero... 3 de Enero... etc). Verifique que a partir de 1 de Marzo la respuesta debe ser de 366 dias.
En aquellas rutinas que calculan los dias de la semana haga repetidas pruebas con fechas escogidas aleatoriamente del año 1999, 2000 y 2001, verificando que los dias de la semana siempre están correctos. (por ejemplo el dia 20 de Agosto de 2000 DEBE ser un Domingo).
Si algún dia de la semana aparece incorrecto, debe proceder a una verificación sobre cual es la fórmula empleada en su confección. Si todas las rutinas están funcionando correctamente, entonces es bastante probable que todos los programas que las han llamado también estarán a salvo del problema, aunque pueden existir aquellos programas que se han saltado la regla y cuyos programadores decidieron hacer las rutinas ellos mismos sin utilizar las de uso público.
- Tente entrar en contacto con el vendedor del compilador COBOL (o cualquier otra lenguaje) que Ud. utiliza. Muchas veces una pequeña modificación dentro del compilador puede ahorrarle millones de dolores de cabeza (y Dolares). A veces es posible alterar el propio compilador para que utilize el bit de signo (+/-, generalmente no utilizado en las fechas) como un indicador si esta pertenece al siglo XX o al siglo XXI (algo asi como -01/01/99 = 1 de Enero de 1999, +01/01/99 = 1 de Enero de 2099).
- Verifique si no es posible programar una rutina de control centralizado que husmee automáticamente dentro de todos los ficheros con formato "ascii" que circulen por las redondezas (generalmente usados para transferencia de datos temporarios) y avise si alguna transferencia está siendo realizada usando el formato "dd/mm/aa" en lugar de "dd/mm/aaaa". Una transferencia de este tipo podrá generar errores en el año 2000 al pasar fechas como "01/01/00" a un sistema desatento.
- Construya un pequeño sistema dedicado específicamente al "problema del BUG", manteniendo actualizados en estos registros cuales problemas fueron detectados, donde y quien los ha solucionado y con quien contactar caso surja un problema inesperado.
C) SISTEMAS COMPRADOS/ALQUILADOS ORIENTADOS A "MAINFRAMES"
En este caso la empresa no dispone de los códigos fuente del sistema, y lo máximo que puede hacer es detectar el problema a tiempo, comunicar al proveedor del software y rezar para que el mismo consiga corregir a tiempo todos los problemas.
La única forma de detectar fallas aqui es colocando el sistema a funcionar en las fechas críticas, creando un ambiente especial dentro de la máquina, iniciando el reloj por ejemplo el 31 de Diciembre de 1999 y ejecutando todas las tareas posibles durante uno o dos días, verificando lo que sucede cuando el reloj cambia para el año 2000. Si el sistema presenta en algunos lugares visiblemente el DIA DE LA SEMANA (Lunes, Martes etc), coloque fechas aleatorias en la máquina (por ejemplo 5 de Julio de 2001, 14 de Octubre de 2000) y vea si el dia de la semana esta correcto. La sincronización correcta de los días de la semana con las fechas es un fuerte indicativo de que el sistema es consistente en las fechas y está a salvo de fallas (por ejemplo si Ud. ponde 1 de Enero de 2001 y ve un MARTES, entonces sabe que lo ha interpretado como 1 de Enero de 1901, visto que deberia ser un LUNES, y asi Ud. sabe que algo grave esta sucediendo dentro de la máquina).
Una buena idea es mantenerse en comunicación constante con otros usuarios del mismo sistema a través de los Grupos de Usuário (probablemente la empresa que le vendió a Ud. el sistema también lo ha vendido a otras firmas), y enterarse de esta forma de los problemas y soluciones que van apareciendo. Mantenerse aislado en este problema puede resultar caro.
D) SISTEMAS PROPIETARIOS ORIENTADOS A "MICROS" (generalmente IBM-PC compat.)
Muchos de los procedimientos citados para "mainframes" también se aplican a los "micros", visto que buena parte de los mismos esta hoy dia interligada en redes dentro de la empresa, asi, existen probablemente bibliotecas públicas de rutinas y las mismas pueden ser probadas de la manera ya citada.
El mundo de los "micros" se diversifica en el momento en que cada máquina actúa también como una estación de trabajo independiente (WorkStation), pudiendo ejecutar programas y rutinas que serian impensables en el mundo de los "mainframes", como por ejemplo planillas de cálculo (Spread Sheets), editoración gráfica (Desktop Publishing), o también estaciones CAD (Computer Aided Design).
Estas funciones consumen gran cantidad de recursos computacionales (tiempo de CPU y cálculo numérico), y serían impensables de ser ejecutados en una máquina centralizada por que la misma tendría que dividir el tiempo de CPU entre muchos centenares de personas con un resultado más que mediocre para cada uno.
Como cada "micro" tiene su propia memoria y CPU (bastante potentes hoy en día), el uso intensivo de una aplicación numérica en una determinada máquina conectada en red pasa totalmente desapercibida por sus vecinas, pero por otro lado crea una cantidad enorme de interfaces y conductos con otras aplicaciones que están presentes en la red.
Piense por ejemplo en una estación de trabajo ejecutando una planilla de cálculo y generando un listado temporario que por su vez deberá alimentar un sistema centralizado en el "mainframe".
Este listado puede contener fechas, y la persona que lo ha generado puede haber sido poco cuidadosa en el manejo de las fechas referentes al año 2000, así el listado que irá a alimentar a los ficheros centrales lleva algunas fechas del tipo "27/03/99" y otras "15/02/00" por que el usuário ha olvidado de alterar la máscara en las fechas.
El peligro que encierran estas aplicaciones reside en que cada usuário tiene una gran libertad de acción para generar datos que por su vez alimentarán a la red, y esta libertad de acción puede desencadenar una serie de fallas en el momento que las máscaras de transferencia de fechas no sean las adecuadas.
Una norma razonable es establecer que a partir de una determinada fecha (por ejemplo 01 de Octubre de 1999) no se aceptarán mas transferencias de fechas usando apenas dos dígitos para el año, y todas las fechas generadas en ficheros temporarios dentro la red deberán tener 4 digitos en el año.
No es imposible hacer alguna rutina de control escondida dentro de la red que verifique todos los datos que tengan algun "nn/nn/nn" en su contenido, avisando a la persona que lo ha creado sobre la inconsistencia.
Aquellos sistemas que utilizan SGBD (Sistemas Gerenciadores de Banco de Datos) como Oracle, Access, dBase-like etc. deben poner especial atención en las relaciones establecidas através de campos de fecha. A veces por descuido se corrige un campo en la tabla principal del banco de datos pero se olvida la corrección en tablas relacionadas.
Como los "micros" son utilizados frecuentemente en el procesamiento "on line" de entrada de datos, (o sea, una persona teclea incesantemente datos de entrada en la máquina), una gran parte del esfuerzo tendrá que ser dedicado a la reformulación de las pantallas de entrada para cambiar el formato externo de las fechas de "dd/mm/aa" para "dd/mm/aaaa".
Aqui es bueno un pequeño grito de alerta: no se apresure a cambiar TODOS los formatos de la forma antigua para la nueva en todas las pantallas, pues algunas soluciones intermediarias pueden ser mucho mas eficientes y fáciles de implementar, como veremos a seguir:
a) Mantener el formato inalterado, mudando solo internamente los programas para entender que años arriba de 50 significan "1900" y abajo de 50 significan "2000".
Fíjese que esta solución es sumamente interesante por que ahorrará dos toques de teclado al digitador (algo que puede significar mucho en las entradas masivas de datos), y su sistema puede perfectamente grabar las fechas internamente usando todos los cuatro digitos.
b) Mantener el formato inalterado en los campos que son apenas informativos (o sea, aquellas fechas que no se digitan, sino que solo se ven). En este caso, es mejor dejar la fecha como está, pues se ahorrará Ud. dos lugares a mas en la pantalla del ordenador, y puede programar la máquina internamente para que muestre siempre solo los dos últimos digitos del año (como ocurre actualmente).
Nada impide que la persona que ve un "01/10/00" SEPA que se trata del año 2000, mientras que si ve un "04/10/97" SEPA que se trata de 1997. La misma regla de "arriba y abajo de 50" se puede aplicar aqui. Ahorrar dos lugares en el año puede parecer ridículo, pero piense en aquellas pantallas tabulares donde hay 5 o 6 tipos de fechas, una al lado de la otra. Con 2 lugares para cada fecha Ud. estará ganando un espacio de 10 o 12 caracteres en el ancho de la pantalla. La misma norma puede ser aplicada a los listados tabulares en papel.
E) SISTEMAS COMPRADOS/ALQUILADOS ORIENTADOS A "MICROS"
En este caso valen las advertencias lanzadas para los "mainframes". Muchas veces NO es posible corregir el problema por no disponer de los códigos fuente, pero si es posible PREVER que un problema ocurrirá y comunicarlo a los proveedores para que lo corrijan.
Sistemas que ejecutan en ordenadores personales son mas fáciles de probar pues el cambio de fecha en los Sistemas Operativos como el MS-DOS o UNIX es fácil de realizar. De esta forma es muy facil y barato destinar una o dos máquinas aisladas para ejecutar intensivamente con los relojes colocados en las fechas críticas sin afectar el resto del trabajo dentro de la empresa.
En aquellos sistemas que operan sobre SGBD (Sistemas Gerenciadores de Banco de Datos) como el Oracle, Acess etc, efectúe un chequeo sobre los listados emitidos en un intervalo que contenga partes del año 1999 y partes del año 2000 para ver si los resultados aparecen acordes con lo esperado (o sea, primero los años 1999 y despues los años 2000). Esto puede parecer obvio, pero recuerde que no todas las llaves de indexacion y ordenamiento usan todos los números de las fechas. Puede muy bien la fecha estar correctamente guardada en el banco de datos pero incorrectamente ordenada por causa de los "9" y los "0". Si Ud. no puede manipular y corregir los índices fallos, entre en contacto con la empresa que ha desarrollado el sistema.
Si desea saber como lucirán los ordenadores en el próximo milenio le invito a leer El Canto del Cisne"
