✨ 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
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)
7
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
8
🔗 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
7
👉 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
7
👉 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.” 😎
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.
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
