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.

Tuesday, December 16, 2014

Control de Procesos
















Hola!  Bienvenidos una vez más a Iseries Venezuela

El Control de procesos es una preocupación constante para gerentes y líderes de proyectos que deben dar la cara cuando un proceso a su cargo falla generando, en algunas ocasiones, consecuencias fatales o el disgusto de un cliente que reclama un mejor servicio.

El tema más delicado y menos tomado en cuenta,  en mi opinión, en el tema de control de procesos es el REPROCESO.

Cuando un proceso que tiene una secuencia de 20 pasos presenta una falla en el paso 13 quedan dos opciones:

1.-Recuperar todos los backups que se tienen “antes de ejecutar el proceso” y ejecutar todo el proceso desde el principio.

2.-Continuar desde donde el proceso falló hacia adelante.
La mayoría de las instalaciones que tienen desarrollos realizados desde los años 80 y 90 optan por la primera solución.

La segunda opción requiere una planificación previa de las fallas en cada paso del proceso para garantizar un reprocesamiento seguro.

Como desarrolladores nos enorgullecemos del conocimiento de muchas técnicas de programación y nos enfocamos en nuestro pequeño mundo llamado “programa”. Cuando integramos nuestro desarrollo a módulos, subsistemas o sistemas conformados por más programas y desarrollos nuestros y de otros programadores,  no planificamos las consecuencias de una falla en cada paso del proceso y tampoco analizamos la manera más eficiente y rápida de solucionar el problema de manera confiable y oportuna. Entregamos nuestro programa y con eso ya “cumplimos”.

En este artículo nos enfocamos en uno de los primeros controles de procesos sencillo que surgió al inicio del surgimiento del as400. 

El uso de área de datos para control de procesos fue una de las primeras ideas que surgió para el control del proceso en as400.  Vamos a partir de que se utiliza un programa CLP principal que ejecuta secuencialmente cada paso.

Cada paso puede realizar cualquier comando como CALL PGM, CRTPF, ADDLIBLE, SBMJOB, etc.

Dependiendo de la actualización de la data y de la naturaleza de los comandos podemos considerarlos pasos individuales o parte de un PASO que agrupa varias acciones. Eso depende del análisis que realice el equipo de trabajo.
Por ejemplo, tenemos un proceso de cinco pasos y declaramos cinco dtaaras y tenemos el siguiente CLP.

PGM

Paso1:
   If cond(dtaara1 = 0) then (do)
     “Ejecutar instrucciones”
    Chgdtaara(dtaara1) value(1)
enddo
Paso5:
   If cond(dtaara5 = 0) then (do)
    “Ejecutar instrucciones”
      Chgdtaara(dtaara5) value(1)
Enddo
 ENDPGM


Aquellos pasos que se ejecutaron sin problemas cambiaran su dtaara al valor 1.

Si el proceso falla en algún punto, el analista puede revisar el status de las dtaaras y realizar los arreglos, respaldo o acciones que se requieran. Luego se puede ejecutar el proceso otra vez sin repetir los pasos previos que no fallaron. La pregunta If Cond(dtaara = 0) evita reprocesar aquellos pasos donde el proceso si pudo culminar.

En artículos posteriores veremos otros mecanismos de control de procesos más elaborados.

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


Saturday, December 6, 2014

Recuperando Los Mensajes de Error: RCVMSG














Hola!  A mis seguidores de IseriesVenezuela.

 Gracias por continuar visitando este blog escrito ustedes.

En esta oportunidad vamos a tratar algo sencillo el comando: RCVMSG
Como hemos visto en artículos anteriores, para controlar los errores de ejecución utilizamos frecuentemente el MONMSG en los programas CLP. Sin embargo, aunque este comando evita que el proceso se detenga no nos suministra el mensaje de error que fue monitoreado.

En muchas instalaciones donde se ejecutan procesos nocturnos múltiples y concurrentes resulta una verdadera pesadilla revisar inmensos listados o anotaciones del Log que arroja el sistema operativo durante la ejecución de los procesos.  En esos logs se anota los CALL, CRTPF, ENDJOB e infinidad de operaciones que retornan complicado el proceso de buscar cual fue el resultado del proceso.

El comando MONMSG contempla la ejecución de acciones específicas
 DO(EXEC)… ENDDO
Podemos ejecutar el comando RCVMSG dentro del grupo de instrucciones EXEC del comando MONMSG. En su expresión más sencilla el comando RCVMSG permite recuperar, a través de variables declaradas dentro del programa CLP el mensaje CPFXXXX y su descripción.
RCVMSG   MSGID(&MID) MSG(&MTEXT)
Luego de capturado el id del Mensaje MID y el texto del mensaje, Mtext, podemos grabarlo en un archivo de errores construido por nosotros. 

Una vez terminado el proceso, consultamos nuestro archivo y podemos rápidamente ver que errores fueron monitoreados durante la ejecución del proceso. Construimos el archivo de errores a nuestra conveniencia. Podemos colocar campos como: Proceso, Sistema, Modulo, Fecha, Usuario, Job, Programa que se estaba ejecutando, Hora, Msgid y Msg-texto.

Cada vez que se ejecuta el proceso se puede realizar un CLRPFM del archivo al principio de la ejecución del mismo y con esto evitamos ocupar memoria con mensajes de fechas anteriores. 

Otro uso práctico del archivo sería generar una estadística por día de la semana, usuario, o cualquier combinación de estos campos para determinar si los errores siguen ocurriendo o se han solucionado completamente.

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

Thursday, October 30, 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