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
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
3 comments:
Rather than use DTAARA we use a file. The file has three fields:
1. Job
2. Step
3. Flag
When step is performed the flag field in the file is updated.
This way you do not have many DTAARA.
We do not use DTAARA. We use file. File has 3 fields:
1. Job
2. Step
3. Flag
When each step is completed Flag field is updated.
This way you do not have many DTAARA.
I'm writing about the beginnings of as400. Of course there are many ways to do that. In The next articles this topic will be extended.
thanks for your comments
Post a Comment