Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

 

Bellacosa Mainframe e o grande desafio de tunar um mainframe Zos com software legado

🍔💾 Essential z/OS Performance Tuning Workshop

Quando performance deixa de ser fé e vira engenharia

No mundo distribuído, performance costuma ser tratada como magia:
“sobe mais recurso”, “escala automático”, “reinicia o serviço”.

No mainframe, isso nunca existiu.

Aqui, performance sempre foi disciplina, observação e responsabilidade.
E é exatamente isso que o Essential z/OS Performance Tuning Workshop carrega no DNA.

Não é um curso para “deixar tudo rápido”.
É um treinamento para não fazer besteira em produção.

---

🧠 Um workshop que nasceu da dor (e do custo de CPU)

Quando o z/OS ainda se chamava MVS, cada ciclo de CPU custava dinheiro real.
Não existia elasticidade, nem desculpa técnica.

Se o sistema ficava lento, alguém tinha que explicar:

• por quê

• onde

• quem causou

• como evitar de novo

O Essential z/OS Performance Tuning Workshop surge dessa escola:
a escola em que medir vem antes de mexer, e mexer sem entender é pecado mortal.

---

🎯 O que o workshop realmente ensina (sem PowerPoint bonito)

👉 Performance não é velocidade

Performance é cumprir SLA de forma previsível.

O workshop deixa isso claro logo cedo:

• CPU a 90% não é problema, se o response time está estável

• Sistema “folgado” pode estar mal configurado

• Pico não é tendência

Aqui, aprende-se a ler o sistema como um organismo, não como um gráfico isolado.

---

⚙️ Os pilares do workshop (onde a verdade mora)

🧩 WLM – Workload Manager

O verdadeiro cérebro do z/OS.

No workshop, cai a ficha:

WLM não é tuning técnico. É política de negócio codificada.

• Service Class errada = prioridade errada

• Prioridade errada = usuário certo reclamando

• Ajuste sem alinhamento = guerra interna

📌 Easter egg clássico:
O WLM sempre faz exatamente o que você mandou.
O problema é quando você mandou errado.

---

📊 RMF – onde a mentira não sobrevive

RMF é tratado como deve ser:

• Monitor III → o agora

• Monitor II → o culpado

• Postprocessor → a história que não pode ser reescrita

O workshop ensina algo raro hoje em dia:

Contexto importa mais que screenshot.

Um gráfico sem horário, workload e mudança recente é só arte abstrata.

---

🗃️ SMF – a caixa-preta do sistema

Aqui o tuning vira investigação.

SMF:

• Não opina

• Não sugere

• Não perdoa

Quem aprende a ler SMF sai do workshop com um superpoder:
parar discussões baseadas em achismo.

---

⚠️ Desafios reais abordados (aqueles que ninguém gosta de admitir)

🔥 “Todo mundo é crítico”

Ambiente compartilhado, dezenas de sistemas, todos “prioridade máxima”.

O workshop ensina a separar:

• workload crítico

• workload importante

• workload barulhento

💡 Easter egg corporativo:
O sistema mais crítico quase nunca é o que mais grita.

---

🔥 Falta de baseline

Sem baseline:

• não existe “piorou”

• só existe “sensação”

Frase implícita do workshop:

Tuning sem baseline é tuning religioso.

---

🔥 A pressão do “só ajusta rapidinho”

Nada gera mais legado tóxico do que tuning feito:

• em incidente

• sem análise

• para agradar gestor

O workshop ensina algo valioso:

Saber dizer NÃO, com métrica na mão.

---

🚀 O que muda depois do workshop

Quem passa por esse treinamento:

• Para de tunar por instinto

• Começa a observar antes de agir

• Aprende a prever gargalos

• Ganha respeito em incidente sério

No mercado, isso tem um efeito curioso:

Profissional que entende performance em z/OS não fica sem emprego.
Fica sem tempo.

---

🕹️ Easter eggs nível CPD

• CPU alta pode ser sinal de sistema saudável

• O melhor tuning, às vezes, é não mexer

• Se o sistema só é lento em horário comercial, o problema raramente é técnico

• Performance tuning é 70% política e 30% tecnologia

---

🧠 Conclusão – a frase que devia estar na parede do CPD

“z/OS não é lento.
Lento é quem não entende o que está medindo.”

O Essential z/OS Performance Tuning Workshop não ensina truques.
Ensina responsabilidade técnica.

