☕ 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

domingo, 7 de janeiro de 2024

Magic Maker: COBOL, Ciência e o Dia em que Descobrimos que Magia Era Apenas uma API sem Documentação

 

Bellacosa Mainframe magic maker e a ciencia do dia api cobol

☕ Um Café no Bellacosa Mainframe

Magic Maker: COBOL, Ciência e o Dia em que Descobrimos que Magia Era Apenas uma API sem Documentação

🪄 Quando Shion encontrou um fenômeno estranho, fez aquilo que todo programador experiente faria: desconfiou da documentação. O problema é que não havia documentação.

Existe uma regra não escrita da informática corporativa:

se alguma coisa funciona há tempo suficiente, eventualmente ninguém mais saberá explicar por quê.

O programa está lá.

Compila.

Executa toda madrugada.

Recebe um arquivo de 14 milhões de registros.

Abre um VSAM que alguém criou quando Michael Jackson ainda lançava discos.

Consulta uma tabela Db2 cujo nome começa com TBHIST.

Chama três módulos COBOL.

Um deles possui comentário de 1997 dizendo:

      * ALTERADO CONFORME SOLICITACAO DO USUARIO.
      * NAO REMOVER ESTA VALIDACAO.

Qual usuário?

Qual solicitação?

Por que não remover?

Ninguém sabe.

Mas você remove?

Nem morto.

Agora imagine a situação inversa.

Você chega a um sistema gigantesco, encontra evidências de que existe uma funcionalidade extraordinária escondida em algum lugar, mas ninguém sequer sabe que ela existe.

Não existe manual.

Não existe README.

Não existe Swagger.

Não existe Javadoc.

Não existe copybook.

Não existe runbook.

Não existe um veterano chamado Cláudio sentado no canto da sala dizendo:

“Ah, isso aí foi o Marcão que fez em 1988.”

Nada.

Você possui apenas o fenômeno.

Uma espécie de resposta produzida pelo sistema.

E precisa descobrir:

qual é a API?

Essa, camaradas, é uma maneira deliciosamente nerd de enxergar Magic Maker: Isekai Mahou no Tsukurikata.

Shion não chegou a um mundo sem magia.

Talvez essa seja nossa primeira interpretação errada.

Ele chegou a um mundo onde a magia existia como fenômeno, mas ainda não existia como tecnologia.

E essa diferença muda tudo.


🧙‍♂️ MAGIC NOT FOUND

A premissa é quase uma piada pronta.

Nosso protagonista sempre sonhou com magia.

Morre.

Reencarna em outro mundo.

Olha em volta.

Fantasia medieval.

Campo.

Espadas.

Castelos.

Tudo certo.

Agora só falta aparecer alguém dizendo:

Fireball!

Nada.

Shion começa a investigar e percebe algo absurdo:

as pessoas daquele mundo não conhecem magia.

Se fosse um isekai convencional, abriria uma tela:

WELCOME, SHION!

CLASS: ARCHMAGE
LEVEL: 1
MANA: 999999
SPECIAL SKILL:
[CREATION MAGIC SSS+]

Obrigado por jogar.

Mas Magic Maker escolhe um caminho mais interessante.

Shion recebe praticamente:

IEF450I MAGIC JOB FAILED
SYSTEM COMPLETION CODE=0C4

MAGIC FACILITY NOT AVAILABLE

E então surge a pergunta fundamental:

E se magia não estiver ausente?
E se ninguém simplesmente descobriu como utilizá-la?

O programador COBOL imediatamente levanta uma sobrancelha.

Ahhhhh.

Agora temos um problema interessante.


🔬 1. A diferença entre fenômeno e tecnologia

Relâmpagos existiam antes de Benjamin Franklin.

Magnetismo existia antes de alguém construir um motor elétrico.

Ondas eletromagnéticas existiam antes do rádio.

Urânio era radioativo antes de Becquerel.

Microrganismos existiam antes de Leeuwenhoek olhar através de suas lentes.

A natureza não esperou nossa documentação para funcionar.

Nós é que demoramos para compreender a interface.

Isso nos leva a uma ideia fundamental:

Uma coisa pode existir muito antes de alguém descobrir como controlá-la.

Em Magic Maker, Shion começa justamente aí.

Ele observa fenômenos.

Luzes.

Energia.

Comportamentos estranhos.

E começa a perguntar.

O QUE É ISSO?
       ↓
QUANDO ACONTECE?
       ↓
POR QUE ACONTECE?
       ↓
POSSO REPETIR?
       ↓
POSSO CONTROLAR?
       ↓
POSSO ENSINAR?

Observe a transformação.

Quando acontece espontaneamente:

fenômeno.

Quando conseguimos reproduzir:

experimento.

Quando entendemos parcialmente:

conhecimento.

Quando conseguimos controlar:

tecnologia.

Quando outra pessoa consegue repetir:

engenharia.

E quando criamos um manual de 1.842 páginas que ninguém lê:

produto IBM.

😆


🧪 2. Shion inventou o laboratório antes de inventar a magia

Essa é uma das coisas que mais gosto conceitualmente em Magic Maker.

Shion não precisa descobrir apenas magia.

Ele precisa descobrir como descobrir magia.

Parece uma diferença pequena.

Não é.

Imagine receber uma caixa preta.

Existe uma entrada.

Existe uma saída.

Você não possui código-fonte.

Então começa:

INPUT A → OUTPUT X
INPUT B → OUTPUT X
INPUT C → OUTPUT Y
INPUT C + TEMPERATURA → OUTPUT Z

Você anota.

Repete.

Altera uma variável.

Observa.

Tenta novamente.

Parabéns.

Você acabou de começar uma engenharia reversa.

É exatamente o que Shion faz com seu universo.

A natureza é o mainframe.

A magia é uma rotina escondida.

E Shion está tentando descobrir o CALL.

       CALL 'MAGIC001'
           USING WS-INTENCAO
                 WS-ENERGIA
                 WS-ALVO
                 WS-RESULTADO.

Problema:

ninguém possui o copybook.

😂


🧠 3. O maior superpoder de Shion não é magia

Aqui mora uma sutileza maravilhosa.

O maior poder que Shion trouxe de nosso mundo talvez não seja conhecimento científico específico.

É uma coisa muito mais simples:

ele sabe que magia deveria ser possível.

Parece bobagem.

Mas pense.

Duas pessoas observam uma luz estranha sobre um lago.

Pessoa A:

Bonito.

Pessoa B:

O que produz isso?

Pessoa A:

Sei lá. Sempre acontece.

Pessoa B:

Sempre quando?

Pessoa A:

À noite.

Pessoa B:

Com determinada temperatura?

Pessoa A:

Nunca pensei nisso.

Pessoa B:

Acontece em outro lago?

Pessoa A:

Nunca procurei.

Pessoa B:

Podemos capturar?

Pessoa A:

Para quê?!

Essa última pergunta é maravilhosa.

Para quê?

Porque grande parte das descobertas começa antes de existir uma utilidade.


☕ 4. A curiosidade é uma transação sem business case

Aqui entramos numa área perigosíssima para qualquer departamento financeiro.

Imagine Shion apresentando o projeto.

Projeto MAGIC

Objetivo: descobrir se existe uma forma desconhecida de energia.

ROI previsto: desconhecido.

Prazo: desconhecido.

Aplicações comerciais: desconhecidas.

Probabilidade de sucesso: desconhecida.

Orçamento: precisamos descobrir.

O gerente fecha a apresentação.

Reprovado.

😂

Esse é um problema histórico da pesquisa básica.

Quando Faraday estudava eletricidade, ninguém poderia apresentar um PowerPoint mostrando:

ROADMAP

1831 — Indução eletromagnética
1879 — Lâmpadas comerciais
1947 — Transistor
1971 — Microprocessador
1981 — IBM PC
2007 — Smartphone
2026 — IA discutindo anime com COBOLzeiro

O futuro não fornece documentação antecipada.

Primeiro alguém pergunta.

Depois descobrimos para que serve.

Shion é movido inicialmente por algo tremendamente humano:

curiosidade.

Ele quer magia porque magia é fascinante.

E isso basta para começar.


⚙️ 5. O primeiro MVP mágico

Depois de observar e experimentar, eventualmente algum fenômeno torna-se reproduzível.

Temos então algo equivalente ao:

Hello World da magia.

Todo programador conhece esse momento.

Você instala uma linguagem.

Configura ambiente.

Cria projeto.

Compila.

Hello World

Tecnicamente inútil.

Emocionalmente gigantesco.

Porque significa:

a cadeia inteira funciona.

Compilador.

Runtime.

Bibliotecas.

Ambiente.

Execução.

Saída.

Na magia ocorre a mesma coisa.

O primeiro fenômeno controlado pode ser pequeno.

Mas prova uma hipótese colossal:

humanos conseguem interferir conscientemente nesse sistema.

Pronto.

Acabou.

O mundo mudou.

Só ainda não sabe.


📚 6. Da descoberta para a API

Agora chegamos ao nosso título.

Uma API é uma interface.

Você não precisa necessariamente saber tudo que acontece internamente.

Precisa conhecer:

entrada, contrato, comportamento e saída.

Imagine que Shion descubra:

INTENÇÃO
+
CONCENTRAÇÃO
+
ENERGIA MÁGICA
+
MÉTODO
=
EFEITO

Temos praticamente:

POST /magic/fire

{
   "mana": 20,
   "target": "goblin",
   "intensity": 5
}

Resposta:

HTTP/1.1 200 OK

{
   "spell": "fire",
   "status": "success"
}

Mas como todo desenvolvedor sabe, o inferno começa nos casos excepcionais.

400 BAD REQUEST

Concentração inválida.

401 UNAUTHORIZED

Usuário não possui habilidade.

429 TOO MANY REQUESTS

Mana esgotada.

500 INTERNAL MAGIC ERROR

Você transformou acidentalmente o galinheiro em antimateria.

😆


🧯 7. E alguém precisa descobrir os limites

Todo sistema possui limites.

É uma das diferenças entre fantasia infantil e engenharia.

Engenharia pergunta:

quanto?

Quanto processamento?

Quanto armazenamento?

Quantas transações?

Quantos usuários simultâneos?

Quanto tempo?

Qual intensidade?

Qual temperatura?

Qual tolerância?

Qual taxa de erro?

Shion começa a fazer perguntas semelhantes sobre magia.

Quanto consigo produzir?

Quantas vezes?

Qual o custo físico?

Quanto tempo preciso recuperar?

O que acontece quando ultrapasso o limite?

De repente surge algo semelhante a:

MAGICAL CAPACITY PLANNING

E aqui um sysprog começa a sorrir.

Porque descobrimos o WLM da magia.

😂

Não basta possuir recurso.

É preciso gerenciá-lo.


🏥 8. Quando o brinquedo vira sistema crítico

Então Magic Maker faz algo importante.

A magia deixa de ser brincadeira.

Surge doença.

Surgem pessoas precisando daquela descoberta.

Nesse momento Shion atravessa uma fronteira ética.

Antes:

“Vamos tentar isso para ver o que acontece.”

Agora:

“Se eu errar, alguém pode sofrer.”

Bem-vindo aos sistemas críticos.

Um SOC7 num programa de treinamento é aprendizado.

Um SOC7 processando folha salarial às quatro da manhã é incidente.

Um erro num jogo pode derrubar seu personagem.

Um erro num sistema hospitalar pode afetar uma pessoa real.

A tecnologia é a mesma.

A responsabilidade mudou.


⚠️ 9. A descoberta cria responsabilidade

Existe uma mensagem escondida muito interessante aí.

Enquanto Shion é o único capaz de fazer alguma coisa, existe uma dependência enorme.

Chamamos isso em TI de:

bus factor = 1.

Ou, no dialeto Bellacosa:

Se Shion for atropelado pela carroça amanhã, acabou a magia?

😆

Esse é um problema sério.

Se sim, ele não criou uma tecnologia.

Criou uma habilidade pessoal.

Para virar tecnologia de verdade, magia precisa sair da cabeça de Shion.

Precisa existir:

DOCUMENTAÇÃO
     ↓
TREINAMENTO
     ↓
REPETIBILIDADE
     ↓
PADRONIZAÇÃO
     ↓
NOVOS PRATICANTES

Isso talvez seja ainda mais importante do que lançar feitiços.


🧙‍♀️ 10. Marie é a primeira homologação

E aqui Marie assume um papel conceitualmente delicioso.

Ela não é simplesmente “a irmã do protagonista”.

Marie representa o primeiro teste fundamental:

outra pessoa consegue compreender aquilo que Shion descobriu?

Se apenas Shion consegue produzir magia:

FEATURE

Se Marie consegue:

PROOF OF CONCEPT

Se dez pessoas conseguem:

TECHNOLOGY

Se dez mil conseguem:

INFRASTRUCTURE

Se ninguém sabe mais quem inventou:

LEGACY

😂


🏛️ 11. O momento em que magia vira legado

Agora vamos avançar cem anos.

Shion morreu.

Marie virou personagem histórica.

Existem escolas de magia.

Há especialistas.

Feitiços possuem classificação.

Existem normas.

Bibliotecas.

Departamentos.

Certificações.

Provavelmente teremos:

Certified Magic Professional Level 1.

Depois:

Magic Solution Architect.

Depois alguém cria:

Agile Magic Practitioner.

Pronto.

Destruíram tudo.

😂

Mas então surge uma nova geração.

Um jovem mago olha um encantamento ancestral:

MAGIC-CURE-LEGACY-V17

São 34 páginas de símbolos.

Ele reclama:

Por que essa porcaria é tão complicada?

Outro responde:

Foi Shion quem fez.

— Quem?

— Um mago antigo.

— Vamos reescrever.

🚨🚨🚨

NÃO!

Porque ninguém lembra que naquela linha aparentemente inútil existe uma validação criada durante a epidemia da Doença da Letargia.

E finalmente fechamos o círculo.

A magia de Shion virou...

COBOL.


🧓 12. O verdadeiro mago é o veterano

Imagine Shion aos 75 anos.

Chega um jovem arquiteto.

— Senhor Shion, vamos modernizar a plataforma mágica.

Shion olha desconfiado.

— Como?

— Microservices.

— De magia?

— Sim.

— Por quê?

— Escalabilidade.

— Quantos feitiços vocês executam?

— Quarenta por dia.

Silêncio.

— E vocês precisam de Kubernetes para isso?

😂😂😂

Shion pega café.

A reunião acabou.


🔐 13. E ninguém pensou na segurança

Porque todo inventor eventualmente descobre outra regra universal:

Se uma tecnologia pode fazer algo útil, alguém tentará utilizá-la para fazer alguma besteira.

Magia cura?

Pode ferir.

Produz energia?

Pode destruir.

Move objetos?

Pode roubar.

Influencia matéria?

Pode virar arma.

Portanto, depois da descoberta inevitavelmente chegará:

MAGIC SECURITY FRAMEWORK

Precisamos de autenticação.

Autorização.

Auditoria.

Logs.

Segregação de funções.

Princípio do menor privilégio.

Shion acaba inventando o:

RACF mágico.

PERMIT FIREBALL
       CLASS(SPELL)
       ID(MARIE)
       ACCESS(READ)

Marie:

— READ?!

Shion:

— Ainda não confio em você com UPDATE.

😂


🧬 14. Ciência não é conhecer todas as respostas

Outra bela mensagem de Magic Maker é uma coisa que frequentemente esquecemos.

Ciência não significa:

“Eu sei.”

Frequentemente significa:

“Eu não sei, mas sei como investigar.”

Essa diferença é monumental.

Shion não possui respostas.

Possui método.

E método é extremamente poderoso.

não sei
   ↓
observo
   ↓
formulo hipótese
   ↓
experimento
   ↓
erro
   ↓
aprendo
   ↓
repito

O fracasso deixa de ser oposição ao conhecimento.

Torna-se parte do processo.


💥 15. MAXCC=0008 também ensina

Programadores antigos sabem disso.

Às vezes o erro ensina mais do que o sucesso.

Quando tudo funciona:

ótimo.

Quando quebra:

por quê?

Você abre log.

Dump.

SYSOUT.

CEEDUMP.

Abend-AID.

Fault Analyzer.

SMF.

Descobre algo que não sabia sobre o sistema.

Shion faz exatamente isso com seu universo.

Cada experimento fracassado elimina hipóteses.

Portanto:

FAILURE != NOTHING

Fracasso experimental produz informação.

Isso é ciência.

Isso também é debugging.


🌍 16. E então aparece a consequência que ninguém planejou

Imagine novamente cem anos depois.

Shion queria simplesmente fazer magia.

Mas sua descoberta produz:

escolas mágicas, profissões, medicina mágica, agricultura mágica, armas mágicas, transporte mágico, comunicação mágica, indústria mágica.

Ele criou uma tecnologia de propósito geral.

Isso aconteceu conosco várias vezes.

Eletricidade.

Computadores.

Internet.

IA.

Cada uma começou resolvendo determinados problemas e depois alterou sistemas inteiros.

O inventor perde controle sobre todas as aplicações futuras.

Essa é uma mensagem enorme escondida dentro da fantasia:

inventar alguma coisa significa liberar possibilidades que você talvez jamais consiga prever.


🤖 17. E chegamos inevitavelmente à Inteligência Artificial

Há uma semelhança interessante com nosso momento atual.

Durante décadas, IA era pesquisa.

Depois começou a funcionar melhor.

Depois saiu do laboratório.

Depois chegou aos produtos.

Depois chegou ao público.

Agora estamos discutindo:

segurança, ética, emprego, educação, copyright, autonomia, agentes, governança, auditoria e legislação.

Ou seja:

descobrir que alguma coisa funciona é apenas o começo da história.

Shion descobre magia.

Nossa primeira reação é:

Fantástico!

A pergunta seguinte deveria ser:

E agora?

Quem pode usar?

Quem ensina?

Quem controla?

Quem responde pelo erro?

Quem define limites?

Quem audita?

Quem recebe acesso?

E quem aperta o botão vermelho?


🥚 Easter Egg: MAGIC.PROD

Alguns anos depois, Shion finalmente cria três ambientes:

MAGIC.DEV
MAGIC.HML
MAGIC.PROD

Marie entra na sala.

— Shion, preciso testar um feitiço.

— DEV.

— Mas é rapidinho.

— DEV.

— Só quero ver se funciona.

— DEV.

— Posso testar aqui mesmo.

— MARIE.

— O quê?

Shion lentamente vira a cadeira.

Ninguém testa magia em produção.

Marie revira os olhos.

Cinco minutos depois:

ICH408I USER(MARIE)
SPELL(FIREBALL)
ACCESS INTENT(UPDATE)
ACCESS ALLOWED(NONE)

Shion havia finalmente criado a maior invenção daquele mundo.

Não era magia.

Era controle de acesso.

😂


☕ 18. No fim, Magic Maker fala sobre nós

É por isso que gosto tanto da premissa.

Retire:

castelos, monstros, reencarnação, fantasia e feitiços.

O que sobra?

Um sujeito curioso encontra algo que ninguém compreende.

Ele pergunta.

Observa.

Experimenta.

Falha.

Repete.

Descobre.

Aplica.

Ensina.

E transforma conhecimento individual em conhecimento coletivo.

Essa história aconteceu milhares de vezes na humanidade.

O fogo.

Metalurgia.

Agricultura.

Escrita.

Matemática.

Navegação.

Máquina a vapor.

Eletricidade.

Computação.

Internet.

Inteligência Artificial.

Toda tecnologia suficientemente madura parece óbvia para quem nasceu depois dela.

Uma criança toca uma tela e conversa instantaneamente com alguém do outro lado do planeta.

Não parece milagre.

É rotina.

Mas mostre um smartphone para alguém de 1726.

Você será o mago.


🪄 O segredo nunca foi a magia

Talvez essa seja a grande mensagem de Magic Maker.

Shion não é especial simplesmente porque consegue produzir magia.

Ele é especial porque olhou para alguma coisa que todos viam e fez uma pergunta diferente.

E existe uma enorme diferença entre:

“Isso não existe.”

e:

“Ainda não descobrimos como fazer.”

A primeira frase encerra uma investigação.

A segunda começa uma aventura.

É assim que ciência avança.

É assim que engenharia avança.

É assim que programação avança.

E talvez seja assim que civilizações avancem.


🖥️ Epílogo — 40 anos depois

Um jovem aprendiz encontra Shion numa sala escura.

Há grimórios empilhados por toda parte.

Cristais piscam nas paredes.

No centro da sala existe uma enorme máquina mágica.

— Mestre Shion...

— Sim?

— Precisamos alterar o sistema.

Shion levanta os olhos.

— Qual sistema?

— O sistema central de magia do reino.

Silêncio.

— Você leu a documentação?

— Não existe documentação.

Shion fecha os olhos.

Respira.

Toma um gole de café.

— Existe.

— Onde?

Shion aponta para uma estante gigantesca.

427 grimórios.

O aprendiz empalidece.

— Preciso ler tudo isso?

— Não.

O garoto suspira aliviado.

Shion completa:

Primeiro você precisa entender por que escrevemos tudo isso.

E naquele instante o jovem finalmente compreendeu.

Ele não estava diante do maior mago daquele mundo.

Estava diante de algo muito mais raro.

O último sujeito que sabia como o sistema funcionava.

Na tela de cristal, silenciosamente, apareceu:

MAGIC MAINFRAME V42.1

SYSTEM READY

ACTIVE USERS: 8,492,117
SPELLS TODAY: 417,883,291
UPTIME: 14,327 DAYS

LAST IPL:
DO NOT ASK.

O aprendiz olhou para Shion.

— Mestre... podemos substituir isso por uma arquitetura moderna?

Shion terminou o café.

Sorriu.

E respondeu:

“Claro. Primeiro me explique exatamente o que essa máquina faz.”

O jovem abriu a boca.

Fechou.

Olhou novamente para os 427 grimórios.

E pediu café.

☕😆

Porque no final descobrimos uma verdade universal:

a magia nunca foi apenas uma API sem documentação.

Era um sistema legado esperando alguém curioso o suficiente para fazer engenharia reversa.

E Shion fez exatamente aquilo que cientistas, engenheiros e programadores vêm fazendo desde que o primeiro humano olhou para alguma coisa incompreensível e decidiu não aceitar simplesmente:

“É assim porque sempre foi assim.”

Ele perguntou:

“Por quê?”

Depois:

“Como?”

E finalmente:

“Será que consigo fazer também?”

Foi assim que nasceu a magia.

Foi assim que nasceu a ciência.

Foi assim que nasceu a engenharia.

E, em algum momento obscuro da história...

provavelmente foi assim que nasceu aquele programa COBOL que continua processando corretamente às 03:17 da madrugada, embora ninguém tenha coragem de mexer nele.

//MAGIC   JOB CLASS=A,MSGCLASS=X
//STEP01  EXEC PGM=SHION
//SYSIN   DD *
   OBSERVE
   QUESTION
   EXPERIMENT
   FAIL
   LEARN
   REPEAT
/*

IEF142I MAGIC STEP01 - STEP WAS EXECUTED

MAXCC=0000

Fim do job.

Ou talvez...

apenas o primeiro step. ☕🪄💻

Sem comentários:

Enviar um comentário

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