✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta FICON. 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.

segunda-feira, 1 de dezembro de 2025

💥 SEU COBOL NÃO FAZ I/O — ELE COMANDA UM EXÉRCITO INVISÍVEL: O Verdadeiro Poder do Channel Subsystem no IBM z17

Bellacosa Mainframe entenda I/O e Channel Subsystem no Z/OS Mainframe

💥 SEU COBOL NÃO FAZ I/O — ELE COMANDA UM EXÉRCITO INVISÍVEL: O Verdadeiro Poder do Channel Subsystem no IBM z17

Se você é dev COBOL sênior e ainda pensa que um READ é só um acesso a disco…
👉 você está vendo apenas a ponta do iceberg.

Porque no mundo do IBM Z (como o z17), o que parece simples esconde uma das arquiteturas mais elegantes já criadas:

💥 Você não faz I/O… você orquestra uma máquina paralela de execução.

E essa máquina tem nome:

👉 Channel Subsystem (CSS)

🧠 🏛️ Um pouco de história (e por que isso é genial)

Lá nos anos 60, enquanto outros sistemas faziam I/O travando a CPU, a IBM fez algo revolucionário:

👉 Criou processadores dedicados para I/O

💥 Resultado:

CPU livre
I/O paralelo
Escalabilidade absurda

Esse conceito nasceu no System/360…
e hoje, no IBM Z (z16/z17), virou uma máquina de throughput brutal.

🔥 O segredo que ninguém te contou

Quando você escreve:


READ CLIENTES-FILE

👉 O que você acha que acontece?

A CPU vai no disco? ❌
O COBOL faz leitura direta? ❌

💥 O que REALMENTE acontece

COBOL chama o access method (QSAM/VSAM)
Ele monta um Channel Program (CCW/DCW)
z/OS passa para o IOS
IOS dispara um SSCH (Start Subchannel)
O Channel Subsystem assume tudo
A Control Unit executa
O device responde
Uma interrupção volta

👉 E a CPU?
💥 Livre para trabalhar

🧠 Arquitetura — o mapa do poder

🔗 Componentes essenciais

Channel (CHPID) → caminhos
Control Unit (CU) → controlador
Device → disco/tape
Subchannel → ponte invisível
UCB → ficha do device no z/OS

💡 Insight Bellacosa

O device é o destino…
o subchannel é o caminho real.

⚙️ Channel Program — o “script secreto”

👉 Você não vê, mas ele existe:


LOCATE
READ
READ

💥 Isso é enviado para o hardware executar.

🧠 Easter Egg técnico

👉 CCW não roda na CPU

👉 Ele roda:

No CSS
Na CU
Com suporte do SAP

💥 É um “programa fora do sistema operacional”

🚀 zHPF — quando o I/O virou turbo

👉 Problema antigo:

CCW = muita conversa

👉 Solução:

zHPF (High Performance FICON)
Usa DCW + TCCB

💥 Resultado:

Menos overhead
Mais throughput
Menos latência

💾 O maior gargalo (e como o mainframe resolve)

❌ Regra antiga

1 UCB = 1 I/O

👉 Resultado:

Fila
Lentidão

🔥 PAV — a virada de jogo

👉 Solução:

Criar aliases (UCBs adicionais)
Permitir I/O paralelo

🧠 Evolução

Static PAV → fixo
Dynamic PAV → WLM
HyperPAV → IOS 🚀

💥 Insight

PAV não acelera o disco…
ele elimina a fila

🔍 Diagnóstico real (nível produção)

Você abre o RMF e vê:


RESPONSE TIME = 25 ms
IOSQ = 18 ms
SERVICE = 6 ms

🧠 Tradução

Disco rápido ✔
Fila enorme ❌

💥 Problema = contenção

🚀 Solução

👉 Ativar HyperPAV

☕ Analogias (pra nunca esquecer)

Channel → estrada
CU → pedágio
Device → destino
UCB → cadastro
Subchannel → rota GPS

🧠 Curiosidades (nível insider)

💡 O CSS pode escolher automaticamente o melhor path
💡 Você pode ter dezenas de paths para um device
💡 I/O continua mesmo com falha de hardware
💡 O z/OS raramente toca no I/O diretamente

🔥 O erro que até sênior comete

“O disco está lento”

💥 Na maioria das vezes:

“O disco está concorrendo”

🚀 Mentalidade de especialista

Sempre pergunte:

É fila ou execução?
Qual volume está quente?
Tenho paralelismo suficiente?

🎯 Conclusão — o verdadeiro poder

Se você entendeu isso, você saiu de:

Dev COBOL
👉 para
Arquiteto de I/O

💥 Frase final Bellacosa

“No mainframe, você não faz I/O…
você delega para uma máquina feita para isso — e ela nunca dorme.” 😎

segunda-feira, 18 de julho de 2022

Muito Além do IBM Z: A Anatomia Completa de um Datacenter Mainframe

Bellacosa Mainframe e a anatomia de um datacenter mainframe ibm z

☕ Um Café no Bellacosa Mainframe

Muito Além do IBM Z: A Anatomia Completa de um Datacenter Mainframe

O Guia Definitivo para um Programador COBOL Padawan Entender Como Cada Cabo, Tubo, Rack e Equipamento Trabalha em Harmonia para Manter Bancos, Cartões de Crédito e Bolsas de Valores Funcionando 24 Horas por Dia

"Um programa COBOL nunca executa sozinho. Antes que uma única instrução MOVE seja processada, existe um verdadeiro ecossistema de engenharia trabalhando silenciosamente para que tudo aconteça."

Introdução

Existe uma cena clássica em filmes de ficção científica: o herói entra em uma enorme sala repleta de luzes, armários metálicos, tubos coloridos, cabos grossos, ventiladores gigantes e quilômetros de equipamentos.

Para a maioria das pessoas aquilo parece apenas uma sala cheia de máquinas.

Para um programador COBOL experiente...

Aquilo é praticamente uma cidade.

A imagem que analisamos representa exatamente isso.

Embora seja uma renderização artística, ela retrata com bastante fidelidade como funciona a infraestrutura de um datacenter corporativo moderno onde vivem os grandes IBM Z.

Quando um programador COBOL escreve:

EXEC SQL
SELECT SALDO
FROM CONTA
END-EXEC

ele normalmente imagina apenas:

Programa → Banco de Dados

Mas, na realidade, essa simples consulta percorre dezenas de equipamentos.

Hoje faremos uma verdadeira visita guiada pelo coração de um datacenter IBM Mainframe.

Pegue seu café.

Vamos entrar.

Bellacosa Mainframe e um moderno cpd centro de processamento de dados

Vista Geral da Sala

Imagine que estamos entrando nesta sala.

A primeira impressão é de organização absoluta.

Nada está ali por acaso.

Cada tubo possui uma função.

Cada cabo tem identificação.

Cada rack possui redundância.

Cada equipamento conversa com dezenas de outros equipamentos.

É exatamente como um grande programa COBOL bem escrito.

Se retirar uma instrução importante...

todo o restante pode parar.

O Teto: Onde Começa a Engenharia

Muitos iniciantes olham apenas para os computadores.

Os veteranos olham primeiro para o teto.

Por quê?

Porque boa parte da infraestrutura passa justamente acima dos equipamentos.

Ali encontramos:

barramentos elétricos
fibra óptica
tubulações
sensores
detectores de fumaça
iluminação
sistema anti-incêndio
monitoramento ambiental

É praticamente um "JCL da infraestrutura".

Painéis de LED

Os painéis brancos não servem apenas para iluminar.

Eles possuem:

baixo consumo
pouca emissão de calor
longa vida útil
alimentação redundante

Em alguns datacenters críticos, até a iluminação possui dupla alimentação.

Se uma UPS falhar...

a sala continua iluminada.

As Grandes Bandejas Porta-Cabos

Observe aquelas estruturas metálicas horizontais.

Elas são chamadas de:

Cable Tray

Cable Ladder.

Ali passam centenas de quilômetros de cabos.

Sim.

Quilômetros.

Em grandes bancos não é raro existir mais de 100 km de cabeamento.

Essas bandejas carregam:

fibra óptica
Ethernet
alimentação
gerenciamento
SAN
FICON
cabos de sincronismo

Existe uma regra importante:

Energia nunca deve viajar junto com dados.

Isso reduz interferências eletromagnéticas.

Os Barramentos Elétricos (Busway)

Ao invés de milhares de cabos grossos...

utiliza-se um grande barramento.

Imagine uma avenida principal.

Dela saem pequenas ruas alimentando cada rack.

Subestação

↓

UPS

↓

Busway

↓

Tap Box

↓

Rack IBM Z

É uma solução muito mais segura.

Os Tubos Coloridos

Talvez sejam o detalhe mais interessante da imagem.

Eles fazem parte do sistema hidráulico do datacenter.

Sim.

Existe hidráulica dentro da sala.

E muita.

Os tubos podem transportar:

Água gelada

Água de retorno

Água industrial

Água para trocadores de calor

Circuitos secundários

Em um IBM z17, centenas de quilowatts de calor precisam ser removidos continuamente.

Easter Egg Bellacosa ☕

Todo iniciante acredita que um computador "esquenta um pouco".

Na realidade...

Um único IBM Z pode dissipar mais calor do que dezenas de aparelhos de ar-condicionado domésticos funcionando simultaneamente.

Por isso existe uma verdadeira usina de refrigeração.

Os Flexíveis Pretos

Cada conjunto preto descendo até os racks provavelmente representa conduítes.

Dentro deles passam:

fibras ópticas
alimentação redundante A
alimentação redundante B
cabos de gerenciamento
sensores ambientais

Tudo separado.

Tudo identificado.

Tudo documentado.

Descidas Individuais

Nenhum rack recebe apenas um cabo.

Normalmente encontramos:

Energia A

Energia B

Fibra A

Fibra B

Rede administrativa

Rede de monitoramento

Aterramento

Tudo redundante.

O Piso Elevado

Embora não apareça na imagem...

quase certamente existe.

Imagine um piso falso com cerca de 60 centímetros.

Debaixo dele passam:

energia

fibras

água

aterramento

ar frio

É praticamente uma segunda cidade escondida.

Os Racks

Agora chegamos à parte mais visível.

Os gabinetes pretos.

Eles podem conter praticamente qualquer equipamento.

Em um datacenter IBM normalmente encontramos:

IBM z17

IBM z16

LinuxONE Emperor

Storage DS8900F

SAN Switch

OSA Express

Crypto Express

Open Systems Servers

Appliances

HMC

IBM z17

O protagonista.

Ali vivem:

CPs

zIIPs

zAAPs (histórico)

IFLs

SAPs

RAIM

Memória

Cache

Canal I/O

Processadores criptográficos

Tudo redundante.

Hardware Management Console (HMC)

Sem ela praticamente não existe IBM Z.

A HMC permite:

IPL

Shutdown

LPAR

Monitoramento

Capacity Planning

Firmware

Diagnóstico

É o painel de controle da nave espacial.

Storage IBM DS8900F

Ao lado do IBM Z quase sempre existe um storage.

Os dados não ficam "dentro" do mainframe.

Eles ficam aqui.

Dentro dele existem:

NVMe

Flash

Cache

RAID

Processadores próprios

Compressão

Deduplicação

Criptografia

SAN Directors

Eles são as grandes rotatórias do armazenamento.

Utilizam:

Fibre Channel

FICON

NVMe over FC

Conectam:

IBM Z

Storage

Backup

Tape

OSA Express

É a placa de rede do IBM Z.

Pode oferecer:

10 Gb

25 Gb

100 Gb

TCP/IP

IPv6

OSA-Express Integrated

Crypto Express

Pouca gente sabe...

O IBM Z possui placas dedicadas para criptografia.

Elas executam:

AES

RSA

ECC

SHA

TLS

PIN bancário

PIX

Open Banking

Tudo acelerado por hardware.

FICON

O COBOL acessa um arquivo VSAM.

O VSAM está no DS8900F.

Como chegam os dados?

Pelos canais FICON.

Eles substituíram os antigos ESCON.

São verdadeiras autoestradas ópticas.

Tape Library

Mesmo em 2026...

fitas continuam existindo.

IBM TS4500

TS7700

LTO

3592

Porque:

backup

retenção

compliance

baixo custo

UPS

Nenhum IBM Z fica ligado diretamente na concessionária.

Entre a rua e o computador existem:

UPS

Bancos de baterias

Inversores

Retificadores

Filtros

Transformadores

Geradores

Quando acaba a energia:

0 segundos

Baterias.

Poucos segundos depois:

Entram os geradores diesel.

O IBM Z nem percebe.

CRAH

Computer Room Air Handler.

Ele recebe água gelada.

Remove calor.

Empurra ar frio.

Tudo continuamente.

Chiller

Fica normalmente fora do prédio.

É o responsável por produzir água gelada.

Sem ele...

nenhum datacenter sobrevive.

Sensores

Espalhados pela sala existem centenas deles.

Temperatura

Umidade

Fumaça

Vibração

Água

Pressão

Energia

Fluxo de ar

Todos ligados ao BMS.

BMS

Building Management System.

É o "z/OS" do prédio.

Controla:

energia

portas

alarmes

incêndio

temperatura

bombas

geradores

Sistema Anti-incêndio

Jamais utilize água.

Os sistemas modernos usam:

FM-200

Novec 1230

Inergen

Eles retiram o oxigênio suficiente para apagar o fogo sem danificar os equipamentos.

Detectores VESDA

Muito antes da fumaça aparecer...

eles detectam partículas microscópicas.

É um dos sistemas mais impressionantes de um datacenter.

Segurança Física

Cartão RFID

Biometria

Reconhecimento facial

Mantrap

CFTV

Guarda 24x7

Registro de acesso

Nada entra sem autorização.

O Caminho de um Simples Programa COBOL

Imagine que você executa:

JOB
 ↓
JES2
 ↓
z/OS
 ↓
COBOL
 ↓
Db2
 ↓
FICON
 ↓
SAN
 ↓
DS8900F
 ↓
SSD Flash
 ↓
Retorno

Tudo isso acontece em milissegundos.

Enquanto isso:

✔ CRAH remove calor

✔ UPS estabiliza energia

✔ Busway distribui alimentação

✔ Chiller produz água gelada

✔ HMC monitora processadores

✔ RMF coleta desempenho

✔ SMF registra estatísticas

✔ RACF protege acessos

✔ WLM prioriza cargas

✔ GDPS pode manter um site de contingência sincronizado

E o programador apenas vê:

DISPLAY "PROCESSAMENTO OK".

A Grande Lição para um Programador COBOL Padawan

Existe uma tendência natural entre iniciantes de acreditar que a programação começa e termina no editor de código. Porém, um sistema corporativo executado em um IBM Z depende de uma infraestrutura gigantesca: energia redundante, climatização de precisão, armazenamento de altíssimo desempenho, redes ópticas, segurança física, monitoramento ambiental e dezenas de componentes especializados trabalhando de forma sincronizada.

Compreender essa arquitetura transforma a maneira como enxergamos o desenvolvimento. Um SELECT no Db2, uma leitura em VSAM ou uma transação CICS percorrem uma cadeia sofisticada de hardware e software antes de retornar o resultado ao usuário.

Essa é uma das maiores lições do universo mainframe: programar bem significa entender o ecossistema completo. Quanto mais o programador COBOL conhece a infraestrutura que sustenta suas aplicações, mais preparado estará para escrever sistemas eficientes, diagnosticar problemas e dialogar com equipes de operações, redes, armazenamento e administração do z/OS.

No mundo IBM Mainframe, o código é apenas a ponta visível de um iceberg de engenharia construído para entregar disponibilidade, desempenho e confiabilidade ininterruptos. É essa combinação de software e infraestrutura que permite aos grandes bancos, seguradoras, companhias aéreas e bolsas de valores processarem milhões de transações por segundo, todos os dias, sem que a maioria das pessoas sequer perceba que um IBM Z está trabalhando silenciosamente nos bastidores.

domingo, 10 de novembro de 2019

☕💥 A Jornada do Padawan COBOL – Parte 11 Desvendando o Universo dos CALLs no Mainframe

Bellacosa Mainframe apresenta o call em cobol parte xi

☕💥 A Jornada do Padawan COBOL – Parte 11

Desvendando o Universo dos CALLs no Mainframe

GRS, ENQ/DEQ, VVDS, VTOC, UCB, IOS, FICON, Channel Subsystem e os Segredos dos Guardiões do Storage IBM Z

Ou como descobrir que, antes de um simples OPEN funcionar, dezenas de componentes já trabalharam silenciosamente para você

Por Vagner Bellacosa – Bellacosa Mainframe

O dia em que o Padawan percebe que um OPEN não é apenas um OPEN

Após dez capítulos, nosso Padawan já entende:

✔ CALL

✔ LE

✔ CICS

✔ JES2

✔ RMF

✔ Telum

✔ Spyre

✔ DevOps

Então ele escreve:

OPEN INPUT CLIENTES

E pensa:

Deve ser simples...

Veterano do Storage sorri.

Não responde.

Abre RMF.

Abre ISMF.

Abre DEVSERV.

E diz:

— Vamos conversar.

O Grande Segredo

Antes do OPEN ocorrer.

Diversos subsistemas trabalham.

Visualmente


COBOL

↓

OPEN

↓

LE

↓

Access Method

↓

Catalog

↓

VVDS

↓

VTOC

↓

UCB

↓

IOS

↓

Channel Subsystem

↓

FICON

↓

DASD

Padawan:

— Tudo isso?

Veterano:

— Apenas para abrir um arquivo.

GRS

Global Resource Serialization

Pouquíssimos desenvolvedores conhecem.

Todos usam.

Diariamente.

Ele evita.

Caos.

Imagine:

Programa A

Atualizando KSDS.

Programa B

Atualizando KSDS.

Programa C

Atualizando KSDS.

Sem GRS.

Corrupção.

Com GRS.

Ordem.

Disciplina.

ENQ

Reserve recurso.

Exemplo

ENQ


SYSDSN


CLIENTE.MASTER

Programa obtém.

Exclusividade.

DEQ

Libera.

Exemplo

DEQ


CLIENTE.MASTER

Easter Egg

Muitos problemas batch.

São.

ENQ presos.

Como descobrir?

SDSF

GRSQ

D GRS

RESERVE

Mais antigo.

Bloqueia.

Dispositivo físico.

Pouco usado.

Hoje.

Sysplex prefere.

GRS.

Catalog

O Google.

Do Mainframe.

Pergunta.

Onde está.

CLIENTE.MASTER?

Catalog responde.

Volume.

Device.

VVDS.

VVDS

VSAM Volume Data Set

Armazena.

Informações VSAM.

Exemplo

KSDS.

ESDS.

RRDS.

VTOC

Volume Table Of Contents

O índice.

Do disco.

Sem VTOC.

Nada existe.

Visualmente


3390


↓

VTOC


↓

Dataset

DSCB

Data Set Control Block

Informações.

Dataset.

Organização.

Extents.

Blocos.

UCB

Unit Control Block

Representa.

Dispositivo.

Exemplo

3390-123


UCB


ONLINE

IOS

Input Output Supervisor

Herói desconhecido.

Gerencia.

I/O.

Escalona.

Requisições.

Comunica.

Canal.

Channel Subsystem

Uma obra-prima IBM.

CPU.

Não conversa.

Diretamente.

Com disco.

Canal conversa.

Visualmente


CPU


↓


CSS


↓


FICON


↓


Storage

FICON

Fiber Connectivity

Substituiu.

ESCON.

Velocidade.

Gigabits.

Latência.

Mínima.

Disponibilidade.

Enorme.

Pidb

Pouco conhecido.

Performance Information Data Base

Engenheiros IBM.

Gostam.

Muito.

Dynamic Path Management

Storage inteligente.

Falhou caminho?

Troca automaticamente.

Aplicação.

Nem percebe.

HyperPAP

Outro segredo.

Balanceia.

I/O.

Otimiza.

Caminhos.

OPEN em detalhes

Padawan escreve.

OPEN INPUT CLIENTE

Sistema executa.


OPEN


↓

Catalog


↓

VVDS


↓

VTOC


↓

GRS


↓

IOS


↓

CSS


↓

FICON


↓

DASD


↓

Retorna

Tudo.

Em milissegundos.

O dia em que o arquivo não abre

Padawan vê.

IEC161I

Pânico.

Veterano pergunta.

Volume?

Catalog?

VVDS?

ENQ?

Path?

FICON?

IOS?

Padawan.

Silêncio.

Ferramentas Jedi

LISTCAT

LISTCAT ENT(CLIENTE.MASTER)

D U,DASD

Ver dispositivos.

DEVSERV

Ver caminhos.

D GRS

Ver locks.

ISMF

Storage Management.

RMF

Pode mostrar.

Tempo de I/O.

Cache Hit.

Miss.

Path Busy.

SMF

Tipos úteis.

SMF42

DFSMS

SMF74

Coupling

SMF70

CPU

Dicas Bellacosa

Dica 1

Aprenda LISTCAT.

Dica 2

Estude VVDS.

Dica 3

GRS salva vidas.

Dica 4

FICON é fascinante.

Dica 5

IOS merece respeito.

Easter Egg Mainframe

Existe um pequeno grupo.

Que consegue olhar.

Isto.

IOS000I


GRS


SMF42


RMF74


UCB


VVDS

E descobrir.

Em dez minutos.

Porque um banco inteiro.

Parou.

Eles.

Não usam capa.

Mas deveriam.

São conhecidos.

Como.

Os Guardiões do Storage IBM Z

Checklist Jedi

✅ Entender GRS

✅ Conhecer ENQ

✅ Conhecer DEQ

✅ Estudar Catalog

✅ Dominar LISTCAT

✅ Aprender VVDS

✅ Entender VTOC

✅ Conhecer UCB

✅ Respeitar IOS

✅ Estudar CSS

✅ Conhecer FICON

✅ Interpretar RMF

A Filosofia Jedi – Parte 11

O Padawan iniciante acredita:

OPEN é um comando.

O desenvolvedor experiente pensa:

OPEN localiza datasets.

O especialista compreende:

OPEN coordena dezenas de componentes do z/OS.

E o Arquiteto IBM Z sabe algo ainda mais profundo:

Um simples OPEN INPUT CLIENTE aciona mecanismos de serialização global, gerenciamento de catálogos, subsistemas de I/O, canais FICON, estruturas de controle de storage e décadas de engenharia IBM, tudo isso para que o desenvolvedor apenas enxergue:

OPEN INPUT CLIENTE

E continue acreditando que foi algo simples.

Próxima aventura do Padawan COBOL – Parte 12

"As Runas Finais do IBM Z: PSA, CVT, ASCB, TCB, RB, SRB, ACEE, CSA, ECSA, SQA, LSQA, PSA Internals e os mistérios dos Control Blocks que sustentam todo o universo z/OS."

domingo, 20 de maio de 2018

IBM Mainframe Discovery : Capítulo V — A Frota Invisível do Transporte Interestelar

Bellacosa Mainframe apresenta ibm mainframe parte v

☕ Um Café no Bellacosa Mainframe

Capítulo V — A Frota Invisível do Transporte Interestelar

O Subsistema de Entrada e Saída (I/O): Por Que o IBM Z Nunca Deixa a CPU Carregar Caixas

SEGUNDA REGRA DA ENGENHARIA GALÁCTICA

Se você encontrar o capitão de uma nave descarregando caixas no depósito...

...alguma coisa está profundamente errada.

O capitão deveria estar comandando.

Os pilotos deveriam estar voando.

Os cientistas pesquisando.

Os médicos salvando vidas.

Existe uma razão para isso.

Especialistas produzem mais quando fazem aquilo para o qual foram projetados.

Curiosamente...

o IBM Mainframe pensou exatamente assim.

Enquanto boa parte dos computadores do planeta obriga a CPU a cuidar de detalhes de Entrada e Saída (I/O)...

o IBM Z simplesmente responde:

"Desculpe... eu tenho uma tripulação especializada para isso."

Hoje vamos conhecer uma das maiores obras de engenharia da computação moderna.

O lendário subsistema de I/O do Mainframe.

O Grande Porto Espacial

Imagine uma gigantesca estação espacial.

Todos os dias chegam:

20 mil cargueiros.

40 mil naves.

Milhões de passageiros.

Bilhões de contêineres.

Agora imagine que existe apenas um único funcionário organizando tudo.

O resultado seria previsível.

Caos.

Filas.

Colisões.

Aeroportos fechados.

Agora imagine outra estação.

Ela possui:

controladores de voo.

torres independentes.

radares.

equipes de solo.

docas automáticas.

computadores dedicados.

Cada profissional cuida apenas da sua especialidade.

Essa segunda estação lembra muito mais o IBM Z.

O Erro Mais Comum dos Computadores

Grande parte dos computadores tradicionais segue um modelo simples.

A CPU deseja ler um arquivo.

Então ela:

manda o pedido.

espera.

confere.

espera novamente.

recebe os dados.

volta ao trabalho.

É como um comandante abandonar a ponte de comando para verificar pessoalmente se o caminhão de suprimentos chegou.

O IBM Z Não Tem Tempo Para Isso

No universo Mainframe existe uma filosofia extremamente elegante.

A CPU deve executar programas.

Mais nada.

Todo o restante...

alguém especializado resolve.

Foi exatamente essa ideia que moldou todo o subsistema de Entrada e Saída.

Segundo Wilhelm G. Spruth, uma das razões da enorme capacidade de processamento transacional do System z é justamente descarregar boa parte do trabalho de I/O para componentes especializados, em vez de consumir ciclos da CPU principal.

Bem-vindo ao Centro Logístico da Galáxia

Imagine um centro de distribuição.

A CPU apenas escreve:

"Preciso deste arquivo."

Instantaneamente surge uma cadeia inteira de especialistas.

Cada um sabe exatamente o que fazer.

Sem interromper o comandante.

Sem desperdiçar energia.

Sem ocupar a ponte principal.

Os Control Units — As Docas Inteligentes

Chegamos ao primeiro personagem desta história.

As famosas:

Control Units.

Imagine uma gigantesca doca espacial.

Ela conversa com:

discos.

fitas.

SSD.

impressoras.

subsistemas.

A CPU sequer precisa conhecer os detalhes desses equipamentos.

Ela conversa apenas com a Control Unit.

É como um capitão dizendo:

"Quero abastecer."

Sem precisar saber:

qual mangueira.

qual válvula.

qual bomba.

Tudo isso fica sob responsabilidade da equipe da doca.

Spruth ressalta que funções tradicionalmente atribuídas a drivers de dispositivos em outras plataformas são executadas pelas Control Units no ambiente System z.

O Carteiro Nunca Vai Até a Floresta

Imagine um carteiro.

Ele não fabrica cartas.

Não escreve mensagens.

Não constrói estradas.

Ele apenas entrega.

As Control Units seguem exatamente essa lógica.

Elas especializam-se na comunicação entre a CPU e o universo externo.

Essa separação simplifica o sistema inteiro.

Drivers? Quase Não...

Aqui encontramos uma das maiores diferenças para Windows e Linux.

Nos PCs existe enorme quantidade de drivers.

Cada dispositivo possui o seu.

Cada fabricante faz diferente.

Cada atualização pode quebrar alguma coisa.

No Mainframe...

a maior parte dessa inteligência foi deslocada para o próprio hardware especializado.

Resultado?

Mais estabilidade.

Mais desempenho.

Menos complexidade para o sistema operacional.

O Channel Subsystem — O Controle de Tráfego Espacial

Agora imagine que existem milhares de cargueiros chegando ao mesmo tempo.

Quem organiza isso?

O verdadeiro maestro chama-se:

Channel Subsystem.

Pense nele como a torre de controle de um gigantesco porto espacial.

Ele decide:

qual caminho utilizar.

qual canal está livre.

qual dispositivo responderá.

qual rota está congestionada.

A CPU?

Nem toma conhecimento.

Segundo o relatório, o Channel Subsystem utiliza processadores especializados chamados System Assist Processors (SAPs), que executam esse gerenciamento fora do alcance do sistema operacional.

SAP — Os Pilotos Automáticos

Esses pequenos especialistas chamam-se:

SAPs

(System Assist Processors).

Imagine dezenas de controladores de voo trabalhando continuamente.

Enquanto isso...

a CPU continua executando COBOL.

CICS.

Db2.

Java.

Sem perder tempo organizando filas de discos.

É como contratar uma equipe inteira apenas para administrar aeroportos.

A Área Secreta da Nave

Existe um compartimento que praticamente nenhum programa consegue enxergar.

Ele chama-se:

Hardware System Area (HSA).

Pense nele como a sala de manutenção da nave.

Somente engenheiros autorizados entram ali.

É nesse ambiente que diversos mecanismos internos trabalham silenciosamente, incluindo parte da infraestrutura utilizada pelos SAPs e pelo gerenciamento dos canais.

Um Disco Pode Ter Muitas Estradas

Agora imagine uma cidade.

Existe apenas uma estrada.

Qualquer acidente paralisa tudo.

No IBM Z isso seria considerado um projeto ruim.

Em vez disso...

cada dispositivo pode possuir diversos caminhos.

Se um canal ficar indisponível...

outro assume.

Sem interromper a viagem.

Esse conceito é conhecido como:

Multiple Paths.

O GPS da Galáxia

Imagine um navegador inteligente.

Se uma rota congestiona...

ele muda imediatamente o caminho.

É exatamente isso que acontece.

O subsistema pode alterar dinamicamente a rota de uma operação de I/O.

A carga continua viajando.

O usuário nem percebe.

Spruth explica que uma operação pode inclusive terminar por um canal diferente daquele em que começou, graças ao gerenciamento dinâmico dos caminhos de conexão.

O Elevador Inteligente

Suponha um edifício de mil andares.

Cinco elevadores.

Todos recebem chamadas ao mesmo tempo.

Quem decide qual elevador atenderá cada passageiro?

O algoritmo.

No Mainframe existe conceito semelhante.

O I/O Scheduling organiza a sequência das operações para reduzir deslocamentos desnecessários e aumentar a eficiência.

Enquanto muitos sistemas realizam esse trabalho utilizando ciclos da CPU, no IBM Z boa parte dele é executada pelos componentes especializados do subsistema de I/O.

FICON — As Rodovias de Luz

Agora vamos observar as estradas.

Em vez de simples cabos...

o IBM Z utiliza conexões ópticas de altíssimo desempenho.

Entre elas destaca-se:

FICON

(Fibre Connection).

Posteriormente surgiu o:

zHPF

(High Performance FICON).

Imagine substituir antigas rodovias por túneis hiperluminais.

Mais velocidade.

Menor latência.

Maior eficiência.

O NUMA Cache Compartilhado

Chegamos a uma das partes mais sofisticadas do relatório.

Imagine quatro enormes cidades espaciais.

Cada uma possui sua biblioteca.

Normalmente...

cada cidade consulta apenas seus próprios livros.

No IBM Z ocorre algo extraordinário.

As bibliotecas conseguem cooperar.

Os caches L2 são organizados de forma a oferecer uma visão compartilhada entre diferentes "books", reduzindo custos de acesso e aumentando a eficiência em sistemas de grande porte.

DMA Diretamente no Cache

Aqui encontramos outra inovação impressionante.

Na maioria dos computadores...

os dispositivos conversam diretamente com a memória principal.

No System z...

certas operações de I/O conseguem atingir diretamente o cache L2.

Imagine um cargueiro entregando suprimentos diretamente na cozinha da nave...

sem precisar passar primeiro pelo almoxarifado.

Resultado?

Muito menos deslocamento.

Muito menos espera.

Mais desempenho.

Spruth destaca essa característica como uma implementação singular da arquitetura System z.

Quantos Discos Cabem Numa Galáxia?

O relatório apresenta números impressionantes.

Um único Channel Subsystem pode administrar dezenas de milhares de subcanais.

Diversos subsistemas podem coexistir.

Isso permite conectar quantidades gigantescas de dispositivos de armazenamento e periféricos.

É uma escala difícil até de imaginar quando pensamos em servidores convencionais.

Por Que Tudo Isso Existe?

Porque bancos não possuem apenas:

um arquivo.

Eles possuem:

milhões.

Uma companhia aérea não processa:

cem reservas.

Processa milhões.

Uma seguradora não grava:

dez registros.

Grava bilhões.

O problema nunca foi ler um arquivo.

O problema sempre foi ler milhões deles simultaneamente.

O Que Mudou Desde 2010?

Desde a publicação do relatório, o subsistema de I/O continuou evoluindo.

Hoje encontramos:

FICON ainda mais rápido;
discos Flash de altíssimo desempenho;
DS8000 muito mais inteligentes;
integração com NVMe;
compressão por hardware;
criptografia transparente;
Storage Class Memory;
melhorias em zHyperLink;
novos mecanismos de paralelismo.

Mas a filosofia permanece rigorosamente igual.

A CPU continua fazendo apenas aquilo que ela faz melhor.

A Grande Lição dos Engenheiros

Existe um princípio elegante escondido neste capítulo.

Não sobrecarregue quem deveria estar pensando.

Delegue.

Especialize.

Distribua responsabilidades.

Curiosamente...

essa não é apenas uma lição para computadores.

Também vale para equipes.

Projetos.

Empresas.

E até para nossas próprias rotinas.

Curiosidades do Diário de Bordo

🚀 Muitos conceitos modernos de aceleração por hardware seguem a mesma filosofia utilizada pelo IBM Z há décadas: mover tarefas especializadas para componentes dedicados.

💾 O subsistema de I/O do Mainframe é frequentemente considerado um dos maiores diferenciais da plataforma, justamente porque permite que a CPU permaneça focada no processamento das aplicações.

🌌 O Channel Subsystem trabalha de forma tão integrada ao hardware que a maior parte dos programas jamais percebe sua complexidade.

📡 Em um IBM Z, a logística de movimentação de dados lembra muito mais a operação de um gigantesco porto espacial automatizado do que a de um computador pessoal.

Diário de Bordo do Padawan COBOL

Antes de deixar o centro logístico da nave, registre estas coordenadas:

✅ A CPU do IBM Z foi projetada para processar negócios, não para administrar filas de dispositivos.

✅ Control Units, Channel Subsystem e SAPs formam uma equipe especializada que descarrega grande parte do trabalho de Entrada e Saída.

✅ Múltiplos caminhos de comunicação aumentam simultaneamente desempenho e disponibilidade.

✅ O segredo da eficiência do IBM Z não está apenas em processadores poderosos, mas em uma arquitetura onde cada componente faz exatamente aquilo para o qual foi criado.

No próximo capítulo atravessaremos as portas do Supervisor do z/OS, o verdadeiro centro nervoso da nave. Descobriremos como Kernel, Address Spaces, Dispatcher e Scheduler coordenam milhões de atividades simultâneas com a serenidade de um comandante experiente, mantendo a ordem em uma galáxia onde o caos tenta aparecer a cada microssegundo.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.