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.

jueves, 30 de octubre de 2014

¿Qué Sabes Sobre Monitor Message MONMSG?

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

sábado, 4 de octubre de 2014

SETON LR Versus RETURN
















Bienvenidos a  Iseries Venezuela!        

En esta oportunidad tratamos la diferencia entre SETON LR y RETURN

He observado varios programas que para "finalizar" utilizan SETON LR otros utilizan RETURN y otros utilizan ambos colocando uno y luego otro. Una manera de asegurarse de que el programa en realidad terminó y no se quedó activo como pasa con Terminator II.

Coloco entrecomillado finalizar porque muchos podrán comprobar que si colocan una instrucción luego del seton lr el programa continúa.

El SETON LR tiene la función de cerrar los archivos abiertos, liberar los espacios de memoria y limpiar la pila de programas eliminado de ella, al programa actual activo de la misma y las variables de trabajo que se almacenan en ella. Un seton LR es interpretado de la siguiente manera por el sistema operativo: "Continúa ejecutando la hoja C hasta el final y luego abandona el programa".

En la siguiente secuencia de instrucciones:

                                        Var1 = 1
                                        Seton LR
                                        VAr1 = VAr1 + 1
                                         Write REC
                                         Return

El programa no se detiene en el SETON LR, porque todavía la hoja C, tiene instrucciones pendientes de ejecución por tanto, el programa suma 1 a la variable Var1 y luego graba en el archivo. Finalmente ejecuta el RETURN y en ese momento sí finaliza el programa.

El resultado final es el siguiente

  • Var1 queda con el valor 2 y
  •  En el archivo se graba un nuevo registro.
Si cambiamos el orden de las instrucciones como en este ejemplo:


                                        Var1 = 1
                                        RETURN
                                        VAr1 = VAr1 + 1
                                         Write REC
                                        Seton LR

El programa se detiene al ejecutar el RETURN y no ejecuta el resto de las instrucciones.
Es decir, no incrementa la variable Var1 y no graba un nuevo registro en el archivo.

El resultado final es el siguiente:

  • Var1 queda con valor 1
  • El programa se detiene inmediatamente.
Hasta ahora podemos concluir lo siguiente.

1.-Esta secuencia de instrucciones:
                                         RETURN
                                          SETON LR
NO tiene sentido porque  el seton LR nunca se va a ejecutar.

2.-El Return suspende inmediatamente la ejecución del programa; el seton LR no lo suspende necesariamente

3.-La mayoría de nosotros colocamos seton lr como ultima instrucción de la hoja C puesto que después de ejecutar el SETON LR, no colocamos mas instrucciones después, no queda otra opción para el sistema operativo que finalizar el programa. Por esta razón es que funciona la intención del programador de finalizar el programa. Si colocásemos otras instrucciones luego del SETON LR, muchos verían con asombro que el programa continúa.

Llamada entre programas.

Hice mención anteriormente que el SETON LR limpia la pila de ejecución. En cambio, el RETURN conserva el valor de las variables en memoria y la pila de programas.
¿Qué significa esto? vamos a verlo con un ejemplo.