☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta alta disponibilidade. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta alta disponibilidade. Mostrar todas as mensagens

quarta-feira, 3 de junho de 2026

A Família IBM Storage TS: Os Guardiões Silenciosos dos Dados que Mantêm o Mundo Funcionando

 

Bellacosa Mainframe a familia ibm storage ts: tapes e cartridges

☕ Um Café no Bellacosa Mainframe

A Família IBM Storage TS: Os Guardiões Silenciosos dos Dados que Mantêm o Mundo Funcionando

Muito além das fitas: conheça a evolução do armazenamento corporativo e descubra por que os maiores bancos do mundo ainda confiam na família IBM TS.

"Um programador COBOL normalmente pensa em arquivos, datasets e VSAM. Um administrador pensa em discos. Mas existe uma camada inteira entre eles que poucos enxergam. É nela que mora a verdadeira magia do armazenamento corporativo."

Existe uma curiosidade interessante.

Pergunte para um desenvolvedor júnior:

"Onde fica armazenado o arquivo que seu programa COBOL acabou de gravar?"

A resposta normalmente será:

"No disco."

Tecnicamente...

Está correta.

Mas também está extremamente incompleta.

Na verdade, entre seu programa COBOL e o disco físico existe um universo inteiro composto por controladoras, caches, virtualização, compressão, replicação, criptografia, fitas virtuais, bibliotecas robotizadas e algoritmos que trabalham 24 horas por dia para garantir que nenhum byte desapareça.

Hoje vamos tomar um café e conhecer um dos mundos mais fascinantes da computação corporativa: a família IBM Storage TS.


Antes de falar de Storage...

Vamos fazer uma viagem no tempo.

Imagine um banco em 1985.

O expediente termina às 18h.

À noite começa o Batch.

Depois dos programas COBOL processarem milhões de transações...

Era necessário fazer backup.

Como?

Em fitas magnéticas.

Literalmente.

O operador colocava dezenas ou centenas de cartuchos na biblioteca.

Os drives começavam a trabalhar.

CPU

↓

COBOL

↓

Disco

↓

Fita

No dia seguinte...

As fitas eram retiradas.

Algumas iam para cofres.

Outras viajavam para outro prédio.

Outras eram guardadas durante anos.

Era o famoso plano de recuperação de desastres.

Na época fazia todo sentido.

Hoje...

Nem tanto.


O problema do backup tradicional

Imagine um banco que possui:

  • 5 PB de dados

  • milhares de servidores

  • centenas de máquinas virtuais

  • IBM Z

  • Linux

  • Windows

  • Cloud

Será que copiar tudo uma vez por dia continua funcionando?

Não.

O mundo mudou.

Hoje existem aplicações funcionando:

  • 24 horas

  • 7 dias por semana

  • 365 dias por ano

Não existe mais "janela de backup".


Bellacosa Mainframe apresenta Virtual Tape

O nascimento do Virtual Tape

A IBM percebeu esse problema ainda nos anos 90.

Em 1997 lançou uma tecnologia revolucionária.

O primeiro Virtual Tape System (VTS).

A ideia parecia simples.

Em vez de gravar diretamente na fita...

O sistema gravaria primeiro em discos rápidos.

Depois moveria automaticamente os dados para fita.

Visualmente:

Aplicação COBOL

↓

Canal FICON

↓

Virtual Tape

↓

Disco

↓

Fita Física

Para o programa...

Nada mudou.

Ele continua acreditando estar escrevendo numa fita.

Esse detalhe é genial.


Curiosidade ☕

Seu programa COBOL nunca "soube" que a fita era virtual.

O JCL continuou praticamente igual.

O DD continuou apontando para uma fita lógica.

Toda a inteligência acontecia atrás das cortinas.

É um dos maiores exemplos de retrocompatibilidade da história da computação.


O que significa TS?

Muita gente acredita que TS significa apenas "Tape Storage".

Na realidade, dentro da linha IBM, TS identifica uma família de soluções de armazenamento corporativo voltadas principalmente para tecnologias de fita e virtualização de fita, embora seus recursos hoje vão muito além do simples uso de cartuchos físicos.

Ao longo dos anos surgiram equipamentos como:

  • TS1120

  • TS1130

  • TS1140

  • TS1150

  • TS1160

  • TS4500

  • TS7700

  • TS7770

  • TS7780

  • TS7785

Cada geração trouxe melhorias em:

  • desempenho

  • criptografia

  • compressão

  • capacidade

  • confiabilidade


A evolução da família TS

Podemos imaginar essa evolução assim:

Fita Física

↓

Virtual Tape

↓

GRID

↓

Cloud

↓

Always-On Data Protection

Perceba que não estamos falando apenas de hardware.

Estamos falando da evolução da própria filosofia de proteção de dados.


A família TS7700

Se existe uma estrela dentro desse universo...

Ela atende pelo nome:

IBM TS7700.

Durante muitos anos foi considerada a principal plataforma de Virtual Tape para ambientes IBM Z.

Ela introduziu conceitos que hoje parecem comuns.

Na época eram revolucionários.

Como:

✔ Cache inteligente

✔ Replicação

✔ GRID

✔ Failover automático

✔ Balanceamento

✔ Virtualização


Imagine uma biblioteca...

Pense numa biblioteca gigantesca.

Milhões de livros.

Agora imagine quatro bibliotecas espalhadas pelo país.

Todas possuem exatamente o mesmo catálogo.

Você entra em qualquer uma.

Pede um livro.

Ela encontra.

Pouco importa onde ele foi guardado originalmente.

Essa é a ideia do GRID.


O que é GRID?

GRID é provavelmente o conceito mais importante da família TS.

Antes:

Servidor Principal

↓

Backup

Depois:

Cluster A

↔

Cluster B

↔

Cluster C

↔

Cluster D

Todos trabalham.

Todos conhecem todos.

Todos possuem consciência dos dados.

É como um time de futebol.

Não existe apenas um jogador.

Se alguém sair machucado...

O jogo continua.


Easter Egg 🎮

Se você assistiu Star Wars, imagine o Conselho Jedi.

Não existe um único Jedi controlando toda a galáxia.

Todos colaboram.

O GRID funciona de maneira parecida.

Cada nó conhece o estado do ambiente inteiro.


Active-Active

Aqui aparece outro conceito importante.

Durante décadas existiu a arquitetura:

Primary

↓

Replica

↓

Standby

O standby ficava parado.

Esperando.

Às vezes durante anos.

No TS7785 isso muda.

Todos trabalham.

Todos recebem carga.

Todos respondem.

Todos podem restaurar dados.

É muito mais eficiente.


O TS7785

Chegamos ao protagonista.

O TS7785 representa uma evolução enorme da arquitetura TS7700.

Ele nasceu para atender não apenas Mainframe.

Mas também:

  • IBM i

  • LinuxONE

  • RHEL

  • ambientes distribuídos

É como se a IBM tivesse dito:

"A tecnologia que funcionou durante décadas no IBM Z agora está pronta para proteger qualquer plataforma."


Construído sobre IBM Power9+

Outro detalhe interessante.

O TS7785 utiliza processadores IBM Power9+.

Por quê?

Porque backup moderno faz muito mais do que copiar arquivos.

Ele precisa:

  • comprimir

  • criptografar

  • verificar integridade

  • sincronizar GRID

  • movimentar dados

  • conversar com Cloud

Tudo isso exige processamento.

Muito processamento.


4 GB por segundo

O artigo informa até:

4 GB/s por cluster.

Vamos traduzir.

4 GB/s

=

240 GB/min

=

14,4 TB/h

Isso significa que enormes volumes podem ser protegidos rapidamente.


Compressão ou Deduplicação?

Essa parte costuma confundir iniciantes.

Hoje quase todo fabricante fala de deduplicação.

A IBM escolheu outro caminho.

Compressão inline.

Vamos entender.


Deduplicação

Imagine dois arquivos.

ABCDEF

ABCXYZ

Os primeiros blocos são iguais.

A deduplicação guarda apenas uma cópia.

Economiza espaço.

Mas...

Na hora do restore precisa reconstruir tudo.

Isso pode consumir tempo.


Compressão Inline

Na compressão:

Arquivo

↓

Compacta

↓

Grava

Na recuperação:

Lê

↓

Descompacta

↓

Pronto

Mais simples.

Mais previsível.

Especialmente em cargas sequenciais típicas de backup.


Curiosidade ☕

A IBM prefere desempenho previsível.

Em ambientes bancários isso normalmente vale mais do que economizar alguns terabytes.


Unified Data Model

Imagine dez administradores.

Cada um sabe onde estão seus backups.

Problema.

Agora imagine:

Um catálogo único.

Todos enxergam tudo.

É isso que faz o Unified Data Model.

Você não precisa decorar onde cada cópia está armazenada.

O sistema resolve isso.


Cloud Storage Tier

Outra evolução importante.

Antigamente:

Disco

↓

Fita

Hoje:

SSD

↓

Disco

↓

Cloud

↓

Deep Archive

Tudo automatizado.

Baseado em políticas.

Por exemplo.

Após 30 dias.

Mover para Cloud.

Após um ano.

Mover para Archive.

Sem intervenção humana.


LAN-Free Backup

Essa tecnologia existe há anos.

Mas continua extremamente relevante.

Sem LAN-Free:

Servidor

↓

Rede Ethernet

↓

Backup Server

↓

Storage

Toda a rede sofre.

Com LAN-Free:

Servidor

↓

Fibre Channel

↓

Storage

Muito mais rápido.

Muito menos congestionamento.


Synthetic Full

Outro nome bonito.

A ideia também é simples.

Ao invés de criar um Full toda semana...

O sistema monta um Full virtual usando:

  • Full anterior

  • incrementais

Resultado.

Economiza:

✔ espaço

✔ tempo

✔ processamento


O conceito de Cyber Resilience

Repare que a IBM quase não fala "backup".

Ela fala:

Cyber Resilience.

Existe uma diferença enorme.

Backup significa:

"Tenho uma cópia."

Cyber Resilience significa:

"Mesmo atacado, continuo funcionando."

São filosofias completamente diferentes.


A regra 3-2-1

Você provavelmente ouvirá essa expressão durante entrevistas.

Ela significa:

  • 3 cópias dos dados

  • 2 mídias diferentes

  • 1 cópia fora do ambiente principal

Hoje muitos especialistas já falam em:

3-2-1-1-0

Onde existe ainda:

  • uma cópia imutável

  • zero erros após validação


Dica para quem trabalha com Mainframe

Se você conhece:

  • JCL

  • DFSMS

  • HSM

  • DFSMShsm

  • FICON

  • SMS

  • Catalog

  • RACF

Você já possui metade dos conceitos necessários para entender Storage Enterprise.

O restante é aprender como esses componentes conversam entre si.


Curiosidade histórica ☕

Os primeiros operadores de Mainframe literalmente carregavam caixas de fitas pelo Data Center.

Hoje um robô faz isso sozinho.

Algumas bibliotecas conseguem movimentar milhares de cartuchos automaticamente sem intervenção humana.

Se você visitar um grande Data Center verá braços robóticos deslizando entre estantes de fitas. Parece cena de ficção científica.


Easter Egg 🎮

Lembra do filme Indiana Jones e os Caçadores da Arca Perdida, quando a Arca é levada para um gigantesco depósito cheio de caixas idênticas?

Aquilo lembra bastante uma biblioteca de fitas corporativa.

A diferença é que, no mundo IBM, um software sabe exatamente onde cada "caixa" está e consegue encontrá-la em segundos.


Outro Easter Egg para os Padawans

No universo Star Wars existe o Holocron.

Ele guarda conhecimento dos Jedi.

No mundo IBM...

As fitas fazem algo parecido.

Elas preservam décadas de informações bancárias, governamentais e empresariais que continuam acessíveis quando necessário.


O futuro

O TS7785 mostra claramente para onde o mercado está caminhando.

Não basta possuir backups.

Será necessário possuir:

  • dados sempre disponíveis

  • múltiplos sites

  • Cloud integrada

  • inteligência automática

  • proteção contra ransomware

  • recuperação quase instantânea

Backup deixa de ser uma tarefa operacional.

Passa a ser parte da estratégia de continuidade do negócio.


Conclusão

Durante muito tempo, storage era visto como "aquele equipamento onde os arquivos ficam guardados". Hoje sabemos que essa visão é limitada. A família IBM Storage TS representa décadas de engenharia voltadas para garantir disponibilidade, desempenho e proteção dos ativos mais valiosos de qualquer organização: seus dados.

Da fita física ao Virtual Tape, da arquitetura GRID ao TS7785 com proteção contínua, a evolução mostra que a IBM não apenas acompanhou as mudanças do mercado, mas ajudou a defini-las. Conceitos como Active-Active, Unified Data Model, Cloud Storage Tier, LAN-Free Backup, Synthetic Full e Cyber Resilience demonstram que armazenamento moderno é muito mais do que capacidade; é inteligência, automação e continuidade operacional.

Para um programador COBOL júnior, entender esse ecossistema é um diferencial importante. Mesmo que você nunca administre um storage corporativo, seus programas gravam dados que percorrem essa infraestrutura todos os dias. Saber o que acontece "do outro lado do dataset" amplia sua visão da arquitetura corporativa e ajuda a compreender por que o IBM Z continua sendo referência mundial em confiabilidade.

No fim das contas, existe uma frase que resume bem a missão da família IBM Storage TS:

"O melhor backup é aquele que você quase nunca percebe... porque os dados continuam disponíveis quando o negócio mais precisa deles."

E talvez esse seja o maior legado da engenharia IBM: construir tecnologias tão confiáveis que passam despercebidas, enquanto silenciosamente protegem bilhões de transações todos os dias.


quarta-feira, 8 de abril de 2026

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

 

Bellacosa Mainframe experimentos reisiliencia em IBM Z

💥 APERTA O ENTER E DERRUBA O DATA CENTER: SOBREVIVA AO LAB DE RESILIÊNCIA IBM Z

🧪 Laboratório prático — do ABEND ao FAILOVER sem perder um byte


🎯 OBJETIVO DO LAB

Você vai simular:

  • 💣 Falha de aplicação (ABEND)
  • ⚙️ Restart automático (ARM)
  • 🧩 Continuidade (Sysplex mental model)
  • 🌍 Disaster Recovery (simulado estilo GDPS)
  • 📊 Validação de RPO/RTO

👉 Resultado esperado:
Sistema continua — usuário nem percebe


🧠 CENÁRIO (VIDA REAL)

Você é dev COBOL em um banco:

  • Batch crítico processa pagamentos
  • Roda em z/OS
  • Usa Db2
  • Integra com CICS

💥 E claro… algo vai dar errado.


🧪 LAB 1 — “PROVOQUE O CAOS” (ABEND CONTROLADO)

🎯 Objetivo:

Gerar uma falha real


📄 Passo 1 — Programa COBOL com erro

IDENTIFICATION DIVISION.
PROGRAM-ID. LABFAIL.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NUM PIC 9(3) VALUE ZEROS.
01 WS-VAL PIC 9(3).

PROCEDURE DIVISION.
MOVE 100 TO WS-VAL
DIVIDE WS-VAL BY WS-NUM GIVING WS-VAL
DISPLAY 'PROCESSO FINALIZADO'
STOP RUN.

👉 Resultado esperado:

S0C7 ou S0CB (divisão por zero)

💡 Comentário Bellacosa

“Se você nunca causou um ABEND de propósito… você ainda não domina o sistema.”


⚙️ LAB 2 — “DEIXA O SISTEMA SE VIRAR” (ARM)

🎯 Objetivo:

Simular restart automático


🧠 Conceito

ARM = Automatic Restart Manager

👉 Ele reinicia automaticamente o que caiu


📄 Passo 2 — Simulação lógica

JOB FAIL → ABEND
ARM detecta → restart automático
JOB reinicia → continua fluxo

🧪 Teste

  1. Execute o programa com erro
  2. Corrija o erro (WS-NUM ≠ 0)
  3. Reexecute

👉 Agora imagine:

  • ARM faria isso sozinho
  • Sem operador

💡 Insight

“ARM é o operador que nunca dorme.”


🧩 LAB 3 — “NÃO PARE O SISTEMA” (MENTALIDADE SYSPLEX)

🎯 Objetivo:

Entender continuidade


🧠 Simulação conceitual

Imagine:

  • LPAR A → falha
  • LPAR B → assume

📄 Fluxo

Transação → LPAR A
Falha → redireciona → LPAR B
Usuário continua

💡 Easter Egg 🔥

“Sysplex não é cluster…
é cluster que não te deixa na mão.”


🌍 LAB 4 — “PERDEMOS O DATA CENTER” (DR SIMULADO)

🎯 Objetivo:

Simular desastre total


🧠 Cenário

  • Site A caiu 💥
  • Site B assume

📄 Exercício

  1. Imagine seu sistema rodando
  2. “Desligue” mentalmente o ambiente
  3. Suba outro ambiente

👉 Perguntas:

  • Quanto tempo levou? (RTO)
  • Perdeu dados? (RPO)

💡 Resposta ideal

  • RTO → segundos/minutos
  • RPO → zero

🔥 Insight

“Se você precisa pensar muito no DR… ele já falhou.”


🧨 LAB 5 — “DESCUBRA SEU SPOF”

🎯 Objetivo:

Encontrar ponto único de falha


📄 Checklist

  • Um único job crítico?
  • Um único DB?
  • Um único operador? 😅

💡 Easter Egg

SPOF mais comum:
👉 Interface Teclado-Cadeira


🤖 LAB 6 — “AUTOMA OU MORRE”

🎯 Objetivo:

Entender automação


📄 Cenário

Sem automação:

  • detectar
  • analisar
  • agir

👉 minutos ou horas


Com automação:

  • detectar
  • agir

👉 segundos


💡 Insight brutal

“Sem automação, seu RTO é humano.”


🧪 LAB 7 — DR TEST (O GRANDE FINAL)

🎯 Objetivo:

Validar tudo


📄 Simulação

  1. Derrube o “ambiente”
  2. Ative backup
  3. Valide sistema

📊 Checklist

  • Sistema subiu?
  • Dados íntegros?
  • Tempo aceitável?

💡 Regra de ouro

“DR não testado = DR inexistente”


🧠 CONSOLIDAÇÃO FINAL


🔗 RELAÇÃO DOS CONCEITOS

  • RAS → evita impacto
  • Models → define arquitetura
  • Planning → garante execução

💥 Fluxo completo

Falha pequena → ARM resolve
Falha média → Sysplex resolve
Desastre total → DR/GDPS resolve

🏁 MISSÃO FINAL DO LAB

👉 Você não está testando sistema
👉 Você está testando sobrevivência do negócio


🔥 FRASE FINAL

“No mainframe, o erro não é falhar…
é deixar o usuário perceber.”

 

sexta-feira, 3 de abril de 2026

💀 Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações

 

Bellacosa Mainframe introduz o DB2

💀 “Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações”

Se você acha que banco de dados é só “guardar informação”… prepare-se: no mundo corporativo pesado — bancos, seguradoras, governos — quem reina é a dupla COBOL + Db2.
E não, isso não é legado morto. Isso é infraestrutura crítica global.


🧬 Origem: quando dados viraram ciência

Antes do Db2, existia caos.

  • arquivos flat
  • duplicação
  • dificuldade de acesso

Então surge o modelo relacional, criado por Edgar F. Codd na IBM.

👉 Resultado:

  • tabelas
  • chaves
  • SQL

E nos anos 80 nasce o Db2, trazendo isso para o mundo enterprise.


🏛️ Db2 no Mainframe: onde o jogo é sério

O Db2 roda no z/OS, lado a lado com:

  • COBOL
  • CICS
  • IMS

💀 Tradução:

Isso aqui processa dinheiro de verdade


☕ O Dev COBOL Sênior (vida real)

Imagine um sistema bancário:

Cliente faz transferência → COBOL → Db2 → commit

💡 Exemplo COBOL + Db2

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - 100
WHERE ID = :ORIGEM
END-EXEC.

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + 100
WHERE ID = :DESTINO
END-EXEC.

EXEC SQL
COMMIT
END-EXEC.

👉 Simples? Sim.
👉 Crítico? ABSURDAMENTE.


🔄 Transações: o coração do sistema

Você viu isso no módulo — aqui é onde ganha vida:

START → UPDATE → COMMIT

Se falhar:

ROLLBACK

💀 Isso evita:

  • dinheiro sumir
  • inconsistência

📜 Logging: a caixa preta do banco

Db2 registra TUDO:

  • INSERT
  • UPDATE
  • DELETE

👉 Isso permite:

  • auditoria
  • recovery
  • rastreamento

💡 Insight

Sem log… você está cego
Com log… você reconstrói o passado


🔄 Recovery: sobrevivência do sistema

Cenário:

  • backup às 6:00
  • falha às 11:00

👉 solução:

Backup + Logs = estado correto

💾 Backup no mundo real

❄️ Cold

  • banco parado

🌡️ Warm

  • leitura apenas

🔥 Hot

  • banco online (produção)

💀 No banco:

parar sistema não é opção → usa hot backup


🔒 Locking: guerra silenciosa

3 programas acessando o mesmo registro:

App1 → lock
App2 → espera
App3 → leitura controlada

👉 Locks evitam corrupção


💡 Regra de ouro

Lock só é liberado no COMMIT


⚡ Performance: onde o DBA brilha

📦 Buffers

  • memória → rápido

📚 Index

  • busca instantânea

⚙️ Optimizer

  • escolhe melhor plano

👉 Exemplo:

Sem índice:

SELECT * FROM CLIENTE WHERE NOME='JOÃO';

Com índice:

CREATE INDEX IDX_NOME ON CLIENTE(NOME);

⚡ diferença absurda


🌐 Integração moderna (sim, Db2 evoluiu)

Hoje Db2 conversa com:

  • APIs
  • Java (JDBC)
  • ODBC
  • microservices

👉 Não é mais só terminal verde 😄


🧠 Stored Procedures: lógica dentro do banco

CREATE PROCEDURE TRANSFERIR(...)

👉 roda dentro do Db2
👉 menos rede
👉 mais performance


🧬 Easter Eggs & Curiosidades

💡 Db2 nasceu dentro da IBM Research
💡 COBOL ainda processa ~70% das transações financeiras mundiais
💡 Muitos sistemas críticos têm décadas sem downtime significativo


💀 Easter Egg raiz:

“If it ain’t broken, don’t migrate it”
(tradução: se está rodando há 30 anos… NÃO mexe 😄)


🔥 Insight nível Bellacosa

Mainframe não é legado…
é infraestrutura estável, segura e absurda em escala


🧠 Visão final (arquitetura)

Usuário → Aplicação (COBOL) → Db2 → Dados

Logs / Backup / Recovery

🚀 Conclusão

Você começou aprendendo:

  • o que é banco
  • modelos
  • DBMS
  • transações
  • logs
  • backup
  • performance

👉 E chegou aqui:

💀 Entendendo como o mundo financeiro roda


💥 Frase final

Enquanto todo mundo fala de cloud…
o dinheiro do mundo continua passando por COBOL + Db2

 

terça-feira, 31 de março de 2026

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

 

Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

  • sobem pra memória
  • descem pra disco
  • migram pra fita
  • aparecem em outro LPAR
  • e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥


🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.


🔥 O que isso significa?

  • memória protegida
  • ambiente independente
  • controle total do sistema

💡 Insight

cada address space é um “universo privado”


⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES


🔥 Evolução histórica

EraLimite
24-bit16MB 😱
31-bit2GB
👉 64-bit16EB 🤯

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”


🧠 Uso real

  • Java
  • Db2
  • middleware
  • grandes buffers

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real


🔥 Sem DAT:

  • programa quebraria
  • memória não funcionaria

💡 Tradução

“você nunca acessa memória real diretamente”


🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

  • GETMAIN
  • STORAGE OBTAIN

🔥 O sistema decide:

  • onde alocar
  • em qual subpool
  • com qual proteção

💡 Insight

memória é gerenciada, não livre


🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools


🔥 Exemplos:

  • SP0 → sistema
  • SP229 → usuário

💡 Tradução

“cada tipo de dado tem seu bairro”


🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

  • dados fora do address space
  • acessados via AR

🔹 Hiperspaces

  • alta performance
  • acesso indireto

🔥 Tradução Bellacosa

“memória extra fora do seu universo”


🧠 Exemplo

Programa → usa Data Space → grande volume de dados

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)


🔥 Fluxo

Memória cheia

página vai para DASD

quando necessário → volta

💡 Problema

👉 excesso de paging = sistema lento 💀


💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

  • baixa latência
  • alta velocidade
  • ideal para OLTP

💡 Uso

  • Db2
  • logs
  • datasets críticos

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄


🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema


💡 Elementos:

  • LPARs
  • Coupling Facility (CF)
  • links de comunicação

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

💡 Tradução

“dados compartilhados em tempo real”


🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

  • lock management
  • cache
  • filas

🔥 Tipos:

  • Internal CF
  • External CF

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”


⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

  • duplica dados
  • garante disponibilidade

💡 Exemplo

CF primário → falha
CF secundário → assume

🧨 Curiosidade

Sistema continua rodando sem impacto 😳


🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

  • locks
  • buffers
  • filas

💡 Uso real

  • Db2 data sharing
  • CICS
  • IMS

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

💡 Insight

performance é resultado do conjunto


🔄 14. PASSO A PASSO COMPLETO

Programa inicia

recebe address space

pede memória (GETMAIN)

DAT traduz endereço

usa data space se necessário

paging ocorre se faltar memória

dados vão para disco/flash

sysplex compartilha dados via CF

duplex garante disponibilidade

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está


🔥 2. Dados podem estar fora do seu address space


💀 3. Paging excessivo mata performance


🧠 4. Sysplex permite vários sistemas compartilharem dados


⚡ 5. CF é o segredo da alta disponibilidade


🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência


💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

quarta-feira, 7 de janeiro de 2026

🔥 SEU VSAM ESTÁ TE SEGURANDO… OU TE LIMITANDO?

 

Bellacosa Mainframe apresenta o VSAM RLS superpoderes em dataset

🔥 SEU VSAM ESTÁ TE SEGURANDO… OU TE LIMITANDO?

💣 VSAM RLS: o modo transacional escondido do z/OS que poucos dominam (e menos ainda sabem usar direito)

Se você ainda trata VSAM como dataset batch com lock global…
👉 você está deixando throughput, concorrência e disponibilidade na mesa.

Hoje vamos abrir a caixa-preta do VSAM RLS (Record-Level Sharing) — no nível que interessa para quem já respira COBOL, CICS e JCL.


🧠 Origem: quando o VSAM precisou evoluir ou morrer

O VSAM nasceu lá atrás, nos tempos de:

  • Batch dominante
  • Processamento sequencial
  • Lock em nível de dataset

Só que o mundo mudou:

  • CICS explodiu
  • OLTP virou padrão
  • Multi-LPAR virou realidade

👉 E o VSAM começou a virar gargalo.


🚀 O nascimento do RLS

O RLS surgiu no z/OS como resposta direta a esse problema:

👉 permitir concorrência real sem reescrever tudo para DB2

Baseado em:

👉 IBM Coupling Facility

💡 Data de adoção forte: final dos anos 90 / início dos 2000 (z/OS já consolidando Parallel Sysplex)


⚙️ O que é VSAM RLS (sem romantismo)

VSAM RLS é:

Um mecanismo que move o controle de lock e cache para fora do dataset e coloca no Coupling Facility

Resultado:

  • 🔐 Lock em nível de registro (ou CI)
  • 🧠 Cache compartilhado entre LPARs
  • ⚡ Acesso simultâneo real

🔍 Como funciona (visão de arquitetura)

Sem RLS:

Programa → VSAM → Disco
(lock global)

Com RLS:

Programa → VSAM → CF (lock/cache) → Disco

👉 O CF vira o “gerente de concorrência”


🧪 IDCAMS: como nasce um VSAM RLS

Aqui começa a responsabilidade.

DEFINE CLUSTER(NAME(PROD.CLIENTES.RLS)
INDEXED
KEYS(10 0)
RECORDSIZE(100 100)
SHAREOPTIONS(3 3)
LOG(UNDO)
FREESPACE(10 10)
)

⚠️ Pontos críticos

  • SHAREOPTIONS(3 3) → obrigatório para multi-acesso
  • LOG(UNDO) → rollback consistente
  • Dataset precisa ser SMS-managed

📖 Exemplo COBOL – leitura com RLS

SELECT CLIENTES ASSIGN TO VSAMFILE
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY IS WS-KEY
FILE STATUS IS WS-STATUS.

READ CLIENTES
INVALID KEY
DISPLAY "NAO ENCONTRADO"
END-READ.

👉 Aqui o lock é gerenciado pelo RLS automaticamente.


✍️ Exemplo COBOL – gravação com concorrência

WRITE REGISTRO-CLIENTE
INVALID KEY
DISPLAY "ERRO NA GRAVACAO"
END-WRITE.

Ou update:

READ CLIENTES
UPDATE
INVALID KEY
...
END-READ.

REWRITE REGISTRO-CLIENTE.

💡 O segredo:

👉 O lock é no registro, não no dataset.


⚖️ Locking: onde mora o poder (e o perigo)

Tipos:

  • 🔹 RECORD → alta concorrência (recomendado)
  • 🔹 CI → menos overhead, mais contenção

📊 Monitoramento (vida real)

Ferramentas:

  • RMF
  • SMF

Métricas que importam

  • Lock contention
  • CF response time
  • Cache hit ratio
  • Buffer efficiency

🚀 Pontos fortes (quando bem usado)

✔️ Concorrência absurda

  • Batch + CICS juntos
  • Sem fila de espera

✔️ Alta disponibilidade

  • CF permite resiliência
  • Recovery consistente

✔️ Escalabilidade

  • Multi-LPAR sem dor

💣 Pontos fracos (o lado sombrio)

❌ Complexidade operacional

  • Não é plug-and-play
  • Exige tuning constante

❌ Dependência do CF

Se o CF sofre…

👉 todo mundo sofre


❌ Debug mais difícil

  • Deadlock não é trivial
  • Problemas são distribuídos

⚠️ Limitações (que pegam senior distraído)

  • ❌ Skip-sequential → proibido
  • ❌ Sequential update clássico → problema
  • ❌ Batch mal escrito → vira gargalo

🧪 Curiosidades de bastidor

💡 VSAM RLS é quase um “NoSQL raiz”

  • Sem SQL
  • Controle transacional básico
  • Altíssimo desempenho

💡 RLS vs DB2

VSAM RLSDB2
Ultra rápidoMais completo
Menos overheadMais recursos
Sem SQLSQL completo

🧠 Caso real (modo guerra)

Cenário:

  • 5 regiões CICS
  • 2 jobs batch
  • 1 dataset VSAM crítico

Sem RLS:

👉 fila de espera
👉 SLA estourando

Com RLS:

👉 concorrência plena
👉 throughput triplicado


⚙️ Tuning (o que separa júnior de senior)

🎯 Ajustes críticos

  • Buffer pool
  • Estrutura do CF
  • Lock level
  • Cache strategy

💡 Regra de ouro

RLS mal configurado é pior que não usar RLS


🔥 Insight final (Bellacosa mode ON)

VSAM RLS é isso:

“Transformar VSAM de arquivo batch em engine transacional distribuído”

Se você domina RLS:

👉 você reduz fila
👉 aumenta throughput
👉 salva SLA

Se você ignora:

👉 seu sistema vira gargalo invisível


☕ Fechamento

VSAM não morreu.

Ele só evoluiu.

E o RLS é o ponto onde:

👉 legado encontra alta performance
👉 batch encontra tempo real
👉 e o COBOL continua reinando 👑

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...