☕ 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

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.

sexta-feira, 1 de fevereiro de 2019

BOOGIEPOP WA WARAWANAI — O ANIME QUE TRANSFORMOU UMA LENDA URBANA EM UM SISTEMA AUTÔNOMO DE DETECÇÃO DE FALHAS HUMANAS

 

Bellacosa Mainframe e o boogiepop wa warawanai

☕💣🎩 OPERADOR, EXISTE UM TASK INVISÍVEL MONITORANDO A HUMANIDADE!

BOOGIEPOP WA WARAWANAI — O ANIME QUE TRANSFORMOU UMA LENDA URBANA EM UM SISTEMA AUTÔNOMO DE DETECÇÃO DE FALHAS HUMANAS

Introdução

Existem animes de terror.

Existem animes de mistério.

Existem animes psicológicos.

E existe Boogiepop wa Warawanai, uma obra tão diferente que, mesmo décadas após sua criação, continua sendo estudada e debatida por fãs, críticos e escritores.

Se a maioria dos animes funciona como um programa linear, executando instruções do início ao fim, Boogiepop funciona como uma análise forense de sistema após um grande incidente.

Você vê fragmentos.

Logs incompletos.

Eventos fora de ordem.

Informações contraditórias.

E somente quando junta tudo percebe que algo muito maior estava acontecendo nos bastidores.


Dados Técnicos

ItemInformação
Título OriginalBoogiepop wa Warawanai (ブギーポップは笑わない)
Título InternacionalBoogiepop and Others
AutorKouhei Kadono
Ilustrador OriginalKouji Ogata
Light Novel OriginalFevereiro de 1998
AnimeJaneiro de 2019
EstúdioMadhouse
DiretorShingo Natsume
Episódios18
GênerosMistério, Terror Psicológico, Sobrenatural, Ficção Científica, Drama, Suspense
Classificação IndicativaAproximadamente 16+

O Estúdio Madhouse

O Datacenter dos Clássicos Psicológicos

Quando o assunto é anime psicológico, poucos estúdios possuem um currículo tão respeitado quanto a Madhouse.

Ela foi responsável por obras como:

Image

Image

Image

Image

  • Monster

  • Death Note

  • Parasyte

  • One Punch Man (Temporada 1)

  • No Game No Life

  • Rainbow

  • Overlord

A escolha da Madhouse para adaptar Boogiepop foi extremamente apropriada.

O estúdio compreendeu que a força da obra não estava na ação.

Estava na atmosfera.

No desconforto.

Na sensação constante de que algo está errado.


Sinopse

Uma estranha lenda urbana circula entre os estudantes.

Dizem que existe uma entidade chamada Boogiepop.

Ela aparece quando o mundo corre perigo.

Quando jovens começam a desaparecer misteriosamente, eventos sobrenaturais passam a ocorrer.

Mas logo descobrimos que os desaparecimentos são apenas a superfície.

Por trás deles existem:

  • Organizações secretas

  • Experimentos humanos

  • Entidades desconhecidas

  • Evolução artificial da humanidade

  • Fenômenos além da compreensão humana

E em algum lugar no meio disso tudo está Boogiepop.

Observando.

Esperando.

Intervindo apenas quando necessário.


Resumo da História

A narrativa acompanha vários estudantes ligados por acontecimentos aparentemente desconexos.

Cada personagem enxerga apenas uma pequena parte do quebra-cabeça.

O espectador recebe:

  • Diferentes perspectivas

  • Diferentes momentos temporais

  • Diferentes interpretações dos mesmos fatos

O resultado é uma narrativa extremamente sofisticada.

Você não acompanha a história.

Você a reconstrói.


Quem é Boogiepop?

O Operador Fantasma do Sistema

Boogiepop é provavelmente um dos personagens mais fascinantes dos animes.

Ele não é exatamente:

  • Um humano

  • Um espírito

  • Um deus

  • Um herói

Ele afirma ser uma "Existência Automática".

Uma espécie de mecanismo de defesa do mundo.

Quando algo ameaça o equilíbrio da humanidade, Boogiepop surge.

Sua função é simples:

Eliminar a anomalia.

Sem ódio.

Sem compaixão.

Sem julgamento.

Como um sistema automatizado corrigindo uma falha crítica em produção.


Principais Personagens

🎩 Boogiepop

A entidade central.

Misterioso.

Calmo.

Perturbadoramente racional.


👧 Touka Miyashita

A estudante através da qual Boogiepop se manifesta.

Sua existência levanta questões profundas sobre identidade e consciência.


⚔️ Nagi Kirima

Conhecida como "A Bruxa de Fogo".

Talvez a personagem mais popular da franquia.

Uma investigadora que enfrenta fenômenos sobrenaturais sem possuir poderes especiais.


🧠 Kazuko Suema

A personagem mais observadora da série.

Representa a lógica diante do caos.


🧬 Manticore

Uma das criaturas mais memoráveis da franquia.

Resultado de experimentos humanos.

Representa a arrogância científica.


🏢 Organização Towa

A verdadeira sombra por trás de inúmeros eventos.

Uma corporação envolvida em manipulação genética e evolução artificial.


O Que Torna Boogiepop Diferente?

1. A Narrativa Não Linear

A maioria dos animes apresenta:

Evento A → Evento B → Evento C

Boogiepop apresenta:

Evento C → Evento A → Evento D → Evento B

E espera que você descubra sozinho o que aconteceu.

É uma experiência semelhante à análise de logs espalhados por múltiplos sistemas.


2. O Monstro Não É o Vilão

Em muitos momentos:

  • Humanos são mais perigosos que monstros.

  • Cientistas são mais assustadores que criaturas.

  • Ambição é mais destrutiva que violência.


3. O Verdadeiro Terror é Existencial

O medo em Boogiepop não vem de sustos.

Vem de perguntas.

Quem sou eu?

O que define uma pessoa?

O livre-arbítrio existe?

O que acontece quando alguém perde sua identidade?


As Grandes Temáticas

Identidade

A série questiona constantemente:

Uma pessoa é seu corpo?

Sua mente?

Suas memórias?

Sua consciência?


Adolescência

Todos os conflitos sobrenaturais funcionam como metáforas da juventude.

Medos.

Inseguranças.

Mudanças.

Solidão.


Evolução Humana

Uma das discussões centrais da obra.

Até onde a humanidade deve evoluir?

Quem decide o próximo estágio?


Individualidade

Boogiepop critica sistemas que tentam transformar pessoas em peças intercambiáveis.


Controle Social

A Organização Towa simboliza instituições que manipulam indivíduos em nome de um suposto bem maior.


As Mensagens Ocultas

A Sociedade Produz Seus Próprios Monstros

Grande parte dos antagonistas nasce de:

  • Rejeição

  • Solidão

  • Abandono

  • Ambição

Os monstros não surgem do nada.

Eles são produzidos pela própria sociedade.


Crescer É Assustador

Todos os personagens enfrentam a transição para a vida adulta.

Os elementos sobrenaturais representam esse processo.


Nem Todo Salvador é Um Herói

Boogiepop salva pessoas.

Mas raramente demonstra empatia.

Ele existe apenas para cumprir sua função.

Isso gera uma reflexão interessante:

Será que eficiência e humanidade são compatíveis?


As Aventuras e Arcos Mais Marcantes

Arco Manticore

Mistura horror corporal, experimentação científica e suspense psicológico.


Arco Imaginator

Explora desejo, poder e a natureza dos sonhos humanos.


Arco King of Distortion

Um dos mais filosóficos.

Discute identidade e percepção da realidade.


Arco Boogiepop at Dawn

Aprofunda os mistérios da origem da Organização Towa.


Impacto Cultural

O Anime que Mudou as Light Novels

Antes de Sword Art Online.

Antes de Re:Zero.

Antes de Monogatari.

Existiu Boogiepop.

A obra ajudou a popularizar o mercado moderno de light novels no Japão.

Muitos autores famosos citam Kouhei Kadono como influência.


Influenciou Diversas Obras

É possível encontrar DNA de Boogiepop em:

  • Durarara!!

  • Baccano!

  • Monogatari

  • Serial Experiments Lain

  • Paranoia Agent

  • Odd Taxi

  • Darker than Black


Houve Censura?

Não houve grandes escândalos de censura.

Porém:

  • Algumas cenas violentas foram suavizadas.

  • Certos aspectos psicológicos foram simplificados.

  • Parte das reflexões filosóficas das novels foi condensada.

Isso ocorreu principalmente para adequação ao formato televisivo.


Curiosidades

🎩 Boogiepop raramente sorri.

Daí o título:

"Boogiepop Nunca Ri".


📚 A novel venceu o Dengeki Novel Prize.

Um dos prêmios mais importantes da indústria japonesa.


🧠 Muitos fãs precisam reassistir ao anime.

Na segunda visualização diversos eventos ganham significados completamente diferentes.


Classificação Bellacosa Mainframe

CritérioNota
Mistério⭐⭐⭐⭐⭐
Complexidade⭐⭐⭐⭐⭐
Terror Psicológico⭐⭐⭐⭐⭐
Filosofia⭐⭐⭐⭐⭐
Personagens⭐⭐⭐⭐⭐
Ação⭐⭐⭐
Reassistibilidade⭐⭐⭐⭐⭐
Facilidade para Iniciantes⭐⭐

Veredito Final

Boogiepop wa Warawanai não é um anime para ser consumido.

É um anime para ser investigado.

Cada episódio funciona como um dataset incompleto.

Cada personagem possui apenas parte da informação.

Cada arco adiciona novos registros ao banco de dados da narrativa.

E quando finalmente todos os logs são correlacionados, o espectador percebe algo extraordinário:

Boogiepop nunca foi apenas uma lenda urbana.

Ele é uma representação da própria humanidade tentando corrigir suas falhas antes que o sistema inteiro entre em ABEND.

Nota Bellacosa Mainframe: 9,8/10

🎩 "O mais sofisticado monitor automático de anomalias humanas já executado no ambiente de produção dos animes." ☕💣🖥️👻


quinta-feira, 31 de janeiro de 2019

Anuncie: Bellacosa Index Page

Divulgando e compartilhando conteúdo

Convidamos você a conhecer o Bellacosa Index Page, um espaço criado para quem valoriza informação bem organizada, curadoria inteligente e divulgação de conteúdos que fogem do óbvio. Mais do que uma simples página de links, o Bellacosa Index funciona como um ponto de encontro entre ideias, projetos e referências que merecem ser descobertas, revisitadas e compartilhadas.

Aqui, cada material divulgado passa por um olhar atento, que busca qualidade, relevância e personalidade. O objetivo é facilitar o acesso a conteúdos que informam, provocam reflexão e despertam curiosidade, seja no campo cultural, tecnológico, criativo ou em temas alternativos que raramente encontram espaço nos canais tradicionais. A proposta é clara: organizar o caos informacional e oferecer ao leitor caminhos confiáveis para explorar novos interesses.

Ao navegar pelo Bellacosa Index Page, você encontrará indicações pensadas para quem gosta de ir além da superfície. Textos, projetos, referências e iniciativas independentes ganham visibilidade, criando uma rede de divulgação que valoriza autoria, identidade e consistência. É um convite à descoberta contínua, onde cada clique pode levar a uma nova perspectiva ou inspiração inesperada.

Se você busca um ambiente que una curadoria, diversidade de temas e uma visão autoral, o Bellacosa Index Page é o lugar certo. Explore, acompanhe as atualizações e permita-se mergulhar em conteúdos que informam, instigam e ampliam horizontes. Descubra o prazer de navegar por uma divulgação feita com critério, intenção e personalidade.



Consulte nossos preços


Ajudando a seu negocio crescer mais, vender mais e atrair novos clientes. 
.
#BellacosaOIndexPage #Planos2019 #CrescendoJuntos #firmandoparcerias #itatiba
.
#Poder #Crescer #Vencer #Vender #AcrediteEmVc
.

Ajudando a ajudar





terça-feira, 29 de janeiro de 2019

Kenja no Mago (賢者の孫) sem Mistérios

 

Bellacosa Mainframe apresenta kenja no mago

☕ Um Café no Bellacosa Mainframe

Kenja no Mago (賢者の孫) sem Mistérios

O Guia do Programador COBOL Padawan para Entender por que Conhecimento Vale Mais do que Poder

Existe uma máxima muito conhecida entre os veteranos de informática:

"Não basta conhecer COBOL. É preciso conhecer negócios."

Essa frase resume perfeitamente Kenja no Mago.

Enquanto a maioria dos isekais mostra heróis treinando durante dezenas de episódios para se tornarem fortes, Shin Wolford praticamente nasce como um "supercomputador mágico". Seu verdadeiro desafio nunca foi derrotar monstros, mas compreender pessoas, política, responsabilidade e o impacto de suas próprias invenções.

É justamente essa inversão que torna Kenja no Mago um dos isekais mais agradáveis da geração de 2019. 


Ficha Técnica

ItemInformação
Título Original賢者の孫 (Kenja no Mago)
Título InternacionalWise Man's Grandchild
AutorTsuyoshi Yoshioka
IlustraçõesSeiji Kikuchi
Web NovelJaneiro de 2015
Light NovelJulho de 2015
MangáMarço de 2016
Anime10 de abril de 2019
EstúdioSILVER LINK.
DiretorMasafumi Tamura
RoteiroTatsuya Takahashi
Episódios12
GêneroIsekai, Fantasia, Magia, Ação, Romance, Comédia
ClassificaçãoFantasia de aventura com elementos de academia mágica

O Studio SILVER LINK.

A SILVER LINK. tornou-se conhecida por produzir séries com ótima direção visual e boa fluidez de animação, como:

  • Bofuri

  • Non Non Biyori

  • Misfit of Demon King Academy

  • Chivalry of a Failed Knight

Em Kenja no Mago, o estúdio investiu principalmente em:

  • efeitos mágicos coloridos;

  • batalhas rápidas;

  • explosões cinematográficas;

  • excelente iluminação;

  • animações fluidas durante os combates.

Embora o orçamento não seja comparável ao de grandes produções como Mushoku Tensei, o resultado final é consistente e divertido. 


Sinopse

Um jovem japonês morre em um acidente de trânsito.

Ele renasce em um mundo medieval mágico.

É encontrado pelo lendário herói Merlin Wolford, conhecido mundialmente como "O Sábio".

Merlin decide criá-lo como seu neto.

Durante quinze anos ensina:

  • magia;

  • alquimia;

  • combate;

  • estratégia;

  • pesquisa.

Mas esquece de ensinar algo essencial...

como viver em sociedade.

Quando Shin entra na Academia de Magia, todos descobrem que existe alguém capaz de destruir exércitos inteiros... mas que não entende sequer as convenções sociais mais básicas. (AnimeWiki)


Resumo da História

A trama acompanha a evolução de Shin enquanto ele:

  • faz amigos;

  • aprende diplomacia;

  • enfrenta demônios;

  • desenvolve novas tecnologias mágicas;

  • combate organizações malignas;

  • ajuda diferentes reinos.

O foco não está apenas nas batalhas, mas em como uma pessoa com conhecimento avançado pode transformar uma sociedade inteira.


Os Personagens

Shin Wolford

O protagonista.

Possui memória parcial da vida passada.

Sua vantagem não é apenas o poder.

É a forma científica de pensar.

Enquanto os demais magos repetem fórmulas antigas, Shin pergunta:

"Existe uma maneira melhor?"

Essa mentalidade revoluciona toda a magia do mundo.


Merlin Wolford

O maior mago da história.

Herói nacional.

Lenda viva.

Seu único erro foi enorme:

ensinar magia antes de ensinar bom senso.

Merlin representa o típico especialista técnico brilhante que esquece de transmitir habilidades humanas.


Melinda Bowen

Esposa de Merlin.

Também considerada uma das pessoas mais poderosas do reino.

É praticamente a "avó perfeita".


Sicily von Claude

A protagonista feminina.

Doce.

Inteligente.

Gentil.

Especialista em magia de suporte.

Ao contrário de muitos romances em isekai, sua relação com Shin evolui de forma natural e sem prolongar indefinidamente o "vai ou não vai".


August von Earlshide

O príncipe.

Longe do clichê do nobre arrogante, demonstra maturidade, liderança e visão política, tornando-se um dos aliados mais importantes de Shin.


Maria von Messina

Responsável por boa parte do humor.

Especialista em magia ofensiva.

Seu jeito impulsivo cria momentos divertidos durante o treinamento e as batalhas.


O Sistema de Magia

Uma das ideias mais interessantes da obra.

A magia funciona por imagem mental.

Quanto melhor o mago compreende um fenômeno físico, mais eficiente é seu feitiço.

Por exemplo:

  • explosões;

  • pressão;

  • temperatura;

  • gravidade;

  • aceleração.

Como Shin possui conhecimentos científicos do Japão moderno, ele cria feitiços muito mais eficientes que os tradicionais.

É quase como um programador COBOL que aprende algoritmos modernos e otimiza um sistema legado sem abandonar sua base.


As Aventuras

Durante a temporada acompanhamos:

  • ingresso na Academia de Magia;

  • formação de amizades;

  • treinamentos;

  • torneios;

  • batalhas contra demônios;

  • conflitos entre reinos;

  • pesquisas mágicas;

  • desenvolvimento de equipamentos encantados;

  • criação de novas técnicas de combate.

A história alterna ação, romance e humor de forma equilibrada.


O que torna Kenja no Mago diferente?

Apesar de compartilhar elementos comuns dos isekais, há diferenças importantes:

1. O protagonista não busca poder

Ele já é extremamente poderoso.

O desafio é amadurecer.


2. Romance sem enrolação

Shin e Sicily assumem seus sentimentos cedo.

Não existe um harém tradicional dominando a narrativa.


3. Ciência aplicada à magia

Poucos isekais utilizam raciocínio científico como elemento central do sistema mágico.


4. Amigos úteis

Os personagens secundários realmente evoluem.

Não servem apenas como espectadores do protagonista.


5. Humor baseado em ingenuidade

Grande parte da comédia surge porque Shin não percebe o quanto suas ações parecem absurdas para as outras pessoas.


Temáticas

O anime aborda diversos temas:

  • responsabilidade;

  • educação;

  • inovação;

  • liderança;

  • amizade;

  • ética no uso do conhecimento;

  • consequências da tecnologia;

  • amadurecimento.


As Mensagens Ocultas

Conhecimento transforma civilizações

A maior arma de Shin não é sua magia.

É sua capacidade de pensar diferente.


Especialistas também precisam aprender habilidades sociais

Merlin forma um mago perfeito.

Mas esquece de formar um cidadão.

É uma crítica divertida ao ensino extremamente técnico.


Inovação nasce da curiosidade

Enquanto todos aceitam tradições, Shin questiona tudo.

Esse comportamento lembra grandes avanços da engenharia e da computação: quem pergunta "por quê?" frequentemente encontra uma solução melhor.


Poder exige responsabilidade

Cada nova magia criada por Shin altera o equilíbrio entre as nações.

O anime mostra que tecnologia sem governança pode gerar riscos enormes.


Para um Programador COBOL Padawan

Imagine que Merlin ensinou COBOL, JCL, CICS, Db2, VSAM, RACF e IMS para um jovem brilhante...

...mas esqueceu de explicar:

  • como funciona um banco;

  • como conversar com usuários;

  • regras de negócio;

  • impacto financeiro das decisões;

  • trabalho em equipe.

Você teria um excelente programador...

...mas um profissional incompleto.

Essa é exatamente a jornada de Shin Wolford.


Impacto Cultural

Embora não tenha alcançado o fenômeno de séries como Re:Zero, Overlord ou Mushoku Tensei, Kenja no Mago consolidou um arquétipo que se tornou muito popular: o protagonista superpoderoso que usa conhecimento moderno para revolucionar um mundo de fantasia. A série também foi elogiada por desenvolver um romance direto e por manter um tom leve e divertido, conquistando um público fiel entre fãs de isekai. 


Curiosidades

  • A obra começou como uma web novel publicada no site Shōsetsuka ni Narō, plataforma que revelou diversos sucessos do gênero isekai.

  • O anime adapta apenas parte da história das light novels.

  • A light novel continuou além do conteúdo visto na animação, oferecendo muito material para quem deseja acompanhar a jornada de Shin.  


Classificação Bellacosa Mainframe

CategoriaNota
História⭐⭐⭐⭐☆ (8,6/10)
Worldbuilding⭐⭐⭐⭐☆ (8,7/10)
Sistema de Magia⭐⭐⭐⭐⭐ (9,4/10)
Personagens⭐⭐⭐⭐☆ (8,8/10)
Romance⭐⭐⭐⭐⭐ (9,1/10)
Comédia⭐⭐⭐⭐☆ (8,8/10)
Ação⭐⭐⭐⭐☆ (8,9/10)
Ritmo⭐⭐⭐⭐☆ (8,7/10)
Diversão⭐⭐⭐⭐⭐ (9,2/10)

Conclusão

Kenja no Mago não pretende desconstruir o gênero isekai nem reinventar suas regras. Seu mérito está em executar muito bem uma fórmula conhecida, combinando fantasia, humor, romance e batalhas mágicas com um protagonista cuja maior força não é apenas o poder, mas a capacidade de aplicar conhecimento de forma criativa. Para o universo Bellacosa Mainframe, a mensagem é clara: dominar uma linguagem, uma ferramenta ou uma tecnologia é apenas o começo. O verdadeiro mestre — seja um mago ou um programador COBOL — é aquele que transforma conhecimento em inovação, sem esquecer que bom senso, ética e responsabilidade são tão importantes quanto qualquer feitiço ou algoritmo.


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