Adefesios en RPG
APIS
Aplicaciones multi-idioma
Apuntadores
Archivos
as400
AS400 Para Principiantes
Base de Datos
Best practices
Better Performance
Botones en RPG
Calidad Profesional
CLP
Colas de Datos
Comandos PC
Cursos
DEBUG en RPG
Desarrollo de Software
Divertidos
EDI
EDI X12
Edward de Bono
el arte de la guerra
FAQS
Fechas en RPG
FRAUDE
FTP
Gerencia de Sistemas
Grupos de activacion
Herramientas Gerenciales
ILE
ilerpg
indicadores
Iseries
JSON
Lista de Códigos de Error
Master Mind
Mejorando el performance
Mejores Prácticas en RPG
micros
Migración
modulos
Monitoreo de Errores
Mouse
OCCUR
pantalla verde
Pantallas
Peores Practicas
Performance
podcast
pointers
Procesos
Programación CL
Ratón
rpg
RPG-FREE
RPGLE
Seguridad
Servidores
Sesion 1 fundamentos de internet
SEU
Sockets
SQL
SQLRPG
Subfiles
subprocedures
Sun Tzu
Tarjetas de Crédito
Tiempos de Respuesta
Tips en RPG
Transfer Control
Triggers
Utilidades
Ventanas moviles
Versiones
videos
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.
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.
Sunday, August 21, 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
Sunday, August 14, 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.
Subscribe to:
Posts (Atom)