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

 

 

Bellacosa Mainframe e o laboratorio pratico de COBOL

☕ Um Café no Bellacosa Mainframe

Laboratório Prático de COBOL Mainframe

Este laboratório foi desenvolvido utilizando uma metodologia de aprendizagem incremental, semelhante ao treinamento de um Padawan: cada exercício introduz um novo conceito, reforça os conhecimentos anteriores e prepara o aluno para o próximo desafio. A ideia não é apenas aprender comandos da linguagem COBOL, mas compreender como um programador de Mainframe pensa, organiza e resolve problemas de negócio.

Durante a execução dos laboratórios, preste atenção principalmente na estrutura dos programas, na nomenclatura das variáveis, na organização das divisões (DIVISION, SECTION e PARAGRAPH), na indentação do código e nas mensagens emitidas pelo compilador. Um bom desenvolvedor COBOL dedica mais tempo entendendo a lógica do programa do que simplesmente escrevendo instruções.

Evite copiar e colar as soluções. Antes de consultar o gabarito, tente resolver cada exercício sozinho. Os erros fazem parte do aprendizado e ajudam a desenvolver o raciocínio lógico necessário para ambientes corporativos.

Ao concluir cada laboratório, faça pequenas modificações no programa: altere valores, acrescente novos campos, crie validações e experimente diferentes abordagens. Essa prática fortalece a compreensão da linguagem e aumenta sua confiança.

Para evoluir, revise frequentemente os laboratórios anteriores, leia códigos escritos por outros desenvolvedores, estude JCL, VSAM, Db2 e CICS paralelamente e mantenha uma rotina constante de prática. No Mainframe, experiência é construída linha por linha, programa por programa e desafio após desafio.

20 Labs para Transformar um Jovem Aprendiz em um Programador COBOL Padawan

Objetivo: Este laboratório foi criado para quem possui apenas conhecimentos básicos de informática (Windows, arquivos, pastas e editores de texto) e deseja aprender COBOL de forma prática, evoluindo passo a passo até os primeiros programas profissionais em IBM Mainframe.

Cada laboratório foi organizado da seguinte forma:

• 🎯 Objetivo

• 📚 O que você aprenderá

• 🛠️ Passo a passo

• 💻 Exercício

• ✅ Solução comentada

• 💡 Dicas Bellacosa

• ☕ Curiosidade Mainframe

---

LAB 01 – Seu Primeiro "Hello World"

🎯 Objetivo

Aprender a estrutura básica de um programa COBOL.

📚 Conceitos

• IDENTIFICATION DIVISION

• PROCEDURE DIVISION

• DISPLAY

• STOP RUN

🛠️ Passo a passo

1. Crie um novo programa.

2. Dê o nome HELLO001.

3. Digite a estrutura mínima.

4. Compile.

5. Execute.

💻 Exercício

Exiba:

Olá Mainframe!

✅ Solução

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO001.

PROCEDURE DIVISION.
    DISPLAY "OLA MAINFRAME!"
    STOP RUN.

💡 Dicas

Sempre utilize nomes significativos.

Evite nomes como:

AAA001
TESTE99
PROGRAMA1

Prefira:

CLIENTE
CALCSAL
FATURA

☕ Curiosidade

Um programa COBOL pode conter dezenas de milhares de linhas sem perda de legibilidade quando bem organizado.

---

LAB 02 – Conhecendo as DIVISIONS

Objetivo

Entender a organização de um programa COBOL.

Aprender:

• Identification

• Environment

• Data

• Procedure

Exercício

Adicione todas as DIVISIONS mesmo que estejam vazias.

Curiosidade

Essa organização existe desde 1959.

Ainda funciona perfeitamente.

---

LAB 03 – Variáveis (WORKING-STORAGE)

Aprender:

• PIC X

• PIC 9

• VALUE

Exercício

Criar:

Nome
Idade
Cidade

Mostrar na tela.

Solução

Utilizar DISPLAY para cada variável.

Dica

Pense na WORKING-STORAGE como a memória RAM do programa.

