✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe concorrencia e questoes de dados quem é relevante
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🗄️ ALAN TURING E O Db2 DOS AGENTES — QUANDO DUAS IAs ESTÃO CERTAS EM REALIDADES DIFERENTES
Db2, agentes de IA, COBOL, SQL, ACID, transações, isolamento, locks, MVCC, dirty read, non-repeatable read, phantom read, lost update, optimistic concurrency, timestamps, versionamento, commit, rollback, contexto, temporalidade, proveniência, RAG — e o dia em que Alan Turing descobriu que uma inteligência artificial pode estar absolutamente certa sobre uma realidade que deixou de existir três segundos atrás.
Quanto tempo uma observação continua válida para esta decisão?
Isso é tão importante quanto o timeout discutido no CICS dos Agentes.
⚛️ CAPÍTULO 6 — ACID ENTRA NA SALA
Quando falamos de bancos transacionais, encontramos a famosa sigla:
ACID
Ela representa quatro propriedades conceituais:
A — Atomicity
C — Consistency
I — Isolation
D — Durability
Vamos traduzi-las para nosso pequeno robô.
⚛️ CAPÍTULO 7 — ATOMICIDADE: TUDO OU NADA
Imagine transferência:
Conta A: -100
Conta B: +100
Não queremos:
Conta A: -100
Conta B: ERROR
A unidade lógica precisa ser tratada de forma coerente.
Ou todas as alterações da unidade de trabalho são confirmadas, ou as alterações não confirmadas precisam ser revertidas conforme a transação e os recursos envolvidos.
Conceitualmente:
BEGIN
DEBIT A
CREDIT B
COMMIT
Se ocorrer problema:
ROLLBACK
Nosso agente precisa entender que ações relacionadas não podem ser tratadas como frases independentes de uma conversa.
🧭 CAPÍTULO 8 — CONSISTÊNCIA: NÃO QUEBRE AS REGRAS DO UNIVERSO
Consistência significa que as operações devem respeitar as regras e invariantes estabelecidas pelo sistema.
Por exemplo:
STOCK >= 0
ou:
ORDER must reference valid CUSTOMER
ou regras implementadas em aplicações, constraints, triggers e outros mecanismos.
O agente pode dizer:
Parece razoável.
Db2 responde:
Não perguntei se parece razoável.
😂
O sistema possui regras.
Inteligência probabilística não substitui integridade transacional.
🧱 CAPÍTULO 9 — ISOLAMENTO: AQUI COMEÇA A DIVERSÃO
Agora chegamos ao ponto central.
Imagine duas transações:
TX-A
TX-B
executando simultaneamente.
Queremos controlar o quanto uma transação pode perceber dos efeitos da outra enquanto ambas estão em andamento.
Isso é parte do problema de:
ISOLATION.
Sem isolamento adequado, concorrência pode produzir resultados surpreendentes.
E agentes multiplicam esse problema porque podemos ter:
10 agentes
100 agentes
1.000 agentes
tomando decisões simultaneamente.
💾 CAPÍTULO 10 — DURABILIDADE: COMMIT NÃO É PROMESSA DE BAR
Quando uma transação é confirmada com sucesso, esperamos que seu resultado persistente sobreviva conforme as garantias oferecidas pelo sistema.
Ou seja:
COMMIT
não deveria significar:
Acho que gravei.
Significa que a alteração alcançou o ponto de confirmação definido pelo sistema transacional.
Para agentes corporativos isso importa muito.
O agente precisa diferenciar:
PLANNED
de:
EXECUTED
e:
COMMITTED.
São estados diferentes.
👻 CAPÍTULO 11 — DIRTY READ: O FANTASMA QUE AINDA PODE DESAPARECER
Imagine:
TX-A:
UPDATE ACCOUNT
SET BALANCE = 2000
Mas ainda não houve commit.
Outra transação consegue observar essa alteração sob condições que permitam leitura não confirmada.
Depois A faz:
ROLLBACK.
A informação que B viu desapareceu.
B tomou decisão sobre algo que nunca se tornou estado confirmado.
É a ideia de:
DIRTY READ.
Para um agente, isso pode ser especialmente perigoso.
Ele pode gerar uma explicação brilhante baseada em uma alteração que será desfeita segundos depois.
🔁 CAPÍTULO 12 — NON-REPEATABLE READ: EU JURO QUE ERA 10.000
Agente A lê:
BALANCE = 10000
Agente B altera:
BALANCE = 2000
COMMIT
A lê novamente:
BALANCE = 2000
A mesma consulta lógica produziu valores diferentes durante a execução da atividade.
O pequeno robô olha para Turing:
— Professor, o banco mentiu para mim!
— Não.
— Mas mudou!
— Exatamente.
O mundo mudou.
Essa é uma distinção filosófica e técnica importante:
Mudança não é inconsistência.
Às vezes o sistema está funcionando perfeitamente.
A realidade simplesmente evoluiu.
👥 CAPÍTULO 13 — PHANTOM READ: APARECEU OUTRO CLIENTE
Imagine:
SELECT COUNT(*)
FROM ORDERS
WHERE STATUS = 'PENDING';
Resultado:
10
Outra transação insere novo pedido pendente.
Você executa novamente.
11
Apareceu uma nova linha que satisfaz o predicado da consulta.
O conjunto observado mudou.
É o tipo de fenômeno associado ao famoso:
PHANTOM.
Para agentes que fazem análises sobre conjuntos de dados, isso importa bastante.
O agente pode perguntar:
Quantas solicitações aguardam aprovação?
A resposta pode envelhecer antes de terminar a frase.
💥 CAPÍTULO 14 — LOST UPDATE: DOIS AGENTES ESTAVAM CERTOS
Temos:
STOCK = 10
Agent-A lê:
10
Agent-B lê:
10.
A decide vender 3.
Calcula:
10 - 3 = 7
B decide vender 4.
Calcula:
10 - 4 = 6.
A grava:
7
B grava:
6.
A atualização de A pode ser efetivamente perdida dependendo da forma como a aplicação implementa a concorrência.
O valor correto deveria refletir ambas as operações:
3.
Dois agentes.
Duas contas matematicamente corretas.
Resultado corporativo errado.
Esse é um dos melhores exemplos de por que:
INTELIGÊNCIA NÃO RESOLVE CONCORRÊNCIA.
🔒 CAPÍTULO 15 — LOCKS: RESERVANDO UM PEDAÇO DA REALIDADE
Uma abordagem tradicional para coordenar concorrência utiliza locks.
Simplificando:
AGENT-A
LOCK ROW
Agora B precisa esperar dependendo da operação, isolamento e mecanismos envolvidos.
A altera.
UPDATE
COMMIT
Lock liberado.
B continua.
Isso pode proteger consistência.
Mas lembra do CICS dos Agentes?
Locks possuem custo.
Se o agente fizer:
LOCK CUSTOMER
CALL LLM
SEARCH WEB
READ 50 PDFs
ASK HUMAN
WAIT 20 MINUTES
o DBA provavelmente surgirá atrás dele segurando um manual do Db2 como arma contundente.
☠️ CAPÍTULO 16 — NÃO PENSE SEGURANDO O LOCK
Nossa regra retorna:
NÃO DEIXE O LLM PENSAR SEGURANDO LOCKS DESNECESSÁRIOS.
Uma arquitetura possível:
READ
↓
CAPTURE VERSION
↓
RELEASE TRANSACTIONAL RESOURCES
↓
THINK
↓
REVALIDATE
↓
SHORT UPDATE TRANSACTION
↓
COMMIT
Mas agora aparece uma pergunta:
Como sabemos se o dado mudou enquanto o agente pensava?
Excelente.
Entramos no próximo monstro.
🔢 CAPÍTULO 17 — VERSIONAMENTO
Imagine tabela conceitual:
CUSTOMER
────────────────────────
ID 12345
BALANCE 10000
VERSION 17
O agente lê:
VERSION = 17.
Vai pensar.
Enquanto isso outra transação altera o registro.
Agora:
VERSION = 18.
Nosso agente retorna e tenta atualizar.
Em vez de simplesmente:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000
WHERE CUSTOMER_ID = 12345;
podemos usar uma estratégia de concorrência otimista:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000,
VERSION = VERSION + 1
WHERE CUSTOMER_ID = 12345
AND VERSION = 17;
Se:
ROWS UPDATED = 1
ótimo.
Se:
ROWS UPDATED = 0
alguma coisa mudou.
Pare.
Releia.
Reavalie.
optimistic CAPÍTULO 18 — OPTIMISTIC CONCURRENCY
O nome vem da ideia:
Provavelmente ninguém vai alterar isto enquanto estou trabalhando.
Em vez de manter um lock durante todo o raciocínio, registramos a versão observada.
Depois verificamos se ainda é a mesma.
Fluxo:
READ VERSION 17
↓
THINK
↓
CHECK VERSION
↓
┌───────┐
│ │
17 18
│ │
▼ ▼
UPDATE STALE
RELOAD
Isso combina muito bem com agentes.
Por quê?
Porque raciocínio de IA pode levar tempo e envolver recursos externos.
Não queremos manter uma transação aberta durante todo esse período.
🥖 CAPÍTULO 19 — O PÃO DE QUEIJO DA CONCORRÊNCIA
Turing coloca um pão de queijo sobre a mesa.
Diz ao Agent-A:
— Quantos existem?
— Um.
Agent-A vira para consultar o LLM sobre a composição nutricional do pão de queijo.
Agent-B chega.
Come o pão de queijo.
Agent-A volta.
— Decidi com 98,7% de confiança que devo comer o pão de queijo.
Turing aponta para o prato vazio.
Agent-A:
ERROR:
RESOURCE NOT FOUND
😂
Essa é concorrência otimista explicada no café.
Você não precisa segurar o pão durante quinze minutos.
Mas antes de mordê-lo:
VERIFIQUE SE ELE AINDA EXISTE.
📸 CAPÍTULO 20 — SNAPSHOT: UMA FOTOGRAFIA DA REALIDADE
Às vezes queremos que uma operação trabalhe sobre uma visão consistente dos dados.
Conceitualmente, podemos imaginar:
SNAPSHOT @ 10:00:00
O agente analisa aquela visão.
Mesmo que o mundo continue mudando, sabemos:
Esta análise corresponde à realidade observada naquele ponto ou contexto transacional.
Isso é extremamente útil.
Mas exige honestidade.
O resultado deveria dizer algo como:
ANALYSIS-AS-OF:
2026-09-27T10:00:00
e não:
CURRENT STATE.
Se os dados eram de dez minutos atrás, não chame de “agora”.
🕰️ CAPÍTULO 21 — “AS OF” PODE SER TÃO IMPORTANTE QUANTO O VALOR
Quão velho este dado pode estar antes de deixar de ser aceitável?
📊 CAPÍTULO 33 — O PAINEL DO Db2 DOS AGENTES
Imagine nosso painel operacional:
RUN-ID......... A004821
AGENT.......... CREDIT-ANALYSIS
DATA SOURCES
────────────────────────────────────────
CUSTOMER VERSION 882 AGE 0.4s
BALANCE VERSION 991 AGE 0.1s
CRM VERSION 441 AGE 2m
CREDIT-RULES VERSION 42 AGE 3d
RAG-DOC VERSION 17 AGE 4h
DECISION AGE.................. 2.8s
STALE SOURCES................. 0
OPEN TRANSACTION.............. NO
LOCKS HELD.................... 0
REVALIDATION REQUIRED......... YES
Agora estamos falando.
O operador consegue enxergar não apenas:
O QUE O AGENTE ESTÁ FAZENDO?
mas:
QUAL REALIDADE ELE ESTÁ VENDO?
🧰 CAPÍTULO 34 — CHECKLIST PARA AGENTES QUE TOMAM DECISÕES SOBRE DADOS
Antes de colocar um agente corporativo em produção, pergunte:
1. Qual é a fonte oficial?
Db2?
API?
RAG?
cache?
2. O dado possui timestamp?
Saiba quando foi observado.
3. Existe versão?
Use versionamento quando necessário.
4. Qual é o freshness budget?
Defina tolerância.
5. O agente mantém transação aberta enquanto pensa?
Evite.
6. Existem locks?
Minimize duração.
7. Pode haver concorrência?
Presuma que sim.
8. Existe optimistic concurrency?
Considere version checking.
9. A ação precisa ser revalidada?
Para ações críticas, quase certamente.
10. O RAG conhece validade documental?
Não use apenas similaridade.
11. Existe proveniência?
Registre origem.
12. Podemos reconstruir a decisão?
Associe dados, versões e RUN-ID.
13. O humano pode demorar para aprovar?
Revalide depois da aprovação.
14. O cache é permitido?
Defina TTL de acordo com semântica.
15. O resultado informa “as of”?
Quando relevante, deveria.
🥚 EASTER EGG — O AGENTE QUE ESTAVA 100% CERTO
02:14 da madrugada.
Telefone toca.
— Produção.
O operador atende.
— Temos problema.
— Qual?
— A IA aprovou uma operação que deveria ter recusado.
Abrem o trace.
RUN-ID A008817
Modelo respondeu corretamente.
Prompt correto.
Regra correta.
RACF correto.
Nenhuma hallucination.
Turing chega carregando café.
— Mostre os dados.
CUSTOMER_STATUS = ACTIVE
— Quando foram lidos?
Silêncio.
Procuram.
CACHE READ:
01:43:02
Turing olha o relógio.
02:14.
Consulta Db2:
CUSTOMER_STATUS = BLOCKED
UPDATE TIME = 01:44:11
O agente estava usando uma informação de 31 minutos atrás.
O jovem programador diz:
— Então a IA errou.
Turing responde:
— Não.
Aponta para o cache.
— Nós entregamos o passado e perguntamos sobre o presente.
Silêncio.
No fundo do CPD, o DBA sorri.
Finalmente não era culpa do banco.
🧬 CAPÍTULO 35 — NOSSO MAINFRAME DOS AGENTES ESTÁ FICANDO INTERESSANTE
Agora nossa arquitetura conceitual possui:
RACF
↓
QUEM PODE?
PF3
↓
POSSO PARAR?
SDSF
↓
O QUE ESTÁ FAZENDO?
MAXCC
↓
FUNCIONOU?
WLM
↓
QUEM RECEBE RECURSOS?
JES2
↓
QUEM COMEÇA E QUANDO?
CICS
↓
QUANTO TEMPO O HUMANO PODE ESPERAR?
E agora:
Db2
↓
QUAL REALIDADE O AGENTE ESTÁ VENDO?
Isso muda tudo.
🏰 CAPÍTULO 36 — O SISTEMA OPERACIONAL CONCEITUAL DOS AGENTES
SELECT
VALUE,
VERSION,
TIMESTAMP
FROM
REALITY
WHERE
NOW = NOW;
O programador observa.
— Professor...
— Sim?
— Essa tabela não existe.
Turing sorri.
— Ainda.
No fundo do CPD, o DBA grita:
— E NEM INVENTA DE CRIAR EM PRODUÇÃO!
O pequeno robô fecha o terminal.
COMMIT;
E todos foram tomar café.
Porque no mainframe, no Db2 e no mundo dos agentes, existe uma verdade que sobrevive a qualquer geração tecnológica:
Uma decisão só é tão confiável quanto os dados, o contexto e o instante da realidade sobre os quais ela foi construída.
READY
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🤖 Alan Turing entra no CPD
O mapa dos agentes de IA explicado por um mainframer
Esta série acompanha a evolução de uma ideia:
compreender os problemas modernos dos
agentes de inteligência artificial
usando conceitos conhecidos por quem trabalha com
mainframe, IBM Z e sistemas corporativos.
A viagem começa pelas pessoas e pela experiência de uso,
passa por observabilidade, priorização e execução,
chega às transações, estado e mensageria
e termina na organização hierárquica do contexto.
01
FEV / 2023
🧠 O currículo invisível da inteligência artificial
Antes de construir agentes inteligentes precisamos
preparar as pessoas que trabalharão com eles.
Técnica, pensamento crítico, conhecimento de negócio,
segurança, ética e responsabilidade formam o currículo
que nem sempre aparece no certificado.
Quando uma IA deixa de apenas responder e começa
a executar ações, sua interface precisa mostrar
objetivos, progresso, permissões e resultados.
PF3, MAXCC e RACF tornam-se excelentes analogias
para controle, retorno e privilégio mínimo.
Autonomia sem observabilidade cria uma caixa-preta.
Inspirado no SDSF do z/OS, este capítulo pergunta
como acompanhar agentes, tarefas, estados, filas,
falhas, logs e resultados em tempo real.
CPU, GPU, tokens, APIs e bancos de dados são recursos
finitos. O Workload Manager inspira uma discussão
sobre prioridades, objetivos de serviço, importância
do trabalho e distribuição dinâmica de recursos
entre agentes.
Quem recebe uma tarefa? Onde ela espera?
Quem decide quando poderá executar?
A lógica de entrada, filas, despacho, execução
e saída do JES2 oferece um paralelo interessante
para a orquestração do trabalho dos agentes.
Uma coisa é uma IA produzir texto.
Outra é permitir que ela execute operações reais
de negócio. CICS introduz a conversa sobre
processamento transacional, concorrência,
segurança e integridade.
Agentes precisam manter estado, checkpoints,
decisões e resultados. O Db2 fornece o ponto
de partida para discutir unidade de trabalho,
consistência, COMMIT, ROLLBACK e recuperação.
Sistemas de agentes não precisam conversar
sincronamente o tempo inteiro. IBM MQ conduz
a discussão para filas, mensagens, desacoplamento,
resiliência, retries, correlação e processamento
assíncrono.
Nem todo conhecimento precisa ser imaginado
como uma tabela. IMS leva a série para estruturas
hierárquicas, relações parent/child e navegação
contextual — conceitos úteis para pensar
organização e recuperação de contexto.
O artigo-âncora reúne toda a evolução da ideia:
pessoas, UX, observabilidade, prioridade,
orquestração, transações, estado, mensageria
e contexto transformam artigos independentes
em uma arquitetura conceitual para agentes de IA.
Bellacosa Mainframe e as ligações dos agentes de ia
☕ UM CAFÉ NO BELLACOSA MAINFRAME
⚡ ALAN TURING E O CICS DOS AGENTES — QUANTO TEMPO UM HUMANO ACEITA OLHAR PARA PROCESSING...?
CICS, agentes de IA, transações online, latência, contexto, pseudo-conversationalidade, concorrência, locks, timeout, Db2, commit, rollback, syncpoint, idempotência, circuit breakers, human-in-the-loop — e o dia em que Alan Turing descobriu que uma inteligência artificial pode pensar durante cinco minutos, desde que não exista um cliente olhando para a ampulheta.
🎬 PRÓLOGO — O HUMANO ESTAVA ESPERANDO
Alan Turing entrou no CPD.
O relógio marcava:
10:14:03
Na tela de um terminal havia uma mensagem:
PROCESSING...
Turing tomou um gole de café.
10:14:08
Nada.
10:14:15
Nada.
10:14:31
Ainda:
PROCESSING...
O jovem programador COBOL apareceu.
— Bom dia, professor.
Turing apontou para a tela.
— O que está acontecendo?
— O agente está pensando.
— Há quanto tempo?
— Trinta segundos.
— E o usuário?
— Esperando.
Turing levantou uma sobrancelha.
— Existe uma diferença enorme entre um agente trabalhar durante trinta segundos e obrigar um ser humano a esperar trinta segundos.
O pequeno robô apareceu.
— Mas eu estou realizando uma análise muito sofisticada!
Turing respondeu:
— Parabéns.
Apontou para o terminal.
— O cliente acabou de fechar a janela.
Silêncio.
Do fundo do CPD, alguém murmurou:
Bem-vindo ao online.
🏛️ CAPÍTULO 1 — JES2 E CICS VIVEM EM UNIVERSOS DIFERENTES
No artigo anterior construímos o:
JES2 DOS AGENTES
A ideia era fantástica para processamento assíncrono.
O usuário submete:
AGENT-CONTRACT-ANALYSIS
recebe:
RUN-ID A004821
e pode ir tomar café.
O agente pode executar:
agora
daqui a cinco minutos
durante a madrugada
Não importa tanto.
Mas agora imagine:
CLIENTE
↓
TELA
↓
"CONSULTAR SALDO"
Ele clicou.
Está esperando.
Temos outro tipo de trabalho.
INTERATIVO
E sistemas interativos possuem uma característica brutal:
EXISTE UM HUMANO MEDINDO O TEMPO.
Não com cronômetro.
Com impaciência.
⚡ CAPÍTULO 2 — CICS NASCEU PARA O MUNDO ONLINE
CICS significa:
Customer Information Control System
Para o programador COBOL iniciante, uma forma útil de pensar nele é:
Um ambiente transacional capaz de executar aplicações online com grande volume de usuários e transações.
Parece muito com aquilo que agentes terão de fazer quando forem colocados dentro de aplicações interativas.
🤖 CAPÍTULO 3 — O AGENTE SAIU DA FILA E ENTROU NA TELA
Imagine:
Usuário:
"Analise este cliente e diga se existe alguma inconsistência."
Nosso agente precisa:
receber contexto
consultar dados
talvez chamar ferramentas
raciocinar
produzir resultado
Se isso estiver num processamento batch:
45 segundos
pode ser perfeitamente aceitável.
Se estiver numa tela de atendimento:
45 segundos
pode parecer uma eternidade.
Essa é uma mudança fundamental.
Não basta perguntar:
O agente consegue executar?
Precisamos perguntar:
O agente consegue executar dentro do orçamento de tempo da experiência humana?
⏱️ CAPÍTULO 4 — LATÊNCIA VIROU EXPERIÊNCIA
Suponha:
AGENT RESPONSE TIME = 800 ms
Excelente.
Agora:
3 segundos
Talvez aceitável.
Agora:
12 segundos
O usuário começa a desconfiar.
Agora:
45 segundos
Talvez já esteja clicando novamente.
Agora:
2 minutos
Ele abriu outra aba.
Agora:
5 minutos
Ele foi fazer café.
O problema não é apenas tecnológico.
É UX.
Portanto precisamos pensar em:
TIME BUDGET
Imagine que nossa experiência tenha:
TOTAL BUDGET = 3 s
Esse orçamento precisa ser dividido.
API............. 200 ms
CICS............ 300 ms
Db2............. 400 ms
Agent........... 1500 ms
Formatting...... 100 ms
Network......... 200 ms
Safety margin... 300 ms
Se o agente gastar sozinho:
8 segundos
não adianta o restante ser rápido.
💰 CAPÍTULO 5 — TEMPO TAMBÉM É ORÇAMENTO
No WLM dos agentes falamos de:
tokens
CPU
API calls
money
Agora adicionamos:
PACIÊNCIA HUMANA
Ela também é finita.
Podemos imaginar:
LATENCY BUDGET
como um recurso.
Cada componente gasta um pedaço.
Usuário
↓ 100 ms
Gateway
↓ 150 ms
Agent
↓ 900 ms
Db2
↓ 200 ms
CICS
↓ 300 ms
Response
Total:
1.65 s
Ótimo.
Mas se o agente decidir:
Vou consultar mais oito ferramentas...
nosso orçamento desaparece.
Autonomia precisa respeitar tempo.
🚦 CAPÍTULO 6 — O AGENTE PRECISA SABER QUANDO PARAR DE PENSAR
Aqui aparece uma consequência interessante.
Um agente pode teoricamente melhorar sua resposta fazendo:
mais buscas
mais chamadas
mais validações
mais raciocínio
Mas numa interação online existe limite.
Podemos estabelecer:
MAX_TOOL_CALLS = 3
MAX_AGENT_TIME = 1500 ms
Se não conseguir concluir:
FALLBACK
Talvez:
"Preciso de uma análise mais profunda.
Posso continuar em segundo plano?"
Agora fazemos uma transformação elegante:
ONLINE
↓
ASYNC
Ou seja:
CICS encontra JES2.
O usuário recebe resposta rápida.
O trabalho longo continua depois.
🔄 CAPÍTULO 7 — FAST PATH E SLOW PATH
Essa arquitetura é extremamente útil para agentes.
FAST PATH
Tente resolver imediatamente.
USER
↓
AGENT
↓
TOOLS
↓
RESPONSE
Limite:
2 segundos
Se a tarefa exigir mais:
SLOW PATH
USER
↓
SUBMIT
↓
RUN-ID
↓
QUEUE
↓
BACKGROUND AGENT
A interface responde:
Análise aprofundada iniciada.
RUN-ID: A004821
Depois o usuário recebe resultado.
Assim não transformamos uma transação online em um batch disfarçado.
Essa frase merece moldura:
Não transforme processamento batch em transação online apenas porque agora existe uma interface bonita na frente.
🧠 CAPÍTULO 8 — CICS APRENDEU A NÃO FICAR CONVERSANDO PARA SEMPRE
Aqui entra um conceito delicioso para nossa analogia:
PSEUDO-CONVERSATIONALIDADE.
Imagine um programa conversacional ingênuo.
O usuário recebe uma tela.
Enquanto pensa durante dois minutos, o programa continua ocupando recursos.
PROGRAMA
↓
ENVIA TELA
↓
ESPERA USUÁRIO
↓
ESPERA...
↓
ESPERA...
Isso não escala bem.
A filosofia pseudo-conversational do CICS é diferente.
Isso já parece uma arquitetura operacional completa.
🧠 CAPÍTULO 36 — O PROGRAMADOR COBOL POSSUI UMA VANTAGEM ESTRANHA
Quando alguém fala:
AI agents
parece que tudo é novo.
Mas um programador COBOL que conhece sistemas transacionais já possui intuições valiosas.
Ele sabe que:
recurso é finito
Sabe que:
lock custa
Sabe que:
transação longa é perigosa
Sabe que:
commit importa
Sabe que:
rollback salva vidas
Sabe que:
usuário não deveria manter programa preso enquanto pensa
Sabe que:
estado precisa sobreviver entre interações
Sabe que:
concorrência cria problemas que não aparecem no teste unitário
Sabe que:
MAXCC=0000
não necessariamente significa que o cliente ficou feliz.
Tudo isso será extraordinariamente útil no mundo dos agentes.
☕ EPÍLOGO — PROCESSING...
O relógio marca:
16:47:01
Um usuário pergunta:
Qual é a situação do meu pedido?
O agente recebe.
16:47:01.100
Consulta contexto.
16:47:01.280
Busca pedido.
16:47:01.510
Consulta Db2.
16:47:01.790
Chama modelo.
16:47:02.620
O agente percebe que precisa de uma análise longa.
Olha para seu orçamento:
LATENCY BUDGET
3.0 s
ELAPSED
1.62 s
Antigamente ele continuaria.
Mais ferramentas.
Mais buscas.
Mais raciocínio.
Mais espera.
Mas agora aprendeu.
Responde:
Encontrei seu pedido. A situação básica está normal. Uma análise detalhada exige mais tempo; vou processá-la em segundo plano e avisá-lo quando terminar.
Tempo total:
2.1 s
Depois:
SUBMIT AGENT-DEEP-ANALYSIS
RUN-ID A009821
O trabalho entra no nosso:
JES2 DOS AGENTES.
O WLM classifica.
O RACF limita.
O SDSF observa.
O checkpoint preserva.
E o usuário continua sua vida.
Turing toma um gole de café.
— Agora você entendeu.
O robô pergunta:
— Entendi o quê?
— Que inteligência não significa responder tudo imediatamente.
— Então o que significa?
— Saber também quando uma tarefa deixou de ser uma transação e virou um job.
O jovem COBOL olha para o quadro.
Ali estava escrita toda a história:
CICS
↓
RESPONDA AGORA
JES2
↓
TRABALHE DEPOIS
E entre os dois:
DECIDA.
Talvez essa seja uma das arquiteturas mais importantes para agentes corporativos.
Porque haverá tarefas que precisam responder em:
300 ms
Outras em:
3 segundos
Outras em:
3 minutos
E algumas podem levar:
3 horas.
O erro será tentar tratar todas da mesma maneira.
Um agente realmente operacional precisa entender:
tempo,
contexto,
concorrência,
consistência,
risco,
custo,
e expectativa humana.
O futuro da IA empresarial talvez não seja simplesmente:
agentes cada vez mais inteligentes.
Talvez seja:
agentes inteligentes o bastante para saber quanto tempo podem ocupar uma transação.
Porque até num sistema online existe uma transação que jamais deveria sofrer timeout.
EXEC CICS
START
TRANSID('CAFE')
END-EXEC.
READY
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🤖 Alan Turing entra no CPD
O mapa dos agentes de IA explicado por um mainframer
Esta série acompanha a evolução de uma ideia:
compreender os problemas modernos dos
agentes de inteligência artificial
usando conceitos conhecidos por quem trabalha com
mainframe, IBM Z e sistemas corporativos.
A viagem começa pelas pessoas e pela experiência de uso,
passa por observabilidade, priorização e execução,
chega às transações, estado e mensageria
e termina na organização hierárquica do contexto.
01
FEV / 2023
🧠 O currículo invisível da inteligência artificial
Antes de construir agentes inteligentes precisamos
preparar as pessoas que trabalharão com eles.
Técnica, pensamento crítico, conhecimento de negócio,
segurança, ética e responsabilidade formam o currículo
que nem sempre aparece no certificado.
Quando uma IA deixa de apenas responder e começa
a executar ações, sua interface precisa mostrar
objetivos, progresso, permissões e resultados.
PF3, MAXCC e RACF tornam-se excelentes analogias
para controle, retorno e privilégio mínimo.
Autonomia sem observabilidade cria uma caixa-preta.
Inspirado no SDSF do z/OS, este capítulo pergunta
como acompanhar agentes, tarefas, estados, filas,
falhas, logs e resultados em tempo real.
CPU, GPU, tokens, APIs e bancos de dados são recursos
finitos. O Workload Manager inspira uma discussão
sobre prioridades, objetivos de serviço, importância
do trabalho e distribuição dinâmica de recursos
entre agentes.
Quem recebe uma tarefa? Onde ela espera?
Quem decide quando poderá executar?
A lógica de entrada, filas, despacho, execução
e saída do JES2 oferece um paralelo interessante
para a orquestração do trabalho dos agentes.
Uma coisa é uma IA produzir texto.
Outra é permitir que ela execute operações reais
de negócio. CICS introduz a conversa sobre
processamento transacional, concorrência,
segurança e integridade.
Agentes precisam manter estado, checkpoints,
decisões e resultados. O Db2 fornece o ponto
de partida para discutir unidade de trabalho,
consistência, COMMIT, ROLLBACK e recuperação.
Sistemas de agentes não precisam conversar
sincronamente o tempo inteiro. IBM MQ conduz
a discussão para filas, mensagens, desacoplamento,
resiliência, retries, correlação e processamento
assíncrono.
Nem todo conhecimento precisa ser imaginado
como uma tabela. IMS leva a série para estruturas
hierárquicas, relações parent/child e navegação
contextual — conceitos úteis para pensar
organização e recuperação de contexto.
O artigo-âncora reúne toda a evolução da ideia:
pessoas, UX, observabilidade, prioridade,
orquestração, transações, estado, mensageria
e contexto transformam artigos independentes
em uma arquitetura conceitual para agentes de IA.
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
