Bellacosa Mainframe e a guerra entre EBCDIC versus ASCII

☕🔥 EBCDIC vs ASCII — A GUERRA SILENCIOSA QUE DIVIDIU A COMPUTAÇÃO

Se você trabalha com Mainframe…

mais cedo ou mais tarde vai descobrir uma verdade dolorosa:

“Nem todo texto é texto.”

Porque no mundo Enterprise…

uma letra “A” pode valer:

• C1 no EBCDIC

• 41 no ASCII

E é exatamente aí que começam:

• arquivos corrompidos,

• integrações quebradas,

• caracteres estranhos,

• “ç” virando lixo,

• jobs falhando,

• FTPs destruindo datasets,

• e programadores entrando em crise existencial.

Hoje vamos mergulhar numa das maiores divisões técnicas da história da computação:

ASCII vs EBCDIC

A batalha entre:

• o padrão do mundo aberto

• e o padrão do império IBM.

---

☕ O QUE É ASCII?

ASCII significa:

American Standard Code for Information Interchange

Criado em:

1963

Padronizado pelo:

ANSI (American National Standards Institute)

Objetivo:
Criar um padrão universal de representação de caracteres.

Antes disso:
cada fabricante fazia sua própria codificação.

Resultado?
Caos absoluto.

Um computador não “entendia” o texto do outro.

ASCII veio para resolver isso.

---

☕ O QUE É EBCDIC?

EBCDIC significa:

Extended Binary Coded Decimal Interchange Code

Criado pela:

IBM

Ano:

1964

Baseado em:

• BCD (Binary Coded Decimal)

• punch cards

• sistemas IBM 1401/360

O EBCDIC nasceu praticamente junto do:

IBM System/360

Ou seja:

o DNA do EBCDIC está ligado diretamente à história do Mainframe moderno.

---

☕ A DIFERENÇA TÉCNICA MAIS IMPORTANTE

A maior diferença NÃO é o tamanho.

Os dois usam 8 bits (na prática moderna).

O problema real é:

O MAPEAMENTO DOS CARACTERES

Exemplo:

Caractere	ASCII	EBCDIC
A	41	C1
B	42	C2
0	30	F0
espaço	20	40

Ou seja:

o mesmo byte representa coisas diferentes.

---

☕ POR QUE ISSO IMPORTA?

Porque computadores não enxergam letras.

Eles enxergam:

bytes

Quando um sistema ASCII lê EBCDIC sem conversão:

vira lixo.

Exemplo clássico:

Você envia um dataset mainframe para Linux sem conversão.

Resultado:

• caracteres quebrados

• colunas desalinhadas

• SQL inválido

• JSON destruído

• XML ilegível

O famoso:

“mojibake corporativo”

---

☕ POR QUE A IBM CRIOU O EBCDIC?

Aqui entra a parte histórica fascinante.

A IBM NÃO queria depender do ASCII.

Na época:

• fabricantes brigavam por padrões

• havia guerra comercial

• ninguém queria perder controle tecnológico

A IBM já possuía:

• sistemas baseados em cartões perfurados

• BCD interno

• hardware orientado ao seu ecossistema

Então ela fez:

o próprio padrão.

E como a IBM dominava o mercado corporativo…

o EBCDIC virou rei nos data centers.

---

☕ ENTÃO POR QUE O ASCII “VENCEU”?

Porque o mundo mudou.

ASCII tinha vantagens gigantes:

1 — Organização lógica dos caracteres

No ASCII:

Sequência
A B C D
41 42 43 44

Tudo sequencial.

Já no EBCDIC:
os caracteres ficam espalhados.

Isso dificulta:

• sorting

• comparações

• parsing

• algoritmos simples

---

☕ 2 — ASCII ERA MAIS SIMPLES

Universidades adotaram ASCII.

Minicomputadores adotaram ASCII.

Unix adotou ASCII.

E quando Unix dominou:

• redes

• internet

• TCP/IP

• e-mail

• web

o ASCII virou padrão global.

---

☕ 3 — INTERNET

A internet praticamente nasceu ASCII.

Protocolos antigos:

• SMTP

• HTTP

• FTP

• TELNET

