Monitoreando Errores en Acceso a Archivos. Segunda Parte

 

Al actualizar un archivo, el registro actualizado es  desbloqueado (deallocated) y cualquier otro programa o proceso puede accederlo y modificarlo sin problemas.

Cuando trabajamos con subfiles, es necesario recargar el subfile cada vez que  la data ha sido actualizada en el programa a fin de mostrar la información actualizada.

Al leer un archivo para cargar el subfile y  evitar bloqueos innecesarios de un registro se deben realizar los read o chain sin bloqueos.

 Luego, una vez que el usuario ha confirmado su petición de grabar la información, realiza nuevamente, un chain pero con Bloqueo de registro y actualiza inmediatamente para permitir que otros procesos que están ejecutándose paralelamente al tuyo puedan acceder a la información y actualizarla en caso de ser necesario.

-------------------------

En este punto hago un paréntesis:

Cuando se realiza el segundo CHAIN o READ para grabar la información, tradicionalmente se usaba el “pool” de variables auxiliares declaradas para guardar los valores nuevos de los campos del archivo y que no se perdieran al hacer el Chain de actualización.

 Recuerda que utilizando el OCCUR puedes ahorrarte este inconveniente y ahorrar espacio y tiempo de programación. 

Puedes consultar este tema en un artículo anterior de este mismo blog:

http://iseriesvenezuela.blogspot.com/2009/11/occur-para-actualizar-archivos.html

-----------------------

Para cargar el subfile utiliza: la (N) permite hacer lecturas sin bloqueo de registro

KeyField       Chain (N)  FileName

O también:

               Read  (N)  FileName

Para actualizar un registro utiliza:

KeyField       Chain   FileName

En general, los desarrolladores no acostumbran realizar pruebas de la aplicación en un ambiente multiusuario. Para evitar errores innecesarios en el ambiente de producción solicita a varios programadores entrar a tu aplicación al mismo tiempo y te sorprenderás de cuantos se quedan “colgados” en alguna parte del proceso.

Otro error frecuente en la actualización de archivos es el de “CLAVE DUPLICADA”

Con estas instrucciones puedes monitorear el error y dar el mensaje sin producir esa fea caida de la pantalla que da muy mala impresiòn:

Chequear que se va a grabar clave duplicada:

C          Monitor
C          WRITE(E) FILENAME
C          On-Error 01021
C          CALL      PROGX
C          EndMon

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

Monitoreando Errores de Acceso a Archivos -Primera Parte.

Cuando realizamos una operación sobre un archivo de datos que requiere “bloquear” un registro, por ejemplo cuando hacemos un CHAIN (en un programa donde el archivo se ha declarado de UPDATE), puede suceder que ocurra un error de I/O porque otro job tiene bloqueado (allocated) el acceso al registro y el tiempo límite de espera para acceder el registro ha expirado. Esto puede acarrear que nuestro programa falle y se detenga la ejecución del mismo.

Generalmente no es obvio  extraer la información sobre el  otro job que no nos está dejando acceder al registro. Otras veces es nuestra propia programación que ha realizado una lectura previa del registro y  en la segunda vuelta de ejecución se encuentra el registro bloqueado.

Cuando el registro esta bloqueado, el archivo se coloca en Status de Error 1218. Podemos obtener la información básica sobre lo que sucede examinando los subcampos de la estructura de datos PSDS en las posiciones comprendidas desde la 91 hasta la 170. Con el Status de Archivo en 1218 este subcampo puede contener un mensaje de primer nivel como este:

Record 3 in use by job 029617/QPGMR/QPADEV0005.

El texto del subcampo puede contener el mensaje de error del Código de error CPF5027 cuando otro job está bloqueando el registro o puede contener el mensaje del código de Error CPF5032 cuando es nuestro propio job quien bloquea el acceso al registro.

Para mayor información de cómo se declara la estructura de datos de SDS (Status Data Structured) puedes consultar el siguiente enlace:

http://wiki.midrange.com/index.php/Program_Status_Data_Structure

Para monitorear errores de lectura por bloqueo de registro este código puede ser de utilidad:

key  chain(E) file

select
when not %error

... Procesamiento Normal

when %error and %status = 01218

... Mensaje: “Registro Retenido por otro Usuario”

     En este punto puedes desplegar el contenido del campo 91-170

     De la SDS declarada en la hoja D de tu programa.

endsl

ALGO MÁS…

Cuando creamos un archivo, o definimos una descripción de trabajo (JOBD) generalmente tomamos  los valores por omisión en cuanto al tiempo de espera por el acceso a un registro (palabras claves: WAITRCD/WAITFILE).

Esto significa que nuestros Jobs van a esperar ese tiempo máximo definido en el archivo físico o en el job hasta que nuestro programa falle. Esto puede ser un tiempo de espera innecesario para procesos nocturnos o procesos diarios de cierre que requieren optimizar al máximo los tiempos de respuesta. Podemos, a través de este comando que realizamos sobre el archivo:

Ovrdbf waitrcd(*immed)

Hacer que nuestro job no espere nada. Es decir, inmediatamente detecta que el registro está bloqueado y nuestro monitoreo del mensaje de error puede mandar el mensaje  al operador o usuario del proceso para aplicar las medidas correctivas que se requieran en forma mas expedita.

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.

Publicado por: Ing. Liliana Suárez