El Jefe Midnight Lunch

✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta enterprise. Mostrar todas as mensagens

terça-feira, 9 de junho de 2026

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

segunda-feira, 8 de junho de 2026

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:

Compila.
Executa JCL.
Alimenta arquivos.
Analisa relatórios.
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

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. ☕💣🚀

sexta-feira, 29 de novembro de 2024

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Bellacosa Mainframe e o clean code no Cobol

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Durante décadas, o COBOL carregou uma fama injusta. Muitos profissionais associam a linguagem a programas gigantescos, difíceis de entender, cheios de GO TO, variáveis com nomes estranhos e regras de negócio espalhadas por milhares de linhas.

Mas existe uma verdade que poucos percebem:

O problema nunca foi o COBOL.

O problema sempre foi a forma como algumas pessoas escreveram COBOL.

Quando observamos sistemas modernos desenvolvidos em Enterprise COBOL para z/OS, encontramos recursos avançados, suporte a programação estruturada, funções intrínsecas, XML, JSON, tratamento de exceções e diversas funcionalidades que permitem criar aplicações extremamente organizadas e fáceis de manter.

Neste artigo vamos explorar as principais boas práticas de codificação para COBOL Mainframe, conceitos de Clean Code e técnicas utilizadas pelas equipes mais maduras do mercado.

Por que qualidade de código importa no Mainframe?

Em muitas empresas, um programa COBOL permanece em produção por décadas.

Enquanto uma aplicação web pode ser substituída em poucos anos, não é raro encontrar programas COBOL escritos nos anos 80 ou 90 ainda executando processos críticos.

Isso significa que:

O código será lido mais vezes do que escrito.
Diversos profissionais irão mantê-lo.
A regra de negócio precisa ser compreendida rapidamente.
Erros podem gerar impactos milionários.

Portanto, escrever código pensando apenas em "funcionar" é um erro.

O objetivo deve ser:

Funcionar hoje e continuar compreensível daqui a 20 anos.

O princípio mais importante: código deve parecer documentação

Um bom programa COBOL deve ser quase autoexplicativo.

Compare:

Exemplo ruim

IF A = 'S'
   MOVE '1' TO B
END-IF

Agora:

IF CLIENTE-ATIVO
   MOVE STATUS-APROVADO
      TO STATUS-CADASTRO
END-IF

No segundo caso, praticamente não é necessário comentário.

O código descreve o negócio.

Essa é uma das bases do Clean Code.

Utilize nomes significativos

Muitos sistemas antigos utilizam variáveis como:

01 WS-A.
01 WS-B.
01 WS-X.

Isso gera enorme dificuldade de manutenção.

Prefira:

01 WS-SALDO-CONTA.
01 WS-LIMITE-CREDITO.
01 WS-VALOR-SAQUE.

Uma boa regra:

Se o nome não explica o conteúdo, o nome está errado.

Padronize convenções de nomenclatura

Equipes maduras possuem padrões claros.

Exemplo:

WS- = Working Storage
LK- = Linkage
IN- = Entrada
OUT- = Saída
CNT- = Contador
FLG- = Flag

Exemplo:

01 WS-NOME-CLIENTE.
01 WS-IDADE-CLIENTE.
01 FLG-CLIENTE-ATIVO.

A simples leitura permite identificar a finalidade da variável.

Evite GO TO sempre que possível

Durante décadas o GO TO foi utilizado excessivamente.

Exemplo:

IF ERRO
   GO TO 9000-ERRO.

Embora ainda exista em muitos sistemas, o uso excessivo gera:

Fluxo confuso
Difícil rastreamento
Baixa manutenibilidade

Prefira:

IF ERRO
   PERFORM 9000-TRATAR-ERRO
END-IF

O PERFORM torna o fluxo muito mais previsível.

Use terminadores de escopo

Um dos maiores avanços do COBOL moderno foi a introdução dos terminadores explícitos.

Evite:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
ELSE
   MOVE 'N' TO STATUS

Prefira:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
   ELSE
      MOVE 'N' TO STATUS
   END-IF
END-IF

Terminações explícitas eliminam ambiguidades.

Mantenha parágrafos pequenos

Quando um parágrafo possui centenas de linhas, sua manutenção torna-se extremamente difícil.

Ruim:

1000-PROCESSAR.

com 500 linhas.

Melhor:

1000-PROCESSAR.

    PERFORM 1100-VALIDAR-DADOS
    PERFORM 1200-CALCULAR-TAXAS
    PERFORM 1300-ATUALIZAR-SALDOS
    PERFORM 1400-GERAR-RELATORIO.

Cada bloco possui responsabilidade específica.

Uma responsabilidade por parágrafo

Um erro comum é misturar atividades.

Exemplo:

2000-PROCESSAR.

faz:

leitura
validação
cálculo
gravação
relatório

Tudo junto.

Prefira dividir responsabilidades.

Isso segue o princípio conhecido como:

Single Responsibility Principle (SRP).

Evite código duplicado

Nada gera mais problemas do que duplicação.

Exemplo:

COMPUTE WS-VALOR =
        WS-VALOR * 1.15

copiado em 20 programas diferentes.

Quando a regra mudar, será necessário alterar os 20.

Melhor:

Criar uma rotina centralizada.

CALL 'CALCIMPO'