foram pensados em ASCII.

Mainframe precisou se adaptar.

Não o contrário.

---

☕ 4 — UNIX E C

A linguagem C e o Unix foram desenhados pensando em ASCII.

Muita lógica assume:

'A' + 1 == 'B'

No ASCII:
funciona perfeitamente.

No EBCDIC:
isso quebra.

---

☕ UMA CURIOSIDADE ABSURDA

No EBCDIC:

as letras NÃO são contínuas.

Exemplo:

Intervalo
A-I
J-R
S-Z

ficam em blocos separados.

Isso acontece por herança dos cartões perfurados IBM.

Até hoje isso surpreende desenvolvedores.

---

☕ OUTRA CURIOSIDADE HISTÓRICA

Muitos bugs antigos de software aconteceram porque programadores assumiam ASCII.

Quando rodavam no Mainframe:
💥 caos.

Especialmente em:

• compiladores

• bibliotecas C

• middleware Unix-to-z/OS

---

☕ O “TRAUMA” DOS PROGRAMADORES DISTRIBUÍDOS

Um clássico do mundo enterprise:

FTP ASCII vs FTP BINARY

Se você transfere:

• fonte COBOL

• JCL

• datasets texto

usa:

ASCII mode

O FTP converte EBCDIC ↔ ASCII.

Mas se você transfere:

• load modules

• arquivos binários

• DBRM

• executáveis

e usa ASCII…

você destrói o arquivo.

Literalmente.

Veteranos de mainframe têm PTSD disso até hoje.

---

☕ POR QUE O EBCDIC SOBREVIVEU?

Porque Mainframe:

nunca foi sobre moda.

Foi sobre:

• estabilidade

• compatibilidade

• legado

• investimento bilionário

Trocar encoding em sistemas bancários gigantescos seria um pesadelo histórico.

Imagine converter:

• COBOL

• CICS

• DB2

• VSAM

• datasets históricos

• aplicações financeiras

• décadas de batch

Tudo isso sem quebrar:

• centavos

• juros

• impostos

• contratos

• auditoria

Resultado:

EBCDIC ficou.

---

☕ MAS O z/OS USA SÓ EBCDIC?

Hoje:

não.

O IBM Z moderno fala praticamente tudo:

• ASCII

• Unicode

• UTF-8

• JSON

• XML

• REST

• APIs

• Linux

Inclusive:
Linux on Z usa UTF-8 normalmente.

O mundo IBM atual é híbrido.

---

☕ O VERDADEIRO “SUCESSOR”

Hoje o padrão dominante não é ASCII.

É:

Unicode / UTF-8

Porque ASCII não suporta:

• japonês

• árabe

• emojis

• acentos complexos

• símbolos globais

UTF-8 virou o idioma universal.

Inclusive:
UTF-8 preserva compatibilidade ASCII nos primeiros 128 caracteres.

Genialidade pura.

---

☕ EASTER EGGS E CURIOSIDADES NERDS

🔥 1 — O “HELLO WORLD” QUEBRADO

Muitos programas antigos imprimiam lixo no Mainframe porque assumiam ASCII.

---

