☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sábado, 9 de fevereiro de 2019

Sempre um Isekai : O Isekai e o Contrato Social Quebrado – Parte I

 

Bellacosa Mainframe e  a quebra do contrato social

☕ Um Café no Bellacosa Mainframe

O Isekai e o Contrato Social Quebrado – Parte I

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Bug Nunca Tenha Estado no Código... Mas na Promessa Feita ao Trabalhador

Existe uma pergunta que comecei a fazer depois de assistir dezenas de isekais.

Não é sobre magia.

Não é sobre espadas.

Nem sobre dragões.

É uma pergunta muito mais simples.

Por que tanta gente acha tão maravilhoso abandonar completamente o próprio mundo?

Pense por um instante.

Imagine que, hoje, um círculo mágico aparecesse debaixo dos seus pés.

Você fosse invocado para outro universo.

Sem celular.

Sem internet.

Sem eletricidade.

Sem supermercado.

Sem chuveiro quente.

Sem café expresso.

Sem pizza no sábado.

Sem streaming.

Sem GPS.

Sem ar-condicionado.

Sem hospital moderno.

Mesmo assim...

Milhões de fãs responderiam imediatamente:

"Estou dentro."

Isso é curioso.

Porque essa resposta diz muito mais sobre o nosso mundo do que sobre o mundo da fantasia.


O Contrato Invisível

Quando comecei minha vida profissional, ainda existia uma promessa que parecia sólida.

Era quase um contrato moral entre a sociedade e o trabalhador.

O acordo era simples.

Você estudaria.

Conseguiria um emprego.

Trabalharia honestamente.

Pagaria seus impostos.

Contribuiria para a previdência.

Criaria sua família.

Compraria sua casa.

E, depois de décadas ajudando a construir o país, teria uma aposentadoria para finalmente respirar.

Não era riqueza.

Era dignidade.

Era uma promessa compreensível.

Era o famoso:

"Faça sua parte que o sistema fará a dele."


O Programa Foi Alterado em Produção

Todo programador COBOL conhece uma regra sagrada.

Nunca mude as regras do negócio sem analisar o impacto.

Porque existe gente usando aquele sistema.

Existe processamento acontecendo.

Existe produção.

Agora imagine um banco.

Você escreveu um programa.

Ele roda perfeitamente há trinta anos.

De repente alguém entra na sala e diz:

— A partir de hoje todas as regras mudaram.

Os cálculos mudaram.

Os prazos mudaram.

Os critérios mudaram.

Boa sorte.

Foi exatamente essa sensação que muitas pessoas tiveram ao longo das últimas décadas.

Não importa se as mudanças tinham justificativas econômicas ou demográficas.

A sensação psicológica foi outra.

O programa mudou enquanto ainda estávamos executando o JOB.


O Tempo Nunca Foi Nosso

Existe outra mudança silenciosa.

Nossos avós trabalhavam muito.

Ninguém discute isso.

Mas quando encerravam o expediente...

O trabalho normalmente ficava na empresa.

Hoje...

O escritório mora dentro do bolso.

O WhatsApp toca.

O Teams notifica.

O e-mail chega às dez da noite.

O celular vibra no domingo.

A reunião invade o almoço.

O expediente termina.

Mas o trabalho continua conectado.

A tecnologia prometeu devolver tempo.

Em muitos casos...

Apenas aumentou a disponibilidade.


Trabalhamos Mais...

Compramos Menos

Existe uma sensação que aparece em praticamente todas as conversas entre trabalhadores.

"Meu pai conseguiu comprar uma casa."

"Meu avô sustentava uma família inteira."

"Hoje preciso fazer contas para trocar de carro."

Cada geração possui desafios diferentes.

Mas é inegável que, para muitas famílias, moradia, educação e custo de vida passaram a consumir uma parcela cada vez maior da renda.

O resultado aparece rapidamente.

Mesmo trabalhando muito...

A percepção de progresso diminui.


O Holerite Conta uma História

Chega o pagamento.

Primeiro aparece o salário bruto.

Por alguns segundos...

Você imagina possibilidades.

Depois vem o salário líquido.

INSS.

Imposto de Renda.

Plano de saúde.

Vale-transporte.

Descontos diversos.

Você respira.

Vai abastecer o carro.

Combustível.

Pedágio.

IPVA.

Seguro.

Depois faz compras.

ICMS embutido.

Conta de luz.

Água.

Internet.

IPTU.

Taxas.

Boletos.

É importante lembrar que impostos financiam serviços públicos essenciais e são parte do funcionamento de qualquer Estado moderno. Ao mesmo tempo, muitos trabalhadores têm a percepção de que a carga tributária, somada ao custo de vida, reduz significativamente o resultado prático de anos de esforço.

No fim do mês...

A pergunta aparece.

"Quanto da minha energia realmente ficou comigo?"


O Burnout Não Nasceu do Nada

Não é coincidência que palavras como:

Burnout.

Ansiedade.

Exaustão.

Depressão.

Síndrome do impostor.

Tenham se tornado tão comuns.

Durante muito tempo acreditamos que trabalhar mais resolveria tudo.

Depois descobrimos que existem problemas que não desaparecem apenas aumentando a carga de trabalho.

Porque ninguém consegue executar um JOB infinito sem consumir recursos.

Até o z/OS sabe disso.

Existe WLM.

Existe gerenciamento de prioridades.

Existe balanceamento de carga.

Existe proteção contra sobrecarga.

Curiosamente...

Às vezes tratamos computadores com mais cuidado do que seres humanos.


Então Surge o Isekai

É exatamente nesse momento que entra o gênero mais popular da última década.

O protagonista está cansado.

Desmotivado.

Sem perspectivas.

Muitas vezes sozinho.

Então...

Truck-kun aparece.

Ou uma magia de invocação.

Ou uma reencarnação.

Poucos minutos depois...

Ele ganha uma nova oportunidade.

Repare.

O sonho nunca foi apenas lançar Fireball.

O sonho era apertar RESET.


Bellacosa Mainframe

Quanto mais penso sobre isso...

Mais acredito que o isekai não nasceu apenas da criatividade japonesa.

Ele nasceu de uma pergunta silenciosa que milhões de trabalhadores fazem todos os dias enquanto voltam para casa em um ônibus lotado.

"Será que era para a vida ser apenas isso?"

Talvez o círculo mágico nunca tenha sido um portal.

Talvez fosse apenas a representação gráfica de um pedido de HELP enviado por milhões de pessoas ao longo de décadas.

Um HELP que nunca recebeu resposta.

E quando o mundo real demora demais para responder...

A fantasia acaba respondendo primeiro.

Continua na Parte II — "Por que o Isekai Explodiu Depois dos Anos 1990? A Década em que o Mundo Parou de Prometer um Futuro Melhor".

☕ UM CAFÉ NO BELLACOSA MAINFRAME

O Isekai e o Contrato Social Quebrado

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Entender Este.

PRIMEIRA REGRA DO PORÃO NENHUM ARTIGO DEVE FICAR ESCONDIDO DOS LEITORES

Entre nesta série sobre trabalho, impostos, burnout, sociedade, salarymen, guildas, promessas quebradas e o verdadeiro significado da fuga para mundos paralelos. Escolha um capítulo, abra a prévia ou leia diretamente no Bellacosa Mainframe.

00
SYSTEM DIAGNOSIS

O Verdadeiro Rei Demônio Talvez Seja o Holerite

Quando um Programador COBOL Descobre que o Isekai Não Vende Magia... Vende um Mundo Onde o Esforço Ainda Vale Alguma Coisa.

Uma introdução à relação entre o sucesso do gênero isekai, a exaustão do trabalhador moderno, os descontos no salário, a perda de propósito e o desejo de recomeçar em outro mundo.

HOLERITE TRABALHO ISEKAI CONTRATO SOCIAL
Ler artigo completo ↗
01
CONTRACT ABEND

O Isekai e o Contrato Social Quebrado — Parte I

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Bug Nunca Tenha Estado no Código... Mas na Promessa Feita ao Trabalhador.

A promessa de trabalhar, contribuir, construir uma carreira e receber segurança no futuro começa a apresentar falhas de processamento.

