Translate

domingo, 7 de junho de 2026

IMS DB: A Vida de um SysAdmin no Mundo do Gigante Invisível do Mainframe

 

Bellacosa Mainframe e o IMS DB sob a visão de um SysAdmin

☕💣🚨 OPERADOR, O ALERTA ACABOU DE DISPARAR... E O IMS ESTÁ NO MEIO DA HISTÓRIA!

A Vida de um Sysadmin no Mundo do Gigante Invisível do Mainframe

São 02h17 da manhã.

O telefone toca.

Nenhuma notícia boa chega nesse horário.

O Sysadmin abre os olhos, pega o celular e encontra uma mensagem curta, objetiva e preocupante:

"Aplicação crítica com lentidão. Filas crescendo. Possível incidente IMS."

Pronto.

O sono acabou.

O café ainda nem começou.

Mas a investigação já está em andamento.

Enquanto milhões de pessoas dormem tranquilamente, existe um exército invisível de profissionais garantindo que bancos, seguradoras, operadoras de cartão, sistemas de saúde e órgãos governamentais continuem funcionando.

Entre eles está o Sysadmin.

E muitas vezes, sem perceber, ele acaba entrando no fascinante universo do IMS.


O Grande Equívoco

Existe uma ideia muito comum entre profissionais iniciantes.

Quando escutam a palavra IMS, imaginam imediatamente:

"Ah, isso é coisa de DBA."

Ou:

"Isso é assunto para programador COBOL."

Ou ainda:

"Isso é responsabilidade do time de aplicações."

E então surge a primeira surpresa.

O Sysadmin interage com o IMS muito mais do que imagina.

Talvez não criando DBDs.

Talvez não escrevendo chamadas DL/I.

Mas certamente monitorando, operando, automatizando, diagnosticando e sustentando o ambiente.


O Que o Usuário Não Vê

Quando alguém faz um PIX pelo celular, a experiência parece simples.

Alguns toques na tela.

Uma confirmação.

Dinheiro transferido.

Fim da história.

Mas por trás daquele gesto existe uma cadeia impressionante:

Aplicativo.

API.

Middleware.

IMS Connect.

IMS TM.

COBOL.

IMS DB.

Mainframe.

Storage.

Rede.

Segurança.

E se qualquer elo dessa corrente apresentar problemas, o primeiro profissional acionado muitas vezes será justamente o Sysadmin.


O Centro de Comando

Imagine uma sala de operações.

Monitores por todos os lados.

Dashboards.

Alertas.

Métricas.

Logs.

Gráficos.

O Sysadmin observa constantemente:

  • Utilização de CPU

  • Consumo de memória

  • Filas

  • Jobs

  • Transações

  • Regiões ativas

  • Recursos críticos

Durante anos ele aprendeu a monitorar:

  • JES2

  • CICS

  • DB2

  • TCP/IP

Mas então surge o IMS.

E ele descobre um novo universo.


O Primeiro Contato

Quase sempre o primeiro contato acontece através de um alerta.

Talvez:

"Fila crescendo."

Ou:

"Tempo de resposta degradado."

Ou:

"Transações aguardando processamento."

Nesse momento o Sysadmin percebe que existe algo além da aplicação.

Existe um componente que recebe mensagens.

Distribui trabalho.

Controla filas.

Executa programas.

Gerencia transações.

Esse componente é o IMS TM.


O Maestro Invisível

Muitos profissionais enxergam o IMS apenas como banco de dados.

Mas o Sysadmin rapidamente descobre que existe um segundo protagonista.

O Transaction Manager.

O famoso IMS TM.

Ele funciona como um maestro.

Recebe solicitações.

Coordena programas.

Controla mensagens.

Distribui carga.

Organiza o fluxo de processamento.

Quando algo desacelera, frequentemente é ali que começam as investigações.


O Terror das Filas Crescentes

Existe uma imagem capaz de acelerar os batimentos cardíacos de qualquer Sysadmin.

Filas crescendo continuamente.

A tela mostra números aumentando.

