Bellacosa Mainframe e os abends em mainframe

☕ Um Café no Bellacosa Mainframe

WarGames Entra no CPD — O Dia em que o WOPR Deu S0C7, Joshua Pediu um Dump e o Programador COBOL Descobriu que ABEND Não Significa “Acabou o Mundo”

Ou: como S0C4, S0C7, SB37, S322, S806, dumps, JES2, JCL, datasets, storage, load libraries e um pouco de sangue-frio transformam “JOB ABENDED” de mensagem apocalíptica em pista de investigação — e por que a melhor maneira de vencer um ABEND talvez seja aprender a não jogar adivinhação

---

“Shall we play a game?”

A tela 3270 ficou silenciosa.

O programador COBOL Padawan tinha acabado de submeter seu primeiro JOB sozinho.

No canto superior da tela:

IKJ56250I JOB COBTST1(JOB01234) SUBMITTED

Ele sorriu.

— Funcionou.

Joshua, instalado misteriosamente em algum lugar entre uma LPAR de desenvolvimento, um terminal antigo e o NORAD, respondeu:

PROCESSING...

Alguns segundos depois:

IEF450I COBTST1 STEP01 - ABEND=S0C7

Silêncio.

O Padawan olhou para a tela.

Olhou para o café.

Olhou novamente para a tela.

— Destruí o mainframe?

Joshua respondeu:

WOULD YOU LIKE TO PLAY
GLOBAL THERMONUCLEAR WAR?

— Não, obrigado. Só queria executar um COBOL.

Bem-vindo ao universo dos ABENDs.

E antes que alguém aperte o botão vermelho, precisamos entender uma coisa fundamental:

ABEND não significa que o mainframe morreu.

Normalmente significa apenas:

um programa, step ou tarefa terminou de maneira anormal.

E isso muda completamente a investigação.

---

1. Primeiro contato — afinal, o que é ABEND?

ABEND é abreviação histórica de:

ABnormal END

Ou seja:

término anormal.

Em um processamento normal, imaginamos algo parecido com:

