Bellacosa Mainframe VSAM lento tuning IDCAMS e outros segredinhos

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

🧠 1) Escolha o tipo correto de arquivo VSAM

📌 Tradução

O VSAM suporta quatro tipos principais de datasets:

• ESDS (Entry-Sequenced Data Set) → acesso sequencial
• KSDS (Key-Sequenced Data Set) → acesso por chave
• RRDS (Relative Record Data Set) → acesso direto por número relativo
• LDS (Linear Data Set) → armazenamento bruto (usado por DB2, etc.)

Cada tipo possui características diferentes e deve ser escolhido conforme o padrão de acesso aos dados.

---

💬 Comentário Bellacosa

Aqui está o primeiro erro clássico de projeto:

❌ “Vou usar KSDS pra tudo porque é mais completo”

👉 Resultado: I/O desnecessário, split, CI/CA fragmentation, e performance indo pro ralo.

---

🧪 Exemplo prático

✔ Caso ideal:

• Batch sequencial (ex: faturamento diário)
  → ESDS ganha disparado
• Sistema online CICS com lookup por chave
  → KSDS obrigatório
• Tabela indexada por posição fixa
  → RRDS simplifica tudo

---

🚀 Dica avançada (pouco falada)

Se seu acesso for altamente randômico:

👉 Combine:

• KSDS
• • SMB + ACCBIAS=DO (Direct Optimized)

Isso muda o jogo de performance.

---

🧠 2) Otimização de buffers

📌 Tradução

Buffers são áreas de memória usadas para armazenar dados temporariamente durante operações VSAM.

• Poucos buffers → excesso de I/O
• Muitos buffers → desperdício de CPU/memória

---

💬 Comentário Bellacosa

Aqui mora um dos maiores gargalos invisíveis:

VSAM não é lento…
VSAM mal bufferizado é lento.

---

🧪 Exemplo prático (JCL)

//DD1 DD DSN=SEU.VSAM.KSDS,
//     AMP=('BUFND=20','BUFNI=10')

• BUFND → buffers de dados
• BUFNI → buffers de índice

---

🧠 Regra de ouro

Tipo de acesso	Ajuste
Sequencial	BUFND alto
Randômico	BUFNI mais importante

---

🚀 Nível PRO (SMB tuning)

AMP=('ACCBIAS=DO','SMB')

• DO → acesso randômico otimizado
• SO → sequencial
• SW/DW → dinâmico

💣 Isso pode reduzir I/O drasticamente.

---

🧠 3) Minimizar tamanho de registro

📌 Tradução

O tamanho do registro influencia diretamente:

• Quantidade de blocos
• Uso de buffer
• Transferência de dados

---

💬 Comentário Bellacosa

Esse é clássico de legado:

“Ah, deixa esse campo aqui... vai que um dia usam”

👉 Resultado:

• Records inflados
• CI mal aproveitado
• Mais EXCP

---

🧪 Exemplo

❌ Ruim:

Cliente:
- Nome (100 bytes)
- Código (10)
- 20 campos não usados

✔ Melhor:

Cliente:
- Nome (40)
- Código (10)

---

🚀 Técnicas avançadas

• Compressão de dados
• REDEFINES em COBOL
• Uso de campos variáveis (spanned records com cuidado)

---

💣 Trade-off real

Registro pequeno	Registro grande
+ menos I/O	+ menos splits
- desperdício de espaço	- mais dados por I/O

---

🧠 4) Ajuste da configuração de I/O

📌 Tradução

A configuração de I/O inclui:

• Tipo de device
• Velocidade
• Canais
• Pathing
• Alocação

Ferramentas recomendadas:

• SMF
• RMF

---

💬 Comentário Bellacosa

Aqui entramos no território dos sysprogs 🔥

Às vezes o problema NÃO é o VSAM
👉 é o storage, canal ou concorrência

---

🧪 Exemplo real

Problema:

• VSAM lento

Análise SMF:

• Alta contenção em volume

Solução:

• Redistribuir datasets
• Melhorar striping
• Ajustar cache

---

🚀 Dica ninja

• Use LSR (Local Shared Resources) em CICS
• Use RLS (Record Level Sharing) para concorrência

💣 Isso muda completamente o comportamento do VSAM online

---

🧠 5) Considerações extras (parte mais rica!)

💬 Expansão Bellacosa

Aqui entram os segredos que poucos documentam 👇

---

🔥 CI SIZE (Control Interval)

• Sequencial → CI maior (ex: 32K)
• Randômico → CI menor (ex: 4K ou 8K)

---

🔥 CA SIZE (Control Area)

• Afeta splits e performance
• CA maior → menos splits

---

🔥 FREESPACE

FREESPACE(20 10)

• 20% no CI
• 10% no CA

👉 Reduz splits (ESSENCIAL em KSDS)

---

🔥 Secondary Allocation

Evite muitos extents:

SPACE=(CYL,(100,50))

---

🔥 Split (o vilão silencioso)

Quando ocorre:

• CI Split
• CA Split

💣 Consequência:

• Mais I/O
• Fragmentação
• Queda brutal de performance

---

🧪 LAB PRÁTICO (nível Bellacosa 😎)

🎯 Objetivo:

Comparar performance com tuning vs sem tuning

---

Cenário 1 (ruim)

• KSDS
• CI pequeno
• Sem buffer tuning
• Sem FREESPACE

---

Cenário 2 (otimizado)

• KSDS
• CI adequado
• FREESPACE(20 10)
• SMB + ACCBIAS
• BUFND/BUFNI ajustado

---

🔍 Métrica:

• EXCP count
• Tempo de execução
• SMF 64/42

---

💥 Resultado esperado:

👉 Redução de I/O de 30% a 80% (sim, acontece!)

---

🏁 Conclusão estilo Bellacosa

VSAM não é velho…
VSAM é mal compreendido.

Quando bem tunado:

💣 Ele compete com banco moderno
💣 Ele escala
💣 Ele é absurdamente eficiente

 

Bellacosa Mainframe analise o triangulo da performance no Mainframe

💥 🧠 VISÃO GERAL — O TRIÂNGULO DA PERFORMANCE

👉 Em 90% dos problemas reais:

• COBOL → lógica
• VSAM → I/O
• DB2 → acesso a dados

---

🔥 1. TUNING COBOL — CPU (o assassino silencioso)

🎯 Problema típico

• CPU alto
• EXEC alto no sampling

---

🧨 Anti-patterns clássicos

❌ Loop ineficiente

PERFORM UNTIL WS-END = 'Y'
   READ FILE
END-PERFORM

---

❌ Reprocessamento desnecessário

• Mesmo cálculo várias vezes
• Falta de cache em memória

---

✅ Boas práticas

✔ Reduzir chamadas repetidas

IF WS-CALCULATED = 'N'
   PERFORM CALC
END-IF

---

✔ Usar tabelas em memória (lookup)

• Evita I/O repetido

---

✔ Minimizar chamadas externas

• DB2
• VSAM
• APIs

---

💣 Insight

COBOL lento raramente é COBOL…
geralmente é acesso a dados mal feito

---

🐢 2. TUNING VSAM — I/O (o vilão invisível)

🎯 Problema típico

• WAIT alto
• I/O dominante no sampling

---

🧨 Problemas clássicos

❌ Acesso aleatório excessivo

• KSDS sem chave eficiente

---

❌ CI/CA splits

• Dataset mal definido

---

❌ Buffer insuficiente

• Muitas operações físicas

---

✅ Boas práticas

✔ Aumentar buffers

• BUFNI / BUFND

---

✔ Acesso sequencial sempre que possível

• Evitar random

---

✔ Ajustar definição do dataset

• CI size
• CA size

---

✔ Usar READ NEXT quando possível

READ FILE NEXT RECORD

---

💥 Insight

VSAM mal configurado transforma CPU em WAIT

---

🗄️ 3. TUNING DB2 — O campeão de problemas

🎯 Problema típico

• WAIT alto
• CPU alto distribuído
• SQL dominante

---

🧨 Problemas clássicos

❌ Full table scan

• Falta de índice

---

❌ SQL executado milhares de vezes

PERFORM 10000 TIMES
   EXEC SQL SELECT ...
END-EXEC

---

❌ Falta de filtro adequado

• WHERE mal definido

---

✅ Boas práticas

✔ Criar índices corretos

• Baseado no WHERE

---

✔ Reduzir chamadas SQL

• Buscar em bloco
• Usar cursor

---

✔ Evitar SELECT dentro de loop

👉 mover lógica para fora

---

✔ Usar EXPLAIN

• Ver access path

---

💣 Insight

1 SQL ruim pode destruir toda a performance

---

🔗 4. INTEGRAÇÃO (onde mora o problema real)

💥 Cenário clássico

COBOL → chama DB2 → DB2 faz I/O → VSAM/disco

---

🧠 Diagnóstico via sampling

Sintoma	Causa
CPU alto	COBOL
WAIT alto	VSAM
CPU + WAIT	DB2

---

🔥 5. CASO REAL COMPLETO

🎯 Sintoma

• Job lento
• 2 horas de execução

---

📊 Sampling mostra

DB2 → 50%
VSAM → 30%
COBOL → 20%

---

🧠 Diagnóstico

👉 Problema NÃO é COBOL
👉 É acesso a dados

---

🔧 Ações

• Criar índice DB2
• Reduzir chamadas SQL
• Ajustar VSAM

---

🚀 Resultado

• Tempo: 2h → 20min
  💥 ganho de 6x

---

⚡ 6. CHECKLIST RÁPIDO (produção)

1. CPU ou WAIT?
2. Identificar hotspot
3. COBOL → otimizar lógica
4. VSAM → otimizar I/O
5. DB2 → otimizar SQL
6. Validar com nova coleta

---

💣 ERROS QUE MAIS VEJO EM PRODUÇÃO

❌ Ajustar COBOL sem olhar DB2
❌ Culpar DB2 sem olhar VSAM
❌ Ignorar I/O
❌ Não usar sampling

---

🧠 MODELO MENTAL FINAL

COBOL = processamento
VSAM  = acesso físico
DB2   = acesso lógico

---

💥 FRASE FINAL (nível arquiteto)

“O gargalo não está no código…
está na forma como o código acessa os dados.”

 

 

Bellacosa Mainframe apresenta um estudo de caso para performance em Mainframe

💥 🔬 PERFORMANCE RELATÓRIO — VISÃO GERAL

PROGRAM MEASURED   - PROG001
JOB NAME           - JOB001
STEP NAME          - P010.S010

---

🧠 O que isso já diz?

👉 Você está analisando:

• Programa: PROG001
• Job: JOB001
• Step específico

💡 Ótimo sinal → análise já está refinada (não é genérica)

---

⚙️ 🔍 BLOCO 1 — Measurement Parameters

ESTIMATED SESSION TIME  - 30 MIN
TARGET SAMPLE SIZE      - 30,000

---

🧠 Interpretação

👉 Configuração padrão profissional:

• 30 min
• 1000 samples/min

✔ Excelente equilíbrio entre precisão e overhead

---

💣 Insight

Se isso estivesse errado → TODO o relatório seria suspeito

---

📊 🔥 BLOCO 2 — Measurement Statistics

EXEC TIME PERCENT - 90.84
WAIT TIME PERCENT - 9.16

---

🧠 Diagnóstico IMEDIATO

👉 Sistema está:

• 90% executando (CPU)
• 9% esperando

---

💥 Conclusão direta

✔ CPU-bound
❌ NÃO é problema de I/O
❌ NÃO é lock
❌ NÃO é DB2 wait

---

🎯 Ação

👉 Investigar:

• Código COBOL
• Algoritmo
• Loop
• Cálculo repetitivo

---

⚖️ 🔬 BLOCO 3 — Margem de erro

RUN MARGIN OF ERROR  - 0.65
CPU MARGIN OF ERROR  - 0.68
WAIT MARGIN OF ERROR - 2.16

---

🧠 Interpretação

👉 Estatisticamente confiável

Valor	Qualidade
< 1%	excelente
< 5%	confiável

---

💣 Insight

Você pode confiar nesse diagnóstico sem medo

---

🔢 📈 BLOCO 4 — Samples

TOTAL SAMPLES TAKEN     - 37,549
TOTAL SAMPLES PROCESSED - 22,548

---

🧠 Interpretação

👉 Nem todos os samples foram úteis

Possíveis motivos:

• CPU idle
• Outro address space
• Thread não relevante

---

💡 Insight

Isso é NORMAL — e esperado

---

⏱️ 📉 BLOCO 5 — Sampling Rate

INITIAL SAMPLING RATE - 8.33/sec
FINAL SAMPLING RATE   - 4.17/sec

---

🧠 Interpretação

👉 Taxa caiu ao longo do tempo

Possíveis causas:

• Mudança de carga
• Menos CPU ativa
• Contenção

---

💥 Insight

Sampling não é constante — ele reflete o ambiente real

---

🧾 🔍 BLOCO 6 — Ambiente

ADDRESS SPACE ID - 0061
DATE/TIME        - execução real
CONDITION CODE   - C-0000

---

🧠 Interpretação

✔ Job terminou OK
✔ Sem abend
✔ Ambiente válido

---

🔥 🔬 DIAGNÓSTICO FINAL

📊 Resumo técnico

CPU → 90%
WAIT → 10%
Erro → baixo
Samples → suficientes

---

🎯 Conclusão

💥 O problema está NO CÓDIGO, não no ambiente

---

💣 Possíveis causas reais

👉 Aqui começa o trabalho do especialista:

🔥 1. Loop ineficiente

PERFORM UNTIL ...

---

🔥 2. Leitura repetitiva

• VSAM read desnecessário
• DB2 repetido

---

🔥 3. Cálculo pesado

• Reprocessamento
• Falta de cache

---

🔥 4. Algoritmo ruim

• Complexidade alta
• Ordenação ineficiente

---

🚀 Próximo passo (o que você faria em produção)

1. Abrir relatório detalhado (modules)
2. Identificar:
   • módulo
   • offset
3. Mapear para código COBOL
4. Ajustar lógica

---

🧠 Modelo mental definitivo

EXEC alto → código
WAIT alto → recurso externo

---

💥 Frase final (nível especialista)

“O relatório já te deu a resposta.
Agora é você que precisa ir até o código.”

 

 

Bellacosa Mainframe introduz o Banco de Dados Hierarquico

☕🌳 BANCO HIERÁRQUICO: O DINOSSAURO DO MAINFRAME QUE AINDA MOVE BILHÕES

Entenda de forma simples como o IMS organiza dados como uma árvore gigante ultra rápida 🚀

Quando um programador COBOL júnior escuta:

🌳 “Banco Hierárquico”

normalmente imagina algo complicado, antigo e misterioso.

E sinceramente?

😄 O IMS realmente parece saído de um laboratório secreto da IBM dos anos 70.

Mas depois que você entende a lógica…

tudo começa a fazer MUITO sentido.

---

🧠 O Que é um Banco Hierárquico?

A ideia principal é simples:

📌 Os dados são organizados como uma árvore.

Exemplo:

CLIENTE
 └── CONTA
      └── CARTAO
           └── MOVIMENTO

Existe:

✅ pai
✅ filho
✅ relacionamento fixo

Igual uma árvore genealógica.

---

🌳 Pense Numa Árvore Real

Imagine:

TRONCO
 └── GALHO
      └── FOLHA

No IMS é parecido:

CLIENTE
 └── CONTA
      └── MOVIMENTO

Cada nível depende do anterior.

---

🚀 Diferença Para Banco Relacional

No DB2 ou Oracle:

SELECT * FROM CLIENTE

Tudo funciona via:

• tabelas

• joins

• SQL

---

🌳 No Banco Hierárquico

Não existem joins clássicos.

Você:

⚡ navega pela árvore.

---

📦 Exemplo Real Bancário

Imagine um banco:

CLIENTE
 └── CONTA
      └── FATURA
           └── MOVIMENTO

O IMS entende naturalmente que:

✅ cliente possui conta
✅ conta possui fatura
✅ fatura possui movimentos

---

🧠 O Grande Segredo

No banco hierárquico:

📌 O caminho importa.

Você normalmente começa do topo:

CLIENTE

e vai descendo.

---

⚡ Por Que Isso é Tão Rápido?

Porque o IMS não precisa:

❌ montar JOIN complexo
❌ calcular relacionamento
❌ pensar demais

Ele já conhece o caminho.

É quase como:

seguir túneis secretos

entre os dados.

---

🌳 O IMS Usa Ponteiros

O IMS liga os segmentos com:

🔑 ponteiros físicos

Exemplo:

CLIENTE
   ↓
CONTA
   ↓
MOVIMENTO

Então o acesso é extremamente rápido.

---

💾 Segmentos

No IMS os registros são chamados de:

🟦 Segmentos

Exemplo:

Segmento	Significado
CLIENTE	registro cliente
CONTA	conta bancária
MOVIMENTO	transação

---

🚀 O Programa COBOL Navega

No IMS o COBOL não faz SQL.

Ele usa:

CALL 'CBLTDLI'

com comandos como:

Comando	Função
GU	busca única
GN	próximo
GNP	próximo filho
ISRT	insert
REPL	update
DLET	delete

---

🌳 Exemplo Mental

Imagine:

CLIENTE JOAO
 └── CONTA 123
      └── MOVIMENTO PIX

O programa faz:

1️⃣ encontra cliente
2️⃣ entra conta
3️⃣ lê movimentos

Tudo navegando pela árvore.

---

⚔️ Hierárquico vs Relacional

Banco Hierárquico	Banco Relacional
árvore	tabelas
navegação	SQL
pai/filho	joins
muito rápido	flexível
rígido	dinâmico

---

💣 A Desvantagem

O banco hierárquico é MUITO rápido…

mas menos flexível.

Exemplo:

Se o banco foi desenhado assim:

CLIENTE
 └── CONTA

e amanhã você quiser acessar:

CONTA → CLIENTE

pode virar dor de cabeça.

---

🚀 Então Por Que Bancos Ainda Usam IMS?

Porque para sistemas críticos:

⚡ velocidade importa muito.

Especialmente em:

• ATM

• cartão

• PIX

• autorização financeira

• telecom

• aviação

---

☕ Curiosidade Bellacosa Mainframe

O IMS nasceu em:

🚀 1968

durante o projeto Apollo da NASA.

Sim.

O mesmo sistema que ajudou a organizar informações da corrida espacial…

continua hoje processando bilhões de transações financeiras.

Enquanto muita tecnologia moderna já morreu…

o “dinossauro” hierárquico continua vivo.

E extremamente rápido.

 

Um Café no Bellacosa Mainframe

2,167 subscribers

O que é Address Space?

Bellacosa Mainframe

4,424 followers

July 25, 2025

Salve jovem padawan, prosseguindo em nossa jornada de descobrimento e compartilhamento de conhecimento, hoje escreverei sobre um tema dificil, tentarei ser claro e ajudar com exemplos fáceis de entender.

Em minhas aulas percebo que os alunos ficam confusos por ser um tema muito abstrato, porém de máxima importância para um desenvolvedor Mainframe, a questão da memória, lembrando que um Z17 tem 16 exabytes de endereço de memória disponível.

Ao codificar, devemos dominar o espaço, ser econômicos em seu uso e dar o máximo de performance para um programa, por isso entender o conceito ajudará bastante.

✅ O que é Address Space?

Um Address Space é um ambiente isolado de execução fornecido pelo z/OS para que um job, um programa ou uma tarefa rode com sua própria memória e recursos protegidos. Pense nele como um "container" de memória virtual onde o seu programa COBOL roda. Esse cointainer será alocado no DATA DIVISION do Cobol e o programa ao ser enviado para o processamento na CPU, reservará esse espaço para usar durante todo o processo.

---

🧠 Por que isso é importante para COBOL?

Quando você submete um job COBOL batch, ou inicia um programa via CICS, o sistema cria um address space para:

• Carregar os programas COBOL compilados (load modules).
• Alocar memória para as variáveis.
• Abrir arquivos (datasets, VSAM, etc.).
• Comunicar com o CICS, DB2 ou IMS.
• Controlar segurança, permissões e acesso via RACF.
• Garantir que um job não interfira em outro (isolamento de execução).

Esse espaço estará isolado de outras aplicações e protegido contra interferências durante todo o processamento dos dados, porém devemos criá-lo com cuidado. Afinal muitas outras aplicações criarão os delas, esse espaço tende a ser continuo e para seu uso mais racional, o endereçamento renumera em tempo de execução para 1 até o ultimo byte reservado.

---

📌 Tipos de Address Space comuns no ambiente z/OS:

Tipo de EspaçoDescriçãoJob Address SpaceCriado quando um JCL é submetido. Executa seu programa COBOL.TSO Address SpaceQuando um usuário entra via TSO (ISPF), um espaço é criado.CICS RegionCICS cria um espaço para executar programas COBOL online.STC (Started Task)Tasks como SDSF, VTAM ou WebSphere são address spaces.

---

🛠️ Dica prática para COBOListas

Se você estiver enfrentando erros de memória, como abend S0C4, S0C1, S80A, saiba que o problema pode estar relacionado à forma como o seu programa está usando (ou ultrapassando) os limites do Address Space.

Sempre recomendo o uso dos Bug traps do COBOL, nunca deixe de validar returns codes, sql codes e validar os valores resultantes. Evitando abends descontralados em tempo de execução.

---

💡 Curiosidade Bellacosa Mainframe:

Cada address space tem sua própria área de memória protegida, mas todos compartilham o mesmo sistema de I/O, JES e catálogo. O z/OS garante que um job de um programador "distraído" não corrompa o ambiente do colega — um isolamento que já existia décadas antes dos containers Docker!

💡 Conclusão

Esse artigo teve como objetivo fornecer os primeiros passos para o futuro Mainframer, mas para obter maiores conhecimentos recomendo visitar o site da IBM , ler os manuais e participar da comunidade para evoluir sempre.

Espero ter ajudado e contem comigo para mais artigos, participe de nossa comunidade.

Ajude-nos a evoluir sempre.

Obrigado.