CONTRATO SOCIAL APOSENTADORIA DIGNIDADE
Ler artigo completo ↗
02
ECONOMY IPL

O Isekai e o Contrato Social Quebrado — Parte II

Quando um Programador COBOL Descobre que os Anos 1990 Talvez Tenham Sido o Grande IPL da Economia Mundial... e Nem Todos os JOBs Voltaram a Executar.

Globalização, tecnologia, automação, terceirização e produtividade reinicializaram a economia mundial, mas muitos trabalhadores ficaram aguardando uma resposta do sistema.

ANOS 1990 GLOBALIZAÇÃO AUTOMAÇÃO
Ler artigo completo ↗
03
MISSION ACCEPTED

O Isekai e o Contrato Social Quebrado — Parte III

Quando um Programador COBOL Descobre que a Guilda dos Aventureiros Talvez Tenha um RH Muito Melhor que o Nosso.

Na guilda existem missões claras, riscos conhecidos, recompensas publicadas e liberdade para escolher o próximo trabalho. No escritório moderno, nem sempre.

GUILDA RH RECOMPENSA
Ler artigo completo ↗
04
CANCEL JOB

O Isekai e o Contrato Social Quebrado — Parte IV

Quando um Programador COBOL Descobre que o Truck-kun Nunca Foi um Caminhão... Mas um Botão de CANCEL JOB para uma Geração Inteira.

Truck-kun representa a interrupção brutal de uma vida repetitiva, exausta e sem perspectiva. Um símbolo sombrio do desejo de cancelar a rotina e recomeçar.

TRUCK-KUN BURNOUT CANCEL JOB
Ler artigo completo ↗
05
SALARYMAN MODE

O Isekai e o Contrato Social Quebrado — Parte V

Quando um Programador COBOL Descobre que Quase Todo Protagonista de Isekai é um Salaryman... e Isso Está Muito Longe de Ser Coincidência.

Programadores, funcionários de escritório e trabalhadores invisíveis protagonizam histórias de recomeço porque representam milhões de pessoas presas em rotinas semelhantes.

SALARYMAN ESCRITÓRIO PROPÓSITO
Ler artigo completo ↗
06
TIME AVAILABLE

O Isekai e o Contrato Social Quebrado — Parte VI

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Feitiço do Isekai Não Seja a Magia... Mas o Tempo para Viver.

O maior luxo de um mundo fantástico talvez não seja lançar feitiços, mas ter tempo para conversar, descansar, conviver, caminhar e participar de uma comunidade.

TEMPO COMUNIDADE QUALIDADE DE VIDA
Ler artigo completo ↗
07
RETURN CODE 00

O Isekai e o Contrato Social Quebrado — Parte VII

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Recuperar Este.

A conclusão da série propõe que talvez o verdadeiro sonho nunca tenha sido abandonar o mundo real, mas recuperar dignidade, propósito, tempo, comunidade e esperança.

ESPERANÇA RECONSTRUÇÃO FUTURO
Ler artigo completo ↗

sexta-feira, 8 de fevereiro de 2019

🍹 Bebidas Brasileiras de Origem Japonesa (ou com DNA Nipônico disfarçado)

 


🍹 Bebidas Brasileiras de Origem Japonesa (ou com DNA Nipônico disfarçado)

Por Vagner Bellacosa ☕ — El Jefe Midnight Lunch Edition


🍶 1. Saquê brasileiro — o destilado que pegou sotaque tropical

Quando os imigrantes japoneses chegaram ao Brasil em 1908, uma das primeiras saudades foi do saquê.
Mas o clima quente, o arroz diferente e a falta de koji japonês obrigaram os pioneiros a improvisar.
Em 1934, surgia em Registro (SP) a primeira produção artesanal de saquê brasileiro, adaptada ao arroz tropical.

O sabor? Menos seco, mais frutado — uma mutação que combinou com o paladar brasileiro.
Nos anos 70, o saquê local já era vendido em bares, misturado com limão, frutas e gelo.
Nascia o “saquerinha”, o primo cosmopolita da caipirinha — o drink que transformou o saquê em festa de boteco.

💡 Curiosidade: hoje o Brasil é o maior produtor de saquê fora do Japão, e o rótulo paulista Azuma Kirin domina 70% do mercado nacional.




🧊 2. Saquerinha — o filho mestiço do Japão com o Brasil

O nome é híbrido e o espírito idem:
mistura do saquê japonês com o ritual da caipirinha brasileira.
Inventada provavelmente em São Paulo nos anos 1980, em bares da Liberdade, a saquerinha virou o drink oficial de quem queria ser chique sem perder o jeitinho tropical.

As versões de morango, kiwi e maracujá substituíram o clássico limão, e a receita rodou o país.
É a prova líquida de que o Brasil nunca copia — adapta, samba e serve gelado.




🧋 3. Bubble Tea Brasil (ou “chá com bolinha” made in Liberdade)

Chegou nos anos 2000 direto de Taiwan e Japão, mas só explodiu em São Paulo depois de ser tropicalizado:
menos chá verde, mais leite, mais açúcar e pérolas de tapioca maiores.
Hoje, há versões com açaí, cupuaçu, cajá e até guaraná, todas criadas aqui.

Na prática, o bubble tea brasileiro é um híbrido nipônico-tupi — a fusão entre tecnologia asiática e calor de padoca paulistana.




🍵 4. Matchá Latte Brasileiro — o zen da cafeteria de shopping

O matchá (pó de chá verde moído) chegou com os imigrantes, mas era raro fora das colônias.
Nos anos 2010, os baristas brasileiros o transformaram em matchá latte, com leite vaporizado e mel — versão mais doce, instagramável e tropical.
É o yakult da geração fitness: oriental na teoria, paulistano na prática.


Bellacosa comenta:

Essas bebidas são o retrato do Brasil que o Japão ajudou a misturar:
disciplinado no preparo, criativo no improviso e sentimental no resultado.

Enquanto o Japão busca a perfeição, o Brasil busca o sabor —
e juntos criaram um portfólio de líquidos que rodariam até no mainframe da nostalgia.


💡 Dica do El Jefe Midnight Lunch:

  • Experimente saquerinha com cachaça branca — modo híbrido, 200% fusão cultural.

  • No calor, um yakult com gelo e vodka vira “saquê da geração Y”.

  • E lembre-se: cada gole dessas fusões é um handshake cultural entre Tóquio e Tatuapé.


segunda-feira, 4 de fevereiro de 2019

O Velho Vagner Senta-se em Astúrias — O Garoto das 5h15 Finalmente Chegou em Casa

 

Bellacosa Mainframe e memoria de um pequeno trabalhador

Um Café no Bellacosa Mainframe

O Velho Vagner Senta-se em Astúrias — O Garoto das 5h15 Finalmente Chegou em Casa

Ou: como um menino de 14 anos atravessou trens destruídos, marmitas, greves, caminhões militares, escola noturna, computadores de 8 bits, montanhas e uma câmera de 35 mm até descobrir que algumas jornadas levam quase uma vida inteira para chegar à estação final



Prólogo — O velho no banco

Astúrias.

Talvez Oviedo.

Talvez uma manhã fria daquelas em que o céu parece não ter decidido se vai chover.

O velho Vagner está sentado em um banco do Campo de San Francisco.

Não está fazendo nada.

E isso, por si só, já é extraordinário.

Durante boa parte da vida ele esteve indo para algum lugar.

Trem.

Ônibus.

Trabalho.

Escola.

Aeroporto.

Escritório.

Data center.

Montanha.

Outro país.

Outra cidade.

Outra aventura.

Mas agora simplesmente está sentado.

Perto dali passam crianças, aposentados, turistas, cachorros, estudantes e pessoas que provavelmente estão atrasadas para alguma coisa.

Vagner observa.

O velho ainda gosta de observar.

Certos programas nunca foram desinstalados.

Ele olha para o relógio.

5h15.

Sorri.

— Eu conheço esse horário.

E, durante alguns segundos, Astúrias desaparece.

Não existe Espanha.

Não existe aposentadoria.

Não existe velho.

Existe São Paulo.

Existe 1987.

E existe um garoto de 14 anos acordando antes do Sol.