JOB
 |
 +-- STEP01
 |
 +-- STEP02
 |
 +-- STEP03
 |
 `-- FIM

Cada programa termina conforme esperado.

Por exemplo:

RETURN CODE = 0000

Mas algo pode acontecer durante a execução:

JOB
 |
 +-- STEP01   RC=0000
 |
 +-- STEP02   ABEND S0C7
 |
 X

O sistema interrompe aquele processamento.

A primeira coisa que o iniciante precisa aprender é não misturar três conceitos:

RETURN CODE
ABEND
SQLCODE

Eles podem aparecer no mesmo trabalho, mas não significam a mesma coisa.

Um RC=0004, por exemplo, normalmente indica que determinado programa terminou e devolveu um código.

Já:

S0C7

significa que houve uma exceção durante a execução.

E:

SQLCODE -811

é uma condição reportada pelo Db2.

São universos relacionados, mas distintos.

---

2. O detalhe que engana todo Padawan: é zero, não letra O

Observe:

S0C4
S0C7

O caractere depois do S é:

0

zero.

Não:

O

Portanto:

S0C7

e não:

SOC7

Essa pequena diferença já entregou muitos novatos aos Sith Lords do suporte.

Também encontramos códigos como:

S806
SB37
S322

O formato varia porque esses códigos representam diferentes System Completion Codes.

---

3. Quem realmente matou o JOB?

Em WarGames, o drama nasce porque todo mundo olha para uma tela e começa a imaginar imediatamente o pior cenário possível.

No mainframe acontece algo parecido.

O operador vê:

ABEND S0C7

O programador conclui:

— Problema no sistema operacional.

O sysprog responde:

— É seu COBOL.

O DBA fala:

— Não tem nada a ver com Db2.

O storage pergunta:

— Por que vocês estão me chamando?

Joshua observa silenciosamente.

O procedimento correto é muito menos cinematográfico:

1. identificar o JOB
2. identificar o STEP
3. identificar o ABEND
4. localizar as mensagens
5. consultar dump/log
6. identificar programa/instrução
7. verificar causa
8. corrigir
9. recompilar, se necessário
10. executar novamente

Isso é investigação.

Não adivinhação.

---

4. O primeiro jogo de Joshua — S0C7

Talvez seja o ABEND mais famoso entre programadores COBOL.

S0C7

Geralmente está associado a uma Data Exception.

Traduzindo para o mundo COBOL:

algum dado que deveria ser numérico não contém uma representação numérica válida para a operação executada.

Imagine:

01  WS-VALOR      PIC 9(05).

E por algum problema de arquivo, layout ou movimentação, a área contém algo incompatível.

Então executamos:

ADD 1 TO WS-VALOR

O processador tenta realizar uma operação decimal.

Só que os bytes armazenados não representam o número esperado.

Resultado possível:

S0C7

O clássico culpado

Considere:

01 WS-NUMERO PIC 9(5).

MOVE '12A45' TO WS-NUMERO.
ADD 1 TO WS-NUMERO.

Dependendo da representação e do contexto, temos material perfeito para uma exceção de dados quando aquela área for usada aritmeticamente.

O verdadeiro problema, entretanto, nem sempre está na linha que deu o ABEND.

Esse é um princípio crucial.

A instrução:

COMPUTE WS-TOTAL = WS-VALOR + WS-TAXA

pode apenas ser o lugar onde a corrupção foi descoberta.

A corrupção talvez tenha acontecido 500 linhas antes.

---

5. Packed decimal — onde o S0C7 encontra seu habitat favorito

No COBOL empresarial encontramos muito:

PIC S9(7)V99 COMP-3

Isso é packed decimal.

Os dígitos são armazenados compactados em nibbles.

Por exemplo, conceitualmente, os valores são codificados em hexadecimal em vez de armazenados simplesmente como caracteres ASCII/EBCDIC visíveis.

O último nibble normalmente contém o sinal.

Valores típicos de sinal incluem:

C = positivo
D = negativo
F = unsigned/positivo em determinados contextos

Se uma área COMP-3 recebe bytes inválidos e depois participa de uma operação decimal, temos forte candidato a:

S0C7

Imagine um layout errado:

Arquivo real:

01 REGISTRO-REAL.
   05 CODIGO       PIC X(05).
   05 VALOR        PIC S9(7)V99 COMP-3.

Seu programa acredita que seja:

01 REGISTRO-ERRADO.
   05 CODIGO       PIC X(06).
   05 VALOR        PIC S9(7)V99 COMP-3.

Um byte mudou de posição.

Agora você não está lendo VALOR.

Está lendo uma mistura de bytes.

Joshua pergunta:

“Would you like to play S0C7?”

---

6. Checklist Bellacosa para um S0C7

Quando aparecer:

S0C7

não saia alterando código aleatoriamente.

Investigue:

O campo é DISPLAY?
COMP?
COMP-3?

O layout do arquivo está correto?

O copybook é a versão correta?

Houve REDEFINES?

Existe MOVE entre campos incompatíveis?

O registro possui o comprimento esperado?

O programa inicializou todas as áreas?

Existe arquivo antigo sendo processado com layout novo?

O erro apareceu depois de alteração de copybook?

E uma pergunta particularmente poderosa:

Qual era o conteúdo hexadecimal do campo no momento do ABEND?

O dump pode responder isso.

Aqui começamos a perceber por que um dump não é lixo.

Ele é a fotografia da cena do crime.

---

7. Segundo jogo — S0C4

Agora Joshua resolve jogar com memória.

S0C4

Esse ABEND está geralmente ligado a problemas de acesso à memória, proteção ou endereçamento.

Em linguagem humana:

o programa tentou acessar uma área de storage que não deveria ou não poderia acessar daquela maneira.

A imagem apresentada resume isso como:

Protection / memory access error.

É uma boa simplificação para o iniciante.

Mas o universo real é mais profundo.

Um S0C4 pode surgir por diversas situações, incluindo erros de endereço, referências inválidas, subscripts incorretos e problemas relacionados ao uso de storage.

---

8. O array que atravessou a fronteira do NORAD

Considere:

01 WS-TABELA.
   05 WS-ITEM PIC X(10) OCCURS 10 TIMES.

01 WS-I PIC 99.

Agora:

MOVE 50 TO WS-I

DISPLAY WS-ITEM(WS-I)

Temos apenas:

1 até 10

mas estamos tentando acessar:

50

Dependendo do programa, compilação e circunstâncias, podemos acabar acessando storage além da estrutura esperada.

Esse tipo de erro é especialmente perigoso porque memória não respeita a nossa intenção.

O processador não pensa:

“Ah, Vagner queria provavelmente o elemento número 5.”

Ele usa o endereço calculado.

Se estiver errado, estará errado em velocidade de mainframe.

---

9. Subscript versus index

COBOL possui mecanismos de tabelas que o iniciante precisa compreender.

Por exemplo:

05 WS-CLIENTE OCCURS 100 TIMES
   INDEXED BY IDX-CLIENTE.

Podemos navegar com índice:

SET IDX-CLIENTE TO 1

ou utilizar subscripts em determinadas definições:

MOVE WS-CLIENTE(WS-I)

Erros nessa lógica podem produzir acesso a áreas inesperadas.

Uma proteção importante durante desenvolvimento é utilizar opções adequadas de compilação e runtime para ajudar a detectar referências fora dos limites.

Em ambientes Enterprise COBOL modernos, opções como verificação de limites podem transformar bugs misteriosos em diagnósticos muito melhores.

Ou seja:

debugabilidade também é uma decisão de compilação.

---

10. S0C4 não significa automaticamente “memória cheia”

Essa confusão merece destaque.

S0C4 não deve ser traduzido simplesmente como:

acabou memória.

Normalmente o raciocínio é mais próximo de:

ocorreu uma exceção relacionada ao acesso/proteção/endereço de storage.

É diferente de:

não há memória suficiente

Por isso precisamos ler as mensagens associadas e o dump.

O código do ABEND é uma pista.

Não é necessariamente o diagnóstico completo.

---

11. Terceiro jogo — SB37

Agora o míssil nuclear é substituído por algo aparentemente muito menos dramático:

um dataset.

O JOB escreve:

AAAA
BBBB
CCCC
...

E continua.

E continua.

Até o z/OS dizer:

SB37

Em termos simplificados:

o dataset ficou sem espaço disponível para continuar a alocação necessária.

É o equivalente mainframe daquele momento:

Disk full

Mas com detalhes importantes relacionados a datasets, volumes, extents e alocação.

---

12. SPACE no JCL — a pequena linha que pode derrubar o STEP

Observe:

//OUTFILE DD DSN=BELLACOSA.TESTE.OUT,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(TRK,(10,5)),
//            UNIT=SYSDA

Simplificando:

10 tracks = alocação primária
 5 tracks = incrementos secundários

Quando o dataset precisa crescer, o sistema tenta obter espaço adicional.

Se não conseguir continuar expandindo adequadamente, podemos encontrar situações como:

SB37

Há outros ABENDs relacionados a espaço, como:

SD37
SE37

E eles não devem ser tratados como absolutamente equivalentes.

Cada um fornece pistas sobre o que aconteceu durante a tentativa de alocação/extensão.

---

13. O erro nem sempre é “aumente o SPACE”

Aqui mora uma armadilha maravilhosa.

O programador vê:

SB37

e faz:

SPACE=(CYL,(9999,9999))

Problema resolvido?

Talvez.

Ou talvez tenha escondido algo muito pior.

Imagine que seu programa deveria escrever:

100.000 registros

mas devido a um loop:

PERFORM UNTIL EOF
    WRITE REG-SAIDA
END-PERFORM

o EOF nunca muda.

O programa escreve eternamente.

O dataset cresce.

Até acabar espaço.

O sintoma é:

SB37

Mas a causa lógica é:

LOOP INFINITO

Joshua está aprendendo.

E agora está fabricando registros em velocidade industrial.

---

14. Quarto jogo — S322

Se existe um código perfeito para um crossover entre JCL e WarGames, é:

S322

Em termos gerais, ele indica que o STEP excedeu determinado limite de tempo de execução permitido.

A imagem resume:

Job exceeded time limit.

Para o iniciante funciona.

Tecnicamente é bom lembrar que o problema normalmente é associado ao step/processamento e seu limite de CPU/tempo aplicável, não necessariamente ao JOB inteiro da forma genérica sugerida pela frase.

Uma causa clássica?

Loop.

PERFORM UNTIL WS-FIM = 'S'
    CONTINUE
END-PERFORM

Se:

WS-FIM

jamais se tornar:

S

parabéns.

Você inventou o moto-perpétuo COBOL.

O sistema, menos otimista, eventualmente intervém.

---

15. TIME no JCL

Podemos encontrar parâmetros como:

//STEP01 EXEC PGM=MEUPGM,TIME=5

O significado exato deve ser interpretado conforme a sintaxe e contexto do JCL, mas o ponto é que limites de execução podem existir.

Então, diante de S322, pergunte:

O programa entrou em loop?

O volume processado aumentou?

Existe READ que não avança?

Existe PERFORM sem saída?

Um SQL está extremamente custoso?

Houve mudança no comportamento de I/O?

O limite configurado é simplesmente inadequado para o workload?

Não conclua imediatamente:

“Preciso aumentar TIME.”

É o equivalente a descobrir que o carro está com acelerador preso e resolver o problema instalando um tanque de combustível maior.

---

16. O clássico loop de arquivo

Observe esta beleza:

PERFORM UNTIL WS-EOF = 'S'

    IF WS-TIPO = 'A'
       PERFORM PROCESSA-A
    END-IF

END-PERFORM.

Cadê o:

READ ARQUIVO

?

Joshua responde:

INTERESTING GAME.
THE ONLY WINNING MOVE IS TO READ THE NEXT RECORD.

---

17. Quinto jogo — S806

A imagem mostra:

806
Load module not found

Para nosso treinamento, vamos escrever corretamente o código de sistema como:

S806

Esse é um dos mais didáticos para entender a relação entre:

JCL
programa
load module
load library
STEPLIB
JOBLIB
link-edit

Imagine:

//STEP01 EXEC PGM=BELL001

O sistema precisa localizar um módulo executável chamado:

BELL001

Mas ele não aparece nas bibliotecas onde a busca está sendo realizada.

Resultado possível:

S806

---

18. “Mas o source existe!”

Essa frase já ecoou em milhares de CPDs:

— O programa existe! Estou vendo o membro no PDS!

Sim.

Mas você pode estar olhando para:

BELLACOSA.COBOL.SOURCE(BELL001)

Isso é source.

O sistema precisa executar o load module/program object correspondente.

Conceitualmente:

SOURCE
   |
   v
COMPILER
   |
   v
OBJECT
   |
   v
LINK-EDIT / BINDER
   |
   v
LOAD MODULE / PROGRAM OBJECT

Executar COBOL não significa o z/OS abrir seu source e interpretar:

MOVE A TO B

O programa precisa ter passado pelo processo necessário para produzir algo executável.

---

19. STEPLIB — o mapa que Joshua perdeu

Imagine:

//STEP01 EXEC PGM=BELL001
//STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR

Estamos indicando uma biblioteca onde o sistema poderá procurar o programa.

Agora imagine:

BELL001 está em:

BELLACOSA.LOAD.PROD

mas o JCL usa:

BELLACOSA.LOAD.TEST

Joshua procura.

Não encontra.

S806

Perguntas úteis:

O nome em PGM= está correto?

O módulo foi link-editado?

O binder terminou com sucesso?

O módulo está realmente nessa LOADLIB?

STEPLIB aponta para a biblioteca correta?

JOBLIB interfere na busca?

Existe diferença entre ambiente DEV, QA e PROD?

Uma nova versão foi compilada mas não implantada?

---

20. O grande mapa dos cinco ABENDs

Guarde esta associação inicial:

Código	Pense primeiro em
S0C4	acesso/endereço/proteção de storage
S0C7	dados numéricos inválidos / data exception
SB37	problema de espaço/extensão de dataset
S322	limite de execução/tempo excedido
S806	programa/load module não localizado

Mas acrescente mentalmente:

“Pense primeiro em...”

e não:

“A causa obrigatoriamente é...”

Essa diferença separa troubleshooting de superstição.

---

21. O verdadeiro professor chama-se JES

Depois do ABEND, uma das primeiras paradas costuma ser a saída do JOB.

No universo z/OS, frequentemente estamos navegando por elementos como:

JES2
SDSF
JESMSGLG
JESJCL
JESYSMSG
SYSOUT
SYSPRINT
CEEDUMP
SYSUDUMP
SYSABEND

Nem todos aparecerão em todos os casos.

Mas isso cria uma regra:

Nunca investigue um ABEND olhando apenas para o código final.

Leia as mensagens próximas ao momento da falha.

Por exemplo:

IEF...
IGD...
IEC...
CEE...
IGZ...

Os prefixos das mensagens já podem indicar qual componente está conversando com você.

O z/OS é quase uma cidade onde cada repartição começa suas cartas com uma assinatura diferente.

---

22. SDSF — nossa sala de guerra

O Padawan abre o SDSF.

Entra no painel de jobs.

Localiza:

COBTST1

E começa a investigação.

Fluxo mental:

ST
 |
 +--> localizar JOB
       |
       +--> verificar RC / ABEND
             |
             +--> localizar STEP
                   |
                   +--> mensagens
                         |
                         +--> SYSOUT
                               |
                               +--> dump

A pergunta não é:

“Onde está escrito S0C7?”

A pergunta é:

“O que estava acontecendo imediatamente antes do S0C7?”

---

23. Procure o STEP, não apenas o JOB

Imagine:

//JOB01 JOB ...
//STEP10 EXEC PGM=PROGA
//STEP20 EXEC PGM=PROGB
//STEP30 EXEC PGM=PROGC

Resultado:

STEP10 RC=0000
STEP20 ABEND=S0C7
STEP30 FLUSH

Temos uma informação gigantesca:

PROGA provavelmente terminou
PROGB falhou
PROGC nem executou

Então não comece depurando PROGC.

Parece óbvio.

Sob pressão de produção às 02:37, deixa de ser.

---

24. Cond code e ABEND não são irmãos gêmeos

Outro conceito importante.

Um programa pode terminar:

RC=0000

Outro:

RC=0004

Outro:

RC=0008

Outro pode sofrer:

ABEND S0C7

Return codes são definidos/conduzidos pelo software conforme sua lógica e convenções.

ABENDs representam término anormal.

Por exemplo, COBOL pode fazer:

MOVE 8 TO RETURN-CODE
GOBACK

O programa terminou deliberadamente com RC 8.

Isso não é igual a sofrer uma exceção e acabar em S0C7.

---

25. E o misterioso Uxxxx?

Nem todo ABEND começa com S.

Você também poderá encontrar algo como:

U4038

O U remete a user abend.

Ou seja, o término foi solicitado por software/aplicação/runtime em determinada condição.

Um clássico em ambientes Language Environment pode envolver códigos dessa família associados a erros detectados durante execução.

Isso nos dá dois grandes mundos conceituais:

Sxxx = System completion code
Uxxxx = User completion code

Para o Padawan, essa distinção já vale ouro.

---

26. Dump — a autópsia do programa

Um dump pode parecer inicialmente uma espécie de pergaminho Sith:

PSW
GPR0
GPR1
GPR2
...
OFFSET
TRACEBACK
STORAGE
HEX
MODULE

O iniciante pensa:

— Preciso aprender hexadecimal, assembler e arquitetura z/Architecture inteira antes de corrigir meu COBOL?

Não.

Mas, conforme você evolui, aprender a ler informações de dump muda radicalmente sua capacidade de suporte.

Procure inicialmente:

Nome do programa
Código do ABEND
Offset
Statement
Entry point
Call chain
Variáveis relevantes
Mensagem do runtime

Compilação com informações adequadas de debug pode permitir uma correlação muito melhor entre:

OFFSET

e:

linha COBOL

Essa é uma das grandes vantagens de manter listings de compilação.

---

27. Nunca jogue fora o compile listing

O compile listing parece inútil enquanto tudo funciona.

Quando o programa cai em produção:

OFFSET +00001A72

de repente aquele listing vira o Santo Graal.

Dependendo das opções e tooling utilizados, ele pode ajudar a relacionar:

offset
paragraph
statement
generated code
data definitions

Por isso equipes maduras conservam artefatos apropriados das builds.

Não somente:

SOURCE.COBOL

Mas também aquilo que permite provar:

qual versão foi compilada, como foi compilada e qual executável foi gerado.

Isso é DevOps antes de DevOps receber esse nome.

---

28. Curiosidade Bellacosa — ABEND é quase uma filosofia operacional

Mainframes nasceram em um mundo em que jobs podiam processar volumes enormes sem alguém olhando continuamente para a tela.

Logo o sistema precisava dizer precisamente:

terminou?

Se sim:

como terminou?

E se algo deu errado:

por quê?

Por isso temos uma cultura inteira ao redor de:

completion codes
return codes
messages
logs
dumps

Cloud, Kubernetes e observabilidade moderna redescobriram ideias semelhantes com:

exit codes
logs
events
traces
metrics
crash dumps
health checks

O CPD de 1975 provavelmente reconheceria muita coisa em uma War Room de 2026.

Só perguntaria por que colocaram emojis no dashboard.

---

29. Método Bellacosa de sete perguntas

Quando um programa cair, faça estas perguntas nesta ordem:

1. Qual JOB falhou?

JOBNAME?
JOBID?

2. Qual STEP falhou?

STEP10?
STEP20?
PROCSTEP?

3. Qual programa estava rodando?

PGM=?

4. Qual foi o ABEND?

S0C7?
S0C4?
S806?
...

5. Que mensagens apareceram antes e depois?

Não leia apenas uma linha.

Contexto importa.

6. Qual foi a última alteração?

Pergunta brutalmente poderosa:

Novo source?
Novo copybook?
Novo arquivo?
Novo JCL?
Nova loadlib?
Novo volume de dados?
Nova versão do compilador?

7. Consigo reproduzir?

O problema reproduzível deixa de ser fantasma.

Vira experimento.

---

30. O jogo mais perigoso chama-se “tentar coisas”

Joshua apresenta:

S0C7

O programador altera:

REGION=0M

Não resolveu.

Aumenta SPACE.

Não resolveu.

Troca DISP.

Não resolveu.

Recompila.

Não resolveu.

Executa novamente.

Não resolveu.

Troca a STEPLIB.

Agora surge:

S806

Parabéns.

Transformamos um incidente em dois.

Troubleshooting profissional segue hipóteses:

EVIDÊNCIA
   ↓
HIPÓTESE
   ↓
TESTE
   ↓
RESULTADO
   ↓
CONCLUSÃO

Não:

ABEND
 ↓
PÂNICO
 ↓
ALTERA TUDO
 ↓
REZA

---

31. Easter egg — Joshua encontra o JCL

Joshua pergunta:

SHALL WE PLAY A GAME?

O operador responde:

//WARGAME JOB (NORAD),'JOSHUA',
//        CLASS=A,
//        MSGCLASS=X
//STEP01 EXEC PGM=WOPR
//STEPLIB DD DSN=NORAD.DEFENSE.LOAD,DISP=SHR
//INPUT   DD *
GLOBAL THERMONUCLEAR WAR
/*

JES2:

JOB SUBMITTED

Três segundos depois:

IEF450I WARGAME STEP01 - ABEND=S806

Operador:

— Graças a Deus esqueceram de instalar o load module.

Às vezes um S806 salva a humanidade.

---

32. O exercício do Padawan — provoque um erro controladamente

Em laboratório, entender falhas controladas é excelente treinamento.

Nunca faça isso em produção.

Crie programas simples destinados especificamente a estudar:

S0C7
limites de OCCURS
arquivo crescendo
loops
STEPLIB incorreta

A ideia não é memorizar cinco códigos.

É aprender a cadeia:

CÓDIGO
   ↓
COMPILAÇÃO
   ↓
LINK
   ↓
JCL
   ↓
EXECUÇÃO
   ↓
JES
   ↓
ABEND
   ↓
DIAGNÓSTICO

Quando você entende a cadeia, dezenas de códigos deixam de parecer mágicos.

---

33. Laboratório mental 1 — S0C7

Você tem:

01 WS-TOTAL PIC S9(7)V99 COMP-3.

O programa sofre:

S0C7

Pergunte:

Quem escreveu nessa área?

Foi MOVE?

Foi arquivo?

Foi Db2?

Foi outra estrutura?

Existe REDEFINES?

O copybook coincide com o registro físico?

Não olhe apenas para:

ADD WS-TOTAL TO ...

A instrução pode ser apenas a vítima que encontrou o cadáver.

---

34. Laboratório mental 2 — S0C4

Programa cai após:

MOVE WS-TABELA(WS-I) TO WS-SAIDA

Pergunte imediatamente:

Qual valor de WS-I?

Qual OCCURS?

Existe DEPENDING ON?

Existe subscript fora da faixa?

Alguma área foi sobrescrita?

Existe CALL utilizando parâmetros incorretos?

Interfaces entre programas são particularmente interessantes.

Se:

CALL 'PGM2' USING A B C

mas PGM2 interpreta parâmetros incompatíveis, podemos produzir estragos memoráveis.

---

35. Laboratório mental 3 — SB37

Dataset lotou.

Antes de simplesmente aumentar espaço, verifique:

Quantos registros eram esperados?

Quantos foram escritos?

LRECL?

RECFM?

SPACE?

Primário/secundário?

Volume disponível?

Extents?

Houve crescimento anormal?

Se ontem o arquivo tinha:

500 MB

e hoje tentou chegar a:

80 GB

não comece culpando o storage.

Pergunte por quê.

---

36. Laboratório mental 4 — S322

Pergunte:

Onde o programa estava?

Quantos registros processou?

Existe progresso no contador?

READ avança?

Cursor Db2 avança?

Laço tem condição de saída?

Foi aumento legítimo de workload?

Um contador de diagnóstico pode ajudar enormemente em desenvolvimento:

ADD 1 TO WS-CONTADOR

IF FUNCTION MOD(WS-CONTADOR 10000) = 0
   DISPLAY 'PROCESSADOS: ' WS-CONTADOR
END-IF

Não necessariamente colocaríamos exatamente isso em toda produção eternamente.

Mas como técnica de investigação, observar progresso é ouro.

---

37. Laboratório mental 5 — S806

Seu JCL:

//STEP01 EXEC PGM=ABC123

Cheque:

ABC123 existe?

Foi bindado/link-editado?

Está na biblioteca correta?

STEPLIB está certa?

O módulo tem esse nome?

Deploy ocorreu?

Existe alias?

Ambiente está apontando para QA ou DEV?

Um detalhe delicioso:

o source pode chamar-se:

PROGRAMA1

e o executável implantado possuir outro nome conforme processo de build.

Nunca presuma.

Verifique.

---

38. ABEND também ensina arquitetura

Esses cinco códigos parecem erros isolados.

Mas observe o que aprendemos:

S0C7

Ensina:

representação de dados
PIC
COMP-3
layouts
copybooks

S0C4

Ensina:

storage
endereçamento
arrays
CALL
memória

SB37

Ensina:

datasets
DASD
SPACE
extents
JCL

S322

Ensina:

CPU
loops
execução batch
limites
performance

S806

Ensina:

build
binder
load libraries
STEPLIB
execução

Ou seja:

estudar ABEND é estudar o próprio mainframe.

---

39. O erro moderno: pedir imediatamente à IA

Em 2026 temos outra personagem sentada na sala do WOPR.

O programador copia:

ABEND S0C7

para uma IA e pergunta:

“Corrija meu programa.”

A IA pode explicar brilhantemente as causas comuns.

Mas faltam informações.

Ela não viu:

dump
layout
input
listing
JCL
alteração recente
conteúdo hexadecimal

A pergunta melhor seria:

Meu STEP STEP20 executando programa FATU001
terminou com S0C7.

O dump aponta para o statement 1487.
A variável usada é WS-VALOR PIC S9(7)V99 COMP-3.
O valor veio do campo ARQ-VALOR de um copybook alterado ontem.

Quais hipóteses devo testar?

Agora existe contexto.

IA não elimina troubleshooting.

Ela pode acelerar troubleshooting bem feito.

---

40. Nunca coloque dados sensíveis do dump em qualquer IA pública

Aqui aparece nosso RACF imaginário.

Dumps podem conter:

nomes
contas
identificadores
dados financeiros
credenciais
tokens
dados pessoais
informações de infraestrutura

Portanto:

sanitizar dados faz parte do diagnóstico moderno.

Não copie um dump de produção inteiro para um serviço externo apenas porque quer descobrir um S0C7.

Joshua pode ser simpático.

Compliance talvez não seja.

---

41. O pequeno dicionário do sobrevivente

O Padawan deve reconhecer:

ABEND

Término anormal.

RC

Return Code.

CC

Condition Code, dependendo do contexto.

STEP

Unidade executável de um JOB.

SYSOUT

Saída gerada durante execução.

DUMP

Estado capturado para diagnóstico.

LOADLIB

Biblioteca contendo programas executáveis.

STEPLIB

DD utilizado para definir bibliotecas privadas de busca para aquele step.

JOBLIB

Biblioteca de busca aplicável aos steps do job dentro das regras pertinentes.

SPACE

Parâmetro relacionado à alocação de espaço do dataset.

OCCURS

Estrutura de repetição/tabela COBOL.

COMP-3

Representação decimal packed.

---

42. Uma rotina realista de incidente

Agora estamos às 03:00.

Produção.

JOB:

FATUR001

falhou.

Passo a passo:

1. Abrir SDSF

Encontrar:

FATUR001

2. Identificar step

Resultado:

STEP040

3. Identificar programa

FATU847

4. Identificar falha

S0C7

5. Ler mensagens

Buscar runtime/dump.

6. Identificar statement/offset

Suponha:

PARAGRAPH CALCULA-TOTAL

7. Identificar operandos

VALOR-BRUTO
TAXA
TOTAL

8. Inspecionar dados

Descobre-se que VALOR-BRUTO contém representação inválida.

9. Descobrir origem

Veio do arquivo produzido por STEP030.

10. Descobrir alteração

Copybook mudou ontem.

Agora temos causa provável.

Não:

“COBOL é antigo.”

Não:

“mainframe travou.”

Não:

“Db2 está estranho.”

Temos evidência.

---

43. O detalhe mais importante: encontre a causa raiz

Imagine que corrigimos um registro manualmente.

JOB roda.

Vitória?

Ainda não.

Precisamos perguntar:

Por que aquele registro ficou inválido?

Talvez:

programa produtor incorreto
copybook incompatível
deploy parcial
arquivo antigo
campo não inicializado
erro de interface
conversão equivocada

Caso contrário, amanhã:

S0C7

volta.

E Joshua pergunta novamente:

SHALL WE PLAY A GAME?

---

44. Prevenindo em vez de apenas corrigindo

O Jedi Mainframe não é aquele que conhece 500 ABEND codes de cabeça.

É aquele que cria sistemas que fornecem evidências boas.

Algumas práticas:

• mantenha listings e artefatos de build;

• versionamento de source e copybooks;

• valide layouts;

• controle deploy de load modules;

• adote testes;

• use opções de compilação apropriadas;

• registre entradas críticas;

• monitore crescimento de datasets;

• monitore CPU e elapsed time;

• trate arquivos e SQLCODE corretamente;

• mantenha documentação de JCL;

• preserve rastreabilidade entre source e executável.

A maior evolução acontece quando o sistema deixa de responder apenas:

DEU ERRO

e começa a responder:

ONDE
QUANDO
COM QUAL DADO
EM QUAL VERSÃO
DEPOIS DE QUAL ALTERAÇÃO

Isso é observabilidade.

---

45. Curiosidade — o mainframe já fazia “observabilidade” quando a palavra nem era moda

Hoje ouvimos:

logs
metrics
traces
telemetry
observability

O ecossistema mainframe possui há décadas uma enorme cultura de:

SMF
JES logs
system messages
dumps
accounting
performance data
audit records

Não são exatamente a mesma coisa das stacks modernas, claro.

Mas a filosofia é familiar:

um sistema crítico precisa deixar rastros suficientes para explicar o que aconteceu.

Os hipsters do Kubernetes descobriram o SYSOUT.

Só trocaram a fonte verde por Grafana.

---

46. A regra WarGames do ABEND

No final de WarGames, Joshua aprende algo fundamental examinando todas as possibilidades.

No mainframe, o programador também precisa parar de jogar:

“Qual alteração aleatória fará o JOB ficar verde?”

O jogo correto é:

“Qual evidência explica por que ele ficou vermelho?”

São filosofias completamente diferentes.

A primeira produz:

tentativa
erro
tentativa
erro
tentativa
milagre

A segunda produz:

observação
hipótese
teste
causa
correção
prevenção

---

47. Cheatsheet do Padawan

Quando aparecer:

S0C7

Pense:

DADO NUMÉRICO INVÁLIDO

Procure:

COMP-3
MOVE
arquivo
copybook
REDEFINES
layout
campo não inicializado

S0C4

Pense:

ACESSO/ENDEREÇO DE STORAGE

Procure:

OCCURS
subscript
index
CALL
ponteiros/referências
área sobrescrita

SB37

Pense:

ESPAÇO DO DATASET

Procure:

SPACE
volume
extents
crescimento
loop de escrita

S322

Pense:

TEMPO/EXECUÇÃO EXCESSIVA

Procure:

loop
READ
volume
SQL
CPU
condição de saída

S806

Pense:

PROGRAMA NÃO ENCONTRADO

Procure:

PGM=
STEPLIB
JOBLIB
LOADLIB
binder
deploy
nome do módulo

---

48. O mapa completo

Nossa aventura começou com cinco códigos.

Mas agora eles formam uma pequena arquitetura:

                    +------------------+
                    |       JOB        |
                    +--------+---------+
                             |
                             v
                    +------------------+
                    |       JCL        |
                    +--------+---------+
                             |
            +----------------+----------------+
            |                                 |
            v                                 v
       +---------+                       +-----------+
       | PROGRAM |                       | DATASETS  |
       +----+----+                       +-----+-----+
            |                                  |
            |                                  +--> SB37
            |
            +--> dados inválidos ------------> S0C7
            |
            +--> storage inválido -----------> S0C4
            |
            +--> loop/tempo -----------------> S322

      Antes de executar:
             |
             +--> módulo ausente ------------> S806

Esse desenho vale mais do que decorar uma tabela.

Ele mostra onde procurar.

---

49. Easter egg final — WOPR pede acesso à produção

Joshua:

ACCESS PRODUCTION?

RACF:

ICH408I USER(JOSHUA) GROUP(NORAD)
  INSUFFICIENT ACCESS AUTHORITY

Joshua:

A STRANGE GAME.
THE ONLY WINNING MOVE IS NOT TO DEPLOY ON FRIDAY.

O sysprog lentamente fecha o terminal.

O Padawan COBOL anota no caderno:

REGRA 1:
NUNCA CONFUNDIR S0C7 COM SOC7.

REGRA 2:
LER O JES.

REGRA 3:
OLHAR O STEP.

REGRA 4:
NÃO ALTERAR TUDO AO MESMO TEMPO.

REGRA 5:
DESCOBRIR CAUSA RAIZ.

REGRA 6:
NÃO DAR UPDATE EM PRODUÇÃO PARA JOSHUA.

Essa última não está no manual IBM.

Mas deveria.

---

Epílogo — a única jogada vencedora é aprender a ler a evidência

No início desta viagem, aqueles códigos pareciam mensagens criptografadas:

S0C4
S0C7
SB37
S322
S806

Agora podemos enxergá-los como pistas.

S0C4 pode nos levar ao mundo de storage e endereçamento.

S0C7 nos obriga a entender representação numérica, COMP-3, layouts e dados.

SB37 abre a porta para datasets, DASD e alocação.

S322 ensina sobre execução, loops, CPU e limites.

S806 revela toda a cadeia de compilação, binder, LOADLIB, STEPLIB e deploy.

E talvez esta seja a maior lição para quem começa em COBOL:

um ABEND não é apenas um erro.

É uma aula de arquitetura embrulhada em uma mensagem desagradável.

O programador iniciante olha:

JOB ABENDED

e pensa:

“Algo quebrou.”

O programador experiente olha a mesma mensagem e pergunta:

Qual JOB?
Qual STEP?
Qual programa?
Qual código?
Qual mensagem?
Qual offset?
Qual dado?
Qual versão?
O que mudou?

Essa mudança de mentalidade é gigantesca.

Porque mainframe não exige que você conheça todas as respostas.

Ele exige que você saiba onde procurar as perguntas certas.

Joshua finalmente apaga da tela:

GLOBAL THERMONUCLEAR WAR

e escreve:

S0C7 DIAGNOSTIC LAB

O Padawan toma um gole de café.

— Podemos jogar.

Joshua responde:

EXCELLENT.

PLEASE PROVIDE:
JOBNAME
STEPNAME
PROGRAM NAME
ABEND CODE
COMPILE LISTING
DUMP

O Padawan sorri.

Agora sim.

Não temos mais um jogador apertando botões aleatórios.

Temos um programador mainframe investigando uma falha.

E no Bellacosa Mainframe, essa é a diferença entre alguém que simplesmente executa COBOL...

...e alguém que começa realmente a entender z/OS.

☕ Fim de JOB.

IEF142I WARGAME STEP99 - STEP WAS EXECUTED - COND CODE 0000

A humanidade sobreviveu.

E melhor ainda:

o Padawan aprendeu a abrir o SDSF antes de culpar o mainframe.