E isso, em qualquer geração de tecnologia, continua raro.

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

 

Bellacosa Mainframe e o conceito de single source of truth

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

Se existe um conceito que todo arquiteto, analista, DBA, operador e até estagiário já ouviu — e todo mundo acha que já tem — esse conceito é o tal do Single Source of Truth.
Spoiler: quase ninguém tem de verdade. E no mainframe isso é ainda mais sagrado (e mais difícil).

Senta que lá vem história.

---

🧠 Origem: quando a verdade ainda cabia em um arquivo VSAM

Antes de buzzwords, cloud, data mesh e dashboards coloridos, o SSOT já existia — só não tinha nome chique.

Nos anos 60/70, no mundo IBM Mainframe, a regra era simples:

“Existe um dado oficial. O resto é cópia, relatório ou dor de cabeça.”

• Um master file VSAM

• Um DB2 table owner bem definido

• Um CICS que mandava na regra de negócio

Se o saldo do cliente estava no arquivo X, qualquer outro valor estava errado, não “divergente”.

👉 Isso era SSOT by design, não por moda.

---

📜 Definição curta (para colar na parede da sala)

Single Source of Truth é a fonte única, autorizada e confiável de um dado, regra ou estado de negócio.

• Não é só onde o dado está

• É quem manda nele

• É quem pode mudar

• É quem responde quando dá problema

No mainframe, isso sempre foi levado a sério porque…
💸 erro de dado = dinheiro real sumindo.

---

🏗️ SSOT no Mainframe: raiz forte, galhos controlados

No mundo IBM Mainframe, o SSOT normalmente assume estas formas:

• 📦 DB2 → verdade transacional

• 📁 VSAM KSDS/ESDS → registros mestres históricos

• 🧠 CICS → verdade das regras online

• 📊 SMF/RMF → verdade operacional

• 🔐 RACF → verdade de segurança (e ponto final)

E aqui vai a regra de ouro, estilo Bellacosa:

Se dois sistemas “mandam” no mesmo dado… nenhum manda.

---

⚠️ O problema moderno: todo mundo quer sua própria verdade

Com a chegada de:

• Data Lakes

• BI Self-Service

• Microservices

• Replicações near-real-time

• APIs para tudo

Nasceu o monstro de três cabeças:

🧟 A Verdade Paralela
🧟 A Verdade de Cache
🧟 A Verdade do PowerPoint

Cada área passa a ter:

• “Meu dado”

• “Meu relatório”

• “Minha métrica”

E quando os números não batem…

👉 a culpa é do mainframe, claro 😏

---

🧩 Formatos de SSOT (sim, existem vários)

1️⃣ SSOT Transacional

• Fonte: DB2 / CICS

• Uso: sistemas core

• Alta integridade

• Baixa tolerância a erro

💡 Mainframe é rei aqui.

---

2️⃣ SSOT Analítico

• Fonte: DW / Lakehouse

• Uso: BI, KPIs

• Risco: latência e transformação

⚠️ Não confundir com verdade operacional.

---

3️⃣ SSOT de Configuração

• Fonte: repositórios únicos

• Ex: parâmetros, tabelas de domínio

🧨 Dica: tabela “copiada” em cada sistema não é SSOT.

---

4️⃣ SSOT de Governança

• Catálogos de dados

• Data lineage

• Glossário corporativo

📚 Onde a verdade é documentada, não só armazenada.

---

🛠️ Dicas práticas (da trincheira, não do slide)

✔️ Defina ownership real

“Quem acorda às 3h da manhã se der erro?”

✔️ Separe dado de consumo

• Origem ≠ réplica ≠ cache

✔️ Documente a verdade

• Se não está escrito, vira lenda urbana.

✔️ Controle quem escreve

• Ler é democrático. Escrever não.

✔️ Mainframe como âncora

• Sistemas modernos orbitam. O core não flutua.

---

💣 Riscos clássicos (a lista da vergonha)

• ❌ Duas bases “oficiais”

• ❌ ETL que “corrige” dado

• ❌ BI explicando divergência em reunião

• ❌ Regra de negócio fora do core

• ❌ “É só um relatório…”

⚠️ Relatório nunca é inocente.

---

🧪 Curiosidades & Easter Eggs

🥚 Easter Egg #1

