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