🔥 2 — A LETRA “{” ERA UM INFERNO

Em alguns terminais EBCDIC:
caracteres especiais mudavam dependendo da code page.

Programadores COBOL antigos sofreram MUITO com isso.

---

🔥 3 — CODE PAGES

Existe:

• EBCDIC US

• EBCDIC BRASIL

• EBCDIC EUROPA

• CP037

• CP1047

• CP500

Ou seja:
nem “o EBCDIC” é único.

---

🔥 4 — O ASCII TEM CONTROLE DE TELETIPO

Caracteres como:

• CR

• LF

• BEL

• ESC

vieram de teletipos mecânicos.

O famoso:

BEL

era literalmente:

tocar um sino físico.

Sim.

Um sino REAL.

---

🔥 5 — O MAINFRAME “TRADUZ” O MUNDO O TEMPO TODO

Hoje grande parte do middleware IBM faz:

• conversão automática

• transcoding

• CCSID mapping

Sem você perceber.

CICS, MQ, DB2, Connect:Direct, FTP…
todos vivem traduzindo bytes.

---

☕ VANTAGENS E DESVANTAGENS

ASCII	EBCDIC
Simples	Forte integração IBM
Dominou internet	Compatibilidade histórica
Organização lógica	Excelente legado corporativo
Melhor interoperabilidade	Integração perfeita com workloads antigos
Fácil para linguagens modernas	Décadas de estabilidade

---

☕ DESVANTAGENS

ASCII	EBCDIC
Originalmente limitado	Pouca interoperabilidade
Não nasceu global	Mapeamento estranho
Dependia de extensões	Conversões constantes
Evoluiu para UTF-8	Complexidade de code pages

---

☕ O GRANDE PONTO FILOSÓFICO

ASCII venceu o mundo aberto.

EBCDIC venceu o mundo corporativo crítico.

ASCII construiu:

• internet

• Unix

• open systems

EBCDIC sustentou:

• bancos

• seguradoras

• governos

• bolsas de valores

• cartões de crédito

Enquanto muita gente fazia:
“Hello World”…

o Mainframe estava liquidando bilhões de dólares por segundo.

---

☕ FRASE FINAL ESTILO BELLACOSA MAINFRAME

“ASCII ajudou a conectar computadores.

EBCDIC ajudou a sustentar o sistema financeiro do planeta.”

 

Bellacosa Mainframe apresenta o famoso gato da sorte maneki neko

Perfeito. Vamos de Maneki-neko no modo Bellacosa Mainframe 🐱⚙️
Origem, história, fofoca, easter egg, curiosidade inútil-útil e aquele paralelo inevitável com sistemas que não podem cair.

---

🐱 Maneki-neko – o gato que dá IPL na sorte

Se você já entrou num restaurante japonês, numa lojinha de bairro ou até num boteco “meio oriental”, provavelmente viu ele lá:
um gato sentado, uma patinha levantada, olhando para o nada… mas trabalhando pesado.

O Maneki-neko (招き猫) não está acenando.
Ele está chamando.

E isso muda tudo.

---

Maneki neko

📜 Origem: logs antigos do Japão feudal

O termo Maneki-neko vem de:

• maneku (招く) → convidar, chamar

• neko (猫) → gato

Ou seja:

“o gato que chama”

As origens mais aceitas ficam entre os séculos XVII e XVIII, no Período Edo, quando o Japão começa a urbanizar, surgem comércios, rotas internas e… concorrência.

Existem três lendas principais, como qualquer sistema legado respeitável.

---

🏯 Lenda do Templo Gotoku-ji (a mais famosa)

Um senhor feudal passava por um templo pobre durante uma tempestade.
Viu um gato levantando a pata, como se chamasse.

Curioso, se aproximou.
No instante seguinte, um raio caiu exatamente onde ele estava antes.

Resultado:

• Sobreviveu

• Financiou o templo

• O gato virou símbolo de proteção + prosperidade

Failover espiritual bem-sucedido.

---

🏮 Lenda da velha comerciante pobre

Uma senhora, sem dinheiro, sonha com um gato dizendo:

“Faça estátuas de mim e você nunca passará fome.”

Ela obedece.
As pessoas começam a comprar.
O dinheiro volta.

Primeiro caso documentado de monetização de mascote.

---

🧧 Lenda da gueixa e o gato enforcado (a versão dark)

Um gato puxa o quimono da gueixa repetidamente.
Assustado, um cliente decapita o gato.

A cabeça voa, mata uma cobra venenosa que estava prestes a atacar a gueixa.

Culpa, remorso, estátuas do gato…

Backup tardio, mas com aprendizado.

---

🐾 A pata levantada NÃO é aleatória

Aqui entra a parte que pouca gente sabe:

• 🐱 Pata esquerda levantada
  → chama clientes, pessoas, movimento
  → comum em lojas e restaurantes

• 🐱 Pata direita levantada
  → chama dinheiro, prosperidade
  → comum em empresas, caixas, escritórios

• 🐱 Duas patas levantadas
  → proteção total
  → também conhecido como “overkill visual”

Duas patas = firewall + IDS + backup offsite.

---

🎨 Cores e seus significados

Nada no Maneki-neko é decorativo. Tudo é configuração.

• 🤍 Branco → pureza, novos começos (default)

• 🖤 Preto → proteção contra azar

• ❤️ Vermelho → saúde

• 💛 Dourado → dinheiro (o mais vendido)

• 💚 Verde → estudos, crescimento

• 💗 Rosa → amor (versão moderna)

---

🧧 A moeda oval (koban)

Muitos Maneki-nekos seguram uma moeda com inscrição:

千万両 (sen man ryō)

Tradução livre:

“10 milhões de ryō”
(uma fortuna absurda na época)

É o equivalente espiritual a:

MAX-AMOUNT=YES

---

🥚 Easter eggs culturais

• O gesto japonês de “chamar alguém” é com a palma para baixo, não para cima
  → o gato NÃO está dando tchau

• No anime Natsume Yuujinchou, Doraemon, Pokémon, Bleach e até Hello Kitty, referências ao Maneki-neko aparecem o tempo todo

• O bairro de Gotoku-ji, em Tóquio, tem milhares de estátuas acumuladas
  → um spool espiritual de agradecimento

---

🧠 Tradução para o mundo mainframe

O Maneki-neko representa:

• Alta disponibilidade

• Chamada constante de recursos

• Proteção contra eventos inesperados

• Resiliência silenciosa

Ele não faz barulho.
Não promete milagres.
Só fica lá, funcionando.

Como um CICS estável numa sexta-feira à noite.

---

☕ Comentário final estilo El Jefe

Talvez o Maneki-neko não traga dinheiro sozinho.
Mas ele lembra algo fundamental:

Sorte também é disciplina, atenção e constância.

O gato não corre atrás da prosperidade.
Ele senta, observa…
e chama.

Como todo bom sistema que dura décadas.

---

🐾⚙️

 

Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉

---

🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

• O sistema vinha em DLIB tapes

• O SYSGEN tinha Stage 1 e Stage 2

• O programador montava tudo na unha

• E manutenção?
  👉 Manual. Muito manual.

Resultado?

• Instabilidade

• Erros humanos

• Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.

---

🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

• Global Zone → cérebro

• Target Zone → sistema em execução

• Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.

---

🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

• O que está instalado?

• Onde está?

• Como foi construído?

• Quem depende de quem?

Zonas:

• Global Zone
  Índice mestre + opções de controle

• Target Zone
  Reflete o que está rodando

• Distribution Zone
  Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.

---

📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

• FUNCTION → produto novo

• PTF → serviço preventivo

• APAR → correção corretiva

• USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

• MCS (++ statements) → inteligência

• Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.

---

🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

1. RECEIVE

   • Entra no SMPPTS

   • Atualiza Global Zone

   • Nada muda no sistema ainda

2. APPLY

   • Atualiza Target Libraries

   • Sistema pode ser testado

   • Ainda reversível

3. RESTORE

   • Volta ao último nível aceito

   • Usa DLIB como fonte

   • Seu botão de “desfazer”

4. ACCEPT

   • Atualiza DLIB

   • Ponto sem volta

   • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.

---

🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

• Menos fita

• Mais automação

• Menos transporte físico

• Mais rastreabilidade

Opções modernas:

• ServerPac → replace completo

• CBPDO → produto ou serviço incremental

• Internet Delivery

  • RECEIVE FROMNETWORK

  • RECEIVE FROMNTS

  • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.

---

🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

• Ele aparece como Open

• Depois Submitted ou Order Center

• E você acompanha em:
  👉 In Progress

Quando muda para Download…
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade

---

🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

• Ordena PTF automaticamente

• Agenda serviço

• Controla origem dos fixes (SourceID)

• Centraliza histórico

Tudo isso com:

• RECEIVE ORDER

• ORDER Management (Option 7)

• Java ou ICSF

• FTPS + Hash SHA-1

---

🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

• Clone do sistema

• Program Directory

• PSP Buckets

• Espaço em Target, DLIB e SMP/E datasets

• IVP depois

• Testes reais

• Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.

---

🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.

---

🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

• Substituir JCL “verboso”

• Padronizar scripts

• Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

☕ Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.

---

🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

• TSO/E

• Batch

• SDSF

• ISPF

• CICS (indiretamente)

• Programas externos

Cada ambiente define:

• Comandos válidos

• RC interpretado

• Recursos disponíveis

• Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.

---

🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

• Tipagem dinâmica

• Strings como cidadão de primeira classe

• Sem declaração obrigatória

• Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2
if parm1 = '' then exit 8

☕ Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.

---

🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

1. Identificação

2. Validação de ambiente

3. Tratamento de RC

4. Controle de erro

5. Cleanup

📌 Exemplo base:

/* REXX */
signal on error
signal on failure
signal on syntax

address tso
"ALLOC FI(IN) DA('DATASET') SHR"
...
exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.

---

🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A'
tab.2 = 'B'
tab.0 = 2

☕ Curiosidade:
Stem mal controlado vira memory leak conceitual.

---

📂 Acesso a Arquivos & Geração de Relatórios

• ALLOC / FREE

• EXECIO DISKR / DISKW

• Geração de relatórios spoolados

• Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)"
do i=1 to L.0
  say L.i
