Capturando los mensajes de Error
El comando MONMSG nos
ofrece la posibilidad de monitorear los mensajes de error que emite el sistema
operativo ante un error de ejecución del programa CLP.
En caso de error, el programador es quien debe decidir e indicar
al sistema operativo la acción a seguir. Si el programador no monitorea el
mensaje de error e indica que instrucciones deben ejecutarse en caso de falla,
el programa detiene su ejecución.
He visto varios códigos de
programas en CLP que colocan el MONMSG antes y después de la instrucción a
monitorear ante la incertidumbre de no saber realmente donde debe colocarse.
El MONMSG debe colocarse en dos eventos estratégicos dentro de un CLP
1.- Al principio del
programa.
El objetivo fundamental de
colocar el Monmsg al principio del
programa es la de capturar cualquier error imprevisto en la ejecución de todo
el programa.
-Aquello que se me haya
olvidado monitorear en las siguientes instrucciones debe caer en esta “RED” que
atrape el error no previsto por mí.-
Para ello utilizamos en
general, los mensajes de error CPF0000 y MCH0000
Cabe destacar en este
punto que la mayoría de los programadores coloca los mensajes CPF0000 y CPF9999
de manera automática. Parecieran interpretar que con colocar desde el 00000
hasta el 9999 abarca todo el rango de mensajes de tipo CPFXXXX.
Cuando queremos monitorear
todos los mensajes de error de una categoría de mensajes es suficiente con colocar las tres
primeras letras que identifican la categoría seguidas de ceros. Esto permite capturar todos los mensajes de error de esa categoría. En este ejemplo es
suficiente con colocar CPF0000 y no es necesario colocar el mensaje CPF9999 en el monmsg ya que el CPF9999 esta siendo incluido al
colocar el mensaje CPF0000.
Lo mismo sucede con
MCH0000. Se monitorean automáticamente todos los mensajes de error MCHXXXX.
También podemos monitorear un subconjunto de mensajes en forma global. Por ejemplo, si queremos monitorear los mensajes que comienzan por CPF98XX con rellenar con ceros las 'X' se incluyen todos los mensajes de esa clclasificación. Con colocar: CPF9800 en el MONMSG, es suficiente.
Con el comando WRKMSGF
*all se puede obtener la lista de archivos de mensajes creados en el equipo. Lo
archivos de mensajes donde residen los mensajes que genera el sistema operativo
comienzan con la letra “Q”. Cada uno de estos archivos de mensajes representa
una categoría de errores a monitorear.
El comando WRKMSGF permite
ver, a través de varias opciones, la descripción detallada de los mensajes que están registrados en cada
archivo de mensajes manejado por el sistema operativo.
Cuando colocamos un MONMSG
como primer comando de un programa CLP es conveniente incluir un EXEC que
realiza un GOTO a una etiqueta en la cual se ejecutarán las instrucciones que
el programador indique en caso de error.
Si monitoreamos el error pero no
indicamos ninguna acción a seguir, podemos deducir erróneamente que el programa
se ejecutó correctamente. La verdad es que nuestro propio monitoreo puede ser
“cuchillo para nuestra garganta” porque no fuimos avisados a tiempo de una
interrupción inesperada que impidió la conclusión del programa.
En la etiqueta referida en
el GOTO podemos colocar un SNDMSG a nuestra cola de usuarios, a la consola, a
la cola de mensajes del operador o llamar a un programa que grabe un archivo de
errores dando aviso por fecha, hora, proceso y usuario de la caída del
programa, por ejemplo. Lo importante es: ¡hacer algo por favor¡
Ejemplo de programa CLP
Pgm
Monmsg(CPF0000 MCH0000)
Addlible INVENTARIO
Crtdupobj obj(MAESTRO) fromlib(INVENTARIO)
objtype(*file)
Tolib(INVENTARIO2) newobj(MAESTRO2) data(*yes)
Call pgm(PGM1)
EndPgm
Supongamos el siguiente
escenario:
La librería INVENTARIO ya estaba en la lista de bibliotecas y
falla el duplicado del
archivo MAESTRO
El programa no genera una
falla fácilmente visible aunque no se haya ejecutado el programa PGM1 o aunque se haya ejecutado
PGM1 sin la biblioteca adecuada y sin la data adecuada. Esto puede generar, por
ejemplo, una actualización no controlada
de la bases de datos.
Lo más recomendable es
programar algo como esto:
Pgm
Monmsg(CPF0000 MCH0000)
exec(goto cmdlbl(FINAL))
Addlible INVENTARIO
Crtdupobj obj(MAESTRO) fromlib(INVENTARIO)
objtype(*file)
Tolib(INVENTARIO2) newobj(MAESTRO2) data(*yes)
Call pgm(PGM1)
FINAL:
SNDMSG MSG(‘Falla en proceso de cierre de mes’)
tousr(*SYSOPR)
EndPgm
2.- Después de cada
instrucción que se desea monitorear
El monitoreo de mensajes
debe colocarse luego de un comando a monitorear
Supongamos que tenemos el siguiente programa:
Pgm
ADDLIBLE INVENTARIO
Monmsg(CPF2103)
Crtdupobj obj(MAESTRO) fromlib(INVENTARIO)
objtype(*file)
Tolib(INVENTARIO2) newobj(MAESTRO2) data(*yes)
EndPgm
Si la Biblioteca INVENTARIO
ya existe en la lista de bibliotecas del job, el programa no fallará, sin
embargo si hay una falla en la duplicación del archivo MAESTRO, el programa
fallará puesto que no hubo después del CRTDUPOBJ un MONMSG que capturara el
error. Tampoco colocamos al principio del programa un monitoreo general de
errores que nos permitiera contener este error en caso de que hubiésemos pasado
por alto el monitoreo del Crtdupobj, como ha sido precisamente este caso.
Hay maneras de recuperar
en el CLP el código CPFXXXX que el sistema ha generado cuando se ejecutó el MONMSG
pero esto corresponde a otro tema mas allá del alcance de este artículo.
Seguiremos profundizando en esto de los mensajes de error en otras entregas.
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
No comments:
Post a Comment