La mayoría de los desarrolladores
“clásicos” en RPG prefieren continuar trabajando con campos numéricos de 8
posiciones declaradas en las DDS para almacenar fechas en los archivos. Esta misma tendencia de las
fechas numéricas de 8 posiciones también se aplica en el código de programación.
Esta práctica común ha provocado inconsistencia de data en algunas
instalaciones.
En algunas instalaciones, cuando
revisamos la data que es almacenada bien sea por procesos interactivos,
procesos batch o por procesos de recepción remota de data, ha sucedido que
algunas fechas se han grabado con el formato ddmmaaaa (diamesaño) otras con el
formato mmddaaaa y otras ddmmaa. Esta inconsistencia sucede con frecuencia en
envío remoto de data con organizaciones o clientes del negocio que tienen otras
plataformas distintas a Iseries/Rpg. (Oracle, Sap, etc)
Con un campo numérico de 8
posiciones, el sistema operativo no puede validar en forma automática si se
está cometiendo una trasgresión en contra de la consistencia de la data. Para
el sistema operativo se trata de un campo numérico de 8 posiciones que puede
contener cualquier dato numérico válido. La interpretación de su contenido, por
supuesto, depende del usuario/programador.
Con tantas fechas y tipos de fecha puede parecer complicado
lidiar con estos detalles, por lo que en los primeros intentos para trabajar
con campos y variables tipo fecha se produce una gran resistencia al cambio.
La clave está en adoptar un estándar de uso para la
organización. Luego de que se produzca un consenso con la gerencia de
desarrollo y con la fábrica de software de la institución, es sencillo generar
plantillas para que los programadores las apliquen a sus desarrollos.
Cabe destacar, que todo este proceso de estandarización está
dirigido a asegurar la consistencia de la data de la empresa y del óptimo
funcionamiento de la operatividad del negocio que, en primera y última
instancia, es lo que se persigue.
Aquellas organizaciones que requieren aplicar formulas en
las cuales los días de vencimientos de pago, cálculos de intereses sobre prestamos,
intereses de mora y otros conceptos financieros, son la base fundamental para
la rentabilidad del negocio están obligadas a asegurar la exactitud del manejo
de los campos de fecha en las bases de datos. Esto evita demandas, reclamos,
denuncias y pérdidas potenciales de clientes.
Algunas de las razones que han llevado a repetir esta
práctica y a no querer incursionar en los campos tipo Fecha son:
- ¿Cómo evitar los errores de fuera de rango que producen fallas estrepitosas en los programas?
- ¿Cómo saber cual fecha está utilizando un job?
- ¿Cómo mostrar en pantalla estas fechas?
- ¿Cómo enviar data remota a otras organizaciones o a otras plataformas que no trabajan con este tipo de campos de fecha?
En este artículo voy a responder a dos de estas inquietudes
para trata de perder el miedo a utilizar este tipo de datos. (En el siguiente
artículo seguiremos con las siguientes dos preguntas)
El primer paso es entender cuantos tipos de fecha hay y
cuales son sus rangos.
Esto contestaría la primera pregunta planteada.
En esta tabla puede verse los tipos de campos de fecha
agrupados por sus rangos permitidos.
En un vistazo podemos captar el número de dígitos que tiene
el año en cada formato y cual es el valor mínimo y el valor máximo permitido
para cada uno de ellos.
Esto nos indica que NO podemos inicializar campos de fecha
con el valor CERO como hacemos con las variables numéricas. Una de las “caídas”
más comunes de los programas se produce por tratar de inicializar fechas en
cero. (0).
En la siguientes tablas vemos los formatos y ejemplos que
aplican a cada tipo de fecha.
Para determinar con cual fecha trabaja un job es necesario conocer
la jerarquía de prioridades con la que
trabaja el sistema.
- Primero se verifica las declaraciones de los campos en las dds y en la hoja de declaración de variables del programa (Hoja D en rpg 4 y en rpg free; Hoja E en las versiones anteriores). Los campos y variables serán interpretados en su formato según esta declaración.
- Luego se verifica la hoja H donde se especifica el DATFMT. Las variables de fecha cuyo formato no esté especificado en la declaración del programa o en la dds si se trata de un campo, se regirán por el formato especificado en la hoja H
- Si la variable o campo tipo fecha no tiene formato especificado en su declaración y tampoco hay un formato declarado en la hoja H, se toma por omisión el formato *ISO para manipular las fechas.
- El Job tiene su propia definición de fechas. Cuando hacemos un submit job (SBMJOB) o cuando estamos ejecutando un proceso por interactivo. Las variables del sistema para ese job tienen su formato de fecha. Por ejemplo: Fecha de ejecución del job, (job Date). Esto significa que si por ejemplo, hacemos en un programa CLP un RTVJOBA (Retrieve Job Atributte) y queremos saber la hora del job se nos devolverá la fecha con el formato que fue especificado en el submit job o con el formato que fue especificado la jobd description asociada a ese job.
Autor: Ing. Liliana Suárez
No comments:
Post a Comment