end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.

---

🔃 Classificação & Manipulação de Dados

• SORT via IDCAMS

• SORT via ICETOOL

• Manipulação em memória (lento)

• Pipeline híbrido REXX + SORT

☕ Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.

---

🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

• LMDINIT

• LMMLIST

• LMCLOSE

📌 Exemplo:

address ispexec
"LMINIT DATAID(DID) DATASET('MY.PDS')"
"LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.

---

🧑‍💻 Interatividade com Usuário (TSO)

• Pseudo-conversational

• Command-level

• SAY / PULL

• Mensagens controladas

☕ Fofoquice:
Interface feia, mas resolve crise em minutos.

---

🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

• Interativo

• Debug rápido

• Dependente de perfil

🟡 REXX Batch Script (Interpretado)

• Executa via IKJEFT01

• Dependente de ambiente

• Mais flexível

🔴 REXX Batch Compilado

• Performance superior

• RC previsível

• Menos tolerante a erro

• Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.

---

🔐 REXX + RACF

REXX não ignora segurança:

• Herda permissões do usuário

• Pode consultar via RACROUTE (indireto)

• Controla acesso via classes

☕ Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.

---

🗄️ REXX + DB2

• DSNREXX

• SQL dinâmico

• RC + SQLCODE + SQLSTATE

• Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX
"EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.