Mais mensagens.

Mais solicitações.

Mais trabalho aguardando execução.

O usuário ainda não percebe.

A aplicação ainda responde.

Mas o profissional de operação sabe:

algo está errado.

A missão começa.


Seguindo os Rastros

A investigação costuma seguir um caminho lógico.

Primeira pergunta:

O Mainframe está saudável?

CPU?

Memória?

Storage?

Coupling Facility?

Tudo normal.

Segunda pergunta:

A rede está funcionando?

TCP/IP?

Conectividade?

TLS?

Tudo normal.

Terceira pergunta:

As regiões IMS estão processando normalmente?

E é nesse momento que o Sysadmin mergulha mais fundo no ecossistema IMS.


As Regiões Misteriosas

O Sysadmin encontra nomes que antes pareciam enigmáticos.

MPP.

BMP.

IFP.

JMP.

Control Region.

Inicialmente parecem apenas siglas.

Depois tornam-se peças fundamentais do quebra-cabeça.

Cada uma possui uma função.

Cada uma possui métricas.

Cada uma pode se transformar na origem de um incidente.

Com o tempo ele aprende a reconhecê-las quase como velhos conhecidos.


O Poder do Monitoramento

Ferramentas modernas oferecem uma visão detalhada do ambiente.

OMEGAMON.

NetView.

Automation.

Painéis customizados.

Alertas inteligentes.

O Sysadmin acompanha:

  • Taxa de transações

  • Utilização das regiões

  • Filas OTMA

  • Consumo de recursos

  • Disponibilidade dos componentes

Ele não precisa conhecer cada detalhe interno do banco.

Mas precisa identificar quando algo foge do comportamento esperado.


O Dia em Que o Recovery Chega

Todo ambiente crítico possui um momento inevitável.

A falha.

Talvez seja um erro humano.

Talvez seja uma pane de hardware.

Talvez seja uma corrupção lógica.

Quando isso acontece, uma palavra domina a reunião:

Recovery.

É nesse instante que entram em cena:

  • Logs

  • Checkpoints

  • Image Copies

  • DBRC

O Sysadmin participa garantindo que os procedimentos ocorram corretamente.

A pressão é enorme.

Porque ninguém pergunta quanto trabalho foi necessário para recuperar o sistema.

Todos querem apenas uma resposta:

"Já voltou?"


A Arte da Automação

Os melhores Sysadmins possuem uma característica em comum.

Eles odeiam repetir trabalho manual.

Por isso automatizam tudo o que podem.

No universo IMS isso significa:

  • Monitoramento automático

  • Reinício controlado

  • Abertura de chamados

  • Geração de alertas

  • Coleta de evidências

  • Verificação de disponibilidade

Muitas vezes um incidente é detectado por scripts antes mesmo que um usuário perceba o problema.


O Encontro com o IMS Connect

O mundo mudou.

As aplicações modernas não acessam diretamente um terminal verde.

Elas utilizam:

  • APIs REST

  • Aplicativos móveis

  • Portais web

  • Serviços distribuídos

A ponte entre esses mundos frequentemente é o IMS Connect.

E isso coloca o Sysadmin novamente no centro da ação.

Porque agora entram em cena:

  • Portas TCP/IP

  • Certificados digitais

  • TLS

  • RACF

  • Balanceamento

  • Firewall

Nem sempre o problema está no IMS.

Mas quase sempre o Sysadmin precisa provar isso.


O Fantasma das Madrugadas

Existe uma cena clássica.

Tudo funciona perfeitamente durante o dia.

Usuários felizes.

Aplicações rápidas.

Monitoramento tranquilo.

Então chega a madrugada.

Processamentos.

Integrações.

Batchs.

Janelas de manutenção.

E algo inesperado acontece.

O Sysadmin aprende rapidamente que a estabilidade de um ambiente não se mede pelos melhores momentos.

Mas pela forma como ele reage aos piores.


O Gigante Que Nunca Parou

Uma das maiores surpresas para quem conhece o IMS é descobrir sua idade.

O produto nasceu em 1966.

Sim.

Antes da chegada do homem à Lua.

Antes da internet.

Antes do computador pessoal.

Antes do smartphone.

Mesmo assim continua presente em ambientes modernos.

Mais impressionante ainda:

continua evoluindo.

Novas versões.

Novas integrações.

Novas capacidades.

Novas ferramentas.

Poucas tecnologias podem contar uma história semelhante.


Por Que o Sysadmin Deve Aprender IMS?

Porque ele está presente.

Porque ele continua crítico.

Porque ele aparece nos incidentes mais importantes.

Porque ele faz parte da infraestrutura.

Porque entender o fluxo das transações reduz drasticamente o tempo de diagnóstico.

E principalmente porque conhecer IMS transforma um operador de ferramentas em um profissional capaz de compreender o negócio por trás da tecnologia.


O Dia em Que Tudo Faz Sentido

Depois de algum tempo convivendo com o ambiente, algo interessante acontece.

O Sysadmin deixa de enxergar apenas componentes isolados.

Ele passa a enxergar o sistema como um organismo vivo.

As filas.

As transações.

As mensagens.

As aplicações.

As integrações.

Tudo conectado.

Tudo dependente.

Tudo trabalhando em conjunto.

E no centro dessa engrenagem gigantesca continua existindo o mesmo software criado para ajudar a NASA a organizar milhões de componentes do Saturn V.


Conclusão

☕💣🚨

Operador...

Enquanto o mundo discute inteligência artificial, computação quântica e novas linguagens de programação, existe um gigante silencioso que continua trabalhando sem descanso.

Ele processa transações.

Controla filas.

Move dinheiro.

Transporta informações.

Conecta gerações de tecnologia.

E frequentemente aparece nos momentos mais críticos da operação.

Quando o alerta toca às duas da manhã, o Sysadmin descobre que o IMS não é apenas um produto.

É uma parte fundamental da infraestrutura que sustenta o mundo digital moderno.

E quanto mais cedo ele compreender esse gigante invisível, mais preparado estará para enfrentar os desafios que realmente importam dentro de um ambiente Mainframe.


sábado, 6 de junho de 2026

IMS DB: A História do Gigante Invisível Que Continua Movendo o Mundo sob a otica de um SysProg

 

Bellacosa Mainframe e o IMS DB na visão de um SysProg

☕💣🚀 OPERADOR, O SYSProg ACABOU DE ESBARRAR NO IMS!

A História do Gigante Invisível Que Continua Movendo o Mundo

Existe uma cena que se repete silenciosamente em datacenters espalhados pelo planeta.

São duas horas da manhã.

O celular do operador toca.

Um alerta vermelho aparece na tela.

Uma aplicação crítica parou de responder.

O aplicativo do banco está lento.

As transações estão acumulando.

O monitoramento mostra filas crescendo.

O incidente é aberto.

Em poucos minutos surgem os personagens clássicos do mundo Mainframe:

  • Operação

  • Sysadmin

  • DBA

  • Desenvolvedor COBOL

  • Especialista de rede

  • Sysprog

E então alguém faz a pergunta que muda completamente a investigação:

— Essa aplicação usa IMS?

Silêncio.

Porque nesse momento todos sabem que entraram em um território especial.

Um território que nasceu antes da chegada do homem à Lua.

Um território que continua processando bilhões de transações diariamente.

Um território chamado IMS.


O Dia em Que o Sysprog Descobre Que Existe Vida Além do JES2

Todo Sysprog conhece bem alguns velhos amigos:

  • z/OS

  • JES2

  • RACF

  • VTAM

  • TCP/IP

  • USS

  • WLM

  • SDSF

São componentes presentes no cotidiano.

Mas cedo ou tarde surge aquele ambiente misterioso.

Uma região diferente.

Um started task estranho.

Um conjunto de logs desconhecidos.

Uma arquitetura enorme.

E então aparece um nome:

IMS.

Muitos profissionais passam anos trabalhando em Mainframe sem perceber o tamanho da presença do IMS dentro das grandes corporações.

Até o dia em que precisam investigar um problema.

E aí tudo muda.


O Gigante Invisível

O curioso sobre o IMS é que ele raramente aparece.

Ninguém abre o aplicativo do banco pensando:

"Vou consultar um banco de dados hierárquico criado em 1966."

Ninguém compra uma passagem aérea pensando:

"Espero que o IMS esteja funcionando."

Ninguém faz um PIX imaginando:

"Obrigado, IMS."

Mas milhões de transações passam por ele diariamente.

O IMS é invisível para o usuário final.

Mas completamente visível para quem trabalha na infraestrutura.

Especialmente para o Sysprog.


O Chamado das Três da Manhã

Imagine a situação.

O monitoramento começa a registrar degradação.

O painel do OMEGAMON mostra filas crescendo.

As mensagens OTMA começam a acumular.

O tempo de resposta aumenta.

A aplicação continua ativa.

O z/OS continua saudável.

O processador está tranquilo.

Mas alguma coisa está errada.

O Sysprog inicia a investigação.

Primeiro verifica:

  • CPU

  • Storage

  • Paging

  • Coupling Facility

  • WLM

Tudo parece normal.

Então ele olha para o ambiente IMS.

E percebe algo interessante.

As regiões MPP estão saturadas.


O Primeiro Contato Com o Mundo IMS

Nesse momento muitos profissionais descobrem que o IMS não é apenas um banco de dados.

Na verdade existem dois mundos.

O primeiro:

IMS DB.

Responsável pelos dados.

O segundo:

IMS TM.

Responsável pelas transações.

É nesse segundo mundo que o Sysprog costuma interagir com maior frequência.

Porque ali vivem:

  • Filas

  • Mensagens

  • Regiões

  • Processamento

  • Balanceamento

  • Integração

É praticamente um sistema operacional dentro do sistema operacional.


O Que o Sysprog Enxerga

O desenvolvedor COBOL enxerga:

Dados.

O DBA enxerga:

Segmentos.

O usuário enxerga:

Aplicações.

O Sysprog enxerga:

Infraestrutura.

Ele observa:

  • MPPs

  • BMPs

  • IFPs

  • JMPs

  • Control Region

  • IMS Connect

  • CQS

  • SCI

  • OM

  • RM

E começa a entender que o IMS é muito mais parecido com um ecossistema do que com um simples banco de dados.


O Momento da Descoberta

Todo Sysprog passa por um momento de revelação.

É quando percebe que o fluxo moderno pode ser algo assim:

Smartphone.

API REST.

z/OS Connect.

IMS Connect.

IMS TM.

Programa COBOL.

IMS DB.

Tudo funcionando em poucos milissegundos.

O usuário acredita que está conversando com uma arquitetura moderna baseada em cloud.

Na realidade existe um software cuja origem remonta ao Projeto Apollo.

E isso é fascinante.


O Mistério do IMS Connect

Uma das áreas onde o Sysprog mais interage atualmente é o IMS Connect.

Porque ele é a ponte entre dois mundos.

De um lado:

  • Mobile

  • APIs

  • Cloud

  • Microserviços

Do outro:

  • IMS

  • COBOL

  • DL/I

  • Bancos hierárquicos

Quando surge um problema de conectividade, o Sysprog frequentemente é chamado.

Ele analisa:

  • TCP/IP

  • Portas

  • TLS

  • Certificados

  • RACF

  • AT-TLS

E muitas vezes descobre que o problema não está no IMS.

Está na infraestrutura.


Quando o Problema É Performance

Performance é outro território clássico.

Imagine uma instituição financeira.

Milhões de transações.

Centenas de regiões.

Milhares de usuários simultâneos.

Tudo funcionando perfeitamente.

Até que algo muda.

Talvez:

  • Um novo aplicativo

  • Uma campanha comercial

  • Um aumento inesperado de carga

De repente o ambiente começa a sofrer.

O Sysprog entra em ação.

Analisa:

  • Buffers

  • Storage

  • CPU

  • I/O

  • Coupling Facility

  • Shared Queues

