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.

domingo, 21 de agosto de 2011

Otra Nota sobre el Trigger.










Un trigger es un atributo de un archivo físico que permite al manejador de Base de datos del AS400 ejecutar un programa en el mismo instante que se haga algún cambio sobre ese archivo. El comando para agregar un trigger a un archivo físico es: ADDPFTRG.

Podemos especificar que queremos que se ejecute un programa X (elaborado por nosotros) antes o después de añadir, eliminar o modificar un registro en el archivo físico sobre el cual estamos ejecutando el trigger. Este programa es desarrollado por nosotros como programadores del sistema, los parámetros de entrada se cargan automáticamente con los valores que el sistema operativo le transfiere. Nosotros no debemos hacer nada más que declarar el nombre del programa en el comando ADDPFTRG. No es necesario especificar los parámetros en este comando. El Sistema operativo, asume que el programa tiene DOS parámetros de entrada.

Importante: El programa que especificamos al incluir un trigger sobre un archivo físico debe tener declarados internamente, dos parámetros de entrada. Estos parámetros son definidos en detalle dentro de una DS (en la hoja E) dentro del programa que nosotros hacemos.
En estos parámetros de nuestro programa, el sistema operativo carga entre otras cosas: nombre del archivo que se ha modificado, Librería, longitud del registro, numero de campos, etc. El sistema operativo entrega en estos parámetros la data residente en el registro antes y después de haber sido alterado. Luego dentro del programa nos corresponde a nosotros como programadores hacer lo que nos interese con la información sobre la data alterada en el archivo.

La duda sobre el uso del trigger reside principalmente en conocer cómo son los parámetros de entrada que debemos declarar en el programa.

En este enlace:
http://www.tylogix.com/Articles/TriggerTechniquesRevisited.htm

Explican detalladamente como declarar la estructura de datos que “desglosa” las posiciones de los parámetros de entrada que entrega el sistema operativo al programa que hemos elaborado. También se explica como recuperar la data del registro modificado antes y después del cambio realizado.

En este blog iseriesvenezuela, también se publicó un artículo anteriormente donde hace referencia a otro enlace que también da su versión de la definición de los parámetros de entrada que debe declararse en el programa.

Este es el enlace dentro de este mismo blog:

http://iseriesvenezuela.blogspot.com/2009/07/que-es-un-trigger.html


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


domingo, 14 de agosto de 2011

Monitoreo de errores en programas CLP




Usualmente el comando MONMSG es utilizado por la mayoría de los programadores para colocar códigos de error conocidos y predecibles. Por ejemplo, en un programa CLP al agregar una librería en la lista de librería y la librería puede que ya exista en la lista, entonces monitoreamos el error CPF2103, para que el programa no se detenga y continúe el proceso.

Es posible la existencia de procesos cuyos errores no son predecibles a simple vista por el programdor y que pueden detener el programa, quedando a expensas de la acción del operador en ese momento. Una vez producido el error y abortado el programa, es necesario revisar el log del job que arroja el sistema operativo para descubrir cual fue el error. El proceso de búsqueda de errores puede volverse engorroso y largo y en algunos casos cuando el log del sistema o los listados del job son eliminados de un día para otro (en forma manual o automática) se pierde el rastro del error.

La siguiente rutina permite capturar el Identificador de mensaje y su descripción, para aquellos mensajes que emite el sistema operativo en caso de errores inesperados para el programador. Se está provocando un error a manera de ejemplo con el comando RMVM (remover miembro de un archivo) en una librería y archivos ficticios.
El Id del error y su texto son capturados en variables del programa y pueden ser grabado posteriormente en un archivo físico de log de errores creado por el programador para su posterior revisión.

Monitoreo de Mensajes de error


Autor: Ing. Liliana Suárez.


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