☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta S0C7. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta S0C7. Mostrar todas as mensagens

segunda-feira, 7 de setembro de 2026

O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

 
Bellacosa Mainframe e o manual para um dev programador cobol iniciante nas artes secretas do mainframe

Um Café no Bellacosa Mainframe

O Manual da Guilda do Programador Mainframe — Do Rank F ao Rank S

Ou: como COBOL, JCL, Db2, CICS, RACF, dumps, documentação, café, S0C7, SQLCODE -911, ICH408I, Technical Debt, Deadline e o Demon Lord Boleto transformaram uma carreira de TI no RPG mais longo que você jamais instalou

Existe um momento inesquecível na vida de todo programador mainframe.

Você recebe seu primeiro USERID.

Alguém lhe entrega uma senha temporária.

Você acessa uma tela preta.

No alto aparece algo que parece ter sido construído numa civilização anterior à invenção do mouse.

Você olha aquilo.

Aquilo olha para você.

Parabéns.

Você acaba de entrar na:


GUILDA DOS PROGRAMADORES MAINFRAME

Seu Rank atual:

F

Sua classe:

Novato

Experiência:

0 XP

Equipamento:

  • um notebook corporativo;

  • um USERID recém-criado;

  • uma senha que expirará no pior momento possível;

  • três PDFs;

  • acesso limitado;

  • nenhum conhecimento sobre produção;

  • uma caneca de café.

Sua primeira quest aparece:

ALTERE UMA MENSAGEM NUM PROGRAMA COBOL.

Dificuldade estimada:

Dificuldade percebida pelo novato:

⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

Você ainda não sabe, mas acabou de iniciar um dos RPGs profissionais mais longos existentes.

Não existe tela de Game Over.

Existe:

ABEND



1. Antes de começar: escolha sua classe

Nos RPGs tradicionais escolhemos Warrior, Mage, Cleric ou Rogue.

No Mainframe RPG também existem classes.

COBOL Developer — Warrior

Ataca problemas diretamente.

Sua arma principal é:

IF
   ...
ELSE
   ...
END-IF

Possui resistência extraordinária a sistemas com quarenta anos.

Fraqueza natural:

dados inválidos.


Db2 Specialist — Mage

Manipula entidades invisíveis chamadas tabelas, índices, packages e access paths.

Seu feitiço favorito:

SELECT

Seu feitiço proibido:

DELETE FROM TABELA;

sem WHERE.

Quando isso acontece, nem resurrection spell resolve facilmente.


CICS Specialist — Rogue

Extremamente rápido.

Trabalha em milissegundos.

Conhece transações, regions e resources.

Seu inimigo natural é alguém dizendo:

“CICS está lento.”

Sem fornecer nenhuma outra informação.


RACF Administrator — Paladin

Guardião das portas.

Decide quem entra.

Quem lê.

Quem altera.

Quem executa.

Seu poder supremo é dizer:

ACCESS DENIED.

Não importa se você é diretor, gerente, arquiteto ou primo do CEO.


System Programmer — Archmage

Classe misteriosa.

Habita regiões profundas do reino chamadas PARMLIB, PROCLIB e SYS1.

Fala palavras como:

IPL.

APF.

LPA.

SVC.

SMF.

WLM.

SMP/E.

Quando entra numa War Room, todos ficam um pouco mais tranquilos.

Ou mais preocupados.

Depende da expressão dele.



2. Rank F — O Novato

Você começa no Rank F.

Não sabe quase nada.

E isso é perfeitamente normal.

Seu primeiro grande aprendizado é descobrir que não saber não é um defeito inicial: é o estado padrão da profissão.

Quests do Rank F

  • acessar TSO/ISPF;

  • navegar entre datasets;

  • entender PDS e membros;

  • editar um programa COBOL;

  • compilar;

  • executar um JOB;

  • consultar SDSF;

  • descobrir por que o JOB não terminou;

  • aprender a diferença entre erro de compilação e ABEND;

  • entender que produção não é lugar para experiências criativas.

Equipamento inicial

Espada COBOL +1

Escudo JCL +1

Mapa ISPF +2

Poção Café +5 concentração

Pergaminho “Manual da Empresa” +10 confusão

Skill especial

ASK SENIOR

Cooldown:

depende do humor do senior.

É provavelmente a skill mais importante dessa fase.



3. O primeiro monstro: JCL ERROR

Você submete seu primeiro JOB.

Espera.

Nada.

Olha novamente.

Descobre uma mensagem.

O coração acelera.

Você pensa:

“Quebrei o mainframe.”

Não.

Provavelmente esqueceu uma vírgula.

Mas essa primeira batalha ensina uma regra fundamental:

Leia a mensagem de erro.

Parece óbvio.

Não é.

Programadores frequentemente passam vinte minutos imaginando teorias sofisticadas enquanto o sistema está dizendo exatamente o problema.

O aventureiro experiente aprende:

Primeiro leia o que o monstro escreveu.

Depois desembainhe a espada.



4. Rank E — Junior

Depois de algumas quests você sobe para Rank E.

Agora consegue fazer pequenas alterações sem supervisão constante.

Isso produz um fenômeno perigoso:

confiança.

Você começa a achar que entende o sistema.

O sistema percebe.

E envia seu primeiro boss.

S0C7


5. Boss #1 — S0C7, o Devorador de Dados

Você executa o programa.

Ele morre.

Na tela:

S0C7

O novato pergunta:

— O que significa?

O veterano responde:

— Data Exception.

Tradução RPG:

Você tentou tratar alguma coisa como número e aquilo discordou.

Talvez um campo numérico contenha dados inválidos.

Talvez exista problema de definição.

Talvez um movimento tenha colocado conteúdo inesperado numa área.

A batalha começa.

Armas contra S0C7

  • dump;

  • offset;

  • listing;

  • compile options;

  • análise dos dados;

  • conhecimento das PICs;

  • atenção.

XP recebido

+350 DEBUGGING

Achievement desbloqueado

“Meu primeiro ABEND.”

Todo programador mainframe deveria receber um badge por isso.


6. Rank D — Pleno em formação

Agora você começa a compreender que programa nenhum vive sozinho.

Seu COBOL conversa com:

Db2.

VSAM.

CICS.

MQ.

Arquivos.

Outros programas.

Jobs.

APIs.

Usuários.

E processos de negócio criados antes de você entrar na empresa.

Você acaba de desbloquear:

DEPENDENCY HELL

A dungeon aumentou.


7. A Party

Nenhum aventureiro sensato entra sozinho numa dungeon perigosa.

No mainframe também não deveria.

Sua party pode possuir:

COBOL Developer

Ataca o código.

DBA

Controla os dragões relacionais.

System Programmer

Manipula as forças fundamentais do z/OS.

Security Specialist

Possui as chaves do castelo.

Production Control

Conhece horários e dependências.

Business Analyst

Traduz a misteriosa linguagem dos usuários.

Support

Sabe onde os cadáveres estão enterrados.

A grande skill profissional aparece quando você percebe:

não precisa saber tudo; precisa saber quem sabe.

Isso vale mais XP do que decorar centenas de comandos.


8. Boss #2 — SQLCODE -911, o Senhor dos Locks

Você escreve SQL.

Testa.

Funciona.

Produção chega.

Então:

SQLCODE = -911

O monstro apareceu.

Rollback.

Deadlock.

Timeout.

Seu programa estava disputando recursos com outra coisa.

Você descobre que bancos de dados não são bibliotecas silenciosas.

São cidades.

Centenas ou milhares de transações querem acessar recursos simultaneamente.

Algumas leem.

Outras alteram.

Algumas seguram locks.

Outras esperam.

Até que Db2 olha para a situação e decide:

“Alguém precisa morrer.”

Parabéns.

Foi sua transação.

Skills necessárias

  • compreender COMMIT;

  • entender ROLLBACK;

  • conhecer locking;

  • investigar concorrência;

  • analisar tempo de transação;

  • compreender access paths;

  • conversar com DBA.

XP

+750 CONCURRENCY

Loot

Anel do COMMIT Frequente

Use com sabedoria.

Commit demais também pode trazer problemas.


9. Rank C — O profissional que começa a enxergar o sistema

Aqui ocorre uma transformação importante.

Você deixa de perguntar apenas:

“Onde está o erro?”

E começa a perguntar:

“Por que esse erro aconteceu?”

Essa mudança parece pequena.

Não é.

É a passagem de executor para analista.

O Rank F corrige o registro.

O Rank C pergunta quem gerou o registro errado.

O Rank F reinicia o JOB.

O Rank C pergunta por que ele falhou.

O Rank F libera espaço.

O Rank C pergunta por que o crescimento não foi previsto.

Você começa a combater causas, não apenas sintomas.


10. Boss #3 — ICH408I, o Guardião das Portas

Você executa alguma coisa.

Recebe:

ICH408I

Você tenta novamente.

ICH408I

Mais uma vez.

ICH408I

O RACF não muda de opinião porque você clicou três vezes.

Esse boss ensina uma das regras fundamentais de segurança:

autenticação não significa autorização.

Você conseguiu entrar no reino.

Isso não significa que pode abrir todas as portas.

Talvez seu USERID não tenha acesso.

Talvez o grupo esteja incorreto.

Talvez o perfil proteja o recurso.

Talvez você precise de READ.

UPDATE.

CONTROL.

ALTER.

E talvez você não devesse receber nenhum deles.

Arma recomendada

Não é:

“Me dê ALTER em tudo.”

A arma correta chama-se:

Least Privilege.

XP

+900 SECURITY

Achievement

“RACF disse não.”


11. Equipamentos raros

Com o tempo você começa a colecionar equipamentos.

Não são espadas.

São ferramentas.

Debugger

Item raro.

Permite observar o monstro antes que ele mate seu programa.

Git

Inventário dimensional.

Guarda versões anteriores das suas armas.

Pipeline CI/CD

Esteira mágica que transporta artefatos entre reinos.

Monitoramento

Olho de Sauron corporativo.

Idealmente usado para observar sistemas, não hobbits.

Logs

Pergaminhos proféticos.

Quase sempre possuem pistas.

Documentação

Item lendário.

Extremamente poderoso.

Raramente atualizado.


12. Rank B — Senior

Aqui surge uma coisa curiosa.

Você sabe muito mais.

Mas começa a dizer:

“Depende.”

O junior acha isso frustrante.

Ele pergunta:

— Qual é a melhor solução?

Senior:

— Depende.

— Qual banco devemos usar?

— Depende.

— Devemos fazer COMMIT aqui?

— Depende.

— Podemos colocar isso em produção?

O senior olha fixamente.

Depende muito.

Isso não é indecisão.

É percepção de contexto.

Quanto mais você aprende, mais percebe quantas variáveis existem.


13. Boss #4 — Deadline, o Senhor do Tempo

Nenhum treinamento prepara adequadamente para esse monstro.

Deadline possui habilidade especial:

TIME COMPRESSION

Projeto de seis meses.

Prazo:

três meses.

Depois:

dois.

Então alguém pergunta:

“Conseguimos entregar sexta?”

Você olha o calendário.

Hoje é quinta.

Ataques do Deadline

  • reunião de status;

  • daily adicional;

  • planilha vermelha;

  • “quick win”;

  • “só falta um detalhe”;

  • mudança de requisito;

  • reunião para discutir por que existem tantas reuniões.

Defesa

  • estimativa realista;

  • priorização;

  • gerenciamento de risco;

  • documentação;

  • comunicação;

  • coragem profissional para dizer:

“Não.”

Essa última é uma skill Rank A.


14. Boss #5 — Technical Debt, o Monstro que Alimentamos

Esse é diferente.

Ele não aparece repentinamente.

Nós o criamos.

Começa pequeno.

“Depois corrigimos.”

“É temporário.”

“Só para entrar em produção.”

“Na próxima release melhoramos.”

Cada frase adiciona HP ao monstro.

Cinco anos depois existe uma rotina de 8.000 linhas que ninguém quer tocar.

O comentário diz:

* TEMPORARIO - NAO REMOVER
* 2007

Estamos em 2026.

O temporário completou dezenove anos.

Pode votar.

😂

Technical Debt Level 80

Ataques:

  • manutenção cara;

  • regressões;

  • medo de mudança;

  • conhecimento concentrado;

  • documentação inexistente;

  • dependências misteriosas.

Fraqueza

Refactoring controlado.

Testes.

Documentação.

Automação.

Tempo.

Naturalmente, o Deadline Boss geralmente impede que você use essas armas.

Os dois trabalham juntos.


15. Rank A — Especialista

O especialista não é necessariamente quem conhece mais comandos.

É quem possui profundidade suficiente para compreender consequências.

Ele começa a enxergar sistemas como ecossistemas.

Uma alteração COBOL pode afetar Db2.

Db2 pode alterar tempo de resposta.

Tempo de resposta pode afetar CICS.

CICS pode afetar usuários.

Usuários podem afetar faturamento.

Faturamento pode afetar diretoria.

Diretoria pode afetar você.

Tudo está conectado.

Skill desbloqueada

SYSTEM THINKING +100


16. A Skill lendária: reconhecer padrões

Um jovem olha um incidente e vê:

ERROR

O especialista olha e pensa:

“Já vi algo parecido.”

Não exatamente aquilo.

Mas algo parecido.

Essa biblioteca mental foi construída durante milhares de horas.

Incidentes.

Projetos.

Erros.

Migrações.

Falhas.

Sucessos.

Madrugadas.

É uma espécie de machine learning biológico.

Dataset:

sua carreira.

Treinamento:

vinte anos.

Inference:

“Olha aquele job primeiro.”


17. O sorriso ninja

Então aparece uma ferramenta nova.

Nova release.

Interface redesenhada.

Cloud.

API.

IDE.

Pipeline.

Você nunca utilizou exatamente aquela versão.

Cliente pergunta:

— Você sabe fazer?

Você:

😎

— Sei.

Internamente:

🦋🦋🦋🦋

O que você realmente quis dizer foi:

“Conheço suficientemente bem esse tipo de problema para descobrir como essa versão resolveu mudar tudo.”

Isso não é necessariamente blefe.

É confiança na capacidade de aprender.

A skill chama-se:

RELEARN

Rank:

S


18. Rank S — Mestre da Guilda

Pouquíssimos chegam aqui no sentido verdadeiro.

Não é determinado por idade.

Nem apenas por certificações.

Rank S aparece quando conhecimento técnico, experiência, contexto, comunicação e capacidade de formar outras pessoas começam a trabalhar juntos.

O Mestre da Guilda não precisa resolver tudo pessoalmente.

Ele sabe organizar a batalha.

Pergunta:

— O que mudou?

— Quando começou?

— Qual impacto?

— Conseguimos reproduzir?

— Temos rollback?

— Quem conhece esse componente?

— Quais evidências temos?

Observe.

Nenhuma magia.

Somente método.


19. A árvore de Skills

Depois de muitos anos, uma árvore possível poderia parecer assim:

PROGRAMADOR MAINFRAME
│
├── COBOL
│   ├── Estruturas
│   ├── Arquivos
│   ├── Debugging
│   └── Performance
│
├── JCL
│   ├── JOB
│   ├── EXEC
│   ├── DD
│   └── Utilities
│
├── DATA
│   ├── VSAM
│   ├── Db2
│   └── IMS
│
├── ONLINE
│   └── CICS
│
├── INTEGRATION
│   ├── MQ
│   ├── APIs
│   └── z/OS Connect
│
├── SECURITY
│   └── RACF
│
├── DEVOPS
│   ├── Git
│   ├── CI/CD
│   └── Automation
│
└── VETERAN SKILLS
    ├── Debugging
    ├── Comunicação
    ├── Contexto
    ├── Mentoria
    ├── Pattern Recognition
    └── Relearn

A última árvore costuma ser a mais difícil.

Não existe curso de quatro horas para obter vinte anos de contexto.


20. Como ganhar XP de verdade

Nem todo XP vem de certificação.

Alguns dos maiores ganhos acontecem quando algo dá errado.

Quest: corrigir primeiro ABEND

+500 XP

Quest: resolver incidente em produção

+1.000 XP

Quest: admitir que sua alteração causou o incidente

+2.000 XP

Quest: documentar para ninguém repetir

+3.000 XP

Quest: ensinar um junior

+5.000 XP

Quest: impedir um incidente antes que aconteça

+10.000 XP

Curiosamente, essa última geralmente não recebe reconhecimento.

Porque nada aconteceu.

Esse é o paradoxo do bom profissional de infraestrutura.


21. Side quests

Durante sua carreira aparecem missões secundárias.

“Aprenda Python.”

“Conheça Cloud.”

“Faça certificação.”

“Estude APIs.”

“Aprenda Git.”

“Agora containers.”

“Agora IA.”

Você abre seu mapa.

Existem 847 quests pendentes.

E apenas 24 horas por dia.

Então desbloqueia uma habilidade fundamental:

SELECT QUEST

Não tente aprender tudo.

Escolha aquilo que aproxima você de algum objetivo.

Senão você passará a vida coletando XP sem terminar a campanha principal.


22. O item mais raro: Tempo

Dinheiro compra livros.

Cursos.

Computadores.

Certificações.

Mas existe um recurso que não pode ser farmado:

tempo.

Um curso gratuito de quarenta horas custa quarenta horas.

Talvez valha.

Talvez não.

O aventureiro Rank S aprende a perguntar:

“Este conhecimento vale o tempo necessário para adquiri-lo?”

Porque cada curso compete com trabalho, descanso, família, leitura, caminhada...

e anime.

Nunca esqueçamos o anime.


23. O chefão secreto: Síndrome do Impostor

Mesmo depois de milhares de XP aparece uma criatura invisível.

Ela sussurra:

“Você não sabe o suficiente.”

Tecnicamente ela está correta.

Ninguém sabe.

O problema está na conclusão seguinte:

“Portanto você não deveria estar aqui.”

Errado.

O especialista não é aquele que sabe tudo.

É aquele que desenvolveu métodos para lidar com aquilo que não sabe.

Essa distinção salva carreiras.


24. O Boss final

Depois de COBOL.

Depois de Db2.

Depois de CICS.

Depois de RACF.

Depois do S0C7.

Depois do -911.

Depois do ICH408I.

Depois do Deadline.

Depois do Technical Debt.

Você acredita estar preparado.

Então o céu escurece.

A música muda.

Surge uma criatura gigantesca.

HP:

Resistência:

100%

Respawn:

MENSAL

Nome:

BOLETO

O Demon Lord definitivo.


25. Boleto — Level 99

Você pode trocar de emprego.

Boleto acompanha.

Pode virar freelancer.

Ele encontra você.

Pode tornar-se consultor.

Ele escala junto.

Pode tirar férias.

Ele sabe onde você mora.

Sua habilidade suprema chama-se:

VENCIMENTO

Todo mês ele retorna.

Isso explica boa parte da economia da Guilda.

O aventureiro veterano pensa:

“Talvez eu pare de aceitar projetos.”

Boleto:

“Interessante.”

😂

E imediatamente aparece no LinkedIn:

COBOL/Db2 Senior Consultant — Immediate Start — 6 months.

O velho aventureiro olha para a espada pendurada na parede.

Suspira.

— Uma última quest.

Boleto sorri.

Ele já ouviu isso antes.


26. New Game+

Existe, porém, uma fase curiosa da carreira.

Depois de acumular conhecimento suficiente, você começa a ensinar.

E ensinar é uma espécie de:

NEW GAME+

Você retorna às primeiras dungeons.

Só que agora acompanha novos aventureiros.

O junior pergunta:

— O que é S0C7?

Você sorri.

Lembra do seu primeiro.

Explica.

Ele resolve.

Ganha XP.

E alguma coisa interessante acontece.

Você também ganha.

Porque ensinar força a organizar aquilo que anos de experiência deixaram intuitivo.

Talvez essa seja uma das formas mais bonitas de veterania.

Transformar cicatrizes em mapas para quem vem depois.


27. Easter Egg — o verdadeiro Rank S

Existe um segredo escondido neste manual.

Rank S não significa:

Super Senior.

Significa:

Sobrevivente.

Sobreviveu às mudanças.

Às releases.

Aos projetos.

Aos incidentes.

Às tecnologias “que acabariam com o mainframe”.

Às reorganizações.

Às ferramentas revolucionárias.

Às interfaces redesenhadas.

Às certificações.

Ao Ceifeiro Silencioso.

Ao Deadline.

Ao Technical Debt.

E, até agora...

ao Boleto.

Mas sobretudo sobreviveu sem perder completamente uma coisa:

curiosidade.

Porque quando a curiosidade morre, estudar vira apenas obrigação.

E uma carreira tecnológica sem vontade de descobrir coisas novas transforma cada atualização numa punição.


28. A regra de ouro da Guilda

Se eu tivesse que entregar somente uma regra ao programador começando hoje, seria:

Aprenda fundamentos profundamente e ferramentas suficientemente.

Ferramentas mudam.

Interfaces mudam.

Versões desaparecem.

Menus migram.

Produtos são renomeados.

Mas compreender transações, dados, concorrência, segurança, arquitetura, debugging e sistemas continuará permitindo que você reconheça os mesmos monstros usando roupas diferentes.

O goblin de 1998 pode aparecer em 2027 com Kubernetes, API REST e inteligência artificial.

Continua sendo goblin.

Só ganhou marketing.


Epílogo — A próxima quest

03:17.

Telefone toca.

Produção está parada.

Um jovem Rank F olha assustado para o terminal.

Ao lado dele existe um veterano Rank S.

— O que faço?

O veterano coloca a caneca de café sobre a mesa.

— Primeiro, não faça nada.

— Como assim?

— Leia.

Eles olham os logs.

O jovem encontra uma mensagem:

ICH408I

— RACF?

O veterano sorri.

— Talvez.

— Você não sabe?

— Ainda não.

O jovem estranha.

Aquele homem possui décadas de experiência.

Como pode responder “não sei”?

O veterano continua:

— Vamos descobrir.

Nesse instante o jovem aprende uma coisa muito maior do que RACF.

Descobre o verdadeiro significado de experiência.

Não é possuir todas as respostas.

É não precisar fingir que possui.

É saber investigar.

Saber testar.

Saber pedir ajuda.

Saber voltar atrás.

Saber diferenciar evidência de palpite.

Saber quando agir.

E, talvez ainda mais importante...

saber quando não agir.

Alguns minutos depois encontram a causa.

04:02.

Produção retorna.

O jovem sorri.

QUEST COMPLETE

+1.000 XP

SKILL UNLOCKED: INCIDENT ANALYSIS

Ele pergunta:

— Um dia chego ao Rank S?

O veterano pega novamente o café.

— Se continuar estudando.

— Só isso?

— Não.

— Trabalhando?

— Também.

— Então como?

O veterano olha para a enorme sala de máquinas.

COBOL continuará executando.

Db2 continuará protegendo dados.

CICS continuará processando transações.

RACF continuará dizendo não.

S0C7 continuará encontrando campos impossíveis.

SQLCODE -911 continuará lembrando que ninguém trabalha sozinho.

Deadline continuará correndo.

Technical Debt continuará crescendo escondido.

Novas ferramentas chegarão.

Interfaces serão redesenhadas.

E o Boleto...

Bem.

O Boleto jamais será descontinuado.

Ele coloca a mão no ombro do novato.

— Continue entrando nas dungeons.

— Mesmo com medo?

O veterano abre o famoso sorriso ninja.

😎

— Principalmente quando houver algumas borboletas.

O jovem olha novamente para o terminal.

No canto inferior aparece:

READY

A próxima quest já está esperando.

Um Café no Bellacosa Mainframe

Mesmos sistemas. Novas histórias. Sempre um bom café.

Ficha final do personagem

Classe: Programador Mainframe
Rank inicial: F
Rank máximo: S
Arma: Conhecimento
Escudo: Experiência
Poção: Café
Mapa: Documentação
Party: Equipe
Skill lendária: Reaprender
Fraqueza: “É só uma alteraçãozinha”
Boss recorrente: Deadline
Boss ancestral: Technical Debt
Demon Lord: Boleto
Achievement final: Ainda curioso depois de décadas
Próxima missão: READY >

Para saber mais

https://eljefemidnightlunch.blogspot.com/2026/09/a-guilda-dos-aventureiros-mainframe-por.html



quinta-feira, 21 de maio de 2026

☕🔥 Guia Completo — ABENDs Clássicos do IBM OS/VS e z/OS

Bellacosa Mainframe e a lista de abends


☕🔥 Guia Completo — ABENDs Clássicos do IBM OS/VS e z/OS

Excelente observação!
No resumo anterior realmente ficaram faltando vários ABENDs importantes da lista original do artigo histórico do OS/VS. Agora segue a versão completa, revisada e expandida, incluindo TODOS os códigos mencionados no documento.


🔥 S013 — OPEN ERROR / DCB ERROR

Mensagem comum

IEC141I

O que significa

Falha ao abrir dataset.

Principais causas

  • BLKSIZE incompatível

  • RECFM incorreto

  • LRECL errado

  • Membro inexistente em PDS

Muito comum em

  • SORT

  • COBOL batch

  • IDCAMS


🔥 S0C1 — OPERATION EXCEPTION

O que significa

Execução de instrução inválida.

Causas

  • Overlay de memória

  • Programa corrompido

  • Executar área de dados como código

  • Compilação/link incorreto


🔥 S0C4 — PROTECTION EXCEPTION

O clássico absoluto do z/OS

O que significa

Acesso inválido à memória.

Causas comuns

  • Subscript fora do limite

  • Ponteiro inválido

  • Tabela ultrapassada

  • LINKAGE SECTION incorreta


🔥 S0C5 — ADDRESSING EXCEPTION

O que significa

Tentativa de acessar endereço inexistente.

Muito comum em

  • CALLs errados

  • Parâmetros incompatíveis

  • Ponteiros inválidos


🔥 S0C7 — DATA EXCEPTION

O ABEND mais famoso do COBOL

O que significa

Campo numérico contém valor inválido.

Exemplos clássicos

MOVE 'ABC' TO WS-VALOR-NUM
ADD 1 TO WS-VALOR-NUM

Principais causas

  • Campo COMP-3 corrompido

  • Dados não numéricos

  • Index fora da tabela

  • Working-storage sem inicialização


🔥 S106 — LINK/LOAD ERROR

O que significa

Falha durante LOAD ou LINK.

Causas

  • Biblioteca incorreta

  • Módulo inconsistente

  • Problema de disco


🔥 S213 — DATASET NOT FOUND

Mensagem comum

IEC143I

O que significa

Dataset inexistente.

Causas

  • DSNAME errado

  • Dataset não catalogado

  • VOL=SER incorreto


🔥 S222 — JOB CANCELADO

Mensagem comum

IEF301I

O que significa

Operador cancelou o job.

Normalmente ocorre por

  • Loop infinito

  • Job preso

  • Alto consumo


🔥 S2F3 — SYSTEM FAILURE

O que significa

Falha do sistema operacional durante execução.

Causas

  • Crash do sistema

  • IPL

  • Problema interno do z/OS

Procedimento

  • Reexecutar o job

  • Verificar logs do sistema


🔥 S322 — TIME EXCEEDED

O que significa

Job excedeu o tempo permitido.

Muito comum em

  • Loops infinitos

  • SQL sem índice

  • SORT gigantes

Exemplo

TIME=1

🔥 S613 — TAPE I/O ERROR

Mensagem comum

IEC147I

O que significa

Erro de I/O em fita magnética.

Causas

  • Fita mal posicionada

  • Multi-volume incorreto

  • Problema físico na fita


🔥 S722 — SYSOUT LIMIT EXCEEDED

O que significa

Quantidade de linhas impressas excedeu limite.

Muito comum em

  • LOOP com DISPLAY

  • Relatórios infinitos

  • Dumps excessivos


🔥 S804 — INSUFFICIENT VIRTUAL STORAGE

O que significa

Falta de memória virtual.

Causas

  • REGION pequena

  • Programa gigante

  • Uso excessivo de tabelas

Exemplo

REGION=512K

🔥 S806 — MODULE NOT FOUND

O loader não encontrou o módulo

Causas

  • STEPLIB errada

  • LOADLIB ausente

  • Nome incorreto do programa

Mensagem clássica

CSV003I REQUESTED MODULE NOT FOUND

🔥 S80A — STORAGE SHORTAGE

O que significa

Complemento do S804.

Causa principal

Falta de memória virtual disponível.


🔥 S813 — TAPE LABEL ERROR

Mensagem comum

IEC149I

O que significa

Nome do dataset na fita não bate com DD.

Causas

  • LABEL incorreto

  • DSNAME errado

  • Volume errado


🔥 S913 — RACF SECURITY VIOLATION

Mensagem comum

IEC150I

O que significa

Acesso negado pelo RACF.

Muito comum em

  • Produção

  • Db2

  • GDGs

  • VSAM corporativo


🔥 SA13 — END OF TAPE / FILE NOT FOUND

Mensagem comum

IEC151I

O que significa

Arquivo não encontrado na fita.

Causas

  • LABEL incorreto

  • Número sequencial errado

  • Volume incorreto


🔥 SB37 — OUT OF SPACE

Mensagem comum

IEC030I

O que significa

Dataset ficou sem espaço.

Causas

  • Espaço secundário insuficiente

  • Muitas extents

  • Volume cheio


🔥 SD37 — NO SECONDARY SPACE

Mensagem comum

IEC031I

O que significa

Acabou espaço primário e não existe secondary allocation.

Exemplo clássico

SPACE=(CYL,(10,0))

🔥 SE37 — EXTENT LIMIT EXCEEDED

Mensagem comum

IEC032I

O que significa

Dataset atingiu limite máximo de extents.

Muito comum em

  • PDS antigos

  • SORT gigantes

  • Arquivos temporários


☕🔥 Os ABENDs Mais Icônicos da História do Mainframe

ABENDSignificado
S0C7Data Exception
S0C4Protection Exception
S806Module Not Found
S913RACF Violation
SB37Dataset sem espaço
S322Timeout
S213Dataset não encontrado

☕ Curiosidade Histórica

Nos tempos do:

  • OS/360

  • OS/VS1

  • OS/VS2

  • MVS/XA

os operadores praticamente decoravam os ABENDs “na raça”.

Muitos programadores COBOL antigos conseguiam identificar o erro apenas olhando:

IEF450I

ou:

IEC141I

sem precisar abrir dump.

Isso virou quase uma “linguagem secreta” do mundo mainframe.


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

 

quarta-feira, 9 de abril de 2025

Dr. COBOL, IA e o Caso do S0C7: quando o novato entrou no CPD achando que aprenderia uma linguagem e descobriu que o paciente tinha 47 sistemas dependentes

 

Bellacosa Mainframe e a ia ensinando cobol

☕ Um Café no Bellacosa Mainframe

Dr. COBOL, IA e o Caso do S0C7: quando o novato entrou no CPD achando que aprenderia uma linguagem e descobriu que o paciente tinha 47 sistemas dependentes

🩺 A IA pode se tornar o melhor mentor de um novo profissional COBOL? Talvez. Mas antes ela terá de aprender uma regra básica da medicina, do mainframe e da vida corporativa: o sintoma quase nunca é a doença.

Imagine a cena.

Segunda-feira. 08h13.

O jovem programador COBOL acaba de chegar à empresa. Notebook novo, crachá ainda cheirando a plástico, LinkedIn atualizado com “Mainframe Developer”, uma caneca estrategicamente posicionada ao lado do teclado e a confiança de quem terminou três cursos no fim de semana.

Ele aprendeu:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

PROCEDURE DIVISION.
    DISPLAY 'HELLO WORLD'.
    STOP RUN.

Fantástico.

O mainframe, entretanto, não está nem um pouco impressionado.

Às 08h17 chega uma mensagem:

JOB PAYR042 - ABEND S0C7

O jovem olha para a tela.

A tela olha para o jovem.

Um silêncio constrangedor instala-se no CPD.

Então entra nosso médico imaginário de sistemas legados: manca metaforicamente pelos corredores digitais, olha para o erro, despreza a primeira explicação e sentencia:

“Todo mundo mente. Inclusive os dados.”

Bem-vindo ao Bellacosa Mainframe Hospital.

O paciente de hoje é um sistema com quarenta anos de idade, dois bilhões de registros, sete aplicações dependentes, três copybooks diferentes descrevendo supostamente a mesma coisa e um comentário escrito por alguém chamado Ferreira em 1998:

* ALTERADO CONFORME SOLICITACAO

Qual solicitação?

Ninguém sabe.

Ferreira aposentou-se.

A solicitação provavelmente foi impressa.

O papel talvez tenha virado confete em alguma festa de fim de ano de 2007.

E você achava que aprender COBOL era decorar PERFORM.


🧬 Primeiro diagnóstico: COBOL não é a doença

Existe uma confusão muito comum entre quem começa.

A pessoa pensa:

“Vou aprender COBOL.”

Perfeito.

COBOL é relativamente simples de compreender.

Considere:

IF SALDO >= VALOR-SAQUE
    SUBTRACT VALOR-SAQUE FROM SALDO
    MOVE '00' TO COD-RETORNO
ELSE
    MOVE '51' TO COD-RETORNO
END-IF.

Não precisamos convocar Alan Turing, Grace Hopper, três monges tibetanos e um DBA certificado para compreender o objetivo geral.

Há saldo?

Sim?

Debita.

Não?

Retorna alguma condição de rejeição.

O problema aparece cinco minutos depois.

Você pergunta:

“Onde veio SALDO?”

Talvez de uma estrutura definida no próprio programa.

Talvez de uma copybook:

COPY CONTACLI.

Talvez tenha vindo do Db2.

Talvez tenha sido lido de VSAM.

Talvez tenha chegado numa COMMAREA do CICS.

Talvez tenha vindo de MQ.

Talvez o programa esteja processando um arquivo produzido três jobs antes.

E pronto.

O primeiro exame revelou uma coisa importante:

você não entrou para estudar apenas uma linguagem. Entrou para estudar um organismo.


🩻 A anatomia do paciente mainframe

O iniciante normalmente conhece as partes separadamente:

COBOL
JCL
VSAM
Db2
CICS
IMS
MQ
RACF
JES2
SORT
GDG
SDSF

Isso parece uma coleção de siglas inventada por alguém que recebia bônus por cada abreviação criada.

Mas o profissional experiente começa a enxergar outra coisa.

Ele vê relações.

Imagine um processamento batch:

Scheduler
    |
    v
   JCL
    |
    v
   JES2
    |
    v
Programa COBOL
  /        \
 v          v
VSAM       Db2
 |
 v
SORT
 |
 v
GDG

Agora um fluxo online:

Usuário
   |
   v
Terminal / Aplicação
   |
   v
 CICS
   |
   v
 COBOL
 /    \
v      v
Db2   VSAM
 |
 v
 MQ
 |
 v
Outro sistema

O iniciante vê caixas.

O veterano vê setas.

E sistemas corporativos quebram assustadoramente bem justamente nas setas.

Esse é um conceito que vale guardar.


🩺 “O programa está certo.”

Maravilha.

O arquivo está certo?

A copybook utilizada para ler o arquivo está certa?

O programa produtor usa a mesma versão?

O consumidor espera o mesmo LRECL?

A codificação é a esperada?

O job executou na sequência correta?

A tabela recebeu todos os registros?

O programa anterior terminou com RC=0 ou alguém aceitou RC=4 como “deve estar tudo bem”?

Uma alteração aparentemente minúscula pode parecer:

01 CLIENTE.
   05 CODIGO       PIC 9(08).
   05 NOME         PIC X(30).

Alguém resolve modernizar gloriosamente:

01 CLIENTE.
   05 CODIGO       PIC 9(08).
   05 NOME         PIC X(40).

“São só dez bytes.”

Dez bytes.

A frase equivalente no mainframe a:

“Acho que esse cogumelo não é venenoso.”

O programa novo entende 48 bytes.

Um programa antigo ainda espera 38.

O arquivo passa pela cadeia.

PROGRAMA A
   |
   | layout novo
   v
ARQUIVO
   |
   | layout antigo
   v
PROGRAMA B
   |
   v
💥

E lá aparece nosso amigo:

ABEND S0C7

O sintoma está no Programa B.

A doença nasceu no Programa A.

House ficaria satisfeito.


🤖 Entra a IA na sala de diagnóstico

Agora acontece algo que nenhuma geração anterior de programadores teve nessa escala.

O novato pode perguntar:

“O que é um S0C7?”

A IA explica.

Depois ele pergunta:

“Explique como se eu nunca tivesse trabalhado com mainframe.”

Ela simplifica.

Depois:

“Mostre um exemplo com PIC X sendo tratado como número.”

Ela mostra.

Depois:

“Como um arquivo desalinhado poderia provocar isso?”

Mais uma explicação.

Depois:

“Que informações eu deveria procurar no dump?”

Mais contexto.

Depois:

“Não me dê a solução. Faça perguntas para eu encontrar a causa.”

E aqui começa uma coisa realmente poderosa.

Porque IA deixa de ser apenas Google com diálogo.

Ela pode transformar-se em mentor.


🧠 A IA não precisa dar respostas. Ela pode construir raciocínio

Essa talvez seja uma das maiores oportunidades do ensino técnico moderno.

Suponha que você diga:

Meu programa terminou com S0C7.

Uma IA ruim para treinamento responde:

“O problema está em um campo numérico contendo dados inválidos. Faça X.”

Você corrige.

Funcionou.

Parabéns.

Você resolveu um incidente e talvez tenha aprendido quase nada.

Agora imagine uma IA configurada como mentor:

Em qual instrução ocorreu o abend?

Você responde.

Qual campo estava sendo usado nessa instrução?

Responde.

Como esse campo é declarado?

Responde.

De onde veio o conteúdo dele?

Responde.

Ele foi recebido de arquivo, Db2, CICS ou calculado anteriormente?

Arquivo.

Qual é o layout esperado?

Você procura.

O programa produtor utiliza a mesma copybook?

Hmmmmm.

Agora o cérebro começa a trabalhar.

Temos:

SINTOMA
   |
   v
HIPÓTESE
   |
   v
EVIDÊNCIA
   |
   v
TESTE
   |
   v
RESULTADO
   |
   v
NOVA HIPÓTESE

Isso é troubleshooting.

E troubleshooting é uma das competências mais importantes que você pode desenvolver em mainframe.


🔬 Diagnóstico diferencial para programadores

Na medicina investigativa, vários problemas podem produzir sintomas parecidos.

No mainframe também.

Um job falhou.

Por quê?

O iniciante frequentemente faz:

FALHOU
  |
  v
ACHOU UMA COISA ESTRANHA
  |
  v
DEVE SER ISSO

Perigoso.

Uma abordagem melhor:

FALHOU
  |
  +--> hipótese A
  |
  +--> hipótese B
  |
  +--> hipótese C
  |
  +--> hipótese D

Depois coletamos evidência.

Por exemplo, diante de um erro envolvendo dados:

Hipótese A: campo numérico contém caractere.

Hipótese B: layout utilizado está incorreto.

Hipótese C: arquivo foi produzido com tamanho diferente.

Hipótese D: área de memória foi sobrescrita anteriormente.

Hipótese E: registro inesperado entrou no processamento.

Agora investigamos.

A IA pode ajudar tremendamente nisso.

Mas existe uma regra importante:

Nunca confunda uma hipótese eloquentemente escrita com uma hipótese comprovada.

Modelos de IA são excelentes em produzir explicações plausíveis.

Produção exige evidência.


🦯 Primeiro easter egg: “Everybody lies”

Nosso médico televisivo imaginário repetiria que todo mundo mente.

No mainframe poderíamos adaptar:

Everybody lies. Especially the input file.

O arquivo se chama:

CLIENTES.VALIDADO.DADOS

Não significa que está validado.

Existe uma coluna chamada:

DATA_VALIDACAO

Não significa que alguém validou.

Existe um campo:

05 VALOR-NUMERICO PIC 9(09).

Também não significa que aqueles bytes realmente contenham números.

A máquina acredita em bytes.

Nós acreditamos em nomes.

Essa diferença já derrubou muitos programas.


☕ O antigo mentor da mesa ao lado

Antes da IA, existia uma tecnologia incrivelmente avançada chamada:

Carlos.

Carlos trabalhava na empresa desde 1987.

Você chegava:

“Carlos, S0C7.”

Carlos olhava por dois segundos.

“Vê o arquivo do step anterior.”

Você perguntava:

“Por quê?”

Ele dizia:

“Cara de layout.”

Como assim cara de layout?

😂

Anos depois você entende.

Carlos não estava praticando magia.

Ele possuía uma base estatística mental construída durante milhares de incidentes.

30 anos
   +
5000 incidentes
   +
milhares de dumps
   +
mudanças
   +
erros
   +
produção
   =
"cara de layout"

Experiência é uma espécie de modelo probabilístico ambulante.

O veterano vê sintomas e atualiza mentalmente probabilidades.

Quase um sysprog bayesiano.


🤖 Agora podemos carregar um “Carlos virtual” conosco

A IA pode ocupar parte desse espaço.