Muitos sistemas “modernos” recriam SSOT… e descobrem 30 anos depois o que o CICS já fazia.

🥚 Easter Egg #2

RACF é um dos SSOTs mais respeitados da empresa — ninguém questiona.

🥚 Easter Egg #3

O termo SSOT ficou famoso com BI, mas nasceu no batch noturno.

---

🧠 Reflexão final (El Jefe mode ON)

SSOT não é tecnologia.
É disciplina organizacional.

Você pode ter:

• Cloud

• Kafka

• Lakehouse

• AI

• Dashboard bonito

Mas se não souber qual dado é o oficial…

👉 Você só tem várias mentiras bem organizadas.

---

☕🌙 Midnight Lunch Thought
No fim do dia (ou da madrugada):
quem controla a verdade controla o sistema.
E historicamente…
o mainframe sempre soube disso.

 

Bellacosa Mainframe o desafio moderno COBOL e IA

🤖💾 COBOL + IA: casamento arranjado ou parceria madura?

Existe uma tentação moderna rondando os data centers desde que alguém colocou “AI” num slide de PowerPoint:
👉 “E se a gente colocasse inteligência artificial direto no COBOL?”

Spoiler de quem já sobreviveu a mais de um hype tecnológico: não é uma boa ideia.
E não, isso não é conservadorismo mainframeiro — é arquitetura com cicatriz de guerra.

---

📜 Um pouco de história (porque tudo no mainframe tem passado)

COBOL nasceu no fim dos anos 50 com uma missão muito clara:
ser previsível, auditável e chato no melhor sentido possível.

• Bancos confiaram nele dinheiro.

• Governos confiaram nele cidadãos.

• Seguradoras confiaram nele contratos de décadas.

Já a IA moderna nasce de outro DNA:

• Probabilística

• Estatística

• Mutável

• Não determinística

👉 Misturar os dois no mesmo código é como pedir para o auditor dormir tranquilo enquanto um modelo muda de comportamento a cada re-treino.

Easter egg histórico 🥚

O maior elogio que você pode fazer a um sistema COBOL é:
“Ele roda há 20 anos e ninguém mexe.”
Tente dizer isso de um modelo de IA. 😏

---

🧠 Mundos diferentes, responsabilidades diferentes

Vamos ser adultos arquiteturalmente:

• COBOL

  • Regras de negócio

  • Transações

  • Commit, rollback, ACID

  • Responsabilidade legal

• IA

  • Scores

  • Classificações

  • Previsões

  • Recomendações

👉 IA sugere. COBOL decide.

Esse é o ponto que muita empresa ignora… até o primeiro incidente regulatório.

---

🏗️ A arquitetura que funciona (e não vira Frankenstein)

A prática vencedora no mundo real é simples e elegante:

❌ IA embutida no código COBOL
✅ IA como serviço externo (API, REST, MQ, gRPC, escolha sua arma)
✅ COBOL como orquestrador e Single Source of Truth

COBOL chama, recebe, valida, registra, decide.
A IA não manda, não grava livro razão, não fecha transação.

Dica Bellacosa 🔧

Se a decisão precisa ser explicada para um auditor, ela não pode estar “dentro de um modelo”.

---

🏦 Casos reais (não são slides, são sistemas vivos)

• Bancos
  COBOL processa pagamentos.
  IA calcula fraud-score.
  Quem bloqueia a transação? 👉 COBOL.

• Seguradoras
  COBOL governa apólices.
  IA classifica sinistros (imagem, texto, padrão).
  Quem aprova? 👉 COBOL.

• Governo
  COBOL mantém o processo.
  IA lê documentos e sugere filas.
  Quem decide? 👉 COBOL (e um humano).

• Varejo
  COBOL fecha pedido.
  IA prevê demanda.
  Quem assina o estoque? 👉 COBOL.

---

⚠️ Desafios e riscos que ninguém coloca no slide

🚨 Riscos técnicos

• Model drift silencioso

• Resultados não reproduzíveis

• Falta de versionamento lógico de decisões

• Debug impossível (“o modelo achou” não é log)

🚨 Riscos organizacionais

• Times sem dono claro da decisão

• Dev achando que “a IA decide”

• Dependência excessiva de vendor/modelo

🚨 Riscos regulatórios

• LGPD / GDPR

• Explainability

• Auditoria

• Responsabilização jurídica

Comentário ácido (com amor) ☕

“A IA decidiu” não é aceito como resposta em tribunal.
Mas “o sistema core autorizou” é.

---

🎮 Easter Eggs para mainframeiros

• COBOL já fazia “decision service” antes de virar moda:
  👉 CALL ‘PROGRAM’ USING COMM-AREA 😄

• MQ sempre foi o avô do desacoplamento moderno.

• Batch noturno + IA em tempo real = yin e yang corporativo.

• O mainframe não é legacy. Legacy é arquitetura ruim.

---

🔍 Análise SWOT – COBOL + IA

✅ Strengths (Forças)

• Estabilidade transacional

• Confiabilidade comprovada

• Governança clara

• Auditoria e rastreabilidade

⚠️ Weaknesses (Fraquezas)

• Falta de profissionais híbridos

• Integração mal feita vira gargalo

• Latência se arquitetura for mal desenhada

🚀 Opportunities (Oportunidades)

• COBOL como Business Layer Inteligente

• Modernização sem reescrita

• IA plugável, substituível, versionável

• Mainframe como hub decisório

💣 Threats (Ameaças)

• Vendor lock-in de IA

• “AI washing” corporativo

• Decisões críticas fora do core

• Pressão por atalhos arquiteturais

---

🧭 Conclusão de quem já viu moda passar

COBOL não está atrasado para IA.
COBOL está exatamente onde deveria estar.

Ele não precisa ser inteligente.
Ele precisa ser responsável.

A arquitetura vencedora do futuro não é:
❌ COBOL ou IA

É:
✅ COBOL + IA, cada um no seu papel.

Tudo fora disso pode até ser tecnicamente empolgante…
mas operacionalmente, juridicamente e regulatoriamente?
👉 Almoço grátis que vira jantar caro.

---

☕ El Jefe – Midnight Lunch
Porque arquitetura se decide melhor quando o sistema está rodando…
e o café ainda está quente.

 

☕ Um Café no Bellacosa Mainframe – Storage que não morre, só evolui

---

📼 IBM LTO-10 Ultrium: quando 40TB cabem em um cartucho (e o mainframe sorri)

Se você acha que fita magnética é coisa de museu, sente-se confortavelmente, pegue seu café ☕ e venha comigo. A IBM acaba de apresentar os novos cartuchos IBM LTO-10 Ultrium, modelos 564 e 664, trazendo 40TB por cartucho e reafirmando uma verdade inconveniente para o mundo cloud-only:

storage em fita nunca morreu — ele só ficou mais inteligente, mais denso e mais confiável.

---

🧠 Conceito técnico – o que é LTO Ultrium, afinal?

LTO (Linear Tape-Open) é um padrão aberto de armazenamento em fita, criado no fim dos anos 90 por IBM, HP e Seagate, com um objetivo claro:
👉 substituir soluções proprietárias caras por um padrão robusto, escalável e de longo prazo.

No mundo mainframe, LTO convive muito bem com:

• DFSMShsm

• TSM / Spectrum Protect

• z/OS, AIX, Linux on Z

• Ambientes híbridos (cloud + on-prem)

---

🚀 LTO-10 Ultrium – o salto técnico

A geração LTO-10 representa um avanço brutal em densidade e confiabilidade.

🔹 Destaques técnicos

• Capacidade nativa: 40TB por cartucho

• Compatibilidade: drives IBM LTO Ultrium 10

• Uso típico: backup, archive, cyber-vault, air-gap

• Performance: pensada para ambientes corporativos e mainframe-grade

💡 Lembre-se: fita não compete com SSD — ela resolve outro problema: retenção, custo por TB e proteção contra ransomware.

---

📦 Os novos modelos IBM

🟦 Model 564

• IBM LTO-10 Ultrium 40TB Data Cartridge

• Pacote com 20 cartuchos

• Com etiquetas

• Volume serial inicial definido

• Ideal para ambientes mainframe, bibliotecas automatizadas e controle rigoroso de mídia

🧠 Perfeito para quem ainda sabe o valor de um bom VOLSER bem planejado.

---

🟩 Model 664

• IBM LTO-10 Ultrium 40TB Data Cartridge

• Disponível em:

  • 20-pack

  • 5-pack

• Sem etiquetas

• Mais flexível para ambientes distribuídos ou etiquetagem customizada

---

🏛️ Um pouco de história – fita é raiz de mainframe

