 |
| Bellacosa Mainframe e o caso dos 8 segundos perdidos |
☕ Um Café no Bellacosa Mainframe
O Caso dos Oito Segundos Perdidos
Quando um Programador COBOL Descobre que o Verdadeiro Vilão Nunca Foi o CICS... Mas um Gargalo Escondido nas Sombras
"Naquela manhã chuvosa, os operadores juravam que o CICS estava lento. O gerente culpava o banco de dados. O DBA apontava para a CPU. O pessoal de infraestrutura acusava o storage. O Sysprog olhava silenciosamente para os gráficos do RMF. E, em algum lugar escondido entre milhões de linhas de COBOL, um único SQL aguardava para ser descoberto..."
Prólogo – O Mistério da Lentidão
Se você perguntar para um programador COBOL iniciante:
"O que faz um sistema ficar lento?"
Provavelmente ouvirá:
"A CPU está cheia."
É uma resposta compreensível.
Mas quase sempre...
Está errada.
Uma das maiores lições que um profissional IBM Mainframe aprende ao longo da carreira é que lentidão é um sintoma, não um diagnóstico.
Performance Tuning é praticamente um trabalho de detetive.
Cada métrica é uma pista.
Cada relatório é um depoimento.
Cada gráfico conta uma parte da história.
E, como todo bom romance policial dos anos 1950, o culpado quase nunca é quem parecia ser no primeiro capítulo.
Hoje vamos abrir os arquivos confidenciais do CPD para investigar um dos casos mais fascinantes do universo CICS.
Prepare seu bloco de notas.
A investigação começou.
Capítulo 1 – O CICS é uma Cidade que Nunca Dorme
Imagine uma enorme cidade.
Milhões de pessoas entram e saem todos os dias.
Existem:
bancos
hospitais
aeroportos
repartições públicas
supermercados
Tudo funcionando ao mesmo tempo.
Essa cidade chama-se CICS.
Cada cidadão é uma transação.
Cada rua representa um recurso do sistema.
Cada cruzamento é um ponto onde pode surgir congestionamento.
Enquanto você dorme...
Essa cidade continua trabalhando.
Ela processa:
PIX
cartões
seguros
folha de pagamento
bolsas de valores
companhias aéreas
telecomunicações
Em alguns ambientes...
Mais de 100 milhões de transações por dia.
E tudo isso precisa acontecer em poucos milissegundos.
Capítulo 2 – O Relógio Nunca Mente
O primeiro suspeito sempre atende pelo nome de:
Response Time
Ele representa o tempo entre:
ENTER
↓
Processamento
↓
Resposta
Parece simples.
Mas esse número esconde dezenas de acontecimentos.
Enquanto o usuário observa apenas uma tela parada...
O CICS está fazendo centenas de operações invisíveis.
O Iceberg da Performance
O usuário vê apenas isto:
Resposta em 8 segundos
O analista enxerga:
CPU
↓
Dispatcher
↓
Storage
↓
Task
↓
DB2
↓
VSAM
↓
MQ
↓
TCP/IP
↓
Locks
↓
I/O
↓
Rede
↓
WLM
↓
Cache
↓
Buffers
↓
SMF
↓
RMF
Cada bloco acrescenta alguns milissegundos.
Somados...
Transformam-se em segundos.
Capítulo 3 – O Detetive Nunca Acusa Sem Evidências
Um erro clássico dos iniciantes é fazer isto:
"O sistema está lento."
Então começam a alterar parâmetros.
Isso é como trocar o motor do carro porque um pneu furou.
Os profissionais experientes seguem uma regra sagrada:
Nunca modifique aquilo que você ainda não mediu.
Primeiro mede.
Depois entende.
Só então modifica.
A Regra de Ouro do Performance Tuning
Existe um mantra repetido por analistas veteranos:
Measure
↓
Analyze
↓
Identify
↓
Optimize
↓
Validate
Ou em português:
Medir
↓
Analisar
↓
Identificar
↓
Otimizar
↓
Validar
Perceba que "otimizar" aparece apenas no quarto passo.
Muitos iniciantes começam justamente por ele.
Capítulo 4 – O Julgamento da CPU
Sempre que algo fica lento...
Alguém diz:
"A CPU está em 95%."
Fim da discussão.
Mas espere.
CPU alta significa culpa?
Não.
CPU alta pode ser consequência.
Imagine um caixa eletrônico tentando consultar um cliente.
O SQL demora.
Enquanto espera...
A CPU continua trabalhando em outras tarefas.
Quando finalmente recebe os dados...
Executa um enorme processamento COBOL.
Resultado:
CPU sobe.
Mas ela não foi o problema inicial.
Ela apenas trabalhou mais porque outra peça atrasou todo o restante.
Curiosidade Noir
Os analistas antigos costumavam dizer:
"CPU é como febre. Ela mostra que existe um problema, mas quase nunca diz qual."
Capítulo 5 – O Sombrio Reino do Db2
Se existe um lugar onde muitos mistérios começam...
É o banco de dados.
Um SQL aparentemente inocente pode esconder um verdadeiro desastre.
Veja:
SELECT *
FROM CLIENTES
Parece simples.
Mas imagine uma tabela com:
120 milhões de registros.
Sem índice.
O Db2 inicia um Table Space Scan.
Milhões de páginas são lidas.
Buffers começam a encher.
Discos trabalham.
CPU cresce.
O usuário espera.
E o gerente conclui:
"CICS está lento."
Na verdade...
Era apenas um SQL mal escrito.
O EXPLAIN é a Lupa de Sherlock Holmes
Nenhum DBA sério trabalha sem EXPLAIN.
Ele responde perguntas como:
Qual índice será utilizado?
Haverá Table Scan?
Quantos registros serão lidos?
Qual Join será escolhido?
Quantas páginas serão acessadas?
É literalmente a autópsia do SQL antes da execução.
Easter Egg nº 1
Se você encontrar um programa COBOL com:
SELECT *
Sem WHERE...
Você acabou de descobrir o equivalente mainframe de deixar a porta da geladeira aberta o dia inteiro.
Capítulo 6 – Os Arquivos VSAM Também Contam Segredos
Muito antes do Db2 dominar os grandes sistemas...
O VSAM já guardava milhões de registros.
E continua fazendo isso.
Os tipos mais comuns:
KSDS
ESDS
RRDS
LDS
Cada um possui comportamento diferente.
Um KSDS muito fragmentado pode sofrer:
CI Split
CA Split
Resultado?
Mais I/O.
Mais espera.
Mais tempo de resposta.
O Mistério dos Buffers
Imagine procurar um livro.
Você pode:
Ir até a biblioteca toda vez.
Ou deixá-lo sobre a mesa.
Os buffers fazem exatamente isso.
Quanto melhores os buffers...
Menos viagens ao disco.
Mais velocidade.
Capítulo 7 – A Memória Invisível
Poucos iniciantes estudam Storage.
Mas deveriam.
No CICS existem áreas famosas:
DSA
EDSA
CDSA
UDSA
SDSA
Quando alguma delas fica cheia...
Começam acontecimentos estranhos.
Transações recusadas.
Lentidão.
Abends.
Filas.
Até surgir uma sigla temida:
SOS
Short On Storage.
Veteranos arrepiam só de ouvir esse nome.
Easter Egg nº 2
No universo CICS, "SOS" não significa "Save Our Souls".
Significa:
"Prepare o café... hoje ninguém vai embora cedo."
Capítulo 8 – O Engarrafamento Invisível
Nem toda lentidão significa problema técnico.
Imagine um banco às 10 horas da manhã.
Milhares de clientes.
Todos chegam ao mesmo tempo.
Os caixas são limitados.
Forma-se uma fila.
No CICS acontece igual.
500 usuários
↓
1000 transações
↓
200 Tasks disponíveis
As demais esperam.
Não existe erro.
Existe congestionamento.
Esse fenômeno chama-se:
Transaction Queuing.
Capítulo 9 – Throughput: O Herói Esquecido
Todo mundo fala em velocidade.
Poucos falam em capacidade.
Imagine dois carros.
Primeiro:
200 km/h
Transporta 2 pessoas.
Segundo:
80 km/h
Transporta 70 passageiros.
Qual leva mais gente?
O segundo.
O mesmo vale para o Mainframe.
Às vezes uma transação demora um pouco mais.
Mas o sistema atende milhares simultaneamente.
Isso é Throughput.
Capítulo 10 – Os Relatórios Nunca Mentem
Quando surge um incidente...
Entram em cena os investigadores.
Cada ferramenta possui uma especialidade.
SMF
É o diário secreto do z/OS.
Tudo fica registrado.
Cada evento.
Cada consumo.
Cada erro.
RMF
É o cardiologista do sistema.
Mede:
CPU
Disco
Canal
Memória
LPAR
WLM
CICS Performance Analyzer
Mostra tendências.
Permite descobrir:
Quando começou a degradação?
Ela piora em determinados horários?
Existe sazonalidade?
Db2 Performance Monitor
Mostra:
Locks.
Buffer Pools.
Getpages.
Elapsed.
CPU.
SQL.
É praticamente uma câmera de segurança do banco de dados.
O Método CSI Mainframe
Imagine uma investigação.
A transação SALD demora oito segundos.
O analista segue o roteiro:
Cena do crime.
↓
Coleta evidências.
↓
Analisa SMF.
↓
Consulta RMF.
↓
Verifica WLM.
↓
Observa CPU.
↓
Analisa SQL.
↓
Examina VSAM.
↓
Confere Storage.
↓
Encontra o gargalo.
Nenhuma hipótese é descartada sem provas.
Curiosidade Histórica
Na década de 1980 muitos problemas eram resolvidos observando apenas consoles, dumps impressos e enormes relatórios em papel contínuo.
Era comum encontrar analistas caminhando pelos corredores carregando pilhas de listagens maiores do que uma mesa de escritório.
Hoje usamos dashboards sofisticados.
Mas o raciocínio investigativo continua exatamente o mesmo.
Passo a Passo para Investigar uma Transação Lenta
Se amanhã você entrar em uma equipe de suporte CICS e ouvir:
"A transação CONSULTA demorou oito segundos."
Siga este roteiro:
Descubra quando o problema começou.
Compare com dias anteriores.
Consulte os relatórios SMF.
Verifique o RMF.
Analise a utilização da CPU.
Verifique o WLM.
Procure espera por recursos.
Analise SQL com EXPLAIN.
Verifique buffers do Db2.
Analise VSAM.
Procure contenção.
Verifique Storage.
Confira MXT e filas.
Compare com a baseline.
Só depois faça alterações.
Essa sequência evita mudanças precipitadas e aumenta muito a chance de encontrar a causa raiz.
Dicas para um Programador COBOL Iniciante
Aprenda SQL antes de tentar otimizar COBOL.
Entenda o funcionamento de índices Db2.
Estude VSAM e seus padrões de acesso.
Conheça as principais áreas de storage do CICS.
Aprenda a ler relatórios SMF e RMF.
Familiarize-se com conceitos de WLM e Dispatching.
Nunca presuma que CPU alta é a causa do problema.
Documente cada alteração realizada em produção.
Crie o hábito de comparar métricas antes e depois de qualquer mudança.
Pense sempre no sistema como um conjunto integrado, e não como componentes isolados.
Curiosidades que Impressionam em Entrevistas
Uma redução de apenas 5 milissegundos em uma transação executada milhões de vezes ao dia pode economizar horas de CPU ao longo do mês.
Em muitos ambientes corporativos, mais de 90% das reclamações de lentidão acabam tendo origem fora do código COBOL, envolvendo SQL, configuração, infraestrutura ou contenção de recursos.
O CICS foi projetado para operar continuamente, processando cargas enormes com alta disponibilidade, o que explica sua presença em bancos, seguradoras, companhias aéreas e órgãos governamentais há décadas.
O Último Suspeito
Quando toda investigação termina...
Os novatos perguntam:
"Então qual era o culpado?"
A resposta dos veteranos costuma ser a mesma.
"Depende."
Porque o verdadeiro segredo do Performance Tuning nunca foi decorar comandos.
Nem decorar parâmetros.
Nem decorar tabelas.
O verdadeiro segredo é aprender a pensar como um investigador.
Cada métrica conta uma história.
Cada relatório revela uma pista.
Cada gráfico esconde um detalhe.
Cada segundo perdido possui uma explicação.
E quando você finalmente domina essa arte, deixa de ser apenas um programador COBOL.
Torna-se um detetive do desempenho, capaz de seguir rastros invisíveis entre milhões de instruções, atravessar as sombras do CICS e revelar o culpado que ninguém mais conseguia enxergar.
Na próxima vez que alguém disser, com toda a convicção, "o CICS está lento", sorria discretamente, pegue sua lupa imaginária e lembre-se da maior lição desta investigação:
No Mainframe, o gargalo raramente está onde todos estão olhando. O verdadeiro mistério está escondido entre as métricas — esperando por alguém paciente o suficiente para conectar todas as pistas.
