Muchos de nosotros recordamos haber trabajado durante los años 90 para encontrar y arreglar cualquier cosa que pudiera causar un «efecto 2000». Se trataba de los problemas causados por el uso de años de 2 dígitos que se producían cuando el año cambiaba de 99 a 00. En aquel momento, IBM nos dio una solución, de forma que los años del 40 al 99 se consideraban de 1940 a 1999, y los años del 00 al 39 se consideraban del 2000 al 2039, lo que nos daba otros 40 años para resolver el problema, pero ahora, en 2024, ha pasado más de la mitad de ese tiempo ¡y la gente está empezando a encontrarse con el problema del 2039!
Para ayudar a encontrar y resolver el problema de 2039, IBM ha lanzado una nueva función en RPG.
Antecedentes
El problema original era que almacenábamos años en campos de 2 dígitos, o fechas completas en campos de 6 dígitos. Por ejemplo, la fecha 31 de diciembre de 1999 se almacenaba en la secuencia Año/Mes/Día como 991231. Esto causó dos problemas: (1) cuando se toma 99 y se le suma 1, se obtiene 100, cuando en realidad se quiere 00. (2) Incluso si se soluciona ese problema, si se compara 000101 (1 de enero de 2000) con 991231, es un número inferior, por lo que los algoritmos de ordenación situarían el año 2000 como anterior al año 1999.
Para solucionar este problema, utilizamos unas rutinas proporcionadas por IBM que convertían temporalmente nuestros años de 2 dígitos en años de 4 dígitos para permitirnos superar el cambio de 1999 a 2000. La conversión temporal funcionaba así:
If year < 40;
temporary_year = 2000 + year;
else;
temporary_year = 1900 + year;
endif;
Esto nos permitió superar la crisis y asegurarnos de que nuestros sistemas informáticos no fallaran cuando llegó el año 2000. El único problema es que ahora el año 2039 se acerca, y por lo tanto, ¡necesitamos repetir todo el proceso de nuevo! En algunos casos, las empresas ya están empezando a encontrarse con el problema. Por ejemplo, el código que calcula un préstamo a 15 años a partir de enero de 2025 estará calculando fechas en 2040.
Incluso si aún no está experimentando problemas, es hora de asegurarse de que todo su código está arreglado. La mejor solución, naturalmente, es actualizarlo todo a años de 4 dígitos antes de que sea demasiado tarde.
La opción DATEYY de ctl-opt
Para ayudarnos a solucionar este problema, IBM ha añadido una nueva función al compilador RPG en forma de palabra clave DATEYY CTL-OPT. Por ejemplo, al usar la instrucción
ctl-opt DATEYY(*WARN);
en su programa RPG, el compilador producirá un mensaje de severidad 10 (advertencia) cuando una de las siguientes situaciones sea cierta:
- Un formato de fecha para un campo de fecha tiene un año de 2 dígitos, como *MDY, *DMY o *JOBRUN.
- Un archivo o estructura de datos definido externamente tiene un formato de año de 2 dígitos.
- El programa utiliza las variables especiales heredadas UDATE o UYEAR.
- El programa utiliza el opcode TIME con un resultado de fecha/hora de 12 dígitos.
Con este mensaje en el listado de compilación, los desarrolladores notarán el problema y serán conscientes de que deberán trabajar en actualizar este código para que utilice un año de 4 dígitos antes de que llegue el año 2039.
Si cree que esto no es suficiente puede dar un paso más codificando esto en su lugar:
ctl-opt DATEYY(*NOALLOW);
El uso de *NOALLOW en lugar de *WARN indica al compilador que produzca un error de gravedad 30, que detendrá la compilación del programa. De esta forma, el error no puede ser ignorado.
Programas RPG usando *JOBRUN
Una buena característica que ofrece RPG es la posibilidad de utilizar el formato de fecha del trabajo en un programa utilizando el valor especial de *JOBRUN. Por ejemplo, en Europa donde se prefieren fechas en día/mes/año, un usuario puede tener su trabajo configurado para usar ese formato, mientras que en USA, el trabajo puede indicar mes/día/año.
Para utilizar esa característica un programa RPG haría algo como esto
DateForUser = %char(curDate: *jobrun);
En este caso, si curDate es 23 de Noviembre de 2024 la DateForUser contendría 11-23-24 en USA, o 23-11-24. Hemos tenido esta característica durante mucho tiempo, y es muy agradable para empresas que tienen usuarios en varios países donde los diferentes usuarios pueden preferir diferentes formatos.
Sin embargo, esto también produce un año de 2 dígitos, por lo que puede causar los mismos problemas en 2039.
Para solucionar este problema, IBM ha introducido la opción *LONGJOBRUN.
DateForUser = %char(curDate: *longjobrun);
Usando *LONGJOBRUN, se producirá un año de 4 dígitos, así que dado el mismo ejemplo tendrás 11-23-2024 en USA o 23-11-2024 en Europa.
Más información
Para más detalles y los PTF necesarios para habilitar estas funciones en IBM i 7.4 y 7.5, puede visitar: https://ibm.biz/rpgcafe_fall_2024_dateyy_2039_problem
Traducción adaptada del artículo original publicado en: https://www.md-na.com/scotts-corner/is-y2k-back-help-for-the-2039-proble… y escrito por Scott Klement
