🔥 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

 

Bellacosa Mainframe apresenta o Trace no REXX

💣🧠 “TRACE ?R”: O SUPERPODER SECRETO DO REXX QUE TRANSFORMA DEBUG EM INVESTIGAÇÃO FORENSE 🧠💣

Quando um EXEC entra em colapso no z/OS… o verdadeiro programador não entra em pânico. Ele ativa o TRACE.

---

Existe um momento na vida de todo profissional Mainframe em que o EXEC começa a agir como entidade paranormal.

Você roda o REXX.

Ele:

• não dá ABEND,
• não retorna RC,
• não mostra erro,
• não funciona,
• e ainda imprime uma mensagem que parece saída de um ritual obscuro do ISPF.

Você olha para a tela.

A tela olha para você.

E naquele instante nasce a pergunta clássica:

“QUE DIABOS ESSE EXEC ESTÁ FAZENDO?”

É aí que entra uma das ferramentas mais poderosas já criadas no universo IBM:

⚡ TRACE ⚡

Mas este artigo não é apenas sobre TRACE.

É sobre:

• debugging profissional,
• tratamento de erros,
• SIGNAL,
• RC,
• traps,
• investigação de falhas,
• sobrevivência operacional,
• e a fina arte de impedir que um EXEC destrua sua sanidade mental às 03:17 da manhã em pleno fechamento bancário.

---

🏛️ O DIA EM QUE O REXX DECIDIU NÃO FALHAR

Uma das características mais bizarras — e ao mesmo tempo geniais — do REXX é:

Ele tenta NÃO te atrapalhar.

Isso parece bonito…

ATÉ VIRAR UM PESADELO.

Exemplo clássico:

/* REXX */

salario = 5000
bonus   = 1200

total = salrio + bonus

say total

Você esperaria:

6200

Mas recebe:

SALRIO1200

Sim.

Porque:

• salrio não existe,
• o REXX assume o nome da variável,
• concatena tudo,
• e segue a vida como se nada tivesse acontecido.

O programa não explode.

O programa apenas:

• distorce a realidade,
• corrompe lógica,
• e abre um portal dimensional dentro do TSO.

---

🚨 SIGNAL ON NOVALUE — O “AIRBAG” DO REXX

Todo EXEC profissional deveria começar com:

Signal On Novalue

Sem isso:

• bugs silenciosos vivem entre nós.

Com isso:

• variáveis inexistentes são capturadas imediatamente.

---

🧪 Exemplo Profissional

/* REXX */
Signal On Novalue

nome = "BELLACOSA"

say sobrenome

exit 0

Novalue:
say "ERRO: Variavel nao inicializada!"
say "Linha:" sigl
say sourceline(sigl)
exit 20

Resultado:

ERRO: Variavel nao inicializada!
Linha: 5
say sobrenome

ABSOLUTAMENTE LINDO.

Você:

• identifica o erro,
• localiza a linha,
• entende o problema,
• salva horas de investigação.

---

🕵️ TRACE — O CSI DO MAINFRAME

Agora chegamos ao coração da magia.

Trace R

Essa instrução transforma o EXEC em um documentário criminal.

Você começa a enxergar:

• execução linha por linha,
• resultados intermediários,
• expressões,
• variáveis,
• comandos host,
• fluxo lógico.

---

🔥 Exemplo

/* REXX */
Trace R

a = 10
b = 20
c = a + b

say c

Saída típica:

>>>   "a = 10"
>>>   "b = 20"
>>>   "c = a + b"
>>>   "30"
30

Você literalmente vê o cérebro do EXEC funcionando.

---

👁️ TRACE ?R — O MODO MATRIX DO REXX

Agora prepare-se.

Porque existe algo ainda mais poderoso:

Trace ?R

O ? ativa:

DEBUG INTERATIVO

Sim.

INTERATIVO.

Em pleno ambiente Mainframe.

Tecnologia ancestral da IBM.

---

🤯 O QUE ISSO FAZ?

O EXEC:

• pausa em cada instrução,
• espera comandos,
• permite inspeção dinâmica.

Você pode:

• reexecutar linha,
• alterar variável,
• testar expressão,
• inspecionar ambiente,
• modificar comportamento em tempo real.

---

🧠 Exemplo

Trace ?R

x = 10
y = 30
z = x + y

say z

Durante execução você pode digitar:

say x

E o EXEC responde.

É praticamente um:

• debugger,
• shell,
• laboratório interativo,
• máquina do tempo operacional.

---

☢️ RC — O NÚMERO QUE DEFINE O DESTINO

No Mainframe existe um conceito sagrado:

RETURN CODE

A variável especial:

rc

contém o retorno do último comando host.

---

🎯 Exemplo

"LISTDS USER.INVALID.DATASET"

say rc

Se dataset não existir:

8

---

📜 Convenção clássica IBM

RC	Significado
0	Sucesso
4	Warning
8	Problema provável
12	Falha séria
16	Caos crescente
20	O datacenter está pegando fogo

(Ok… o último é interpretação emocional.)