Ela nunca dorme.

Não precisa sair para almoçar.

Não diz:

“Leia o manual.”

Mesmo quando, sejamos justos, você deveria ler o manual.

Ela pode explicar DISP=(NEW,CATLG,DELETE) dez vezes.

Primeiro tecnicamente.

Depois usando analogia.

Depois visualmente:

DISP=(NEW,CATLG,DELETE)
       |    |      |
       |    |      +-- Se der errado, apagar
       |    +--------- Se der certo, catalogar
       +-------------- Dataset novo

Ainda não entendeu?

Ela pode comparar com criar um arquivo no Windows.

Ainda não?

Pode construir um exercício.

Ainda não?

Pode perguntar onde está sua dúvida.

Isso resolve um problema pedagógico enorme.


😶 “Professor, eu não entendi.”

Na sala de aula existe vergonha.

O professor explica.

Você pergunta.

Ele explica novamente.

Você continua sem entender.

Olha ao redor.

Todo mundo parece ter entendido.

Provavelmente metade também não entendeu, mas ninguém quer ser o próximo.

Você pensa:

“Vou pesquisar depois.”

Nunca pesquisa.

A IA elimina boa parte dessa pressão social.

Você pode perguntar:

“Explique outra vez.”

“Mais simples.”

“Agora como uma analogia de restaurante.”

“Agora esqueça o restaurante porque piorou.”

😂

Essa adaptabilidade é espetacular.


🗺️ Mas a maior vantagem talvez seja mostrar o mapa

Um dos maiores sofrimentos do novo profissional é não saber onde cada tecnologia se encaixa.

Você aprende JCL.

Depois Db2.

Depois CICS.

Depois VSAM.

Mas ninguém mostra o bairro inteiro.

A IA pode responder:

“Estou estudando COBOL. Onde JCL, Db2, CICS, VSAM e MQ entram?”

E criar:

                SISTEMA CORPORATIVO
                       |
          +------------+------------+
          |                         |
        BATCH                     ONLINE
          |                         |
         JCL                       CICS
          |                         |
        COBOL                     COBOL
       /     \                   /     \
    VSAM     Db2              VSAM     Db2
      \       /                  |
       \     /                   MQ
        DADOS                    |
                            OUTROS SISTEMAS

Agora o estudante ganha um modelo mental.

Depois ele aprofunda cada caixa.

Esse aprendizado é muito melhor do que colecionar siglas.


🌉 IA também pode funcionar como tradutora entre gerações tecnológicas

Imagine alguém vindo de Java.

Podemos explicar conceitos mainframe construindo pontes:

Mundo distribuído          Mainframe

Aplicação                   Programa COBOL
SQL database                Db2
Messaging                   MQ
Transaction manager         CICS
Batch orchestration         JCL + scheduler
Authorization               RACF/SAF
Logs/telemetria             SMF + ferramentas

Mas há uma pegadinha importantíssima.

Analogias ajudam.

Analogias também enganam.

CICS não é simplesmente “Spring Boot antigo”.

JCL não é “um shell script mais velho”.

RACF não é “Active Directory do mainframe”.

Essas comparações podem ensinar uma primeira aproximação, mas depois precisamos perguntar:

“Onde essa analogia deixa de funcionar?”

Essa pergunta é maravilhosa.

Ela transforma conhecimento superficial em conhecimento estrutural.


🏺 O segundo mistério: arqueologia corporativa

Chegamos a uma área em que IA encontra dificuldades especiais.

Veja:

IF COD-AGENCIA = 9999
    PERFORM ROTINA-ESPECIAL
END-IF.

Você pergunta:

“Por que 9999?”

O código não responde.

A documentação não responde.

O Git não responde porque aquele programa nasceu quando Git era apenas o verbo inglês para alguém desagradável.

O comentário informa:

* ALT FERREIRA 12/09/1997

Obrigado novamente, Ferreira.

A IA pode explicar o comportamento.

Pode investigar dependências.

Pode sugerir hipóteses.

Mas talvez só uma pessoa saiba:

“Em 1997 a agência 9999 representava uma unidade centralizadora criada durante uma migração.”

E lá está Carlos novamente.

Tomando café.


🏦 Código possui regras de negócio fossilizadas

Esse é um ponto fundamental para o iniciante.

Você pode encontrar:

IF DIAS-ATRASO > 90
    PERFORM BLOQUEIA-OPERACAO
END-IF.

Programação trivial.

Mas por que 90?

Legislação?

Norma regulatória?

Contrato?

Política comercial?

Uma limitação técnica histórica?

Uma regra que mudou em 2006 e ninguém percebeu?

O código pode explicar como.

O código nem sempre explica por quê.

E profissionais COBOL frequentemente trabalham justamente onde tecnologia e negócio se encontram.

Banco.

Seguro.

Governo.

Cartões.

Logística.

Aviação.

Telecomunicações.

Você não pode ser excelente nesses ambientes conhecendo apenas sintaxe.


🧠 É por isso que JUNIOR + IA = SENIOR é uma conta errada

Existe uma fantasia corporativa muito tentadora:

1 JUNIOR
+
CHATGPT
=
1 SENIOR

Não.

A equação mais razoável é:

JUNIOR + IA
=
JUNIOR MUITO MAIS ACELERADO

Enquanto:

SENIOR + IA
=
SENIOR COM UM EXOESQUELETO COGNITIVO

O júnior ganha velocidade para descobrir conceitos.

O sênior ganha velocidade para analisar, documentar, comparar, automatizar e investigar.

Mas experiência operacional não aparece magicamente porque alguém colocou um prompt bonito.


🚨 O terceiro caso da noite: competência terceirizada

Existe uma doença nova chegando ao hospital.

Chamaremos de:

Síndrome do Ctrl+C / Ctrl+V Cognitivo

Sintomas:

O desenvolvedor recebe erro.

Copia para IA.

Recebe resposta.

Copia solução.

Executa.

Funcionou.

Fecha chamado.

No dia seguinte aparece problema parecido.

Ele copia novamente.

Após dois anos parece possuir dois anos de experiência.

Na realidade talvez possua:

730 dias usando respostas prontas

Isso é perigoso.

Porque conhecimento não é somente conseguir produzir uma ação correta.

Conhecimento significa conseguir responder:

Por que essa ação é correta?

Quando ela seria errada?

Quais consequências pode gerar?

Como provar que resolveu?


🧪 Receita Bellacosa para aprender com IA sem virar passageiro

Quando encontrar um problema, experimente este fluxo:

1. LEIA O ERRO
       |
2. FORMULE SUA HIPÓTESE
       |
3. PEÇA À IA OUTRAS HIPÓTESES
       |
4. PROCURE EVIDÊNCIAS
       |
5. CONSULTE DOCUMENTAÇÃO
       |
6. TESTE EM AMBIENTE SEGURO
       |
7. COMPARE RESULTADOS
       |
8. DOCUMENTE O APRENDIZADO

Observe algo importante.

A IA entrou no passo 3.

Não no passo 1.

Essa pequena diferença muda tudo.


🎓 Transforme a IA num examinador inconveniente

Um prompt educativo muito melhor do que:

“Resolva este problema.”

é:

“Estou aprendendo COBOL. Não me dê a resposta. Faça uma pergunta de cada vez para me ajudar a diagnosticar este erro.”

Agora você está usando IA como mentor.

Outra excelente instrução:

“Quando eu responder, diga se minha hipótese faz sentido e peça evidências.”

Ou:

“Apresente três causas plausíveis, mas não diga qual é a correta. Diga como testar cada uma.”

Isso começa a formar mentalidade investigativa.


🔐 Há ainda um paciente que ninguém pode esquecer: segurança

O iniciante descobre que IA explica código maravilhosamente.

Então pensa:

“Vou colar este programa inteiro.”

Calma.

Aquele programa pode conter:

  • regras de negócio proprietárias;

  • nomes de tabelas;

  • estruturas internas;

  • endpoints;

  • dados pessoais;

  • informações financeiras;

  • arquiteturas sensíveis;

  • credenciais acidentalmente embutidas;

  • detalhes de autorização;

  • nomes de datasets;

  • informações reguladas.

Em ambiente corporativo:

IA + MAINFRAME

sempre deveria vir acompanhado de:

IA
+
SEGURANÇA
+
GOVERNANÇA
+
CLASSIFICAÇÃO DE DADOS
+
COMPLIANCE

A pergunta não é apenas:

“A IA consegue analisar?”

Também é:

“Eu tenho autorização para fornecer isso a ela?”


📚 Quarto easter egg: o manual não morreu

Há uma cena recorrente no suporte técnico.

Pergunta:

“O que significa esse parâmetro?”

Resposta:

“Segundo a documentação…”

O iniciante suspira.

A IA mudou a interface.

Não mudou a necessidade de fonte confiável.

Especialmente em:

  • CICS;

  • Db2;

  • RACF;

  • z/OS;

  • compiladores;

  • opções de runtime;

  • APARs;

  • parâmetros;

  • performance;

  • segurança.

Use IA para compreender documentação.

Não transforme IA em substituta infalível da documentação.

O pipeline saudável é:

IA
 |
 v
EXPLICAÇÃO
 |
 v
DOCUMENTAÇÃO
 |
 v
VALIDAÇÃO
 |
 v
LABORATÓRIO
 |
 v
CONHECIMENTO

🧙‍♂️ O veterano também muda de função

Aqui encontramos algo deliciosamente paradoxal.

Quanto melhor ficar a IA, mais interessante pode ficar o trabalho do mentor humano.

Carlos não precisa mais passar cinquenta minutos explicando:

PIC S9(7)V99 COMP-3

A IA faz isso.

Carlos pode gastar os cinquenta minutos explicando:

“Por que nós usamos esse campo dessa maneira neste sistema?”

Essa pergunta é infinitamente mais rica.

O veterano deixa de ser:

MANUAL HUMANO DE SINTAXE

e passa a ser:

MENTOR
ARQUITETO
CONTEXTUALIZADOR
GUARDIÃO DA MEMÓRIA
CRÍTICO

Talvez a IA não esteja reduzindo o valor do veterano.

Talvez esteja finalmente libertando o veterano para transmitir justamente o conhecimento que nunca coube nos manuais.


🧓➡️🤖➡️🧑‍💻 E podemos preservar conhecimento corporativo

Agora imagine algo ainda maior.

Carlos explica:

“Quando o job X termina com RC=4 durante o fechamento, veja primeiro o arquivo Y. Há uma situação histórica em que ele chega incompleto.”

Esse conhecimento é registrado.

Validado.

Classificado.

Documentado.

Depois colocado numa base corporativa de conhecimento.

VETERANO
   |
   v
EXPERIÊNCIA
   |
   v
DOCUMENTAÇÃO
   |
   v
KNOWLEDGE BASE
   |
   v
IA CORPORATIVA
   |
   v
NOVO PROFISSIONAL

Agora não estamos mais falando apenas de uma IA que conhece COBOL.

Estamos criando uma IA que consegue ajudar pessoas a compreender aquele ambiente.

Isso pode ser revolucionário para organizações com décadas de sistemas legados.


🚀 Minha trilha de seis níveis para o novo COBOLzeiro

Começaria pequeno.

Nível 1 — Aprenda a língua

COBOL básico.

Divisions.

Data Division.

Picture clauses.

MOVE.

IF.

PERFORM.

READ.

WRITE.

CALL.

Aqui a IA funciona muito bem como professora particular.

Nível 2 — Descubra o ecossistema

Comece JCL, datasets, JES, SDSF, Db2, VSAM e CICS.

Não precisa dominar tudo.

Construa o mapa.

Nível 3 — Aprenda a seguir dados

Pergunte sempre:

De onde veio?
Onde está agora?
Quem altera?
Para onde vai?
Quem consome depois?

Esse exercício é poderosíssimo.

Nível 4 — Quebre coisas

Em laboratório, claro.

Cause:

S0C7
S0C4
arquivo inexistente
RC diferente de zero
SQLCODE negativo
registro inválido

Depois investigue.

Quem nunca viu nada quebrado fica perigosamente assustado quando produção quebra.

Nível 5 — Faça diagnóstico, não caça ao Google

Crie hipóteses.

Colete evidências.

Leia logs.

Compare antes/depois.

Aprenda dumps.

Nível 6 — Aprenda o negócio

Finalmente pergunte:

“Por que esse sistema existe?”

Essa é provavelmente uma das perguntas mais importantes de toda sua carreira.


☕ O último caso

São 03h17.

Produção.

O fechamento parou.

Seu monitor mostra:

JOB FINCLOSE
ABEND S0C7

Um ano atrás você teria imediatamente perguntado à IA:

“Como corrigir S0C7?”

Hoje você olha.

Pensa.

Diz mentalmente:

“S0C7 é sintoma.”

Consulta o step.

Descobre o programa.

Localiza a instrução.

Identifica o campo.

Rastreia a origem.

O dado veio de um arquivo.

Você compara o layout.

A copybook do produtor mudou ontem.

A do consumidor não.

Silêncio.

Você encontrou o paciente zero.

Corrige o problema.

Reprocessa.

Alguns minutos depois:

IEF142I FINCLOSE STEP070 - STEP WAS EXECUTED
IEF285I...
MAXCC=0000

Você se recosta na cadeira.

A IA ajudou.

A documentação ajudou.

O mentor ajudou.

Os exercícios ajudaram.

Mas naquele momento havia algo novo dentro da equação:

você.


🩺 Diagnóstico final

Então, afinal:

A IA pode se tornar o melhor mentor para um novo profissional COBOL?

Pode se tornar o mentor mais disponível que já existiu.

Pode repetir infinitamente.

Adaptar explicações.

Construir diagramas.

Criar exercícios.

Comparar COBOL com Java e Python.

Explicar JCL.

Decifrar SQL.

Criar cenários CICS.

Simular incidentes.

Transformar um S0C7 em aula.

Questionar hipóteses.

Acompanhar evolução.

Mostrar conexões que antes demoravam anos para aparecer.

Mas existe uma coisa que precisamos evitar a qualquer custo:

IA
   ↓
RESPOSTA
   ↓
COPIAR
   ↓
PRODUÇÃO

O futuro interessante é:

              CURIOSIDADE
                   |
                   v
              FUNDAMENTOS
                   |
                   v
        +----------+----------+
        |                     |
        v                     v
       IA                 VETERANO
        |                     |
        +----------+----------+
                   |
                   v
             INVESTIGAÇÃO
                   |
                   v
              EVIDÊNCIA
                   |
                   v
             EXPERIÊNCIA
                   |
                   v
           MODELO MENTAL
                   |
                   v
      PROFISSIONAL MAINFRAME

A IA não precisa transformar o iniciante em um falso veterano.

Ela pode fazer algo muito melhor:

ajudar o iniciante a chegar mais rápido ao ponto em que começa a pensar como um profissional.

E aí está a diferença fundamental.

Aprender COBOL nunca foi somente memorizar:

PERFORM PROCESSA-DADOS
    UNTIL FIM-ARQUIVO.

É compreender por que aqueles dados existem, quem os produz, quem depende deles, quais regras representam, quais consequências uma alteração pode provocar e como descobrir o que aconteceu quando alguma coisa inevitavelmente der errado.

Porque no Bellacosa Mainframe Hospital a regra continua valendo:

O erro que aparece na tela é apenas o paciente dizendo onde dói. Não significa que seja ali que está a doença.

E quando o novato finalmente entende isso…

☕ pega a caneca.

🖥️ abre o SDSF.

🩺 observa os sintomas.

🧠 formula hipóteses.

🤖 consulta seu mentor artificial.

📚 confirma na documentação.

🔬 procura evidências.

E então, diante daquele velho sistema que parecia uma criatura incompreensível feita de COBOL, JCL, Db2, VSAM, CICS, copybooks e quarenta anos de decisões humanas, começa finalmente a dizer:

“Interessante… o paciente não está mentindo. Só estamos fazendo a pergunta errada.”

E somewhere, em algum CPD perdido no tempo, Carlos sorri atrás de uma caneca de café.

Porque nasceu mais um COBOLzeiro. ☕🧙‍♂️

terça-feira, 20 de agosto de 2024

Debugando programa COBOL

Bellacosa Mainframe e o debug em cobol

☕ Um Café no Bellacosa Mainframe

Professor Pardal Entra no Abend: a Arte de Debugar COBOL sem Transformar Produção em Patópolis

🐔🔧 S0C7, S0C4, dumps, CEEDUMP, SYSOUT, DISPLAY, offsets, compile listings, Db2, CICS e a velha ciência de descobrir por que um programa que “funcionava ontem” resolveu explodir hoje

Existe uma frase particularmente perigosa no universo mainframe:

“Mas esse programa nunca deu problema.”

Meu jovem Padawan...

Um programa COBOL que está há 27 anos em produção não está necessariamente correto.

Ele pode simplesmente estar há 27 anos esperando o registro certo para explodir.

Então chega terça-feira.

02:47 da manhã.

O telefone toca.

JOB CLIENTE ABENDED
SYSTEM COMPLETION CODE=0C7

Silêncio.

Alguém pergunta:

— Quem alterou o programa?

Resposta:

— Ninguém.

Outra pessoa:

— Mudaram o arquivo?

— Não.

— Db2?

— Não.

— JCL?

— Também não.

Nesse momento, uma pequena porta se abre no CPD.

Entra um galo antropomórfico de chapéu, óculos e ferramentas.

Professor Pardal.

Ele olha para o dump.

Olha para o programador.

Olha novamente para o dump.

E provavelmente pergunta:

“Você leu a mensagem de erro?”

Porque antes de inventarmos observabilidade, AIOps, telemetry, tracing e outras palavras capazes de consumir três slides cada...

já existia uma técnica extraordinariamente eficiente:

LER A PORRA DO ERRO.

Bem-vindo ao maravilhoso mundo do debug COBOL.


🐔 Professor Pardal assume o plantão

Nos quadrinhos Disney, Professor Pardal é aquele inventor capaz de construir praticamente qualquer coisa.

Máquinas impossíveis.

Robôs.

Veículos.

Dispositivos absurdos.

Soluções para problemas que ninguém sabia que possuía.

E frequentemente suas invenções criam problemas ainda maiores.

Ou seja:

perfeitamente qualificado para desenvolvimento corporativo.

Ele também possui um pequeno ajudante robótico chamado Lampadinha.

Portanto nossa arquitetura está pronta:

PROFESSOR PARDAL
      |
      +---- Programador COBOL
      |
      +---- Lampadinha
              |
              +---- IA generativa

Agora precisamos descobrir por que:

COMPUTE WS-TOTAL =
        WS-QUANTIDADE * WS-VALOR.

mandou nosso JOB diretamente para Valhalla.


🧠 Debug não significa olhar código

Primeira lição do Professor Pardal:

debug é investigação.

Existe uma diferença enorme.

O programador desesperado abre o código e começa:

rolando...

rolando...

rolando...

rolando...

Até encontrar alguma coisa que parece suspeita.

Então altera.

Compila.

Executa.

Falha.

Altera outra coisa.

Compila.

Executa.

Falha diferente.

Parabéns.

Você não está fazendo debugging.

Está praticando:

Programação Orientada a Superstição™

Professor Pardal jogaria uma chave inglesa em sua cabeça.

O processo correto começa com evidência.


🔎 1. Qual foi exatamente o ABEND?

Antes de olhar código:

QUAL JOB?
QUAL STEP?
QUAL PROGRAMA?
QUAL ABEND?
QUAL OFFSET?
QUAL ARQUIVO?
QUAL REGISTRO?
QUAL SQLCODE?
QUAL TRANSAÇÃO?

Imagine:

JOBNAME  : FATURA01
STEP     : STEP030
PROGRAM  : FATU120
ABEND    : S0C7

Já sabemos muita coisa.

S0C7 normalmente aponta para uma data exception.

Em linguagem Bellacosa:

alguma operação decimal encontrou algo que não deveria estar ali.

Você esperava:

12345

Recebeu:

12A45

COBOL olhou aquilo.

Pensou por aproximadamente três nanossegundos.

E decidiu:

VAI TOMAR NO CU.

S0C7.

💥 S0C7 — o clássico

Talvez seja o ABEND mais famoso do universo COBOL.

Imagine:

01 WS-VALOR PIC 9(05).

MOVE '12A45' TO WS-VALOR.

ADD 1 TO WS-VALOR.

A movimentação pode deixar dados incompatíveis com aquilo que posteriormente será tratado como numérico.

Quando uma instrução decimal tenta utilizar o campo...

💥

SYSTEM COMPLETION CODE=0C7

Professor Pardal imediatamente pergunta:

De onde veio WS-VALOR?

