Bellacosa Mainframe e o Gravity do Santander

☕🚀 PADAWAN COBOL, O QUE É O GRAVITY DO SANTANDER?

"Imagine que alguém pegasse décadas de COBOL, CICS, DB2 e Mainframe, colocasse tudo dentro de um foguete espacial e o lançasse rumo à nuvem. Esse foguete atende pelo nome de Gravity."

---

📖 Sinopse

O Gravity é a plataforma tecnológica criada pelo Banco Santander para modernizar seu núcleo bancário (Core Banking).

Não é apenas um software.

Não é apenas uma migração para nuvem.

É uma estratégia completa para permitir que sistemas bancários gigantescos deixem de depender exclusivamente de ambientes tradicionais de mainframe e passem a operar em arquitetura cloud moderna.

O objetivo é simples:

Fazer um banco de 180 milhões de clientes funcionar com a velocidade de uma fintech sem perder a robustez de um mainframe.

---

🏛 História

Durante décadas o Santander construiu seus sistemas bancários sobre tecnologias tradicionais:

• COBOL

• Mainframe IBM

• Bancos relacionais

• Sistemas batch

• Processamento transacional

Essas plataformas eram extremamente confiáveis.

O problema?

O mercado mudou.

Clientes passaram a exigir:

• PIX instantâneo

• Aplicativos móveis

• APIs

• Open Finance

• Integração em tempo real

O modelo tradicional começou a limitar a velocidade de inovação.

Por volta da década de 2010 o Santander iniciou um programa de transformação que culminou no Gravity.

Em 2022 o projeto ganhou notoriedade internacional quando o Google anunciou o uso da tecnologia por trás do Gravity no serviço Dual Run.

Em 2025 o Santander informou que mais de 90% de sua infraestrutura tecnológica já estava em nuvem.

---

Bellacosa Mainframe visuliza o Gravity

🚀 O que é o Gravity?

Pense nele como um:

Tradutor Universal Bancário

Ele permite que aplicações que antes viviam exclusivamente no mainframe possam operar em ambiente cloud.

Sua função principal é:

• Modernizar o Core Banking

• Executar processamento distribuído

• Operar em nuvem

• Facilitar migrações

• Reduzir dependência de hardware especializado

---

🏦 O que é Core Banking?

Padawan...

Quando você consulta saldo no aplicativo...

Quando faz um PIX...

Quando recebe salário...

Quando solicita empréstimo...

Tudo isso acaba passando pelo Core Banking.

É o coração do banco.

Sem ele:

💀 nada funciona.

---

⚙ Como funciona?

O segredo do Gravity é o conceito chamado:

Dual Run

Imagine duas locomotivas andando lado a lado.

Locomotiva 1

Mainframe

• COBOL

• CICS

• DB2

Locomotiva 2

Cloud

• Microservices

• Containers

• APIs

Durante um período ambas executam simultaneamente.

Os resultados são comparados.

Se tudo bater:

✅ a aplicação pode ser movida para nuvem.

Isso reduz enormemente o risco da migração.

---

🖥 Tecnologias Envolvidas

Embora o Santander não revele todos os detalhes internos, sabe-se que o projeto envolve:

Cloud Computing

• Google Cloud

• Kubernetes

• Containers

APIs

• REST

• Open Banking

DevOps

• CI/CD

• Deploy automatizado

Data

• Processamento distribuído

• Streaming

Engenharia Moderna

• Observabilidade

• Telemetria

• Monitoramento

---

☕ O que acontece com o COBOL?

A pergunta de um milhão de dólares.

Muitos imaginam:

"Migrar para nuvem significa jogar COBOL fora."

Errado.

O próprio Santander declarou que muitos dos profissionais que criaram os sistemas de mainframe há 20 anos participam do Gravity.

Isso revela algo importante:

O conhecimento de negócio continua valendo ouro.

A linguagem muda.

O negócio permanece.

---

🔥 Pontos Fortes

Escalabilidade

Pode crescer rapidamente conforme a demanda.

---

Agilidade

Novas funcionalidades podem ser liberadas em horas.

Antes levavam dias ou semanas.

---

Menor Dependência de Hardware

Não exige expansão física de datacenters.

---

Automação

Reduz atividades operacionais repetitivas.

---

Modernização

Facilita integração com:

• APIs

• Open Finance

• IA

• Aplicativos móveis

---

💣 Pontos Fracos

Complexidade

Migrar um banco não é igual migrar um site.

É extremamente complexo.

---

Custos Elevados

Projetos dessa magnitude custam bilhões.

---

Dependência da Cloud

O banco passa a depender mais dos provedores de nuvem.

---

Escassez de Talentos

Encontrar profissionais que entendam:

• Mainframe

• Cloud

• DevOps

• Negócio bancário

não é simples.

---

🤔 Curiosidades

Curiosidade 1

O Gravity não foi comprado.

Foi desenvolvido pelo próprio Santander.

---

Curiosidade 2

O Google aproveitou conceitos da tecnologia para construir o Dual Run.

---

Curiosidade 3

Poucos bancos do tamanho do Santander tentaram uma transformação tão profunda.

---

Curiosidade 4

O conhecimento dos especialistas de mainframe foi considerado fundamental.

---

Curiosidade 5

Mais de 1 trilhão de operações técnicas por ano deverão ser executadas através da plataforma.

---

🌎 Impacto no Mercado

O Gravity é observado por:

• BBVA

• HSBC

• ING

• Barclays

• Deutsche Bank

• Itaú

• Bradesco

• Banco do Brasil

Todos enfrentam o mesmo desafio:

Como modernizar décadas de sistemas sem parar o banco?

---

👨‍💻 O que muda para o Desenvolvedor COBOL?

Antigamente:

COBOL
 ↓
CICS
 ↓
DB2
 ↓
Produção

Agora:

COBOL
 ↓
API
 ↓
Container
 ↓
Cloud
 ↓
Observabilidade
 ↓
Produção

O desenvolvedor moderno precisa entender:

• APIs

• JSON

• Git

• DevOps

• Cloud

• Segurança

---

⚠ Riscos para a Carreira

Se o profissional pensar:

"Vou aprender apenas COBOL e parar no tempo."

Existe risco.

O mercado quer cada vez mais:

Profissionais Híbridos

• COBOL + Cloud

• COBOL + APIs

• COBOL + Java

• COBOL + Python

• COBOL + DevOps

O especialista puro continua existindo.

Mas o híbrido tende a ser mais valorizado.

---

🎯 Vantagens para o Profissional Mainframe

O Padawan costuma acreditar que:

"Cloud vai matar o Mainframe."

Na prática acontece o contrário.

Quem entende:

• Batch

• Integridade transacional

• Recuperação

• Consistência

• Alta disponibilidade

possui conhecimentos raros que muitos profissionais cloud nunca estudaram.

Por isso diversos arquitetos de transformação digital vieram do mundo mainframe.

---

☕ Resumo Bellacosa Mainframe

Gravity em uma frase

"É a ponte construída pelo Santander para levar décadas de conhecimento em COBOL e Mainframe para a nuvem sem destruir aquilo que fez o banco funcionar durante gerações."

O Padawan precisa aprender?

✅ Sim.

Precisa abandonar COBOL?

❌ Não.

Precisa aprender cloud?

✅ Sim.

O Mainframe vai acabar amanhã?

❌ Não.

O mercado está mudando?

✅ Muito rápido.

Quem será mais valorizado?

🚀 O profissional que souber conversar tanto com o veterano de JCL quanto com o engenheiro de Kubernetes.

Porque o futuro não é COBOL contra Cloud.

O futuro é COBOL + Cloud, e o Gravity talvez seja um dos maiores exemplos dessa convergência já vistos na indústria bancária mundial. ☕🔥🚀🏦💻

Gravity https://www.santander.com/en/press-room/press-releases/2025/06/santander-completes-the-digitalization-of-its-technology-infrastructure-in-spain-with-the-deployment-of-gravity

Gravity Power https://www.jornalintegracao.com/noticia/40336/revista-britanica-the-banker-elege-o-banco-mais-inovador-do-mundo

Inovação https://jornaleconomico.sapo.pt/noticias/santander-escolhido-como-mais-inovador-por-causa-da-plataforma-gravity/

Gravity - https://sapo.pt/artigo/santander-torna-se-o-primeiro-grande-banco-ocidental-a-operar-100-na-cloud-6865c821bf6e672c9d4acb54

Gravity - https://thedigitalbanker.com/santander-passes-key-milestone-in-its-transformation-after-migrating-its-cib-banking-platform-to-the-cloud/

Bellacosa Mainframe e tenta entender a razao do Cobol nao existir fora do Mainframe

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?

Quando alguém fala em COBOL, a maioria das pessoas imediatamente imagina um enorme IBM Z, salas refrigeradas, bancos, seguradoras e sistemas que movimentam bilhões de dólares por dia.

Mas existe uma curiosidade que poucos conhecem:

O COBOL nunca foi exclusivo do Mainframe.

Durante décadas existiram versões para:

• MS-DOS

• Windows

• Linux

• Unix

• AIX

• HP-UX

• Solaris

• AS/400

• VMS

• até mesmo Raspberry Pi atualmente

Empresas como Micro Focus, Fujitsu, RM/COBOL, Acucobol, GNUCobol e outras investiram milhões tentando popularizar o COBOL fora do universo IBM.

Mesmo assim, quando ouvimos a palavra COBOL em 2026, quase todo mundo associa imediatamente ao Mainframe.

A pergunta é inevitável:

Por que isso aconteceu?

Por que Java virou universal?

Por que C conquistou sistemas operacionais?

Por que Python dominou a automação?

E por que COBOL permaneceu praticamente "preso" ao Mainframe?

A resposta envolve tecnologia, mercado, marketing, história, cultura corporativa e até psicologia.

Pegue seu café.

Hoje vamos mergulhar em uma das maiores curiosidades da história da computação.

---

O MAIOR MITO SOBRE COBOL

Existe uma crença popular:

"COBOL só funciona em Mainframe."

Isso nunca foi verdade.

Desde os anos 70 já existiam compiladores COBOL para minicomputadores.

Nos anos 80 surgiram versões para:

• DOS

• Unix

• VAX/VMS

Nos anos 90:

• Windows

• OS/2

• Linux

Nos anos 2000:

• .NET

• JVM

• Web Services

Tecnicamente falando, o COBOL poderia ter seguido praticamente qualquer caminho.

Mas não seguiu.

---

O PROBLEMA NUNCA FOI A LINGUAGEM

Essa é a primeira coisa que surpreende muita gente.

O COBOL não fracassou fora do Mainframe porque era ruim.

Na verdade ele possuía diversas vantagens.

Extremamente legível

Exemplo:

IF SALDO-CONTA IS GREATER THAN LIMITE-CREDITO
   DISPLAY "LIMITE EXCEDIDO"
END-IF

Até alguém sem conhecimento profundo consegue entender.

---

Excelente para regras de negócio

Bancos adoram COBOL porque ele descreve regras empresariais com clareza.

Por exemplo:

COMPUTE JUROS =
    VALOR * TAXA / 100

Não existe mistério.

---

Forte manipulação de registros

Antes dos bancos relacionais se popularizarem, isso era ouro.

---

Precisão decimal

Enquanto várias linguagens sofriam com arredondamentos, COBOL nasceu para dinheiro.

E dinheiro não aceita erro.

---

O VERDADEIRO PROBLEMA: O COBOL NASCEU PARA NEGÓCIOS

A palavra COBOL significa:

Common Business Oriented Language

Observe:

Não é:

• Common Game Language

• Common Scientific Language

• Common Internet Language

É:

Business.

Negócios.

Empresas.

Contabilidade.

Folha de pagamento.

Seguros.

Finanças.

Faturamento.

Desde o nascimento, ele tinha um propósito extremamente específico.

---

ENQUANTO ISSO, O MUNDO MUDOU

Na década de 1960 isso era perfeito.

Mas nas décadas seguintes surgiram novos mercados.

---

Computação científica

FORTRAN dominou.

---

Sistemas operacionais

C dominou.

---

Inteligência Artificial

LISP dominou inicialmente.

---

Aplicações gráficas

C++

---

Internet

Java

PHP

Perl

JavaScript

---

Ciência de Dados

Python

R

---

O mundo começou a exigir coisas que nunca foram prioridade para o COBOL.

---

O COBOL NÃO FOI FEITO PARA SER "COOL"

Aqui existe um fator psicológico interessantíssimo.

Pense nos heróis da programação:

• Linus Torvalds → C

• Guido van Rossum → Python

• Bjarne Stroustrup → C++

• James Gosling → Java

Agora pense em COBOL.

A maioria das pessoas nem sabe quem foi Grace Hopper.

Grace Hopper ajudou a criar conceitos fundamentais que levariam ao COBOL.

Mas a linguagem nunca foi vendida como algo revolucionário.

Ela foi vendida como algo:

• estável

• corporativo

• burocrático

E isso afasta jovens desenvolvedores.

---

O EFEITO "BANCO"

Imagine dois anúncios.

Linguagem A

"Crie jogos incríveis!"

Linguagem B

"Automatize cálculos atuariais."

Qual parece mais divertida?

Foi exatamente isso que aconteceu.

COBOL ficou associado a:

• bancos

• seguradoras

• governos

• sistemas legados

Enquanto outras linguagens ficaram associadas à inovação.

---

O ERRO DE MARKETING MAIS CARO DA HISTÓRIA

Durante os anos 80 e 90, universidades começaram a ensinar:

• C

• Pascal

• C++

• Java

COBOL desapareceu dos cursos.

A consequência foi devastadora.

Menos estudantes.

Menos projetos.

Menos comunidade.

Menos livros.

Menos ferramentas.

Menos conteúdo.

Menos adoção.

Criou-se um círculo vicioso.

---

O PROBLEMA DAS FERRAMENTAS

Vamos ser honestos.

Nos anos 90 era muito mais divertido programar Visual Basic do que COBOL.

Visual Basic tinha:

• botões

• janelas

• eventos

Você arrastava componentes.

Tudo aparecia na tela.

COBOL continuava focado em:

OPEN INPUT CLIENTES
READ CLIENTES

O apelo visual era praticamente zero.

---

O MUNDO APAIXONOU-SE POR INTERFACES GRÁFICAS

Quando o Windows explodiu, surgiu uma nova geração de desenvolvedores.

Eles queriam construir:

• telas

• jogos

• multimídia

COBOL não era o candidato natural.

---

O MAINFRAME PROTEGEU O COBOL

Aqui está a maior ironia.

O Mainframe foi simultaneamente:

• a maior força do COBOL

• e sua maior prisão

Sem Mainframe talvez COBOL tivesse desaparecido.

Mas graças ao Mainframe ele sobreviveu.

Por outro lado, o sucesso no Mainframe reduziu o incentivo para conquistar outros mercados.

Os bancos já estavam satisfeitos.

Por que mudar?

---

O FATOR ECONÔMICO

Imagine um banco.

Você possui:

• 50 milhões de linhas COBOL

• 40 anos de história

• bilhões movimentados diariamente

Qual decisão é mais segura?

Opção A

Migrar tudo.

Opção B

Continuar usando COBOL.

A resposta é óbvia.

---

O EFEITO "SE ESTÁ FUNCIONANDO, NÃO MEXA"

Poucas linguagens tiveram a sorte de trabalhar em ambientes tão conservadores.

Um sistema bancário precisa:

• estabilidade

• previsibilidade

• auditoria

Não precisa ser moderno.

Precisa funcionar.

E COBOL funciona.

Muito bem.

---

A CHEGADA DA INTERNET

Nos anos 90 surgiu a Web.

Foi uma nova corrida do ouro.

Linguagens correram para conquistar esse território.

• Java

• PHP

• Perl

• ASP

COBOL chegou depois.

Muito depois.

Quando chegou, o mercado já tinha donos.

---

O PROBLEMA DA COMUNIDADE

Uma linguagem vive ou morre pela comunidade.

Python possui:

• milhões de usuários

• milhares de bibliotecas

• eventos globais

Java possui ecossistema gigantesco.

COBOL sempre teve uma comunidade menor.

Extremamente qualificada.

Mas menor.

---

O FATOR OPEN SOURCE

Outro golpe importante.

O movimento Open Source impulsionou:

• Linux

• Python

• PHP

• Perl

COBOL permaneceu muito ligado ao mundo corporativo.

Licenças caras.

Compiladores pagos.

Ferramentas empresariais.

Isso limitou sua expansão.

---

MAS EXISTE COBOL OPEN SOURCE

Hoje existe o fantástico:

GNUCobol

GnuCOBOL Official Project

Ele compila COBOL para C e roda em:

• Linux

• Windows

• macOS

Mostrando que o COBOL continua vivo fora do Mainframe.

---

O COBOL É LENTO?

Outro mito.

Na verdade, muitas implementações COBOL são extremamente rápidas.

Especialmente em processamento transacional.

O problema nunca foi desempenho.

---

O COBOL É ANTIGO DEMAIS?

Também não.

Veja a ironia.

Hoje temos:

• APIs REST

• JSON

• XML

• Kafka

• Containers

• Docker

E o COBOL já conversa com tudo isso.

Inclusive o usuário Bellacosa Mainframe frequentemente explora integrações modernas entre COBOL, JSON, CICS Web Services e z/OS Connect.

O problema não é tecnológico.

É percepção de mercado.

---

O PARADOXO DO SUCESSO

O COBOL sofreu do mesmo problema que o DB2 Mainframe.

Ele ficou tão bom no que fazia que nunca precisou mudar radicalmente.

Enquanto outras linguagens lutavam para sobreviver, o COBOL já tinha conquistado o setor financeiro.

---

O QUE ACONTECERIA SE O COBOL FOSSE CRIADO HOJE?

Imagine uma linguagem com:

• sintaxe legível

• precisão decimal nativa

• foco em regras de negócio

• forte tipagem

• excelente auditoria

Provavelmente seria vendida como:

• FinTech Language

• Banking Language

• Enterprise Language

E talvez fosse considerada revolucionária.

---

O COBOL PERDEU A GUERRA?

Não.

Na verdade, ele venceu uma guerra diferente.

Enquanto milhares de linguagens nasceram e morreram, COBOL continua executando sistemas críticos após mais de seis décadas.

Poucas tecnologias na história conseguiram isso.

---

A VERDADE QUE POUCOS ADMITEM

Quando um programador Python cria um sistema hoje, ninguém sabe se ele existirá daqui a 30 anos.

Quando um programador COBOL cria um sistema bancário, existe uma boa chance de alguém ainda estar executando aquele código décadas depois.

Isso muda completamente a forma de projetar software.

---

A GRANDE LIÇÃO PARA OS PADAWANS

A pergunta correta não é:

"Por que COBOL ficou nichado no Mainframe?"

A pergunta correta é:

"Por que o Mainframe continuou sendo o melhor lugar para executar aquilo que o COBOL foi criado para fazer?"

Porque o COBOL nasceu para resolver problemas empresariais gigantescos.

E o Mainframe continua sendo a plataforma mais eficiente para executar esses processos com:

• confiabilidade

• segurança

• disponibilidade

• escalabilidade

• integridade transacional

O COBOL não ficou preso ao Mainframe.

Na realidade, ele encontrou seu habitat natural.

As versões para DOS, Windows e Linux sempre existiram, continuam existindo e funcionam muito bem.

Mas fora do Mainframe ele precisava competir com centenas de linguagens.

Dentro do Mainframe ele se tornou rei.

E existe uma enorme diferença entre participar de uma competição e dominar um reino.

Mais de 65 anos depois de seu nascimento, o COBOL continua processando salários, aposentadorias, seguros, cartões de crédito, transferências bancárias e operações financeiras que sustentam boa parte da economia mundial.

Poucas linguagens podem dizer isso.

E talvez esse seja o maior paradoxo da computação:

O COBOL não conquistou todas as plataformas porque nunca precisou.

Ele já estava ocupado movendo o mundo. ☕🚀

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

Bellacosa Mainframe e tecnicas e ferramentas de teste automatizado em ibm mainframe

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

A Arte Esquecida dos Testes no IBM Mainframe

Existe uma crença antiga nos corredores dos CPDs:

"Se compilou sem erro e rodou em produção, então está certo."

Foi exatamente esse tipo de pensamento que produziu alguns dos maiores incidentes da história da computação corporativa.

No mundo Mainframe, um erro não afeta apenas um usuário.

Pode afetar:

• milhões de contas bancárias

• faturamento de operadoras

• pagamento de aposentadorias

• processamento de cartões

• sistemas governamentais

Por isso, testar COBOL nunca foi opcional.

Sempre foi sobrevivência.

O curioso é que durante décadas o programador COBOL executava testes praticamente de forma artesanal:

1. Criava um arquivo de teste

2. Submetia um JOB

3. Esperava terminar

4. Analisava SYSOUT

5. Corrigia

6. Repetia

Hoje o cenário mudou radicalmente.

Temos frameworks modernos, automação, DevOps, CI/CD e até testes unitários para COBOL.

Sim.

Você leu corretamente.

Testes unitários para COBOL.

---

Como Pensar em Testes COBOL

Antes das ferramentas, precisamos entender os níveis de teste.

1. Teste Unitário

Valida apenas uma rotina.

Exemplo:

Programa calcula juros.

Entrada:

VALOR = 1000
TAXA  = 10

Saída esperada:

1100

Nada de arquivos.

Nada de DB2.

Nada de CICS.

Somente lógica.

---

2. Teste de Integração

Valida interação entre componentes.

Exemplo:

COBOL
 ↓
DB2
 ↓
MQ
 ↓
Outro Sistema

Aqui os problemas aparecem.

A lógica funciona.

A integração não.

---

3. Teste de Sistema

Avalia o fluxo completo.

Exemplo:

Tela CICS
 ↓
COBOL
 ↓
DB2
 ↓
IMS
 ↓
MQ

Tudo junto.

Como acontece na produção.

---

4. Teste de Regressão

O mais importante.

Você altera uma linha.

Precisa garantir que não destruiu outras 500 funcionalidades.

É aqui que a automação brilha.

---

Ferramenta 1 — IBM ZUnit

A joia da coroa da IBM.

ZUnit é o framework oficial de testes unitários para COBOL.

Foi criado para trazer ao Mainframe conceitos comuns em Java e .NET.

Zunit - https://eljefemidnightlunch.blogspot.com/2021/05/padawan-o-zunit-e-o-momento-em-que-o.html 

Vantagens

✔ Teste automatizado

✔ Integrado ao IDz

✔ Repetível

✔ Excelente para DevOps

✔ Integração com pipelines

---

Desvantagens

✘ Curva de aprendizado

✘ Dependência do ecossistema IBM

✘ Nem sempre simples para programas antigos

---

Exemplo Prático com ZUnit

Suponha o programa:

IDENTIFICATION DIVISION.
PROGRAM-ID. CALCJURO.

COMPUTE VALOR-FINAL =
        VALOR + (VALOR * TAXA / 100).

Passo 1

Abrir IDz.

---

Passo 2

Criar projeto ZUnit.

File
  New
    ZUnit Test Case

---

Passo 3

Selecionar programa COBOL.

CALCJURO

---

Passo 4

Definir entrada.

VALOR = 1000
TAXA  = 10

---

Passo 5

Definir saída esperada.

1100

---

Passo 6

Executar.

Run As
   ZUnit Test

Resultado:

PASS

ou

FAIL

---

Ferramenta 2 — IBM COBOL Check: Encontrando Defeitos Antes da Execução

Antes de executar qualquer teste, existe uma etapa ainda mais inteligente.

A análise estática.

É aqui que entra o IBM COBOL Check.

IBM Cobol Check - https://eljefemidnightlunch.blogspot.com/2026/06/ibm-cobol-check-ferramenta-que-trouxe.html

O Que É?

O COBOL Check examina o código-fonte procurando defeitos potenciais sem executar uma única instrução.

Ele atua como um inspetor de qualidade automatizado.

Enquanto o ZUnit pergunta:

"O programa funciona?"

O COBOL Check pergunta:

"Existe algo suspeito neste código?"

---

Problemas Detectados

Variáveis Não Inicializadas

01 WS-TOTAL PIC 9(05).

ADD 100 TO WS-TOTAL.

O campo recebeu valor antes?

Talvez não.

---

Índices Fora da Faixa

MOVE 150 TO WS-INDICE.

MOVE 'ABC' TO WS-DADO(WS-INDICE).

Tabela com apenas 100 ocorrências.

Possível S0C4.

---

Código Morto

STOP RUN.

DISPLAY 'NUNCA EXECUTA'

Trecho inalcançável.

---

Condições Impossíveis

IF VALOR > 100
AND VALOR < 50

Nunca será verdadeiro.

---

Possíveis S0C7

MOVE 'ABCDE' TO CAMPO-NUMERICO.

ADD 1 TO CAMPO-NUMERICO.

Compila.

Mas pode explodir em produção.

---

Vantagens do COBOL Check

✔ Não precisa executar o programa

✔ Automatizável

✔ Excelente para DevOps

✔ Descobre defeitos cedo

✔ Padronização corporativa

---

Desvantagens

✘ Não substitui testes

✘ Pode gerar falsos positivos

✘ Requer parametrização adequada

---

Ferramenta 3 — IBM Debug Tool

Muita gente acha que Debug Tool serve apenas para depuração.

Errado.

Ele também é excelente para validação de comportamento.

Vantagens

✔ Sem alterar código

✔ Breakpoints

✔ Análise em tempo real

✔ Visualização de variáveis

---

Desvantagens

✘ Não substitui testes automatizados

✘ Processo mais manual

---

Exemplo

Interceptar:

COMPUTE TOTAL = A + B

Durante execução:

AT LINE 125
DISPLAY TOTAL

Verificando se:

10 + 15 = 25

---

Ferramenta 4 — File-AID

Uma das ferramentas mais usadas para testes.

Principalmente em ambientes bancários.

O que faz?

Criação de massa de testes.

Manipulação de arquivos.

Comparação de resultados.

---

Exemplo

Criar arquivo VSAM contendo:

CLIENTE 001
CLIENTE 002
CLIENTE 003

Executar programa.

Comparar resultado.

---

Vantagens

✔ Rápido

✔ Simples

✔ Excelente para testes batch

---

Desvantagens

✘ Não executa lógica unitária

✘ Foco em dados

---

Ferramenta 5 — Xpediter

O lendário depurador da Compuware/BMC.

Praticamente um microscópio para COBOL.

Permite

• Breakpoints

• Alteração dinâmica

• Rastreamento

• Simulação

---

Vantagens

✔ Muito poderoso

✔ Excelente para programas complexos

✔ Integração com CICS

---

Desvantagens

✘ Licenciamento

✘ Excesso de recursos para iniciantes

---

Ferramenta 6 — Abend-AID

Não é exatamente uma ferramenta de testes.

Mas salva vidas.

Quando ocorre:

S0C7

ou

S0C4

Ela mostra:

• linha exata

• variável envolvida

• conteúdo dos campos

---

Vantagens

✔ Diagnóstico rápido

✔ Redução de MTTR

✔ Histórico de falhas

---

Desvantagens

✘ Atua após o erro

✘ Não evita defeitos

---

Técnica Clássica: Golden File

Uma das técnicas mais usadas em Mainframe.

Executa-se um programa conhecido.

Resultado esperado:

ARQ-OK

Depois da alteração:

ARQ-NOVO

Comparação:

SUPERC

ou

File-AID Compare

Se forem idênticos:

TESTE APROVADO

---

Técnica Moderna: Mocking

Muito usada com ZUnit.

Imagine:

SELECT CLIENTE
       ASSIGN TO VSAMCLI.

Em vez de acessar VSAM real:

VSAM MOCK

Resultado:

• teste rápido

• sem riscos

• repetível

---

Técnica de Cobertura

Pergunta simples:

Quanto do programa foi realmente executado?

Muitos acreditam:

Teste passou

Logo:

Programa está correto

Não necessariamente.

Você pode ter testado apenas 20% dos caminhos.

Ferramentas modernas ajudam a medir cobertura.

---

Curiosidades Históricas

COBOL já tinha testes antes da moda

Décadas antes de JUnit existir:

Programadores Mainframe já criavam:

ARQTEST1
ARQTEST2
ARQTEST3

Executando cenários controlados.

Na prática, eram testes unitários artesanais.

---

O custo do erro

Um defeito descoberto:

• Durante codificação → custo 1x

• Durante homologação → custo 10x

• Em produção → custo 100x

Essa regra continua válida.

---

Grandes bancos executam milhões de testes

Em ambientes modernos de DevOps Mainframe, pipelines podem disparar milhares de testes automáticos a cada alteração de código COBOL.

O objetivo é simples:

Quebrar no laboratório para não quebrar na produção.

---

Dicas do Bellacosa

☕ Dica 1

Nunca teste apenas o cenário feliz.

Teste:

• zeros

• negativos

• máximos

• mínimos

• espaços

• nulos

---

☕ Dica 2

Todo S0C7 que chega em produção é um teste que faltou.

---

☕ Dica 3

Crie bibliotecas permanentes de massa de testes.

Economiza centenas de horas.

---

☕ Dica 4

Automatize tudo o que puder.

O programador esquece.

O script não.

---

☕ Dica 5

Sempre mantenha testes de regressão após correções.

O defeito corrigido hoje costuma reaparecer daqui seis meses.

---

Exemplo de Pipeline DevOps Mainframe

Git
 ↓
Commit
 ↓
Build COBOL
 ↓
ZUnit
 ↓
Análise de Qualidade
 ↓
Deploy Homologação
 ↓
Testes Integração
 ↓
Produção

Cada etapa reduz riscos.

Cada teste reduz surpresas.

---

Resumo Executivo

Testar COBOL em ambiente IBM Mainframe deixou de ser uma atividade manual e passou a ser parte fundamental da engenharia moderna de software. Ferramentas como IBM ZUnit, Debug Tool, File-AID, Xpediter e Abend-AID permitem validar lógica, criar massas de teste, depurar falhas e automatizar regressões. O segredo não está apenas na ferramenta, mas na disciplina de criar cenários abrangentes, automatizar execuções e manter uma suíte de testes confiável. No fim das contas, o verdadeiro profissional Mainframe não é aquele que nunca gera defeitos. É aquele que constrói mecanismos para encontrá-los antes que o cliente encontre primeiro.

☕💣🚀 PADAWAN, O TESTE NÃO EXISTE PARA PROVAR QUE SEU COBOL ESTÁ CERTO. ELE EXISTE PARA PROVAR QUANTAS MANEIRAS ELE AINDA TEM DE DAR ERRADO ANTES DA PRODUÇÃO DESCOBRIR!

 

Bellacosa Mainframe e as variaveis computacionais do COBOL 

☕💣🚀 COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5 para o Programador COBOL Jr.

Uma das maiores fontes de confusão para quem começa em COBOL é entender por que existem tantos tipos numéricos.

A resposta está na história dos mainframes IBM.

Cada COMP surgiu para resolver um problema específico de armazenamento, desempenho ou precisão matemática. (IBM)

---

Linha do Tempo

Tipo	Surgiu
COMP	Década de 1960
COMP-1	Década de 1970
COMP-2	Década de 1970
COMP-3	Década de 1960
COMP-4	Década de 1970
COMP-5	Década de 1980

Os números exatos variam conforme compilador e plataforma, mas COMP-3 e COMP já existiam nos ambientes System/360. COMP-1, COMP-2 e COMP-4 apareceram como extensões IBM. COMP-5 surgiu posteriormente para resolver limitações do BINARY tradicional. (IBM)

---

COMP-1

O que é

Ponto flutuante simples (single precision).

Ocupa:

• 4 bytes

Utilizado para:

• cálculos científicos

• engenharia

• estatística

Não deve ser usado para dinheiro. (IBM)

---

Exemplo

01 WS-TEMPERATURA COMP-1.

MOVE 23.75 TO WS-TEMPERATURA.

---

Vantagens

• rápido

• suporta expoentes

• ocupa pouco espaço

---

Desvantagens

• perde precisão decimal

• gera arredondamentos inesperados

---

Exemplo clássico

COMPUTE RESULT = 0.1 + 0.2

Resultado pode não ser exatamente:

0.300000

Isso acontece porque o valor é armazenado em binário.

---

COMP-2

O que é

Ponto flutuante duplo (double precision).

Ocupa:

• 8 bytes

Muito mais preciso que COMP-1. (IBM)

---

Exemplo

01 WS-PI COMP-2.

MOVE 3.14159265358979 TO WS-PI.

---

Vantagens

• enorme faixa de valores

• excelente precisão científica

---

Desvantagens

• mais lento

• ocupa mais memória

• inadequado para dinheiro

---

COMP-3

O Rei dos Bancos

Também chamado:

PACKED DECIMAL

ou

COMPUTATIONAL-3

É o formato mais amado pelos bancos. (IBM)

---

Como funciona

Cada byte armazena:

2 dígitos

mais um nibble de sinal.

---

Exemplo

01 SALDO PIC S9(7)V99 COMP-3.

Valor:

12345.67

Internamente:

12 34 56 7C

(C = positivo)

---

Vantagens

• extremamente compacto

• precisão decimal perfeita

• ideal para dinheiro

---

Desvantagens

• CPU precisa converter para cálculo

• não é legível em dump

---

Melhor uso

Contas correntes
Faturas
Cartões
Seguros
Folha de pagamento

---

COMP-4

O que é

Binário IBM.

Sinônimo de:

BINARY
COMP

na maioria dos compiladores IBM. (IBM)

---

Exemplo

01 CONTADOR PIC S9(4) COMP-4.

---

Tamanho

Dígitos	Bytes
1-4	2
5-9	4
10-18	8

(IBM)

---

Vantagens

• muito rápido

• ideal para índices

• excelente para contadores

---

Desvantagens

O comportamento depende do:

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Isso já causou milhares de bugs em migrações COBOL. (IBM)

---

COMP-5

O que é

Binary Native.

Foi criado para eliminar limitações do COMP-4. (IBM)

---

Exemplo

01 WS-ID PIC S9(4) COMP-5.

---

Diferença Fundamental

Mesmo declarando:

PIC S9(4)

um COMP-5 de 2 bytes pode armazenar:

-32768
até
+32767

porque usa a capacidade real do campo binário. (IBM)

---

Vantagens

• mais rápido

• ideal para APIs

• ideal para CICS

• ideal para LE

• ideal para interoperabilidade com C

---

Desvantagens

• pode surpreender quem espera validação pelo PIC

• programas antigos podem comportar-se diferente

---

Comparação Geral

Característica	COMP-1	COMP-2	COMP-3	COMP-4	COMP-5
Tipo	Float	Float	Decimal	Binário	Binário Nativo
Bytes	4	8	Variável	2/4/8	2/4/8
Dinheiro	❌	❌	✅	⚠️	⚠️
Velocidade	Alta	Alta	Média	Muito Alta	Muito Alta
Precisão Decimal	Baixa	Média	Excelente	Boa	Boa
Interoperabilidade	Média	Média	Baixa	Média	Excelente

---

Opções de Compilação que Afetam Tudo

TRUNC

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Principal responsável por diferenças em COMP e COMP-4. (IBM)

---

ARITH

ARITH(COMPAT)
ARITH(EXTEND)

Impacta precisão matemática.

Muito importante para:

COMP-3
COMPUTE
DIVIDE
MULTIPLY

---

NUMPROC

NUMPROC(PFD)
NUMPROC(MIG)
NUMPROC(NOPFD)

Afeta tratamento de sinais inválidos em COMP-3.

---

RULES(NOEVENPACK)

Detecta packed decimals com número par de dígitos, ajudando a otimizar COMP-3. (IBM)

---

Problemas Conhecidos

1. Dinheiro em COMP-1

Erro clássico.

01 SALDO COMP-1.

Nunca faça isso.

---

2. Migração COBOL V4 → V6

Mudanças em:

TRUNC
ARITH
OPTIMIZATION

geraram diferenças de resultados em milhares de aplicações. (IBM)

---

3. COMP-3 Corrompido

Dump:

12 34 5F

Sinal inválido.

Pode gerar:

S0C7

---

4. Overflow Silencioso

Muito comum em:

COMP
COMP-4

quando TRUNC(BIN) está ativo.

---

Easter Eggs e Curiosidades

1. O banco não gosta de FLOAT

Em muitos bancos você encontrará:

0 ocorrências de COMP-1
0 ocorrências de COMP-2

em milhões de linhas COBOL.

---

2. COMP-3 domina Wall Street

Grande parte dos sistemas financeiros de alto volume ainda utiliza COMP-3 para valores monetários devido à precisão decimal exata.

---

3. TRUNC(BIN) "transforma" COMP em COMP-5

Na prática, muitos comportamentos tornam-se equivalentes para operações binárias. (IBM)

---

4. Packed Decimal foi uma genialidade da IBM

Quando memória custava fortunas, armazenar dois dígitos por byte era uma enorme vantagem econômica.

---

Regra de Ouro para o Programador COBOL Jr.

Se estiver em dúvida:

Dinheiro      -> COMP-3
Contadores    -> COMP-5
Índices       -> COMP-5
Percentuais   -> COMP-3
Cálculos científicos -> COMP-2
Integração C/C++ -> COMP-5

Em ambientes modernos z/OS com Enterprise COBOL 6.x, a combinação mais comum e segura é:

COMP-3 para valores financeiros
COMP-5 para inteiros e contadores

Essa dupla cobre praticamente 95% das necessidades de aplicações corporativas em bancos, seguradoras e grandes empresas. (IBM)

 

Bellacosa Mainframe e um laboratorio pratico IMS DB

☕💣🚨 LABORATÓRIO IMS PARA SYSPROGS E SYSADMINS

10 Incidentes Reais de Monitoramento e Troubleshooting no IMS Mainframe

Este laboratório foi projetado para colocar o aluno em situações próximas das encontradas em bancos, seguradoras e ambientes corporativos que utilizam IMS TM e IMS DB.

Objetivo:

• Desenvolver raciocínio de troubleshooting

• Interpretar sintomas

• Utilizar monitoramento

• Identificar causa raiz

• Aplicar correções

---

LAB 1 — Filas OTMA Crescendo Sem Parar

Cenário

Usuários reclamam que operações via aplicativo móvel estão lentas.

Monitoramento:

OMEGAMON IMS

OTMA Queue Depth

08:00 -> 100
08:05 -> 500
08:10 -> 1500
08:15 -> 3500

---

O que investigar

Verificar:

/DIS TMEMBER
/DIS TRAN

Analisar:

• IMS Connect

• OTMA

• MPPs disponíveis

---

Diagnóstico

As mensagens chegam.

Os programas não conseguem consumi-las.

---

Causa Raiz

Todas as MPPs estão ocupadas.

---

Solução

Aumentar MPPs:

/START REGION TYPE(MPP)

ou corrigir programa que está monopolizando processamento.

---

LAB 2 — IMS Connect Respondendo Lentamente

Cenário

Aplicativo mobile demora 15 segundos.

Terminal IMS continua rápido.

---

Monitoramento

PING OK

IMS TM OK

IMS Connect Response
15 segundos

---

Investigação

Verificar:

NETSTAT
AT-TLS
TCPIP

---

Diagnóstico

Handshake TLS excessivamente lento.

---

Causa

Certificado expirado gerando renegociações.

---

Solução

Atualizar certificados RACF.

Reiniciar componentes TLS.

---

LAB 3 — Região MPP Consumindo CPU Excessiva

Cenário

CPU dispara para 95%.

---

Monitoramento

RMF

IMSMPR01

CPU = 92%

---

Investigação

Verificar:

/DIS REGION

Analisar dumps.

---

Diagnóstico

Loop lógico no programa COBOL.

---

Causa

GN executado sem condição de parada.

---

Solução

Corrigir programa.

Recompilar.

Reimplantar.

---

LAB 4 — Banco IMS Não Abre

Cenário

Após IPL:

/START DB

Falha.

---

Mensagem

DATABASE NOT AVAILABLE

---

Investigação

Consultar:

DBRC
RECON

---

Diagnóstico

Image Copy inconsistente.

---

Causa

Backup interrompido.

---

Solução

Executar Recovery.

Gerar nova Image Copy.

---

LAB 5 — Shared Queue Congestionada

Cenário

IMSplex apresenta lentidão.

---

Monitoramento

CQS Queue Depth

Normal: 300

Atual: 25.000

---

Investigação

Verificar:

CQS
CF
Shared Queues

---

Diagnóstico

Estrutura da Coupling Facility saturada.

---

Solução

Expandir estrutura.

Redistribuir carga.

---

LAB 6 — Falha de Comunicação Mobile → IMS

Cenário

Aplicativo recebe:

HTTP 503

---

Investigação

Fluxo:

Mobile
 |
API
 |
z/OS Connect
 |
IMS Connect

---

Diagnóstico

IMS Connect indisponível.

---

Verificação

D A,L

---

Solução

Reiniciar:

S HWS

---

LAB 7 — Crescimento Anormal de Storage

Cenário

IMS termina com:

S878

---

Monitoramento

Region Storage

31-bit exhausted

---

Investigação

Analisar:

Buffers
Pools
Storage reports

---

Diagnóstico

Buffer pool configurado incorretamente.

---

Solução

Redimensionar buffers.

Migrar estruturas para 64 bits.

---

LAB 8 — Tempo de Resposta Intermitente

Cenário

Usuário reclama:

Às vezes rápido.
Às vezes lento.

---

Monitoramento

RMF

I/O Peaks

---

Investigação

Verificar:

• DASD

• Storage Controller

• Canal FICON

---

Diagnóstico

Contenção de I/O.

---

Solução

Redistribuir datasets.

Balancear volumes.

---

LAB 9 — Falha de Recovery

Cenário

Recovery falha.

---

Mensagem

LOG RECORD MISSING

---

Investigação

Analisar:

RECON
Archive Logs
DBRC

---

Diagnóstico

Log arquivado ausente.

---

Solução

Restaurar log perdido.

Reexecutar recovery.

---

LAB 10 — O Incidente das 2 da Manhã

Cenário

Todos os sintomas aparecem ao mesmo tempo.

Filas crescendo
CPU alta
Usuários reclamando
Mobile lento

---

Monitoramento

OMEGAMON
RMF
IMS
TCPIP

---

Investigação

Passo 1

CPU

Passo 2

Storage

Passo 3

IMS Connect

Passo 4

MPP

Passo 5

OTMA

---

Diagnóstico

Uma única MPP travada.

Todas as filas aguardando.

---

Solução

Cancelar região problemática.

/CANCEL REGION

Iniciar nova região.

/START REGION TYPE(MPP)

Filas normalizam.

Sistema volta ao normal.

---

Resultado Esperado do Laboratório

Ao concluir os 10 incidentes o aluno terá contato com:

✅ IMS TM

✅ IMS Connect

✅ OTMA

✅ MPP

✅ BMP

✅ Shared Queues

✅ CQS

✅ IMSplex

✅ DBRC

✅ Recovery

✅ Storage

✅ Performance

✅ OMEGAMON

✅ RMF

✅ RACF

✅ TCP/IP

E principalmente aprenderá a pensar como um Sysprog ou Sysadmin experiente:

"Não procurar apenas o erro, mas entender o fluxo completo da transação do usuário até o IMS Database."

☕💣🚀 Regra de ouro do laboratório: em ambientes IMS, o sintoma raramente está no mesmo lugar da causa raiz. O trabalho do Sysprog e do Sysadmin é seguir a trilha da transação até encontrar o verdadeiro culpado.

Neo COBOL : Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Bellacosa Mainframe e o que há de mais moderno no COBOL

☕💣🚀 PADAWAN, O COBOL FUGIU DO TERMINAL VERDE!

Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Existe uma pergunta que aparece em praticamente toda palestra sobre Mainframe.

Ela normalmente vem de alguém que nunca trabalhou com IBM Z.

Às vezes é um estudante.

Às vezes é um programador Java.

Às vezes é um gerente recém-chegado ao mundo corporativo.

A pergunta é sempre a mesma:

— Mas COBOL ainda existe?

E eu sempre respondo:

— Não apenas existe. Ele movimenta boa parte da economia mundial enquanto você dorme.

O mais curioso é que o COBOL de hoje não se parece nem um pouco com a imagem que muita gente guarda na cabeça.

Quando alguém fala em COBOL, normalmente imagina uma sala escura, um operador digitando comandos em uma tela verde, um terminal 3270 piscando e um monte de programas escritos há cinquenta anos.

Essa imagem até possui um fundo de verdade.

Mas ela representa apenas uma pequena parte da história.

A realidade é que o Mainframe passou por uma transformação silenciosa que poucas pessoas fora do mercado IBM perceberam.

E talvez essa seja uma das maiores revoluções tecnológicas dos últimos anos.

---

O Gigante Invisível Nunca Foi Embora

Enquanto o mundo discutia startups, aplicativos móveis e computação em nuvem, o Mainframe continuava fazendo aquilo que sempre fez melhor:

Processar volumes absurdos de dados com segurança, disponibilidade e confiabilidade.

Hoje ele continua presente em:

• Bancos

• Seguradoras

• Bolsas de valores

• Governos

• Operadoras de cartão

• Empresas aéreas

• Sistemas de saúde

Bilhões de transações passam diariamente por sistemas COBOL.

Grande parte do dinheiro que circula pelo planeta toca algum programa COBOL em algum momento da jornada.

O curioso é que quase ninguém percebe isso.

Por isso costumo chamar o Mainframe de:

O Gigante Invisível da Computação.

---

O Dia em Que o Mainframe Conheceu o VS Code

Durante décadas o ambiente clássico de desenvolvimento foi dominado por ferramentas tradicionais como:

• ISPF

• TSO

• SDSF

• Editores 3270

Essas ferramentas continuam extremamente importantes.

Mas a nova geração de desenvolvedores cresceu usando interfaces gráficas, IDEs modernas e integração contínua.

A IBM percebeu isso.

O resultado foi uma mudança histórica.

Hoje um programador COBOL pode desenvolver utilizando:

• Visual Studio Code

• Git

• GitHub

• GitHub Actions

• APIs REST

• Zowe Explorer

Ou seja:

O desenvolvedor pode trabalhar em uma interface praticamente idêntica à utilizada por equipes Java, Python ou JavaScript.

A barreira psicológica que separava o Mainframe do restante da indústria começou a desaparecer.

---

Zowe: A Ponte Entre Dois Mundos

Talvez nenhuma ferramenta tenha simbolizado tanto essa transformação quanto o Zowe.

Criado sob o guarda-chuva do Open Mainframe Project, o Zowe funciona como uma ponte entre o universo moderno de desenvolvimento e o ambiente IBM Z.

Com ele é possível:

• Navegar em datasets

• Visualizar jobs

• Consultar JES

• Trabalhar com USS

• Automatizar tarefas

• Consumir APIs do z/OS

Tudo isso sem sair do VS Code.

Para quem cresceu usando ISPF, a experiência parece quase mágica.

Para quem veio do mundo distribuído, finalmente o Mainframe passa a parecer familiar.

---

Open Mainframe Project: O Movimento Que Mudou Tudo

Durante muitos anos existiu um mito.

O mito dizia que Mainframe era uma tecnologia fechada.

Que tudo era proprietário.

Que inovação só acontecia fora desse ambiente.

Então surgiu o Open Mainframe Project.

A iniciativa passou a reunir:

• IBM

• Bancos

• Universidades

• Comunidade Open Source

• Grandes empresas globais

O objetivo era simples:

Modernizar o ecossistema sem destruir aquilo que o tornou confiável.

Foi dessa iniciativa que nasceram diversos projetos fundamentais.

Entre eles:

• Zowe

• COBOL Check

• Z Open Editor

• Mentorship Programs

• Cursos gratuitos

O resultado foi um crescimento enorme da comunidade.

---

O Git Finalmente Chegou ao Mainframe

Antigamente o controle de versões era feito através de soluções corporativas específicas.

Hoje a realidade mudou.

Git tornou-se parte integrante do desenvolvimento Mainframe moderno.

Agora podemos:

• Criar branches

• Fazer merge

• Abrir pull requests

• Revisar código

• Automatizar validações

Exatamente como acontece no restante da indústria.

O Mainframe deixou de ser uma ilha.

Ele tornou-se mais um participante do ecossistema DevOps.

---

DevOps Não É Apenas Moda

Existe quem pense que DevOps é apenas uma palavra bonita para colocar em apresentações.

Não é.

DevOps representa uma mudança cultural profunda.

No passado era comum ver equipes divididas:

Desenvolvimento de um lado.

Operação do outro.

Cada grupo trabalhando isoladamente.

Hoje o objetivo é integração.

Automação.

Colaboração.

Velocidade.

Qualidade.

E o IBM Z abraçou completamente essa filosofia.

---

CI/CD Também Chegou ao COBOL

Um dos maiores choques para quem está entrando no mercado Mainframe é descobrir que existem pipelines CI/CD para COBOL.

Sim.

Pipelines completos.

O fluxo pode ser algo como:

Commit → Build → Testes → Deploy → Produção

Ferramentas modernas como:

• GitHub Actions

• Jenkins

• DBB

• UrbanCode

• Zowe CLI

permitem automatizar praticamente todo o ciclo de desenvolvimento.

O mesmo conceito utilizado em aplicações web agora pode ser aplicado a programas COBOL.

---

Testes Automatizados: O JUnit do Mainframe

Durante muito tempo existiu a falsa ideia de que COBOL não possuía testes unitários.

Hoje isso está completamente ultrapassado.

Ferramentas como COBOL Check permitem:

• Criar testes automatizados

• Validar regras de negócio

• Executar regressões

• Integrar com pipelines DevOps

O conceito é muito parecido com:

• JUnit

• NUnit

• PyTest

A diferença é que agora estamos falando de COBOL.

Isso reduz riscos.

Melhora qualidade.

E aumenta a confiança durante mudanças em sistemas críticos.

---

APIs: O Mainframe Conversa Com Tudo

Outro mito clássico:

"O Mainframe é isolado."

Errado.

O Mainframe moderno conversa com praticamente qualquer tecnologia.

Hoje é comum encontrar:

• APIs REST

• Serviços Web

• JSON

• XML

• Kafka

• MQ

• Cloud

Um programa COBOL pode ser chamado por:

• Aplicativos móveis

• Sites

• Microserviços

• Plataformas em nuvem

A integração tornou-se um dos pilares da modernização.

---

UTF-8: O COBOL Aprendeu Novos Idiomas

Durante décadas os sistemas corporativos lidaram principalmente com conjuntos de caracteres tradicionais.

Agora o mundo é global.

Precisamos lidar com:

• Português

• Japonês

• Chinês

• Árabe

• Emojis

O Enterprise COBOL evoluiu para suportar:

• UTF-8

• NATIONAL

• Dynamic-Length Items

Isso abre portas para aplicações verdadeiramente globais.

---

Multithreading e Performance

Outra área de enorme evolução foi a capacidade de execução paralela.

Recursos modernos permitem:

• Multithreading

• THREAD Compiler Option

• LOCAL-STORAGE

• THREADSAFE

Isso significa melhor aproveitamento dos recursos do hardware IBM Z.

E quando falamos de IBM Z, estamos falando de uma das plataformas mais poderosas já criadas para processamento transacional.

---

O Papel da Inteligência Artificial

Talvez estejamos entrando na fase mais interessante da história do Mainframe.

A Inteligência Artificial começou a chegar ao ambiente IBM Z.

Hoje já vemos:

• Assistentes de código

• Geração automática de documentação

• Explicação de programas legados

• Conversão de código

• Análise de impacto

• Apoio à modernização

Ferramentas como GitHub Copilot, Watsonx e soluções corporativas especializadas estão transformando a forma como trabalhamos.

O desenvolvedor deixa de gastar energia com tarefas repetitivas e passa a focar na lógica de negócio.

---

O Novo Programador Mainframe

O mercado mudou.

O profissional mais valorizado não é apenas aquele que conhece COBOL.

Nem apenas aquele que conhece DevOps.

O profissional mais procurado é aquele que consegue unir os dois mundos.

O desenvolvedor moderno entende:

• COBOL

• JCL

• DB2

• CICS

• Git

• APIs

• VS Code

• Zowe

• DevOps

• CI/CD

• Testes automatizados

Ele compreende o legado.

Mas também compreende a inovação.

E essa combinação é extremamente rara.

---

O Futuro Já Chegou

Muitas pessoas continuam esperando o fim do Mainframe.

Esperam isso há décadas.

Enquanto isso, o IBM Z continua evoluindo.

Continua processando bilhões de transações.

Continua movimentando bancos.

Continua sustentando governos.

Continua integrando-se com nuvem, APIs, DevOps e Inteligência Artificial.

Talvez a maior surpresa não seja que o Mainframe tenha sobrevivido.

Talvez a maior surpresa seja perceber que ele nunca esteve tão moderno.

E aqui está a lição mais importante desta história.

☕💣🚀

OPERADOR, O COBOL NÃO FICOU PRESO NO PASSADO.

ELE SIMPLESMENTE ESPEROU O RESTO DA INDÚSTRIA ALCANÇÁ-LO.

Este texto já está pronto para publicação no Blogspot, LinkedIn Articles ou newsletter "Um Café no Bellacosa Mainframe".

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

 

Bellacosa Mainframe e o IBM Cobol Check

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Se você trabalhou anos com COBOL, provavelmente já viveu esta situação:

Altera o programa
↓
Compila
↓
Executa o JCL
↓
Espera o batch
↓
Confere SYSOUT
↓
Descobre erro
↓
Volta para o início

Durante décadas essa foi a rotina natural do desenvolvedor Mainframe.

Enquanto isso, no mundo Java, C#, Python e JavaScript, os programadores criavam centenas de testes automatizados que validavam cada função antes mesmo do deploy.

Então surgiu uma pergunta:

"Por que COBOL não pode fazer o mesmo?"

Foi exatamente dessa necessidade que nasceu o COBOL Check.

---

O Que é o IBM COBOL Check?

O COBOL Check é um framework de testes unitários para COBOL inspirado diretamente em ferramentas como:

• JUnit (Java)

• NUnit (.NET)

• PyTest (Python)

• RSpec (Ruby)

Seu objetivo é permitir que desenvolvedores criem testes automatizados para programas COBOL de forma granular, validando regras de negócio sem depender de execuções batch completas. (GitHub)

Na prática, ele permite testar:

• Parágrafos

• Seções

• Regras de negócio

• Cálculos

• Validações

• Programas inteiros

Tudo de forma automatizada.

---

Quem Criou o COBOL Check?

Muita gente pensa que é um produto comercial da IBM.

Na realidade, o COBOL Check nasceu dentro do ecossistema do Open Mainframe Project, com apoio da comunidade Mainframe moderna e contribuições de empresas que utilizam COBOL em larga escala. (GitHub)

Seu propósito era resolver um problema antigo:

Como fazer microtestes em aplicações COBOL do mesmo modo que fazemos em Java?

---

Quando Foi Lançado?

O projeto apareceu publicamente no final da década de 2010 dentro do movimento de modernização DevOps para IBM Z.

Ele surgiu durante a onda de iniciativas Open Source voltadas ao Mainframe, juntamente com projetos como:

• Zowe

• IBM Z Open Editor

• DBB

• Galasa

e rapidamente ganhou destaque por trazer testes unitários para COBOL de forma simples. (GitHub)

---

O Problema Que Ele Resolve

Imagine um programa bancário.

CALCULA-JUROS.
    COMPUTE JUROS =
       SALDO * TAXA.

Sem testes unitários você normalmente:

1. Compila.

2. Executa JCL.

3. Alimenta arquivos.

4. Analisa relatórios.

5. Verifica resultados.

Tudo isso para validar uma única regra.

Com COBOL Check você cria um teste automatizado.

---

A Grande Ideia

O conceito é exatamente o mesmo do JUnit.

Você cria:

Código

CALCULA-DESCONTO.

Teste

TEST-DESCONTO.

Execução

PASS

ou

FAIL

Simples assim.

---

Como Funciona Internamente?

O COBOL Check cria um ambiente de teste que:

• Executa trechos específicos do programa

• Injeta dados de entrada

• Compara resultados

• Gera relatórios

Ele também oferece suporte para:

• Assertions

• Stubs

• Mocks

• Verificação de chamadas

• Relatórios JUnit XML

• Relatórios HTML (GitHub)

Isso o aproxima bastante dos frameworks modernos.

---

Sistemas Suportados

O foco principal é:

IBM z/OS

Utilizando:

• Enterprise COBOL

• JCL

• Ambientes tradicionais de produção

Também pode ser utilizado em ambientes modernos ligados ao ecossistema Open Mainframe.

---

Dependências

Uma instalação típica envolve:

Compilador COBOL

Normalmente:

• Enterprise COBOL V5+

• Enterprise COBOL V6+

Ambiente z/OS

• TSO

• ISPF

• USS (quando aplicável)

Ferramentas modernas

Frequentemente combinado com:

• Git

• Jenkins

• Zowe

• DBB

• IBM Z Open Editor (Marketplace do Visual Studio)

---

Como Instalar

O processo varia conforme a empresa.

Em geral:

1. Obter o projeto

Disponível através do repositório oficial do Open Mainframe Project. (GitHub)

2. Fazer upload

Copiar os fontes para datasets do ambiente.

Exemplo:

USER.COBOLCHECK.SOURCE

3. Compilar

Executar os jobs de instalação.

//COMPILE EXEC IGYWCL

4. Configurar bibliotecas

Adicionar:

STEPLIB
SYSLIB
COPYLIB

5. Validar instalação

Executar os exemplos fornecidos.

---

Primeiro Exemplo Passo a Passo

Vamos criar algo simples.

---

Programa

IDENTIFICATION DIVISION.
PROGRAM-ID. CALC01.

WORKING-STORAGE SECTION.
01 WS-VALOR PIC 9(5).
01 WS-DESCONTO PIC 9(5).

PROCEDURE DIVISION.

    COMPUTE WS-DESCONTO =
       WS-VALOR * 10 / 100.

    GOBACK.

---

Cenário de Teste

Queremos provar que:

1000 = 100 de desconto

---

Caso de Teste

MOVE 1000 TO WS-VALOR

PERFORM CALCULO

ASSERT WS-DESCONTO = 100

---

Resultado

TESTE 001
PASS

---

Testando Múltiplos Cenários

Você pode criar vários testes.

Caso 1

1000 -> 100

Caso 2

2000 -> 200

Caso 3

5000 -> 500

Resultado:

3 TESTS
3 PASSED

---

Assertions

Uma das partes mais importantes.

Exemplo:

ASSERT TRUE

ASSERT FALSE

ASSERT EQUAL

ASSERT NOT EQUAL

Muito parecido com:

assertEquals()
assertTrue()
assertFalse()

---

Mocks

Outro recurso extremamente poderoso.

Imagine um programa que acessa:

DB2
VSAM
IMS
MQ

Você não quer depender desses recursos durante o teste.

Então cria um Mock.

---

Exemplo Conceitual

Produção:

READ CLIENTE

Teste:

MOCK CLIENTE

Resultado:

CLIENTE SIMULADO

Sem acessar banco real.

---

Stubs

Parecido com Mock.

Você substitui componentes complexos por versões simplificadas.

Exemplo:

CONSULTA-SERASA

vira

CONSULTA-SERASA-STUB

Permitindo testes rápidos.

---

Relatórios

Após executar os testes você pode gerar:

HTML

PASS
FAIL
TOTAL

XML

Formato compatível com:

• Jenkins

• GitHub Actions

• Azure DevOps

• GitLab CI/CD (GitHub)

---

Integração com Jenkins

Fluxo clássico:

Git Commit
      ↓
Build
      ↓
COBOL Check
      ↓
Relatório
      ↓
Deploy

Se um teste falhar:

BUILD FAILED

Sem deploy.

---

Integração com Git

Imagine:

Pull Request

Antes da aprovação:

Executar COBOL Check

Resultado:

Todos os testes passaram

Só então ocorre o merge.

---

Benefícios Para Bancos

Os maiores usuários são:

• Bancos

• Seguradoras

• Telecom

• Governo

Porque possuem milhões de linhas COBOL.

Alterar uma linha sem proteção pode gerar:

S0C7
Abends
Valores incorretos
Erros financeiros

O COBOL Check reduz drasticamente esse risco.

---

Curiosidade #1

Muitos programadores COBOL experientes inicialmente desconfiaram da ideia.

A reação típica era:

"Teste unitário é coisa de Java."

Hoje isso mudou completamente.

---

Curiosidade #2

O projeto nasceu justamente porque ferramentas comerciais existentes geralmente testavam programas inteiros, mas não permitiam testar pequenos blocos de lógica com granularidade suficiente. (GitHub)

---

Curiosidade #3

Uma das metas do COBOL Check era incentivar melhores práticas de desenvolvimento, como:

• Separação de responsabilidades

• Modularização

• Refatoração segura

Conceitos já populares no mundo Java. (GitHub)

---

Dicas de Ouro

Dica 1

Comece pelos cálculos.

São os testes mais fáceis.

---

Dica 2

Não tente cobrir o sistema inteiro.

Comece pelos módulos críticos.

---

Dica 3

Automatize tudo.

Teste manual não escala.

---

Dica 4

Integre com Jenkins.

O ganho de produtividade é enorme.

---

Dica 5

Execute testes a cada alteração.

Não espere a homologação.

---

Erros Comuns

Erro 1

Criar testes enormes.

Ruim:

Testar 20 regras juntas

Bom:

1 regra = 1 teste

---

Erro 2

Depender de dados reais.

Use mocks.

---

Erro 3

Não automatizar.

Se o teste depende de ação humana:

Você perdeu metade do benefício.

---

Easter Egg Mainframe ☕

Existe uma ironia divertida na história.

Durante décadas ouvimos:

"COBOL é antigo."

Mas hoje encontramos no mundo COBOL:

✅ Git

✅ VS Code

✅ Pipelines CI/CD

✅ DevOps

✅ Open Source

✅ APIs REST

✅ Containers

✅ Testes Unitários

✅ Inteligência Artificial

Enquanto muitos sistemas "modernos" desaparecem após poucos anos, aplicações COBOL escritas nos anos 70 continuam processando bilhões de dólares diariamente.

O COBOL Check é um símbolo dessa evolução.

Ele mostra que o Mainframe não ficou parado no tempo.

Pelo contrário.

O gigante apenas incorporou as melhores ideias do desenvolvimento moderno sem abrir mão da estabilidade que o tornou lendário.

---

Conclusão

O COBOL Check representa uma das iniciativas mais importantes da modernização do desenvolvimento Mainframe.

Ele trouxe para o COBOL conceitos consagrados por ferramentas como JUnit, permitindo:

• Testes unitários automatizados

• Mocks e Stubs

• Relatórios HTML e XML

• Integração com CI/CD

• Maior qualidade de código

• Refatoração segura

• Menor risco em produção (GitHub)

No estilo Bellacosa Mainframe, podemos resumir assim:

O COBOL Check é a prova definitiva de que o COBOL não ficou preso ao passado. O gigante aprendeu a testar como os sistemas modernos, mas continua entregando a confiabilidade que mantém bancos, governos e grandes empresas funcionando todos os dias. ☕💣🚀