✨ 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
Bellacosa Mainframe fala sobre Cloud Terraform RACF
☁️🔥 Do RACF ao Terraform: Como um Padawan Mainframe Pode Dominar a Nuvem Antes que a Nuvem Domine Você
“A cloud não substituiu o mainframe. Ela apenas espalhou o mainframe pelo planeta — sem manual impresso.”
Se você vem do mundo z/OS, COBOL, CICS, JCL ou operações críticas, este artigo é para você, jovem Padawan. 🧭
Vamos traduzir Cloud Adoption + Cloud Governance + IaC + Segurança para o idioma mainframe — com exemplos reais, curiosidades e alguns easter eggs técnicos no caminho.
Bellacosa Mainframe e o game COBOL em retro 8 bits
☕ Um Café no Bellacosa Mainframe
🎮 COBOL's Laboratory — Quando o Programador COBOL Vira o Herói de um Videogame 8 Bits
Da USS Enterprise ao Nintendo Entertainment System: por que um jogo sobre COBOL é muito mais profundo do que parece
"A lógica é o início da sabedoria, não o seu fim." — Sr. Spock
Imagine acordar em 1989.
Você liga sua televisão de tubo.
Coloca um cartucho no Nintendo Entertainment System.
Aparece a clássica tela preta.
Uma música chiptune começa a tocar.
No centro da tela surge uma enorme palavra:
COBOL
Logo abaixo...
PRESS START
Nesse instante você percebe uma coisa curiosa.
Você não vai controlar um guerreiro.
Não será um ninja.
Nem um encanador italiano.
Muito menos um cavaleiro medieval.
Você será...
Dr. COBOL.
O cientista mais brilhante de toda Bit City.
Pode parecer apenas uma brincadeira criada por fãs.
Mas existe uma homenagem muito maior escondida nessa ideia.
Ela celebra uma linguagem que, discretamente, continua movimentando bancos, bolsas de valores, seguradoras, governos, companhias aéreas e sistemas críticos em praticamente todos os continentes.
E curiosamente...
Essa homenagem foi feita utilizando um videogame dos anos 80.
Parece improvável.
Mas faz todo sentido.
Hoje vamos descobrir por quê.
Pegue sua caneca de café.
O computador de bordo da USS Enterprise já calculou nossa rota.
Vamos iniciar a missão.
Capítulo 1 — O jogo realmente existe
Sim.
Não é uma montagem.
Não é IA.
Não é um conceito.
É um jogo homebrew para o Nintendo Entertainment System (NES), desenvolvido pela Oniric Factor.
Hardware original através de flash cartridges compatíveis
Ou seja...
Em pleno século XXI alguém resolveu criar um jogo inteiro onde o protagonista é...
COBOL.
Só isso já merece respeito.
Capítulo 2 — O verdadeiro significado da história
A sinopse oficial parece simples.
O cientista Dr. Cobol precisa impedir que seu antigo discípulo...
Dr. Pascal...
Roube todas as suas invenções.
Mas existe um significado escondido.
Na computação, linguagens possuem "personalidade".
COBOL nunca foi criada para fazer gráficos.
Nem jogos.
Nem inteligência artificial.
Ela nasceu para resolver problemas extremamente importantes.
folha de pagamento
contas bancárias
seguros
aposentadorias
impostos
logística
Enquanto isso...
Pascal nasceu anos depois.
Seu objetivo era completamente diferente.
Ensinar programação.
Ensinar algoritmos.
Ensinar lógica.
Percebe a genialidade?
O jogo transforma duas filosofias da computação em personagens.
Capítulo 3 — A rivalidade que nunca existiu
O jogo apresenta:
COBOL versus Pascal.
Mas isso nunca aconteceu na vida real.
Cada linguagem dominou um universo diferente.
COBOL
Pascal
Negócios
Educação
Empresas
Universidades
Bancos
Laboratórios
Sistemas críticos
Algoritmos
Processamento em lote
Estruturas de dados
Na verdade...
Elas sempre coexistiram.
O jogo apenas transforma essa diferença em uma divertida batalha entre cientistas.
Capítulo 4 — Dr. Cobol
O protagonista não é um guerreiro.
Ele é um inventor.
Isso representa perfeitamente a linguagem.
Todo sistema COBOL é uma invenção.
Cada programa resolve um problema do mundo real.
Um programa pode calcular:
aposentadorias
imposto de renda
folha salarial
juros
investimentos
previdência
Em outras palavras...
Dr. Cobol é o engenheiro responsável por manter Bit City funcionando.
Capítulo 5 — Dr. Pascal
Pascal aparece como um cientista enlouquecido.
Essa escolha lembra imediatamente personagens famosos.
Dr. Wily
Dr. Robotnik
Dr. Neo Cortex
Todos eles usam ciência para destruir.
Enquanto Cobol usa ciência para construir.
Capítulo 6 — Bit City
O próprio nome da cidade possui easter eggs.
Bit.
O menor elemento da computação.
Um único bit vale:
0
ou
1
Tudo nasce daí.
Bytes.
Arquivos.
Programas.
Mainframes.
Internet.
Tudo começou com bits.
Curiosidade Bellacosa
Algumas versões da descrição oficial citam M.O.S. City, uma referência muito provável à lendária MOS Technology, fabricante do processador 6502, um dos chips mais influentes da história. O NES utiliza uma CPU derivada desse projeto (Ricoh 2A03), conectando o universo do jogo diretamente às raízes da computação doméstica.
Capítulo 7 — O verdadeiro inimigo
As criaturas mutantes.
Elas representam o quê?
Vamos pensar como um desenvolvedor.
No mundo real nossos monstros são:
👾 Bugs
👾 Dados inválidos
👾 SQLCODE negativos
👾 ABENDs
👾 Arquivos corrompidos
👾 Chaves duplicadas
👾 Deadlocks
👾 Falhas de comunicação
Os monstros do jogo são uma metáfora perfeita.
Capítulo 8 — Se fosse um jogo de Mainframe
Imagine algumas fases.
Fase 1
HELLO WORLD
Objetivo
Aprender
IDENTIFICATION DIVISION
Fase 2
WORKING-STORAGE
Monstros:
PIC inválidos
VALUE incorreto
COMP-3 defeituoso
Fase 3
VSAM Forest
Chefão
INVALID KEY
Fase 4
JCL Mountain
Chefão
S806
Fase 5
DB2 Caverns
Chefão
SQLCODE -904
Fase 6
CICS Fortress
Chefão
AEI9
Última fase
Production
O maior inimigo de todos.
ABEND.
Capítulo 9 — Os Power-ups do Programador COBOL
Todo bom jogo possui itens especiais.
No universo Bellacosa Mainframe eles seriam:
☕
Café
Recupera energia.
Item obrigatório.
📘
Manual IBM
+30 Inteligência.
🖥
ISPF
Permite editar código.
📄
JCL
Desbloqueia novas fases.
🗂
COPYBOOK
Novos poderes.
🔐
RACF
Escudo de segurança.
💾
Load Module
Transformação definitiva.
📊
EXPLAIN PLAN
Permite prever ataques do chefão SQL.
Capítulo 10 — O paralelo com Star Trek
Aqui começa nossa viagem espacial.
Imagine a Enterprise.
Quem seria quem?
Capitão Kirk
Gerente do projeto.
Decide prioridades.
Sr. Spock
Analista de sistemas.
Pensa logicamente.
Nunca programa por impulso.
Scotty
Compilador COBOL.
Transforma código em algo executável.
Quando tudo funciona...
Ele diz:
"I'm giving her all she's got!"
Uhura
MQ Series.
Toda comunicação passa por ela.
Worf
RACF.
Nada entra sem autorização.
Data
Db2.
Memória perfeita.
Enterprise
IBM Z.
A nave mais confiável da Frota.
O Cadete
Você.
O Programador COBOL Padawan.
Capítulo 11 — Como um Padawan venceria o jogo
Missão 1
Aprender COBOL.
↓
Missão 2
Aprender JCL.
↓
Missão 3
Conhecer VSAM.
↓
Missão 4
Estudar Db2.
↓
Missão 5
Entender CICS.
↓
Missão 6
Aprender z/OS.
↓
Missão Final
Resolver um ABEND em produção.
Parabéns.
Você terminou o tutorial.
Curiosidades que poucos conhecem
🎮 O NES continua vivo
Mesmo décadas após seu lançamento, desenvolvedores independentes continuam criando jogos inéditos para o console. Essa cena é conhecida como homebrew e reúne programadores, artistas e músicos apaixonados por hardware clássico.
💾 O hardware impõe criatividade
O NES possui recursos extremamente limitados em comparação aos computadores atuais. Isso obriga os desenvolvedores a escrever código altamente otimizado, uma filosofia que lembra muito a programação em mainframes, onde eficiência e confiabilidade sempre foram essenciais.
🎵 Música chiptune
A trilha sonora de Cobol's Laboratory, composta por Kevin van der Burg, utiliza a estética sonora típica dos consoles 8 bits. Cada melodia precisa respeitar as limitações dos canais de áudio do NES, transformando restrições técnicas em criatividade.
🧠 O verdadeiro easter egg
COBOL foi criado em 1959.
O NES nasceu em 1983.
Mesmo separados por mais de duas décadas, ambos compartilham uma característica fundamental:
Foram projetados para serem confiáveis, simples de usar dentro de seus objetivos e capazes de atravessar gerações.
Easter Eggs Bellacosa Mainframe
🐣 Easter Egg #1
Dr. Pascal é um cientista.
Na vida real, Niklaus Wirth, criador da linguagem Pascal, também era um pesquisador e professor universitário.
🐣 Easter Egg #2
O personagem principal não luta com espadas.
Ele luta usando inteligência.
Como qualquer bom analista.
🐣 Easter Egg #3
PRESS START.
Essa talvez seja a melhor mensagem do jogo.
Todo desenvolvedor começa exatamente assim.
Sem experiência.
Sem atalhos.
Sem Continue.
Apenas...
START.
🐣 Easter Egg #4
Bit City representa o universo digital.
O IBM Z representa o coração dessa cidade.
Enquanto tudo parece silencioso...
Bilhões de transações acontecem.
Todos os dias.
🐣 Easter Egg #5 – A Diretriz Principal de Spock
Se o Sr. Spock fosse mentor de um programador COBOL, provavelmente diria:
"Um bom programa não impressiona por sua complexidade, mas por sua clareza. A lógica elegante reduz erros, facilita a manutenção e permite que outros compreendam seu raciocínio décadas depois."
Essa frase resume a essência do COBOL: escrever código para pessoas lerem, e não apenas para máquinas executarem.
Passo a passo para o Programador COBOL Padawan
Domine a sintaxe básica. Entenda as divisões do COBOL e escreva pequenos programas.
Aprenda JCL. Um programa precisa ser compilado e executado corretamente.
Conheça arquivos VSAM e sequenciais. Eles são a base de muitos sistemas legados.
Estude SQL e Db2. Grande parte das aplicações corporativas utiliza banco de dados.
Entenda CICS e IMS. Eles representam o processamento online de alta disponibilidade.
Aprenda a investigar ABENDs. Ler mensagens, dumps e logs faz parte da rotina.
Nunca pare de aprender. Assim como um jogo libera novas fases, o universo IBM Z sempre oferece novos desafios, como APIs, DevOps, Zowe, OpenShift e Inteligência Artificial.
Conclusão — O verdadeiro significado de "PRESS START"
À primeira vista, Cobol's Laboratory parece apenas uma divertida homenagem em pixel art a uma linguagem de programação clássica. Porém, quando observamos com atenção, percebemos algo muito maior.
Ele celebra a história da computação.
Celebra a criatividade da comunidade homebrew.
Celebra os pioneiros que construíram sistemas capazes de sobreviver por décadas.
E, acima de tudo, lembra que COBOL continua sendo um dos pilares invisíveis do mundo moderno.
Assim como a USS Enterprise não impressiona apenas por sua velocidade, mas pela confiança que inspira em cada missão, o IBM Z e o COBOL permanecem cumprindo sua missão silenciosamente: manter funcionando os sistemas que sustentam a economia global.
Da próxima vez que encontrar uma tela verde, um programa COBOL ou um JCL aparentemente antigo, lembre-se da tela inicial daquele cartucho imaginário:
COBOL
PRESS START
Porque toda grande jornada na Frota Estelar — e todo grande programador COBOL — começou exatamente da mesma forma: com a coragem de apertar Start e explorar um universo onde lógica, disciplina e conhecimento são as maiores armas da missão.
☕🐉💀 O Hikikomori que Só Queria um Sofá e Acabou Criando uma Civilização — Por Que Você Deveria Dar uma Chance a Jitsu wa Ore, Saikyō Deshita?
Ou: Haruto ganhou poderes divinos, inventou streaming interdimensional, terceirizou a escola para o próprio clone, adotou monstros, conheceu uma dragão hikikomori profissional e ainda tentou resolver tudo sem levantar do sofá
Existe um momento perigoso na vida de todo otaku.
Você abre a lista de animes e encontra:
Isekai.
Protagonista reencarnado.
Magia.
Família nobre.
Poder absurdo.
O sujeito provavelmente consegue derrotar um dragão antes do café da manhã.
Você olha aquilo e pensa:
“Ah, não. Outro.”
Foi mais ou menos assim que comecei Jitsu wa Ore, Saikyō Deshita? — Am I Actually the Strongest?.
E cometi um erro.
Porque aquilo que parecia ser o Isekai Overpower nº 8.427 rapidamente revelou uma criatura completamente diferente.
Este é um anime sobre um hikikomori que morreu, ganhou uma segunda vida, recebeu poderes praticamente divinos e tomou talvez a decisão mais coerente da história do gênero:
continuar sendo hikikomori.
E, meus amigos...
isso muda tudo.
1. O isekai que finalmente entendeu o hikikomori
Existe uma contradição curiosa em muitos isekais.
O protagonista passa anos isolado.
Não gosta de gente.
Não trabalha.
Evita responsabilidades.
Passa o tempo jogando videogame, lendo mangá e assistindo anime.
Morre.
Reencarna.
Cinco minutos depois está:
entrando numa guilda;
formando grupo;
viajando pelo continente;
negociando com reis;
fazendo amigos;
liderando exércitos;
conquistando garotas;
salvando civilizações.
Peraí.
Trocaram o mundo ou trocaram o sujeito?
Haruto é diferente.
Ele chega ao novo mundo e, essencialmente, pergunta:
“Legal. Como faço para recuperar meu quarto?”
Essa é a primeira grande sacada de Jitsu wa Ore.
A reencarnação não executou:
DELETE PERSONALIDADE-ANTIGA
Haruto continua sendo Haruto.
Preguiçoso.
Antissocial.
Otaku.
Profundamente comprometido com o projeto estratégico de não fazer absolutamente nada que possa ser evitado.
Só que agora ele possui magia absurda.
E começa a utilizá-la da maneira mais hikikomori possível.
2. O bebê com RACF SPECIAL
Haruto renasce numa família real.
Uma deusa lhe concedeu enorme poder mágico.
Existe apenas um pequeno problema.
O sistema utilizado naquele mundo para medir magia não consegue interpretar corretamente o poder do bebê.
Resultado?
A família acredita que ele possui pouquíssima magia.
Em linguagem Bellacosa Mainframe:
MAGIC-LEVEL PIC 9(2).
Haruto nasceu com um valor que praticamente provocou overflow na especificação.
A corte olha o relatório.
LEVEL = 02
Conclusão:
“Inútil.”
E o bebê é abandonado.
Um dos seres potencialmente mais poderosos daquele mundo sofre DELETE porque alguém confiou cegamente numa métrica que não compreendia.
Já começou bem.
Mas então aparece Gold Zenfis.
3. Gold e a primeira grande mensagem do anime
Gold encontra o bebê abandonado.
Ele poderia simplesmente seguir viagem.
Não segue.
E posteriormente descobrimos algo que torna sua decisão muito mais emocionante: Gold já havia perdido uma criança.
Ele sabe o valor de uma vida infantil justamente porque conhece a dor de perdê-la.
E aqui existe uma diferença fundamental.
Gold não salva Haruto porque percebe que ele é overpower.
Não existe:
“Este bebê possui um poder lendário! Preciso criá-lo!”
Nada disso.
Gold salva Haruto porque...
é um bebê abandonado.
Para a família biológica:
MAGIC LEVEL = LOW
VALUE = ZERO
Para Gold:
TYPE = CHILD
VALUE = INESTIMABLE
Essa pequena decisão acaba ecoando por praticamente toda a série.
Porque Haruto cresce cercado por uma família que o acolheu antes de saber o que ele poderia oferecer em troca.
Mais tarde, quando criaturas rejeitadas começam a aparecer diante dele...
Haruto fará algo muito parecido.
Mesmo que jamais admita estar fazendo isso.
4. Charlotte entrou no sistema
Então aparece Charlotte.
A irmãzinha.
A pequena criatura que executará:
ALTER HARUTO ADD HUMAN-EMOTIONS
Haruto gosta dela.
Muito.
Embora provavelmente preferisse enfrentar um exército a fazer uma declaração sentimental sobre isso.
Charlotte, por sua vez, fica completamente pinei pelo onii-chan.
E então Haruto comete um dos maiores erros operacionais de sua segunda vida.
Mostra anime para ela.
5. Sim: existe anime dentro do anime
Essa talvez seja uma das melhores piadas da série.
Haruto descobre que sua magia é tão versátil que consegue criar algo semelhante a interfaces e janelas mágicas.
Então esse homem, possuidor de poderes que poderiam revolucionar a civilização, faz aquilo que qualquer otaku responsável faria:
tenta acessar entretenimento do Japão.
Sim.
O sujeito praticamente inventa streaming interdimensional.
Outros protagonistas usariam magia dimensional para invadir fortalezas.
Haruto:
“Será que consigo pegar anime?”
Consegue.
E mostra para Charlotte.
Grande erro.
Porque Charlotte não simplesmente gosta de anime.
CHARLOTTE DESCOBRE A CULTURA OTAKU.
A menina começa a absorver conceitos de heróis, vilões, identidades secretas e organizações misteriosas.
O anime passa a influenciar a maneira como ela interpreta o próprio mundo.
Temos então:
Japão → Haruto → anime → Charlotte → delírio otaku → Haruto obrigado a participar.
Haruto inventou o próprio incidente.
6. O clone sindicalizado
Haruto também consegue criar uma cópia de si mesmo.
Protagonista convencional:
“Fantástico! Posso lutar em dois lugares simultaneamente!”
Haruto:
“Fantástico! Ele pode cumprir minhas obrigações enquanto fico em casa.”
Isso é extraordinariamente coerente.
Haruto automatizou a própria presença.
Só existe um problema.
O clone...
também é Haruto.
Portanto também não gosta de fazer aquilo.
E chega o momento maravilhoso em que a cópia reclama, basicamente argumentando:
“Você sabe que eu não gosto disso tanto quanto você e mesmo assim me obriga a fazer!”
GENIAL.
Haruto conseguiu terceirizar aquilo que odeia para o único funcionário do universo que odeia exatamente as mesmas coisas.
Nascia ali o primeiro conflito trabalhista entre processo pai e processo filho.
7. Flay e o incidente do leitinho
E então temos Flay.
Em determinado momento Haruto exagera no uso dos poderes, fica completamente sem energia e pede leite.
Uma solicitação aparentemente simples.
Flay interpreta de outra maneira.
E começa a oferecer uma solução... biologicamente direta demais.
Haruto congela.
“QUE PORRA É ESSA?! SE CUBRA, MULHER!”
Flay atende ao requisito.
Volta vestida.
Só que com uma roupa de couro ainda mais fetichista.
Haruto percebe imediatamente que:
a emenda ficou pior que o soneto.
Aqui temos uma lição clássica da engenharia de requisitos:
o sistema fez exatamente aquilo que você pediu, não aquilo que você queria.
REQUISITO: SE CUBRA
RESULTADO: COBERTA
TEST CASE: PASS
USUÁRIO: NÃO ERA ISSO!
8. Pandemônio: o hikikomori criou uma civilização
E então Jitsu wa Ore começa a ficar surpreendentemente bonito.
Haruto passa a acolher criaturas que não possuem lugar no restante daquele mundo.
Esqueletos.
Monstros.
Demônios.
Golems.
Dragões.
E nasce Pandemônio.
Não porque Haruto decidiu:
“Construirei uma grande nação onde todas as espécies viverão em harmonia!”
Isso exigiria discurso.
Reunião.
Planejamento.
Provavelmente PowerPoint.
Haruto morreria novamente.
A filosofia dele é muito mais simples:
“Podem ficar aí. Só não me encham o saco.”
Pouco depois:
POPULATION = GROWING
FOOD PRODUCTION = ACTIVE
SECURITY = STABLE
CIVILIZATION = CREATED
Haruto:
“Como diabos aconteceu isso?”
9. Os esqueletos e a bondade que ninguém ordenou
Uma das cenas mais simpáticas envolve justamente os esqueletos.
Novas criaturas começam a chegar.
Mais habitantes significam mais bocas para alimentar.
E os esqueletos começam a trabalhar duro para aumentar a produção de alimentos.
Ninguém precisou ordenar.
Não houve decreto.
Não houve palestra sobre solidariedade.
Eles simplesmente perceberam:
“Tem mais gente aqui. Precisamos garantir que haja comida.”
E aí aparece uma das mensagens mais bonitas escondidas debaixo da comédia:
bondade gera bondade.
Gold acolheu Haruto.
Haruto acolheu criaturas rejeitadas.
Essas criaturas passam a acolher outras.
PERFORM BONDADE
O problema é que ninguém colocou:
UNTIL.
10. O verdadeiro monstro talvez não seja o esqueleto
A sociedade humana daquele mundo abandonou um bebê porque ele aparentemente não possuía valor.
Enquanto isso, esqueletos classificados como monstros trabalham para garantir que desconhecidos tenham o que comer.
A série nunca precisa parar para fazer um discurso filosófico sobre isso.
Ela simplesmente coloca as duas situações diante de nós.
E deixa uma pergunta:
afinal, quem é o monstro?
11. A golem é uma menininha
Porque obviamente é.
Neste ponto você já deveria ter aprendido que Jitsu wa Ore não pretende respeitar suas expectativas.
Você escuta:
GOLEM.
Imagina:
HEIGHT = 4 METERS
DEFENSE = 9999
TUM... TUM... TUM...
Aparece uma menininha adorável.
Kawaii.
Pronto.
Aceite.
Os chimpanzés responsáveis pelo roteiro já abriram o segundo barril de saquê.
12. A dragão hikikomori profissional
E chegamos a uma das melhores personagens dessa loucura.
Uma dragão revela que viveu reclusa durante aproximadamente 300 anos.
Qualquer protagonista convencional responderia:
“Que tristeza! Você precisa voltar a conhecer o mundo!”
Haruto?
Haruto fica impressionado.
Basicamente:
“UAAAAU! PROFISSIONAL! OUTRO NÍVEL!”
Finalmente encontrou sua senpai.
Haruto achava que era hikikomori.
Apareceu uma criatura com 300 anos de experiência comprovada.
Empresas querem reduzir riscos fazendo pequenas entregas em vez de grandes implantações trimestrais.
É justamente aí que entra o CI/CD.
E não...
CI/CD não significa abandonar o Mainframe.
Significa modernizar a maneira de trabalhar com ele.
Antes de tudo: o que significa CI/CD?
CI significa Continuous Integration.
CD significa Continuous Delivery ou Continuous Deployment.
São conceitos diferentes.
Continuous Integration
É a prática de integrar alterações ao repositório principal várias vezes ao dia.
Em vez de esperar uma semana para juntar o trabalho de dez programadores, cada alteração pequena é integrada rapidamente.
Isso reduz conflitos.
Reduz retrabalho.
Reduz surpresas.
Continuous Delivery
Depois que o código foi integrado, ele já está preparado para ser implantado.
Existe uma "linha de montagem".
Cada etapa acontece automaticamente.
Por exemplo:
compilação
geração de DBRM
BIND
testes
análise de qualidade
empacotamento
aprovação
implantação
Tudo acontece de forma repetível.
Continuous Deployment
Vai além.
Após todos os testes serem aprovados, a implantação ocorre automaticamente.
Nem todas as empresas permitem isso no Mainframe.
E tudo bem.
Em ambientes bancários, normalmente existe uma aprovação humana antes da produção.
Como nasceu o CI/CD?
Nos anos 90, os projetos começaram a ficar enormes.
Cada desenvolvedor trabalhava isoladamente.
Quando chegava a hora de integrar tudo...
Era um verdadeiro pesadelo.
Esse problema ficou conhecido como Integration Hell.
Martin Fowler e outros especialistas passaram a defender integrações frequentes.
Mais tarde, o movimento Agile fortaleceu essa ideia.
Depois veio o DevOps.
E finalmente surgiram pipelines automatizados.
Hoje praticamente toda aplicação moderna utiliza CI/CD.
Inclusive aplicações que executam em IBM Z.
"Mas Mainframe sempre teve automação..."
Essa é uma observação extremamente interessante.
Muito antes de existir Jenkins...
Muito antes de existir GitHub Actions...
Muito antes de existir Azure DevOps...
O Mainframe já possuía automação.
Pense em:
JCL
PROCs
Scheduler
CA-7
Control-M
IBM Workload Scheduler
REXX
CLIST
Na prática...
O Mainframe já automatizava tarefas quando muitos servidores ainda nem existiam.
O que mudou foi a filosofia.
Antes automatizávamos jobs.
Hoje automatizamos todo o ciclo de desenvolvimento.
Essa diferença muda completamente a produtividade.
O velho processo
Imagine um desenvolvedor COBOL.
Ele altera:
CLIENTE01.CBL
Depois precisa:
compilar
gerar load
atualizar DBRM
fazer BIND
solicitar implantação
enviar documentação
abrir chamado
esperar aprovação
Cada etapa depende de uma pessoa.
Cada pessoa gera espera.
Cada espera aumenta o tempo.
Cada demora aumenta o custo.
O processo moderno
Agora imagine outra empresa.
O desenvolvedor apenas faz:
git commit
git push
O restante acontece sozinho.
Pipeline:
↓
Compila COBOL
↓
Executa testes
↓
Executa análise estática
↓
Compila DB2
↓
Gera Package
↓
Executa BIND
↓
Publica artefatos
↓
Implanta homologação
↓
Notifica equipe
↓
Solicita aprovação
↓
Produção
O programador continua escrevendo COBOL.
Quem mudou foi o processo.
O Git substitui o Endevor?
Essa é uma das perguntas mais comuns.
Resposta curta:
Depende.
Muitas empresas continuam usando:
Endevor
Changeman
ISPW
Outras utilizam Git integrado.
Algumas usam ambos.
Hoje existem integrações excelentes entre Git e ambientes z/OS.
O importante não é abandonar uma ferramenta.
É automatizar o fluxo.
Como funciona uma pipeline Mainframe?
Uma pipeline normalmente possui etapas bem definidas.
Etapa 1
Receber alteração.
git push
Etapa 2
Executar compilação.
COBOL.
PLI.
Assembler.
Easytrieve.
Natural.
Etapa 3
Executar análise de qualidade.
Exemplo:
variáveis não utilizadas
SQL incorreto
COPY duplicado
warnings
complexidade
Etapa 4
Executar testes.
Hoje existem ferramentas como:
zUnit
IBM Test Accelerator
Micro Focus Unit Test
Etapa 5
Gerar artefatos.
LOAD MODULE
DBRM
Package
Objetos
Etapa 6
Implantar automaticamente.
Dependendo da empresa:
Desenvolvimento
Integração
Homologação
Produção
O que muda para um programador COBOL?
Muita coisa.
Mas não na linguagem.
Na forma de trabalhar.
Antes:
"Funcionou na minha LPAR."
Agora:
"O pipeline precisa aprovar."
Antes:
"O compilador aceitou."
Agora:
"Todos os testes precisam passar."
Antes:
"Eu testei."
Agora:
"O teste automatizado comprovou."
Essa mudança cultural é enorme.
O programador passa a escrever testes
Isso assusta muitos profissionais.
Mas pense da seguinte forma.
Se você altera um cálculo de juros.
Como garante que não quebrou o restante?
Criando testes.
Os testes viram documentação viva.
E principalmente...
Protegem seu código daqui a cinco anos.
Qualidade deixa de ser opcional
Em muitas empresas modernas:
Código com warning...
Não passa.
Cobertura baixa...
Não passa.
Duplicação elevada...
Não passa.
Complexidade excessiva...
Não passa.
O pipeline torna-se um fiscal automático.
O papel do JCL muda?
Não.
Na verdade...
Ele ganha ainda mais importância.
Toda pipeline Mainframe executa JCL.
Compilação.
Link-edit.
BIND.
RUN.
Utility.
IDCAMS.
SORT.
Tudo continua passando pelo bom e velho JCL.
A diferença é que ele agora faz parte de um fluxo automatizado.
Ferramentas comuns
Hoje encontramos diversas soluções.
IBM Dependency Based Build (DBB)
Permite construir aplicações Mainframe utilizando Git e pipelines modernas.
Jenkins
Muito usado para orquestrar pipelines.
GitHub Actions
Integra facilmente repositórios Git.
GitLab CI
Muito utilizado em ambientes híbridos.
Azure DevOps
Cada vez mais presente em grandes empresas.
UrbanCode Deploy
Muito forte para implantação empresarial.
Ansible
Automação de infraestrutura.
Inclusive para IBM Z.
O que exige atenção?
Nem tudo são flores.
Alguns cuidados são fundamentais.
Dependências
Um programa COBOL pode utilizar dezenas de COPYBOOKS.
Uma alteração em COPY pode impactar centenas de programas.
A pipeline precisa descobrir essas dependências.
Ordem de compilação
No mundo distribuído isso costuma ser simples.
No Mainframe nem sempre.
Existem:
COPY
DBRM
BMS
Mapsets
PSB
DBD
Macros
Assembler
Tudo possui ordem correta.
Segurança
Automatizar não significa liberar tudo.
Pipelines precisam utilizar:
RACF
certificados
tokens
controle de acesso
segregação de funções
auditoria
Aprovação
Nem toda implantação deve ser automática.
Em ambientes regulados:
bancos
seguros
governo
saúde
geralmente existe aprovação humana.
Os riscos
Automação ruim automatiza erros.
Se o pipeline estiver incorreto...
O erro será reproduzido centenas de vezes.
Outro risco:
Implantar rapidamente código mal testado.
Velocidade sem qualidade é perigosa.
CI/CD não elimina responsabilidade.
Ele aumenta a responsabilidade.
Um erro clássico
Um desenvolvedor altera um COPYBOOK.
Compila apenas seu programa.
Tudo funciona.
Produção falha.
Por quê?
Porque outros 700 programas dependiam daquele COPY.
Uma pipeline moderna detecta esse impacto automaticamente.
Outro erro clássico
"Vamos automatizar tudo."
Sem documentação.
Sem padronização.
Sem versionamento.
Resultado?
Caos automatizado.
Automação precisa nascer de processos bem definidos.
A evolução do papel do programador
Há vinte anos.
O programador escrevia código.
Hoje ele precisa compreender:
Git
Branches
Merge
Pipeline
Testes
Qualidade
Observabilidade
Versionamento
Entrega
Automação
Isso não significa virar DevOps.
Significa entender o ciclo completo.
Curiosidades
Pouca gente sabe, mas muitos bancos já executam pipelines modernas para COBOL.
Algumas empresas realizam centenas de compilações automáticas diariamente.
Existem ambientes em que um simples Pull Request dispara:
compilação COBOL
geração de DBRM
testes
análise de qualidade
implantação automática em ambiente de integração
Tudo em poucos minutos.
Algo que antigamente podia consumir vários dias.
CI/CD elimina o analista de produção?
Não.
Ele muda de função.
Em vez de executar tarefas repetitivas.
Passa a administrar pipelines.
Governança.
Qualidade.
Segurança.
Métricas.
Automação.
Seu trabalho torna-se mais estratégico.
Vantagens
Os ganhos são enormes.
Menos erros humanos.
Entregas menores e mais seguras.
Feedback quase imediato.
Redução do retrabalho.
Maior rastreabilidade.
Auditoria facilitada.
Padronização dos processos.
Menor tempo entre desenvolvimento e produção.
Melhor qualidade do software.
Maior confiança nas implantações.
E as desvantagens?
Também existem.
Curva de aprendizado.
Mudança cultural.
Investimento inicial.
Necessidade de testes automatizados.
Dependência de boas práticas.
Necessidade de revisão das esteiras existentes.
Empresas que tentam implantar CI/CD apenas comprando ferramentas normalmente fracassam.
O sucesso está na mudança de cultura.
O futuro
A próxima evolução já começou.
Pipelines inteligentes.
IA revisando código COBOL.
Agentes analisando impacto.
Testes sendo gerados automaticamente.
Análise de risco baseada em Machine Learning.
Deploy assistido por Inteligência Artificial.
Tudo isso já está chegando ao IBM Z.
O programador que entender CI/CD hoje estará muito mais preparado para trabalhar com essas tecnologias amanhã.
Conclusão
Durante muito tempo acreditou-se que modernizar o Mainframe significava substituir COBOL.
A realidade mostrou exatamente o contrário.
Os maiores bancos, seguradoras e empresas do mundo continuam confiando no IBM Z para executar suas cargas mais críticas. O que mudou não foi a robustez da plataforma, mas a forma como desenvolvemos, testamos e entregamos software.
CI/CD não é uma moda importada do mundo distribuído. É a evolução natural da automação que o próprio Mainframe sempre cultivou. A diferença é que agora automatizamos toda a jornada do desenvolvimento, desde o primeiro commit até a implantação em produção, com rastreabilidade, testes, segurança e governança.
Para o Programador COBOL Padawan, a maior transformação não está em aprender uma nova linguagem, mas em adotar uma nova mentalidade. Continuará escrevendo PROCEDURE DIVISION, manipulando VSAM, DB2, CICS e JCL, porém trabalhando em equipes colaborativas, utilizando Git, pipelines, testes automatizados e revisão contínua de código.
No fim das contas, o COBOL continua sendo o motor. O CI/CD passa a ser a esteira inteligente que garante que esse motor seja atualizado com segurança, rapidez e qualidade.
Porque no universo do IBM Mainframe, o futuro não pertence a quem escreve mais linhas de código.
Pertence a quem consegue entregar valor ao negócio com confiança, repetibilidade e excelência.
E essa é, talvez, a maior evolução que um verdadeiro Padawan pode aprender.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
