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

 

 

Bellacosa Mainframe em mão na massa tuning de VSAM

🔧 Laboratório Prático – Tuning de VSAM no z/OS

🎯 Objetivo do Lab

• Melhorar desempenho de datasets VSAM
• Reduzir splits de CI/CA
• Otimizar acesso por chave
• Ajustar buffers e freespace
• Diagnosticar gargalos reais

Tudo isso no contexto de IBM z/OS, usando Virtual Storage Access Method e utilitários como IDCAMS.

---

🧱 Lab 1 — Diagnóstico inicial (onde dói?)

Antes de mexer, descubra o estado real do dataset.

Passo 1 — Obter estatísticas reais

//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  LISTCAT ENTRIES(MEU.VSAM.KSDS) ALL
/*

O que observar

• CI/CA splits
• Freespace atual
• Tamanho médio de registros
• Número de extents
• Buffering atual

⚠️ Se você não mede, você só está chutando.

---

⚡ Lab 2 — Reduzindo CI Splits (onde mora a dor)

CI Split = fragmentação = I/O extra = usuário bravo.

Situação comum

Dataset crescendo e inserções frequentes no meio do arquivo.

Ação — Ajustar FREESPACE

//SYSIN DD *
  ALTER MEU.VSAM.KSDS
    FREESPACE(20 10)
/*

• 20% livre em cada CI
• 10% livre em cada CA

Isso dá “espaço de manobra” para inserções sem quebrar tudo.

---

🚀 Lab 3 — Buffers: o turbo escondido

Buffers mal configurados matam performance silenciosamente.

Verifique no JCL da aplicação:

//DD1 DD DSN=MEU.VSAM.KSDS,DISP=SHR,AMP='BUFND=20,BUFNI=10'

• BUFND → dados
• BUFNI → índice

📈 Regra prática:

• Aplicações intensivas em leitura → aumente BUFND
• Acesso por chave → aumente BUFNI

---

🧪 Lab 4 — Reorganização (o reset saudável)

Com o tempo, fragmentação vira regra.

Backup e Reorg

//REPRO EXEC PGM=IDCAMS
//SYSIN DD *
  REPRO INFILE(OLD) OUTFILE(NEW)
/*

✔ Remove fragmentação
✔ Reequilibra índices
✔ Melhora I/O

---

🧠 Lab 5 — Escolha do tipo certo de dataset

Nem tudo é KSDS.

• Muitas inserções sequenciais? → considere ESDS
• Acesso por posição fixa? → RRDS
• Acesso por chave intenso? → KSDS

Escolher errado custa caro.

---

🧩 Lab 6 — Medindo impacto (antes x depois)

Sempre compare:

• tempo de resposta
• I/O count
• splits por hora
• consumo de CPU

Sem isso, não é tuning — é fé.

---

💣 Erros clássicos (até de sênior)

• Aumentar buffers sem medir impacto
• Ignorar freespace
• Reorg sem revisar parâmetros
• Copiar parâmetros de outro sistema “porque lá funciona”

Cada ambiente é único.

---

🏁 Resultado esperado

Se fizer certo, você verá:

• menos splits
• menos I/O
• menor tempo de resposta
• usuários mais felizes (e menos incidentes às 2h da manhã 😄)
• 
  

 

Bellacosa Mainframe e o poder do VSAM

💥 VSAM -> SEU COBOL NÃO GUARDA DADOS — ELE COMANDA UM IMPÉRIO: A VERDADE BRUTAL SOBRE VSAM NO z/OS QUE TODO SÊNIOR DEVERIA DOMINAR

Se você programa há anos em COBOL, provavelmente já ouviu a frase: “grava no VSAM”.
Mas o que isso realmente significa no universo do IBM z/OS?

Spoiler: não é só “um arquivo”. É um mecanismo de armazenamento tão robusto que sustenta bancos, seguradoras, governos e varejo global — sem fazer barulho.

Hoje vamos olhar o VSAM como engenheiros de verdade olham: por dentro.

---

🧬 O começo de tudo — quando “arquivo” não era suficiente

No início da era mainframe, os dados eram armazenados em sequências lineares. Funciona? Sim. Escala? Não.
Com o crescimento de aplicações transacionais, era preciso:

• acesso direto e rápido,
• indexação inteligente,
• controle fino de armazenamento,
• integridade em workloads absurdos.

E aí nasce o Virtual Storage Access Method, projetado para dar ao mainframe um modelo de armazenamento estruturado, indexado e previsível.

O VSAM não é só um “arquivo”. É uma camada de acesso inteligente a dados.

---

🏗️ A arquitetura — onde a mágica acontece

No VSAM, você não pensa em linhas ou páginas. Você pensa em estruturas:

📦 KSDS — o queridinho

• Acesso por chave
• Ideal para transações
• Indexado automaticamente

Exemplo real:

Cliente → chave = CPF
Acesso direto em milissegundos.

---

📦 ESDS — o sequencial turbinado

• Dados entram em ordem
• Ótimo para logs e histórico

---

📦 RRDS — quando posição é tudo

• Acesso por número de registro
• Perfeito para tabelas estáveis

---

📦 LDS — o lado oculto

• Sem estrutura imposta
• Usado por componentes internos (ex.: bases internas do IBM Db2 for z/OS)

---

⚙️ Quem manda aqui é o IDCAMS

Se VSAM é o motor, o IDCAMS é o mecânico.

Criar dataset? DEFINE CLUSTER
Apagar? DELETE
Alterar atributos? ALTER

Exemplo simplificado:

DEFINE CLUSTER (
  NAME(MEU.VSAM.KSDS)
  INDEXED
  KEYS(10 0)
  RECORDSIZE(200 200)
  TRACKS(10 5)
)

Parece simples… até você errar o tamanho do registro e o mundo desabar 😅

---

⚡ Performance — o jogo de xadrez

No VSAM, performance não é sorte. É engenharia.

Fatores que importam:

• tamanho do CI (Control Interval)
• tamanho do CA (Control Area)
• splits
• buffering
• cache

Se você já viu isso em produção:

IDC3351I ** VSAM OPEN RETURN CODE IS 168

… você já entendeu que VSAM não perdoa descuido.

---

🔥 VSAM + CICS: casamento que sustenta bancos

Quando um programa roda no IBM CICS Transaction Server, e precisa de dados em milissegundos, quem responde é o VSAM.

Transação chega → CICS dispara → VSAM entrega → cliente feliz.

E quando não entrega… todo mundo descobre rapidinho 😂

---

🧪 Easter Eggs que quase ninguém comenta

• VSAM não foi criado só para aplicações: o próprio sistema usa internamente.
• LDS é muito usado internamente por componentes de sistema.
• Muitos “bancos de dados” legados são, na verdade, VSAM com lógica de negócio em COBOL.

---

🧠 Erros clássicos (até de gente experiente)

❌ CI pequeno demais → muitos splits
❌ Key mal definida → gargalo eterno
❌ Ignorar FREESPACE → performance degrada rápido
❌ Tratar VSAM como arquivo texto → sofrimento garantido

---

🛠️ Dica de ouro — o que separa o sênior do júnior

Júnior pensa:

“Funciona.”

Sênior pensa:

“Funciona em produção às 14h de sexta-feira?”

---

🚀 Conclusão — dominar VSAM é dominar o core do mainframe

Se você trabalha com COBOL, VSAM não é opcional. É base.
Entender VSAM é entender como dados realmente vivem no mainframe.

E quando você domina isso, você não é só programador —
você é engenheiro de sistemas críticos.

 

Bellacosa Mainframe com uma overview do Dataset VSAM no z/os

🔥 VSAM NÃO MORREU — ELE SÓ ESTÁ RODANDO EM PRODUÇÃO HÁ 40 ANOS SEM ABEND

🧠 O Segredo Mais Subestimado do z/OS (e por que você ainda depende dele)

Se você é desenvolvedor COBOL raiz, daqueles que já viram JCL com mais linhas que romance russo, então sabe: VSAM não é só storage… é infraestrutura crítica disfarçada de dataset.

Enquanto o mundo fala de NoSQL, Data Lakes e Kubernetes, lá no coração do IBM z/OS, o VSAM continua firme, resiliente… e silenciosamente essencial.

---

🧬 Origem: quando performance era questão de sobrevivência

O VSAM nasceu nos anos 60 com o OS/VS, evoluindo até o que conhecemos hoje no z/OS. Ele foi criado para resolver limitações dos métodos antigos (ISAM principalmente), trazendo:

• Acesso indexado eficiente
• Gerenciamento automático de espaço
• Alta performance com grandes volumes

👉 Em outras palavras: VSAM foi o “Db2” antes do Db2 existir.

---

🚀 Versão atual relevante

Hoje, estamos na linha do:

👉 z/OS 3.x (como 3.1, 3.2, etc.)

E isso significa:

✔ VSAM atualizado automaticamente
✔ Melhorias de performance
✔ Integração com DFSMS
✔ Suporte a grandes volumes (EAV / Extended Addressability)

---

⚙️ O que evoluiu no VSAM ao longo do tempo

Mesmo sem “versão própria”, ele evoluiu MUITO:

🔹 Extended Addressability (EA)

• Saiu do limite de GB → foi para TB

🔹 RLS (Record Level Sharing)

• Concorrência real (quase “transacional”)

🔹 DFSMS

• Gerenciamento automático (ACS routines)

🔹 Buffering avançado

• Performance tuning muito mais fino

---

🧱 Onde o VSAM vive hoje

VSAM não é só “arquivo COBOL”:

👉 Ele é base de coisas grandes, como:

• IBM Db2 for z/OS (usa LDS por baixo)
• Catálogo do sistema
• Sistemas críticos bancários

💥 Ou seja:
Mesmo que você “não use VSAM”… você usa.

---

⚠️ Erro comum de iniciante (e até de sênior distraído)

Perguntar:

“Qual versão do VSAM estamos usando?”

👉 A pergunta correta é:

“Qual versão do z/OS estamos rodando?”

---

🗂️ Tipos de Arquivos VSAM (o coração da arquitetura)

🔑 KSDS — Key Sequenced Data Set (o rei do pedaço)

• Acesso por chave (PRIMARY KEY raiz do COBOL)
• Possui INDEX + DATA
• Suporta acesso sequencial e direto

💬 Comentário Bellacosa:
Se VSAM fosse banco de dados, o KSDS seria o OLTP raiz.

---

📦 ESDS — Entry Sequenced Data Set

• Registros gravados em ordem de entrada
• Sem chave
• Acesso via RBA (Relative Byte Address)

💬 Uso clássico: logs, trilhas de auditoria, arquivos append-only

---

🔢 RRDS — Relative Record Data Set

• Acesso via número relativo (RRN)
• Pode ter slots vazios
• Pode ser FIXED ou VARIABLE

💬 Parece simples… até você esquecer que tem slot vazio e dar READ errado 😅

---

🧱 LDS — Linear Data Set

• Sem estrutura lógica de registros
• Usado por sistemas como IBM Db2 for z/OS
• Base para tablespaces

💬 Aqui o VSAM vira “infra invisível”

---

⚙️ IDCAMS — O canivete suíço do VSAM

Se você nunca digitou isso, você não viveu:

//STEP01 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DEFINE CLUSTER(NAME(MEU.KSDS)
    INDEXED
    KEYS(10 0)
    RECORDSIZE(80 80)
    CYLINDERS(5 2))
/*

📌 Com o IDCAMS você:

• DEFINE / DELETE / ALTER
• REPRO (ETL raiz do mainframe)
• LISTCAT (o “SELECT * FROM VSAM”)

💬 Curiosidade:
O REPRO já fazia “data migration” décadas antes do termo existir.

---

🧠 Curiosidades que só quem viveu sabe

• VSAM usa Control Interval (CI) e Control Area (CA) — tuning fino de performance
• Split de CI/CA pode causar degradação se mal dimensionado
• Buffer tuning pode mudar completamente o desempenho
• SHAREOPTIONS define concorrência (e dor de cabeça 😄)

---

📊 VSAM vs SQL (Db2): o choque de paradigmas

VSAM	Db2
Navegacional	Declarativo
Ultra rápido	Flexível
Sem overhead	Com engine
Controle manual	Automação

👉 Hoje, o IBM Db2 for z/OS usa VSAM (LDS) por baixo.

💥 Plot twist: Você acha que saiu do VSAM… mas nunca saiu.

---

🧮 Limitações e características técnicas

• Máx. tamanho: até dezenas de TB (dependendo do tipo e configuração)
• Máx. keys:
  • 1 chave primária
  • múltiplos AIX (Alternate Indexes)
• Máx. tamanho de registro: ~32KB
• CI tamanho: 512 bytes até 32KB
• CA: múltiplos de CI

📌 Limitação real não é técnica — é governança e design

---

🧷 Pontos Fortes

✅ Performance absurda (baixo overhead)
✅ Estabilidade lendária
✅ Controle fino
✅ Ideal para batch massivo

---

⚠️ Pontos Fracos

❌ Complexidade operacional
❌ Curva de aprendizado alta
❌ Sem SQL nativo
❌ Manutenção manual (splits, tuning)

---

🧪 Exemplo COBOL clássico (KSDS)

READ MEU-KSDS
  KEY IS WS-CHAVE
  INVALID KEY
     DISPLAY 'NAO ENCONTRADO'
END-READ.

💬 Simples. Direto. Sem ORM. Sem mágica.

---

🚀 Versões atuais e evolução

VSAM continua sendo parte essencial do IBM z/OS (versões atuais como 3.x).

E evoluiu com:

• RLS (Record Level Sharing)
• DFSMS integração
• Melhorias de cache e buffering

---

📦 📊 Tamanho máximo de um VSAM (na prática e na teoria)

No IBM z/OS, o tamanho de um dataset VSAM não é um único número fixo — ele depende de:

• Tipo do VSAM (KSDS, ESDS, RRDS, LDS)

• Tamanho do CI (Control Interval)

• Quantidade de CA (Control Areas)

• Limitações do volume (DASD)

• SMS / DFSMS

---

🧠 💥 Resposta direta (o número que você quer)

👉 Um VSAM pode chegar a dezenas de TERABYTES

📌 Valores típicos modernos:

• Até ~128 TB por dataset (em ambientes modernos com Extended Addressability)
• Limitado principalmente pelo volume e configuração SMS

---

⚙️ 🔍 O que define esse limite?

1. 📦 Extended Addressability (EA)

Sem isso, você está preso ao passado.

• VSAM clássico: ~4 GB limite antigo
• VSAM com EA: escala para terabytes

💬 Se não tem EA habilitado → você está vivendo em 1985

---

2. 🧱 Control Areas (CA) e Control Intervals (CI)

• CI: até 32 KB
• CA: conjunto de CIs
• Total = CI × quantidade de CAs

👉 O VSAM cresce horizontalmente via CAs

---

3. 💽 Limite físico do DASD

Mesmo que o VSAM suporte muito:

• Seu volume pode limitar (3390, EAV, etc.)
• Multi-volume entra em jogo

---

🗂️ 📊 Por tipo de VSAM

Tipo	Tamanho Máximo
KSDS	Até dezenas de TB
ESDS	Similar ao KSDS
RRDS	Limitado por slots
LDS	Pode chegar a tamanhos enormes (base do Db2)

💬 LDS é o campeão pesado, porque é usado por IBM Db2 for z/OS

---

⚠️ 🚨 Limitações reais (as que doem em produção)

Não é o “máximo teórico” que quebra você… é isso aqui:

• CI mal dimensionado → splits constantes
• CA splits → degradação absurda
• AIX mal planejado → performance despenca
• Buffer tuning errado → gargalo invisível

💥 Ou seja:
👉 Você raramente quebra por tamanho — quebra por design

---

🧪 💡 Resumo estilo Bellacosa

👉 Teoricamente:
VSAM é gigante (TBs)

👉 Na prática:
Seu VSAM vai até onde seu projeto aguenta

---

☕ 🔥 Provocação final

Você está preocupado com o tamanho máximo…

…mas já olhou quantos CA splits seu KSDS teve hoje? 😏

---

🔑 Quantos AIX (Alternate Indexes) um KSDS pode ter?

IBM z/OS

💥 Resposta direta:

Até 255 Alternate Indexes (AIX)

---

🧠 Mas calma… isso é o limite TEÓRICO

Na prática, você raramente — quase nunca — chega perto disso.

---

⚙️ Como isso funciona por baixo dos panos

Cada AIX é:

• Um VSAM KSDS separado
• Com seu próprio INDEX + DATA
• Ligado ao cluster base via PATH

👉 Ou seja:

Você não tem “um arquivo com vários índices”

Você tem vários datasets VSAM interligados

---

🧱 Estrutura lógica

BASE CLUSTER (KSDS)
   ↓
   ├── AIX 1
   ├── AIX 2
   ├── AIX 3
   └── ...

Cada AIX:

• Pode ter chave diferente
• Pode permitir duplicidade (ou não)
• Pode ter upgrade automático (ou não)

---

⚠️ 🚨 Limitações reais (as que ferram em produção)

Aqui está o que ninguém te conta:

1. 🔥 Overhead de UPDATE

Cada WRITE/REWRITE no KSDS:

👉 Atualiza TODOS os AIX associados

💥 Resultado:

• I/O explode
• CPU sobe
• Batch começa a sofrer

---

2. 🧨 Risco de inconsistência

Se você não usar:

• UPGRADE
• PATH corretamente definido

👉 Pode ficar com AIX desatualizado

---

3. 🐌 Performance degradada

Quanto mais AIX:

• Mais lookup indireto
• Mais leitura de INDEX
• Mais complexidade

---

4. 💽 Espaço em disco

Cada AIX = outro VSAM

👉 10 AIX ≠ leve

👉 50 AIX = você criou um “pseudo-DB maluco”

---

📊 Regra de ouro (mundo real)

Quantidade de AIX	Situação
1–3	👍 Saudável
4–10	⚠️ Cuidado
10+	🚨 Arquitetura suspeita
50+	💀 Você perdeu o controle
255	☠️ Experimento acadêmico

---

🧪 Exemplo IDCAMS (AIX)

DEFINE ALTERNATEINDEX(NAME(MEU.AIX1)
  RELATE(MEU.KSDS)
  KEYS(5 0)
  RECORDSIZE(80 80)
  UPGRADE)

E o PATH:

DEFINE PATH(NAME(MEU.PATH1)
  PATHENTRY(MEU.AIX1))

---

💡 Insight estilo Bellacosa

👉 VSAM permite até 255 AIX…

Mas isso NÃO significa que você deve usar.

💥 Se você precisa de muitos índices:

👉 talvez o problema não seja VSAM… é modelagem

---

☕ Provocação 

Se o seu KSDS tem muitos AIX…

Você está usando VSAM…

ou tentando recriar o IBM Db2 for z/OS na unha? 😏

-----------------------------------------------------------------------------------

💡 Reflexão final (estilo Bellacosa Mainframe)

Enquanto muita gente corre atrás da “nova tecnologia revolucionária”…

👉 O VSAM está lá:

• Processando milhões de transações
• Sem downtime
• Sem hype
• Sem marketing

💥 VSAM não é legado. Ele é o alicerce.

---

☕ Provocação final

Você realmente entende VSAM…
ou só sabe fazer READ NEXT sem dar ABEND?