Bellacosa Mainframe e o meu projeto de assistant

☕💣Laboratorio Bellacosa Mainframe Assistant

"Porque nem todo problema precisa virar um ABEND."

🚀 Sobre o Projeto

O Bellacosa Mainframe Assistant é um assistente virtual especializado em tecnologias IBM Mainframe, criado para ajudar estudantes, operadores, desenvolvedores e administradores a navegar pelo universo do z/OS sem precisar abrir cinquenta manuais da IBM ao mesmo tempo.

A proposta é unir Inteligência Artificial com décadas de conhecimento acumulado sobre:

• COBOL
• JCL
• CICS
• DB2
• RACF
• TSO/ISPF
• JES2
• VSAM
• SORT
• IDCAMS
• z/OS
• Aspera
• Operação Mainframe

Tudo explicado de forma simples, prática e com exemplos reais de ambiente corporativo.

---

🎯 Objetivo

Reduzir a curva de aprendizado de profissionais que desejam:

• Entrar no mercado Mainframe
• Evoluir tecnicamente
• Resolver problemas operacionais
• Entender mensagens de sistema
• Aprender boas práticas
• Modernizar aplicações legadas

---

👨‍💻 Público-Alvo

Este agente foi desenvolvido para:

Iniciantes

Pessoas que nunca acessaram um ISPF e ainda acham que JCL é uma linguagem de programação.

Desenvolvedores

Profissionais que trabalham com:

• COBOL
• PL/I
• Natural
• Assembler

Operadores

Profissionais responsáveis por:

• JES2
• Spool
• SDSF
• Console
• Monitoramento

Administradores

Especialistas em:

• RACF
• CICS
• DB2
• z/OS

Empresas

Organizações que desejam preservar conhecimento técnico e acelerar treinamentos.

---

☕ Filosofia Bellacosa Mainframe

O agente segue alguns princípios simples:

1. Explicar sem complicar

A IBM já escreveu os manuais.

O objetivo aqui é traduzir o "IBMês" para português humano.

---

2. Ensinar com exemplos reais

Ao invés de apenas mostrar sintaxe:

//STEP01 EXEC PGM=IEFBR14

o agente explica:

"Esse é o famoso Hello World do operador Mainframe."

---

3. Contar a história por trás da tecnologia

Porque entender:

• por que o RACF existe
• por que o VSAM foi criado
• por que o JES2 funciona da forma atual

faz toda diferença no aprendizado.

---

4. Misturar técnica e curiosidade

Você pode aprender:

• Como funciona um checkpoint do JES2
• Como um ABEND acontece
• Como a NASA utilizou Mainframes
• Como bancos processam milhões de transações

Tudo na mesma conversa.

---

📚 Base de Conhecimento

Desenvolvimento

• COBOL
• Enterprise COBOL
• COBOL/400
• PL/I
• Natural
• Assembler

Processamento Batch

• JCL
• PROC
• Utilities
• SORT
• DFSORT
• Syncsort

Banco de Dados

• DB2
• VSAM
• IMS

Online

• CICS
• Web Services
• REST APIs
• z/OS Connect

Segurança

• RACF
• Perfis
• Classes
• Permissões

Operação

• JES2
• SDSF
• Console
• Spool
• WLM

Administração

• TSO
• ISPF
• SMP/E
• Catalogs

---

🧠 Como o Agente Responde

O Bellacosa Mainframe Assistant procura:

1. Entender o problema.
2. Explicar o conceito.
3. Mostrar um exemplo.
4. Apresentar boas práticas.
5. Alertar sobre armadilhas comuns.

---

💬 Exemplos de Perguntas

COBOL

"Como funciona um READ em VSAM?"

JCL

"Qual a diferença entre COND e IF/THEN?"

RACF

"Como conceder acesso a um dataset?"

JES2

"O que significa a mensagem $HASP250?"

CICS

"Como criar um Web Service em COBOL?"

---

📊 Métricas de Sucesso

O agente será avaliado por:

Métrica	Objetivo
Precisão	> 90%
Clareza	> 90%
Tempo de Resposta	< 5 segundos
Satisfação	> 4,5/5

---

🔧 Tecnologias Utilizadas

• Inteligência Artificial Generativa
• Processamento de Linguagem Natural
• Bases de Conhecimento Especializadas
• Documentação IBM
• Engenharia de Prompt

---

🔮 Evoluções Futuras

• Integração com manuais IBM
• Laboratórios interativos
• Simulador de JCL
• Simulador de RACF
• Simulador de Operação JES2
• Quiz automático
• Geração de exemplos COBOL
• Correção automática de JCL

---

☕💣 Mensagem Final

Mainframe não é tecnologia antiga.

É tecnologia que continua funcionando enquanto muitas outras já foram substituídas várias vezes.

O Bellacosa Mainframe Assistant nasceu para mostrar que aprender Mainframe pode ser tão interessante quanto assistir uma série, jogar um RPG ou explorar um novo universo tecnológico.

Porque no fim das contas...

Todo operador já derrubou um JOB.

Todo programador já causou um ABEND.

E todo profissional Mainframe tem pelo menos uma história impossível de acreditar durante o café.

Bem-vindo ao Bellacosa Mainframe Assistant.

https://github.com/VagnerBellacosa/395_ConstruaAssistenteVirtual_IAGenerativa

☕💣 Bellacosa Mainframe Assistant

Projeto desenvolvido para o desafio Construa seu Assistente Virtual com IA Generativa.
Um especialista virtual focado em COBOL, JCL, CICS, DB2, RACF, JES2, VSAM, TSO/ISPF e tecnologias IBM Mainframe.

🚀 Abrir Projeto no GitHub

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

• 28.000 linhas

• 134 COPYBOOKS

• 742 parágrafos

• Comentários da época do Plano Real

• Um PERFORM THRU que ninguém entende

• Um campo chamado WK-AREA1

• Outro chamado WK-AREA2

• Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica

---

O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

• principal

• juros

• correção

• multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.

---

EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

• 3.000 agências

• dezenas de fusões

• múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.

---

COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.

---

Frase 2

"É só uma correção rápida."

Nunca é.

---

Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.

---

Frase 4

"Não mexe porque funciona."

O terror dos bancos.

---

OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

• GOTO excessivo

• PERFORM THRU gigantes

• variáveis sem significado

• duplicação

---

2. Arquitetura

Problemas maiores.

Exemplos:

• sistemas monolíticos

