Forzar un DUMP en un programa RPG

Cuando monitoreamos errores en un programa RPG, esperamos haber dado con la lista de todos los errores posibles que puedan presentarse antes de que el programa pase del ambiente de desarrollo al ambiente de producción. Sin embargo, esto no sucede siempre.


En el transcurso de las pruebas se producen ciertos errores que podemos controlar, corregir o monitorear. Cuando el programa entra en producción puede sorprendernos la aparición de errores inesperados de acuerdo a la autoridad, la data en los archivos y los objetos creados que pueden ser distintos al entorno de pruebas que teníamos en producción.


Cuando un sistema está recién instalado en producción, el operador del sistema puede encontrarse ante el dilema de no saber que respuesta presionar ante la consola del As400. ¿debo presionar C= cancelar, D= Dump o G= GO?.


Según la experticia del operador y la disponibilidad del encargado del sistema, muchas veces se cancela el proceso perdiéndose la oportunidad de tener un DUMP de memoria que permita acceder a información que hace posible analizar el error y tomar las acciones correctivas y evitar que se produzca una próxima vez.
La solución es no dejar que el operador tenga en sus manos la responsabilidad de dar una respuesta. Para ello vamos a forzar un DUMP a nivel del programa RPG.


En versiones previas a V5R1 esta es la rutina standard de monitoreo de error. Puedes observar que en la hoja H se especifica debug (*YES)

H Debug( *Yes )


C *PSSR BegSr

C Dump

* Colocar el código para manejar la excepción

C EndSr


En versiones posteriors a V5R1 Forzamos el DUMP asi:


C *PSSR BegSr
C Dump(A)

* Colocar código para manejar la excepción.

C EndSr

Un DUMP con un código de operación extendido con una ‘A’ el programa siempre ejecutará el DUMP sin considerar los atributos de DEBUG. Puedes remover las especificaciones de la hoja H y utilizar el código DUMP(A)

EL DUMP, arroja un listado con el valor de las variables y campos del programa en el momento que sucedió la falla.

Si tienes dudas en el funcionamiento de la rutina *PSSR, revisa articulos previos que te explicaran en este mismo blog cómo se monitorean errores en RPG.

Si te pareció interesante, reenvialo 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

Error de Datos Decimales

Los campos declarados numéricos en archivos y programas serán chequeados por el OS/400 para verificar si contienen números validos, cuando la data cargada en ellos es utilizada en el programa. Si estos campos no tienen números validos, se produce un: Error de Datos Decimales: Data Decimal Error y al menos que el error sea monitoreado en el programa, el programa fallará.

Por ejemplo si recibes información de otro computador a través de un archivo, este podría venir con data errónea, si el campo numérico contiene blancos, caracteres especiales o caracteres alfabéticos. Cuando el archivo es abierto en el programa y el registro contiene data inválida no se produce un error. Pero si el campo que contiene data invalida es leído en el programa cuando es el primer operando de una operación MOVE o alguna operación DIV, SUB, ADD, MULT o si está es el dato origen en una operación EVAL (es decir si es el operando a la derecha). También una operación WRITE o UPDATE verificará data inválida y el programa caerá.

Si frecuentemente recibes archivos que contienen data inválida y necesitas corregir la data puedes declarar los campos como carácter y usar TESTN o CHECK para verificar
Que el campo contiene números validos y si la data es correcta o no.

Algunas veces el problema ocurre cuando el campo numérico es “solapado” (overlaid) con una definición numérica en la estructura de datos. Por ejemplo si tienes un empaquetado numérico (packed) y el programador define el campo como ZONED en la estructura de datos el campo contendrá data que es inválida para un campo zoned aún cuando sea validad para un campo empaquetado (packed)
Cuando declaras una estructura de datos con campos numéricos el inicializarla en la declaración evita que se produzcan errores de data decimal.

Cuando el programa RPG no contiene una rutina de monitoreo de errores, es posible que el programa falle y quede en manos del operador del sistema la responsabilidad de responder al error con: C= cancelar, D=Dump G= Go.
Es recomendable tener una rutina de monitoreo de error y provocar un DUMP forzado en el programa para poder analizar cual campo o variable contiene data inválida.

Eso lo vamos a ver en el siguiente artículo.

Si te pareció interesante, reenvialo 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

Restricciones de Integridad de la Base de Datos

(Para ampliar la imagen haz click)

En muchos centros informáticos se trabaja el diseño de base de datos sin el uso de DB2 que es el manejador de Base de Datos del Iseries. Luego del desarrollo de un sistema en estas condiciones, la documentación debería reflejar las restricciones de la base de datos para asegurar la consistencia e integridad de la información contenida en la misma.

Para la base de datos que ilustra la figura del artículo, coloco un ejemplo de las reglas de integridad que rigen a esta base de datos y que deberían estar reflejadas en la documentación técnica que apoya el mantenimiento y expansión de todas las aplicaciones que residen en el Iseries.


Restricciones de Integridad de la base de datos.

1.-Un Directorio no puede crearse para Áreas Distintas.

2.- El Identificador del listado es único para cada área, pero puede repetirse para áreas distintas. Por tanto la clave que identifica un reporte es área-Identificador de Reporte (Prefijo). Esto se diseño en esta forma para no disminuir el rango de Identificadores de reportes para cada área.

3.- No puede eliminarse un reporte si pertenece a un directorio. Primero hay que “deshacer” el Enlace con el directorio y luego Eliminar el reporte del área.

4.- Si desea eliminarse un Directorio debe eliminarse primero su enlace al área que pertenece y luego se eliminará el directorio.


5.- Los programas deben validar y actualizar respetando los puntos anteriormente expuestos.

Si te pareció interesante, reenvialo 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