---

🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

• TSO

• ISPEXEC

• SDSF

• CONSOLE

• DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.

---

🔢 Return Code (RC) — o idioma da produção

• RC ≠ erro sempre

• RC precisa ser interpretado

• Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.

---

📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

• Ambiente restritivo

• Casos reais

• Incidentes simulados

Instruções REXX

• IF, DO, SELECT

• SIGNAL, EXIT

• PARSE

Funções Internas / Sub-rotinas

• Modularização

• Reuso

• Controle de escopo

Comandos REXX

• SAY, PULL, TRACE

• QUEUE / PULL

• EXECIO

Funções TSO / CONSOLE

• WTO

• MODIFY

• DUMP

• SDSF

INTERPRET (🔥 perigoso)

• Execução dinâmica

• Flexibilidade extrema

• Risco máximo

☕ Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.

---

🥚 Easter Eggs & Fofoquices REXX

• Todo ambiente tem um EXEC “salvador”

• Sempre existe um REXX sem comentários rodando há anos

• O melhor REXX é o que não precisa ser explicado

• Debug começa com TRACE ?R

---

☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

• Script simples

• Linguagem de iniciante

• Alternativa ao COBOL

REXX é:

• Cola do z/OS

• Automação estratégica

• Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.

 

Bellacosa Mainframe explica o JSON

🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe ☕🔥

“Enquanto muita gente ainda pensava em arquivos texto… o JSON já estava preparando o planeta para microserviços, APIs e integração global.”

---

🚀 Introdução — O Formato Que Conquistou o Mundo

Se existe algo que une JavaScript, Python, Java, Node.js, Kubernetes, APIs REST, Open Banking, cloud e até o z/OS… esse algo é o JSON.

Sim…

Aquele bloco aparentemente simples:

{
  "cliente": "BELLACOSA",
  "conta": 12345,
  "saldo": 9999.99
}

Hoje parece trivial.

Mas o impacto do JSON na computação foi monstruoso.

Ele virou:

• o idioma oficial das APIs,
• a “cola” da internet moderna,
• o padrão universal de troca de dados,
• e uma das maiores revoluções silenciosas da computação corporativa.

E o mais curioso?

O JSON nasceu de forma extremamente simples… quase como um “truque elegante” dentro do JavaScript.

---

🧠 Quem Criou o JSON?

O JSON foi criado por:

👨 Douglas Crockford

Programador, arquiteto de software e evangelista JavaScript.

---

📅 Data de Criação

O JSON começou a ganhar forma por volta de:

📌 2001

E foi oficialmente popularizado entre:

📌 2002–2005

---

🌍 O Problema Que o JSON Resolveu

Antes do JSON, integração era quase sempre baseada em:

• XML
• CSV
• Arquivos posicionais
• Protocolos binários
• EDI
• Mensagens proprietárias

O problema?

Tudo era:

• pesado,
• verboso,
• lento,
• difícil de ler,
• difícil de debugar.

Exemplo de XML:

<cliente>
   <nome>BELLACOSA</nome>
   <saldo>9999.99</saldo>
</cliente>

Agora compare com JSON:

{
   "nome": "BELLACOSA",
   "saldo": 9999.99
}

Menos ruído.
Mais legibilidade.
Mais velocidade.
Mais simplicidade.

E o mercado enlouqueceu.

---

⚡ O Grande Segredo do JSON

O JSON nasceu inspirado diretamente nos objetos JavaScript.

Na prática:

var cliente = {
   nome: "BELLACOSA",
   saldo: 9999.99
}

Douglas Crockford percebeu:

“E se isso virar um formato universal de troca de dados?”

E virou.

---

🔥 O JSON Explodiu Com as APIs REST

Quando APIs REST começaram a dominar o mercado…

o JSON virou praticamente obrigatório.

Porque:

• era leve,
• rápido,
• fácil de parsear,
• perfeito para internet,
• amigável para humanos.

Resultado?

O XML começou a perder espaço rapidamente.

---

☕ O Mainframe Não Ficou de Fora

Aqui começa a parte interessante para o mundo COBOL.

Muita gente achava:

“Mainframe nunca vai falar JSON.”

Erro histórico.

Hoje o z/OS conversa JSON o tempo inteiro:

• APIs REST
• z/OS Connect
• CICS Web Services
• MQ
• Kafka
• Open Banking
• Microsserviços
• Cloud híbrida

O JSON virou peça fundamental da modernização mainframe.

---

🧠 COBOL + JSON = O Casamento Corporativo Moderno

A IBM percebeu rapidamente:

Se o mainframe quisesse continuar reinando…
precisaria falar JSON nativamente.

E então vieram recursos modernos como:

📌 JSON PARSE

e

📌 JSON GENERATE

no Enterprise COBOL.

---

🚀 Exemplo COBOL Moderno Com JSON

Gerando JSON

IDENTIFICATION DIVISION.
PROGRAM-ID. GERJSON.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 CLIENTE.
   05 NOME      PIC X(20) VALUE 'BELLACOSA'.
   05 SALDO     PIC 9(5)V99 VALUE 99999.99.

01 JSON-SAIDA  PIC X(200).

PROCEDURE DIVISION.

JSON GENERATE JSON-SAIDA
   FROM CLIENTE

DISPLAY JSON-SAIDA.

STOP RUN.

Saída:

{"NOME":"BELLACOSA","SALDO":99999.99}

---

🔥 Parsing JSON no COBOL

Recebendo API REST

JSON PARSE JSON-ENTRADA
   INTO CLIENTE

Isso foi revolucionário no z/OS.

Porque eliminou:

• parsers manuais,
• tratamentos absurdos,
• lógica artesanal,
• conversões complexas.

---

🧠 O Que Tornou o JSON Tão Poderoso?

📌 1. Legibilidade Humana

Até operador consegue entender.

---

📌 2. Estrutura Hierárquica

Permite:

• objetos,
• listas,
• arrays,
• árvores complexas.

