 |
| Bellacosa Mainframe e o diario secreto do mainframe |
☕ Um Café no Bellacosa Mainframe
O Diário Secreto do Mainframe
Quando o Detetive Descobriu que o CICS Nunca Esquece
Os Arquivos Proibidos do SMF e o Mistério das Transações Fantasmas
"Todo crime deixa rastros. Alguns deixam pegadas na lama. Outros deixam registros no SMF."
Era uma noite fria.
A chuva batia contra as enormes janelas do Centro de Processamento de Dados.
As luzes verdes dos painéis piscavam lentamente, como se respirassem.
No silêncio do CPD, apenas um som quebrava a monotonia:
O z/OS continuava trabalhando.
Milhões de transações.
Milhões de clientes.
Milhões de histórias.
Foi então que o telefone tocou.
— "Bellacosa... temos um problema."
A agência central havia recebido centenas de reclamações.
As consultas de saldo estavam lentas.
PIX demorando.
Transferências atrasadas.
Nenhum ABEND.
Nenhum programa parado.
Nenhum operador sabia explicar.
Era um daqueles casos que lembravam as antigas revistas policiais da década de 1950.
O assassino parecia invisível.
Mas Sherlock Holmes costumava dizer:
"O criminoso sempre deixa evidências. O verdadeiro desafio é saber onde procurar."
No mundo IBM Z, essas evidências possuem três letras.
SMF.
O Diário do Mainframe
Imagine que o mainframe fosse um enorme castelo.
Milhares de pessoas entram.
Outras saem.
Mensagens circulam.
Portas se abrem.
Cofres são acessados.
Elevadores sobem.
Documentos são consultados.
Agora imagine que um escriba invisível acompanhe absolutamente tudo.
Cada passo.
Cada porta.
Cada funcionário.
Cada visitante.
Nada escapa.
Esse escriba chama-se System Management Facility.
Ou simplesmente:
SMF.
Enquanto todos trabalham, ele apenas observa.
E escreve.
Sem emoção.
Sem opinião.
Somente fatos.
É por isso que muitos administradores chamam o SMF de:
O Diário Oficial do z/OS.
Muito Além do CICS
Uma das primeiras descobertas de qualquer iniciante é perceber que o SMF não pertence ao CICS.
Na verdade...
o CICS é apenas um dos muitos narradores dessa grande história.
Imagine um jornal.
Cada editor envia suas notícias.
O editor de esportes.
O editor de economia.
O editor de política.
Todos escrevem para a mesma redação.
No mainframe acontece exatamente isso.
Diversos componentes enviam informações para o SMF.
Entre eles:
CICS
Db2
IMS
JES2
JES3
RACF
WLM
RMF
TCP/IP
DFSMS
USS
MQ
inúmeros produtos IBM e de terceiros
O SMF apenas organiza tudo.
Ele não cria os acontecimentos.
Ele apenas registra.
A Caixa-Preta do Computador
Se um avião sofre um acidente...
qual equipamento os investigadores procuram primeiro?
A caixa-preta.
Ela revela:
velocidade
altitude
comandos
alarmes
falhas
No mainframe acontece o mesmo.
Quando ocorre uma lentidão...
um pico de CPU...
um problema de produção...
ou uma degradação misteriosa...
todos correm para o SMF.
Porque ele estava olhando.
Desde o começo.
Como Tudo Acontece
Visualize a sequência.
Cliente
↓
Terminal 3270
↓
TOR
↓
AOR
↓
Programa COBOL
↓
VSAM / Db2 / MQ
↓
Resposta
Enquanto isso...
quase invisível...
há outro fluxo acontecendo.
Transação
↓
CICS
↓
Monitor
↓
SMF
↓
Dataset
↓
Relatórios
↓
Análise
↓
Correções
Perceba algo interessante.
O usuário nunca enxerga esse caminho.
Mas ele acontece o tempo inteiro.
O Caderno do Detetive
Imagine Sherlock Holmes investigando um roubo.
Ele possui um pequeno caderno.
Nele escreve:
09:03
Suspeito entrou.
09:05
Abriu a porta.
09:07
Falou com o caixa.
09:08
Saiu correndo.
O SMF faz exatamente isso.
Só que para computadores.
Por exemplo:
Transação: SALD
Usuário: AG03451
CPU: 3 ms
Db2: 2 SELECT
VSAM: 1 READ
Tempo Total: 118 ms
Resultado: OK
Depois outra.
Depois outra.
Depois outra.
Milhões delas.
A História Contada Pelos Números
Muitos iniciantes acreditam que números são frios.
Na verdade...
eles contam histórias.
Imagine este gráfico.
08:00
CPU 32%
09:00
CPU 40%
10:00
CPU 51%
11:00
CPU 67%
12:00
CPU 89%
12:15
CPU 97%
O que aconteceu?
Foi o COBOL?
Foi o Db2?
Foi a rede?
Foi um loop?
Sem o SMF...
ninguém sabe.
Com o SMF...
a investigação apenas começou.
O Registro Mais Famoso
Entre centenas de registros existentes...
há um verdadeiro astro do universo CICS.
O famoso:
SMF Tipo 110
Ele guarda praticamente um raio-X das transações.
Entre diversas informações encontramos:
Transaction ID
Program Name
User ID
CPU Time
Response Time
Wait Time
Dispatch Time
Syncpoint
File Requests
Db2 Calls
MQ Calls
Temporary Storage
Transient Data
Storage
Abends
Estatísticas de recursos
É como possuir uma câmera filmando cada detalhe da operação.
Os Outros Personagens da História
O infográfico também apresenta outros registros muito importantes.
Tipo 30
Accounting.
Mostra como um Address Space utilizou recursos.
Muito usado para cobrança interna, auditoria e consumo de CPU.
Tipo 70
CPU.
Quantos processadores estavam ocupados.
Quanto cada um trabalhou.
Carga do sistema.
Muito utilizado junto ao RMF.
Tipo 120
Hoje bastante associado a workloads HTTP, serviços web e componentes que utilizam diferentes subtipos desse registro para monitoramento de aplicações modernas.
Tipo 140
Dependendo do produto e da configuração, pode registrar estatísticas relacionadas a acesso a arquivos e utilização de recursos específicos.
O Crime Perfeito
Agora imagine um banco.
São exatamente 13:58.
Tudo funciona.
Às 14:03...
clientes começam a reclamar.
O suporte recebe dezenas de chamados.
Primeira hipótese.
"O COBOL está ruim."
Segunda hipótese.
"O Db2 caiu."
Terceira hipótese.
"A rede está lenta."
O analista experiente sorri.
Abre os relatórios do SMF.
E encontra:
CPU
98%
Db2 Wait
89 ms
Storage
SOS Warning
Número de transações
Triplicou.
Mistério resolvido.
Não era defeito.
Era excesso de carga.
Performance Não É Velocidade
Uma das maiores descobertas de quem trabalha com monitoramento é entender que performance não significa apenas rapidez.
Ela envolve equilíbrio.
Imagine uma rodovia.
Se passam cem carros por minuto...
todos chegam rapidamente.
Mas se passam dez mil...
o congestionamento aparece.
No CICS ocorre exatamente isso.
Nem sempre um programa ficou mais lento.
Às vezes...
simplesmente existem pessoas demais utilizando o mesmo recurso.
Capacity Planning
Aqui surge uma das aplicações mais inteligentes do SMF.
Ele permite prever o futuro.
Imagine estes dados.
Janeiro
CPU média
48%
Fevereiro
55%
Março
63%
Abril
71%
Maio
79%
Junho
87%
Julho
93%
Pergunta.
Você esperaria agosto chegar?
Claro que não.
Os registros históricos mostram a tendência.
É possível comprar capacidade antes do colapso.
Isso chama-se:
Capacity Planning.
É uma das tarefas mais importantes dos arquitetos IBM Z.
Os Parceiros do Detetive
Ler registros SMF diretamente não é uma tarefa comum. Em ambientes corporativos, diversas ferramentas interpretam esses dados e os apresentam em gráficos e relatórios.
Entre elas:
IBM OMEGAMON
RMF
CICS Performance Analyzer
MXG
SAS
IntelliMagic
MainView
SYSVIEW
Elas transformam milhões de registros em informações compreensíveis.
Como um Programador COBOL Pode Usar o SMF?
Muitos pensam:
"Mas eu sou apenas desenvolvedor."
Grande erro.
Um excelente programador aprende muito observando o comportamento das aplicações em produção.
Imagine que seu programa executa:
EXEC SQL
SELECT ...
END-EXEC
Você acredita que ele seja eficiente.
Mas o SMF mostra:
tempo de CPU baixo
espera enorme no Db2
milhares de leituras
resposta acima do esperado
A conclusão muda completamente.
O problema não estava no COBOL.
Estava no acesso aos dados.
Essa percepção transforma um programador comum em um desenvolvedor capaz de dialogar com DBAs, especialistas em performance e arquitetos de sistemas.
Passo a Passo para Entender um Problema Usando SMF
Sempre que houver uma degradação de desempenho, siga um método de investigação:
Passo 1 – Identifique o horário
Quando o problema começou?
Foi às 09h? Às 14h? Durante o fechamento do dia?
Sem delimitar o período, a análise fica muito mais difícil.
Passo 2 – Consulte os registros
Verifique os registros SMF correspondentes ao intervalo.
Procure aumento de CPU, filas de espera, eventos de exceção e crescimento do volume de transações.
Passo 3 – Correlacione recursos
Analise:
CPU
Memória
Storage
Db2
VSAM
MQ
Rede
WLM
O gargalo pode estar fora do programa COBOL.
Passo 4 – Compare com dias anteriores
O comportamento mudou?
Ou sempre foi assim?
A comparação histórica costuma revelar tendências invisíveis em uma análise isolada.
Passo 5 – Aplique a correção
Depois de identificar a causa, ajuste índices, SQL, parâmetros do CICS, distribuição de carga ou capacidade do ambiente.
Em seguida, volte ao SMF e confirme se os indicadores realmente melhoraram.
Curiosidades que Pouca Gente Conhece
O SMF registra muito mais do que performance
Também existem registros relacionados a:
logons
auditoria
segurança
RACF
alterações de configuração
eventos do sistema
utilização de dispositivos
atividades de rede
O SMF é um dos pilares das auditorias em ambientes regulados.
Os datasets SMF podem ficar gigantescos
Em grandes bancos, seguradoras ou órgãos governamentais, milhões de registros são produzidos diariamente.
Por isso, políticas de descarte, arquivamento e processamento são indispensáveis.
O monitoramento precisa de equilíbrio
Habilitar todas as classes de monitoramento em todos os momentos gera uma quantidade enorme de dados e pode aumentar o custo operacional.
Por isso, administradores escolhem cuidadosamente quais informações coletar em cada ambiente.
Dicas de Ouro para o Iniciante
✔ Nunca conclua que "o COBOL está lento" antes de analisar os dados.
✔ Aprenda a diferença entre tempo de CPU e tempo de espera.
✔ Estude o SMF Tipo 110 em conjunto com o monitoramento do CICS.
✔ Familiarize-se com ferramentas como OMEGAMON e RMF.
✔ Observe tendências, não apenas eventos isolados.
✔ Entenda que um gargalo pode surgir da combinação de CPU, Db2, VSAM, MQ, rede e carga simultânea.
✔ O melhor analista não é quem faz suposições; é quem coleta evidências.
Easter Egg ☕
Nas antigas histórias de detetive, havia sempre um personagem discreto que parecia não participar da trama: o porteiro, o escrivão ou o arquivista. Quase ninguém prestava atenção nele... até o capítulo final, quando seus registros revelavam exatamente quem entrou, quem saiu e em que momento o crime aconteceu.
No universo do IBM Z, esse personagem silencioso é o SMF.
Enquanto programas COBOL executam cálculos, CICS atende milhões de transações e Db2 responde consultas, o SMF continua escrevendo, linha após linha, a verdadeira história do sistema.
Quando todos dizem "não sabemos o que aconteceu", ele responde silenciosamente:
"Eu sei. Eu estava observando o tempo todo."
E talvez essa seja a maior lição para quem está começando no mundo do Mainframe: os melhores profissionais não resolvem mistérios por sorte ou intuição. Eles aprendem a ler as evidências que o próprio sistema deixou para trás. No IBM Z, poucas fontes de conhecimento são tão valiosas quanto os registros SMF — o diário secreto que transforma milhões de eventos aparentemente desconexos em uma narrativa completa sobre desempenho, confiabilidade e a extraordinária engenharia que mantém o mundo funcionando todos os dias.
