 |
| Bellacosa Mainframe e o caso do agente fantasma onde o ibm bob habita? |
☕ Um Café no Bellacosa Mainframe
CSI Las Vegas — O Caso do Agente Fantasma
Afinal... Onde Mora o IBM Bob?
"Toda investigação começa com uma pergunta aparentemente simples. No CSI Las Vegas aprendemos que, muitas vezes, a resposta está escondida exatamente onde ninguém pensa em procurar."
A pergunta chegou ao laboratório Bellacosa Mainframe numa tarde qualquer.
"O IBM Bob mora dentro do Mainframe?"
Silêncio.
O programador COBOL olha para o SDSF.
O operador observa a JES2.
O Sysprog abre a SYS1.PROCLIB.
O Administrador RACF consulta os Started Tasks.
Nada.
Nenhum PROC chamado BOB.
Nenhuma SYS.BOB.LIB.
Nenhum BOBLOAD.
Nenhum BOBPROC.
Nenhum STC.
Então...
Onde diabos mora esse agente?
Pegue sua lanterna.
Hoje investigaremos uma das maiores cenas do crime da Inteligência Artificial aplicada ao IBM Z.
Cena do Crime
CSI Las Vegas.
Sala escura.
Monitores iluminando o laboratório.
Na parede um enorme diagrama do z/OS.
Grissom aproxima-se.
— Catherine...
Onde está o Bob?
Nick responde:
— Não encontramos nenhum dataset.
Sara consulta o catálogo.
LISTCAT LEVEL(SYS.BOB)
Resultado:
ENTRY NOT FOUND
Brass pergunta:
— Então ele não existe?
Grissom sorri.
— Existe.
Só não mora onde vocês estão procurando.
A Primeira Hipótese
Todo programador COBOL imagina algo parecido com isto.
SYS1.PROCLIB
↓
SYS1.PARMLIB
↓
SYS1.LINKLIB
↓
USER.COBOL
↓
COPYLIB
↓
JCLLIB
↓
SYS.BOB.LIB
Seria maravilhoso.
Uma biblioteca contendo:
BOB
BOBINIT
BOBPROC
BOBLOAD
BOBCFG
Mas isso simplesmente não existe.
Pelo menos não na arquitetura atual.
O Grande Engano
Nós, profissionais de mainframe, fomos treinados durante quarenta anos para acreditar que:
"Se executa alguma coisa...
ela deve morar em algum dataset."
É natural pensar assim.
O CICS mora em bibliotecas.
O DB2 mora em bibliotecas.
O IMS mora em bibliotecas.
O MQ mora em bibliotecas.
O RACF possui módulos.
O DFSORT possui módulos.
Até o ISPF possui bibliotecas.
Então...
onde mora Bob?
A resposta muda completamente nossa forma de pensar.
Bob não mora no z/OS
Bob é um serviço.
Mais precisamente,
um AI Software Engineer Service.
Ele vive em infraestrutura moderna.
Pode estar:
IBM Cloud
Linux
Kubernetes
OpenShift
LinuxONE
Cloud privada
Data Center corporativo
Mas normalmente
não dentro do Address Space do z/OS.
Pense no Banco de Dados
Imagine um programa COBOL.
READ CLIENTE
Os dados não estão no COBOL.
Estão no VSAM.
Agora imagine:
EXEC SQL
SELECT *
FROM CLIENTES
O DB2 não mora no COBOL.
Ele responde ao COBOL.
Bob faz exatamente isso.
O Novo Modelo Mental
Em vez disso,
pense assim.
IBM Bob
AI Service
│
HTTPS / MCP / APIs
│
IBM Z Open Editor
│
Seu Programa
│
Mainframe
O Bob está do outro lado da conversa.
Quem faz a ponte?
Aqui entra um personagem novo.
O MCP.
Model Context Protocol.
Imagine o velho VTAM.
Ele ligava terminais.
O MCP liga Inteligências Artificiais.
Antes
3270
↓
VTAM
↓
CICS
Hoje
Bob
↓
MCP
↓
Git
↓
Filesystem
↓
Mainframe
↓
Cloud
↓
SQLite
↓
Appwrite
↓
GitHub
É o mesmo conceito.
Mudou apenas o protocolo.
O Investigador encontra uma pista
Sara abre o VS Code.
Existe um programa COBOL.
CLIENTE.CBL
Bob consegue explicar.
Grissom pergunta.
Como?
Será que Bob entrou no PDS?
Não.
Quem abriu o programa foi o editor.
O editor entregou o conteúdo ao Bob.
Quem entrega os COPYBOOKs?
Outra pergunta excelente.
Imagine.
COPY CLIENTE.
COPY CONTA.
COPY BMSMAP.
O editor conhece o projeto.
Ele resolve os COPYBOOKs.
Quando Bob precisa entender o código,
ele recebe esse contexto.
Não porque entrou no Mainframe.
Mas porque alguém lhe mostrou.
A mesma lógica vale para
JCL
PROC
SYSIN
SQL
REXX
CLIST
HLASM
Tudo depende do contexto entregue.
Então Bob nunca acessa o Mainframe?
Aí está o detalhe interessante.
Ele pode acessar.
Mas através de portas autorizadas.
Nunca "invadindo" o z/OS.
Por exemplo.
Caminho 1
VS Code
↓
Zowe Explorer
↓
z/OSMF
↓
REST
↓
Mainframe
Caminho 2
Bob
↓
MCP
↓
Git
↓
Pipeline
↓
DBB
↓
Mainframe
Caminho 3
Bob
↓
SSH
↓
USS
↓
Linux
Tudo depende da arquitetura.
LinuxONE entra na investigação
Agora a história fica muito mais interessante.
Imagine um datacenter IBM.
Rack
↓
IBM Z
+
LinuxONE
↓
Rede interna
↓
Storage
↓
OpenShift
O LinuxONE é um monstro.
Ele roda Linux.
Mas não é um Linux qualquer.
Ele compartilha muitas características do IBM Z.
Alta disponibilidade.
Segurança.
Virtualização.
Criptografia.
Escalabilidade absurda.
E se Bob morasse no LinuxONE?
Agora estamos falando.
Imagine.
LinuxONE
↓
OpenShift
↓
Container
↓
IBM Bob
Esse cenário faz muito sentido.
Porque:
baixa latência
segurança
sem sair do datacenter
integração corporativa
Bob e OpenShift
Imagine.
Pod
↓
IBM Bob
↓
MCP Server
↓
REST APIs
Tudo rodando localmente.
O Mainframe conversa pela rede interna.
Muito parecido com:
CICS
↓
MQ
↓
Application Server
O papel do Telum
Agora entra outro personagem.
Telum.
O processador do IBM Z.
Muita gente pensa:
"O Telum roda Bob."
Não exatamente.
O que Telum realmente faz?
Telum possui IA embarcada.
Mas ela foi criada para inferência transacional.
Exemplo.
Fraude bancária.
Cartão de crédito.
Detecção de risco.
Scoring.
Machine Learning.
Tudo isso acontece durante a própria transação.
Imagine.
Cliente compra.
↓
CICS.
↓
COBOL.
↓
DB2.
↓
Telum AI.
↓
Fraude detectada.
↓
Autoriza.
↓
Resposta.
Tudo em poucos milissegundos.
Então Bob usa Telum?
Hoje,
não diretamente.
Bob é um agente.
Telum é um acelerador de IA.
São papéis diferentes.
É como comparar.
Compilador COBOL
e
CPU
O compilador usa a CPU.
Mas não mora nela.
Poderia usar?
Perfeitamente.
Imagine uma arquitetura futura.
IBM Bob
↓
LLM
↓
Agente
↓
Inferência Telum
↓
Mainframe
Algumas decisões poderiam ser aceleradas pelo hardware.
O Grande Sonho do Sysprog
Agora imagine uma empresa.
Tudo dentro do próprio datacenter.
Firewall
│
────────────────────────────────────
IBM Z
────────────────────────────────────
z/OS
│
z/OSMF
│
REST APIs
────────────────────────────────────
LinuxONE
────────────────────────────────────
OpenShift Cluster
│
IBM Bob
MCP Server
Vector Database
Granite LLM
watsonx
────────────────────────────────────
Storage
────────────────────────────────────
Observe.
Bob continua não morando no z/OS.
Mas mora ao lado.
Dentro da mesma empresa.
Como um Sysprog enxergaria isso?
Algo parecido com:
Users
↓
VS Code
↓
Bob
↓
MCP
↓
z/OSMF
↓
RACF
↓
Datasets
↓
JES2
↓
CICS
↓
DB2
Cada camada conversa apenas com a seguinte.
O papel do RACF
Outra pergunta importante.
Bob pode ler qualquer dataset?
Não.
Quem manda continua sendo o RACF.
Imagine.
USER
↓
RACF
↓
Permissão
↓
Dataset
Bob nunca deveria ultrapassar essas permissões.
Ele atua com as credenciais autorizadas.
E o Sysadmin?
O Sysadmin enxerga diferente.
Ele pensa.
CPU.
Containers.
Pods.
TLS.
Certificados.
Load Balancer.
Storage.
OpenShift.
Logs.
Monitoramento.
Prometheus.
Grafana.
Para ele,
Bob é apenas mais um serviço corporativo.
O Sysprog pensa diferente
Ele pensa.
SYS1.PARMLIB
LPAR
SMF
RMF
APF
LINKLIST
JES
RACF
WLM
Por isso existe a confusão.
Bob pertence mais ao universo DevOps do que ao universo clássico do z/OS.
E se IBM decidisse integrar tudo?
Agora começa a ficção científica.
Imagine.
IBM.BOB.STC
Started Task.
BOBPROC
PROC.
SYS1.BOBLIB
Biblioteca.
BOBCFG
Parâmetros.
BOBMCP
Servidor.
Tudo hospedado em USS.
Não é impossível.
Na verdade,
USS já permite executar aplicações Linux-like dentro do z/OS.
Poderíamos imaginar:
USS
↓
Container
↓
Granite
↓
MCP
↓
Bob
Embora hoje esse não seja o modelo oficial.
Easter Egg nº 1
Lembra quando dizíamos:
"O Mainframe é um computador enorme."
Hoje essa definição está errada.
O IBM Z virou um grande orquestrador.
Ele conversa com:
Linux
Cloud
Kubernetes
APIs
IA
Containers
O computador deixou de ser uma ilha.
Easter Egg nº 2
Nos anos 1980 perguntávamos:
"Onde está o programa?"
Hoje perguntamos:
"Onde está o serviço?"
É uma mudança filosófica enorme.
Easter Egg nº 3
Daqui a alguns anos,
talvez um novo programador pergunte:
"Onde mora o Agente?"
E o Sysprog responderá:
"Não importa onde ele mora.
Importa apenas qual identidade RACF ele usa."
Veredito do CSI Las Vegas
Grissom fecha a pasta da investigação.
Na primeira página está escrito:
O Caso do Agente Fantasma
Conclusão:
O IBM Bob não desapareceu.
Nunca esteve escondido em uma SYS.BOB.LIB.
Nunca foi um módulo APF.
Nunca ocupou uma PDSE ao lado dos seus COPYBOOKs.
Ele representa uma nova geração de software: serviços inteligentes distribuídos, acessados por protocolos modernos e integrados ao ecossistema corporativo.
Para o programador COBOL, isso pode parecer estranho no início. Afinal, passamos décadas procurando tudo em bibliotecas, PROCs, LOADLIBs e datasets catalogados. Mas o mundo mudou.
Hoje, o código continua vivendo no z/OS. Os dados continuam protegidos pelo RACF. Os JOBs continuam passando pelo JES2. O CICS continua processando milhões de transações e o Db2 continua armazenando o coração do negócio.
A novidade é que surgiu um novo colega de equipe.
Ele não mora na estante das bibliotecas.
Ele mora na rede.
Pode estar em um cluster OpenShift sobre LinuxONE, em uma nuvem privada IBM, integrado ao watsonx e aos modelos Granite, conversando com o z/OS por z/OSMF, Zowe, MCP e APIs seguras.
É como um consultor extremamente experiente sentado do outro lado do vidro da sala de operações. Ele não toca diretamente nos datasets nem invade o sistema. Observa o contexto que você lhe fornece, analisa, sugere, documenta, revisa e acelera o trabalho.
Talvez essa seja a maior transformação desde o surgimento do CICS ou do Db2: o conhecimento deixou de estar preso a uma biblioteca física e passou a existir como um serviço inteligente, distribuído, colaborativo e conectado.
E quem sabe, daqui a alguns anos, ao abrir um console do z/OS, o Sysprog encontre finalmente aquele velho sonho realizado:
===> START BOB
IEF403I BOB - STARTED
IBM AI Software Engineer ready.
Waiting for next mission...
Nesse dia, provavelmente Grissom apenas sorriria e diria:
"O agente nunca esteve perdido. Nós é que estávamos procurando no lugar errado."
Sem comentários:
Enviar um comentário