Lista de problemas vinculados al año 2000

	Sign In Sign-Up

Propósito de este documento:

La información que sigue es un intento de organizar la creciente lista de los inconvenientes asociados al año 2000. Nos ayudará a estimar la magnitud del problema que tenemos por delante, planificar el proyecto, especificando los requerimientos de herramientas necesarias y prevenir los problemas ocultos mediante la realización de las pruebas correspondientes con anticipación.

Ordenar el caos: pero como?

Fue difícil decidir una estructura lógica para todos los problemas encontrados. Debería organizarlo por la profesión de la persona que aborda el tema? Por el objeto donde se presenta el problema? Por el tipo de programa? Todas estas propuestas son razonables. El resultado corresponde a lo que fue lo mas intuitivo para mí. Reconozco que no se trata de una propiedad científica pero para mí funciona. He creado una estructura de árbol con las siguientes ramas principales:

•Organización y Sociedad

•Hardware y Sistemas operativos

•Estructura de Datos

•Software de aplicación

•Interfaces

•Análisis

•Cambios

•Validación

Compilación de temas Año 2000 (versión 2.0)

Esta lista es una compilación de problemas (y a veces soluciones) mencionadas en la literatura en el YEAR2000 Internet forum. He eliminado algunos elementos que se repiten y otros que son demasiado técnicos para que yo los pueda tratar correctamente. El árbol es una estructura dinámica que nunca se termina. Cualquier comentario será bienvenido.

Los números indican la estructura del árbol (por cuestiones referenciales). En cualquier nivel el orden es al azar para permitir los agregados sin necesidad de modificar la numeración.

1 Organización y Sociedad

Este aspecto está muy poco documentado en comparación con la parte técnica En parte porque este ítem depende mucho de la organización. Sin embargo, Micro Focus ha presentado muy buen material al respecto en la conferencia de Usuarios (19 de mayo de1995.)

1.1 Problemas entre semejantes

1.1.1 El problema del misil

Ud. arregla todos los problemas internamente. Pero aparece otra organización, con la cual Ud. no tiene nada que ver, con problemas. (podría ser un proveedor externo que cambie sus aplicaciones ).

1.1.2 Empresas relacionadas se equivocan

Que sucederá cuando los proveedores no puedan entregar porque su computadora no funciona? Cuando las cosas no son despachadas a sus clientes? Cuando no hay comunicaciones por algunas horas? Piense en el peor escenario..

1.1.3 Problemas importados

Esta es una verdadera amenaza para el manejo de proyectos.

1.2 Acuerdos de Nivel de Servicios

1.2.1 ACSs con proveedores de software.

El problema del año 2000 parte del acuerdo? Quien pagará. Los proveedores estarán mejor posicionados que Ud. en las negociaciones y puede hacer un gran negocio. Asegúrese mediante referencias.

1.2.2 ACSs con el departamento de Sistemas

Esto puede ser serio.

1.3 El problema de la negación

Excusas bien documentadas [De Jager, Micro Focus], por ignorancia, intereses personales. Un problema serio es que Ud. necesita un ejemplo concreto de algún desastre que ya haya ocurrido para que le presten atención; pero aún no ocurren las tragedias. Es como el huevo o la gallina.

1.4 Prioridades

Las grandes organizaciones tienen muy ocupada la agenda de Sistemas. Perder millones demorará otras cosas.

1.5 Centros en retroceso

Ellos tienen los mismos problemas y probablemente menos experiencia.

1.6 El día del juicio final

1.6.1 Sábado

Un alivio para la mayoría de las empresas, pero no para todas, el primero de enero de 2000 es un sábado. Los problemas que se pasaron por alto aparecerán cuando no tenga mucha gente disponible.

1.6.2 El primer día

Durante el primer día del nuevo MILENIO se pueden generar problemas en redes globales debido a los cambios de zonas horarias. Una cuestión difícil: quién es responsable?

1.7 El riesgo de la oportunidad

Bien documentado. Porque no estandarizar formatos de fecha y nombres y … Puede ocurrir que debamos utilizar bases de datos relacionales u OO, que ocurre con las modificaciones de los sistemas actuales combinados? . Cualquier falla y los proyectos quedan fuera de control. (y las fechas de implementación no se pueden mover.)

1.8 Los proveedores de soluciones

1.8.1 Como conseguirlos?

Un año atrás era un problema. Ud. era el primero que preguntó. Ese inconveniente actualmente está resuelto. Las hordas lo contactarán sin que los llame. Elija el mejor. [Gartner] ofrece algunos buenos datos al respecto.

1.8.2 Como mantenerlos alejados?

Ud. lo ha dicho claramente: lo hacemos nosotros con un pequeño grupo de expertos externos. No se sorprenda si ellos contactan a su gerente y lo ridiculizan.

1.8.3 Como mantenerlos afuera después?

Déjelos revisar su software. Por supuesto que no perderán la oportunidad. Pero ahora ellos son LOS expertos en su sistema. Las empresas especializadas en el año 2000 no presentan este efecto secundario.

2 Hardware Y Sistemas Operativos

2.1 Específicos de Hardware

Este punto está muy incompleto. Será interesante ver como crece esta parte del árbol.

2.1.1 Tandem.

Información no verificada en un problema que ya ocurrió con la fecha de expiración de una licencia de software causó inconvenientes debido a la diferencia de formato de fecha (DDMM) y (MMDD) El problema fue resuelto y puede ser un caso interesante.

2.1.2 IBM 390.

Información repetida pero no verificada indica que el sistema tendrá serios problemas.

2.2 Específicos de Sistemas Operativos

2.2.1 Unix: OK (sin verificar)

2.2.2 VMS: OK (sin verificar)

2.2.3 DOS:

La fecha pasa a 1980 en la mayoría de los casos [De Jager] (verificado)

2.2.4 Windows 3.1:

Salta generalmente a 1900 [De Jager] (verificado)

2.3 Compiladores

3 Estructura de datos

3.1 General

3.1.1 año de 2 dígitos

Este es el problema básico.

3.1.2 Otros días trágicos

Las fechas están en diferentes formatos y tamaños. Algunos formatos utilizan desplazamientos que cuentan días o milisegundos. Esto puede causar errores de desbordamiento Se han informado muchos casos.

3.1.3 fuera de rango

3.1.4 Ambigüedad

Las fechas en las aplicaciones deben ser reinterpretadas. En la mayoría de los sistemas esto no es un problema. Pero que sucede cuando en un sistema el punto de corte (pivot) no coincide con otros.

3.1.5 Aritmética.

La raíz de todos los problemas. [Christenson] presenta un buen análisis en el YEAR2000 forum.

3.1.5.1 Calculo de cantidad de días, etc.

3.1.5.2 Clasificación de datos (Sort).

3.1.5.3 Selecciones basadas en campos clave

3.1.5.4 Selecciones basadas en campos que no son clave

3.2 Bases de Datos y archivos de datos (ISAM, VSAM)

3.2.1 Específicos de Bases de Datos

3.2.1.1 DBASE3: falla (sin verificar)

3.2.1.2 DBASE4: OK (sin verificar)

3.2.1.3 Oracle: OK (sin verificar)

3.2.2 Fechas de expiración en validación de registro

4 Software de aplicación

4.1 General

Es importante distinguir entre el software desarrollado internamente del comercial

Puede esperar que los proveedores ofrezcan soluciones (si todavía andan por ahí), gratis si la competencia es grande. Si no consigue ayuda de los proveedores y no tiene los programas, Ud., tiene un problema cuya única solución por el momento es el reemplazo del software.

4.1.1 Específicos de lenguajes de programación

Algunos inconvenientes son mas frecuentes con algunos lenguajes que con otros.

4.1.1.1 Los lenguajes orientados a objetos no tendrán grandes problemas

4.1.1.2 En BASIC y COBOL los valores iniciales son cero por omisión (default).

4.1.2 El año bisiesto

Este inconveniente también podría estar en Sistemas Operativos. Se ha reportado que ISPF tiene este problema Los sistemas desarrollados internamente tienen mayor chance de sufrir este problema (por las dudas: el 2000 es un año bisiesto!)

4.1.3 Abuso de los campos de fecha

4.1.3.1 99 indica último registro, fecha infinito u otra cosa

4.1.3.2 00 para señalar que el dato es nulo

4.1.3.3 99 00 como valores por omisión

4.1.3.4 Interpretaciones especiales del 00

4.1.3.5 Centuria 19 por programa

4.1.3.6 Centuria con manejo separado

4.1.4 Uso de fechas en campos alfanuméricos.

4.1.5 Programas fuente no disponibles

Ahora Ud. puede reemplazar (caro), hacer pruebas de caja negra(complejo y prolongado) o realizar reingeniería (complejo y prolongado).

4.1.6 Sin documentación o desactualizada.

A nosotros no nos va a ocurrir!

4.1.7 Licencias con fecha de expiración

El sistema no funciona. Perfectamente ocultado por el proveedor. Esta puede ser realmente una bomba de tiempo.

4.2 Específico de Aplicaciones

4.2.1 Excel: OK (sin verificar)

4.2.2 Lotus: OK (sin verificar)

4.2.3 Access: problemas de clasificación (sin verificar)

4.3 Software de aplicación por función

4.3.1 Sistemas de respaldo (backup)

Errores in el manejo de las fechas puede forzar a que nunca se realicen respaldos incrementales (archivos que han cambiado). Que se borren los archivos antes de la última actualización puede llevar a una masiva pérdida de datos.

4.3.2 Sistemas en tiempo real

4.3.3 Relojes de redes

Si falla la hora del servidor, fallan todos los equipos clientes.

4.3.4 Software de impresoras

4.3.5 Pronósticos, herramientas de planificación

Estos productos tendrán problemas antes que el resto y probablemente ya se estén solucionados.

4.3.6 Aplicaciones controladas por computadoras

Es fácil olvidarse alguna de estas.

4.3.6.1 PABX (centrales telefónicas)

La central de la compañía telefónica.

4.3.6.2 Ascensores

4.3.6.3 Sistemas de seguridad

Todos los permisos han expirado! El primero de enero nadie puede entrar.

4.3.6.4 Satélites

4.3.7 Sistemas de correo electrónico

Store? and forward?

4.3.8 Calculo de intereses

5 Interfaces

5.1 Interfaces entre máquinas

5.1.1 Interface entre máquinas (en su red)

Bien documentado (el problema, no las soluciones) Equipos sueltos son fáciles de verificar y corregir. Equipos en red requieren cambios sincronizados

5.1.2 Entre compañías

Los problemas se pueden presentar con transmisiones de EDI o con intercambio en medios magnéticos.

5.2 Interfaces de usuarios (pantallas)

5.3 Salidas impresas

6 Análisis

6.1 Elección de herramientas

Un tema difícil. Ud. debe conocer que sistemas tiene, que herramientas existen y como estas herramientas se adecuan a sus sistemas. Por lo tanto Ud, debe tener una idea sobre que consultores necesita y que es lo que pueden ofrecer. No se olvide que estos expertos tienen muchas herramientas disponibles y saben como utilizarlas, pero puede ocurrir que en algunos casos sea necesario desarrollar herramientas específicas..

6.2 Elección de la estrategia

[Christenson] elaboró su trabajo 'Cambiar datos o programas?''(Change data or programs?)'. [Gartner] presentó algunas pautas. Los puntos relevantes son: exposición de los negocios, ciclo de vida de los sistemas , tiempo, perfil de la compañía respecto a las plataformas, sistemas operativos y ambiente de desarrollo de software, disponibilidad de mano de obra adecuada, sensibilidad de las aplicaciones a las fechas, disponibilidad de programas fuente y documentación, etc..

6.3 Confidencialidad

Ud. está dispuesto a darle acceso a sus datos y aplicaciones a terceros?

6.4 Detección

6.4.1 Una aguja en el pajar

Es difícil encontrar fechas cuando no hay normas de codificación. Esto es vale para los programas y para las llamadas externas..

6.4.2 Propagación

Es muy común utilizar variables internas para cálculo. Las variables que se utilizan para fechas en algún caso y para datos alfanuméricos en otro puede indicar a las herramientas que muchos campos alfanuméricos sean seleccionados como candidatos de campos de fecha.

7 Cambios

Probablemente sirva 'Cambiar datos o programas?' [Christenson] nuevamente.

7.1 Cambio de programas

7.2 Cambio de módulos de copia

7.3 Cambio de campos de fecha

7.3.1 Cambio de semántica

7.3.1.1 Utilizar notación hexadecimal

7.3.1.2 Reemplazar desplazamiento

7.3.1.3 Empaquetado

7.3.2 Falta de espacio

Agregar dos dígitos a millones de registro puede traer problemas de espacio

7.3.2.1 Ganar espacio para las fechas a costa de otros datos

7.3.2.2 Aprovechar espacio no utilizado en los registros

7.3.3 Fechas como campos clave

7.3.4 Estandarización

ISO 8601 tiene un estándar. EDIFACT para mensajes EDI.

7.4 Cambio de las fechas existentes

7.4.1 Utilizar "menor que" para encontrar la centuria

Fácil solución en muchos casos.

7.5 Cambio en pantallas y listados

7.6 Cambio de interfaces

7.6.1 Cambio de la definición de la interface

7.6.2 Agregar programas adaptadores (bridge)

Lo mejor serían adaptadores universales que tipo de fecha ingresa y que reemplace el formato viejo por el nuevo y viceversa.

7.7 Actualizaciones combinadas

7.7.1 Pasar a COBOL II o COBOL 370

7.7.2 Pasar a bases de datos relacionales

8 Validación

8.1 Desarrollo de grupos de aplicaciones de prueba

Se ha informado que no solo hay que verificar las fechas que corresponden al año 2000 sino que la prueba debe alcanzar desde la actualidad y hasta el año 2003 por lo menos.

Serge Bouwens

PTT Telecom

Netherlands

Traducción y adaptación: Fernando Namias

Fernando Namias y Asociados

Argentina