Bellacosa Mainframe apresenta o HLASM

💾🔥 HLASM: O “MICROCÓDIGO HUMANO” QUE DOMA O MAINFRAME — DIRETO DO FERRO PARA A HISTÓRIA 🔥💾

Se tem uma linguagem que não conversa com o sistema… ela conversa com o hardware. E faz isso com elegância brutal. Bem-vindo ao universo do HLASM — onde cada instrução é praticamente um pulso elétrico com intenção.

---

🧬 ORIGEM: DO ASM/360 AO HLASM

A história do HLASM começa lá atrás, com o lendário IBM System/360 (1964). Na época, o assembler era o ASM/360, evoluindo depois para:

• Assembler F
• Assembler H
• Assembler XF
• E finalmente o HLASM

📅 Lançamento do HLASM: década de 1990 (oficialmente por volta de 1992–1994), acompanhando a evolução dos sistemas z/OS

👉 A ideia foi clara:
Manter o poder do assembler, mas adicionar recursos “high level” como:

• macros mais poderosas
• melhor diagnóstico
• estruturação mais legível
• integração moderna com o ambiente z/OS

---

⚙️ O QUE TORNA O HLASM DIFERENTE?

HLASM não é “baixo nível raiz”. Ele é um assembler evoluído, com inteligência embutida.

💡 Destaques:

• Macros sofisticadas (quase uma metalinguagem)
• Controle avançado de fluxo
• Suporte a debug e listagens detalhadas
• Integração com ferramentas modernas IBM
• Performance absurda (nível hardware)

👉 Em resumo:
Você escreve assembler… mas com superpoderes.

---

🏛️ COMPATIBILIDADE: A RELÍQUIA QUE NUNCA MORRE

HLASM mantém compatibilidade com décadas de código legado.

Isso significa:

• Código dos anos 70 ainda roda hoje 😳
• Integra com:
  • CICS
  • DB2
  • IMS
• Funciona perfeitamente nos atuais IBM Z

👉 Isso não é retrocompatibilidade…
É imortalidade corporativa.

---

🧠 FILOSOFIA: QUANDO VOCÊ PENSA COMO O PROCESSADOR

Programar em HLASM é entender:

• registradores
• endereçamento
• instruções de máquina
• pipeline do processador

É quase como conversar direto com a CPU:

“Carregue isso. Compare aquilo. Salte agora.”

Sem intermediários. Sem abstrações.

---

⚔️ HLASM vs ASSEMBLY DO MUNDO PC

Agora começa a parte divertida 😄

🖥️ x86 / x64 (PC, Windows, Linux, macOS)

• Usado em NASM, MASM
• Arquiteturas:
  • 8 bits (8080, 8085)
  • 16 bits (8086)
  • 32 bits (80386)
  • 64 bits (x86-64)

👉 Características:

• Forte dependência de registradores limitados
• Segmentação histórica (16 bits)
• Instruções mais “bagunçadas” (CISC complexo)

---

🧊 HLASM (Mainframe)

• Arquitetura limpa e consistente desde o System/360
• Registradores bem definidos (R0–R15)
• Endereçamento poderoso
• Foco em processamento massivo e confiabilidade

👉 Diferença brutal:

Aspecto	HLASM	x86/x64
Estabilidade	Décadas sem ruptura	Mudanças constantes
Legado	Totalmente preservado	Parcial
Clareza	Alta consistência	Muitas exceções
Performance	Otimizado para I/O e batch	Otimizado para geral

---

🧪 CURIOSIDADES QUE POUCA GENTE SABE

💡 HLASM é usado até hoje em:

• Núcleos bancários
• Sistemas de pagamento
• Processamento de milhões de transações por segundo

💡 Muitas rotinas críticas em COBOL chamam HLASM por baixo

💡 Algumas empresas NUNCA reescreveram seus códigos assembler… só foram evoluindo

💡 HLASM é tão eficiente que às vezes substitui C/C++ em partes críticas

---

🛠️ DICAS DE OURO (ESTILO BELLACOSA 😎)

🔥 1. Aprenda registradores como extensão do seu cérebro
R1 não é número… é propósito.

🔥 2. Domine macros
Macro em HLASM = produtividade + elegância

🔥 3. Leia listagens (LISTING)
É ali que você vira mestre.

🔥 4. Entenda o fluxo de execução real
Branch errado = desastre silencioso

🔥 5. Combine com COBOL
COBOL + HLASM = performance + legibilidade

---

🧾 COMENTÁRIO REALISTA (SEM ROMANTIZAR)

HLASM não é para iniciantes.

Ele exige:

• disciplina
• atenção absurda
• entendimento profundo do sistema

Mas em troca?

👉 Você ganha controle TOTAL.