---

💀 O ERRO MAIS COMUM DOS INICIANTES

Executar comando host…

e IGNORAR o RC.

Exemplo proibido em 37 países:

"ALLOC FI(TESTE) DA('ARQ.INEXISTENTE') SHR"

"EXECIO * DISKR TESTE"

Se ALLOC falhar:

• EXECIO também falha,
• mensagens ficam confusas,
• debugging vira arqueologia.

---

✅ Forma correta

"ALLOC FI(TESTE) DA('ARQ.INEXISTENTE') SHR"

If rc <> 0 Then Do
   Say "Falha na alocacao!"
   Exit 8
End

---

🧨 SIGNAL ON ERROR — O CAÇADOR DE DESASTRES

Outra arma essencial:

Signal On Error

Agora qualquer comando host com RC ruim:

• desvia execução,
• entra no trap,
• permite recovery.

---

🛡️ Exemplo corporativo

/* REXX */
Signal On Error

"DELETE USER.PROD.ARQ"

say "Arquivo removido"

exit 0

Error:
say "Falha no comando host"
say "RC =" rc
say "Linha =" sigl
exit 12

---

🧬 SIGL — A LINHA DO CRIME

A variável:

sigl

contém:

a linha onde o erro ocorreu.

Isso é ouro puro.

---

🧠 SOURCELINE() — A MEMÓRIA FOTOGRÁFICA DO EXEC

Você pode mostrar exatamente a linha problemática:

say sourceline(sigl)

Exemplo:

"DELETE USER.PROD.ARQ"

O EXEC literalmente aponta:

“FOI AQUI.”

---

🏴‍☠️ EASTER EGG MAINFRAME #1

Veteranos de REXX frequentemente usam:

Trace ?R

como se fosse um mini TSO dentro do próprio EXEC.

É quase um:

• “REXXCEPTION”,
• um EXEC rodando dentro do EXEC,
• enquanto você conversa com ele durante a execução.

---

🏴‍☠️ EASTER EGG MAINFRAME #2

Existe uma lenda antiga de operadores que:

• ativavam TRACE,
• esqueciam de desligar,
• geravam SYSOUT gigantesco,
• e enchiam spool JES2 inteiro.

Moral da história:

Trace O

também salva carreiras.

---

🏴‍☠️ EASTER EGG MAINFRAME #3

Programador Mainframe raiz não chama bug de bug.

Ele chama de:

• “anomalia operacional”,
• “comportamento inesperado”,
• “efeito colateral do ambiente”,
• ou:

“funciona em produção.”

---

⚙️ O VERDADEIRO ENSINAMENTO

Debugging não é apenas corrigir erros.

É:

• entender fluxo,
• prever falhas,
• construir resiliência,
• escrever automações seguras,
• proteger produção,
• facilitar manutenção futura.

---

🏛️ O MAINFRAME NÃO PERDOA DESCUIDO

Um EXEC mal escrito pode:

• apagar datasets,
• travar usuários,
• consumir spool,
• quebrar automações,
• causar RC cascata em batch,
• gerar incidentes gigantescos.

Por isso programadores experientes:

• validam RC,
• usam SIGNAL,
• usam TRACE,
• documentam tudo,
• tratam exceções.

---

🚀 CONCLUSÃO

REXX parece simples.

Mas por trás da simplicidade existe uma linguagem:

• elegante,
• introspectiva,
• extremamente poderosa,
• absurdamente avançada para sua época.

E quando você domina:

• TRACE,
• SIGNAL,
• RC,
• NOVALUE,
• SOURCELINE,
• SIGL,

você deixa de apenas “escrever scripts”.

Você começa a construir:

automações enterprise-grade dignas do universo z/OS.

Porque no fim…

o verdadeiro programador Mainframe não teme o erro.

Ele:

• captura,
• analisa,
• documenta,
• trata,
• e transforma caos operacional em engenharia confiável.

💙🖥️🚀

 

Bellacosa Mainframe homenageia Grace Hopper

Um Café no Bellacosa Mainframe

2,168 subscribers

Homenagem a Incrível Grace

Bellacosa Mainframe

4,424 followers

July 16, 2025

• #Desperte o potencial
• #Marketing Digital

Dia 9 - Homenagem a Incrível Grace

Dia 9 - Pesquise e escreva sobre uma inspiração na área de tecnologia e por que essa pessoa é uma inspiração para você.

Homenagem a Grace Hopper

Bem-vindo jovem padawan, hoje irei falar sobre a mestra das mestras Jedi, aquele que foi a mãe de todos os Analistas de Sistemas e programadores, tudo o que fazemos hoje, devemos fazer um agradecimento a esta mulher. Uma programadora impar, a mais famosa DEV da história e como ela ajudou a criar uma das primeiras linguagem de alto nível. Senta que la vem historia.

Num próximo artigo irei falar dos primeiros computadores criados la longe no século XIX e seu complicados programas em linguagem de máquina e cartões perfurados e se não fosse a Grace ainda estávamos com esses cartões.