PERFORM 5000-CALCULAR-IMPOSTO

Centralização reduz erros.

Comentários devem explicar o motivo, não o óbvio

Comentário ruim:

MOVE WS-NOME
 TO WS-NOME-SAIDA

Comentário:

* Move o nome para saída

Isso não agrega valor.

Comentário bom:

* Regra exigida pelo Banco Central
* Circular 3456/2024

Explica o motivo da regra.

Organize o programa em camadas lógicas

Uma estrutura clássica é:

IDENTIFICATION DIVISION

ENVIRONMENT DIVISION

DATA DIVISION

PROCEDURE DIVISION

0000-MAIN

1000-INICIALIZAR

2000-LER-ARQUIVO

3000-PROCESSAR

4000-GRAVAR

9000-FINALIZAR

Essa organização ajuda qualquer programador a navegar rapidamente pelo código.

Utilize COPYBOOKS adequadamente

Copybooks são excelentes para reutilização.

Exemplo:

COPY CLIENTE.

Benefícios:

Padronização
Reutilização
Menor manutenção

Mas cuidado:

Não transforme copybooks em monstros de milhares de linhas.

Trate erros explicitamente

Um programa profissional nunca assume sucesso.

Errado:

READ ARQ-CLIENTE

Melhor:

READ ARQ-CLIENTE
   AT END
      SET FIM-ARQUIVO TO TRUE
END-READ

Ou:

EXEC SQL
    SELECT ...
END-EXEC

IF SQLCODE NOT = ZERO
    PERFORM 9000-TRATAR-ERRO
END-IF

Nunca ignore SQLCODE

Em ambientes DB2 esta regra é sagrada.

Após cada comando SQL:

IF SQLCODE = 0

EVALUATE TRUE
   WHEN SQLCODE = 0
   WHEN SQLCODE = 100
   WHEN OTHER
END-EVALUATE

Ignorar SQLCODE é abrir espaço para falhas silenciosas.

Prefira EVALUATE ao invés de IFs excessivos

Ruim:

IF TIPO = 'A'
...
ELSE
   IF TIPO = 'B'
...

Melhor:

EVALUATE TIPO
   WHEN 'A'
      ...
   WHEN 'B'
      ...
   WHEN 'C'
      ...
   WHEN OTHER
      ...
END-EVALUATE

Mais legível e mais fácil de expandir.

Utilize variáveis booleanas (88 Level)

Um recurso poderoso e subutilizado.

01 WS-STATUS.
   05 WS-COD-STATUS PIC X.

88 CLIENTE-ATIVO VALUE 'A'.
88 CLIENTE-INATIVO VALUE 'I'.

Uso:

IF CLIENTE-ATIVO

Muito melhor que:

IF WS-COD-STATUS = 'A'

Reduza dependências externas

Quanto mais dependências:

Mais acoplamento
Mais manutenção
Mais risco

Sempre avalie:

"Essa chamada realmente é necessária?"

Mantenha consistência visual

Exemplo:

MOVE WS-NOME
   TO WS-NOME-SAIDA

ADD WS-VALOR
   TO WS-TOTAL

PERFORM 3000-PROCESSAR

Código alinhado facilita leitura.

A produtividade da manutenção aumenta significativamente.

Evite números mágicos

Ruim:

IF WS-IDADE > 18

Melhor:

78 IDADE-MINIMA VALUE 18.

IF WS-IDADE > IDADE-MINIMA

A regra fica documentada.

Faça validações no início

Evite processar dados inválidos.

Exemplo:

IF WS-CPF = SPACES
   PERFORM 9000-ERRO
   GO TO 9999-SAIDA
END-IF

Falhar cedo reduz complexidade.

Desenvolva pensando em testes

Uma boa prática moderna é escrever código facilmente testável.

Rotinas menores:

1100-VALIDAR
1200-CALCULAR
1300-GERAR

permitem testes independentes.

Registre logs úteis

Logs não devem apenas indicar erro.

Exemplo:

Cliente 12345 rejeitado.
Motivo: Limite insuficiente.

Informação útil reduz tempo de diagnóstico.

Utilize recursos modernos do COBOL

Muitos programadores ainda escrevem COBOL como nos anos 80.

Entretanto o Enterprise COBOL oferece:

Functions
Inline Perform
Scope Terminators
XML PARSE
JSON PARSE
JSON GENERATE
Intrinsic Functions
UTF-8
National Data

Utilizar recursos modernos aumenta produtividade e legibilidade.

Revise código antes de promover

Code Review é uma das melhores práticas existentes.

Benefícios:

Detecta defeitos
Padroniza estilo
Compartilha conhecimento
Melhora qualidade

Nenhum profissional experiente deveria temer revisão.

Métricas que valem a pena acompanhar

Alguns indicadores importantes:

Complexidade ciclomática
Linhas por módulo
Cobertura de testes
Duplicação de código
Defeitos em produção

O que é medido tende a melhorar.

O verdadeiro significado de Clean Code no Mainframe

Muitos acreditam que Clean Code é apenas uma moda criada para Java ou aplicações web.

Não é.

Clean Code significa:

Clareza
Simplicidade
Legibilidade
Manutenibilidade
Organização

Esses princípios são universais.

Eles funcionam tão bem em COBOL quanto em qualquer linguagem moderna.

Conclusão

O mercado frequentemente discute modernização de aplicações, APIs, cloud e inteligência artificial. Entretanto, poucas empresas percebem que a maior modernização possível muitas vezes começa dentro do próprio código COBOL.

Um programa limpo reduz custos, diminui defeitos, acelera manutenções e facilita a transferência de conhecimento entre gerações de profissionais.

O COBOL moderno oferece todos os recursos necessários para produzir software elegante, estruturado e sustentável.

A diferença entre um sistema que sobrevive décadas com qualidade e outro que se transforma em um pesadelo operacional não está na linguagem utilizada.

Está na disciplina de engenharia aplicada por quem escreve o código.

E essa disciplina continua sendo uma das habilidades mais valiosas de qualquer profissional de Mainframe.

Título alternativo para maior engajamento em blog/newsletter:

☕💣 SEU COBOL FUNCIONA... MAS ALGUÉM CONSEGUE ENTENDER? AS 25 REGRAS DE CLEAN CODE QUE TODO PROGRAMADOR MAINFRAME DEVERIA SEGUIR ANTES DA PRÓXIMA PROMOÇÃO PARA PRODUÇÃO

sexta-feira, 31 de maio de 2024

☕🔥 A MODERNIZAÇÃO QUE DERRETEU US$ 170 MILHÕES

Bellacosa Mainframe e a migraçao que falhou

☕🔥 “A MODERNIZAÇÃO QUE DERRETEU US$ 170 MILHÕES”:

O DIA EM QUE A BOLSA DA AUSTRÁLIA DESCOBRIU QUE SUBSTITUIR MAINFRAME NÃO É BRINCADEIRA

Existe uma narrativa quase religiosa no mercado de tecnologia:

“Legacy é ruim. Mainframe é antigo. Blockchain resolve. Microserviços escalam tudo.”

A Australian Securities Exchange (ASX) resolveu apostar exatamente nisso.

E o resultado virou um dos maiores desastres modernos de migração de sistemas críticos financeiros.

📅 O CASO ASX — A LINHA DO TEMPO DO FRACASSO

2016 — O anúncio revolucionário

A ASX anunciou ao mercado que substituiria o CHESS:

sistema de clearing e liquidação da bolsa australiana
construído nos anos 1990
baseado em COBOL e mainframe
altamente estável
crítico para o mercado financeiro australiano

pela “nova geração”:

✅ Blockchain
✅ Distributed Ledger Technology (DLT)
✅ arquitetura moderna
✅ liquidação mais rápida
✅ redução de custos
✅ transparência distribuída

Na época, o mercado aplaudiu.

A imprensa chamou de:

“a primeira bolsa do mundo movida por blockchain”.

🏛 O QUE ERA O CHESS?

O CHESS não era “só um sistema antigo”.

Era literalmente o coração operacional da bolsa australiana.

Ele:

controlava custódia
liquidação financeira
ownership de ativos
sincronização entre participantes
integridade transacional do mercado

E fazia isso com:

~2,5 milhões de transações/dia
capacidade de pico acima de 10 milhões
disponibilidade de 99,95%
consistência transacional rígida

Tudo em mainframe.

⚠ O ERRO CONCEITUAL QUE MUITA GENTE NÃO ENTENDE

Muitos executivos olham para um sistema COBOL e enxergam:

“software velho”.

Mas sistemas financeiros antigos são frequentemente:

✅ extremamente otimizados
✅ previsíveis
✅ resilientes
✅ deterministicamente consistentes
✅ refinados por décadas de incidentes reais

Cada regra esquisita do sistema normalmente existe porque:

algum desastre já aconteceu antes.

Sistemas financeiros são cemitérios de exceções históricas.

🚨 2018 — O PRIMEIRO SINAL DE DESASTRE

O go-live estava planejado para 2018.

Mas começaram os adiamentos.

Depois vieram:

problemas de performance
problemas de sincronização
dificuldades de escalabilidade
inconsistência operacional
dúvidas sobre throughput
dúvidas sobre latência

E isso é importante:

Blockchain funciona MUITO melhor em cenários onde:

confiança é distribuída
latência não é crítica
consistência eventual é aceitável

Mercado financeiro NÃO aceita isso.

💥 O GRANDE PROBLEMA: CONSISTÊNCIA FORTE SOB ALTÍSSIMA CONCORRÊNCIA

O inferno começou aqui.

Em bolsa de valores:

uma transação não pode “talvez acontecer”
um ativo não pode aparecer duplicado
uma liquidação não pode entrar em eventual consistency
não existe “vamos sincronizar depois”

O sistema precisa garantir propriedades ACID:

ACID = {Atomicidade,\ Consist\hat{e}ncia,\ Isolamento,\ Durabilidade}

E garantir isso em arquitetura distribuída é brutalmente difícil.

⚡ O PROBLEMA QUE POWERPOINT NÃO MOSTRA: LATÊNCIA

Arquiteturas distribuídas introduzem:

comunicação entre nós
consenso
replicação
sincronização
validação distribuída

Tudo isso adiciona:

VARIABILIDADE

E mercado financeiro odeia variabilidade.

Porque:

microssegundos importam
previsibilidade importa
jitter importa
filas importam
lock contention importa

Mainframes foram literalmente desenhados para esse cenário.

📉 2022 — A AUDITORIA DA ACCENTURE

A situação ficou tão crítica que a ASX chamou a Accenture para revisar o projeto.

O relatório foi devastador.

Problemas encontrados:

🔴 Deficiências graves de design

🔴 Complexidade operacional subestimada

🔴 Riscos de escalabilidade

🔴 Falhas de governança

🔴 Cronogramas irreais

🔴 Problemas de engenharia estrutural

Pouco depois:

💣 Novembro de 2022 — PROJETO CANCELADO

Após quase 7 anos:

✅ cancelamento total
✅ prejuízo de ~240–255 milhões AUD
✅ perda de credibilidade
✅ impacto regulatório
✅ desgaste institucional gigantesco

⚖ 2024 — O ESCÂNDALO REGULATÓRIO

A situação piorou.

A ASIC (regulador australiano) processou a ASX alegando:

comunicação enganosa ao mercado
relatórios excessivamente otimistas
ocultação do verdadeiro estado do projeto

Isso é gravíssimo em mercado financeiro.

Porque investidores tomam decisões baseadas nessas comunicações.

🧠 A LIÇÃO MAIS IMPORTANTE

O fracasso NÃO significa:

❌ “Blockchain é inútil”
❌ “Tecnologia moderna não presta”
❌ “Mainframe vence tudo”

A lição real é muito mais profunda:

Sistemas críticos têm propriedades invisíveis.

E essas propriedades:

não aparecem no backlog Agile
não aparecem no PowerPoint
não aparecem no pitch de consultoria

Mas aparecem violentamente em produção.

☠ OUTROS CASOS FAMOSOS DE MIGRAÇÃO QUE FALHARAM REDONDAMENTE

🇬🇧 TSB Bank (Reino Unido) — 2018

“O banco migrou… e os clientes perderam acesso às contas”

O TSB tentou migrar da plataforma Lloyds para uma nova infraestrutura.

Resultado:

milhões de clientes sem acesso
contas erradas
saldos inconsistentes
pagamentos falhando
caos operacional

Impacto estimado:

💸 mais de £330 milhões em prejuízos.

O CEO acabou renunciando.

🇺🇸 Knight Capital — 2012

“45 minutos quase destruíram a empresa”

Não foi exatamente migração completa, mas atualização de sistema crítico.

Erro de deploy:

algoritmo antigo ativado por acidente
ordens disparadas descontroladamente

Resultado:

💥 US$ 440 milhões perdidos em 45 minutos.

A empresa praticamente morreu.

🇺🇸 Healthcare.gov — 2013

“O portal de saúde dos EUA colapsou no lançamento”

Problemas:

integração entre fornecedores
arquitetura complexa
testes insuficientes
escalabilidade ruim

O sistema entrou em colapso quase imediato.

🇬🇧 British Airways — 2017

“Uma falha derrubou operações globais”

Falha durante mudança operacional/data center.

Resultado:

voos cancelados
caos mundial
sistemas indisponíveis
prejuízo enorme

Muitos especialistas apontaram que simplificações excessivas na arquitetura contribuíram para o desastre.

🇩🇪 Deutsche Bank — tentativas de modernização

O Deutsche Bank passou anos tentando reduzir dependência de sistemas legados.

O problema?

Décadas de fusões criaram um “Frankenstein bancário”.

Em vários momentos, executivos admitiram que:

ninguém entendia totalmente o ecossistema
existiam dependências invisíveis
havia lógica de negócio enterrada no legado

☕ O QUE O MUNDO ENTERPRISE APRENDEU (E REAPRENDE TODO ANO)

Mainframe não sobreviveu por nostalgia.

Ele sobreviveu porque:

downtime custa bilhões
inconsistência destrói mercados
throughput real é difícil
previsibilidade vale ouro

🏛 O PARADOXO DO MAINFRAME

Quanto menos você ouve falar do sistema…

maior a chance de ele estar funcionando perfeitamente.

Porque sistemas realmente críticos:

não podem viralizar
não podem falhar bonito
não podem “iterar em produção”

Eles simplesmente precisam funcionar.

Todos os dias.

Por décadas.

🔥 A VERDADE QUE MUITA CONSULTORIA EVITA DIZER

Migrar sistema crítico não é:

✅ “reescrever código”

É:

migrar comportamento emergente
migrar décadas de exceções
migrar semântica operacional
migrar timing implícito
migrar cultura
migrar conhecimento tribal
migrar integrações invisíveis

E muitas vezes…

ninguém mais entende completamente tudo isso.

☕ A CONCLUSÃO MAIS INCÔMODA

Talvez a pergunta correta não seja:

“Por que ainda usam COBOL?”

Mas sim:

“Por que sistemas escritos há 40 anos continuam mais confiáveis do que muitas arquiteturas modernas?”

domingo, 19 de abril de 2015

☕🔥 TRABALHAR COM SISTEMAS LEGADOS — O QUE MUITA GENTE AINDA NÃO ENTENDE

Bellacosa Mainframe e os sistemas legados do mainframe

☕🔥 TRABALHAR COM SISTEMAS LEGADOS — O QUE MUITA GENTE AINDA NÃO ENTENDE

O universo dos sistemas legados e aqui existe algo importante:

muita gente fala sobre “modernização” sem realmente entender:

o valor do legado,
a engenharia envolvida,
a complexidade do negócio,
e principalmente…
o custo gigantesco de substituir décadas de conhecimento corporativo.

O autor desmonta vários mitos sobre sistemas legados e mostra algo que profissionais experientes já perceberam há muito tempo:

legado não significa velho.
legado significa sobrevivente.

O PRIMEIRO GRANDE ERRO:

CONFUNDIR “ANTIGO” COM “OBSOLETO”

Esse talvez seja o maior preconceito da área de TI.

Existe uma falsa narrativa de que:

se usa COBOL → é velho
se roda em mainframe → está ultrapassado
se foi criado há 30 anos → precisa morrer

Mas isso ignora um detalhe brutal:

O sistema ainda funciona.

E mais:
funciona em escala absurda.

O texto cita os IBM Z processando bilhões de transações.

Isso não é exagero.

O QUE O MAINFRAME ENTREGA QUE MUITOS SISTEMAS “MODERNOS” NÃO ENTREGAM?

1. ESTABILIDADE

Um sistema bancário core:

não pode parar,
não pode corromper dados,
não pode perder transações.

Enquanto muitos sistemas modernos:

reiniciam containers,
escalam pods,
reciclam microserviços,
aceitam indisponibilidade parcial,

o mainframe foi projetado para:

continuidade absoluta,
integridade transacional,
consistência de dados.

2. COMPATIBILIDADE DE DÉCADAS

Isso é uma obra de engenharia gigantesca.

Um programa COBOL compilado há décadas ainda pode funcionar hoje com mínimas alterações.

Imagine isso no mundo JavaScript.

Tente rodar:

AngularJS antigo,
bibliotecas JQuery antigas,
dependências npm de 10 anos atrás.

Você provavelmente terá:

incompatibilidades,
vulnerabilidades,
APIs quebradas,
frameworks mortos.

No mainframe:

o investimento é preservado.

3. ESCALABILIDADE REAL

Muita gente acha que escalabilidade significa:
“subir mais containers”.

No IBM Z:

escalabilidade envolve throughput transacional massivo,
I/O absurdamente otimizado,
processamento paralelo sofisticado,
canais dedicados,
criptografia em hardware.

É outro nível de engenharia.

O TEXTO ATACA UM MITO PERIGOSO:

“É SÓ REESCREVER”

Essa frase já destruiu projetos bilionários.

EXEMPLO REAL:

O SISTEMA NÃO É SÓ CÓDIGO

Um sistema legado de banco contém:

regras fiscais,
exceções históricas,
comportamento jurídico,
integrações obscuras,
regras nunca documentadas,
tratamentos especiais,
decisões de negócio acumuladas por décadas.

Muitas vezes:
nem a empresa sabe exatamente tudo que o sistema faz.

Porque:
o sistema VIROU o próprio negócio.

EXEMPLO PRÁTICO

Imagine um sistema de conta corrente criado em 1987.

Durante décadas ele recebeu:

correções,
adequações do Banco Central,
planos econômicos,
inflação,
moedas diferentes,
PIX,
Open Finance,
LGPD,
integração mobile,
antifraude,
compliance.

Agora imagine alguém dizendo:

“vamos reescrever tudo em Node.js.”

Isso é equivalente a:

trocar o motor de um avião em voo.

O ANO 2000 PROVOU O VALOR DOS LEGADOS

O texto cita algo brilhante:
o bug do milênio.

E isso é importantíssimo historicamente.

O QUE FOI O Y2K?

Muitos sistemas armazenavam ano com 2 dígitos:

O medo era:
2000 virar “00”
e sistemas interpretarem:
1900.

O QUE AS EMPRESAS FIZERAM?

Elas tiveram duas opções:

OPÇÃO 1

Reescrever tudo.

OPÇÃO 2

Corrigir os sistemas existentes.

A maioria escolheu:

corrigir.

Por quê?

Porque:

era mais seguro,
mais barato,
menos arriscado,
mais previsível.

Isso já mostrava:
o legado tinha valor demais para ser descartado.

A GRANDE VERDADE:

O LEGADO CARREGA O CONHECIMENTO DA EMPRESA

Isso é uma das ideias mais profundas do texto.

Muitos sistemas legados:

NÃO possuem documentação completa,
NÃO possuem diagramas UML,
NÃO possuem arquitetura formal moderna.

Mas possuem algo mais valioso:

décadas de comportamento validado em produção.

“A VERDADE ESTÁ NOS FONTES”

Essa frase do texto é fantástica.

Porque ela descreve exatamente a realidade do maintainer.

Em muitos ambientes:

o código é a documentação,
o batch é a documentação,
o JCL é a documentação,
o SYSIN é a documentação,
o histórico de incidentes é a documentação.

O DRAMA DA MANUTENÇÃO EVOLUTIVA

Aqui o texto entra numa crítica extremamente importante.

Existe um erro clássico:
querer aplicar metodologias modernas de desenvolvimento em sistemas construídos há 30 anos.

EXEMPLO PRÁTICO

Imagine exigir:

microsserviços,
DDD,
UML completa,
Swagger,
pipelines modernos,
arquitetura hexagonal,

num sistema:

monolítico,
batch,
COBOL,
VSAM,
CICS,
DB2,
sem documentação formal.

Isso frequentemente vira:

burocracia,
atraso,
custo,
documentação inútil.

O QUE REALMENTE AJUDA EM LEGADO?

O texto sugere algo muito mais inteligente:

1. Engenharia reversa

Entender o sistema a partir do código.

2. Refactoring gradual

Melhorar sem destruir.

3. Ferramentas cognitivas

Usar IA para:

mapear fluxos,
identificar impacto,
localizar regras de negócio.

4. Modelagem baseada no que EXISTE

E não no que seria “ideal”.

A ANALOGIA DO MÉDICO É BRILHANTE

Essa é uma das melhores partes do texto.

O autor compara:

sistemas em produção
com
pacientes em emergência.

E isso é MUITO real.

CENÁRIO REAL DE PRODUÇÃO

02:13 da madrugada

Um job crítico ABENDA.

Impacto:

folha de pagamento parada,
TED não enviada,
PIX inconsistente,
faturamento bloqueado.

O analista precisa:

PASSO 1 — IDENTIFICAR O SINTOMA

qual JOB falhou?
qual step?
qual ABEND?
qual dataset?
qual SQLCODE?

PASSO 2 — INVESTIGAR A CAUSA

Pode ser:

espaço,
índice inválido,
deadlock,
arquivo corrompido,
retorno incorreto,
problema lógico.

PASSO 3 — INTERVIR SEM PIORAR

Aqui mora o perigo.

Uma correção mal feita pode:

corromper milhões de registros,
causar inconsistência contábil,
derrubar outros sistemas.

PASSO 4 — RESTABELECER O SERVIÇO

O objetivo é:

restaurar operação rapidamente,
preservar integridade,
minimizar impacto financeiro.

Isso exige:

raciocínio,
experiência,
leitura de dump,
análise sistêmica,
sangue frio.

POR QUE ISSO VICIA?

Porque existe adrenalina intelectual.

Você:

investiga,
correlaciona,
deduz,
testa hipóteses,
encontra causa raiz,
salva produção.

É quase trabalho investigativo.

O QUE O MERCADO NÃO ENTENDE

Muitos enxergam:
“programador COBOL”.

Mas o profissional legado experiente normalmente entende:

negócio,
processamento,
arquitetura,
performance,
banco de dados,
recovery,
segurança,
integração,
operação.

Frequentemente ele é:

o verdadeiro guardião operacional da empresa.

O PARADOXO DO LEGADO

Quanto mais importante o sistema:

menos ele pode falhar,
menos ele pode mudar radicalmente.

Por isso:
os sistemas mais críticos do mundo
costumam ser os mais antigos.

PASSO A PASSO:

COMO UM PROFISSIONAL DE LEGADO EVOLUI

NÍVEL 1 — SOBREVIVÊNCIA

Aprende:

JCL,
COBOL,
logs,
abends.

NÍVEL 2 — ENTENDIMENTO

Começa a:

ler fluxos,
entender batch,
mapear integrações.

NÍVEL 3 — ANÁLISE

Consegue:

fazer troubleshooting,
identificar impacto,
otimizar processos.

NÍVEL 4 — VISÃO SISTÊMICA

Entende:

negócio,
arquitetura corporativa,
operação enterprise.

NÍVEL 5 — REFERÊNCIA

Vira:

mentor,
resolvedor de crises,
especialista raro.

A GRANDE LIÇÃO DO TEXTO

Sistemas legados não sobreviveram por acidente.

Eles sobreviveram porque:

funcionam,
escalam,
são resilientes,
carregam décadas de conhecimento,
sustentam operações críticas do planeta.

CONCLUSÃO

O texto desmonta a visão superficial de que:
“legado é lixo tecnológico”.

Na prática:

legado é engenharia viva,
conhecimento acumulado,
estabilidade operacional,
patrimônio corporativo.

E existe algo quase poético nisso:

Muitos sistemas modernos nascem já pensando em substituição.

Os legados nasceram para durar.

E duraram tanto…
que acabaram sustentando o mundo inteiro.

terça-feira, 14 de maio de 2013

🧾 COBOL 4.00 no IBM Mainframe

Guia para Iniciantes: Código Limpo, Seguro e Econômico

“COBOL 4 não perdoa código ruim.
Ele executa… e te cobra por isso.”

🕰️ Um Pouco de Contexto (Por que COBOL 4 importa)

O Enterprise COBOL 4.00 marcou uma virada de chave no mainframe:

Introduziu um novo compilador
Passou a gerar código mais próximo da arquitetura moderna
Começou a penalizar código antigo e relaxado

👉 Muitos programas antigos funcionam, mas:

Gastam mais CPU
Usam mais memória
Sofrem em batch pesado

🧱 Estrutura Básica de um Programa COBOL (Visão Rápida)


IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Para iniciantes:

DATA DIVISION mal feita = desastre
PROCEDURE DIVISION confusa = CPU jogada fora

⚠️ Grandes Perigos para Iniciantes no COBOL 4

☠️ 1. Código que “funciona” mas custa caro

Exemplo perigoso:


PERFORM UNTIL EOF
   READ ARQ
   MOVE CAMPO-A TO CAMPO-B
END-PERFORM

❌ MOVE desnecessário dentro do loop
❌ Loop sem controle de volume

✅ Melhor prática:


READ ARQ AT END
   SET EOF TO TRUE
END-READ

E só mover o que for necessário.

☠️ 2. PERFORM Excessivo (Modular demais mata CPU)

Iniciantes adoram:


PERFORM TRATA-REGISTRO

dentro de loop com milhões de registros.

⚠️ Cada PERFORM é custo.

✔️ Dica:

Inline lógica crítica
Use PERFORM para controle, não para micro-rotinas

☠️ 3. Variáveis mal definidas (memória desperdiçada)

Erro clássico:


01 WS-VALOR     PIC X(1000).

Quando só precisa de 10 bytes 😱

✔️ Regra de ouro:

PIC do tamanho exato
Evite campos genéricos “pra garantir”

📉 Menos memória = menos cache miss = menos CPU.

☠️ 4. Repetir cálculos desnecessários

Erro comum:


COMPUTE WS-TOTAL = WS-QTD * WS-VALOR

feito várias vezes no loop com os mesmos valores.

✔️ Dica:

Calcule uma vez
Armazene
Reutilize

🧼 Como Escrever Código Mais Limpo no COBOL 4

✅ Use nomes claros


WS-VALOR-TOTAL
WS-FIM-ARQUIVO

❌ Evite:


WS-A
WS-X1

✅ Evite lógica escondida

Código perigoso:


IF A = B
   MOVE X TO Y
ELSE
   IF C = D
      MOVE Z TO Y
   END-IF
END-IF

✔️ Melhor:

Clareza > esperteza
COBOL foi feito para ser legível

🚀 Performance no COBOL 4: Dicas Práticas

⚙️ 1. Tire código de dentro de loops

Cada instrução dentro de loop custa N vezes.

⚙️ 2. Use corretamente os níveis da DATA DIVISION

Campos agrupados bem definidos
Evite REDEFINES desnecessário

REDEFINES mal usado = bugs silenciosos.

⚙️ 3. Cuidado com STRING e UNSTRING

Eles são poderosos… e caros.

✔️ Use apenas quando necessário
✔️ Evite em loops grandes

⚙️ 4. Arquivos: leia com cuidado

READ sequencial é barato
READ aleatório é caro
Releitura custa CPU e I/O

🧠 Pontos de Atenção que Geram Bugs em Produção

Armadilha	Problema
Campo não inicializado	Resultado imprevisível
EOF mal tratado	Loop infinito
IF aninhado demais	Erro lógico
REDEFINES confuso	Dados corrompidos
Índices fora do limite	ABEND

🧙 Curiosidades & Easter Eggs COBOL 4

COBOL 4 foi o primeiro passo real rumo ao COBOL 5
Programas antigos compilam, mas podem custar o dobro de CPU
O compilador já “entende” melhor a arquitetura do zSeries

🧭 Primeiros Passos Recomendados para Padawans

Aprenda estrutura limpa
Evite copiar código velho sem entender
Sempre pense:

“Isso vai rodar quantas vezes?”
Meça CPU quando possível
Menos código = menos custo

🏁 Conclusão

COBOL 4.00 é:

Estável
Poderoso
Implacável com código mal escrito

“No mainframe, não existe código inocente.
Só código caro ou econômico.”

sexta-feira, 27 de fevereiro de 2004

💾 Quando o COBOL ainda era Rei e o compilador 3.3 era o trono.

Codificando em cobol no Banco Real na Avenida Paulista

💾 EL JEFE MIDNIGHT LUNCH — Bellacosa Mainframe Edition

“Quando o COBOL ainda era Rei e o compilador 3.3 era o trono.”

🕰️ IBM Enterprise COBOL 3.3 — o meio do caminho entre o clássico e o moderno

Lançado em 1996, o Enterprise COBOL for z/OS Version 3 Release 3 (ou simplesmente COBOL 3.3) foi um divisor de águas entre a era dos mainframes MVS/ESA e o nascimento do z/OS. Ele marcou a última geração “pré-Enterprise 4.x”, onde o foco era compatibilidade com códigos legados e início da transição para novas arquiteturas do System/390.

🧠 Contexto histórico:
O mundo corporativo ainda respirava Year 2000 (Y2K) e os bancos se preparavam para rodar seus batchs sem colapsar em 01/01/2000. COBOL 3.3 foi o herói silencioso dessa missão.

🖥️ Sistema Operacional e Hardware Suportado

Sistema operacional: MVS/ESA, OS/390 (ainda antes do z/OS).
Arquitetura: IBM System/390.
Ambiente típico: CICS, IMS, DB2 e JCL puro no batchão da madrugada.
Compilador predecessor: COBOL 3.2 (1994).
Sucessor direto: Enterprise COBOL 4.1 (2007).

⚙️ O que mudou em relação ao COBOL 3.2

COBOL 3.3 não reinventou a roda — ele poliu o aro.
Foi uma versão mais otimizada e estável, que consolidou recursos introduzidos no 3.2 e preparou terreno para o salto à arquitetura de 64 bits.

Principais evoluções:

🔹 Melhor integração com DB2 e CICS, com suporte refinado ao EXEC SQL e EXEC CICS.
🔹 Melhoria no desempenho de I/O, especialmente em acessos VSAM e sequenciais.
🔹 Aprimoramento do OPTIMIZER, gerando código objeto mais rápido e leve.
🔹 Suporte estendido ao compilador LE (Language Environment), o que permitia rodar COBOL junto de C, PL/I e outras linguagens IBM sob o mesmo runtime.
🔹 Melhor diagnóstico de erros com mensagens mais detalhadas — uma revolução para quem vinha do COBOL VS II.

🚀 Novidades que empolgaram na época

Uso mais intensivo do LE Runtime — Adeus aos abends misteriosos!
Melhor suporte a variáveis longas e strings dinâmicas.
Compatibilidade maior com compiladores anteriores — o que permitiu modernizar sistemas sem reescrever tudo.
Introdução de novos níveis de OPT (otimização), permitindo ajustar performance por job.

💡 Dica Bellacosa: sempre compile COBOL 3.3 com OPT(2) em ambientes de produção — o ganho de performance em batch pode ser surpreendente.

🧩 Curiosidades que só o velho JCL lembra

Muitos ambientes migraram para o 3.3 apenas para garantir compatibilidade Y2K.
O compilador era notoriamente mais lento que o 3.2 em máquinas pequenas, mas o executável final rodava mais rápido.
Foi o primeiro COBOL Enterprise oficialmente integrado ao LE/370, abrindo caminho para o “z-Cobol moderno”.
Nos laboratórios da IBM em Poughkeepsie, era chamado internamente de “The Reliable Beast”.

🧙‍♂️ Macetes de Mestre Jedi

Compile sempre com LIST, XREF e OFFSET — esses relatórios são ouro quando o abend te visita às 3h da manhã.
Atenção ao CALL ‘CEE3PRM’ — muitos esqueciam de ajustar parâmetros LE, e o programa travava por stack overflow.
Recompile VS Rebind: se o programa interage com DB2, recompile sempre após rebind de planilhas.
Cuidado com o nível de compilador no CICS — o mismatch entre DFHEIBLK e CICS level era um pesadelo comum.

📚 Para os Padawans

Se você é novo no Mainframe, saiba:

COBOL 3.3 é o elo perdido entre o COBOL “clássico” e o Enterprise moderno.
Ele foi a base sobre a qual nasceram os COBOL 4.x, 5.x e 6.x, que hoje dominam o z/OS.
Aprender 3.3 é entender as raízes do desempenho e da estabilidade que tornaram o mainframe o que ele é.

🏁 Resumo Bellacosa Mainframe

Versão	Lançamento	SO	Destaques	Curiosidades
COBOL 3.2	1994	MVS/ESA	Introdução ao LE, CICS integrado	Primeiro a usar LE/370
👉 COBOL 3.3 👈	1996	MVS/ESA, OS/390	Otimização, DB2/CICS refinados, melhor I/O	Usado em massa no Y2K
COBOL 4.1	2007	z/OS	64 bits, XML, Web Services	Marco da era zEnterprise

☕ Fechando o café da madrugada

COBOL 3.3 foi aquele compilador que não aparecia nas manchetes, mas segurou o mundo.
Enquanto os bancos se preocupavam com o bug do milênio, ele trabalhava incansável, compilando batchs que rodariam por décadas.
Foi o “meio-termo perfeito” — sólido, compatível e pronto para o novo milênio.

“No z/OS, o tempo passa diferente. Uma versão de COBOL pode durar mais que muitos casamentos.”
— El Jefe, 1999.

Translate

terça-feira, 9 de junho de 2026

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

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

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

O Gigante Invisível Nunca Foi Embora

O Dia em Que o Mainframe Conheceu o VS Code

Zowe: A Ponte Entre Dois Mundos

Open Mainframe Project: O Movimento Que Mudou Tudo

O Git Finalmente Chegou ao Mainframe

DevOps Não É Apenas Moda

CI/CD Também Chegou ao COBOL

Testes Automatizados: O JUnit do Mainframe

APIs: O Mainframe Conversa Com Tudo

UTF-8: O COBOL Aprendeu Novos Idiomas

Multithreading e Performance

O Papel da Inteligência Artificial

O Novo Programador Mainframe

O Futuro Já Chegou

segunda-feira, 8 de junho de 2026

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

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

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

O Que é o IBM COBOL Check?

Quem Criou o COBOL Check?

Quando Foi Lançado?

O Problema Que Ele Resolve

A Grande Ideia

Código

Teste

Execução

Como Funciona Internamente?

Sistemas Suportados

IBM z/OS

Dependências

Compilador COBOL

Ambiente z/OS

Ferramentas modernas

Como Instalar

1. Obter o projeto

2. Fazer upload

3. Compilar

4. Configurar bibliotecas

5. Validar instalação

Primeiro Exemplo Passo a Passo

Programa

Cenário de Teste

Caso de Teste

Resultado

Testando Múltiplos Cenários

Caso 1

Caso 2

Caso 3

Assertions

Mocks

Exemplo Conceitual

Stubs

Relatórios

HTML

XML

Integração com Jenkins

Integração com Git

Benefícios Para Bancos

Curiosidade #1

Curiosidade #2

Curiosidade #3

Dicas de Ouro

Dica 1

Dica 2

Dica 3

Dica 4

Dica 5

Erros Comuns

Erro 1

Erro 2

Erro 3

Easter Egg Mainframe ☕

Conclusão

sexta-feira, 29 de novembro de 2024

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO