Monitoreo de errores en programas RPG. Primera Parte. (1/4)

En un programa CLP es muy fácil monitorear los mensajes de error. Utilizando el comando MONMSG(códigodeerrror) y especificando el código de error que se requiere monitorear, se puede con facilidad tomar el control del programa enviando el mensaje de error correspondiente y direccionado la ejecución del programa a la instrucción donde se requiere continuar sin que se produzca un mensaje de error en pantalla que incomode al usuario o que coloque en alerta al operador del sistema.
En RPG el asunto es un poco más complicado. Existen tres maneras de monitorear los mensajes de error.

1-La primera de ellas está relacionada con el monitoreo sobre errores producidos en la operación sobre un archivo.
a.- INFDS
b .-Uso de la Extensión (E) en el código de operación.

2-La segunda se relaciona con errores propios de la ejecución de alguna instrucción de RPG

3-La tercera es la más efectiva y sustituye a las anteriores pero está disponible únicamente para RPG IV e ILE-RPG

Monitoreo de Errores de Archivos. (primera parte)

INFDS(NOMBREDS)

La palabra clave INFDS te permite definir, en el programa RPG, el nombre de una estructura de datos que contiene la información asociada con un archivo. El nombre de la estructura de datos que se utilizará para tal fin se especifica en el parámetro de la palabra INFDS. Si INFDS es especificada en más de un archivo, cada estructura de datos asociada debe tener un nombre único.
Una INFDS debe ser definida para cada archivo para recoger la información relacionada con los errores de excepción disponibles para el programa.

La INFDS tiene la siguiente información.
• File Feedback (longitud 80)
• Open Feedback (longitud 160)
• Input/Output Feedback (longitud126)
• Device Specific Feedback (longitude variable)
• Get Attributes Feedback (longitude variable)

Para este artículo vamos a trabajar con el FILE FEEDBACK. La información contenida en las primeras 80 posiciones para monitorear los errores de archivos a tiempo de ejecución es, en general, más que suficiente para extraer la causa del error en el proceso de manipulación del archivo dentro del programa.

Para mayor detalle sobre las secciones restante de la INFDS puede remitirse al siguiente Link:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/books_web/c0925086306.htm


File Feedback Information

The file feedback information comienza en la posición 1 y termina en la posición 80 de la estructura de datos. Esta segmento de la estructura de datos contiene la siguiente información sobre el error de excepción que se produce en el programa RPG.

• El nombre del archivo sobre el cual ha ocurrido el error.
• El registro que estaba siendo procesado cuando el error ocurrió.
• La última operación que se estaba realizando sobre el archivo cuando
ocurrió el error.
• El código de error.
• La rutina de RPG que se estaba ejecutando cuando se produjo el error.

Algunos códigos de excepción para archivos son por ejemplo:

00000 NO hay errores
01216 Error en una operación implícita Open/Close
01218 Registro está bloqueado.
00012 Registro no encontrado en operación Chain, setll, setgt.
00013 El subfile ya está lleno en operación write.

La lista completa de errores de archivos está en el documento:
iSeries
WebSphere® Development Studio
ILE RPG Reference Summary
Version 5
SX09-1315-03

En el link de este blog titulado: Manuales y Documentos RPG, puedes acceder y descargarlo. Tiene el nombre: IleRPgReferenceSummaryversion5
La lista de códigos se encuentra en el primer capítulo titulado: Error Handling.

A continuación un ejemplo sencillo de manejo de errores para archivo en RPG.
*
* Ejemplo de manejo de errores de excepción en un archivo
*
FARCHIVO UF E K DISK INFDS(DSERROR)
FFDISPLAY CF E WORKSTN

* Define la Data Estructura de datos declarada en el INFDS

DDSERROR DS
DFILESTATUS *STATUS

C DOW NOT (*IN03)

* Monitoreo de errores.

C EXFMT RDISPLAY
C EVAL *IN91 = *Off
C Eval *in98 = *Off
C*
C Key CHAIN RARCHIVO 9091
C*
C Select
C When *in91 /* hay error*/
C Exsr Sr_Error
C*
C*
C When not(*in90)
C Eval NroCust = NroCust + 1
C
* Si hay error en Update el indicador 98 se encederá
C UPDATE Rarchivo 98

* Llama a la Rutina de Error
C IF *In98
C EXSR Sr_Error
C EndIf
C
C EndSl
CENDDO
C Eval LR = *On
* Error processing

C Sr_Error BEGSR

C* Select
C When FileStatus = 01218
C EVAL ERRMSG='El Registro ya está bloqueado'
C
C When FileStatus = 01022
C EVAL ERRMSG='Error en reglas de integridad'
C
EndSl
C*
C ENDSR
La estructura de Datos DSERROR contiene la información que se requiere sobre el status del archivo. Podemos observar que no fue necesario conocer la definición de las primeras 80 posiciones. Declaramos la variable FileStatus indicándole al programa con la palabra clave *STATUS que la variable FileStatus está asociada al código de error guardado por el sistema operativo en la Estructura de datos DSERROR.
Podemos declarar la DSERROR con todas las palabras claves que nos interesa acceder de las primeras 80 posiciones sobre los errores monitoreados para el archivo, de acuerdo a lo especificado en los párrafos anteriores. Para archivos de dispositivo debe declararse otra DSERROR, y debe revisarse las palabras claves correspondientes a la DS, puesto que se requiere otro tipo de información. En el link de public boulder de Ibm hay más información al respecto. La misma observación aplica para archivos de spool.

Utilizando las palabras claves mas conocidas. La DS quedaría declarada así:

Standard RPG feedback area 1-80

DDSERROR ....... DS
DFile ................. *FILE ------------- * File name
DFileStatus ....... *STATUS --------- * Status code
DOPCode .......... *OPCODE -------- * Last Operation code
DRoutin ............ *ROUTINE ------- * RPG Routine
DRecordFmt ..... *RECORD -------- * Record name

Si te pareció interesante, reenvialo 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