Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

• sobem pra memória
• descem pra disco
• migram pra fita
• aparecem em outro LPAR
• e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥

---

🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.

---

🔥 O que isso significa?

• memória protegida
• ambiente independente
• controle total do sistema

---

💡 Insight

cada address space é um “universo privado”

---

⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES

---

🔥 Evolução histórica

Era	Limite
24-bit	16MB 😱
31-bit	2GB
👉 64-bit	16EB 🤯

---

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”

---

🧠 Uso real

• Java
• Db2
• middleware
• grandes buffers

---

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real

---

🔥 Sem DAT:

• programa quebraria
• memória não funcionaria

---

💡 Tradução

“você nunca acessa memória real diretamente”

---

🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

• GETMAIN
• STORAGE OBTAIN

---

🔥 O sistema decide:

• onde alocar
• em qual subpool
• com qual proteção

---

💡 Insight

memória é gerenciada, não livre

---

🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools

---

🔥 Exemplos:

• SP0 → sistema
• SP229 → usuário

---

💡 Tradução

“cada tipo de dado tem seu bairro”

---

🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

• dados fora do address space
• acessados via AR

---

🔹 Hiperspaces

• alta performance
• acesso indireto

---

🔥 Tradução Bellacosa

“memória extra fora do seu universo”

---

🧠 Exemplo

Programa → usa Data Space → grande volume de dados

---

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)

---

🔥 Fluxo

Memória cheia
 ↓
página vai para DASD
 ↓
quando necessário → volta

---

💡 Problema

👉 excesso de paging = sistema lento 💀

---

💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

• baixa latência
• alta velocidade
• ideal para OLTP

---

💡 Uso

• Db2
• logs
• datasets críticos

---

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄

---

🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema

---

💡 Elementos:

• LPARs
• Coupling Facility (CF)
• links de comunicação

---

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

---

💡 Tradução

“dados compartilhados em tempo real”

---

🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

• lock management
• cache
• filas

---

🔥 Tipos:

• Internal CF
• External CF

---

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”

---

⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

• duplica dados
• garante disponibilidade

---

💡 Exemplo

CF primário → falha
CF secundário → assume

---

🧨 Curiosidade

Sistema continua rodando sem impacto 😳

---

🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

• locks
• buffers
• filas

---

💡 Uso real

• Db2 data sharing
• CICS
• IMS

---

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

---

💡 Insight

performance é resultado do conjunto

---

🔄 14. PASSO A PASSO COMPLETO

Programa inicia
 ↓
recebe address space
 ↓
pede memória (GETMAIN)
 ↓
DAT traduz endereço
 ↓
usa data space se necessário
 ↓
paging ocorre se faltar memória
 ↓
dados vão para disco/flash
 ↓
sysplex compartilha dados via CF
 ↓
duplex garante disponibilidade

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está

---

🔥 2. Dados podem estar fora do seu address space

---

💀 3. Paging excessivo mata performance

---

🧠 4. Sysplex permite vários sistemas compartilharem dados

---

⚡ 5. CF é o segredo da alta disponibilidade

---

🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência

---

💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

 

Bellacosa Mainframe e o servidor web dentro Mainframe

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳

IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

Se você ainda acha que mainframe é “tela verde + batch”…
👉 você está anos atrás.

Existe um componente rodando silenciosamente no z/OS que transforma:

COBOL legado → API moderna → web → mobile → cloud

Esse cara é o IBM HTTP Server (IHS).
E hoje você vai entender como ele funciona de verdade — no estilo Bellacosa 👊🔥

---

🌐 O QUE É O IBM HTTP SERVER?

O IHS (IBM HTTP Server) é o web server oficial da IBM.

👉 Baseado no Apache, mas com:

• integração com z/OS
• segurança enterprise (RACF)
• performance absurda

---

💡 Tradução direta:

“É o Apache… só que preparado pra rodar num banco de bilhões.”

---

🧠 COMO ELE FUNCIONA (VISÃO REAL)

Quando alguém acessa:

https://empresa.com/api/clientes

Acontece isso:

Cliente (browser/app)
   ↓
IBM HTTP Server (z/OS)
   ↓
Backend (CICS / COBOL / DB2)
   ↓
Resposta HTTP

---

🔥 Insight importante

O IHS NÃO executa COBOL diretamente.

Ele:

• recebe requisição
• encaminha para outro componente (ex: CICS, WAS)
• devolve resposta

---

🏗️ ARQUITETURA TÍPICA

Internet
   ↓
IHS (porta 80/443)
   ↓
WebSphere / z/OS Connect
   ↓
COBOL / CICS / DB2

---

⚙️ INSTALAÇÃO (nível z/OS raiz)

🔹 Requisitos básicos

• z/OS instalado
• TCP/IP ativo
• USS (UNIX System Services)
• Dataset do produto (SMP/E)

---

🔥 Onde ele vive?

👉 No USS (Unix do z/OS)

Exemplo de path:

/usr/lpp/ihs

---

💡 Insight

Se não conhece USS… já começou errado no mundo moderno do mainframe.

---

📦 INSTALAÇÃO via SMP/E

Resumo do processo:

1. RECEIVE
2. APPLY
3. ACCEPT

👉 padrão IBM para software

---

⚙️ CONFIGURAÇÃO

Arquivo principal:

httpd.conf

---

🔹 Exemplo simples

Listen 8080

ServerName localhost

DocumentRoot "/u/ihs/htdocs"

<Directory "/u/ihs/htdocs">
    AllowOverride None
    Require all granted
</Directory>

---

💡 Tradução

• porta → onde escuta
• document root → onde estão arquivos
• directory → permissões

---

🚀 EXECUÇÃO NO z/OS

Você pode iniciar via:

🔹 USS (direto)

apachectl start

---

🔹 Ou via JCL (mainframe raiz 👇)

//IHSSTART JOB ...
//STEP1 EXEC PGM=BPXBATCH
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDPARM DD *
SH /usr/lpp/ihs/bin/apachectl start
/*

---

🔥 Tradução Bellacosa

JCL chama UNIX… que sobe o servidor web 😳

---

🧪 TESTES (o momento da verdade)

Após subir:

🔹 Teste básico

curl http://localhost:8080

---

🔹 Ou browser:

http://hostname:8080

---

🧩 INTEGRAÇÃO COM COBOL

🔥 Cenário real

Você tem:

• programa COBOL em CICS

Quer expor como API:

👉 Caminho:

IHS → z/OS Connect → CICS → COBOL

---

💡 Resultado

• COBOL vira REST API
• JSON entra / sai
• mundo moderno conversa com legado

---

🔐 SEGURANÇA

🔹 Recursos:

• SSL/TLS
• certificados digitais
• integração com RACF

---

🧨 Easter Egg

Você pode proteger endpoint HTTP com regras RACF.

👉 Sim, segurança de banco direto na web.

---

⚡ PERFORMANCE

🔥 Diferenciais no z/OS:

• alta disponibilidade
• integração com sistema
• throughput absurdo

---

💡 Insight

O gargalo raramente é o IHS…
geralmente é o backend (COBOL/DB2)

---

🧨 CURIOSIDADES (nível Bellacosa)

🧠 1. Apache dentro do mainframe

Sim, mas adaptado e otimizado.

---

🔥 2. COBOL pode responder HTTP

Com ajuda de outros componentes.

---

💀 3. Web pode rodar sem sair da máquina

Com HiperSockets (memória ↔ memória).

---

🤯 4. Você pode ter API moderna…

rodando código de 30 anos.

---

⚠️ PROBLEMAS COMUNS

• porta já em uso
• erro de permissão USS
• SSL mal configurado
• backend não responde

---

🧠 DICAS DE OURO

💡 Dica 1

Sempre valide:

netstat -a | grep 8080

---

💡 Dica 2

Logs são sua vida:

logs/error_log
logs/access_log

---

💡 Dica 3

Entenda o fluxo completo

IHS raramente é o problema — ele só repassa.

---

🎯 RESUMO FINAL

✔ IHS = web server do z/OS

✔ Baseado em Apache

✔ Roda no USS

✔ Integra com COBOL via outros serviços

✔ Permite API, web e cloud

---

💥 FRASE FINAL

“O IBM HTTP Server é o tradutor…
que faz o mundo moderno entender o que o COBOL sempre soube fazer.”

 

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI! O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

 

Bellacosa Mainframe fala sobre z/OS system Service Structure

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI!
O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

---

Se você é dev COBOL raiz, daqueles que já tomou S0C7 no café da manhã e resolveu com dump na unha… segura essa:

👉 Existe uma camada no z/OS que você usa o tempo todo…
👉 Mas quase ninguém entende de verdade…
👉 E ela decide TUDO — do I/O ao ABEND.

Bem-vindo à z/OS System Services Structure.

---

🧠 O QUE É ESSA TAL DE STRUCTURE?

Pensa no z/OS como uma cidade:

• Você (COBOL) → é o cidadão
• JCL → é o pedido formal
• JES2 → é o correio
• E o System Services?
  👉 É a prefeitura, polícia, energia, trânsito e bombeiros… TUDO JUNTO.

É a estrutura que fornece serviços fundamentais como:

• Gerenciamento de tarefas (Task Management)
• Comunicação entre programas
• Gerenciamento de memória
• I/O (entrada/saída)
• Tratamento de erros (ABENDs 👀)

---

⚙️ A ESTRUTURA NA PRÁTICA (SEM MIMIMI)

Aqui entra o coração técnico que muita gente ignora:

🔹 Control Blocks (os “documentos secretos”)

• TCB (Task Control Block) → representa uma task
• ASCB (Address Space Control Block) → representa o espaço de endereçamento
• RB (Request Block) → encadeamento de chamadas

💡 Easter egg:
Se você já viu um dump com “TCB=…” e ignorou…
👉 você literalmente ignorou o “RG” da sua task.

---

🔹 Dispatcher (o maestro invisível)

• Decide qual task roda
• Gerencia prioridade
• Alterna contexto

💬 Comentário Bellacosa-style:

“Se seu programa está ‘lento’, talvez o problema não seja o COBOL…
é o dispatcher dizendo: calma campeão, tem fila 😎”

---

🔹 SVC (Supervisor Call)

• Porta de entrada para serviços do sistema
• Tudo passa por aqui

👉 Quando seu COBOL faz I/O, quem resolve não é ele…
é o z/OS via SVC.

💡 Curiosidade:
SVC é tipo syscall no Linux… só que com terno e gravata 👔

---

💥 ONDE ISSO TE PEGA (E VOCÊ NEM SABIA)

Se liga nesses cenários:

• ABEND estranho sem causa aparente
• Programa “travando” sem loop
• I/O lento do nada
• Problemas intermitentes

👉 90% das vezes… está ligado ao System Services, não ao seu código.

---

🧩 COMO TUDO SE CONECTA (VISÃO RAIZ)

Fluxo simplificado:

1. Seu COBOL executa
2. Precisa de recurso (I/O, memória, etc)
3. Chama um serviço via SVC
4. System Services aciona control blocks
5. Dispatcher decide quando executar
6. Resultado volta pra sua aplicação

👉 Se algo falhar nesse caminho…
💥 ABEND na sua cara

---

🧠 GUIA DE ESTUDO (MODO GUERREIRO MAINFRAME)

Se você quer sair do nível “codador” e virar engenheiro de verdade, estude isso:

📚 Ordem sugerida:

1. Address Spaces (ASID, ASCB)
2. TCB e SRB
3. Dispatcher e prioridades
4. SVCs mais comuns
5. Gerenciamento de memória (GETMAIN/FREEMAIN)
6. Dump reading (IPCS)

---

🧪 Dica prática (ouro puro 💰)

Pegue um dump real e procure:

• TCB atual
• PSW
• Última SVC chamada

👉 Isso é mais valioso que 10 cursos teóricos.

---

🕵️‍♂️ EASTER EGGS QUE POUCA GENTE SABE

💣 1. COBOL NÃO CONTROLA NADA
Quem controla é o z/OS. Seu programa só pede.

---

💣 2. ABEND NÃO É ERRO — É DECISÃO
O sistema decidiu parar você.
👉 E sempre tem motivo.

---

💣 3. TUDO É BLOCO ENCADEADO
z/OS é basicamente um grande “linked list corporativo” 😂

---

💣 4. PERFORMANCE NÃO É SÓ CÓDIGO
Pode ser prioridade de TCB, dispatching, ou contenção.

---

🚀 FRASE PRA LEVAR PRA VIDA (E PRO LINKEDIN 😎)

“Quem não entende System Services no z/OS…
não depura problema — só apaga incêndio.”

---

🔥 CONCLUSÃO (SEM ENROLAR)

Se você:

• Só olha código COBOL → você vê a superfície
• Entende System Services → você vê o sistema inteiro

👉 E é aqui que mora a diferença entre:

• Programador
  vs
• Especialista em Mainframe

 

Bellacosa Mainframe fala sobre dumps

🔥 SEU PROGRAMA ABENDOU… E AGORA?

O GUIA DEFINITIVO (E SEM MIMIMI) PARA DOMINAR DUMPS NO MAINFRAME 💥

Se você é dev COBOL e nunca ficou olhando um dump como se fosse hieróglifo egípcio… você ainda vai passar por isso 😄

Mas aqui vai a verdade estilo Bellacosa Mainframe:

👉 Dump não é problema… dump é RESPOSTA.
👉 Quem não sabe ler dump… fica refém de tentativa e erro.
👉 Quem domina dump… vira referência no time.

Bora transformar esse “bicho de 7 cabeças” em ferramenta de guerra ⚔️

---

💣 O QUE É UM DUMP (SEM ROMANCE)

Um dump é basicamente:

📌 Um snapshot da memória no momento do erro (ABEND)

Quando o programa explode (S0C7, S0C4, U4038…), o sistema salva:

• Conteúdo de registradores
• Memória ativa
• Área de variáveis
• Stack de execução
• PSW (Program Status Word)

👉 É literalmente o “estado da cena do crime”.

---

🧨 TIPOS DE DUMP (E POR QUE ISSO IMPORTA)

🔹 1. SYSUDUMP (o clássico raiz)

• Mais simples
• Legível
• Ideal para devs COBOL

👉 Se você está começando, é seu melhor amigo

---

🔹 2. SYSABEND (o detalhista hardcore)

• Muito mais verboso
• Inclui muito mais memória

👉 Útil… mas pode te afogar em informação

---

🔹 3. SYSMDUMP (nível CSI do mainframe)

• Dump completo de memória
• Usado para análise profunda / suporte IBM

👉 Aqui já é território de especialista ou suporte

---

📦 DDS DE DUMP (O QUE NÃO TE CONTAM DIREITO)

No JCL, o dump nasce aqui:

//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSMDUMP DD SYSOUT=*

💡 Dica Bellacosa:

• Nunca coloque os 3 juntos sem motivo
• Pode gerar dump gigante e travar spool

👉 Escolha com estratégia, não no desespero

---

🧠 COMO LER UM DUMP (O JEITO CERTO)

Aqui é onde separa dev comum de dev ninja 🥷

🔍 1. Comece pelo ABEND CODE

Exemplos clássicos:

• S0C7 → erro de dados (numérico inválido)
• S0C4 → violação de memória
• S0C1 → instrução inválida

👉 80% dos casos você resolve só entendendo isso

---

🧭 2. Vá direto no PSW

O PSW mostra:

• Endereço da instrução que falhou

👉 Esse endereço é o “X marca o tesouro” 🏴‍☠️

---

📍 3. Localize o OFFSET

Você vai ver algo assim:

OFFSET = 00001A2C

Agora:

👉 Procure no listing do compilador
👉 Encontre a linha correspondente

💡 Easter egg:
Se você compila com LIST, MAP, OFFSET… sua vida muda completamente

---

🧩 4. Analise os REGISTERS

Especial atenção para:

• R14 → retorno
• R15 → entrada
• R13 → área de trabalho

👉 Isso ajuda a entender o fluxo do programa

---

🔎 5. Veja o conteúdo das variáveis

No dump você verá HEX + EBCDIC:

F1F2F3F4 = 1234

👉 Aqui você encontra:

• Campo numérico com lixo
• Campo alfanumérico corrompido
• Dados desalinhados

---

⚡ EXEMPLO REAL (RAIZ)

Erro clássico:

MOVE WS-TEXTO TO WS-NUMERO

Se WS-TEXTO tiver:

'ABC'

💥 Resultado:

S0C7

👉 Dump vai mostrar valor inválido no campo numérico

---

🧠 COMO SER RÁPIDO (MODO ELITE)

🚀 Regra de ouro:

“Não leia dump inteiro. Faça ele te responder.”

Checklist prático:

1. ABEND code
2. PSW address
3. OFFSET
4. Linha no listing
5. Variável envolvida

👉 Pronto. Resolve 90% dos casos.

---

🧪 DICAS AVANÇADAS (OURO PURO)

💡 Compile assim sempre:

SSRANGE, LIST, MAP, OFFSET

• SSRANGE → pega erro de índice
• MAP → mostra variáveis
• OFFSET → conecta dump com código

---

💡 Use CEEDUMP (quando tiver LE)

Se seu ambiente usa Language Environment:

👉 você ganha dump mais amigável

---

💡 Procure por "LAST EXECUTED STATEMENT"

Alguns dumps mostram isso direto
👉 economiza MUITO tempo

---

💡 Cuidado com redefines

👉 80% dos dumps estranhos vêm daqui

---

🕵️ CURIOSIDADES (EASTER EGGS MAINFRAME)

• O termo “dump” vem literalmente de “despejar memória”
• Dumps existem desde os anos 60 (sim, mais velhos que muita linguagem moderna)
• Em ambientes críticos, dumps são analisados automaticamente por ferramentas de IA (sim, já estamos aí 🤯)

---

💬 COMENTÁRIO ESTILO BELLA

Se você ainda resolve erro com:

👉 DISPLAY pra todo lado
👉 Teste na tentativa
👉 “Ah, deve ser isso aqui…”

Você está perdendo tempo de vida.

---

🏁 CONCLUSÃO

Dump não é inimigo.

👉 Dump é o debugger raiz do mainframe.
👉 Dump é a verdade nua e crua.
👉 Dump é onde o COBOL fala com você.

E quando você aprende a ouvir…

💥 Você para de apagar incêndio e começa a dominar o ambiente.

 

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:

1. Veja PSW
2. Ache a instrução
3. Verifique o dado
4. 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.”