La semana pasada estuve de guardia, tuve varias llamadas, una el día 1 a las siete de la mañana, menos mal que el fin de año me porté bien porque atender a un cliente con resaca no suele traer buenas consecuencias, pero el domingo por la noche, alrededor de la 24 horas me pasaron a un cliente que tenía su iSeries muerto.
El código de error olía a máquina desbordada.
El iSeries cuando llega al umbral del almacenamiento empieza a lanzar pecaos como si lo estuvieran matando, es lógico porque el desbordamiento de un sistema puede implicar la pérdida completa de todos los datos de la ASP.
Después de ciertas comprobaciones, le hice hacer IPL en manual hasta la pantalla donde pone la fecha.
En esta pantalla puedes hacer varias cosas, por ejemplo borrar colas de salida. Esta opción se deja como penúltimo recurso, lo normal es que tenga muchos archivos de spool válidos, pero hay una opción que puede servirnos para salir del paso "Borrar anotaciones de trabajo incompletas".
Fue la que cogimos, aparentemente arrancó bien, el comando WRKSYSSTS confirmó nuestras sospechas, máquina al 98% de ocupación, que no se mueva nadie ¡¡¡.
Y ahora que hacemos ???
Lo primero "CLROUTQ QEZJOBLOG", el sistema estuvo más de 15 minutos cepillandose archivos de spool.
El cliente volvio a mirar el porcentaje de ocupación y aparentemente estaba igual, cogno, que ha pasado con el espacio que ocupaban todos esos miembros ???.
Le mandé cepillarse los históricos (WORKOBJ QHST*) y reclamar almacenamiento de spool "RCLSPLSTG" .
Pasados unos minutos ya había bajado del 90%, situación aun grave pero menos preocupante.
No me voy a enrollar mucho con este tema, solo diré que tener un sistema rozando el umbral puede traer estas cosas, además de los problemas de rendimiento que lleva asociados, pero el título de esta entrada puede explicar el motivo por el cual aparentemente no había mejorado la ocupación al borrar el mogollón de JOBLOG.
Mejor pongo un enlace con un documento que seguro que lo explica mejor que yo.    

Here está el documento.