Introdução

O primeiro computador ou contador foi criado por Hollerith e usava cartões perfurados para funcionar, sendo muito difícil a sua codificação, com a evolução das indústrias e a necessidade de computação os computadores evoluíram drasticamente. Mas um evento obrigou o mundo a automatizar e aumentar a rapidez.

Este evento foi a Segunda Guerra Mundial, mas por que uma guerra necessita de computadores? Primeiro imagine a logística de enviar suprimentos para milhares de soldados em centenas de campos de batalha? Calcular as baixas e os recrutamentos? Pagar os salários?

Um trabalho hoje extinto, mas num passado não tão distante, existiam os computadores humanos, pessoas com grandes habilidades em cálculo, numa época em que calculadoras mecânicas eram caras.

Então uma das suas funções mais importante era o cálculo das tabelas de balísticas. Sim jovem padawan imagine que antigamente os artilheiros e operadores de canhões e baterias de artilharia precisavam de tabelas ou tabuas com cálculos dos alvos, conforme o local onde estavam tinham as coordenadas tipo potencia, angulo e distância.

Imagine-se no meio de uma batalha, aquele caos ninguém terá tempo de calcular corretamente a posição, por isso existiam tabelas pré-calculadas com essa informação.

Nos quartéis existiam centenas de matemáticos nessa tarefa, os melhores eram envolvidos em projetos de espionagem, criando tabelas de criptografia para esconder as mensagens inimigas.

Mas onde entra a admirável Grace nisto tudo?

No esforço de guerra, todo se voluntariaram para lutar e Grace Hopper queria chutar a bunda dos nazistas, deslocando-se ao centro de alistamento da Marinha como voluntaria, porem foi considerada velha para o combate, mas como era professora de Matemática.

Foi convidada para servir na retaguarda, mais precisamente na NAVY RESERVES, afinal ela PHD em matemática, logo foi envolvida nas equipes de computação. Programando no MARK I e participando do projeto UNIVAC I, criando artigos científicos que auxiliaram muito a evolução dos computadores.

UNIVAC

UNIVAC I (Universal Automatic Computer I)

Um gigante que revolucionou o mundo, era da dimensão de um armário, pesava 13 toneladas e custava entre 1,25 e 1,5 milhões de dólares. Estes são alguns dos fatos mais interessantes sobre o UNIVAC I, o primeiro computador comercial da história entregue ao Departamento do Censo dos Estados Unidos a 31 de março de 1951,

O UNIVAC usava 5 200 válvulas e consumia 125 kW para fazer 1905 operações por segundo, com um clock de 2,25 MHz. O sistema completo ocupava mais de 35 m² de espaço no piso.

Sua memória de mil palavras era armazenada num dispositivo chamado delay line memory, construído com mercúrio e cristais piezoelétricos.

A entrada e saída de informações eram realizadas por uma fita metálica de 1/2 polegada de largura e 400 m de comprimento. Normalmente acompanhados de um dispositivo impressor chamado Uniprinter, que, sozinho, consumia 14 kW.

Pré-história da Codificação

Neste ambiente de mudança e evolução constante, cada empresa queria que seu equipamento e método fossem o padrão, onde ninguém se entendia e fica difícil a troca de conhecimento.

Nisso a nossa Admirável Grace entra em ação, trabalhando na padronização e criação de melhores praticas no uso do computador. Com esse desafio em mãos, ela criou o FLOW-MATIC (Business Language version 0, abreviado B-0) é a primeira linguagem de programação em alto nível, ou linguagem natural, assemelhada ao inglês.

A Flow-matic foi criada e especificada a partir de 1955 por Grace Hopper no Remington Rand para ser usada no primeiro computador comercial UNIVAC I.

COBOL

O grande trabalho de Grace foi ter iniciado a longa trilha que culminou na especificação da linguagem de programação COBOL que durante mais de 6 décadas dominou o mercado de mainframes e passou aos mini e micros computadores.

Gerações de programadores no mundo inteiro trabalharam unicamente com esta linguagem e ainda hoje milhares de código legado funcionam nos CPDs pelo mundo afora.

Conclusão

Neste pequeno artigo fiz a minha justa homenagem a essa mulher que foi a primeira HACKER do mundo, criou a sua própria linguagem de computador, fez o unboxing do UNIVAC I, chutou a bunda de nazistas trabalhando arduamente em codificação.

Chegou ao mais alto grau de distinção da US NAVY, chegando a almirante e ainda tem um navio navegando com seu nome. Entrou para a história criando inúmeros artigos sobre programação e foi pioneira na solução de bugs informáticos.

Por isso fica meu muito obrigado admirável Grace, fabulosa, fantástica a mãe de todos os DEVS.

Espero ter ajudado. Bom curso a todos.

Mais momento jabá, entrevista para a ITV exposição primavera e suas flores, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=IqmW8rWqmx8

Bom curso a todos.

https://www.linkedin.com/in/vagnerbellacosa/

https://github.com/VagnerBellacosa/

#Desafio21DiasNaDIO

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa