Translate

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

domingo, 29 de março de 2026

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI! O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

 

Bellacosa Mainframe fala sobre z/OS system Service Structure

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI!
O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀


Se você é dev COBOL raiz, daqueles que já tomou S0C7 no café da manhã e resolveu com dump na unha… segura essa:

👉 Existe uma camada no z/OS que você usa o tempo todo…
👉 Mas quase ninguém entende de verdade…
👉 E ela decide TUDO — do I/O ao ABEND.

Bem-vindo à z/OS System Services Structure.


🧠 O QUE É ESSA TAL DE STRUCTURE?

Pensa no z/OS como uma cidade:

  • Você (COBOL) → é o cidadão
  • JCL → é o pedido formal
  • JES2 → é o correio
  • E o System Services?
    👉 É a prefeitura, polícia, energia, trânsito e bombeiros… TUDO JUNTO.

É a estrutura que fornece serviços fundamentais como:

  • Gerenciamento de tarefas (Task Management)
  • Comunicação entre programas
  • Gerenciamento de memória
  • I/O (entrada/saída)
  • Tratamento de erros (ABENDs 👀)

⚙️ A ESTRUTURA NA PRÁTICA (SEM MIMIMI)

Aqui entra o coração técnico que muita gente ignora:

🔹 Control Blocks (os “documentos secretos”)

  • TCB (Task Control Block) → representa uma task
  • ASCB (Address Space Control Block) → representa o espaço de endereçamento
  • RB (Request Block) → encadeamento de chamadas

💡 Easter egg:
Se você já viu um dump com “TCB=…” e ignorou…
👉 você literalmente ignorou o “RG” da sua task.


🔹 Dispatcher (o maestro invisível)

  • Decide qual task roda
  • Gerencia prioridade
  • Alterna contexto

💬 Comentário Bellacosa-style:

“Se seu programa está ‘lento’, talvez o problema não seja o COBOL…
é o dispatcher dizendo: calma campeão, tem fila 😎”


🔹 SVC (Supervisor Call)

  • Porta de entrada para serviços do sistema
  • Tudo passa por aqui

👉 Quando seu COBOL faz I/O, quem resolve não é ele…
é o z/OS via SVC.

💡 Curiosidade:
SVC é tipo syscall no Linux… só que com terno e gravata 👔


💥 ONDE ISSO TE PEGA (E VOCÊ NEM SABIA)

Se liga nesses cenários:

  • ABEND estranho sem causa aparente
  • Programa “travando” sem loop
  • I/O lento do nada
  • Problemas intermitentes

👉 90% das vezes… está ligado ao System Services, não ao seu código.


🧩 COMO TUDO SE CONECTA (VISÃO RAIZ)

Fluxo simplificado:

  1. Seu COBOL executa
  2. Precisa de recurso (I/O, memória, etc)
  3. Chama um serviço via SVC
  4. System Services aciona control blocks
  5. Dispatcher decide quando executar
  6. Resultado volta pra sua aplicação

👉 Se algo falhar nesse caminho…
💥 ABEND na sua cara


🧠 GUIA DE ESTUDO (MODO GUERREIRO MAINFRAME)

Se você quer sair do nível “codador” e virar engenheiro de verdade, estude isso:

📚 Ordem sugerida:

  1. Address Spaces (ASID, ASCB)
  2. TCB e SRB
  3. Dispatcher e prioridades
  4. SVCs mais comuns
  5. Gerenciamento de memória (GETMAIN/FREEMAIN)
  6. Dump reading (IPCS)

🧪 Dica prática (ouro puro 💰)

Pegue um dump real e procure:

  • TCB atual
  • PSW
  • Última SVC chamada

👉 Isso é mais valioso que 10 cursos teóricos.


🕵️‍♂️ EASTER EGGS QUE POUCA GENTE SABE

💣 1. COBOL NÃO CONTROLA NADA
Quem controla é o z/OS. Seu programa só pede.


💣 2. ABEND NÃO É ERRO — É DECISÃO
O sistema decidiu parar você.
👉 E sempre tem motivo.


💣 3. TUDO É BLOCO ENCADEADO
z/OS é basicamente um grande “linked list corporativo” 😂


💣 4. PERFORMANCE NÃO É SÓ CÓDIGO
Pode ser prioridade de TCB, dispatching, ou contenção.


🚀 FRASE PRA LEVAR PRA VIDA (E PRO LINKEDIN 😎)

“Quem não entende System Services no z/OS…
não depura problema — só apaga incêndio.”


🔥 CONCLUSÃO (SEM ENROLAR)

Se você:

  • Só olha código COBOL → você vê a superfície
  • Entende System Services → você vê o sistema inteiro

👉 E é aqui que mora a diferença entre:

  • Programador
    vs
  • Especialista em Mainframe

domingo, 8 de fevereiro de 2026

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳 O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

 

Bellacosa Mainframe em uma viagem ao Addressability do z/os

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳

O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

Você acha que seu COBOL acessa memória direto?

👉 Não acessa.

No mainframe, nada é direto.
Tudo passa por:

  • tradução
  • autorização
  • tabelas
  • registradores
  • controle do sistema

Se você não entende isso…
👉 você nunca vai dominar dump, performance ou abend 💀


🧠 O QUE É ADDRESSABILITY (SEM ENROLAR)

Addressability é:

a capacidade de um programa acessar dados — onde quer que eles estejam


💡 Tradução Bellacosa

“Addressability é o GPS + chave + autorização da memória.”


⚙️ 1. DISPATCHING WORK — ONDE TUDO COMEÇA

Quando sua task roda:

  • dispatcher escolhe
  • CPU assume
  • CR1 é carregado

👉 CR1 aponta para o address space ativo


🔥 Insight

CR1 define “qual mundo você está enxergando”


🌍 2. VIRTUAL STORAGE — O UNIVERSO NÃO É REAL

Cada usuário tem:

👉 seu próprio universo de memória


🔹 Características:

  • até 16 exabytes 😳
  • isolado
  • protegido

💡 História

MVS = Multiple Virtual Storage

👉 desde os anos 70 já fazia isso


🧨 Easter Egg

Você acha que está acessando memória real…

👉 está acessando endereço virtual traduzido


🧩 3. ADDRESS SPACE — SUA “BOLHA”

Tudo roda dentro de:

👉 um address space


🔹 Tipos:

  • Batch
  • TSO
  • Started Task

💡 Insight

cada programa vive isolado


🔗 4. CROSS MEMORY — QUEBRANDO A BOLHA

Mas… o sistema permite sair dela.


🔹 O que é?

Acessar outro address space


🔥 Exemplo real

COBOL → chama serviço → DB2 → retorna

👉 são address spaces diferentes


💡 Estados:

  • Home → origem
  • Primary → execução
  • Secondary → dados

🧨 Curiosidade

Se são diferentes:

👉 você está em cross-memory mode


🚀 5. PROGRAM CALL (PC) — O TELEPORTE DO z/OS

🔹 O que faz?

  • troca de address space
  • mantém controle
  • permite retorno

🔥 Fluxo real

User → LLA → VLF → módulo → volta

👉 tudo invisível


💡 Tradução

PC é um “portal controlado”


🧱 6. LINKAGE STACK — A MEMÓRIA DA EXECUÇÃO

Sempre que um programa chama outro:

👉 estado é salvo automaticamente


🔹 Salva:

  • registradores
  • PSW
  • access registers

💡 Vantagens

  • menos erro
  • suporte a reentrância
  • debug mais limpo

🧨 Curiosidade

Substitui os antigos save areas


⚙️ 7. ACCESS REGISTERS — O PODER ESCONDIDO

🔹 O que são?

  • 16 registradores
  • permitem acessar outros espaços

🔥 Funcionamento

AR → qual espaço
GR → qual dado

💡 Tradução Bellacosa

AR = endereço do universo
GR = endereço dentro do universo


🧠 8. ACCESS LIST / ALET / ALE — CONTROLE DE ACESSO

Nada é livre.


🔹 Processo:

  1. obter S-token
  2. ALESERV
  3. criar ALE
  4. gerar ALET
  5. carregar AR

💡 Insight

acesso exige autorização formal


🧨 Curiosidade

Sem isso:

👉 proteção de memória bloqueia acesso


⚡ 9. ADDRESSABILITY MODES

🔹 AMODE

  • 24-bit
  • 31-bit
  • 64-bit

🔹 RMODE

  • onde o programa carrega

💡 História

Compatibilidade com décadas de software


🔄 10. PASSO A PASSO COMPLETO

Task é despachada

CR1 define address space

Programa executa

Se precisar:
→ PC (outro space)
→ AR (outro data space)

Linkage stack salva estado

Retorno

💀 ONDE ISSO APARECE NA VIDA REAL?

🔥 Dump (IPCS)

Você vê:

  • PSW
  • registers
  • ARs
  • linkage stack

🔥 Abend clássico

👉 S0C4 = erro de addressability


🔥 Performance

  • cross memory custa
  • LPA melhora

🧨 CURIOSIDADES (NÍVEL JEDI)

🤯 1. Um programa pode acessar vários universos ao mesmo tempo


🔥 2. Memória é totalmente virtual


💀 3. Um erro de ponteiro quebra tudo (S0C4)


🧠 4. O sistema controla TUDO via tabelas


🎯 RESUMO FINAL

✔ Addressability = acesso controlado

✔ Address space = isolamento

✔ Cross memory = comunicação

✔ PC = chamada entre espaços

✔ AR = acesso avançado

✔ Linkage stack = estado


💥 FRASE FINAL

“No mainframe, memória não é um lugar… é um privilégio concedido pelo sistema.”