---

🧠 ANALOGIA FINAL

Se linguagens modernas são:

• Java = carro automático
• Python = carro elétrico
• C = carro manual esportivo

👉 HLASM é:

um caça supersônico com painel analógico.

Você não dirige…
Você pilota.

---

🚀 FECHAMENTO

O HLASM não é só uma linguagem.

É um legado vivo.
Uma ponte entre 1964 e o futuro.
Um lembrete de que, às vezes…

👉 o caminho mais direto ainda é o mais poderoso.

 

Bellacosa Mainframe explica os 31 bits de endereçamento de memoria no IBM MVS

🔥 “31 Bits?! O Bug que Virou Arquitetura: o Segredo Oculto do MVS que Quase Quebrou o Mainframe (e Salvou Tudo)”

Se você chegou até aqui, jovem padawan do aço e silício… prepare-se: essa não é só uma história técnica — é um daqueles momentos em que uma limitação virou genialidade.

Hoje você vai entender por que o MVS roda em 31 bits, mesmo em um mundo que já flertava com 32 bits — e como isso se conecta diretamente com compatibilidade, performance e… um bit que virou lenda. 🧠⚡

---

🧠 O Contexto: Quando 32 bits Ainda Era Ficção Científica Prática

Voltamos para os anos 70/80, época do OS/360 e da evolução para o MVS.

Naquele tempo:

• 24 bits era o padrão (endereçamento até 16 MB 😱)
• A IBM precisava evoluir
• Mas não podia quebrar NADA do que já existia

💡 Tradução Bellacosa:

“Evoluir sem quebrar legado — o esporte olímpico do mainframe.”

---

⚙️ A Chegada dos 32 bits… com um Plot Twist

Quando a IBM decidiu expandir para 32 bits, veio o dilema:

👉 Como crescer sem destruir milhares de aplicações escritas para 24 bits?

A solução foi engenhosa e ousada:

➡️ Usar apenas 31 bits para endereço
➡️ E reservar 1 bit para controle

---

💥 O Bit 0: O Verdadeiro Protagonista

Aqui entra o easter egg mais clássico do mundo mainframe:

O bit mais significativo (bit 0) foi separado para indicar o modo de endereçamento.

📌 Resultado:

Bit 0	Significado
0	Endereço válido (modo 31 bits)
1	Controle especial (ex: retorno de subrotina)

💡 Isso permitia:

• Misturar código 24 bits com 31 bits
• Manter compatibilidade TOTAL
• Evitar crashes catastróficos

---

🧬 O Nascimento do “Modo 31”

O MVS passou a operar em algo híbrido:

• 24-bit mode (legado)
• 31-bit mode (expansão)

E isso foi formalizado em arquiteturas como:

👉 System/370-XA

---

🎮 Exemplo Prático (Estilo Raiz)

Imagine um programa chamando uma subrotina:

BALR  R14,R15

O endereço de retorno fica no registrador com o bit 0 ligado (1).

🔍 Isso significa:

“Ei! Isso não é um endereço comum — é um ponteiro de controle!”

🔥 Resultado:

• O sistema sabe diferenciar código de controle
• Evita confusão com endereços reais
• Permite transições seguras entre modos

---

🧪 Analogias para Padawans

Pense assim:

O MVS usa 31 bits como endereço e guarda o último bit como se fosse um "selo VIP" no ingresso 🎟️

• Sem selo → endereço normal
• Com selo → instrução especial

---

🧠 Por que isso foi GENIAL?

Porque resolveu 3 problemas gigantes de uma vez:

1. 🛡️ Compatibilidade absoluta

Programas antigos continuaram funcionando.

2. 🚀 Expansão de memória

Sai de 16 MB → até 2 GB

3. 🧩 Controle inteligente

O sistema ganhou uma forma de distinguir contextos sem custo extra

---

🐣 Easter Egg que poucos contam

Muitos bugs clássicos em assembler vinham de:

👉 esquecer de limpar o bit 0

Resultado?

💥 Endereço inválido
💥 S0C4 (proteção)
💥 Caos existencial do operador

---

⚡ Comentário Bellacosa Mainframe

Se você acha isso gambiarra…

💬 “No mundo distribuído, isso seria um workaround.
No mainframe… virou ARQUITETURA OFICIAL.”

E mais:

👉 Essa decisão influenciou diretamente o caminho até o 64 bits no z/Architecture

---

🚀 Moral da História

O MVS não é 31 bits por limitação.

Ele é 31 bits por estratégia, elegância e sobrevivência.

Às vezes, a melhor inovação não é avançar tudo…
é avançar sem quebrar nada.

---

🔥 TL;DR para o Padawan Apressado

