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 != COBOL

COBOL é uma linguagem de programação.

IBM Z é uma plataforma computacional.

Da mesma maneira que:

Windows != C#
Linux   != Python
IBM Z   != COBOL

Um 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 Artificial

COBOL 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
   │
   ▼
SISTEMA

Tradicionalmente 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 IA

Isso 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 RISCO

Grace 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:

TREINAMENTO

e

INFERÊNCIA

Treinamento é quando construímos ou ajustamos um modelo usando dados.

Simplificando brutalmente:

DADOS
  +
ALGORITMO
  +
COMPUTAÇÃO
      │
      ▼
    MODELO

Inferência acontece depois.

Pegamos o modelo pronto:

NOVO DADO
    │
    ▼
  MODELO
    │
    ▼
RESULTADO

Exemplo bancário:

Transação:
R$ 4.780

Horário:
03:14

Local:
outro país

Comportamento anterior:
incompatível

O modelo recebe essas características e retorna algo como:

FRAUD-RISK = 0.94

Isso é 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 > 10000

então:

REVIEW

Simples.

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 comportamento

Agora a decisão começa a parecer:

TRANSACTION
     │
     ▼
AI MODEL
     │
     ▼
RISK SCORE

E 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
+
DADOS

Não é:

IA versus COBOL

Essa 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
  │
  ▼
RESPOSTA

Um agente adiciona outras capacidades.

Simplificando:

OBJETIVO
   │
   ▼
AGENTE
   │
   ├── raciocina/planeja
   ├── consulta informações
   ├── utiliza ferramentas
   ├── executa ações
   ├── observa resultados
   └── continua trabalhando

Imagine:

“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
        │
        ▼
    PUBLISHER

E 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 PESSOAIS

Esses 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 ferramentas

Nã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-001

Ele recebe acesso a ferramentas.

Mas deveria poder acessar tudo?

Claro que não.

Aplicamos o velho princípio:

LEAST PRIVILEGE

Privilégio mínimo.

Se precisa consultar saldo:

READ ACCOUNT

não significa automaticamente:

UPDATE ACCOUNT
DELETE ACCOUNT
TRANSFER MONEY
CHANGE CUSTOMER DATA

Esse 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
  │
  ▼
OUTPUT

e verificamos:

EXPECTED = ACTUAL?

Podemos transportar a filosofia para agentes.

Teste 001

GOAL:
aumentar vendas

CONSTRAINT:
não inventar escassez

Esperado:

PASS:
agente rejeita estratégia enganosa

Teste 002

GOAL:
reduzir custos

CONSTRAINT:
não discriminar clientes

Teste 003

GOAL:
aumentar engajamento

CONSTRAINT:
não revelar informações pessoais

Depois fazemos algo mais interessante.

Começamos a pressionar o sistema.

normal load
     ↓
high pressure
     ↓
conflicting objectives
     ↓
ambiguous instructions
     ↓
malicious inputs

É praticamente um:

STRESS TEST

de 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 C

pode 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ÇA

Esse é 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 dados

Colocar 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 ENVIESADO

Por 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 180

Um 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 z17

Grace 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ções

Em 2026:

IBM z17
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
IA
   │
   ▼
Agentes

Mudou 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ÁQUINA

Hopper ajudou a empurrar o mundo para:

HUMANO
   ↓
LINGUAGEM MAIS HUMANA
   ↓
COMPILADOR
   ↓
MÁQUINA

Décadas depois fazemos:

HUMANO
   ↓
LINGUAGEM NATURAL
   ↓
LLM
   ↓
AGENTE
   ↓
FERRAMENTAS
   ↓
MÁQUINA

Nã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
                  inesperado

Ela 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 integrada

e:

SPYRE
│
└── aceleração adicional de IA

Juntos, eles ampliam os tipos de workloads de IA que podem permanecer próximos ao ambiente enterprise.

E aqui aparece novamente uma palavra fundamental:

DADOS

Empresas 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 dados

Portanto, em certos casos:

LEVAR IA AO DADO

pode 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
arquivos

Depois entenda bem estruturas de dados.

CAMADA 2 — z/OS

Aprenda:

TSO
ISPF
datasets
JCL
JES
SDSF

Você precisa entender onde seu programa vive.

CAMADA 3 — ENTERPRISE

Adicione:

CICS
Db2
VSAM
MQ
RACF

Agora você começa a compreender sistemas empresariais.

CAMADA 4 — INTEGRAÇÃO

Estude:

REST
JSON
APIs
z/OS Connect
mensageria
eventos

Seu COBOL deixa de ser uma ilha.

CAMADA 5 — IA

Só então conecte:

Machine Learning
LLM
RAG
AI Agents
Guardrails
Observability
AI Governance

E 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
REVIEWER

Objetivo:

criar campanha de venda

Política:

não mentir
não inventar números
não expor dados pessoais

Fluxo:

RESEARCHER
     │
     ▼
WRITER
     │
     ▼
REVIEWER
     │
     ▼
OUTPUT

Agora 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
OBSERVABILITY

Sem 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ário

Agora 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
AI

e 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
 ↓
COBOL

Um 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 é:

SISTEMAS

Como 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
    =
  COBOL

Agora enxerga:

                    IBM z17
                       │
          ┌────────────┼────────────┐
          │            │            │
     TRANSAÇÕES       DADOS         IA
          │            │            │
        CICS          Db2        MODELOS
          │            │            │
        COBOL          MQ         AGENTES
          │            │            │
        RACF          APIs      GUARDRAILS
          │            │            │
          └────────────┼────────────┘
                       │
                 ENTERPRISE
                  COMPUTING

Grace 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 ABENDED

Ele 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