---

LAB 04 – MOVE

Aprender:

MOVE

Exercício

Mover:

JOÃO

para

CLIENTE

Depois mostrar.

Curiosidade

MOVE é uma das instruções mais utilizadas do COBOL.

---

LAB 05 – Matemática

Aprender

ADD

SUBTRACT

MULTIPLY

DIVIDE

COMPUTE

Exercício

Criar uma calculadora simples.

Entrada:

10

20

Saída:

Soma

Subtração

Multiplicação

Divisão

Dica

Prefira COMPUTE quando a expressão ficar grande.

---

LAB 06 – IF

Aprender decisões.

Exercício

Se idade >=18

Mostrar

MAIOR

Senão

MENOR

Curiosidade

IF aninhado pode ficar difícil de ler.

Nos próximos labs veremos alternativas melhores.

---

LAB 07 – EVALUATE

Aprender o "switch" do COBOL.

Exercício

Digite:

1
2
3

Mostrar:

Janeiro

Fevereiro

Março

Dica Bellacosa

Muitos programadores usam IF.

Os experientes preferem EVALUATE.

---

LAB 08 – PERFORM

Criar laços.

Exercício

Mostrar:

1

2

3

...

10

Aprender

PERFORM VARYING

---

LAB 09 – Tabelas

Aprender:

OCCURS

Exercício

Cadastrar

5 nomes.

Mostrar todos.

Curiosidade

Aqui começa o verdadeiro poder do COBOL.

---

LAB 10 – SEARCH

Pesquisar dentro da tabela.

Exercício

Encontrar

MARIA

na lista.

Dica

Depois compare SEARCH com SEARCH ALL.

---

LAB 11 – STRING

Concatenar textos.

JOAO

+

SILVA

Resultado

JOAO SILVA

---

LAB 12 – UNSTRING

Separar:

JOAO;SILVA;25

em três campos.

Hoje isso é muito usado em integração de sistemas.

---

LAB 13 – Arquivos Sequenciais

Criar arquivo.

Gravar:

ANA

CARLOS

PEDRO

Depois ler.

Curiosidade

Antes dos bancos de dados, praticamente tudo funcionava assim.

---

LAB 14 – Arquivos Indexados (VSAM)

Introdução ao KSDS.

Entender:

• Chave

• Registro

• Índice

Mesmo que o ambiente de testes utilize arquivos simplificados, o conceito prepara você para ambientes corporativos.

---

LAB 15 – Datas

Utilizar:

FUNCTION CURRENT-DATE

Mostrar:

• Ano

• Mês

• Dia

Dica

Evite criar rotinas próprias de data quando houver função intrínseca.

---

LAB 16 – Funções Intrínsecas

Explorar:

• LENGTH

• UPPER-CASE

• LOWER-CASE

• NUMVAL

• INTEGER

• RANDOM

Exercício

Converter um nome para maiúsculas e minúsculas.

---

LAB 17 – Modularização

Criar:

Programa Principal

↓

Subprograma

Enviar parâmetros.

Curiosidade

Grandes bancos possuem milhares de subprogramas reutilizados por diversos sistemas.

---

LAB 18 – SQL em COBOL

Introdução ao Embedded SQL.

Criar:

SELECT

INSERT

UPDATE

Mesmo sem Db2 instalado, entender a sintaxe e o fluxo de execução já coloca o aluno em contato com a realidade do Mainframe.

---

LAB 19 – JSON

Gerar JSON.

Utilizar:

JSON GENERATE

Depois fazer:

JSON PARSE

Curiosidade

Hoje milhares de APIs REST utilizam exatamente essas instruções para conversar com aplicativos móveis e sistemas web.

---

LAB 20 – Projeto Final

Construir um pequeno sistema de cadastro.

Funcionalidades:

• Cadastrar cliente

• Alterar cliente

• Excluir cliente

• Consultar cliente

• Relatório

• Total de clientes

• Validação de dados

• Tratamento de erros

• Mensagens amigáveis