• MVS usou 31 bits para endereço
• 1 bit virou controle (bit 0)
• Garantiu compatibilidade com 24 bits
• Evitou reescrever o mundo inteiro
• Criou um dos hacks mais elegantes da história da computação 

 

Bellacosa Mainframe explica o endereçamento de memoria no IBM Mainframe 24 31 e 64 bits

📊 “Da Era dos 16MB ao Infinito: A Linha do Tempo que Explica 24 → 31 → 64 bits no Mainframe”

Prepare-se, padawan… agora você vai enxergar a evolução do mainframe como um verdadeiro mapa de poder computacional — cada salto não foi só técnico… foi uma jogada estratégica digna de xadrez. ♟️

---

🟢 1. Era 24 bits — O Mundo Cabia em 16MB

🔹 Contexto

• Arquitetura do OS/360
• Endereçamento: 24 bits
• Limite: 16 MB

🧠 O que isso significava?

• Tudo precisava caber em um espaço minúsculo
• Programas eram ultra otimizados
• Overlays eram comuns (carregar partes do programa sob demanda)

💬 Bellacosa insight:

“Aqui nasceu o DNA da eficiência — cada byte valia ouro.”

---

🟡 2. Era 31 bits — O Hack Mais Elegante da História

🔹 Contexto

• Evolução para o MVS
• Introdução da System/370-XA

⚙️ O que mudou?

• Endereçamento: 31 bits (não 32!)
• Limite: 2 GB
• 1 bit reservado (bit 0) para controle

🔥 O pulo do gato:

• Compatibilidade TOTAL com 24 bits
• Mistura de modos (24 + 31)
• Controle inteligente via bit mais significativo

🧪 Conceito-chave:

O endereço não é só endereço — ele carrega “intenção”

💬 Bellacosa insight:

“Enquanto o mundo queria mais bits… o mainframe queria mais inteligência.”

---

🔵 3. Era 64 bits — O Universo Expandido

🔹 Contexto

• Arquitetura moderna: z/Architecture
• Sistemas como z/OS

🚀 O que mudou?

• Endereçamento: 64 bits
• Limite teórico: exabytes
• Espaço virtual gigantesco

🧠 Novos conceitos:

• Above the bar / below the bar
• Memory objects
• Large memory exploitation

💬 Bellacosa insight:

“Agora não é mais sobre caber… é sobre escalar sem limites.”

---

📊 Timeline Simplificada (Estilo Raiz)

1970s  ───────────────► 24 bits (16 MB)
          OS/360

1980s  ───────────────► 31 bits (2 GB)
          MVS / System/370-XA
          (bit 0 reservado 👀)

2000+  ───────────────► 64 bits (exabytes)
          z/Architecture / z/OS

---

🧬 Conexão Evolutiva (O Segredo por Trás)

Era	Problema	Solução	Filosofia
24 bits	Memória limitada	Otimização extrema	“Faça caber”
31 bits	Crescer sem quebrar	Bit de controle	“Evolua com legado”
64 bits	Escalabilidade	Espaço massivo	“Expanda sem limites”

---

🐣 Easter Egg de Mestre

Mesmo no mundo 64 bits…

👉 O conceito de “compatibilidade com legado” continua vivo
👉 E o espírito do bit 0 ainda ecoa nas decisões de design

💥 Ou seja:

O passado do mainframe nunca foi descartado — ele foi incorporado

---

⚡ Fechamento Estilo Bellacosa

Se você entendeu essa timeline, você desbloqueou algo raro:

🧠 Você não vê mais bits… você vê decisões arquiteturais

Porque no mainframe:

Cada bit tem história
Cada limitação vira estratégia
E cada evolução respeita o passado

 

Bellacosa Mainframe e a linguagem assembler em mainframe o mitico hlasm

☕💣🚀 PADAWAN, O ASSEMBLER NÃO É UMA LINGUAGEM. É O MOMENTO EM QUE VOCÊ PARA DE DISCUTIR COM O COMPUTADOR E COMEÇA A CONVERSAR DIRETAMENTE COM A CPU!

As Lições Ocultas do Curso IBM z/Architecture Assembler Language – Part 2

Existe um momento na vida de todo profissional de Mainframe em que COBOL deixa de ser suficiente.

Não porque COBOL seja limitado.

Não porque o Mainframe seja antigo.

Mas porque surge uma pergunta perigosa:

"O que realmente acontece quando meu programa executa?"

É nesse momento que nasce o interesse pelo Assembler.

O curso IBM EZ341G — z/Architecture Assembler Language Part 2: Machine Instructions — não ensina apenas instruções. Ele ensina como o processador IBM Z pensa.

E isso muda tudo.

---

O Grande Segredo: Tudo é Registrador