• dependências excessivas

• integrações frágeis

---

3. Dados

Muito comum em bancos.

Exemplos:

• arquivos VSAM redundantes

• tabelas DB2 duplicadas

• dados inconsistentes

---

4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

• deploy manual

• testes manuais

• documentação inexistente

---

COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.

---

Sintoma 1

Mudanças simples levam semanas.

---

Sintoma 2

Toda alteração gera incidente.

---

Sintoma 3

Poucas pessoas entendem o sistema.

---

Sintoma 4

Ninguém quer mexer.

---

Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.

---

MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.

---

1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

• mais difícil testar

• mais difícil manter

• maior risco

Meta saudável:

• abaixo de 10 excelente

• até 20 aceitável

• acima de 30 perigoso

---

2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

• 500 linhas → simples

• 5.000 linhas → atenção

• 20.000 linhas → investigação

---

3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

• cadastro

• empréstimo

• cartão

• investimentos

Quando muda uma regra:

quatro programas precisam mudar.

---

4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.

---

5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.

---

6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?

---

FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.

---

IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

• dependências

• impacto

• análise de código

Mostra relacionamentos invisíveis.

---

IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

• DevOps

• testes

• integração

---

SONARQUBE

Uma das mais famosas.

Analisa:

• complexidade

• duplicação

• vulnerabilidades

Possui suporte para COBOL.

---

TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

• visualização

• debugging

• análise

---

ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.

---

GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.

---

COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.

---

PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

• onde está

• quanto existe

• qual impacto

---

PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.

---

PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.

---

PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.

---

PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.

---

PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.

---

PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.

---

O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

---

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.

---

CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.

---

A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

• melhorar nomes

• remover comentários obsoletos

• eliminar duplicações

Pequenas melhorias acumulam enormes resultados.

---

O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

• processar pagamentos

• movimentar bilhões

• atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.

---

O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"

---

☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

• Internet Banking

• Aplicativos móveis

• Chatbots

• APIs

• Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.

---

O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

---

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

• Portais Web

• Gateways API

• Aplicativos móveis

• Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.

---

O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

• Processos manuais escondidos

• Dependência excessiva de funcionários específicos

• Sistemas sem escalabilidade

• Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.

---

☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.

---

O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

• Comprar servidores

• Instalar servidores

• Configurar servidores

Meses de trabalho.

---

NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.

---

A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.

---

RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.

---

O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.

---

O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.

---

👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.

---

O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.

---

O DIA DO DESASTRE

Essa pessoa:

• aposenta

• muda de empresa

• entra em férias

Pronto.

Agora existe um risco operacional.

---

O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.

---

O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

• Git

• APIs

• DevOps

• Cloud

• Automação

• CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.

---

O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.

---

UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

• Git

• VS Code

• Zowe

• APIs REST

• Jenkins

• SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.

---

UM COBOL ANTIGO É REPELENTE

Agora imagine:

• documentação inexistente

• deploy manual

• FTP

• planilhas Excel

• mudanças sem controle

O problema não é COBOL.

É a cultura.

---

O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

• hardware

• software

• licenças

Mas esquecem:

• turnover

• treinamento

• conhecimento perdido

Esses custos podem superar os custos tecnológicos.

---

O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.

---

O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

---

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

• agilidade

• automação

• integração

• APIs

• escalabilidade

• experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

• pessoas

• conhecimento

• processos

• documentação

• cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.

---

CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

• documentação

• testes

• APIs

• observabilidade

• versionamento

• arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.

 

Bellacosa Mainframe como pagar dividas tecnicas em mainframe

☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998

Existe uma frase muito conhecida no mercado de tecnologia:

"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."

Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.

Mas a verdade é muito mais divertida.

Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.

Toda vez que alguém dizia:

"Depois a gente arruma."

Nascia uma nova parcela.

E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.

Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.

---

O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.

Imagine um programa COBOL.

Você precisa entregar uma alteração urgente.

O correto seria:

• Revisar arquitetura

• Atualizar documentação

• Criar testes

• Refatorar módulos

Mas o prazo é amanhã.

Então alguém faz:

IF CLIENTE = '999999'
    GO TO TRATAMENTO-ESPECIAL.

Entrega.

Produção funciona.

Cliente feliz.

Projeto encerrado.

Mas daqui a dois anos ninguém lembra por que aquele IF existe.

A dívida nasceu.

---

O MAIOR MITO DO MAINFRAME

Muita gente acredita que:

"Código antigo é dívida técnica."

Errado.

Código antigo pode ser excelente.

Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.

Por outro lado, existem programas escritos há seis meses que já nasceram endividados.

A idade do código não importa.

O que importa é:

• Complexidade

• Manutenibilidade

• Clareza

• Testabilidade

• Documentação

---

COMO IDENTIFICAR DÍVIDA TÉCNICA

O primeiro passo é aprender a enxergá-la.

Alguns sintomas clássicos:

Programa que ninguém quer alterar

Quando uma demanda chega e todos falam:

"Tomara que não seja naquele programa..."

Existe dívida.

---

Alteração simples demora dias

Mudança:

Trocar 20 para 25.

Tempo gasto:

3 dias

Existe dívida.

---

Muitos abends

Se o mesmo módulo gera incidentes frequentemente:

• S0C7

• S0C4

• SQLCODE negativos

• Arquivos inconsistentes

Existe dívida.

---

Dependência de especialistas

Quando apenas uma pessoa entende o sistema.

Isso é uma dívida técnica humana.

Extremamente perigosa.

---

A METÁFORA DO CARTÃO DE CRÉDITO

A IBM utiliza uma analogia excelente.

Imagine um cartão.

Você compra algo hoje.

O benefício é imediato.

O pagamento fica para depois.

Dívida técnica funciona igual.

Benefício imediato:

Entreguei no prazo

Pagamento futuro:

Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho

O problema não é usar o cartão.

O problema é esquecer da fatura.

---

COMO MAPEAR A DÍVIDA TÉCNICA

A primeira atividade prática é criar um inventário.

Monte uma planilha contendo:

Sistema	Problema	Impacto	Prioridade
Cadastro	GO TO excessivo	Médio	Média
Cobrança	Sem documentação	Alto	Alta
Faturamento	Alta complexidade	Alto	Alta

Você não consegue corrigir aquilo que não consegue enxergar.

---

MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA

Uma das métricas mais famosas.

Ela mede quantos caminhos lógicos existem em um programa.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Pouca complexidade.

Agora imagine:

IF A
 IF B
  IF C
   IF D

A complexidade explode.

Quanto maior a complexidade:

• Mais difícil testar

• Mais difícil manter

• Maior risco de erro

Regra prática:

Valor	Situação
1 a 10	Boa
11 a 20	Atenção
Acima de 20	Risco

---

MÉTRICA 2 – TEMPO DE MANUTENÇÃO

Métrica simples.

Quanto tempo leva para implementar uma mudança?

Exemplo:

Alteração simples:

4 horas

Virou:

3 dias

A dívida está cobrando juros.

---

MÉTRICA 3 – QUANTIDADE DE INCIDENTES

Monitore:

• Chamados

• Tickets

• Problemas recorrentes

Se determinado programa gera:

20% dos incidentes

Ele deve entrar imediatamente no backlog técnico.

---

MÉTRICA 4 – COBERTURA DE TESTES

Quanto do sistema possui testes?

Exemplo:

10%

Muito arriscado.

80%

Muito saudável.

No mundo COBOL isso pode envolver:

• Unit Test

• Testes automatizados

• Batch Validation

---

MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO

MTTR

Mean Time To Recovery.

Quanto tempo leva para resolver um problema?

Exemplo:

10 minutos

Excelente.

8 horas

Existe forte dívida técnica.

---

A REGRA DOS 20%

Uma prática muito utilizada é reservar:

80% desenvolvimento
20% redução de dívida técnica

Isso impede que a dívida cresça infinitamente.

---

TÉCNICA 1 – REFATORAÇÃO CONTÍNUA

Refatorar significa melhorar sem alterar comportamento.

Exemplo:

Antes:

GO TO ERRO.
GO TO ERRO.
GO TO ERRO.

Depois:

PERFORM TRATA-ERRO.

Mesmo resultado.

Código mais limpo.

---

TÉCNICA 2 – MODULARIZAÇÃO

Programas gigantes são fábricas de dívida.

Já encontrei programas com:

80.000 linhas

Divida responsabilidades.

Crie módulos menores.

Mais simples de entender.

Mais simples de testar.

---

TÉCNICA 3 – DOCUMENTAÇÃO VIVA

Documentação morta é inútil.

Documentação viva é atualizada junto com o sistema.

Documente:

• Fluxos

• Arquivos

• Tabelas

• Regras de negócio

---

TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO

Existe um cemitério escondido em todo sistema.

Trechos como:

IF FLAG = 'X'

Que nunca mais executam.

Remover código morto reduz:

• Complexidade

• Risco

• Tempo de manutenção

---

TÉCNICA 5 – BACKLOG TÉCNICO

Crie um backlog específico.

Exemplo:

Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto

A dívida precisa aparecer oficialmente.

Caso contrário ela nunca será priorizada.

---

FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME

IBM Application Discovery

Mapeia dependências.

Mostra:

• Programas

• Arquivos

• CICS

• DB2

Excelente para arqueologia de sistemas.

---

IBM ADDI

Application Discovery and Delivery Intelligence.

Permite visualizar relacionamentos invisíveis.

Muito útil para sistemas legados.

---

SonarQube

Mesmo para COBOL.

Detecta:

• Complexidade

• Duplicação

• Código suspeito

---

IBM Developer for z/OS

Auxilia:

• Navegação

• Análise

• Refatoração

---

Jira

Controle de backlog técnico.

Muitas empresas utilizam para registrar dívida técnica.

---

EASTER EGG MAINFRAME

Quer descobrir rapidamente onde existe dívida?

Procure:

GO TO
ALTER
NEXT SENTENCE

Ou:

STEP099
STEP100
STEP101

Sem documentação.

Você provavelmente encontrou um sítio arqueológico corporativo.

---

O ERRO MAIS COMUM DOS JUNIORES

Pensar:

"Vou reescrever tudo."

Não.

Esse é o caminho para o desastre.

A melhor estratégia quase sempre é:

Pequenas melhorias contínuas.

Todo dia.

Toda sprint.

Todo projeto.

Toda manutenção.

---

COMO EVOLUIR COMO PROFISSIONAL

Programadores experientes não são aqueles que escrevem mais código.

São aqueles que reduzem complexidade.

Quando você consegue olhar para um sistema e dizer:

"Esse trecho vai gerar problema daqui a dois anos."

Você começou a pensar como arquiteto.

---

O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS

Eles não combatem apenas bugs.

Eles combatem as causas dos bugs.

Essa é a diferença entre apagar incêndios e construir sistemas duradouros.

---

CONCLUSÃO

Dívida técnica não é um defeito.

Ela é uma ferramenta.

Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.

O problema surge quando ninguém controla o saldo.

O programador COBOL júnior que aprender a:

• Identificar dívida

• Medir dívida

• Priorizar dívida

• Reduzir dívida

• Monitorar dívida

Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.

Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.

É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.

 

Bellacosa Mainframe divida tecnica decisões erradas que pagamos até hoje

☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

Existe uma lenda antiga nos CPDs.

Ela diz que, em algum lugar do ambiente de produção, existe um programa COBOL que ninguém entende.

Ninguém sabe quem escreveu.

Ninguém sabe por que funciona.

Ninguém sabe o que acontece se ele parar.

Mas todos sabem de uma coisa:

ninguém tem coragem de mexer nele.

Se você trabalha em Mainframe há algum tempo, provavelmente já encontrou um desses.

Talvez ele tenha 30 mil linhas.

Talvez possua 700 GO TO.

Talvez utilize arquivos VSAM que nem aparecem mais na documentação.

Talvez tenha comentários escritos por alguém que já se aposentou há vinte anos.

E talvez ele continue processando milhões de reais por dia.

Parabéns.

Você acabou de encontrar um dos sintomas mais clássicos da dívida técnica.

---

O QUE É DÍVIDA TÉCNICA?

O termo foi criado por Ward Cunningham.

A ideia é simples.

Você faz uma escolha rápida hoje para ganhar velocidade.

Em troca, aceita que precisará corrigir aquilo futuramente.

É exatamente igual a um empréstimo bancário.

Você recebe um benefício imediato.

Mas depois paga juros.

No software, os juros aparecem na forma de:

• retrabalho;

• manutenção mais lenta;

• defeitos;

• incidentes;

• dificuldade de evolução;

• dependência de especialistas.

O problema é que muitas empresas pegam esse empréstimo todos os dias.

E quase nunca pagam.

---

O DIA EM QUE O SISTEMA COMEÇA A COBRAR JUROS

Imagine um programador COBOL júnior.

Recebe uma demanda urgente.

Precisa incluir um novo código de operação.

O correto seria:

• revisar regras;

• criar módulo reutilizável;

• atualizar documentação;

• executar testes.

Mas o prazo está apertado.

Então ele faz:

IF COD-OPER = '99'
   MOVE 'S' TO FLAG-ESPECIAL
END-IF.

Entrega.

Funciona.

Todos ficam felizes.

Seis meses depois surge:

Operação 98.

Depois 97.

Depois 96.

Quando alguém percebe, existe:

IF COD-OPER = '99'
OR COD-OPER = '98'
OR COD-OPER = '97'
OR COD-OPER = '96'

O programa continua funcionando.

Mas ficou pior.

Essa diferença entre funcionar e ser saudável é onde mora a dívida técnica.

---

COMO IDENTIFICAR DÍVIDA TÉCNICA

Os sinais são sempre parecidos.

1. Programas gigantes

Quando um COBOL possui:

• 10 mil linhas;

• 20 mil linhas;

• 50 mil linhas;

ninguém consegue compreender tudo.

Complexidade gera risco.

---

2. Dependência de uma única pessoa

Quando você ouve:

"Somente o João conhece esse sistema."

Acenda o alerta vermelho.

O João pode tirar férias.

O João pode mudar de empresa.

O João pode se aposentar.

O sistema precisa sobreviver sem heróis.

---

3. Medo de alterar

Se toda mudança gera receio:

"Vamos torcer para não derrubar produção."

Existe dívida técnica.

---

4. Muitas correções

Quando a equipe passa mais tempo corrigindo do que evoluindo.

O sistema está pagando juros elevados.

---

AS PRINCIPAIS MÉTRICAS

Métricas transformam sensação em informação.

Sem métricas ninguém sabe se está melhorando.

---

1. LEAD TIME

Tempo entre solicitação e entrega.

Exemplo:

Pedido feito em:

01/06

Produção:

10/06

Lead Time = 9 dias

Quanto menor melhor.

---

2. CYCLE TIME

Tempo efetivamente gasto desenvolvendo.

Exemplo:

Demanda recebida.

Ficou parada cinco dias.

Desenvolvimento levou dois dias.

Cycle Time = 2 dias.

---

3. CHANGE FAILURE RATE

Percentual de mudanças que causam problemas.

Exemplo:

100 implantações.

10 causaram incidentes.

Taxa:

10%

Quanto menor melhor.

---

4. MTTR

Mean Time To Recovery.

Tempo médio para recuperar produção.

Exemplo:

ABEND às 10h.

Sistema normal às 11h.

MTTR = 1 hora.

---

5. REWORK

Retrabalho.

Mede quanto esforço foi gasto corrigindo erros.

Imagine:

100 horas trabalhadas.

25 horas corrigindo problemas.

Rework:

25%

Muito alto.

---

6. REFATORAÇÃO

Esforço dedicado a melhorar código existente.

Uma equipe saudável normalmente reserva tempo para:

• limpeza;

• reorganização;

• modularização.

---

ENTENDENDO O GRÁFICO DA LINEARB

Imagine:

59% Novo Trabalho

17% Refatoração

24% Retrabalho

Significa:

A cada 100 horas:

59 horas criam valor.

17 horas melhoram qualidade.

24 horas apagam incêndios.

Quase um quarto da energia da equipe foi desperdiçada.

---

COMO REDUZIR DÍVIDA TÉCNICA

Agora chegamos ao ponto mais importante.

---

PASSO 1 — MAPEAR O PROBLEMA

Não tente resolver tudo.

Primeiro descubra:

• quais programas mudam mais;

• quais causam mais incidentes;

• quais possuem maior complexidade.

Faça uma planilha simples.

Programa	Alterações	Incidentes
FIN001	120	15
FIN002	10	0
FIN003	95	12

Comece pelos maiores problemas.

---

PASSO 2 — CRIAR BACKLOG TÉCNICO

Muitas empresas possuem backlog funcional.

Poucas possuem backlog técnico.

Crie itens como:

• remover código morto;

• modularizar rotina;

• eliminar duplicação;

• documentar interfaces.

Essas atividades precisam ser visíveis.

---

PASSO 3 — REFATORAR PEQUENO

Erro clássico:

"Vamos reescrever tudo."

Não faça isso.

Melhore gradualmente.

Hoje:

• extrair um parágrafo.

Amanhã:

• eliminar duplicação.

Depois:

• criar módulo reutilizável.

Pequenas vitórias acumulam grandes resultados.

---

PASSO 4 — DOCUMENTAR

Documentação não precisa ser um livro.

Basta responder:

• o que faz;

• entradas;

• saídas;

• dependências.

Já ajuda enormemente.

---

PASSO 5 — REVISÃO DE CÓDIGO

Mesmo no Mainframe.

Principalmente no Mainframe.

Checklist simples:

✓ Nome adequado

✓ Lógica clara

✓ Tratamento de erro

✓ Performance

✓ Documentação

✓ Testes

---

PASSO 6 — TESTES

O segredo dos sistemas modernos.

Sem testes:

refatorar é perigoso.

Com testes:

refatorar é seguro.

Mesmo em COBOL.

Ferramentas como:

• IBM Debug Tool

• IBM Application Discovery

• IBM ZUnit

• Micro Focus Unit Testing

ajudam muito.

---

PASSO 7 — REDUZIR COMPLEXIDADE

Pergunta mágica:

"Existe uma forma mais simples?"

Sempre existe.

Quanto mais simples:

• menor risco;

• menor manutenção;

• menor custo.

---

FERRAMENTAS ÚTEIS

IBM Application Discovery

Mapeia dependências.

Mostra:

• programas;

• copybooks;

• arquivos;

• fluxos.

Excelente para arqueologia de sistemas.

---

SonarQube

Analisa qualidade.

Detecta:

• duplicação;

• complexidade;

• vulnerabilidades.

---

Git

Mesmo para Mainframe.

Ajuda a controlar mudanças.

---

Jira

Controle de backlog técnico.

---

ServiceNow

Correlação entre incidentes e sistemas.

---

O SEGREDO QUE NINGUÉM CONTA

A maioria das dívidas técnicas não nasce do código.

Nasce da organização.

Promessas irreais.

Prazos impossíveis.

Mudanças constantes.

Prioridades conflitantes.

O código apenas reflete o ambiente em que foi criado.

---

EASTER EGG MAINFRAME

Existe um teste simples.

Abra um programa COBOL.

Role até o final.

Se encontrar:

GO TO FIM-PROGRAMA

não se assuste.

Se encontrar:

GO TO INICIO

fique atento.

Se encontrar:

GO TO PARAGRAFO-XYZ

que chama outro GO TO que chama outro GO TO...

Parabéns.

Você encontrou uma relíquia arqueológica do período Jurássico dos sistemas corporativos.

---

O CAMINHO DE EVOLUÇÃO DO PROGRAMADOR JÚNIOR

Nível 1:

Faz funcionar.

Nível 2:

Faz funcionar corretamente.

Nível 3:

Faz funcionar de forma simples.

Nível 4:

Faz funcionar de forma sustentável.

Nível 5:

Melhora o sistema toda vez que toca nele.

É nesse último estágio que nasce o verdadeiro arquiteto de sistemas.

---

A GRANDE LIÇÃO

O programador iniciante acredita que seu trabalho é escrever código.

O programador experiente descobre que seu trabalho é reduzir complexidade.

Código novo gera valor.

Mas código limpo preserva valor.

A dívida técnica não explode como um ABEND.

Ela cresce silenciosamente.

Linha após linha.

Workaround após workaround.

Correção após correção.

Até o dia em que uma mudança de cinco minutos passa a exigir três semanas.

Nesse momento os juros finalmente chegaram.

E como qualquer empréstimo antigo, quanto mais tempo você esperar para pagar, mais caro ficará.

Reconhecimento pelos 5 anos no DIO Global - Digital Innovation One

 

Bellacosa Mainframe DIO Global 5 anos

O DIO Global faz 5 anos esse mês. E quando a gente olhar para essa data de verdade, o que aparece não é um número. São rostos. 

São mais de 50.000 profissionais que foram contratados em empresas de tecnologia através da DIO. Pessoas que estavam em transição de carreira, que buscavam a primeira vaga, que precisavam do inglês certo para competir com qualquer profissional do mundo. Que tinham talento, mas precisavam de um caminho. 

Você ajudou a construir esse caminho. 

O conteúdo que você produziu chegou a profissionais que mudaram de vida por conta do que aprenderam. Isso é raro. A maioria das pessoas passa anos trabalhando sem saber ao certo o impacto do que faz. Você sabe. 

Cinco anos é tempo suficiente para olhar para trás e ter clareza sobre quem construiu isso junto. E o seu nome está nessa lista. 

Em anexo você encontra um reconhecimento de gratidão da DIO pelo que você fez pela educação e pela carreira de tanta gente que confiou nesse projeto.  

 

Nosso agradecimento e reconhecimento por você ter impactado milhares de pessoas por meio da educação e empregabilidade. 

 

Obrigada pela sua contribuição.

DIO
Learning & Curriculum Lead

---------------------------------------------------------------------------------------------------------------------------------

Gratidão

Alcançar cinco anos de participação na DIO (Digital Innovation One) representa muito mais do que uma marca temporal. É o reconhecimento de uma trajetória construída por meio de aprendizado contínuo, troca de experiências e desenvolvimento profissional dentro de uma das maiores comunidades de tecnologia do Brasil.

Ao longo desse período, milhares de profissionais utilizaram a plataforma para expandir conhecimentos em áreas como programação, computação em nuvem, inteligência artificial, ciência de dados, segurança da informação, DevOps, arquitetura de sistemas e diversas outras especialidades do mercado tecnológico. A DIO tornou-se uma ponte entre conhecimento e oportunidades, aproximando estudantes, profissionais e empresas.

Receber um reconhecimento pelos cinco anos de jornada simboliza dedicação, persistência e compromisso com a evolução constante. Em um setor que se transforma diariamente, manter-se atualizado é um diferencial fundamental para enfrentar novos desafios e acompanhar as mudanças do mercado.

Além dos cursos e certificações, a experiência envolve participação em comunidades, eventos, bootcamps e iniciativas colaborativas que fortalecem o networking e o compartilhamento de conhecimento.

Esse marco também representa uma oportunidade para olhar para trás e perceber o quanto foi conquistado ao longo dos anos. Mais do que um certificado ou homenagem, os cinco anos na DIO refletem uma trajetória de crescimento, aprendizado contínuo e paixão pela tecnologia, valores essenciais para quem constrói uma carreira sólida na área de TI.

 

Bellacosa Mainframe e o monstro da divida tecnica 

☕💣 DÍVIDA TÉCNICA: O MONSTRO INVISÍVEL QUE ESTÁ COMENDO O SEU COBOL DESDE O SÉCULO PASSADO

"O sistema funciona perfeitamente. Só ninguém sabe como."

Se você trabalha com Mainframe há algum tempo, provavelmente já ouviu frases como:

• "Não mexe nisso que funciona."

• "Esse programa está em produção há 20 anos."

• "Só o João sabe alterar esse módulo."

• "Depois a gente documenta."

• "Precisamos entregar hoje."

Parabéns.

Você acabou de encontrar alguns dos maiores sintomas de uma das doenças mais comuns da tecnologia moderna:

A Dívida Técnica.

E não, ela não acontece apenas em Java, Python ou aplicações web modernas.

Na verdade, muitos dos maiores casos de dívida técnica do planeta estão rodando neste exato momento em sistemas COBOL responsáveis por bancos, seguradoras, governos, companhias aéreas e bolsas de valores.

Vamos entender o que é, como identificar, controlar e principalmente como sobreviver a ela.

---

O QUE É DÍVIDA TÉCNICA?

A definição mais simples é:

Dívida Técnica é o custo futuro gerado quando escolhemos uma solução rápida hoje em vez da melhor solução possível.

Imagine que você recebeu uma demanda urgente.

O gerente aparece correndo:

"Precisamos colocar essa alteração em produção amanhã."

Você sabe que o correto seria:

• revisar a arquitetura;

• atualizar documentação;

• criar casos de teste;

• revisar impactos;

• atualizar fluxogramas.

Mas o prazo não permite.

Então você faz um ajuste rápido.

Entrega.

Todo mundo feliz.

Até que seis meses depois alguém precisa alterar novamente aquele trecho.

Agora ninguém entende mais nada.

A dívida venceu.

E os juros começaram a ser cobrados.

---

A ANALOGIA COM O CARTÃO DE CRÉDITO

A comparação mais famosa é com uma dívida financeira.

Quando você compra algo parcelado:

Você ganha agora.

Mas paga depois.

Na dívida técnica acontece exatamente o mesmo.

Você ganha:

• velocidade;

• prazo;

• entrega rápida.

Mas paga depois com:

• bugs;

• retrabalho;

• manutenção cara;

• incidentes de produção.

Quanto mais tempo passa, maiores ficam os juros.

---

O COBOL NÃO CRIA DÍVIDA TÉCNICA

Essa é uma das maiores injustiças da informática.

Muitos dizem:

"Cobol é dívida técnica."

Errado.

COBOL não é dívida técnica.

COBOL mal mantido é dívida técnica.

Existem programas COBOL escritos há 30 anos que continuam:

• legíveis;

• documentados;

• organizados;

• eficientes.

E existem aplicações modernas escritas há seis meses que já parecem um filme de terror.

A linguagem não é o problema.

A disciplina é.

---

COMO A DÍVIDA TÉCNICA NASCE

Ela normalmente surge de quatro formas.

1. Pressão por prazo

O caso mais comum.

"Entrega primeiro."

"Arruma depois."

O problema é que o depois quase nunca chega.

---

2. Falta de documentação

O desenvolvedor conhece tudo.

Então ele pensa:

"Não preciso documentar."

Dois anos depois ele muda de empresa.

Agora ninguém entende o programa.

---

3. Correções emergenciais

Produção caiu.

Cliente está ligando.

Diretoria está nervosa.

O objetivo vira apenas:

"Faça voltar."

Nesse momento quase ninguém pensa em qualidade.

---

4. Sistemas legados

Bibliotecas antigas.

COPYBOOKs herdados.

Macros esquecidas.

JCLs copiados durante décadas.

Tudo isso acumula dívida.

---

EXEMPLO REAL DE DÍVIDA TÉCNICA EM COBOL

Imagine um cálculo de desconto.

Versão original:

IF CLIENTE-VIP
   COMPUTE DESCONTO = VALOR * 0.15
END-IF

Simples.

Legível.

Agora passam dez anos.

Novas regras surgem.

Resultado:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...

Mais tarde:

IF CLIENTE-TIPO = 'A'
...
ELSE
IF CLIENTE-TIPO = 'B'
...
ELSE
IF CLIENTE-TIPO = 'C'
...
ELSE
IF REGIAO = 'S'
...

Depois de centenas de mudanças:

Ninguém sabe mais como o cálculo funciona.

O programa funciona.

Mas ninguém entende.

Isso é dívida técnica.

---

OS SINTOMAS MAIS PERIGOSOS

Se você encontrar estes sinais, ligue o alerta.

Programas gigantes

Mais de 10.000 linhas.

COPYBOOKs duplicados

A mesma estrutura em vários lugares.

JCLs clonados

Mudam apenas o nome do JOB.

Falta de comentários

Tudo depende da memória dos analistas.

Testes manuais

Ninguém consegue validar rapidamente.

Dependência de uma pessoa

"O Carlos sabe."

Quando você ouve isso, existe dívida técnica.

---

O EFEITO JUROS COMPOSTOS

Aqui está a parte assustadora.

Dívida técnica cresce de forma parecida com juros compostos.

Um bug gera:

• remendo;

• novo remendo;

• ajuste do remendo;

• correção da correção.

Depois de alguns anos ninguém consegue alterar sem medo.

O custo explode.

---

COMO MAPEAR DÍVIDA TÉCNICA

Primeiro passo:

Pare de adivinhar.

Crie um inventário.

Faça uma planilha simples.

Colunas:

• Sistema

• Programa

• Problema

• Impacto

• Complexidade

• Prioridade

Exemplo:

Programa	Problema	Impacto
COBCLI01	Sem documentação	Alto
COBFAT02	12.000 linhas	Alto
COBPAG03	Sem testes	Médio

Agora a dívida virou algo visível.

---

MÉTRICAS IMPORTANTES

Um programador júnior deve aprender a medir.

Algumas métricas úteis:

Número de ABENDs

Se cresce continuamente:

há algo errado.

---

Tempo de correção

Quanto tempo leva para corrigir um incidente?

Quanto maior, maior a dívida.

---

Quantidade de módulos sem documentação

Métrica simples e poderosa.

---

Cobertura de testes

Quanto mais baixa, maior o risco.

---

FERRAMENTAS ÚTEIS NO MAINFRAME

Muitos iniciantes acham que Mainframe não possui ferramentas modernas.

Possui.

E muitas.

IBM Application Discovery

Mapeia dependências.

Excelente para sistemas gigantes.

---

IBM ADDI

Application Discovery and Delivery Intelligence.

Mostra relacionamentos entre:

• COBOL

• JCL

• DB2

• CICS

---

IBM Debug Tool

Ajuda a entender comportamento de programas complexos.

---

IBM Fault Analyzer

Investiga ABENDs.

---

IBM File Manager

Analisa arquivos rapidamente.

---

IBM Dependency Based Build

Automação moderna para pipelines Mainframe.

---

COMO REDUZIR A DÍVIDA

Agora vem a parte prática.

---

Passo 1 – Pare de criar dívida nova

Antes de pagar a antiga.

Evite criar mais.

Parece óbvio.

Mas é onde tudo começa.

---

Passo 2 – Refatore pequenos trechos

Não tente reescrever tudo.

Ataque pequenas áreas.

Exemplo:

• nomes ruins;

• IFs excessivos;

• parágrafos gigantes.

---

Passo 3 – Documente enquanto aprende

Cada descoberta vira documentação.

Não espere um projeto oficial.

---

Passo 4 – Automatize testes

Mesmo testes simples ajudam.

Menos medo de alterar.

Mais velocidade.

---

Passo 5 – Padronize

Defina padrões.

Por exemplo:

• nomenclatura;

• comentários;

• estrutura de programas;

• organização de COPYBOOKs.

---

O ERRO MAIS COMUM DOS JUNIORES

Achar que refatorar significa reescrever tudo.

Não.

Refatoração significa melhorar sem alterar comportamento.

Você limpa.

Organiza.

Simplifica.

Sem mudar resultado.

---

O SEGREDO DOS ANALISTAS SENIORES

Muitos iniciantes acreditam que profissionais experientes sabem tudo.

Não sabem.

A diferença é que eles:

• documentam mais;

• investigam melhor;

• evitam atalhos perigosos;

