✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
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ística
TCB
SRB
Peso
Médio
Leve
CPU
Normal
Melhor
WAIT
Sim
Não
Performance
Boa
Excelente
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."
Bellacosa Mainframe apresenta o ibm mainframe parte vi
☕ Um Café no Bellacosa Mainframe
Capítulo VI — O Grande Maestro Invisível
O Supervisor do z/OS: Quem Realmente Comanda a Nave?
TERCEIRA REGRA DAS GRANDES CIVILIZAÇÕES
Se você entrar na ponte de comando de uma gigantesca nave espacial e encontrar todos gritando ao mesmo tempo...
...corra.
Porque alguém perdeu o controle.
Agora imagine uma nave com:
cinco milhões de passageiros;
centenas de milhares de robôs;
milhares de laboratórios;
dezenas de hangares;
milhões de mensagens por segundo.
Mesmo assim...
Tudo funciona em perfeita ordem.
Quem organiza tudo isso?
Um personagem quase invisível.
Ele nunca aparece nas propagandas.
Nunca recebe prêmios.
Nunca é lembrado quando tudo funciona.
Mas basta ele falhar...
...e toda a galáxia entra em pânico.
Seu nome é:
Supervisor.
Bem-vindo ao cérebro do z/OS.
O Mito do Sistema Operacional
Quando um Padawan COBOL ouve falar em sistema operacional, normalmente imagina algo parecido com Windows.
Uma área de trabalho.
Ícones.
Mouse.
Papel de parede.
Lixeira.
O z/OS sorri discretamente.
Porque ele nunca foi criado para ser bonito.
Foi criado para manter bancos funcionando às três horas da manhã.
Enquanto você dorme.
Imagine uma Cidade Planetária
Esqueça computadores.
Imagine uma cidade que nunca dorme.
Ela possui:
hospitais;
aeroportos;
metrôs;
usinas;
polícia;
bombeiros;
telecomunicações;
bancos;
universidades.
Milhões de pessoas vivem ali.
Todas querem atenção.
Ao mesmo tempo.
Se não existir alguém coordenando tudo...
o caos será inevitável.
Esse coordenador é o Supervisor.
O Maestro Invisível
Imagine uma orquestra com:
200 mil músicos.
Cada um toca um instrumento diferente.
Violinos.
Pianos.
Metais.
Percussão.
Corais.
Agora imagine que ninguém pode parar.
Nunca.
Quem garante que todos toquem em perfeita sincronia?
O maestro.
O Supervisor do z/OS exerce exatamente esse papel.
Segundo Wilhelm G. Spruth, o Supervisor controla os recursos fundamentais do sistema, administra interrupções, coordena a execução dos programas e fornece os serviços básicos necessários para todo o restante do sistema operacional funcionar.
O Primeiro Ser a Despertar
Quando um IBM Z inicia...
quem acorda primeiro?
Não é o COBOL.
Nem o Db2.
Nem o CICS.
Nem o TSO.
O primeiro a despertar é o núcleo do sistema.
Chamado tradicionalmente de:
Nucleus.
Imagine o reator principal da nave.
Sem ele...
nada acontece.
O Nucleus — O Reator Central
O Nucleus contém os componentes absolutamente essenciais.
Ali vivem rotinas responsáveis por:
gerenciamento de memória;
tratamento de interrupções;
escalonamento;
proteção;
comunicação com hardware;
serviços básicos.
É o coração pulsante do z/OS.
Por isso ele permanece residente em memória durante toda a execução do sistema.
O Grande Mapa da Cidade
Agora imagine uma cidade gigantesca.
Você precisa saber exatamente onde está:
cada prédio.
cada rua.
cada ponte.
cada estação.
No z/OS esse mapa chama-se:
Memória Virtual.
Mas cuidado.
Ela não é apenas um monte de bytes.
Ela é cuidadosamente organizada.
Os Bairros da Galáxia
A memória do z/OS parece uma cidade cuidadosamente planejada.
Existem bairros com funções específicas.
Entre eles:
CSA.
SQA.
LPA.
PLPA.
FLPA.
MLPA.
Cada um possui regras próprias.
Cada um recebe moradores específicos.
Misturar tudo seria como construir um aeroporto dentro de uma biblioteca.
CSA — A Praça Central
CSA significa:
Common Service Area.
Imagine uma enorme praça pública.
Todos podem passar por ela.
Diversos componentes compartilham informações ali.
Mas exatamente por ser compartilhada...
ela precisa ser extremamente protegida.
SQA — A Área Militar
Agora imagine um setor altamente restrito.
Não entram turistas.
Nem curiosos.
Apenas oficiais autorizados.
Esse setor chama-se:
System Queue Area.
Ali ficam estruturas críticas utilizadas pelo próprio sistema operacional.
Qualquer corrupção nessa região pode comprometer toda a nave.
LPA — A Biblioteca Universal
Imagine uma biblioteca gigantesca.
Milhares de pessoas consultam o mesmo livro.
Seria absurdo imprimir uma cópia para cada uma.
No z/OS surgiu uma ideia brilhante.
Carregar apenas uma única cópia.
Todos compartilham.
Essa biblioteca recebe o nome de:
Link Pack Area.
Ela contém módulos amplamente utilizados por diversas aplicações.
Economia de memória.
Maior desempenho.
Mais estabilidade.
Address Spaces — Pequenos Universos Paralelos
Chegamos a um dos conceitos mais fascinantes do Mainframe.
Imagine um gigantesco prédio.
Cada apartamento representa um universo independente.
Os moradores podem decorar como quiserem.
Mover móveis.
Trocar cortinas.
Pintar paredes.
Mas nunca atravessam magicamente para o apartamento vizinho.
Cada apartamento é um:
Address Space.
Segundo Spruth, o z/OS utiliza Address Spaces independentes para isolar aplicações e proteger o sistema, permitindo que milhares de ambientes coexistam simultaneamente.
Por Que Isso É Importante?
Imagine um programa COBOL contendo um erro grave.
Em muitos sistemas antigos...
ele poderia comprometer todo o computador.
No z/OS...
normalmente ele derruba apenas seu próprio universo.
Os vizinhos continuam vivendo normalmente.
Essa é uma enorme diferença filosófica.
Tarefas Dentro das Tarefas
Agora imagine uma universidade.
Cada faculdade possui dezenas de cursos.
Cada curso possui centenas de alunos.
No z/OS ocorre algo semelhante.
Dentro de um Address Space existem:
Tasks.
Subtasks.
TCBs.
SRBs.
É uma organização hierárquica extremamente eficiente.
Dispatcher — O Controlador de Tráfego
Imagine um aeroporto.
Dezenas de aviões querem pousar.
Centenas desejam decolar.
Quem decide?
A torre.
No z/OS ela chama-se:
Dispatcher.
Sua missão é extremamente simples.
Escolher:
quem executa.
quando executa.
quanto tempo executa.
Depois passa a vez ao próximo.
Spruth descreve o Dispatcher como o responsável por distribuir o tempo de CPU entre as diferentes unidades de trabalho do sistema.
Scheduler — O Mestre das Filas
Agora imagine um restaurante gigantesco.
Milhares de pedidos chegam.
Quem organiza a cozinha?
O Scheduler.
No z/OS ele coordena prioridades.
Urgências.
Dependências.
Recursos.
Nada acontece por acaso.
Interrupções — O Telefone Vermelho
Imagine que durante uma missão alguém aperta um botão de emergência.
O comandante interrompe imediatamente a conversa.
Primeiro resolve a emergência.
Depois continua.
As interrupções funcionam exatamente assim.
Elas avisam ao Supervisor que algum evento importante ocorreu.
Disco terminou.
Rede respondeu.
Timer expirou.
Erro aconteceu.
O Supervisor reorganiza tudo em microssegundos.
Problemas Também Entram na Fila
Curiosamente...
até os problemas seguem regras.
Quando ocorre um erro:
o Supervisor registra.
analisa.
protege o restante do sistema.
gera informações para diagnóstico.
Nada acontece de forma aleatória.
Até o caos é organizado.
O Sistema Nunca Para de Observar
Enquanto aplicações trabalham...
o Supervisor acompanha continuamente:
uso de CPU.
uso de memória.
I/O.
esperas.
prioridades.
contenção.
É como um comandante observando milhares de painéis simultaneamente.
O Tempo Compartilhado
Um iniciante costuma perguntar:
"Como milhares de programas executam ao mesmo tempo?"
A resposta curta é:
eles não executam exatamente ao mesmo tempo.
O Supervisor alterna entre eles tão rapidamente que nosso cérebro percebe continuidade.
É como assistir a um filme.
Na verdade...
você está vendo dezenas de fotografias por segundo.
Quando Tudo Parece Simultâneo
Imagine um mágico lançando:
vinte bolas.
Nenhuma cai.
O segredo?
Ele sabe exatamente quando mover cada mão.
O Dispatcher faz algo parecido.
Troca rapidamente de contexto entre milhares de tarefas.
Resultado?
Todos acreditam possuir a CPU inteira.
O Supervisor Nunca Dorme
Mesmo durante períodos aparentemente tranquilos...
ele continua trabalhando.
Verificando timers.
Tratando interrupções.
Liberando memória.
Gerenciando filas.
Coordenando recursos.
Ele é o único tripulante que jamais abandona a ponte de comando.
O Que Mudou Desde 2010?
Desde que Spruth escreveu seu relatório, o Supervisor do z/OS evoluiu significativamente.
Hoje convivemos com:
processadores multicore muito maiores;
integração profunda com virtualização PR/SM;
Workload Manager extremamente sofisticado;
suporte ampliado para Java, Linux e containers;
automação inteligente;
observabilidade em tempo real;
integração com APIs REST;
inteligência artificial auxiliando diagnósticos.
Mas sua missão continua exatamente igual:
garantir ordem em meio ao caos.
A Filosofia dos Grandes Comandantes
Existe uma lição escondida aqui.
O Supervisor nunca tenta fazer tudo.
Ele coordena.
Distribui.
Organiza.
Confia em especialistas.
Essa talvez seja uma das maiores lições da engenharia.
E também da liderança.
Um bom comandante não pilota todas as naves.
Ele garante que cada especialista faça o melhor trabalho possível.
Curiosidades do Diário de Bordo
🧠 O Supervisor do z/OS permanece ativo durante toda a vida do sistema operacional, coordenando praticamente todos os recursos importantes.
🌌 Address Spaces representam ambientes isolados que permitem enorme estabilidade e proteção entre aplicações.
📚 A Link Pack Area (LPA) evita desperdício de memória compartilhando módulos comuns entre milhares de programas.
🚀 Dispatcher e Scheduler trabalham continuamente para manter equilíbrio entre desempenho, prioridades e utilização eficiente dos recursos.
Diário de Bordo do Padawan COBOL
Antes de deixar a ponte de comando da nave, registre estas coordenadas no seu Holocron Técnico:
✅ Um sistema operacional corporativo é muito mais do que um carregador de programas; ele é o grande coordenador de toda a infraestrutura.
✅ O Supervisor do z/OS atua como um maestro invisível, organizando milhares de atividades simultaneamente sem perder o controle.
✅ O isolamento por Address Spaces é um dos pilares da estabilidade do Mainframe, permitindo que aplicações coexistam com segurança.
✅ Grandes sistemas não sobrevivem porque possuem processadores rápidos. Eles sobrevivem porque existe inteligência coordenando cada microssegundo de sua operação.
Missão Seguinte
No próximo capítulo, embarcaremos em um dos setores mais movimentados de toda a galáxia IBM Z: o JES (Job Entry Subsystem).
Descobriremos por que um simples JCL é, na verdade, um plano de voo interestelar; como milhares de jobs entram em filas sem se atropelar; e por que o JES funciona como a gigantesca torre de controle responsável por sincronizar toda a produção batch do planeta.
Prepare seu cartão perfurado imaginário, revise seu JCL e mantenha sua toalha — e seu café — sempre por perto. Afinal, nossa próxima escala será o coração da produção em lote do universo mainframe.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
