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:
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”
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
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
No comments:
Post a Comment