Jobs, subsistemas e job logs no IBM i: WRKACTJOB, WRKSBS, DSPJOBLOG e como encerrar um job com segurança

O que é

Toda unidade de trabalho no IBM i — uma sessão 5250 interativa, um job em lote, um processo PASE iniciado via SSH, um job de servidor TCP/IP — é executada como um job dentro de um subsistema, um ambiente de execução com pools de memória e filas de jobs próprios (QINTER para interativos, QBATCH para lote, QSYSWRK e QUSRWRK para muitos jobs de servidor). WRKACTJOB lista todos os jobs atualmente ativos em todos os subsistemas, com informações de CPU e status; WRKSBS lista os próprios subsistemas ativos.

Cada job acumula um job log: os comandos que executou e as mensagens que recebeu ou enviou, útil para diagnosticar por que um comando CL se comportou de forma inesperada. DSPJOBLOG mostra o log de um job que ainda está ativo ou cujo log está pendente (ainda não gravado); depois de gravado, o log é o spooled file QPJOBLOG desse job. DSPJOB ou WRKJOB podem exibir um job nos status ativo, em fila de jobs ou em fila de saída, e WRKUSRJOB lista todos os jobs — ativos, em fila ou com saída pendente — submetidos sob um determinado perfil de usuário. O nível de registro de mensagens e os atributos de texto na descrição do job controlam quanto detalhe vai parar no log.

As mensagens de operador do sistema como um todo — avisos de início e parada de servidores, erros de dispositivos e de comunicação, alertas de segurança — vão para a fila de mensagens QSYSOPR, e não para o log de um job específico. DSPMSG QSYSOPR a exibe; o utilitário PASE system (veja o artigo sobre SSH/PASE) torna isso visível para uma sessão SSH executada remotamente.

Encerrar um job não é simplesmente "matá-lo": o ENDJOB recebe um valor em OPTION. OPTION(*CNTRLD), o padrão, pede ao job que termine de forma controlada dentro do tempo DELAY (padrão: 30 segundos); se o job registrou um tratador de sinais e demonstrou interesse em sinais assíncronos, o sistema operacional gera o sinal SIGTERM para que a aplicação possa fazer a limpeza, e só força o encerramento se o prazo expirar. OPTION(*IMMED) pula essa fase cooperativa e encerra o job imediatamente, sem garantia de SIGTERM — adequado apenas para um job que já está travado ou sem resposta.

Por que importa

Um agente que automatiza o controle de jobs precisa distinguir entre "quero que este job seja encerrado de forma limpa" (*CNTRLD, com um atraso longo o bastante para qualquer limpeza em múltiplas threads) e "este job está travado e preciso eliminá-lo" (*IMMED). Também precisa saber qual fila de mensagens (o log do próprio job ou a QSYSOPR) realmente conterá a evidência do que deu errado.

Como aplicar

• Use WRKACTJOB ou WRKUSRJOB user-id para localizar um job antes de agir sobre ele, em vez de adivinhar o número do job.
• Use o nome totalmente qualificado, ENDJOB JOB(number/user/name) OPTION(*CNTRLD) DELAY(nnn); um nome de job isolado pode corresponder a vários jobs. Reserve *IMMED para jobs que não respondem a um encerramento controlado. Encerrar jobs de outros usuários normalmente exige a autoridade especial *JOBCTL.
• Consulte DSPMSG QSYSOPR para falhas no nível do sistema (servidor fora do ar, erro de dispositivo), que não aparecerão no log do job de uma aplicação.
• Se o log de um job estiver escasso, verifique o nível de registro na descrição do job antes de presumir que nada aconteceu.

Armadilhas

• Encerrar um job com várias threads usando um atraso curto demais para que as threads percebam o SIGTERM e façam a limpeza, o que acaba sendo apenas um *IMMED mais lento.
• Procurar uma falha de inicialização ou de servidor no job log quando ela, na verdade, foi registrada na QSYSOPR.