🔥 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 ☕🖥️