• controlam a dívida técnica.

O conhecimento não está apenas no código.

Está na disciplina.

---

EASTER EGG DOS MAINFRAMEIROS

Se encontrar um comentário parecido com:

* NÃO REMOVER
* FUNCIONA ASSIM DESDE 1994

Você provavelmente encontrou um artefato arqueológico corporativo.

Trate com respeito.

Mas investigue.

Porque muitas vezes ele esconde uma dívida técnica histórica.

---

A REGRA DOS 5 MINUTOS

Uma dica poderosa.

Se você gastou cinco minutos para entender algo complicado:

documente.

O próximo desenvolvedor agradecerá.

E talvez esse próximo desenvolvedor seja você daqui a seis meses.

---

COMO EVOLUIR NA CARREIRA ATRAVÉS DA DÍVIDA TÉCNICA

Os melhores profissionais não são os que criam mais código.

São os que reduzem complexidade.

Quando você aprende a:

• mapear problemas;

• documentar;

• simplificar;

• automatizar;

• refatorar;

você deixa de ser apenas um programador.

Você passa a ser um engenheiro de software.

---

CONCLUSÃO

Dívida técnica não é um bug.

Não é um ABEND.

Não é um programa COBOL antigo.

Ela é o resultado de decisões acumuladas ao longo do tempo.

Algumas são necessárias.

Outras são perigosas.

O segredo não é eliminar toda dívida técnica.

Isso é impossível.

O segredo é conhecê-la, monitorá-la e pagá-la antes que ela assuma o controle do sistema.

Porque, no final das contas, o verdadeiro problema não é aquele programa COBOL de 1987.

O problema é ninguém mais entender por que ele ainda funciona.

E quando esse dia chega...

o próximo chamado de produção costuma acontecer às 03:17 da manhã de um domingo.

Aproveite e conheça BACKLOG

https://eljefemidnightlunch.blogspot.com/2025/01/backlog-o-arquivo-secreto-que-separa-um.html

Backlog

☕ MAINFRAME INSIGHTS

📋💣 BACKLOG: O Arquivo Secreto Que Separa um Programador COBOL Comum de um Verdadeiro Arquiteto de Sistemas

Descubra por que o backlog é muito mais do que uma lista de tarefas e como ele se tornou a arma estratégica dos profissionais que dominam sistemas críticos.

Ler Artigo Completo →

 

Bellacosa Mainframe a arte da guerra contra o caos conheça o RCA

☕🔥💣 O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS

Root Cause Analysis no IBM Mainframe: Por Que Reiniciar o CICS Não Resolve Seus Problemas

Existe uma frase muito comum nos corredores dos data centers:

"Reinicia que volta."

Durante décadas ela funcionou.

O CICS travou?

Reinicia.

O batch falhou?

Roda de novo.

O MQ congestionou?

Dá STOP e START.

O JES2 ficou estranho?

Cancela alguns jobs.

O storage explodiu?

Aumenta a região.

O problema é que essa mentalidade criou gerações de profissionais especialistas em apagar incêndios, mas não necessariamente especialistas em eliminar incêndios.

E existe uma diferença gigantesca entre as duas coisas.

O verdadeiro profissional de Mainframe moderno não é aquele que resolve o incidente mais rápido.

É aquele que garante que o incidente nunca mais aconteça.

É aí que entra uma das disciplinas mais importantes da engenharia moderna:

Root Cause Analysis (RCA)

Ou, em português:

Análise de Causa Raiz

Uma habilidade que separa o operador comum do engenheiro de confiabilidade.

---

O INCIDENTE NÃO É O PROBLEMA

Este é talvez o conceito mais importante de todo o artigo.

Quando um sistema cai, aquilo que você vê não é o problema.

É apenas a consequência visível.

Imagine uma transação CICS que começa a responder lentamente.

O usuário reclama.

O suporte abre um chamado.

O operador percebe aumento de CPU.

O time de infraestrutura aumenta recursos.

Tudo parece resolvido.

Mas alguns dias depois o problema volta.

Por quê?

Porque ninguém investigou a causa raiz.

A lentidão era apenas um sintoma.

O problema verdadeiro talvez fosse:

• SQL ineficiente

• Índice DB2 corrompido

• Loop em programa COBOL

• Fila MQ congestionada

• Deadlock de recursos

• Automação mal configurada

Resolver o sintoma gera alívio.

Resolver a causa gera evolução.

---

O MAIOR PECADO DA TI MODERNA

A Harvard Business Review publicou um estudo mostrando que a maioria dos executivos acredita que suas organizações são ruins em diagnosticar problemas.

Isso não surpreende.

A cultura corporativa moderna recompensa velocidade.

Poucas vezes recompensa investigação.

A pressão é sempre:

"Volta o sistema agora."

Raramente alguém pergunta:

"Por que ele caiu?"

E menos ainda:

"Como impedimos que isso aconteça novamente?"

---

O DETETIVE DIGITAL

Um bom profissional de RCA pensa como um investigador.

Quando ocorre uma falha ele não procura imediatamente uma solução.

Primeiro procura evidências.

Ele coleta:

• SYSLOG

• JESMSGLG

• SMF

• RMF

• Dumps

• Traces

• Mensagens CICS

• Logs DB2

• Eventos MQ

• Métricas OMEGAMON

Cada informação conta parte da história.

Nenhum log isolado revela a verdade completa.

O segredo está na correlação.

---

O CASO DO BATCH QUE ATRASAVA TODA SEXTA-FEIRA

Vamos analisar um exemplo realista.

Toda sexta-feira o processamento noturno atrasava duas horas.

A primeira reação foi aumentar os initiators JES2.

Funcionou por algumas semanas.

Depois o atraso voltou.

Nova tentativa:

Mais CPU.

Mais memória.

Mais canais.

Nada resolveu.

Quando uma análise de causa raiz foi finalmente realizada, descobriu-se que um programa COBOL executava uma consulta DB2 sem índice adequado.

Toda sexta-feira havia crescimento no volume de dados.

A consulta que normalmente levava segundos passava a consumir minutos.

Um único SQL provocava efeito cascata em dezenas de jobs dependentes.

A verdadeira solução não foi comprar hardware.

Foi corrigir um SQL.

---

O MÉTODO DOS CINCO PORQUÊS

Uma técnica clássica de RCA é conhecida como:

Five Whys

Cinco Porquês.

Exemplo:

Problema:

Batch falhou.

Por quê?