Durante o curso inteiro existe uma mensagem escondida:

LH    3,NUM
AR    3,4
CR    3,5
BE    IGUAL

Tudo gira em torno dos registradores.

Quando um programador COBOL escreve:

ADD VALOR-A TO VALOR-B

o compilador transforma isso em dezenas de instruções de máquina.

O processador não entende COBOL.

Não entende Java.

Não entende Python.

Ele entende apenas instruções.

E quase todas elas envolvem registradores.

---

A Regra de Ouro: Se Tem G, Pense em 64 Bits

Uma das maiores pegadinhas do curso é distinguir instruções de 32 e 64 bits.

O padrão da IBM é elegantemente simples:

G = Grande = 64 bits

Exemplos:

LG
LGR
LGFI
AG
AGFI
CG
CGR

Todos trabalham sobre o registrador completo.

Já:

L
A
C
AFI

operam apenas sobre a low half do registrador.

Essa pequena letra "G" aparece em dezenas de questões do exame.

---

O Mistério do Condition Code

O Condition Code é provavelmente o conceito mais importante do curso.

Após uma comparação:

CR  3,4

a CPU grava um valor invisível dentro do PSW.

Esse valor é:

CC=0 Equal
CC=1 Low
CC=2 High

Depois disso:

JE    IGUAL
JL    MENOR
JH    MAIOR

tomam decisões baseadas nesse resultado.

Perceba a beleza do mecanismo.

O processador não executa "IF".

Ele apenas produz Condition Codes.

Todo o resto é interpretação.

---

O Macete 8421

Outro conceito que aparece repetidamente no exame:

8 = Zero
4 = Minus
2 = Plus
1 = Overflow

Esse é o famoso padrão das máscaras de branch.

Por isso:

JZ
JM
JP
JO

são apenas apelidos amigáveis para máscaras numéricas.

Quando você entende isso, dezenas de Extended Mnemonics deixam de ser um problema.

---

Packed Decimal: A Religião Financeira do Mainframe

Se existe uma tecnologia que sobreviveu a todas as modas da computação, é o Packed Decimal.

Enquanto o restante do mundo usa floating point para tudo, bancos continuam confiando bilhões de dólares diariamente em instruções como:

AP
SP
MP
DP
CP

O motivo é simples.

Dinheiro não tolera aproximações.

---

Como Reconhecer um Packed Decimal Válido

Muitos alunos perdem pontos porque esquecem uma regra básica.

Os dígitos devem conter:

0-9

E o último nibble deve conter um sinal:

C
D
F

Exemplos válidos:

123C
123D
550F

Exemplos inválidos:

12AC
00C1
1ABC

Quando isso acontece:

S0C7
Data Exception

O famoso terror dos programadores COBOL.

---

O Verdadeiro Significado do S0C7

Muitos iniciantes acreditam que:

S0C7 = erro de COBOL

Errado.

O S0C7 é um erro da CPU.

Ela tentou executar uma operação decimal e encontrou dados inválidos.

O COBOL apenas estava no lugar errado na hora errada.

---

Multiplicação: Onde Todo Mundo Erra

As instruções:

M
MR
MP

parecem simples.

Mas escondem algumas das regras mais cruéis da arquitetura.

Por exemplo:

MR 2,3

não multiplica R2 por R3.

Na verdade utiliza:

Par R2-R3

e coloca o resultado distribuído entre os dois registradores.

Essa é uma das pegadinhas favoritas da IBM.

---

Divisão: A Arte de Produzir S0CB

A instrução:

DP

é responsável por um dos abends mais famosos do mundo Mainframe:

S0CB
Decimal Divide Exception

Ele ocorre quando:

• O divisor é zero.

• O quociente não cabe no campo de destino.

Ou seja, a CPU está protegendo seus dados.

---

SRP: A Instrução que Parece Magia

Poucas instruções impressionam tanto quanto:

SRP

Shift and Round Packed.

Com ela podemos:

123.95 -> 123
123.95 -> 124
55 -> 5500

Tudo sem realizar multiplicações ou divisões explícitas.

Na prática, SRP é uma calculadora financeira embutida no hardware.

---

ED: O Momento em que o Mainframe Aprende a Falar com Humanos

Packed Decimal é excelente para cálculos.

Mas humanos não gostam de ler:

12345C

É aí que entra:

ED

A instrução EDIT.

Ela transforma números internos em formatos amigáveis:

12.345,67
24.00
999.99

O ED é literalmente a ponte entre o mundo da CPU e o mundo dos relatórios.

---

O Poder das Máscaras

A maioria dos alunos demora para perceber que:

ED

não faz a formatação.

Quem faz é a máscara.

Por isso encontramos padrões como:

20
21
4B
6B
40

onde:

20 = Digit Selector
21 = Significance Starter
4B = Ponto Decimal
6B = Vírgula
40 = Espaço

É um mecanismo brilhante criado décadas antes da maioria das linguagens modernas.

---

O Que o Curso Realmente Ensina

Oficialmente o curso fala sobre:

• LOAD

• STORE

• ADD

• SUBTRACT

• MULTIPLY

• DIVIDE

• COMPARE

• BRANCH

• CHARACTERS

• PACKED DECIMAL

Mas na prática ele ensina algo muito mais profundo.

Ele mostra que toda linguagem moderna, toda API, todo framework e toda aplicação corporativa acabam reduzidos a algumas operações fundamentais:

Mover dados
Somar
Subtrair
Comparar
Desviar
Formatar

O Mainframe apenas faz isso de forma extremamente explícita.

---

Conclusão

☕💣🚀 PADAWAN, quando você aprende Assembler, descobre um segredo que poucos profissionais conhecem.

O computador nunca executou COBOL.

Nunca executou Java.

Nunca executou Python.

Ele sempre executou instruções de máquina.

O Assembler apenas remove o tradutor e permite que você converse diretamente com a arquitetura IBM Z.

E quando isso acontece, você deixa de ser apenas um programador.

Você começa a entender como a própria CPU pensa.

☕💥 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í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 e o primeiro programa cobol

🌌 O Primeiro Programa no Mainframe: A Jornada do Padawan na Galáxia do COBOL

Por Vagner Bellacosa — Bellacosa Mainframe Chronicles

---

“Antes de um Jedi empunhar seu sabre de luz, ele aprende a sentir a Força. No Mainframe, antes de rodar um programa, o Padawan precisa aprender a sentir o zumbido do MVS.”
— Mestre Bellacosa

---

🚀 Capítulo 1: O Despertar do Terminal

Todo Jedi Mainframe começa no TSO/ISPF, o templo sagrado onde o código nasce.
Aqui, não há cliques, não há mouse, só o poder dos comandos.

🌀 Dica do Mestre:
TSO significa Time Sharing Option. É o modo como o z/OS permite que vários usuários interajam simultaneamente com o sistema.
O ISPF (Interactive System Productivity Facility) é o ambiente gráfico textual — sim, gráfico de ASCII, mas ainda assim — onde tudo acontece.

Para começar:

1. Entre no TSO (geralmente com um logon ID e senha).

2. Ao ver o menu do ISPF, escolha a opção 2 – Edit.

3. Crie seu primeiro dataset para o código-fonte:

   CREATE 'USERID.COBOL.SOURCE'
   

   (substitua USERID pelo seu logon)

---

🧙‍♂️ Capítulo 2: Invocando o Espírito do COBOL

Dentro do dataset USERID.COBOL.SOURCE, vamos escrever o primeiro feitiço:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLOMF.
       PROCEDURE DIVISION.
           DISPLAY 'HELLO MAINFRAME WORLD!'.
           STOP RUN.

💡 Curiosidade Bellacosa:
O primeiro programa COBOL Hello World rodou em 1959. Desde então, milhões de “HELLOs” ecoaram nos datacenters do mundo — inclusive em satélites e sistemas bancários.

🧩 Easter Egg Técnico:
Se você escrever DISPLAY 'HELLO WORLD' sem o ponto final (.), o compilador pode engasgar!
No COBOL, o ponto é sagrado — é o ponto final das sentenças, não só da gramática. 😉

---

🧰 Capítulo 3: O Ritual do JCL

Nenhum programa vive sem o JCL (Job Control Language) — o pergaminho que instrui o Mainframe a compilar e executar seu código.

Crie outro dataset:

CREATE 'USERID.JCL'

Agora o job:

//HELLOJOB JOB 'COBOL TEST',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1    EXEC PGM=IGYCRCTL
//COBOL.SYSIN DD DSN=USERID.COBOL.SOURCE(HELLOMF),DISP=SHR
//COBOL.SYSLIN DD DSN=&&LOADSET,UNIT=VIO,SPACE=(CYL,(1,1)),DISP=(MOD,PASS)
//SYSOUT   DD SYSOUT=*
//SYSPRINT DD SYSOUT=*

//STEP2    EXEC PGM=HELOWMF
//STEPLIB  DD DSN=USERID.LOADLIB,DISP=SHR
//SYSOUT   DD SYSOUT=*

⚙️ Explicando o feitiço:

• JOB é o início da magia — identifica o job ao JES2, o oráculo do spool.

• EXEC chama o compilador (IGYCRCTL) e depois o programa.

• SYSOUT=* manda a saída para o spool, visível com o comando SDSF ou OUTLIST.

