🧠 Padawan, aproxime-se do console… hoje o assunto é: Monitoramento de Disco no IBM Mainframe

 

Bellacosa Mainframe apresenta storage no ZOS

🧠 Padawan, aproxime-se do console… hoje o assunto é: Monitoramento de Disco no IBM Mainframe

(ou: como não deixar o DASD virar o Lado Sombrio da Força)

---

📜 Um pouco de história (porque no mainframe nada nasce ontem)

Antes de existir storage definido por software, cloud ou “é só aumentar o volume”, já existia DASD — Direct Access Storage Device.
Nos primórdios, isso significava discos gigantes, barulhentos, caríssimos e venerados 🛐.

👉 O mainframe sempre tratou disco como recurso nobre.
Nada de “joga log fora depois a gente vê”.

E aí entra o lendário…

---

IBM Mainframe unidade de disco 

💿 DASD – Direct Access Storage Device

No mundo z/OS, disco não é disco, é DASD.
E DASD tem personalidade, etiqueta e hierarquia.

Tipos clássicos

• 📀 3380 – Jurassic Park (ainda aparece em livro antigo)

• 💿 3390 – O padrão ouro (e nosso foco)

• 🧠 EAV / EAS – Extended Address Volumes (para os discos gigantes de hoje)

---

Unidade de disco 3390 antiga

🧱 O mito do 3390

📦 O que é um 3390?

Um modelo lógico de disco, não importa se o storage físico é:

• DS8K

• Flash

• NVMe disfarçado de DASD

👉 Para o z/OS, continua sendo um 3390, com:

• 📐 Trilhas

• 📊 Cylinders

• 🧮 Extents

Tamanhos clássicos

Tipo	Cylinders
3390-1	1.113
3390-3	3.339
3390-9	10.017
3390-27	32.760
EAV	milhões 😈

🧠 Easter Egg:

Mesmo em storage 100% flash, o z/OS ainda “pensa” em trilhas.
Legacy não morre, evolui.

---

👀 Por que monitorar DASD, Padawan?

Porque disco cheio não avisa com carinho.
Ele derruba job, trava aplicação e chama gerente.

Riscos clássicos

• 🚨 Volume acima de 85%

• 🚨 Fragmentação absurda

• 🚨 Catálogo estourado

• 🚨 Extents demais por dataset

• 🚨 Sorts falhando sem espaço temporário

---

🛠️ Ferramentas nativas (sem gastar um centavo)

📟 SDSF

Seu sabre de luz inicial.

Comandos úteis:

DA

ou

/D U,DASD,ONLINE

Você vê:

• Volume

• Device Type (3390)

• Online/Offline

• Uso geral

---

🧾 IDCAMS – O velho sábio

  LISTCAT LEVEL(SYS1) ALL

Ou para volumes:

  LISTCAT VOLUME(VOL001)

📌 Mostra:

• Quantos datasets

• Extents

• Fragmentação

• Catálogo

🧠 Easter Egg:

LISTCAT mal interpretado já causou pânico desnecessário em muito CPD.

---

🧪 DFSMS – O cérebro invisível

Se você usa:

• SMS

• Storage Groups

• Management Classes

Então o monitoramento precisa olhar:

• Storage Group cheio

• Pool desbalanceado

• Volumes quentes vs frios

Comandos:

D SMS,SG
D SMS,VOL

---

🧙‍♂️ Ferramentas corporativas (o lado premium da Força)

• IBM Tivoli / OMEGAMON

• BMC MainView

• Broadcom SYSVIEW

Essas ferramentas:

• Alertam antes do caos

• Criam gráficos bonitos

• Salvam operadores de madrugadas ruins ☕😵‍💫

---

📐 Métricas que todo Padawan deve decorar

🔢 Uso de volume

• 🟢 Até 70% → zen

• 🟡 70–85% → atenção

• 🔴 > 85% → reunião marcada

🧩 Fragmentação

• Muitos extents = performance ruim

• VSAM sofre mais que sequential

🧮 Extents

• Dataset com 200+ extents é pedido de REORG

• Antigamente: limite era dor e sofrimento

---

🧪 Exemplo real (história de guerra)

“O batch sempre rodou… até hoje.”

Motivo?

• Volume temporário (SORTWK) com 92%

• Job falha com:

IEC070I 112-112

Solução?

• Monitoramento

• Alocação dinâmica

• Limpeza automática

📌 Moral: disco cheio não falha… ele se vinga.

---

🧠 Curiosidades & Fofoquices de CPD

• 🔍 Muitos ambientes ainda usam um único volume SYSRES

• 🧓 Dataset criado em 1998 ainda rodando em produção

• 😅 Volume “temporário” com dados críticos

• 📦 Flash moderno, mas pensado como 3390-3

---

🧭 Dicas Bellacosa Mainframe™️

✔️ Nunca confie em volume acima de 80%
✔️ Monitore tendência, não só foto do momento
✔️ Volume “barato” é o que causa outage caro
✔️ Documente storage group (ninguém faz, todo mundo sofre)
✔️ Ensine o Padawan antes que ele vire Operador às 3h da manhã

---

🧩 Encerrando…

Monitorar DASD no mainframe não é só técnica —
é filosofia, história viva e respeito à máquina.

💬 “No mainframe, disco não acaba… ele avisa.
O problema é quando ninguém está ouvindo.”

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Runstats

🔷 RUNSTATS no DB2: Mantendo Estatísticas Sempre Frescas

No DB2 para IBM z/OS, RUNSTATS é a ferramenta que mantém o otimizador de consultas informado sobre os dados. Sem estatísticas precisas, o DB2 não consegue criar planos de execução eficientes, e suas queries podem ficar lentas ou pesadas.

---

🕰️ História e Origem

• Nos anos 80, com bancos de dados relacionais massivos da IBM, surgiu a necessidade de coletar informações sobre o volume e distribuição dos dados.

• O DB2 precisava de uma forma de “aprender” sobre tabelas e índices:

  • Quantas linhas existem

  • Quantas páginas são ocupadas

  • Distribuição dos valores em colunas

• Assim nasceu o RUNSTATS, permitindo que o otimizador de consultas escolha o melhor caminho de acesso.

Pense no RUNSTATS como alimentar o cérebro do DB2 para que ele saiba onde estão os dados e como acessá-los mais rápido.

---

⚙️ O que o RUNSTATS faz?

O RUNSTATS coleta estatísticas sobre tabelas e índices, incluindo:

1. Número de linhas

2. Número de páginas (clusters e extent)

3. Distribuição de valores em colunas (histogramas)

4. Número de valores distintos

5. Estatísticas de índice

Essas informações são usadas pelo otimizador DB2 para criar o plano de execução mais eficiente para SELECTs, JOINs e outras operações.

---

🔹 Sintaxe básica

RUNSTATS TABLESPACE nome_tabela
  TABLE(nome_tabela) AND INDEXES ALL;

• TABLE(nome_tabela) → a tabela alvo

• INDEXES ALL → coleta estatísticas de todos os índices da tabela

• Pode ser executado em batch ou online, dependendo da criticalidade

---

🔹 Opções comuns

• ON ALL COLUMNS → coleta histograma de todas as colunas

• ON COLUMNS (col1, col2) → coleta histograma apenas de colunas importantes

• WITH DISTRIBUTION ON → útil para colunas usadas em joins ou WHERE

---

💡 Dicas Bellacosa

1. Rodar periodicamente → especialmente depois de grandes INSERTs/UPDATEs/DELETEs

2. Priorizar colunas usadas em WHERE/JOIN → reduz custo de coleta de estatísticas

3. Evite RUNSTATS durante pico de produção → pode causar I/O extra

4. Use COPY + RUNSTATS em DB2 online → mantém performance sem travar aplicações

5. Sempre verifique os planos de execução → o RUNSTATS influencia diretamente o EXPLAIN PLAN.

---

🔍 Curiosidades e Easter Eggs

• O RUNSTATS não altera dados, apenas coleta informações.

• Alguns DBAs brincam que “RUNSTATS é como fazer checkup anual no seu banco de dados” — sem ele, você dirige no escuro.

• Se você fizer uma reorganização (REORG) e não rodar RUNSTATS, DB2 pode subestimar ou superestimar linhas → queries lentas.

---

📈 Impacto na Performance

• Consultas mais rápidas → otimizador tem informações precisas

• JOINs e filtros eficientes → DB2 escolhe índices corretos

• Sem RUNSTATS → DB2 pode fazer table scan em vez de index scan, desperdiçando CPU e I/O

• Em ambientes grandes (milhões de linhas), RUNSTATS planejado e incremental é crucial

---

🧪 Exemplo prático

Suponha que você tenha a tabela ORDERS no DB2 z/OS:

RUNSTATS TABLESPACE ORDSPACE
  TABLE(ORDERS)
  ON ALL COLUMNS
  AND INDEXES ALL;

• DB2 coleta estatísticas de todas as colunas da tabela e de todos os índices.

• Agora, quando você rodar:

SELECT CUSTOMERID, COUNT(*)
FROM ORDERS
WHERE ORDERDATE BETWEEN '2025-01-01' AND '2025-12-31'
GROUP BY CUSTOMERID;

• O otimizador usará estatísticas precisas para escolher o melhor índice e evitar full table scan.

---

🔑 Resumo Bellacosa

Conceito	Detalhe
O que é	Comando para coletar estatísticas sobre tabelas e índices
Sintaxe	RUNSTATS TABLESPACE ... TABLE(...) AND INDEXES ALL
Quando usar	Após grandes mudanças nos dados, ou periodicamente
Impacto	Melhora planos de execução e performance de queries
Dicas Bellacosa	Priorize colunas usadas em WHERE/JOIN, evite horários de pico, combine com REORG

---

💡 Easter Egg:

Mesmo que você tenha todos os índices perfeitos, DB2 sem RUNSTATS é como ter mapas sem GPS — o otimizador pode escolher caminhos ruins e atrasar seu batch.

 

Bellacosa Mainframe apresenta a batalha dos terços espanhois versus o samurais do periodo sengoku

⚔️ Quando o Mundo Colidiu: Terços Espanhóis vs Samurais (1582)

Uma lição de sistemas, disciplina e cultura — muito antes do mainframe existir

Se você acha que globalização começou com a internet, APIs ou cloud híbrida, sinto informar: em 1582 o mundo já rodava integrado, só que em modo batch marítimo, com latência de meses e documentação escrita à pena.

E foi nesse cenário que aconteceu algo que parece roteiro de anime histórico:
👉 soldados dos Terços espanhóis enfrentando guerreiros samurais no Japão feudal.

Não é lenda. Não é fanfic. É história.

---

🌍 O mundo antes do “isolamento japonês”

O Japão do século XVI estava longe de ser um sistema fechado. Durante o Período Sengoku, o país vivia guerras internas constantes, com senhores feudais (daimyōs) disputando poder como se fossem LPARs concorrentes pelo mesmo hardware.

Enquanto isso:

• Portugueses já haviam chegado ao Japão (1543)

• Jesuítas circulavam livremente

• Armas de fogo europeias eram fabricadas localmente

• Espanhóis dominavam as Filipinas

Ou seja: o Japão estava conectado ao mundo, testando novas “features” militares.

---

🛡️ Terços Espanhóis: o sistema mais estável da época

Os Terços eram a elite militar da Europa. Eles dominaram campos de batalha por mais de um século graças a algo simples e poderoso:

👉 integração de componentes.

• Piqueiros protegiam arcabuzeiros

• Arcabuzeiros davam suporte de fogo

• Disciplina rígida

• Cadeia de comando clara

• Treinamento contínuo

No mundo mainframe?

Os Terços eram um Sysplex humano: cada unidade falhava pouco, mas o conjunto era quase imbatível.

Eles não dependiam de heróis individuais.
Dependiam do processo.

---

⚔️ Samurais: excelência individual e adaptação rápida

O samurai real — não o romantizado — era um profissional da guerra:

• Mestre em katana, arco e lança

• Usuário experiente de armas de fogo (tanegashima)

• Treinado desde jovem

• Guiado por códigos de honra, mas também por pragmatismo

O Japão adotou armas de fogo mais rápido que muitos países europeus.
Sim, isso quebra vários mitos de anime.

No paralelo tecnológico:

O samurai era o engenheiro sênior raiz: domina tudo, resolve no braço, mas brilha mesmo quando bem integrado ao time.

---

💥 O confronto de 1582: menos Hollywood, mais realidade

O encontro entre Terços (ou soldados ibéricos ligados às Filipinas) e samurais ocorreu em um contexto de tensões locais, missões diplomáticas e confrontos armados pontuais.

Não foi uma batalha campal épica.
Foi um choque real de doutrinas militares.

Relatos da época mostram:

• Europeus impressionados com a ferocidade e técnica japonesa

• Japoneses atentos à eficiência das formações europeias

• Ambos entendendo que o inimigo não era “atrasado”

Resultado?
👉 Aprendizado mútuo, não aniquilação.

---

🧠 O que esse episódio ensinou ao mundo

Esse encontro ajudou a moldar decisões importantes:

• O Japão aperfeiçoou o uso de armas de fogo

• A disciplina coletiva ganhou mais valor

• Mais tarde, o xogunato Tokugawa restringiria armas não por ignorância, mas por controle social

Ou seja:

Às vezes você não elimina a tecnologia — você a governa.

Soa familiar, mainframer?

---

🥚 Easter eggs históricos (porque todo bom sistema tem)

• Samurais usavam arcabuzes em larga escala

• O Japão produzia armas com qualidade europeia

• Terços só perderam protagonismo no século XVII

• Animes como Drifters e Samurai Champloo exploram esse choque cultural

• Parece isekai? Mas é documentação histórica

---

🧩 A lição final (para quem vive entre COBOL e anime)

O confronto entre Terços e samurais deixa um recado claro:

O futuro não pertence ao mais forte, nem ao mais honrado.
Pertence a quem integra tradição com inovação.

No nosso mundo:

• COBOL + APIs

• Mainframe + Cloud

• Cultura antiga + tecnologia nova

Exatamente como em 1582.

---

☕ Comentário final estilo El Jefe

Enquanto muita gente ainda discute se o mainframe “vai acabar”, vale lembrar:
os sistemas que sobrevivem são aqueles que se adaptam sem perder identidade.

Os Terços caíram.
Os samurais mudaram.
O Japão se transformou.

E o mainframe?
Segue firme, silencioso, processando o mundo.

END-OF-JOB
RC=0

🛡️ SMP/E e Segurança: Quando manutenção vira proteção (ou vulnerabilidade)

 

Bellacosa Mainframe apresenta IBM SMP/E

🛡️ SMP/E e Segurança

Quando manutenção vira proteção (ou vulnerabilidade)

“No mainframe, segurança não começa no RACF.
Começa no SMP/E.”

---

🧠 Por que SMP/E é parte da segurança?

SMP/E controla o que entra no sistema operacional.

Quem controla:

• Código

• Versões

• Dependências

• Histórico

…controla superfície de ataque.

👉 Um PTF não aplicado é uma brecha.
👉 Um PTF mal aplicado é um risco maior ainda.

---

🔓 O maior mito

❌ “Segurança é só RACF, ACF2 ou TopSecret.”

✅ Verdade:

• RACF protege acesso

• SMP/E protege integridade do código

📌 Sem SMP/E bem gerenciado:

• Módulos vulneráveis continuam rodando

• Correções críticas não entram

• Auditoria reprova

---

🚨 PTF de segurança: prioridade máxima

A IBM libera PTFs que:

• Corrigem falhas exploráveis

• Atendem compliance (PCI, SOX, LGPD)

• Eliminam vetores de ataque

Esses PTFs geralmente vêm com:

• ++HOLD(SECURITY)

• Texto explicativo detalhado

👉 Não aplicar é decisão de risco.

---

🔍 ++HOLD(SECURITY): leia com atenção

O que significa?

++HOLD(SECURITY)

Indica:

• Impacto direto em segurança

• Mudança de comportamento

• Possível quebra de compatibilidade

📌 Normalmente envolve:

• Autorização

• Criptografia

• Controle de acesso

• SMF / auditoria

---

Dica Bellacosa

Ignore um HOLD de segurança e o auditor vai encontrar.

---

🔥 ++ERROR e segurança

Um ++ERROR em PTF de segurança é crítico:

• Pode corrigir parcialmente a falha

• Pode introduzir outro risco

• Pode exigir mitigação adicional

👉 Decisão nunca é automática.

📌 Boas ações:

• Ler APAR

• Avaliar CVE

• Consultar IBM

• Planejar superseding PTF

---

🔐 Controle de acesso ao SMP/E

Quem deve ter acesso?

• System Programmers

• Pouquíssimas pessoas

• Com segregação clara

📌 Proteger:

• CSI datasets

• SMP/E libraries

• JCL de manutenção

---

Boas práticas de RACF

• UACC=NONE

• Acesso mínimo necessário

• LOG de alterações

• Perfis específicos para SMP/E

👉 Quem mexe no SMP/E mexe no sistema inteiro.

---

🧾 Auditoria e compliance

Auditores adoram perguntar:

• Quais PTFs estão aplicados?

• Quando?

• Por quem?

• Por quê?

👉 SMP/E responde tudo isso.

📌 CSI é prova documental.

---

🧪 APPLY CHECK como ferramenta de segurança

APPLY CHECK ajuda a:

• Identificar impacto

• Prever conflitos

• Avaliar risco antes da mudança

💡 Dica Bellacosa:

“APPLY CHECK é auditoria preventiva.”

---

🔄 Manutenção atrasada = risco ativo

• PTF antigo = CVE ativo

• Função obsoleta = ataque conhecido

• Versão desatualizada = não conformidade

👉 Segurança também é disciplina de manutenção.

---

🧠 Caso real (estilo Bellacosa)

Falha crítica corrigida por PTF
PTF não aplicado por medo de IPL
Exploração acontece
Auditor pergunta: “Por quê?”

📌 Resposta errada:

“Porque sempre funcionou assim.”

---

🎓 Como aprender SMP/E focado em segurança

• Ler PTFs de segurança

• Analisar HOLDS

• Estudar CVEs

• Participar de workshops

• Integrar SMP/E com gestão de risco

---

🧠 Curiosidades Bellacosa

• SMP/E já fazia secure supply chain antes do termo existir

• Código assinado é inútil se não for aplicado

• Auditor confia mais no CSI do que em planilha

---

🧾 Comentário final – SMP/E e Segurança

Segurança não é só impedir acesso.
É garantir que o código certo esteja rodando.

E isso…
👉 é trabalho do SMP/E.

🛡️💾🔥