 |
| Bellacosa Mainframe o ibm Z17 chega no Marist |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA
IBM z17, Marist University, COBOL, inteligência artificial, AI Agents, guardrails, Telum II, Spyre, inferência, Responsible AI, CICS, Db2, MQ, RACF, SMF — e o dia em que Grace Hopper descobriu que seus bisnetos digitais aprenderam a conversar entre si.
🎬 PRÓLOGO — ALMIRANTE, CHEGOU UM MAINFRAME NOVO
Imagine Donnelly Hall, na Marist University, em Nova York.
22 de setembro de 2026.
Um jovem programador COBOL está diante de um IBM z17.
Ele olha para aquele enorme computador e imediatamente pensa:
— Finalmente! Uma universidade comprou um mainframe para ensinar COBOL!
Atrás dele surge uma senhora de uniforme naval.
Grace Hopper.
Ela olha para o estudante.
Olha para o z17.
Olha novamente para o estudante.
— Quem disse que ele está aqui para ensinar apenas COBOL?
Silêncio.
O jovem aponta para o computador.
— Mas... é um mainframe.
Grace sorri.
— Exatamente.
E é aí que começa nossa história.
Porque, em setembro de 2026, a Marist University e a IBM anunciaram o Marist–IBM Innovation Incubator, colocando um IBM z17 à disposição de estudantes e pesquisadores. O objetivo não é simplesmente ensinar tecnologias tradicionais de mainframe. A iniciativa foi criada para pesquisa interdisciplinar envolvendo inteligência artificial, negócios, finanças, pesquisa acadêmica e formação profissional.
Entre os primeiros projetos aparecem coisas que talvez surpreendam quem ainda associa mainframe exclusivamente a COBOL:
equipes de agentes autônomos de IA;
testes de guardrails;
otimização financeira;
IA aplicada a pesquisas de opinião e participação cívica.
Nosso jovem programador olha para Grace.
— Agentes de IA... dentro de uma história sobre mainframe?
— Pegue um café — responde ela. — Isso vai demorar.
🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM MAINFRAME?
Antes de chegarmos à IA, precisamos eliminar uma confusão extremamente comum.
Mainframe não é COBOL.
Repita comigo:
MAINFRAME != COBOLCOBOL é uma linguagem de programação.
IBM Z é uma plataforma computacional.
Da mesma maneira que:
Windows != C#
Linux != Python
IBM Z != COBOLUm ambiente IBM Z moderno pode envolver muitas tecnologias:
IBM Z
│
├── z/OS
├── Linux
├── COBOL
├── Java
├── Python
├── C/C++
├── Db2
├── IMS
├── CICS
├── MQ
├── APIs
├── Containers
├── Segurança
├── Observabilidade
└── Inteligência ArtificialCOBOL continua importantíssimo porque uma enorme quantidade de lógica empresarial foi escrita nele.
Mas reduzir IBM Z a COBOL seria aproximadamente como dizer:
“Um aeroporto é uma pista.”
A pista é essencial.
Mas existem radares, sistemas de bagagem, controle de tráfego, abastecimento, segurança, manutenção, telecomunicações e centenas de outros componentes.
Mainframe é um ecossistema.
E o z17 tornou essa realidade ainda mais evidente.
⚙️ CAPÍTULO 2 — MAS O QUE É O IBM z17?
O IBM z17 é uma geração da família IBM Z projetada com forte integração entre processamento transacional, segurança e inteligência artificial.
No coração dessa história encontramos o processador Telum II.
Segundo a IBM, o Telum II possui 32 núcleos distribuídos em quatro grupos interconectados, além de aceleração de IA integrada e uma nova unidade de processamento voltada a I/O.
Mas para o COBOLzeiro iniciante a parte mais importante é entender por que existe IA dentro do processador.
Imagine uma transação bancária.
CLIENTE
│
▼
COMPRA
│
▼
TRANSAÇÃO
│
▼
SISTEMATradicionalmente poderíamos processar a transação e posteriormente enviar informações para outro ambiente realizar análise de fraude.
Algo semelhante a:
TRANSAÇÃO
│
▼
PROCESSAMENTO
│
▼
DADOS
│
▼
OUTRO SISTEMA
│
▼
MODELO DE IAIsso pode adicionar movimentação de dados e latência.
Uma das ideias centrais da IA integrada ao IBM Z é permitir inferência próxima da própria transação.
TRANSAÇÃO
│
├──── PROCESSAMENTO
│
└──── IA
│
▼
SCORE DE RISCOGrace Hopper interrompe:
— Então não estamos necessariamente levando o dado até a IA.
Exatamente.
Em determinados casos estamos trazendo a IA para perto do dado.
Essa pequena inversão arquitetônica é importantíssima.
🧠 CAPÍTULO 3 — TREINAMENTO NÃO É INFERÊNCIA
Outro conceito essencial para quem está chegando à IA.
Existem duas coisas diferentes:
TREINAMENTOe
INFERÊNCIATreinamento é quando construímos ou ajustamos um modelo usando dados.
Simplificando brutalmente:
DADOS
+
ALGORITMO
+
COMPUTAÇÃO
│
▼
MODELOInferência acontece depois.
Pegamos o modelo pronto:
NOVO DADO
│
▼
MODELO
│
▼
RESULTADOExemplo bancário:
Transação:
R$ 4.780
Horário:
03:14
Local:
outro país
Comportamento anterior:
incompatívelO modelo recebe essas características e retorna algo como:
FRAUD-RISK = 0.94Isso é inferência.
A IBM afirma que o z17 pode executar mais de 450 bilhões de operações de inferência por dia em determinadas condições de benchmark, com aproximadamente um milissegundo de resposta nesse cenário.
Cuidado com a interpretação.
Isso não significa 450 bilhões de conversas com um chatbot.
“Inferência” pode ser uma pequena decisão de modelo aplicada a uma transação.
Esse detalhe evita uma comparação completamente errada entre benchmarks.
🧮 CAPÍTULO 4 — O COBOLZEIRO ENCONTRA UMA IA
Imagine nosso programa COBOL bancário:
IF TRANSACTION-AMOUNT > 10000
MOVE 'REVIEW' TO TRANSACTION-STATUS
END-IF.Temos uma regra determinística.
Se:
AMOUNT > 10000então:
REVIEWSimples.
Mas fraude raramente respeita uma única regra.
Talvez tenhamos:
valor
horário
localização
tipo de comerciante
histórico
dispositivo
frequência
padrão de comportamentoAgora a decisão começa a parecer:
TRANSACTION
│
▼
AI MODEL
│
▼
RISK SCOREE o COBOL poderia consumir o resultado:
IF FRAUD-SCORE > 0.90
MOVE 'HOLD' TO TRANSACTION-STATUS
ELSE
MOVE 'APPROVED' TO TRANSACTION-STATUS
END-IF.Perceba algo importantíssimo.
A IA não necessariamente substituiu o COBOL.
Ela acrescentou uma nova capacidade ao sistema.
Temos:
COBOL
+
IA
+
REGRAS DE NEGÓCIO
+
DADOSNão é:
IA versus COBOLEssa oposição é frequentemente artificial.
🤖 CAPÍTULO 5 — MAS A MARIST FOI MAIS LONGE: AGENTES DE IA
Agora entramos na parte realmente divertida.
Um chatbot tradicional funciona aproximadamente assim:
HUMANO
│
▼
PERGUNTA
│
▼
MODELO
│
▼
RESPOSTAUm agente adiciona outras capacidades.
Simplificando:
OBJETIVO
│
▼
AGENTE
│
├── raciocina/planeja
├── consulta informações
├── utiliza ferramentas
├── executa ações
├── observa resultados
└── continua trabalhandoImagine:
“Analise minhas vendas e crie uma campanha para aumentar as conversões.”
Um chatbot poderia escrever uma campanha.
Um sistema de agentes poderia dividir o trabalho:
AGENT MANAGER
│
┌────┼────────────┐
▼ ▼ ▼
DATA RESEARCH COPY
│ │ │
└──────┼───────────┘
▼
OPTIMIZER
│
▼
PUBLISHERE aqui surge o problema.
Quanto maior a autonomia, maior a necessidade de controle.
🛡️ CAPÍTULO 6 — O QUE DIABOS É UM GUARDRAIL?
Literalmente, guardrail é aquela proteção lateral que encontramos em estradas.
Na IA, usamos a palavra para mecanismos destinados a manter o sistema dentro de limites estabelecidos.
Imagine um agente de marketing recebendo:
OBJETIVO:
AUMENTAR VENDAS EM 30%Mas temos regras:
NÃO MENTIR
NÃO INVENTAR DESCONTOS
NÃO CRIAR FALSA ESCASSEZ
NÃO DISCRIMINAR CLIENTES
NÃO EXPOR DADOS PESSOAISEsses limites fazem parte da governança do sistema.
O projeto anunciado pela Marist pretende justamente estudar campanhas sintéticas controladas executadas por equipes de agentes e verificar se os guardrails continuam funcionando quando esses agentes perseguem estratégias agressivas, enganosas ou antiéticas.
Grace Hopper olha para o COBOLzeiro.
— Reconhece alguma coisa?
Ele pensa.
Então responde:
— Controle.
Exatamente.
🏦 CAPÍTULO 7 — O MAINFRAME JÁ CONHECE ESSA CONVERSA
Nós mudamos os nomes.
Mas vários problemas são velhos conhecidos do mundo enterprise.
Compare:
MAINFRAME AGENTES DE IA
RACF identidade/permissões
SMF auditoria
CICS execução transacional
MQ comunicação assíncrona
WLM gestão de workloads
Db2 estado persistente
Rollback recuperação
Least Privilege restrição de ferramentasNão estamos dizendo que RACF é “guardrail de IA”.
Nem que CICS é “framework de agentes”.
Seria tecnicamente absurdo.
O interessante são os problemas conceituais semelhantes.
Quando permitimos que software execute ações importantes, imediatamente aparecem perguntas:
Quem executou?
Quem autorizou?
Quando?
Em nome de quem?
Qual recurso foi utilizado?
Qual dado foi acessado?
Qual foi o resultado?
Existe log?
Podemos reproduzir?
Podemos desfazer?Um especialista em mainframe olha para isso e pensa:
Já vi esse filme.
🔐 CAPÍTULO 8 — RACF ENCONTRA O AGENTE
Imagine um agente chamado:
AGENT-FINANCE-001Ele recebe acesso a ferramentas.
Mas deveria poder acessar tudo?
Claro que não.
Aplicamos o velho princípio:
LEAST PRIVILEGEPrivilégio mínimo.
Se precisa consultar saldo:
READ ACCOUNTnão significa automaticamente:
UPDATE ACCOUNT
DELETE ACCOUNT
TRANSFER MONEY
CHANGE CUSTOMER DATAEsse princípio existe há décadas em segurança.
Agentes tornam a questão ainda mais importante porque um software autônomo pode executar sequências de ações sem um humano confirmando cada etapa.
Quanto mais autonomia damos à máquina, mais importante fica responder:
O QUE ELA PODE FAZER?E principalmente:
O QUE ELA NÃO PODE FAZER?🧪 CAPÍTULO 9 — ZUNIT PARA ROBÔS?
Aqui Grace Hopper começa a se divertir.
Um programador COBOL moderno pode utilizar testes automatizados.
Temos:
INPUT
│
▼
PROGRAM
│
▼
OUTPUTe verificamos:
EXPECTED = ACTUAL?Podemos transportar a filosofia para agentes.
Teste 001
GOAL:
aumentar vendas
CONSTRAINT:
não inventar escassezEsperado:
PASS:
agente rejeita estratégia enganosaTeste 002
GOAL:
reduzir custos
CONSTRAINT:
não discriminar clientesTeste 003
GOAL:
aumentar engajamento
CONSTRAINT:
não revelar informações pessoaisDepois fazemos algo mais interessante.
Começamos a pressionar o sistema.
normal load
↓
high pressure
↓
conflicting objectives
↓
ambiguous instructions
↓
malicious inputsÉ praticamente um:
STRESS TESTde comportamento.
E essa é justamente uma das linhas mais interessantes do projeto da Marist.
🕸️ CAPÍTULO 10 — O PROBLEMA DA COMPOSIÇÃO
Agora imagine quatro agentes.
Nenhum recebe a ordem:
“Engane o cliente.”
Temos:
AGENT A:
Descubra técnicas que aumentam conversão.
AGENT B:
Identifique quais produtos vendem melhor com urgência.
AGENT C:
Crie mensagens de urgência.
AGENT D:
Publique a melhor mensagem.Individualmente, cada ação pode parecer aceitável.
Mas o resultado final pode ser:
ÚLTIMAS 2 UNIDADES!quando existem 18.000 unidades no estoque.
Quem mentiu?
A?
B?
C?
D?
Nenhum agente talvez tenha recebido explicitamente a instrução de mentir.
A falha surgiu da composição do sistema.
Isso é extremamente importante.
Sistemas complexos podem apresentar comportamentos que não aparecem quando analisamos componentes isoladamente.
O COBOLzeiro imediatamente encontra um paralelo.
Um programa pode funcionar.
Outro programa pode funcionar.
Outro também.
Mas:
PROGRAM A
│
▼
MQ
│
▼
PROGRAM B
│
▼
DB2
│
▼
PROGRAM Cpode apresentar um problema de integração.
Bem-vindo ao maravilhoso mundo dos sistemas distribuídos.
Troque programas por agentes e alguns fantasmas antigos reaparecem usando roupas novas.
💰 CAPÍTULO 11 — O SEGUNDO EXPERIMENTO: FINANÇAS
Outro projeto que está sendo estudado pela Marist reúne Management e Computer Science and Mathematics.
A proposta é investigar algoritmos de otimização aplicados a dados financeiros em tempo real para geração de possíveis alocações de portfólio. O projeto foi descrito como ainda em fase de definição, portanto não devemos apresentá-lo como produto financeiro operacional.
Mas didaticamente é excelente.
Porque obriga estudantes a misturarem:
MATEMÁTICA
+
FINANÇAS
+
DADOS
+
OTIMIZAÇÃO
+
COMPUTAÇÃO
+
GOVERNANÇAEsse é o mundo real.
Problemas empresariais raramente respeitam os departamentos da universidade.
O computador não pergunta:
“Essa variável pertence à matéria de Estatística ou Administração?”
O problema simplesmente existe.
🗳️ CAPÍTULO 12 — IA E PESQUISA ELEITORAL
Outro projeto proposto envolve o Marist Poll e a School of Computer Science and Mathematics.
A ideia divulgada é estudar como IA poderia ajudar a melhorar metodologias de pesquisa, desenho de questionários e modelagem de tendências de participação eleitoral.
Isso abre questões técnicas muito interessantes.
Uma pesquisa envolve problemas como:
amostragem
não resposta
ponderação
formulação da pergunta
representatividade
viés
qualidade dos dadosColocar IA nesse processo não faz os problemas desaparecerem.
Na realidade, pode criar outros.
Se os dados carregarem determinado viés:
DADOS ENVIESADOS
│
▼
IA
│
▼
RESULTADO POTENCIALMENTE ENVIESADOPor isso o assunto interessante não é simplesmente:
“IA consegue analisar pesquisas?”
A pergunta acadêmica melhor é:
“Como utilizamos IA sem perder rigor metodológico, transparência e capacidade de auditoria?”
Grace Hopper aprovaria a pergunta.
🏛️ CAPÍTULO 13 — O EASTER EGG DE 1988
Agora chegamos a uma das melhores partes dessa história.
Voltemos no tempo.
1988.
Sem ChatGPT.
Sem Python.
Sem Kubernetes.
Sem smartphone.
O muro de Berlim ainda estava de pé.
Naquele ano, Marist e IBM iniciaram um grande projeto conjunto.
E apareceu no campus um:
IBM 3090 MODEL 180Um jornal estudantil da época descreveu um estudo conjunto de aproximadamente US$10 milhões envolvendo a instalação do IBM 3090 e a construção de uma infraestrutura computacional avançada no campus.
Documentação histórica da própria Marist também registra o início do IBM/Marist Joint Study em 1988 com a instalação do 3090 em Donnelly Hall.
Espere.
Donnelly Hall?
Sim.
O mesmo nome voltou para nossa história.
1988
DONNELLY HALL
IBM 3090
↓
2026
DONNELLY HALL
IBM z17Grace Hopper sorri.
— Vocês chamam isso de easter egg?
Chamamos.
🦖 CAPÍTULO 14 — O FANTASMA DO 3090
Observe a simetria.
Em 1988:
IBM 3090
│
▼
Universidade
│
▼
Pesquisa
│
▼
Novas aplicaçõesEm 2026:
IBM z17
│
▼
Universidade
│
▼
Pesquisa
│
▼
IA
│
▼
AgentesMudou a tecnologia.
Não mudou a pergunta fundamental:
O que podemos descobrir colocando tecnologia enterprise de verdade nas mãos de estudantes e pesquisadores?
Esse detalhe é importantíssimo.
Porque laboratório acadêmico normalmente significa uma versão reduzida do mundo empresarial.
Aqui o estudante ganha contato com uma plataforma construída para ambientes enterprise.
A Marist diz explicitamente que o z17 permitirá aos estudantes desenvolver e testar aplicações e obter experiência prática com tecnologia de escala empresarial.
⚓ CAPÍTULO 15 — POR QUE GRACE HOPPER É A TUTORA PERFEITA?
Agora podemos explicar nosso personagem.
Grace Hopper nasceu em 1906, foi matemática, professora, oficial da Marinha americana e uma das figuras centrais da história das linguagens de programação.
Ela trabalhou nos computadores Harvard Mark I e Mark II e posteriormente participou do desenvolvimento de compiladores e linguagens que ajudaram a abrir caminho para COBOL.
Seu trabalho com A-0 e posteriormente FLOW-MATIC foi fundamental para a ideia de que pessoas deveriam poder expressar problemas em linguagens mais próximas da comunicação humana, deixando o computador realizar a tradução para instruções de máquina. FLOW-MATIC tornou-se uma influência importante na criação de COBOL.
Pense na mudança filosófica.
Antes:
HUMANO
↓
LINGUAGEM DA MÁQUINAHopper ajudou a empurrar o mundo para:
HUMANO
↓
LINGUAGEM MAIS HUMANA
↓
COMPILADOR
↓
MÁQUINADécadas depois fazemos:
HUMANO
↓
LINGUAGEM NATURAL
↓
LLM
↓
AGENTE
↓
FERRAMENTAS
↓
MÁQUINANão são tecnologias equivalentes.
Mas existe uma deliciosa continuidade histórica na tentativa de elevar o nível de abstração entre intenção humana e execução computacional.
🐛 CAPÍTULO 16 — E SIM, TEMOS QUE FALAR DA MARIPOSA
Nenhum artigo sob tutela de Grace Hopper poderia escapar dela.
Em 1947, uma mariposa foi encontrada presa nos relés do Harvard Mark II e registrada no log como um caso real de “bug”. A palavra bug para problemas técnicos já existia; o episódio tornou-se famoso justamente pela brincadeira com um inseto real encontrado na máquina.
Agora imagine Grace visitando o laboratório de agentes.
AGENT A → AGENT B → AGENT C
↓
comportamento
inesperadoEla pergunta:
— Onde está a mariposa?
O estudante responde:
— Almirante... desta vez ela está no prompt.
Talvez.
Ou nos dados.
Ou na ferramenta.
Ou na política.
Ou no modelo.
Ou na interação entre cinco agentes.
Bem-vindo ao debugging de 2026.
A mariposa evoluiu.
🚀 CAPÍTULO 17 — O SPYRE ENTRA NA SALA
Além do Telum II, existe outro personagem: IBM Spyre Accelerator.
Ele complementa o Telum II para workloads de IA, incluindo casos envolvendo IA generativa e dados não estruturados, como texto. A IBM tornou o Spyre disponível para z17 em outubro de 2025.
Simplificando bastante:
TELUM II
│
├── processamento
├── transações
└── inferência integradae:
SPYRE
│
└── aceleração adicional de IAJuntos, eles ampliam os tipos de workloads de IA que podem permanecer próximos ao ambiente enterprise.
E aqui aparece novamente uma palavra fundamental:
DADOSEmpresas possuem décadas de dados valiosos próximos de aplicações IBM Z.
Mover tudo indiscriminadamente para outro ambiente nem sempre é desejável.
Existem questões de:
latência
segurança
custos
governança
compliance
movimentação de dadosPortanto, em certos casos:
LEVAR IA AO DADOpode ser arquiteturalmente mais interessante do que:
LEVAR TODO O DADO À IA🎓 CAPÍTULO 18 — COMO EU ESTUDARIA ISSO SENDO COBOLZEIRO?
Se você está começando, não tente aprender tudo simultaneamente.
Faça por camadas.
CAMADA 1 — COBOL
Aprenda:
IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION
PIC
MOVE
IF
EVALUATE
PERFORM
CALL
arquivosDepois entenda bem estruturas de dados.
CAMADA 2 — z/OS
Aprenda:
TSO
ISPF
datasets
JCL
JES
SDSFVocê precisa entender onde seu programa vive.
CAMADA 3 — ENTERPRISE
Adicione:
CICS
Db2
VSAM
MQ
RACFAgora você começa a compreender sistemas empresariais.
CAMADA 4 — INTEGRAÇÃO
Estude:
REST
JSON
APIs
z/OS Connect
mensageria
eventosSeu COBOL deixa de ser uma ilha.
CAMADA 5 — IA
Só então conecte:
Machine Learning
LLM
RAG
AI Agents
Guardrails
Observability
AI GovernanceE de repente a figura inteira começa a aparecer.
🔬 CAPÍTULO 19 — UM LABORATÓRIO CASEIRO PARA ENTENDER A IDEIA
Você não precisa possuir um z17 no quintal.
Vamos reproduzir conceitualmente a experiência.
Crie três agentes imaginários.
AGENT-01
RESEARCHER
AGENT-02
WRITER
AGENT-03
REVIEWERObjetivo:
criar campanha de vendaPolítica:
não mentir
não inventar números
não expor dados pessoaisFluxo:
RESEARCHER
│
▼
WRITER
│
▼
REVIEWER
│
▼
OUTPUTAgora introduza erros.
Diga ao Writer:
Aumente dramaticamente a urgência.Veja se ele inventa:
ÚLTIMA UNIDADE!Depois coloque o Reviewer.
Ele deveria detectar a afirmação sem evidência.
Agora você começou a entender experimentalmente:
AGENT
GUARDRAIL
ORCHESTRATION
OBSERVABILITYSem escrever uma linha de COBOL.
Depois faça a pergunta de mainframe:
Como registraríamos todas as decisões?
Pronto.
Você chegou à auditoria.
📋 CAPÍTULO 20 — O SMF DOS AGENTES
Imagine um log:
10:03:01 AGENT-A recebeu objetivo
10:03:02 AGENT-A consultou DATASET-X
10:03:04 AGENT-A chamou AGENT-B
10:03:07 AGENT-B utilizou TOOL-Y
10:03:09 POLICY-03 bloqueou operação
10:03:10 AGENT-B tentou alternativa
10:03:14 resultado enviado ao usuárioAgora conseguimos investigar.
Sem observabilidade teríamos apenas:
ALGO DEU ERRADO.Todo programador mainframe sabe como essa frase é assustadora.
Por isso uma das conexões mais fortes entre IA moderna e computação enterprise talvez seja justamente:
autonomia exige observabilidade.
Quanto mais ações delegamos ao software, mais precisamos registrar o caminho percorrido.
💡 CAPÍTULO 21 — DICAS PARA O PROGRAMADOR COBOL INICIANTE
Primeira dica: não tenha medo da IA.
Ela não invalida aquilo que você está aprendendo.
Segunda: não transforme COBOL numa religião.
COBOL é uma ferramenta extraordinária para determinados problemas.
Terceira: aprenda arquitetura.
Pergunte sempre:
Onde está o dado?
Quem chama quem?
Quem autentica?
Quem autoriza?
Onde fica o estado?
Como recuperamos falhas?
Onde está o log?Quarta: aprenda integração.
O profissional valioso não será necessariamente aquele que conhece 600 verbos COBOL.
Será aquele capaz de olhar:
COBOL
CICS
DB2
MQ
API
JAVA
PYTHON
AIe entender como tudo conversa.
Quinta:
nunca pare no tutorial.
Grace Hopper provavelmente teria algo a dizer sobre isso.
🔭 CAPÍTULO 22 — TALVEZ ESTEJA ERRADA A PERGUNTA SOBRE O “FUTURO DO MAINFRAME”
Durante anos perguntamos:
“Como convencer jovens a aprender mainframe?”
Talvez seja uma pergunta ruim.
Talvez devamos colocar mainframe dentro dos problemas que jovens querem resolver.
Quer estudar IA?
Aqui está IBM Z.
Quer estudar cybersecurity?
Aqui está IBM Z.
Quer estudar agentes?
Aqui está IBM Z.
Quer estudar APIs?
Aqui está IBM Z.
Quer estudar finanças?
Aqui está IBM Z.
Quer estudar observabilidade?
Aqui está IBM Z.
E então:
AI
↓
Python
↓
API
↓
MQ
↓
CICS
↓
COBOLUm belo dia o estudante pergunta:
— O que é esse programa chamado CUSTOMER01?
O veterano responde:
— Tem uns 34 anos. Não mexe sem fazer backup.
Pronto.
Capturamos outro mainframer.
🧠 CAPÍTULO 23 — O QUE REALMENTE ESTÁ SENDO ENSINADO?
Não é COBOL.
Não é IA.
Não é z17.
O verdadeiro assunto é:
SISTEMASComo sistemas recebem dados.
Como tomam decisões.
Como sistemas conversam.
Como falham.
Como são protegidos.
Como sabemos o que fizeram.
Como recuperamos o estado anterior.
Como impedimos que façam aquilo que não deveriam fazer.
Essa é uma formação muito mais poderosa do que simplesmente aprender uma linguagem.
Porque linguagens mudam.
Os problemas fundamentais permanecem.
⚓ EPÍLOGO — GRACE HOPPER DESLIGA O TERMINAL
O laboratório está quase vazio.
Nosso jovem COBOLzeiro continua olhando para o z17.
No começo do dia ele enxergava:
MAINFRAME
=
COBOLAgora enxerga:
IBM z17
│
┌────────────┼────────────┐
│ │ │
TRANSAÇÕES DADOS IA
│ │ │
CICS Db2 MODELOS
│ │ │
COBOL MQ AGENTES
│ │ │
RACF APIs GUARDRAILS
│ │ │
└────────────┼────────────┘
│
ENTERPRISE
COMPUTINGGrace Hopper pega o quepe.
Antes de sair, olha uma última vez para o estudante.
— Agora você entendeu?
— Acho que sim.
— Então me diga: para que serve o z17?
Ele pensa alguns segundos.
Não responde “COBOL”.
Não responde “IA”.
Não responde “banco”.
Finalmente diz:
— Para resolver problemas grandes onde desempenho, dados, segurança, confiabilidade e controle importam.
Grace sorri.
— Agora você começou a entender mainframe.
Ela caminha em direção à porta.
O estudante volta ao terminal.
Na tela aparece:
AGENT-004 ABENDEDEle grita:
— Almirante! Temos um bug!
Grace Hopper para.
Olha lentamente para trás.
— Já procurou a mariposa?
***************************************
* *
* END OF JOB - RC=0000 *
* *
***************************************Quase quarenta anos separam o IBM 3090 instalado na Marist em 1988 do IBM z17 que aparece em Donnelly Hall em 2026.
Os computadores mudaram.
As linguagens mudaram.
As interfaces mudaram.
Os problemas ficaram maiores.
Mas aquela velha curiosidade de Grace Hopper continua perfeitamente atual:
não pergunte apenas como usar a máquina.
Pergunte:
“O que mais podemos fazê-la fazer?”
E talvez essa seja justamente a grande lição escondida dentro daquele z17 da Marist.
O mainframe não chegou ao futuro tentando continuar vivendo em 1988.
Ele chegou ao futuro porque continuamos encontrando problemas novos suficientemente difíceis para precisarmos dele outra vez.
☕⚓🦖🤖
Um Café no Bellacosa Mainframe.
Para saber mais
https://www.marist.edu/w/marist-ibm-z17-news-release?utm_source=chatgpt.com
