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

 

terça-feira, 2 de julho de 2019

☕💥 A Jornada do Padawan COBOL – Parte 7 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe explica o CALL em COBOL Parte VII

☕💥 A Jornada do Padawan COBOL – Parte 7

Desvendando o Universo dos CALLs no Mainframe

BALR, BASR, BASSM, SVC, PC, TCB, SRB, Cross Memory, zIIP e os Segredos dos Sysprogs Jedi do IBM Z

Ou como descobrir que, por trás de um simples CALL COBOL, existe um universo de instruções Assembly capaz de processar bilhões de transações por dia

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que COBOL é apenas uma ilusão confortável

Até agora descobrimos:

✔ Static CALL

✔ Dynamic CALL

✔ Binder

✔ LE

✔ CICS

✔ APIs

✔ MQ

✔ REST

Mas existe algo que poucos desenvolvedores COBOL enxergam.

Quando você escreve:

CALL 'SUBPGM'

O hardware IBM Z não entende COBOL.

Ele entende.

Instruções Assembly

E é aqui que começa a verdadeira aventura.


O que existe por trás do CALL

Imagine:

Programa COBOL

Compilador

LE

Assembler

CPU z16


O processador executa algo semelhante a:

BALR R14,R15

ou

BASR R14,R15

BALR

Branch and Link Register

O avô do CALL.


Exemplo

BALR 14,15

O que faz?

Salva endereço retorno.

Desvia execução.


Visualmente


MAIN


00010000


BALR


↓


SUBPGM


00025000


EXECUTA


RETORNA




BASR

Mais moderno.


Branch and Save Register


Mesmo conceito.

Melhor otimização.


BASSM

Território Jedi.

Poucos entram.


Branch And Save And Set Mode


Troca modo.

24 bits.

31 bits.

64 bits.


Exemplo

BASSM R14,R15

Por que existe?

Compatibilidade.

Programas antigos.

AMODE mistos.


O conceito de Supervisor

Padawan acredita.

Programa faz tudo.

IBM sorri.


Usuário

não faz quase nada.


Sistema faz.


SVC

Supervisor Call


Programa pede ajuda.


Exemplo

SVC 99

Sistema operacional assume.

Executa.

Retorna.


Exemplos famosos

SVC 13

ABEND


SVC 99

Dynamic Allocation


SVC 19

OPEN


O Program Call

PC Instruction


Mais rápido.

Mais seguro.

Cross Memory.


Muito usado por:

RACF

DB2

JES2

SAF


Cross Memory

Território dos Sysprogs.


Endereço A

fala com

Endereço B


Visualmente


USER SPACE


↓


PC


↓


DB2 SPACE


↓


RETORNA



TCB

Task Control Block


Representa.

Uma tarefa.


CICS

Muitos TCBs.


Batch

Normalmente um.


SRB

Service Request Block


Mais leve.

Mais rápido.


Menos overhead.


Muito usado.

RMF

SMF

DB2


TCB versus SRB

CaracterísticaTCBSRB
PesoMédioLeve
CPUNormalMelhor
WAITSimNão
PerformanceBoaExcelente

zIIP

O sonho do financeiro.


Specialty Engine


Pode executar:

XML

Java

MQ

DRDA

REST

Analytics


CPU geral agradece.


HiperDispatch

Poucos conhecem.

IBM adora.


Mantém afinidade.

CPU cache.


Melhora latência.


LE Internals

Language Environment.


Controla.

Heap

Stack

Condition Handler

Exceptions

Threads

Storage


O Condition Handler

Exemplo

ON EXCEPTION

LE intercepta.

Processa.

Retorna.


Como nasce um S0C4

Programa

CALL

LE

Assembler

PSW

Address Exception

ABEND


O PSW

Program Status Word


Coração do processador.


Guarda

Modo

Estado

Máscaras

Endereço


IPCS mostra.


Registradores

IBM Z possui

16 registradores


R14

Retorno


R15

Entrada


R13

Save Area


Veteranos decoram.


Save Area

Mágica antiga.


Assembler

STM 14,12,12(13)

Salva contexto.


Retorna depois.


Porque COBOL parece mágico

O compilador faz.

Tudo isso.

Automaticamente.


Padawan escreve

CALL 'PAGTO'

IBM executa.

Milhares.

De instruções.


Dicas Bellacosa

Dica 1

Nunca ignore PSW.


Dica 2

Aprenda registradores.


Dica 3

Entenda LE.


Dica 4

Conheça SVC99.


Dica 5

Estude TCB.


Dica 6

SRB é ouro.


Dica 7

zIIP economiza dinheiro.


Easter Egg Mainframe

Existe um grupo de profissionais.

Que olha isto.

BALR 14,15

E imediatamente sabe.

AMODE.

RMODE.

PSW.

TCB.

Offset.

Storage Key.

Cross Memory.

PC Bit.

SRB.


São conhecidos pelos desenvolvedores COBOL como:

Os Sysprogs Jedi


Checklist Jedi da Parte 7

✅ Entender BALR

✅ Entender BASR

✅ Conhecer BASSM

✅ Saber SVC99

✅ Estudar LE

✅ Aprender TCB

✅ Aprender SRB

✅ Conhecer Cross Memory

✅ Entender PSW

✅ Conhecer IPCS

✅ Aproveitar zIIP

✅ Ler Assembly sem medo


A Filosofia Jedi do CALL – Parte 7

O Padawan iniciante acredita:

COBOL chama COBOL.

O desenvolvedor intermediário pensa:

COBOL usa LE.

O especialista entende:

COBOL é uma linguagem elegante construída sobre décadas de engenharia do z/Architecture, Assembly, supervisão do z/OS e mecanismos extremamente otimizados de gerenciamento de contexto.

E o Mestre Mainframe compreende algo ainda mais profundo:

Um simples CALL 'SUBPGM' é apenas a ponta visível de uma cadeia tecnológica refinada ao longo de mais de cinquenta anos, permitindo que um IBM Z execute bilhões de instruções por segundo com níveis de disponibilidade, segurança e eficiência que ainda hoje servem de referência para toda a indústria.


Próxima aventura do Padawan COBOL – Parte 8

"As Últimas Runas do Mainframe: DLLs Avançadas, Metal C, Callable Services, SAF, RACF, PC-Bit, APF, Dataspaces, Hiperspaces, Coupling Facility e os segredos que poucos profissionais IBM Z dominam."