😈🔥 Lendo SMF do MQ como se fosse trace distribuído

Conhecimento básico sobre aplicações distribuídas para quem já confiou mais no SMF do que em qualquer dashboard

---

☕ 02:48 — Quando a fila cresce e ninguém sabe “quem começou”

No mundo cloud, alguém pergunta:

“Qual serviço está causando o problema?”

No mundo mainframe, a pergunta sempre foi melhor:

“Qual transação chegou primeiro?”

Este artigo é sobre ler SMF do IBM MQ for z/OS com a mesma lógica usada para distributed tracing moderno — só que com décadas a mais de maturidade.

---

1️⃣ Contexto histórico: antes do trace existir, o SMF já contava a história 🧬

Distributed tracing surgiu porque:

• sistemas ficaram espalhados

• ninguém sabia por onde o request passava

No z/OS:

• tudo sempre passou por um lugar auditável

• o SMF virou a linha do tempo oficial

📌 Comentário Bellacosa:
Trace é novidade.
Linha do tempo sempre foi obrigação.

---

2️⃣ O que é um trace distribuído, afinal? 🧩

Trace distribuído:

• segue um request

• de serviço em serviço

• até o resultado (ou falha)

SMF do MQ faz o mesmo:

• PUT

• fila

• GET

• consumo

• impacto em recursos

🔥 Tradução direta:
Cada mensagem no MQ é um request distribuído encapsulado.

---

3️⃣ Mapa mental: SMF do MQ ↔ Trace moderno 🗺️

SMF MQ (z/OS)	Trace distribuído	Significado
PUT MESSAGE	Span inicial	Entrada do request
Queue Name	Service name	Destino lógico
GET MESSAGE	Span consumidor	Processamento
Queue Depth	Lag	Acúmulo de trabalho
Elapsed Time	Latência	Tempo fim a fim
CPU / I/O	Resource usage	Custo do request
Aplicação	Service ID	Responsável

😈 Easter egg:
Fila crescendo é trace parado no meio do caminho.

---

4️⃣ Lendo SMF como linha do tempo (não como relatório) ⏱️

Erro comum:

• olhar SMF como estatística fria

Leitura correta:

• montar sequência temporal

• entender causa → efeito

📌 Comentário Bellacosa:
Trace não é gráfico bonito.
É história cronológica.

---

5️⃣ Passo a passo: leitura estilo “trace distribuído” 🔍

5.1 — Identifique o PUT inicial

• Quem publicou?

• Em que horário?

• Com qual volume?

👉 Equivalente ao primeiro span do trace.

---

5.2 — Observe a evolução da fila

• Crescimento constante?

• Explosão pontual?

😈 Easter egg:
Fila crescendo devagar é mais perigosa que pico.

---

5.3 — Analise o GET

• Está acontecendo?

• Está atrasado?

• Está mais lento?

📌 Tradução:
Consumidor virou gargalo.

---

5.4 — Correlacione com recursos (RMF mode) 📊

• CPU alta?

• I/O saturado?

• Espera?

🔥 Comentário Bellacosa:
Mensagem não some. Ela espera.

---

5.5 — Ache o primeiro desvio

• Antes do alerta

• Antes da reclamação

• Antes do incidente

👉 Esse é o root cause real.

---

6️⃣ Curiosidades que só mainframer percebe 😈

• MQ nunca mente

• Ele só acumula evidência

• SMF sempre esteve certo

• O erro humano vem depois

📌 Comentário ácido:
Alertas gritam. SMF sussurra — e acerta.

---

7️⃣ Erros clássicos ao analisar MQ ⚠️

❌ Aumentar depth máximo
❌ Ajustar buffers sem análise
❌ Culpar o MQ
❌ Ignorar correlação temporal

🔥 Regra imortal:
Fila cheia é consequência, não diagnóstico.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Mensageria confiável

• Backpressure

• Throughput vs Latência

• Observabilidade

• Root cause analysis

Exercício Bellacosa

👉 Pegue um relatório SMF do MQ
👉 Monte uma timeline manual
👉 Marque onde o fluxo parou

---

🎯 Aplicações práticas desse entendimento

• Integração mainframe-cloud

• Sistemas event-driven críticos

• Análise de gargalos

• Prevenção de incidentes

• Auditoria e compliance