1. 05:15 — IPL

Quem trabalha com mainframe sabe que alguns sistemas precisam começar antes que os usuários percebam que existem.

Com aquele garoto acontecia algo parecido.

Às 5h15 começava o IPL.

Não havia botão SNOOZE filosoficamente aceitável.

Era levantar.

Vestir-se.

Conferir documentos.

Dinheiro.

Marmita.

Horário.

Sair.

O mundo ainda estava escuro.

Enquanto muitos adolescentes dormiam, aquele menino já estava executando sua primeira rotina crítica do dia.

PERFORM ACORDAR
PERFORM ARRUMAR-SE
PERFORM CONFERIR-MARMITA
PERFORM CORRER-PARA-ESTACAO
PERFORM PEGAR-TREM
    UNTIL CHEGAR-AO-TRABALHO

Qualquer atraso propagava-se pelo sistema.

Perder alguns minutos em casa podia significar perder o trem.

Perder o trem podia significar perder o ônibus.

Perder o ônibus podia significar chegar atrasado.

Chegar atrasado podia significar problema no emprego.

O relógio não queria saber se chovia.

Nem se fazia frio.

Nem se havia granizo.

Nem se o transporte estava ruim.

Nem se você tinha 14 anos.

O relógio simplesmente contava.



2. O trem que podia matar

Em 1987, a ferrovia deixou de ser apenas transporte.

Um grave acidente envolvendo trens marcou São Paulo.

Para o garoto que dependia daquele sistema, porém, a tragédia não desapareceu quando saiu dos jornais.

Os trens acidentados permaneceram durante meses na região da estação Roosevelt, no Brás.

No começo estavam cobertos.

Um plástico preto escondia parte daquilo.

Mas plástico envelhece.

Rasga.

O vento abre frestas.

E aquilo que deveria desaparecer volta a aparecer.

Todos os dias, o garoto passava por ali.

Não era necessário que ninguém explicasse mortalidade para ele.

A aula estava estacionada diante da plataforma.

Aquilo podia acontecer com o trem em que ele estava.

E na manhã seguinte?

Entrava novamente.

Esse detalhe é importante.

Coragem não significa acreditar que nada acontecerá.

Às vezes coragem significa conhecer perfeitamente o risco e, mesmo assim, perceber que você precisa continuar.



3. O vilão também era o herói

Décadas depois, sentado em Astúrias, Vagner finalmente encontrou uma definição para aquele trem.

Ele era simultaneamente:

vilão e herói.

Era vilão quando estava superlotado.

Quando quebrava.

Quando atrasava.

Quando pessoas brigavam.

Quando havia batedores de carteira.

Quando o medo de assalto acompanhava o passageiro.

Quando alguém precisava viajar perigosamente junto a uma porta aberta.

Mas à noite ele se transformava.

Depois do trabalho.

Depois da escola.

Depois de um dia começado às 5h15.

Quando as luzes daquela composição apareciam ao longe, existia uma certeza extraordinária:

vou chegar em casa.

O mesmo objeto que pela manhã representava perigo, à noite representava salvação.

Talvez algumas das relações mais importantes da vida sejam assim.

Não cabem facilmente nas categorias de amor ou ódio.



4. Quando o sistema caía

Programadores mainframe aprendem cedo uma verdade:

todo sistema eventualmente falha.

E quando aquele sistema ferroviário falhava, o caos não era metafórico.

Trem quebrado significava milhares de pessoas tentando encontrar uma alternativa.

Vagner lembra de ocasiões em que voltou sobre uma locomotiva diesel porque era o espaço disponível.

Lembra também de viagens junto a portas abertas, situação em que permanecer no veículo exigia esforço físico.

Hoje, olhando retrospectivamente, não há qualquer motivo para romantizar aquilo.

Era perigosíssimo.

Mas esse é justamente o problema de analisar o passado apenas com as condições do presente.

Naquele momento a pergunta prática não era:

— Qual opção oferece melhor conforto e segurança?

Era:

Como volto para casa?

Essa diferença explica muita coisa.



5. GREVE — SYSTEM UNAVAILABLE

Então existiam as greves.

E havia uma perversidade especial quando a paralisação atingia o retorno.

O trabalhador conseguira chegar.

Cumprira sua jornada.

Agora estava dezenas de quilômetros distante de casa.

E o sistema desaparecia.

Hoje um telefone imediatamente apresentaria mapas, aplicativos, mensagens, grupos, localização e alternativas.

Naquele mundo, grande parte do sistema de informação era humano.

— Disseram que tem ônibus lá.

— Parece que vai sair um trem.

— Estão colocando caminhões.

— Vai por aquele lado.

A multidão funcionava como uma gigantesca rede peer-to-peer analógica.

E algumas vezes aparecia uma solução extraordinária:

transporte disponibilizado com apoio policial/militar.

Caminhões utilizados normalmente para transportar efetivos recebiam uma multidão desesperada para voltar para casa.

O garoto via policiais tentando organizar o embarque.

Cães.

Gritos.

Gente comprimida.

Confusão.

Décadas depois, a melhor referência cinematográfica que encontra é:

evacuação de filme de apocalipse zumbi.

Só faltavam os zumbis.

Ou talvez os zumbis fossem os próprios passageiros depois de quinze horas acordados.



6. O pau-de-arara metropolitano

Quando dezenas de pessoas deveriam ocupar determinado espaço e aparece uma multidão muito maior tentando embarcar, desaparece rapidamente qualquer ideia sofisticada de transporte.

Sobra capacidade física.

Onde cabe mais um?

Sobe.

Aperta.

Segura.

Vai.

Foi nesse tipo de situação que o garoto compreendeu corporalmente uma expressão que até então poderia parecer apenas histórica:

pau-de-arara.

Não era aventura.

Não era atração turística.

Era contingência.

E talvez tenha sido justamente daí que nasceu aquela brincadeira mental:

“Estou fazendo treinamento militar.”

Porque havia dias em que a metáfora estava perigosamente próxima da realidade.



7. 08:00 — “Bom dia!”

Talvez uma das maiores ironias daquela vida acontecesse às oito da manhã.

Depois de acordar às 5h15.

Depois do frio.

Depois da estação.

Depois do trem.

Depois da multidão.

Depois do ônibus.

Depois de proteger documentos e dinheiro.

Depois de calcular cada minuto.

O garoto chegava ao trabalho.

E alguém dizia:

— Bom dia!

E começava oficialmente a jornada.

Oficialmente.

Porque para o relógio de ponto, tudo aquilo que aconteceu antes simplesmente não existia.

Era processamento externo.

O trabalhador chegava às oito.

O sistema registrava:

ENTRADA = 08:00

Mas ninguém registrava:

JORNADA-REAL-DO-SER-HUMANO = 05:15


8. A carteira profissional era uma patente

Entretanto, seria um erro transformar toda essa história apenas em sofrimento.

Havia orgulho.

A carteira profissional assinada representava algo enorme.

Era quase uma patente militar.

Aquele adolescente havia entrado oficialmente no mundo do trabalho.

Salário.

Décimo terceiro.

Férias.

Direitos.

Possibilidade de comprar.

Possibilidade de ajudar.

Possibilidade de planejar.

Possibilidade de melhorar.

A carteira dizia:

“Você agora participa do sistema.”

E isso tinha um peso enorme.



9. A marmita era o tesouro

Todo RPG possui inventário.

O inventário daquele aventureiro tinha um item particularmente importante:

MARMITA.

Hoje é fácil subestimar aquilo.

Mas a marmita significava dinheiro, preparação e alimento para atravessar a jornada.

E havia bosses específicos.

Boss 1 — Marmita azedou.

GAME OVER no almoço.

Boss 2 — Marmita caiu.

Tesouro perdido durante o transporte.

Boss 3 — Vazou.

Dano de área na mochila.

O problema é que nem sempre havia dinheiro para simplesmente comprar outra refeição.

Portanto cuidar da marmita era logística.

Décadas depois, quando aquele garoto conseguiu proporcionar comida melhor para a família, talvez a vitória tivesse um sabor que alguém criado com abundância jamais perceberia completamente.



10. 17:15 — Não acabou

