Translate

sábado, 6 de janeiro de 2024

Goblin Slayer — Parte Final ? Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy da Atualidade A Síntese Definitiva de uma Jornada que Vai Muito Além da Caça aos Goblins

 

Bellacosa Mainframe conclui a saga Goblin Slayer

☕ Um Café no Bellacosa Mainframe

Goblin Slayer — Parte Final ? Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy da Atualidade

A Síntese Definitiva de uma Jornada que Vai Muito Além da Caça aos Goblins

"Quando um Programador COBOL Descobre que Algumas Obras São Como Sistemas de Missão Crítica: quanto mais você estuda sua arquitetura, mais percebe a genialidade escondida entre as linhas."


Introdução — O Último Café Antes de Deixar a Guilda

Toda grande jornada chega a um momento em que olhamos para trás.

Foi assim com Frodo ao deixar a Terra-média.

Foi assim com Conan depois de conquistar seu reino.

Foi assim com Guts ao compreender que sua maior batalha nunca foi apenas contra os Apóstolos.

E talvez seja exatamente assim quando terminamos de analisar Goblin Slayer.

Ao longo desta série no Bellacosa Mainframe, percorremos um caminho que começou aparentemente simples.

Queríamos entender por que um aventureiro comum dedicava toda a sua vida a eliminar goblins.

Mas, pouco a pouco, descobrimos que a verdadeira resposta nunca esteve nos goblins.

Ela estava na forma como Kumo Kagyu construiu seu universo.

Exploramos sua cronologia.

Sua engenharia militar.

Sua estratégia.

Sua psicologia.

Sua ecologia.

Suas referências culturais.

Seus simbolismos.

E finalmente seus cem pequenos segredos.

Agora é hora de juntar todas essas peças.

Porque apenas quando observamos o mosaico completo percebemos que Goblin Slayer nunca foi apenas um anime.

Foi um exercício de arquitetura narrativa.


Muito Além da Violência

Uma das maiores injustiças cometidas contra Goblin Slayer foi defini-lo apenas pelo primeiro episódio.

Naturalmente, aquele episódio marcou profundamente o público.

Foi chocante.

Brutal.

Desconfortável.

Intencionalmente difícil de assistir.

Mas reduzir toda a obra a esse momento seria como resumir Berserk apenas ao Eclipse ou Neon Genesis Evangelion apenas às batalhas contra os Anjos.

O impacto inicial existe para estabelecer uma verdade simples:

naquele mundo, consequências existem.

A partir daí, a série passa a discutir algo muito maior.

Como pessoas traumatizadas continuam vivendo.

Como pequenas ameaças podem destruir civilizações inteiras.

Como disciplina supera talento.

Como inteligência vence força.

Como experiência vale mais que heroísmo impulsivo.


A Cronologia Revela um Autor Paciente

Nossa primeira parada foi compreender como Goblin Slayer nasceu.

A cronologia da franquia mostrou um crescimento orgânico.

Web Novel.

Light Novel.

Mangá.

Spin-offs.

Filme.

Anime.

Nada surgiu por acaso.

Cada nova mídia ampliou partes específicas daquele universo.

Kumo Kagyu nunca tentou reescrever sua história.

Ele preferiu expandi-la.

É exatamente assim que arquitetos experientes evoluem grandes sistemas.

Em vez de substituir tudo.

Acrescentam novas camadas.


O Worldbuilding Invisível

Um dos aspectos mais brilhantes da obra é justamente aquilo que raramente recebe destaque.

O mundo continua funcionando sem o protagonista.

Enquanto Goblin Slayer limpa uma pequena caverna...

A Hero derrota ameaças capazes de salvar o continente.

Reis governam.

Guerras acontecem.

Mercadores viajam.

A Guild recebe novas missões.

Essa sensação de continuidade faz o universo parecer vivo.

Não existe a impressão de que o mundo foi criado apenas para servir ao protagonista.

Pelo contrário.

Ele parece apenas mais um entre milhares de aventureiros.

E isso aumenta enormemente a credibilidade da narrativa.


Goblins Nunca Foram Apenas Goblins

Ao estudarmos sua biologia, percebemos outra genialidade.

Os goblins representam muito mais que monstros.

Funcionam como uma espécie invasora.

Adaptam-se.

Aprendem.

Exploram vulnerabilidades.

Utilizam ferramentas.

Criam hierarquias.

Expandem território.

Essa abordagem quase ecológica diferencia Goblin Slayer da maioria das fantasias modernas.

Os goblins possuem comportamento consistente.

Não aparecem apenas quando o roteiro precisa de um inimigo.

Eles seguem regras.


Psicologia em Vez de Poderes

Talvez a maior qualidade do protagonista seja justamente aquilo que ele não possui.

Não há transformação.

Não há forma definitiva.

Não há espada lendária.

Não existe um "modo deus".

Existe apenas um homem profundamente traumatizado tentando impedir que outras pessoas vivam o mesmo pesadelo.

Sua evolução acontece internamente.

Cada amizade.

Cada conversa.

Cada pequena demonstração de confiança.

Cada sorriso raro.

Tudo representa progresso.

É uma evolução emocional.

Muito mais difícil de escrever.

Muito mais humana.


Estratégia Como Superpoder

Se existe uma característica que define Goblin Slayer, talvez seja sua maneira de pensar.

Ele nunca vence porque luta melhor.

Vence porque pensa melhor.

Enquanto outros aventureiros procuram equipamentos lendários...

Ele estuda o terreno.

Enquanto outros treinam golpes espetaculares...

Ele analisa rotas de fuga.

Enquanto outros sonham com glória...

Ele procura reduzir riscos.

Sua mente funciona como um tabuleiro de xadrez.

Cada decisão considera consequências futuras.

Cada combate começa muito antes da primeira espada.


Engenharia Militar Disfarçada de Fantasia

Nossa análise da engenharia militar revelou algo surpreendente.

Goblin Slayer combate como um oficial de estado-maior.

Reconhecimento.

Logística.

Redundância.

Planejamento.

Contingência.

Controle de recursos.

Economia de esforço.

São conceitos utilizados por exércitos reais ao longo da história.

Kumo Kagyu simplesmente transportou esses princípios para um universo fantástico.

O resultado foi um protagonista extremamente convincente.


Os Simbolismos Quase Invisíveis

Outra camada fascinante está nos símbolos.

O capacete.

A armadura.

O escudo pequeno.

A espada curta.

As cavernas.

O fogo.

A luz.

O silêncio.

Nada parece escolhido aleatoriamente.

Cada elemento comunica algo sobre o protagonista.

Sua dificuldade em abandonar o passado.

Sua necessidade constante de proteção.

Sua recusa em tornar-se um herói convencional.

Esses pequenos detalhes enriquecem profundamente a narrativa.


As Influências Culturais

Durante nossa jornada também encontramos inúmeras referências.

Conan.

Berserk.

Tolkien.

Dungeons & Dragons.

Sword World RPG.

Mitologia europeia.

História militar.

Literatura fantástica.

Kumo Kagyu não copia.

Ele dialoga.

Mistura.

Adapta.

Transforma.

O resultado é uma obra extremamente familiar para fãs de fantasia, mas ainda assim original.


O Código-Fonte Narrativo

Talvez seja aqui que o Bellacosa Mainframe encontre sua maior analogia.

Programadores iniciantes costumam admirar programas enormes.

Arquitetos experientes admiram programas coerentes.

Goblin Slayer funciona exatamente assim.

Na superfície vemos combates.

Logo abaixo encontramos planejamento.

Depois estratégia.

Depois psicologia.

Depois ecologia.

Depois simbolismos.

Depois referências.

Cada releitura revela uma camada adicional.

Como um sistema COBOL escrito por alguém que pensou não apenas na execução de hoje, mas na manutenção das próximas décadas.


O Impacto na Cultura Otaku

Nem toda obra precisa agradar a todos para tornar-se importante.

Goblin Slayer dividiu opiniões desde o primeiro dia.

E talvez justamente por isso tenha se tornado uma referência dentro da Dark Fantasy contemporânea.

A série reacendeu discussões sobre:

o peso das consequências.

o uso responsável da violência na narrativa.

a construção do trauma.

a importância do planejamento.

a influência dos RPGs clássicos.

o retorno de protagonistas imperfeitos.

Ela mostrou que ainda existe espaço para histórias em que inteligência supera poderes sobrenaturais.

Muitos animes posteriores passaram a valorizar protagonistas mais técnicos, observadores e estratégicos, reforçando o interesse por personagens que vencem pela preparação, e não apenas pelo poder bruto.


O Que um Programador COBOL Aprende com Goblin Slayer?

Pode parecer improvável aproximar um anime de um ambiente IBM Z.

Mas quanto mais observamos, mais paralelos aparecem.

Goblin Slayer nunca improvisa em produção.

Ele testa.

Planeja.

Analisa.

Documenta mentalmente.

Aprende com incidentes.

Constrói redundâncias.

Protege recursos.

Minimiza riscos.

É exatamente assim que trabalham os melhores arquitetos de sistemas.

Um bom profissional de mainframe sabe que heroísmo costuma ser sinal de planejamento insuficiente.

O verdadeiro sucesso acontece quando ninguém percebe que um desastre foi evitado.

Goblin Slayer vive essa filosofia diariamente.

Ele não busca reconhecimento.

Busca estabilidade.

E estabilidade é uma palavra que qualquer profissional de missão crítica compreende profundamente.


A Maior Lição da Série

Depois de milhares de páginas, dezenas de capítulos e incontáveis batalhas, talvez a maior lição de Goblin Slayer seja surpreendentemente simples.

Grandes vitórias raramente pertencem aos mais fortes.

Pertencem aos mais preparados.

O protagonista nunca derrota seus inimigos porque nasceu especial.

Ele vence porque estuda.

Observa.

Aprende.

Adapta-se.

Corrige erros.

Persiste.

Essa talvez seja uma das mensagens mais inspiradoras da obra.

Ela nos lembra que competência não nasce pronta.

É construída.

Missão após missão.

Erro após erro.

Dia após dia.


Epílogo — O Último Registro no Grimório

Chegamos ao fim desta longa jornada.

Começamos perguntando quem era Goblin Slayer.

Terminamos entendendo por que sua história permanece tão relevante.

Descobrimos que a cronologia explica sua evolução.

Que a biologia explica seus inimigos.

Que a psicologia explica suas escolhas.

Que a estratégia explica suas vitórias.

Que a engenharia militar explica sua eficiência.

Que os simbolismos explicam sua humanidade.

Que as referências culturais explicam sua riqueza narrativa.

E que os cem segredos apenas confirmam aquilo que já suspeitávamos.

Kumo Kagyu escreveu muito mais do que uma história de fantasia.

Construiu uma obra sobre disciplina.

Resiliência.

Memória.

Planejamento.

Responsabilidade.

E sobre a coragem silenciosa daqueles que escolhem enfrentar os monstros que ninguém mais considera importantes.

No Bellacosa Mainframe costumamos dizer que os melhores sistemas são aqueles que continuam funcionando por décadas sem chamar atenção.

Goblin Slayer pertence exatamente a essa categoria.

Talvez nunca seja a obra mais barulhenta.

Talvez nunca seja a mais popular.

Mas continuará sendo revisitada porque foi construída sobre fundamentos sólidos.

E assim encerramos nossa campanha.

Fechamos o grimório.

Guardamos a espada curta.

Retiramos o capacete apenas por um instante.

O café acabou de esfriar.

Mas as histórias verdadeiramente bem escritas nunca terminam quando fechamos o livro.

Elas continuam sendo executadas, silenciosamente, na memória de quem aprendeu a enxergar além da superfície.

Como um grande programa COBOL em produção.

Invisível para quase todos.

Essencial para quem realmente compreende sua arquitetura.

Um Café no Bellacosa Mainframe

ARQUIVOS DA GUILDA • CLASSIFICAÇÃO: DARK FANTASY

Goblin Slayer sem Mistérios

O Guia Definitivo da Série Completa

Uma jornada por cronologia, psicologia, biologia, estratégia, engenharia militar, referências culturais, simbolismos e os segredos escondidos de Goblin Slayer.

“Quando um Programador COBOL Descobre que Grandes Obras Também Precisam de um Mapa para Não se Perder na Dungeon.”
Explorar a série
RELATÓRIO DE MISSÃO

Uma série construída como uma campanha de RPG

Goblin Slayer sem Mistérios é uma coleção especial do Bellacosa Mainframe dedicada à análise profunda da obra criada por Kumo Kagyu. Cada capítulo investiga uma camada diferente da franquia, relacionando fantasia sombria, RPG de mesa, estratégia, trauma, sobrevivência, engenharia militar e arquitetura de sistemas.

A coleção foi organizada em ordem cronológica para facilitar a leitura. Você pode começar pela Parte I, seguir capítulo após capítulo ou utilizar os filtros para selecionar assuntos como psicologia, goblins, táticas, história da franquia e cultura otaku.

Todos os títulos abaixo são links HTML reais e permanecem acessíveis mesmo quando o JavaScript estiver desativado. Isso facilita a navegação dos leitores e a descoberta das páginas por mecanismos de busca.

Progresso da campanha 0 de 14 missões visitadas
14 capítulos encontrados
I
Introdução

Goblin Slayer sem Mistérios — Parte I

O ponto de entrada da campanha. Uma análise sobre o herói invisível que não salva o mundo em uma única batalha, mas impede silenciosamente que ele desmorone todos os dias.

Heroísmo Disciplina Mainframe
II
Disciplina

Goblin Slayer sem Mistérios — Parte II

O verdadeiro poder não está na espada, mas na constância de levantar, preparar os equipamentos e executar diariamente o trabalho que quase ninguém deseja assumir.

Rotina Dever Persistência
III
Missão crítica

Goblin Slayer sem Mistérios — Parte III

Nem todo herói enfrenta o Rei Demônio. Alguns garantem que na segunda-feira existirão sistema, salários, luz e uma aldeia inteira ainda de pé.

Disponibilidade Proteção Responsabilidade
IV
Arquitetura

Parte IV — O Arquiteto Invisível de Goblin Slayer

Uma reflexão sobre profissionais que projetam soluções, previnem desastres e permanecem atrás do terminal enquanto o restante do mundo apenas percebe que tudo continua funcionando.

Arquitetura COBOL Prevenção
V
Cronologia

Parte V — A Evolução Cronológica Completa da Franquia

Da publicação original às light novels, mangás, adaptações, spin-offs, filme e temporadas do anime: a evolução de uma história que cresceu release após release.

Web Novel Light Novel Anime
VI
Biologia

Parte VI — A Biologia dos Goblins

Anatomia, comportamento, adaptação, hierarquia e ecologia dos goblins analisados como uma espécie invasora capaz de explorar brechas e evoluir rapidamente.

Ecologia Adaptação Worldbuilding
VII
Referências

Parte VII — As Referências Escondidas de Goblin Slayer

Conan, Berserk, Tolkien, Dungeons & Dragons, Sword World RPG, literatura fantástica, mitologia e cultura pop escondidos entre as linhas da obra de Kumo Kagyu.

RPG Literatura Cultura pop
VIII
Psicologia

Parte VIII — A Psicologia Profunda de Goblin Slayer

Trauma, hipervigilância, isolamento, necessidade de controle, resiliência e reconstrução emocional por meio das relações que lentamente devolvem humanidade ao protagonista.

Trauma Memória Resiliência
IX
Engenharia militar

Parte IX — A Engenharia Militar de Goblin Slayer

Reconhecimento, suprimentos, redundância, controle do terreno, fortificação, retirada e arquitetura operacional transformam batalhas perigosas em vitórias planejadas.

Logística Terreno Contingência
X
Estratégia

Parte X — A Estratégia de Goblin Slayer

Uma análise sobre informação, iniciativa, especialização, probabilidades, redundância e a capacidade de pensar diversos movimentos à frente do adversário.

Planejamento Inteligência Antecipação
XI
100 segredos

Parte XI — Os 100 Segredos de Goblin Slayer

Cem detalhes sobre personagens, mundo, goblins, equipamentos, narrativa, simbolismos, RPG, produção, psicologia e estratégia que podem passar despercebidos até pelos fãs.

Easter eggs Simbolismos Curiosidades
XII
Guia completo

Parte XII — Goblin Slayer sem Mistérios

O mapa da campanha: introdução, sequência recomendada, resumo dos capítulos e orientação para explorar todas as camadas da coleção sem se perder na dungeon.

Índice Mapa Ordem de leitura
FINAL
Síntese definitiva

Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy

A conclusão da jornada, reunindo cronologia, psicologia, estratégia, engenharia militar, simbolismos, referências culturais, construção de mundo e impacto na cultura otaku.

Dark Fantasy Síntese Conclusão
BÔNUS
Dossiê militar

A Composição do Exército Goblin em The Fate of an Adventurer

Rei Goblin, estado-maior, Champions, Shamans, arqueiros, infantaria, Riders, logística e cadeia de comando analisados como componentes de uma força militar organizada.

Exército Goblin Hierarquia Ordem de batalha
ROTA RECOMENDADA

Como percorrer esta dungeon

Comece pelas três primeiras partes para compreender a proposta da série. Depois visite o Arquiteto Invisível, conheça a evolução da franquia e aprofunde-se em biologia, referências, psicologia, engenharia militar e estratégia.

  1. 01 Fundamentos do herói invisível
  2. 02 História e evolução da franquia
  3. 03 Biologia e organização dos goblins
  4. 04 Psicologia e simbolismos
  5. 05 Engenharia militar e estratégia
  6. 06 Segredos, guia completo e síntese final
Bellacosa Mainframe Dark Fantasy • Anime • RPG • COBOL • Estratégia

“A vitória não é improviso. É arquitetura.”

sexta-feira, 5 de janeiro de 2024

☕💣 TESTOU 100% DOS CASOS... E MESMO ASSIM QUEBROU EM PRODUÇÃO? O MAIOR MITO DOS TESTES EM MAINFRAME QUE AINDA ENGANA MUITA GENTE

 

Bellacosa Mainframe e a cobertura de testes em mainframe

☕💣 TESTOU 100% DOS CASOS... E MESMO ASSIM QUEBROU EM PRODUÇÃO? O MAIOR MITO DOS TESTES EM MAINFRAME QUE AINDA ENGANA MUITA GENTE

Se existe uma frase que todo profissional de Mainframe já ouviu alguma vez, ela é:

"O programa foi totalmente testado."

Curiosamente, essa mesma frase costuma aparecer poucas horas antes de um incidente em produção.

E aqui está uma verdade que muitos profissionais descobrem apenas depois de alguns anos de guerra:

Não existe programa totalmente testado.

O que existe é um programa com um nível de cobertura suficientemente alto para reduzir o risco a um patamar aceitável.

A pergunta correta nunca deveria ser:

"O programa foi testado?"

Mas sim:

"Qual foi a cobertura real do teste?"

E mais importante ainda:

"O que ficou sem ser testado?"

Hoje vamos conversar sobre um dos assuntos mais importantes para analistas, desenvolvedores COBOL, testadores, líderes técnicos e gestores de aplicações Mainframe:

Como medir cobertura de testes, construir um plano realmente abrangente e aumentar drasticamente a qualidade das entregas.

Pegue seu café.

Porque cobertura de teste não é quantidade de cenários.

É ciência.


O grande erro: confundir quantidade com cobertura

Muitos profissionais acreditam que executar muitos casos de teste significa possuir alta cobertura.

Não significa.

Imagine um programa COBOL com:

  • 20 IFs

  • 5 EVALUATEs

  • 3 loops

  • 15 regras de negócio

Você executa 500 casos.

Mas todos seguem o mesmo caminho lógico.

Resultado:

  • 500 execuções

  • cobertura baixíssima

Você apenas percorreu a mesma estrada centenas de vezes.

É como testar um elevador indo somente para o segundo andar.

Você pode apertar o botão mil vezes.

Ainda não sabe o que acontece no décimo quinto andar.


O que é cobertura de teste?

Cobertura é uma métrica que mede quanto do comportamento do software foi exercitado durante os testes.

Ela responde perguntas como:

  • Quantas instruções foram executadas?

  • Quantos IFs foram percorridos?

  • Quantas decisões foram avaliadas?

  • Quantos caminhos lógicos foram explorados?

  • Quantas regras de negócio foram validadas?

Quanto maior a cobertura, maior a confiança.

Mas atenção:

100% de cobertura não significa ausência de defeitos.

Significa apenas que tudo foi visitado.

Não necessariamente validado corretamente.


As camadas de cobertura

Um plano robusto costuma analisar múltiplas camadas.


1. Cobertura de instruções (Statement Coverage)

A mais básica.

Pergunta:

Cada linha executável foi executada ao menos uma vez?

Exemplo:

IF SALDO > 0
   MOVE 'A' TO STATUS
ELSE
   MOVE 'B' TO STATUS
END-IF

Se apenas SALDO > 0 foi testado:

MOVE 'A'

executou.

Mas:

MOVE 'B'

não.

Cobertura parcial.

Para atingir 100%, ambos os caminhos precisam ser executados.


2. Cobertura de decisões (Branch Coverage)

Mais importante.

Pergunta:

Cada decisão assumiu todos os resultados possíveis?

Exemplo:

IF CLIENTE-ATIVO

Devemos testar:

  • TRUE

  • FALSE

Muitos projetos param na cobertura de instruções.

Os melhores projetos vão além e medem cobertura de decisões.


3. Cobertura de condições

Exemplo:

IF IDADE > 18
AND RENDA > 5000

Precisamos validar:

IDADERENDA
TT
TF
FT
FF

Caso contrário, parte da lógica pode nunca ter sido exercitada.


4. Cobertura de caminhos (Path Coverage)

Aqui a brincadeira fica séria.

Imagine:

IF A
   IF B
      ...
   END-IF
END-IF

Agora existem vários caminhos:

  • A=T B=T

  • A=T B=F

  • A=F

Quanto mais IFs surgem, mais caminhos aparecem.

O crescimento é explosivo.

Por isso ninguém tenta cobrir absolutamente todos os caminhos em sistemas grandes.

O objetivo é cobrir os caminhos críticos.


O conceito mais importante do Mainframe

Cobertura de negócio

Esta é a cobertura que realmente paga as contas.

Perguntas:

  • Emissão de apólice funcionou?

  • Pagamento foi processado?

  • Cálculo de juros foi validado?

  • Baixa financeira foi testada?

  • Cancelamento foi exercitado?

O usuário não se importa se:

PERFORM 1000-PROCESSA

executou.

Ele se importa se o dinheiro caiu na conta correta.

Por isso:

Cobertura técnica sem cobertura funcional é uma ilusão perigosa.


Como construir um plano de teste abrangente

A técnica que uso para ensinar equipes é simples.

Divida os cenários em grupos.


Grupo 1 – Casos normais

Fluxo feliz.

O famoso Happy Path.

Exemplo:

Cliente válido.

Conta válida.

Saldo suficiente.

Arquivo disponível.

Tudo funcionando.

Esses testes validam o comportamento esperado.


Grupo 2 – Casos de fronteira

Aqui vivem os defeitos.

Exemplo:

Campo aceita:

0 a 999999

Testar:

0
1
999998
999999

Mas também:

-1
1000000

A maioria dos bugs aparece nos limites.


Grupo 3 – Casos inválidos

Todo sistema recebe lixo.

Você precisa descobrir como ele reage.

Exemplos:

CPF inválido.

Data inválida.

Arquivo vazio.

Campo nulo.

Código inexistente.

Registro duplicado.

Produção faz isso diariamente.

Seu teste também deve fazer.


Grupo 4 – Casos excepcionais

Os mais esquecidos.

Exemplo:

VSAM indisponível.

DB2 retornando erro.

Dataset cheio.

Timeout de CICS.

Lock de registro.

Fila MQ parada.

É justamente aqui que nascem os incidentes mais caros.


O método Bellacosa para testar COBOL

Quando olho um programa, sigo sempre esta sequência.


Entrada

O que entra?

Analise:

LINKAGE
COMMAREA
ARQUIVOS
DB2
MQ
VSAM

Liste tudo.


Processamento

O que acontece?

Mapeie:

  • IF

  • EVALUATE

  • PERFORM

  • GO TO

  • loops

Tudo que altera comportamento.


Saída

O que sai?

Arquivos.

Relatórios.

Tabelas.

Mensagens.

Retornos.

Abends.

Tudo deve ser validado.


A matriz de cobertura

Uma técnica extremamente poderosa.

Monte uma tabela.

RegraTestada
Regra 1Sim
Regra 2Sim
Regra 3Não
Regra 4Sim

Agora faça o mesmo para:

  • programas

  • módulos

  • telas

  • transações

  • jobs

A matriz revela instantaneamente os buracos.


Cobertura para Batch

Em batch devemos validar:

Arquivo vazio

0 registros

Arquivo pequeno

10 registros

Arquivo médio

100.000 registros

Arquivo grande

10 milhões de registros

Registro inválido

Registro duplicado

Chave fora de sequência

Dataset inexistente

Espaço insuficiente

Return codes

Tudo isso precisa aparecer no plano.


Cobertura para CICS

Valide:

  • Entrada válida

  • Entrada inválida

  • PF Keys

  • Timeout

  • Commarea vazia

  • Commarea truncada

  • Falha de comunicação

  • Reentrada da transação

Muitos defeitos aparecem apenas em ambiente online.


Cobertura para DB2

Nunca teste apenas o SQLCODE 0.

Teste:

0
+100
-803
-811
-904
-911
-913

Grande parte dos problemas de produção surge justamente nos códigos de erro.


Cobertura para VSAM

Valide:

READ OK
NOT FOUND
DUPLICATE KEY
END OF FILE
OPEN ERROR

Muitos testes ignoram completamente os File Status.

Erro clássico.


Testes de performance também fazem parte da cobertura

Um programa pode estar funcionalmente correto.

Mas:

  • consumir CPU demais

  • gerar EXCP excessivo

  • aumentar elapsed time

E então falhar operacionalmente.

Portanto inclua:

  • volume realista

  • pico de carga

  • concorrência

  • consumo de recursos


Como medir cobertura no Mainframe

Hoje existem ferramentas especializadas.

Entre elas:

  • IBM Debug Tool

  • IBM Application Delivery Foundation

  • IBM Fault Analyzer

  • IBM Application Performance Analyzer

  • Compuware Topaz

  • Compuware Xpediter

  • Micro Focus Enterprise Analyzer

  • SonarQube para COBOL

Essas soluções conseguem mostrar:

  • linhas executadas

  • branches percorridos

  • percentuais de cobertura

  • áreas não testadas

Transformando percepção em números.

E números vencem opiniões.


A armadilha do 100%

Imagine:

IF VALOR > 1000

Você executa:

1001

e

999

Cobertura:

100%.

Mas você não testou:

1000

Exatamente o limite.

Portanto:

100% de cobertura não significa qualidade máxima.

Significa apenas que todos os pontos foram visitados.


O indicador que realmente importa

Depois de décadas observando projetos, cheguei a uma conclusão.

A melhor pergunta não é:

"Qual a cobertura?"

Mas:

"Qual o risco residual?"

Se uma rotina financeira movimenta bilhões:

  • 95% pode ser insuficiente.

Se uma rotina gera relatório interno:

  • 80% pode ser aceitável.

Cobertura deve ser analisada junto com criticidade.


A filosofia dos grandes times

Equipes maduras fazem quatro perguntas:

O que testamos?

O que não testamos?

Por que não testamos?

Qual o risco disso?

Quando essas respostas existem, o plano de teste deixa de ser um documento burocrático.

Ele vira uma ferramenta de gestão de risco.


Conclusão

O profissional júnior acredita que testar é executar casos.

O profissional experiente entende que testar é procurar defeitos.

E o veterano de Mainframe sabe algo ainda mais importante:

Cobertura não é uma porcentagem. É a medida da sua confiança antes de colocar um programa em produção.

Porque no mundo real ninguém é acordado às 3 da manhã por causa dos cenários que foram testados.

Somos acordados pelos cenários que esquecemos de testar.

E quase sempre eles estavam escondidos exatamente naquele IF, naquele SQLCODE, naquele File Status ou naquele registro de fronteira que alguém julgou improvável.

No Mainframe, assim como na aviação, o problema raramente está no voo que você simulou.

O problema está naquele que você acreditou que jamais aconteceria. ☕💣🚀


quinta-feira, 4 de janeiro de 2024

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

 

Bellacosa Mainframe e laboratorio pratico de performance

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

Este laboratório foi criado para transformar conceitos em prática.

A ideia é que o aluno pense como um Analista de Performance, um Desenvolvedor COBOL e um Sysprog ao mesmo tempo.

Cada exercício possui:

  • Cenário

  • Desafio

  • Solução Comentada

  • Conceitos Envolvidos


EXERCÍCIO 1

Identificando o Tipo de Teste

Cenário

O banco deseja validar se o Internet Banking suporta 5.000 usuários simultâneos.

Pergunta

Qual tipo de teste deve ser realizado?

A) Estresse

B) Resistência

C) Carga

D) Pico


Solução

Resposta:

C) Carga

O objetivo é validar a capacidade prevista do ambiente.

Não estamos ultrapassando limites.

Não estamos testando durante horas.

Não estamos simulando explosões repentinas.

Estamos simulando o uso normal esperado.


EXERCÍCIO 2

Descobrindo o Gargalo

Cenário

Uma consulta de saldo apresenta:

ComponenteTempo
Front-End50 ms
API80 ms
CICS1200 ms
DB2950 ms

Pergunta

Onde está o principal gargalo?


Solução

CICS e DB2.

O tempo de resposta total está concentrado nessas camadas.

O Front-End e API representam parcela muito pequena do processamento.

O próximo passo seria analisar:

  • SQL

  • Índices

  • Plano de acesso

  • Locks


EXERCÍCIO 3

Avaliando Throughput

Cenário

Durante um teste foram processadas:

120.000 transações

em

60 segundos

Pergunta

Qual o Throughput?


Solução

Fórmula:

TPS = Transações ÷ Tempo

120.000 ÷ 60

TPS = 2.000

Resposta:

2.000 TPS


EXERCÍCIO 4

Encontrando Problema de Código COBOL

Programa

PERFORM UNTIL WS-FIM = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO WS-FIM
   END-READ

   PERFORM PROCESSA-CLIENTE

END-PERFORM

Pergunta

Qual risco de performance existe?


Solução

Se o arquivo possuir milhões de registros:

  • CPU elevada

  • I/O elevado

  • Tempo excessivo

O código não está errado.

Mas pode não escalar.

Performance depende do volume.


EXERCÍCIO 5

Escolhendo a Ferramenta

Cenário

Você precisa gerar:

10.000 usuários simultâneos

realizando chamadas HTTP.

Pergunta

Qual ferramenta apresentada seria mais indicada?


Solução

Apache JMeter.

Porque:

  • Open Source

  • Escalável

  • HTTP

  • HTTPS

  • REST

  • SOAP

Foi justamente a ferramenta mostrada na apresentação.


EXERCÍCIO 6

Teste de Resistência

Cenário

Uma aplicação funciona perfeitamente por:

30 minutos

Após:

8 horas

o consumo de memória cresce continuamente.

Pergunta

Qual tipo de teste identificou o problema?


Solução

Teste de Resistência.

Também chamado:

Soak Test

ou

Endurance Test.

Esse tipo de problema dificilmente aparece em testes rápidos.


EXERCÍCIO 7

Simulando Black Friday

Cenário

Usuários simultâneos:

09:00 → 1.000

09:01 → 10.000

09:02 → 15.000

09:03 → 1.000

Pergunta

Qual tipo de teste está sendo realizado?


Solução

Teste de Pico.

Objetivo:

Validar explosões repentinas de acesso.

Muito comum em:

  • Black Friday

  • PIX

  • Campanhas

  • Venda de ingressos


EXERCÍCIO 8

Análise de Mainframe

Cenário

Durante o teste:

CPU = 35%

Tempo de Resposta = 8 segundos

Pergunta

A CPU é o problema?


Solução

Não necessariamente.

Esse é um erro clássico.

Mesmo com CPU baixa podem existir:

  • Locks DB2

  • Espera de I/O

  • MQ congestionado

  • SQL ruim

  • Contenção CICS

CPU baixa não significa ambiente saudável.


EXERCÍCIO 9

Virtualização de Serviços

Cenário

O microsserviço precisa chamar:

  • Serviço A

  • Serviço B

  • Mainframe

Mas o Mainframe está indisponível.

Pergunta

Como continuar os testes?


Solução

Utilizando Virtualização.

Criamos respostas simuladas.

Exemplo:

{
  "conta":"12345",
  "saldo":"1500.00"
}

Assim os testes continuam sem depender do ambiente real.


EXERCÍCIO 10

Diagnóstico Completo

Cenário

O Grafana mostra:

CPU = 40%

Memória = 45%

Tempo Médio = 5 segundos

Dynatrace mostra:

API = 100 ms

CICS = 250 ms

DB2 = 4200 ms

Pergunta

Onde você investigaria primeiro?


Solução

DB2.

O banco responde por mais de 80% do tempo total.

Possíveis causas:

  • Full Scan

  • Índice ausente

  • Estatísticas desatualizadas

  • Lock

  • SQL mal otimizado


DESAFIO FINAL DO PADAWAN ☕💣

Imagine a seguinte arquitetura:

Mobile
   ↓
Apache
   ↓
WebSphere
   ↓
API
   ↓
MQ
   ↓
CICS
   ↓
COBOL
   ↓
DB2

Você recebe a reclamação:

"Consultar saldo está demorando 12 segundos."

Descreva:

  1. Quais ferramentas utilizaria?

  2. Quais métricas analisaria?

  3. Quais componentes investigaria primeiro?

  4. Como executaria um teste de carga?

  5. Como validaria a correção?


GABARITO ESPERADO

Ferramentas:

  • JMeter

  • Dynatrace

  • Grafana

  • OMEGAMON

  • RMF

  • SMF

Métricas:

  • CPU

  • TPS

  • Tempo Médio

  • P95

  • P99

  • I/O

  • MQ Depth

  • Tempo DB2

Investigação:

  1. Dynatrace

  2. DB2

  3. CICS

  4. MQ

  5. API

Teste:

  • 5.000 usuários

  • Ramp-up gradual

  • Monitoramento simultâneo

Validação:

Comparar:

Antes = 12 segundos

Depois = meta inferior a 2 segundos


Missão Extra Bellacosa Mainframe

Pegue um programa COBOL real do seu ambiente e responda:

  • Quantos READs ele executa?

  • Quantos WRITEs?

  • Quantos SELECTs DB2?

  • Qual o maior loop?

  • Qual o volume esperado?

  • Como ele se comportaria com 10 milhões de registros?

Se você conseguir responder essas perguntas, já começou a pensar como um profissional de Performance Mainframe e não apenas como um programador COBOL. ☕💣🚀


quarta-feira, 3 de janeiro de 2024

Descubra o que foi/é a Crise do Software.

Do que estou falando? Do caos atrás dos teclados, devido a instabilidade dos primeiros anos da computação com softwares imprecisos e os gastos milionários em CPDS. Esse termo foi cunhado na década de 70 do século passado e até hoje motiva muita discussão entre acadêmicos e profissionais.
Leia na InTEGRA

terça-feira, 2 de janeiro de 2024

☕💣🔥 O DIA EM QUE 10.000 USUÁRIOS DERRUBARAM UM COBOL QUE FUNCIONAVA PERFEITAMENTE — O GUIA DEFINITIVO DE TESTES DE PERFORMANCE PARA O PADAWAN DO MAINFRAME

Bellacosa Mainframe e a performance em mainframe


☕💣🔥 O DIA EM QUE 10.000 USUÁRIOS DERRUBARAM UM COBOL QUE FUNCIONAVA PERFEITAMENTE — O GUIA DEFINITIVO DE TESTES DE PERFORMANCE PARA O PADAWAN DO MAINFRAME

Existem algumas frases que assustam qualquer profissional experiente de Mainframe.

Uma delas é:

"Pode colocar em produção. Já testamos tudo."

A segunda é:

"Funcionou na minha máquina."

E a terceira, talvez a mais perigosa de todas:

"Performance a gente vê depois."

Se você é um jovem Padawan do COBOL, provavelmente acredita que o trabalho do programador termina quando o programa compila sem erros, passa nos testes funcionais e devolve o resultado correto.

Mas existe um mundo oculto além da lógica.

Um universo onde programas corretos derrubam bancos.

Onde APIs perfeitamente desenvolvidas travam durante a Black Friday.

Onde um SELECT aparentemente inocente consegue transformar uma aplicação inteira em um incêndio corporativo.

Esse universo chama-se Performance.

E hoje vamos conversar sobre um assunto que separa programadores comuns dos profissionais que sobrevivem décadas trabalhando em ambientes críticos.

Vamos falar sobre Testes de Performance.


A PRIMEIRA GRANDE LIÇÃO

Imagine que você criou um programa COBOL chamado CONSULTA-SALDO.

O programa recebe:

  • Agência

  • Conta

Consulta o DB2.

Retorna o saldo.

Você testa.

Funciona.

Seu colega testa.

Funciona.

O analista testa.

Funciona.

O gerente testa.

Funciona.

Todo mundo comemora.

O programa sobe para produção.

Cinco minutos depois:

O Internet Banking trava.

O aplicativo móvel trava.

O atendimento telefônico trava.

O gerente da agência liga desesperado.

E você pensa:

"Mas aqui funcionava..."

Sim.

Funcionava.

Para um usuário.

Produção não possui um usuário.

Produção possui milhares.

Essa é a primeira lição da performance.

Um sistema que funciona para uma pessoa não necessariamente funciona para dez mil.


O QUE É UM TESTE DE PERFORMANCE?

Muitos iniciantes acreditam que teste de performance significa medir velocidade.

Não é apenas isso.

Teste de performance é a arte de descobrir como um sistema se comporta quando submetido ao mundo real.

Queremos responder perguntas como:

  • Quantos usuários suporta?

  • Qual o tempo de resposta?

  • Onde está o gargalo?

  • Quanto de CPU consome?

  • Quanto de memória utiliza?

  • Quantas transações por segundo processa?

Na prática estamos tentando descobrir o limite antes que o cliente descubra primeiro.

Porque quando o cliente descobre primeiro, normalmente já existe uma crise instalada.


TESTES FUNCIONAIS X TESTES NÃO FUNCIONAIS

O material apresentado faz uma separação extremamente importante.

Testes funcionais verificam:

"O sistema faz o que deveria fazer?"

Exemplo:

Você informa uma conta.

O sistema retorna o saldo correto.

Teste aprovado.

Mas existe outra pergunta.

"O sistema continua fazendo isso quando dez mil usuários acessam simultaneamente?"

Essa pergunta pertence ao mundo dos testes não funcionais.

E é exatamente aqui que entra a performance.


O EXEMPLO DO AUTOMÓVEL

Imagine um carro.

Você gira a chave.

O motor liga.

Teste funcional aprovado.

Mas ainda faltam várias perguntas:

  • Qual a velocidade máxima?

  • Quanto consome?

  • Quanto suporta de carga?

  • Como se comporta em uma subida?

  • Como reage após cinco horas de viagem?

Essas perguntas representam os testes não funcionais.

O mesmo vale para sistemas.


O QUE REALMENTE DERRUBA SISTEMAS?

O Padawan normalmente pensa:

"Se estiver lento é porque falta CPU."

Nem sempre.

Na verdade, CPU costuma ser apenas um dos suspeitos.

Os verdadeiros vilões geralmente são:

  • SQL mal escrito

  • Índices ausentes

  • Locks excessivos

  • Filas MQ congestionadas

  • Chamada excessiva a serviços

  • Pool JDBC esgotado

  • Recursos compartilhados

Em outras palavras:

O problema normalmente não está onde você imagina.


TESTE DE CARGA

Este é o mais conhecido.

O objetivo é reproduzir o uso normal esperado.

Imagine:

O banco estima 5.000 usuários simultâneos.

Criamos então um cenário simulando exatamente esse volume.

A pergunta é simples:

"O sistema suporta?"

Se suporta, ótimo.

Se não suporta, ainda temos tempo para corrigir.

Muito melhor descobrir isso no laboratório do que no Jornal Nacional.


TESTE DE ESTRESSE

Aqui a conversa fica interessante.

Em vez de testar o limite esperado, ultrapassamos o limite.

Muito.

Se o ambiente foi projetado para 5.000 usuários:

Testamos 10.000.

15.000.

20.000.

Queremos descobrir:

Como ele falha?

Uma falha controlada é muito melhor que um colapso inesperado.


TESTE DE RESISTÊNCIA

Agora imagine uma maratona.

O sistema suporta 5.000 usuários.

Ótimo.

Mas por quanto tempo?

Uma hora?

Duas?

Dez?

Vinte e quatro?

O teste de resistência mantém carga constante durante longos períodos.

Muitas aplicações parecem saudáveis por trinta minutos.

Depois começam a consumir memória.

Depois mais memória.

Depois ainda mais memória.

Até morrerem lentamente.

É o famoso Memory Leak.


TESTE DE PICO

Imagine a abertura das vendas de um show.

Ou a Black Friday.

Ou o lançamento de um PIX promocional.

O tráfego explode.

O sistema precisa absorver esse impacto.

O teste de pico verifica exatamente isso.

O comportamento durante explosões repentinas.


O MUNDO HÍBRIDO

Antigamente era simples.

Usuário.

Tela.

Mainframe.

Fim.

Hoje não.

Hoje temos:

Aplicativo Mobile

Apache

WebSphere

API Gateway

Microsserviços

MQ

CICS

COBOL

DB2

Percebe o problema?

Se a tela demora cinco segundos, onde está o gargalo?

Pode estar em qualquer ponto da cadeia.

E é por isso que observabilidade se tornou tão importante.


APACHE JMETER

Se existe uma ferramenta que virou símbolo dos testes de carga modernos, essa ferramenta é o Apache JMeter.

Pense nele como um exército virtual.

Você configura usuários fictícios.

Esses usuários começam a executar operações.

Consultar saldo.

Fazer transferência.

Emitir extrato.

Pagar boleto.

E o sistema acredita que são usuários reais.

O JMeter consegue gerar milhares de acessos simultâneos.

É exatamente assim que simulamos produção sem colocar clientes reais em risco.


EXEMPLO PRÁTICO

Suponha uma API:

GET /saldo

Queremos simular:

5.000 usuários.

Criamos:

Thread Group

Usuários: 5000

Ramp-Up: 300 segundos

Loop: infinito

Agora adicionamos:

HTTP Request

Executamos.

Pronto.

Começamos a produzir carga.

Mas isso é apenas metade da história.


POR QUE APENAS GERAR CARGA NÃO BASTA?

Imagine um médico.

Ele mede sua pressão.

Mas ignora:

  • Frequência cardíaca

  • Oxigenação

  • Temperatura

Seria um diagnóstico completo?

Claro que não.

Com performance ocorre a mesma coisa.

Gerar carga é apenas o começo.

Precisamos observar o ambiente inteiro.


DYNATRACE

É aqui que entra o Dynatrace.

Pense nele como uma tomografia computadorizada da aplicação.

Ele acompanha cada requisição.

Cada chamada.

Cada serviço.

Cada banco de dados.

Cada microsserviço.

Cada transação.

Em vez de simplesmente dizer:

"Está lento."

Ele mostra:

"Está lento porque o Serviço X chamou o Serviço Y que executou uma consulta SQL custosa."

Agora existe informação para agir.


O SONHO DE TODO ANALISTA DE PERFORMANCE

Imagine um clique no aplicativo.

Consultar saldo.

Dynatrace exibe:

Frontend = 80 ms

API = 100 ms

Microsserviço = 120 ms

CICS = 800 ms

DB2 = 700 ms

Pronto.

Achamos o culpado.

Não existe mais adivinhação.


GRAFANA

Se Dynatrace é o médico.

Grafana é o painel da UTI.

Ele transforma números em gráficos.

Mostra:

  • CPU

  • Memória

  • Throughput

  • Erros

  • Tempo médio

  • Percentil 95

  • Percentil 99

E permite acompanhar tudo em tempo real.

Uma imagem muitas vezes vale mais que mil relatórios.


O QUE O MAINFRAME ENSINA SOBRE PERFORMANCE?

Muito antes da palavra observabilidade virar moda, o Mainframe já monitorava tudo.

E quando digo tudo, é tudo mesmo.

O z/OS nasceu para ambientes críticos.

Por isso existem ferramentas extremamente sofisticadas.


SMF

System Management Facility.

Registra praticamente tudo.

CPU.

I/O.

Transações.

Consumo.

Execução.

É o grande livro de registros do sistema.


RMF

Resource Measurement Facility.

Analisa comportamento dos recursos.

Ajuda a identificar gargalos.

Mostra utilização de processadores.

Filas.

Memória.

Dispositivos.


OMEGAMON

Uma das ferramentas mais famosas do universo IBM.

Monitora:

  • z/OS

  • CICS

  • DB2

  • MQ

Em tempo real.

Quando algo fica lento, geralmente ele é um dos primeiros lugares onde o especialista procura respostas.


O MAIOR ERRO DOS PROGRAMADORES INICIANTES

O Padawan costuma pensar:

"Meu programa executa rápido."

Mas rápido para quem?

Com qual volume?

Em qual horário?

Contra qual banco?

Com quantos registros?

Essas perguntas mudam tudo.

Um SELECT que retorna dez linhas parece maravilhoso.

O mesmo SELECT retornando dez milhões de linhas pode virar um desastre.


O CASO DO LOOP INOCENTE

Imagine:

PERFORM UNTIL EOF

READ ARQUIVO

PROCESSA

END-PERFORM

Parece simples.

Mas e se o arquivo possuir:

50 milhões de registros?

Agora o cenário muda.

Performance não depende apenas do código.

Depende dos dados.


PERFORMANCE É ARQUITETURA

Muitos acreditam que performance é responsabilidade exclusiva da infraestrutura.

Não é.

Também não é responsabilidade exclusiva do desenvolvedor.

Performance é responsabilidade de todos.

Arquitetura.

Banco.

Infraestrutura.

Rede.

Aplicação.

Integração.

Monitoramento.

Tudo influencia.


A MENTALIDADE DO PROFISSIONAL MADURO

O iniciante pergunta:

"Funciona?"

O profissional experiente pergunta:

"Funciona sob carga?"

O iniciante pergunta:

"Retornou o resultado?"

O profissional experiente pergunta:

"Quanto tempo demorou?"

O iniciante pergunta:

"Passou no teste?"

O profissional experiente pergunta:

"Qual foi o consumo?"

Essa mudança de mentalidade transforma carreiras.


A LIÇÃO FINAL

Ao longo dos anos vi programas COBOL sobreviverem décadas.

Vi sistemas processarem bilhões de transações.

Vi ambientes suportarem eventos gigantescos sem falhar.

E todos tinham algo em comum.

Performance não era tratada como um detalhe.

Era tratada como requisito.

Porque funcionalidades atraem usuários.

Mas é a performance que permite que eles permaneçam utilizando o sistema.

No fim das contas, um programa COBOL não é avaliado apenas pelo que faz.

Ele é avaliado pela velocidade, estabilidade e capacidade com que faz aquilo.

E essa é a diferença entre escrever código e construir sistemas capazes de sobreviver ao mundo real.

Bem-vindo ao próximo nível da sua jornada no Mainframe, jovem Padawan.

Agora você já sabe que compilar é apenas o começo.


segunda-feira, 1 de janeiro de 2024

COBOL : O mundo depende de um código de quase 65 anos que ninguém conhece mais

Bellacosa Mainframe e o cobol um codigo de 65 anos que continua na ativa

☕ Um Café no Bellacosa Mainframe

COBOL: O Mundo Depende de um Código de Quase 65 Anos que Ninguém Conhece Mais

Quando os programadores abriram o sarcófago do sistema legado, descobriram que o cadáver continuava processando a folha de pagamento

Naquela madrugada, o último programador COBOL da empresa recebeu uma ligação.

O sistema central havia parado.

Milhares de pagamentos estavam presos. As agências não conseguiam consultar contas. Os arquivos da compensação aguardavam processamento. Na sala de crise, dezenas de especialistas examinavam painéis modernos, APIs coloridas e dashboards brilhantes.

Mas ninguém sabia abrir o programa que controlava tudo.

O código havia sido escrito antes de muitos daqueles profissionais nascerem.

O telefone tocou novamente.

Do outro lado da linha, uma voz perguntou:

— Ainda existe alguém que entende COBOL?

O velho programador olhou para o terminal verde.

E respondeu:

— Existe. Mas vocês passaram trinta anos fingindo que não precisavam de nós.*


O monstro que deveria ter morrido

As revistas de terror dos anos 1950 adoravam histórias sobre criaturas que se recusavam a permanecer enterradas.

Um cientista encontrava um cadáver.

Aplicava eletricidade.

A criatura abria os olhos.

O laboratório pegava fogo.

E, na última página, o leitor descobria que o verdadeiro monstro não era o cadáver ressuscitado.

Era a arrogância do cientista.

A história do COBOL possui algo dessa atmosfera.

Durante décadas, consultorias, jornalistas, fornecedores e futuristas anunciaram sua morte. A cada nova geração tecnológica aparecia alguém disposto a escrever o epitáfio definitivo:

“Agora o COBOL será substituído.”

Vieram as linguagens estruturadas.

Vieram os computadores pessoais.

Vieram os sistemas cliente-servidor.

Veio a internet.

Vieram Java, .NET, os microsserviços, a computação em nuvem, os containers e a inteligência artificial.

O COBOL ouviu todos os discursos.

Depois voltou ao trabalho.

Em 2026, o COBOL não tem “quase 65 anos”. Sua criação começou em 1959, o que significa que sua história já atravessa aproximadamente 67 anos. A primeira versão da linguagem foi disponibilizada em 1960. Ela nasceu de um esforço colaborativo ligado ao CODASYL, inspirado parcialmente no FLOW-MATIC de Grace Hopper e voltado ao processamento comercial portátil entre diferentes computadores. (IBM)

Esse detalhe torna a história ainda mais impressionante.

O mundo não depende simplesmente de uma linguagem antiga.

Depende de uma linguagem criada quando:

  • computadores ocupavam salas inteiras;

  • programas eram frequentemente introduzidos por cartões perfurados;

  • não existiam microprocessadores;

  • a internet moderna não existia;

  • a chegada do homem à Lua ainda estava no futuro;

  • grande parte da população mundial jamais havia visto um computador.

E, apesar disso, inúmeros sistemas escritos ou evoluídos a partir dessa tradição continuam executando atividades críticas.

O cadáver não apenas abriu os olhos.

Ele continua fechando o movimento financeiro da madrugada.


Capítulo I — A cidade moderna construída sobre catacumbas

Imagine uma pessoa utilizando um aplicativo bancário.

Ela abre o celular.

Consulta o saldo.

Paga uma conta.

Faz uma transferência.

Compra uma passagem.

Contrata um seguro.

Recebe o salário.

Tudo parece novo.

A interface possui ícones modernos, animações suaves, reconhecimento biométrico e notificações instantâneas.

Mas a aparência do aplicativo não revela necessariamente onde a lógica central do negócio está sendo executada.

Por trás da tela pode existir uma cadeia semelhante a esta:

CLIENTE
   │
   ▼
APLICATIVO MÓVEL
   │
   ▼
API GATEWAY
   │
   ▼
SERVIÇO JAVA / MICROSSERVIÇO
   │
   ▼
IBM MQ OU OUTRA CAMADA DE INTEGRAÇÃO
   │
   ▼
CICS OU IMS
   │
   ▼
PROGRAMA COBOL
   │
   ▼
DB2, VSAM OU IMS DB
   │
   ▼
REGRA CENTRAL DO NEGÓCIO

O cliente enxerga apenas o andar mais recente do edifício.

O COBOL pode estar nas fundações.

Essa é a primeira grande revelação da nossa revista de horror: modernização visual não significa necessariamente substituição do núcleo transacional.

Uma empresa pode criar aplicativos modernos, APIs REST, portais Web, assistentes de inteligência artificial e experiências móveis sem remover imediatamente os programas que conhecem as regras mais profundas do negócio.

O aplicativo sabe exibir um botão.

O programa central sabe se aquela operação pode ou não acontecer.


Capítulo II — “Ninguém conhece mais” é verdade?

A frase é propositalmente assustadora:

“O mundo depende de um código que ninguém conhece mais.”

Mas ela precisa ser examinada com cuidado.

Não é verdade que literalmente ninguém conheça COBOL.

Existem milhares de profissionais, comunidades, empresas, universidades, cursos e iniciativas de capacitação. O Open Mainframe Project, por exemplo, mantém um curso aberto de programação COBOL com material educacional e experiências práticas utilizando ferramentas modernas. (Open Mainframe Project)

O problema real é mais sutil — e talvez mais perigoso.

Muitas organizações possuem sistemas que:

  • foram construídos durante décadas;

  • receberam alterações de centenas de profissionais;

  • incorporaram regras que não estão totalmente documentadas;

  • dependem de programas, arquivos, transações e rotinas interligadas;

  • perderam parte dos especialistas que acompanharam sua evolução;

  • são conhecidos profundamente por um grupo cada vez menor de pessoas.

Portanto, o horror não é a ausência total de programadores COBOL.

O horror é a perda do conhecimento contextual.

Conhecer a sintaxe da linguagem não significa conhecer o sistema.

Um estudante pode aprender rapidamente que este comando soma um valor:

ADD WS-VALOR TO WS-TOTAL.

Mas somente a experiência com a aplicação revelará:

  • de onde vem WS-VALOR;

  • o que representa WS-TOTAL;

  • quais exceções comerciais se aplicam;

  • se o valor está em reais ou centavos;

  • quais programas dependem desse resultado;

  • quais arquivos serão atualizados;

  • qual transação chamou o módulo;

  • quais controles de auditoria devem ser registrados;

  • o que acontece em caso de rollback;

  • quais consequências surgem se o cálculo estiver errado.

A sintaxe é o mapa da entrada.

O conhecimento do negócio é o mapa das catacumbas.


Capítulo III — O código não envelhece como um corpo humano

Existe uma ideia enganosa segundo a qual software envelhece exatamente como máquinas físicas.

Um automóvel de 1959 sofre ferrugem.

Peças se desgastam.

Mangueiras racham.

O motor perde compressão.

Código-fonte não envelhece dessa forma.

Uma instrução não se desgasta porque foi executada um bilhão de vezes.

Considere:

IF SALDO-DISPONIVEL >= VALOR-SOLICITADO
    PERFORM AUTORIZAR-OPERACAO
ELSE
    PERFORM RECUSAR-OPERACAO
END-IF.

Se essa regra está correta, testada e atende ao negócio, sua idade cronológica não a torna automaticamente defeituosa.

O que envelhece ao redor do código?

  • os requisitos;

  • as interfaces;

  • os formatos de dados;

  • os compiladores;

  • as práticas de desenvolvimento;

  • as dependências;

  • a documentação;

  • o conhecimento das equipes;

  • a facilidade de manutenção;

  • a arquitetura em que o programa está inserido.

Portanto, o problema não é simplesmente dizer:

“Este programa tem quarenta anos.”

A pergunta correta é:

“Este programa ainda atende ao negócio, pode ser mantido com segurança, está bem testado e possui uma arquitetura sustentável?”

Um programa antigo pode estar sólido.

Um microsserviço escrito na semana passada pode ser um desastre.

Juventude não é sinônimo de qualidade.

Idade não é sinônimo de obsolescência.


Capítulo IV — O segredo dentro do sarcófago: regras de negócio

Quando uma empresa observa milhões de linhas de COBOL, pode acreditar que está olhando apenas para código.

Não está.

Está olhando para história institucional condensada.

Dentro daqueles programas podem existir regras como:

  • cálculo de tarifas;

  • incidência de juros;

  • processamento de impostos;

  • critérios de elegibilidade;

  • limites de crédito;

  • períodos de carência;

  • contratos antigos;

  • exceções regulatórias;

  • tratamento de feriados;

  • arredondamentos financeiros;

  • regras específicas para determinados clientes;

  • mudanças legais acumuladas ao longo de décadas.

Imagine uma seguradora com um programa criado originalmente nos anos 1980.

Ao longo dos anos, ele foi alterado para acomodar:

1984 — nova categoria de contrato
1988 — mudança constitucional
1994 — nova moeda
1999 — alteração tributária
2002 — produto adicional
2008 — nova regra de risco
2015 — adequação regulatória
2020 — operação emergencial
2024 — integração com API
2026 — análise assistida por IA

Ao final desse processo, o sistema não contém apenas algoritmos.

Ele contém a arqueologia da empresa.

Substituí-lo exige mais do que converter comandos de uma linguagem para outra.

É necessário descobrir o significado de cada regra, inclusive daquelas que ninguém mais se lembra de ter solicitado.


Capítulo V — O programa que ninguém ousava apagar

Em algum ponto de toda grande aplicação existe uma rotina semelhante à sala proibida de uma mansão.

Todos sabem que ela existe.

Ninguém gosta de alterá-la.

A documentação diz apenas:

“Não modificar sem consultar a equipe responsável.”

O problema é que a equipe responsável deixou de existir em 1998.

O programa continua sendo executado.

Talvez ele tenha um nome como:

PGMCL093

Ninguém sabe exatamente por que o número 93 foi escolhido.

Dentro dele aparece:

IF WS-TIPO-CLIENTE = '7'
   AND WS-CODIGO-ESPECIAL NOT = 'X'
   AND WS-DATA-BASE < 19940701
      MOVE 'S' TO WS-ISENCAO
END-IF.

O jovem programador pergunta:

— Por que clientes do tipo 7 recebem isenção antes de 1º de julho de 1994?

Silêncio.

Alguém responde:

— Sempre funcionou assim.

Esse é o momento em que a manutenção deixa de ser apenas programação e se transforma em investigação.

O código apresenta o que.

Nem sempre explica o porquê.

Remover aquela condição pode parecer uma limpeza.

Mas talvez ela proteja contratos antigos, decisões judiciais, benefícios adquiridos ou registros históricos.

Uma linha aparentemente inútil pode ser a última testemunha de uma regra que a organização esqueceu.


Capítulo VI — A maldição da reescrita total

Quando executivos encontram sistemas antigos, uma ideia surge como o plano perfeito do cientista ambicioso:

“Vamos reescrever tudo do zero.”

Em uma apresentação, o plano parece impecável:

COBOL ANTIGO
     ↓
ANÁLISE AUTOMÁTICA
     ↓
CONVERSÃO
     ↓
JAVA, C# OU NUVEM
     ↓
PROBLEMA RESOLVIDO

Mas sistemas críticos não são simples blocos de texto.

Uma reescrita precisa preservar:

  • resultados;

  • regras;

  • arredondamentos;

  • formatos;

  • tempos de processamento;

  • integrações;

  • sequências de atualização;

  • tratamento de falhas;

  • segurança;

  • auditoria;

  • recuperação;

  • compatibilidade com dados históricos;

  • comportamento em situações excepcionais.

Considere um cálculo financeiro:

COMPUTE VALOR-LIQUIDO ROUNDED =
        VALOR-BRUTO - TAXA - IMPOSTO.

Uma tradução sintaticamente correta para outra linguagem não garante comportamento idêntico.

Pode haver diferenças em:

  • representação decimal;

  • precisão;

  • arredondamento;

  • overflow;

  • tratamento de sinal;

  • campos compactados;

  • conversão de caracteres;

  • ordenação;

  • datas;

  • valores ausentes.

O programa convertido compila.

Os testes básicos passam.

Mas uma diferença de um centavo aparece somente em determinada combinação de contrato, data e categoria.

Multiplique um centavo por milhões de operações.

O pequeno fantasma ganha corpo.


Capítulo VII — COBOL não trabalha sozinho

Outro erro comum é imaginar que preservar profissionais COBOL resolve todo o problema.

Não resolve.

Uma aplicação Mainframe costuma depender de uma stack inteira:

COBOL
  ├── JCL
  ├── CICS
  ├── IMS
  ├── Db2
  ├── VSAM
  ├── IBM MQ
  ├── RACF
  ├── SORT
  ├── JES2
  ├── SDSF
  ├── SMF
  ├── WLM
  ├── DFSMS
  └── z/OS

O programador pode dominar a lógica COBOL e ainda assim precisar entender:

  • como o job foi submetido;

  • qual dataset foi utilizado;

  • qual versão do módulo está carregada;

  • qual package do Db2 foi associado;

  • qual plano está executando;

  • qual fila recebeu a mensagem;

  • qual transação CICS iniciou o programa;

  • qual autorização RACF foi negada;

  • qual step retornou código diferente de zero;

  • qual arquivo VSAM sofreu contenção;

  • qual política do WLM alterou a prioridade;

  • qual mudança de produção introduziu o problema.

COBOL é um cômodo da mansão.

O profissional precisa conhecer os corredores.


Capítulo VIII — O mundo depende do COBOL ou das aplicações?

Aqui precisamos separar a propaganda da engenharia.

O mundo não depende de cada programa COBOL existente.

Há programas desnecessários, duplicados, mal projetados, pouco utilizados ou prontos para aposentadoria.

Também existem sistemas COBOL que podem ser substituídos com segurança.

A afirmação mais correta é:

Partes importantes da economia e da administração corporativa ainda dependem de aplicações críticas construídas, mantidas ou evoluídas em COBOL.

A própria IBM descreve o COBOL como uma linguagem orientada aos negócios utilizada em operações econômicas cotidianas invisíveis e em processos de missão crítica. O Enterprise COBOL para z/OS continua sendo oferecido como compilador empresarial destinado à modernização de aplicações críticas. (@ibmdeveloper)

Essa distinção é importante.

Não devemos transformar COBOL em religião.

Também não devemos tratá-lo como sucata apenas por causa de sua idade.

A decisão precisa considerar:

  • custo;

  • risco;

  • criticidade;

  • capacidade de manutenção;

  • estratégia empresarial;

  • disponibilidade de profissionais;

  • qualidade dos testes;

  • acoplamento;

  • volume de processamento;

  • metas de modernização.

Em alguns casos, manter é sensato.

Em outros, modernizar gradualmente é melhor.

Em certos sistemas, substituir será necessário.

O erro está nas decisões automáticas.


Capítulo IX — Por que as novas gerações não aprenderam?

O desaparecimento gradual do conhecimento COBOL não aconteceu por acidente.

Durante anos, muitos estudantes ouviram:

“Não aprenda isso. Está morrendo.”

As universidades reduziram o espaço dedicado ao processamento corporativo clássico.

Os cursos rápidos preferiram tecnologias que produziam interfaces visuais em poucas aulas.

As empresas deixaram de formar profissionais internamente.

Especialistas experientes se aposentaram.

Documentações permaneceram desatualizadas.

Projetos de substituição foram anunciados, adiados e novamente anunciados.

O resultado foi um paradoxo:

EMPRESAS DIZEM QUE COBOL NÃO TEM FUTURO
                  +
EMPRESAS CONTINUAM EXECUTANDO COBOL
                  +
EMPRESAS DEIXAM DE TREINAR PESSOAS
                  =
FALTA DE PROFISSIONAIS

A escassez não prova que a linguagem seja impossível de aprender.

Prova que o pipeline de formação foi negligenciado.

Nenhuma tecnologia sobrevive apenas por possuir bons compiladores.

Ela precisa de pessoas.


Capítulo X — O último programador não é um feiticeiro

Existe uma tendência perigosa de transformar o especialista veterano em figura mística.

Ele é chamado quando:

  • o fechamento falha;

  • o arquivo não fecha;

  • o saldo fica inconsistente;

  • o batch ultrapassa a janela;

  • uma transação recebe ABEND;

  • ninguém entende determinada regra.

O veterano observa três mensagens, consulta um dump e identifica o problema.

Todos ficam impressionados.

Mas aquilo que parece magia geralmente é conhecimento acumulado:

  • convenções de nomes;

  • histórico de incidentes;

  • padrões recorrentes;

  • arquitetura;

  • regras comerciais;

  • relações entre programas;

  • comportamento do ambiente.

O objetivo de uma organização madura não deve ser manter um feiticeiro indispensável.

Deve ser transformar o conhecimento individual em capacidade coletiva.

Isso exige:

  • documentação;

  • revisão de código;

  • mentoria;

  • programação em pares;

  • mapas de dependências;

  • inventário de aplicações;

  • testes automatizados;

  • gravação de sessões técnicas;

  • rotação de responsabilidades;

  • comunidades internas;

  • formação contínua.

Quando apenas uma pessoa sabe como o sistema funciona, o problema não é o COBOL.

É a governança.


Capítulo XI — Inteligência artificial: o novo caçador de fantasmas

A inteligência artificial pode ajudar a investigar grandes bases COBOL.

Ela pode apoiar tarefas como:

  • explicar trechos de código;

  • resumir parágrafos;

  • sugerir documentação;

  • identificar dependências;

  • gerar casos de teste;

  • localizar padrões repetidos;

  • auxiliar conversões;

  • relacionar programas e copybooks;

  • produzir diagramas;

  • acelerar a integração de novos profissionais.

Mas existe uma diferença entre explicar a estrutura de uma rotina e compreender completamente sua intenção empresarial.

Uma IA pode observar:

IF DATA-CONTRATO < DATA-CORTE
    MOVE TAXA-ANTIGA TO TAXA-APLICADA
ELSE
    MOVE TAXA-NOVA TO TAXA-APLICADA
END-IF.

Ela provavelmente explicará:

“O programa seleciona uma taxa com base na data do contrato.”

Correto.

Mas ainda restam perguntas:

  • quem definiu a data de corte?

  • a regra decorre de uma lei?

  • existem exceções?

  • contratos renegociados mantêm a taxa antiga?

  • a data está em calendário local?

  • o comportamento foi validado pelo setor jurídico?

  • outros programas repetem a mesma lógica?

A IA acende uma lanterna poderosa.

Ela não substitui automaticamente o mapa do castelo.


Capítulo XII — Como impedir que o conhecimento desapareça

Uma organização que depende de COBOL precisa tratar conhecimento como ativo estratégico.

1. Inventariar

Descobrir:

  • quantos programas existem;

  • quais são executados;

  • quais estão abandonados;

  • quais são críticos;

  • quais copybooks compartilham;

  • quais tabelas e arquivos acessam;

  • quais sistemas os chamam.

2. Mapear dependências

Criar relações como:

JOB FATURA01
   └── STEP010
       └── PROGRAMA FATC100
           ├── COPYBOOK CLI001
           ├── DB2 TABELA CLIENTE
           ├── DB2 TABELA FATURA
           └── MQ FILA NOTIFICACAO

3. Documentar regras

Não apenas:

“Este parágrafo calcula juros.”

Mas:

“Calcula juros para contratos anteriores à mudança regulatória de determinada data, preservando a metodologia prevista no produto original.”

4. Automatizar testes

Antes de alterar um programa, registrar seu comportamento esperado.

Casos comuns.

Casos extremos.

Valores nulos.

Datas críticas.

Limites.

Erros.

Reprocessamentos.

5. Formar sucessores

Um especialista sem aprendiz representa conhecimento com data de expiração.

6. Modernizar ferramentas

COBOL pode ser desenvolvido com:

  • editores modernos;

  • Git;

  • pipelines;

  • testes automatizados;

  • análise estática;

  • integração contínua;

  • APIs;

  • observabilidade.

Preservar a linguagem não exige preservar todos os métodos de trabalho de 1975.


Capítulo XIII — O estudante diante da porta proibida

Para um jovem universitário, COBOL pode parecer uma escolha estranha.

Seus colegas falam sobre:

  • inteligência artificial;

  • Python;

  • aplicações móveis;

  • jogos;

  • realidade virtual;

  • startups;

  • nuvem.

Então ele encontra uma vaga mencionando:

COBOL
JCL
CICS
DB2
VSAM
IBM MQ
z/OS

Parece uma mensagem enviada por outra época.

Mas ali existe uma oportunidade rara.

Aprender COBOL pode ensinar algo que muitos cursos rápidos não mostram:

  • processamento de grandes volumes;

  • precisão decimal;

  • estruturas de registros;

  • transações;

  • integridade;

  • recuperação;

  • batch;

  • segurança;

  • desempenho;

  • sistemas de missão crítica;

  • responsabilidade operacional.

O estudante não precisa abandonar tecnologias modernas.

Ele pode se tornar a ponte.

COBOL + APIs
COBOL + JAVA
COBOL + PYTHON
COBOL + CLOUD
COBOL + DEVOPS
COBOL + IA

O profissional mais valioso não será necessariamente aquele que vive apenas no passado.

Será aquele capaz de conectar décadas diferentes sem destruir o que mantém a empresa funcionando.


Arquivo secreto: três mitos enterrados no cemitério

Mito 1 — “COBOL é lento”

A velocidade de uma aplicação depende de diversos fatores:

  • algoritmo;

  • acesso a dados;

  • compilação;

  • arquitetura;

  • I/O;

  • SQL;

  • volume;

  • configuração;

  • contenção.

Uma aplicação mal projetada pode ser lenta em qualquer linguagem.

Mito 2 — “Migrar COBOL significa traduzir comandos”

Não.

Migrar envolve reconstruir comportamento, integrações, dados, operações, segurança e conhecimento de negócio.

Mito 3 — “Manter COBOL significa rejeitar inovação”

Também não.

Uma aplicação COBOL pode ser:

  • exposta por APIs;

  • integrada com eventos;

  • incluída em CI/CD;

  • observada por ferramentas modernas;

  • acessada por aplicações móveis;

  • conectada a serviços de IA.

Modernização não é sinônimo obrigatório de reescrita.


Easter egg — A lápide que errou o enterro

Durante o desenvolvimento do COBOL, o integrante Howard Bromberg produziu uma lápide humorística, antecipando que a linguagem não teria futuro. A peça tornou-se parte da coleção do Computer History Museum. O epitáfio falhou de maneira espetacular: décadas depois, COBOL continuava presente em sistemas críticos. (CHM)

Talvez essa seja a maior piada interna da história da programação.

A linguagem recebeu uma lápide antes mesmo de viver plenamente.

Depois sobreviveu a muitos dos sistemas que deveriam substituí-la.


Conclusão — O verdadeiro horror não está no código

Na última página da revista, a equipe finalmente desce ao subsolo do edifício.

Encontra armários, diagramas, fitas, manuais e milhares de programas.

No centro da sala existe um terminal ainda ligado.

Na tela, uma mensagem:

PROCESSAMENTO CONCLUÍDO COM SUCESSO
RETURN CODE = 0000

O jovem programador se aproxima.

— Então o sistema ainda funciona?

O veterano responde:

— Funciona.

— E por que todos estão com medo?

O velho profissional aponta para uma estante vazia.

— Porque ali ficava a documentação.

O terror do COBOL não está em sua idade.

Não está em sua sintaxe.

Não está nas colunas antigas, nos parágrafos ou nos nomes escritos em letras maiúsculas.

O verdadeiro horror nasce quando uma sociedade depende de sistemas que conhece apenas superficialmente.

Nasce quando empresas mantêm aplicações críticas, mas deixam de formar pessoas.

Quando substituem documentação por memória individual.

Quando confundem interface moderna com arquitetura moderna.

Quando acreditam que uma ferramenta automática pode reconstruir décadas de regras empresariais sem investigação, testes e participação humana.

O COBOL começou a ser desenvolvido em 1959 e continua sendo utilizado porque resolveu — e ainda resolve — problemas fundamentais do processamento corporativo. (IBM)

Ele não é um morto-vivo.

É uma linguagem que envelheceu junto com as instituições que ajudou a construir.

O problema nunca foi o código antigo.

O problema é o conhecimento que permitimos desaparecer ao redor dele.

Quando o último especialista apagar a luz e fechar a porta do CPD, o sistema provavelmente continuará funcionando.

Por algum tempo.

Executará jobs.

Atualizará contas.

Processará contratos.

Calculará valores.

Responderá transações.

Até a noite em que algo inesperado acontecer.

Então os telefones tocarão.

As telas ficarão vermelhas.

A sala de crise será aberta.

E alguém fará a pergunta que nenhuma empresa deveria esperar para responder:

“Quem ainda conhece este código?”

Do fundo da Torre Invisível, talvez venha apenas o ruído dos discos, o brilho verde de um terminal abandonado e uma última mensagem piscando na escuridão:

PROGRAMMER NOT FOUND.

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


Uma parcela alarmantemente grande dos sistemas empresariais e financeiros do mundo funciona em COBOL, e apenas uma pequena comunidade de programadores sabe disso. A IBM acha que o Watson pode ajudar, mas não é garantido.
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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