Antecedentes
A menos que lo arreglen…todas las computadoras…en todas partes del mundo…sufrirán un choque en enero 1 de 2000. ¿Puede imaginarlo…sólo por un momento… el caos que causaría? Sería en el tráfico aéreo, luces de tránsito, sin luz en su compañía, compañías que no producirán bienes, no habrá bienes en las tiendas a tiempo, la tiendas no podrán enviar las facturas y no podrá enviar a nadie sus facturas. Los negocios caerán en punto muerto. ¿Podría ocurrir una catástrofe como esta? Bueno, si lee esto y piensa en las consecuencias, tal vez podría reducir la probabilidad del fortalecimiento del evento. Si ignora las advertencias, o si rehusa a preguntarse ¿Podría pasar?, entonces Ud. es parte del problema. ¿Cómo es posible que las computadoras lleguen a sucumbir? La explicación es simple, muy simple y mucha gente como Ud. tiene dificultades para creer en el problema. Después de Diciembre 31 de 1999, las computadoras no sabrán qué año es. Esto puede sonar alocado. Suena como historia de ciencia ficción. Pero es realmente lo que pasará. Aquí está el porqué.
Nuestros programadores de computadoras, para almacenar las fechas siguieron este formato: dd/mm/aa. Esto significa que hemos permitido utilizar 2 dígitos para el día (dd), dos para el mes (mm) y dos para el año (aa). ¿Es claro el problema?
Algunos ejemplos podrían ayudar. Yo nací en agosto 02 de 1963. Almacené la información en la computadora así: 02/08/63. Los hermanos Wright realizaron su primer viaje en avión en diciembre 17 de 1903, y es almacenado como: 17/12/03. Cuando lleguemos a 1 de enero de 2000 la información de las computadoras será 01/01/00.
¿Ahora ve el problema? Le hemos indicado a las computadoras que asuman que 02/08/63, que 17/12/03 significan 02/agosto/1963 y 17/diciembre/1903 respectivamente, ¿qué pasará si asume eso para 01/01/00, que ella interpretará que es 01/enero/1900. Esto es. Este es el problema. Las computadoras, todas las computadoras, pensarán que todas las fechas después del 31 de diciembre de 1999, serán de 100 años en el pasado.
¿Y qué? Para entender las implicaciones de este "pequeño" error, debemos mirar una de las más básicas, de los más comunes, cálculos realizados por computadora. Los cálculos para determinar cuánto tiempo ha pasado de un evento a otro, por ejemplo ¿cuántos años tiene Ud.?
Yo nací en 02 de agosto de 1963, Si le preguntamos a la computadora por mi edad, ella restará mi fecha de nacimiento a la fecha actual. O sea algo así: 97-63(recuerde que sólo son dos dígitos para la fecha) y su respuesta será: 34 años, lo cual desafortunadamente es cierto.
En enero 1 de 2000, los cálculos se harán exactamente igual, restando el año de mi nacimiento al año actual, es decir 00-63, y yo proclamaré a viva voz que tengo -63 años de edad. Lo cual es risible, erróneo y causará problemas para cualquier programa que haga cálculos con base en este dato. Pero el problema afecta a más que sólo a cálculos. Afecta a toda la información que se basa en el tiempo. Cuando expira una licencia de conducir. Cuando expira una tarjeta de crédito.
Cuando una medicina se vence. Cuando una maquinaria tiene que ser reparada. Cuando construir un producto. Cuando expira una suscripción. Todos estos cálculos se basan en fechas, y si una computadora no sabe la fecha, estos cálculos no pueden realizarse.
Tal vez esté en su mente volando ideas como "¡Cómo pudieron ser tan torpes los programadores de computadoras!… ¡No sabían que el año 2000 llegaría…!¿Porqué no almacenaron desde el principio las fechas con cuatro dígitos?, y finalmente, cuando menos… "bueno, que le pongan cuatro dígitos a las fechas y ya, es todo." ¿Qué problema hay en esto?
Estas son ideas comunes para quienes escuchan sobre "La crisis de las computadoras en el año 2000". Todos estos y más se vuelven más incrédulos cuando se les mencionan los costos estimados para solucionar este problema: $600 billones (US) en el mundo. $600 billones por arreglar dos dígitos perdidos, de otra manera las computadoras en todos el mundo caerán el caos. Y esto sí suena a ciencia ficción. Desafortunadamente no lo es. Es muy real y afecta a todos en la tierra.
Haga la obvia pregunta ¿Por qué se utilizaron dos dígitos sabiendo que necesitaríamos cuatro dígitos con la llegada del nuevo milenio? Bueno, la mala noticia es que esto se hizo deliberadamente, pero con muy buenas intenciones, siendo honestos. […]
El problema del año 2000 surgió por una decisión de compromiso ingenieril de darle al campo fecha correspondiente al año sólo dos dígitos para ahorrar memoria (un recurso muy costoso en ese momento). Pero eso ocurría hace casi treinta años, cuando el fin de milenio se veía como algo tan lejano que se creía que habría tiempo suficiente para corregir este problema. Si nos ponemos a pensar, el 31 de diciembre de 9999 las computadoras estarán en un problema similar. Lo primero que tendemos a imaginar es que hasta el 9999 las computadoras evolucionarán hasta límites insospechados. Pero esto es algo muy similar a lo que creían en aquellas épocas quienes se decidieron cortar el año a dos dígitos.
Cuando las computadoras llegaron a los negocios mundiales a finales de los 60's principios de los 70's eran muy costosas. Este costo, se presentaba directamente en dos aspectos de la computación: cuántos datos podrían almacenarse y qué tan rápido era el proceso de esos datos. Así incrementar algunos atributos eran asunto de costo y rapidez.
Una forma de almacenar datos era por medio de las "tarjetas de Hollerith", o tarjeta perforadas, que se creaban según un patrón y leídas por medio de luz. Cada una de esas tarjetas, tenían espacio suficiente para 80 caracteres de información. 80 caracteres no era mucha información. Escriba en ella su nombre completo, dirección, fecha de nacimiento y los blancos entre palabras, fácilmente sobre pasa los 80 caracteres. ¡ Que gran problema almacenar información en estas tarjetas! Este fue precisamente el problema con que se enfrentaron los programadores de los 60's y 70's. Las tarjetas no eran suficientes para almacenar toda la información que se necesitaba, era realmente un compromiso. Así que escribían 020863 por 02/08/1963 salvando así cuatro preciosos caracteres, de los cuales dos eran "19". Los programadores comprometieron exactitud por costos cuando decidieron almacenar el año en dos dígitos. Su razonamiento, hasta ahora, tenía mucho sentido. Especialmente si ubicamos este compromiso en su época. Eran los 60's y 70's, faltaban 30 o 40 años para el cambio de siglo, era lejano.
Parte de su razonamiento era que sus códigos en este tiempo serían reemplazados. Se asumió que los programas escritos en los 60's y 70's no estarían en uso 30 años después. Esta particular presunción estaba equivocada, muy equivocada. Tenemos muchísimo código antiguo en uso, hoy día, conocido como "Sistemas heredados".
Tenga en cuenta que los compromisos nunca se hicieron en forma aislada, siempre fueron con colaboración. Los administradores de centro de cómputo, le decían al cliente que si querían almacenar cuatro dígitos en la fecha debían adquirir una computadora más grande y que se debían escribir programas más complicados para almacenar esos datos o utilizar 4 tarjetas perforadas más. El cliente típicamente les diría: ¿Acaso estás loco? ¿Quiere que gaste otro millón de dólares para almacenar dos dígitos más, que probablemente no serán utilizados hasta dentro de 30 años? ¡Deje todo con dos dígitos y déjeme tranquilo! Más bien utilice sólo un dígito y ahórreme dinero.
Pues bien este compromiso se constituyó en un estándar en la industria. Las computadoras siempre eran caras, hasta la última década cuando se ha hecho posible que incluso tengamos computadoras en nuestra casas y son mucho más poderosas que las del 60 y 70. El problema es que mientras las computadoras cambiaron, aquel estándar no cambió. Muchos programadores, hasta ahora, han escrito códigos que fallarán en el año 2000. Generalmente no somos muy buenos para mirar el futuro y planificar eventos que tendrán lugar 5 años en el futuro. Otro desafortunado capítulo en esta historia es que los "profesionales" en computación son muy rotativos. Es inusual que en la industria de la computación trabajen por más de 5 años para la misma compañía haciendo lo mismo. Por qué preocuparse entonces por un problema que se presentará en el futuro, si probablemente trabaje en otro sitio.
Bien, entendemos el problema, pero el problema seguramente es sencillo de resolver, sólo ponga dos dígitos más y ya, ¿qué problema hay en eso?
Bueno realmente esto no es difícil del todo. Prácticamente cualquier programador puede mirar una línea de código que contiene un cálculo de fecha y hacer los cambios necesarios para resolver el asunto. Pero el problema es que ¡ese no es el problema…! Cuando se dice "ponga dos dígitos más y ya", se está haciendo una presunción. Y el que la hace no sabe qué dañina es. La presunción es que: sabemos dónde están las fechas. ¡No es cierto!. No sabemos dónde están las fechas en nuestros códigos de programas y debemos buscarlas para arreglarlas.
Buscarlas es la parte más larga del problema por dos razones: La primera, ¿tiene idea de la cantidad de líneas de código que se han escrito en los últimos 30 años? No es difícil para una compañía tener 100,000,000 líneas de código o más. (para este artículo se asume que su compañía los tiene). 100,000,000 no es fácil de recorrer, y es complicado darse una idea de lo que significa en líneas de código.
¿Qué tan largo puede llegar, sólo mirando las líneas si gasta un segundo en cada una? Asuma 8 horas al día, 5 días a la semana… se tomará 13 años para ver todas esas líneas de código. O tomaría 13 personas en un año. O 156 personas en un mes.
Indudablemente, esta situación tiene todas las características propias de una verdadera crisis. Los japoneses describen el concepto de crisis con la unión de dos ideogramas: el di riesgo y el de oportunidad. Y esto guarda muchas analogías con el problema del 2000. Para una empresa, resolver este problema implica destinar una gran cantidad de recursos. Entonces, surge el interrogante obvio: si vamos a encarar un proyecto de tal magnitud solo para solucionar unproblema de compatibilidad de fechas, ¿por qué no aprovechar esta "oportunidad" para mejorar la tecnología de la empresa? Y esta es la tendencia de solución que más beneficios trae: convertir la crisis en oportunidad.
¿A quién se le pasó por alto?
En todas las profesiones suelen existir prácticas que perduran mucho tiempo después que desapareció la razón que les dio origen; la programación de las computadoras no es una excepción. La costumbre de ahorrar dos lugares de memoria guardando sólo los dos últimos dígitos del año de una fecha ha sobrevivido desde los orígenes de las computadora electrónicas, allá por 1946, hasta el año 1996, sin descartar que alguno que otro "distraído" la siga utilizando hoy en día. Esta simplificación se dan en los cuatro niveles que suelen presentarse en la operatoria del procesamiento electrónico de información:
Las máquinas intrínsecamente consideradas, con su "BIOS" o sistema básico de arranque y funcionamiento. El sistema operativo, o programa madre, que a su vez carga todos los programas, aplicaciones y utilitarios. El lenguaje o entorno de programación, fuente de las aplicaciones. Los datos e información propiamente dichos, generados por el sistema e ingresados por los usuarios o provenientes de otros sistemas.
Pensándolo rápidamente, puede parecer que el ahorro de dos dígitos no es significativo, pero es preciso considerar dos factores: por un lado, el costo por unidad de información guardada y ,por el otro, la cantidad de registros en que aparece la fecha. Si retrocedemos hasta 1964, el costo de almacenamiento por MB tenía una gran dispersión de acuerdo con el tipo de equipo y la clase de medio, ya que todavía eran muy populares las grandes cintas de carrete abierto que, aunque no eran tan costosas, sí eran muy lentas (las que sí eran costosas eran las consolas de cinta). No obstante, y para dar un orden de magnitud, se podría estimar un promedio de U$S 11.000 por MB. Otro buen año para tomar como referencia es 1985, cuando se había extendido el uso del disco rígido con cierto grado de estandarización y empezaron a popularizares las famosas Pcs modelo XT.
En dicha época, el costo promedio era de U$S 150 por cada MB, cálculo que surge de tomar tanto las unidades centrales, los famosos "Lavarropas"(por su tamaño y forma), como los enormes discos removibles.
El origen del problema proviene de utilizar solamente los dos últimos dígitos del año en el almacenamiento y procesamiento de fechas. Esta era una práctica común de programadores, fabricantes de computadoras y otros equipos, que buscaban ahorrar espacio de almacenamiento, debido a los altos costos del mismo. Pero que implícitamente suponía que los sistemas no continuarían operativos para el año 2000, al no soportar el cambio de milenio en la lógica de los mismos.
Al utilizar solo dos dígitos, el año 2000 se procesará como '00', teniendo consecuencias inesperadas y provocando comportamientos no previstos. Es el caso de cálculo de edades, años bisiestos, ordenamiento por fechas, generación de claves únicas, comparación por fechas. etc. El grado de impacto del año 2000 también dependerá de la naturaleza de la información almacenada o procesada, de la función soportada por el recurso (computadoras, sistemas, proveedores, interfaces, etc.) que falle y de la naturaleza de la falla. Muchas organizaciones tienen sistemas que para sus cálculos actuales utilizan fechas en el futuro: proyecciones, tendencias, presupuestos, vencimientos, cálculos de intereses, etc. Para dichos organismos los problemas del año 2000 ya son un hecho y no ocurrirán sólo después de la medianoche del 31 de diciembre de 1999.
Si bien el principal problema será el error o la ambigüedad en las fechas con formato de 2 dígitos, hay otros aspectos que también merecen consideración. Uno de ellos es que muchos sistemas se reservan determinados números como comodines o valores límites para facilitar la homogeneidad de las aplicaciones. Por ejemplo, ¿quién no ha utilizado al conocido cliente 999999 y su contraparte, el año 99?. También pueden causar problemas los sistemas que utilizan el 99 como límite superior para una transacción y el 00 como valor mínimo para la misma. Otro uso que se le ha dado al año 99 es como sinónimo de "sin fecha de vencimiento", generando la consiguiente confusión. Más grave aún (por la dificultad para detectarlo) es el caso de los sistemas que usan 4 dígitos para el año, pero los 2 primeros los pone siempre el programa, forzando el 19. Muchos de estos problemas sólo podrán detectarse mediante simulaciones muy minuciosamente planeadas.
Se acerca el fin del milenio y, con él, uno de los problemas más graves al que se tendrá que enfrentar nuestra sociedad tecnológica. He aqui una visión sobre lo que nos puede esperar si no actuamos cuanto antes.
Imagine que el reloj digital de su oficina, en el piso 15 del edificio, marca un minuto antes de la medianoche del 31 de diciembre de 1999. Está a punto de terminar un complejo proyecto que lo ha mantenido absorto durante varias semanas. La alarma de su reloj de pulso marca exactamente las 00:00 horas: ya es el año 2000. Decide hablarle a su esposa, toma el teléfono de su escritorio y marca la clave que le da acceso a una línea fuera de la oficina. No escucha el tono habitual de marcado, así que lo intenta de nuevo, pero el teléfono no funciona. De igual manera, la máquina del fax y el aire acondicionado se han apagado.
En su computadora trata de revisar la base de datos del proyecto y advierte que el programa falla inexplicablemente y que no hay una solución rápida a la vista. Como ya está muy agotado, opta por retirarse a casa. Cuando llama a uno de los elevadores, ve que ambos permanecen estacionados en el sótano del edificio y no se mueven pa ra nada. ¡Sólo esto le faltaba! Después de bajar 15 pisos por las escaleras de emergencia, se da cuenta de que la puerta de seguridad que conduce hacia el estacionamiento no se abre con su tarjeta de acceso electrónica. Tiene que abrir la puerta manualmente, y la alarma de seguridad no se activa, cosa que ya no le sorprende. Finalmente llega a su auto, pero le es imposible arrancarlo. El tablero de diagnóstico le indica una falla en la computadora central. Por lo visto, tendrá que caminar 10 kilómetros hasta su casa.
Esta situación imaginaria es una de las menos graves que probablemente nos sucedan al inciar el próximo siglo. Y es que, justo en el cambio de año, de 1999 al 2000, se hará patente uno de los errores tecnológicos más triviales y, a la vez, más grandes de la historia, con una serie de consecuencias desastrosas para todo el mundo si no se actúa cuanto antes.
¿En qué consiste el error del año 2000? Básicamente en representar, dentro de un programa de cómputo (que puede estar en una computadora o un microprocesador que controle algún proceso automático), la fecha con dos dígitos en vez de cuatro. Por ejemplo, la representación dentro de un programa para 1997 es 97.
En muchos programas, especialmente los de inventarias, finanzas y manejadores de bases de datos, como un procedimiento estándar se acostumbra comparar fechas restando los dígitos del año para ordenar las bases de datos o, simplemente, para actualizar un sistema de facturación o de nómina.
Hasta aquí, todo suena bien; basta con restar la fecha mayor de la menor. Así, 1999 – 1997 = 99 – 97 = 3. Pero ¿qué tal 2000 – 1997 = 00 – 97 = – 97? ¿ Acaso han pasado -97 años entre 1997 y el 2000? ¿Cómo puede tener esto coherencia para nosotros o para el programa? ¿Por qué se cometió un error tan trivial? Independientemente de la mala o nula implementación de una ingeniería de software adecuada, existen otros puntos de vista al respecto que tratan de justificar el error.
Cuestionando a algunos de mis colegas desarrolladores de software, que han programado casi durante las últimas dos o tres décadas, he encontrado un sinnúmero de explicaciones, que van desde: " … pensamos que era más fácil para el usuario, que tenía que introducir una gran cantidad de datos, teclear dos dígitos para la fecha en vez de cuatro", hasta: " … nunca creímos que nuestros clientes usaran nuestro software más de una década… consideramos que, como su sistema de cómputo ya iba a salir del mercado por obsoleto, nos iban a pedir que diseñáramos un nuevo software para su nuevo hardware".
Una explicación un poco más realista es que muchos lenguajes, tales como el COBOL, representan los años con dos dígitos por default y tienen su propia representación para las fechas. Así, el 26 de febrero de 1990 se representa como 900226 y el 1' de enero de 1991 como 910101, lo cual permite a la computadora comparar los dos números y asumir correctamente que el número menor representa la fecha más antigua. Por supuesto, en el caso del 12 de enero del 2000 (o 000101), la comparación fallará. (Otro lenguaje menos obsoleto que el COBOL, que usa dos dígitos para el año, es el Clipper, por lo menos en su
versión Nantucket 87.)
Claro que hay -y hubo- forma de evitar estos errores fácilmente, al menos en los programas escritos para las computadoras. Sólo que implicaba teclear más o menos líneas de código, dependiendo de la habilidad del programador. Pero realmente no era cosa del otro mundo resolver el futuro error. Lo que pasa es que muchas veces nos regimos, como casi todo en la
naturaleza, por el principio de la mínima acción.
Cabe aclarar que este problema no sólo se refiere al COBOL o al Clipper, sino que puede encontrarse en varios lenguajes que son usados para crear programas de cómputo. En los programas escritos para los mieroprocesadores, el conflicto radica fundamentalmente en que, por diseño, existen chips que sólo tienen una cantidad limitada de memoria para manejar la fecha y, si se añaden dos dígitos más para ésta, hay problemas de saturación de memoria, así que el chip termina por fallar. También algunas PCs enfrentarán serias dificultades por el cambio de fecha, debido al diseño de su chip BIOS.
De acuerdo con la estructura de los programas o el estilo de programación, los resultados pueden ser muy variados. Van desde el sencillo mensaje de error en la pantalla de la computadora, cuando se trate de usar el programa, hasta la corrupción de las bases de datos y las fallas impredecibles en sistemas automatizados que son controlados por mieroprocesadores, que basan su funcionamiento en las comparaciones de las fechas.
Crónica de una catástrofe anunciada
¿Es realmente esto tan grave como parece? En noviembre de 1995, el Departamento de Defensa de los Estados Unidos fue uno de los primeros organismos en alertar a todo el mundo sobre el error del 2000. Por lo menos dentro del ejército, implementar una logística precisa y eficiente para resolver el error en todos los sistemas de cómputo que dependían de las fechas pasó a ser prioridad número uno. Aun esta dependencia, siendo muy cuidadosa con el desarrollo del cómputo intramuros, iba a tener que lidiar con millones de líneas de código obsoleto y mal documentado. El problema era serio, pues se habían desarrollado lenguajes y dialectos de cómputo propietarios, tales como el Jovial, que a la fecha están en desuso, así como toda una serie de chips diseñados para una gama de aplicaciones, lo mismo para el control de misiles que para tener un minio sobre los procesos automáos de los almacenes de material activo -tales como el de Pantex, en Texas, que es el depósito de pluto nio más grande que existe sobre la Tierra- o sobre los radares, comunicaciones y sistemas logísticos.
Los peligros son obvios en el ejército, pero fuera, ¿qué podemos esperar? Ello depende de la cantidad de sistemas críticos que estén basados en años de dos dígitos. Por ejemplo, un sistema que se dedique a calendarízar juntas para una compañía fallará totalmente en el 2000, pero tal fracaso no pasará de ser una pequeña molestia para esa empresa. En cambio, la más pequeña imprecisión en un sistema que programe por fechas el mantenimiento de las partes de los aviones de una línea aérea es totalmente inaceptable.
Otro lugar donde se puede tener un gravísimo impacto es en la banca, y no sólo por la predecible caída de la Bolsa para el 2000, sino por una serie de posibles errores con la actualización de los intereses de las cuentas, por citar un ejemplo. Michael Yudkin, el responsable del área de proyectos de tecnología del Chase Manhattan Bank, sabe acerca de este riesgo: "Nosotros procesamos 2 trillones de dólares por día; sí un error ocurre, no vamos a recibir una llamada de nuestro CEO. ¡Nos van a llamar de la Casa Blanca!"
Según los analístas, los problemas no terminarían ahí. Habría que vigilar muy de cerca hospitales con áistemas de soporte para pacientes críticos, plantas nucleares (fundamentalmente con tecnología obsoleta, como en la ex Unión Soviética), sistemas de posicionamiento global (GPS), industrias que usen chips basados en fechas para el control de flujo de fluídos y sistemas de control de vuelos comerciales (si bien la Administración Federal de Aviación ya ha tomado cartas en el asunto para reemplazar todos los sistemas de control de tráfico aéreo con el Sistema de Automatización Avanzado o AAS). El Departamento de Defensa de los Estados Unidos calcula que el costo para resolver el error del 2000 en la industria del cómputo a nivel mundial va de 400 a 600 bíllones de dólares. Esta suma se repartiría así: 10% para resolver el problema directamente, 40% para implementar directrices de solución y 50% para pruebas tanto de vulnerabilidad como de la misma solución implementada.
Particularmente en un país como México, ¿qué se debe hacer? Incorporar directrices de solución es un poco más difícil que en los países del Primer Mundo. Para empezar, ellos tienen una tecnología computacional nativa, tanto en hardware como en software, junto con una serie de agencias gubernamentales, centros de investigación y universidades ampliamente vinculadas con la industria, que cuentan con una enorme infraestructura de cómputo desde hace décadas y que están díspuestas a ayudar a las empresas, gubernamentales o no. Aparte, y debido al fuerte poder adquisitivo en esas naciones, la obsolescencia en equipos de cómputo comerciales es mucho menor que en nuestro país, en donde cambiar grandes equipos del tipo mainframe o actualizar software resulta bastante más difícil.
El lector debe empezar por cuestíonarse si su empresa tiene un sistema de cómputo obsoleto (que, con error del 2000 o sin él, es probable que falle tarde o temprano). Después, si su sistema depende críticamente del manejo de fechas. Para ello debe acudir en una primera instancia al dístribuidor y tratar de arreglar con él garantías, contratos de mantenimiento o contratos de arreglo del problema. Aquí es preciso que tenga mucho cuidado, pues muchos proveedores de software/hardware probablemente traten de evadirse argumentando que sus sistemas son infalibles o tratando de embromarlo con una serie de cláusulas poco claras en los contratos o garantías. Está en todo su derecho de exigir cartas firmadas como responsivas, para lo cual puede solicitar la ayuda de consultores profesionales en el área de cómputo e, incluso, de la Procuraduría Federal del Consumidor.
Imaginemos que está a punto de adquirir cualquier sistema de cómputo, ya sea hardware o software, desde una PC hasta un mainframe, o desde cualquier software comercial para procesar textos y hojas de cálculo o manejar bases de datos, hasta la implementación de un complejo sistema de cómputo hecho a la medida de su empresa.
La primera pregunta que debe hacer, aun antes del precio, es si el sistema no tiene conflicto con el cambio de fecha, y hasta qué día es contable. Y si decide comprar un sistema que va a ser contable hasta el año 2010 o hasta el 2500, por ejemplo, asegúrese de que el proveedor ponga esto por escrito en su garantía, contrato de mantenimiento o carta responsiva firmada. Para ello también puede solicitar la asesoría de un consultor de cómputo especializado. Todavía falta poco más de dos años para implementar soluciones urgentes y radicales. De no hacerlo, habrá que resignarse no sólo a que se pierdan aviones en pleno vuelo, se deteriore la economía mundial o haya una infinidad de accidentes industriales, sino a que nos privemos de lo mucho que hemos ganado como sociedad basada en la tecnología de la información.
La proximidad del Año 2000 ha puesto de manifiesto el alto riesgo existente de que los sistemas informatizados fallen o realicen tratamientos erróneos debido a:
- Empleo de formatos de fecha para el año con solo dos posiciones (año en siglo).
- Diseño y funcionamiento de los relojes y sistemas internos.
- Consideración equivocada del Año 2000 como no bisiesto.
Por otro lado, la equivocación, muy extendida, de denominar a la llegada del Año 2000 como cambio de siglo o cambio de milenio, siendo así que no se pasará al nuevo siglo y milenio hasta el día 1 de enero del 2001, en principio solo es conceptual y no es de esperar que tenga mayor trascendencia.
Orígenes del problema
En el primer caso, uso de dos dígitos para el año, el motivo inicial para ello fue, hace ya bastantes años, la necesidad de ahorrar espacio en los dispositivos de almacenamiento, muy caros en aquellos momentos, y en muchos casos limitados técnicamente por la arquitectura y posibilidades de los equipos. A ello se unía la reducida capacidad de proceso y el lógico deseo de optimizar los tiempos globales de ejecución.
La consideración del Año 2000 no parecía oportuna; se trataba de un futuro relativamente lejano y el creciente avance de la tecnología hacía previsible una sustitución de los sistemas antes de su llegada.
Pese a haber cambiado las circunstancias como consecuencia del rápido desarrollo tecnológico, procesos posteriores siguieron este mismo criterio de utilizar sólo dos dígitos para representar el año, sobre todo para facilitar la necesaria compatibilidad con los antiguos sistemas y métodos, pero también en parte debido posiblemente a la costumbre.
En cuanto a la segunda causa, relojes y sistemas internos no adaptados, su origen es similar. Las posibilidades técnicas existentes en los primeros momentos y los criterios iniciales de diseño adoptados han constituido normalmente la base sobre la que han ido evolucionando equipos y sistemas básicos, buscando unos menores costes de desarrollo de los productos y el aprovechamiento en la mayor medida posible del parque informático instalado.
Por último, la errónea consideración del Año 2000 como año normal o no bisiesto tiene su origen en el olvido, hasta cierto punto comprensible por su excepcionalidad, de una parte del convenio que rige, desde la reforma de Gregorio XIII en el año 1583, la determinación de los años bisiestos, como medio para absorber totalmente la diferencia entre el año solar (algo más de 365,25 días) y el año de calendario (365 días). La expresión completa de dicho convenio es:
Serán en principio años bisiestos, que tendrán un día más que los normales y que corresponderá concretamente al 29 de Febrero, los años que sean múltiplos de cuatro, excepto aquello que simultáneamente sean múltiplos de cien, salvo que a su vez lo sean de cuatrocientos.
Esto significa que desde el año 1600 no se había dado que un cambio de centuria coincidiera con un año bisiesto y, por supuesto, es la primera vez que ésto ocurre desde que existen los actuales sistemas informáticos.
Debido a las causas expuestas es muy probable que surjan problemas en:
Los Sistemas de Información o Aplicaciones Informáticas, tanto desarrollados a la medida como estándar, y sobre todo en los más antiguos o en los modernos con ellos relacionados, ya que gran parte utilizan, para representar el año, los dos últimos dígitos significativos en lugar de las cuatro cifras.
Asimismo hay muchos programas que ejecutan algoritmos de cálculo en los que no se ha tenido en cuenta que el año 2000 es bisiesto.
Los propios Sistemas Operativos, Gestores de Bases de Datos y otros de utilidad o básicos que pueden ser incapaces de trabajar con años expresados con cuatro dígitos.
Los ordenadores cuyo reloj del sistema retorne en el año 2000 o sucesivos a un año base, que será incorrecto y provocará errores en los programas que se exploten en ellos y hagan uso en cualquier forma de la fecha del sistema.
Además existen todavía en operación algunos ordenadores que no soportan el formato de fecha completa en ocho dígitos.
Los equipos y sistemas de control, generalmente denominados sistemas empotrados, como los empleados en ascensores, semáforos, puertas o cajas de seguridad, etc., que utilizan procesadores y, en general, elementos informáticos para su funcionamiento, y que pueden fallar al considerar valores incorrectos en cualquiera de los parámetros por ellos manejados (día de la semana, número de la semana, etc.).
Por otra parte, desde una perspectiva funcional los problemas pueden afectar a cualquier Área de un Organismo, ya que hoy en día prácticamente todas las unidades organizativas de las Administraciones Públicas hacen un uso importante, cuando no intensivo, de los medios informáticos.
Normalmente cualquier organización, y por supuesto las Administraciones Públicas, utilizan de forma habitual en sus procesos informáticos datos basados en la consideración de fechas y que pueden verse afectados.
En general los tipos de problemas más probables serán:
Errores en algoritmos aritméticos debidos a la identificación del año por medio de sólo dos posiciones (aa), como:
- Años de antigüedad de los empleados a partir de su fecha de ingreso.
- Edades calculadas a partir de la fecha de nacimiento.
- Fechas de renovación o vencimiento en función de una fecha inicial y un plazo dado (carné de conducir, avales, …).
- Plazos de liquidación sobre la base de la diferencia entre dos fechas (intereses, recargos, …).
Etc.
Por ejemplo, suponiendo que ya se estuviera en el año 2000, si un empleado entró en 1952, el cálculo de la antigüedad en el Organismo, con el formato del año de dos dígitos, resultaría de la siguiente manera:
00 – 52 = – 52
es decir un resultado negativo, que de no esperar el programa el valor con signo se consideraría como positivo y válido, siendo así que el cálculo correcto debería haber sido 48 años.
Errores de lógica en los programas, también causados por la identificación del año por medio de solo dos posiciones (aa), como:
- Aplicación de valores según fecha de vigencia (tipos impositivos, tasas, …).
- Tomas de decisión automáticas en función de fechas (borrado de datos, contenidos de la información, …).
- Etc.
Un ejemplo de este tipo de problemas sería la ejecución en el año 2000 de un proceso de paso de los datos de los padrones anteriores al año 1990 a ficheros históricos en cinta fuera de línea, es decir no accesibles directamente desde el ordenador, en el que se planteara la disyuntiva:
Si Año (aa) < 90 mover registros a soporte en cinta
ya que evidentemente para el año 2000 el valor considerado sería 00, que es menor que 90.
Errores en los procedimientos informatizados debidos al uso en los programas con fines especiales de valores específicos del año representado en dos dígitos
Este es el caso, por desgracia no tan infrecuente, de haber empleado el valor 00 para indicar año desconocido o 99 para marcar el fin de un fichero.
Errores en procesos de ordenación de registros de datos al estar identificado el ejercicio por solamente dos posiciones.
Evidentemente en esta situación los valores correspondientes a los primeros años dos mil precederían a los de los últimos años mil novecientos en una secuencia ascendente y viceversa en una descendente.
Errores de diversos tipos, según la eventual utilización en los programas de la fecha del sistema, si el reloj interno o determinadas utilidades no se comportan correctamente con relación al año 2000 o sucesivos. Errores en los cálculos o la lógica de los programas debidos a no identificar al año 2000 como bisiesto.
Plazos de vencimiento según días del año 2000 transcurridos en una fecha posterior al 28 de Febrero (días hábiles para presentación de recursos, cobro de recargos, …).
Determinación del día de la semana, también a partir del 28 de Febrero del 2000 (apertura programada de cajas fuertes o puertas de seguridad, frecuencia de cambio en semáforos, …).
Identificación de las fechas de comienzo y fin de una semana concreta, posterior a la décima.
Errores, prácticamente de todos los tipos anteriores, pese a haberlos previsto internamente por falta de consistencia con los trasmitidos por o a terceros: otros organismos públicos (estatales, autonómicos, locales o supranacionales) o empresas privadas.
Además hay que tener en cuenta que estos problemas tendrán un efecto "dominó", es decir se propagarán en cascada, contaminando posiblemente a otros procesos que podrían haberse ejecutado de forma correcta.
Magnitud esperada del error del año 2000
Si bien las evaluaciones más recientes, basadas en una mayor experiencia práctica, tienden a rebajar algo las apreciaciones hechas inicialmente por los estudiosos teóricos del tema, los expertos siguen considerando como de primera magnitud los problemas derivados de la llegada del Año 2000.
Una idea al respecto la pueden dar las siguientes estimaciones en cuanto al grado de afectación para una instalación de tamaño medio:
Componentes (programas, rutinas, copys, etc.): del orden del 80 %, normalmente con un mínimo del 60 %. Datos: en torno al 3 %.Líneas de Código de los componentes: entre un 2 % y un 5 %.
Estas cifras deben considerarse solamente a título indicativo, en cuanto previenen sobre la posible gran dimensión del problema, ya que las circunstancias propias de cada instalación pueden suponer importantes variaciones de las mismas, tanto a favor como en contra.
Aún cuando el problema del Año 2000 podría asimilarse simplemente a un proyecto de mantenimiento de los elementos informáticos de una organización, de gran magnitud eso sí, presenta una serie de peculiaridades que es necesario resaltar, pues son la causa de su singularidad e importancia.
El problema afecta a la totalidad del mercado prácticamente, ya que, de una manera u otra, su ámbito es mundial y alcanza a todas las organizaciones, tanto públicas como privadas, comprendiendo a sistemas y equipamiento.
La fecha límite será el 1 de Enero del año 2000, en la que el problema deberá estar totalmente resuelto, no siendo posibles retrasos si que ello suponga un gran riesgo.
Incluso, algunas áreas deberán haber resuelto sus problemas antes de dicha fecha, si deben operar con fechas de los años 2000 a medio o largo plazo:
Durante los periodos de sustitución, conversión, pruebas e implantación los procesos o elementos cambiados deberán coexistir con los antiguos, aún no adaptados, con el mantenimiento habitual del conjunto y con la gestión diaria, no siendo en general admisible la paralización de las actividades, ni siquiera durante cortos períodos de tiempo.
Simultáneamente aparece otro efecto, el de la adaptación al Euro, que afecta a cualquier organización dentro de la Comunidad Europea cuyo país se haya integrado en la Moneda Única, lo que seguramente será el caso de España.
Los procesos de cambio en ambos casos, Euro y Año 2000, se desarrollarán prácticamente en paralelo, durante un período muy similar y afectarán probablemente a gran parte de los Sistemas de Información.
Los recursos económicos que será inevitablemente necesario emplear en la adaptación al Año 2000, es muy probable que sean bastante elevados.
Sin embargo, el acierto en la estrategia y las decisiones adoptadas puede hacer que el montante económico se reduzca, si bien el desembolso será en general siempre considerable.
Las ejecuciones de los cambios se han de desarrollar durante un período prolongado de tiempo, a lo largo del cual pueden sufrir variaciones elementos internos como las estrategias y políticas a seguir, la estructura organizativa y los procedimientos de trabajo, y componentes externos como las tecnologías y los sistemas, básicos o de aplicación.
El ámbito y alcance de los cambios y, en general, acciones a emprender, dentro del contexto anteriormente descrito, hacen que los correspondientes procesos sean de una extraordinaria complicación, pese a su teórica simplicidad técnica.
El problema del año 2000 en el mundo
El mundo enfrenta actualmente uno de los grandes retos de la Era de la Información. A medida en que nos adentramos en un nuevo milenio, muchos sistemas de computación, así como los circuitos integrados que forman parte de prácticamente todo, desde las computadoras personales hasta los aparatos domésticos y el industrial refinado, están destinados a retroceder en el tiempo.
El problema es que muchos sistemas más antiguos de computadoras y circuitos integrados utilizan sólo los dos primeros dígitos de un año para registrar la fecha. De esta manera, cuando llegue el año 2000, esos circuitos integrados pueden reconocer 00 como el año 1900, no 2000. El mal funcionamiento resultante ocasionaría graves alteraciones de los circuitos de energía eléctrica, plantas de tratamiento de agua, redes financieras, sistemas de telecomunicaciones y sistemas de control de tráfico aéreo en todo el mundo. En un mundo cada vez más interconectado dentro de una economía mundial, las redes de computación son tan fuertes como su vínculo más débil. Si bien cada nación posiblemente experimente sus propios problemas de sistemas en particular, en un sentido bastante real, estamos todos en esto.
¿Por qué los diseñadores de programas de computadoras cometerían un error tan obvio? Hace 30 años, la memoria de las computadoras era mucho menor que en la actualidad, por lo que los programadores recurrían a atajos, como indicar el año con dos dígitos, para ahorrar memoria. Asumían que los programas que diseñaban pasarían de moda y serían reemplazados otros nuevos mucho antes del año 2000. Con todo, en la práctica, muchos sistemas de computación grandes y complicados, tales como los que emplea la banca, las aseguradoras o los corredores de bolsa han evolucionado con el paso del tiempo, añadiendo el último programa de computadora a los sistemas existentes. En consecuencia, cualquier organización que opera sistemas de computación interconectados a gran escala deberá revisar millones de líneas de código de computación para determinar cómo se manejan las fechas, acto seguido reescribir el programa para corregir el problema, luego poner a trabajar esas aplicaciones para ver cómo funcionan y posteriormente revisar la comunicación de cada programa con las aplicaciones internas y externas que utiliza.
No es difícil el ajuste tecnológico, pero debido a la gran escala de los problemas del año 2000, nos encontramos frente a un enorme desafío organizativo y gerencial. Sólo para citar un ejemplo: existe un grupolimitado de personas capacitadas para corregir el entuerto, programadores diestros en lenguajes de computación que pudieron haber quedado obsoletos hace años.
A fin de coordinar la labor en torno a este problema dentro de los muchos sistemas del gobierno estadounidense, el presidente Clinton ha formado un consejo de más de 30 agencias. Nuestra meta primordial consiste en mantener los servicios gubernamentales básicos: garantizar que se sigan concediendo los beneficios relativos a la asistencia médica y el desempleo, que la recaudación de impuestos no se vea alterada. El objetivo ambicioso del presidente es que el 100 por ciento de los sistemas gubernamentales esté "de acuerdo con el año 2000", esto es, ajustado, para marzo de 1999. Asimismo, el consejo cuenta con grupos de trabajo dedicados a la intercomunicación con los gobiernos estatales y locales en torno a este problema y a la evaluación de los esfuerzos de las compañías privadas en 35 sectores industriales, tales como transporte, telecomunicaciones y finanzas.
Por otra parte, nos inquieta la situación en cuanto a los esfuerzos para resolver el problema del año 2000 en otros países, toda vez que muchos sistemas de computación cruzan las fronteras nacionales y en la economía mundial ninguna nación es una isla digital en sí. Estamos trabajando a través de agencias internacionales para abordar el problema. La Organización de las Naciones Unidas aprobó una resolución que exhorta a todos los estados miembros a emprender acciones y notificarlo a la Asamblea General para el 1 de octubre. El Banco Mundial celebra 20 conferencias regionales para incrementar la percepción pública de este tema, a lo que Estados Unidos contribuiye con un aporte de 12 millones de dólares. El Fondo Monetario Internacional ha convenido en ejercer toda su influencia para alentar a los países a que inviertan recursos en el problema. La secretaria de Estado Madeleine Albright ha enviado un cable a las embajadas estadounidenses en todo el mundo, donde gira instrucciones a los embajadores para que indaguen en cada país anfitrión acerca de su grado de preparación para el año 2000. El Servicio Informativo y Cultural de Estados Unidos (USIS) encabeza un grupo de trabajo del Consejo Presidencial cuya misión es incrementar la percepción pública del problema, servir de puerta de acceso a la información y concentrarse en un plan de contigencia con otros países.
Desafortunadamente, a estas alturas, cuando faltan menos de 500 días para el 1 de enero del año 2000, considero que el mayor problema sigue siendo el de la percepción del problema por parte de dirigentesgubernamentales, periodistas, empresarios y el público en general en muchos países. El primer paso es que las naciones y las empresas privadas hagan un inventario de todas sus operaciones que abarcan computadoras y desarrollen un plan para corregirlas. Un segundo paso de vital importancia es la planificación de contingencia. El Consejo Presidencial para el Año 2000 ha solicitado a cada agencia gubernamental estadounidense que elabore dos tipos de planes: uno, ¿qué haremos si algunos de nuestros sistemas de computación no funcionan? El segundo nivel comprende un plan de contingencia externo: ¿qué haremos si fallan los sistemas interconectados con los nuestros?
Es posible que las perturbaciones relativas al año 2000 comiencen antes del nuevo milenio en la medida en que los sistemas anacrónicos intenten calcular o programar acontecimientos futuros. Es difícil predecir en este momento qué pasará precisamente. Existe un cúmulo de sitios en la Web en Estados Unidos donde algunos expertos a los que nadie catalogaría de alarmistas han pronosticado fallas extendidas del sistema que conducirán a interrupciones de energía eléctrica, problemas de tránsito, recesión económica y, posiblemente, en ciertas regiones, déficit de alimentos. Aunque tiendo a ser más optimista que estos profetas del desastre, me preocupan particularmente los países donde la inactividad y el desconocimiento podrían llevar a la materialización de algunos casos extremos. El caso es que al emprender acción ahora podemos reducir al mínimo las dislocaciones y, con optimismo, efectuar una transición sin tropiezos hacia el año 2000.
WASHINGTON — El vicesecretario de Hacienda de Estados Unidos Lawrence Summers dice que los países deben actuar ahora para evitar ramificaciones económicas mayores que podrían surgir de los problemas que plantea el problema de las computadoras conocido como "año 2000" (Y2K).
"A menos que se los corrija, los problemas del año 2000 afectarán todos los aspectos de nuestro sistema financiero, incluso la liquidación de transacciones financieras, el procesamiento de transacciones financieras rutinarias y el despacho de fondos en los sistemas de cajeros automáticos", dijo Summers, al declarar el 6 de julio en una Comisión Especial del Senado sobre el Problema Tecnológico del año 2000.
Las siglas Y2K significan año 2000 y se refieren al hecho de que el 1 de enero del año 2000, los miles de millones de circuitos integrados semiconductores de las computadoras de todo el mundo podrían registrar esa fecha como el 1 de enero del año 1900. Potencialmente todos los sistemas que usan estos circuitos integrados semiconductores podrían confundirse.
Summers urgió que los países den estos tres pasos en abordar la cuestión: realizar un inventario de todas las aplicaciones que requieren modificación; ordenar según su prioridad los sistemas claves y modificar los programas de computadora para asegurar que cumplen con los requisitos del año 2000; y ordenar que las firmas sometan a prueba sus programas actualizados.
"Debemos ser realistas en cuanto al hecho de que el problema del año 2000 es un acontecimiento nuevo, y no podemos prever todas las complicaciones que podrían surgir", dijo Summers. "No podemos descartar por entero la posibilidad de dislocaciones del sistema financiero y otros sectores de la economía, tanto en Estados Unidos como en otras partes. La clave consiste en administrar los riesgos mediante la asignación de prioridades a aquellos sistemas que deben estar absolutamente en condiciones operativas, en tanto que se dedican menores recursos a otras áreas, y se establecen arreglos de contingencia apropiados para reducir el perjuicio causado por cualquier falla que ocurra".
A continuación una traducción extraoficial del texto de la declaración de Summers como fue preparada para su lectura:
Declaración del vicesecretario de Hacienda Larry Summers ante la Comisión Especial del Senado de Estados Unidos sobre el Problema Tecnológico del Año 2000.
Señor presidente y miembros de la Comisión, el Departamento de Hacienda quiere agradecerles el que hayan realizado esta importante audiencia y apoya sus esfuerzos para examinar los problemas del año 2000 y sus ramificaciones en la banca y las finanzas internacionales. A menos que se los corrija, los problemas del año 2000 afectarán todos
los aspectos de nuestro sistema financiero, incluso la liquidación de transacciones financieras, el procesamiento de transacciones financieras rutinarias, y el despacho de fondos en los sistemas de cajero automático.
Todas las firmas financieras corren posible riesgo. Aun aquellas entidades que actúan de manera responsable para renovar sus propios sistemas pueden ser perjudicadas, debido a la naturaleza intervinculada del sistema financiero — una falla de una contraparte, proveedor o vendedor puede tener un impacto negativo en lo que de otro modo sería una firma solvente. Si las fallas son generalizadas, pueden representar una amenaza a los mercados centrales tales como las bolsas de valores y las cámaras de compensación.
La audiencia de hoy sobre esta cuestión se realiza en un momento propicio. En los meses recientes ha habido un aumento de actividad internacional sobre la cuestión del año 2000. Hace dos semanas, el Reino Unido organizó una reunión de expertos de los ministerios de Relaciones Exteriores de los países del G-8 para discutir la cuestión del año 2000 y otras transfronterizas. En esa reunión, cada país presentó un resumen de sus esfuerzos junto con un análisis del progreso en otros países. Otros foros internacionales, incluso el Banco Mundial, la OCDE y organizaciones regionales llevan también a cabo programas importantes para ayudar a coordinar actividades internacionales en este terreno.
Medidas de Supervisión en Estados Unidos
En Estados Unidos, los reguladores financieros han tomado medidas para alentar a las firmas a que aborden apropiadamente la cuestión del año 2000.
La Comisión de Valores y Cambio requiere ahora que las compañías públicas revelen los problemas del año 2000 en sus trámites corporativos, lo que puede ayudar a los inversionistas a evaluar el impacto del año 2000 en el valor de mercado de una firma. Entre otras cosas, la Comisión de Valores y Cambio requiere ahora que una compañía pública revele el hecho de que no ha realizado una evaluación de sus cuestiones relacionadas con el año 2000. Además, una compañía pública debe describir el material relacionado con las cuestiones del año 2000 y revelar la naturaleza del impacto potencial en la firma, incluso sus planes generales para abordar esas cuestiones. Esta revelación, que es potencialmente una estrategia muy poderosa basada en incentivos, está destinada a inducir presión del mercado sobre las compañías para que tomen medidas correctivas apropiadas.
De igual manera, los reguladores de la banca de Estados Unidos examinan ahora, como asunto de rutina, las cuestiones del año 2000 cuando efectúan exámenes de las instituciones bancarias bajo supervisión federal. Los exámenes se realizan para:
- Determinar si la organización tiene un plan efectivo para identificar, renovar, probar y llevar a la práctica una solución para el año 2000;
- Evaluar el efecto de los esfuerzos del año 2000 en los planes estratégicos y operativos del banco;
- Determinar si la organización ha coordinado eficazmente sus capacidades de procesamiento para el año 2000 con sus clientes, vendedores y socios de sus sistemas de pago;
- Evaluar la suficiencia de controles internos para el proceso del año 2000; e
- Identificar si son necesarias medidas correctivas adicionales.
Preocupaciones fuera de Estados Unidos
En Estados Unidos y en todas partes, la industria de servicios financieros parece que les lleva la delantera a otros sectores importantes de la industria en abordar el problema del año 2000. Las firmas financieras trabajan arduamente para renovar sistemas anticuados en grandes centros financieros de Estados Unidos como Nueva York y Chicago, así como en otras jurisdicciones importantes del mercado como Londres y Francfort. Las principales firmas financieras internacionales ya han iniciado ensayos internos, y ya se han programado para el año próximo actividades de ensayo en toda la industria.
No obstante, es muy difícil evaluar la eficacia de los programas de renovación que actualmente se realizan en cada país. Cada país encara dificultades distintas a medida que busca una solución efectiva del problema. En Europa, por ejemplo, muchos países de la Unión Europea deben lidiar con la conversión a la euromoneda simultáneamente con el problema del año 2000. Japón considera efectuar cambios importantes en su sistema financiero, lo que podría afectar también su esfuerzo de ajustarse al año 2000. Otros países asiáticos deben atender amenazas más inmediatas a sus economías.
Fuera de los centros financieros principales, los problemas que cause el año 2000 pueden ser importantes. En estos países, puede ser más difícil financiar el costo de contratar programadores para solucionar el problema, o aun identificar los sistemas que necesitan renovación, en primer lugar. Por otro lado, el hecho de que muchos países en desarrollo no se han automatizado en la misma medida que Estados Unidos significa que no hay tantos sistemas que puedan fallar. Más aun, lo sistemas que están en uso en esos países más pobres con frecuencia se han comprado más recientemente — y, por lo tanto, es más probable que llenen los requisitos para el año 2000 — que los sistemas de computadores instalados en muchas partes de las naciones industrializadas avanzadas.
Medidas que se Sugieren para Otros Países
Cada país tendrá que aplicar su propia solución del problema del año 2000, basada en las circunstancias, recursos y problemas particulares que sean pertinentes. Sin embargo, hay algunas premisas fundamentales que muchos expertos consideran que cada país debería tener presente cuando aplica un esfuerzo de cumplimiento relacionado con el año 2000. En particular, hay tres cuestiones fundamentales: inventario/evaluación, renovación y ensayo.
En primer lugar, las autoridades en materia de computación creen que es de ayuda que cada país evalúe su vulnerabilidad ante el problema del año 2000. Esto debería incluir un inventario de todas las aplicaciones que requieren modificación y una evaluación de qué medidas de innovación hay que aplicar. En Estados Unidos, la meta era asegurar que todo ese examen de inventario y evaluación quede completado para septiembre, y los reguladores vigilan a aquellas instituciones financieras que no alcanzan a cumplir con esta fecha límite.
Segundo, los expertos están de acuerdo con que cada país debe continuar la evaluación con una fase de renovación, en la cual los programas de computadora individuales se modifiquen para asegurar el cumplimiento relacionado con el año 2000. Es esencial que las firmas asignen prioridades a sus esfuerzos, de modo que las aplicaciones más esenciales reciban atención prioritaria, seguidas luego por los programas de computadora que tendrían un efecto más limitado en la firma en la eventualidad de una falla relacionada con el año 2000. La mayoría de las firmas de Estados Unidos emprenden al presente sus programas de renovación, los cuales deberían quedar completados en su mayor parte para diciembre de 1998.
Tercero, e igualmente importante en opinión de virtualmente todos los profesionales, figura la fase de ensayo, que los países, individualmente, deberían ordenar cumplir a las firmas en su jurisdicción. Es imposible exagerar la importancia de estos programas de ensayo, puesto que aun los programadores diestros pueden pasar por alto tareas esenciales. Los ensayos exteriores deberían incluir ensayos tanto con contrapartes simples como con contrapartes múltiples. En Estados Unidos se espera que tales ensayos comiencen no más tarde de diciembre de 1998, pero los ensayos exteriores requieren necesariamente la cooperación de gobiernos y firmas de otros países.
Trabajo en Otros Foros Internacionales
Debido a nuestra preocupación respecto del progreso que otras naciones logran en el área del año 2000, Hacienda emprendió un esfuerzo importante para elevar el perfil de la cuestión y actuar como un catalizador de la acción en muchos países. Hacienda sometió al G-7, en marzo de 1998, un estudio sobre el problema del año 2000 que les pedía a los países del G-7 aplicar en cada una de sus jurisdicciones programas abarcadores relacionados con el año 2000, y ayudar también a otros países. Desde entonces, hemos trabajado con otros países para asegurar que el problema del año 2000 se incluyera en el temario de la cumbre de Birmingham. Las conclusiones a que llegaron el 8 de mayo los ministros de Finanzas del G-7 pedían a los organismos reguladores internacionales (p. ej. el Comité de Basilea sobre Supervisión Bancaria, la Organización Internacional de Comisiones de Títulos de Capital, la Asociación Internacional de Supervisores de Seguros, y el Comité de Sistemas y Arreglos de Pagos) que "vigilen" los esfuerzos del sector privado y que "hagan todo lo que puedan para alentar el cumplimiento". Como se discute más abajo, estas entidades enfrentan el reto del año 2000 y evalúan y observan activamente los esfuerzos de cumplimiento relacionados con el año 2000 que realizan las firmas financieras en sus respectivas industrias, en lugar de simplemente "aumentar la percepción" del problema.
Subsecuentemente, el 17 de mayo, los Jefes de Estado y Gobierno del G-8 se reunieron y pidieron a los países que trabajaran en común para resolver el problema del año 2000, y pidieron expresamente a las organizaciones internacionales, inclusive el Banco Mundial y la Organización de Cooperación y Desarrollo Económicos (OCDE) que ayuden a resolver el problema.
Hacienda planteó también en otros foros interncionales el problema relacionado con el año 2000. A fines de mayo, los ministros de Finanzas del foro de Cooperación Económica de Asia y el Pacífico (CEAP) discutieron con representantes del sector privado la importancia de resolver, de una manera oportuna, los problemas de las economías de la CEAP relacionados con el año 2000. Urgieron también al Banco Mundial y al Banco Asiático de Desarrollo que ayuden a los países a ocuparse de este problema, y las autoridades nacionales supervisoras y reguladoras dentro de la región trabajan con los organismos reguladores internacionales para aplicar medidas con el fin de resolverlo. El problema relacionado con el año 2000 se incluyó también en la Declaración Ministerial Conjunta de la reunión de la Cumbre de los Ministros de Finanzas de las Américas de diciembre pasado en Chile, y Hacienda sigue estimulando a esta agrupación de ministros de Finanzas de América del Norte y del Sur a que trabaje con sus países miembros para aplicar soluciones efectivas al problema.
La Labor de los Organismos Reguladores Internacionales
Los organismos reguladores internacionales han establecido el Consejo Mundial del Año 2000, y emprenden acción para coordinar los aspectos financieros del problema relacionado con el año 2000. Los esfuerzos del Consejo del Año 2000 se iniciaron en abril, luego de una conferencia de líderes mundiales sobre el problema relacionado con el año 2000 celebrada en Basilea, Suiza. Esa conferencia fue de ayuda para aumentar todavía más la percepción del problema relacionado con el año 2000. Nos encontramos en trámites de designar un enlace de Hacienda con el Consejo del Año 2000 para mantenerlo informado de sus esfuerzos y promover los mismos con el fin de emprender un programa activo de observación y evaluación de la situación, y desarrollar medidas de reparación apropiadas donde sea evidente que un país o grupo de países en particular ha quedado a la zaga en su programa relacionado con el año 2000.
Otras organizaciones, en particular la OCDE, toman parte en la tarea de coordinar algunos de los aspectos no financieros más significativos del problema relacionado con el año 2000, tales como los de telecomunicaciones y redes del tendido eléctrico, donde una dislocación de las comunicaciones o las redes del tendido eléctrico podría causar perjuicio económico general.
Función de las Instituciones Financieras Internacionales (IFI) y los Bancos de Desarrollo Multilaterales (BDM)
Hacienda presta creciente atención a la función que el Banco Mundial y el Fondo Monetario Internacional, al igual que los bancos de desarrollo regionales multilaterales, tales como el Banco Asiático de Desarrollo, el Banco Interamericano de Desarrollo, y el Banco Europeo de Reconstrucción y Fomento, podrían desempeñar con respecto al problema relacionado con el año 2000. En nuestras discusiones con estas entidades, nos sentimos en general satisfechos con que tomen medidas razonables para evaluar y renovar sus propios sistemas internos y aplaudimos su previsión en este sentido. Entre otras cosas, parece que todas estas instituciones han tomado medidas para evaluar sus sistemas de misión esenciales, y están bien avanzados con respecto a la renovación o reemplazo de sistemas obsoletos que no podrán dar cumplimiento.
Alentamos también activamente a las instituciones financieras internacionales (IFI) a que consideren una gama completa de políticas que podrían emprender en conjunción con sus países clientes. Esperamos asegurar que todos los proyectos y programas que financian estas organizaciones cumplan con las exigencias del año 2000. El 15 de junio los ejecutivos de información de todas las IFI se reunieron para intercambiar opiniones y experiencias sobre problemas potenciales de computadoras relacionados con el año 2000 y explorar maneras de ofrecer ayuda técnica a sus países miembros.
Conclusión
No hay una cura fácil para el problema del año 2000. Como muchas otras cuestiones, la del año 2000 requerirá una gran cantidad de diligencia, planificación y trabajo arduo para que los países impidan que los sistemas esenciales fallen. Hacienda trabaja en una gama de foros internacionales para ayudar a promover soluciones apropiadas.
Pero, si bien las instituciones internacionales y Hacienda pueden ayudar a los esfuerzos relacionados con el año 2000 emprendidos en varios países, a fin de cuentas cada país tendrá que aplicar su propia solución al problema y asumir la responsabilidad de cualquier falla. Debemos ser realistas en cuanto al hecho de que el problema del año 2000 es un acontecimiento nuevo, y no podemos prever todas las complicaciones que podrían surgir. Por lo tanto, no podemos descartar por entero la posibilidad de dislocaciones del sistema financiero y otros sectores de la economía, tanto en Estados Unidos como en otras partes. La clave consiste en administrar los riesgos mediante la asignación de prioridades a aquellos sistemas que deben estar absolutamente en condiciones operativas, en tanto que se dedican menores recursos a otras áreas, y se establecen arreglos de contingencia apropiados para reducir el perjuicio causado por cualquier falla que ocurra.
En Estados Unidos nos encontramos bien avanzados en este proceso, y confiamos en que otros países logren progresos similares con respecto a la renovación y ensayo de sus sistemas de computadoras para tener en cuenta el problema del año 2000. Esta audiencia es muy útil en relación con ese proceso, en la medida en que puede ayudar a aumentar la percepción y asegurar que todas las entidades pertinentes apliquen sus mejores esfuerzos a resolver el problema.
Uno de los problemas relacionados con el año 2000, en particular para México, es la dependencia tecnológica que tenemos en relación a otros países donde se diseña, construye y produce la tecnología, y que resulta una enorme desventaja.
Debido a que la tecnología se diseña en otros países, por ejemplo en los Estados Unidos de Norteamérica, los sistemas operativos, documentación de los equipos, mapas electrónicos, etc., se encuentran en inglés. Adicionalmente, en materia de sistemas de software desarrollados por terceros, y que son conocidos como paquetes, también se encuentran en inglés, y por ejemplo en el caso del desarrollo de paquetes de contabilidad, éstos por lo general obedecen a las normas y leyes del país donde fueron desarrollados.
Esto hace que cuando se integra la tecnología al mercado mexicano, sea necesario regionalizar su uso, entre otras acciones, a través de la traducción de los comandos al español y la adecuación de los paquetes de software a las normas y leyes que en la materia apliquen en México. Esta regionalización normalmente se realiza cuando el equipo o el software de referencia se instalan y se ponen a punto para iniciar su funcionamiento.
Sin embargo, cuando el fabricante del producto, equipo o software, pone en el mercado una nueva versión, en donde se incluyen mejoras o se corrigen errores, normalmente se tiene que evaluar el impacto para aplicar la nueva versión. Si ésta no representa una mejora sustancial en el rendimiento del equipo; en el funcionamiento del software, o no se han presentado los problemas que se corrigen, esta nueva versión no se instala, ya que hacerlo representaría verificar que la regionalización y adecuación del equipo o software no se pierdan. Con ello la funcionalidad esperada se puede ver afectada, amén de que puede significar un costo adicional, ya que es posible que para que la nueva versión funcione correctamente, se requieran más recursos como disco duro, memoria, o un nuevo módulo en el equipo, lo que significaría una inversión adicional, generalmente no programada.
Dicho fenómeno produce que en la gran mayoría de los casos, las versiones instaladas de sistemas operativos, utilerías del sistema, bases de datos, lenguajes de programación, equipos, y paquetes de software, no correspondan a la última versión que el fabricante liberó.
Esta reflexión obedece a que en la actualidad las empresas de cómputo como IBM, han señalado que la solución del problema del año 2000 que sus sistemas operativos, utilerías del sistema, compiladores, lenguajes de programación y paquetes, pudieran tener, se encuentran resueltos en sus últimas versiones.
Esta actualización tecnológica necesariamente tendrá un costo tanto económico, como en tiempo, y significará uno de los puntos de evaluación y análisis más importantes en la solución.
Por otro lado, y derivado del costo de la tecnología, ésta tiende a permanecer por grandes periodos en la vida productiva de México. Recuerdo que cuando desarrollaba funciones de soporte técnico en una institución de gobierno, fue adquirida una computadora de gran escala, y como responsables de su uso y permanencia en dicha institución, solicitamos al fabricante que en el contrato a celebrar, se incluyera una cláusula en donde se especificara que el equipo objeto de la compra-venta tuviera una garantía de partes y refacciones por diez años, cuando en otros países esta garantía la otorga el fabricante solamente por cinco años.
Este fenómeno tendrá graves repercusiones cuando se detecte en el proceso de un proyecto del año 2000, ya que puede ser que las garantías ofrecidas por el fabricante ya hayan vencido, y posiblemente desde hace algunos años, y por otro lado, que las posibilidades de corrección por parte del fabricante ya no existan, dado que los recursos para ello están en desuso desde tiempo atrás.
Lo anterior, posiblemente obligue a la empresa o negocio a sustituír equipos o software, sobre todo cuando éstos realicen funciones críticas para el negocio, significando de igual manera una inversión de alto costo no prevista.
Cuando se inició el uso de computadoras para soportar la operación de las empresas, la oferta y variedad de paquetes de software que cubrieran las necesidades y la funcionalidad de las empresas en México era muy poca y no ofrecía las soluciones adecuadas, por lo que normalmente se optó por hacer los desarrollos de software en casa. Esto no representa en realidad un problema ya que la gran mayoría de las empresas en México tienen departamentos de informática. Un ejemplo de esto es que el año pasado una Compañía de Seguros analizó la posibilidad de adquirir un paquete de seguros, desarrollado en los Estados Unidos de Norteamérica, actualmente todos sus paquetes son desarrollados en casa. Asimismo los tres bancos más grandes del país tienen software desarrollado en casa y en casi todo el sector público los sistemas son desarrollados a la medida, etc.
Así como los equipos de cómputo o maquinaria en general tienden a permanecer por un largo período en las empresas, de igual manera el desarrollo de los sistemas computarizados tienen varios años de antigüedad. Esto hace que en un proyecto del año 2000 sea necesaria la revisión de sistemas computarizados que están funcionando desde hace muchos años, de los que probablemente no exista la documentación adecuada, o no exista el programa fuente.
La gran mayoría de la tecnología de computadoras ha sido mejorada a través de los años, mediante la adquisición de nuevos modelos de computadoras que normalmente son del mismo proveedor, con objeto de utilizar el mismo software por muchos años, sin la necesidad de reprogramar los sistemas, simplemente transfiriendo a la nueva tecnología los códigos objeto de los sistemas en producción. Esto se hace aún cuando en el mercado existan mejores alternativas tecnológicas, con otros proveedores. En la institución de gobierno en donde trabajé, se utilizó por casi 20 años la tecnología de UNISYS antes Burroughs, en razón a que los sistemas computarizados de la institución estaban desarrollados en el lenguaje de programación ALGOL. El esfuerzo por reemplazarlo después de tres años de cambio de plataforma de equipos, no ha sido concluido.
Además, el personal del área de desarrollo de sistemas que estuvo involucrada en el análisis, diseño y desarrollo de los programas en cuestión, posiblemente se haya separado de la empresa desde hace tiempo, por lo que el conocimiento a profundidad del o los sistemas computarizados, que el personal de informática que trabaja en la empresa tiene de ellos, sea poco o ninguno.
Muchas veces el criterio a seguir con estos sistemas computarizados es: si funcionan, no efectuar modificaciones que signifiquen alguna funcionalidad adicional. En lugar de ello, se agregan otros sistemas computarizados, satélites del central que complementen dicha funcionalidad. Si un sistema computarizado, que se considera crítico, funciona adecuada y regularmente, no se toca, con objeto de no afectar su operación.
Los sistemas computarizados satélites, con el tiempo, hacen más compleja la operación, y significan enlaces de información a analizar en un proyecto del año 2000.
Dada la magnitud del problema del año 2000 a nivel mundial, la oferta de trabajo para los desarrolladores de sistemas computarizados, como los especialistas en el lenguaje de programación COBOL, se ha incrementado y en la actualidad representa una mejora económica para éstos de importantes magnitudes.
Países como India y México, que cuentan con una buena fuente de recursos humanos en materia de desarrollo de sistemas computarizados, actualmente están viendo surgir un fenómeno de fuga de especialistas en el ramo. En lo personal he sabido de varios casos de programadores de sistemas computarizados que han sido contratados por compañías consultoras, o de desarrollo de sistemas computarizados de los Estados Unidos de Norteamérica, por un período de tres a cuatro años, en donde les facilitan el hospedaje, transportación, etc. y sobre todo les pagan en dólares. El único requisito es que deben residir en los Estados Unidos de Norteamérica durante ese tiempo.
Estas compañías posteriormente ofrecen sus servicios a las empresas mexicanas y por supuesto el cobro de sus servicios es en dólares, con lo que se afecta a la economía de las empresas, además de que la experiencia en proyectos de este tipo no se convierte en un activo de la empresa mexicana.
Debido a la situación económica por la que atraviesa México, la gran mayoría de las empresas medianas o pequeñas no están conscientes del problema del año 2000. Están más preocupadas porque el negocio sobreviva. Algunas tienen compromisos económicos que agravan su situación económica. La inversión que requiere un proyecto del año 2000, no ha sido considerada, de tal manera que no podemos estimar con certeza cuál será el monto de inversión en este rubro.
Aunado a esta situación está la falta de información en los medios de comunicación, gobierno, sector financiero y sector privado acerca del problema del año 2000.
Por ejemplo, no existe una página en Internet acerca del problema del año 2000 en México. Muy pocos documentos del tema están en español. Como resultado de esto, el público en general no tiene ninguna información acerca de que es lo que va a suceder con relación a los servicios que proporciona el sector público, como el abasto de energía eléctrica, de agua, de servicios privados de telefonía, durante la transición hacia el año 2000. Los pocos artículos periodísticos acerca del año 2000 que aparecen en la prensa, se refieren al problema del año 2000 como algo que está ocurriendo en otros países, pero no en México. Esto hace suponer que el problema de la tecnología a final de siglo no va a suceder en México, que el problema va a ocurrir en otros lugares, en otras latitudes, pero no aquí.
La instancia de gobierno que tiene bajo su cargo el control de los proyectos del año 2000 en el gobierno federal, realizó una reunión con los encargados de informática y los Contralores Internos, después de un año de haber efectuado la primera reunión para evaluar los avances de los proyectos del año 2000. Como resultado de esta reunión se publicó un artículo en el periódico que señalaba que los "avances son importantes", pero no publicaron cifras o estadísticas de los resultados ni del avance. Dada la naturaleza de las funciones de los asistentes a dicha reunión, me parece que en el gobierno federal no ha sido considerado en la exacta dimensión el problema del año 2000 en los sistemas anidados, que incluye a los servicios de energía eléctrica, a través de la Comisión Federal de Electricidad (CFE) y los de abasto de agua, por medio de la Comisión Nacional del Agua (CNA), ambos servicios a nivel nacional. Otro tipo de funcionarios como los operativos, deberían ser incluídos en estas reuniones.
En un periódico recientemente se publicó una noticia que menciona "con respecto al problema del año 2000, la información ha sido incorrecta, debido a ello los proveedores y consultores, han decidido no hablar más del asunto y en lugar de ello, dedicar sus esfuerzos en resolver el problema." Esta afirmación me resulta sorprendente, tenemos todo el derecho a saber del problema y cuál es el avance en su solución, en las dependencias de gobierno y en el sector privado. Debemos saber cuáles son los riesgos, cuándo serán una realidad, qué podemos hacer al respecto, etc.
El funcionamiento eficaz de los gobiernos, las empresas y otras organizaciones del mundo entero se verá amenazado a medida que nos acerquemos al final del siglo. La amenaza proviene del problema de cambio de fecha del siglo (denominado asimismo "Millennium Bug" o "Y2K"). Los sistemas informatizados importantes para el funcionamiento correcto de las infraestructuras nacionales corren peligro, tales como redes nacionales de suministro de electricidad, sistemas de control del tráfico aéreo y terrestre, comunicaciones terrestres y por satélite, hospitales, bancos locales e internacionales y servicios financieros. Tampoco puede hacerse caso omiso de las repercusiones que tendrían para la seguridad los fallos en los sistemas relacionados con la defensa.
1.El efecto 2000 se compone en realidad de dos problemas relacionados.
2.El primero es que el software que procesa las fechas generalmente hace caso omiso del siglo, por ejemplo, el 6 de abril de 1998 pasa a ser 980406. Esto hace que las comparaciones entre fechas de siglos diferentes se efectúen mal; en particular, 2000, registrado como "00", viene antes de 1999, que se registra como "99" y no después. También puede ocurrir que el software que convierte el formato informático (binario) en una fecha que puede leer el ser humano no funcione bien. Por ejemplo, el año que sigue a 99 podría aparecer como 100, provocando el desbordamiento del campo disponible de dos dígitos y posiblemente sobreescribiendo otros datos y provocando otros fallos de software imprevisibles.
3.El segundo problema es que una gran parte de los equipos electrónicos contienen un reloj incorporado. Con frecuencia, se trata de un reloj de PC estándar porque el hardware utiliza componente estándares producidos en grandes cantidades para disminuir el costo. Estos relojes suelen tener la misma dificultad con las fechas del próximo siglo, salvo que parece ser más bien un problema de hardware que de software. Por eso, los sistemas, incluidos los sistemas informatizados en los que se encuentra la mayor parte de los chips, pueden fallar aunque no usen ninguna función relacionada directamente con el tiempo, simplemente porque el hardware detecta un fallo y se detiene. Esto ocurrirá frecuentemente, ya sea en el primer segundo del nuevo milenio o bien en la primera ocasión en que el equipo se apague y se encienda otra vez posteriormente si tiene un mecanismo de autoverificación de "encendido". Dado que los fabricantes cambian de proveedores de componentes o cambian otros detalles de las especificaciones de vez en cuando, para estar absolutamente seguro del cumplimiento con el milenio, tal vez sea necesario someter a prueba cada unidad individual de un modelo específico.
4.A continuación se presentan algunos ejemplos de los tipos de tecnología que los expertos ya han identificado como vulnerables al Efecto 2000 junto con algunas ilustraciones del impacto. Esta lista dista de ser exhaustiva (por ejemplo, se omiten elementos como jubilaciones, seguridad social, seguros, impuestos, etc., a pesar de ser potencialmente graves).
La mayoría de las centrales eléctricas, cualquiera que sea los combustibles que utilicen e incluidas las hidroeléctricas, tendrán más de una unidad vulnerable al milenio. Por ejemplo, una reciente prueba "post-2000" en una central eléctrica del Reino Unido hizo que la central entrase en estado de "protección automática" cuando el sensor de los gases de la combustión no pudo calcular la temperatura media de los gases en el lapso de 30 segundos porque no reconoció la fecha/hora posterior al 31-12-1999. Hay muchas otras aplicaciones que utilizan este tipo de variables promedio como verificación de seguridad, por ejemplo, mandos de motores, mandos de vuelo, equipo de mantenimiento de las funciones vitales.
No se sabe a ciencia cierta si todas las centrales nucleares entrarían en estado de protección automática. Es probable que los sistemas automáticos sean vulnerables al Efecto 2000 pero no es seguro que entren en estado de protección automática. Las pruebas relativas al milenio son cruciales.
Las redes de electricidad son incluso más vulnerables debido a un fenómeno conocido como "Colapso progresivo", en virtud del cual un fallo en una parte del sistema aumenta la carga en el resto, desencadenando fallos adicionales hasta llegar al punto de cierre. Se cree que el apagón ocurrido recientemente en el centro de Auckland ocurrió de este modo (si bien el fallo inicial tuvo que ver con las condiciones meteorológicas). El fallo de la red afectaría a todos los equipos dependientes de electricidad en otros puntos de la cadena, salvo donde hubiera energía eléctrica local de reserva.
Los oleoductos y gasoductos dependen de válvulas automáticas, muchas de las cuales tienen componentes vulnerables al milenio (especialmente, pero no exclusivamente, si hay una autoverificación de mantenimiento relacionada con el tiempo). Se sabe que algunos tipos de válvulas entran en estado de cierre automático, y otras en estado de apertura automática. Esta tecnología también se halla ampliamente difundida en los conductos de las instalaciones petroquímicas (si bien algunos expertos consideran que primero habrá fallos en el centro de tales instalaciones), en las instalaciones de terminales petroleros y en buques cisterna. No se puede descartar la contaminación accidental por petróleo.
Las redes telefónicas nacionales dependen en gran medida de microchips y son tan vulnerables al colapso progresivo como las redes de electricidad. BT ha invertido 500 millones de libras en los 5 últimos años en el cumplimiento con el efecto 2000. Pero muchos de los organismos homólogos extranjeros, incluidas empresas de Oriente Medio y Lejano, no han iniciado aún programas; tal vez ya sea demasiado tarde para que esas empresas eviten interrupciones graves de las comunicaciones telefónicas, de fax y de datos.
También los teléfonos celulares tienen generalmente microchips que, en los sistemas más antiguos en particular, podrían ser vulnerables al cambio de milenio, junto con las centrales telefónicas.
Se considera que algunos cables submarinos son vulnerables al milenio. Cualquier problema surgirá principalmente en los componentes en tierra pero no se descarta el reemplazo o la reprogramación de repetidores en el fondo marino.
La situación relativa a los satélites de telecomunicaciones es menos clara (si bien las estaciones terrestres son ciertamente vulnerables).
También Internet plantea un interrogante. Se anticipan problemas en la forma en que los datos de encaminamiento son generados y nombrados; es probable que hay fallos de nodos y algunos expertos no descartan la posibilidad de colapso progresivo.
Control de tráfico aéreo: alrededor de 40 centros de Estados Unidos son vulnerables, al igual que muchos de Europa, junto con otros sistemas electrónicos de tierra de los cuales depende el tráfico aéreo (hasta 200 en la UE). Los fallos en una zona repercutirán sobre otras zonas.
Si bien no se trata de un problema del milenio en sí, el fallo por sobrecarga de fecha del Sistema Global de Posicionamiento (GPS) satelital que ocurrirá en agosto de 1999 tendrá un efecto profundo sobre la navegación mundial, que se verá agravado, por ejemplo, por fallos de los sistemas de navegación embarcados.
También podrían verse afectados los sistemas de control informatizados en aviones y buques. Muchos motores modernos utilizados en automóviles familiares así como en medios de transporte comerciales tienen sistemas de mantenimiento y control de motor sensibles a las fechas; no se sabe si éstos fallarán. Los camiones y autobuses diesel (así como los trenes, posiblemente) podrían ser vulnerables ya que, en general, los motores diesel grandes se utilizan comúnmente para diversas funciones, por ejemplo, motores de camiones y generadores de emergencia, y luego son programados para una tarea específica por controladores electrónicos de Acaja negra@. En general, éstos pueden ser reemplazados o reprogramados sólo por el fabricante.
Muchas señales automáticas de tráfico son vulnerables en las carreteras y en los ferrocarriles (cuyos sistemas informatizados de agujas también podrían ser vulnerables). Las redes ferroviarias electrificadas, incluidos los ferrocarriles metropolitanos, podrían estas sujetas al colapso progresivo.
Abastecimiento y saneamiento de aguas
Las cañerías principales de agua y los embalses se ven afectados por los mismos problemas potenciales con las válvulas y bombas que los oleoductos y gasoductos. En el Reino Unido, las compañías de abastecimiento de agua no se ponen de acuerdo con respecto a la escala del problema pero ninguno niega su existencia.
De modo similar, las cañerías de aguas negras: una compuerta de descarga en Cornwall que fue sometida prueba creyó que la fecha era 1900 y calculó mal las mareas. Si esto ocurriera fuera de las condiciones de prueba, podría ocasionar daños a los sistemas y un peligro potencial para la salud.
En los Países Bajos, se descubrió que un hospital tenía más de 9000 unidades vulnerables al milenio, las cuales abarcaban una gran variedad de funciones. Se considera, por ejemplo, que los equipos de transfusión modernos (que tienen un programa de autoverificación semestral estándar) son vulnerables.
Un estudio realizado en un hospital del Reino Unido estimó que entre 600 y 1.500 pacientes de hospital del Servicio Nacional de la Salud (NHS) podrían morir como resultado de fallos de equipos relacionados con el Efecto 2000, incluso si se hicieran los mayores esfuerzos desde ahora y hasta el año 2000. Los cálculos de BMA sugieren otras 1.800 muertes entre pacientes externos (por ejemplo, en aparatos de diálisis). Los fallos de sistemas funcionamiento continuo podrían ocasionar más muertes posteriormente (por ejemplo, diabéticos si las unidades de refrigeración necesarias para almacenar insulina permanecieses fuera de línea).
Los aparatos de radioterapia son por lo general vulnerables y ya hay casos en los que los ordenadores recomiendan la descarga temprana, y peligrosa, de isótopos radiactivos tras un cálculo erróneo -relacionado con el milenio- de la duración de la vida media.
Es posible que los generadores de emergencia de hospitales fallen por la misma razón que los camiones diesel (véase más arriba) o, de modo más prosaico, por fallos mecánicos si están sometidos a un uso prolongado.
Sistemas de edificios y fábricas
Los fallos potenciales en los sistemas de control de edificios comprenden ascensores, calefacción, iluminación, aire acondicionado, puertas de seguridad de control electrónico, sistemas antincendio y alarmas contra intrusos. Las pruebas de cerraduras temporizadas en los recintos de seguridad de bancos hicieron que las cámaras acorazadas estuvieran cerradas herméticamente durante un período de hasta 80 años.
Las cadenas de producción automáticas también podrían estar sujetas a fallos, uno de los cuales podría hacer que se interrumpiera toda la producción.
En los supermercados modernos, el control de existencias es casi invariablemente automático. Los sistemas electrónicos de pago (y los cajeros automáticos) también son vulnerables y se corre el riesgo de que los consumidores no puedan pagar aún en el caso de que haya existencias para comprar.
Los productos manufacturados (fármacos al igual que alimentos) con fecha de vencimiento posmilenio ya han sido distribuidos desde centros informatizados de gestión de existencias antes que artículos con una fecha de vencimiento de 1999; se ha ordenado que otras existencias de fecha similar sean desechadas, encargándose automáticamente existencias de reposición.
ÁREAS DE PRIORIDAD PARA LA ACCIÓN
En las economías de mercado, una gran parte de las medidas correctivas incumbirán al sector privado, pero los gobiernos nacionales tienen la responsabilidad clave de asegurarse de que el sector privado se dedique plenamente a ello y de encargarse de los sistemas bajo su propio control. Esto último es especialmente importante en aquellos casos en que la generación de energía, el transporte y las comunicaciones continúen estando en manos del Estado. La planificación de medidas correctivas internacionales es crucial. Consideramos que hay cinco áreas de prioridad en las que existe la necesidad clara de que los gobiernos actúen en el ámbito internacional para asegurarse de que todo esté pronto. Estas áreas son: generación de energía, transporte, telecomunicaciones, finanzas y defensa.
Las soluciones apropiadas a nivel nacional variarán en cierta medida de un Estado a otro según las estructuras gubernamentales y económicas involucradas. Pero algunos elementos serán necesarios casi con seguridad:
- campañas de concienciación para instar a las empresas/organizaciones a resolver el problema
- insistencia en que el sector estatal asegure el cumplimiento con el milenio de sistemas críticos
- asegurarse de que haya directrices específicas y concretas sobre los que es necesario hacer
- resolver el problema creciente de la falta de personal capacitado; adiestramiento
- planificación para situaciones imprevistas de posibles fallos
- suministro de información a consumidores y al público en general.
LA EXPERIENCIA DEL REINO UNIDO
El Reino Unido ha creado un entidad,"Action 2000", para difundir el mensaje entre las compañías y empresas del país. Sin embargo, Action 2000 y el Gobierno británico están descubriendo que, cuanto más se enfoquen los problemas en detalle, más complejas y caras son las repercusiones que se descubren. En general hemos descubierto que, si bien el nivel de concienciación es ahora alto y la planificación de las grandes empresas/organizaciones se halla bien avanzada, muchas firmas más pequeñas han hecho poco o nada por evaluar y corregir sus propios sistemas. Tendremos sumo gusto en compartir con otros nuestra experiencia con el programa Action 2000.
Consecuencias del problema del milenio
El tema del año 2000 no solo afecta a los sistemas informáticos, software, mainframes y computadoras personales sino a todo dispositivo electrónico que tenga lógica sensible a fechas.
La variedad de estos dispositivos que pueden verse afectados es realmente extensa. Por lo tanto, los líderes y responsables de los Proyectos año 2000 deberán en cada caso analizar cuidadosamente los posibles puntos de fallas, y gestionar el proceso de certificación e implementación de las actualizaciones con los proveedores correspondientes.
Lamentablemente son muchos los sistemas con este inconveniente. Muchos son sistemas desarrollados hace tiempo con aquel criterio de ahorrar costos de almacenamiento y otros, aun desarrollados recientemente, lo tienen como fruto de la imprevisión.
Las APLICACIONES, el HARDWARE y los SISTEMAS OPERATIVOS deben considerar al año con los 4 dígitos. Existe también la posibilidad de que si bien un Sistema no tenga, en si, problemas, los datos provenientes de otras aplicaciones no compatibles año 2000 le ocasionen serios inconvenientes.
Asimismo, pueden verse afectados otros sistemas periféricos que operan con fechas, tales como: aire acondicionado, central telefónica, seguridad de accesos, centrales eléctricas, equipos médicos, aviones, ascensores, cajas de seguridad, etc.
Estamos frente a una nueva característica de los negocios en la que muchos bancos se lanzarán a una campaña promocionando la efectividad de sus sistemas de computación. Sin duda, mucha gente retirará sus depósitos de aquellos bancos que no le hayan transmitido una fuerte confianza en su sistema de informática. Y, según los pronósticos, la mayoría de las empresas que cerrarán como consecuencia del efecto 2000 serán empresas de servicios, bancos y entidades financieras.
Si bien la mayor magnitud del problema es a nivel del soft, o sea de programas, las máquinas intrínsecamente también pueden estar impedidas de transitar en forma correcta el paso del 1999 al 2000.
Para comprender mejor el problema es necesario entender básicamente como se maneja la fecha y hora en las computadoras personales. En general una computadora personal (PC) tiene dos relojes, uno interno, que llamaremos RTC (real-time clock) que está en el hardware, y uno externo, reloj del sistema (RSO), que es mantenido por el sistema operativo (SO). El RTC funciona aún cuando la PC esté apagada, mediante una batería interna. Cuando la PC se enciende, el RSO, se inicializa con el valor del RTC, a través de funciones del BIOS (Basic Input Output System). El BIOS, además de permitir el arranque de la PC, provee interfaces para la comunicación entre el sistema operativo y el hardware en forma de varios servicios (ej. obtener fecha/hora, inicializar fecha/ hora, etc.).
Los dos relojes funcionan en forma independiente. El RSO es un contador que se incrementa una cierta cantidad de veces por segundo. Con la fecha que obtuvo en la inicialización va calculando la fecha y hora. El RTC mantiene, en forma permanente, la información de la fecha (dd-mm-aa), en una memoria interna (CMOS RAM). El problema es que el siglo, que se almacena en otro lugar, no es incrementado automáticamente por el RTC cuando el valor del año pasa de 99 a 00. Por tanto el resultado es que 1/1/2000 parecerá ser 1/1/1900. El BIOS es el que debe actualizar el siglo, sin embargo en las versiones que no son compatibles con el año 2000 esto no sucede.
Además hay que tener en cuenta que el sistema operativo (DOS/Windows), incrementará correctamente la fecha que mantiene (RSO) si esta funcionando durante la transición de milenio, pero no necesariamente actualizará el siglo en el RTC. Mientras la máquina siga funcionando, la fecha del sistema operativo será correcta, pero si la computadora es reiniciada o encendida después del 1/1/2000, el RTC devolverá como fecha 1/1/00 al DOS. Este es un valor inválido, ya que DOS representa fechas posteriores al 1/1/80, y devolverá la fecha 4/1/80, que es un código de error. El software que se utiliza en las PC lee la fecha de la computadora, de forma tal que, si esa fecha es incorrecta este error se extiende al mismo. Por tanto, es necesario verificar si su PC tiene una versión de BIOS que actualice automáticamente el siglo, de forma tal que cuando el RTC le devuelva como fecha 1/1/00 reconozca el cambio de siglo y el BIOS devuelva al SO la fecha 1/1/2000.
Hay varias aplicaciones que le permitirán saber si su PC es compatible con el año 2000. NSTL empezó a trabajar desde 1983 como una organización independiente dedicada exclusivamente a hacer pruebas de funcionamiento y rendimientos de hardware y software a nivel mundial. Para verificar la compatibilidad con el año 2000, NSTL desarrolló un programa, que está disponible gratuitamente en la Web site de NSTL , llamado YMARK2000. Este programa, realiza las siguientes comprobaciones:
Verifica la compatibilidad del RTC (Reloj de Tiempo Real)con el chip de Motorola MC146818. Este test asegura que la fecha y hora indicadas sean compatibles con el MC146818 y que los datos estén en formato empaquetado BCD. Verifica la progresión, en tiempo real, desde el 31 de Diciembre de 1999 al 1° de Enero de 2000. Si el soporte en tiempo real falla, se chequea la posibilidad de inicializar la fecha en forma manual. Verifica que se reconozca y soporte el año 2000 como año bisiesto. Este test asegura que la PC soporta el cambio de milenio sin necesidad de intervención del usuario. En algunos casos tendrá que escribir la fecha en forma manual el 1/1/2000 a través de DOS o Windows.
Algunos BIOS pueden ser actualizados, para lo cual es necesario consultar con su proveedor de PC, o buscar en la WEB.
Instrucciones para el Test:
1.Reinicie la PC en modo DOS (no es ni para Windows ni para OS/2)
2.Ejecute el programa 2000.EXE y cuando pregunte: "Do you accept…." escriba "Y" (sin comillas) y comenzará el test.
3.Lea los resultados en su pantalla.
4.Si desea obtener el resultado impreso escriba: 2000 >PRN
NSTL no garantiza la exactitud, suficiencia o integridad de los servicios provistos en relación con este programa. Nstl no da ninguna garantía, expresa, o implícita, acerca de los resultados a ser obtenidos por cualquier persona o entidad por el uso de los contenidos de este programa. Nstl no da ninguna garantía expresa o implícita de calidad del producto para ser comercializado o de la aptitud para un propósito particular de cualquier producto mencionado en este programa.
Sistemas "a medida"
Dentro de la empresa Por un lado, esta categoría de soft representa la posibilidad de la revisión en forma totalmente independiente para la empresa, pero, a su ve, implica el gran esfuerzo interno y ocupación de mano de obra propia, a; veces en detrimento de sistemas nuevos que se están desarrollando. En buena medida, el tiempo insumido en esta tarea dependerá de la calidad dela documentación que la misma empresa ha desarrollado y de la antigüedad de los programas, sin descartar la disponibilidad de los programadores originales. Para encarar el tema, deberá evaluarse qué cantidad de código tiene documentación actualizada y cuánto no. En función de esto se podrá reforzar la búsqueda con paquetes de localización de código determinante. De una u otra manera, igualmente es necesario cierto grado de revisión manual.
Realizados en forma externa En este caso, la relación actual con el proveedor jugará un papel relevante, es decir, si éste efectúa el mantenimiento del sistema o si es la misma empresa la que debe realizarlo. En el primer caso, el enfoque es idéntico al sistema a medida desarrollado dentro de la empresa; en caso contrario, deberá negociarse con el proveedor el tiempo y forma en que se realizará el trabajo de detección correspondiente. Cualquiera fuera el contenido del acuerdo, la empresa deberá guardar para sí un buen grado de control del avance del proyecto, cuestión de no tener sorpresas desagradables con poco tiempo de maniobra.
Importar y exportar datos Otro tema de suma importancia es la interconexión de sistemas que existen en la actualidad, con la consiguiente proliferación de intercambio de información entre distintas empresas e instituciones. No bastará que una empresa corrija sus aplicaciones sino que también deberá corregir parte de la información que le llega desde afuera en formato incompleto.
Para los europeos, se agrega otro factor de complicación, ya que se están modificando los sistemas para la unificación monetaria del Mercado Común. Para 1999, se incorporará el Euro como valor de intercambio para las transacciones intermercado y, para el 2002, éste reemplazaría a las monedas locales en todo tipo de transacción.
Además de registrar el estado actual de la información que proviene de fuentes externas a la empresa, será necesario agregar las nuevas circunstancias que se van produciendo de acuerdo con las negociaciones entre ambas partes, así como también tener en cuenta la eventual presencia de módulos de conversión.
Deberán registrarse y mantenerse los archivos interfaces que salen hacia otras empresas, acordando con éstas el formato que tendrán a partir de la implementación y actualizando posibles cambios.
Los formularios que intervienen Si bien no es una tarea que requiera personal de alta especialización en sistemas ni un soft espectacular, es un eslabón de la cadena que no se debe descuidar.
Se trata de los formularios preimpresos que usa la empresa: órdenes de compra, recibos, facturas, cheques, etc., que suelen tener preimpreso el "19" o tener lugar para sólo dos dígitos. Todo esto debe preverse y será necesario encargar formularios nuevos que, o bien tendrán el "20" o no tendrán nada en caso de que el programa imprima todo el campo completo del año. Haciendo un poco de futurología, seguro que habrá más de un programador que el 31 de diciembre de 1999 tendrá que modificar un programa para que tache el 19 preimpreso con una serie de "X" o asteriscos.
De tal manera, los eventuales cambios en los diseños de los formularios deberán entrar en la planificación general de la implementación de los sistemas corregidos.
Parece que el año 2000 para algunos va a ser un problema y para otros una solución a sus economías, por lo menos para un solo segmento de la sociedad: los abogados.
Una presentación realizada en una reciente conferencia de suscriptores patrocinada por el Lloyd de Londres, se estimó que U$S 1 billón o más, estará en juego en los litigios que se producirán derivados del problema del año 2000. "Casi todas las grandes empresas ya han establecido alguna práctica legal con vistas a prevenirse del problema del año 2000", dijo uno de los abogados expositores. "Las compañías de computación que le venden grandes sistemas a los gobiernos locales son los blancos más vulnerables", añadió el letrado.
Mientras los abogados del Viejo Mundo y los Estados Unidos comienzan a trazar su estrategia para el año 2000, en la argentina aún no existe la suficiente "conciencia legal" sobre las consecuencias económicas que provocará el Y2K.
El experto en derecho en tecnologías de la información, Dr. Antonio Millé, expuso el problema desde su área en "¿Cuáles serán las responsabilidades legales de su empresa o de sus socios comerciales afectados por el problema del año 2000"?. Sus recomendaciones se basaron en que la tecnología no es un área litigiosa y que, en nuestro país, a diferencia de los EE.UU., no existe una cultura litigante.
Debido a esto, el objetivo en la parte legal debe ser buscar soluciones entre las partes intervinientes, "hay que evaluar con prudencia el impacto del problema sobre la propia empresa: los proveedores no deben dejarse apabullar por el terror de los usuarios y éstos no deben dejarse envolver por los argumentos de venta de los proveedores".
Tanto los paquetes de soft estándar como la mayoría de los lenguajes y entornos de programación tienen en el contrato de licencia cláusulas por las cuales deslindan responsabilidades en forma muy amplia e implícitamente incluyen cualquier problema derivado del 2000. En realidad, la mayoría de estos contratos han sido redactados hace bastante tiempo y se refieren en forma muy específica, por ejemplo, a que el soft en cuestión se usa por cuenta y riesgo del licenciatario, ya que el mismo no fue diseñado para aplicaciones de misión crítica, como aeronavegación, defensa, instalaciones para salud, etc. De todos modos, estas cláusulas pueden o no tener efecto en la jurisdicción de la empresa, dado que hay legislaciones que no admiten algunos tipos de exclusión de las responsabilidades en los contratos y garantías. Por esta razón, es conveniente averiguar específicamente cómo es la ley local. Por otro lado, hay que tener en cuenta que, si los sistemas que usted compró a un tercero le causan problemas a alguien más, quizás usted sea el único responsable o, en el mejor de los casos, co-responsable de la acción.
Salvo que conste en forma escrita en algún tipo de documentación firmada por el cliente, todo elemento de procesamiento electrónico de información debería funcionar correctamente antes, durante y después del año 2000, ya sea porque el producto originalmente cumple ese requisito, o porque el proveedor facilita sin costo adicional los elementos que corrigen ese problema con suficiente antelación.
Esto es así aun cuando la vigencia de la garantía ya haya caducado. Es decir que el fabricante, desarrollador o proveedor deberá responder por el problema. No podrá invocar cuestiones de fuerza mayor ni imprevisibilidad, ya que el problema no obedece ni a una acción de la naturaleza, ni a un hecho producido en forma posterior a la entrega de los elementos y que no puedo ser previsto en dicho momento; menos aún obedece a un uso incorrecto por parte del usuario. Si bien recién se ha alertado sobre el tema en forma masiva desde el año 1996, la falta de previsión global no exime de responsabilidad a los causantes del problema, ya que, tanto la llegada del año 2000 después del 1999, como la imposibilidad de efectuar cálculos correctos sobre cuatro cifras usando sólo dos más allá del intervalo 1900-1999 eran previsibles aun 50 años atrás.
Si la empresa que originariamente realizó los sistemas es la que actualmente realiza el mantenimiento de los mismos, deberá encarar la adecuación de los programas sin que ello signifique una merma en los servicios habituales ni un costo adicional. Es importante tener muy en cuenta todo lo antedicho en cuanto a lo que "corresponde" o a lo que el derecho comparado sugiere, No obstante, no se deberá perder el espíritu práctico y, probablemente, la otra parte no querrá perder dinero. Es ahí donde comienza el terreno de las negociaciones, La existencia de nuevas versiones de equipos o sistemas podrá complicar aún más el panorama, ya que además de cumplir adecuadamente los requisitos para el 2000, tiene beneficios adicionales.
En estos casos, probablemente se partan las diferencias y el proveedor no tendrá la ganancia del producto a pleno y el cliente no deberá desembolsar el precio total de la nueva versión, ya que su interés primario era el tema fechas.
¿Qué derechos tengo?
Modelo de cláusulas de garantía relativas al problema informático del año 2000
A continuación se presentan modelos de dichas cláusulas de garantía utilizados por el Banco Mundial en todos los documentos relativos a las adquisiciones informáticas, a fin de imponer a los fabricantes, proveedores y contratistas responsabilidad de evitar el problema informático del año 2000.
- Objetivo
El fabricante o proveedor garantiza que todos los sistemas, programas y microprogramas de computación entregados en virtud de esta orden de compra permitirán procesar correctamente los campos de fechas (incluidos, sin que la mención sea taxativa, su cálculo, comparación y ordenamiento) comprendidas en el siglo XX, el siglo XXI o en ambos siglos, incluidos los cálculos que comprendan años bisiestos. La vigencia de esta garantía relativa al año 2000 y los recursos disponibles para el Cliente en caso de incumplimiento de esta garantía serán los definidos en los plazos y limitaciones de las garantías contenidas en la orden de compra, a los que también estarán sujetos, estipulándose que, a pesar de cualquier disposición en contrario de dicha garantía o garantías, los recursos disponibles para el Cliente en virtud de esta garantía relativa al año 2000 comprenderán la reparación o el reemplazo de cualquier producto suministrado en virtud de esta orden de compra que resulte defectuoso en los términos de la garantía relativa al año 2000, y cuyo defecto se comunicara al fabricante o proveedor por escrito a más tardar el 31 de diciembre del año 2000. Nada de lo estipulado en esta garantía deberá interpretarse como una limitación a los derechos o recursos que el Cliente pueda tener de otra manera en virtud de esta orden de compra con respecto a defectos distintos de los cubiertos por la garantía relativa al problema informático del año 2000.
- Garantía relativa al problema informático del año 2000 en las órdenes de compra
- Garantía relativa al problema informático del año 2000 en los contratos
3.1 para su inclusión en todos los contratos de compra y acuerdos de licencia de programas de computación
1. Perfecto funcionamiento en el año 2000
- El propietario de la licencia declara y garantiza que el programa de computación y/o lógica de este producto fue diseñado para su uso antes, durante y después del año civil 2000 ("año 2000"), y que el programa y/o la lógica de computación funcionarán durante dichos períodos de tiempo sin error de campos de fechas, incluidos, concretamente, los errores relacionados con, o derivados de, campos de fechas que correspondan o se refieran a distintos siglos o a más de un siglo y el tratamiento correcto del año 2000 como año bisiesto.
1.2 Sin perjuicio de la generalidad de lo expuesto, el propietario de la licencia declara y garantiza que el programa y lógica de computación:
1.2.1 No llegarán anormalmente a su fin ni proporcionarán resultados inválidos o incorrectos como consecuencia de campos de fechas, incluidas, concretamente, los que correspondan o se refieran a distintos siglos o a más de un siglo;
1.2.2 Se han diseñado para asegurar su compatibilidad con el año 2000 incluidos, sin que la mención sea taxativa, el reconocimiento del siglo correspondiente a los campos de fechas, cálculos que comprenden fórmulas y valores de fecha del mismo siglo y de varios siglos y valores de interfaz de campos de fechas que reflejen el siglo;
1.2.3 Ordenarán y manipularán los datos que contengan fechas, incluidas fórmulas que comprendan un siglo y varios siglos, y no harán que la aplicación llegue anormalmente a su fin ni generarán datos incorrectos.
1.3 La expresión "garantía de perfecto funcionamiento en el año 2000" significará el conjunto de las garantías estipuladas en esta Sección 1.
1.4 Si el propietario de la licencia no incluye en el producto la "garantía de perfecto funcionamiento en el año 2000" en el momento de la compra o el arrendamiento del programa y lógica de computación, deberá suministrar, sin costo adicional alguno para el Cliente, y a más tardar el 30 de junio de 1999, una versión del producto que sí incluya la "garantía de perfecto funcionamiento en el año 2000", y deberá instalar, probar y garantizar dicha versión sin costo adicional alguno.
2. PLAZO: La "garantía de perfecto funcionamiento en el año 2000" estipulada en el presente documento entrará en vigor en la fecha del acuerdo de licencia, y su vencimiento se producirá recién en la fecha de vencimiento del acuerdo de licencia.
3. RENUNCIA A LA LIMITACIÓN DE LA RESPONSABILIDAD: Toda disposición del acuerdo de licencia que en general limite o elimine la responsabilidad de cualquiera de las partes no resultará aplicable con respecto a la "garantía de perfecto funcionamiento en el año 2000" estipulada en el presente documento.
4. RESTRICCIÓN RELATIVA AL USO; LIMITACIÓN DE LA RESPONSABILIDAD: En caso de que el Cliente tenga derecho a modificar el programa de computación de conformidad con las disposiciones del acuerdo de licencia, el Cliente conviene en que no lo hará en una forma que pudiera tornarlo defectuoso en los términos de la garantía relativa al año 2000 prevista en este documento. El propietario de la licencia no será responsable de los defectos en los términos de esta garantía en la medida en que dicho defecto sea atribuible a la modificación del programa de computación por el Cliente.
3.2 para su inclusión en todos los contratos de adquisición de sistemas de computación, incluidos los que tengan programas de computación incorporados o integrados
El contratista garantiza que todo sistema, programa, lógica de computación u otros equipos suministrados o producidos en virtud de este contrato permitirán registrar correctamente y con precisión el cambio de fecha y hora al llegarse al año 2000 y años posteriores (incluido el reconocimiento del año 2000 como año bisiesto) de una manera que sea transparente para el Cliente, o bien, en caso de ser necesarias actualizaciones o soluciones alternativas para asegurar los cálculos y ordenamientos adecuados del cambio de fecha y hora en el sistema, programa, lógica de computación u otro equipo, se deberá suministrar al Cliente dicha actualización o solución alternativa sin costo adicional alguno, ya sea incorporándola en el producto entregado originalmente o en una versión revisada que deberá ser entregada, instalada, probada y aceptada por el Cliente a más tardar el 30 de junio de 1999.
El impacto legal, como era previsible, se considera menor que el económico. En los Estados Unidos ocurre exactamente lo contrario, pues la preocupación por los juicios y las demandas originados por el mal manejo de la información son una gran preocupación en las cúpulas de las empresas. Esto es previsible en función de lo que es la cultura en este tipo de temas en la Argentina.
El conflicto del año 2000 afectará a todo el mundo, ya sean en forma directa o indirecta: algunos casi no lo notarán, otros deberán efectuar un gran esfuerzo para salir indemnes y el resto sufrirá las consecuencias de la imprevisión y perderá su empresa o la verá reducirse a su mínima expresión. Tomando las precauciones correctas, será posible evitar casi todos los problemas; el grado en que este problema afectará a cada empresa dependerá de muchas variables, pero las dos más importantes son la antigüedad y calidad de los sistemas, y el rubro al que se dedican.
Algunas fechas pasan inadvertidas en un sistema mientras todo funciona bien, por ejemplo, las que sirven para rutinas de codificación o generación de números de control. Es cuando las cosas empiezan a fallar cuando realmente nos damos cuenta de que las fechas están presentes en todas las actividades. Las compañías telefónicas facturan proporcionalmente al tiempo de línea utilizado. El banco pagará más intereses cuanto más tiempo tenga su dinero en una caja de ahorro y, como contrapartida, cobrará más cuanto más tiempo le deban sus solicitantes de créditos. Los sistemas de clearing y acreditación de cheques, valores, cámaras compensadoras, etc., se verán seriamente afectados.
La mayoría de los bancos tienen sistemas que detectan cuándo una cuenta no ha tenido movimiento durante varios años y, en esos casos, disparan automáticamente una serie de acciones que, en el más leve de los casos, consiste en ubicar al titular de la cuenta o a algún pariente y, en el más severo, implica que el banco tome ese dinero para cubrir gastos de mantenimiento o lo done a instituciones de bien público. Esto es muy fácil que ocurra; imaginemos que un cliente efectúa una transacción entre el 23/12/1999 y la siguiente el 07/01/2000. Para el banco, la diferencia entre las dos fechas sería -99, es decir, 99 años entre ambas operaciones en vez de dos semanas.
También hay fechas en algunos sistemas de encriptado de datos, sobre todo en los que se usan para envíos de información bancaria y diplomática. Las empresas que elaboran, fraccionan o distribuyen productos alimenticios, medicamentos y cualquier otro tipo de sustancia perecedera que pierde efectividad después de cierto tiempo correrán el riesgo de distribuir productos vencidos o destruir lotes recién elaborados. En definitiva, todo lo que posea fechas de vencimiento correrá peligro. Si cree que casi todo está arreglado y que a usted no le va a tocar, haga algunas pruebas en forma personal. Fíjese en las facturas que tiene sin pagar y cuente cuántas fechas de vencimiento tienen 4 dígitos. Observe las fechas de emisión y vencimiento de su tarjeta de crédito y la fecha en la boleta de depósito de la caja de ahorro. Verifique sus contratos de locación, medicina pre-paga y pólizas de seguro.
Imagínese que todas esas fechas están ingresadas en las computadoras y lo van a estar por un buen tiempo más. Pareciera que todos piensan que el siglo 20 no terminará nunca.
Conocemos la presencia de microchips, adminículos que hoy en día están infiltrados desde el más inocente de los artefactos electrodomésticos hasta la más mortal de las centrales nucleares, controlando todas sus funciones. Es de esperar que el funcionamiento de los artefactos de los arsenales nucleares esté bien documentado. Los canales de televisión y las radios tiene prácticamente todos sus sistemas relacionados con el tiempo: la programación y la publicidad se organizan en base a estrictos horarios y fechas, y la publicidad se factura de acuerdo con la duración de los avisos. En las grandes explotaciones agropecuarias, las tareas de cría de distintas especies se organizan en base a diferentes tipos de alimentación según la edad, esquemas de vacunaciones, etc. En las actividades relacionadas con la salud, la fecha es fundamental: desde la planificación de turnos en consultorios externos de sanatorios hasta la fecha de vencimiento de medicamentos, desde los tratamientos programados, hasta los análisis con cultivos.
Dentro de los servicios públicos merece especial mención el área de salud, referida tanto a organizaciones públicas como privadas. En Abril de 1998 se constituyó un grupo de trabajo dentro de la Unidad Ejecutora 2000 (Argentina) para encarar el problema en el sector Salud. Se comenzó con una investigación acerca de cuál sería el equipamiento que podría resultar afectado, clasificándolo sobre la base de su criticidad y abarcando tanto las acciones de diagnóstico como de tratamiento de pacientes. Por dicho motivo se ha planificado una serie de comunicaciones y reuniones tendientes a lograr la toma de conciencia del problema por parte de:
- empresas productoras y comercializadoras de productos relacionados con la medicina;
- sociedades científicas;
- establecimientos sanitarios;
- profesionales; y
- servicios médicos afectados. Ha comenzado la realización de un inventario de todo el equipamiento involucrado, a fin de la ulterior planificación de las acciones necesarias para su corrección.
El área de Salud requiere especial atención y un accionar muy cuidadoso respecto de la problemática del año 2000. La mayoría del equipamiento médico moderno tiene microprocesadores incorporados con lógica sensible a fechas. Llegado el año 2000 algunos equipamientos biomédicos pueden verse afectados y no operar en forma correcta, provocando fallas que pueden ir desde problemas simples como informes impresos con 00 en vez de 2000, hasta equipamiento automático que deje de funcionar.
Los responsables de proyectos año 2000 deben realizar un inventario del equipamiento utilizado y verificar con el proveedor del mismo su compatibilidad año 2000. Otra fuente de información importante es Internet, donde los distintos fabricantes publican la situación de sus productos respecto de esta problemática.
Las empresas de servicios
En Argentina, la Unidad Ejecutora 2000 está dando asesoramiento a los Organismos Reguladores, especialmente a aquellos ligados con áreas de servicios públicos. El objetivo es obtener una eficaz acción sobre las empresas públicas o privadas que están bajo sus respectivas órbitas, tendiente a que adecuen sus sistemas para el año 2000 y así evitar los previsibles inconvenientes en la prestación de los servicios.
El área de energía, en sus diferentes tipos y diversidad de actividades se encuentra en la esfera de la Secretaria de Energía.
Con respecto a la energía eléctrica, la empresa CAMMESA (Compañía Administradora del Mercado Mayorista Eléctrico S.A.), integrada por la Secretaría de Energía y las cámaras que agrupan a las empresas de producción, transporte y distribución, está llevando a cabo las acciones relativas a la problemática del año 2000. Además participa el ENRE (Ente Nacional de Regulación Eléctrica) que, entre otras funciones, tiene a su cargo el dictado de normas sobre seguridad pública y su control, así como la promoción de la operación y confiabilidad de los servicios de distribución y transporte. Esta entidad llevará adelante un seguimiento de las actividades de las empresas, especialmente cuando ellas involucren dispositivos que puedan verse afectados con el ingreso al año 2000. También se realizan acciones con los organismos responsables de las restantes fuentes de energía, como gas e hidrocarburos líquidos, incluyendo además a la ARN (Autoridad Regulatoria Nuclear).
Con respecto al área de Gas en particular, ENARGAS (Ente Nacional de Regulación del Gas) ha requerido, a las 11 empresas reguladas por ella, la presentación de los planes de acción en curso en relación con la Problemática del año 2000. En este momento se está estableciendo la metodología de trabajo entre ENARGAS y las empresas, con colaboración de la UE-2000.
El área de comunicaciones está regulada por la Comisión Nacional de Comunicaciones, dependiente de la Secretaría de Comunicaciones, habiéndose ya establecido contacto con aquella para tratar el tema de la Problemática del año 2000. Se ha encarado un plan de control de las acciones de las empresas prestatarias del servicio de comunicación y hubo avances con respecto a los sistemas de su propia organización.
También se verán afectadas las empresas proveedoras de software y, como si fuera un castigo divino, el problema las afectará por partida doble: por un lado, como usuarios de sistemas deberán corregir sus aplicaciones y, por otro lado, deberán solucionar los problemas de sus clientes. Como si esto fuera poco, las que no puedan dar soluciones satisfactorias tendrán que afrontar altos costos en materia de arreglos, indemnizaciones y procesos legales.
¿¿¡¡ Tengo que cambiar mi sistema!!?? Todo sistema informático tiene en relación con sus datos un rango de validez asociado, tanto para la representación como para las operaciones que realiza con los mismos. Dentro del rango de validez, un sistema informático debe cumplir dos condiciones:
- Que los datos con los que trabaja sean unívocos
- Que las operaciones que realiza con los datos y los resultados sean válidos.
Todo dato que un sistema almacene o intercambie con otro sistema debe estar en un formato tal que sea interpretado en forma unívoca.
Requerimientos para productos que trabajen con fechas:
- El producto deberá tener definido explícitamente un rango de fechas en relación con un calendario, también explícito, en el que cumpla plenamente su funcionalidad.
- En el rango de fechas definido, deberá manipular y representar en forma unívoca las fechas, en relación con el calendario especificado.
- Todas las operaciones que realice con las mismas y sus resultados, deberán ser correctas y conservar la misma relación unívoca.
- Todo almacenamiento o interface que incluya fechas deberá especificar en los mismos la centuria en forma explícita o a través de algoritmos o reglas de inferencia que no presenten ambigüedad.
Se define como Año 2000 compatible, todo componente que cumpla con los "Requerimientos para productos que trabajen con fechas" para el calendario Gregoriano y con los siguientes rangos mínimos de validez:
- Hardware y Firmware desde 1/1/1980 hasta 31/12/2030
- Sistemas Operativos desde 1/1/1980 hasta 31/12/2030
- Software de base y Sistemas de desarrollo desde 1/1/0001 hasta 31/12/2999
Aplicativos El rango a establecer en estos casos, deberá ser acorde con el rango de fechas
necesario para el correcto cumplimiento de todas las funciones que el sistema de información deberá soportar.
- Jurídico
Parece que el año 2000 para algunos va a ser un problema y para otros una solución a sus economías, por lo menos para un solo segmento de la sociedad: los abogados.
Una presentación realizada en una reciente conferencia de suscriptores patrocinada por el Lloyd de Londres, se estimó que U$S 1 billón o más, estará en juego en los litigios que se producirán derivados del problema del año 2000. "Casi todas las grandes empresas ya han establecido alguna práctica legal con vistas a prevenirse del problema del año 2000", dijo uno de los abogados expositores. "Las compañías de computación que le venden grandes sistemas a los gobiernos locales son los blancos más vulnerables", añadió el letrado.
Mientras los abogados del Viejo Mundo y los Estados Unidos comienzan a trazar su estrategia para el año 2000, en la argentina aún no existe la suficiente "conciencia legal" sobre las consecuencias económicas que provocará el Y2K.
El experto en derecho en tecnologías de la información, Dr. Antonio Millé, expuso el problema desde su área en "¿Cuáles serán las responsabilidades legales de su empresa o de sus socios comerciales afectados por el problema del año 2000"?. Sus recomendaciones se basaron en que la tecnología no es un área litigiosa y que, en nuestro país, a diferencia de los EE.UU., no existe una cultura litigante.
Debido a esto, el objetivo en la parte legal debe ser buscar soluciones entre las partes intervinientes, "hay que evaluar con prudencia el impacto del problema sobre la propia empresa: los proveedores no deben dejarse apabullar por el terror de los usuarios y éstos no deben dejarse envolver por los argumentos de venta de los proveedores".
El encarar adecuadamente la llegada del año 2000 supone, además, el identificar los riesgos en que se puede incurrir, con el fin de poderlos evaluar y emprender las acciones precisas para superarlos o en todo caso minimizarlos.
Entre los más significativos de carácter general están:
La consideración únicamente de los Sistemas de Información corporativos desarrollados a la medida, con olvido de los departamentales y de las aplicaciones estándar o paquetes, de los sistemas básicos (gestores de bases de datos, sistemas operativos, utilidades, etc.), de los equipos de proceso, almacenamiento y comunicaciones, e incluso de aquellos otros que sencillamente utilizan microprocesadores (centralitas, controles de accesos, etc.), puede provocar problemas de importancia no inferior a la que daría lugar el funcionamiento erróneo de los primeros.
- Alcance
La evaluación equivocada de la magnitud del impacto de los problemas a que da lugar en un organismo la llegada del Año 2000 o un planteamiento que parta de que se trata de algo que básicamente deben resolver otros, casi con total seguridad provocará inaceptables desviaciones en el tiempo y muy probablemente la imposibilidad de contar con los recursos suficientes, internos o externos, para recomponer la situación.
Las dudas en acometer los trabajos necesarios y el consiguiente aplazamiento del comienzo de las actuaciones pueden incrementar exponencialmente los riesgos de no llegar en fecha y de incurrir en costes excesivos e indebidos.
- Recursos
Una visión no contrastada, demasiado optimista de antemano sobre la capacidad, disponibilidad y adecuación de los recursos humanos y materiales que se han de emplear, tanto en términos de idoneidad técnica como de volumen, puede afectar muy negativamente al cumplimiento de los plazos y la calidad de los resultados.
- Costes económicos
La aparición de errores en los procesos de registro y elaboración de la información, así como consecuentemente en su uso, pueden dar lugar a costes, directos e indirectos, o disminuciones de ingresos muy importantes; a los que habría que añadir seguramente efectos intangibles negativos en cuanto a calidad de servicio y deterioro de la imagen de las Administraciones Públicas.
En un proceso tan complejo, amplio y dilatado como será normalmente el de adaptación al Año 2000, es prácticamente imposible que no se produzcan imprevistos y aparezcan fallos, aún cuando los procedimientos de cambio se desarrollen correctamente.
La tentación de aprovechar la coincidencia en el tiempo de las dos problemáticas que afectarán próximamente a cualquier Organismo: la llegada del Año 2000 y la entrada en vigor del Euro, unificando en un solo proyecto su resolución, puede ser muy fuerte.
Es esta una alternativa estratégica que debe ser cuidadosamente analizada en cada instalación, ya que la complejidad y volumen de las actuaciones a realizar en ambos casos y las diferencias realmente existentes en los aspectos funcionales, incluso en el caso de los formatos, que es el que mayor similitud supone, representan un serio inconveniente para ello.
No obstante es posible e incluso aconsejable con carácter general el empleo de herramientas comunes y el doble uso de estudios e informaciones de índole general o referentes al impacto en los sistemas en cuanto a la identificación de fechas e importes.
Todo ello independientemente de la obligada coordinación entre los dos proyectos, que por otra parte no sería sino un caso particular de la que en general debe existir en relación con los desarrollos e implantación de nuevos sistemas el mantenimiento de los que estén en explotación, la puesta en marcha de nuevos equipos o sistemas básicos, etc..
Por otra parte, con carácter más general, la obligada coexistencia con el funcionamiento y mantenimiento habituales de los sistemas existentes y con el desarrollo de otros nuevos es también un riesgo potencial que se ha de superar estableciendo los adecuados mecanismos de control y coordinación en cuanto a cambios, configuración y normativa.
Dar por seguro y obligado que los suministradores de equipos y sistemas emprenderán en todos los casos las actuaciones necesarias para la resolución del problema del Año 2000, y que serán capaces de dar una respuesta adecuada en los plazos correctos, no constituye una apreciación incuestionable.
A ello habría que añadir la dificultad que pueden suponer las personalizaciones hechas a paquetes, en las que el papel y responsabilidades del suministrador puede no estar claras.
Por tanto, se deben adoptar las medidas de seguimiento pertinentes para identificar o establecer los compromisos adquiridos por los suministradores y controlar el avance de sus actuaciones, considerando los oportunos planes de contingencia en previsión de posibles incumplimientos.
Normalmente todos los Organismos de las Administraciones Públicas precisan enviar o recibir información. Si dicho intercambio se hace por medios informáticos, soportes magnéticos o comunicaciones, es difícil que el emisor y el receptor implanten simultáneamente las adecuaciones de formato de la fecha.
Será, por tanto, necesario establecer los mecanismos de coordinación adecuados, con el fin de asegurar la integridad de los datos y evitar el asumir o provocar contingencias.
Alternativas de Solución para el problema
Desde una perspectiva general y de forma sintética las posibles opciones en el caso de los Sistemas de Información, son:
- Convertir las aplicaciones, es decir adecuar los programas, y eventualmente los datos, conforme a alguna de las diferentes técnicas existentes.
- Desarrollar nuevamente las aplicaciones, respetando estrictamente sus funcionalidades actuales o incorporando otras nuevas.
- Sustituir las aplicaciones desarrolladas a la medida por paquetes estándar.
- Sustituir los paquetes estándar por nuevas versiones u otros que cumplan las especificaciones necesarias.
- Eliminar las aplicaciones sin sustituirlas por no ser ya realmente necesarias.
En cuanto a las soluciones en el caso de que existan problemas con los equipos o los sistemas básicos, estas se limitan a:
Migrar hacia nuevas versiones, si no están discontinuados los productos. Sustituir por nuevos productos, del mismo fabricante o de otro.
En los diferentes ámbitos habrá que estudiar cual es la solución más idónea considerando factores tales como:
- Criticidad de las aplicaciones o productos.
- Disponibilidad de recursos.
- Coste de cada alternativa.
- Fiabilidad de la solución.
- Garantía de cumplimiento de plazos.
- Integración en relación con el conjunto de la instalación.
- Adecuación a la estrategia general de sistemas.
- Cobertura global de riesgos.
¿Qué es una fecha? No es una pregunta simplista, es seria y responderla correctamente, aumentaría el éxito de resolver el problema.
Para entender la complejidad de la pregunta ¿qué es una fecha?, necesitamos entender un concepto clave en las computadoras: Las computadoras son "sabios idiotas". Ellas realizan tareas milagrosas, pero no entienden nada de lo que están haciendo.
Una forma de describir las computadoras, es verlas como manipuladoras de símbolos. Los símbolos por sí mismos no tienen significado para ellas. Los símbolos significan mucho para nosotros, pero para las computadoras son "sólo" ceros (0) y unos (1) que son manipulados de acuerdo a unas reglas predefinidas por nosotros.
Cuando una computadora resta 55 a 00 y ofrece el resultado -55, esto lo hace siguiendo las reglas de aritmética y lo hace correctamente. Y es correcto, hasta que nosotros decidimos que aquel datos, representa una fecha, un año y hasta que esos números no contengan toda la información necesaria para que lo sea, la respuesta no tiene significado. Esto, no tiene significado porque 00 podría representar 2000, pero nosotros le indicamos a la computadora que "asuma" que 55 representa 1955 y que 00 represente 1900. Y obviamente esta incorrecta instrucción es un error.
Si tenemos todas las fechas etiquetadas de acuerdo a estándares, por ejemplo, todas las fechas llevarán el prefijo DATE, entonces encontrar las fechas en nuestros programas sería facilísimo. Pero nunca se creó tal estándar. Las fechas han sido etiquetadas, como mejor se le ocurría al programador, algunas con bdate como prefijo y otras con cualquier cosa, sólo el programador lo sabe.
Existen otras alternativas para la bien intencionada frase "ponga dos dígitos más y ya", es la parte más simple de comunicar. Hay dos "soluciones" más al asunto.
Crear otro bit para un dato conocido como "indicador de siglo" ("century") Si el indicador está en 0 entonces el número 55 se refiere al año 1955, si es 1 entonces se refiere al año 2055. Esto es un poco más complicado y toma más tiempo de comunicar. Esto crea un problema secundario. ¿Utilizarán todas las compañías 0 para indicar "19" o algunas utilizarán 0 para indicar "18" y 1 para "19"?
Otra solución, mucho más complicada de explicar y por tanto más susceptible a error, es utilizar un "dato lógico" para hacer que la computadora determine el siglo adecuado. Por ejemplo: Si se introduce un nuevo dato de nacimiento a la computadora, para efectos de matrícula escolar, entonces se puede asumir que cualquier dato mayor a 90 es el año "19nn", entonces cualquiera menor a 10 será del año "20nn". Por supuesto que se tiene que actualizar este rango de fecha en la base de datos de la computadora o hacer que la computadora lo cambie, dependiendo de la fecha actual (como vemos es difícil de explicar).
Por ahí, se encuentran más esotéricas soluciones. No tan simples como las descritas aquí y todas sufren de alguna falla…y hay todavía 100,000,000 de líneas por cambiar en su compañía.
No importa cuál solución escoja, aún tenemos 100,000,000 de líneas de código que contienen un número desconocido de errores, que son difíciles de identificar y deben ser arreglados antes de DICIEMBRE DE 1998.
¡¡¿1998?!! Esta es otra parte de las malas noticias…No importa qué cantidad de código tenga, no importa qué cantidad de presupuesto tenga disponible para realizar la tarea, no importa cómo piensa hacer la conversión, Ud. tiene la misma fecha límite para hacerlo. Diciembre 31 de 1998. Se debe terminar el asunto en esta fecha, ya que debe probar los cientos de miles de cambios que habrá hecho en sus aplicaciones. Se necesitará hacer esto antes del 2000, ya que es un riesgo para los negocios descubrir errores cuando no se tiene idea que tanto tiempo se tomará arreglarlos. Si mientras tanto, se detiene la línea de producción, no se podrá atender a los clientes porque los programas para facturarlos no están trabajando.
Las compañías que han asumido el reto no han sobrestimado el tiempo para resolverlo. El problema siempre se ha presentado como extenso, feo y costoso que cualquier otro imaginado, costoso… más costoso de los que se imagina. ¡Ya se escucha el crujir de dientes! Tenemos que hablar de los costos. ¿Cuánto costará arreglarlo? Si consultamos un mercenario, podría preguntar ¿Cuánto tiene? He aquí la terrible aproximación que se hace en la industria… $1.00 por cada línea de código. ¡qué significa esto para el que tiene 100,000,000 líneas de código? (estimar este proyecto es sumamente difícil ya que el costo final depende de otras muchas variables). Recordemos qué tan grande es 100,000,000 líneas de código. Si se gasta un dólar cada segundo, 8 horas al día, 5 días a la semana, esto tomará más de 13 años para gastar $100,000,000.
Algunas compañías han descubierto con asombro que les tomará casi 100 años resolver el problema. Que deben poner 30 ó 50 personas en este proyecto. Que estas personas no harán más en los siguientes 2 o 3 años más que trabajar en el proyecto del año 2000, hasta que sea resuelto. Otras compañías han sugerido que alguien llegue con una solución, y dejan el problema para después, porque esperan que igual que las viejas películas del oeste, llegue el "llanero solitario" a rescatarlos en el último momento.
Los expertos que han estudiado el asunto con profundidad, están de acuerdo en pocas cosas, sin embargo en algo sí están de acuerdo, la probabilidad de una solución mágica no existe. Esto es grande, y se pondrá feo y menos que lo arreglemos, las computadoras llegarán a sufrir. ¿Dónde comenzar? Ud. comenzará verificando si el problema es verdad. La única cosa buena del problema, es que Ud. todo lo que tiene que hacer es examinar sus sistemas y ver qué pasa si la fecha es 01/01/00.
Antes de examinar sus sistemas, abra su billetera o bolso y examine los documentos que en ella tiene. Mire su tarjeta del banco, su tarjeta de crédito, carné de seguro, licencia de conducir, etc… ¿Cuántos contienen datos con dos dígitos? ¿Cuántos sistemas que utilizamos, contienen datos de este tipo ya asumirán que 00 es 1900?
Para continuar con esta mini – auditoría, vayamos a todos nuestros sistemas y veamos si aceptan 4 dígitos. Si no es así, la oportunidad que sean afectados negativamente por el cambio de siglo es terrible. Sea más agresivo, introduzca a su sistema fechas del 2000. Donde las computadoras aceptan solamente datos de dos dígitos, introduzca 00 a ver qué pasa. Si los acepta no se alegre todavía…espere que la computadora procese y dé resultados. ¿Asume la computadora que 00 es 1900? Si lo hizo, ya terminó la prueba…Ud. tiene problemas. ¿Qué hacer con respecto a esto? ¡He ahí la pregunta! ¿Lo ignorará hasta que el sistema falle, y hasta ese momento lo tratará de arreglarlo? ¿O lo hará ahora? Para arreglarlo, debe seguir dos pasos:
1. Asigne a una responsable que se asegure que su compañía puede seguir a flote en el futuro y no naufragará contra referencias 00. Alguien que no tenga otra responsabilidad excepto asegurarse que su compañía puede operar en el año 2000. Si Ud. trata, o alguien trata que hacer esto como parte de sus responsabilidades, fallarán. Fallarán porque no será prioridad 1, entonces harán otras tareas para hoy, y el proyecto no se iniciará o este nunca terminará.
2. Después, deberá determinar, cuánto código hay en su organización. Si sólo tienen 50,000 líneas de código y bien documentado, entonces su problema es muy diferentes si tuviera 500,000,000 líneas. Lo primero que debe hacerse, es saber cuánto código tiene, pero esta es una respuesta que casi nadie la tiene. ¿Por qué? Porque nunca hemos tenido un sistema que abarque toda una organización. Las compañías han encontrado que solo obtienen las respuestas a esta pregunta de 3 a 6 meses o a veces más. Así que comience por un inventario y al mismo tiempo dé una mirada en el mercado para ver qué soluciones encuentra para la crisis del 2000.
Aunque hemos afirmado la dificultad de encontrar las fechas en los sistemas, hay muchas buenas herramientas en el mercado para realizar inventarios automáticos. Hay algunas extremadamente inteligentes que pueden cambiar gran parte, no todas, del código automáticamente. La habilidad de estas herramientas para ayudar en la localización de las fechas, depende del lenguaje que utilizaron para desarrollar las aplicaciones.
Prepárese para alguna desilusión cuando examine algunas de estas herramientas. Puede ser que no haya ninguna herramienta disponible para una sustancial parte de nuestro inventario. Hay cerca de 500 lenguajes de programación utilizados para desarrollar aplicaciones. Muchas de estas herramientas de conversión e inventario con pocas modificaciones, funcionan bien con estos 500 lenguajes. Una mayoría de las herramientas se enfocan en COBOL, el más popular de los lenguajes de negocios en el mundo. Muy pocas herramientas, si las han diseñado, ayudarán en esta área en lenguajes como APL o JOVIAL.
Una vez que haya seleccionado un vendedor para público en general o un vendedor exclusivo, estará listo para ejecutar su primer análisis de impacto. El propósito de este análisis es determinar a gran detalle la naturaleza de su problema.
Hay algunas preguntas que deben ser contestadas. ¿Cuál es su sistema crítico? Tiene que ser aquel que trabaje día tras día y que sin él no se podría realizar su negocio. ¿Cuándo fallará? Muchos sistemas fallarán antes del 2000. Fallarán porque algunas de sus aplicaciones utilizan fechas futuras. Por ejemplo las agencias de rentas de autos, que verifican la expiración de las licencias para conducir.
Una vez obtenida la información de este análisis, debe iniciar la creación de un plan. ¿Qué aplicaciones deben ser cambiadas? ¿Cuándo deben estar listas? ¿Cuánta gente necesito en esta fase del proyecto? ¿Cuál es su línea límite de tiempo y qué hará para liberarse de ella?
A diferencia de otros proyectos, la fecha límite no se puede mover, está ahí y no se puede cambiar: 1º de enero de 2000. No se podrá posponer. En esta fecha los sistemas podrían caer en caos, y dejar de funcionar hasta que sean reparados. Si su sistema de contabilidad falla, entonces no se podrán producir facturas hasta que lo arreglen. ¿Qué tan largo puede sobrevivir su organización sin la posibilidad de emitir recibos por sus servicios? El camino parece largo, difícil y con la línea final más incomprensible antes jamas vista.
Sólo hay una pequeña buena noticia en todos esto para los programadores de computadoras, y es que los salarios de los programadores están esperando sobre un cohete para los próximos años y después de que la compañía descubra el problema real del 2000 requerirán un gran número de ellos. Por supuesto que esto no es una buena noticia para quienes pagan los salarios, sobre todo tener que pagarle a quienes ocasionaron el problema. Haga matemáticas. Tome el estimado de $600,000,000,000 y extiéndalo a tres años, es decir $200,000,000,000 por año. Asuma que un programador obtiene $100,000 por año (ahora no, pero después) eso significa que necesitaremos 2,000,000 de programadores trabajando en esto todos los días por los próximos 3 años. Todo porque los programadores trataron de ahorrar espacio en las tarjetas de Hollerith hace 30 años.
Soluciones parciales
El 70% de las empresas está buscando una solución integral. Tiene tendencia a analizar todo el problema como un conjunto y buscar una solución integral para resolverlo.
Pese a ello, el 30% restante piensa como alternativa una solución parcial, subestimando quizá que el Y2K no es tan complejo como para derivar todos los esfuerzos hacia ese punto.
Después de mi, el diluvio
La siguiente es una técnica que, en muchos casos, no se puede utilizar y, cuando es posible utilizarla, no siempre es conveniente. No obstante, puede ser la única alternativa para los casos en que no se dispone de algunos de los programas fuentes para modificarlos, o bien cuando el tiempo de que se dispone es totalmente insuficiente.
A todas las fechas que se agregan, mediante una rutina externa se les resta al campo del año el número 28 y, luego, al leerla, se les suma 28. De esta manera, se evita que desborden los dos dígitos, por lo menos hasta el año 2027, en que eventualmente habría que empezar a restarles 56, pero digamos que así se dispone de un lapso más que razonable como para hacer correcciones más elegantes. Internamente, los programas manejas y graban fechas atrasadas casi tres décadas, pero a nivel de resultados externos, quedan los correctos.
Se utiliza la cifra de 28 años y sus múltiplos porque es el ciclo en que se corresponden los días con las fechas, por ejemplo el 7 de enero de 1972 fue viernes y el 7 de enero del 2000 también lo será.
De esta manera, el sistema procesará correctamente las rutinas que validen los días hábiles. En lo que a limitaciones se refiere, este método no podrá ser utilizado fácilmente, por ejemplo, si el programa toma la fecha del sistema en una PC, ya que ésta no puede ser inferior al 1 de enero de 1980.
A veces, lo mejor no es compatible con lo posible. Imaginemos una empresa que acomete el problema muy fuera de tiempo, y que por cualquier método convencional no podrá llegar ni a cubrir las aplicaciones más críticas. En este caso se pueden usar todos los medios automáticos y paquetes estándar de corrección y migración que sean aplicables a nuestra plataforma de trabajo. A partir de ahí, todo el esfuerzo se concentrará en simular y verificar todas las condiciones de error y corregirlas; todo esto, por supuesto, realizado en un ambiente en paralelo con la aplicación. No es una solución para cardíacos, pero quizás sea la única.
La imposibilidad física, una implementación en paralelo Dependiendo de la técnica empleada y sus variante, además de la implementación en paralelo se puede llegar a trabajar sobre las mismas versiones operativas, pero agregando una rutina por la cual no se usen los formatos y/o modificaciones hasta que no se ingrese una clave de activación general en los sistemas.
Veamos los pro y los contra de esta situación:
Paralelamente a la ejecución de los cambios, la empresa seguirá su funcionamiento normal, lo cual obviamente significa que surgirán desarrollos nuevos con posterioridad a una o varias de las etapas del proyecto 2000. Acá pueden surgir dos alternativas: se trata de sistemas independientes de los ya establecidos o bien se trata de desarrollos con diversos grados de conexión con el soft ya existente.
En el primer caso, la solución pasará por elaborar rutinas de fechas con 4 dígitos para el año y las correspondientes grabaciones en archivos con dicho formato.
Para el segundo caso, las cosas cambian radicalmente y, si bien se puede trabajar con versiones híbridas, lo más aconsejable es desarrollar una versión que sea compatible con el sistema actual y otra con las correcciones por el 2000. Si bien puede parecer una solución que duplique el trabajo, en realidad no lo es, puesto que la versión C2000 se irá generando como la simple copia de texto del programa actual con la rutina modificada simultáneamente. Al trabajar con una sola versión que "piense" con qué tipo de fecha está trabajando, se genera un altísimo riesgo y se dificulta el mantenimiento.
Los costos a corto, mediano y largo plazo de estas soluciones Si bien todo indica que los costos son menores tanto a corto como a mediano plazo, es solamente como "patear la pelota hacia adelante" y aumentar los costos a largo plazo consecuentemente con los riesgos de la organización.
El costo de este tipo de soluciones parciales, que bien podrán definirse como "parches" es menor en cantidad de personas dedicadas al proyecto y en tiempo y recursos utilizables para el desarrollo del mismo. No se necesitarán equipos adicionales ni grandes modificaciones en los campos fecha, sino rutinas externas que "oculten" el año real.
Además se puede apreciar que en un término de tiempo mediano, se llegará con la solución al día requerido, lo que implica que no traerá aparejado el cierre de la empresa por falta de planificación al respecto.
Sin embargo, la solución no es definitiva y deja librado al azar la modificación final de los programas con lo cual volveremos a estar en algún momento frente a esta misma situación. Realmente es imposible determinar en ese futuro cuál será el costo y el riesgo puede ser muy alto, no solamente económico sino que puede provocar otros conflictos no previstos.
Hace dos años me preguntaron si las empresas enfrentarán un enorme dolor de cabeza el 31 de diciembre de 1999 debido al "problema del año 2000", Y2K por sus siglas en inglés (Year Two Thousand).
El problema del año 2000 es causado por el uso de fechas de dos dígitos en los programas de computadora, tales como "01" para señalar el primer año de un nuevo siglo. Cuando pasamos del 1999 al 2000, las fechas de dos dígitos se hacen ambiguas.
Si alguien se jubila en el año 2001 y la computadora interpreta "01" como 1901, entonces puede decidir que la persona se jubiló antes de ser contratada y por lo tanto no tiene que recibir un céntimo de pensión. "Será un dolor de cabeza", dije al aludir el problema del año 2000. "Lo que aún resta por determinar es cuan grave será el daño". Lo cierto es que empresas a nivel mundial están trabajando arduamente para evitar daños.
Las centrales de computadoras serán las más afectadas. Eso se debe en parte a que el uso de dos dígitos para las fechas era común en los sistemas más antiguos cuya memoria era limitada a raíz de los altos costos. Debido a que el problema puede hallarse en cualquier parte en un código muy complejo, lo más difícil es encontrar todos los lugares donde puede ocurrir.
No es sorprendente que los programadores en toda la industria de cómputo o de tecnologías de la información (TI) se adapten a nuestra manera de pensar. Es por eso que inclusive algunos programas producidos en estos últimos años tienen el problema del año 2000, aunque eso no está muy generalizado.
Por ejemplo, de los 60 productos básicos de Microsoft, sólo tres no satisfacen los requisitos establecidos. Los tres fueron lanzados a la venta antes de 1995, y sólo uno, "Word 5 para DOS", requiere una actualización (la mayoría de los productos de Microsoft podrán funcionar sin problemas inclusive en el siglo 22. A su vez, Windows NT puede lidiar con fechas durante los próximos 10,000 años).
Las empresas deben revisar sus programas y asegurarse de que empleen fechas de cuatro dígitos en el futuro. Aunque Microsoft y otrosvendedores han estado publicando información durante algún tiempo acerca del problema del año 2000, los clientes están buscando información más específica.
Como resultado, mi empresa recientemente actualizó su lugar del Año 2000 en la red Internet. El sitio es httpp://microsoft.com./year2000 e incluye consejos técnicos para organizaciones. Nuestro consejo principal es que, debido a la magnitud de los sistemas afectados, las compañías deben examinar sus sistemas técnicos de punta a punta.
Empresas que comenzaron a trabajar en el problema hace varios años pueden analizar y arreglar con tiempo sus sistemas. Otras compañías pueden reemplazar sus aplicaciones más viejas con otras modernas que posean la misma funcionalidad. Entre tanto, he aquí algunas cosas que pueden hacerse:
– Emplear programas actualizados cuando sea posible. Los problemas del año 2000 son relativamente raros en reciente "software" de empresas líderes en el ramo.
– Poner a funcionar los sistemas de computadora de una empresa en sistemas más nuevos y verificar la forma en que operan.
– Simplificar complejos procesos antiguos y hacer participar a manejo de las computadoras. Cuando el proceso es más simple, también resulta más fácil automatizarlo y actualizarlo.
– Preparar un plan de emergencia en caso de fallas. Es posible desarrollar una combinación de sistemas de computadora y otros manuales que cubran los aspectos esenciales a fin de mantener a una empresa en funcionamiento.
No será una tarea fácil. Todas las computadoras de una empresa deben ser sometidas a escrutinio a fin de determinar cómo lidian con las fechas. Pero eso puede concretarse si se cuenta con un buen plan capaz de establecer claras prioridades.
En la actualidad los profesionales de la tecnología de información que parecen enfrentar una tarea más difícil son los europeos. No sólo deben lidiar con el problema del año 2000 sino también implementar sistemas financieros que puedan manejar el Euro, la divisa que comenzará a circular a partir del primero de enero de 1999…
Hablando de Computadoras Bill Gates
Y2K vs TI
Los sistemas operativos
Para Mainframe
La gran mayoría de los sistemas hechos para Mainframe tienen una antigüedad considerable y, por ende, los formatos de fecha son de dos dígitos para el año; por otra parte, suelen tener distintas lógicas de programación. Los sistemas operativos en sí mismos soportan el formato de fecha largo, pero a veces, dependen del lenguaje de programación utilizado y su versión.
Para Midrange
Unix (en general) soporta 4 dígitos, pero la mayoría de las aplicaciones sólo usan los 2 dígitos habituales para el año. Algunas aplicaciones pueden confundir el 2000 con el año 1970.
Para Pcs / Redes
DOS 3.0 – 3.3 – 4.0 – 5.0 – 6.0 – 6.2: en general, tienen un BIOS con una fecha de inicio que es 01-01-80. En la mayoría de los casos, manejan el año con dos dígitos. Hay que correrle un test a la PC para verificar.
Windows 3 – 3.1 – 3.11 – 95 – 98 – NT: manejan formatos largos y cortos para fecha; hay que vigilar qué valor está tomando la aplicación. En Windows 95, por ejemplo, cuando se ingresa cambio de fecha, el sistema pone como formato dd-mm-aa, a pesar de que realmente toma 4 dígitos para el año. Para Windows NT, si bien la mayoría de las funciones de fecha son compatibles, las rutinas calendario requieren un parche.
Novell Netware: si bien algunos consideran a los productos Novell Netware simplemente como un paquete para conectar equipos entre sí, en realidad se trata de un sistema operativo, y como tal merece respeto y atención. Actualmente hay 60.000.000 de usuarios Novell en el mundo y la empresa se encuentra actualmente en proceso de analizar toda su producción, además de investigar los productos de terceras partes que habitualmente se utilizan junto con sus propios productos. En este caso, habrá que esperar y ver; ya que la cantidad de versiones Novell es realmente importante y, probablemente, la respuesta dada por el gigante de las redes será confiable.
Los paquetes utilitarios
En lo referente a planillas de cálculos, procesadores de textos, correo electrónico y, en general, todos los utilitarios de oficina, apreciamos que lo más práctico es comprar las versiones posteriores a 1997, que en el caso de las grandes marcas se están diseñando para soportar bien los cuatro dígitos del año. Pero no todo termina ahí: habrá también que migrar los datos desde los productos más antiguos, y habrá que pasar todas las fechas con formato largo o bien modificarlas. Sobre todo a nivel de planillas de cálculos, habrá muchas macros que sus dueños querrán conservar. Todo este bagaje de procedimiento deberá ser cargado manualmente o mediante los utilitarios de migración que traen los mismos paquetes. Lo que no puede automatizarse es la revisión del formato en que efectivamente quedaron traspasados. También será conveniente la revisión funcional de las distintas rutinas y planillas con los usuarios específicos.
Los sistemas operativos y aplicaciones Microsoft se utilizan en casi todas las computadoras, por lo que usted y su empresa dependen de cómo solucionó la compañía de Bill Gates el problema del año 2000.
El concepto de "Certificado para el año 2000", con que se promocionan muchos productos de software, no es útil para clasificar el comportamiento de un producto en el nuevo milenio, ni refleja las complejidades que los usuarios pueden enfrentar con el cambio de siglo. La frase tampoco ofrece una guía que permita al usuario prepararse para el 2000.
Hay diversas razones que impiden que exista una auténtica garantía de certificación en el mercado:
– Aún cuando existen algunas definiciones de "compatibilidad con el año 2000", no existe hasta el momento un conjunto de pruebas estándares capaces de certificar la compatibilidad. En algunos de los actuales procesos de certificación, la certificación se efectúa en ambientes estrictamente controlados. Cualquier prueba que se desvíe de la configuración autorizada debe ser re-certificada para ser compatible. En el caso del año 2000 es imposible que un sistema de certificación similar pueda ser implementado en un marco de tiempo razonable. En síntesis no existe estándar alguno que permita afirmar que un software está realmente certificado para el año 2000.
– Con la flexibilidad de programación del software moderno es bastante probable que, al usar un programa de forma determinada, muchas personas acaben enfrentando el problema del año 2000 independientemente del producto que empleen. Muchos usuarios, por ejemplo, almacenan fechas en campos de texto, realizan cálculos particulares en ciertas aplicaciones y capturan datos en dos dígitos en forma forzada. Esto significa que, para tener una auténtica validación del año 2000, no sólo tendría que ser certificado el producto sino también su uso.
– Aún cuando no cumplan con todos los criterios de una "Certificación 2000", algunos productos podrán ser usados más allá de fin de siglo. Esto se aplica especialmente a productos que utilizan una ventana de tiempo para convertir campos de fecha correspondiente al año de dos dígitos a cuatro automáticamente. Por lo tanto, el no ser "Compatible con el año 2000" ignora la posibilidad que esos productos se puedan utilizar correctamente en el siglo XXI.
Para ayudar a sus clientes a preparar sus sistemas, Microsoft identifica el comportamiento de los productos a través de la siguiente clasificación:
– Tipo A: el producto no tiene problemas conocidos relacionados con el año 2000 que impidan su continua utilización y no requiere cambios en su modo de empleo. Acepta la captura en formato de dos dígitos en una ventana 19XX – 20XX. En los productos de este tipo , el valor de los dos dígitos automáticamente determina los dos dígitos precedentes. Por ejemplo en Microsoft Excel, en sus versiones 4, 5 y 7, los dígitos 00 a 19 son automáticamente interpretados como 2000 a 2019 mientras que el 20 es capturado como 1920. En la versión 97 de los productos Microsoft, el pivote se incrementa a 29, por lo que el número se almacena como 2029 y el 30 como 1930.
– Tipo B: el producto no tiene problemas con el año 2000 que le impidan operar correctamente en esa fecha. Sin embargo, requerirá cambios en la manera en que es utilizado. Por ejemplo, es necesario evitar escribir dos números para representar fechas de cuatro dígitos.
-Tipo C: existen condiciones que impiden al sistema operar correctamente con el año 2000.
Cabe mencionar que la plataforma de 32 bits ofrece una biblioteca de funciones que, entre otras cosas, provee la capacidad de convertir fechas de dos a cuatro dígitos.
Microsoft ha detectado ciertas limitaciones de tipo B y C en algunos de sus productos. Sin embargo, en la mayoría de los casos estas limitaciones resultan ser menores. Por ejemplo, Microsoft Windows 3.x y Windows 95 presentan errores estéticos en su versión original, ya que el despliegue de los archivos creados en el año 2000 genera basura en la pantalla. No obstante, este inconveniente no origina ningún error en los cálculos o la destrucción de la información.
Fechas límites de los productos
En los sistemas operativos y las aplicaciones Microsoft se han detectado los siguientes límites en la manipulación de fechas.
Productos Microsoft / Año límite
Microsoft Access / 9999
Microsoft Excel 95 / 2078
Microsoft Excel 97 / 9999
Microsoft Proyect 95 / 2049
Microsoft SQL Server / 9999
Ms-DOS sistema de archivos (FAT 16) / 2108
Visual C++(4.x) runtime library / 2036
Visual FoxPro / 9999
Windows 3.x sistema de archivos (FAT 16) / 2108
Windows 95 sistema de archivos (FAT 16) / 2108
Windows 95 sistema de archivos (FAT 32) / 2108
Windows 95 runtime library (WIN 32) / 2099
Windows para Workgroups (FAT 16) / 2108
Windows NT sistema de archivos (FAT 16) / 2108
Windows NT sistema de archivos (NTFS) / 29601
Windows NT runtime library (WIN 32) / 2099
WordBasic / Comandos de fechas de Microsoft Word / 4095
Los lenguajes de programación
Normalmente, el primer paso es fijarse en los manuales técnicos del lenguaje específico (preferentemente los provistos por el fabricante, no manuales o libros de otras fuentes, que aún cuando pueden ser muy confiables, no crean compromiso del fabricante con el cliente). Si los formatos de fecha son c/ 2k, el próximo paso será revisar la codificación de los programas; de lo contrario, habrá que cambiar a una versión c/2k y migrar la aplicación, con la correspondiente modificación de programas.
Assembler (Microsoft MASM 4, 6 y anteriores): son lenguajes de bajo nivel, en los cuales el programador puede idear cualquier formato o rutina, por lo cual deben revisarse íntegramente línea por línea.
C, Turbo C, C++, Pro C: la posibilidad de usar tanto rutinas estándar como propias obliga a un nivel de revisión similar al del punto anterior. Herramientas para C y C++:
– Change Master: análisis de impacto, análisis a nivel de programa, edición de código y testeo automático de reestructuración.
– SuperVisor: análisis de impacto, administración de proyecto, análisis a nivel de programa, edición y reestructuración de código, generación de código y prueba automatizada.
COBOL: el COBOL merece párrafo aparte por varias razones. A pesar de su antigüedad (las primeras versiones de idearon en 1959 y la mayoría de las versiones se basan en el COBOL ANS de 1968), nada menos que el 65% de los datos procesados en el mundo están en este lenguaje. En general, la programación es antigua y, casi sin excepción, requiere conversiones totales de fechas, cuando no de sistema operativo. Algunas herramientas:
- Abstract/Probe: análisis a nivel de programa
- Analizador Janus: análisis de impacto, generación diccionario de datos
- ACT 2000: análisis de impacto, análisis a nivel programa, edición y regeneración de código
- CAL/400: análisis de impacto, administración de proyectos, edición y reestructuración de código
- TCS Year 2000 Conversion Tools: análisis de impacto, administración de proyecto, análisis de programas, edición, reestructuración y generación de código, pruebas automatizadas
- SmartBridge: crea un puente entre archivo y programas, usa técnicas de compresión, expansión y selección, soporta 22 formatos de fechas. Puede utilizarse sobre sistema operativo MVS con versiones OS/VS COBOL, COBOL II, y COBOL 370. Métodos de acceso soportados: VSAM, QSAM, BDAM, IMS, ADABAS, DATACOM y archivos planos. Monitor de transacciones CICS
Fortran IV: el manejo numérico que permite el Fortran es grande, y la variedad de rutinas existentes también, pero requiere una revisión completa.
Basic, Basic2, True Basic, Quick Basic: la variedad es amplia y conviene revisarla extensamente. Por suerte, en estos lenguajes frecuentemente se utilizan rutinas centralizadas de fechas accedidas desde varios módulos, lo cual facilita la detección y corrección.
Visual Basic de 16 bits en conversión implícita utiliza una ventana lógica de operación correcta de 1900 a 1999. Visual Basic de 32 bits utiliza funciones del Sistema Operativo (WIN 32) para una ventana 1930'2029.
Clipper Autumn 85, Summer 87, 5.0,5.2,5.3: con la sentencia SetCenturyON, y el uso de las rutinas internas, Clipper reconoce perfectamente desde 01/01/100 hasta 31/12/2999. Clipper en todas sus versiones mencionadas soporta formatos de año en 4 dígitos, no obstante la gran mayoría de los programas existentes en el mercado, sólo usan 2 dígitos y habrá bastante trabajo de corrección
Informix: todas las versiones de Informix soportan 4 dígitos, las funciones date y date() retornan valores desde 1 a 9999 para el año. Para todas las rutinas internas de cálculo de bisiestos, diferencias de días, meses y años, toma como fecha inicial el 31 de diciembre de 1899, con lo cual todos los programas si utilizan las rutinas internas de fechas funcionarán correctamente. No obstante el sistema permite usar fechas abreviadas, con lo cual si hay rutinas definidas por el programador, habrá que revisar.
Sybase: la versión System 11 tiene soporte de fechas desde 1 de enero de 1753 hasta el 31 de diciembre de 9999. Tiene ya incorporado windowing, y cuando lee fechas con dos dígitos para el año interpreta 19XX para años mayores o iguales a 50 y 20XX para menores a 50. Por fecha default toma 1 de enero de 1900. Se deben tomar idénticas precauciones que las antedichas para Informix.
Oracle: recién es compatible a partir de las versiones 7.x en adelante, de igual manera como en el caso anterior, para las versiones nuevas habrá que verificar el código programado. En la versión 7, el formato normal de fecha es DD-MMM-AA por ejemplo 22 de Julio de 1998 será 22-JUL-98. Hay una opción: sysdate, 'yyy' con lo cual se usan tres dígitos, que para el caso del 2000 tampoco son suficientes. Para los productos asociados Designer 2000, Developer 2000 se deben revisar todos los diseños para verificar compatibilidad. Herramienta:
-Unravel 2000: análisis de impacto, analizador de estructuras lógicas y físicas, analizador de comunicación de datos, analizador de datos locales, editor de conversión, biblioteca de utilitarios. Para versiones 2.3 a 3 de Oracle Forms.
El acceso de datos de otro sistema
Con respecto al Y2K hay quienes ya han adherido a la importancia del caso y se encuentran trabajando y quienes, por diversas razones, no lo consideran crítico y urgente (o no tienen forma de insertarlo en sus proyectos) y están en problemas.
Si al estado actual de la solución en las empresas le aplicamos un sencillo análisis, sólo de sentido común, podremos ver que aunque quienes no lo han hecho hasta ahora comenzarán a reparar el problema mañana, o iniciarán raudas reingenierías para reemplazar totalmente sus sistemas afectados, no existe modo alguno de que todas las empresas, organizaciones y establecimientos logren en su conjunto resolver el problema antes del 1 de enero del 2000.
Todos los recursos de programadores, más todas las herramientas de análisis automático y todas las metodologías, con todos los expertos disponibles, con todas las alternativas de reemplazos de sistemas no pueden cubrir todo el trabajo y todos los sistemas a corregir ni en 1999, ni en el 2000, ni aún siquiera en el 2002.
También resulta claro que la trama de interrelaciones de los sistemas de las empresas hace que el problema no sea sólo de algunas empresas aisladas, sino que tarde o temprano, cotidiana o esporádicamente, las que solucionaron el problema tendrán que interactuar con otras que no lo hicieron y los efectos secundarios de un proveedor que no haya solucionado el problema tendrán expansiones muy altas y, en el mismo sentido, los efectos en los sistemas gubernamentales pueden llegar a niveles de catástrofe.
En conclusión, existen entidades públicas y privadas que no han solucionado el problema, ni terminarán de hacerlo a tiempo. El impacto de esta "no solución a tiempo" será menor cuanto más empresas corrijan su problema. Pero, debido a la alta dependencia del intercambio de datos, el efecto global será cercano a una ausencia de solución.
Ante esta situación, la única posibilidad de poder seguir operando más allá del 2000 sin un sistemas corregido (o completamente corregido) es por medio de un "plan de contingencia", o sea la ejecución; de un grupo de contramedidas que permitan que los sistemas sigan operando luego de ocurridas las condiciones de falla. En este concepto y planificación se encuentra trabajando el Grupo de Investigación en Seguridad y Virus Informático de la Facultad de Tecnología Informática de la Universidad de Belgrano, como planteo de investigación desde 1997.
Este proyecto no calcula los problemas con objeto estadístico, sino que enfoca el trabajo en poder listarlos para, como contrapartida, poder enumerar acciones para enfrentarlos, anular sus efectos o minimizarlos al máximo posible. Naturalmente, este plan abarca a la estructura de sistemas argentinos en términos masivos y genéricos, pero debería formularse como un primer acercamiento para un necesario programa de confrontación a un problema que resulta indiscutible. En el mismo sentido, pero en términos "micro", las empresas que hayan tomado las acciones necesarias para eliminar el problema en sus sistemas, que hayan instrumentado medidas de resguardo legales (como hacerles firmar y asegurar la compatibilidad con el año 2000 a sus proveedores de todo tipo), o hayan renovado todos sus sistemas, deberían implementar planes de contingencia especiales que previeran las posibles consecuencias y acciones a tomar contra los efectos colaterales del problema en el resto de la sociedad comercial y en particular con las empresas que interactúan.
Los costos a corto, mediano y largo plazo de estas soluciones
La prensa especializada, publicaciones en Internet, conferencias y prácticamente cualquier medio o evento que se refiera al tema del año 2000 y en particular sobre sus costos, han difundido estimaciones del mismo en frases que, si bien difieren en los valores de costo, poseen una estructura similar a la que sigue: "A partir de las experiencias actuales de conversión se ha podido determinar que el costo de reparación varia entre U$S 1,10 y U$S 1,80 por línea de código COBOL, siendo aún mayor para programas escritos en ASSEMBLER".
Expresiones como esta, antes de ser utilizadas o dadas por ciertas, requieren un cuidadoso entendimiento y análisis de todos los aspectos que están involucrados en la determinación de los costos mencionados. El objetivo de estos artículos es justamente intentar clarificar la visión de los mismos. El primer punto que requiere aclaración es la generalizada utilización de la cantidad de líneas de código para estimar los costos de conversión.
La cantidad de líneas de código es simplemente una variable que ha demostrado estar relacionada, en el promedio de los organismos, con el esfuerzo requerido para efectuar la conversión, a mayor cantidad de líneas de código existe una mayor cantidad de líneas a revisar, alta probabilidad de encontrar líneas que deban ser corregidas, una cantidad importante de archivos y lenguaje de control como así también, mayor volumen de pruebas a realizar. Si bien la cantidad de líneas de código y el lenguaje en que están escritas son variables que entran en juego, existen muchas otras que están relacionadas con el esfuerzo y por ende influyen sobre el costo para la adecuación del año 2000.
Una de las variables más importantes es la técnica que se siga para la conversión es decir, si es necesario expandir los datos y modificar los programas o pueden utilizar técnicas de "ventanas de fechas" que permiten mantener inalterados los datos requiriendo sólo la modificación de los programas. Este factor modifica de tal manera la complejidad y el esfuerzo requerido que varios consultores recomiendan que, de utilizar "ventanas de fecha" para estimar los costos totales de adecuación se considere sólo entre el 40 y el 60 por ciento del total de líneas de código.
Por otra parte las líneas de código que afectan el esfuerzo de conversión no son todas las que, en muchos casos, reposan en las bibliotecas de programas fuente, sino sólo aquellas que corresponden a programas que realmente se ejecutan. Las que son reusadas en numerosos programas (tales como los "copys", rutinas insertas en los programas, etc.) deberían ser contadas una sola vez. Estas consideraciones sobre la relatividad de la cantidad de líneas de código como elemento para medir el esfuerzo de conversión no invalida su utilización, con los resguardos correspondientes, como factor indicativo del costo total del proceso.
El segundo punto que está incluido en frases como las que encabezan este artículo es el del costo por línea de código. El valor que se menciona en casi todas las estimaciones es el costo total que la empresa u organismo debe considerar que tendrá todo el proceso de adecuación. Vale la pena recalcar dos palabras: COSTO TOTAL y analizar que elementos contribuyen a él. Para hacer esto es necesario tener en cuenta las distintas etapas que se requiere seguir en el proceso de adecuación, a grandes rasgos son:
- Tareas de Inventario. Identificación del Hardware y Software de Base que no es compatible y su solución: Esta es una tarea que debe ser encarada por personal del organismo y requiere consultas e interacción con los proveedores del mismo y su eventual reemplazo
- Inventario de programas, archivos, lenguaje de control. En esta tarea, si bien las herramientas o los servicios de los proveedores externos, pueden ser de utilidad, el principal peso recae sobre el personal del organismo
- Tareas de Análisis de Impacto. Identificación de los campos de fechas en los archivos y su rango de validez, con el fin de determinar la posible utilización de la técnica de ventana o codificación. Esta es una tarea en la que prácticamente la totalidad del esfuerzo debe ser realizado por los analistas o usuarios del sistema ya que son los que están en condiciones de realizarla más eficientemente.
- Definición de patrones de fecha y determinación de su ubicación en los programas. Esta es una tarea en la que, de existir un proveedor externo, debe trabajar en estrecho contacto con el personal del organismo; los analistas del organismo identifican los patrones iniciales de fecha, el proveedor utiliza las herramientas para identificar y ubicar los mismos y su propagación (campos relacionados con los mismos que también contienen fechas) y requiere nuevamente de una cuidadosa revisión de los analistas del organismo para determinar efectivamente cuáles deben ser incluidas en el proceso de corrección y cuáles no. Tan importante es la participación del personal del organismo en esta tarea que la experiencia demuestra que el ritmo de avance en esta etapa, generalmente conocida cómo análisis de impacto, está dado por la velocidad con la que se realizan estas revisiones, ya que las herramientas entregan en poco tiempo, gran cantidad de material que debe luego ser analizado.
- Realización de las correcciones, documentación de las mismas y pruebas unitarias. Esta si, es una tarea que, una vez identificados los puntos de corrección, puede ser encomendada a proveedores externos, siendo de cualquier manera necesaria y conveniente la participación de analistas del organismo en la definición de las rutinas a utilizar para manejo de ventana y operaciones relacionadas con fechas a fin de asegurar su adecuación al organismo y para conservar el conocimiento sobre las aplicaciones que permita su posterior mantenimiento. De la misma forma es necesario que se realice una revisión de la documentación provista por el proveedor.
- Pruebas de Aplicación y de Sistemas. En esta tarea, sólo los analistas de la instalación están en condiciones de definir los casos de prueba necesarios, la preparación del entorno y la verificación de los resultados, ya sea que las pruebas en sí las realice personal del organismo o del proveedor. La tarea que necesariamente debe realizar el proveedor, como parte de la garantía de su trabajo es la de efectuar las correcciones necesarias ante fallas que se presenten en esta etapa.
- Implementación. Esta es fundamentalmente una tarea a realizar por personal del organismo. Todas las estimaciones sobre los esfuerzos relacionados con la concreción de estas tareas, incluyendo el Gartner Group, indican que no menos del 50 al 60% del esfuerzo total, se destina a la Realización de las pruebas. Por otra parte se estima que el gerenciamiento del proyecto, tarea que no puede ser delegada por el organismo, incrementa en un 15 % el costo (esto incluye también el gerenciamiento propio del proveedor).También queda claro que en el restante 40 ó 50% del esfuerzo total, es sumamente importante la contribución del personal del organismo (la adecuación es siempre una tarea conjunta).
Conclusiones sobre costos asociados con la adecuación año 2000
Hay que tener en cuenta que, de los costos totales por línea de código que se difunden, cuando se consideran los asociados con el proveedor externo, los mismos deberían encontrarse entre el 20 y el 30 % de los costos totales. Esta variación depende del grado de participación del mismo en el proceso.
Estos valores coinciden, aproximadamente, con los encontrados en empresas que proveen servicios de adecuación en Buenos Aires. La mayoría cotiza por debajo de $0,50 por línea de código analizada y corregida. El resto del costo, debiera ser contemplado sobre los recursos propios del organismo que resultan indispensables en todo este proceso.
El promedio de gasto en la resolución del problema entre las empresas argentinas encuestadas es de 600.000 dólares, aunque hay una importante dispersión.
Un dato muy interesante es que en el 85% de las empresas, los gastos para resolver el problema del año 2000 impactan en el presupuesto del área de sistemas. Esto significa que estas empresas van dejar de hacer inversiones que estaban previstas para el área de sistemas, con la intención de dedicar esos fondos a resolver el problema del año 2000. Por otro lado, hay un 15% de empresas en lasque el presupuesto para la resolución del problema pasa por otro lado que no es el presupuesto del área de sistemas. Por lo general, estas empresas son multinacionales que tienen directivas corporativas e inclusive, en algún caso, recursos corporativos para resolver el problema.
Hay un 30% de empresas que en el presupuesto del 97 ya tienen incluidos parte de los gastos para la resolución del problema, mientras que un 47% recién comienza a gastar este año.
Factores de éxito para solucionar el problema del milenio
Se podrían resumir en la correcta consideración de las especiales características y de los riegos que condicionan la adecuada resolución de los problemas que plantea la llegada del Año 2000.
Más específicamente se concretarían en:
- Concepción del proyecto.
El proyecto de adaptación al Año 2000 debe ser considerado como de vital importancia por todos los miembros de las Administraciones Públicas, pero especialmente por sus estamentos directivos que, asumiéndolo como tal, deben auspiciarlo, aprobar la asignación de recursos y supervisarlo a alto nivel.
La resolución de los problemas a que puede dar lugar la proximidad del Año 2000, es una tarea que deben afrontar principalmente las unidades técnicas responsables de los Sistemas de Información, pero sería un tremendo error pensar que sólo afecta a éstos, ya que además incide de una u otra manera sobre el funcionamiento de toda la organización, entre otras razones por poder precisar una importante dedicación de recursos humanos y financieros, suponer retrasos en la puesta en marcha de nuevas funcionalidades (mantenimiento perfectivo) o cambios en determinados hábitos de trabajo. A su vez, si bien parte de los cambios deberían abordarlos los fabricantes de equipos o los suministradores de los sistemas básicos o de los paquetes, es competencia de los responsables de los Sistemas de Información el tomar las medidas oportunas por si ello no se produjera, así como dirigir y controlar la eventual adecuación de las aplicaciones por empresas externas. Suya es la gestión y responsabilidad operativas del proyecto global, en tanto cuenten con los recursos necesarios.
- Planificación de las soluciones
Es necesaria la determinación precisa de las políticas y criterios a seguir y de los recursos, métodos, técnicas y herramientas a emplear, así como una coordinación y previsión de las actividades a realizar, que optimicen los esfuerzos, añadan valor al proceso en la medida de lo posible, garanticen el cumplimiento de los plazos límite y eviten, subsanen o cuando menos palien las posibles contingencias.
Las principales razones para ello son el alcance de las acciones a realizar, que pueden afectar a la estrategia, el equipamiento, las aplicaciones, el personal, etc., el gran volumen de elementos sobre los que normalmente habrá que incidir, las relaciones de toda índole con terceros y la convivencia con el funcionamiento habitual.
Un caso particular pero de especial importancia es el cuidadoso análisis de las coincidencias y diferencias entre los proyectos de adecuación al Año 2000 y al Euro, con el fin de determinar su grado de unificación.
- Gestión y control de los proyectos
Por los mismos motivos aducidos en el punto anterior, la magnitud de los proyectos a acometer hace que su teórica sencillez técnica en determinados aspectos se vea normalmente superada por su complejidad de ejecución práctica, lo que, unido a la existencia de fechas límite, requiere un esfuerzo singular en cuanto a la dirección, organización, coordinación y supervisión de las actividades a realizar y los recursos a emplear, a lo que habrá que añadir un control estricto de cambios y versiones de los componentes informáticos.
Es obligada la realización de pruebas exhaustivas que garanticen adecuadamente la calidad de los cambios, de forma individual y conjunta, evitando o en todo caso minimizando la aparición y propagación de errores una vez puestos en explotación los sistemas.
El normalmente elevado número de cambios a realizar, la dispersión de estos en diversas aplicaciones, la posible incorporación de nuevos elementos o sustitución de sistemas, la necesidad de cumplir determinados plazos y las negativas consecuencias de caer sobre todo en algunos de los riesgos existentes, justifica sobradamente la necesidad de un mayor esfuerzo en este ámbito.
Es inexcusable la asignación de los medios humanos y materiales precisos, superiores evidentemente a los necesarios para la operación normal, creando equipos multidisciplinares que piloten, apoyen y materialicen los procesos de cambio y adecuación, empleando para ello las herramientas, metodologías y técnicas más adaptadas al problema y a las particularidades de cada instalación concreta. En este sentido hay que tomar conciencia de la excepcionalidad de la situación.
El problema del calendario :
El calendario utilizado actualmente, es el Gregoriano desde 1542. Su particularidad es la de fijar universalmente, por un lado, la contabilidad de los años, y por el otro, las reglas sobre los años bisiestos.
Así, son bisiestos los años cuyo número es divisible por 4, salvo los años seculares (cambio de siglo), a menos, que estos últimos no sean divisibles por 400. Es así como 1900, no fue bisiesto, en tanto que el año 2000, será bisiesto: habrá un 29 de febrero 2000. Los sistemas informáticos, y electrónicos, tendrán que encontrar esta fecha, sin error….
Las consecuencias del paso al Año 2000, sobre los cálculos :
Al hacer algunos ejercicios de cálculo con las fechas, uno toma realmente, consciencia de la situación:
Por ejemplo, al clasificar las fechas: 01/01/00 es anterior al 31/12/99, puesto que 00<99. Esto quiere decir, que ya no se pueden calcular correctamente ni las duraciones, ni los plazos, ni tampoco organizar, ni clasificar.
Los siguientes ejemplos, muestran las situaciones encontradas, o probadas :
Supongamos que una máquina trata las fechas sobre 6 posiciones (Días/Meses/Años), que la última visita de mantenimiento, se efectuó en diciembre del 99, y que, estemos en enero del 00. Si la fecha de la última visita de mantenimiento de esta máquina (ondulador, nevera, aire acondicionado, maquinaria, ascensor, etc…) se compara con la fecha del día, el automatismo de control del mantenimiento, va a deducir que la máquina no se ha revisado desde hace muchos años (00-99). Entonces, el automatismo va a colocarla inmediatamente en seguridad.
Así, la máquina podrá pararse, abrirse,… y, pero ya no podrá funcionar normalmente. Esto se pudo verificar durante los tests. En general, las máquinas utilizan lenguajes de "bajo nivel" (tipo assembleur). El paso al año 2000, puede provocar un sobrepaso del contador (99+1 = 100, sea 00, a más de un bit de reserva). La máquina puede bloquearse con "error". Este caso se produjo durante los tests.
Los ficheros hechos en el 97, cuyas grabaciones deben conservarse 3 años, se pueden destruir, apenas hechos, sin que se haya constatado ningún disfuncionamiento. En efecto, 97 + 3 = 00. Como 00 es inferior al año en curso (97), se puede reutilizar el espacio, puesto que los ficheros son obsoletos. Este caso ya se dió. Peor aún, algunos programas viejos, utilizaron el código 99, como sinónimo de anomalía. Este aspecto hay que tenerlo en cuenta, sobretodo que no hay mucho tiempo para corregir estos sistemas.
Los cálculos de intereses, de fecha de entrega del material, de anotaciones contables, los archivos de la empresa, los sistemas de apertura de las cajas fuertes,…todo lo que es importante para su actividad, o para la empresa, debe verificarse, y eventualmente controlarse.
En comparación con los proyectos clásicos, los proyectos Año 2000, tienen algunas características evidentes, pero que vale la pena, revisar :
No se puede aplazar el término. Aunque no tenga mucha importancia, vale la pena anotar el hecho, que es la primera vez, que las empresas, y los informáticos se ven confrontados a una fecha límite, ante la cual no hay nada que hacer.
Las correcciones pueden ser muy costosas, y la recuperación de esta inversión es improbable. Sólo resta a esperar, que con este paso al año 2000, los rivales tengan muchos más problemas…
El enemigo número 1 es el tiempo. Cada día que pasa, es un día perdido, que no puede recuperarse. El año 2000, realmente es una carrera contra el reloj.
El 1o. de enero 2000 es un sábado, lo que deja un día más (el domingo), para los eventuales defectos (pequeños).
El año 2000 llega… en el año 2000 (!), lo cual puede erigirse en un obstáculo, para que este asunto sea tratado, dado que las personas responsables pueden bloquearlo, con su jubilación antes de la fecha fatídica, y dejándolo en "espera" demasiado tiempo.
Dada la situación, hay que prever, el solicitar a los empleados que se queden todo el día J. Es probable, que ese día, hayan pensado venir a trabajar….
El año 2000 es bisiesto: hay pasar el año 2000, y … el 29 de febrero 2000 !
Es muy difícil presentar el Problema Año 2000, a la dirección de su empresa :
Vulgarizar el problema, es ridiculizarlo.
Es una inversión que no produce nada.
Hay que hacerlo cuanto antes.
De vez en cuando, a causa de la falta de recursos, hay que parar, o aplazar, los proyectos importantes de la empresa,
Casi todas las funciones de la empresa, están afectadas de una u otra manera, por el proyecto Año 2000:
La dirección general,
La informática (responsable de la informática, responsable de los estudios, responsable del sistema, responsable de las telecomunicaciones y de las redes) Los responsables operacionales, y los directores de división (responsable de función, responsable de los recursos generales, Director de Personal) La dirección financiera, jurídica, de seguros, contabilidad, auditoría, auditor Etc…
Lo que está en juego. Lo que está en juego para su empresa, o según su actividad, es muy importante. En orden de importancia :
Eventos puramente internos y calitativos, por ejemplo, los problemas de ergonomía, o de
confort, al nivel de las pantallas de escritura, y de los estados imprimidos, Eventos más importantes, que se traducen por una pérdida de la calidad evidente, de la parte de los usuarios, de su actividad, o de sus clientes: por ejemplo, retardos, o errores en los bonos de pedidos, o de entregas, de las fechas de almacenaje erróneas, de los resultados de laboratorio mal archivados, etc. … Problemas más importantes de continuidad de la actividad. El año 2000 puede bloquear durante mucho tiempo sus sistemas. Si este término es importante, tendrá que poner en obra, en un momento dado, una situación de crisis de los sistemas de remplazo: por ejemplo, una contabilidad parcialmente manual, un pago de los proveedores, totalmente manual, etc… En fin, pero no hay que olvidar que se trata del mayor de los riesgos, puede haber perturbaciones importantes y masivas, al interior de las informaciones. A tal punto, que usted no podrá volver a considerarlas como fiables: por ejemplo, una gestión de reservas completamente contaminada por las fechas de entrega falsas, los montos de facturación completamente erróneas, y los archivos, y las grabaciones perdidos.
Esto quiere decir que hay que efectuar varias verificaciones del sistema de información, así como de los sistemas industriales, y de los sistemas electrónicos en general. Estas verificaciones deben llevar a la elaboración de un plan de acción minucioso, para constatar que lo esencial se preservó.
La supervivencia de su empresa, depende del hecho de tomar en cuenta el problema del año 2000. Dado que el tiempo está en su contra, usted no puede descuidar este problema
!
Las soluciones del problema:
Son de 3 tipos :
la adaptación de la máquina, del material, o del programa el remplazo de la máquina, del material, o del programa no se hace nada, dado que el disfuncionamiento no es crítico.
Hay varias estrategias posibles, si usted decide modificar los programas, ya que diversas estrategias de conversión de fechas son posibles. Su empresa debe escoger, en función de los elementos determinados, y de sus opciones estratégicas. No existe ninguna regla universal aplicable.
La acción :
La solución de la crisis año 2000, consiste en una optimización del tiempo que queda, hasta el paso efectivo al 01/01/2000, o de su horizonte crítico. Por esto es indispensable el tener una organización, y una planificación rigurosas.
Cualquiera que sea su sector, la estrategia que hay que desarrollar, comprende 6 etapas principales :
sacar el proyecto de empresa, y de prevención que incluye, entre otras cosas, la problemática: (con la ayuda del CD-ROM MARJORI 2000); la sensibilización de los decidores (utilizando un modelo de carta, así que de transparencias de formato PowerPoint (versión 4.0, o 95). los inventarios (máquinas, materiales, programas, aspectos jurídicos) definición de los planes de acciones. Ejecución de los planes de acciones (modificaciones, remplazo), y de los tests instalación vigilancia, plan de crisis del 31 de diciembre de 1999, 29 de febrero 2000
Bibliografía:
- Soluciones Informáticas para el año 2000 – Martín Peisojovich – CompuMagazine
- Revista CompuMagazine – Año XI – Nº 116 – "Cuenta regresiva" – Marzo de 1998
- Revista CompuMagazine – Año XI – Nº 118 – "Poder CIO" – Mayo de 1998
- Revista CompuMagazine – Año XI – Nº 122- "Sultanes del Outsourcing" – Setiembre de 1998
- Revista CompuMagazine – Año XI – Nº 123 – "Sistemas a la Carta" – Octubre de 1998
- http://www.unlu.edu.ar/~varios/juridico.htm
- http://www.unlu.edu.ar/~varios/informat.htm
- http://www.unlu.edu.ar/~varios/quecomo.htm
- http://www.unlu.edu.ar/~varios/solparc.htm
- http://pita.microfocus.com/mfspain/2maldit.htm
- http://www.unlu.edu.ar/~varios/crisis.htm
- http://www.unlu.edu.ar/~varios/soldefin.htm
- http://www.unlu.edu.ar/~varios/biblio.htm
- http://arc.org.tw/USIA/www.usia.gov/topical/global/y2k/sp980707.htm
- http://arc.org.tw/USIA/www.usia.gov/topical/global/y2k/sp980902.htm
- http://www.itpolicy.gsa.gov/mks/yr2000/y2kconf/papers/paper58fp.htm
- http://pita.microfocus.com/mfspain/mkt_y2k.htm
- http://w3.sistelcom.com/usr/ppatronl/Efecto2000.htm
- http://www.unlu.edu.ar/~varios/socioeco.htm
- http://www.onnet.es/07001.htm
- http://www.unica.edu.ni/2k.html
- http://www.map.es/csi/pg8002.htm
Autor:
Justo Mendez Aleman