✨ 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
🚀💥 CICS: O “CONTROLADOR DE TRÁFEGO” DO MAINFRAME — ONDE TASKS NASCEM, EXECUTAM… E ÀS VEZES PRECISAM SER ELIMINADAS 💥🚀
Se você é SysProg raiz, sabe: o IBM CICS não é só um subsistema — é um organismo vivo. Milhares de transações pulsando por segundo, usuários conectados, filas, locks, DB2, MQ… e no meio disso tudo: você, com a responsabilidade de manter tudo fluindo.
Aqui vai um guia no estilo “mão na massa + café forte” pra dominar o gerenciamento do CICS no dia a dia.
🧠🔥 VISÃO MENTAL DO CICS (ANTES DE OPERAR)
Pense no CICS como:
Dispatcher → controla quem executa
Tasks (TCA) → unidades de trabalho
Terminal/User → origem da transação
Programs → lógica (COBOL, PL/I…)
Resources → VSAM, DB2, MQ
👉 Cada ENTER do usuário vira uma task 👉 Cada task consome CPU, storage e locks 👉 E sim… algumas tasks travam tudo 😄
🕵️♂️🔍 1. VENDO LOGS COMO UM DETETIVE
No CICS, erro nunca vem sozinho. Ele deixa rastro.
📌 Principais logs:
CSMT → mensagens gerais
CSM1 → log auxiliar
Transient Data Queue (TDQ) → logs customizados
SMF 110 → performance e auditoria
🔎 Exemplo clássico:
DFHAC2001 TRANSACTION ABCD ABENDED WITH CODE ASRA
👉 Tradução Bellacosa:
“Alguém fez besteira no programa — provavelmente S0C4 disfarçado” 😄
👤🆔 2. IDENTIFICANDO USER E TASK EM TEMPO REAL
Aqui começa o jogo de verdade.
📌 Transação chave:
CEMT I TASK
Isso mostra:
Task Number
Transaction ID
UserID
Status (RUNNING, WAITING…)
CPU Time
🔥 Exemplo:
Tas(000123) Tra(ABCD) Use(USER01) Sta(RUN)
👉 Você já sabe:
Quem → USER01
O quê → ABCD
Qual → Task 123
💡 Dica de ouro:
CEMT I TASK USE(USER01)
👉 Filtra direto no usuário (perfeito pra incidentes)
☠️💣 3. DERRUBANDO TASK (QUANDO O CAOS CHEGA)
Quando uma task trava:
segura recurso
explode CPU
trava fila inteira
👉 Você entra com autoridade:
💥 Comando:
CEMT SET TASK(123) PURGE
⚠️ Versão nuclear:
CEMT SET TASK(123) FORCEPURGE
👉 Diferença:
PURGE → educado
FORCEPURGE → “sai ou eu te mato” 😄
💡 Cuidado:
Pode deixar dados inconsistentes
Use quando não há alternativa
📊⚡ 4. MONITORANDO PERFORMANCE E CONSUMO
Aqui mora o SysProg de elite.
📌 Transações importantes:
CEMT I SYS → visão geral
CEMT I TASK → consumo por task
CEMT I TRAN → estatísticas de transação
🔎 Indicadores críticos:
CPU time alto
Tasks WAITING (lock?)
Storage crescente
Response time degradando
🧠 Dica avançada (nível hard):
Use SMF 110 + ferramentas como:
IBM OMEGAMON
IBM RMF
👉 Isso revela:
Top consumidores
Gargalos invisíveis
Tendência de carga
🛠️📋 5. CHECKLIST DE SOBREVIVÊNCIA DO SYSPROG CICS
Quando der problema, siga isso:
✅ Passo a passo real:
Ver logs (CSMT)
Identificar erro (abend?)
Listar tasks
CEMT I TASK
Filtrar usuário/transação
Ver consumo
Decidir ação
aguardar
PURGE
FORCEPURGE
Validar impacto
Registrar ocorrência
🧩💡 EASTER EGGS DE QUEM VIVE CICS
👉 😄 “Toda ASRA tem uma história triste por trás” 👉 😄 “Se precisa dar FORCEPURGE… alguém fez deploy na sexta” 👉 😄 “Task WAITING sem motivo = lock escondido no DB2”
🏛️📜 CURIOSIDADES QUE POUCA GENTE SABE
O IBM CICS nasceu nos anos 60 (!!)
Ainda hoje processa bilhões de transações/dia
Grande parte dos caixas eletrônicos do mundo passam por ele
Ele é um dos sistemas mais resilientes já criados
🎯💬 COMENTÁRIO FINAL (NA VEIA)
Gerenciar CICS não é rodar comando.
É:
entender comportamento
prever problema
agir rápido
e às vezes… tomar decisões duras
👉 Porque no fim do dia:
“CICS parado não é sistema fora — é empresa parada.”
🔭 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS A INTELIGÊNCIA ARTIFICIAL ESTÁ FAZENDO AGORA?
Observabilidade, logs, métricas, traces, spans, OpenTelemetry, tokens, custos, latência, estados, workflows, auditoria, SDSF, JES2, SMF, RMF, CICS — e o dia em que Alan Turing descobriu que “AGENT RUNNING...” era quase tão informativo quanto um operador responder “sei lá, está processando”.
🎬 PRÓLOGO — O ROBÔ ESTAVA “TRABALHANDO”
Alan Turing entrou novamente no CPD.
O pequeno agente de IA estava diante de um terminal.
Na tela:
AGENT STATUS
============
RUNNING...
Turing esperou.
Um minuto.
Dois minutos.
Cinco minutos.
Continuava:
RUNNING...
O jovem programador COBOL apareceu carregando café.
— Bom dia, professor.
Turing apontou para a tela.
— O que ele está fazendo?
— Trabalhando.
— Em quê?
— Não sei.
— Em qual etapa?
— Também não sei.
— Encontrou algum erro?
— Acho que não.
— Quanto já gastou?
— Não faço ideia.
— Está esperando alguma coisa?
— Talvez.
Turing olhou novamente para:
RUNNING...
e sentenciou:
— Então vocês construíram uma máquina capaz de tomar decisões, utilizar ferramentas e executar ações... mas colocaram nela a mesma lâmpada de “ocupado” de uma impressora de 1987?
Silêncio.
No fundo do CPD alguém apertou Enter tentando não rir.
Turing puxou uma cadeira.
— Abra o SDSF.
E assim começou nossa terceira aventura.
🏛️ CAPÍTULO 1 — NO MAINFRAME, “ESTÁ RODANDO” NUNCA FOI RESPOSTA SUFICIENTE
Provavelmente essa resposta não sobreviveria muitos minutos no CPD.
Queremos saber:
JOBNAME
JOBID
OWNER
STATUS
QUEUE
STEP
RETURN CODE
OUTPUT
O SDSF existe justamente nesse universo de monitorar e controlar processamento z/OS. A documentação da IBM descreve painéis capazes de acompanhar jobs desde a fila de entrada do JES, passando pelo processamento, até as filas de saída; o painel ST, por exemplo, é central para gerenciamento de jobs e output.
AGENT: REPORT
RUN-ID: A000471
OBJECTIVE:
Consolidar relatórios de setembro
CURRENT STATE:
WAITING_APPROVAL
CURRENT STEP:
5/7 - Enviar relatório financeiro
WAITING FOR:
Aprovação humana
WAIT TIME:
00:03:42
Agora sabemos o que está acontecendo.
Talvez o agente nem esteja consumindo processamento significativo.
Está simplesmente esperando alguém.
Uma boa interface precisa diferenciar:
TRABALHANDO
de:
ESPERANDO
e de:
TRAVADO
Parece óbvio.
Até você encontrar sistemas que tratam os três como:
PROCESSING...
🪵 CAPÍTULO 4 — LOG: O DIÁRIO DE BORDO
Primeiro instrumento da nossa caixa de observabilidade:
LOG.
Log é basicamente o registro de eventos ocorridos.
O OpenTelemetry define logs como registros de eventos e suporta informações estruturadas como timestamp, severidade, corpo, atributos e também identificadores de trace e span, permitindo correlação com outros sinais.
Um log simples:
10:01:03 Agent started
10:01:04 Reading report
10:01:12 Report loaded
10:01:13 Calling model
10:01:18 Analysis completed
Em vez de texto para seres humanos lerem manualmente, possuímos campos que sistemas podem consultar.
Podemos perguntar:
event = tool.error
ou:
run_id = A000471
ou:
duration_ms > 5000
Isso é tremendamente mais poderoso.
📜 CAPÍTULO 5 — O SYSOUT DO ROBÔ
Aqui o programador COBOL começa a sorrir.
Porque o conceito não é estranho.
Quando um job termina, frequentemente vamos investigar sua saída.
SDSF permite navegar pelos outputs de jobs e pelas informações de processamento; historicamente, muito output destinado ao JES sequer precisava ser fisicamente impresso — podia ser inspecionado no SDSF.
Não precisamos literalmente transformar agentes em JES.
Mas precisamos abandonar a filosofia:
“Ele respondeu, então provavelmente deu tudo certo.”
📊 CAPÍTULO 6 — MÉTRICA NÃO É LOG
Turing escreve:
LOG
≠
METRIC
Log responde muito bem a:
O que aconteceu?
Métrica responde melhor a:
Quanto está acontecendo?
Por exemplo:
agent_runs_total = 15420
agent_failures_total = 327
average_duration = 18.4 s
tool_calls_total = 92481
approval_wait_time = 47.2 s
input_tokens = ...
output_tokens = ...
OpenTelemetry é hoje um framework vendor-neutral para instrumentar, gerar, coletar e exportar telemetria, incluindo traces, metrics e logs.
Para aplicações GenAI, suas convenções incluem atributos relacionados ao uso de tokens e identificação de workflows/agentes; essas convenções específicas continuam evoluindo, portanto não devemos tratá-las como uma pedra gravada para toda a eternidade.
💰 CAPÍTULO 7 — AGORA A TELEMETRIA TEM CONTA PARA PAGAR
No mainframe sempre aprendemos que recurso computacional custa.
As convenções de GenAI do OpenTelemetry contemplam métricas e atributos de uso de tokens; a observabilidade pode então ajudar a detectar prompts excessivamente grandes, regressões de latência e padrões de consumo.
E aqui aparece um velho fantasma mainframe:
EFICIÊNCIA.
Um agente que consegue resolver uma tarefa em:
3 chamadas
pode ser operacionalmente preferível a outro que precisa:
37 chamadas
mesmo que ambos terminem corretamente.
⏱️ CAPÍTULO 8 — LATÊNCIA: O AGENTE DEMOROU, MAS ONDE?
Imagine:
TOTAL = 18 segundos
Isso não nos diz muita coisa.
Talvez:
LLM............. 2 s
DATABASE........ 1 s
API............. 1 s
FILE............ 1 s
Então onde foram parar os outros 13 segundos?
Precisamos decompor.
É aí que entramos no mundo do distributed tracing.
A busca documental está custando quase cinco segundos.
Um span representa uma execução individual de uma operação significativa dentro de um trace; as convenções do OpenTelemetry padronizam atributos para facilitar correlação entre tecnologias diferentes.
🔬 CAPÍTULO 10 — TRACE É O “QUAL STEP ESTÁ DEMORANDO?” DO MUNDO DISTRIBUÍDO
A própria documentação de observabilidade GenAI chama atenção para o fato de que conteúdo de mensagens e tool calls pode ser capturado quando habilitado, enquanto implementações podem permitir desativar a exportação desse conteúdo.
Portanto:
Observabilidade não significa registrar tudo indiscriminadamente.
Precisamos pensar em:
REDACTION
MASKING
SAMPLING
RETENTION
ACCESS CONTROL
ENCRYPTION
O log também é dado.
E dado precisa de governança.
🧹 CAPÍTULO 17 — NÃO TRANSFORME O LOG NUM DEPÓSITO DE LIXO
Outro clássico.
DEBUG 1
DEBUG 2
ENTROU AQUI
PASSOU AQUI
TESTE
XYZ
AAAA
😂
Todo programador já encontrou algum parente dessa criatura.
Logs úteis precisam responder perguntas.
Uma boa estrutura pode incluir:
timestamp
severity
service
agent
run_id
trace_id
span_id
event
tool
duration
status
error_type
E usar níveis coerentes:
DEBUG
INFO
WARN
ERROR
Não transforme tudo em:
ERROR
senão o erro perde significado.
É o equivalente moderno de um painel inteiro piscando vermelho.
O Collector pode receber, processar e exportar telemetria.
O objetivo não é:
“Comprar um dashboard bonito.”
É:
Padronizar a forma de produzir e transportar evidência operacional.
🏷️ CAPÍTULO 19 — CONVENÇÕES SEMÂNTICAS: CHAME A MESMA COISA PELO MESMO NOME
Imagine:
Sistema A:
duration
Sistema B:
elapsed
Sistema C:
execution_time
Sistema D:
how_long_this_thing_took
😂
Agora tente construir um dashboard corporativo.
Convenções semânticas procuram padronizar nomes e significados para operações e dados observáveis. O OpenTelemetry mantém convenções para traces, métricas, logs, profiles e resources.
No universo GenAI isso é especialmente importante.
Queremos poder falar de conceitos como:
agent
model
operation
tool
token usage
workflow
de maneira consistente.
As convenções GenAI ainda estão evoluindo, o que é natural numa área que também está mudando rapidamente.
🧬 CAPÍTULO 20 — SDSF + SMF + RMF + OTEL: NÃO SÃO A MESMA COISA
Aqui precisamos evitar uma simplificação perigosa.
Não podemos dizer:
SDSF = OpenTelemetry
Não é.
Nem:
SMF = logs
RMF = metrics
como equivalências técnicas exatas.
São tecnologias com histórias, escopos e arquiteturas diferentes.
Mas podemos construir uma ponte didática.
SDSF
Ajuda o operador a ver e controlar execução.
SMF
Produz enorme quantidade de registros operacionais e de accounting sobre atividades do sistema.
RMF
Historicamente fornece medição e análise de performance e recursos.
OpenTelemetry
Padroniza instrumentação e transporte de sinais modernos de observabilidade.
latência
tokens
tool calls
retries
erros
tempo aguardando humano
custo
PASSO 5 — TRACE AS DEPENDÊNCIAS
Quando a execução atravessar:
agent → API → Db2 → MQ → CICS
preserve correlação.
PASSO 6 — PROTEJA A TELEMETRIA
Não registre segredos simplesmente porque são úteis para debugging.
PASSO 7 — DEFINA SUCESSO
Não use apenas:
DONE
Use critérios de negócio.
PASSO 8 — CONSTRUA ALERTAS ÚTEIS
Não alerte para tudo.
Alerte quando algo realmente exigir atenção.
🚨 CAPÍTULO 23 — O ALERTA QUE TOCA ÀS 3 DA MANHÃ
Todo sistema de observabilidade eventualmente encontra seu verdadeiro teste:
03:17.
Telefone toca.
ALERT:
AGENT FAILURE RATE > 25%
Você abre o painel.
Descobre:
Tool: CUSTOMER-API
p99 latency: 31s
Timeout rate: 38%
Retries: 4.2 per run
Agora existe hipótese.
Sem observabilidade:
A IA ficou burra.
Com observabilidade:
A API de clientes está degradada; o agente está repetindo chamadas e acumulando timeout.
Essa diferença é gigantesca.
Modelos inteligentes introduzem novas fontes de incerteza.
Não devemos atribuir todo problema ao modelo.
Pode ser:
modelo
prompt
tool
API
rede
Db2
MQ
permissão
rate limit
dados
timeout
bug
Observabilidade separa fantasmas de evidências.
🧙 CAPÍTULO 24 — TURING DESENHA AS QUATRO PERGUNTAS
Turing pega o giz.
Escreve:
1. O QUE ESTÁ ACONTECENDO?
Estado + logs.
2. QUANTO ESTÁ ACONTECENDO?
Métricas.
3. POR ONDE PASSOU?
Trace.
4. QUEM AUTORIZOU?
Auditoria.
O jovem COBOL acrescenta uma quinta:
5. QUANTO CUSTOU?
Turing olha.
— Muito bem.
O administrador do CPD acrescenta:
6. POSSO PARAR?
E o administrador RACF:
7. ELE PODIA FAZER ISSO?
Agora temos praticamente toda a série:
PF3
↓
POSSO PARAR?
MAXCC
↓
FUNCIONOU?
RACF
↓
PODIA FAZER?
SDSF
↓
O QUE ESTÁ FAZENDO?
🥚 EASTER EGG — S A00471
São 02:58.
O jovem operador vê:
AGENT RUN-ID STATE
REPORT A00471 RUNNING
Digite:
S A00471
A tela abre.
CURRENT ACTION:
Searching documentation
ELAPSED:
02:47:31
FILES FOUND:
4,281,771
CURRENT DIRECTORY:
/
Silêncio.
Turing olha para o programador.
O programador olha para Turing.
O administrador de segurança derruba o café.
Alguém pergunta:
— Quem deu acesso ao filesystem inteiro?
Do fundo da sala vem uma voz:
— Foi para facilitar o protótipo.
O administrador RACF levanta lentamente da cadeira.
ICH408I
Fim do easter egg.
☕ EPÍLOGO — NÃO QUERO UMA IA TRANSPARENTE; QUERO UMA IA OPERÁVEL
Existe uma diferença importante.
Quando falamos em observabilidade, não estamos necessariamente exigindo enxergar todos os mecanismos internos de um modelo.
Queremos algo muito mais prático.
Queremos saber:
qual tarefa
qual execução
qual estado
qual etapa
qual ferramenta
quanto tempo
quanto recurso
qual erro
qual resultado
qual aprovação
Em outras palavras:
OPERABILIDADE.
Um agente corporativo precisa ser operável.
Precisa ser possível colocar alguém diante dele e perguntar:
O que está acontecendo?
E obter resposta melhor que:
RUNNING...
Isso parece uma discussão sobre inteligência artificial.
Mas também é uma discussão profundamente antiga sobre sistemas.
O mainframe aprendeu há décadas que executar trabalho empresarial significa deixar evidência.
Jobs possuem identidade.
Execuções possuem estados.
Etapas possuem resultados.
Output pode ser examinado.
Falhas precisam ser investigadas.
Recursos precisam ser medidos.
A IBM descreve SDSF justamente como um meio seguro de monitorar e gerenciar sistemas z/OS, jobs, output, recursos e mensagens operacionais.
O mundo distribuído acrescentou novos desafios.
Microsserviços.
APIs.
Cloud.
Containers.
Mensageria.
Agora adicionamos:
LLMs.
Tools.
RAG.
Copilotos.
Agentes.
Mas a pergunta do operador continua assustadoramente parecida.
O que diabos está acontecendo agora?
OpenTelemetry nos oferece uma linguagem moderna para parte dessa investigação, reunindo logs, métricas e traces e permitindo correlação entre componentes.
E os agentes tornam essa disciplina ainda mais importante.
Porque não estamos observando apenas software executando um caminho predeterminado.
Podemos estar observando software escolhendo dinamicamente qual caminho executar.
Para um operador, um SRE, um programador COBOL ou qualquer pessoa que já tenha passado algumas horas tentando descobrir por que um sistema parou às três da manhã...
isso já é uma diferença gigantesca.
Porque o futuro talvez esteja cheio de agentes inteligentes.
Mas quando alguma coisa der errado, alguém ainda precisará abrir uma tela e perguntar:
ST
Qual é o status?
Algumas perguntas sobrevivem a todas as revoluções tecnológicas.
READY
E, naturalmente...
há outro agente na fila.
☕ 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
