domingo, 20 de dezembro de 2009

🔥🧠 COBOL no z/OS — COMO O PROGRAMA “EXISTE” NA MEMÓRIA (DO SUBMIT AO FREEMAIN) 🧠🔥

Bellacosa Mainframe explica uso de storage de um programa Cobol Batch do sub até o Freemain

🔥🧠 COBOL no z/OS — COMO O PROGRAMA “EXISTE” NA MEMÓRIA (DO SUBMIT AO FREEMAIN) 🧠🔥

Uma visão completa — arquitetura + runtime + storage + troubleshooting — exatamente como um Dev Mainframe precisa entender 😎

Baseado na arquitetura de memória virtual do z/OS (VSM/RSM/ASM, áreas common/private, DAT, etc.) .

🚀 VISÃO GERAL — A JORNADA DO PROGRAMA COBOL

👉 Um programa COBOL no mainframe não é carregado “na RAM” diretamente como em PCs.

Ele passa por:


JCL → JES → Initiator → Address Space → Loader → LE → Execução → Término → Liberação

Programa Cobol uso de storage

🧭 PASSO 1 — SUBMIT DO JCL

Quando você faz:


//STEP1 EXEC PGM=MEUPROG

O que acontece:

1️⃣ JES2/JES3 recebe o job
2️⃣ JCL é interpretado
3️⃣ Recursos são reservados
4️⃣ Job entra na fila

👉 Nenhuma memória do programa ainda foi alocada.

🏗️ PASSO 2 — CRIAÇÃO DO ADDRESS SPACE

Quando o job inicia:

👉 O z/OS cria um Address Space dedicado

Esse espaço virtual contém:

Áreas privadas do job
Áreas comuns compartilhadas
Estruturas do sistema

🧠 Estrutura simplificada


COMMON STORAGE (global)
-----------------------
PRIVATE STORAGE (do job)

📏 PASSO 3 — POSIÇÃO NA MEMÓRIA (LINE / BAR)

🔻 Below the Line (24-bit)

0 → 16 MB
👉 Legacy (raramente usado por COBOL moderno)

🔸 Above the Line (31-bit)

16 MB → 2 GB
👉 Onde vive a maioria dos programas COBOL batch

🔺 Above the Bar (64-bit)

2 GB
👉 Dados grandes, LE heaps modernos, Java, DB2 buffers etc.

🧠 Onde um COBOL típico roda?

👉 Código geralmente em 31-bit
👉 Dados podem estar 31-bit ou 64-bit

🧩 PASSO 4 — QUEM CARREGA O PROGRAMA?

🏆 Loader do z/OS (Program Fetch)

Fluxo:

1️⃣ Initiator chama o programa
2️⃣ Loader procura módulo em:

STEPLIB
JOBLIB
LNKLST
LPA (se residente)

3️⃣ Módulo é carregado na memória virtual

📦 Onde o código fica?

Normalmente:

👉 Private storage do address space
👉 Ou LPA se compartilhado (read-only)

🧠 PASSO 5 — LINGUAGE ENVIRONMENT (LE)

Programas COBOL modernos executam sob LE.

O LE cria:

Stack
Heap
Control blocks
Runtime services
Condition handlers

🧱 Heaps do LE

Podem ficar:

Below the bar
Above the bar (HEAP64)
Mixed

⚙️ PASSO 6 — EXECUÇÃO

Durante a execução o programa usa:

🔹 Código (reentrante)

Read-only, pode ser compartilhado

🔹 WORKING-STORAGE

Dados globais do programa

🔹 LOCAL-STORAGE

Dados por chamada

🔹 FILE BUFFERS

Buffers de I/O

🔹 LE heaps

Alocações dinâmicas

🧠 Quem gerencia a memória?

🔷 VSM — Virtual Storage Manager

👉 Alocação virtual (GETMAIN/STORAGE)

🔶 RSM — Real Storage Manager

👉 Mapeamento para memória física

🔷 ASM — Auxiliary Storage Manager

👉 Paging se necessário

📊 VISÃO INTERNA SIMPLIFICADA


Address Space do Job
│
├─ User Region
│   ├─ Código COBOL
│   ├─ WORKING-STORAGE
│   ├─ LE Heap/Stack
│   └─ Buffers
│
├─ LSQA
│   └─ Control blocks locais
│
└─ COMMON (CSA/SQA/LPA)
    └─ Componentes globais

🔄 PASSO 7 — CHAMADAS ENTRE PROGRAMAS

Quando um COBOL faz:


CALL 'OUTROPGM'

Pode ocorrer:

🔹 Static call

Módulo já carregado

🔹 Dynamic call

Loader traz novo módulo

👉 Pode alocar mais storage.

🧵 PASSO 8 — PAGING (SE NECESSÁRIO)

Se memória física faltar:

👉 Páginas podem ir para auxiliary storage

Transparente para o programa.

🏁 PASSO 9 — TÉRMINO DO PROGRAMA

Quando termina:

1️⃣ LE executa rotinas de cleanup
2️⃣ Arquivos são fechados
3️⃣ Storage privado é liberado
4️⃣ Control blocks são removidos

🧹 PASSO 10 — LIBERAÇÃO DO ADDRESS SPACE

👉 O sistema destrói o espaço virtual do job.

Tudo que não é comum desaparece.

📊 WORKFLOW COMPLETO


SUBMIT
  ↓
JES Queue
  ↓
Initiator seleciona job
  ↓
Criação do Address Space
  ↓
Loader carrega programa
  ↓
LE inicializa runtime
  ↓
Execução COBOL
  ↓
I/O e alocações dinâmicas
  ↓
Finalização
  ↓
Liberação de storage
  ↓
Address Space destruído


Como funciona um Cobol Batch no Mainframe

💣 TROUBLESHOOTING — VISÃO DO DEV COBOL

🔥 S878 — falta de storage

Causas típicas:

Loop de alocação
Heaps grandes
REGION pequeno
Vazamento via LE

🔥 0C4 — proteção

Ponteiro inválido
Overlay
Uso após FREEMAIN
Dados corrompidos

🔥 S40D — region pequena

Muitos buffers
Tabelas grandes
Recursão
LE heap insuficiente

🧠 DICAS DE OURO PARA DEV MAINFRAME

✔ Código reentrante economiza memória

Pode ser compartilhado entre jobs.

✔ Usar LOCAL-STORAGE reduz interferência

Cada invocação tem sua cópia.

✔ Dados gigantes → considerar ABOVE THE BAR

Via LE e opções de compilação.

✔ Evitar loops de alocação dinâmica

🏆 RESUMO FINAL — QUEM FAZ O QUÊ?

Componente	Função
JES	Gerencia job
Initiator	Executa
Loader	Carrega programa
LE	Runtime COBOL
VSM	Memória virtual
RSM	Memória real
ASM	Paging
z/OS	Orquestra tudo

🎯 CONCLUSÃO

👉 Um programa COBOL não “fica na memória” —
ele vive dentro de um ecossistema sofisticado de virtualização.

Entender isso permite:

💎 Diagnosticar ABENDs difíceis
💎 Otimizar performance
💎 Dimensionar REGION corretamente
💎 Conversar de igual para igual com SysProg
💎 Evoluir para arquiteto de plataforma

https://www.linkedin.com/pulse/cobol-zos-como-o-programa-existe-na-mem%25C3%25B3ria-do-submit-bellacosa-xliaf