Translate

Mostrar mensagens com a etiqueta lpar. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta lpar. Mostrar todas as mensagens

sexta-feira, 13 de março de 2026

🖖 “Scotty, Teletransporte Já!” — O Dia em que o Mainframe Aprendeu a Viajar Mais Rápido que a Luz (e Deixou o Dr. Spock Intrigado)

 

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.

E o HiperSockets é o teletransporte.


🖖 Epílogo — Spock aprovaria?

Sem dúvida.

Porque é:

✔ Elegante
✔ Eficiente
✔ Discreto
✔ Extremamente lógico
✔ Assustadoramente poderoso

Exatamente como a engenharia Vulcana.


 



sexta-feira, 27 de setembro de 2024

Hypervisor no Mainframe sem Mistérios

 

Bellacosa Mainframe e o hypervisor no mainframe sem misterios

☕ Um Café no Bellacosa Mainframe

Hypervisor no Mainframe sem Mistérios

Como um IBM Z Executa Centenas de Servidores ao Mesmo Tempo — O Guia Definitivo para o Programador COBOL Padawan Inspirado em Star Trek

"A lógica é o começo da sabedoria, não o fim."

— Sr. Spock


Introdução — A Grande Ilusão da Computação

Imagine entrar na ponte da USS Enterprise.

O Capitão Kirk acredita que possui uma nave inteira à sua disposição.

O engenheiro Scotty controla motores, energia e sistemas.

O Dr. McCoy utiliza computadores médicos.

Spock executa simulações científicas.

Cada um acredita possuir recursos exclusivos.

Mas existe apenas uma única nave.

O segredo é que existe um sistema extremamente inteligente distribuindo recursos para todos ao mesmo tempo.

No IBM Z acontece exatamente isso.

Para um programador COBOL iniciante, isso pode parecer magia.

Na realidade, trata-se de uma das maiores invenções da história da computação:

o Hypervisor.

E a parte curiosa?

O mainframe fazia isso quando o restante do mundo ainda estava tentando descobrir como compartilhar um computador entre vários usuários.


Antes de tudo...

Muita gente pensa que virtualização nasceu com VMware.

Spoiler...

Não nasceu.

A IBM já fazia virtualização completa décadas antes da Internet existir.

Quando o primeiro PC da IBM apareceu em 1981, os mainframes já executavam dezenas de sistemas operacionais simultaneamente.

Isso muda completamente a perspectiva histórica.


O que é um Hypervisor?

A definição técnica é simples.

Um Hypervisor é um software (ou firmware especializado) responsável por criar computadores virtuais.

Cada computador virtual recebe:

  • memória

  • CPUs

  • discos

  • placas de rede

  • dispositivos

  • acesso ao hardware

Tudo isso sem possuir fisicamente esses equipamentos.

Para o sistema operacional convidado (Guest OS), parece existir um computador inteiro.

Na verdade...

Ele está dividindo recursos com centenas de outros sistemas.


Uma analogia Bellacosa

Imagine um enorme prédio comercial.

Existe:

  • uma única estrutura

  • um único elevador

  • uma única instalação elétrica

  • um único sistema hidráulico

Mas existem centenas de empresas trabalhando ali.

Cada empresa acredita possuir seu próprio escritório.

Quem administra tudo?

O síndico.

No mundo da computação...

O síndico chama-se Hypervisor.


O problema que ele resolve

Nos anos 60 um computador custava milhões de dólares.

Não fazia sentido deixá-lo executando apenas um sistema.

Era desperdício.

A IBM percebeu isso rapidamente.

A ideia era simples:

"Se o computador é poderoso, por que não criar vários computadores dentro dele?"

Nascia a virtualização.


A origem histórica

Voltamos para 1964.

IBM System/360.

Era revolucionário.

Mas ainda executava apenas um sistema operacional por vez.

Logo depois veio o projeto:

CP-40

Depois:

CP-67

Esses projetos deram origem ao:

VM/370

E praticamente toda a indústria copiou essa ideia décadas depois.

Curiosamente...

A palavra "Virtual Machine" já era usada pela IBM muito antes do VMware existir.


Linha do tempo

1964

System/360

1967

CP-40

1968

CP-67

1972

VM/370

1988

PR/SM

1990

LPAR

2000+

z/VM

Hoje

IBM z16

IBM z17

Linux

z/OS

z/VM

KVM

Todos convivendo na mesma máquina.


O nascimento das Máquinas Virtuais

Imagine possuir um computador enorme.

O Hypervisor cria:

Computador A

Computador B

Computador C

Computador D

Todos são imaginários.

Mas funcionam como computadores reais.

Cada um pode instalar:

  • Linux

  • z/OS

  • z/VM

  • z/VSE

  • z/TPF

Sem interferir uns nos outros.


Como isso funciona?

O Hypervisor controla quatro grandes recursos.

CPU

Quando um sistema precisa processar algo...

Ele pede CPU.

