Translate

Mostrar mensagens com a etiqueta Address Spaces. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Address Spaces. Mostrar todas as mensagens

quinta-feira, 26 de março de 2026

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

 

Bellacosa Mainframe explorando address spaces & tasks

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

🧙‍♂️ Padawan, aproxime-se.
Se você entender profundamente Address Spaces e Tasks, você atravessa a porta de entrada do mundo Sysprog. Sem isso, z/OS parece magia. Com isso, vira engenharia.

Pegue seu café. Vamos abrir o capô do mainframe. ☕


🌌 Capítulo 1 — O z/OS Não Executa Programas. Executa Universos.

Em um PC comum você pensa:

“Vou rodar um programa.”

No z/OS, o raciocínio é outro:

⭐ “Vou criar um ambiente isolado onde programas poderão existir.”

Esse ambiente é o:

🏢 Address Space

Ele contém:

  • Memória virtual privada
  • Identidade de segurança
  • Recursos
  • Estruturas de controle
  • Tasks (unidades de execução)
  • Programas rodando

👉 Tudo roda dentro de um address space.

Exceto funções internas do kernel — e isso é assunto para um Jedi Master.


🔎 Como ver o “multiverso” ao vivo

Abra o SDSF:

SDSF → DA

Cada linha é um universo independente:

  • MASTER
  • JES2
  • TCPIP
  • IBMUSER
  • CICS
  • Jobs batch
  • Processos UNIX

Um sistema real pode ter centenas.

🥚 Easter Egg #1:
O MASTER é sempre ASID 1.
Se ele cair… você tem problemas maiores do que um dump.


🔒 Capítulo 2 — O Isolamento Que Salvou o Mainframe

Cada address space tem memória privada.

Um programa em A NÃO pode acessar a memória de B.

Isso evita:

  • Corrupção entre aplicações
  • Vazamento de dados
  • Quedas sistêmicas
  • Caos total

🧠 Mas há um truque genial…

Cada espaço acha que possui toda a memória.

Sim. Toda.


🧭 Virtual Memory — A Ilusão Controlada

Dois programas podem usar o mesmo endereço:

x'2795'

E acessar memórias físicas diferentes.

Isso ocorre graças à:

⭐ DAT — Dynamic Address Translation

Virtual → Page Tables → Real Memory

👉 Daí o nome Address Space.

Cada universo tem seus próprios endereços.


🤝 Compartilhamento? Só com permissão

Quando necessário:

  • Common Storage (CSA/ECSA)
  • Cross-memory services
  • Program Call
  • Serviços autorizados

Exemplo clássico:

CICS falando com DB2.


🧵 Capítulo 3 — Dentro do Universo: Tasks

Um address space sozinho não executa nada.

Quem executa são:

🧵 Tasks (TCBs ou SRBs)

⭐ Task = menor unidade despachável

O dispatcher agenda tasks nos CPUs.


⚡ Paralelismo real

Se houver 10 CPUs → até 10 tasks executando simultaneamente.

Mas…

🥚 Easter Egg #2:
A maioria das tasks está esperando algo — não executando.

Porque sistemas corporativos são I/O-bound.


⏳ Estados típicos

🟢 Running

No CPU agora

🟡 Ready

Quer CPU, mas aguarda

🔴 Waiting

Esperando evento:

  • I/O
  • Lock
  • Resposta externa
  • Timer
  • Memória

📦 Uma task pode executar vários programas

Mas:

❗ Apenas um por vez

Exemplo COBOL clássico:

MAIN
CALL VALIDATE
CALL CALCULATE
CALL UPDATE
CALL PRINT
STOP RUN

Tudo na mesma task.


⚙️ Quer paralelismo? Crie novas tasks.

ATTACH → nova TCB

Exemplo batch paralelo:

Task A → Arquivo1
Task B → Arquivo2
Task C → Arquivo3

🐧 Padawans vindos do UNIX

Boa analogia:

z/OSUNIX
Address SpaceProcess
Task (TCB)Thread

E sim:

⭐ Cada thread USS é uma task.


👑 Capítulo 4 — A Task Raiz: RCT

Quando um address space nasce:

  1. Cria-se a Region Control Task (RCT)
  2. Outras tasks são iniciadas
  3. Programas executam nelas

Hierarquia:

Address Space
└── RCT
├── Task A
└── Task B

🥚 Easter Egg #3:
Se a RCT terminar… o address space inteiro termina.

Sem órfãos. Sem bagunça.


⚡ Capítulo 5 — O Primo Ninja: SRB

Existem dois tipos de tasks:

🧵 TCB — normal

Aplicações, batch, TSO, etc.

⚡ SRB — especial

Serviços do sistema.

Diferenças fundamentais:

TCBSRB
Pode esperarGeralmente não
Longo prazoCurto
LocalPode ser cross-memory
AplicaçõesSistema

SRBs são criados via:

SCHEDULE

Não automaticamente.


🧠 Capítulo 6 — Memória Compartilhada entre Tasks

Dentro do mesmo address space:

👉 Tasks compartilham memória.

Isso permite cooperação rápida.

Mas também risco.

Programas autorizados podem proteger áreas — aplicações comuns raramente fazem isso.


🏛️ Capítulo 7 — Como Address Spaces Nascem

Criados quando surge um workload independente:

  • IPL do sistema
  • START de serviço
  • Logon TSO
  • Job batch selecionado pelo JES
  • Processo UNIX iniciado

❌ NÃO quando:

  • Um programa começa
  • Um comando TSO é digitado
  • Uma subrotina é chamada

🥚 Easter Egg #4:
Criar address space é caro. z/OS evita fazer isso sem necessidade.


🧾 Capítulo 8 — ASCB, ASID e Jobname

Cada address space é registrado por um:

⭐ ASCB — Address Space Control Block

Contém:

  • ASID (ID interno)
  • Jobname (nome visível)
  • Ponteiros para TCBs
  • Estado
  • Dados de gerenciamento

Operador vê:

👉 JOBNAME

Sistema usa:

👉 ASID


👨‍💼 Capítulo 9 — Administração na Vida Real

Operadores controlam address spaces, não tasks.

Comandos típicos:

S TCPIP
P CICS
C JOB123
F JES2,QUIESCE

Tasks só entram em cena quando algo dá errado.


💥 Capítulo 10 — Por Que Isso Faz o Mainframe Ser o Mainframe

Essa arquitetura permite:

✔ Escalabilidade massiva
✔ Isolamento forte
✔ Alta disponibilidade
✔ Throughput absurdo
✔ Recuperação controlada
✔ Multi-tenant seguro


🏆 O Insight Jedi

🏢 Address Space = Ambiente

🧵 Task = Execução

💻 Program = Código executado

Ou, no idioma Bellacosa:

“O z/OS não roda programas.
Ele mantém universos onde programas vivem.”


☕ Missão do Padawan

Se você entendeu este artigo, já ultrapassou 80% dos iniciantes em mainframe.

O próximo passo é dominar:

  • Dispatching e WLM
  • Storage Manager
  • JES internals
  • Subsystems architecture
  • Dump analysis

💬 Último conselho

🧙‍♂️ “Quem entende Address Spaces e Tasks não apenas usa o z/OS… começa a pensar como ele.”


 

sexta-feira, 6 de fevereiro de 2026

🔥 SE O z/OS NÃO SOBE… NADA EXISTE 💀O guia proibido do IPL que todo dev COBOL deveria entender (mas quase ninguém entende)

 

Bellacosa Mainframe fala sobre a iniacialização do ambiente operacional

🔥 SE O z/OS NÃO SOBE… NADA EXISTE 💀

O guia proibido do IPL que todo dev COBOL deveria entender (mas quase ninguém entende)

Você escreve COBOL… compila… roda…
👉 e acha que o sistema “tá lá pronto”.

Errado.

Antes do seu programa existir, acontece um ritual quase místico chamado:

IPL — Initial Program Load

E aqui vai a verdade estilo Bellacosa:

💥 “Se o IPL falhar… o mainframe inteiro simplesmente NÃO EXISTE.”

Hoje você vai entender isso como um padawan do mainframe, mas com visão de Jedi 👊🔥


🧠 O QUE É O IPL (O NASCIMENTO DO SISTEMA)

O IPL é o momento em que:

  • o hardware ganha vida
  • o z/OS é carregado
  • os primeiros address spaces são criados

👉 Segundo o material, ele:

  • carrega o sistema do disco
  • inicializa o kernel
  • cria o ambiente completo

🔥 Tradução Bellacosa

“IPL é o Big Bang do z/OS.”


🧱 OS DATASETS QUE FAZEM O MILAGRE ACONTECER

Sem eles… não tem sistema. Simples assim.


🔥 SYS1.NUCLEUS — o coração

Contém:

  • NIP (Nucleus Initialization Program)
  • RIM (Resource Initialization)
  • módulos básicos do kernel

👉 É literalmente o “cérebro inicial”.


🔥 SYS1.LPALIB — a memória compartilhada

  • módulos do sistema
  • SVCs
  • rotinas críticas

👉 Vai parar dentro da LPA (já já explico 👀)


🔥 SYS1.LINKLIB — o arsenal

  • programas do sistema
  • inclui o Master JCL

👉 Aqui começa a execução de verdade.


🔥 SYS1.PARMLIB — o cérebro de configuração

Define:

  • como o sistema vai funcionar
  • performance
  • segurança

👉 É o /etc do z/OS… só que turbinado.


🔥 SYS1.PROCLIB — automação

  • procedures (START, etc.)
  • inicialização de subsistemas

🔥 Outros importantes

  • PAGE DATASETS → memória virtual
  • SMF → estatísticas
  • DUMP → análise de erro

💡 Insight de ouro

“z/OS não sobe com código… sobe com DATASETS.”


⚙️ I/O CONFIG — O MAPA DO MUNDO

Antes do sistema usar qualquer coisa, ele precisa saber:

  • quais devices existem
  • onde estão
  • como acessar

🔹 Quem faz isso?

👉 HCD + IOCDS + IODF


🔥 Durante o IPL:

  • cada device gera um UCB (Unit Control Block)
  • o sistema passa a reconhecer discos, fitas, etc.

🧨 Easter Egg

Se o device não está no IODF… ele NÃO EXISTE pro sistema.


🧠 PARMLIB — ONDE VOCÊ DOMINA O SISTEMA

🔹 O que é?

Um conjunto de membros tipo:

  • IEASYSxx
  • LOADxx
  • outros

🔥 Função

Define:

  • memória
  • subsistemas
  • comportamento do sistema

💡 Dica de Jedi

Nunca mexa direto no default:

IEASYS00 → base
IEASYS01 → custom

👉 Se quebrar, você volta.


⚡ LOADXX — O DNA DO IPL

Esse cara decide:

  • qual nucleus usar
  • qual configuração carregar
  • qual PARMLIB seguir

🔹 Estrutura mental

LOADxx

aponta para:
- NUCLEUS
- PARMLIB
- CONFIG

🧨 Curiosidade

Um LOADxx pode subir vários sistemas no sysplex 😳


🚀 NIP — O CONSTRUTOR DO UNIVERSO

🔹 Nucleus Initialization Program

Ele:

  • inicializa memória
  • cria control blocks
  • cria address spaces

🔥 Resultado

transforma hardware em z/OS funcional


🧩 LINK PACK AREA (LPA) — ONDE TUDO FICA PRONTO

🔹 Tipos:

  • FLPA → fixo
  • MLPA → modificado
  • PLPA → paginável

💡 Tradução

LPA = “biblioteca carregada na memória para todo mundo usar”


👥 ADDRESS SPACES — O SISTEMA GANHA VIDA

🔥 Primeiro criado:

👉 MASTER (001 👀)


Depois:

  • JES
  • SMF
  • RSM
  • GRS
  • TRACE
  • DUMP

💡 Insight

Tudo nasce no IPL. Nada existia antes.


⚙️ PASSO A PASSO DO IPL (SIMPLIFICADO)

1. Power on
2. CPU lê DASD (SYSRES)
3. Carrega IPL text (IEAIPL00)
4. Carrega NUCLEUS
5. Executa NIP
6. Lê PARMLIB
7. Configura I/O (IODF)
8. Cria address spaces
9. Inicia subsistemas

👉 Boom 💥 sistema vivo


🔧 TUNING (onde os Jedi brilham)

🔥 Onde ajustar:

  • PARMLIB
  • LPA
  • PAGE datasets

💡 Exemplos:

  • mais memória → melhor performance
  • LPA otimizada → menos I/O
  • configuração errada → desastre

💀 TROUBLESHOOTING (quando tudo dá errado)

🔥 Problemas clássicos:

  • dataset não encontrado
  • erro no PARMLIB
  • device inexistente
  • LOADxx incorreto

🧨 Sintoma clássico:

👉 Disabled Wait Code


💡 Tradução

“Deu ruim antes do sistema existir.”


🧨 CURIOSIDADES QUE POUCOS SABEM

🤯 1. O sistema começa praticamente “cego”

Sem PARMLIB → nada funciona


🔥 2. O primeiro address space é 001

Nunca 000 (pegadinha de prova)


💀 3. IPL falha sem log amigável

Você ganha código e reza 😄


🧠 4. Tudo gira em torno de control blocks

Criados desde o início pelo NIP


🎯 RESUMO FINAL (nível padawan → jedi)

✔ IPL = nascimento do sistema

✔ SYS1 datasets = base de tudo

✔ PARMLIB = cérebro

✔ LOADxx = DNA

✔ NIP = construtor

✔ LPA = memória compartilhada

✔ Address spaces = vida


💥 FRASE FINAL

“Você acha que executa programas…
mas primeiro o z/OS precisa nascer — e esse nascimento é uma obra de engenharia absurda.”