✨ 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
Parte I – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param?
Quando um jovem Padawan COBOL entra pela primeira vez em uma empresa que utiliza IBM Z, normalmente ele acredita que seu trabalho consiste em escrever programas COBOL, executar alguns Jobs, consultar arquivos VSAM e, eventualmente, criar uma transação CICS.
Não demora muito para ouvir frases como:
"Precisamos garantir o SLA."
"O RTO deste sistema é de cinco minutos."
"Não podemos ter nenhum Single Point of Failure."
"Essa aplicação precisa ser resiliente."
Nesse momento, o Padawan percebe que entrou em um universo completamente diferente daquele ensinado na maioria dos cursos de programação.
No IBM Z, escrever software é apenas uma parte da engenharia. A outra metade consiste em garantir que esse software continue funcionando quando tudo ao redor começa a falhar.
Bem-vindo ao mundo da Resiliência.
Os conceitos apresentados nesta primeira parte são a base para compreender por que os maiores bancos, seguradoras, bolsas de valores, companhias aéreas e governos do mundo continuam confiando no IBM Z para executar suas aplicações mais críticas. Os termos discutidos a seguir fazem parte do glossário de Resiliency do IBM Z e representam os pilares conceituais dessa arquitetura.
O que significa Resiliency?
Imagine um hospital.
Ninguém espera que um hospital nunca enfrente problemas.
Equipamentos quebram.
Transformadores queimam.
Geradores precisam de manutenção.
Redes elétricas falham.
Mesmo assim...
A cirurgia não pode parar.
No mundo dos computadores acontece exatamente a mesma coisa.
Resiliência significa continuar prestando serviço mesmo quando partes da infraestrutura apresentam defeitos.
Esse é um conceito muito diferente de simplesmente "não quebrar".
Todo equipamento quebra.
Todo software possui defeitos.
Todo disco possui vida útil.
Toda memória pode apresentar falhas.
A diferença é que o IBM Z foi projetado assumindo que essas falhas acontecerão.
A arquitetura inteira trabalha para impedir que o usuário perceba qualquer interrupção.
Essa filosofia explica por que milhares de transações bancárias continuam acontecendo enquanto técnicos substituem processadores, discos ou placas de comunicação.
Para um programador COBOL, compreender Resiliency muda completamente a forma de pensar. O objetivo deixa de ser apenas fazer o programa "funcionar"; passa a ser escrever aplicações que convivam com uma infraestrutura preparada para falhas.
RAS – Reliability, Availability and Serviceability
Existe um conceito extremamente famoso dentro da IBM:
RAS.
São apenas três palavras.
Mas representam décadas de engenharia.
Reliability
Confiabilidade.
O equipamento precisa falhar pouco.
Isso envolve:
qualidade dos componentes;
redundância;
testes de fábrica;
validações contínuas.
Quanto maior a confiabilidade, menor a probabilidade de interrupções inesperadas.
Availability
Disponibilidade.
Mesmo quando alguma coisa quebra...
O serviço continua.
É exatamente aqui que entram conceitos como:
Parallel Sysplex;
GDPS;
Load Balancing;
WLM.
Disponibilidade não significa ausência de falhas.
Significa continuidade do negócio.
Serviceability
Facilidade de manutenção.
Imagine trocar um disco sem desligar o computador.
Ou substituir memória durante a operação.
Ou atualizar firmware sem interromper milhares de usuários.
Isso é Serviceability.
Quanto mais simples a manutenção...
Menor o tempo de indisponibilidade.
High Availability (HA)
Muitos iniciantes acreditam que Alta Disponibilidade significa "100% online".
Não é verdade.
Alta Disponibilidade significa reduzir o impacto das interrupções até um nível aceitável para o negócio.
Imagine dois caixas eletrônicos.
Se um apresentar defeito...
O cliente utiliza o outro.
Agora imagine dois servidores CICS.
Se um falhar...
O outro assume automaticamente.
Essa é a essência da HA.
A infraestrutura foi desenhada para absorver falhas sem interromper o serviço.
Disaster Recovery (DR)
Enquanto a Alta Disponibilidade lida com falhas locais, o Disaster Recovery pensa em eventos extremos.
Perguntas típicas são:
E se o prédio pegar fogo?
E se faltar energia por várias horas?
E se houver uma enchente?
E se todo o datacenter ficar inacessível?
Nesse cenário entra o Plano de Recuperação de Desastres.
O objetivo não é impedir o desastre.
É garantir que o negócio sobreviva a ele.
No IBM Z, tecnologias como GDPS, replicação de dados e sites espelhados fazem parte dessa estratégia.
SLA – Service Level Agreement
Todo sistema existe para atender um negócio.
E o negócio estabelece compromissos.
Exemplo:
"O Internet Banking deve permanecer disponível 99,99% do tempo."
Isso é um SLA.
Curiosamente, poucas pessoas percebem o impacto desses números.
Veja:
99% parece excelente.
99,9% é muito melhor.
99,99% é extraordinário.
99,999% representa apenas alguns minutos de indisponibilidade por ano.
Cada "9" adicional exige muito mais investimento em hardware, software, processos e pessoas.
RPO – Recovery Point Objective
Imagine que um banco sofra uma pane às 15h.
Qual o último dado aceitável?
15h00?
14h59?
14h30?
Ontem?
Essa resposta define o RPO.
Quanto menor o RPO...
Menor a perda de informações.
Em sistemas financeiros modernos, o objetivo costuma ser próximo de zero.
Nenhuma transação pode desaparecer.
RTO – Recovery Time Objective
Agora faça outra pergunta.
Quanto tempo o sistema pode permanecer parado?
Cinco minutos?
Uma hora?
Quatro horas?
Isso é o RTO.
Observe a diferença.
O RPO mede perda de dados.
O RTO mede tempo de recuperação.
São conceitos diferentes.
E ambos determinam toda a arquitetura de um ambiente corporativo.
Single Point of Failure (SPoF)
Este talvez seja o termo mais importante para qualquer arquiteto.
Imagine um único switch de rede.
Se ele quebrar...
Toda a empresa para.
Esse switch é um SPoF.
Agora pense em um único banco de dados.
Ou uma única fonte de alimentação.
Ou um único servidor DNS.
Todos são candidatos a pontos únicos de falha.
A missão dos arquitetos IBM Z é eliminar todos eles.
Por isso existem componentes redundantes, caminhos alternativos e múltiplos mecanismos de recuperação.
Component Failure Impact Analysis (CFIA)
O nome parece complicado.
Mas a ideia é simples.
Pergunte para cada componente:
"O que acontece se você morrer agora?"
Depois repita para:
discos;
processadores;
memória;
switches;
links;
storages;
sistemas operacionais.
Se alguma resposta for:
"Tudo para."
Você encontrou um problema.
O CFIA é justamente o exercício sistemático de identificar esses riscos antes que eles ocorram.
ITIL – Muito Além da Tecnologia
Muitos desenvolvedores imaginam que disponibilidade depende apenas do hardware.
Na prática, processos mal definidos também derrubam sistemas.
É aqui que entra a ITIL.
Ela organiza boas práticas para:
mudanças;
incidentes;
problemas;
configuração;
continuidade;
disponibilidade.
Quando uma grande instituição financeira realiza uma atualização em produção, normalmente existe todo um processo inspirado nessas práticas para reduzir riscos.
A Mentalidade IBM Z
Existe uma frase bastante conhecida entre profissionais experientes de Mainframe:
"No IBM Z, falhas são esperadas. O que não é aceitável é que elas interrompam o negócio."
Essa mentalidade muda completamente a forma de desenvolver software.
O programador COBOL deixa de enxergar apenas linhas de código e passa a compreender que sua aplicação faz parte de um ecossistema muito maior, onde hardware, sistema operacional, middleware, armazenamento e processos trabalham em conjunto para garantir continuidade.
Cada programa Batch, cada transação CICS e cada acesso ao Db2 participa de uma cadeia cuidadosamente projetada para manter milhões de pessoas utilizando serviços bancários, comprando passagens aéreas, movimentando bolsas de valores ou recebendo benefícios sociais sem sequer imaginar a complexidade escondida por trás de uma simples tela.
Esse é o verdadeiro espírito do IBM Z.
Não construir computadores que nunca falham.
Mas construir sistemas que continuam funcionando mesmo quando inevitavelmente algo dá errado.
No próximo capítulo, deixaremos os conceitos e entraremos na infraestrutura física do IBM Z, explorando componentes como CPC, Processing Units, HMC, Support Element, License Internal Code e outros elementos que fazem do mainframe uma das plataformas mais resilientes já criadas.
Bellacosa Mainframe e as prioridades dos agenstes de ia
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🚦 ALAN TURING E O WLM DOS AGENTES — QUANDO 500 INTELIGÊNCIAS ARTIFICIAIS QUEREM TRABALHAR AO MESMO TEMPO
Workload Management, filas, prioridades, SLA, SLO, backpressure, rate limits, throttling, quotas, tokens, custos, latência, concorrência, CICS, Db2, MQ, JES2, WLM — e o dia em que Alan Turing descobriu que inteligência artificial também precisa aprender a esperar na fila.
🎬 PRÓLOGO — QUINHENTOS ROBÔS CHEGARAM PARA TRABALHAR
Alan Turing entrou no CPD às 08:59.
Tudo parecia tranquilo.
O café estava quente.
O operador examinava o SDSF.
O jovem programador COBOL tentava entender por que um PIC 9(05) não aceitava aquilo que ele jurava ser um número.
Se B é um processamento de baixa prioridade, talvez possa aguardar.
Podemos inclusive imaginar políticas:
IF DAILY_BUDGET > 80%
THROTTLE BACKGROUND AGENTS
END-IF
Olha o COBOL aparecendo.
👨💻 CAPÍTULO 13 — UM WLM DE AGENTES EM PSEUDO-COBOL
Vamos brincar.
EVALUATE AGENT-CLASS
WHEN 'CRITICAL'
MOVE 50 TO MAX-CONCURRENCY
MOVE 1000 TO RATE-LIMIT
WHEN 'INTERACTIVE'
MOVE 25 TO MAX-CONCURRENCY
MOVE 500 TO RATE-LIMIT
WHEN 'STANDARD'
MOVE 10 TO MAX-CONCURRENCY
MOVE 200 TO RATE-LIMIT
WHEN 'BACKGROUND'
MOVE 2 TO MAX-CONCURRENCY
MOVE 50 TO RATE-LIMIT
END-EVALUATE.
Naturalmente um sistema real seria muito mais sofisticado.
Do outro lado do CPD, o administrador WLM fecha os olhos.
Turing pega o café.
— Acabamos de descobrir por que governança existe.
👑 CAPÍTULO 27 — PRIORIDADE TAMBÉM PRECISA DE GOVERNANÇA
Esse ponto é fundamental.
Se qualquer equipe puder declarar:
MY_AGENT = CRITICAL
em poucas semanas teremos:
500 CRITICAL AGENTS
E então:
CRITICAL
não significa absolutamente nada.
Precisamos de critérios.
Por exemplo:
CRITICAL
Impacto financeiro imediato
ou risco operacional grave.
INTERACTIVE
Humano aguardando resposta.
STANDARD
Processamento normal.
BACKGROUND
Sem interação humana imediata.
Classificação precisa ser governada.
Caso contrário ocorre a inflação de prioridade.
É como colocar:
URGENTE!!!
em todos os e-mails.
Depois de algum tempo ninguém acredita mais.
🛡️ CAPÍTULO 28 — DEGRADAÇÃO GRACIOSA
Imagine que o modelo mais poderoso esteja saturado.
Temos duas escolhas.
A
Falhar.
B
Talvez usar um modelo menor para tarefas compatíveis.
PREMIUM MODEL
↓ saturado
SMALL MODEL
Ou reduzir funcionalidades.
FULL ANALYSIS
↓ pressão
BASIC ANALYSIS
Isso é uma forma de graceful degradation.
O sistema continua oferecendo valor, embora em nível reduzido.
Mas cuidado.
Nunca faça downgrade silencioso quando isso alterar requisitos críticos de qualidade ou segurança.
A UX precisa informar quando o comportamento muda de maneira relevante.
📉 CAPÍTULO 29 — ERROR BUDGET: QUANTO PODEMOS ERRAR?
Em práticas de SRE aparece um conceito interessante:
error budget.
Se nosso SLO é:
99.9%
não estamos declarando perfeição absoluta.
Existe uma margem de falha tolerada.
O orçamento de erro ajuda a equilibrar:
confiabilidade
e:
velocidade de mudança
Para agentes, o conceito pode inspirar discussões úteis.
Mas precisamos tomar cuidado.
Não significa:
O agente tem autorização para errar 0,1% das transferências bancárias.
😂
Contexto importa.
Algumas operações exigem controles muito mais rigorosos.
O princípio é operacional:
Defina objetivos mensuráveis e saiba quanto desvio é tolerável antes de tomar ação.
🧠 CAPÍTULO 30 — A INTELIGÊNCIA NÃO ELIMINA A FILA
Talvez esta seja a conclusão mais divertida.
Passamos décadas tornando máquinas mais inteligentes.
Criamos:
machine learning
deep learning
LLMs
agents
E finalmente construímos software capaz de:
interpretar
planejar
decidir
usar ferramentas
Então colocamos 500 deles juntos.
E descobrimos que eles precisam...
pegar senha.
😂
Porque inteligência não cria CPU infinita.
Não cria banda infinita.
Não cria conexões Db2 infinitas.
Não cria tokens infinitos.
E definitivamente não cria orçamento infinito.
Portanto até uma sociedade de agentes precisa de:
fila
prioridade
quota
limite
scheduler
Alguns problemas sobrevivem a todas as revoluções tecnológicas.
RACF
→ quem pode fazer?
PF3
→ posso parar?
SDSF
→ o que está fazendo?
MAXCC
→ funcionou?
WLM
→ quem recebe recursos primeiro?
Agora nossa arquitetura começa a parecer adulta.
☕ EPÍLOGO — ATÉ ROBÔ PRECISA ESPERAR SUA VEZ
No final do dia, Turing voltou ao painel.
Às 09:00 havia:
500 agentes
todos tentando executar simultaneamente.
Agora o sistema mostrava:
AI WORKLOAD MANAGER
CRITICAL
ACTIVE: 42
QUEUED: 3
SLO: OK
INTERACTIVE
ACTIVE: 80
QUEUED: 17
SLO: OK
STANDARD
ACTIVE: 40
QUEUED: 121
SLO: OK
BACKGROUND
ACTIVE: 10
QUEUED: 287
SLO: OK
O pequeno robô protestou:
— Mas existem 287 agentes esperando!
Turing respondeu:
— Sim.
— Isso não é ruim?
— Não necessariamente.
— Mas eles poderiam estar trabalhando.
— Não.
Turing apontou para o painel:
DB2 POOL......... 72%
CICS............. HEALTHY
API ERRORS....... 0.2%
P95.............. WITHIN SLO
COST/HOUR........ CONTROLLED
— Eles poderiam estar competindo.
Essa é uma diferença importante.
Um sistema saudável não é aquele no qual tudo executa imediatamente.
É aquele no qual o trabalho certo recebe os recursos certos no momento certo, enquanto o restante espera de maneira controlada.
Essa lição existe no mainframe há décadas.
E continuará existindo quando nossos sistemas forem povoados por milhares de agentes.
Porque o problema fundamental nunca foi apenas executar trabalho.
Foi administrar:
DEMANDA
contra:
CAPACIDADE
respeitando:
OBJETIVOS
e:
PRIORIDADES
sem destruir:
CONFIABILIDADE
ou:
ORÇAMENTO.
Turing escreve cinco perguntas no quadro:
RACF
QUEM PODE?
PF3
POSSO PARAR?
SDSF
O QUE ESTÁ FAZENDO?
MAXCC
FUNCIONOU?
WLM
QUEM PASSA PRIMEIRO?
O jovem programador COBOL observa aquilo por alguns segundos.
— Professor...
— Sim?
— Estamos realmente inventando o futuro ou apenas reencontrando problemas antigos em abstrações novas?
Turing sorri.
Talvez essa seja uma das perguntas mais importantes de toda esta série.
A computação muda de linguagem.
Muda de interface.
Muda de hardware.
Muda de arquitetura.
Muda de escala.
Mas determinados problemas permanecem:
identidade,
autoridade,
observabilidade,
prioridade,
recuperação,
capacidade,
controle.
Chamávamos uma unidade de trabalho de:
JOB
Agora podemos chamá-la de:
AGENT RUN
Chamávamos o gerenciamento de recursos de:
WORKLOAD MANAGEMENT
E talvez continuemos chamando exatamente assim.
Porque quando 500 inteligências artificiais levantarem a mão ao mesmo tempo e disserem:
Eu quero trabalhar!
alguém — humano ou software — ainda terá que responder:
Pegue uma senha.
No canto da tela aparece:
AGENT-ARCHIVE
STATE: QUEUED
POSITION: 287
O robô pergunta:
— Quanto tempo?
Turing olha para o WLM.
— Depende da importância do seu trabalho.
O robô cruza os braços.
— Isso é discriminação contra inteligências artificiais.
O operador responde do fundo do CPD:
— Não. É capacity planning.
READY
E havia outros 286 agentes na frente dele.
☕ 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
