✨ 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 apresenta um checklist de RCA para sysprog junior
☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN
Como Evoluir de Apagador de Incêndios para Caçador de Causas Raiz
A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.
Poucos aprendem a impedir que eles aconteçam novamente.
O objetivo deste checklist é desenvolver a mentalidade de investigação que transforma um operador técnico em um verdadeiro engenheiro de confiabilidade.
🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR
Conhecer a arquitetura do ambiente
☐ Entender o fluxo completo da aplicação
☐ Conhecer as LPARs existentes
☐ Entender Sysplex
☐ Conhecer JES2/JES3
☐ Entender CICS
☐ Entender DB2
☐ Entender MQ
☐ Conhecer Storage Management
☐ Entender WLM
☐ Conhecer SDSF profundamente
Objetivo
Parar de enxergar componentes isolados e começar a enxergar o ecossistema.
📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS
Antes de agir:
☐ Registrar horário exato do incidente
☐ Identificar quem reportou
☐ Verificar impacto
☐ Capturar mensagens de erro
☐ Salvar logs
☐ Salvar SYSLOG
☐ Salvar JESMSGLG
☐ Salvar JESJCL
☐ Salvar JESYSMSG
☐ Registrar alterações recentes
☐ Verificar deploys recentes
Regra de ouro
Nunca altere o ambiente antes de coletar evidências.
🔥 NÍVEL 3 — ANÁLISE JES2
☐ Verificar initiators
☐ Verificar classes
☐ Verificar backlog
☐ Verificar spool
☐ Verificar HOLDs
☐ Verificar jobs looping
☐ Verificar jobs aguardando recursos
☐ Verificar ENQ contention
☐ Verificar mensagens $HASP
Pergunta obrigatória
O problema começou no JES2 ou chegou até ele?
💾 NÍVEL 4 — STORAGE E MEMÓRIA
☐ Verificar CSA
☐ Verificar ECSA
☐ Verificar SQA
☐ Verificar ESQA
☐ Verificar Private Area
☐ Procurar storage leaks
☐ Analisar crescimento anormal
☐ Verificar mensagens IEA e IEF
☐ Consultar RMF
Atenção
Muitos "problemas de sistema" são apenas vazamentos de memória.
⚡ NÍVEL 5 — PERFORMANCE
☐ Verificar CPU
☐ Verificar I/O
☐ Verificar Paging
☐ Verificar DASD
☐ Verificar Coupling Facility
☐ Verificar WLM
☐ Verificar gargalos
☐ Comparar com baseline
☐ Analisar tendências
Objetivo
Entender se a degradação é sintoma ou causa.
🖥️ NÍVEL 6 — RCA EM CICS
☐ Verificar transações lentas
☐ Verificar tasks pendentes
☐ Verificar Short On Storage
☐ Verificar TD Queues
☐ Verificar TS Queues
☐ Verificar DB2 Attach
☐ Verificar MQ Attach
☐ Verificar abends
☐ Verificar dumps
☐ Analisar traces
Nunca conclua
"CICS está lento"
sem descobrir:
"POR QUE está lento?"
🗄️ NÍVEL 7 — RCA EM DB2
☐ Verificar deadlocks
☐ Verificar lock escalation
☐ Verificar SQLCODEs
☐ Verificar buffer pools
☐ Verificar índices
☐ Procurar full table scan
☐ Verificar RUNSTATS
☐ Verificar REORG pendente
☐ Verificar crescimento de tabelas
Regra
Muitos problemas de CICS são, na verdade, problemas de DB2.
📬 NÍVEL 8 — RCA EM MQ
☐ Verificar Queue Depth
☐ Verificar canais
☐ Verificar backlog
☐ Verificar consumidores
☐ Verificar produtores
☐ Verificar DLQ
☐ Verificar mensagens presas
☐ Verificar timeouts
Lembre-se
Fila cheia normalmente é consequência.
Raramente é a causa raiz.
📊 NÍVEL 9 — OBSERVABILIDADE
☐ Utilizar OMEGAMON
☐ Utilizar RMF
☐ Utilizar SMF
☐ Utilizar NetView
☐ Utilizar Sysview
☐ Criar dashboards
☐ Definir baseline
☐ Identificar anomalias
☐ Correlacionar eventos
Meta
Parar de reagir.
Começar a prever.
🔎 NÍVEL 10 — TÉCNICAS DE INVESTIGAÇÃO
Five Whys
☐ Aplicar os 5 Porquês
Timeline Analysis
☐ Construir linha do tempo
Event Correlation
☐ Correlacionar eventos
Impact Analysis
☐ Medir impacto real
Trend Analysis
☐ Procurar recorrência
🤖 NÍVEL 11 — AUTOMAÇÃO E PREVENÇÃO
☐ Automatizar alertas
☐ Automatizar coleta de evidências
☐ Automatizar correções simples
☐ Criar scripts REXX
☐ Criar procedimentos de recuperação
☐ Integrar com SA z/OS
☐ Integrar com NetView
☐ Criar runbooks
Objetivo
Não resolver mais rápido.
Resolver menos vezes.
📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO
☐ Manter base de incidentes
☐ Documentar RCA
☐ Criar Wiki interna
☐ Registrar lições aprendidas
☐ Catalogar soluções
☐ Criar biblioteca de dumps
☐ Registrar padrões recorrentes
Ouro do Sysprog
Experiência documentada vale mais que memória.
🧠 NÍVEL 13 — MENTALIDADE DE MESTRE
Antes de qualquer ação pergunte:
☐ O que aconteceu?
☐ Quando aconteceu?
☐ Quem foi impactado?
☐ O que mudou?
☐ Isso já aconteceu antes?
☐ O que os logs mostram?
☐ O que os dados mostram?
☐ Estou tratando sintoma ou causa?
☐ Como impedir recorrência?
☐ O que aprendi hoje?
🏆 CHECKLIST FINAL DO SYSprog MESTRE
Quando um incidente ocorrer:
❌ Não reinicie imediatamente
❌ Não assuma conclusões
❌ Não culpe usuários
❌ Não culpe desenvolvedores
❌ Não culpe infraestrutura
✅ Colete evidências
✅ Analise dados
✅ Correlacione eventos
✅ Pergunte "por quê?"
✅ Encontre a causa raiz
✅ Elimine a recorrência
✅ Documente a descoberta
✅ Compartilhe conhecimento
☕ Regra Suprema do Bellacosa Mainframe
"O Padawan reinicia o CICS.
O Sysprog investiga o dump.
O Mestre encontra a causa raiz.
O Arquiteto faz o problema desaparecer para sempre." 🚀💣🔥
Bellacosa Mainframe e a grande orquestra do IBM Mainframe
☕🖥️ A GRANDE ORQUESTRA DO IBM MAINFRAME — QUEM SÃO OS GUARDIÕES DO DATACENTER MAIS PODEROSO DO MUNDO? 🔥
A imagem mostra algo que muita gente fora do universo mainframe nunca entende direito:
👉 um ambiente IBM Mainframe NÃO funciona apenas com “programadores COBOL”.
Ele é praticamente uma cidade tecnológica viva.
Cada profissional controla uma parte crítica do ecossistema. Quando tudo funciona… ninguém percebe. Quando algo falha… bancos, governos, seguradoras, cartões, aeroportos e bolsas de valores podem literalmente parar.
Vamos entrar no “datacenter secreto” no estilo Bellacosa Mainframe. ☕💾
🧠 VISÃO GERAL DA EQUIPE MAINFRAME
Na prática, um grande ambiente IBM Z possui:
Operadores
SysProg
SysAdmin
Segurança RACF
Redes VTAM/TCPIP
Performance/Capacity
Automação
Gerentes do Computer Center
Desenvolvedores COBOL/PLI/Natural/Assembler
DBA DB2
Storage
Scheduler
Disaster Recovery
Middleware
Cada um possui poderes específicos.
E SIM… há guerras silenciosas entre áreas. 😅
🧑💼 1. COMPUTER CENTER MANAGER
☕ “O Maestro do Datacenter”
É o comandante operacional.
Ele não necessariamente configura tudo… mas coordena TUDO.
🎯 Conhecimento Básico
Precisa entender:
Mainframe architecture
SLA
Incident management
Capacity
Segurança
Auditoria
Gestão de crises
Escala 24x7
ITIL
Continuidade
🔥 Principais Atividades
Coordenar mudanças
Aprovar deploys críticos
Gerenciar incidentes severos
Controlar equipes
Planejar capacidade
Coordenar DRP (Disaster Recovery)
🛠️ Ferramentas
ServiceNow
Control-M
Omegamon
z/OSMF
Jira
CA7
Tivoli
📋 Responsabilidades
Garantir disponibilidade
Evitar indisponibilidade bancária
Controlar janelas batch
Aprovar mudanças críticas
🧨 Easter Egg
Em muitos bancos:
“Se o gerente do datacenter ligar de madrugada… alguém vai perder o sono.”
😅
🤖 2. AUTOMATION ADMINISTRATOR
☕ “O Senhor dos Robôs do z/OS”
Esse cara automatiza o caos.
Sem ele: o operador enlouquece.
🎯 Conhecimento Básico
REXX
NetView
System Automation
OPS/MVS
JES2
Console automation
SDSF
🔥 Principais Atividades
Automatizar mensagens
Reiniciar tasks automaticamente
Monitorar jobs
Criar respostas automáticas
Reduzir intervenção humana
🛠️ Ferramentas
IBM System Automation
CA OPS/MVS
NetView
REXX
SDSF
📋 Exemplo Real
Mensagem:
IEC161I DATA SET FULL
A automação pode:
Detectar erro
Abrir alerta
Alocar novo volume
Reiniciar processo
Avisar operador
Tudo sozinho.
🔥
🧨 Curiosidade
Alguns ambientes possuem:
MAIS DE 100 MIL REGRAS AUTOMÁTICAS
Sim… um “mini cérebro artificial” antes da IA moderna.
👨💻 3. SYSTEM PROGRAMMER (SYSPROG)
☕ “O Feiticeiro Supremo do Mainframe”
Esse é o mago negro do IBM Z.
Pouquíssimas pessoas chegam nesse nível.
🎯 Conhecimento Básico
Precisa dominar:
z/OS
JES2/JES3
IPL
PARMLIB
PROCLIB
VTAM
SMP/E
RACF
Dump analysis
APF
LPA
Catalog
Unix System Services
E muitas vezes: Assembler.
😳
🔥 Principais Atividades
Instalar produtos IBM
Aplicar PTFs
Fazer IPL
Resolver abends sistêmicos
Ajustar performance
Gerenciar subsistemas
🛠️ Ferramentas
SMP/E
IPCS
SDSF
RMF
Omegamon
ISPF
HCD
z/OSMF
📋 Passo a Passo Real — IPL
Cenário:
Atualização crítica do z/OS.
Passos:
Validar PARMLIB
Verificar APF libraries
Aplicar maintenance SMP/E
Fazer backup
Agendar janela
Derrubar subsistemas
Executar IPL
Validar JES2
Subir CICS/DB2
Liberar produção
🧨 Easter Egg SysProg
Os SysProgs antigos dizem:
“Se você nunca derrubou um LPAR em produção… você ainda é júnior.”
💀
🌐 4. NETWORK ADMINISTRATOR
☕ “O Guardião Invisível da VTAM”
Sem rede… o terminal 3270 vira decoração.
🎯 Conhecimento Básico
VTAM
TCP/IP
SNA
OSA
HiperSockets
TN3270
FTP
MQ
🔥 Atividades
Configurar conectividade
Resolver timeout
Ajustar rotas
Integrar distribuído
Configurar criptografia
🛠️ Ferramentas
NETSTAT
VTAM commands
TCPIP stack
Wireshark
Omegamon Network
📋 Exemplo
Usuários não conseguem acessar CICS.
Investigação:
TESTAR TN3270
Verificar VTAM ACTIVE
Validar TCPIP
Conferir porta
Analisar firewall
Validar certificado TLS
🧨 Curiosidade
Muitos ambientes antigos ainda possuem:
SNA rodando em produção em 2026.
SIM. Tecnologia dos anos 70 ainda movendo bilhões.
🔥
🔐 5. SECURITY ADMINISTRATOR
☕ “O Mestre do RACF”
Esse profissional controla: quem pode tocar no quê.
🎯 Conhecimento Básico
RACF
ACF2
TopSecret
SAF
MFA
PassTickets
Digital Certificates
🔥 Atividades
Criar acessos
Auditar usuários
Segregar funções
Investigar violações
Configurar MFA
🛠️ Ferramentas
RACF commands
SMF
zSecure
CARLa
MFA Server
📋 Exemplo Passo a Passo
Novo analista COBOL:
Criar USERID
Associar GROUP
Liberar TSO
Liberar dataset
Liberar CICS
Validar DB2
Ativar MFA
🧨 Easter Egg RACF
O maior medo de um sysprog:
ICH408I USER NOT AUTHORIZED
😅
📊 6. PERFORMANCE/CAPACITY SPECIALIST
☕ “O Economista do Mainframe”
Ele controla: CPU = dinheiro.
🎯 Conhecimento
RMF
SMF
WLM
CPU tuning
IO tuning
Paging
Buffer pools
🔥 Atividades
Analisar gargalos
Planejar crescimento
Ajustar WLM
Reduzir MIPS/MSU
Evitar sobrecarga
🛠️ Ferramentas
RMF
MXG
Omegamon
Mainview
IntelliMagic
📋 Exemplo
Batch noturno atrasou.
Investigação:
CPU saturation?
IO contention?
EXCP elevado?
DB2 lock?
Paging?
Canal congestionado?
🧨 Curiosidade
Em bancos:
1% de otimização
milhões economizados.
💀
🖥️ 7. OPERATOR
☕ “O Piloto da Nave Mainframe”
Muita gente subestima o operador.
ERRO GRAVE.
Ele é quem mantém a operação viva 24x7.
🎯 Conhecimento Básico
JES2
SDSF
Console
Batch
CICS
IPL básico
Recovery
Procedures
🔥 Principais Atividades
Monitorar jobs
Responder mensagens
Controlar spool
Reiniciar tasks
Executar comandos
Acionar suporte
🛠️ Ferramentas
SDSF
HMC
Omegamon
NetView
Console z/OS
📋 Exemplo Real — Job Preso
Situação
Job travado há 4 horas.
Operador faz:
1. Verifica SDSF
ST
DA
QUEUE
2. Analisa mensagem
IEC501A
3. Descobre fita offline
4. Aciona storage
5. Monta volume
6. Responde console
R xx,YES
7. Job continua
🔥
🧨 Easter Egg Operador
Operador veterano consegue:
identificar problema “pelo barulho do console”.
Sim… isso existe. 😅
👨💻 E OS DEVELOPERS?
☕ “Os Arquitetos do Negócio”
Os developers criam:
COBOL
PLI
Assembler
Natural
JCL
CICS
DB2
🎯 Conhecimento
Regras bancárias
Batch
Online
VSAM
SQL
APIs
MQ
Web Services
🔥 Atividades
Criar programas
Corrigir abends
Fazer tuning SQL
Integrar APIs
Modernizar legado
🛠️ Ferramentas
IDz
Endevor
Changeman
File-AID
Abend-AID
DB2 SPUFI
📋 Exemplo Real
PIX falhando.
Developer:
Analisa logs
Verifica MQ
Confere DB2
Debuga COBOL
Ajusta timeout
Faz bind DBRM
Libera produção
💀 A VERDADE QUE NINGUÉM CONTA
No mainframe:
SysProg culpa rede
Rede culpa segurança
Segurança culpa developer
Developer culpa DB2
Operador culpa automação
Automação culpa mensagem IBM
IBM culpa maintenance faltando
😅
☕ O ECOSSISTEMA REAL
Um grande IBM Mainframe pode ter:
milhares de jobs/hora
petabytes
milhões de transações CICS
uptime absurdo
processamento financeiro global
E tudo depende dessa equipe funcionando como uma orquestra.
Bellacosa Mainframe apresenta o CICS Structure Intercomunication
🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR — A VERDADE QUE TODO SYSprog JUNIOR DESCOBRE QUANDO ENTENDE CICS STRUCTURE & INTERCOMMUNICATION 💾🏛️🌐
Durante anos, muita gente ouviu frases como:
“Mainframe é centralizado”
“CICS é legado”
“IBM Z é tecnologia antiga”
“Cloud substituiu o mainframe”
E então o padawan começa a estudar:
🔥 CICS Structure and Intercommunication.
Nesse momento acontece algo curioso.
Ele percebe:
💣 o IBM CICS já fazia computação distribuída enterprise MUITO antes da internet moderna, dos microsserviços, do Kubernetes e da cloud híbrida virarem moda.
E isso muda completamente sua visão sobre o mundo IBM Z.
☕ O ERRO CLÁSSICO DE QUEM ESTÁ COMEÇANDO
O iniciante normalmente imagina o CICS assim:
Usuário → COBOL → VSAM
Algo simples. Linear. Monolítico.
Mas o ambiente enterprise real é mais próximo disso:
🔥 o CICS é um ecossistema distribuído monstruosamente sofisticado.
🏛️ O CICS NÃO É “UM PROGRAMA”
Esse é o primeiro choque.
O CICS moderno:
💣 não é uma única região.
Ele pode possuir:
dezenas de regiões
múltiplos hosts
múltiplas LPARs
workloads distribuídos
failover automático
roteamento dinâmico
Tudo funcionando:
⚡ simultaneamente.
☕ O QUE É UMA REGIÃO CICS?
Uma região CICS:
🔥 é um address space do z/OS.
Ou seja:
possui memória própria
tasks próprias
recursos próprios
controle próprio
E roda:
💾 como Started Task ou Batch Job.
☕ O SYSprog JUNIOR DESCOBRE UMA VERDADE IMPORTANTE
O CICS:
❌ não é o sistema operacional.
Ele roda:
🏛️ SOBRE o z/OS.
Assim como:
Db2
MQ
JES2
VTAM
TCP/IP
💾 O CICS É “APENAS” MAIS UM WORKLOAD DO z/OS
Só que esse “workload”:
💣 movimenta o planeta financeiro.
🔥 TOR, AOR E FOR — A SEPARAÇÃO QUE MUDOU TUDO
Aqui começa a engenharia enterprise de verdade.
☕ TOR — TERMINAL OWNING REGION
Responsável por:
receber conexões
controlar sessões
entrada de usuários
roteamento
O TOR funciona como:
🚦 controlador de tráfego.
☕ AOR — APPLICATION OWNING REGION
Aqui mora:
COBOL
regras de negócio
Db2
MQ
VSAM
O AOR:
⚡ executa o trabalho pesado.
☕ FOR — FILE OWNING REGION
Especializada em:
VSAM
locking
controle de arquivos
integridade
💣 ISSO É GENIAL
Porque:
workload pode ser distribuído
funções podem ser separadas
gargalos podem ser evitados
escalabilidade aumenta absurdamente
🌐 MRO — O “SERVICE MESH INVISÍVEL” DO CICS
Quando o padawan aprende MRO:
🔥 sua mente explode.
☕ O QUE É MRO?
🌐 Multiregion Operation
Permite:
comunicação entre regiões CICS
dentro do mesmo z/OS
ou dentro do mesmo Sysplex
💾 O MAIS IMPRESSIONANTE
O MRO usa:
⚡ IRC — Interregion Communication.
☕ O IRC É A JOIA ESCONDIDA DO CICS
Porque:
comunicação é interna
não precisa TCP/IP
não precisa SNA
não precisa VTAM
💣 RESULTADO?
✅ baixa latência
✅ throughput monstruoso
✅ comunicação ultra rápida
✅ escalabilidade massiva
☕ O MRO É BASICAMENTE:
🔥 um “service bus interno” criado décadas antes da cloud moderna.
🌎 ISC — QUANDO O CICS APRENDEU A FALAR COM O MUNDO
Depois vem:
🌐 ISC — Intersystem Communication.
☕ O ISC CONECTA:
hosts diferentes
sistemas remotos
datacenters
ambientes distribuídos
Usando:
🔥 SNA / APPC / LU6.2
💾 ISSO ERA A “INTERNET IBM”
Muito antes:
APIs REST
HTTP moderno
cloud hybrid
☕ O ISC PERMITIU:
✅ ATMs nacionais
✅ agências distribuídas
✅ bancos globais
✅ processamento remoto
✅ integração CICS ↔ IMS
💣 COMPUTAÇÃO DISTRIBUÍDA REAL
Nos anos 80 e 90. Quando muita gente ainda nem entendia redes corporativas direito.
🌐 IPIC — O CICS ENTRA NA ERA TCP/IP
O mundo mudou. O TCP/IP venceu. E o CICS evoluiu.
Nasce:
🔥 IPIC — IP Interconnectivity.
☕ AGORA O CICS CONVERSA VIA:
✅ TCP/IP
✅ APIs
✅ Linux
✅ OpenShift
✅ cloud
✅ microsserviços
💾 O CICS NÃO MORREU
Ele:
⚡ se modernizou.
🌉 CICS TRANSACTION GATEWAY — A PONTE ENTRE O PASSADO E O FUTURO
Agora entra:
🔥 CTG — CICS Transaction Gateway.
☕ O CTG É O “TRADUTOR”
Entre:
Java
.NET
aplicações web
APIs REST
e:
💾 o mundo CICS/COBOL.
☕ FLUXO MODERNO REAL
App Mobile
↓
API REST
↓
Java Spring
↓
CTG
↓
CICS
↓
COBOL
↓
Db2
💣 O USUÁRIO NÃO FAZ IDEIA
Que:
um COBOL de décadas atrás
respondeu sua operação bancária em milissegundos.
🏛️ CICSPLEX — O “KUBERNETES” QUE EXISTIA ANTES DO KUBERNETES
Quando o ambiente cresce absurdamente:
dezenas de regiões
múltiplos hosts
milhões de transações
entra:
🌐 CICSPlex.
☕ O CICSPLEX TRANSFORMA:
Múltiplos CICS:
⚡ em um único ambiente lógico.
💾 O CPSM FAZ:
✅ workload balancing
✅ failover
✅ gerenciamento centralizado
✅ roteamento dinâmico
✅ monitoramento
💣 ISSO É ORQUESTRAÇÃO ENTERPRISE
Muito antes:
Kubernetes
OpenShift
cloud orchestration
☕ O SYSprog JUNIOR COMEÇA A ENTENDER
Que o IBM Z:
❌ nunca foi “parado no tempo”.
Na verdade:
🔥 ele estava anos à frente.
🌐 O CICS JÁ FAZIA:
✅ clusterização
✅ workload balancing
✅ comunicação distribuída
✅ middleware enterprise
✅ failover automático
✅ integração híbrida
✅ service orchestration
✅ APIs corporativas
Décadas antes:
da cloud moderna
dos microsserviços
do service mesh
do Kubernetes
💾 O GRANDE SEGREDO DO MAINFRAME
O mundo moderno reinventou conceitos que:
🏛️ o IBM Z já dominava há décadas.
☕ ENQUANTO MUITOS SISTEMAS MODERNOS:
quebram facilmente
perdem consistência
sofrem downtime
escalam mal
O CICS continua:
⚡ processando bilhões de transações silenciosamente.
💣 O PADAWAN FINALMENTE ENTENDE
O CICS:
❌ não é apenas EXEC CICS SEND MAP.
Ele é:
🌐 uma plataforma transacional distribuída de missão crítica.
🏛️ CONCLUSÃO BELLACOSA MAINFRAME™
Quando um sysprog junior realmente entende:
MRO
IRC
ISC
IPIC
CTG
CICSPlex
regiões CICS
ele percebe algo impressionante:
🔥 o mainframe nunca ficou para trás.
Na verdade:
💾 o restante da indústria passou décadas tentando reinventar conceitos que o IBM Z já utilizava silenciosamente desde muito antes da explosão da computação cloud moderna.
Quando um Programador Embarca no Seaview e Descobre que o Verdadeiro Monstro do Oceano Não é um Polvo Gigante... É uma Anomalia de Performance Escondida Entre Milhões de Métricas
"Profundidade: 8.000 metros."
"Pressão externa: centenas de atmosferas."
"Silêncio absoluto."
No fundo do oceano não existe espaço para improvisação.
Não existe Ctrl+C.
Não existe reboot.
Não existe "vamos tentar novamente amanhã".
Uma pequena falha...
...e toda a missão termina.
Curiosamente, é exatamente assim que funciona um IBM Z.
Enquanto milhões de pessoas compram, transferem dinheiro, usam cartões, fazem PIX, reservam passagens e movimentam bolsas de valores, o mainframe continua trabalhando silenciosamente nas profundezas da infraestrutura mundial.
É justamente aí que nasce o universo do AIOps, do Performance Management e do Capacity Planning.
Prepare seu uniforme da Marinha Nelson Institute, embarque no USS Seaview, comandado pelo Almirante Harriman Nelson e pelo Capitão Lee Crane, porque hoje faremos uma viagem ao fundo do mar... das métricas do IBM Z.
Capítulo 1 — O Oceano Invisível do Mainframe
Todo iniciante imagina que um computador executa apenas programas.
Na realidade, um IBM Z executa milhares de atividades simultaneamente.
Enquanto seu programa COBOL faz um simples:
READ CLIENTES
o sistema inteiro está trabalhando.
Nos bastidores existem:
Dispatcher
PR/SM
WLM
zIIP
RMF
SMF
CICS
Db2
MQ
JES2
VSAM
RACF
DFSMS
Coupling Facility
IOS
Channel Subsystem
Todos gerando estatísticas.
Imagine centenas de sensores espalhados pelo casco do Seaview.
Cada sensor mede:
pressão
temperatura
velocidade
combustível
profundidade
oxigênio
consumo elétrico
Agora multiplique isso por dezenas de milhares.
É isso que o IBM Z mede continuamente.
Easter Egg nº 1
Na série Viagem ao Fundo do Mar, o Seaview parecia navegar calmamente.
Mas na sala de máquinas havia dezenas de oficiais monitorando centenas de instrumentos.
No IBM Z acontece exatamente o mesmo.
Você vê apenas uma tela 3270.
Por trás dela existe um oceano inteiro de telemetria.
Capítulo 2 — O erro que muita gente está cometendo
Com a chegada dos LLMs surgiu uma ideia perigosa.
"Agora basta perguntar para uma IA."
Será?
Imagine entrar no Seaview e perguntar:
— IA, estamos seguros?
Resposta:
— Sim.
Fim.
Mas...
E se existir uma microfissura no casco?
E se um sonar estiver apresentando ruído?
E se uma bomba hidráulica estiver começando a vibrar?
A IA respondeu.
Mas não analisou.
Essa é exatamente a diferença entre um chatbot e uma plataforma especializada como o IBM Z IntelliMagic Vision.
Informação não é conhecimento
Uma IA pode responder:
"A CPU está em 82%."
Ótimo.
Mas isso é bom?
Ruim?
Esperado?
Anormal?
Ela não sabe.
Porque falta contexto.
O especialista pergunta:
qual CPC?
qual LPAR?
qual horário?
qual workload?
qual Service Class?
qual política WLM?
houve IPL?
mudou o firmware?
houve novo package Db2?
apareceu nova aplicação Java?
aumentou MQ?
mudou o peso PR/SM?
É outro nível de investigação.
Capítulo 3 — O verdadeiro tesouro do oceano chama-se SMF
Poucos iniciantes conhecem o SMF.
Mas ele talvez seja o recurso mais valioso do z/OS.
SMF significa:
System Management Facility
Pense nele como o diário de bordo do Seaview.
Tudo é registrado.
Tudo.
Quem usou CPU.
Quem fez I/O.
Quem abriu datasets.
Quem executou CICS.
Quem acessou Db2.
Quem consumiu zIIP.
Quem gerou paging.
Quem alterou configuração.
Décadas de história ficam registradas.
Sem SMF...
não existe análise histórica.
Curiosidade
Muitas empresas possuem anos de dados SMF armazenados.
Algumas conseguem comparar o comportamento atual com períodos de cinco ou dez anos atrás.
É como comparar uma expedição submarina atual com os registros originais do Almirante Nelson.
Capítulo 4 — Uma imagem vale mais que mil RMFs
O artigo comenta algo extremamente importante.
Uma figura vale mais que mil palavras.
Observe mentalmente a topologia apresentada.
Diversos:
CPC
↓
LPARs
↓
Sysplex
Tudo conectado.
Em segundos o especialista entende:
Quem pertence a quem.
Quem compartilha recursos.
Quem faz parte do mesmo Sysplex.
Quem utiliza determinado processador.
Nenhum texto consegue transmitir isso tão rapidamente.
Easter Egg nº 2
No Seaview existia uma enorme mesa de navegação.
Ninguém decorava o oceano.
Eles olhavam o mapa.
O IntelliMagic faz exatamente isso.
Ele desenha o mapa do seu mainframe.
Capítulo 5 — O poder do Change Detection
Imagine esta situação.
Segunda-feira:
Tudo perfeito.
Terça-feira:
Usuários reclamando.
O que mudou?
Essa pergunta pode consumir dias de investigação.
Mas o IntelliMagic compara automaticamente períodos diferentes.
Ele verifica:
CPU
zIIP
Dispatch Time
Busy
Eligible Work
Utilização
Tendências
Desvios
Não apenas mostra valores.
Mostra mudanças.
E mais importante...
Mostra mudanças relevantes.
O segredo do desvio padrão
Imagine um sonar.
O ruído normal fica entre:
10 e 15 decibéis.
Hoje apareceu:
Nada mudou.
Agora imagine:
Tem algo enorme vindo na direção do submarino.
Foi isso que o desvio padrão detectou.
Mudanças realmente fora do comportamento esperado.
Não basta aumentar.
Precisa aumentar de forma estatisticamente significativa.
Capítulo 6 — Health Rating
Talvez a funcionalidade mais fascinante.
Imagine o painel do Seaview.
Luzes verdes.
Luzes amarelas.
Luzes vermelhas.
Você não precisa ler milhares de sensores.
Basta olhar o painel.
No IntelliMagic ocorre exatamente isso.
Cada sistema recebe indicadores como:
Dispatch Time
MVS Busy
LPAR Busy
zIIP
IOSQ
Pending
Connect
Interrupt
Page-ins
Em poucos segundos o especialista sabe onde investigar primeiro.
Dica Bellacosa
Nunca olhe apenas um indicador.
Performance é correlação.
CPU alta pode ser consequência.
Não a causa.
Capítulo 7 — Tendência vale mais que fotografia
Uma fotografia mostra um instante.
Um gráfico mostra uma história.
É por isso que Capacity Planning utiliza séries históricas.
Não interessa apenas saber:
Hoje = 70%.
Interessa descobrir:
Janeiro:
65%
Fevereiro:
67%
Março:
69%
Abril:
72%
Maio:
75%
Junho:
78%
Agora existe uma tendência.
Sem histórico...
não existe previsão.
Capítulo 8 — Capacity Planning
Aqui muitos iniciantes cometem outro erro.
Pensam:
Capacity Planning = CPU.
Não.
CPU é apenas uma peça.
O especialista observa:
CPU
↓
Memória
↓
I/O
↓
Storage
↓
Channels
↓
Paging
↓
Network
↓
zIIP
↓
MSU
↓
Software
↓
CICS
↓
Db2
↓
MQ
↓
IMS
↓
Batch
↓
Online
↓
WLM
Tudo ao mesmo tempo.
Porque gargalos raramente aparecem isolados.
Curiosidade
Em muitos ambientes o problema nunca foi CPU.
Foi um único volume DASD saturado.
Ou uma fila MQ crescendo.
Ou uma política WLM mal definida.
Ou uma consulta SQL sem índice.
Capítulo 9 — O verdadeiro papel do especialista
O artigo fala algo maravilhoso.
O maior problema não é coletar dados.
É interpretá-los.
Hoje qualquer ferramenta coleta milhões de métricas.
Mas poucas conseguem responder:
O que realmente importa?
Imagine o Seaview.
Existem dez mil instrumentos.
Mas apenas um oficial experiente percebe que pequenas vibrações significam falha futura.
É exatamente isso que faz um especialista em performance.
Capítulo 10 — Explainability
Uma IA responde.
O especialista explica.
Existe enorme diferença.
Imagine um diretor perguntando:
"Por que precisamos comprar outro CPC?"
Você responde:
"Porque a IA sugeriu."
A reunião termina.
Agora imagine responder:
crescimento médio de 18% ao ano;
tendência confirmada em 36 meses;
workloads Batch crescendo;
consumo zIIP estabilizado;
pico de MSU chegando ao limite contratual;
risco para SLA da aplicação bancária;
previsão estatística de saturação em oito meses.
Agora existe evidência.
Easter Egg nº 3
No Seaview, o Almirante Nelson nunca dizia apenas:
"Vamos mergulhar."
Ele mostrava:
cartas náuticas;
sonar;
profundidade;
corrente marítima;
combustível;
pressão.
Isso é explainability.
Capítulo 11 — IA não substitui Analytics
Esse talvez seja o maior ensinamento do artigo.
A IA facilita perguntas.
O IntelliMagic produz respostas confiáveis.
Pense assim.
ChatGPT é como um excelente oficial de comunicações.
Ele conversa.
Resume.
Explica.
O IntelliMagic é o centro de controle do submarino.
Mas por trás dela existe um motor especializado analisando:
milhares de métricas;
estatísticas;
tendências;
Health Insights;
correlações;
previsões.
É exatamente essa união que o artigo chama de:
AI + Analytics.
Curiosidades Bellacosa
✅ Um único IBM Z pode produzir milhões de registros SMF por dia.
✅ O WLM ajusta prioridades automaticamente centenas de vezes por segundo para manter os objetivos de serviço.
✅ O zIIP pode descarregar grande parte do processamento elegível de Db2, XML, Java, criptografia e workloads analíticos, reduzindo custos de software em muitos cenários.
✅ Um problema aparentemente "de CPU" pode, na verdade, ser consequência de filas de I/O, contenção em locks Db2, espera por MQ ou políticas WLM inadequadas.
✅ Ferramentas como o IBM Z IntelliMagic Vision incorporam décadas de conhecimento de especialistas em performance, automatizando análises que antes exigiam anos de experiência.
Conclusão — A Verdadeira Viagem ao Fundo do Mar
Ao final da missão, o USS Seaview emerge lentamente das profundezas. A tripulação sobreviveu não porque tinha o sonar mais bonito ou o rádio mais moderno, mas porque soube interpretar corretamente cada sinal vindo do oceano.
No IBM Z acontece exatamente o mesmo.
Os gráficos, mapas de Sysplex, indicadores de saúde, detecção automática de mudanças e análises históricas são os "sonares" do mundo corporativo. Eles transformam bilhões de amostras de desempenho em conhecimento acionável.
A IA generativa representa o novo oficial de comunicações: traduz perguntas complexas para linguagem natural, resume informações e acelera o acesso ao conhecimento. Já plataformas como o IBM Z IntelliMagic Vision são o cérebro analítico do navio, capazes de correlacionar milhares de métricas, detectar riscos antes que se tornem incidentes e justificar cada conclusão com evidências.
Para o programador COBOL iniciante, a maior lição é simples: escrever um bom programa não significa apenas fazer a lógica funcionar. Significa entender como esse programa consome CPU, acessa VSAM e Db2, utiliza CICS, aproveita zIIP, respeita as metas do WLM e influencia todo o ecossistema do mainframe.
No universo Bellacosa Mainframe, o código é apenas a ponta do iceberg.
A verdadeira aventura começa quando você aprende a enxergar o oceano invisível que existe sob cada EXEC CICS, cada SELECT no Db2, cada mensagem no MQ e cada READ em um dataset. É nesse oceano que vivem os maiores desafios da engenharia de performance — e também onde se encontram os maiores tesouros de conhecimento para quem deseja se tornar um verdadeiro Mestre Jedi do Mainframe.
Bellacosa Mainframe analisando a performance mainframe
☕ Um Café no Bellacosa Mainframe
Hércule Poirot Entra no CPD — O Caso do Sistema que Estava Verde, Mas Já Estava Morto por Dentro
Ou: por que latência, erros, CPU, filas, Db2, MQ e I/O não são uma coleção de números — são as pequenas células cinzentas que impedem o SEV-1 antes do café esfriar
Há uma cena recorrente em tecnologia que faria Hércule Poirot ajustar o bigode, olhar para o dashboard e dizer, com delicada indignação belga: “Mon ami, todos os suspeitos têm álibi. E, ainda assim, a folha de pagamento não foi processada.”
O painel está verde. CPU em 38%. Memória em 61%. Banco “UP”. Rede “normal”. Ninguém abriu chamado de infraestrutura. Mas o usuário está esperando oito segundos para consultar o saldo, o atendente do call center aperta Enter pela terceira vez, a fila do IBM MQ cresce como lista de compras em véspera de feriado e o batch que terminava às 5h ainda está conversando com o DASD às 8h12.
Essa é a verdade incômoda do monitoramento: sistemas raramente deixam de funcionar como uma lâmpada que apaga. Eles se deterioram em sinais pequenos, correlacionados e, muitas vezes, educados demais para disparar um alarme simples. Primeiro uma consulta Db2 demora um pouco mais. Depois o pool de conexões fica ocupado. Em seguida, a aplicação segura as requisições por mais tempo. As filas crescem. Os timeouts começam. Os usuários tentam de novo. O volume aumenta artificialmente. A CPU finalmente sobe. Quando alguém percebe, o incidente já não é técnico: virou negócio, reputação e reunião de diretoria.
Para um programador COBOL iniciante, a mensagem mais importante é esta: monitoramento não é assunto exclusivo do “pessoal de infraestrutura”. Quando seu programa faz um EXEC SQL, grava uma mensagem MQ, chama uma transação CICS, lê um VSAM ou recebe um arquivo de entrada, ele passa a fazer parte da história operacional do sistema. O código pode compilar lindamente e ainda assim criar um gargalo capaz de transformar uma terça-feira comum num episódio de investigação criminal.
Prólogo — Poirot não procura números; ele procura a verdade
Métricas são medições. Observabilidade é a capacidade de explicar o que está acontecendo a partir dos efeitos que o sistema produz. Monitoramento é a prática de acompanhar esses sinais e agir a tempo.
Parece uma diferença de dicionário, mas não é. Um dashboard que exibe 250 gráficos pode ser menos útil do que uma única pergunta bem formulada:
A transação importante para o usuário está concluindo corretamente, dentro do tempo prometido?
Imagine uma aplicação bancária. A CPU pode estar baixa. O CICS pode estar ativo. O Db2 pode responder ao comando de health check. Porém, se a operação de transferência demora 20 segundos e 4% delas terminam em timeout, o serviço não está saudável para quem precisa pagar uma conta. Ele está apenas respirando com aparelhos ligados.
Poirot não ficaria satisfeito com “o servidor está no ar”. Ele perguntaria: “No ar para quem? Fazendo o quê? Em quanto tempo? Com qual taxa de sucesso? E o que mudou antes de Madame Latência começar a gritar?”
1. Latência — a primeira testemunha costuma ser o relógio
Latência é o tempo gasto entre um pedido e uma resposta útil. Em aplicações web é o tempo da requisição. Em CICS, pode ser o tempo percebido pelo usuário na transação. Em batch, pode ser o tempo de execução de uma etapa. Em MQ, pode ser o intervalo entre a mensagem entrar na fila e ser efetivamente consumida.
Ela é uma das melhores primeiras pistas porque o usuário sente demora antes de entender qualquer outra coisa. Usuário não abre RMF, não consulta SMF e não discute buffer pool. Usuário diz: “Está lento.” E frequentemente está certo.
Há uma armadilha: não confie apenas na média. Se 95 consultas respondem em 200 milissegundos e cinco levam 20 segundos, a média pode até parecer elegante num PowerPoint. Mas aquelas cinco pessoas vivem a versão completa do desastre.
Por isso usamos percentis:
p50: o comportamento típico, a mediana;
p95: a experiência dos 5% mais lentos;
p99: a cauda ruim, onde se escondem timeouts e casos críticos.
Em um ambiente COBOL/Db2, uma tela pode permanecer rápida para quase todos, enquanto um tipo específico de cliente dispara uma consulta com critério pouco seletivo. É o equivalente técnico de descobrir que todas as vítimas tomaram chá, mas apenas uma escolheu a xícara errada.
Dica prática: defina um objetivo de serviço, ou SLO. Por exemplo: “99,9% das consultas de saldo devem terminar com sucesso em até 1 segundo.” Agora a conversa deixa de ser “parece lento” e passa a ser verificável.
2. Taxa de erros — quando o sistema deixa evidência no local do crime
Taxa de erros mede falhas explícitas: HTTP 500, timeout, abend, autenticação rejeitada, mensagem devolvida, SQLCODE negativo, transação com rollback ou job encerrado com RC maior que o permitido.
Mas nem todo erro é o mesmo crime. Um 404 causado por URL digitada errada é bem diferente de uma transferência financeira que retorna 500. Um SQLCODE -100 pode ser resultado esperado — nenhum registro encontrado. Já um SQLCODE -911 pode indicar deadlock ou timeout; aí Poirot põe a mão no queixo, porque duas transações disputando recursos contam uma história bem mais interessante.
Um iniciante em COBOL deve aprender desde cedo a tratar retorno e contexto, não apenas “seguir em frente” depois do comando:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTE
WHERE CPF = :WS-CPF
END-EXEC
EVALUATE SQLCODE
WHEN 0
CONTINUE
WHEN 100
MOVE 'CLIENTE NAO ENCONTRADO' TO WS-MENSAGEM
WHEN OTHER
PERFORM REGISTRA-ERRO-DB2
MOVE 'FALHA TEMPORARIA' TO WS-MENSAGEM
END-EVALUATE.
O detalhe operacional é essencial: registre a falha com identificador da transação, programa, operação e correlação da requisição. Um log dizendo apenas “erro no banco” é tão útil quanto uma testemunha dizendo “vi alguém de chapéu”.
3. Throughput — muito trabalho pode ser sucesso ou pânico
Throughput é volume processado por unidade de tempo: transações por segundo, requisições por minuto, mensagens consumidas, registros lidos, documentos emitidos ou pagamentos autorizados.
Um aumento de throughput pode significar uma campanha bem-sucedida. Mas também pode significar que usuários estão repetindo cliques porque nada responde, que uma integração entrou em loop de retry ou que um lote foi reenviado três vezes.
Esse último caso é uma bela curiosidade de CPD: às vezes o sistema não está recebendo mais trabalho real; está recebendo o mesmo trabalho, repetido por ansiedade humana ou erro de software. É o “efeito elevador”: o botão não respondeu, então alguém apertou cinco vezes. Em sistemas distribuídos, cada tentativa pode abrir conexão, chamar serviço, consultar Db2 e colocar mensagem na fila. A consequência é um aumento de carga que agrava exatamente a lentidão que motivou o novo clique.
Compare sempre throughput com latência, erro e filas. Mais transações com latência estável e erro baixo é capacidade. Mais transações com demora, falhas e acúmulo é saturação disfarçada de sucesso.
4. CPU — o suspeito famoso, mas raramente o único culpado
CPU é a métrica mais vista porque é intuitiva. Uso alto pode apontar carga legítima, loop, compressão, criptografia, serialização, processamento excessivo ou necessidade de capacidade adicional.
Mas CPU baixa não inocenta o sistema. Uma transação bloqueada esperando I/O, lock Db2, resposta de rede ou disponibilidade de conexão pode consumir pouca CPU e, ainda assim, fazer o usuário envelhecer diante da tela.
No z/OS, a investigação é ainda mais refinada. Não basta perguntar “quanto de CPU?”; é preciso considerar CP, zIIP, WLM, prioridade da service class, dispatching delay e a diferença entre usar CPU e esperar para receber CPU. Um workload pode ter sido classificado com importância inadequada, enquanto outro, menos importante, ganha a pista de corrida.
Para o programador COBOL, a lição é humilde e poderosa: antes de concluir que falta máquina, procure trabalho desperdiçado. Um PERFORM mal controlado, uma busca sequencial onde seria possível indexação, conversões repetidas, leitura desnecessária de registros e chamadas redundantes fazem muito barulho quando multiplicadas por milhões.
5. Memória — o vazamento começa como gota e termina como enchente
Memória é a capacidade de manter dados e execução disponíveis sem recorrer excessivamente a paginação, swap ou reinicializações. Vazamentos de memória são particularmente traiçoeiros: a aplicação funciona após o deploy, passa nos testes, opera por algumas horas e, aos poucos, cresce até transformar manutenção de rotina em madrugada de guerra.
Em plataformas distribuídas, procure crescimento contínuo, garbage collection cada vez mais frequente, pausas longas e processos mortos por falta de memória. Em ambiente mainframe, o vocabulário varia — regiões CICS, storage, address spaces, limites e pressão de recursos — mas o princípio é o mesmo: consumo que sobe sem retornar ao patamar normal merece investigação.
Muitos incidentes não são causados por “falta de memória” em sentido absoluto. São causados por fragmentação, limites por processo, vazamento de conexões ou uma aplicação mantendo objetos que deveriam ter sido liberados. O grande crime pode estar numa pequena referência esquecida.
6. Disco e I/O — o porão escuro onde o gargalo se esconde
CPU de 20%, memória tranquila e aplicação lenta: este é o momento de olhar para I/O. A aplicação talvez não esteja calculando; talvez esteja esperando leitura, escrita, flush de log ou páginas do banco.
No mundo Db2, uma consulta aparentemente simples pode fazer centenas de milhares de leituras se o access path for ruim. No VSAM, uma rotina pode transformar acesso direto em leitura sequencial involuntária. No batch, um arquivo enorme pode competir por recursos em um horário já pressionado.
Monitore latência de leitura e escrita, IOPS, fila de I/O, tempo de resposta de volumes, espaço disponível e waits. No z/OS, RMF, SMF, OMEGAMON, SYSVIEW e ferramentas equivalentes ajudam a separar “meu programa está lento” de “meu programa está à espera do storage”.
Eis uma regra de investigação: se alguém sugere comprar mais CPU antes de examinar I/O e SQL, Poirot recomenda cautela. Pode ser como aumentar a potência do carro quando ele está parado numa fila de pedágio.
7. Latência de rede — toda dependência distante aumenta a fragilidade
Uma transação moderna pode atravessar API Gateway, autenticação, microsserviço, cache, serviço externo, MQ, CICS, Db2 e retornar. Cada salto é uma chance adicional de atraso, falha ou timeout.
Não reduza rede a um teste de ping. Há DNS lento, perda de pacotes, handshake TLS, proxy saturado, pool de conexões esgotado, firewall, rota alterada e API de terceiro que decidiu fazer manutenção sem avisar. A parte local pode estar perfeita; a chamada externa pode ser o veneno no chá.
O remédio é rastreamento distribuído: um identificador de correlação que acompanha a requisição. Assim, em vez de saber apenas que a operação demorou oito segundos, você descobre que gastou 200 ms no gateway, 300 ms no CICS, 6,7 s esperando a API externa e 800 ms no Db2.
8. Profundidade de fila — a confissão silenciosa do sistema assíncrono
Fila é uma promessa: “não processei agora, mas processarei daqui a pouco”. IBM MQ é excelente nisso. Ele desacopla produtor e consumidor, absorve picos e protege aplicações. Mas fila crescendo sem parar é a prova de que a entrada é maior que a saída.
Não observe só quantas mensagens existem. Observe também:
taxa de entrada versus taxa de consumo;
idade da mensagem mais antiga;
quantidade de consumidores ativos;
retries e mensagens em dead-letter queue;
tempo total até a conclusão do negócio.
Uma fila com 100 mil mensagens pode ser normal numa madrugada de processamento massivo. Uma fila com 200 mensagens pode ser gravíssima se costumava ficar zerada e cada uma corresponde a uma autorização de cartão. Contexto, como sempre, é a pequena célula cinzenta que separa análise de decoração.
9. Cache hit rate — velocidade emprestada precisa ser devolvida com correção
Cache evita consultas caras. Quando há hit, o dado já está disponível; quando há miss, a aplicação precisa buscar no banco, no disco ou num serviço remoto. Taxa de acerto baixa pode despejar carga sobre o Db2 e iniciar uma cascata: mais leitura, mais I/O, mais latência, mais timeouts e mais retries.
Porém, uma taxa alta não é absolvição. Cache pode entregar dado velho. Em sistemas de saldo, estoque, preço ou autorização, velocidade sem consistência é apenas um erro muito rápido.
Defina claramente o que pode ser armazenado, por quanto tempo, como invalidar e o que fazer em caso de falha. Nem tudo merece cache; alguns dados existem exatamente para serem consultados em sua forma mais atual.
10. Tempo de consulta Db2 — o mordomo quase sempre tem um índice
Há uma piada de veterano: quando uma aplicação está lenta, a culpa é da rede; quando a rede está boa, a culpa é do servidor; quando o servidor está bom, alguém finalmente abre o EXPLAIN.
Consultas ao banco são causas clássicas de degradação escondida. Meça duração, volume de execuções, linhas lidas versus retornadas, uso de índices, locks, deadlocks, tempo de commit e plano de acesso. Uma query de dois segundos rodando uma vez pode ser tolerável. A mesma query executada vinte mil vezes por minuto é um pedido formal de incidente.
Para quem começa em COBOL com Db2, três hábitos evitam boa parte dos crimes:
Não use SELECT * se precisa de duas colunas.
Conheça as colunas de filtro e os índices disponíveis.
Verifique o plano de acesso quando o volume real crescer.
Também cuide das estatísticas. Um otimizador decide com base no que sabe. Se as estatísticas não representam mais a tabela, ele pode escolher um caminho que parece excelente no papel e péssimo no DASD.
O método Poirot: um passo a passo para investigar degradação
Quando o alerta tocar, resista à tentação de acusar o primeiro gráfico vermelho. Siga um roteiro.
Primeiro: confirme o impacto. Qual jornada foi afetada? Login, pagamento, consulta, emissão, batch, integração? Quem sente: todos, uma região, um cliente, uma versão?
Segundo: determine quando começou. Houve deploy, alteração de parâmetro, pico de tráfego, janela de batch, mudança de certificado, atualização de tabela, campanha comercial ou falha externa?
Terceiro: compare sinais. A latência subiu antes dos erros? A fila cresceu antes da CPU? O Db2 ficou lento antes da aplicação esgotar conexões? A sequência importa: ela é a linha do tempo do crime.
Quarto: encontre o gargalo, não o sintoma. Aumentar instâncias pode piorar uma base já sobrecarregada. Reiniciar consumidor pode gerar uma tempestade de reprocessamento. Escalar CPU não cura lock Db2.
Quinto: reduza o impacto. Limite tráfego, faça rollback de mudança, ative modo degradado, aumente consumidores com cuidado, interrompa batch concorrente ou desabilite uma função não essencial.
Sexto: registre o caso. Depois do incidente, documente causa, sinais iniciais, decisão tomada, impacto, correção e alerta preventivo. O objetivo não é achar um culpado humano; é fazer o sistema ensinar a própria equipe.
O dashboard que vale alguma coisa
O painel deve começar pelo negócio, não pelo hardware. Coloque no topo as transações críticas, taxa de sucesso, latência p95/p99 e orçamento de erro. Depois, use CPU, memória, I/O, rede, cache, fila e banco como trilha de investigação.
Uma estrutura simples e poderosa é observar quatro sinais de ouro:
latência: está demorando?
tráfego: quanto trabalho chegou?
erros: está falhando?
saturação: qual recurso chegou ao limite?
Os dez sinais do infográfico aprofundam essa estrutura. Eles não competem entre si; conversam entre si.
Epílogo — o sinal em que se deve confiar
Se Poirot tivesse de escolher apenas um sinal para decisão em produção, ele provavelmente escolheria um SLO ligado à experiência da transação crítica: sucesso dentro de um tempo aceitável. CPU, memória, rede, disco, Db2 e fila são fundamentais para encontrar a causa. Mas o usuário não compra CPU. Ele compra o resultado.
Portanto, a melhor métrica não é “CPU abaixo de 80%”. É algo como: “99,9% das transferências devem concluir corretamente em até dois segundos.” Essa promessa pode ser medida, defendida e investigada.
No fim, monitorar é isso: notar o aumento discreto da latência antes de virar timeout; perceber a fila antes de virar backlog; encontrar a query antes de ela virar indisponibilidade; ouvir os sinais antes que o CPD inteiro grite.
E quando alguém disser que está tudo verde, mas o cliente está esperando, ajuste o bigode imaginário e responda: “Então, mon ami, talvez devêssemos investigar o que esses verdes estão deixando de contar.”
01 CLIENTE.
05 DADOS.
10 NOME PIC X(30).
10 CIDADE PIC X(20).
Valores opcionais
Nem sempre todos os campos existirão.
Exemplo
{
"nome":"Pedro"
}
Sem idade.
Sem saldo.
Os campos COBOL permanecerão com seus valores iniciais (SPACES, ZEROS ou VALUE), por isso é importante inicializar a estrutura antes do JSON PARSE, geralmente com:
INITIALIZE WS-CLIENTE
Campos numéricos
Muito cuidado.
JSON
"idade":"ABC"
Jamais poderá alimentar
PIC 999
O parser gerará exceção.
Decimais
JSON
123.45
COBOL
PIC 9(5)V99
O ponto decimal é interpretado automaticamente conforme as regras do compilador e da representação numérica.
Booleanos
JSON
true
false
COBOL não possui um tipo booleano tradicional.
Uma prática comum é utilizar:
05 ATIVO PIC X.
88 CLIENTE-ATIVO VALUE "S".
88 CLIENTE-INATIVO VALUE "N".
Ou mapear para indicadores específicos conforme o padrão da aplicação.
Controle de tamanho
Um erro comum dos iniciantes.
Criar
PIC X(100)
para um JSON de
500 caracteres.
Resultado?
Truncamento.
Sempre dimensione com folga ou utilize áreas compatíveis com o tamanho esperado.
Performance
O parser da IBM é extremamente eficiente.
Mesmo assim:
Evite gerar JSON gigantescos.
Não faça PARSE repetidamente da mesma informação.
Reutilize áreas de trabalho.
Inicialize apenas quando necessário.
Evite cópias desnecessárias do buffer.
Armadilhas
Nomes diferentes
JSON
customerName
COBOL
CLIENTE-NOME
Não haverá correspondência automática sem mecanismos de mapeamento.
Campos obrigatórios
Nem sempre existirão.
Sempre valide.
Tipos incompatíveis
Número enviado como texto.
Texto enviado como número.
Boolean enviado como string.
São causas clássicas de erro.
Caracteres especiais
JSON utiliza UTF-8 com frequência.
Aplicações tradicionais em z/OS podem utilizar EBCDIC.
Em integrações, pode ser necessário converter a codificação antes do JSON PARSE ou após o JSON GENERATE.
Riscos
Os maiores riscos não estão no JSON.
Estão nos dados.
Por exemplo:
JSON malformado.
Dados incompletos.
Campos inesperados.
Tamanho excessivo.
Conteúdo malicioso.
Falhas de conversão de caracteres.
Exposição de informações sensíveis em logs.
Valide sempre a entrada e registre apenas o necessário.
Vantagens
Utilizar JSON no Mainframe oferece inúmeras vantagens:
integração simples com APIs REST;
comunicação natural com aplicações Java, .NET, Python e Node.js;
suporte a microsserviços;
facilidade de integração com nuvem;
menor necessidade de conversões proprietárias;
manutenção mais simples;
suporte nativo do Enterprise COBOL;
excelente desempenho quando comparado a parsers desenvolvidos manualmente.
Onde ele é utilizado?
Hoje praticamente em todos os projetos modernos.
Open Banking
PIX
Internet Banking
Aplicativos Mobile
APIs REST
IBM z/OS Connect
IBM API Connect
IBM MQ
Kafka
Cloud
Inteligência Artificial
IBM watsonx
Integrações híbridas entre IBM Z e plataformas distribuídas
Boas práticas
Um Padawan COBOL deve criar alguns hábitos desde o primeiro dia:
Inicialize as estruturas antes do processamento (INITIALIZE).
Utilize ON EXCEPTION e trate todos os erros.
Dimensione corretamente o buffer JSON.
Valide obrigatoriedade e formato dos campos.
Documente o layout esperado.
Mantenha os nomes consistentes entre JSON e estrutura COBOL sempre que possível.
Evite expor informações confidenciais em arquivos de log.
Teste com JSONs válidos, inválidos, incompletos e com dados extremos.
Conclusão
Durante muito tempo existiu o mito de que o Mainframe "não falava JSON". Isso deixou de ser verdade há anos. O Enterprise COBOL trouxe comandos nativos que simplificam enormemente a leitura e a geração desse formato, permitindo que aplicações escritas há décadas conversem com APIs modernas, serviços em nuvem, aplicações móveis e plataformas de Inteligência Artificial.
Para um Programador Padawan, aprender JSON significa abrir uma porta para o futuro sem abandonar os fundamentos que fazem do COBOL uma das linguagens mais confiáveis do mundo. Quem domina registros, copybooks e validação de dados aprenderá JSON rapidamente. A diferença está apenas na forma de representar a informação.
O verdadeiro desafio não é escrever JSON PARSE ou JSON GENERATE. É compreender a estrutura dos dados, validar corretamente o conteúdo recebido, tratar exceções, garantir compatibilidade de tipos e proteger informações sensíveis. Esses princípios sempre fizeram parte do desenvolvimento em Mainframe e continuam válidos na era das APIs.
No fim das contas, JSON não substitui o COBOL. Ele amplia sua capacidade de comunicação. E um IBM Z que conversa com o mundo moderno continua fazendo aquilo que sempre fez melhor: processar dados com segurança, desempenho e confiabilidade.
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
