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

Translate

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

sábado, 7 de fevereiro de 2026

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀 O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

 

Bellacosa Mainframe apresenta a gestão de tarefas no z/os

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀

O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

Você digita um JCL, dá submit e pensa:
👉 “beleza, agora é só esperar o output”

Errado.

No z/OS, seu job entra em um ecossistema competitivo, onde:

  • CPU é disputada
  • memória é compartilhada
  • prioridades são negociadas
  • o sistema decide tudo

Se você quer sair do nível “usuário de mainframe” e virar engenheiro de sistema, esse é o mapa mental que muda o jogo 👊🔥


🧠 1. O COMEÇO — SUBMIT NÃO É EXECUÇÃO

Quando você faz submit:

//JOB ...

👉 seu job NÃO executa.


🔹 O que acontece de verdade

  • JES recebe
  • vai pro spool
  • ganha um número
  • entra numa fila
  • espera um initiator

🔥 Tradução Bellacosa

“Submit é só entrar na fila do sistema.”


💡 Exemplo real

Você tem 100 jobs na fila…

👉 seu job pode esperar minutos ou horas


⚙️ 2. JOB → TASK (A TRANSFORMAÇÃO INVISÍVEL)

O z/OS não trabalha com “jobs”.

👉 Ele trabalha com:

TASKS (TCBs)


🔹 Como funciona

JOB → STEPS → TASKS (TCB)

Cada step vira uma unidade executável.


🧨 Curiosidade

Um job pode gerar várias tasks simultâneas.


⚡ 3. DISPATCHER — O “DEUS DO CPU”

Esse é o cara mais importante do sistema.


🔹 Função

Decidir:

“Quem roda AGORA?”


🔥 Como ele faz isso

  • varre a fila (WUQ)
  • pega TCB ou SRB
  • escolhe o de maior prioridade
  • carrega contexto
  • entrega CPU

💡 Insight poderoso

O dispatcher troca tarefas milhares de vezes por segundo


🧠 Tradução

CPU nunca fica “presa” a um programa


🧩 4. TCB vs SRB — A BRIGA INTERNA

🔹 TCB

  • usado por aplicações (COBOL 👀)
  • pode ser interrompido

🔹 SRB

  • usado pelo sistema
  • maior prioridade
  • execução mais rápida

🔥 Tradução Bellacosa

SRB é o “VIP do sistema”
TCB é o trabalhador comum 😄


🧠 5. ENCLAVES — O NÍVEL CORPORATIVO

Aqui o sistema evolui de técnico → negócio.


🔹 O que é?

Um conjunto de tarefas:

👉 espalhadas em vários address spaces
👉 tratadas como uma unidade


🔥 Exemplo real

App Web → WAS → CICS → DB2

👉 tudo isso vira um enclave


💡 Insight

O z/OS não gerencia código… gerencia transações de negócio


🖥️ 6. PR/SM — O MESTRE DO HARDWARE

Antes do z/OS, existe:

👉 PR/SM (hypervisor)


🔹 Ele faz:

  • divide hardware em LPARs
  • entrega CPU virtual
  • controla recursos

🔥 Relação

Hardware → PR/SM → z/OS → Task

🧨 Curiosidade

Seu z/OS pode não saber qual CPU física está usando 😳


⚡ 7. CPU MANAGEMENT — ONDE PERFORMANCE NASCE

🔹 Conceitos:

  • HyperDispatch
  • afinidade CPU/memória
  • otimização de cache

💡 Insight

Rodar perto do dado = menos latência


🔥 Tradução Bellacosa

Não é só rodar… é rodar no lugar certo


👥 8. ADDRESS SPACES — O UNIVERSO ISOLADO

Cada coisa roda em seu próprio espaço:

  • Batch
  • TSO
  • Started Task

🔥 Dentro deles:

  • TCBs
  • subtasks
  • memória isolada

💡 Exemplo

Um batch:

Initiator → cria address space → cria TCB → executa

🔗 9. DYNAMIC LINKAGE — COMO OS PROGRAMAS SE CONECTAM

🔹 Comandos principais:

  • LINK
  • LOAD
  • ATTACH
  • XCTL

🔥 O que fazem?

  • chamam programas
  • carregam módulos
  • transferem controle

💡 Ordem de busca:

  1. memória (LPA)
  2. JOBLIB/STEPLIB
  3. LINKLIST

🧨 Easter Egg

Se está na LPA… é MUITO mais rápido


🧠 10. WLM — O VERDADEIRO CHEFE

🔥 Workload Manager

Define:

  • prioridade
  • objetivos
  • distribuição de CPU

💡 Exemplo real

Tipo de workloadPrioridade
pagamento onlinealta
batch relatóriobaixa

🔥 Tradução Bellacosa

O sistema não atende quem pede… atende quem importa


🔒 11. SERIALIZATION — EVITANDO O CAOS

🔹 Problema:

2 jobs querem o mesmo recurso


🔹 Solução:

  • ENQ / DEQ
  • GRS

💡 Exemplo

Dois jobs acessando dataset:

👉 um espera


🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Seu job pode nunca rodar

Se prioridade for baixa


🔥 2. CPU pode trocar de task milhares de vezes

Você nem percebe


💀 3. SRB pode interromper seu programa

Sem você saber


🧠 4. Um único negócio pode rodar em vários address spaces

(enclave)


⚙️ PASSO A PASSO REAL (SIMPLIFICADO)

Submit Job

JES spool

Fila de execução

Initiator pega job

Cria Address Space

Cria TCB

Dispatcher escolhe

CPU executa

WLM ajusta prioridade

Output no spool

🎯 RESUMO FINAL

✔ Job vira task

✔ Task disputa CPU

✔ Dispatcher decide

✔ WLM prioriza

✔ PR/SM gerencia hardware

✔ Enclave agrupa negócio


💥 FRASE FINAL

“Você não executa um job no mainframe…
você entra numa competição onde o z/OS decide se você merece rodar.”


 

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.


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.

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