E percebe que o IMS continua fazendo exatamente aquilo para o qual foi criado:

processar volumes absurdos de dados.


O Dia em Que o Sysprog Conhece o IMSplex

Se existe um conceito capaz de impressionar um Sysprog, esse conceito é o IMSplex.

Imagine vários IMS funcionando como uma única entidade lógica.

Algo semelhante ao Parallel Sysplex.

Mas voltado para o universo IMS.

O Sysprog passa então a lidar com:

  • SCI

  • OM

  • RM

  • CQS

E descobre que a arquitetura é muito mais sofisticada do que imaginava.


Recovery: O Momento da Verdade

Existe uma situação que separa curiosos de especialistas.

Recovery.

Quando tudo funciona, qualquer ambiente parece simples.

Mas quando ocorre uma falha séria...

A verdadeira engenharia aparece.

É nesse momento que surgem:

  • DBRC

  • Logs

  • Image Copies

  • Checkpoints

O Sysprog participa do processo.

Nem sempre executando o recovery diretamente.

Mas garantindo que toda a infraestrutura necessária esteja disponível.


A Grande Lição do IMS

Talvez a maior lição que o IMS ensine seja esta:

Desempenho não nasce da moda.

Nasce da arquitetura.

O IMS foi criado em uma época em que recursos eram escassos.

CPU era cara.

Memória era rara.

Disco era limitado.

Cada acesso precisava ser cuidadosamente planejado.

Por isso o produto foi construído com obsessão por eficiência.

Décadas depois, essa obsessão continua produzindo resultados.


O Futuro do IMS

Muita gente imagina que o IMS seja um fóssil.

Mas basta observar as versões mais recentes.

IMS Connect.

APIs REST.

Integração com Java.

Catálogo IMS.

Managed ACBs.

Observabilidade.

Uso ampliado de memória de 64 bits.

O produto continua evoluindo.

Não para competir com bancos modernos.

Mas para continuar fazendo aquilo que sempre fez melhor:

executar cargas críticas em escala gigantesca.


Por Que um Sysprog Deve Aprender IMS?

Porque cedo ou tarde ele vai encontrá-lo.

Talvez durante uma migração.

Talvez durante uma investigação.

Talvez durante um incidente crítico.

Talvez durante uma modernização.

Quando isso acontecer, entender IMS fará toda a diferença.

Não é necessário se tornar um DBA IMS.

Não é necessário dominar DL/I.

Mas compreender:

  • Arquitetura

  • Regiões

  • IMS Connect

  • IMSplex

  • DBRC

  • Recovery

  • Performance

transforma completamente a capacidade de diagnosticar problemas.


Conclusão

☕💣🚀

Operador...

Existe uma boa chance de que neste exato momento algum aplicativo bancário esteja consultando um banco IMS.

Existe uma boa chance de que alguma companhia aérea esteja processando reservas através dele.

Existe uma boa chance de que algum sistema de seguros esteja executando milhões de transações sobre uma arquitetura criada há quase seis décadas.

E existe uma boa chance de que, em algum momento da sua carreira, você receba uma ligação no meio da madrugada e escute a frase:

"Precisamos da ajuda do Sysprog. O IMS está envolvido."

Quando esse dia chegar, você descobrirá que o IMS não é apenas um banco de dados.

Ele é um dos pilares invisíveis que sustentam o mundo digital moderno.

E entender como ele funciona é uma das habilidades mais valiosas que um profissional de Mainframe pode desenvolver.

Esse artigo segue o estilo narrativo do Bellacosa Mainframe: abertura impactante, storytelling operacional, visão prática de Sysprog, curiosidades históricas, arquitetura técnica e fechamento inspiracional.


sexta-feira, 5 de junho de 2026

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

 

Bellacosa Mainframe e o assistente de IA LLM RAG

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

"Primeiro ele responde perguntas. Depois organiza tarefas. Em seguida consulta sistemas. Quando você percebe, existe uma inteligência trabalhando ao seu lado 24 horas por dia."