Neste projeto, o aluno reúne praticamente todos os conceitos aprendidos nos laboratórios anteriores.

---

Dicas de Codificação que Todo Padawan Deveria Conhecer

• Escreva um programa por vez e faça-o funcionar antes de adicionar novas funcionalidades.

• Use nomes claros para variáveis: WS-NOME-CLIENTE é melhor que A1.

• Comente por que o código existe, não apenas o que ele faz.

• Padronize a indentação. Um código bem alinhado é muito mais fácil de manter.

• Evite duplicação de lógica. Se um trecho será usado várias vezes, transforme-o em um parágrafo ou subprograma.

• Compile frequentemente. Encontrar um erro logo após escrevê-lo é muito mais fácil do que depurar centenas de linhas depois.

• Leia mensagens do compilador com atenção; elas ensinam muito.

---

Easter Eggs do COBOL

🔹 EVALUATE TRUE pode substituir longas cadeias de IF.

🔹 88-Level Condition Names deixam o código muito mais legível, permitindo escrever condições como IF CLIENTE-ATIVO.

🔹 REDEFINES permite enxergar a mesma área de memória de formas diferentes, um recurso poderoso quando usado com critério.

🔹 COPYBOOKS evitam duplicação e garantem padronização entre programas.

🔹 INSPECT pode substituir diversos loops para contar ou substituir caracteres.

🔹 INITIALIZE é uma forma elegante de limpar grupos inteiros de variáveis.

🔹 PERFORM THRU, apesar de existir, deve ser usado com cautela em novos projetos.

---

Como Evoluir Após os 20 Labs

Se você concluiu todos os laboratórios, já domina uma base sólida de COBOL. O próximo passo é expandir seu conhecimento para o ecossistema IBM Z.

Uma trilha recomendada é:

1. JCL (Job Control Language)

2. TSO/ISPF

3. VSAM

4. Db2 for z/OS

5. CICS Transaction Server

6. IMS DB/DC

7. SORT (DFSORT e SyncSort)

8. REXX

9. Git e GitHub

10. VS Code + Zowe Explorer

11. DevOps para Mainframe

12. APIs REST com z/OS Connect

13. IBM MQ

14. Testes com ZUnit

15. Observabilidade, OpenTelemetry e automação com Ansible

Ao final dessa jornada, o aluno deixa de ser apenas um iniciante e passa a compreender como os grandes bancos, seguradoras e empresas de cartão de crédito desenvolvem e mantêm sistemas que processam milhões de transações diariamente.

Conclusão

Estes 20 laboratórios foram pensados para ensinar COBOL da mesma forma que um mestre Jedi ensina um Padawan: começando pelos fundamentos, praticando continuamente e aumentando a dificuldade de forma gradual. Em vez de decorar comandos, o aluno aprende a raciocinar como um desenvolvedor Mainframe, compreendendo não apenas como escrever código, mas por que determinadas práticas existem e como elas contribuem para criar sistemas robustos, seguros e preparados para décadas de evolução.

 

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'

ou

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

ou

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

 

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?”

 

 

Bellacosa Mainframe e o ibm mq muito alem das filas

IBM MQ: Muito Além das Filas — A Engenharia Invisível que Mantém Grandes Empresas em Movimento

"Se o banco autorizou seu PIX, a companhia aérea confirmou sua passagem e a operadora aprovou sua compra no cartão em poucos segundos, existe uma boa chance de que o IBM MQ tenha participado dessa conversa silenciosa entre sistemas."

A comparação entre administrar filas de mensagens e controlar o tráfego aéreo é extremamente feliz. Em ambos os casos, o objetivo não é apenas transportar algo de um ponto ao outro, mas garantir que cada "passageiro" (mensagem) chegue ao destino correto, na ordem adequada, sem colisões, sem perdas e com total rastreabilidade.

É justamente essa capacidade que fez do IBM MQ um dos pilares da integração corporativa por mais de três décadas.

