Translate

Mostrar mensagens com a etiqueta Arquitetura Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Arquitetura Mainframe. Mostrar todas as mensagens

segunda-feira, 2 de março de 2026

☕ “CALL ‘SABEDORIA’ USING PADAWAN” — O Guia Definitivo de Subprogramação COBOL Que Separa Aprendizes de Mestres do Mainframe

 

Bellacosa Mainframe exemplifica call no Cobol

☕ “CALL ‘SABEDORIA’ USING PADAWAN” — O Guia Definitivo de Subprogramação COBOL Que Separa Aprendizes de Mestres do Mainframe

Se você acha que subprogramação em COBOL é só “CALL e pronto”… prepare-se.
Você está prestes a atravessar a porta que leva do programador de exercícios para o engenheiro de sistemas que mantém bancos funcionando 💎

Neste artigo, vou falar com você — jovem Padawan do mainframe — no melhor estilo Bellacosa: direto, prático, cheio de contexto real, curiosidades históricas e aquelas “armadilhas invisíveis” que só aparecem em produção às 3h da manhã.

Pegue seu café ☕. Vamos lá.


🧠 Por que subprogramação é o coração do COBOL?

Grandes sistemas COBOL NÃO são programas gigantes.

Eles são:

👉 Redes de módulos especializados
👉 Bibliotecas corporativas compartilhadas
👉 Camadas de negócio reutilizáveis
👉 Serviços internos antes da palavra “microservice” existir

Um sistema bancário típico executa milhares de subprogramas por segundo.


🧩 O que é um Subprograma, afinal?

Um subprograma é um programa COBOL independente que:

✔ Pode ser chamado por outro
✔ Executa uma tarefa específica
✔ Recebe dados
✔ Retorna resultados
✔ Continua existindo sozinho

Em termos modernos:

É como uma função gigante com superpoderes de desempenho.


📞 O ritual sagrado: CALL

Programa principal (Caller)

CALL "CALCJURO" USING WS-VALOR WS-RESULT

Subprograma (Callee)

LINKAGE SECTION.
01 VALOR PIC 9(7)V99.
01 RESULT PIC 9(7)V99.

PROCEDURE DIVISION USING VALOR RESULT.
COMPUTE RESULT = VALOR * 1.05
GOBACK.

💥 Pronto. Comunicação entre programas.


🔗 Easter Egg #1 — COBOL já fazia “APIs internas” nos anos 70

Antes de REST, SOAP, gRPC…

Mainframes já tinham bibliotecas de serviços corporativos reutilizáveis.


📦 O segredo oculto: LINKAGE SECTION

Padawan, grave isto na pedra:

Sem LINKAGE SECTION, não há parâmetros.

Ela define a interface do subprograma — o “contrato”.


🔄 Como os dados são passados?

🔹 BY REFERENCE (padrão)

👉 Mesma área de memória
👉 Alterações retornam

CALL "PGM" USING WS-DATA

💎 Rápido, eficiente, poderoso… e perigoso.


🔹 BY CONTENT

👉 Cópia do valor
👉 Caller não vê mudanças

CALL "PGM" USING BY CONTENT WS-DATA

🔹 BY VALUE

👉 Valor literal — comum com C/Java


⚠️ Easter Egg #2 — A causa invisível de bugs fantasma

90% dos “dados misteriosamente alterados” em sistemas antigos são BY REFERENCE mal usado.


🧭 Quem é o Main Program?

Plot twist:

👉 O código não define.
👉 O ambiente define.

No batch:

➡ O programa do EXEC no JCL é o principal.

Em CICS:

➡ O ambiente decide.

O mesmo módulo pode ser:

✔ Main hoje
✔ Subprograma amanhã
✔ Serviço compartilhado depois


🧩 Embedded vs External — A Guerra dos Módulos

🧱 Embedded (Contained)

✔ Dentro do mesmo source
✔ Compilado junto
✔ Uso local

MAIN
└─ SUB-A (no mesmo arquivo)

🌐 External

✔ Fonte separado
✔ Compilado independente
✔ Reutilizável

👉 Padrão dominante nas empresas.


🏦 Curiosidade real

Alguns subprogramas bancários:

💰 Executam bilhões de vezes
📅 Estão em produção há décadas
🧠 São mais antigos que muitos programadores


🛑 Como terminar um programa corretamente?

Padawan, memorize isso:

ComandoSubprogramaMain Program
GOBACKRetornaEncerra
EXIT PROGRAMRetorna❌ Não usar
STOP RUN💀 Mata tudoEncerra

⚠️ Easter Egg #3 — O botão nuclear

Um STOP RUN dentro de um subprograma compartilhado pode derrubar:

💥 Transações online
💥 Jobs batch inteiros
💥 Sistemas críticos

Sim, já aconteceu.


📡 Comunicação entre Programas — Três níveis de poder

🟦 Local

Só dentro do programa.

👉 Padrão.


🌍 Global

Programa + subprogramas embutidos.


🌐 External

Todos os programas da run unit.

👉 Use com extremo cuidado.


⚠️ Regra de Ouro Corporativa

Prefira parâmetros explícitos a variáveis globais.

Isso é engenharia profissional.


📥 RETURNING — O modo “função moderna”

Alguns compiladores permitem retorno explícito:

CALL "SUB"
USING IN-DATA
RETURNING OUT-DATA

Subprograma:

PROCEDURE DIVISION USING IN-DATA
RETURNING OUT-DATA.

💎 Menos comum, mas elegante.


🏦 Padrão real de mercado

Quase sempre:

CALL "SERVICO"
USING REQUEST-BLOCK
RESPONSE-BLOCK

Porque sistemas grandes preferem estruturas completas.


🧪 Passo a passo para criar um subprograma robusto

1️⃣ Defina interface clara (LINKAGE)

2️⃣ Use estruturas, não campos soltos

3️⃣ Documente a ordem dos parâmetros

4️⃣ Use GOBACK

5️⃣ Evite GLOBAL/EXTERNAL sem necessidade

6️⃣ Teste isoladamente


💎 Easter Egg Final — O verdadeiro poder do COBOL

Subprogramação é a razão pela qual:

🏦 Bancos não param
✈️ Sistemas de reserva funcionam
📊 Processamento massivo é possível
🕰️ Código sobrevive por décadas


☕ Mensagem do Mestre para o Padawan

Se você dominar subprogramação COBOL, você deixa de ser apenas um programador.

Você se torna:

🏛️ Um arquiteto de sistemas críticos

Porque o mainframe não é sobre código pequeno.

É sobre:

👉 Confiabilidade
👉 Desempenho
👉 Longevidade
👉 Engenharia disciplinada

quinta-feira, 5 de fevereiro de 2026

🔥 VOCÊ PROGRAMA EM COBOL… MAS NÃO FAZ IDEIA DO MONSTRO QUE ESTÁ RODANDO POR TRÁS 😳

 

Bellacosa Mainframe apresenta o Hardware Mainframe 

🔥 VOCÊ PROGRAMA EM COBOL… MAS NÃO FAZ IDEIA DO MONSTRO QUE ESTÁ RODANDO POR TRÁS 😳

O guia que separa quem “codifica” de quem realmente ENTENDE o z/OS

Se você é dev COBOL e acha que seu programa “roda sozinho”…
👉 já começa errado.

O que você chama de execução é, na verdade, um balé absurdo entre hardware, sistema operacional e estruturas invisíveis que decidem se seu job vive… ou morre 💀

Esse artigo é o mapa mental que o curso da IBM tenta te dar — mas agora no estilo Bellacosa Mainframe raiz.


🧠 O MÓDULO INTRODUTÓRIO (o verdadeiro objetivo)

O curso não quer te ensinar comando.

Ele quer te ensinar a pensar assim:

“Se algo deu errado… quem está envolvido por trás?”

Segundo o próprio material do curso, a ideia é te dar uma visão conectada do sistema, não isolada


🔥 Tradução direta:

Você deixa de ser:

  • 👶 Dev que roda JOB

E vira:

  • 🧠 Engenheiro que entende o ecossistema

⚙️ O QUE VOCÊ PRECISA SABER ANTES (pré-requisitos reais)

Se você quer extrair valor desse curso, precisa de base em:

🧩 Conceitos obrigatórios:

  • Address space
  • Multiprocessing
  • Virtual storage
  • Interrupts
  • Dispatcher
  • SVC

👉 Tudo isso é citado como base necessária


💡 E o segredo que ninguém te conta:

Você NÃO precisa dominar tudo…

Mas precisa entender quem manda em quem.


🧬 O MAPA DO UNIVERSO MAINFRAME

Vamos simplificar o que o curso espalha em vários vídeos:

z/Architecture → define regras
z System → implementa hardware
z/OS → controla execução
Seu COBOL → obedece tudo isso

🔥 Frase pra tatuar na testa:

“COBOL não executa… ele é executado.”


🧠 z/Architecture — O DNA DO SISTEMA

A arquitetura define:

  • instruções da CPU
  • registradores
  • interrupções
  • modelo de memória

👉 É o contrato entre hardware e software


🧨 Curiosidade (Easter Egg #1)

Você pode rodar código de 1965 (System/360) hoje.

👉 Isso mesmo.

Backward compatibility absurda.


🖥️ z Systems — A MÁQUINA MONSTRA

Aqui entra o hardware de verdade (ex: z16):

  • até 40 TB de memória
  • centenas de processadores
  • AI dentro do chip 😳

🤖 Easter Egg #2

O z16 tem IA rodando dentro do processador.

👉 Seu COBOL pode estar rodando lado a lado com inferência de IA.


⚡ Processadores (isso cai em prova e vida real)

Não existe só CPU:

  • CP → geral
  • zIIP → offload (DB2, XML)
  • IFL → Linux
  • SAP → I/O

👉 Performance no mainframe é distribuição, não clock.


🧠 z/OS — O CÉREBRO QUE MANDA EM TUDO

O z/OS é:

  • scheduler
  • gerenciador de memória
  • gerenciador de I/O
  • segurança
  • rede

👉 Ele decide:

  • quem roda
  • quando roda
  • por quanto tempo

💀 Easter Egg #3

Seu programa pode estar pronto…

👉 mas fica parado porque o dispatcher não liberou CPU.


🧱 CONTROL BLOCKS — O VERDADEIRO SISTEMA

Aqui está o segredo mais importante de todos:

O z/OS não confia em código… ele confia em estruturas.

Exemplos:

  • TCB → task
  • ASCB → address space
  • PSA → base do sistema

🔥 Regra de ouro:

“Se não está em um control block… não existe.”


⚡ INTERRUPTS — O QUE REALMENTE CONTROLA O FLUXO

Tudo no sistema muda por interrupção:

  • I/O terminou
  • erro aconteceu (S0C4 👀)
  • tempo acabou

💡 Tradução Bellacosa:

Interrupt é o “plot twist” do sistema.


🔍 COMO UM DEV COBOL DEVE ESTUDAR ISSO?

Aqui entra o ouro.


🚀 PASSO 1 — Pare de pensar só no código

Quando rodar um programa, pergunte:

  • em qual address space estou?
  • quem é meu TCB?
  • estou em WAIT ou RUN?

🔥 PASSO 2 — Comece pelo visível

Ferramentas:

  • SDSF → ver jobs
  • ISPF → ambiente
  • JES → fila

🧠 PASSO 3 — Evolua pro invisível

  • IPCS (dump)
  • control blocks
  • PSW / registers

💀 PASSO 4 — Aprenda com erro

Nada ensina mais que:

  • S0C4
  • S0C7
  • loops infinitos

🧨 DICAS DE OURO (nível Bellacosa)

💡 Dica 1

Quando travar:

não pergunte “o que meu código fez?”
pergunte “o que o sistema fez com meu código?”


💡 Dica 2

Aprenda registradores:

  • R13 → cadeia
  • R14 → retorno
  • R15 → entrada

💡 Dica 3

Leia dump mesmo sem entender tudo.

👉 Com o tempo, você começa a “enxergar o sistema”.


🤯 CURIOSIDADES QUE EXPLODEM A MENTE

🧨 1. Seu programa não controla nada

Tudo é mediado pelo z/OS.


🧨 2. I/O é mais importante que CPU

Mainframe é I/O-driven.


🧨 3. Rede pode nem existir

Com HiperSockets, comunicação é memória ↔ memória.


🧨 4. Segurança é hardware

Criptografia roda direto no chip.


🎯 RESUMO FINAL

Se você entendeu isso, você mudou de nível:

✔ Código é só uma parte

✔ Sistema decide tudo

✔ Hardware influencia tudo

✔ Control blocks são a verdade

✔ Interrupts mandam no fluxo


💥 FRASE FINAL (pra fechar com estilo)

“Você não programa em COBOL…
você negocia com o z/OS pra ele deixar seu programa existir.”