Bellacosa Mainframe ajudando a solucionar abends soc7

🔥 “PASSOU EM HOMOLOGAÇÃO… QUEBROU EM PRODUÇÃO”: O Fantasma do S0C7 que Só Aparece Depois — Um Guia de Sobrevivência para QA, Sustentação e Padawans do Mainframe ☕💻

Senhoras e senhores da trincheira do legado, cavaleiros do JCL, monges do dump IPCS e jovens padawans da qualidade…

Existe uma entidade que não respeita cronograma, SLA, ITIL nem cerimônia ágil.

Ela não aparece no DEV.
Não aparece no SIT.
Não aparece na UAT.

Mas às 02:37 da manhã de domingo, em batch crítico…

💥 S0C7 — DATA EXCEPTION

E o telefone toca.

---

☕ A História que Todo Time de Sustentação Já Viveu

Projeto entregue.
Testes aprovados.
Checklist verde.
Change implementado.

Primeira carga real de produção.

Tudo parece normal… até o job noturno cair.

No log:

IGZ0006S A data exception (System Completion Code=0C7)

O desenvolvedor jura:

“Mas isso passou em todos os testes!”

O analista de QA responde:

“Usamos os dados homologados aprovados pelo negócio.”

O suporte pensa:

“Ok… quem mexeu no layout do arquivo?”

---

🧠 Verdade Inconveniente nº 1

Homologação testa cenários.
Produção testa a realidade.

E a realidade tem:

✔ Dados sujos
✔ Interfaces antigas
✔ Sistemas externos fora de padrão
✔ Arquivos truncados
✔ Migrações parciais
✔ Conversões mal documentadas
✔ Operadores humanos cansados
✔ Programas de 1987 rodando “intactos”

---

🔎 O Vilão Invisível: Dados NÃO CONFIÁVEIS

Em ambientes corporativos reais, especialmente em sistemas core:

👉 O programa raramente quebra por lógica
👉 Ele quebra porque confiou em dados inválidos

E quando existe COMP-3 no meio…

💣 Basta um nibble errado.

---

🧩 Onde QA e Homologação Mais Erram (Sem Saber)

Testes usam dados:

✔ Bonitos
✔ Consistentes
✔ Validados
✔ “De laboratório”

Produção usa dados:

💀 Históricos
💀 Herdados
💀 Convertidos
💀 Misturados
💀 Incompletos
💀 Digitados manualmente

---

📜 Um Easter Egg Histórico (Pouca Gente Sabe)

Nos anos 70 e 80, quando dados vinham de cartões perfurados e fitas:

👉 Erros físicos eram comuns
👉 Leituras incompletas aconteciam
👉 Bits podiam “virar”

Por isso, muitos sistemas antigos tinham:

• Validações redundantes

• Campos de controle

• Checksums primitivos

• Programas “sanitizadores”

Com a modernização…

Essas camadas desapareceram.

Mas os dados continuaram vivos.

---

🧨 Exemplo Real Clássico de Produção

Arquivo externo enviado por parceiro.

Layout:

05 VALOR-TOTAL PIC S9(9)V99 COMP-3.

Em homologação:

✔ Arquivo gerado por ferramenta
✔ Dados corretos

Em produção:

Um registro veio truncado por erro na transferência.

Hex esperado:

12 34 56 78 9C

Hex recebido:

12 34 56 78 9A

Nibble final inválido.

Resultado:

💥 S0C7 ao fazer COMPUTE

---

⚠️ Verdade Inconveniente nº 2

O erro não acontece na leitura.
Nem no MOVE.

👉 Ele explode quando o valor é usado.

Ou seja:

O problema pode estar centenas de linhas antes.

---

🛠️ Como Times de Sustentação Resolvem de Verdade

Não é só “corrigir o programa”.

É fazer engenharia reversa do desastre.

✔ Passo 1 — Identificar o registro exato

• Dump

• SYSOUT

• SMF

• Logs do step anterior

---

✔ Passo 2 — Analisar HEX (não DISPLAY)

Porque COMP-3 não é texto.

Ferramentas comuns:

• IPCS

• File-AID

• Abend-AID

• Debug Tool

---

✔ Passo 3 — Descobrir a origem

Perguntas chave:

• Quem gerou o arquivo?

• Houve compressão?

• Transferência binária ou texto?

• Mudou o layout?

• Sistema fonte mudou linguagem?

• Houve conversão ASCII/EBCDIC?

---

🧪 Guia de Ouro para QA de Mainframe

Se você trabalha com qualidade, homologação ou testes…

💎 Teste dados feios.

Crie cenários com:

• Campos vazios

• Bytes inválidos

• Tamanhos errados

• Registros truncados

• Valores máximos

• Valores negativos inesperados

• Arquivos mistos

• Dados históricos reais anonimizados

👉 Isso vale mais que mil casos “bonitinhos”.

---

🧙‍♂️ Técnicas de Defesa que Mestres do Mainframe Usam

🔹 Inicialização agressiva

MOVE ZERO TO WS-AMOUNT

---

🔹 Validação na entrada

Nunca confiar em interface externa.

---

🔹 Programas sanitizadores

Batch que valida e rejeita registros suspeitos antes do processamento principal.

---

🔹 Versionamento rigoroso de copybooks

Uma pequena divergência de layout pode causar caos.

---

🔹 Testes com dados de produção (mascarados)

Isso separa ambientes maduros dos amadores.

---

🤯 Curiosidade Técnica Pouco Comentada

S0C7 não é erro “de COBOL”.

É um hardware exception de decimal arithmetic tratado pelo runtime.

Ou seja:

👉 O processador detecta que os bits não formam um número decimal válido.

Mainframe não “tenta adivinhar”.
Ele simplesmente interrompe.

Precisão absoluta > tolerância.

---

🧩 Verdade Final para Padawans

Se você viu S0C7…

Não pense primeiro no código.

Pense:

“Qual dado traiu o programa?”

---

☕ Moral da História

Produção não é um ambiente maior.

É um ambiente mais caótico.

Programas COBOL antigos sobrevivem décadas porque:

👉 Foram escritos assumindo que o mundo é imperfeito.

Quando esquecemos disso…

O legado cobra.

---

💥 Regra de Ouro do Bellacosa Mainframe

“Sistema robusto não é o que funciona com dados corretos.
É o que sobrevive a dados errados.”