Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

Wednesday, July 30, 2014

Variables y Campos tipo *DATE Primera parte.

                                                                              

 












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.

  1. 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.

  1. 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

  1. 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.

  1. 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.

        Continuará...

 Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo. 

Autor: Ing. Liliana Suárez