 |
| Bellacosa Mainframe explica rtm o grande guarda-costas. |
🔥 COBOL NÃO QUEBROU… FOI O RTM QUE DECIDIU O DESTINO
Se você trabalha com COBOL há anos, já viu isso acontecer:
💥 S0C7
💥 S0C4
💥 S878
…e aquele silêncio constrangedor no batch.
E aí vem a pergunta clássica:
👉 “O que aconteceu?”
Errado.
A pergunta certa é:
🧠 “O que o z/OS fez quando isso aconteceu?”
Porque no exato momento do ABEND…
quem assume o controle não é o seu programa.
É o RTM — Recovery Termination Manager.
🧠 O RTM: o juiz invisível do seu programa
O RTM é um componente do z/OS que entra em ação sempre que algo relevante acontece:
- ✔️ Erro
- ✔️ Falha
- ✔️ Terminação normal (sim!)
👉 Ele é responsável por:
- Capturar o erro
- Tentar recuperar
- Decidir o destino
- Registrar tudo
💡 Tradução Bellacosa:
🔥 “O RTM é quem decide se seu programa vive… ou vira dump.”
🚨 Quando o ABEND acontece (o bastidor real)
Você vê:
S0C7 – erro de dados
O RTM vê:
- Tipo de exceção
- Estado da CPU (PSW)
- Registradores
- Control blocks
- Contexto da task
👉 E imediatamente inicia o fluxo:
Erro → RTM → Recovery → Decisão → Dump → Investigação
💡 Isso acontece em milissegundos.
⚙️ Os serviços do RTM (o que ele realmente faz)
1️⃣ Captura do erro (o “detetive”)
O RTM intercepta:
- Program checks (S0C4, S0C7…)
- I/O errors
- Machine checks
- Falhas de memória
👉 Ele coleta o estado completo do sistema.
💡 Easter egg:
O SDWA é criado aqui — é literalmente o “snapshot do crime”.
2️⃣ Tentativa de recuperação (o “paramédico”)
Aqui entram os famosos:
- ESTAE → nível da aplicação
- FRR → nível do sistema
👉 O RTM pergunta:
“Alguém consegue salvar isso?”
💡 Curiosidade:
- Muitos sistemas robustos usam ESTAE para evitar queda total
- COBOL “puro” raramente usa diretamente… mas se beneficia disso sem saber
3️⃣ Decisão (o “juiz”)
Depois da tentativa:
- Continua execução?
- Finaliza a task?
- Derruba o address space?
👉 Essa decisão é crítica.
💡 Insight:
Nem todo erro vira ABEND visível — alguns são absorvidos
4️⃣ Geração de evidência (o “perito”)
O RTM gera:
- SYSUDUMP / SYSABEND / SYSMDUMP
- SVC dump
- LOGREC
👉 Isso vira seu material de análise.
💡 Frase forte:
Sem dump, você está cego.
🧹 RTM também limpa a bagunça (e isso é pouco falado)
Agora vem o que pouca gente sabe:
🔥 O RTM também atua quando TUDO DÁ CERTO
Quando seu job termina normalmente:
- Fecha datasets
- Libera memória
- Cancela timers
- Remove enqueues
- Limpa control blocks
👉 Isso é feito de forma extremamente eficiente.
💡 Comentário Bellacosa:
“Se o RTM não limpasse… o z/OS virava um lixão em minutos”
🧩 RTM1 vs RTM2 (nível raiz)
🔹 RTM1 (System Level)
- Falhas do sistema
- Interface com FRR
🔹 RTM2 (Task Level)
- Programas (COBOL aqui 👈)
- Interface com ESTAE
👉 Fluxo clássico:
Erro
↓
RTM1
↓
FRR
↓
RTM2
↓
ESTAE
↓
Decisão
💡 Isso é arquitetura de verdade.
📦 Dumps: o presente que ninguém quer… mas precisa
Tipos que você já viu:
- SYSUDUMP → básico
- SYSABEND → completo
- SYSMDUMP → raiz (hex)
👉 E os de sistema:
- SVC Dump
- Standalone Dump
💡 Dica prática:
🔥 “Se o problema é estranho… peça SYSMDUMP”
🗂️ LOGREC: o histórico que salva sua vida
LOGREC guarda:
- Erros de hardware
- Eventos do sistema
- Condições críticas
💡 Dica de ouro:
👉 Sempre comece por LOGREC antes do dump
🧠 SLIP e DAE (nível ninja)
🔹 SLIP
- Armadilha de erro
- Dispara dump sob condição
🔹 DAE
- Evita dumps duplicados
💡 Produção sem isso:
caos + storage cheio
💥 Aplicação prática (COBOL raiz)
S0C7 — o clássico
👉 Normalmente:
- Dado inválido em campo numérico
Mas o RTM te dá:
- Instrução que falhou
- Endereço
- Conteúdo do campo
💡 Dica prática:
- Veja PSW
- Ache a instrução
- Verifique o dado
- Volte no código
🧠 Insight final (o que separa níveis)
❌ Júnior: “Deu S0C7”
❌ Pleno: “Campo inválido”
✅ Sênior: “Eu sei exatamente onde e por quê”
🏁 Conclusão (sem mimimi)
O RTM é:
- 🔥 O guardião da estabilidade
- 🔍 O perito do erro
- ⚖️ O juiz da execução
- 🧹 O faxineiro do sistema
💬 Frase pra levar pra vida
“COBOL não quebra…
o RTM só revela o que já estava errado.”
