✨ 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 comenta sobre o hipersocket o teletransporte do Ibm Mainframe
🖖 “Scotty, Teletransporte Já!” — O Dia em que o Mainframe Aprendeu a Viajar Mais Rápido que a Luz (e Deixou o Sr. Spock Intrigado)
Padawan… aproxime-se do console 3270. Hoje você não vai aprender apenas uma tecnologia. Vai descobrir um dos truques mais elegantes, silenciosos e quase “alienígenas” do IBM Z.
Uma tecnologia tão absurda que, se existisse na USS Enterprise, o Dr. Spock levantaria uma sobrancelha e diria:
“Fascinante.”
Estamos falando do lendário — e subestimado — HiperSockets.
🚀 O que é HiperSockets (sem enrolação acadêmica)
HiperSockets é uma rede TCP/IP completamente interna ao mainframe, baseada em memória.
Sem:
❌ cabos
❌ placas de rede externas
❌ switches
❌ roteadores
❌ latência física
👉 É comunicação entre sistemas… sem sair da máquina.
Se várias LPARs são universos paralelos dentro do IBM Z, o HiperSockets é o portal dimensional entre eles.
🖖 Analogia Star Trek — Teletransporte do Enterprise
Quando a tripulação se transporta:
USS Enterprise → superfície do planeta
Eles não pegam nave auxiliar. Não atravessam o espaço. Não passam pelo “trânsito orbital”.
👉 Eles simplesmente desaparecem aqui… e reaparecem lá.
HiperSockets faz exatamente isso com pacotes TCP/IP.
Fluxo de pacotes via tcpip normal
Sem:
CPU → NIC → cabo → switch → roteador → firewall → outro servidor
Fluxo de pacotes tcpip via hipersocket mainframe
Mas sim:
CPU → memória → outra LPAR → pronto
Se o Spock fosse arquiteto de sistemas, ele diria:
“Altamente lógico. A rede externa é… desnecessária.”
🧠 Como funciona (o segredo técnico)
O coração da tecnologia é um hardware especial:
➡️ IQD — Internal Queued Direct Communication
Ele permite que diferentes LPARs troquem dados através de filas na memória compartilhada, sob controle do PR/SM (hipervisor do Z).
Para o sistema operacional:
👉 Parece uma interface de rede normal 👉 Usa TCP/IP padrão 👉 Funciona com aplicações sem modificação
Mas fisicamente…
Nada saiu da máquina.
📜 Origem e História — Quando a IBM “trapaceou” na rede
HiperSockets apareceu no final dos anos 1990 / início dos 2000, junto com a evolução dos mainframes para ambientes massivamente virtualizados.
Problema da época:
💣 Muitas LPARs 💣 Muito tráfego interno 💣 Gargalo nas redes físicas 💣 Latência desnecessária
A IBM fez algo tipicamente “mainframe”:
“E se a gente simplesmente não usar a rede?”
Resultado: uma LAN interna de velocidade absurda.
🔥 Aplicações práticas (mundo real)
Padawan, isto aqui move bancos, bolsas e governos.
Usos clássicos:
✔ z/OS ↔ Linux on Z ✔ Application server ↔ DB2 ✔ CICS ↔ Middleware ✔ Batch ↔ serviços online ✔ Comunicação entre LPARs de produção ✔ Gateways internos de APIs ✔ Ambientes Parallel Sysplex
Em sistemas financeiros de altíssimo volume, HiperSockets é praticamente obrigatório.
⚡ Por que é tão rápido?
Porque elimina o inimigo número 1 da computação distribuída:
👉 A rede física
Sem interrupções externas:
Sem congestionamento
Sem jitter
Sem perda de pacote
Sem latência de hardware externo
Sem overhead de drivers físicos
É comunicação memória → memória.
🔒 Segurança digna da Seção 31
O tráfego:
🛡️ Nunca sai da máquina 🛡️ Não pode ser sniffado externamente 🛡️ Não depende de infraestrutura de rede 🛡️ Reduz superfície de ataque
Em ambientes críticos, isso é ouro puro.
🥚 Easter Egg Mainframe — O detalhe que poucos contam
HiperSockets usa endereçamento IP normal.
Sim.
Você pode fazer um:
PING 10.x.x.x
…e estar falando com outro sistema que literalmente está:
👉 No mesmo gabinete 👉 Na mesma CPU 👉 A poucos nanossegundos de distância
É como enviar uma carta para a sala ao lado… usando o protocolo postal internacional.
🤯 Curiosidade que faz arquitetos sorrirem
Em data centers distribuídos, gasta-se milhões para reduzir latência de rede.
No IBM Z, muitas vezes a solução é:
“Coloque tudo dentro da mesma máquina.”
🧙♂️ Versão Bellacosa para guardar na alma
Se servidores distribuídos são naves viajando pelo espaço… o IBM Z é um universo inteiro dentro de uma única estrela.
RMF Monitor III
SMF72
CF Activity
WLM Delay
SRB Time
E descobrir.
Em cinco minutos.
Por que um sistema bancário inteiro ficou lento.
Eles recebem muitos telefonemas.
Muito café.
Pouco reconhecimento.
São conhecidos.
Como:
Os Engenheiros IBM Z
Filosofia Jedi da Parte 9
O Padawan iniciante acredita:
Meu programa executa sozinho.
O desenvolvedor experiente pensa:
Meu programa depende do sistema.
O Mestre Mainframe entende:
Nenhum CALL existe isoladamente.
Ele depende de:
JES2
LE
WLM
SRM
RMF
SMF
XCF
Sysplex
Coupling Facility
Crypto Express
Telum AI
zIIP
HiperSockets
E o Arquiteto Supremo IBM Z sabe que, quando um desenvolvedor digita:
CALL 'SUBPGM'
ele está acionando silenciosamente décadas de engenharia IBM, dezenas de subsistemas, hardware especializado e mecanismos refinados durante mais de meio século, permitindo que bilhões de transações sejam executadas todos os dias com disponibilidade que continua sendo referência para toda a indústria.
Próxima aventura do Padawan COBOL – Parte 10
"As Últimas Runas do IBM Z: Telum II, Spyre AI Accelerator, Quantum Safe Cryptography, z/OS Connect Enterprise Edition, OpenTelemetry, Ansible, Zowe, DevOps e a Nova Ordem dos Arquitetos IBM Z."
Bellacosa Mainframe apresenta ibm mainframe parte ix
☕ Um Café no Bellacosa Mainframe
Capítulo IX — A Federação das Naves Invisíveis
PR/SM, LPARs e Virtualização: Como Um Único Computador se Transformou em uma Galáxia Inteira
SEXTA REGRA DAS GRANDES CIVILIZAÇÕES
Nunca compre uma nave espacial apenas porque ela é enorme.
Pergunte primeiro:
Quantas civilizações diferentes conseguem viver dentro dela sem começar uma guerra?
Parece uma pergunta estranha.
Mas foi exatamente essa pergunta que a IBM respondeu décadas atrás.
Imagine uma nave gigantesca.
Dentro dela vivem:
uma federação de banqueiros;
um grupo de cientistas;
uma academia militar;
uma universidade;
um hospital;
uma estação meteorológica;
uma fábrica de robôs.
Todos utilizam o mesmo casco.
A mesma energia.
Os mesmos motores.
Mas nenhum deles sabe que os outros existem.
Parece magia.
Não é.
É virtualização.
O Grande Apartamento Cósmico
Imagine um prédio com cem apartamentos.
Todos compartilham:
fundação;
elevadores;
telhado;
energia elétrica;
encanamento.
Mas cada morador acredita possuir sua própria casa.
O IBM Z faz exatamente isso.
Só que em escala planetária.
Antes da Virtualização
Voltemos algumas décadas.
Você precisava de um servidor para:
Banco.
Outro para RH.
Outro para folha.
Outro para testes.
Outro para desenvolvimento.
Outro para homologação.
Resultado?
Salas inteiras cheias de computadores.
Baixa utilização.
Muito calor.
Muito desperdício.
Então Surgiu Uma Ideia Revolucionária
Um engenheiro olhou para aquele enorme computador e perguntou:
"Por que não dividir essa nave em várias menores?"
Hoje isso parece óbvio.
Na década de 1970 era praticamente ficção científica.
A Grande Mágica
Imagine um teatro.
Existe apenas um palco.
Mas cinco peças diferentes acontecem simultaneamente.
Cada plateia acredita que ocupa o teatro inteiro.
Como isso seria possível?
No IBM Z isso acontece todos os dias.
Cada ambiente acredita possuir:
sua própria CPU.
sua própria memória.
seus próprios discos.
seu próprio sistema operacional.
Na realidade...
todos compartilham o mesmo hardware.
Conheça o PR/SM
Nos bastidores existe um personagem extremamente discreto.
Seu nome é:
PR/SM
Processor Resource/System Manager.
Pense nele como o administrador da estação espacial.
Ele decide:
quem recebe CPU.
quem recebe memória.
quem recebe canais de I/O.
quem pode utilizar determinado recurso.
Segundo Wilhelm G. Spruth, o PR/SM é responsável por particionar logicamente um único sistema físico em ambientes completamente independentes, oferecendo isolamento em nível de hardware.
As LPARs — Pequenos Universos
Agora chegamos às estrelas principais deste capítulo.
As famosas:
LPARs
(Logical Partitions).
Imagine uma gigantesca nave.
Agora coloque dentro dela:
USS Alpha.
USS Beta.
USS Gamma.
USS Delta.
Cada nave possui:
tripulação.
missões.
comandante.
computadores.
sistemas.
Elas dividem o mesmo casco.
Mas vivem vidas completamente independentes.
Cada LPAR acredita ser um computador completo.
E, do ponto de vista do sistema operacional...
ela realmente é.
Um Hotel de Luxo
Imagine um hotel.
Cada hóspede possui:
quarto.
banheiro.
telefone.
televisão.
Wi-Fi.
Ar-condicionado.
Nenhum hóspede invade o quarto do outro.
As LPARs seguem exatamente esse princípio.
Cada uma recebe recursos exclusivos.
Segurança.
Isolamento.
Previsibilidade.
O Vizinho Barulhento Não Existe
Você já morou perto de alguém que fazia festa às três da manhã?
No IBM Z isso seria inaceitável.
Uma LPAR não pode consumir recursos pertencentes à outra.
O PR/SM garante essa separação.
Mesmo que uma aplicação apresente problemas...
as demais continuam funcionando normalmente.
Compartilhar Não Significa Misturar
Essa é uma lição importante.
Compartilhar hardware não significa compartilhar tudo.
Imagine um prédio.
Os apartamentos compartilham:
estrutura.
água.
energia.
Mas ninguém compartilha:
escova de dentes.
geladeira.
conta bancária.
O isolamento permanece absoluto.
CPU Compartilhada ou Dedicada?
Agora imagine uma frota espacial.
Algumas naves possuem pilotos exclusivos.
Outras utilizam pilotos compartilhados.
No IBM Z acontece exatamente isso.
Uma LPAR pode receber:
CPUs dedicadas
ou
CPUs compartilhadas.
O administrador escolhe conforme a necessidade.
O Maestro Continua Trabalhando
Lembra do Supervisor?
Agora ele ganhou um chefe.
O PR/SM coordena as LPARs.
Dentro de cada LPAR...
o Supervisor organiza seus próprios programas.
É uma hierarquia elegante.
Como uma federação.
Cada planeta governa seus habitantes.
Mas existe um conselho superior distribuindo recursos entre todos.
E Se Uma LPAR Travar?
Imagine um apartamento.
O morador derruba uma estante.
Os outros apartamentos continuam intactos.
O mesmo ocorre aqui.
Uma LPAR pode sofrer problemas.
As demais continuam operando normalmente.
Esse isolamento é um dos pilares da confiabilidade do IBM Z.
O Grande Restaurante Galáctico
Imagine um restaurante gigantesco.
Existem:
clientes VIP.
turistas.
tripulações.
embaixadores.
Todos utilizam a mesma cozinha.
Mas recebem atendimento diferente.
O PR/SM faz algo semelhante.
Distribui recursos conforme prioridades.
Sem desperdício.
Dynamic LPAR
Agora imagine algo curioso.
Enquanto a nave está viajando...
você aumenta o tamanho de um dos apartamentos.
Sem parar a nave.
Sem desligar motores.
Sem evacuar passageiros.
Isso existe.
Chama-se:
Dynamic LPAR.
Processadores, memória e alguns recursos podem ser adicionados ou removidos dinamicamente, reduzindo drasticamente interrupções operacionais.
O Universo Está Vivo
As necessidades mudam.
Às nove da manhã:
Banco precisa de mais CPU.
À meia-noite:
Batch precisa crescer.
Domingo:
Homologação precisa de recursos.
Segunda-feira:
Desenvolvimento aumenta.
Tudo isso pode acontecer dinamicamente.
WLM Entra em Cena
Agora surge outro personagem.
O famoso:
Workload Manager.
Imagine um gerente de aeroporto.
Ele percebe:
"A pista internacional está lotada."
Então redistribui equipes.
Abre novos portões.
Prioriza determinados voos.
O WLM faz exatamente isso com cargas de trabalho.
Ele conversa continuamente com o PR/SM para ajustar a distribuição dos recursos conforme os objetivos definidos pela instalação.
A Grande Ilusão
Curiosamente...
o sistema operacional nunca percebe toda essa complexidade.
O z/OS acredita possuir um computador inteiro.
Linux acredita possuir outro.
z/VM acredita possuir outro.
Todos vivem felizes.
Enquanto o PR/SM coordena silenciosamente tudo nos bastidores.
A Virtualização Não Nasceu Ontem
Existe um mito curioso.
Muita gente acredita que virtualização começou com VMware.
Ou Hyper-V.
Ou KVM.
Na realidade...
o universo Mainframe experimentava esses conceitos décadas antes.
Spruth destaca a virtualização por hardware como uma das características distintivas do System z, muito antes de ela se tornar comum em servidores distribuídos.
Isso não diminui a importância das plataformas modernas.
Mas mostra como muitas ideias consideradas "novas" possuem raízes muito mais antigas.
Hipersockets — O Teletransporte
Imagine duas naves estacionadas lado a lado.
Tradicionalmente...
elas conversariam usando rádio.
No IBM Z surgiu outra ideia.
Por que usar cabos...
...se ambas vivem dentro da mesma nave?
Assim nasceram os:
Hipersockets.
Eles permitem comunicação extremamente rápida entre LPARs, utilizando memória em vez de redes físicas.
É quase um teletransporte de mensagens.
Spruth apresenta os Hipersockets como um mecanismo de comunicação interna de altíssimo desempenho entre partições lógicas.
Uma Cidade Dentro de Outra Cidade
Imagine uma metrópole.
Dentro dela existe outra cidade.
Dentro dessa cidade...
outra.
Parece impossível.
Mas no IBM Z isso também acontece.
Uma LPAR pode executar:
z/VM.
Dentro do z/VM surgem:
centenas.
milhares.
de máquinas virtuais Linux.
Uma verdadeira galáxia de computadores vivendo dentro de outro computador.
O Que Mudou Desde 2010?
Desde que Spruth escreveu seu relatório, a virtualização evoluiu ainda mais.
Hoje encontramos:
dezenas de TB de memória por sistema;
milhares de máquinas Linux simultâneas;
OpenShift nativo;
Kubernetes;
containers;
Secure Execution;
integração híbrida com nuvem;
LinuxONE;
IA embarcada.
Mas o conceito permanece idêntico.
Um único computador.
Múltos mundos.
Perfeitamente isolados.
Uma Lição Para a Vida
Existe uma filosofia escondida neste capítulo.
Uma grande cidade não precisa eliminar diferenças.
Ela precisa organizá-las.
Cada LPAR possui sua missão.
Seu ritmo.
Sua prioridade.
Seu sistema operacional.
Sua cultura.
Mesmo assim...
todas cooperam utilizando a mesma infraestrutura.
Talvez essa seja uma das metáforas mais bonitas da engenharia.
Curiosidades do Diário de Bordo
🚀 O PR/SM é certificado em altos níveis de segurança e isolamento, permitindo que ambientes com diferentes requisitos coexistam no mesmo hardware físico.
🛰️ Hipersockets eliminam boa parte da latência de comunicação entre LPARs ao manter o tráfego inteiramente dentro do sistema.
🖥️ Um único IBM Z pode hospedar simultaneamente z/OS, Linux, z/VM e outros ambientes, cada um acreditando possuir sua própria máquina.
🌌 A virtualização em hardware do IBM Z antecedeu em muitos anos a popularização da virtualização em servidores x86.
Diário de Bordo do Padawan COBOL
Antes de deixar a Federação das LPARs, registre estas coordenadas no seu Holocron Técnico:
✅ Virtualização não significa apenas dividir recursos; significa criar ambientes independentes, seguros e previsíveis.
✅ O PR/SM atua como o grande administrador da nave, distribuindo CPU, memória e I/O entre diferentes partições.
✅ As LPARs permitem consolidar múltiplos sistemas em um único hardware sem sacrificar isolamento ou desempenho.
✅ Muitas tecnologias modernas de consolidação e computação em nuvem seguem princípios que o IBM Z já aplicava décadas antes.
Missão Seguinte
No próximo capítulo faremos um salto para uma das tecnologias mais impressionantes do universo IBM Z: o Parallel Sysplex e a Coupling Facility.
Descobriremos como várias naves conseguem pensar como uma só, compartilhar dados em tempo real e continuar operando mesmo quando uma delas sai de combate. Se as LPARs transformaram um computador em vários mundos, o Parallel Sysplex transformará vários computadores em uma única civilização galáctica.
☕ 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.
Hardware Mainframe IBM Z: Conheça Todos os Componentes
Quando falamos em um Mainframe IBM Z, muitas pessoas imaginam apenas um "computador gigante". Na realidade, ele é um conjunto extremamente sofisticado de componentes projetados para entregar:
Nos modelos atuais existem dezenas ou centenas de núcleos.
Exemplo:
CP1
CP2
CP3
CP4
...
Cada núcleo executa milhares de threads.
Processadores Auxiliares
Um dos diferenciais do Mainframe.
Eles descarregam trabalho dos CPs.
zIIP
z Integrated Information Processor
Muito utilizado atualmente.
Executa:
DB2
Java
XML
JSON
Analytics
APIs
Exemplo:
DB2 Query
↓
zIIP
Economiza licenciamento.
zAAP
z Application Assist Processor
Criado para Java.
Hoje muitas funções foram absorvidas pelo zIIP.
IFL
Integrated Facility for Linux
Processador dedicado para Linux.
Executa:
Ubuntu
RHEL
SUSE
Debian
sobre:
LinuxONE
z/VM
KVM
SAP
System Assist Processor
Executa tarefas internas.
Exemplos:
Gerenciamento
Sincronização
Monitoramento
Crypto Express
Processadores criptográficos dedicados.
Executam:
AES
RSA
ECC
TLS
Certificados
Sem impactar CPUs principais.
Memória RAM
Mainframes modernos possuem:
Terabytes
de memória
Características:
✅ ECC
✅ Correção automática
✅ Redundância
✅ Hot Swap
Cache
Existem múltiplos níveis.
L1
L2
L3
L4
Objetivo:
Reduzir acesso à memória principal.
Storage
Armazenamento corporativo.
DASD
Direct Access Storage Device
Equivalente aos discos.
Hoje geralmente:
Flash
SSD
NVMe
IBM DS8000
Storage mais comum em Mainframe.
Capaz de armazenar:
Petabytes
de informação.
Estrutura
Mainframe
↓
FICON
↓
DS8000
FICON
Fiber Connection
Protocolo principal de comunicação Storage/Mainframe.
Substituiu o ESCON.
Velocidades:
16 Gbps
32 Gbps
64 Gbps
Canais de I/O
Grande diferencial do Mainframe.
Enquanto servidores comuns usam CPU para I/O:
CPU
↓
Disco
No Mainframe:
CPU
↓
Canal
↓
Controladora
↓
Storage
Resultado:
Menos carga nas CPUs.
CHPID
Channel Path Identifier
Identifica caminhos de I/O.
OSA
Open Systems Adapter
Placa de rede Mainframe.
Conecta:
TCP/IP
Ethernet
Cloud
Internet
HiperSockets
Rede virtual interna.
Comunicação:
LPAR
↔
LPAR
Sem sair do equipamento.
Velocidade extremamente alta.
Comunicação de Rede
Protocolos suportados:
TCP/IP
IPv4
IPv6
TLS
HTTPS
FTP
MQ
Kafka
Controladores de Rede
Possuem:
10 Gb
25 Gb
40 Gb
100 Gb
e superiores.
LPARs
Logical Partitions
Virtualização nativa.
Exemplo:
IBM Z
│
├── LPAR1 z/OS
├── LPAR2 Linux
├── LPAR3 Teste
└── LPAR4 Produção
PR/SM
Processor Resource/System Manager
Hypervisor embarcado.
Responsável pelas LPARs.
z/VM
Camada adicional de virtualização.
Pode executar:
Milhares de VMs Linux
LinuxONE
Utiliza processadores IFL.
Executa:
OpenShift
Docker
Kubernetes
IA
Energia
Mainframes possuem múltiplas fontes.
Fonte A
Fonte B
Fonte C
Características:
✅ Redundância
✅ Hot Swap
✅ Failover automático
UPS
Normalmente conectado a sistemas de energia ininterrupta.
Refrigeração
Mainframes modernos utilizam:
Ar Forçado
Modelos menores.
Refrigeração Líquida
Modelos maiores.
Fluxo:
Processador
↓
Cold Plate
↓
Água Refrigerada
↓
Trocador de Calor
Sensores
Centenas de sensores monitoram:
Temperatura
Energia
Vibração
Umidade
Cabos
Existem vários tipos.
FICON
Storage.
Ethernet
Rede.
Fibre Channel
SAN.
HiperSockets
Interno.
Cabos de Energia
Redundantes.
Criptografia Integrada
Os processadores IBM Telum possuem:
Criptografia embarcada
Executam:
TLS
VPN
Open Banking
PIX
IBM Telum
Processador atual da família IBM Z.
Características:
✅ IA embarcada
✅ Criptografia
✅ Cache gigante
✅ Alta frequência
Exemplo Completo
App Mobile
↓
Internet
↓
OSA
↓
z/OS Connect
↓
CP / zIIP
↓
CICS
↓
DB2
↓
FICON
↓
DS8000
Componentes Resumidos
Componente
Função
CP
CPU principal
zIIP
Processamento auxiliar
IFL
Linux
SAP
Serviços internos
Crypto Express
Criptografia
RAM
Memória
Cache
Aceleração
DASD
Armazenamento
DS8000
Storage corporativo
FICON
Comunicação Storage
OSA
Rede
HiperSockets
Rede interna
LPAR
Virtualização
PR/SM
Hypervisor
z/VM
Virtualização Linux
Telum
Processador IBM Z
Curiosidade
Um único IBM Z moderno pode:
Executar milhares de máquinas virtuais
Processar milhões de transações por segundo
Possuir dezenas de TB de memória
Armazenar petabytes de dados
Operar continuamente por anos sem parada planejada
Por isso, bancos, bolsas de valores, governos e seguradoras continuam utilizando Mainframes como plataforma principal para suas aplicações mais críticas.
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