O Hypervisor responde:

"Espere sua vez."

Em microssegundos ele alterna entre centenas de sistemas.

Para cada sistema parece possuir uma CPU exclusiva.


Memória

O mesmo acontece com RAM.

Cada máquina virtual acredita possuir memória exclusiva.

Na realidade...

Toda memória é compartilhada cuidadosamente.


Disco

Cada sistema possui seus próprios discos.

Mas muitas vezes esses discos são apenas áreas reservadas dentro de grandes volumes físicos.


Rede

Cada servidor virtual possui placas de rede.

Elas também podem ser totalmente virtuais.

O Hypervisor conecta tudo internamente.

Sem sequer sair do equipamento.


Parece mágica?

Não.

É matemática.

E engenharia.

Muita engenharia.


Hypervisor Tipo 1

Existem dois tipos.

O mais poderoso é:

Bare Metal.

Ou:

Tipo 1.

Ele roda diretamente sobre o hardware.

Sem Windows.

Sem Linux.

Sem intermediários.

É exatamente o caso do IBM Z.


Hypervisor Tipo 2

Neste caso existe um sistema operacional.

Windows

VMware Workstation

Máquinas Virtuais

O desempenho é menor.


No IBM Z é diferente

Hardware

Firmware

PR/SM

LPARs

z/VM

Linux

Aplicações

Existe uma enorme hierarquia.

Cada camada aumenta a flexibilidade.


PR/SM

Aqui mora um dos segredos do mainframe.

PR/SM significa:

Processor Resource/System Manager.

Ele é considerado um Hypervisor de nível extremamente baixo.

Na prática...

Ele divide o computador físico em diversas LPARs.


O que é uma LPAR?

Significa:

Logical Partition.

É praticamente um computador inteiro.

Pode possuir:

12 CPUs

64 GB RAM

20 discos

10 interfaces de rede

Enquanto outra LPAR possui recursos completamente diferentes.


Imagine uma pizza

Uma pizza inteira representa o IBM Z.

Você corta em:

4 fatias.

Cada fatia torna-se uma LPAR.

Cada LPAR acredita possuir sua própria pizza.

Mesmo pertencendo à mesma pizza original.


E depois entra o z/VM

Agora vem a parte divertida.

Dentro de uma LPAR...

Pode existir outro Hypervisor.

Esse Hypervisor chama-se:

z/VM.

Agora temos:

IBM Z

LPAR

z/VM

500 máquinas Linux

Containers

Aplicações

Sim.

Virtualização dentro da virtualização.

É como um espelho refletindo outro espelho.


Star Trek explica isso muito bem

Lembra do Holodeck?

O Holodeck cria ambientes completos.

Cada personagem acredita estar vivendo num mundo real.

Mas tudo acontece dentro da Enterprise.

O Hypervisor faz exatamente isso.

Cada sistema operacional acredita possuir um computador físico.

Na realidade...

Está dentro do "Holodeck" do IBM Z.


Por que isso é tão importante?

Porque aumenta:

  • utilização

  • segurança

  • disponibilidade

  • economia

  • flexibilidade


Segurança

Cada máquina virtual fica isolada.

Se uma apresentar problema...

As demais continuam funcionando.

É como compartimentos estanques de uma nave estelar.

Uma explosão na Engenharia não destrói a ponte.


Alta disponibilidade

Imagine atualizar um Linux.

Os outros continuam funcionando.

Atualizar uma aplicação.

As demais continuam.

Trocar memória.

Trocar CPU.

Adicionar discos.

Tudo quase sem impacto.


Eficiência absurda

Um servidor x86 costuma operar entre:

15%

30%

de utilização.

Um IBM Z frequentemente trabalha entre:

80%

95%

de utilização.

Sem perda significativa de desempenho.

Esse é um dos grandes diferenciais do mainframe.


Compartilhamento Inteligente

O Hypervisor conhece prioridades.

Um banco pode receber mais CPU.

Uma aplicação de testes recebe menos.

Tudo automático.


Dynamic Resource Allocation

Outro recurso fantástico.

É possível aumentar CPUs.

Adicionar memória.

Modificar prioridades.

Tudo enquanto o sistema continua funcionando.

Sem reboot.

Isso impressiona até hoje.


Como isso afeta um programador COBOL?

Muito mais do que parece.

Seu programa roda dentro de:

COBOL

LE Runtime

z/OS

LPAR

PR/SM

Hardware

Você raramente percebe.

Mas o Hypervisor trabalha silenciosamente por trás.


Quando um COBOL executa

Imagine um programa de folha de pagamento.

Ele solicita CPU.

O z/OS solicita recursos.

O PR/SM entrega processadores.

Tudo acontece em microssegundos.

Você nunca percebe.

Mas existe um verdadeiro maestro coordenando toda essa orquestra.


O que acontece se houver excesso de carga?

O Hypervisor redistribui recursos.

Algumas LPARs recebem mais CPU.

Outras esperam alguns microssegundos.

Tudo automaticamente.


Curiosidade impressionante

Um único IBM Z pode executar milhares de máquinas virtuais Linux.

Tudo dentro do mesmo equipamento.

Consumindo menos energia que centenas de servidores distribuídos.

É por isso que grandes bancos continuam investindo em mainframe.


Easter Egg nº 1

A expressão Virtual Machine ficou famosa nos PCs.

Mas ela nasceu dentro da IBM.

Décadas antes.


Easter Egg nº 2

O VMware foi fundado apenas em 1998.

O VM/370 existia desde 1972.

Mais de 25 anos antes.


Easter Egg nº 3

A maioria dos administradores VMware nunca imaginou que muitos conceitos modernos foram herdados direta ou indiretamente dos laboratórios da IBM.


Easter Egg nº 4

O PR/SM possui certificação de isolamento extremamente rigorosa (EAL5+ em avaliações Common Criteria para determinadas configurações), permitindo que workloads de diferentes níveis de confiança coexistam com forte separação lógica. Isso é um dos motivos pelos quais governos e grandes instituições financeiras confiam na plataforma.


Dicas para o Padawan COBOL

✔ Nunca pense que seu programa "está sozinho".

Sempre existe uma camada abaixo dele.


✔ Aprenda o conceito de LPAR.

Você verá esse termo praticamente todos os dias.


✔ Entenda o z/VM.

Mesmo trabalhando apenas com COBOL.

Ele aparece frequentemente em ambientes Linux on Z.


✔ Estude PR/SM.

Poucos desenvolvedores conhecem.

Mas quem entende virtualização compreende muito melhor o IBM Z.


✔ Não confunda LPAR com Máquina Virtual.

LPAR é uma partição lógica criada diretamente pelo PR/SM. Dentro de uma LPAR, o z/VM pode criar centenas ou milhares de máquinas virtuais.


Comparação rápida

Universo Star TrekIBM Z
USS EnterpriseHardware físico
HolodeckHypervisor
Ponte de ComandoLPAR
Simulações do HolodeckMáquinas Virtuais
ScottyAdministrador do sistema
SpockWLM e gerenciamento inteligente de recursos
Computador da navePR/SM + z/VM

Lições aprendidas

Existe um mito de que virtualização é uma tecnologia moderna.

Na realidade, ela nasceu no mundo dos mainframes.

O IBM Z não apenas executa programas COBOL. Ele hospeda diversos sistemas operacionais, milhares de aplicações e enormes ambientes Linux com isolamento, segurança e desempenho excepcionais. O hypervisor — especialmente o PR/SM, complementado pelo z/VM quando necessário — é o grande responsável por essa façanha.

Quando um programador COBOL envia um JOB pelo JCL, acessa Db2, CICS ou IMS, dificilmente percebe que há uma sofisticada infraestrutura distribuindo CPUs, memória, dispositivos e redes em tempo real. Assim como a tripulação da Enterprise confia que a nave responderá a cada comando, o desenvolvedor confia que o IBM Z entregará recursos quando forem necessários.

E talvez essa seja a maior lição do universo de Star Trek aplicada ao mainframe: a tecnologia mais extraordinária é aquela que trabalha tão bem que quase se torna invisível. O hypervisor é esse "oficial silencioso" da nave. Ele não aparece na tela 3270, não compila programas COBOL e não executa SQL, mas sem ele grande parte da eficiência, da disponibilidade e da confiabilidade que tornaram o IBM Z uma referência mundial simplesmente não existiria.

Como diria o Sr. Spock:

"A eficiência não está em possuir mais recursos, mas em utilizá-los com inteligência."

Essa frase resume perfeitamente a filosofia do hypervisor no IBM Z: transformar um único computador físico em uma verdadeira frota de computadores virtuais, trabalhando em perfeita harmonia há mais de cinco décadas.


sábado, 20 de julho de 2024

Road Map para Aprender Mainframe

O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe. Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço. Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além. #ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex

sexta-feira, 28 de setembro de 2018

IBM Mainframe Discovery : Capítulo IX — A Federação das Naves Invisíveis

 

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.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

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

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo

sexta-feira, 11 de maio de 2007

O que é IML (Initial Microcode Load)?

Bellacosa Mainframe apresenta o que é o initial microcode load



O que é IML (Initial Microcode Load)?

O IML é o procedimento que carrega o Licensed Internal Code (LIC) — o microcódigo/firmware da IBM — para os processadores e componentes do Mainframe.

Sem o IML, o computador é apenas um conjunto de circuitos eletrônicos.

Depois do IML, ele passa a reconhecer:

  • CPUs

  • memória

  • canais de I/O

  • criptografia

  • PR/SM

  • LPARs

  • dispositivos físicos

Somente após isso é possível fazer o IPL do z/OS.


Pense em um computador comum

Quando você liga um PC, acontece algo parecido:

Energia

↓

BIOS/UEFI

↓

Firmware

↓

Boot Loader

↓

Windows/Linux

No Mainframe IBM Z:

Energia

↓

IML

↓

Licensed Internal Code (LIC)

↓

PR/SM

↓

LPAR

↓

IPL

↓

z/OS

O IML equivale aproximadamente ao papel do BIOS/UEFI em um PC, porém muito mais sofisticado.


O que o IML faz?

Durante o IML o sistema:

Inicializa os processadores

Verifica:

  • CP

  • zIIP

  • IFL

  • zAAP (modelos antigos)

  • SAP


Inicializa a memória

Faz testes.

Mapeia a RAM.

Verifica erros ECC.


Inicializa os canais

Reconhece:

  • FICON

  • OSA

  • HiperSockets

  • Crypto Express


Carrega o PR/SM

O Processor Resource/System Manager é um hipervisor implementado em firmware.

Ele permite criar:

LPAR 1

LPAR 2

LPAR 3

LPAR 4

Sem IML não existe PR/SM.

Sem PR/SM não existem LPARs.


Inicializa os adaptadores

São preparados:

  • placas de rede

  • canais FICON

  • criptografia

  • aceleradores


Onde fica o microcódigo?

Ele não está no z/OS.

Ele fica armazenado em memória não volátil do equipamento.

Quando ocorre o IML:

Firmware IBM

↓

Memória interna

↓

Processadores

↓

Hardware operacional

Quem executa o IML?

Normalmente:

  • IBM CE (Customer Engineer)

  • Administradores de Hardware

  • Equipe de infraestrutura

Quase nunca o operador do sistema.

Muito menos o programador COBOL.


HMC

Todo o processo é iniciado pela Hardware Management Console.

Na HMC é possível:

  • escolher a imagem de firmware;

  • iniciar o IML;

  • acompanhar o progresso;

  • visualizar erros;

  • administrar LPARs.


Quando fazemos um IML?

Situações comuns:

Instalação de um novo Mainframe

Sempre.


Upgrade de firmware

Após instalar uma nova versão do Licensed Internal Code.


Troca de CPU

Quando novos processadores são instalados.


Expansão do hardware

Adicionar:

  • memória

  • canais

  • placas


Correção crítica

Após determinadas manutenções.


O que acontece depois?

Depois do IML:

Hardware OK

↓

LPAR pronta

↓

Seleciona dispositivo IPL

↓

IPL do z/OS

↓

Master Scheduler

↓

JES2

↓

Subsystems

↓

CICS

↓

Db2

↓

MQ

Um detalhe interessante

O IML não carrega apenas "firmware".

Ele também ativa recursos exclusivos do IBM Z:

  • PR/SM

  • Dynamic Partition Manager

  • Resource Manager

  • Crypto

  • Capacity on Demand

  • Diagnóstico interno


O programador COBOL percebe isso?

Praticamente nunca.

Quando ele chega ao trabalho:

  • o hardware já fez o IML;

  • o z/OS já fez o IPL;

  • CICS já iniciou;

  • Db2 já está ativo.

Para ele, basta abrir o ISPF.

Mas nos bastidores houve dezenas de etapas antes.


IML x IPL

IMLIPL
FirmwareSistema Operacional
HardwareSoftware
Muito raroMais frequente
Executado via HMCExecutado na LPAR
Inicializa o IBM ZInicializa o z/OS

Curiosidade histórica

Nos primeiros IBM System/360 e System/370, parte do microcódigo era carregada por mídias externas, como fitas ou discos especiais, durante a inicialização. Com a evolução das gerações (System/390 e IBM Z), o firmware passou a ficar armazenado internamente e o processo tornou-se muito mais automatizado, seguro e confiável.


Curiosidade técnica

Uma única máquina IBM Z pode conter dezenas de LPARs executando diferentes sistemas operacionais (como z/OS, z/VM, Linux on Z e z/VSE). Todas essas partições dependem do mesmo microcódigo carregado durante o IML. Em outras palavras, um único IML prepara toda a infraestrutura física sobre a qual diversos sistemas operacionais funcionarão.


Resumindo em uma frase

O IML é a etapa que "dá vida" ao hardware do Mainframe IBM, carregando o microcódigo (Licensed Internal Code), habilitando recursos como PR/SM e LPARs e preparando a máquina para que, em seguida, o IPL possa carregar o z/OS e os demais sistemas operacionais.

O que é IML no Mainframe?

Se você está estudando Mainframe, pode encontrar a sigla IML, principalmente em materiais sobre hardware IBM, processadores e suporte técnico.

Muitos iniciantes confundem IML com IPL, mas são processos diferentes.


Definição simples

IML significa:

Initial Microcode Load

Em português:

Carga Inicial do Microcódigo

É o processo de carregar o microcódigo (firmware) que controla os componentes de hardware do Mainframe IBM.

Em outras palavras:

  • IML inicializa o hardware.

  • IPL inicializa o sistema operacional.


O que é microcódigo?

O microcódigo é um software de baixo nível gravado para controlar o funcionamento interno do processador e de outros componentes do sistema.

Ele fica entre o hardware físico e o sistema operacional.

Aplicações

↓

z/OS

↓

Firmware (Microcódigo)

↓

Hardware IBM Z

Sem esse microcódigo, o hardware não consegue operar corretamente.


Quando o IML é utilizado?

O IML normalmente ocorre:

  • quando um novo Mainframe é ligado;

  • após manutenção de hardware;

  • depois de uma atualização de firmware;

  • na substituição de processadores ou placas;

  • após determinadas falhas de hardware.

É um procedimento muito menos frequente que um IPL.


Diferença entre IML e IPL

IMLIPL
Initial Microcode LoadInitial Program Load
Inicializa o hardwareInicializa o z/OS
Carrega firmwareCarrega o sistema operacional
Executado por engenheiros de hardwareExecutado por operadores e administradores
Ocorre raramentePode ocorrer sempre que o sistema é reiniciado

Ordem de inicialização

Em um Mainframe IBM Z, a sequência simplificada é:

Energia

↓

IML

↓

Hardware operacional

↓

IPL

↓

z/OS iniciado

↓

CICS, Db2, MQ e aplicações

Quem realiza o IML?

Na maioria dos ambientes, o IML é responsabilidade de:

  • engenheiros de hardware IBM;

  • equipes de suporte da IBM;

  • administradores de infraestrutura especializados.

Programadores COBOL normalmente nunca executam um IML.


Relação com a HMC

O procedimento é controlado pela HMC (Hardware Management Console).

Por meio dela é possível:

  • carregar novo microcódigo;

  • verificar o estado do hardware;

  • inicializar componentes;

  • monitorar processadores;

  • administrar LPARs.


Atualizações de microcódigo

A IBM libera periodicamente novas versões do firmware para:

  • corrigir falhas;

  • aumentar estabilidade;

  • melhorar desempenho;

  • adicionar suporte a novos recursos;

  • corrigir vulnerabilidades de segurança.

Após determinadas atualizações, pode ser necessário realizar um IML.


Exemplo prático

Imagine que um banco adquiriu novos processadores para um IBM z17.

Antes que o z/OS possa utilizá-los, é necessário:

Instalação do hardware

↓

Atualização do microcódigo

↓

IML

↓

Hardware reconhece os novos recursos

↓

IPL

↓

z/OS disponível

O IML afeta aplicações?

Indiretamente, sim.

Enquanto o hardware está passando por um IML, o sistema não está disponível para execução das cargas de trabalho. Por isso, o procedimento costuma ser planejado em janelas de manutenção.


Curiosidades

1. O IML existe desde os primeiros Mainframes IBM

Embora a tecnologia tenha evoluído muito, a necessidade de carregar o firmware do equipamento continua presente nas gerações atuais do IBM Z.


2. Firmware moderno é muito mais complexo

O microcódigo atual controla recursos como virtualização, criptografia por hardware, gerenciamento de energia e diagnóstico automático.


3. Nem todo IPL exige um IML

É comum reiniciar apenas o sistema operacional (IPL) sem recarregar o microcódigo do equipamento.


4. Atualizações podem ser feitas com mínima interrupção

Em modelos recentes do IBM Z, diversos componentes permitem manutenção e atualização planejadas para reduzir indisponibilidade, embora algumas alterações ainda exijam um IML.


Erros comuns de iniciantes

"IML e IPL são a mesma coisa"

Não. O IML prepara o hardware, enquanto o IPL carrega o sistema operacional.


"Todo reboot faz um IML"

Não. Em muitos casos, basta realizar um IPL do z/OS.


"O programador COBOL precisa conhecer IML em detalhes"

Normalmente não. É um conceito importante para entender a arquitetura do Mainframe, mas sua execução fica a cargo das equipes de infraestrutura e hardware.


Conclusão

O Initial Microcode Load (IML) é um procedimento fundamental da arquitetura dos Mainframes IBM. Ele prepara o hardware carregando o firmware que controla processadores, memória e demais componentes físicos. Somente após um IML bem-sucedido é possível realizar o IPL (Initial Program Load) e iniciar o z/OS. Embora seja pouco visível para programadores COBOL, compreender a diferença entre IML e IPL ajuda a entender melhor como um IBM Z é inicializado e por que o Mainframe é reconhecido por sua confiabilidade e robustez.

quarta-feira, 18 de abril de 2007

crie seo com 150 bytes crie 12 marcadores para o blogspot limitado a 160 bytes, separado por virgulas e sem hashtag

 

Bellacosa Mainframe o que é IPL

O que é IPL?

Se existe uma sigla que todo profissional de IBM Mainframe aprende logo no início da carreira, essa sigla é:

IPL

Sempre que ouvimos frases como:

  • "Vamos fazer um IPL do sistema."

  • "O IPL está programado para domingo."

  • "Após aplicar a manutenção será necessário IPL."

estamos falando de um dos processos mais importantes do IBM Z.

Sem o IPL, nenhum sistema operacional pode iniciar.


Definição simples

IPL (Initial Program Load) é o processo de inicialização (boot) de um IBM Mainframe.

Durante o IPL, o hardware carrega o sistema operacional (como o z/OS) para a memória principal e prepara todos os componentes necessários para que o computador comece a funcionar.

Em outras palavras:

O IPL é o equivalente ao "boot" de um computador pessoal, porém muito mais sofisticado.


Uma analogia simples

Imagine um grande aeroporto.

Antes do primeiro voo do dia, é necessário:

  • ligar as luzes;

  • energizar os radares;

  • iniciar os computadores;

  • ativar as comunicações;

  • abrir os portões;

  • preparar as equipes.

Somente depois disso o aeroporto começa a operar.

O IPL faz exatamente isso com o IBM Z.


O que significa IPL?

IPL significa:

Initial Program Load

Em português:

Carga Inicial de Programa.

Na prática, representa todo o processo de inicialização do sistema operacional.


Por que o IPL é necessário?

Quando o IBM Z é ligado, a memória principal está vazia.

É preciso carregar:

  • o z/OS;

  • tabelas do sistema;

  • drivers;

  • gerenciadores de memória;

  • JES2 ou JES3;

  • subsistemas.

Tudo isso acontece durante o IPL.


Como funciona?

O processo pode ser representado assim:

Ligar IBM Z

↓

HMC

↓

Selecionar dispositivo IPL

↓

Hardware inicia leitura

↓

Carrega z/OS

↓

Inicializa memória

↓

Inicializa JES

↓

Inicializa subsistemas

↓

Sistema disponível

Quem inicia o IPL?

Normalmente o processo é iniciado pela:

HMC (Hardware Management Console)

O administrador escolhe:

  • qual LPAR será iniciada;

  • qual dispositivo será utilizado;

  • quais parâmetros serão carregados.


O dispositivo IPL

O sistema operacional precisa estar armazenado em algum lugar.

Normalmente o IPL pode ocorrer a partir de:

  • DASD;

  • Volume IPL;

  • dispositivos especiais;

  • mídia de recuperação.

A HMC informa ao hardware onde localizar esse sistema.


O que acontece durante o IPL?

Diversas etapas ocorrem.

Inicialização do Hardware

O IBM Z verifica:

  • CPUs;

  • memória;

  • canais;

  • dispositivos;

  • adaptadores.


Carregamento do z/OS

O sistema operacional é transferido do disco para a memória.


Inicialização da Memória

São criadas:

  • Address Spaces;

  • áreas do núcleo;

  • tabelas internas;

  • estruturas de controle.


Inicialização do JES2

O JES é responsável por:

  • Jobs;

  • spool;

  • filas;

  • impressão.

Sem ele praticamente nenhum processamento batch ocorre.


Inicialização dos Subsistemas

Depois surgem:

  • CICS;

  • Db2;

  • IMS;

  • MQ;

  • TCP/IP;

  • RACF;

  • USS.

Cada um inicia seus próprios Address Spaces.


IPL Normal

É o mais comum.

O sistema é iniciado normalmente.

Hardware

↓

z/OS

↓

Sistema disponível

IPL Frio (Cold IPL)

Algumas estruturas são recriadas do zero.

Pode ocorrer após:

  • manutenção;

  • recuperação;

  • problemas graves.


IPL Quente (Warm IPL)

Grande parte das informações anteriores é reaproveitada.

O retorno costuma ser mais rápido.


IPL e LPAR

Cada LPAR possui seu próprio IPL.

Exemplo:

IBM Z

↓

LPAR Produção

↓

IPL

↓

z/OS Produção

----------------

LPAR Testes

↓

IPL

↓

z/OS Testes

Uma LPAR pode ser reiniciada sem afetar as demais.


IPL e HMC

O administrador utiliza a HMC para:

  • selecionar a LPAR;

  • escolher o dispositivo IPL;

  • iniciar o boot;

  • acompanhar mensagens.


O que acontece após o IPL?

Depois que o sistema operacional inicia:

  • usuários podem entrar no TSO;

  • jobs podem ser submetidos;

  • CICS aceita transações;

  • Db2 abre bancos;

  • MQ inicia filas;

  • aplicações ficam disponíveis.


Quanto tempo demora?

Depende do ambiente.

Pequenos sistemas:

alguns minutos.

Grandes bancos:

10 a 30 minutos, ou mais, dependendo da quantidade de subsistemas e aplicações.


Quem realiza IPL?

Principalmente:

  • Operadores Mainframe;

  • Sysprogs;

  • Administradores z/OS;

  • Equipes de Infraestrutura;

  • Suporte IBM.

Programadores COBOL normalmente apenas acompanham o processo.


Benefícios

Inicialização segura

Todo o ambiente é carregado de forma controlada.


Verificação do hardware

Problemas físicos podem ser detectados logo no início.


Preparação completa

Todos os subsistemas são inicializados na sequência correta.


Alta confiabilidade

O processo é altamente automatizado e testado.


Curiosidades incríveis

1. O termo IPL é mais antigo que o conceito moderno de "boot"

Enquanto computadores pessoais popularizaram a palavra boot, o universo IBM já utilizava o termo IPL desde os primeiros grandes sistemas.


2. Um grande banco pode executar dezenas de IPLs planejados por ano

Eles ocorrem principalmente durante janelas de manutenção para instalação de novas versões, PTFs ou atualizações de hardware.


3. Nem toda manutenção exige IPL

Diversas atualizações podem ser aplicadas dinamicamente, mas algumas alterações no núcleo do sistema operacional ainda exigem reinicialização.


4. Um IBM Z pode manter outras LPARs funcionando durante o IPL de uma delas

Graças à virtualização por LPAR, reiniciar um ambiente de testes não interrompe, necessariamente, o ambiente de produção.


Erros comuns de iniciantes

"IPL é apenas ligar o computador"

Não.

O IPL envolve uma sequência complexa de inicialização do hardware, carregamento do sistema operacional e ativação de diversos subsistemas.


"Toda atualização exige IPL"

Não.

Muitas correções são aplicadas dinamicamente.

Somente determinadas alterações de sistema exigem uma reinicialização.


"Fazer IPL reinicia todas as LPARs"

Não.

Cada LPAR pode ser iniciada ou reiniciada individualmente.


Quando aprender IPL?

O conceito de IPL deve ser estudado logo após compreender:

  • IBM Z;

  • HMC;

  • LPAR;

  • z/OS;

  • Address Space.

Esse conhecimento será fundamental para entender administração de sistemas, recuperação de ambientes, manutenção e operação do IBM Mainframe.


Conclusão

O IPL (Initial Program Load) é o processo de inicialização do IBM Mainframe. Durante essa sequência, o hardware carrega o sistema operacional z/OS na memória, verifica os recursos físicos e inicia subsistemas essenciais como JES2, CICS, Db2, IMS e MQ.

Mais do que um simples "boot", o IPL representa uma etapa crítica para garantir que todo o ambiente IBM Z esteja disponível, seguro e pronto para processar milhões de transações com a confiabilidade que caracteriza os mainframes IBM.

terça-feira, 17 de abril de 2007

O que é HMC?

 

Bellacosa Mainframe o que é HMC

O que é HMC?

Quando alguém vê um IBM Z pela primeira vez, costuma imaginar que todo o controle do computador acontece pelo z/OS.

Na realidade, antes mesmo do sistema operacional iniciar, existe um equipamento responsável por administrar o hardware do mainframe.

Esse equipamento chama-se:

HMC (Hardware Management Console)

Ela é uma das ferramentas mais importantes de toda a infraestrutura IBM Z.

Sem ela, seria praticamente impossível configurar, iniciar e administrar um mainframe moderno.


Definição simples

A HMC (Hardware Management Console) é o console de administração do hardware do IBM Z.

Ela permite controlar praticamente todos os recursos físicos do equipamento, como:

  • ligar e desligar o mainframe;
  • criar LPARs;
  • gerenciar processadores;
  • monitorar hardware;
  • iniciar IPL;
  • administrar canais de I/O;
  • acompanhar alertas de hardware.

Em outras palavras:

A HMC é o painel de controle do computador IBM Z.


Uma analogia simples

Imagine um grande edifício inteligente.

Existe uma sala de controle responsável por:

  • energia elétrica;
  • elevadores;
  • ar-condicionado;
  • câmeras;
  • segurança.

Mesmo antes dos funcionários chegarem para trabalhar, essa sala já está operando.

A HMC exerce um papel semelhante.

Ela administra o hardware antes mesmo do z/OS ser carregado.


O que significa HMC?

HMC significa:

Hardware Management Console

Em português:

Console de Gerenciamento de Hardware.


Para que serve?

A HMC permite administrar praticamente todo o IBM Z.

Entre suas funções estão:

  • configurar o servidor;
  • criar LPARs;
  • iniciar sistemas operacionais;
  • acompanhar utilização do hardware;
  • detectar falhas;
  • controlar processadores;
  • administrar canais;
  • configurar dispositivos.

Onde fica a HMC?

Normalmente a HMC é:

  • um computador dedicado;
  • uma estação administrativa;
  • conectada diretamente ao IBM Z.

Hoje também pode ser acessada remotamente de forma segura, conforme a política da empresa.


Como funciona?

Imagine o seguinte fluxo:

Administrador

↓

HMC

↓

IBM Z

↓

LPAR

↓

z/OS

↓

CICS / Db2 / IMS

A HMC conversa diretamente com o hardware.


O que é possível fazer?

Ligar o Mainframe

Após manutenção física, a HMC pode iniciar o equipamento.


Executar IPL

O IPL (Initial Program Load) é iniciado através da HMC.

Exemplo:

Selecionar LPAR

↓

Escolher dispositivo IPL

↓

Start

Criar LPARs

Uma das tarefas mais importantes.

Exemplo:

LPAR Produção

LPAR Homologação

LPAR Desenvolvimento

LPAR Testes

Cada LPAR funciona como um computador independente.


Configurar Processadores

É possível definir:

  • CPUs gerais (CP);
  • zIIPs;
  • IFLs;
  • SAPs;
  • processadores reservados.

Monitorar Hardware

A HMC acompanha:

  • temperatura;
  • fontes;
  • ventiladores;
  • memória;
  • processadores;
  • canais;
  • discos.

Detectar Falhas

Caso exista algum problema físico:

Memória com defeito

↓

HMC detecta

↓

Alerta operador

Recursos administrados

A HMC controla:

  • CPC (Central Processor Complex);
  • LPARs;
  • CPUs;
  • Memória;
  • Canais FICON;
  • I/O;
  • Criptografia;
  • Adaptadores de rede.

O que é CPC?

O CPC representa o computador físico IBM Z.

Dentro dele existem:

  • processadores;
  • memória;
  • canais;
  • dispositivos.

A HMC administra todo esse conjunto.


HMC e LPAR

A HMC permite dividir um único IBM Z em diversos computadores virtuais.

Exemplo:

IBM Z

↓

LPAR 1

↓

z/OS Produção

----------------

LPAR 2

↓

Linux

----------------

LPAR 3

↓

z/VM

----------------

LPAR 4

↓

z/OS Desenvolvimento

Tudo controlado pela HMC.


HMC e Hardware

A HMC também permite visualizar:

  • número de CPUs;
  • utilização;
  • memória instalada;
  • status dos canais;
  • adaptadores;
  • dispositivos conectados.

Segurança

O acesso à HMC é altamente controlado.

Existem perfis específicos para:

  • operadores;
  • administradores;
  • engenheiros;
  • suporte IBM.

Nem todos possuem as mesmas permissões.


Quem utiliza a HMC?

Principalmente:

  • Sysprogs;
  • Administradores IBM Z;
  • Operadores Mainframe;
  • Especialistas em Hardware IBM;
  • Equipes de Infraestrutura;
  • Suporte IBM.

Programadores COBOL normalmente não utilizam a HMC.


Benefícios

Administração centralizada

Todo o hardware pode ser controlado por um único console.


Alta disponibilidade

Permite identificar problemas rapidamente.


Virtualização

Gerencia dezenas de LPARs simultaneamente.


Segurança

Controle rigoroso de acesso.


Facilidade operacional

Grande parte da administração ocorre através de interface gráfica.


Curiosidades incríveis

1. A HMC controla o hardware, não o z/OS

Ela atua em um nível inferior ao sistema operacional.


2. Um único IBM Z pode possuir dezenas de LPARs

Todas administradas pela mesma HMC.


3. A HMC monitora milhares de sensores internos

Ela acompanha continuamente temperatura, energia, memória, processadores e outros componentes do equipamento.


4. Grandes empresas costumam utilizar HMCs redundantes

É comum haver duas HMCs configuradas para garantir continuidade administrativa caso uma delas apresente falha.


Erros comuns de iniciantes

"HMC é o sistema operacional"

Não.

Ela administra o hardware.

O sistema operacional é o z/OS, Linux on Z, z/VM ou outro ambiente instalado nas LPARs.


"Programadores COBOL utilizam HMC"

Normalmente não.

Seu uso é voltado para administração da infraestrutura.


"A HMC controla apenas o IPL"

Não.

Ela também administra processadores, memória, LPARs, canais, dispositivos e diversos recursos físicos do IBM Z.


Quando aprender HMC?

O estudo da HMC é recomendado após compreender os conceitos de:

  • IBM Z;
  • z/OS;
  • IPL;
  • LPAR;
  • CPC;
  • Storage;
  • canais de I/O.

Esse conhecimento é essencial para quem deseja atuar como operador de mainframe, administrador de sistemas ou Sysprog.


Conclusão

A HMC (Hardware Management Console) é o principal console de administração do hardware do IBM Mainframe. Ela permite controlar o computador físico IBM Z, criar LPARs, iniciar sistemas operacionais, monitorar componentes, executar IPLs e gerenciar recursos como CPUs, memória e canais de I/O.

Por atuar diretamente sobre a infraestrutura do equipamento, a HMC é uma ferramenta indispensável para garantir a disponibilidade, a segurança e o desempenho do ambiente IBM Z, sendo um dos conhecimentos fundamentais para profissionais de infraestrutura e administração de mainframes.

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...