Cobol en español
  Página de Inicio Recomiéndala Contáctame Usuarios en Linea
13
     Crea Una cuenta  
Video 1
Video 2
Video 3

Si te ha servido la web
o te han gustado los videos, colabora haciendo click en el botón.

MANUALES
TEMATICOS
BASES DE DATOS
COBOL / WINDOWS
COBOL / UNIX
HISTORIA /DOCS
 
BUSCADOR
PROGRAMANDO-Dos
TRUCOS
AÑO 2.000
TEORIA POWCOB-3
PROG. POWCOB-3
TEORIA POWCOB-5
PROG. POWCOB-5
OCX-ESCOBOL
RUTINAS/MANUALES
OCX / JUEGOS
HERRAMIENTAS
COMPILADORES
ENCUESTAS
ENLACES
FOROS
TOP 10

CHAT   Usuarios: 0
Año 2.000
TEMARIOLo que fue el año 2.000

Lo que fue el año 2.000

página(s) : 1/2
(4083 palabras totales en este texto)
(9904 Lecturas)   Versión Imprimible



IDENTIFICATION DIVISION. (Introduccion)

¿ Porque es un problema la llegada del año 2.000 ?. Cuando desde Cobol le pedimos al Sistema que nos de la fecha actual, ésta nos viene en formato AAMMDD y los dígitos correspondientes al milenio los deprecia, con lo cual cuando intentamos comparar fechas de distinto siglo el resultado puede ser erróneo, por ejemplo:

Que fecha sería mayor 19991020 (20 de Octubre de 1.999) o 20000115 (15 de Enero del 2.000), en teoría es mayor la que hace referencia a un año mayor, pero al depreciar los 2 primer dígitos y solo ofrecernos 991020, para la primera y 000115 para la segunda resulta que la fecha que hace referencia a 1999 la considera mayor.

Vamos a ver todo ésto lo mas claramente posible (quizás para la mayoría todo ésto sea muy evidente, pero intento que para las personas que no lo sea, lo entiendan bien), para comprobar cuando una fecha es mayor que otra, se comparan como si de un número entero se tratase, 991020 es mayor que 000115 (novecientos noventa y un mil veinte es mayor que ciento quince).Pero si tuviéramos la fecha en formato completo AAAAMMDD, el resultado sería distinto, porque 20000115 es mayor que 19991020(veinte millones ciento quince es mayor que diecinueve millones novecientos noventa y un mil veinte).

Formato AAMMDD
991.020
000.115

Formato AAAAMMDD
20.000.115
19.991.020


¿ Porque se guardan las fechas en formato AAMMDD y no como se leen en español DDMMAA ?. Creo que con la respuesta anterior está todo dicho, si el formato fuera el español no podriamos operar como si fuesen números, ya que 210598 sería mayor que 190598, pero en cambio sería menor que 010698, y la realidad nos dice que eso no es así, la fecha mayor sería 010698, luego 210598 y por último 190598.

Para verlo todo un poco mas claro mirad a la tabla siguiente, están ordenados de mayor a menor, fijaros que hay diferencia entre los dos formatos, mientras para el DDMMAA la fecha 21 de Mayo de 1.998 sería la mayor, para el formato AAMMDD la mayor es el 1 de Junio de 1.998, por tanto la correcta. (el hecho de poner el separador de miles es para que podais apreciar mejor la cifra mayor, imaginándola como un número entero).

Formato DDMMAA
210.598
190.598
010.698

Formato AAMMDD
980.601
980.521
980.519



ENVIRONMENT DIVISION. (Desarrollo)

El análisis, es sin duda la parte mas importante de todo el proyecto, hay que tener bien inventariado tanto los archivos a los que va a afectar, como a los programas que utilizan esos archivos.

Obviamente la manera que tenemos cada programador para hacer nuestro trabajo es muy diferente, por lo que entiendo que no todos tendremos los mismos criterios ni la misma forma de enfocar nuestras aplicaciones o proyectos. A continuación os detallo mis criterios:
  • Trabajo en UNIX SVR4 con RM/COBOL 85 Versión 6.00.00, sin ninguna herramienta adicional.
  • Todas las FD´s de los ficheros las tengo en archivos aparte que luego llamo con copy desde cada programa para evitarme errores con los nombre de los campos.
  • Los programas van en un directorio y los archivos en otro.
  • La Working-Storage Section es común para todos los programas, igual nombre para las variables.
  • En la Select nunca doy el lugar absoluto del archivo para tener mas libertad, es decir si el archivo Clientes.dat se encuentra en el directorio /home/datos y los programas están en /home/programas, la dirección a la que hago referencia sería "../datos/clientes.dat" , de ésta manera si ahora en vez de estar todo colgado de /home lo estuviera de /pepe , no habría ningún problema.
Bien, una vez hechas las consideraciones oportunas pasamos al detalle del proyecto.
Es muy importante tener todo sobre papel, es decir un listado con todos los programas y lo que hacen para no perderte, otro con todos los archivos y una carpeta con todas las FD´s listadas (se que es un trabajo meticuloso, pero a la larga los resultados se obtienen y los errores serán mínimos).

A continuación haremos una copia de nuestros directorios de programas y archivos en otro lugar, en mi caso los originales parten de /home , teniendo los programas en un directorio y los archivos en otro, pues bien esa misma estructura se copia a /home1 o a cualquier otro directorio, para ir haciendo los cambios sin entorpecer la labor de la empresa.

Yo he preferido que tanto en pantalla como en los listados, la fecha siga apareciendo en 6 dígitos, por varios motivos:
  • El usuario no tendrá que modificar su hábito de introducir fechas, sería mucho mas latoso para él introducir 8 dígitos que 6, además de su falta de costumbre y consiguiente probabilidad de error. Él no debe de notar nada, menos problemas.
  • En las cabeceras de los listados no hay que hacer ninguna modificación.
  • En el diseño de la pantalla no hay que modificar, en alguna hasta sería un grave problema, puesto que están llenas y no cabe ni una coma.
  • Y por último. hay que pensar que en el 2.001 ya todo volverá a la normalidad (practicamente) porque volveremos a comparar fechas del mismo siglo.
La solución que yo he tomado vale unicamente hasta el año 2.090 pero por desgracia para ese año....., de todas formas solo cambiano un número de una de las rutinas problema resuelto.

   Inicio de Página    | Siguiente (2/2)
Sitio desarrollado con PHP-Nuke. Todos los Derechos Reservados.
PHP-Nuke es un Software Libre realizado con licencia GNU/GPL.
Página creada en Junio de 1.998, con el proposito de difundir el lenguaje Cobol en nuestra lengua.
Andres Montes [98/11]