Reducir el impacto de los errores
Cuando
se procesan datos y a pesar de las validaciones, existe una probabilidad que un
proceso pueda cancelar su ejecución. Existen múltiples causas que pueden causar
este problema, entre ellas:
- Error
de datos (datos no informados, datos del tipo incorrecto, datos erróneos,
datos fuera de rango)
- Error
de cálculo (división por cero, desbordamiento de datos)
- Error
de memoria (memoria insuficiente para tratar un proceso, acceso incorrecto
a una tabla, desbordamiento de una tabla)
- Lectura
incorrecta de un fichero de entrada (no controlar bien el fin de fichero,
no tener tratamiento para cuando se
lee un fichero vacío)
- Escritura
incorrecta de un fichero (falta de espacio al escribir un fichero)
- Error
de DB2 (error de contención al intentar actualizar una tabla)
Estadísticamente
es imposible que en una instalación que procesa millones de registros todos los
días del año no surja una combinación de los factores anteriores que cancele un
proceso.
Solucionar
un error tiene un coste en tiempo que penaliza la ventana batch, sobre todo si
el proceso forma parte de la ruta crítica de proceso por lo que el resto de los
procesos condicionados a él tienen que
esperar.
El
coste de los fallos puede ser elevado, si el personal de Operaciones no puede
solucionar el error en un tiempo prudencial por sus propios medios y tiene que
recurrir a la ayuda de otras personas que tengan que conectarse al mainframe
desde sus casas o simplemente acudir por la noche a la instalación.
El
cancelamiento de procesos es una de las causas fundamentales de que la carga de
trabajo de la ventana batch demore más de lo previsto y en ocasiones haya que
trasladar procesos a la ventana online.
Si
se reduce considerablemente el impacto de los fallos, se reducen considerablemente
los problemas de rendimiento.
La
manera de atacar este problema afecta a varias áreas dentro de una instalación
de mainframe:
- Arquitectura / Metodología
/ Sistemas:
aportan las normas de diseño correcto de programas y procesos
- Desarrollo: Crea los programas y
procesos, recepciona y corrige los fallos
- Operaciones: Detecta los fallos,
elabora estadísticas, corrige los fallos documentados, avisa al personal
de desarrollo en caso de errores críticos
Para
reducir el impacto de los errores existen dos estrategias:
- Reducir
la frecuencia de fallos
- Reducir
el coste de cada uno de los fallos
Reducir la frecuencia de los fallos
Hay
que elaborar una estrategia cuidadosa para perseguir y corregir la mayor
cantidad posible de fallos. Algunos son tan fáciles de arreglar como asignar
almacenamiento (disco o memoria) a un paso de proceso. Otros como los S0C7
(asignar valores no numéricos a un campo numérico) o S0C4 (error de memoria al
acceder a un área inexistente) pueden ser causados por malas prácticas de
programación o pruebas deficientes.
Para
reducir la frecuencia de los fallos, puede realizarse un enfoque estadístico
apoyado en preguntas tales como:
- ¿Cuál
es la frecuencia de los fallos de proceso (cancelamientos)?
- ¿Cuál
es la frecuencia de los tipos más comunes de fallos?
- ¿En
que tiempo Operaciones recupera un proceso antes los fallos más comunes?
- ¿Cuántos
intentos hay que realizar antes de poder recuperar un proceso con los
fallos más comunes?
- ¿Es
posible recuperar el proceso a partir del punto en el que falló (ahorro de
tiempo al no tratar registros ya procesados)?
- ¿Está
documentada la forma de resolver los fallos más comunes?
- ¿Está
entrenado el personal de Operaciones en la resolución de fallos que
involucran acciones de sistema (asignar memoria, cambiar almacenamiento en
disco o clases de almacenamiento, etc.)?
- ¿Existe
un compromiso o previsiones de arreglar estos fallos por parte de los
equipos de Desarrollo?
La
mayor fuente de errores en batch es la validación de datos. Hay varias formas
de tratar los datos antes de procesarlos:
- Añadiendo
un paso con un programa que realice validaciones exhaustivas de cada
registro leído
- Añadiendo
un paso de DFSORT/ICETOOL con el operador VERIFY que permita detectar
casos como números decimales en formato inválido, por ejemplo:
VERIFY FROM(INDD) ON(22,16,PD) ON(7,9,ZD)
- Añadiendo
las validaciones extra a los propios programas que componen el proceso
Reducir el coste de cada fallo
Comprender
el coste de cada fallo esta asociado a las siguientes preguntas:
- ¿Qué
demora introduce a la ventana batch la solución de un determinado fallo?
- ¿Cuántos
intentos hay que realizar hasta que un proceso puede recuperarse de un
fallo y terminar correctamente?
- ¿Cuál
es el porcentaje de fallos repetidos? O sea, ¿un proceso se recupera en
dos, tres o más intentos?
El
impacto de un fallo en un proceso puede reducirse si:
- Automatizamos
la recuperación del proceso
- Tenemos
una política de recuperación adecuada y bien definida (documentada y en
manos del personal apropiado)
- Hacer
que el proceso pueda recuperarse a partir del punto en que se produjo el
fallo (relanzamiento)
Recuperación automatizada
La
recuperación automatizada de procesos implica disponer de una plataforma
adecuada, como por ejemplo OPC/ESA.
Normalmente
es más rápido y confiable recuperar un proceso utilizando esta facilidad,
aunque la plataforma tiene que aprender previamente como tratar determinados
fallos de un proceso.
Política de recuperación
Tanto
con técnicas automatizadas como manuales, el personal de operaciones tiene que
tener una documentación proporcionada por Desarrollo y basada en normas
aprobadas por Calidad/Arquitectura/Sistemas.
Cuando
un proceso se cancela normalmente Operaciones sigue los siguientes pasos:
- Analizar
la causa y el ámbito del fallo para decidir cuáles son las acciones de
recuperación que hay que tomar
- Reparar
el problema, si es posible
- Restaurar
los ficheros que el proceso actualizó a su estado original (si los
hubiera)
- Lanzar
el proceso desde el comienzo (o desde el punto en que se produjo el fallo)
Relanzamiento
El
relanzamiento o reposicionamiento obedece a un patrón de diseño que permite en
caso de fallo recuperar el proceso en un punto determinado y terminar el
tratamiento del conjunto de datos de entrada.
El
secreto para restaurar un proceso consiste en una combinación de dos factores:
- Apuntar
a los datos correctos
- Relanzar
el proceso en el paso correcto (usualmente el paso donde se produjo el
fallo o el paso anterior)
Una
de las técnicas más simples consiste en grabar en un fichero un contador con la
posición dentro del fichero de entrada del dato que hemos procesado.
De
esta manera si el proceso se interrumpe en algún punto, podemos eliminar de la
entrada los registros tratados o posicionarnos en el registro correcto y
continuar el proceso.
El
enfoque es parecido cuando se leen registros de una base de datos. Cada vez que
se hace un COMMIT de un conjunto de registros procesados, se guarda en un
archivo la clave del último registro procesado.
Si
se interrumpe el proceso, puede volver a abrirse un cursor sobre la tabla donde
la clave sea mayor que la clave guardada. De esta manera no se vuelven a
recuperar de la base de datos los registros tratados y el proceso puede
continuar.
0 comentarios:
Publicar un comentario