Translate

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

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

 

quinta-feira, 2 de maio de 2019

☕💥 A Jornada do Padawan COBOL – Parte 5 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o call em cobol parte V

☕💥 A Jornada do Padawan COBOL – Parte 5

Desvendando o Universo dos CALLs no Mainframe

Binder, Link-Edit, FETCH, CANCEL, Program Objects, DLLs, LPA, LINKLIST e os Segredos dos Mestres do z/OS

Ou como descobrir que um CALL pode custar microssegundos, megabytes e algumas noites de sono se você não entender o que acontece depois do compilador

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que COBOL não gera executáveis

Até agora aprendemos:

✔ Static CALL

✔ Dynamic CALL

✔ By Reference

✔ Reentrância

✔ LE

✔ Heap

✔ Stack

✔ CEEDUMP

Mas existe uma pergunta importante.

Quando fazemos:

CALL 'VALIDA01'

Como exatamente o z/OS encontra este programa?

Onde ele mora?

Quem o carrega?

Quem o remove?

Quem o deixa residente?

Prepare outro café.

Hoje vamos conhecer o Binder.


O Binder

Antigamente chamávamos de:

Link Edit

Linkage Editor

IEWL

Hoje chamamos simplesmente de:

Binder


Ele é o responsável por transformar:

Objeto

em

Programa executável


Visualmente

COBOL Source

↓

IGYCRCTL

↓

Object Module

↓

Binder

↓

Program Object

↓

PDMLIB

O que o Binder faz

Resolve símbolos

Resolve CALL estático

Organiza seções

Cria aliases

Define AMODE

Define RMODE

Otimiza carregamento


Static CALL revisitado

Exemplo

CALL 'CPFVAL'

Binder procura:

CPFVAL

Achou.

Inclui.

Executável cresce.


Visualmente


MAIN


+

CPFVAL


+

JUROS


+

PIX


=


MAINLOAD


Dynamic CALL

Binder ignora.

Não liga.

Não participa.


Em execução.

Sistema procura.


Onde procura?

STEPLIB

Primeiro.


JOBLIB

Depois.


TASKLIB


LPA


LINKLIST


LPDB

Dependendo ambiente


Fluxo


CALL CPFVAL


↓

STEPLIB


↓

JOBLIB


↓

LPA


↓

LINKLIST


↓

Achou


↓

Carrega


↓

Executa


Quanto custa?

Cada busca.

CPU.

I/O.

Tempo.


Pouco?

Sim.

Milhões de vezes?

Muito.


O segredo da LPA

Link Pack Area


Área compartilhada.


Programa carregado

uma vez.


Usado por todos.


Visualmente


LPA


CPFVAL



CLIENTE A


CLIENTE B


CLIENTE C


CLIENTE D


Excelente.


Quando usar?

Rotinas muito chamadas.

Segurança.

Conversão.

Data.

Utilitários.


FETCH

Poucos usam.

Poucos conhecem.

Muito poderoso.


Exemplo

CALL 'IGZCFCC'

Internamente.

Faz FETCH.


FETCH significa

Pré-carregar.


Antes da execução.


Benefício

Evita primeira carga.

Reduz latência.


CANCEL

Um comando subestimado.


Exemplo

CALL WS-PGM


...


CANCEL WS-PGM

O que faz?

Remove programa da memória.


Por que usar?

Liberar storage.

Reinicializar estado.


Exemplo

Subprograma mantém cache.

Quer limpar.

CANCEL 'CACHE001'

Nova chamada.

Programa recarregado.


Cuidado

CANCEL excessivo

mata performance.


DLL no zOS

Sim.

Existe.


Dynamic Link Library.


Program Objects.


LE suporta.


Exemplo

C

COBOL

PLI

Assembler

Compartilhando.


Program Objects

Evolução do antigo Load Module.


Vantagens

Maior tamanho

AMODE 64

Melhor performance

Mais símbolos

Debug


IBM recomenda.

Sempre.


AMODE

Já vimos.

Mas Binder controla.


Exemplo

AMODE(31)


RMODE(ANY)

RMODE

Onde carregar.


RMODE 24

Baixa memória.


RMODE ANY

Qualquer lugar.


Mais flexível.


Alias

Binder pode criar.


Exemplo

Programa

CLIENTE01

Alias

CL001

Mesmo executável.

Dois nomes.


Problemas clássicos

S806

Programa não encontrado.


Verificar

STEPLIB

LPA

LINKLIST

Binder


S0C1

Módulo inválido.


Compilação errada.


U4087

LE.


S878

Sem memória.


Como descobrir

LISTLOAD

AMBLIST

IEWL

IPCS

SDSF


AMBLIST

Ferramenta maravilhosa.

Pouco utilizada.


Permite ver

AMODE

RMODE

Alias

Entradas

Tamanho


Exemplo

AMBLIST LISTIDR

Dica Bellacosa

Sempre guardar map.


Compile

LIST


OFFSET


MAP

Futuro você agradece.


Microbenchmark Jedi

Método

Tempo

Static CALL

0,8 us

Dynamic

2 us

FETCH

1 us

LPA

0,5 us

CANCEL frequente

8 us


Easter Egg Mainframe

Existe em muitos bancos.

Programa chamado.

GENERICA

Dentro.

EVALUATE WS-TIPO


WHEN 001


CALL P001


WHEN 002


CALL P002


WHEN 003


CALL P003


...


WHEN 999


CALL P999


END-EVALUATE

Mais de 900 programas.


Autor

Aposentado.

Documentação

Nenhuma.


Produção

Executa bilhões.

Diariamente.


Ninguém toca.


Conhecido pelos veteranos como:

A Biblioteca de Alexandria do Mainframe™


Checklist Jedi do Binder

✅ Static apenas quando necessário

✅ Dynamic para produtos

✅ Evitar CANCEL excessivo

✅ Preferir Program Objects

✅ Verificar AMODE

✅ Verificar RMODE

✅ Utilizar LPA

✅ Medir CPU

✅ Guardar MAP

✅ Gerar OFFSET

✅ Conhecer AMBLIST

✅ Conhecer Binder


A Filosofia Jedi do CALL – Parte 5

O Padawan iniciante acredita:

O compilador cria o executável.

O desenvolvedor intermediário pensa:

O Binder junta módulos.

O Mestre Mainframe entende:

O Binder é um arquiteto invisível. Ele decide onde o programa viverá, como será carregado, quem poderá compartilhá-lo, quanto storage consumirá e quantos microssegundos serão economizados em milhões de transações.

E é exatamente por isso que alguns arquitetos IBM Z conseguem olhar para um simples:

CALL 'SUBPGM'

E enxergar imediatamente:

  • Binder

  • Program Objects

  • LPA

  • RMODE

  • AMODE

  • FETCH

  • CANCEL

  • LE

  • CPU

  • Storage

  • Cache

  • Concurrency

  • Escalabilidade

Porque no universo do Mainframe, um CALL nunca é apenas um CALL.

É uma decisão de arquitetura que pode continuar impactando sistemas críticos por décadas.


Na Parte 6, o Padawan poderá explorar o nível Mestre: CICS LINK/XCTL, COMMAREA, Channels & Containers, z/OS Connect, APIs REST, Java, JNI, Metal C, MQ, zIIP, SMF 110, Strobe, APA e como os arquitetos modernos integram COBOL com microsserviços e nuvem.