Como expliqué en anteriores artículos, el JES2 (Job Entry Subsystem) es el subsistema de trabajos que utiliza el mainframe para sacar adelante jobs que se envían para que los procesen, y luego dejan una salida para su estudio o análisis. El JES2 entre otras cosas tiene unos datasets de SPOOL o HASPACES que se utilizan para guardar el proceso y el resultado de los trabajos en ejecución, en cola o procesados. Y, salvo que se le diga en el JCL donde lanzas el trabajo, que los "purgue" o borre, van quedando ahi llenando el SPOOL, poco a poco, pero sin remisión.
La alarma puede llegar si se lee lo siguiente en la consola del sistema:
*09.33.16 *$HASP050 JES2 RESOURCE SHORTAGE OF JQES - 99% * UTILIZATION REACHED *09.33.40 *$HASP050 JES2 RESOURCE SHORTAGE OF JOES - 99% * UTILIZATION REACHED
Estos mensajes alertan que el SPOOL de Job Queue elements (JQE) y el Job Output Elements (JOE) están al 99%. Si llegaran al 100%, se produciría una situación de deadlock, no pudiendo lanzar nada para borrar nada porque no nos lo permitiría y congelando la producción teniendo que recurrir al "botonazo y tentetieso", teniendo que realizar una IPL "cold start" con el parámetro de JES2 r xx,cold,noreq.
Esto formatearía los SPOOLs y todo lo que tuvieramos guardado de salidas de trabajos, se perdería sin remedio, pero por lo menos todo volvería a arrancar.
Llegar al 100% es el extremo de la dejadez supina del departamento de operación, de hecho los mensajes del 99% también lo son, ya que dichos mensajes empiezan a aparecer cuando se sobrepasa el 80% de utilización (aunque este parámetro es configurable en el JES2PARM que reside en la PARMLIB), y a menos que no se haga nada para remediarlo y dejar que se llene todo, se podrían tratar sin problemas para nunca llegar al 100%.
El artículo de hoy tratará sobre cómo llevar un control del SPOOL haciendo un mantenimiento de las colas de salida para que no se llenen los dataset de SPOOL.
-
Opción 1: Borrado manual. La persona que lanza el job es al fin y al cabo responsable de su salida, así que lo lógico es que una vez que termine de ver su proceso y salida, lo borre del spool, así no se va llenando.
-
Opción 2: Automatizar el borrado. Se podría decidir una política en la instalación que los jobs acabados con mas de 15 días de antigüedad, se borren de manera automática, simplemente ejecutando el siguiente comando de consola:
$OJOBQ,Q=A,CANCEL,A>15.
Este comando borraría todos los jobs de clase A. Si quisieramos borrar los de otra clase, cambiaríamos la Q=A por Q=B, Q=X, etcétera. Y si editamos nuestro planificador (ver Planificación de trabajos con Mainframes) y añadimos la siguiente línea al miembro PLANIF:
/*$TA,T=10.00,'$VS,''$OJOBQ,Q=A,CANCEL,A>15'''
Haremos que todos los días a las 10 de la mañana, se ejecute el comando que haga que los trabajos con mas de 15 días de antigüedad en la cola de salida de clase A se borren.
Sencillo, ¿no?.
Comentarios