Às 17h15 terminava o expediente.

Mas não o dia.

Começava outra quest.

ESCOLA.

Outros bosses.

Outras regras.

Outras exigências.

Professor.

Matéria.

Trabalho.

Prova.

Nota.

E aqui surge um detalhe maravilhoso.

O objetivo do garoto não era simplesmente passar.

Sua meta era:

TOP 5 DA CLASSE

Pense nisso.

Acordar às 5h15.

Atravessar São Paulo.

Trabalhar.

Ir para a escola.

Sentar diante de uma prova.

E ainda pensar:

quero estar entre os cinco melhores.

Não havia bônus por cansaço.

A prova não perguntava:

TRABALHOU-HOJE? S
PEGOU-TREM-LOTADO? S
ESTA-CANSADO? S

ADD 2 TO NOTA-FINAL

Nada disso.

Nove era nove.

Dez era dez.

E o garoto queria disputar as primeiras posições.



11. O sorriso profissional

Existia ainda uma disciplina invisível.

Autocontrole.

O mundo podia estar uma porcaria.

O trem podia ter atrasado.

Alguém podia ter empurrado você.

Sua marmita podia ter sofrido um ABEND.

Você podia estar cansado.

Mas no trabalho precisava existir:

educação;

atenção;

disposição;

respeito;

controle emocional.

Uma explosão de raiva podia colocar tudo a perder.

Portanto o garoto aprendeu cedo uma das habilidades mais difíceis do mundo profissional:

não permitir que todo erro externo provoque um ABEND interno.

Isso não significa engolir tudo.

Significa compreender que nem toda batalha merece ser travada.



12. Então apareceram as recompensas

A campanha começou a produzir loot.

Primeiro, coisas fundamentais.

Melhor comida.

Depois:

melhor assistência médica.

E havia algo ainda maior.

Ele podia ajudar a mãe.

Podia ajudar os irmãos.

O dinheiro deixava de ser apenas remuneração.

Transformava-se em qualidade de vida para uma pequena comunidade chamada família.

Então chegou uma conquista memorável:

a primeira televisão colorida.

Parece banal em 2026.

Não era.

A televisão colorida dizia silenciosamente:

estamos avançando.



13. O Nintendinho entra em casa

Depois veio o videogame.

O primeiro Nintendo.

E quando sobrava algum dinheiro:

cartuchos.

Existe uma ironia deliciosa nisso.

O adolescente que havia passado o dia inteiro enfrentando fases, obstáculos e bosses chegava em casa e ligava uma máquina cujo objetivo era...

enfrentar fases, obstáculos e bosses.

Talvez Mario parecesse até relaxante.

Pelo menos Bowser não fazia greve de transporte.


14. Os computadores de 8 bits

Mas algumas máquinas tinham outra magia.

Os computadores domésticos de 8 bits mostravam uma superfície aparentemente simples.

Teclado.

Tela.

Pouca memória.

Poucas cores.

Entretanto havia alguma coisa escondida dentro deles.

E o garoto queria saber:

como isso funciona?

Essa pergunta é perigosíssima.

Porque algumas pessoas passam o resto da vida tentando respondê-la.

O computador deixa de ser eletrodoméstico.

Vira território.

Você digita alguma coisa.

A máquina responde.

Muda um valor.

Acontece outra coisa.

Erro.

Tenta novamente.

Funciona.

É uma sensação extraordinária:

eu disse para a máquina fazer alguma coisa e ela fez.

Décadas depois haveria COBOL, mainframes, bancos de dados, redes, APIs, inteligência artificial.

Mas antes de todas essas catedrais existiram pequenas máquinas de 8 bits dizendo:

READY.


15. O raio de 500 quilômetros

Quando sobrava algum dinheiro, entretanto, Vagner não comprava somente coisas.

Comprava distância.

Seu universo de aventuras tinha uma regra financeira.

Não dava para atravessar o planeta.

Tudo bem.

Qual era o mundo disponível?

Talvez 100 quilômetros.

No máximo aproximadamente 500.

E dentro daquele raio existiam montanhas.

Vales.

Trilhas.

Estradas.

Campings.

Cidades.

Histórias.

Descobriu cedo algo que muitos viajantes demoram para compreender:

aventura não é proporcional à distância.

Você pode atravessar dez mil quilômetros e não descobrir nada.

Pode caminhar vinte quilômetros e voltar diferente.


16. Caminhar porque queria

Existe uma diferença maravilhosa entre as caminhadas da semana e as caminhadas das aventuras.

Durante a semana ele caminhava porque precisava.

No fim de semana podia caminhar porque queria.

Essa diferença é liberdade.

Na cidade:

você precisa chegar ali.

Na montanha:

quero descobrir o que existe depois daquela curva.

Na cidade havia relógio.

Na trilha havia horizonte.

Na cidade havia ponto.

Na montanha havia cume.

Talvez por isso as pernas que durante a semana eram ferramentas de transporte se transformassem no fim de semana em instrumentos de descoberta.


17. Então apareceu a câmera

Em algum momento surgiu dinheiro suficiente para outra conquista.

Uma câmera fotográfica brasileira de 35 mm.

Não era Leica.

Não era Nikon profissional.

Não era equipamento de fotógrafo da National Geographic.

Sua óptica, lembrada décadas depois, merece uma definição técnica extremamente precisa:

perversa.

Fotografava mal.

E daí?

Ela possuía uma característica que nenhuma câmera moderna consegue reproduzir:

estava lá.

Foi para as aventuras.

Viu aquelas pessoas.

Viu aqueles lugares.

Recebeu aquela luz.


18. Trinta e seis oportunidades

Fotografia analógica ensinava economia.

Um filme tinha quantidade limitada de poses.

Cada clique custava.

Filme custava.

Revelação custava.

Ampliação custava.

Então antes do dedo havia pensamento.

Vale a fotografia?

Qual enquadramento?

A luz está boa?

Chego mais perto?

Espero?

Click.

Pronto.

Não havia tela traseira.

Não existia:

— Ficou ruim, faço mais vinte.

O resultado podia aparecer muito depois.

E talvez justamente por isso cada fotografia carregasse uma expectativa que desapareceu parcialmente da fotografia digital.


19. O aventureiro virou documentarista

Antes da câmera, Vagner voltava com histórias.

Depois dela, voltou também com provas.

Uma montanha.

Um acampamento.

Um amigo.

Uma estrada.

Uma cidade.

Uma roupa.

Uma mochila.

Uma paisagem.

Naquele momento ele provavelmente pensava que estava apenas tirando fotografias.

Não sabia que estava criando um arquivo histórico da própria vida.


20. NEGATIVO.MASTER

Décadas passaram.

As fotografias envelheceram.

A tecnologia mudou.

Mas os negativos permaneceram.

E então aconteceu algo maravilhoso.

As fotografias viraram imagens digitais.

As imagens digitais viraram vídeos.

Os vídeos foram parar no YouTube.

Aquele clique mecânico feito décadas atrás passou a existir em servidores distribuídos pelo planeta.

O pipeline poderia ser representado assim:

AVENTURA
   |
   V
CAMERA 35MM
   |
   V
NEGATIVO
   |
   V
FOTOGRAFIA
   |
   V
SCAN
   |
   V
VIDEO
   |
   V
YOUTUBE
   |
   V
MEMORIA

Um programador mainframe reconheceria imediatamente a arquitetura.

O negativo é o dataset master.

O scan é uma transformação.

O vídeo é aplicação.

O YouTube é distribuição.

Nunca apague o master.


21. A câmera atravessa o Atlântico

A velha câmera continuou existindo.

Em algum momento atravessou o oceano.

Foi para Portugal.

E acabou nas mãos do filho.

Para o filho?

Um cacareco.

Compreensível.

Objetivamente é uma câmera antiga com óptica limitada.

Existem telefones que fazem fotografias incomparavelmente melhores.

Mas para o velho sentado em Astúrias aquele objeto possui outra especificação.

Não é:

DEVICE TYPE = CAMERA
FORMAT = 35MM
OPTICS = QUESTIONABLE

É:

DEVICE TYPE = TIME MACHINE
VALUE = INCALCULAVEL