🔥 Comentário final:
Quem entende SMF do MQ já entende tracing distribuído — só não chamava assim.

---

🖤 Epílogo — 03:19, filas sob controle

Enquanto o mundo descobre tracing,
o mainframe segue entregando história completa, com provas.

El Jefe Midnight Lunch assina:
“Mensagem não mente. E SMF nunca esquece.”

 

 

🧠 “SMF como fonte de verdade para observabilidade corporativa”

Porque antes de existir observability platform, já existia evidência

---

☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.

---

🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

• auditoria

• cobrança

• capacidade

• performance

• rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.

---

🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

• Logs

• Metrics

• Traces

No z/OS:

• Tudo isso… em um formato só

• Com timestamp confiável

• Com contexto de sistema

• Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.

---

🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.

---

📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade moderna	SMF
Métricas amostradas	Dados completos
Traces instrumentados	Evidência sistêmica
Logs verbosos	Registros estruturados
Dashboards	Capacidade histórica
Alertas	Diagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.

---

🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.

---

🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

• híbridas

• distribuídas

• event-driven

O SMF entra como:

• referência de carga real

• baseline de comportamento

• âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

• se foi CPU

• se foi I/O

• se foi concorrência

• ou se foi culpa de quem chamou demais

---

📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

• Observabilidade ≠ Monitoramento

• Correlação ≠ Alerta

• Evidência ≠ Opinião

• Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.

---

🎯 Aplicações reais no mundo corporativo

• Auditoria e compliance

• Capacity planning sério

• SRE corporativo

• Integração com AIOps

• Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.

---

🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

 

 

🔥 Como extrair listagens SMF no IBM mainframe z/OS (sem romantizar, sem mistério)

Conhecimento básico sobre aplicações distribuídas explicado para quem confia em SMF mais do que em dashboard bonito

---

☕ 01:37 — Antes de existir “observabilidade”, já existia verdade

No mundo cloud, observabilidade é:

• moda

• ferramenta

• assinatura mensal

No mainframe, observabilidade sempre foi:

SMF ou nada

Se você quer entender aplicações distribuídas, mensageria, performance e incidentes, aprender a extrair, ler e interpretar SMF é obrigação moral de todo mainframer.

---

1️⃣ Breve história: SMF não foi feito para te agradar 🧬

O System Management Facility (SMF) nasceu para:

• auditoria

• capacidade

• cobrança

• performance

• verdade operacional

📌 Comentário Bellacosa:
SMF não explica.
SMF prova.

---

2️⃣ Onde os dados SMF ficam no z/OS 🗂️

Formas comuns de armazenamento:

1️⃣ Datasets sequenciais ativos

• SYS1.MANx (MAN1, MAN2, MAN3)

• Gravados continuamente

• Reutilizados em rotação

2️⃣ SMF em log stream (z/OS moderno)

• Via System Logger

• Mais seguro

• Mais escalável

📌 Easter egg:
Quem ainda lê MANx direto está vivendo perigosamente.

---

3️⃣ Tipos de SMF mais usados (tradução prática)

Tipo SMF	Para quê serve
30	Uso de CPU por job
70–78	RMF (capacidade, CPU, I/O)
80	Segurança
110	CICS
116	MQ
120	WebSphere
122	DB2

🔥 Comentário:
Distribuído chama isso de “telemetria”.
Você chama de SMF desde sempre.

---

4️⃣ Extração clássica: IFASMFDP (o velho confiável) 🛠️

O utilitário padrão para descarregar SMF é o IFASMFDP.

Exemplo básico de JCL para extrair SMF