No mainframe, fita sempre foi:

• Backup confiável

• Arquivo regulatório

• Última linha de defesa

Dos rolo aberto aos 3480, 3490, 3590, até o LTO moderno, a fita evoluiu silenciosamente enquanto o resto do mundo brigava por IOPS.

🕰️ Curiosidade histórica:
o primeiro backup corporativo confiável do mundo foi feito em fita — e isso não mudou até hoje.

---

🛡️ Segurança & Ransomware – o retorno do “air-gap”

Aqui está o ponto onde LTO-10 brilha forte:

• Cartucho offline

• Imune a ataque remoto

• Ideal para cyber-vault

• Atende compliance pesado (banco, governo, saúde)

🔐 O ransomware odeia fita porque fita não responde a ping.

---

🧪 Exemplo prático (mundo real)

Imagine um ambiente z/OS com:

• 300TB de dados históricos

• Retenção de 7 anos

• Backup diário + full semanal

Com LTO-10 (40TB):

• Menos cartuchos

• Menos movimentação física

• Menor custo por TB

• Melhor controle operacional

📊 Resultado: menos stress, menos mídia, mais previsibilidade.

---

🧙 Easter eggs & fofoquices do datacenter

🥚 Easter egg #1:
Apesar do nome “open”, quem domina LTO em escala sempre foi a IBM (principalmente em ambientes mainframe).

🥚 Easter egg #2:
Enquanto o mundo fala em “green IT”, fita sempre foi o storage mais sustentável: baixo consumo, longa vida útil, zero energia quando parada.

🥚 Fofoquinha:
Muita empresa correu para cloud… e voltou para fita quando a fatura mensal começou a parecer um extrato do cartão black 😄

---

🗣️ Comentário Bellacosa Mainframe™

“Storage bom é aquele que você só lembra quando dá problema.
E fita… simplesmente não dá problema.”

O IBM LTO-10 Ultrium prova que mainframe não vive de nostalgia, vive de engenharia séria, previsibilidade e custo controlado.

---

🧩 Conclusão

Os novos cartuchos IBM LTO-10 modelos 564 e 664 não são apenas “mais capacidade”.
Eles são:

• Continuidade de uma história sólida

• Resposta moderna a ransomware

• Prova de que legacy ≠ obsoleto

☕ Se você cuida de dados críticos, compliance pesado ou simplesmente gosta de dormir tranquilo… fita ainda é sua melhor amiga.

---

 

Bellacosa Mainframe apresenta o tape libraries automatizado

☕ Um Café no Bellacosa Mainframe – Guia Prático de Fita no z/OS

---

📼 Guia prático de fita/cartridge no z/OS

(para quem já apanhou de VOLSER, SMS e HSM… ou vai apanhar)

Se tem uma coisa que todo mainframeiro aprende cedo ou tarde é que fita no z/OS não é só “backup”.
É política, automação, performance, custo, compliance… e um pouco de fé 😄

Vamos ao guia prático, direto ao ponto, no melhor estilo Bellacosa Mainframe.

---

1️⃣ Conceito básico – fita no z/OS não é só hardware

No z/OS, fita envolve três mundos trabalhando juntos:

• 🧠 Sistema Operacional (z/OS)

• 🧩 SMS (DFSMS)

• 🤖 Gerenciador de backup (DFSMShsm / Spectrum Protect)

📌 Regra de ouro:

Se a política estiver errada, não existe cartucho LTO-10 que salve.

---

2️⃣ Tipos de fita no z/OS

🔹 Fita real (tape físico)

• LTO, TS11xx, etc

• Biblioteca robótica

• Drive dedicado ou compartilhado

🔹 Fita virtual (VTS / VTL)

• Emula fita

• Backend em disco ou objeto

• Performance absurda, mas não é air-gap

🧠 Dica Bellacosa:

Ambiente grande sempre usa virtual + físico. Um sem o outro é pecado técnico.

---

3️⃣ Componentes principais (anota aí, padawan)

📦 Cartucho

• Ex: LTO-10 Ultrium 40TB

• Identificado por VOLSER

• Pode ser rotulado (SL) ou não rotulado (NL)

🏷️ Label

• SL (Standard Label) – o mais comum

• NL (No Label) – só para quem sabe muito bem o que está fazendo

🔢 VOLSER

• Nome do cartucho (6 caracteres)

• Ex: LTO001, BK2026

🥚 Easter egg:
VOLSER mal planejado vira caos operacional em 6 meses.

---

4️⃣ SMS e fita – onde tudo pode dar errado

🧩 Storage Class

Define:

• Se pode ir para fita

• Performance

• QoS

🗂️ Data Class

Define:

• LRECL, RECFM

• Se pode ser estendido

• Tipo de dataset

📜 Management Class (o coração da fita)

Define:

• Migração

• Backup

• Retenção

• Expiração

📌 Exemplo clássico

Primary Days Non-Usage: 5
Secondary Days Non-Usage: 30
Expire After Days: 365

☕ Tradução Bellacosa:

“Depois de 5 dias sem usar, manda pra fita.
Depois de 1 ano, pode morrer em paz.”

---

5️⃣ DFSMShsm – o dono da fita no z/OS

Se você usa z/OS, você usa HSM, mesmo que não saiba.

🛠️ O que ele faz

• Backup

• Migração

• Recall

• Expiração

• Controle de catálogo

🔑 Comandos essenciais

HSM LIST TAPE
HSM LIST BACKUP
HSM QUERY MIGRATION
HSM RELEASE

🥚 Easter egg:
Quando o recall demora, não xingue o HSM primeiro. Veja drive, robô e concorrência.

---

6️⃣ JCL básico gravando em fita

✍️ Exemplo simples

//STEP1   EXEC PGM=IEBGENER
//SYSUT1  DD  DSN=MEU.ARQUIVO.INPUT,DISP=SHR
//SYSUT2  DD  DSN=MEU.ARQUIVO.TAPE,
//            DISP=(NEW,KEEP),
//            UNIT=TAPE,
//            LABEL=(1,SL),
//            VOL=SER=LT0010
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DUMMY

🧠 Dica:

Hoje quase ninguém codifica VOL=SER fixo.
Deixe o SMS escolher — ele sabe mais que você (e não esquece).

---

7️⃣ Bibliotecas robóticas – o “braço invisível”

No z/OS moderno:

• Robô monta

• Robô desmonta

• Operador só observa

⚠️ Erro comum de iniciante:
Pensar que fita é lenta.
👉 Lento é drive disputado.

---

8️⃣ Performance – sim, fita pode ser rápida

• Streaming contínuo = performance boa

• Muitos arquivos pequenos = sofrimento

🧠 Dica avançada:

Agrupe dados antes de gravar em fita.
Fita odeia stop/start.

---

9️⃣ Segurança e ransomware

Fita no z/OS é:

• Offline

• Isolada

• Confiável

🔐 Estratégia moderna:

• Backup diário em VTL

• Cópia semanal para fita física

• Cartucho fora do datacenter

☕ Isso se chama sobreviver a segunda-feira.

---

🔟 Erros clássicos (todos já cometemos)

❌ VOLSER sem padrão
❌ Retenção mal definida
❌ Fita virando “lixeira eterna”
❌ Esquecer limpeza de drive
❌ Achar que cloud substitui tudo

---

🗣️ Comentário final Bellacosa Mainframe™

“Quem domina fita, domina o tempo.
Porque dado velho também vale dinheiro.”

Fita no z/OS não é legado.
É engenharia, processo e maturidade operacional.

 

Bellacosa Mainframe apresenta o HSM e DFSMS

☕ Um Café no Bellacosa Mainframe – HSM: o zelador invisível do z/OS

---

🧠 O que é HSM e DFSMShsm no IBM Mainframe z/OS

(ou: quem realmente manda nos seus discos enquanto você dorme)

Se você trabalha com IBM Mainframe z/OS e acha que HSM é só “backup automático”, sinto dizer:
👉 você está usando um Ferrari para ir à padaria.

Hoje vamos falar de HSM e do lendário DFSMShsm, no melhor estilo Bellacosa Mainframe: técnico, histórico, com fofoca, easter egg e aquela verdade que ninguém gosta de ouvir 😄

---

🧩 Conceito básico – o que é HSM?

HSM (Hierarchical Storage Management) é o conceito de gerenciamento hierárquico de armazenamento.

Em bom português mainframeiro:

“Colocar o dado certo, no lugar certo, pelo tempo certo, no custo certo.”

No z/OS, quem implementa isso é o DFSMShsm.

---

🏛️ O que é DFSMShsm?

DFSMShsm (Data Facility Storage Management Subsystem – Hierarchical Storage Manager) é um subsystem do DFSMS responsável por:

• Backup

• Migração

• Recall

• Expiração

• Gerenciamento de fita

• Liberação automática de espaço em disco

📌 Importante:
DFSMShsm não é um produto opcional “legalzinho” — ele é parte estrutural do z/OS moderno.

---

🕰️ Origem e história – HSM é mais velho que você imagina

• Década de 1970: IBM já lidava com o problema de disco caro

• Surgem os primeiros conceitos de hierarquia de storage

• Anos 80: nasce o HSM para MVS

• Anos 90: integração total com SMS

• Hoje: HSM segue firme no z/OS, convivendo com cloud, VTL e LTO-10

🥚 Easter egg histórico:

O conceito de tiering moderno (hot, warm, cold data) nasceu no mainframe, não na nuvem.

---

🧠 Como o DFSMShsm funciona (visão prática)

Ele observa:

• Uso do dataset

• Política definida no SMS

• Espaço disponível

• Prioridade

E toma decisões sozinho.

Ele pode:

• Migrar dataset para fita

• Criar backups automáticos

• Trazer dados de volta (recall)

• Apagar dados vencidos

☕ Sem pedir sua opinião.

---

📦 O que o HSM armazena?

🔹 Em disco (DASD)

• Dados ativos

• Dados recém-criados

🔹 Em fita

• Dados migrados

• Backups

• Dados raramente acessados

• Histórico e compliance

📌 Tudo catalogado, tudo controlado.

---

🧾 Tipos de operação do DFSMShsm

🔄 Migração

• Move dados pouco usados para fita

• Mantém um “stub” no catálogo

🔙 Recall

• Usuário acessa dataset

• HSM busca na fita automaticamente

💾 Backup

• Incremental

• Full

• Versionado

🧹 Expiração

• Remove dados vencidos

• Libera espaço físico

---

🧪 Exemplo prático (mundo real)

📁 Dataset: FIN.RELATORIOS.2019

• 180 dias sem uso

• Management Class diz: migrar

• HSM envia para fita

• Dataset continua “existindo”

👨‍💻 Usuário acessa em 2026:

• HSM faz recall

• Usuário acha que “sempre esteve ali”

• Operador sorri 😄

---

🧾 Exemplo de política SMS (simplificado)

Primary Days Non-Usage: 7
Secondary Days Non-Usage: 60
Expire After Days: 1825

☕ Tradução Bellacosa:

7 dias quente
60 dias morno
Depois disso… fita e paz eterna por 5 anos

---

🔧 Comandos essenciais do HSM

HSM LIST BACKUP
HSM LIST MIGRATION
HSM QUERY ACTIVE
HSM RELEASE
HSM RECOVER

🥚 Easter egg:
Se você nunca usou HSM QUERY, você confia demais 😄

---

🪜 Passo a passo – HSM funcionando na prática

1️⃣ Dataset é criado com SMS
2️⃣ Management Class define política
3️⃣ Usuário para de usar
4️⃣ HSM migra automaticamente
5️⃣ Backup é feito conforme agenda
6️⃣ Expiração limpa o que venceu

🎯 Tudo sem JCL manual, sem intervenção humana.

---

💪 Pontos fortes do DFSMShsm

✅ Automação extrema
✅ Economia de disco
✅ Integração total com z/OS
✅ Escalabilidade absurda
✅ Confiabilidade histórica
✅ Ideal para compliance e auditoria

---

⚠️ Pontos fracos (sim, eles existem)

❌ Curva de aprendizado
❌ Política mal feita vira desastre
❌ Recall em fita pode ser lento
❌ Dependência forte de SMS bem desenhado

☕ Verdade dura:

HSM ruim não é culpa do HSM — é culpa de quem configurou.

---

🧙 Curiosidades & Easter Eggs

🥚 O HSM já “salvou” mais empresa de crash de disco do que qualquer cloud
🥚 Muitas empresas usam HSM há 20 anos e nunca pararam para documentar
🥚 HSM é tão confiável que só é lembrado quando alguém desativa sem querer

---

🗣️ Comentário final Bellacosa Mainframe™

“DFSMShsm é como o síndico do prédio:
ninguém percebe, mas se ele falhar… o caos se instala.”

No IBM z/OS, HSM não é luxo, é sobrevivência operacional.