---

📌 3. Independência de Linguagem

Funciona em:

• COBOL
• Java
• Python
• Go
• Node.js
• Rust
• RPG
• PL/I

---

📌 4. Perfeito Para APIs

JSON praticamente virou:

“o TCP/IP da integração moderna.”

---

⚠️ Desvantagens do JSON

Nem tudo são flores.

---

❌ 1. Sem Tipagem Forte

JSON puro não define:

• decimal fixo,
• packed decimal,
• COMP-3,
• datas reais.

Isso gera problemas em integrações financeiras.

---

❌ 2. Overhead de Texto

JSON é texto.

Protocolos binários podem ser mais rápidos.

---

❌ 3. Segurança

Parsing inseguro pode causar:

• injection,
• payload malicioso,
• consumo excessivo de memória.

---

❌ 4. Precisão Numérica

Problema clássico:

• valores financeiros,
• arredondamentos,
• IEEE floating point.

O mainframe sofre muito menos disso graças ao decimal packed.

---

🔥 Curiosidades Históricas

☕ JSON NÃO É Linguagem

Apesar do nome:

JavaScript Object Notation

JSON NÃO é uma linguagem de programação.

É apenas um formato de dados.

---

☕ O JSON Virou Padrão Oficial

RFC oficial:

📌 RFC 8259

---

☕ XML Dominava Absolutamente

Antes do JSON:

• SOAP,
• WSDL,
• XML Schema,
• namespaces,
• tags gigantescas.

Parecia um ritual mágico corporativo.

JSON chegou como uma motosserra.

---

💣 Easter Egg Histórico

Douglas Crockford chegou a remover referências perigosas do JavaScript porque:

📌 JSON podia executar código involuntariamente

No começo muita gente fazia:

eval(json)

Isso virou um pesadelo de segurança.

Daí nasceram parsers seguros.

---

🚀 JSON no Mundo Mainframe Moderno

Hoje o JSON está em todo lugar no z/OS:

Tecnologia	Uso
z/OS Connect	APIs REST
CICS	Web Services
IMS	Integração moderna
MQ	Mensageria
Kafka	Streaming
Db2 REST	APIs corporativas
Open Banking	Payloads financeiros
Cloud híbrida	Microsserviços

---

🔥 O JSON Mudou o Papel do Programador COBOL

Antigamente:

• COBOL manipulava arquivos,
• VSAM,
• copybooks,
• EBCDIC.

Hoje o COBOL moderno:

• consome APIs,
• gera REST,
• fala HTTP,
• troca JSON,
• integra cloud,
• conversa com Kubernetes.

O programador COBOL virou:

engenheiro de integração corporativa.

---

☕ Comparação Filosófica: JSON vs Copybook COBOL

Curiosamente…

JSON lembra MUITO a ideia dos copybooks.

Veja:

Copybook

01 CLIENTE.
   05 NOME PIC X(20).
   05 SALDO PIC 9(5)V99.

JSON

{
   "NOME": "BELLACOSA",
   "SALDO": 99999.99
}

Ambos descrevem estrutura de dados.

A diferença?

O JSON atravessa internet, nuvem e APIs.

---

🧠 O Verdadeiro Motivo do Sucesso do JSON

Não foi tecnologia.

Foi simplicidade.

O JSON venceu porque:

• humanos entendem,
• programadores gostam,
• APIs adoram,
• clouds dependem,
• empresas inteiras padronizaram nele.

---

💣 Conclusão — O JSON Virou a “Nova Linguagem Universal”

O JSON não matou o COBOL.

Na verdade…

Ele ajudou o COBOL a sobreviver à era cloud.

Hoje o mainframe continua relevante porque aprendeu:

• REST,
• APIs,
• microsserviços,
• containers,
• integração moderna,
• e principalmente…
• JSON.

E talvez essa seja a maior ironia da computação:

O formato que nasceu no JavaScript acabou ajudando o z/OS a continuar dominando o coração financeiro do planeta.

---

☕ Frase Final no Estilo Bellacosa Mainframe

“O COBOL continua processando bilhões… mas agora conversa com o mundo em JSON.” 🔥🚀