Aprenda a aumentar sua comunidade.
Técnicas para gerir comentários e curtidas dos vídeos e com isso aumentar sua comunidade no Youtube.
01
✨ 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
quarta-feira, 7 de fevereiro de 2018
terça-feira, 6 de fevereiro de 2018
Youtube : Primeiros passos
Saiba mais sobre o Youtube
Os primeiros passos no Youtube, como criar um canal, as regras de comunidades, ser visto e os direitos autorais.
Youtube : Seja Descoberto
Como divulgar seus vídeos
Usando títulos, tag, descrição e metadados seu vídeo poderá ser descoberto mais facilmente.
segunda-feira, 5 de fevereiro de 2018
Youtube : Ganhe Insight com o Youtube Analytics
Saiba usar o Analytics Series
Aprendendo sobre as estatísticas do Youtube, utilizando o analytics,
Youtube : Criar um ótimo conteúdo
Como criar um ótimo conteúdo?
Vale a pena, gastar alguns minutos para acompanhar os cursos do Youtube.
domingo, 4 de fevereiro de 2018
IBM Mainframe Discovery : Capítulo II — A Planta da Nave Mais Duradoura da Galáxia
 |
| Bellacosa Mainframe apresenta o ibm mainframe parte II |
☕ Um Café no Bellacosa Mainframe
Capítulo II — A Planta da Nave Mais Duradoura da Galáxia
Arquitetura do IBM System/360 ao IBM z15
NÃO JULGUE UMA NAVE PELA PINTURA EXTERNA
Existe um erro que praticamente toda civilização tecnológica já cometeu.
Ela olha para uma máquina antiga e pensa:
— "Isso já deveria estar num museu."
Cinco minutos depois...
...essa mesma máquina está autorizando o pagamento do salário de milhões de pessoas.
Bem-vindo ao universo do IBM Mainframe.
Hoje vamos visitar algo muito mais importante do que processadores.
Vamos conhecer sua arquitetura.
Porque computadores podem envelhecer.
Arquiteturas excepcionais, não.
Imagine uma Cidade Espacial
Esqueça por alguns minutos a palavra "computador".
Ela limita nossa imaginação.
Imagine uma gigantesca estação espacial.
Ela possui:
bairros
ruas
centrais elétricas
hangares
elevadores
centros médicos
defesa
comunicação
logística
Agora imagine que essa estação precisa permanecer funcionando por cinquenta anos.
Sem demolir bairros.
Sem mudar endereços.
Sem obrigar milhões de habitantes a mudarem de casa.
Esse é exatamente o problema que Gene Amdahl e sua equipe receberam em 1964.
Eles não estavam construindo apenas um computador.
Estavam projetando uma cidade capaz de sobreviver por gerações.
O Caos Antes do System/360
Hoje parece natural que um programa rode em diferentes modelos de computador.
Na década de 1960 isso era praticamente ficção científica.
Cada computador era um planeta isolado.
Cada planeta possuía:
linguagem própria
instruções próprias
periféricos próprios
compiladores próprios
sistema operacional próprio
Trocar de equipamento significava reescrever praticamente tudo.
Era como mudar de planeta e descobrir que até a gravidade havia sido reinventada.
Então Veio uma Ideia Quase Louca
Em vez de construir vários computadores...
...por que não construir uma única arquitetura?
Uma família inteira.
Pequena.
Média.
Grande.
Gigante.
Mas todas falando exatamente a mesma língua.
Hoje isso parece óbvio.
Na época foi revolucionário.
Essa ideia ficou conhecida como System/360.
Segundo Wilhelm G. Spruth, a arquitetura nasceu do trabalho de três nomes fundamentais — Gene Amdahl, Gerry Blaauw e Fred Brooks — e estabeleceu princípios tão sólidos que continuaram influenciando a computação por décadas.
A Grande Biblioteca Galáctica
Imagine uma biblioteca.
Cada livro representa um programa COBOL.
Em outras plataformas, quando surge um computador novo, alguém decide reorganizar completamente as estantes.
Resultado?
Todos os livros precisam ser reescritos.
No universo IBM aconteceu o contrário.
As estantes cresceram.
Novas alas foram construídas.
Novas salas apareceram.
Mas o endereço dos livros continuou válido.
Essa filosofia ficou conhecida como:
Compatibilidade binária.
É uma das maiores obras de engenharia da história da computação.
O Que Significa Compatibilidade?
Vamos imaginar.
Você escreveu um programa COBOL em 1978.
Outro programador escreveu um em 1992.
Outro em 2008.
Outro hoje.
Todos podem coexistir.
Não porque o mundo parou.
Mas porque a arquitetura evoluiu sem destruir o passado.
É como uma nave espacial que recebe motores novos, escudos novos e computadores novos...
...mas continua aceitando a mesma chave da porta de cinquenta anos atrás.
Arquitetura Não É Hardware
Aqui existe outra confusão muito comum.
Muitos pensam que arquitetura significa:
processador.
Na verdade...
arquitetura é um contrato.
Ela responde perguntas fundamentais.
Como funcionam os registradores?
Como a memória é endereçada?
Como as instruções são codificadas?
Como interrupções acontecem?
Como programas conversam com o sistema operacional?
Enquanto esse contrato permanece consistente...
o restante pode evoluir.
E evoluiu.
Muito.
A Nave Recebeu Motores Novos
Ao longo das décadas nasceram:
System/370.
zSeries.
System z.
IBM Z.
z13.
z14.
z15.
z16.
z17.
Mudaram:
chips
cache
frequência
memória
criptografia
IA
virtualização
Mas o coração da nave continuou reconhecendo seus antigos passageiros.
Isso é extraordinariamente raro na indústria.
Os Registradores: a Mesa do Capitão
Imagine o capitão da nave.
Durante uma missão ele não consulta o depósito de carga para cada decisão.
Ele mantém informações críticas sobre sua mesa.
Os registradores fazem exatamente isso.
São as áreas mais rápidas da CPU.
Ali ficam:
endereços.
contadores.
operandos.
resultados intermediários.
O processador consulta os registradores milhares de milhões de vezes por segundo.
No IBM Z eles foram cuidadosamente preservados e ampliados ao longo das gerações, mantendo compatibilidade enquanto novas capacidades eram adicionadas.
A Linguagem da Nave
Todo computador possui um idioma.
Chamamos isso de:
Instruction Set Architecture.
Ou ISA.
Ela define todas as instruções que o processador compreende.
Imagine uma tripulação internacional.
Independentemente do país de origem...
todos seguem o mesmo protocolo operacional.
É isso que o ISA representa.
Um contrato universal entre hardware e software.
Spruth destaca que o conjunto de instruções do System z permaneceu limpo, compacto e extremamente eficiente, contribuindo para melhor aproveitamento de cache e menor necessidade de largura de banda entre CPU e memória.
O Segredo da Linguagem Compacta
Existe uma curiosidade fascinante.
O relatório cita um estudo interno da IBM indicando que o código gerado para System z podia ser significativamente mais compacto do que em algumas arquiteturas contemporâneas.
Por quê?
Porque muitas instruções realizavam mais trabalho.
Isso significa:
menos bytes.
menos cache ocupado.
menos tráfego interno.
Imagine duas tripulações.
Uma precisa usar vinte palavras para transmitir uma ordem.
Outra transmite a mesma ideia em oito.
Quem termina primeiro?
O Mito da Velocidade
Muitos iniciantes perguntam:
"O IBM Z tem o clock mais alto?"
Essa pergunta lembra alguém perguntando:
"Qual estação espacial é mais rápida?"
Depende.
Mais rápida para quê?
Uma nave de carga não foi feita para vencer corridas.
Foi feita para nunca perder sua carga.
O IBM Z foi otimizado para throughput, previsibilidade e processamento contínuo.
Não apenas para velocidade instantânea.
Pipeline: A Linha de Produção Interestelar
Imagine uma fábrica de sondas espaciais.
Enquanto uma sonda recebe pintura...
outra instala motores.
Outra monta sensores.
Outra faz testes.
Tudo acontece simultaneamente.
O pipeline da CPU funciona assim.
Várias instruções avançam em diferentes etapas ao mesmo tempo.
Quando uma termina...
outra já está pronta.
O resultado é enorme eficiência.
Cache: A Mochila do Explorador
Nenhum explorador atravessa um planeta carregando todo o depósito da nave.
Ele leva apenas aquilo que usará logo.
Cache é exatamente isso.
Uma mochila extremamente rápida.
Quanto melhor organizada...
menos tempo o processador perde procurando dados.
Spruth observa que a arquitetura compacta do System z favorece justamente um uso mais eficiente das memórias cache L1 e L2.
A Arquitetura Cresce Sem Quebrar
Talvez este seja o verdadeiro milagre.
Em muitas plataformas...
crescer significa substituir.
No IBM Z...
crescer quase sempre significou ampliar.
Novas instruções aparecem.
Novos registradores surgem.
Novos recursos são incorporados.
Mas os antigos continuam funcionando.
É como ampliar uma estação espacial adicionando novos módulos sem desligar os antigos.
A Filosofia do "Não Jogue Fora"
Existe uma enorme diferença entre engenharia e moda.
Moda muda porque sim.
Engenharia muda porque precisa.
A IBM sempre tratou compatibilidade como patrimônio.
Isso exigiu disciplina.
Cada nova geração precisava responder uma pergunta difícil:
"Como evoluir sem destruir o investimento de nossos clientes?"
Essa pergunta moldou toda a arquitetura do System z.
A Evolução Continua
Desde a publicação do relatório de Spruth, a arquitetura continuou evoluindo.
Hoje encontramos recursos que em 2010 ainda não existiam:
aceleração para inteligência artificial embarcada;
criptografia resistente a ameaças futuras;
integração profunda com Linux, containers e OpenShift;
otimizações para APIs, microsserviços e cargas híbridas;
novos mecanismos de observabilidade e automação.
O curioso é que tudo isso foi incorporado preservando a essência da arquitetura criada em 1964.
A nave continua recebendo novos módulos sem abandonar seu projeto original.
O Que um Padawan COBOL Deve Aprender?
Muitos iniciantes acreditam que aprender COBOL é decorar comandos.
Não é.
Aprender COBOL também significa compreender a plataforma onde ele vive.
Quando você entende a arquitetura do IBM Z, várias decisões da linguagem passam a fazer sentido:
por que certos tipos de dados existem;
por que a eficiência de I/O é tão valorizada;
por que compatibilidade é tratada como princípio;
por que estabilidade é considerada uma funcionalidade.
Você deixa de ser apenas alguém que escreve código.
Passa a compreender a lógica da nave inteira.
Curiosidades do Diário de Bordo
📖 O investimento no projeto System/360 foi um dos maiores da história da IBM e redefiniu completamente sua estratégia.
🖥️ A filosofia de compatibilidade binária do System/360 influenciou gerações de arquiteturas e sistemas operacionais.
🚀 Enquanto muitas plataformas passaram por rupturas frequentes, a família IBM Z preferiu evoluir continuamente, preservando aplicações e conhecimento acumulado.
🧠 O relatório de Spruth lembra que até outras arquiteturas de destaque reconheceram a influência conceitual do trabalho iniciado por Amdahl, Blaauw e Brooks.
Diário de Bordo do Padawan COBOL
Antes de embarcar para o próximo setor da nave, registre estas quatro coordenadas no seu caderno de bordo:
✅ Arquitetura é muito mais do que hardware; é um contrato de longo prazo entre software e máquina.
✅ O maior diferencial do IBM Z não é apenas potência, mas a capacidade de evoluir sem abandonar o passado.
✅ Compatibilidade binária não é um detalhe técnico; ela protege décadas de investimento e conhecimento.
✅ Grandes arquiteturas não sobrevivem por sorte. Elas sobrevivem porque foram projetadas para continuar relevantes mesmo quando toda a galáxia muda ao seu redor.
No próximo capítulo, entraremos na sala de máquinas da nave para descobrir um dos maiores segredos do IBM Z: como ele foi projetado para continuar funcionando quando praticamente qualquer outro computador já teria desistido. Afinal, na galáxia dos sistemas críticos, sobreviver a uma falha não é um luxo — é parte da missão.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
02
Capítulo II — A Planta da Nave Mais Duradoura da Galáxia
Leia no visor ou abra a publicação original.
03
Capítulo III — A Nave Que Se Recusa a Explodir
Leia no visor ou abra a publicação original.
04
05
Capítulo V — A Frota Invisível do Transporte Interestelar
Leia no visor ou abra a publicação original.
06
07
Capítulo VII — O Grande Terminal de Embarque da Galáxia
Leia no visor ou abra a publicação original.
08
Capítulo VIII — A Metrópole das Transações Infinitas
Leia no visor ou abra a publicação original.
09
Capítulo IX — A Federação das Naves Invisíveis
Leia no visor ou abra a publicação original.
10
Capítulo X — A Consciência Coletiva da Galáxia
Leia no visor ou abra a publicação original.
11
Capítulo XI — O Almirante Invisível da Frota
Leia no visor ou abra a publicação original.
12
Capítulo XII — A Biblioteca Infinita da Galáxia
Leia no visor ou abra a publicação original.
13
Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia
Leia no visor ou abra a publicação original.
14
15
Capítulo XV — O Tradutor Universal da Federação
Leia no visor ou abra a publicação original.
16
Capítulo XVI — A Fábrica Automática da Federação
Leia no visor ou abra a publicação original.
17
Capítulo XVII — A Última Fronteira Nunca Foi o Espaço
Leia no visor ou abra a publicação original.
18
19
Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando
Leia no visor ou abra a publicação original.
Índice completo em links HTML rastreáveis
Esta lista permanece no conteúdo da postagem para navegação, acessibilidade e descoberta por mecanismos de busca.
- Capítulo I — Não Entre em Pânico!
- Capítulo II — A Planta da Nave Mais Duradoura da Galáxia
- Capítulo III — A Nave Que Se Recusa a Explodir
- Capítulo IV — A Sala dos Cofres Cósmicos
- Capítulo V — A Frota Invisível do Transporte Interestelar
- Capítulo VI — O Grande Maestro Invisível
- Capítulo VII — O Grande Terminal de Embarque da Galáxia
- Capítulo VIII — A Metrópole das Transações Infinitas
- Capítulo IX — A Federação das Naves Invisíveis
- Capítulo X — A Consciência Coletiva da Galáxia
- Capítulo XI — O Almirante Invisível da Frota
- Capítulo XII — A Biblioteca Infinita da Galáxia
- Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia
- Capítulo XIV — O Jardim Secreto da Nave
- Capítulo XV — O Tradutor Universal da Federação
- Capítulo XVI — A Fábrica Automática da Federação
- Capítulo XVII — A Última Fronteira Nunca Foi o Espaço
- Capítulo XVIII — O Guia Nunca Terminou
- Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando
sábado, 3 de fevereiro de 2018
O Diário Secreto do Mainframe : Quando o Detetive Descobriu que o CICS Nunca Esquece
 |
| 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.
Subscrever:
Mensagens (Atom)
