Monografias.com > Computación > General
Descargar Imprimir Comentar Ver trabajos relacionados

El problema del año 2.000




Enviado por al264705



    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.

    Nace un
    error

    ¿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.

    Causas del
    Problema

    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.

    Posibles
    problemas

    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.

    Características
    principales

    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:

    Coexistencia con el
    día a día

    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.

    Coincidencia con el
    Euro

    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.

    Coste económico
    elevado

    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.

    Plazos de
    conversión largos

    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.

    Complejidad
    operativa

    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 problema en
      Estados
      Unidos de América.

    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:

    1. 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;
    2. Evaluar el efecto de los esfuerzos del
      año 2000 en los planes estratégicos y operativos
      del banco;
    3. 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;
    4. Evaluar la suficiencia de controles internos
      para el proceso del
      año 2000; e
    5. 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.

    • El problema del
      año 2000 en México

    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.

    • Nota del
      Gobierno Britanico sobre el Efecto del
      2000

    INTRODUCCIÓN

    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.

    ANTECEDENTES
    TÉCNICOS

    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).

    Suministro
    eléctrico

    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.

    Telecomunicaciones

    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.

    Transporte

    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.

    Salud
    Pública

    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.

    Abastecimiento de
    alimentos

    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.

    SOLUCIONES

    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.

    • Otros efectos
      del cambio de siglo

    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.

    • Informático

    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.

    • 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".

    Mi software ya no
    funciona

    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

    1. 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.

    2. 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.

    3. Garantía
      relativa al problema informático del año 2000 en
      las órdenes de compra
    4. 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

    1. 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.

    • Socio-Economico

    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:

    1. empresas productoras y comercializadoras de
      productos
      relacionados con la medicina;
    2. sociedades
      científicas;
    3. establecimientos sanitarios;
    4. profesionales; y
    5. 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:

    1. 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.
    2. En el rango de fechas definido, deberá
      manipular y representar en forma unívoca las fechas, en
      relación con el calendario
      especificado.
    3. Todas las operaciones que
      realice con las mismas y sus resultados, deberán ser
      correctas y conservar la misma relación
      unívoca.
    4. 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".

    Riesgos del bug del
    año 2000

    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.

    Contingencias

    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.

    Interacción
    entre proyectos

    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.

    Suministradores
    externos

    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.

    Transferencias de
    información

    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.

    Soluciones
    Parciales

    ¿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.

    Soluciones
    Definitivas

    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.

    • Pruebas de los
      cambios

    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.

    • Selección
      y dotación de recursos

    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.

    • Algunas
      evidencias.

    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:

     

     

    Autor:

    Justo Mendez Aleman

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter