Feliz Natal do pequeno Luigi para a famiglia Bellacosa. O pequenino Luigi aprontando arte, brincando com os Esquilinhos dançantes. Na época para ele era uma loucura ouvir esses esquilinhos, ele adorava brincar, agarrar, abraçar, apertar as musiquinhas sempre fazendo bagunca com eles.
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
