Trabajos, subsistemas y registros de trabajo en IBM i: WRKACTJOB, WRKSBS, DSPJOBLOG, y cómo finalizar un trabajo de forma segura

Qué es

Toda unidad de trabajo en IBM i — una sesión interactiva 5250, un trabajo por lotes, un proceso PASE iniciado por SSH, un trabajo de servidor TCP/IP — se ejecuta como un trabajo dentro de un subsistema, un entorno de ejecución con sus propios conjuntos de almacenamiento y colas de trabajo (QINTER para interactivo, QBATCH para lotes, QSYSWRK y QUSRWRK para muchos trabajos de servidor). WRKACTJOB lista todos los trabajos actualmente activos en todos los subsistemas con información de CPU y de estado; WRKSBS lista los propios subsistemas activos.

Cada trabajo acumula un registro de trabajo (job log): los comandos que ejecutó y los mensajes que recibió o envió, útil para diagnosticar por qué un comando CL se comportó de forma inesperada. DSPJOBLOG muestra el registro de un trabajo que sigue activo o cuyo registro está pendiente (aún no escrito); una vez escrito, el registro es el archivo de spool QPJOBLOG de ese trabajo; DSPJOB o WRKJOB pueden mostrar un trabajo en estado activo, en cola de trabajos o en cola de salida, y WRKUSRJOB lista todos los trabajos — activos, en cola o con salida pendiente — enviados bajo un perfil de usuario determinado. El nivel de registro de mensajes y los atributos de texto de la descripción de trabajo controlan cuánto detalle acaba en el registro.

Los mensajes de operador de todo el sistema — avisos de inicio/detención de servidor, errores de dispositivo y de comunicaciones, advertencias de seguridad — llegan a la cola de mensajes QSYSOPR en lugar del registro de un trabajo concreto. DSPMSG QSYSOPR lo muestra, algo que la utilidad PASE system (véase el artículo sobre SSH/PASE) hace visible a una sesión SSH ejecutada de forma remota.

Finalizar un trabajo no es simplemente «matarlo»: ENDJOB recibe un valor OPTION. OPTION(*CNTRLD), el predeterminado, pide al trabajo que finalice de forma controlada dentro del tiempo DELAY (30 segundos por defecto); si el trabajo ha registrado un manejador de señales y ha expresado interés en señales asíncronas, el sistema operativo genera la señal SIGTERM para que la aplicación pueda limpiar, y solo fuerza la terminación si el plazo expira. OPTION(*IMMED) omite esa fase cooperativa y finaliza el trabajo de inmediato, sin garantía de SIGTERM — apropiado solo para un trabajo que ya está colgado o que no responde.

Por qué importa

Un agente que programe el control de trabajos necesita distinguir «quiero que este trabajo se cierre limpiamente» (*CNTRLD, con un plazo lo bastante largo para cualquier limpieza multihilo) de «este trabajo está atascado y necesito que desaparezca» (*IMMED), y necesita saber qué cola de mensajes (el propio registro del trabajo frente a QSYSOPR) contendrá realmente la evidencia de lo que falló.

Cómo aplicarlo

• Usar WRKACTJOB o WRKUSRJOB user-id para localizar un trabajo antes de actuar sobre él, en lugar de adivinar un número de trabajo.
• Usar el nombre totalmente calificado, ENDJOB JOB(number/user/name) OPTION(*CNTRLD) DELAY(nnn); un nombre de trabajo sin calificar puede coincidir con varios trabajos. Reservar *IMMED para trabajos que no responden a una finalización controlada. Finalizar trabajos de otros usuarios normalmente requiere la autoridad especial *JOBCTL.
• Comprobar DSPMSG QSYSOPR para fallos a nivel de sistema (servidor caído, error de dispositivo) que no aparecerán en el registro propio de un trabajo de aplicación.
• Si el registro de un trabajo es escaso, comprobar su nivel de registro en la descripción de trabajo antes de asumir que no ocurrió nada.

Trampas

• Finalizar un trabajo multihilo con un plazo demasiado corto para que sus hilos adviertan SIGTERM y limpien, lo que simplemente se convierte en un *IMMED más lento.
• Buscar un fallo de inicio o de servidor en el registro de un trabajo cuando en realidad se publicó en QSYSOPR.