Enquanto novas tecnologias aparecem todos os anos, o MQ permanece praticamente onipresente em bancos, seguradoras, bolsas de valores, empresas de logística, telecomunicações, governos e indústrias.

Isso acontece porque ele resolve um problema que nunca deixou de existir:

Como permitir que dezenas ou centenas de sistemas diferentes conversem entre si de forma confiável?

---

O verdadeiro problema não é enviar mensagens

Enviar uma mensagem é fácil.

Um socket TCP faz isso.

Uma API REST também.

Um POST HTTP consegue transportar informações perfeitamente.

O problema começa quando surgem perguntas muito mais difíceis:

• E se o sistema destino estiver indisponível?

• E se a rede cair durante a transmissão?

• E se o consumidor estiver mais lento que o produtor?

• E se houver milhares de mensagens por segundo?

• Como garantir que nenhuma mensagem seja perdida?

• Como recuperar mensagens após um desastre?

• Como processar tudo exatamente uma única vez?

É aqui que o IBM MQ mostra por que continua sendo referência.

Ele não é apenas um mecanismo de envio.

Ele é um sistema completo de entrega garantida.

---

Local Queues: o coração do Queue Manager

O texto começa destacando as Local Queues.

Pode parecer apenas um objeto simples.

Na prática, elas representam o ponto onde toda a arquitetura converge.

Quando um programa COBOL executa:

MQPUT

ele normalmente está gravando em uma Local Queue.

Quando um programa Java faz:

put(message)

também.

Quando um serviço REST recebe uma requisição e publica uma mensagem...

...novamente estamos falando de uma Local Queue.

Ela é o "disco de pouso" das mensagens.

---

O ciclo de vida de uma fila

O artigo cita o CRUD clássico.

Mas cada comando tem implicações importantes.

DEFINE

Criar uma fila significa estabelecer diversas políticas:

• persistência

• tamanho máximo

• profundidade

• prioridade

• triggering

• cluster

• segurança

• compartilhamento

Não é simplesmente "criar uma pasta".

É definir comportamento operacional.

---

LIKE

Pouca gente utiliza adequadamente:

DEFINE QLOCAL(NOVA.FILA)
LIKE(FILA.MODELO)

Esse comando economiza horas.

Imagine uma organização com:

• MAXDEPTH

• DEFPSIST

• SHARE

• TRIGGER

• MONQ

• HARDENBO

todos configurados segundo padrões corporativos.

Copiar a definição evita inconsistências.

Em ambientes regulados isso é praticamente obrigatório.

---

ALTER

Alterar filas em produção exige cuidado.

Exemplo:

ALTER QLOCAL(PAGAMENTOS)
MAXDEPTH(500000)

Parece inocente.

Mas alterar atributos pode afetar:

• performance

• consumo de disco

• comportamento das aplicações

Administradores experientes sempre avaliam o impacto antes de executar alterações.

---

CLEAR

Este comando merece respeito.

CLEAR QLOCAL(TESTE)

Ele elimina todas as mensagens.

Não existe "desfazer".

Jamais deve ser utilizado em produção sem absoluta certeza.

---

DELETE

Excluir uma fila exige planejamento.

Muitas aplicações dependem daquele objeto.

Apagar uma queue errada pode derrubar diversos sistemas ao mesmo tempo.

---

Filas maiores que 2 TB

Esse detalhe passa despercebido por muitos profissionais.

Quando pensamos em filas normalmente imaginamos alguns megabytes.

Na realidade, grandes bancos mantêm milhões de mensagens simultaneamente.

Imagine:

• processamento noturno

• liquidação financeira

• cartões

• PIX

• TED

• boletos

Durante picos, enormes volumes permanecem temporariamente armazenados.

O MQ foi projetado para esse cenário.

---

Remote Queues: desacoplamento arquitetural

Talvez este seja o ponto mais elegante do artigo.

Uma Remote Queue não contém mensagens.

Ela contém conhecimento.

Conhecimento sobre onde determinada mensagem deve chegar.

Esse conceito é chamado de indireção.

