Translate

terça-feira, 31 de março de 2026

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

 

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

EraLimite
24-bit16MB 😱
31-bit2GB
👉 64-bit16EB 🤯

💡 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.”

☕ O Holocron do IBM Bob Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z

 

Bellacosa Mainframe e uma trilha para aprender o IBM BOB

☕ O Holocron do IBM Bob

Como um Padawan COBOL Pode Aprender a Trabalhar com um Companheiro de IA Criado pela IBM sem Abandonar o IBM Z, o JCL e sua Caneca de Café

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma verdade desconfortável.

O mundo mudou.

Enquanto passamos décadas aprendendo os segredos do DISP, do DFSORT, do CICS, do Db2, do VSAM e dos utilitários mais obscuros do z/OS, uma nova geração de desenvolvedores começou a conversar com máquinas em linguagem natural e pedir que elas escrevessem código, documentação, testes e até arquiteturas inteiras.

A primeira reação de muitos profissionais experientes costuma ser previsível:

"Isso é modinha."

"IA não entende COBOL."

"Nunca vai substituir um analista de produção."

"Nem sabe o que é um S322."

Talvez.

Mas talvez estejamos olhando para a ferramenta errada.

Porque IBM Bob não nasceu para substituir um especialista IBM Z.

Ele nasceu para trabalhar ao lado dele.

E isso muda completamente a história.

O que é o IBM Bob?

Imagine um aprendiz extremamente dedicado.

Ele nunca dorme.

Não reclama.

Lê milhares de páginas de documentação em segundos.

Conhece APIs.

Conhece padrões modernos.

Entende agentes.

Consegue construir ferramentas.

Escreve testes.

Produz documentação.

Sugere modernizações.

Ajuda a criar MCP Servers.

Conversa com o watsonx.

Integra-se ao Orchestrate.

Pode inclusive auxiliar equipes inteiras durante o ciclo de desenvolvimento.

Esse aprendiz atende pelo nome de IBM Bob.

Bob pode ser visto como um companheiro de desenvolvimento baseado em IA, desenhado para apoiar atividades do ciclo de vida de software e construção de agentes corporativos.

Mas existe um detalhe importante.

Bob não conhece seu ambiente.

Ele não conhece sua instalação.

Ele não conhece suas convenções.

Ele não sabe onde estão seus copybooks.

Ele não entende por que aquele JOB roda somente às quartas-feiras às 02h37 da manhã.

Você sabe.

E é exatamente por isso que você continua sendo importante.


O Erro que Muitos Padawans Cometem

Muitos profissionais COBOL observam ferramentas de IA e concluem:

"Isso é para programadores Python."

Não.

Na verdade, talvez sejamos justamente os profissionais mais preparados para utilizá-las.

Quem trabalhou em Mainframe desenvolveu habilidades raras:

Pensamento sistêmico.

Modelagem de negócios.

Análise de impacto.

Governança.

Segurança.

Auditoria.

Confiabilidade.

Capacidade de compreender aplicações escritas há quarenta anos.

E IA gosta de contexto.

IA gosta de conhecimento estruturado.

IA gosta de especialistas.

Ela precisa de mestres para guiá-la.

O futuro não pertence ao desenvolvedor que apenas escreve código.

Pertence ao profissional capaz de ensinar máquinas a compreender sistemas complexos.


A Trilha do Padawan IBM Bob

Resolvi montar uma trilha de oito semanas.

Nada impossível.

Nada acadêmico.

Nada de cursos infinitos de vinte horas falando sobre redes neurais.

Apenas uma jornada prática.

Semana 1 — Entender o Ecossistema IBM AI

Objetivo:

Compreender o que existe ao redor de Bob.

Estude:

  • watsonx.ai

  • Granite

  • watsonx.data

  • watsonx.governance

  • AI Agents

  • MCP

Faça cursos gratuitos no IBM SkillsBuild.

Não tenha pressa.

Seu objetivo não é virar cientista de dados.

Seu objetivo é aprender a conversar com uma nova geração de ferramentas.


Semana 2 — Aprender Agentes

Descubra que um agente não é apenas um chatbot.

Ele pode:

Planejar.

Executar.

Consultar APIs.

Tomar decisões.

Utilizar memória.

Usar ferramentas externas.

Exercício:

Imagine um agente chamado:

COBOL Guru

Pergunte:

Explique este JCL.

Procure copybooks.

Liste dependências.

Estime complexidade.

Perceba algo interessante.

Você já sabe fazer isso.

A diferença é que agora poderá ensinar uma IA a ajudá-lo.


Semana 3 — Conhecer Bob

Leia a documentação.

Entenda seus casos de uso.

Observe demonstrações.

Experimente prompts.

Pergunte:

Analise este programa COBOL.

Gere documentação.

Escreva testes.

Sugira APIs.

Crie OpenAPI.

Identifique código morto.

Comece pequeno.

Um programa.

Depois dez.

Depois cem.


Semana 4 — Watsonx Orchestrate

Aqui a mágica começa.

Bob deixa de ser apenas um assistente.

Passa a participar de fluxos empresariais.

Skill.

Ferramenta.

Agente.

Processo.

Orquestração.

E então você percebe algo curioso.

É quase como desenhar uma aplicação CICS moderna.

Só que utilizando IA.


Semana 5 — Descobrir MCP

MCP talvez seja uma das tecnologias mais interessantes surgidas recentemente.

Em vez de pedir que uma IA adivinhe informações, você oferece ferramentas para que ela consulte dados reais.

Imagine um MCP chamado:

BellacosaMainframeServer

Com funções:

analyze_jcl()

find_copybook()

search_db2()

locate_cics_program()

find_dead_code()

estimate_batch_window()

De repente Bob deixa de ser um chatbot.

Ele se torna um analista júnior extremamente produtivo.


Semana 6 — Hands-on

Construa.

Erre.

Experimente.

Quebre.

Reconstrua.

Peça:

Bob, documente esta aplicação.

Depois:

Gere casos de teste.

Depois:

Crie APIs REST.

Depois:

Produza Markdown.

Depois:

Gere Swagger.

Pouco a pouco você perceberá que Bob não elimina conhecimento COBOL.

Ele amplia seu alcance.


Semana 7 — Mainframe Modernization

Pegue um sistema real.

COBOL.

JCL.

Db2.

VSAM.

CICS.

E pergunte:

O que pode ser modernizado?

O que pode virar API?

O que está obsoleto?

O que nunca é utilizado?

Você ficará surpreso.

Bob pode sugerir caminhos.

Mas somente um profissional experiente saberá decidir quais realmente fazem sentido.


Semana 8 — O Projeto Final

Construa algo seu.

Um sonho.

Um laboratório.

Um produto.

Um experimento.

Sugiro:

Bellacosa Bob for Mainframe

Capaz de:

Receber COBOL.

Analisar JCL.

Documentar aplicações.

Gerar testes.

Produzir OpenAPI.

Encontrar dependências.

Responder perguntas.

Criar artigos.

Explicar abends.

Mapear datasets.

Imagine um novo colega dizendo:

Bom dia.

Detectei cinco programas sem testes.

Há três copybooks duplicados.

Posso gerar documentação.

Deseja continuar?

Quem recusaria ajuda?


O Conselho de um Mestre para os Padawans COBOL

Durante anos ouvimos previsões sobre a morte do Mainframe.

Elas vieram.

E foram embora.

O IBM Z continua processando transações, cartões, seguros, governos, bolsas de valores e sistemas críticos do planeta.

Agora surge uma nova onda.

IA.

Agentes.

MCP.

Orquestração.

Granite.

Bob.

E novamente alguns profissionais ficarão olhando de longe.

Esperando passar.

Outros decidirão estudar.

Experimentar.

Errar.

Construir.

Compartilhar.

E descobrirão que a IA não veio para apagar décadas de experiência.

Veio para amplificar aquilo que os especialistas IBM Z sempre tiveram de mais valioso:

Conhecimento.

Contexto.

Disciplina.

Arquitetura.

Curiosidade.

Portanto, jovem Padawan COBOL, coloque mais café na caneca.

Abra o SkillsBuild.

Explore o Bob.

Construa seu primeiro agente.

Crie seu primeiro MCP.

Converse com o futuro.

E lembre-se:

A Força pode estar nos prompts, mas a verdadeira sabedoria continua residindo em quem conhece o significado de um DISP=(MOD,CATLG,DELETE), de um Abend U4038 e da responsabilidade de manter funcionando sistemas que movimentam bilhões de registros todos os dias.

Que os Holocrons do IBM Z estejam com você.


segunda-feira, 30 de março de 2026

🔥 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.”

 

domingo, 29 de março de 2026

🔥 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

sábado, 28 de março de 2026

🔥 SEU PROGRAMA ABENDOU… E AGORA?

 

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.

sexta-feira, 27 de março de 2026

🔥 COBOL NÃO QUEBROU… FOI O RTM QUE DECIDIU O DESTINO

 

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.”