Dataset estava bloqueado.

Por quê?

Outro job mantinha ENQ.

Por quê?

Entrou em loop.

Por quê?

SQL aguardava retries.

Por quê?

Índice DB2 estava inconsistente.

Agora temos a causa raiz.

Observe que a resposta verdadeira apareceu apenas após várias camadas de investigação.

---

O INIMIGO INVISÍVEL CHAMADO CULTURA

Muitas vezes a causa raiz não está no software.

Nem no hardware.

Nem na rede.

Está nas pessoas.

Considere o seguinte cenário.

Um deploy derruba produção.

A primeira conclusão costuma ser:

"O desenvolvedor errou."

Mas uma análise profunda pode revelar:

• Prazo impossível

• Falta de testes

• Ausência de homologação

• Pressão da gestão

• Processo de aprovação falho

O erro humano foi apenas o último elo da corrente.

A verdadeira falha estava no sistema organizacional.

---

O MODELO DE CONGRUÊNCIA

Uma abordagem extremamente interessante utilizada em liderança organizacional é o Modelo de Congruência.

Ele analisa cinco dimensões:

Trabalho

O que precisa ser feito?

Dependências

Quem depende de quem?

Capacidades

As pessoas possuem conhecimento suficiente?

Estrutura

A organização facilita ou dificulta o trabalho?

Cultura

Os comportamentos desejados são incentivados?

No Mainframe isso é extremamente aplicável.

Não adianta investir milhões em Z17 se:

• a equipe não recebe treinamento

• a documentação está desatualizada

• os processos são confusos

• ninguém entende as integrações

---

O MAINFRAME MODERNO É UM ECOSSISTEMA

Nos anos 80 era relativamente fácil identificar falhas.

Hoje um único fluxo pode envolver:

• COBOL

• CICS

• DB2

• MQ

• APIs REST

• Kafka

• Cloud

• Linux on Z

• Zowe

• DevOps

A causa raiz pode estar em qualquer lugar.

Ou em vários lugares simultaneamente.

Por isso a investigação precisa ser sistêmica.

---

A ARMADILHA DO "SEMPRE FOI ASSIM"

Uma das causas mais perigosas de incidentes recorrentes é a complacência.

Frases famosas:

"Isso acontece às vezes."

"Sempre fizemos assim."

"Nunca deu problema."

São frases que deveriam acender alertas imediatos.

Porque normalmente escondem riscos acumulados durante anos.

---

COMO REALIZAR UM RCA NO MAINFRAME

Passo 1 — Definir o Problema

Não investigue algo genérico.

Errado:

"O sistema está ruim."

Correto:

"O CICS CICSPRD apresentou aumento de resposta de 0,3 para 8 segundos entre 14h e 15h."

Problemas bem definidos geram investigações eficientes.

---

Passo 2 — Coletar Evidências

Reúna:

• logs

• métricas

• dumps

• relatórios

• eventos

Sem dados você possui apenas opiniões.

---

Passo 3 — Construir a Linha do Tempo

Pergunte:

O que aconteceu primeiro?

O que aconteceu depois?

Qual evento precedeu a falha?

Muitas causas aparecem quando organizamos os fatos cronologicamente.

---

Passo 4 — Correlacionar Eventos

Um erro aparentemente isolado pode estar conectado a dezenas de outros eventos.

O desafio é encontrar essas relações.

---

Passo 5 — Aplicar os Cinco Porquês

Continue perguntando:

Por quê?

Até chegar à origem.

---

Passo 6 — Validar a Hipótese

A hipótese precisa ser comprovada.

Não basta parecer correta.

Ela deve explicar:

• o incidente

• os sintomas

• a recorrência

---

Passo 7 — Criar Plano de Ação

A correção deve:

• eliminar a causa

• reduzir riscos

• ser mensurável

---

FERRAMENTAS ESSENCIAIS PARA RCA NO Z/OS

RMF

Identifica gargalos de performance.

SMF

Registra praticamente tudo que acontece.

IPCS

Análise de dumps.

OMEGAMON

Observabilidade avançada.

SDSF

Investigação operacional.

NetView

Correlação de eventos.

System Automation

Automação e recuperação.

JES2

Análise de filas, execução e spool.

---

O FUTURO: AIOPS E RCA AUTOMATIZADO

Estamos entrando em uma era fascinante.

Ferramentas modernas conseguem:

• detectar anomalias

• prever falhas

• correlacionar eventos

• sugerir causas prováveis

AIOps não substitui o analista.

Mas amplifica sua capacidade.

O profissional moderno utilizará IA para acelerar investigações complexas.

---

ONDE A MAIORIA DAS EMPRESAS ERRA

As falhas mais comuns são:

Falta de documentação

Sem histórico não existe aprendizado.

Ausência de postmortem

O incidente é resolvido e esquecido.

Busca por culpados

Pessoas escondem erros quando temem punição.

Falta de métricas

Sem observabilidade não existe RCA.

Correções paliativas

Workarounds substituem soluções definitivas.

---

COMO EVOLUIR SUA ORGANIZAÇÃO

Empresas maduras desenvolvem cultura de aprendizado.

Após cada incidente perguntam:

• O que aconteceu?

• Por que aconteceu?

• Como detectamos?

• Como evitaremos recorrência?

• O que aprendemos?

Essa simples mudança transforma organizações.

---

O SYSprog PADAWAN E O MESTRE

O Padawan reinicia.

O Mestre investiga.

O Padawan fecha chamados.

O Mestre elimina problemas.

O Padawan trata sintomas.

O Mestre trata causas.

O Padawan celebra quando o sistema volta.

O Mestre celebra quando o sistema não cai novamente.

Essa é a verdadeira evolução profissional.

---

CONCLUSÃO

Root Cause Analysis não é apenas uma metodologia.

É uma filosofia.

É a diferença entre sobreviver e evoluir.

No mundo do IBM Z17, DevOps, observabilidade, automação e inteligência artificial, a capacidade de descobrir a causa raiz tornou-se uma das habilidades mais valiosas da engenharia moderna.

Porque reiniciar um sistema pode resolver um incidente.

Mas apenas entender a causa raiz pode impedir que ele volte.

E é exatamente isso que separa um operador de console de um arquiteto da estabilidade.

No final das contas, o verdadeiro inimigo nunca foi o abend.

Nunca foi o dump.

Nunca foi o job cancelado.

O verdadeiro inimigo sempre foi aquilo que ninguém investigou.