Na Engenharia de Software, indireção é uma das técnicas mais poderosas para reduzir acoplamento.

---

Sem Remote Queue

Aplicação precisa conhecer:

• servidor

• porta

• canal

• queue manager

• fila destino

Toda alteração exige nova implantação.

---

Com Remote Queue

A aplicação apenas envia:

MQPUT
CLIENTES

O administrador decide:

• qual servidor

• qual Queue Manager

• qual canal

• qual rota

A aplicação permanece completamente ignorante da infraestrutura.

Esse desacoplamento reduz drasticamente custos de manutenção.

---

Uma analogia simples

Imagine enviar uma carta.

Sem MQ:

Você escreve diretamente o endereço completo.

Se o destinatário mudar de prédio, precisa reenviar todas as cartas.

Com MQ:

Você entrega a carta para a central de distribuição.

Ela sabe exatamente para onde encaminhar.

O remetente nunca precisa conhecer a rota.

---

RNAME, RQMNAME e XMITQ

Esses três atributos representam praticamente a tabela de roteamento do MQ.

RNAME

Destino real.

PAGAMENTOS

---

RQMNAME

Qual Queue Manager administra essa fila.

Pode estar em outra cidade.

Outro país.

Outro datacenter.

---

XMITQ

A "rodovia".

Ela guarda mensagens enquanto aguardam transporte.

Caso a comunicação seja interrompida, elas permanecem armazenadas.

Quando o canal voltar, seguem viagem automaticamente.

É uma fila de espera extremamente inteligente.

---

A beleza da transparência

O usuário destaca um benefício enorme:

Trocar infraestrutura sem alterar código.

Esse talvez seja o maior presente que um administrador pode oferecer aos desenvolvedores.

Mudanças ficam concentradas na infraestrutura.

Aplicações permanecem intactas.

Essa separação de responsabilidades é um princípio clássico de arquitetura corporativa.

---

Model Queues

Pouca gente conhece.

Menos gente ainda utiliza.

Imagine milhares de clientes conectados simultaneamente.

Cada um precisa de uma fila temporária.

Criar manualmente seria impossível.

A Model Queue resolve isso.

Ela funciona como uma classe em programação orientada a objetos.

A partir dela o MQ cria filas temporárias dinamicamente.

É extremamente elegante.

---

Services

Outro recurso subestimado.

Muitos sistemas precisam iniciar automaticamente processos auxiliares.

Por exemplo:

• daemon Java

• listener

• programa C

• script Shell

Em vez de depender do sistema operacional, o próprio MQ pode controlar esse ciclo de vida.

Resultado:

menos scripts

menos automações

menos pontos de falha.

---

Triggering

Aqui entramos em automação pura.

Imagine um supermercado.

Quando chegam dez clientes na fila do caixa...

automaticamente outro caixa é aberto.

Triggering faz exatamente isso.

Quando uma fila atinge determinada condição:

• inicia um programa

• desperta um consumidor

• executa um processamento Batch

• chama um serviço

Sem intervenção humana.

É um dos recursos mais antigos do MQ e continua extremamente eficiente.

---

dmpmqmsg

Administradores antigos ainda chamam de qload.

É praticamente um "canivete suíço".

Permite:

• backup

• restauração

• migração

• cópia

• exportação

• importação

Durante migrações entre ambientes ele costuma ser indispensável.

---

O comentário mais importante

O autor encerra com uma observação extremamente verdadeira:

A maioria dos problemas não está no IBM MQ.

Quem administra middleware sabe disso.

Quando algo "não chega", normalmente o MQ está funcionando exatamente como deveria.

Os problemas costumam estar em:

• aplicações

• canais bloqueados

• certificados expirados

• permissões OAM

• firewalls

• DNS

• Cluster Receiver

• Channel Authentication (CHLAUTH)

• SSL/TLS

• regras de roteamento

• filas de transmissão congestionadas

O MQ normalmente apenas evidencia problemas existentes em outras camadas.

---

Linha de comando versus MQ Explorer

Essa pergunta desperta quase uma divisão filosófica.

MQ Explorer

Vantagens:

• visual

• intuitivo

• excelente para iniciantes

• facilita inspeções rápidas

Desvantagens:

• menos automatizável

• difícil em grandes ambientes

---

MQSC

Vantagens:

• rapidez

• scripts

• versionamento

• automação

• DevOps

• auditoria

Administradores experientes frequentemente preferem:

runmqsc

porque conseguem reproduzir alterações em dezenas de servidores utilizando exatamente os mesmos comandos.

Infrastructure as Code começa justamente aqui.

---

Uma reflexão arquitetural

O maior mérito do IBM MQ nunca foi apenas transportar mensagens.

Seu verdadeiro valor está em separar aplicações da infraestrutura.

Essa separação permite que empresas mudem servidores, troquem sistemas operacionais, modernizem datacenters, migrem para containers, integrem APIs REST, conectem aplicações em nuvem e mantenham sistemas COBOL escritos há décadas funcionando exatamente da mesma forma.

É uma demonstração clássica de engenharia de software bem executada: o produtor não precisa conhecer o consumidor, o consumidor não precisa conhecer o produtor e ambos continuam evoluindo de forma independente. Esse desacoplamento reduz riscos, facilita modernizações graduais e garante continuidade operacional — razão pela qual o IBM MQ permanece essencial em arquiteturas de missão crítica, mesmo em uma era dominada por microsserviços, APIs REST, eventos e plataformas em nuvem.

Em outras palavras, o IBM MQ não é apenas um produto de mensageria. Ele é uma camada estratégica de integração que protege as aplicações das mudanças inevitáveis da infraestrutura, permitindo que empresas inovem sem comprometer a estabilidade de seus sistemas mais críticos. É essa combinação de confiabilidade, escalabilidade e abstração que explica por que, mais de 30 anos após seu lançamento, o IBM MQ continua sendo um dos componentes mais respeitados e utilizados no ecossistema IBM Z e nas grandes arquiteturas corporativas.

 

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:

• 98

• 99

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.

 

⚙️ IBM System z12 – O Coração Digital da Nova Economia

O mainframe que trouxe velocidade, inteligência e integração para a era do Big Data.

---

🧭 Introdução Técnica

Em 2015, a IBM apresentou o System z13, mas antes dele, em 2012, o System zEnterprise EC12 (z11) pavimentou o caminho. Porém, a família z12 consolidou o amadurecimento da arquitetura híbrida e da computação analítica.
O System zEnterprise BC12 (zBC12) — lançado em 2013 e às vezes chamado de System z12 em contextos comerciais — marcou a transição entre o poder bruto do z11 e a eficiência inteligente do z13.

O z12 foi um mainframe projetado para a era dos aplicativos móveis, do analytics em tempo real, e das transações seguras em escala global.
Seu diferencial: processadores mais rápidos, zAware aprimorado, compressão mais eficiente e integração com ambientes x86 via zBX (zBlade Extension).

---

🕰️ Ficha Técnica – IBM System z12

Item	Detalhe
Ano de Lançamento	2013
Modelos	zEnterprise BC12 (zBC12)
CPU	4,2 GHz, quad-core (tecnologia refinada 32 nm CMOS)
Arquitetura	IBM z/Architecture (64 bits)
Sistema Operacional	z/OS 2.1 – 2.2
Memória Máxima	512 GB
Antecessor	zEnterprise EC12 (System z11)
Sucessor	z13 (2015)

---

🔄 O que muda em relação ao System z11 (EC12)

1. Nova Escala de Acesso: O z12 (BC12) trouxe o poder do z11 para empresas médias, com custo reduzido e mesmo nível de resiliência.

2. Desempenho: 36% mais rápido por core em relação ao z10 BC, e 2x mais rápido no throughput geral.

3. Eficiência Energética: redução de até 30% no consumo de energia por MIPS.

4. zAware 2.0: o sistema de autodiagnóstico analítico foi aprimorado com inteligência baseada em padrões comportamentais.

5. zEDC (Enterprise Data Compression): até 80% de economia de I/O e disco.

6. Criptografia: CryptoExpress4S com aceleração para AES, RSA, ECC e SHA-3.

7. Suporte aprimorado a Linux on Z: mais LPARs, IFLs e integração direta com z/VM 6.3.

8. Virtualização Avançada: PR/SM com balanceamento dinâmico entre engines zIIP, zAAP e IFL.

---

🧠 Curiosidades Bellacosa

• Apesar do nome comercial zBC12, a IBM o apresentou como parte da família z12, pois compartilhava o mesmo núcleo tecnológico do zEC12.

• Foi o primeiro mainframe a permitir total integração com nuvens privadas e móveis, com suporte nativo a IBM Cloud Manager.

• O z12 tinha o lema de marketing “Designed for Mobile, Cloud and Big Data”, refletindo o início da era dos smartphones e apps bancários.

• Em ambiente Linux on Z, o z12 podia consolidar até 8.000 servidores x86 virtuais em um único frame.

• O visual mantinha o design preto e prata da linha zEnterprise, mas com um painel mais compacto e sistema de resfriamento redesenhado.

• O z12 foi o último a usar zEnterprise BladeCenter Extension (zBX), antes da IBM migrar definitivamente para integração via software.

---

💾 Nota Técnica

• Clock: 4,2 GHz (quad-core)

• Cache: L1 – 64 KB, L2 – 3 MB, L3 – 48 MB compartilhado

• Memória: até 512 GB

• Canais I/O: FICON Express8S, OSA-Express4, HiperSockets de alta velocidade

• Criptografia: CryptoExpress4S (RSA 4096, AES-256, SHA-3)

• Virtualização: PR/SM com Dynamic Logical Partitioning

• Firmware: HMC 2.15, zAware 2.0, Capacity on Demand instantâneo

---

💡 Dicas Bellacosa para Profissionais e Padawans

1. Entenda o z12 como elo híbrido: ele representa a consolidação entre o mainframe tradicional e o mundo das nuvens privadas.

2. Estude o zEDC: tecnologia-chave que impacta performance, compressão e custos de armazenamento até hoje.

3. Explore o zAware 2.0: foi o início do AIOps — análise comportamental de logs e predição de falhas.

4. Dica prática: o z12 BC ainda é usado em ambientes de teste para z/OS 2.2 e Linux on Z, ideal para estudos de performance tuning.

5. Curiosidade de aula: muitos z12 foram vendidos para universidades e bancos regionais como mainframe de entrada, pela confiabilidade e custo-benefício.

---

🧬 Origem e História

O System z12 nasceu como uma versão otimizada do EC12, mas voltada à democratização da plataforma Z.
Projetado nos laboratórios da IBM em Poughkeepsie (EUA) e Boeblingen (Alemanha), seu lançamento em julho de 2013 reforçou o conceito de mainframe acessível, modular e preparado para a economia digital.

O nome “zEnterprise BC12” (Business Class) marca o foco em pequenas e médias empresas, mas mantendo a mesma confiabilidade dos grandes zSystems.

---

📜 Legado e Impacto

O System z12 (zBC12) foi o último mainframe “intermediário” com o DNA clássico da série zEnterprise antes da revolução do z13.
Ele consolidou três legados fundamentais:

• Automação cognitiva (zAware 2.0)

• Compressão nativa (zEDC)

• Integração móvel e em nuvem

O z12 pavimentou a chegada do mainframe cognitivo, antecipando o que o z13 faria em escala global com Watson e Big Data.

---

☕ Conclusão Bellacosa

O IBM System z12 foi o mainframe da transição digital, onde potência encontrou inteligência.
Ele uniu a confiabilidade lendária do z11 à necessidade moderna de integração e análise.
Pequeno no tamanho, gigante no impacto.

“O z12 não foi apenas um mainframe — foi o primeiro cérebro preparado para entender o mundo conectado.”
— Bellacosa Mainframe