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.

 

⏰🔥 SRE explicado para quem já foi acordado por batch quebrado

---

02:47 — Introdução: quando o telefone tocava e você já sabia

Antes de existir SRE, já existia plantão.
Antes de “on-call rotation”, já existia pager, telefone fixo e operador nervoso.
Antes de “incident postmortem”, já existia a pergunta clássica:

“O que mudou desde ontem?”

Site Reliability Engineering (SRE) não nasceu no Google.
Nasceu no trauma coletivo de quem precisava manter sistema crítico em pé, custe o que custar.

---

1️⃣ O que é SRE (traduzido para dialeto mainframe)

SRE é aplicar engenharia para garantir:

• Disponibilidade

• Performance

• Confiabilidade

• Previsibilidade

Não é suporte.
Não é operação reativa.
É disciplina.

📌 Mainframer entende assim:

“Não apagar incêndio. Evitar que ele comece.”

---

2️⃣ O mito: SRE é coisa de cloud 😈

Mentira.

Mainframe já fazia SRE com:

• SLAs rígidos

• Janelas de batch

• Planejamento de capacidade

• Controles de mudança

• Automação pesada

😈 Easter egg:
ITIL copiou metade disso e deu nome bonito.

---

3️⃣ SLIs, SLOs e SLAs (ou: como medir sem enganar)

SLI – Indicador

• Tempo de resposta

• Taxa de erro

• Throughput

SLO – Objetivo

• “99,9% das transações em até X ms”

SLA – Contrato

• Multa

• Diretoria

• Dor

📎 Mainframer traduz:

“Se o fechamento não roda, tem reunião amanhã.”

---

4️⃣ Error Budget: a parte que o negócio nunca entendeu 💣

Error Budget =
100% − SLO

Se o sistema pode falhar 0,1% do tempo:

• Você pode inovar

• Pode mudar

• Pode arriscar

Se estourar:

• Congela mudança

• Estabiliza

• Arruma casa

😈 Easter egg:
No mainframe isso se chamava “congelamento pré-fechamento”.

---

5️⃣ Postmortem sem caça às bruxas 🧠

SRE prega:

• Análise sem culpados

• Foco no processo

• Aprendizado real

Mainframer sabe:

“Sistema não quebra sozinho.”

📌 Curiosidade:
Quem caça culpado esconde problema.

---

6️⃣ Automação: batch, scripts e o futuro 🤖

SRE vive de automação:

• Deploy automático

• Rollback

• Self-healing

• Escala automática

Mainframe já fazia:

• JCL

• Restart automático

• Schedulers

• Abends tratados

😈 Easter egg:
JCL é Infrastructure as Code sem marketing.

---

7️⃣ Passo a passo para pensar como SRE (modo Bellacosa)

1️⃣ Defina o que é “funcionar”
2️⃣ Meça tudo que importa
3️⃣ Crie limites claros
4️⃣ Automatize o repetitivo
5️⃣ Aceite falhas pequenas
6️⃣ Aprenda com cada incidente
7️⃣ Melhore antes da próxima pancada

---

8️⃣ Guia de estudo para mainframers cansados 📚

Conceitos

• SRE

• SLIs / SLOs

• Error Budget

• Incident Management

• Chaos Engineering

Ferramentas modernas

• Instana

• PagerDuty

• Grafana

• Kubernetes (sim…)

---

9️⃣ Aplicações práticas no mundo híbrido

• Redução de chamadas noturnas

• Menos stress operacional

• Melhor diálogo com negócio

• Estabilidade com inovação

• Arquiteturas mais conscientes

🎯 Mainframer SRE vira pilar da empresa.

---

🔟 Curiosidades que doem 😬

• 100% disponível não existe

• Mudança sem métrica é aposta

• Automatizar erro escala desastre

• Confiabilidade custa tempo e dinheiro

📌 Verdade dura:
Sistema crítico exige humildade técnica.

---

11️⃣ Comentário final (05:31, céu clareando)

SRE não é moda.
É sobrevivência profissional.

Se você já:

• Dormiu mal por batch quebrado

• Evitou mudança perto do fechamento

• Confiou mais em histórico do que em promessa

Então você já era SRE, antes do nome existir.

🖤 El Jefe Midnight Lunch encerra a série:
Confiabilidade não se improvisa. Se constrói.

 

 

🔥 Error Handling Techniques no CICS

 

---

☕ Midnight Lunch, abend na tela e o silêncio mortal

São 12h58.
Usuário digita Enter.
A tela pisca.
ASRA.

No console, ninguém fala.
Alguém finalmente quebra o gelo:

“Isso não foi tratado…”

Hoje o almoço é pesado. Vamos falar de tratamento de erros no CICS — a diferença entre um sistema profissional e um sistema que vive de reza e IPL.

---

🏛️ História: quando erro virou disciplina

Nos primórdios, erro em CICS era simples:

• Deu problema → abend

• Debug → dump

• Corrige → volta pra produção

Com o crescimento de sistemas 24x7, isso virou inaceitável.
O CICS evoluiu e trouxe mecanismos formais de error handling, muito antes de try/catch virar moda.

📌 CICS não evita erro. Ele oferece ferramentas para dominá-lo.

---

🧠 Conceito essencial (grave isso)

Erro não tratado = falha arquitetural
Erro tratado = comportamento esperado

Mainframe não tolera improviso.

---

🧯 Principais técnicas de Error Handling no CICS

Vamos separar por camadas — como todo bom sistema corporativo.

---

1️⃣ RESP / RESP2 – o primeiro escudo

O que é?

Quase todo comando CICS retorna:

• RESP → código principal

• RESP2 → detalhe fino do erro

Exemplo

EXEC CICS READ FILE('ARQCLI')
     INTO(WS-REG)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC.

Boa prática

• Sempre testar RESP

• Nunca confiar que “vai dar certo”

📌 RESP ignorado é bug incubado.

---

2️⃣ HANDLE CONDITION – o guarda-costas antigo

O que é?

Permite capturar condições específicas e redirecionar o fluxo.

EXEC CICS HANDLE CONDITION
     NOTFND(LABEL-NOTFND)
     DUPREC(LABEL-DUP)
END-EXEC.

Vantagens

✔ Simples
✔ Muito usado em código legado

Riscos

❌ Global demais
❌ Difícil de rastrear
❌ Pode mascarar erro

📌 HANDLE CONDITION é faca de cozinha: útil, mas perigosa.

---

3️⃣ IGNORE CONDITION – o tapa pra debaixo do tapete

O que é?

Ignora explicitamente uma condição.

EXEC CICS IGNORE CONDITION NOTFND END-EXEC.

⚠️ Use só quando:

• A condição é esperada

• Você sabe exatamente o impacto

📌 IGNORE CONDITION sem comentário é crime técnico.

---

4️⃣ HANDLE ABEND – o airbag

O que é?

Intercepta abends CICS antes de matar a transação.

EXEC CICS HANDLE ABEND
     PROGRAM('ABENDPGM')
END-EXEC.

O que dá pra fazer?

• Logar contexto

• Gravar TDQ/TSQ

• Avisar monitoria

• Encerrar com dignidade

📌 HANDLE ABEND não evita o erro. Evita o caos.

---

5️⃣ ABEND explícito – erro controlado é maturidade

Às vezes, abendar é a decisão correta.

EXEC CICS ABEND ABCODE('APPL')
     NODUMP
END-EXEC.

Use quando:

• Integridade foi comprometida

• Continuar é mais perigoso

• Auditoria exige parada

📌 Abend consciente é melhor que sucesso falso.

---

🛠️ Passo a passo Bellacosa (como tratar erro direito)

1️⃣ Capture RESP / RESP2
2️⃣ Decida: recuperar ou encerrar
3️⃣ Registre contexto (log)
4️⃣ Informe o usuário de forma clara
5️⃣ Garanta consistência de dados

📌 Tratamento de erro também é UX.

---

⚠️ Erros clássicos (easter eggs mainframe)

🐣 RESP nunca testado
🐣 HANDLE CONDITION genérico demais
🐣 IGNORE CONDITION sem explicação
🐣 Dump infinito em produção
🐣 Abend sem log

📌 Todo ASRA famoso começou assim.

---

📦 Integração com TSQ, TDQ e logs

Boas práticas:

• TDQ para log de erro

• TSQ para contexto temporário

• SMF para auditoria

• Integração com monitoria (OMEGAMON, Instana)

📌 Erro que não é logado vai voltar.

---

📚 Guia de estudo para mainframers

Domine estes tópicos:

• CICS Conditions & RESP codes

• Abend codes (AEI0, ASRA, APCT)

• Program Control error handling

• Recovery & Backout

• Logging e monitoramento

📖 Manual essencial: CICS Application Programming Guide

---

🤓 Curiosidades de boteco mainframe

🍺 HANDLE CONDITION é mais antigo que Java
🍺 Muitos sistemas “estáveis” vivem à base de IGNORE CONDITION
🍺 O melhor log é o que nunca precisa ser lido
🍺 Já vi HANDLE ABEND salvar auditoria milionária

---

💬 Comentário El Jefe Midnight Lunch

“Erro não mata sistema.
Falta de tratamento, sim.”

---

🚀 Aplicações reais hoje

• Sistemas bancários 24x7

• Processamento de cartões

• Governo e seguradoras

• Plataformas críticas globais

---

🎯 Conclusão Bellacosa

CICS não exige perfeição.
Exige responsabilidade.

Quem trata erro direito:

• Dorme melhor

• Evita incidente grave

• Ganha respeito do operador

🔥 Error handling não é opcional. É caráter técnico.