Bellacosa Mainframe apresenta Storage para DEV Cobol

💣 SEU COBOL NÃO É LENTO — SEU STORAGE É QUE DECIDE O DESTINO DO JOB

Um papo direto com quem já escreveu milhões de linhas em COBOL…
mas talvez nunca tenha olhado o storage como o verdadeiro protagonista.

---

☕ Introdução — o erro que ninguém te contou

Você já viu isso:

• Job que ontem rodava em 5 minutos… hoje leva 40
• Batch que “do nada” começa a gargalar
• VSAM “misteriosamente” lento
• DB2 com I/O explodindo

E alguém diz:

“É o programa.”

Não.
Na maioria das vezes… é o storage.

---

🧠 CAPÍTULO 1 — Antes do disco… existia o tempo físico

🧾 Cartão perfurado: o primeiro “storage”

Antes de DASD, antes de tape…
o dado era literalmente um buraco no papel.

• Cada linha COBOL → um cartão
• Ordem física → lógica do programa
• Caiu no chão? 💣 acabou o sistema

💡 Insight:

O primeiro “bug” da história era… baralho embaralhado.

---

🎞️ CAPÍTULO 2 — Tape: o começo do streaming

📼 Fita magnética — o avô do Big D

Tape trouxe algo revolucionário:

• Processamento sequencial
• Grandes volumes
• Backup antes de existir “backup”

👉 E aqui nasce o conceito que você usa até hoje:

Batch

💡 Curiosidade:

• Tape ODEIA parar
• Se parar → “shoe-shining” (vai e volta igual fita cassete)

---

💿 CAPÍTULO 3 — Disco: quando o acesso ficou inteligente

🏢 DASD (Direct Access Storage Device)

Aqui muda o jogo:

• Acesso direto (não sequencial)
• Surge VSAM
• Surge CICS
• Surge DB2

👉 Você para de ler tudo… e passa a ler o que precisa

💡 Insight COBOL:

READ NEXT virou READ KEY

---

⚡ CAPÍTULO 4 — Flash: o fim da mecânica

🔥 SSD no mundo enterprise

Sem disco girando
Sem braço mecânico
Sem latência física relevante

👉 Resultado:

• I/O quase instantâneo
• Batch acelera absurdamente
• DB2 muda comportamento

💡 Insight crítico:

Flash não melhora programa ruim…
ele expõe arquitetura ruim

---

🚀 CAPÍTULO 5 — NVMe: paralelismo bruto

Aqui não é mais “rápido”…
é outro modelo mental.

• I/O paralelo massivo
• Filas simultâneas
• CPU quase não espera

👉 No mainframe:

O gargalo deixa de ser storage… e vira desenho da aplicação

---

🔌 CAPÍTULO 6 — O segredo que poucos entendem: I/O NÃO É CPU

🧠 Como o z/OS realmente funciona

No mundo distribuído:

• CPU faz tudo

No mainframe:

• CPU manda
• Channel executa
• Storage responde

👉 Resultado:

Seu COBOL NÃO faz I/O… ele pede I/O

💡 Easter egg:

• EXCP → você acha que controla tudo
• Mas quem manda mesmo é o Channel Subsystem

---

🧬 CAPÍTULO 7 — RAID: onde mora o risco invisível

Você nunca configurou RAID no COBOL…
mas ele define seu tempo de execução.

• RAID 5 → barato, mais lento
• RAID 10 → caro, extremamente rápido
• RAID 6 → seguro, mais pesado

💣 Verdade dura:

RAID errado = gargalo invisível

---

🧠 CAPÍTULO 8 — SMS: o cérebro invisível

Aqui está o ponto mais ignorado por dev:

SMS decide onde seu dado vai viver

• Storage Class → performance
• Management Class → lifecycle
• Data Class → formato

👉 Você escreve:

OPEN INPUT ARQUIVO

👉 Mas quem decide:

• Disco?
• Flash?
• Tape?

💡 Insight:

Você não controla o storage…
você negocia com ele

---

📦 CAPÍTULO 9 — Tape moderno: o sobrevivente

Tape não morreu.

Ele virou:

• Backup
• Archive
• Compliance
• Air gap (anti-ransomware)

💡 Insight:

Quando tudo falha…
é o tape que salva

---

🤖 CAPÍTULO 10 — Cartridge + robô = escala

• Cartucho = mídia
• Drive = leitura
• Robô = automação

👉 Você pede dataset
👉 Um robô físico movimenta o dado

Sim… existe um braço robótico trabalhando pro seu JCL

---

🧊 CAPÍTULO 11 — Air Gap: o último nível

• Offline
• Fora da rede
• Intocável

👉 Nem hacker… nem erro humano alcança

---

💣 CAPÍTULO FINAL — A verdade que muda tudo

Você achava que:

“Programa define performance”

Mas na prática:

• Storage define latência
• RAID define risco
• SMS define localização
• Tape define sobrevivência

---

☕ Bellacosa-style conclusão

“COBOL executa regra de negócio…
mas é o storage que decide se ela chega a tempo.”

 

💣 LAB MASTER 🔥 Storage Não Armazena — Ele Decide o Destino do Dado

 

Bellacosa Mainframe Treine Storage Mainframe

💣 LAB MASTER

🔥 Storage Não Armazena — Ele Decide o Destino do Dado

---

🎯 Objetivo do LAB

Ao final você será capaz de:

• Entender como o SMS decide storage
• Criar datasets com e sem striping
• Simular impacto de RAID (conceitual)
• Trabalhar com DASD vs Tape
• Ver migração automática (HSM ML1/ML2)
• Executar backup e restore
• Entender o papel do air gap

---

🏗️ Cenário

Você é responsável por:

• Um ambiente com:
  • DASD (disco)
  • Flash (simulado via classe)
  • Tape (ML2)
• Workloads:
  • Batch pesado
  • Dados críticos
  • Arquivos de archive

---

🧪 LAB 1 — Alocação sem SMS (controle manual)

🎯 Objetivo

Sentir o “mundo antigo”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.MANUAL,
//      DISP=(NEW,CATLG),
//      UNIT=3390,
//      SPACE=(CYL,(10,5))

🧠 O que observar:

• Você escolhe tudo manualmente
• Sem inteligência

---

🧪 LAB 2 — Alocação com SMS

🎯 Objetivo

Ver o SMS em ação

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.SMS,
//      DISP=(NEW,CATLG),
//      DATACLAS=STANDARD,
//      STORCLAS=FAST,
//      MGMTCLAS=BACKUP

🧠 O que observar:

• Nenhum volume definido
• SMS decide tudo

---

🧪 LAB 3 — Striping (performance)

🎯 Objetivo

Simular I/O paralelo

👉 Criar Data Class com:

• Stripe Count = 4

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.STRIP,
//     DISP=(NEW,CATLG),
//     DATACLAS=STRIPE4

🧠 Observe:

• Dataset distribuído
• Performance maior

---

🧪 LAB 4 — RAID (conceitual via comportamento)

🎯 Objetivo

Entender impacto sem ver RAID direto

Teste:

• Dataset pequeno vs grande
• Com e sem striping

👉 Analise:

• Tempo de execução
• I/O count

💡 Insight:

RAID está por baixo — você vê o efeito, não a configuração

---

🧪 LAB 5 — Tape (gravação)

🎯 Objetivo

Gravar em fita

//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=USER.TEST.SMS,DISP=SHR
//SYSUT2   DD DSN=USER.TEST.TAPE,
//         DISP=(NEW,CATLG),
//         UNIT=TAPE,
//         VOL=SER=TAPE01

🧠 Observe:

• Acesso sequencial
• Tempo maior

---

Bellacosa Mainframe apresenta leitor cartrige com braço robotico

🧪 LAB 6 — HSM (migração automática)

🎯 Objetivo

Ver dados indo para tape

Comando:

HSEND MIGRATE DATASET('USER.TEST.SMS')

🧠 Resultado:

• ML1 → disco
• ML2 → tape

---

Bellacosa Mainframe apresenta antigo leitor tape para mainframe mvs 

🧪 LAB 7 — Recall (volta do tape)

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.SMS,DISP=SHR

🧠 Observe:

• Dataset volta do tape
• Delay perceptível

---

🧪 LAB 8 — Backup

🎯 Objetivo

Criar cópia de segurança

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,
//     UNIT=TAPE,
//     DISP=(NEW,CATLG)
//SYSIN DD *
 DUMP DATASET(USER.TEST.SMS) -
      OUTDD(DUMP)
/*

---

🧪 LAB 9 — Simulação de desastre

🎯 Objetivo

Recuperação

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,DISP=SHR
//SYSIN DD *
 RESTORE DATASET(USER.TEST.SMS) -
         INDD(DUMP)
/*

---

🧪 LAB 10 — Air Gap (conceito aplicado)

🎯 Objetivo

Entender proteção real

👉 Cenário:

• Dataset corrompido
• Backup online comprometido

👉 Recuperação:

• Apenas via tape

💡 Insight:

Aqui você entende por que tape ainda existe

---

🧠 Fechamento técnico

Você acabou de trabalhar com:

• DASD (3390)
• SMS (policy-driven storage)
• Striping (performance)
• RAID (efeito indireto)
• Tape (sequencial)
• HSM (automação)
• Backup/Restore
• Air Gap (segurança real)

---

☕ Bellacosa-style conclusão

“Você não manipulou disco…
você manipulou decisões sobre onde o dado vive, se move… e sobrevive.”

 

 

☕ 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.

Conheça unidade de armazenamento CARTRIDGE Storage

A

storage mainframe cartridge e robot de leitura

FUJIFILM Corporation e a IBM anunciaram o desenvolvimento de um sistema de armazenamento em fita nativo de 50 TB, apresentando a maior capacidade nativa de cartucho de fita de dados do mundo.

 

IBM Tape Data Cartridge 700 GB

Conheça unidade de armazenamento CARTRIDGE Storage #MAINFRAME #IBM #STORAGE #cartridge

IBM Tape Data Cartridge 700 GB

 

🔥 IBM 3592 JF – O cartucho que carrega impérios de dados

---

🧠 Introdução – quando o dado dorme em fita, mas sonha em petabytes

Se você acha que fita magnética é coisa de museu, é porque nunca encarou um IBM 3592 JF rodando em um TS1140/TS1150 dentro de um data center que parece mais uma nave espacial do que uma sala fria.
O 3592 JF não é “backup”. Ele é arquivo corporativo, retenção legal, seguro contra ransomware e, em muitos bancos, a última linha de defesa da civilização digital.

Bem-vindo ao mundo onde dados não são deletados — são arquivados com honra.

---

📜 História – da fita de rolo ao JF

A linhagem do IBM 3592 nasce no início dos anos 2000 como sucessor espiritual das 3490/3480.
O sufixo JF marca uma geração madura, refinada, feita para:

• Ambientes z/OS heavy-duty

• Integração com DFSMS/HSM

• Coexistência com VTS, TS7700 e GDPS

📼 O JF é o tipo de mídia que sobrevive a mudanças de diretoria, ERPs, fusões e três modas de cloud.

---

🧱 Arquitetura do cartucho IBM 3592 JF

Características físicas e lógicas:

• 📏 Formato proprietário IBM (não confundir com LTO)

• 💾 Capacidade nativa: ~700 GB

• 🗜️ Capacidade com compressão: até ~2–3 TB (dependendo do workload)

• 🔐 Suporte a criptografia por hardware

• 🧬 Servo tracking de altíssima precisão

💡 Easter egg: a densidade da fita é tão alta que um cartucho mal acondicionado “grita” no log do drive antes mesmo de falhar.

---

🏗️ Onde ele vive no mundo real

Normalmente você encontra o 3592 JF em:

• 🗄️ IBM TS3500 / TS4500 Tape Library

• 🧠 TS7700 (Virtual Tape Server) como mídia física de backend

• 🧾 Ambientes regulados: bancos, seguradoras, governos

Ele conversa intimamente com:

• z/OS DFSMS

• HSM (Hierarchical Storage Manager)

• DFSMShsm Migration / Recall

---

🔄 Workflow clássico no mainframe

📌 Passo a passo “vida de fita”

1. Dataset criado (PS ou GDG)

2. Política de SMS decide: disk hoje, fita amanhã

3. HSM migra o dataset para fita

4. Catalog aponta para volume JF

5. Recall on-demand traz o dado de volta

6. Dataset volta ao disco como se nada tivesse acontecido

🧙‍♂️ Magia negra mainframe: a aplicação nunca sabe que o dado dormiu em fita.

---

📊 Logs, SMF e rastros

O 3592 JF deixa pegadas elegantes:

• SMF 14/15 – uso de fita

• SMF 42 – atividades de DFSMS

• SMF 94 – criptografia

• Logs do TS7700 (se virtualizado)

📎 Dica Bellacosa: fita não mente. Se algo sumiu, o SMF sabe onde foi parar.

---

🧩 Curiosidades que só quem viveu sabe

• ☕ Drives 3592 “acordam” antes do operador terminar o café

• 🔁 Uma fita JF pode sobreviver 30 anos se bem armazenada

• 🧯 Ransomware odeia fita — ela não monta sozinha

• 🎩 Cartucho com label mal escrito vira lenda urbana no CPD

---

🛠️ Dicas práticas de sobrevivência

✔️ Padronize nomenclatura de volumes
✔️ Nunca misture JF com JE/JB sem planejamento
✔️ Use criptografia nativa, não “caseira”
✔️ Monitore recalls excessivos (sinal de má política de HSM)
✔️ Tape não é lenta — lento é acesso mal desenhado

---

📚 Guia de estudo para mainframers

📖 Leia e domine:

• DFSMS Storage Administration

• DFSMShsm Implementation

• IBM TS11xx Drive Redbooks

• SMF 14/15 deep dive

🧠 Exercício clássico:

Simule migração, expiração, recall e auditoria de um dataset crítico sem que a aplicação perceba.

---

🧪 Aplicações reais do IBM 3592 JF

• 📜 Retenção legal (7–30 anos)

• 🏦 Histórico financeiro imutável

• 🧬 Dados médicos arquivados

• 🛰️ DR offline (air gap real)

• 📦 Data lake pré-cloud que ainda funciona

---

🧨 Comentário final – El Jefe Style

Enquanto o mundo discute se “cloud é o futuro”, o IBM 3592 JF continua fazendo o que sempre fez:
guardar o passado para proteger o futuro.

No mainframe, fita não é legado.
É estratégia.

🔥 Midnight Lunch aprovado. A fita gira, o dado dorme, o mainframer sorri.

Bellacosa Mainframe apresenta Storage Management no IBM z/OS

---

🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.

---

☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

• Já sofreu com SMS override

• Já ouviu “o ACS mandou”

• Já viu dataset ir parar num disco que você nem sabia que existia

• Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.

---

🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

• Disco era caro

• Poucos volumes

• Programador escolhia tudo

• Erro humano era rotina

💣 Anos 80: o caos

• Explosão de dados

• Batch gigante

• Fragmentação absurda

• Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

• Padronizar

• Automatizar

• Controlar

• Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.

---

🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

• Parte nativa do z/OS

• Gerente de dados

• Juiz das decisões de disco

• Guarda-costas da infraestrutura

Ele cuida de:

• DASD

• TAPE

• Migração

• Backup

• Alocação

• Performance

• Disponibilidade

---

💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

• z/OS

• SYS1

• Aplicações

• VSAM

• Logs

• Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

---

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

• Tape é barato

• Tape é denso

• Tape é confiável

• Tape é rei do backup

DFSMS controla:

• Migração HSM

• Recall automático

• Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.

---

🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

• VOL=SER

• SPACE

• UNIT

Vantagem:

• Controle total

Desvantagem:

• Risco total

📌 Hoje: usado só em casos muito específicos.

---

🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

• Nome do dataset

O SMS decide:

• Onde fica

• Quanto espaço

• Performance

• Migração

📌 Naming convention é lei.

---

🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

• Data Class

• Storage Class

• Storage Group

Baseado em:

• Nome do dataset

• Usuário

• Programa

• Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.

---

🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

• Storage admin

• Infra

• Arquitetura

Aqui você vê:

• Volumes

• Classes

• Storage Groups

• ACS

• Espaço real

📌 Programador geralmente não entra aqui.

---

🧱 Data Class – O DNA do dataset

Define:

• RECFM (FB, VB…)

• LRECL

• DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.

---

🚀 Storage Class – Performance e SLA

Define:

• Prioridade

• Backup

• Migração

• Disponibilidade

📌 Onde o negócio fala mais alto que o código.

---

🗄️ Storage Group – O endereço físico

• Conjunto de volumes

• Abstração total

• Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.

---

📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

• Batch

• Relatórios

• Entrada/Saída simples

---

📚 PO / PDS / PDSE

• Código

• JCL

• Copybooks

📌 PDSE > PDS (sempre que possível).

---

🧬 VSAM

• KSDS

• ESDS

• RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.

---

📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”

---

🧪 Passo a passo prático (vida real)

1. Dataset criado

2. ACS roda

3. Classes atribuídas

4. Volume escolhido

5. Espaço ajustado

6. Catálogo atualizado

Tudo automático.

---

🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito

---

🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype

---

☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

• 📚 Transformar isso em curso

• 🧪 Criar labs práticos

• 🎓 Adaptar para aula corporativa

• 🔐 Criar versão bancária real

• 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️