Essa pergunta vale ouro.

Porque frequentemente o erro não está na instrução que explodiu.

A instrução apenas encontrou o cadáver.


🕵️ A cena do crime

Considere:

READ ARQ-CLIENTES
   AT END
      SET EOF TO TRUE
   NOT AT END
      MOVE CLI-VALOR TO WS-VALOR
END-READ.

...

COMPUTE WS-TOTAL = WS-VALOR * WS-TAXA.

O COMPUTE explode.

Quem é acusado?

COMPUTE

Mas talvez o verdadeiro assassino tenha acontecido vinte instruções antes:

MOVE CLI-VALOR TO WS-VALOR

E talvez CLI-VALOR tenha vindo de:

ARQUIVO

que veio de:

SORT

que veio de:

OUTRO PROGRAMA

que veio de:

DB2

que recebeu dados de:

API

que recebeu alguma porcaria enviada por alguém.

Bem-vindo ao debugging corporativo.


🗺️ O mapa do Professor Pardal

Uma investigação eficiente pode ser visualizada assim:

ABEND
  ↓
STEP
  ↓
PROGRAMA
  ↓
OFFSET
  ↓
INSTRUÇÃO
  ↓
VARIÁVEIS
  ↓
ORIGEM DOS DADOS
  ↓
REGISTRO
  ↓
CAUSA

Não:

ABEND
  ↓
PÂNICO
  ↓
ALTERA QUALQUER COISA
  ↓
COMPILA
  ↓
REZA

Essa segunda metodologia é bastante popular.


📜 2. Leia o dump

Ah, o dump.

Aquele maravilhoso documento de 18 quilômetros que aparece no spool.

O programador iniciante abre:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
HEX HEX HEX HEX HEX HEX HEX HEX
REGISTER REGISTER REGISTER
STORAGE STORAGE STORAGE

Fecha.

E declara:

“Não dá para entender.”

Professor Pardal sorri.

Porque o dump não foi criado para ser bonito.

Foi criado para contar o que existia na memória quando o programa morreu.

É a autópsia.


🧬 CEEDUMP

Em ambientes Language Environment, podemos encontrar informações extremamente úteis no CEEDUMP.

Dependendo da configuração e do problema, você pode conseguir identificar:

  • programa;

  • condição;

  • offset;

  • traceback;

  • rotina;

  • registradores;

  • storage;

  • contexto da falha.

Você não precisa compreender imediatamente cada byte.

Primeiro procure aquilo que reduz o universo da investigação.

Se seu programa possui 25.000 linhas e você descobre aproximadamente onde ocorreu a falha...

já eliminou uma enorme quantidade de Patópolis.


📐 3. O offset é seu amigo

Imagine uma mensagem apontando algo semelhante a:

PROGRAM FATU120
OFFSET X'00001A7C'

Agora temos uma coordenada.

Precisamos relacioná-la ao código compilado.

É aqui que o compile listing se torna extremamente importante.

Dependendo do compilador, opções utilizadas e informações disponíveis, podemos correlacionar offsets com statements/instruções.

Professor Pardal abre sua bancada:

ABEND
+
OFFSET
+
COMPILE LISTING
=
LOCALIZAÇÃO PROVÁVEL

Agora nossa investigação saiu de:

“Existe algum problema no programa.”

para:

“Existe alguma coisa errada nesta região.”

Isso muda tudo.


📚 Compile listing não é papel para alimentar impressora

Durante anos conheci programadores que tratavam listing como aquele negócio gigantesco produzido depois da compilação.

Errado.

Ele pode ser uma verdadeira radiografia do programa.

Dependendo das opções de compilação, encontramos informações sobre:

SOURCE
CROSS-REFERENCE
DATA MAP
PROCEDURE MAP
OFFSETS
MESSAGES
OPTIMIZATION

O velho:

XREF

pode ser particularmente interessante.

Quer saber onde determinada variável aparece?

Em vez de executar:

CTRL+F
CTRL+F
CTRL+F
CTRL+F

você pode analisar suas referências.


🐔 Professor Pardal pergunta: “Quem mexeu nesta variável?”

Imagine:

01 WS-SALDO PIC S9(09)V99 COMP-3.

Você encontra problema em WS-SALDO.

Pergunta:

Quem escreve nele?

Talvez:

01230 MOVE DB2-SALDO TO WS-SALDO
01870 ADD WS-JUROS TO WS-SALDO
02410 MOVE ZERO TO WS-SALDO
03150 COMPUTE WS-SALDO = ...

Agora temos suspeitos.

Debugging começa a parecer investigação criminal.

Porque essencialmente é.


🔦 Lampadinha recomenda DISPLAY

E chegamos à ferramenta mais sofisticada já inventada pela humanidade.

DISPLAY.

Sim.

Pode rir.

Temos ferramentas modernas de debugging.

IDEs.

Debuggers interativos.

Tracing.

Observabilidade.

Ferramentas comerciais excelentes.

Mas existe um momento na carreira de todo COBOLzeiro em que aparece:

DISPLAY 'ENTREI AQUI'.

Depois:

DISPLAY 'WS-VALOR=' WS-VALOR.

Depois:

DISPLAY 'ANTES DO COMPUTE'.

E finalmente:

DISPLAY 'MEU DEUS CHEGOU AQUI'.

É feio?

Sim.

Funciona?

ABSOLUTAMENTE.


⚠️ Mas DISPLAY também pode virar arma de destruição

Professor Pardal faz uma advertência.

Imagine:

PERFORM UNTIL EOF
   READ ARQUIVO
   DISPLAY REGISTRO-INTEIRO
END-PERFORM.

Arquivo:

83.000.000 registros

JES2:

VOCÊ TEM CERTEZA DISSO, FILHO?

Portanto DISPLAY deve ser usado com inteligência.

Talvez:

IF WS-CONTADOR < 100
   DISPLAY ...
END-IF

Ou somente quando determinada condição ocorrer:

IF WS-CLIENTE = 123456
   DISPLAY ...
END-IF

Debugging não deveria provocar um novo incidente.

Embora isso torne a história muito melhor depois.


🧯 S0C4 — entrou onde não deveria

Outro clássico:

S0C4

De maneira simplificada, estamos frequentemente olhando para algum problema de acesso à memória/storage, endereço inválido ou operação relacionada.

É uma família de situações que exige analisar contexto.

Ponteiros.

Índices.

Subscripts.

CALLs.

Parâmetros.

Storage.

Professor Pardal imediatamente procura coisas como:

SET ADDRESS OF ...

ou tabelas:

01 TABELA.
   05 ITEM OCCURS 100 TIMES.

e alguém fazendo:

ITEM(347)

A tabela possui 100 posições.

O programador quer acessar 347.

COBOL responde:

interessante.

O sistema responde:

S0C4.


📦 SSRANGE — o cinto de segurança

Durante desenvolvimento e testes, opções como SSRANGE podem ajudar enormemente na identificação de problemas relacionados a referências fora dos limites permitidos.

É o equivalente COBOL de colocar Professor Pardal ao lado da tabela dizendo:

“Meu amigo, existem 100 posições aqui. Por que você está tentando acessar a 347?”

Naturalmente existe custo associado às verificações adicionais, portanto decisões de compilação para desenvolvimento, teste e produção precisam considerar o ambiente e as políticas da organização.

Mas durante diagnóstico?

Pode ser extremamente útil.


🧮 COMP-3: onde mora o demônio hexadecimal

Agora entramos numa região particularmente divertida.

Packed decimal.

PIC S9(7)V99 COMP-3.

O programador iniciante olha um dump hexadecimal e pensa:

Satanás.

O COBOLzeiro experiente olha:

12 34 56 78 9C

e pensa:

Ah, 1234567,89 positivo.

E continua tomando café.

Campos COMP-3 são eficientes e tradicionais no processamento decimal empresarial.

Mas quando dados inválidos entram nesse território...

o S0C7 começa a afiar a faca.


🧪 TESTE O DADO, NÃO SUA FÉ

Uma das grandes lições do debugging é:

nunca confie cegamente na entrada.

“Mas o arquivo vem de outro sistema.”

Maravilha.

Outro sistema também possui programadores.

“Mas vem do banco.”

Ótimo.

“Mas existe validação.”

Excelente.

Mesmo assim:

VALIDATE.

Porque sistemas antigos frequentemente acumulam décadas de exceções, migrações, conversões e pequenas decisões históricas.

O campo chamado:

DATA-NASCIMENTO

pode conter:

00000000
99999999
20260231
        

e algum valor que ninguém consegue explicar desde 1987.


🗄️ Quando o culpado é Db2

Agora nosso programa executa SQL.

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CLIENTE
    WHERE ID = :WS-ID
END-EXEC.

Professor Pardal pergunta imediatamente:

SQLCODE?
SQLSTATE?

Não faça isto:

EXEC SQL
   ...
END-EXEC

CONTINUE.

Faça tratamento adequado.

Porque:

SQLCODE = 0

é uma história.

SQLCODE = +100

é outra.

Valores negativos contam histórias ainda mais interessantes.

Um bom debug de aplicação Db2 exige entender não apenas COBOL, mas a conversa entre:

PROGRAMA
   ↕
SQL
   ↕
DB2

🏦 CICS: agora o pato ficou bravo

Batch já é divertido.

Então entramos no CICS.

Agora temos:

TRANSACTION
COMMAREA
CHANNELS
CONTAINERS
RESP
RESP2
EIBRESP
EIBRCODE
MAPAS
TSQ
TDQ
FILES
DB2
MQ

E o usuário diz:

“A tela fechou.”

Excelente descrição técnica.

Professor Pardal pergunta:

Qual transação?

Usuário:

“Aquela azul.”

Bem-vindo ao suporte.


🚨 RESP e RESP2

Uma prática importantíssima no CICS é não tratar comandos como se fossem infalíveis.

Exemplo conceitual:

EXEC CICS READ
     FILE('CLIENTE')
     INTO(WS-REGISTRO)
     RIDFLD(WS-CHAVE)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC.

Agora conseguimos investigar.

Em vez de:

NÃO FUNCIONOU

temos informação sobre a resposta da operação.

Debugging é justamente isso:

transformar “não funciona” em evidência mensurável.


🧠 Professor Pardal apresenta o método científico

A melhor maneira de debugar COBOL não é decorar ABENDs.

É pensar como cientista.

Temos:

OBSERVAÇÃO
    ↓
HIPÓTESE
    ↓
TESTE
    ↓
EVIDÊNCIA
    ↓
CONCLUSÃO

Exemplo:

Observação

S0C7 durante cálculo.

Hipótese

WS-VALOR contém dados não numéricos.

Teste

Inspecionar campo imediatamente antes da operação.

Evidência

WS-VALOR = '00012A45'

Nova pergunta

Quem colocou A ali?

Seguimos para trás.

Isso é debugging.


❌ O anti-debug

O método corporativo alternativo é:

S0C7
 ↓
"DEVE SER O DB2"
 ↓
DBA INVESTIGA
 ↓
NÃO É DB2
 ↓
"DEVE SER INFRA"
 ↓
INFRA INVESTIGA
 ↓
NÃO É INFRA
 ↓
"SERÁ A REDE?"
 ↓
NETWORK INVESTIGA
 ↓
NÃO É REDE
 ↓
3 HORAS DE WAR ROOM
 ↓
CAMPO NUMÉRICO CONTINHA 'X'

Professor Pardal abandona Patópolis.


🤖 Lampadinha ganhou IA generativa

Agora chegamos a 2026.

Imagine Professor Pardal com uma Lampadinha equipada com IA.

Você fornece:

ABEND
dump
compile listing
trecho COBOL
copybook
JCL
mensagens

E pergunta:

“Quais são as hipóteses mais prováveis?”

Isso pode acelerar brutalmente a investigação.

IA pode ajudar a:

  • interpretar mensagens;

  • explicar código legado;

  • correlacionar variáveis;

  • sugerir pontos de inspeção;

  • construir hipóteses;

  • explicar hexadecimal;

  • analisar fluxos;

  • sugerir casos de teste.

Mas existe uma regra fundamental:

IA NÃO TRANSFORMA HIPÓTESE EM EVIDÊNCIA.

Se Lampadinha disser:

“Provavelmente WS-VALOR possui dado inválido.”

Excelente.

Agora prove.


🧠 IA pode alucinar. Dump não.

Esta frase deveria estar colada em toda War Room moderna.

IA:
"Talvez seja..."

DUMP:
"ERA ISTO."

Use IA como copiloto investigativo.

Não como oráculo.

Especialmente em ambientes críticos.

E jamais copie dumps de produção contendo dados sensíveis para serviços externos sem autorização, mascaramento e respeito às políticas de segurança.

Professor Pardal é maluco.

Mas RACF continua observando.


🔐 DEBUG também é segurança

Essa parte frequentemente é esquecida.

Dump pode conter:

CPF
CONTA
NOME
TOKEN
CARTÃO
ENDEREÇO
DADOS FINANCEIROS
CHAVES
CREDENCIAIS

DISPLAY também pode colocar dados sensíveis no spool.

Logs permanecem.

SYSOUT permanece.

Ferramentas armazenam informações.

Portanto:

DEBUG ≠ LIBEROU GERAL

Em produção, diagnóstico precisa respeitar controles de segurança e privacidade.


🧰 A caixa de ferramentas do Professor Pardal

Nosso laboratório COBOL pode conter várias ferramentas e técnicas:

ABEND MESSAGES
SYSOUT
JES/SDSF
DUMP
CEEDUMP
COMPILE LISTING
XREF
OFFSET
DISPLAY
SSRANGE
TEST OPTIONS
DEBUGGERS
FAULT ANALYSIS TOOLS
FILE INSPECTION
DB2 DIAGNOSTICS
CICS DIAGNOSTICS
SMF
LOGS

Nenhuma ferramenta substitui raciocínio.

Porque o problema fundamental continua sendo:

O que o programa deveria fazer e o que ele realmente fez?

Essa diferença é o território do debugger.


🧭 O algoritmo Bellacosa-Pardal de Debug COBOL™

Quando alguma coisa explodir:

1. NÃO ENTRE EM PÂNICO
        ↓
2. IDENTIFIQUE JOB/STEP/PROGRAMA
        ↓
3. LEIA O ABEND/MENSAGEM
        ↓
4. PROCURE OFFSET/TRACEBACK
        ↓
5. CONSULTE O LISTING
        ↓
6. IDENTIFIQUE A INSTRUÇÃO
        ↓
7. INSPECIONE AS VARIÁVEIS
        ↓
8. DESCUBRA QUEM AS ALTEROU
        ↓
9. RASTREIE A ORIGEM DOS DADOS
        ↓
10. CRIE UMA HIPÓTESE
        ↓
11. TESTE
        ↓
12. REPRODUZA
        ↓
13. CORRIJA A CAUSA
        ↓
14. FAÇA TESTE DE REGRESSÃO
        ↓
15. DOCUMENTE

Observe o item 13:

CORRIJA A CAUSA.

Não simplesmente o sintoma.


🩹 O remendo que cria o monstro

Programa:

IF WS-VALOR IS NUMERIC
   COMPUTE ...
END-IF.

Problema desapareceu.

CABÔ!

Talvez.

Mas espere.

Por que WS-VALOR não era numérico?

Se deveria obrigatoriamente ser...

você acabou de esconder um problema de qualidade de dados.

O programa não explode mais.

Agora apenas ignora silenciosamente dinheiro.

Excelente.

Transformamos um S0C7 visível em um erro contábil invisível.

Professor Pardal começa a suar frio.


🧪 Corrigir não é provar

Depois da alteração:

“Funcionou.”

Não significa:

“Está correto.”

Precisamos testar:

CASO ORIGINAL
CASOS NORMAIS
LIMITES
ZEROS
NEGATIVOS
VALORES MÁXIMOS
DADOS INVÁLIDOS
ARQUIVO VAZIO
DUPLICIDADES
ERROS DB2
ERROS CICS

E principalmente:

garantir que você não consertou uma coisa quebrando três.

Esse fenômeno é conhecido tecnicamente como:

sexta-feira às 17h43.


📚 Documente o incidente

Encontramos:

CAUSA:
campo VALOR recebeu caractere inválido.

ORIGEM:
programa anterior gerou registro inconsistente.

IMPACTO:
JOB FATURA01 interrompido.

CORREÇÃO:
validação corrigida na origem.

PREVENÇÃO:
teste adicionado.

Isso vale muito mais do que:

PROBLEMA RESOLVIDO.

Daqui a três anos outro programador pode encontrar situação semelhante.

E descobrir que o Professor Pardal de 2026 deixou um mapa.


🐔 O melhor debugger não é quem conhece todos os ABENDs

É quem sabe fazer boas perguntas.

O QUE FALHOU?

ONDE?

QUANDO?

COM QUAL DADO?

SEMPRE ACONTECE?

QUAL FOI A ÚLTIMA EXECUÇÃO BOA?

O QUE MUDOU?

CONSEGUIMOS REPRODUZIR?

QUAL VARIÁVEL ESTAVA ERRADA?

QUEM ALTEROU ESSA VARIÁVEL?

DE ONDE VEIO O DADO?

Cada resposta reduz o espaço de busca.

Debugging é uma batalha contra possibilidades.

Começamos com:

QUALQUER COISA PODE ESTAR ERRADA

e terminamos com:

ESTE BYTE ESTÁ ERRADO.

Isso é lindo.


☕ Professor Pardal termina seu café

Depois de duas horas de investigação encontramos a causa.

Um arquivo recebido por um programa COBOL possuía um registro:

0000000000000012578

e outro:

00000000000000A2578

Um único caractere.

Um miserável:

A

No meio de milhões de registros.

Esse pequeno A atravessou sistemas.

Passou por arquivos.

Entrou no programa.

Chegou a um campo tratado como numérico.

Esperou pacientemente.

Então encontrou uma operação decimal.

E derrubou um JOB gigantesco.

Milhares de linhas COBOL.

Db2.

JES2.

z/OS.

Mainframe de milhões de dólares.

Equipe de operações.

Desenvolvedores.

DBAs.

War Room.

Gestores.

Todos derrotados por:

A

Professor Pardal olha para Lampadinha.

Lampadinha olha para o dump.

O operador pergunta:

— Então era o mainframe?

Pardal responde:

— Não.

— Era COBOL?

— Não.

— Db2?

— Não.

— CICS?

— Também não.

— Então o que era?

Ele aponta para o registro.

A

Silêncio.

O JOB é reprocessado.

IEF142I FATURA01 STEP030 - STEP WAS EXECUTED
IEF285I
MAXCC=0000

E mais uma vez o gigantesco dinossauro de silício volta a trabalhar como se absolutamente nada tivesse acontecido.


🦖 A moral da história

Depois de décadas trabalhando com software, aprendemos uma coisa desconfortável:

os bugs mais difíceis nem sempre são tecnicamente sofisticados.

Às vezes são apenas pequenos.

Escondidos.

Intermitentes.

Dependentes de dados.

Dependentes de sequência.

Dependentes de uma combinação que acontece uma vez a cada cinco milhões de registros.

Por isso ferramentas são importantes.

Mas método é mais importante.

Professor Pardal pode possuir a oficina inteira.

Lampadinha pode possuir inteligência artificial.

Você pode ter o melhor debugger disponível.

Mas no final alguém ainda precisa perguntar:

“O que aconteceu imediatamente antes disso?”

E continuar perguntando.

Até encontrar aquele miserável byte que resolveu transformar uma madrugada tranquila em uma War Room.


☕ Epílogo — Um Café no Bellacosa Mainframe

03:58.

Incidente encerrado.

Professor Pardal guarda suas ferramentas.

Lampadinha desliga a IA.

Operações fecha o chamado.

O gerente pergunta:

“Podemos considerar causa raiz identificada?”

Sim.

“Podemos evitar recorrência?”

Sim.

“Precisamos de reunião amanhã?”

...

Professor Pardal olha para o relógio.

Olha para o mainframe.

Olha para Lampadinha.

Lampadinha discretamente apaga a luz.

E ambos fogem de Patópolis antes que alguém consiga pronunciar:

“Post-Mortem.”

🐔🔧☕🦖

JOB DEBUGPARDAL — MAXCC=0000

E todos viveram felizes...

até o próximo S0C7.

https://eljefemidnightlunch.blogspot.com/2026/06/a-saga-de-vagner-bellacosa-no-reino-dos.html

DISPLAY e BUG TRAP as melhores maneiras de debugar um programa COBOL. Qual é a sua técnica? #ibm #mainframe #cobol #debug #trap #bug #returncode #maxcc #jcl #sdsf #job

 
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...