Por isso talvez seja hora de buscá-la.


22. “Para ele é um cacareco. Para mim foi o mundo.”

O velho repete a frase baixinho.

Uma senhora que passa pelo banco talvez olhe para ele.

Ele sorri.

Não está falando com ela.

Está falando com alguém sentado imaginariamente ao seu lado.

Um garoto de 14 anos.

O menino pergunta:

— Então a câmera era boa?

O velho ri.

— Era uma porcaria.

— Então por que você quer ela de volta?

O velho olha para as árvores.

Demora alguns segundos.

— Porque foi com ela que eu aprendi que minha vida merecia ser fotografada.

O garoto fica quieto.

Essa resposta ele ainda não consegue compreender.


23. O easter egg no banco

Talvez exista ainda outra personagem naquele parque.

Mafalda.

Em Oviedo, uma escultura da personagem de Quino está sentada justamente em um banco do Campo de San Francisco, diante do estanque.

Isso parece um easter egg bom demais para desperdiçar.

Imagine o velho Vagner passando por ela.

Mafalda continua criança.

Ele envelheceu.

Ela permanece fazendo perguntas desconfortáveis ao mundo.

Ele passou a vida tentando responder algumas delas.

Por alguns segundos olha para a menina de bronze.

— Você não envelheceu nada.

Mafalda obviamente não responde.

— Trapaceira.

E continua andando.


24. O menino finalmente pergunta

De volta ao banco, o garoto imaginário faz outra pergunta:

— A gente venceu?

Essa é difícil.

Porque vida não é videogame.

Não existe tela final.

Não aparecem créditos.

Sempre haverá alguma coisa incompleta.

Alguma escolha errada.

Alguma pessoa que partiu.

Alguma oportunidade perdida.

Alguma cicatriz.

Então o velho poderia responder com números.

Carreira.

Viagens.

Computadores.

Trabalho.

Família.

Projetos.

Mas talvez nada disso responda realmente.

Ele pensa na mãe.

Nos irmãos.

Na televisão colorida.

No Nintendo.

Nos cartuchos.

Na comida melhor.

No plano de saúde.

Na escola.

Nas notas.

Na câmera.

Nos negativos.

Nas montanhas.

Então responde:

Lutamos o bom combate.

O garoto entende.


25. Não vencemos porque ficamos ricos

Essa distinção importa.

A vitória daquela história não foi transformar pobreza em ostentação.

Foi transformar trabalho em possibilidade.

Possibilidade de comer melhor.

Possibilidade de cuidar da saúde.

Possibilidade de ajudar a família.

Possibilidade de estudar.

Possibilidade de conhecer tecnologia.

Possibilidade de comprar um videogame.

Possibilidade de fotografar.

Possibilidade de caminhar por uma montanha simplesmente porque queria.

Possibilidade de ampliar progressivamente o mapa.

Essa talvez seja uma definição muito mais interessante de prosperidade:

aumentar a quantidade de escolhas disponíveis.


26. O verdadeiro sistema legado

Programadores iniciantes costumam ouvir que sistemas legados são antigos.

Não é uma boa definição.

Legado é aquilo que continua carregando valor de uma geração para outra.

Nesse sentido, a câmera é legado.

Os negativos são legado.

As histórias são legado.

O conhecimento é legado.

Até determinadas cicatrizes são legado.

Um programa COBOL escrito quarenta anos atrás pode continuar processando porque ainda contém regras importantes.

Uma fotografia ruim feita quarenta anos atrás pode continuar valiosa porque contém pessoas e lugares que não podem ser recompilados.

Há coisas que envelhecem.

Há coisas que acumulam significado.

Não confunda as duas.


27. Dica do velho programador

Se você é um programador COBOL iniciante lendo isto, talvez esteja esperando uma grande lição técnica.

Aqui está:

não despreze sistemas antigos apenas porque parecem ruins.

Primeiro pergunte:

— O que existe aqui que não pode ser recriado?

Faça isso com programas.

Faça isso com documentos.

Faça isso com fotografias.

Faça isso com pessoas.

Uma rotina horrorosa escrita em 1987 pode conter uma regra de negócio que ninguém documentou.

Um negativo riscado pode conter a única fotografia existente de determinado momento.

Uma câmera vagabunda pode ser um cacareco para você e o mundo inteiro para outra pessoa.

Valor e qualidade técnica não são sinônimos.

Essa é uma lição que serve tanto para fotografia quanto para mainframe.


28. 05:15 outra vez

O velho olha novamente o relógio.

É curioso.

Durante décadas, 5h15 significou:

CORRA.

Agora não.

Não há trem para pegar.

Não há ponto.

Não há ônibus.

Não há prova.

Não há marmita.

Não há chefe esperando.

Ele pode simplesmente continuar sentado.

Talvez essa seja uma das maiores conquistas de todas.

Ter finalmente conquistado o direito de não correr.


Epílogo — O garoto chegou

Começa uma chuva fina sobre Oviedo.

O velho levanta.

Durante alguns segundos imagina novamente o garoto.

Quatorze anos.

Marmita.

Carteira profissional.

Caderno.

Pouco dinheiro.

Uma quantidade absurda de vontade.

— Vem — diz o velho.

O garoto pergunta:

— Para onde?

Vagner olha para as ruas de Astúrias.

Sorri.

— Para casa.

O garoto olha desconfiado.

— De trem?

O velho ri.

— Hoje não.

Começam a caminhar.

Um tem mais de meio século de histórias.

O outro ainda não sabe nenhuma delas.

Mas são a mesma pessoa.

Passam pelas árvores.

Talvez pela Mafalda.

Talvez por algum turista fotografando tudo com um telefone capaz de produzir imagens que aquela velha câmera brasileira jamais sonharia registrar.

O velho pensa na câmera que ficou em Portugal.

Preciso trazê-la de volta.

Não para fotografar.

Talvez nunca mais coloque um filme nela.

Não importa.

Ela cumpriu sua missão.

Aquela pequena caixa com óptica perversa viu o mundo quando o mundo ainda era pequeno.

Primeiro o mundo tinha vinte quilômetros até o trabalho.

Depois quinhentos quilômetros de aventuras.

Depois atravessou oceanos.

E agora existe um velho caminhando tranquilamente por Astúrias.

Se algum desconhecido perguntasse quanto vale aquela câmera, talvez não houvesse resposta possível.

Porque existem objetos cujo preço pode ser pesquisado.

E existem objetos cujo valor está armazenado em outro sistema.

Um sistema sem SQL.

Sem backup.

Sem REST API.

Sem documentação.

Chamado memória.

E nesse sistema existe um registro que jamais deve receber DELETE:

01 PRIMEIRA-CAMERA.
   05 FABRICACAO        PIC X(10) VALUE 'BRASILEIRA'.
   05 FILME             PIC X(04) VALUE '35MM'.
   05 OTICA             PIC X(10) VALUE 'PERVERSA'.
   05 VALOR-COMERCIAL   PIC 9(09)V99 VALUE ZEROS.
   05 VALOR-PARA-MIM    PIC X(12) VALUE 'FOI O MUNDO'.

O compilador reclama:

VALOR-PARA-MIM não cabe no campo.

O velho programador olha para a mensagem.

Sorri.

Claro que não cabe.

Nunca coube.


Um Café no Bellacosa Mainframe

Alguns sistemas sobrevivem porque ninguém conseguiu substituí-los.

Algumas fotografias sobrevivem porque ninguém consegue repeti-las.

E algumas histórias sobrevivem porque, depois de quase quarenta anos, o garoto das 5h15 finalmente encontrou tempo para sentar em um banco e contá-las.




domingo, 3 de fevereiro de 2019

🏛️ ARQUIMEDES E A ALAVANCA QUE MOVEU O MAINFRAME

 

Bellacosa Mainframe e a evolução do cobol mainframe para os proximos anos

☕ Um Café no Bellacosa Mainframe

🏛️ ARQUIMEDES E A ALAVANCA QUE MOVEU O MAINFRAME

COBOL, CICS, Db2, VSAM, APIs, MQ, Kafka, Git, CI/CD, cloud, observabilidade, segurança, IA — e o dia em que Arquimedes descobriu que não precisava levantar o mainframe: bastava encontrar o ponto de apoio correto.



🎬 PRÓLOGO — DÊ-ME UMA ALAVANCA E EU MOVEREI O MAINFRAME

Imagine a cena.

Você acaba de entrar em uma grande empresa como programador COBOL.

Na sua frente existe um terminal.

Na tela:

------------------------ ISPF PRIMARY OPTION MENU -----------------------

0  Settings
1  View
2  Edit
3  Utilities
4  Foreground
5  Batch
6  Command

Você aprendeu COBOL.

Aprendeu um pouco de JCL.

Descobriu que PIC X(20) não é uma fotografia de vinte pixels.

Já ouviu falar em CICS, Db2 e VSAM.

Então chega alguém da arquitetura e anuncia:

— Precisamos modernizar o mainframe.

Seu coração dispara.

Você pensa:

“Pronto. Passei seis meses estudando COBOL e agora vão jogar tudo fora.”

Nesse instante, uma figura de barba entra na sala carregando pergaminhos, compassos e uma estranha alavanca.

É Arquimedes de Siracusa.

Ele observa o IBM Z, olha para você e pergunta:

— Jovem programador, quem disse que modernizar significa destruir?

Você aponta para uma apresentação corporativa onde aparecem:

CLOUD
KUBERNETES
MICROSERVICES
APIs
KAFKA
DEVOPS
AI

Arquimedes sorri.

— Dê-me um ponto de apoio suficientemente bom e moverei o mundo.

Ele olha novamente para o mainframe.

— Para este aqui talvez precisemos também de MQ.

E começa nossa aventura.



🏛️ CAPÍTULO 1 — O MAINFRAME NÃO É UMA ILHA

O primeiro conceito que precisamos compreender é simples:

Mainframe Integration & Modernization não significa simplesmente substituir COBOL.

Uma aplicação empresarial tradicional pode possuir:

COBOL
  │
  ├── CICS
  ├── IMS
  ├── Db2
  ├── VSAM
  ├── MQ
  └── Batch/JCL

Durante décadas, grande parte do processamento corporativo podia acontecer nesse ecossistema.

Mas a empresa de 2026 também possui:

Mobile
Web
APIs
Cloud
SaaS
Containers
OpenShift
Kafka
Analytics
Data Lake
AI
CRM
Fraud Detection
Observability

A pergunta interessante, portanto, não é:

“Como tiramos o COBOL daqui?”

A pergunta é:

“Como fazemos todos esses mundos trabalharem juntos?”

Arquimedes provavelmente reconheceria imediatamente o problema.

Você não precisa carregar uma pedra gigantesca nas costas se puder construir uma máquina capaz de movimentá-la.

Modernização funciona de maneira semelhante.



⚖️ CAPÍTULO 2 — O PONTO DE APOIO

Imagine uma aplicação COBOL executando perfeitamente há vinte anos.

Ela calcula alguma regra extremamente importante.

Talvez limite de crédito.

Talvez impostos.

Talvez liquidação financeira.

Talvez autorização de pagamento.

Por que reescrever imediatamente essa lógica apenas porque um aplicativo mobile precisa utilizá-la?

Considere:

3270
 │
 ▼
CICS
 │
 ▼
COBOL
 │
 ▼
Db2

Essa aplicação pode funcionar muito bem.

O problema é que agora alguém deseja acessar aquela função através de:

Smartphone

Uma possibilidade seria:

Smartphone
    │
    ▼
REST API
    │
    ▼
z/OS Connect
    │
    ▼
CICS
    │
    ▼
COBOL
    │
    ▼
Db2

Observe a genialidade.

O programa COBOL pode continuar executando a regra empresarial.

O que mudou foi a maneira de chegar até ele.

Arquimedes apontaria para o desenho:

— Eis sua alavanca.



🔌 CAPÍTULO 3 — API ENABLEMENT

Vamos imaginar um programa que trabalha com algo parecido com:

01 CUSTOMER-REQUEST.
   05 CUSTOMER-ID PIC 9(10).

01 CUSTOMER-RESPONSE.
   05 CUSTOMER-NAME  PIC X(40).
   05 CUSTOMER-LIMIT PIC 9(9)V99.

Para um programador COBOL, isso é perfeitamente compreensível.

Mas um desenvolvedor web provavelmente espera algo como:

{
  "customerId": 123456
}

e deseja receber:

{
  "customerName": "JOAO SILVA",
  "customerLimit": 15000.00
}

Existe uma tradução entre mundos.

JSON
 ↓
estrutura de dados
 ↓
COBOL
 ↓
regra de negócio
 ↓
estrutura de resposta
 ↓
JSON

Isso permite que uma aplicação criada décadas atrás participe de arquiteturas contemporâneas.

Mas cuidado.

Arquimedes levanta um dedo.

— Uma alavanca mal posicionada também derruba paredes.

Transformar cada programa COBOL em uma API não significa automaticamente criar uma boa arquitetura.



🚪 CAPÍTULO 4 — NEM TODO PROGRAMA PRECISA VIRAR API

Imagine 700 programas COBOL.

Alguém tem a brilhante ideia:

“Vamos criar 700 APIs!”

Temos agora:

API001
API002
API003
...
API700

Parabéns.

Transformamos um problema organizado em 700 problemas distribuídos.

APIs precisam de arquitetura.

Precisamos pensar em:

  • contratos;

  • versionamento;

  • granularidade;

  • autenticação;

  • autorização;

  • timeout;

  • rate limiting;

  • tratamento de erros;

  • idempotência;

  • disponibilidade;

  • documentação;

  • observabilidade;

  • governança.

Uma API deveria representar uma capacidade útil ao consumidor, e não simplesmente revelar cada detalhe interno do legado.

Essa diferença parece pequena.

Arquiteturalmente é gigantesca.


📬 CAPÍTULO 5 — ARQUIMEDES DESCOBRE O MQ

Arquimedes encontra uma fila.

Não uma fila de cidadãos esperando pão em Siracusa.

Uma queue.

Ele pergunta:

— Para que serve?

Explicamos:

PRODUTOR
   │
  PUT
   ▼
┌─────────────┐
│    QUEUE    │
└─────────────┘
   │
  GET
   ▼
CONSUMIDOR

O produtor coloca uma mensagem.

O consumidor pode processá-la.

Isso possibilita desacoplamento.

Compare com uma comunicação síncrona:

A ─────► B
A ◄───── B

A chama B e fica esperando.

Agora:

A ─────► QUEUE ─────► B

A e B não precisam necessariamente executar no mesmo instante ou compartilhar exatamente o mesmo ciclo de disponibilidade.

Para ambientes empresariais, isso pode ser extremamente valioso.


⏳ CAPÍTULO 6 — SÍNCRONO OU ASSÍNCRONO?

Essa decisão precisa ser compreendida pelo iniciante.

Imagine:

“Quero consultar meu saldo.”

Você provavelmente deseja resposta imediatamente.

GET /saldo
     │
     ▼
processamento
     │
     ▼
R$ 1.234,56

É um excelente candidato a comunicação síncrona.

Agora imagine:

“Compra aprovada.”

Vários sistemas podem querer saber disso:

COMPRA APROVADA
       │
       ├── Fraude
       ├── Analytics
       ├── CRM
       ├── Pontos
       ├── Notificação
       └── Data Lake

Obrigar o programa responsável pela compra a chamar todos esses sistemas diretamente pode criar um emaranhado terrível.

Melhor considerar uma mensagem ou evento.


🌊 CAPÍTULO 7 — EVENT-DRIVEN ARCHITECTURE

Aqui Arquimedes fica particularmente interessado.

Suponha:

CICS
 │
 ▼
COBOL
 │
 ▼
PAYMENT APPROVED

Em vez de o programa conhecer todos os interessados:

COBOL
 ├── chama FRAUDE
 ├── chama CRM
 ├── chama ANALYTICS
 ├── chama LOYALTY
 └── chama NOTIFICATION

podemos publicar um evento:

           PAYMENT_APPROVED
                  │
       ┌──────────┼──────────┐
       │          │          │
       ▼          ▼          ▼
    Fraud      Loyalty    Analytics
       │
       ▼
 Notification

