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.

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

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

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

Enlace Consultado

¡Hey!... ¡Eso No Fue lo Que Yo te Pedí!

Relativamente hace poco tiempo se ha desarrollado una disciplina denominada: Ingeniería de Requerimientos que procura brindarnos una metodología para que podamos definir con claridad lo que el usuario nos pide como desarrolladores de software. Esta disciplina tiene una serie de pasos que pueden variar dependiendo de las estrategias de desarrollo de software que se hayan adoptado. Existe una gran literatura en la web bien extensa y completa sobre este tema. Por tanto, en este artículo me dedicaré a exponer en forma sencilla las prácticas  que me han resultado exitosas en la definición de requerimientos basándome en mi propia experiencia y sin atarme a ninguna tendencia específica aunque pueda estar tomando algunos puntos importantes de ellas.

En mi experiencia, hay dos estrategias fundamentales que garantizan la definición exitosa de un requerimiento:

1.-Divide y Reinaras

Esto significa no esperar hasta el final para hacer entregas ni para realizar verificaciones de las mismas. Esto implica dividir la definición de requerimiento en “fases”.

Cada fase debe de la definición del requerimiento debe:

Ø      Tener al menos un entregable.

Un entregable es algo material, visible y tangible que se presenta al usuario y al equipo de trabajo de las áreas involucradas que constituye una evidencia del avance del ANÁLISIS del requerimiento.

Un entregable puede ser un documento en Word o pdf , una presentación en power point; una exposición donde se muestre cómo sería la secuencia de pantallas y los campos, registros, ventanas y subfiles que habría en cada una de ellas, un archivo grabado en cinta, un video, etc

En lo personal, la secuencia de pantallas es mi favorito.

El entregable hace posible que las objeciones a la definición del requerimiento sean detectadas a tiempo; permite rectificar y unificar criterios;  detectar condiciones de ejecución, de validación o de operatividad que en la solicitud inicial no fueron detectadas.

        

Ø      Propuestas con soluciones verificables.

La verificabilidad es una lista de condiciones que toda propuesta de solución debe cumplir.

    La Lista es la Siguiente:

Cinco Recomendaciones Para Crear Archivos con DDS

 En esta oportunidad voy a referirme a la clásica creación de “base de datos” utilizando DDS. 

Coloco entre comillas base de datos porque en realidad DDS es un manejador de archivos y no un manejador de base de datos.

Crear Bases de datos con  DB2 tiene una serie de validaciones automáticas suministradas por el DB2 que impiden de alguna manera la generación de algunos “Frankenstein”; en cambio, la libertad del uso de las DDS  si permiten la proliferación de algunas creaturas terroríficas que deambulan en los pantanos de los sistemas de las organizaciones

1.-El Diccionario de Datos.

El uso del diccionario de datos que tuvo su auge en  décadas pasadas ha pasado a ser, en varias instalaciones, una colección mas en el  baúl de los recuerdos. El Diccionario de datos permite mantener la consistencia e integridad de la data. En algunas instalaciones vemos por ejemplo, que unos archivos tienen el código de país de tres posiciones alfabéticos, otros los tienes de dos posiciones numéricos y otros de seis posiciones alineados a la izquierda utilizando solo los primeros dos caracteres. Para evitar esta variedad de definiciones que rompen con la consistencia de la base de datos es importante y fundamental utilizar un diccionario de datos.

2.-Normalización de las Bases de Datos.

Hay material de estudio académicamente certificado que explica como definir una base de datos siguiendo las reglas normalización de primera forma normal hasta quinta forma normal. Es bueno desempolvar lo que aprendimos en las instituciones y llevarlo a las mejores prácticas en nuestros sitios laborales. En los siguientes artículos vamos a ver la aplicación de la normalización de las bases de datos en el desarrollo de programas RPG usando DDS.

3.-NO colocar índices en los archivos físicos.

Colocar claves en los archivos físicos retarda los procesos de recuperación, copia y salvado de la data. Incluso retardan el tiempo de respuesta de los procesos. Es preferible utilizar lógicos, SQL o cualquier otro medio de acceso indexado que satisfaga esa necesidad de ordenamiento.

4.-Deje algunos campos comodín.

Dada la dinámica de los cambios en las normas y reglas del negocio, algunas veces es imposible predecir la necesidad de expandir un archivo creándole mas campos y cuando las modificaciones que requiere el negocio nos lleva a la necesidad de crear campos adicionales preferimos crear otras tablas o archivos que viene a ser la “extensión” del archivo base. Es conveniente crear algunos campos extras de tipo carácter y numérico que permita prevenirnos de modificaciones dramáticas a futuro, que involucre la recompilacion de varios programas que depende de las definiciones de los archivos.

Aunque algunos prefieran crear tablas adicionales, la consulta de estas tablas en procesos nocturnos (hacer chain una y otra vez) puede retrasar el tiempo de respuesta.

5.-Sea consistente en la nomenclatura de los campos.

Aún utilizando el diccionario de datos, los archivos que reposan sobre él en cuanto a su definición pueden tener sus propios nombres de campos según el criterio del analista o las normas de desarrollo del departamento de sistemas.

¿Qué es eso de la consistencia en los nombres?

Por ejemplo para los campos que sean código utilice las tres primeras posiciones de la izquierda como COD  o si lo prefiere CD o de cualquier otra manera. Cualquier sea su elección mantenga esa nomenclatura en todos lados. Si se trata de una descripción y decide utilizar DES utilice DES a lo largo y ancho de la base de datos.

Aunque una longitud de 6 posiciones es bastante corta para describir el concepto del uso de un campo, el respeto por las convenciones de uso y nomenclatura establecidas por el departamento de sistemas y de base de datos, facilita al analista entender rápidamente de qué se trata el contenido de la data.

En el siguiente enlace conseguirás mas información sobre creación de base de datos publicada en otros artículos de este mismo blog.

Haz click aqui:  Bases de Datos

En las próximas entregas voy a ilustrar la definición y el uso paso a paso de una base de datos adaptado a DDS y para desarrolladores RPG además de otras recomendaciones.

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