Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98

Llevamos ya un par de años escuchando susurros sobre el tan sabido "Defecto 2000". Estos susurros se han convertido en voces a lo largo del ultimo semestre y parece que quieren convertirse en gritos.

¿Que hay, o puede haber de cierto en esto?. Vamos a intentar separar un poco los intereses creados de la realidad. No sé si esto va a ser posible.

Mis ancestros gallegos todavía me hacen preguntarme ¿y por qué?. Es decir ¿por qué me haces esta pregunta?. Salen a flote las viejas suspicacias cuando me hacen una pregunta del por qué me la hacen. Aquí estamos en un caso similar. No hay pregunta, hay una realidad (!?) pero ¿y por qué? ¿y por qué parece que todo el mundo está interesado?. ¿y a quien beneficia?

Seamos un poco realistas, vamos a distinguir dos posibles mundos totalmente diferentes y que pudieran verse afectados por este "defecto" (es más significativa la palabra "defecto" a "efecto"). Los dos posibles entornos que parecen idénticos pero que bajo mi punto de vista son absolutamente diferentes son:

1) Programación "pura".

2) Sistemas empotrados.

Vamos a verlos despacito y vamos a ver sus posibles repercusiones. Fijémonos que el "único" problema es en el tratamiento de fechas. Distingamos ahora que posibles errores pueden cometerse en el tratamiento de las fechas:

1) Viejos sistemas de almacenamiento de la informacion, en donde "primaba" el ahorro de espacio y el año de las fechas se guardaba en dos posiciones.

2) Rutinas de calculo que no consideren bisitesto el año 2000. Es perfectamente posible, ya que la definicion de bisiesto es: un año es bisiesto si es divisible por 4, excepto los centenarios, los cuales para ser bisiestos deben ser divisibles por 400. Por tanto 1900 no fue bisiesto (centenario) pero el 2000 sí lo será (centenario pero divisible por 400).

3) Sistemas en tiempo real, en los cuales se toma la fecha a partir de un "chip" o circuito temporizador ("sistemas empotrados"). Estos sistemas pueden tener o nó una programacion y por tanto pueden tener programas "empotrados" grabados de fabrica en memoria ROM (solo lectura).

* No existen otras posiblidades. Por tanto creo que podemos diferenciar claramente entre "programacion" y "sistemas empotrados". Es verdad que casi toda la programacion en algun momento se basa en un "sistema empotrado". Por ejemplo la fecha del sistema. Esta fecha se alimenta de algun circuito de reloj y posteriormente se grabará en nuestros registros de operaciones.

Vamos a obviar por ahora esta "fecha del sistema". Centremonos unicamente en la programacion de aplicaciones de alto nivel suponiendo que la fecha del sistema es correcta.

P1. ¿Existe algun riesgo de malfuncionamiento?

P2. ¿Que repercusiones tendría un posible error y su rapidez en subsanarlo?

P3. ¿Quienes pueden estar interesados en "maximizar" el error?

R1. Evidentemente el riesgo existe siempre. Pero vamos a minimizarlo un poco. La vida media de una aplicacion operativa o de gestión es de 7 años. Por tanto podemos asumir que un porcentaje muy elevado de las aplicaciones actuales, están por diseño preparadas para el año 2000. Nadie en los analisis de aplicaciones guarda ya desde hace mucho tiempo el año en 2 posiciones. Puede que por costumbre, an algunos listados, documentos, etc, unicamente se "muestren" las dos ultimas posiciones, pero internamente el "dato" tiene las 4 posiciones del año.

Hay un ejemplo bastante evidente: muchas de las aplicaciones de gestion ya están realizando calculos para más alla del año 2000 sin problemas. Pensemos por ejemplo en los calculos de un prestamo, de una inversión en Activos Financieros, de una proyeccion de valores futuros, etc. No hay fallos en estas aplicaciones.

Pudiera haber algun problema real de programacion al no tener presente que el año 2000 será bisiesto, pero realmente el problema no afectaría mas que al calculo de dias entre dos fechas que comprendan al 29 de Febrero del 2000. Este problema en principio debe ser minimo y diagnosticable facilmente desde las aplicaciones que ya están trabajando con fechas superiores al 2000.

R2. ¿Repercusiones del error?. A nivel de programacion de alto nivel, entiendo que serían minimas. Los profesionales de la informatica, por desgracia, estamos acostumbrados a errores. Somos humanos y es facilisimo al modificar en cualquier momento una aplicacion el equivocarnos. Y además pensemos que el 20% de una aplicacion es el desarrollo y el 80% mantenimiento por tanto estos errorese sucederán. Simplemente se corrige y además su correccion en el 99% de los casos es en el día y sin que el usuario final note dicho error. En este nivel estoy hablando por "mi" experiencia, creo que es una experiencia válida: un entorno en una gran Entidad Bancaria con miles de procesos diarios y millones de lineas de programacion. Evidentemente hay errores: se detectan y subsanan en el dia. Un posible error del "defecto" 2000, no sería mas que uno más de los que nos pueden suceder en cualquier momento.

R3. ¿intereses creados?. Muchisimos. Fundamentalmente existen dos colectivos totalmente interesados.

Por una parte las empresas que han surgido con sus programas de analisis de impacto y sus grupos de especialistas. Y por otra parte las empresas de servicios informaticos que nos "brindan" ayuda como alquiler de grupos de programacion para revisar codigo de programas.

En España, las Empresas de Servicios Informaticos han crecido en los dos ultimos años por encima de un 400%. Ha existido (y todavia contiúa) un factor en Europa que explica este crecimiento. La conversión al Euro. Pero el otro gran factor, responsable al menos de la mitad de ese crecimiento es el "Efecto 2000". Actualmente existe una demanda altisima de personal informatico no cualificado. Un par de cursillos y a verificar como "experto" en los temas del año 2000.

Por otra parte las Empresas de Analisis de Impacto, están haciendo su "agosto". Programas que analizan miles de referencias cruzadas a campos de tipo "fecha" en los programas. Miles de horas "revisando" (normalmente mediante sub-contratacion a las empresas de servicios anteriores), toda la programacion. "Bugs" reales pillados: nulos, minimos o sin importancia. Pero eso sí: los responsables dormirán tranquilos. Han conseguido su "certificacion".

Igualmente se subcontratan y alquilan equipos de ordenadores identicos, se trasvasan los datos reales a ellos y se "envejecen" mediante programas al efecto. Se les situa como fecha del sistema en el año 2000 y se repiten simulaciones (que de sobra sabemos que saldrán bien) para evaluar riesgos. Otra "inversion" más.

Pasemos al tema más serio: SISTEMAS EMPOTRADOS.

Hemos partido de la premisa que la "fecha del sistema" es correcta. Recordemos que en los grandes sistemas, cada dispositivo puede que lleve sus circuitos especiales de fechas.

Evidentemente aquí puede existir un problemas serio. Descompongamos a su ves el problema en dos entornos.

1) Sistemas de calculo y gestion. Mainframes y Ordenadores personales.

2) Sistema industriales.

En el entorno 1), el problema no es tan grave. Los grandes fabricantes de ordenadores, ya han revisado sus "circuitos" y han certificado tanto sus equipos como sistemas operativos. Los pequeños fabricantes (mundo de los PCs) ni lo han hecho, ni lo harán. Pero para intentar paliar estos efectos, los sistemas operativos actuales están intentando subsanar mediante programacion a alto nivel, el posible efecto de un chip erroneo. Igualmente muchas de las BIOS de los PCs se estan reprogramando a tal efecto. No es preocupante este problema.

Curiosamente tampoco preocupa mucho el tema de los ordenadores personales a las empresas que hemos citado anteriormente. Simplemente porque no hay dinero por el medio. El usuario final no va a pagar por estos cambios.

* El tema realmente preocupante y que en efecto no "veo" que se hayan tomado medidas excepto en muy pocos colectivos, son los Sistemas Industriales". Generalicemos estos sistemas como "Sistemas Empotrados" y consideremos a la industria tambien a grandes colectivos: Aviacion, Comunicaciones etc.

Dentro de estos colectivos, existen circuitos de temporizacion de hace mas de 20 años. Y por fabricantes diversos. Estos son totalmente susceptibles de sufrir el "virus" del 2000.

¿Medidas adoptadas en estos casos? Pocas. En algunos casos como por ejemplo la Aviacion, se estan tomando mas medidas de "precaucion" que reales. Se están consiguiendoi certificaciones de algunos fabricantes de componentes. Pero nadie se atreve a certificar en su conjunto un avion. Además la programacion de muchos de estos sistemas, es un programacion de hace 20 años y ademas, programacion "empotrada". Es decir programacion dentro de "chips" no manipulables (y además del año de "la tana"). Igualmente la mayoria de los programas del trafico aereo es programacion tambien empotrada. ¿quie puede revisar esto?.

Las medidas a adaptar en estos casos, al igual que en la mayoria de la industria son medidas de "precaucion". Por ejemplo: no volar el 1 de Enero del 2000, y revisar por parte de los responsables que pasaría en este caso.

Igualmente es preocupante dentro de estos sistemas, los sistemas de comunicacion. Tambien pueden verse afectados.

¿Por qué no se adoptan las gigantescas medidas que vemos en los entornos de programacion "pura"? Simplemente porque no se sabe que hacer para prevenir o probar en "real" en los sistemas empotrados.

* En programacion "pura" este es el chocolate del loro: La Estafa del 2000.

.....pero un responsable de sistemas informaticos, no puede correr el riesgo de que "no le estafen". Es preferible "pagar" ese impuesto a que la minima incidencia (que sucederá de todas formas) le haga temblar en su puesto. Por tanto sí que hay un respuesta al por qué inicial: hay que pagar dicho "impuesto".

Volver a Artículos y FAQs

© 1997-2009 Duiops (http://www.duiops.net)
Prohibida la reproducción parcial o total de los textos o las imágenes

Para comentarios, usa las direcciones e-mail de contacto.