O produtor diz:

“Isto aconteceu.”

Os consumidores decidem o que fazer.

Esse conceito é fundamental para compreender arquiteturas orientadas a eventos e tecnologias de streaming.

É também onde Kafka costuma aparecer nas conversas modernas.


☁️ CAPÍTULO 8 — CLOUD NÃO É UM BURACO NEGRO QUE ENGOLIRÁ O MAINFRAME

Outro mito precisa desaparecer.

MODERNO = CLOUD

ANTIGO = MAINFRAME

Não.

Arquitetura empresarial não deveria funcionar como campeonato de futebol entre plataformas.

Podemos ter:

              ENTERPRISE
                  │
      ┌───────────┼───────────┐
      │           │           │
    Cloud      IBM Z        SaaS
      │           │           │
Containers       CICS         CRM
      │           │
 APIs            MQ
      │           │
 Kafka           Db2
      └───────────┼───────────┘
                  │
                 DATA

Isso é arquitetura híbrida.

Cada workload pode permanecer onde faz mais sentido considerando:

performance, segurança, custo, disponibilidade, latência, governança, proximidade dos dados e requisitos empresariais.

Arquimedes resume:

Não mova a pedra apenas porque você possui uma alavanca.


🧩 CAPÍTULO 9 — MICROSERVICES NÃO SÃO PÓ MÁGICO

Outra tentação moderna:

“Vamos transformar tudo em microservices.”

Calma.

Imagine um sistema COBOL gigantesco:

CUSTOMER SYSTEM

Ele contém:

Customer
Address
Credit
Payment
History
Fraud
Notification

Talvez faça sentido extrair algumas capacidades gradualmente.

Por exemplo:

        MAINFRAME
   ┌────────────────┐
   │ Customer       │
   │ Credit         │
   │ Payment        │
   └───────┬────────┘
           │
         APIs
           │
     ┌─────┴──────┐
     │            │
Notification   Analytics
 Service        Service

Não precisamos transformar todo COBOL em Java durante um fim de semana.

Aliás, se alguém propuser isso numa sexta-feira às 17h, Arquimedes recomenda correr.


🪴 CAPÍTULO 10 — STRANGLER PATTERN

Uma abordagem extremamente interessante consiste em substituir capacidades gradualmente.

Começamos:

LEGADO
████████████████████

Depois:

LEGADO
████████████████

NOVO
████

Depois:

LEGADO
██████████

NOVO
██████████

E talvez finalmente:

LEGADO
██

NOVO
██████████████████

Ou talvez não.

Talvez aquela pequena parte antiga continue sendo excelente.

Essa é uma lição importante:

Modernização não precisa terminar com zero COBOL.


🧬 CAPÍTULO 11 — AS MUITAS FORMAS DE MODERNIZAR

Arquimedes abre seu pergaminho.

Existem várias estratégias.

RETAIN

Mantemos a aplicação.

REHOST

Mudamos onde ela executa com poucas mudanças funcionais.

REPLATFORM

Alteramos a plataforma ou componentes sem reconstruir tudo.

REFACTOR

Reestruturamos partes da aplicação.

REARCHITECT

Mudamos profundamente sua arquitetura.

REWRITE

Reescrevemos.

REPLACE

Substituímos por outro sistema ou produto.

RETIRE

Descobrimos que ninguém precisava mais daquilo.

Esse último caso produz uma das grandes ironias da arqueologia de software.

Às vezes uma empresa passa meses estudando como modernizar um programa que poderia simplesmente ser aposentado.


🔎 CAPÍTULO 12 — ARQUEOLOGIA DE SOFTWARE

Antes de mexer precisamos saber o que existe.

Imagine:

PROG001
   │
   ├── CALL PROG002
   │       │
   │       └── Db2 TABLE01
   │
   ├── CALL PROG003
   │       │
   │       └── VSAM01
   │
   └── MQ QUEUE01

Agora imagine isso multiplicado por milhares.

Temos:

COBOL
JCL
Copybooks
PROCs
Db2
VSAM
CICS
IMS
MQ
Assembler
REXX

Precisamos responder:

Quem chama este programa?

Qual programa altera esta tabela?

Quem utiliza este copybook?

Qual job executa isto?

Qual transação CICS inicia essa cadeia?

Se eu mudar este campo, quem quebra?

Esse trabalho é chamado frequentemente de Application Discovery e Dependency Analysis.


💥 CAPÍTULO 13 — BLAST RADIUS

O termo é maravilhoso.

Qual será o raio da explosão se alterarmos alguma coisa?

Imagine modificar:

COPY CUSTOMER

Talvez seja usado por:

        CUSTOMER COPYBOOK
              │
     ┌────────┼────────┐
     │        │        │
   PGMA     PGMB     PGMC
     │        │
   CICS     BATCH

Alterar um campo aparentemente inocente pode afetar dezenas ou centenas de componentes.

O programador iniciante aprende rapidamente uma regra:

Em sistemas empresariais, compreender dependências antes de alterar código é tão importante quanto saber programar.


💻 CAPÍTULO 14 — COBOL TAMBÉM PODE TER UMA OFICINA MODERNA

Modernização também acontece no processo de desenvolvimento.

O modelo tradicional poderia ser:

ISPF
 ↓
EDIT
 ↓
COMPILE
 ↓
LINK
 ↓
TEST
 ↓
PROMOTE

Mas podemos incorporar:

IDE
 │
 ▼
Git
 │
 ▼
Pull Request
 │
 ▼
CI Pipeline
 │
 ├── Build
 ├── Static Analysis
 ├── Unit Test
 ├── Security
 ├── Integration Test
 └── Deployment

Observe novamente:

COBOL continua COBOL.

Modernizamos a oficina.


🌳 CAPÍTULO 15 — GIT ENCONTRA O MAINFRAME

Para o novo profissional, Git é particularmente importante.

Conceitos como:

repository
commit
branch
merge
pull request
code review
pipeline

aproximam desenvolvimento mainframe das práticas existentes no restante da engenharia de software.

O grande ganho não é poder dizer:

“Temos Git!”

É conseguir construir rastreabilidade.

Requirement
   ↓
Change
   ↓
Commit
   ↓
Build
   ↓
Test
   ↓
Approval
   ↓
Deploy

Isso é muito mais interessante.


📊 CAPÍTULO 16 — O DETETIVE DA LATÊNCIA

Agora nossa aplicação ficou moderna:

Mobile
 ↓
API Gateway
 ↓
Cloud
 ↓
API
 ↓
MQ
 ↓
CICS
 ↓
COBOL
 ↓
Db2

Então o usuário reclama:

“Está lento.”

Fantástico.

Onde?

Precisamos descobrir.

Talvez:

Mobile          100 ms
Network         250 ms
Gateway          30 ms
Cloud Service   100 ms
Integration      50 ms
CICS             60 ms
COBOL            10 ms
Db2            6300 ms

Sem observabilidade, todos começam a apontar para os outros.

Cloud culpa mainframe.

Mainframe culpa rede.

Rede culpa aplicação.

Aplicação culpa banco.

Banco culpa Mercúrio retrógrado.

É por isso que arquiteturas distribuídas precisam de:

METRICS
LOGS
TRACES
EVENTS
CORRELATION IDs
SLIs
SLOs
ALERTS
DASHBOARDS

Modernização sem observabilidade cria sistemas que conversam muito e explicam pouco.


🔐 CAPÍTULO 17 — QUEM É VOCÊ?

Antes:

USER
 ↓
3270
 ↓
RACF
 ↓
CICS

Agora:

Mobile
 ↓
OAuth / OIDC
 ↓
API Gateway
 ↓
Service
 ↓
API
 ↓
Mainframe
 ↓
RACF

A pergunta fica muito mais interessante:

Quem realmente está executando a transação?

É o usuário?

É uma service account?

É o API Gateway?

É uma aplicação?

O sistema precisa lidar com identidade, autorização, credenciais, tokens, auditoria e propagação de contexto.

Isso é essencial.

Não adianta modernizar a porta e esquecer a fechadura.


🤖 CAPÍTULO 18 — ARQUIMEDES CONHECE A INTELIGÊNCIA ARTIFICIAL

Finalmente mostramos IA generativa para Arquimedes.

Ele observa um programa COBOL com 4.000 linhas.

A IA consegue auxiliar na geração de:

Resumo
 │
 ├── entradas
 ├── saídas
 ├── tabelas
 ├── arquivos
 ├── chamadas
 ├── regras
 └── possíveis dependências

Excelente.

Também pode ajudar com:

  • documentação;

  • explicação de COBOL;

  • compreensão de JCL;

  • criação de testes;

  • geração de exemplos;

  • explicação de SQL;

  • identificação preliminar de dependências;

  • apoio à modernização.

Mas Arquimedes percebe rapidamente a limitação.

IA pode dizer:

“Esta condição aparentemente é redundante.”

E você encontra:

* VBR 1998
* NAO REMOVER.
* PROCESSAMENTO ESPECIAL NO ULTIMO DIA UTIL.

A IA não estava na reunião de 1998.

Nem você.

Esse comentário talvez seja a única lápide arqueológica de uma regra empresarial esquecida.

Portanto:

IA é ferramenta de investigação, não autoridade histórica absoluta sobre o legado.


💣 CAPÍTULO 19 — O MONSTRO DISTRIBUÍDO

Agora chegamos ao maior easter egg arquitetural.

Alguém modernizou tudo:

☁ CLOUD

Microservice A
Microservice B
Microservice C
Microservice D
Microservice E
      │
      ▼
 Kubernetes
      │
      ▼
    APIs
      │
      ▼
   COBOL-X

Todos os microservices dependem do mesmo programa.

Se COBOL-X parar:

💥💥💥

Tudo para.

Criamos um:

Distributed Monolith.

Só que agora ele possui:

containers
network latency
service discovery
APIs
JSON
Kubernetes
cloud

e continua dependendo da mesma função central.

Arquimedes olha para nós.

— Vocês inventaram cinco alavancas para levantar a mesma pedra.

Exatamente.


🧭 CAPÍTULO 20 — PASSO A PASSO PARA MODERNIZAR COM INTELIGÊNCIA

Se você é iniciante, memorize esta sequência.

PASSO 1 — Descubra

Mapeie:

Aplicações
Programas
Dados
JCL
Transações
Interfaces
Dependências

PASSO 2 — Entenda o negócio

Descubra por que aquilo existe.

Código sem contexto empresarial é apenas arqueologia incompleta.

PASSO 3 — Classifique

Para cada componente pergunte:

Retain?
Rehost?
Replatform?
Refactor?
Rewrite?
Replace?
Retire?

PASSO 4 — Identifique interfaces

Procure oportunidades para:

API
MQ
Events
Files
Streaming

PASSO 5 — Desacople cuidadosamente

Não transforme dependências locais em centenas de dependências de rede sem necessidade.

PASSO 6 — Automatize

Introduza:

Git
CI/CD
Tests
Quality Gates
Security

PASSO 7 — Observe

Instrumente:

Logs
Metrics
Traces
Correlation IDs

PASSO 8 — Proteja

Pense em:

Identity
Authentication
Authorization
Encryption
Audit
Secrets

PASSO 9 — Modernize gradualmente

Evite Big Bang quando uma migração incremental puder reduzir risco.

PASSO 10 — Meça

Pergunte se realmente melhoramos:

Time-to-market?
Disponibilidade?
MTTR?
Performance?
Custo?
Segurança?
Experiência do desenvolvedor?
Risco operacional?

Se nenhuma métrica melhorou, talvez tenhamos apenas comprado tecnologia nova.


🥚 EASTER EGG — 03:17

Às 03:17 da madrugada, o telefone toca.

Produção está com problema.

Um arquiteto pergunta:

— Quem mexeu no mainframe?

Ninguém.

O COBOL está executando normalmente.

CICS está saudável.

Db2 está saudável.

Depois de quarenta minutos descobrem:

API Gateway
     │
     ▼
timeout = 2 segundos

Uma nova configuração havia sido implantada naquela noite.

O mainframe levava:

2,08 segundos

para determinada consulta de fechamento.

Durante quinze anos isso nunca foi problema.

A modernização introduziu um timeout de dois segundos.

Moral do easter egg:

Quando modernizamos uma arquitetura, herdamos os problemas antigos e também ganhamos novas categorias de problemas.

Por isso observabilidade e conhecimento ponta a ponta são fundamentais.


🧠 CURIOSIDADE — O VALOR NÃO ESTÁ APENAS NO CÓDIGO

Um sistema COBOL antigo pode representar décadas de decisões empresariais.

Imagine:

IF CUSTOMER-TYPE = '07'
   AND COUNTRY = 'BR'
   AND TRANSACTION-CODE = '83'
   AND AMOUNT > ZERO

Para um desenvolvedor recém-chegado isso parece apenas uma condição.

Mas talvez ela represente:

Lei
Regulação
Contrato
Fraude ocorrida em 2003
Regra tributária
Exceção operacional
Decisão judicial
Comportamento de cliente

É por isso que substituir código não significa automaticamente substituir conhecimento.


🏛️ EPÍLOGO — A ALAVANCA DE ARQUIMEDES

Arquimedes finalmente volta para Siracusa.

Antes de partir, escreve no quadro:

              MAINFRAME
                  │
        ┌─────────┼─────────┐
        │         │         │
       API       MQ       EVENTS
        │         │         │
        └─────────┼─────────┘
                  │
           HYBRID CLOUD
                  │
      ┌───────────┼───────────┐
      │           │           │
 Containers    Analytics      AI
      │
    DevOps

Ele olha para o jovem programador COBOL.

— Agora compreendeu?

O jovem responde:

— Acho que sim. Modernização não significa substituir COBOL.

Arquimedes sorri.

— Continue.

— Significa descobrir onde está o valor, entender as dependências e construir maneiras modernas, seguras e observáveis de utilizar esse patrimônio.

Arquimedes pega sua alavanca.

— Muito melhor.

E antes de desaparecer pela porta, deixa sua última equação:

MODERNIZAÇÃO
      =
VALOR EXISTENTE
      +
INTEGRAÇÃO
      +
AUTOMAÇÃO
      +
OBSERVABILIDADE
      +
SEGURANÇA
      +
EVOLUÇÃO GRADUAL

Talvez essa seja a maior lição de Mainframe Integration & Modernization.

Não precisamos demolir a catedral para instalar eletricidade.

Não precisamos destruir a biblioteca porque inventamos a Internet.

E não precisamos reescrever quarenta anos de regras empresariais simplesmente porque alguém descobriu Kubernetes na semana passada.

O profissional mainframe moderno precisa conhecer COBOL, CICS, IMS, Db2, VSAM e JCL.

Mas seu horizonte não termina ali.

Ele precisa olhar também para:

REST
JSON
OpenAPI
MQ
Events
Kafka
Git
CI/CD
Containers
Cloud
Observability
Security
AI

Porque o verdadeiro profissional de modernização não pergunta:

“Como eu tiro essa aplicação do mainframe?”

Ele pergunta:

“Qual é o melhor lugar para cada capacidade e como faço todas elas trabalharem juntas?”

Arquimedes dizia que precisava apenas de um ponto de apoio para mover o mundo.

No Mainframe Integration & Modernization, o segredo é semelhante.

O IBM Z pode continuar sendo a pedra gigantesca, sólida e confiável no centro da empresa.

APIs podem ser as alavancas.

MQ e eventos podem ser as engrenagens.

Git e CI/CD podem modernizar a oficina.

Observabilidade pode fornecer os instrumentos de medição.

Segurança pode controlar quem toca na máquina.

IA pode ajudar a interpretar os antigos pergaminhos COBOL.

E o programador que começou olhando assustado para uma tela verde finalmente percebe algo importante:

ele não está estudando uma tecnologia do passado.

Está aprendendo a construir pontes entre décadas diferentes da computação.

E talvez seja exatamente aí que esteja o verdadeiro significado de modernizar o mainframe.

Bellacosa Mainframe — porque às vezes, para chegar ao futuro, não precisamos destruir o passado. Precisamos apenas encontrar a alavanca certa.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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