🚀 Afinal, o que é um Assistente de IA?

Imagine um operador de computador que:

✅ Nunca dorme
✅ Nunca tira férias
✅ Nunca esquece um procedimento
✅ Aprende com documentação
✅ Conversa em linguagem natural

Um Assistente de Inteligência Artificial é um software capaz de compreender perguntas, interpretar contexto, acessar informações e executar tarefas para auxiliar pessoas em suas atividades.

Diferente de um chatbot tradicional, que segue roteiros pré-definidos, um assistente moderno utiliza modelos de linguagem (LLMs) para raciocinar sobre problemas e gerar respostas dinâmicas.

Na prática, ele pode:

  • Responder dúvidas técnicas

  • Gerar código

  • Criar documentos

  • Automatizar processos

  • Consultar bancos de dados

  • Executar fluxos de negócio

  • Integrar sistemas corporativos

  • Apoiar decisões operacionais

Pense nele como uma mistura de:

  • Analista de Sistemas

  • Operador

  • DBA

  • Documentador

  • Programador

  • Professor

Tudo em uma única interface.


🏛️ O Assistente de IA no Mundo Mainframe

Imagine um assistente treinado com:

  • JCL

  • COBOL

  • CICS

  • DB2

  • IMS

  • RACF

  • TSO/ISPF

  • JES2

  • z/OS

Você poderia perguntar:

"Por que este JOB deu ABEND S0C7?"

ou

"Monte um JCL para copiar um VSAM KSDS."

ou

"Explique a diferença entre EXEC CICS LINK e XCTL."

Em segundos ele produziria:

  • Explicações

  • Diagnósticos

  • Exemplos

  • Sugestões de correção

É como ter um especialista Bellacosa Mainframe disponível 24x7.


🔧 Como Construir um Assistente de IA?

Hoje existem vários caminhos.

Caminho 1 — O Mais Simples

Utilizar plataformas prontas:

  • GPTs personalizados

  • Assistants

  • Copilots

  • No-Code AI Builders

Você fornece:

  • Documentação

  • PDFs

  • Manuais

  • Procedimentos

E o assistente aprende aquele contexto.

Ideal para:

  • Empresas

  • Equipes de suporte

  • Times de treinamento


Caminho 2 — Assistente com Base de Conhecimento

Arquitetura típica:

Usuário
   │
   ▼
Assistente IA
   │
   ▼
Base de Conhecimento
   │
   ├── PDFs
   ├── Manuais
   ├── Wikis
   ├── Procedimentos
   └── Documentação Técnica

O modelo consulta documentos antes de responder.

Chamamos isso de:

RAG (Retrieval Augmented Generation)

É uma das arquiteturas mais populares atualmente.


Caminho 3 — Assistente Corporativo

Aqui a brincadeira fica séria.

Usuário
   │
   ▼
Assistente IA
   │
   ├── SAP
   ├── Mainframe
   ├── Banco de Dados
   ├── ServiceNow
   ├── Jira
   ├── APIs
   └── Sistemas Legados

O assistente deixa de apenas responder.

Ele passa a:

  • Consultar sistemas

  • Abrir chamados

  • Executar processos

  • Atualizar registros

Estamos entrando no território dos Agentes de IA.


🎯 O Que Eu Ganho Construindo Um?

Muito mais do que parece.

1. Produtividade

Tarefas que demoravam horas passam a levar minutos.


2. Documentação Viva

Em vez de procurar em centenas de PDFs:

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

Você simplesmente pergunta.


3. Treinamento Acelerado

Novatos aprendem mais rápido.

Um júnior pode consultar o assistente constantemente.


4. Preservação do Conhecimento

Quando especialistas se aposentam, muito conhecimento desaparece.

O assistente pode ajudar a preservar:

  • Procedimentos

  • Boas práticas

  • Lições aprendidas


5. Disponibilidade 24x7

Não importa:

  • Madrugada

  • Feriado

  • Final de semana

O assistente continua disponível.


⚠️ As Desvantagens

Nem tudo é magia.

Alucinações

O maior problema atual.

A IA pode responder com enorme confiança algo completamente errado.

Exemplo:

"Qual parâmetro resolve esse ABEND?"

Ela pode inventar uma solução inexistente.


Dependência Excessiva

Algumas pessoas param de pensar.

Começam a copiar respostas sem validar.

Isso é extremamente perigoso.


Custo

Modelos avançados podem gerar custos relevantes.

Especialmente em grandes empresas.


Segurança

Documentos enviados para modelos externos podem conter:

  • Dados sensíveis

  • Segredos corporativos

  • Informações confidenciais

Governança é obrigatória.


☠️ Os Caminhos Tenebrosos

Agora entramos na sala escura do datacenter.

Luzes piscando.

Ar-condicionado rugindo.

Alarmes ao fundo.


Caminho Tenebroso #1

Confiar Cegamente na IA

A IA não é uma autoridade.

Ela é uma ferramenta.

Quem assina a decisão continua sendo o humano.


Caminho Tenebroso #2

Alimentar a IA com Dados Incorretos

Existe uma regra antiga:

Garbage In
Garbage Out

Se o treinamento estiver errado:

As respostas estarão erradas.


Caminho Tenebroso #3

Expor Informações Sigilosas

Jamais envie para modelos públicos:

  • Senhas

  • Chaves de API

  • Dumps confidenciais

  • Dados de clientes

Uma única falha pode gerar consequências enormes.


Caminho Tenebroso #4

Automatizar Sem Controle

Um assistente que apenas responde é uma coisa.

Um assistente que executa comandos é outra completamente diferente.

Imagine:

DELETE PRODUCAO

executado automaticamente.

Nem preciso explicar o restante da história...


Caminho Tenebroso #5

Substituir Conhecimento Humano

O objetivo não é eliminar especialistas.

É amplificar sua capacidade.

O melhor cenário é:

Humano + IA

e não

Humano OU IA

🎓 O Futuro

Estamos caminhando para uma era onde cada profissional terá seu próprio assistente especializado.

Um desenvolvedor terá um assistente de programação.

Um médico terá um assistente clínico.

Um advogado terá um assistente jurídico.

E um profissional de Mainframe poderá ter algo como:

"Bellacosa Mainframe Assistant"

Capaz de explicar:

  • JES2

  • RACF

  • CICS

  • DB2

  • COBOL

  • JCL

  • z/OS

com exemplos, laboratórios e diagnósticos.


☕💣 Conclusão Bellacosa Mainframe

O assistente de IA não é o fim do operador.

Não é o fim do programador.

Não é o fim do analista.

Ele é uma nova camada de abstração, assim como:

  • Assembly evoluiu para COBOL

  • Cartões perfurados evoluíram para terminais

  • Terminais evoluíram para interfaces gráficas

  • Interfaces evoluíram para a Web

Agora estamos entrando na era da conversa.

A pergunta não é mais:

"Como faço isso?"

Mas sim:

"Como explico para a IA o que eu preciso?"

Quem dominar essa habilidade terá uma vantagem semelhante à de quem aprendeu internet nos anos 90 ou computação em nuvem nos anos 2000.

Porque, no fim das contas, o maior poder da IA não está em responder perguntas.

Está em transformar conhecimento em ação.

E isso, meu amigo operador, é algo que merece um café forte antes do próximo IPL. ☕🚀💣


quinta-feira, 4 de junho de 2026

☕💣 Laboratorio Bellacosa Mainframe Assistant

 

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étricaObjetivo
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

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

 

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.


quarta-feira, 3 de junho de 2026

☕💣📋 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

 

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:

SistemaProblemaImpactoPrioridade
CadastroGO TO excessivoMédioMédia
CobrançaSem documentaçãoAltoAlta
FaturamentoAlta complexidadeAltoAlta

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:

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

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



terça-feira, 2 de junho de 2026

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

 

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.

ProgramaAlteraçõesIncidentes
FIN00112015
FIN002100
FIN0039512

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