🪄 Easter Egg Jedi:
O compilador COBOL chama o “IGYCRCTL” (IBM Guy’s Compiler Routine Control) — sim, o “IGY” vem da IBM Guy, apelido do engenheiro que escreveu o protótipo original em 1959 (piada interna).

---

🖥️ Capítulo 4: Invocando o Spool

Após submeter o job com o comando SUBMIT, use:

=SD

ou

SDSF -> ST (Status)

Para ver o job rodando. Quando terminar, veja a saída (? ou S).

Se tudo der certo, o spool mostrará:

HELLO MAINFRAME WORLD!

🎉 Parabéns, Padawan!
Você acaba de executar seu primeiro programa em um dos sistemas mais poderosos e estáveis do planeta.

---

🧭 Capítulo 5: As Trilhas do Aprendizado

Agora que sentiu o gosto da Força, siga o mapa dos próximos passos:

Nível	Missão	Ferramenta	Dica do Mestre
🥉 Iniciante	Criar programas COBOL simples	ISPF Edit	Sempre compile com atenção às mensagens IGY*
🥈 Aprendiz	Manipular VSAM	IDCAMS + COBOL	Aprenda REDEFINES e FILE STATUS
🥇 Cavaleiro	Criar programas CICS	CEDA + BMS	Domine COMMAREA e LINKAGE SECTION
🧙 Mestre	Criar Web Services no z/OS	CICS Web Services / z/OS Connect	COBOL + JSON = futuro clássico

---

☕ Curiosidade Bellacosa:

• O z/OS ainda roda código compilado há 40 anos — sim, o seu HELLOMF pode rodar em 2065 se bem armazenado.

• Em alguns bancos, a política é: “nunca mexa em programa que funciona há mais de 20 anos” — o código é tratado como reliquia sagrada.

• O STOP RUN. equivale ao “May the Force be with you” do COBOL — encerra o ciclo do programa com honra.

---

🌠 Conclusão: O Caminho do Código Antigo

O Mainframe não é um sistema — é uma filosofia.
Cada tela azul do ISPF é um portal para o passado, e cada DISPLAY é um elo com o futuro.
Ser um Padawan Mainframe é aprender que, antes de tudo, o poder está na paciência, na curiosidade e no amor por sistemas que nunca morrem.

 

Bellacosa Mainframe apresenta o HLASM Assembly no modo puro

💀 “HLASM: O Fantasma do Mainframe Que Decide Se Seu Sistema Vive ou Cai

📜 Origem e evolução

➡️ Tradução resumida:
HLASM é uma evolução do Assembly original criado com o IBM System/360 (1964).
Em 1992, a IBM lançou o HLASM com melhorias importantes.

💡 Explicando de verdade

Assembly sempre existiu como a linguagem mais próxima do hardware.
O HLASM veio para resolver um problema clássico:

“Assembly é poderoso… mas um inferno de manter.”

Então a IBM trouxe:

• Macros mais avançadas (quase “funções” antes de existir função)
• Mensagens de erro mais humanas
• Integração com ferramentas como ISPF

👉 Ou seja: não mudou a essência, mas tornou o caos… mais organizado.

---

⚙️ Onde o HLASM se encaixa

➡️ Tradução:
HLASM roda na base do sistema — mais próximo do hardware que COBOL ou Java.

💣 Interpretação estilo Bellacosa:

Se o mainframe fosse uma empresa:

• COBOL → gerente de negócios
• Java → funcionário moderno
• HLASM → o cara que controla o prédio inteiro, energia, segurança e elevador

👉 Ele não aparece… mas sem ele, nada sobe.

---

🏦 Uso no mundo real

➡️ Tradução:
HLASM é usado em:

• Sistemas operacionais
• Transações de alta performance
• Middleware
• Rotinas críticas

💥 Tradução prática:

Quando você passa um cartão:

Existe uma chance enorme de um trecho em HLASM validar aquilo em milissegundos.

---

🚀 Principais usos (com exemplos reais)

1. Exits de sistema

Exemplo citado: IEFU83 (SMF Exit)

👉 O que isso significa?
Você intercepta eventos do sistema e decide:

• gravar log
• ignorar
• alterar comportamento

💣 Isso é hackear o comportamento do z/OS oficialmente

---

2. Rotinas ultra-performáticas

Exemplo:

• Subrotina em assembler chamada por COBOL
• Uso da instrução CKSM (checksum)

👉 Tradução Bellacosa:
COBOL pede ajuda pro HLASM quando:

“preciso fazer isso MUITO rápido ou não dá”

---

3. Acesso direto ao hardware

HLASM permite:

• usar instruções novas do processador antes de qualquer linguagem suportar
• manipular memória diretamente

👉 Isso é nível:

“você não programa… você conversa com o CPU”

---

⚡ Benefícios

✔ Controle absoluto
✔ Performance absurda
✔ Compatibilidade histórica (código de décadas ainda roda)

💣 Insight crítico

Isso é o motivo do mainframe ainda dominar:

O código não envelhece… ele acumula valor.

---

⚠️ Problemas

➡️ Tradução:

• Curva de aprendizado brutal
• Código difícil de entender
• Pouca gente nova aprendendo

💥 Tradução honesta:

HLASM não é difícil…

Ele é hostil.

E pior:

• muitos códigos são praticamente indecifráveis
• dependem de “tribo” (knowledge transfer)

---

👨‍💻 Quem usa HLASM hoje?

Perfis:

1. System Programmers
2. Performance Engineers
3. Desenvolvedores de produtos z/OS

💣 Realidade de mercado:

HLASM é raro → logo:

💰 Quem domina… cobra caro.

---

📉 Tendência moderna (muito importante!)

O autor fala algo extremamente relevante:

➡️ Hoje existe movimento de MIGRAR HLASM → COBOL / Metal C

💡 Por quê?

• Compiladores evoluíram
• Performance do HLL melhorou
• Falta de profissionais HLASM

👉 Tradução brutal:

O sistema ainda depende de HLASM…
mas o mercado está tentando escapar dele.

---

🧠 Análise Profunda (nível arquiteto)

🔥 O paradoxo do HLASM

HLASM é:

• indispensável
• poderoso
• eterno

E ao mesmo tempo:

• evitado
• temido
• escasso

👉 Isso cria um fenômeno único:

“tecnologia crítica… mas invisível”

---

🏛️ Por que ele nunca morreu?

Porque ele resolve 3 coisas que nenhuma linguagem resolve igual:

1. Tempo (performance extrema)
2. Controle (nível de hardware)
3. Compatibilidade (50+ anos)

---

💣 Insight Bellacosa (o mais importante)

HLASM não é só linguagem.

Ele é o “firmware lógico” do mainframe.

---

🧪 Exemplo prático (simplificado)

Cenário:

Você tem um programa COBOL que processa milhões de registros.

Problema:

• lento
• consumo alto de CPU

Solução:

Criar subrotina em HLASM:

CHECKSUM  DS    0H
          LR    R2,R1
          CKSM  R2,R3
          BR    R14

👉 COBOL chama isso → ganha performance brutal

---

🔮 Futuro do HLASM

Tendências:

✔ Vai continuar existindo
✔ Vai ficar mais restrito
✔ Vai virar skill premium

O que muda:

• Mais ferramentas com IA
• Mais abstração
• Menos código novo em assembler

---

💬 Conclusão no estilo Bellacosa Mainframe

💣 HLASM é o seguinte:

Você não escolhe aprender…
você é escolhido pela necessidade.

Ele é:

• o código que ninguém quer mexer
• mas todo sistema crítico depende

👉 E quando dá problema…

não é bug… é incidente de guerra.

 

 

Bellacosa Mainframe e o paradigma de programação imperativo

O que é Paradigma de Programação Imperativo?

Quando começamos a estudar:

• COBOL;

• Assembler;

• C;

• JCL;

• programação mainframe;

encontramos um conceito muito importante chamado:

paradigma de programação.

E um dos paradigmas mais famosos da computação é o:

paradigma imperativo.

---

O que significa “paradigma”?

Paradigma é:

um modelo ou estilo de programação.

Ou seja:
é a forma como organizamos a lógica do programa.

---

Definição simples

Programação imperativa é:

dizer ao computador exatamente o que fazer, passo a passo.

O programa descreve:

• sequência;

• comandos;

• mudanças de estado;

• fluxo de execução.

---

Analogia simples

Imagine ensinar alguém a fazer um bolo.

Você diz:

1. Pegue farinha
2. Misture ovos
3. Ligue o forno
4. Coloque a massa
5. Asse por 40 minutos

Isso é:

programação imperativa.

Você descreve:

cada passo da execução.

---

Por que “imperativo”?

Porque o programa usa:

comandos e instruções.

Ou seja:
ele “ordena” o que o computador deve fazer.

---

Como isso aparece no mainframe?

O mainframe tradicional é fortemente baseado em:

paradigma imperativo.

Principalmente em:

• COBOL;

• Assembler;

• PL/I;

• JCL procedural.

---

Exemplo simples em pseudocódigo

LER SALARIO
SE SALARIO > 5000
   CALCULAR IMPOSTO
SENAO
   MOSTRAR ISENTO

---

O programa controla:

• ordem;

• variáveis;

• decisões;

• fluxo.

---

Exemplo COBOL

IF SALARIO > 5000
   COMPUTE IMPOSTO = SALARIO * 0.15
ELSE
   DISPLAY 'ISENTO'
END-IF

---

Isso é imperativo porque:

o programador define:

exatamente como o processamento acontece.

---

Características do paradigma imperativo

---

Sequência de comandos

---

Alteração de variáveis

---

Controle de fluxo

---

Uso de IF e LOOP

---

Estado do programa muda durante execução

---

O que é “estado”?

Valores atuais do programa.

Exemplo:

SALDO = 100

Depois:

SALDO = 200

O estado mudou.

---

Estruturas clássicas do imperativo

---

IF

Decisão.

---

PERFORM

Repetição COBOL.

---

GO TO

Desvio fluxo.

---

MOVE

Movimentação dados.

---

COMPUTE

Cálculo.

---

Exemplo COBOL batch

READ CLIENTE
IF SALDO > 0
   WRITE RELATORIO
END-IF

---

Fluxo típico imperativo

INICIO
 ↓
LER DADOS
 ↓
PROCESSAR
 ↓
ATUALIZAR
 ↓
GERAR SAÍDA
 ↓
FIM

---

Por que o paradigma imperativo domina no mainframe?

Porque ele funciona muito bem para:

• processamento batch;

• regras de negócio;

• arquivos sequenciais;

• grande volume de dados.

---

O COBOL é imperativo?

Sim.

Principalmente:

COBOL procedural clássico.

---

O Assembler é imperativo?

Totalmente.

Assembler é um dos exemplos mais “puros” de paradigma imperativo.

---

O JCL é imperativo?

Parcialmente.

Porque ele descreve:

sequência operacional.

---

Paradigma imperativo vs declarativo

---

Imperativo

Diz:

COMO fazer.

---

Declarativo

Diz:

O QUE deseja obter.

---

Exemplo SQL

SELECT NOME
FROM CLIENTES
WHERE SALDO > 1000

Isso é mais:

declarativo.

---

Porque o SQL não explica:

• loops;

• leitura;

• memória;

• fluxo detalhado.

---

Exemplo imperativo equivalente

LER CLIENTE
SE SALDO > 1000
   MOSTRAR NOME
LER PRÓXIMO

---

Paradigma imperativo em batch

Muito comum em:

• COBOL;

• SORT;

• processamento sequencial.

---

Exemplo clássico batch

LER REGISTRO
VALIDAR
CALCULAR
GRAVAR
LER PRÓXIMO

---

Isso é extremamente comum no z/OS

---

O que é programação procedural?

Subtipo muito ligado ao paradigma imperativo.

Usa:

• procedimentos;

• rotinas;

• subprogramas.

---

COBOL clássico é procedural

---

Vantagens do paradigma imperativo

---

Fácil entender fluxo

---

Controle detalhado

---

Excelente para batch

---

Ótimo desempenho

---

Muito eficiente em processamento massivo

---

Desvantagens

---

Pode ficar complexo

---

Muito código repetitivo

---

GO TO excessivo vira “spaghetti code”

---

Difícil manutenção em sistemas enormes

---

O que é spaghetti code?

Código confuso cheio de desvios.

Muito comum em sistemas antigos.

---

Curiosidades incríveis

1. Grande parte do sistema financeiro mundial roda lógica imperativa

---

2. COBOL foi criado pensando em processamento procedural

---

3. Mainframes executam bilhões de instruções imperativas diariamente

---

4. Muitos sistemas críticos possuem décadas de evolução imperativa

---

Erros comuns de iniciantes

---

1. Confundir paradigma com linguagem

Paradigma:
modelo lógico.

Linguagem:
ferramenta.

---

2. Usar GO TO demais

---

3. Não controlar estado das variáveis

---

4. Criar lógica procedural confusa

---

Como isso aparece no dia a dia?

Praticamente em:

• COBOL;

• batch;

• JCL;

• DB2 procedural;

• CICS;

• automação.

---

Exemplo real simplificado

LER CONTA
 ↓
VALIDAR
 ↓
CALCULAR JUROS
 ↓
ATUALIZAR DB2
 ↓
GERAR RELATÓRIO

---

Resumo rápido

Conceito	Significado
Paradigma	Estilo de programação
Imperativo	Diz como fazer
Estado	Valores atuais
Procedural	Baseado em procedimentos
Fluxo	Ordem da execução
COBOL	Principal exemplo no mainframe

---

Conclusão

O paradigma imperativo é um dos modelos mais importantes da computação e domina grande parte do desenvolvimento tradicional em mainframe IBM Z.

Ele organiza programas através de comandos sequenciais, decisões e alterações de estado, sendo a base do COBOL, Assembler e do processamento batch no z/OS.