//SMFDUMP  JOB (ACCT),'EXTRAI SMF',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IFASMFDP
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DUMP OUTDD(DUMP1,TYPE(116))
/*
//DUMP1    DD DSN=USER.SMF.MQ.DUMP,
//             DISP=(NEW,CATLG),
//             SPACE=(CYL,(50,10)),
//             DCB=(RECFM=VB,LRECL=32756)

📌 O que isso faz:
Extrai SMF tipo 116 (IBM MQ) para um dataset legível por programas de análise.

😈 Easter egg:
Esse “DUMP” é mais útil que muito core file moderno.

---

5️⃣ Extraindo de Log Stream (modo adulto) 🚀

Quando SMF está no System Logger, usa-se:

//STEP1 EXEC PGM=IFASMFDP
//SYSIN DD *
  DUMP FROM(LOGSTREAM)
       LOGSTREAM(SMF.LOGSTREAM.NAME)
       OUTDD(DUMP1)
       TYPE(30,70,116)
/*

🔥 Comentário Bellacosa:
Se você usa log stream, você dorme melhor.

---

6️⃣ Como “baixar” SMF para fora do mainframe 🌍

Depois de extrair para dataset:

Opções clássicas:

• FTP (modo binary!)

• SFTP

• NDM

• Tools corporativas

📌 Regra sagrada:
Nunca transfira SMF em ASCII.

😈 Easter egg traumático:
SMF convertido errado vira ficção científica.

---

7️⃣ Como ler SMF (spoiler: não é com os olhos) 👀

SMF não é texto.
Você precisa de:

• Sort (DFSORT)

• Programas de leitura

• Ferramentas (IBM, vendor ou caseiras)

Exemplo simples com DFSORT (filtrando registros)

//SORTSMF EXEC PGM=SORT
//SYSOUT  DD SYSOUT=*
//SORTIN  DD DSN=USER.SMF.MQ.DUMP,DISP=SHR
//SORTOUT DD DSN=USER.SMF.MQ.FILTRADO,
//            DISP=(NEW,CATLG),
//            SPACE=(CYL,(20,5))
//SYSIN   DD *
  SORT FIELDS=COPY
/*

📌 Comentário:
Sort é o SQL original do mainframe.

---

8️⃣ Lendo SMF como observabilidade distribuída 🧠

Mentalidade correta:

• Não leia registro isolado

• Monte linha do tempo

• Correlacione com:

  • batch

  • CICS

  • MQ

  • APIs

🔥 Tradução Bellacosa:
Trace distribuído = SMF correlacionado.

---

9️⃣ Erros clássicos (não faça isso) ⚠️

❌ Ler SMF sem objetivo
❌ Ajustar sistema sem evidência
❌ Ignorar horário
❌ Confiar só em alertas
❌ Jogar fora dados históricos

😈 Comentário ácido:
Quem não guarda SMF está escolhendo não aprender.

---

🔟 Guia de estudo para mainframers curiosos 📚

Conceitos

• SMF architecture

• RMF

• Capacity planning

• Mensageria (MQ)

• Observabilidade

Exercício Bellacosa

👉 Extraia SMF tipo 116
👉 Monte timeline de PUT/GET
👉 Compare com fila crescendo

---

🎯 Aplicações reais desse conhecimento

• Performance tuning

• Diagnóstico de incidentes

• Auditoria

• Integração mainframe-cloud

• SRE corporativo

---

🖤 Epílogo — 02:58, tudo explicado

Cloud vende visibilidade.
Mainframe sempre entregou evidência.

El Jefe Midnight Lunch assina:
“SMF não é difícil. Difícil é trabalhar sem ele.”

 

 

Cics filas TSQ e TDQ passagem de dados

🔥 Understanding QUEUE, TSQ e TDQ no CICS

 

---

☕ Midnight Lunch, fila cheia e CICS aberto

Todo mainframer já passou por isso: programa CICS travado, usuário reclamando, operador olhando o CEMT, e alguém solta a clássica pergunta:

“Isso aí não é fila? TSQ ou TDQ?”

E o silêncio toma conta do data center.
Vamos resolver isso de vez, no estilo Bellacosa: com história, conceito, prática, fofoca técnica e alguns easter eggs de quem já levou AEI0 na testa.

---

🏛️ Um pouco de história: filas antes da nuvem

Antes de Kafka, Redis, RabbitMQ e afins, o CICS já sabia lidar com filas.
Desde os anos 70, IBM introduziu mecanismos simples, rápidos e extremamente eficientes para armazenar dados temporários ou sequenciais durante a execução de transações online.

Esses mecanismos são chamados genericamente de QUEUE, mas na prática se dividem em:

• TSQ – Temporary Storage Queue

• TDQ – Transient Data Queue

Ambos são filas, mas com propósitos, comportamentos e riscos bem diferentes.

---

🧠 Conceito-chave (guarde isso como mantra)

TSQ = memória temporária, aleatória, flexível
TDQ = fluxo sequencial, estilo arquivo/log, orientado a eventos

Se você entendeu isso, já está 50% certificado CICS 😄

---

📦 TSQ – Temporary Storage Queue

O que é?

Uma fila temporária de armazenamento usada por programas CICS para guardar dados durante ou entre transações.

Ela pode residir:

• Em memória (MAIN)

• Em disco (AUX – VSAM)

Características

✔ Acesso direto por item
✔ Pode ler, escrever, atualizar e apagar
✔ Pode sobreviver ao fim da transação
✔ Pode ser compartilhada entre programas

Comandos principais

EXEC CICS WRITEQ TS
EXEC CICS READQ TS
EXEC CICS DELETEQ TS

Exemplo mental (Bellacosa way)

Imagine um post-it compartilhado entre programas CICS:

• Programa A escreve dados

• Programa B lê

• Programa C atualiza

• Programa D apaga

Tudo rápido, sem I/O pesado.

---

⚠️ Armadilhas clássicas (easter eggs)

• TSQ esquecida = vazamento de storage

• Nome dinâmico mal feito = fila órfã

• Volume alto em MAIN = SOS no CEMT I TASK

📌 Dica de ouro: sempre pense em DELETEQ TS.

---

🧾 TDQ – Transient Data Queue

O que é?

Uma fila sequencial, orientada a eventos, muito usada como:

• Log

• Interface com batch

• Comunicação com sistemas externos

Tipos de TDQ

1. Intrapartition TDQ

   • Dentro do CICS

   • Uma única partição

2. Extrapartition TDQ

   • Fora do CICS

   • Geralmente associada a um dataset sequencial

---

Características

✔ Escrita sequencial
✔ Leitura normalmente sequencial
✔ Ideal para log e integração
❌ Não permite acesso aleatório
❌ Não é feita para update

Comandos principais

EXEC CICS WRITEQ TD
EXEC CICS READQ TD

---

Exemplo prático

• Transação online grava eventos em TDQ

• Job batch lê essa TDQ depois

• Processamento assíncrono elegante, old school e eficiente

📌 Isso é o avô espiritual do streaming moderno.

---

🥊 TSQ vs TDQ – Luta no octógono

Critério	TSQ	TDQ
Tipo	Temporária	Sequencial
Acesso	Aleatório	Sequencial
Uso típico	Work area, cache	Log, interface
Performance	Muito alta	Alta
Persistência	Configurável	Depende do tipo
Risco comum	Storage leak	Fila parada

---

🛠️ Passo a passo mental (como escolher)

1️⃣ Preciso acessar dados fora de ordem? → TSQ
2️⃣ Preciso registrar eventos/logs? → TDQ
3️⃣ Comunicação com batch? → TDQ extrapartition
4️⃣ Compartilhar estado entre transações? → TSQ

---

📚 Guia de estudo para mainframers

Se você quer dominar filas no CICS, estude:

• Storage Management (MAIN vs AUX)

• CEMT I TSQUEUE / TDQUEUE

• Recovery e rollback

• CICS Logging e Journals

• Integração TSQ + MQ (sim, isso acontece)

📖 Manual-chave: CICS Application Programming Guide

---

🤓 Curiosidades de boteco mainframe

🍺 TSQ já foi usada como cache improvisado antes de DB2
🍺 TDQ era chamada de “log dos pobres” nos anos 80
🍺 Muitos sistemas críticos ainda rodam com TDQ + batch noturno
🍺 Já existiram sistemas bancários inteiros baseados em TSQ (não recomendado 😅)

---

💬 Comentário El Jefe Midnight Lunch

“Enquanto o mundo redescobre filas com nomes modernos,
o CICS continua servindo café quente, confiável e previsível
desde antes de você nascer.”

---

🚀 Aplicações modernas (sim, ainda hoje)

• Core bancário

• Sistemas de cartão

• Logs de auditoria

• Integração com MQ e APIs

• Work areas de alta performance

---

🎯 Conclusão Bellacosa

TSQ e TDQ não são relíquias.
São armas cirúrgicas, feitas para problemas específicos.

Quem sabe usar:

• Escreve código mais rápido

• Evita gargalos

• Dorme tranquilo quando o CICS sobe

🔥 CICS não é velho. Velho é quem não entende fila.