✨ 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
💣🔥 TPS NÃO É THROUGHPUT — É O SEU “COMMIT FINANCEIRO” PASSANDO NO CICS 🔥💣
Se você entrou numa discussão de arquitetura falando de fila, banco NoSQL e multi-região antes de entender o que é dinheiro sendo movimentado, já começou igual job com JCL errado: vai rodar… mas vai dar abend.
⚙️ TPS vs Throughput — visão Bellacosa Mainframe
No mundo raiz (sim, aquele do CICS + DB2 + commit de verdade):
TPS (Transactions Per Second) 👉 É o COMMIT EXECUTADO 👉 É o dinheiro que mudou de dono 👉 É o ponto sem volta
Throughput 👉 É o volume de processamento 👉 Inclui request, fila, validação, retry 👉 Muito barulho… nem sempre dinheiro
💥 Tradução brutal:
Throughput é fila cheia. TPS é saldo alterado com sucesso.
Se você tem:
20k req/s entrando
3k virando transação
👉 Você NÃO tem um sistema de 20k. 👉 Você tem um sistema de 3k TPS financeiro.
🌍 Multi-região — quando o sistema vira “sysplex global sem JES”
Quando você sai de uma região…
Você não escalou. Você entrou em guerra.
Agora você tem:
🌐 Latência: 100–200ms (no mínimo)
🔄 Consistência distribuída
⚠️ Conflito de escrita
🔁 Failover real (não o de slide de PowerPoint)
💣 E aqui vem o ponto que derruba sistema:
TPS deixa de ser capacidade e vira problema de coordenação global.
💥 Onde TODO mundo quebra (sem exceção)
1. Consistência forte global
👉 “Vamos manter saldo sincronizado em todas regiões”
Resultado:
Lock distribuído
Round-trip global
TPS despenca mais rápido que job mal indexado
💣 Isso aqui mata performance.
2. Dependência síncrona entre regiões
👉 API Brasil → chama EUA → espera resposta
Resultado:
Cada request carrega latência global
Você virou refém da pior região
💣 É o equivalente moderno de:
“esperar fita montar pra continuar o batch”
3. Hotspot de dados
👉 Conta sendo acessada globalmente
Resultado:
Contenção
Locking
Throughput artificialmente alto… TPS real baixo
💣 Clássico erro de modelagem.
☠️ O ERRO RAIZ (o mais perigoso)
“Vamos usar Kafka” “Vamos usar Cassandra” “Vamos fazer active-active”
🚫 Errado.
Isso é igual dizer:
“Vamos usar DFSORT” antes de saber o layout do arquivo.
🧠 Modelo mental Bellacosa (nível arquiteto de guerra)
Antes de falar de tecnologia, responda:
1. Tipo de operação
💰 Financeira crítica?
🔁 Pode reprocessar?
♻️ É idempotente?
2. Consistência
🔒 Forte → saldo, ledger
📊 Eventual → extrato, notificação
💣 Regra de ouro:
Quanto mais consistência, menor o TPS possível.
3. Latência aceitável
⚡ 100ms?
🕒 500ms?
🔁 segundos com retry?
👉 Isso define TUDO.
4. Distribuição geográfica
Usuário local?
Cross-border?
👉 Se for global, esqueça sonho de consistência forte em tudo.
5. Perfil de carga
📈 Constante?
🚀 Pico violento?
👉 Sistema que aguenta pico não nasce por acidente.
Kojak Entra no CPD — O Dia em que um SQLCODE -911 Virou Suspeito e o Db2 Foi Chamado para Depor
Ou: como COBOL, SQL, DBRM, BIND, PACKAGE, access path, COMMIT, ROLLBACK, locking, CICS e um programador iniciante descobriram que, no mainframe, até um SELECT tem antecedentes
Nova York, 1973.
Um policial careca, impecavelmente vestido, andando pelas ruas com um pirulito na boca começa a resolver crimes enquanto solta ironias e uma pergunta que se tornaria inseparável do personagem:
“Who loves ya, baby?”
Era o tenente Theo Kojak.
A série Kojak, criada por Abby Mann e protagonizada por Telly Savalas, estreou na CBS em 24 de outubro de 1973 e permaneceu originalmente no ar até 1978. (Paramount Press Express)
Curiosamente, Kojak surgiu antes da série: Telly Savalas interpretou o personagem no telefilme The Marcus-Nelson Murders, de 1973, que funcionou como origem do programa. (Los Angeles Times)
E existe algo profundamente mainframe em Kojak.
Ele não olha apenas para o cadáver.
Olha para quem entrou, quem saiu, quem tinha autorização, quem estava segurando o recurso, quem alterou o registro e por que aquela história aparentemente perfeita não combina com as evidências.
Troque a delegacia por um CPD.
Troque o assassinato por uma transação travada.
Troque as testemunhas por logs.
E dê ao tenente um terminal 3270.
Temos nosso novo investigador Db2.
Prólogo — 03:17, alguma coisa morreu em produção
O telefone toca.
O programador COBOL iniciante atende.
— Produção está parada.
Cinco palavras capazes de transformar café em combustível nuclear.
Ele abre o fonte.
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE NUMERO = :WS-CONTA
END-EXEC.
Olha novamente.
Nada parece errado.
Compilou.
Ontem funcionava.
O programador conclui:
— Deve ser o banco.
A porta do CPD abre.
Um homem careca entra lentamente, coloca um pirulito na boca e observa o terminal.
— O banco, baby?
Silêncio.
— Vamos começar novamente. Quem executou o SQL?
E aí descobrimos nosso primeiro problema.
1. COBOL não executa SQL sozinho
Quando vemos:
EXEC SQL
SELECT ...
END-EXEC
é fácil imaginar que SELECT seja uma instrução COBOL.
Não é.
COBOL e SQL são linguagens diferentes trabalhando juntas.
Podemos imaginar três responsabilidades:
COBOL
│
├── lógica da aplicação
├── cálculos
├── decisões
└── fluxo
│
▼
SQL
│
└── declara quais dados queremos
│
▼
Db2
│
└── determina como obtê-los
O COBOL pode dizer:
“Preciso consultar o saldo desta conta.”
O SQL expressa:
SELECT SALDO
FROM CONTA
WHERE NUMERO = :WS-CONTA
E o Db2 precisa resolver como encontrar aquele registro eficientemente.
Kojak tira o pirulito da boca.
— Então temos três testemunhas. COBOL diz uma coisa, SQL pede outra e Db2 faz o trabalho pesado.
Aqui aparece uma palavra que todo programador COBOL/Db2 precisa conhecer:
BIND.
Simplificando bastante, durante o bind o Db2 trabalha com as informações SQL preparadas anteriormente e produz aquilo que será necessário para executar o SQL estático.
Temos:
DBRM
│
▼
BIND PACKAGE
│
▼
PACKAGE
Agora nossa investigação começa a ficar interessante.
Porque significa que existem dois universos relacionados:
STATIC SQL
conhecido durante
preparação/deployment
│
▼
processamento
│
▼
DBRM
│
▼
BIND
│
▼
PACKAGE
Mas existe SQL dinâmico.
Podemos ter situações nas quais a instrução é preparada durante a execução usando mecanismos como PREPARE e EXECUTE.
Isso oferece flexibilidade, mas muda aspectos da preparação e execução.
Novamente:
não existe “um é sempre melhor”.
Existe:
qual mecanismo atende melhor ao problema?
19. O crime perfeito: SELECT *
Kojak encontra:
SELECT *
FROM CLIENTE
Olha para o programador.
Olha novamente para a tela.
— Você precisa de todas essas colunas?
— Não.
— Então por que pediu?
Silêncio.
Essa pergunta vale ouro.
Evite transportar dados desnecessários.
Se precisa de:
NOME
SALDO
não peça quarenta colunas simplesmente porque:
SELECT *
é mais rápido de digitar.
Cinco segundos economizados na programação podem gerar trabalho desnecessário repetido milhões de vezes em produção.
20. Outro suspeito: SELECT dentro de LOOP
Agora Kojak encontra:
PERFORM 100000 TIMES
SELECT ...
END-PERFORM
Acende a luz da sala de interrogatório.
Dependendo do problema, isso pode representar enorme quantidade de chamadas e processamento que talvez pudesse ser resolvida por uma estratégia SQL muito melhor.
O erro conceitual é tratar banco relacional como arquivo sequencial:
LEIA
LEIA
LEIA
LEIA
LEIA
SQL trabalha naturalmente com conjuntos.
Essa mudança de pensamento é enorme para quem vem de COBOL procedural.
21. Não coloque toda a investigação num único SQL monstruoso
Mas existe o extremo oposto.
Alguém aprende que SQL trabalha com conjuntos e produz:
SELECT
JOIN
JOIN
JOIN
CASE
CASE
SUBQUERY
UNION
CTE
FUNCTION
JOIN
...
O SQL parece o mapa genealógico de Game of Thrones.
SQL complexo não é automaticamente ruim.
Às vezes uma operação sofisticada no banco é exatamente a solução correta.
Mas complexidade precisa possuir justificativa.
Legibilidade importa.
Manutenção importa.
Performance importa.
Testabilidade importa.
22. EXPLAIN — reconstruindo a cena do crime
Se queremos investigar desempenho, precisamos saber mais sobre o access path.
É aí que conceitos relacionados ao EXPLAIN tornam-se fundamentais.
O objetivo é investigar como o Db2 pretende ou decidiu acessar os dados, conforme o cenário analisado.
Agora entendemos por que profissionais podem trabalhar décadas com mainframe e continuar aprendendo.
24. Kojak finalmente resolve o caso
Voltamos às 03:17.
O programa estava correto.
O SQL também.
O Db2 estava disponível.
O problema estava relacionado à concorrência.
Outra unidade de trabalho estava mantendo recursos necessários.
A transação esperou.
O limite foi atingido.
O SQL recebeu erro.
O programa não possuía tratamento suficientemente inteligente.
A mensagem apresentada ao operador foi:
ERRO NO BANCO
Ou seja:
o único inocente da investigação talvez fosse justamente “o banco”.
Kojak olha para o programador.
— Então você acusou Db2 sem verificar SQLCODE, reason code, locks, unidade de trabalho e logs?
— Sim.
Kojak coloca o pirulito na boca.
— Who loves ya, baby?
🍭 Easter egg — por que Kojak usa pirulito?
Esse detalhe é perfeito para nossa história.
O pirulito não nasceu simplesmente como um adereço aleatório inventado pelo departamento de marketing. Telly Savalas contou posteriormente que a ideia surgiu numa situação em que uma personagem queria que Kojak parasse de fumar e lhe entregava um pirulito; o detalhe pegou e tornou-se uma das marcas visuais do personagem. (Los Angeles Times)
Na própria série, o pirulito apareceu durante a primeira temporada e acabou associado à tentativa de reduzir o cigarro. (Wikipedia)
o sistema corporativo não é um programa. É um ecossistema de componentes cooperando.
O SELECT SALDO que parece possuir cinco linhas pode envolver host variables, processamento SQL, DBRM, package, optimizer, estatísticas, índices, buffer management, locking, logging, segurança, recuperação e infraestrutura antes de devolver alguns bytes para WS-SALDO.
Essa é uma das coisas mais bonitas do mainframe.
Na superfície:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
...
END-EXEC.
Debaixo:
50 ANOS
DE
ENGENHARIA
│
▼
WS-SALDO
O programador olha para a variável.
Depois olha para Kojak.
Finalmente compreendeu.
Não basta perguntar:
“O programa compilou?”
É preciso investigar:
Qual SQL executou? Qual SQLCODE retornou? Qual package? Qual access path? As estatísticas estão adequadas? Existe índice apropriado? Houve locking? Timeout? Deadlock? Onde começa e termina a unidade de trabalho? Houve COMMIT? O que os logs mostram?
Porque produção não aceita álibi.
Produção aceita evidência.
Kojak se levanta, pega o sobretudo e caminha para a porta do CPD.
O programador pergunta:
— Tenente, e se amanhã aparecer outro -911?
Kojak sorri.
— Agora você sabe interrogar os suspeitos, baby.
E sai.
Na mesa fica apenas um pirulito, um dump, três relatórios de performance e um post-it:
****************************************
* NÃO CULPE O DB2 ANTES DO EXPLAIN. *
****************************************
📨 ALAN TURING E O MQ DOS AGENTES — A MENSAGEM CHEGOU DUAS VEZES
IBM MQ, agentes de IA, mensageria, filas, producers, consumers, delivery semantics, acknowledgements, commit, rollback, duplicate delivery, idempotência, ordering, correlation ID, message ID, poison messages, backout queues, dead-letter queues, retry, persistence, request/reply, COBOL, CICS, Db2 — e o dia em que Alan Turing descobriu que uma mensagem pode chegar duas vezes sem que ninguém tenha cometido o mesmo erro duas vezes.
A qual conversa, fluxo ou solicitação ela pertence?
RUN-ID
Qual execução do agente está processando?
Isso será ouro para observabilidade.
🔗 CAPÍTULO 5 — CORRELATION ID: ENCONTRE A CONVERSA NO MEIO DO CAOS
Imagine:
REQUEST
MESSAGE-ID M100
CORREL-ID C500
O serviço responde:
RESPONSE
MESSAGE-ID M101
CORREL-ID C500
São mensagens diferentes.
Mas pertencem à mesma conversa.
Em sistemas distribuídos isso é extremamente útil.
Podemos seguir:
USER REQUEST
↓
CICS
↓
MQ
↓
AGENT
↓
Db2
↓
ANOTHER QUEUE
Tudo associado a:
CORRELATION-ID C500.
Quando alguém pergunta:
O que aconteceu com a solicitação do cliente?
não precisamos procurar agulha no palheiro.
📦 CAPÍTULO 6 — A MENSAGEM PODE SOBREVIVER AO CONSUMIDOR
Aqui está uma das grandes vantagens de mensageria confiável.
O producer envia.
PUT MESSAGE
O consumer está desligado.
A mensagem pode permanecer na fila conforme sua configuração e características.
Depois:
CONSUMER START
Ele processa.
Isso é muito diferente de uma chamada síncrona simples.
No mundo dos agentes isso é poderoso.
O LLM pode estar indisponível.
O worker pode reiniciar.
A aplicação pode sofrer manutenção.
A mensagem continua aguardando.
Mas agora surge uma pergunta:
Quanto tempo?
⏰ CAPÍTULO 7 — MENSAGENS TAMBÉM ENVELHECEM
Olha quem voltou.
Nosso amigo do Db2:
TEMPO.
Imagine:
MESSAGE CREATED:
10:00
O consumidor consegue processar:
14:00.
Tecnicamente a mensagem chegou.
Mas ainda faz sentido?
Talvez seja:
GENERATE MONTHLY REPORT
Sem problema.
Talvez seja:
CUSTOMER IS CURRENTLY LOGGED IN
Quatro horas depois?
Provavelmente inútil.
Logo mensagens também possuem:
AGE
EXPIRY
BUSINESS VALIDITY.
O MQ dos Agentes encontra o Db2 dos Agentes.
Não basta perguntar:
A mensagem chegou?
Pergunte:
Ela ainda significa alguma coisa quando chegou?
💥 CAPÍTULO 8 — A MENSAGEM CHEGOU DUAS VEZES
Finalmente chegamos ao monstro.
Imagine:
GET M001
O agente processa.
INSERT PAYMENT
COMMIT
Tudo certo.
Mas antes de completar adequadamente o ciclo de consumo:
CRASH.
Quando volta, dependendo da arquitetura e semântica empregada, a mensagem pode estar novamente disponível.
GET M001
O agente grita:
— Eu já processei isso!
A infraestrutura responde:
— Prove.
😂
Bem-vindo à possibilidade de:
REDELIVERY.
🧠 CAPÍTULO 9 — POR QUE DUPLICATAS EXISTEM?
Porque sistemas distribuídos possuem pontos de falha.
Considere:
MESSAGE
↓
PROCESS
↓
DATABASE UPDATE
↓
ACKNOWLEDGE
Agora imagine falha exatamente aqui:
DATABASE UPDATE
↓
COMMIT
↓
💀 CRASH
↓
ACKNOWLEDGE
Do ponto de vista do banco:
SUCCESS.
Do ponto de vista da mensageria:
NÃO SEI SE ELE TERMINOU.
O sistema possui duas escolhas ruins.
Escolha A
Assumir que processou.
Pode perder mensagem.
Escolha B
Entregar novamente.
Pode duplicar processamento.
Sistemas confiáveis frequentemente preferem não perder trabalho.
Então seu consumidor precisa estar preparado para duplicatas quando a semântica e arquitetura permitirem redelivery.
🔁 CAPÍTULO 10 — AT-LEAST-ONCE
Uma semântica comum em sistemas de mensageria e processamento distribuído é:
AT-LEAST-ONCE
Ou seja:
A mensagem será processada pelo menos uma vez.
Isso pode significar:
1
ou:
2
ou, em situações problemáticas:
mais.
Então:
AT-LEAST-ONCE
não significa:
EXACTLY-ONCE.
Se o efeito da mensagem não puder acontecer duas vezes, precisamos projetar proteção.
🎯 CAPÍTULO 11 — EXACTLY-ONCE É O UNICÓRNIO DA DUNGEON
Todo mundo quer:
EXACTLY ONCE.
A mensagem chega uma vez.
É processada uma vez.
O efeito acontece uma vez.
Perfeito.
Mas sistemas distribuídos possuem:
falhas
timeouts
restarts
partições
retries
E cada fronteira transacional complica o problema.
Se MQ e Db2 participam de uma unidade coordenada adequadamente, podemos obter garantias transacionais fortes em cenários específicos.
Mas quando nosso agente chama:
Db2
REST API
email
LLM
CRM SaaS
payment service
a conversa muda.
Nem todos participam da mesma transação.
Por isso é perigoso jogar:
EXACTLY-ONCE
num slide como se fosse magia.
🛡️ CAPÍTULO 12 — IDEMPOTÊNCIA ENTRA COM UMA ESPADA
A solução prática frequentemente passa por:
IDEMPOTÊNCIA.
Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indesejados depois da primeira aplicação bem-sucedida.
Exemplo perigoso:
ADD R$ 100 TO BALANCE
Execute duas vezes:
+100
+100
Resultado diferente.
Agora imagine:
SET PAYMENT P123 STATUS = PROCESSED
Executar novamente pode ser inofensivo dependendo da regra.
Ou:
PROCESS PAYMENT
WHERE PAYMENT_ID = P123
AND STATUS = PENDING
Depois da primeira execução:
STATUS = PROCESSED.
A segunda encontra:
NOT PENDING.
Nada acontece.
Muito melhor.
🪪 CAPÍTULO 13 — IDEMPOTENCY KEY
Outra técnica:
IDEMPOTENCY-KEY.
Exemplo:
IDEMPOTENCY-KEY = ORDER-9981-PAYMENT
Antes de executar:
SELECT STATUS
FROM PROCESSED_MESSAGES
WHERE IDEMPOTENCY_KEY = :KEY;
Se já existe:
ALREADY PROCESSED
não repetimos o efeito.
Se não existe:
PROCESS
STORE KEY
COMMIT
O detalhe crucial é tornar essa proteção suficientemente atômica para impedir dois consumidores concorrentes de passarem pela verificação simultaneamente.
Porque senão:
AGENT-A: não existe!
AGENT-B: não existe!
AGENT-A: processa!
AGENT-B: processa!
Parabéns.
Construímos uma deduplicação que duplica.
😂
🔐 CAPÍTULO 14 — MQ E Db2 PRECISAM CONVERSAR SOBRE COMMIT
Agora chegamos ao terreno favorito do mainframe.
Imagine:
MQGET
↓
UPDATE Db2
↓
COMMIT
Queremos que o consumo da mensagem e a alteração no banco tenham comportamento consistente.
Idealmente, dentro de um desenho transacional apropriado:
GET MESSAGE
+
UPDATE DATABASE
+
COMMIT
fazem parte de uma unidade lógica coerente.
Se falhar:
ROLLBACK.
A alteração do banco não fica pela metade e a mensagem pode permanecer disponível conforme a unidade de trabalho.
Esse é exatamente o tipo de problema que mainframes resolvem há décadas.
🧱 CAPÍTULO 15 — UNIT OF WORK VOLTOU
Nosso velho amigo:
UOW
Unit of Work.
Conceitualmente:
BEGIN UOW
GET MESSAGE
UPDATE DB2
INSERT AUDIT
COMMIT UOW
Se:
UPDATE DB2
falhar:
ROLLBACK.
O importante é definir claramente:
Quais efeitos pertencem à mesma unidade de consistência?
Para agentes, isso é essencial.
Porque eles tendem a fazer muitas coisas.
☠️ CAPÍTULO 16 — O PROBLEMA DAS AÇÕES EXTERNAS
Nosso agente:
GET MESSAGE
↓
UPDATE Db2
↓
SEND EMAIL
↓
CALL PAYMENT API
↓
POST MESSAGE
Rollback?
Db2:
— Posso ajudar.
MQ:
— Também.
E-mail:
— Já enviei.
API externa:
— Já cobrei.
Internet:
— Boa sorte.
😂
Essa é a fronteira entre transações locais/coordenadas e efeitos distribuídos externos.
SCHEMA......... OK
VERSION........ SUPPORTED
AUTHORITY...... OK
DUPLICATE...... NO
ORDER.......... OK
FRESHNESS...... OK
Consulta Db2.
CURRENT STATE.. VALID
Inicia unidade de trabalho.
PROCESS PAYMENT
INSERT AUDIT
REGISTER MESSAGE
Confirma.
COMMIT.
Resultado:
SUCCESS.
Alguns milissegundos depois:
💥
O worker cai.
Reinicia.
A mensagem aparece novamente.
O velho agente teria gritado:
Já fiz isso!
O novo apenas consulta:
IDEMPOTENCY-KEY = P88271.
Resposta:
ALREADY PROCESSED.
Nenhum pagamento duplicado.
Nenhuma madrugada destruída.
Nenhum DBA perseguindo robôs pelo corredor.
O agente registra:
DUPLICATE DELIVERY
BUSINESS EFFECT SKIPPED
STATUS = SAFE
Turing toma o primeiro café da manhã.
O programador pergunta:
— Então a duplicata deixou de ser um problema?
— Não.
— Mas não aconteceu nada.
— Exatamente.
O programador pensa.
Turing continua:
— Engenharia confiável não é construir um universo onde falhas nunca acontecem.
Aponta para a tela:
REDELIVERY DETECTED
— É construir um sistema no qual falhas esperadas deixam de virar desastres inesperados.
O pequeno robô levanta a mão.
— Professor?
— Sim?
— Posso apagar a mensagem de 1999?
Do outro lado do CPD o administrador MQ grita:
— NÃO! PRIMEIRO FAZ BACKUP!
😂
Turing fecha o terminal.
Na tela permanece:
MQ
────────────────────────
MESSAGE-ID...... M004821
DELIVERY........ 2
PROCESSING...... IDEMPOTENT
BUSINESS EFFECT. ONCE
STATUS.......... SAFE
COMMIT.......... OK
E embaixo:
A MENSAGEM PODE CHEGAR NOVAMENTE.
O EFEITO NÃO PRECISA ACONTECER NOVAMENTE.
Essa é talvez a grande lição do MQ dos Agentes.
Porque quando centenas de inteligências artificiais começarem a conversar entre si, delegando tarefas, publicando eventos, recebendo respostas, reiniciando workers, atravessando APIs, bancos, filas e nuvens, não bastará perguntar:
A mensagem chegou?
Teremos de perguntar:
Qual mensagem?
De quem?
Quando?
Em qual ordem?
Quantas vezes?
Ainda é válida?
Já foi processada?
O efeito foi confirmado?
Posso executar novamente?
E se eu cair exatamente agora?
O mainframe conhece essa paranoia há décadas.
E talvez por isso tenha tanta coisa para ensinar aos agentes.
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
