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