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.

Robert E. Howard : Quando um Programador Descobre que o Homem que Criou Conan Também Escreveu a Arquitetura da Fantasia Moderna

 

Bellacosa Mainframe apresenta o lendario Robert E. Howard criador do Conan o Barbaro

☕ Um Café no Bellacosa Mainframe

Robert E. Howard sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o Homem que Criou Conan Também Escreveu a Arquitetura da Fantasia Moderna Como Quem Projetava um Sistema Crítico de Mainframe

"Alguns programadores escrevem software que sobrevive décadas. Robert E. Howard escreveu personagens que sobreviveram quase um século."

---

Introdução – O Programador Invisível da Fantasia

Existe uma pergunta curiosa.

Quem inventou o COBOL?

Grace Hopper participou da sua criação.

Quem inventou C?

Dennis Ritchie.

Quem inventou Java?

James Gosling.

Quem inventou Linux?

Linus Torvalds.

Agora faça outra pergunta.

Quem inventou praticamente toda a fantasia heroica moderna?

Pouquíssima gente conhece a resposta.

Robert Ervin Howard.

Seu nome talvez não seja imediatamente reconhecido.

Mas seus personagens...

Esses você conhece.

Conan.

Kull.

Solomon Kane.

Bran Mak Morn.

Red Sonja (que mais tarde seria expandida por Roy Thomas a partir de uma personagem de Howard).

Centenas de conceitos utilizados hoje em RPGs, videogames, mangás, filmes e séries nasceram de sua imaginação.

Curiosamente...

Ele fez tudo isso antes dos trinta anos de idade.

Para um programador COBOL existe uma analogia perfeita.

Howard foi para a literatura o que um arquiteto de sistemas foi para o mainframe.

Ele não criou apenas programas.

Criou uma plataforma inteira.

---

O Menino do Texas

Robert Ervin Howard nasceu em 22 de janeiro de 1906, em Peaster, Texas.

Seu pai era médico.

Na infância a família mudou diversas vezes acompanhando cidades ligadas ao petróleo.

Isso parece um detalhe.

Mas mudou completamente sua forma de escrever.

Howard cresceu observando cidades nascerem praticamente da noite para o dia.

Homens enriquecendo.

Empresas desaparecendo.

Violência.

Ganância.

Corridas pelo ouro negro.

Tudo isso moldou sua visão de mundo.

Ele percebeu algo muito cedo.

Civilizações não são eternas.

Empresas também não.

Tecnologias muito menos.

Esse pensamento aparece em praticamente todos os seus contos.

---

Howard Era um Arquiteto de Mundos

Muita gente acredita que Howard simplesmente escrevia aventuras.

Não.

Ele fazia algo muito mais sofisticado.

Primeiro criava:

• geografia;

• história;

• economia;

• religião;

• política;

• povos;

• idiomas;

• cultura;

• conflitos.

Só depois escrevia as histórias.

Isso lembra muito um arquiteto de software.

Antes do primeiro programa existir, define-se:

• arquitetura;

• camadas;

• banco de dados;

• comunicação;

• segurança;

• desempenho;

• disponibilidade.

Howard fazia exatamente isso.

---

A Era Hiboriana: um Grande Projeto de Software

Quando criou Conan, Howard percebeu um problema.

Se utilizasse História real...

ficaria preso aos fatos.

Então criou uma linha do tempo completamente nova.

A famosa Era Hiboriana.

Era praticamente um framework.

Depois disso bastava adicionar novas histórias.

É semelhante ao que fazemos hoje criando uma plataforma corporativa.

Primeiro vem a arquitetura.

Depois surgem centenas de aplicações.

---

Weird Tales: O GitHub da Década de 1930

Howard publicou grande parte de sua obra na lendária revista Weird Tales.

Imagine uma mistura de:

GitHub.

Medium.

Dev.to.

LinkedIn.

Revista científica.

Tudo ao mesmo tempo.

Era ali que escritores publicavam seus trabalhos.

Ali também estavam:

• H. P. Lovecraft;

• Clark Ashton Smith;

• Seabury Quinn.

Esses autores trocavam cartas constantemente.

Não existia Internet.

Não existia e-mail.

Mesmo assim construíram uma comunidade criativa extremamente ativa.

Era praticamente um Open Source da literatura.

---

Easter Egg nº 1

Howard e Lovecraft escreveram dezenas de cartas discutindo filosofia, história, religião e literatura.

Essas conversas influenciaram diretamente a criação dos universos de ambos.

É como acompanhar hoje uma longa discussão técnica entre os criadores do Linux e do Kubernetes.

---

Conan Não Foi Seu Primeiro Personagem

Essa talvez seja uma das maiores surpresas.

Antes de Conan vieram vários personagens.

Entre eles:

• Solomon Kane;

• Kull;

• Bran Mak Morn;

• Sailor Steve Costigan;

• El Borak.

Cada personagem explorava um aspecto diferente da natureza humana.

Conan acabou ficando famoso.

Mas Howard jamais escreveu apenas fantasia.

---

O Método Howard

Existe um depoimento famoso.

Howard dizia que não inventava Conan.

Ele apenas observava.

Segundo ele:

Conan "sentava-se ao seu lado" e contava suas aventuras.

Parece superstição.

Na verdade descreve algo conhecido por escritores.

Quando o personagem está suficientemente desenvolvido...

ele praticamente ganha vida.

Curiosamente acontece o mesmo com sistemas muito grandes.

Depois de décadas de evolução...

eles parecem possuir personalidade própria.

Todo veterano COBOL sabe disso.

---

O Código Invisível

Imagine um sistema legado.

Você abre um programa.

Não conhece quem escreveu.

Mas consegue perceber:

esse programador gostava de tabelas.

esse preferia PERFORM.

aquele utilizava GO TO.

outro fazia tudo modular.

Autores deixam assinaturas invisíveis.

Howard também.

Depois de alguns contos conseguimos identificar imediatamente seu estilo.

---

A Filosofia das Civilizações

Existe um tema recorrente.

Howard acreditava que:

civilizações crescem;

ficam ricas;

tornam-se burocráticas;

enfraquecem;

desaparecem.

Enquanto povos considerados "bárbaros" continuam evoluindo.

Essa ideia aparece em:

Conan.

Kull.

Bran Mak Morn.

É praticamente uma teoria sobre inovação.

---

Easter Egg nº 2

Décadas depois diversos historiadores observaram semelhanças entre a visão de Howard e teorias sobre ascensão e queda de impérios discutidas por autores como Oswald Spengler e Arnold Toynbee.

---

Howard e o Mainframe

Existe uma curiosidade interessante.

Mainframes também envelhecem.

Não porque fiquem ruins.

Mas porque acumulam conhecimento.

Um sistema bancário com cinquenta anos possui milhares de decisões incorporadas.

Howard descrevia reinos exatamente assim.

Castelos construídos sobre castelos.

Templos sobre templos.

Civilizações sobre civilizações.

É impossível não lembrar de aplicações COBOL que carregam decisões tomadas ainda na década de 1970.

---

Seus Personagens São Arquétipos

Conan representa sobrevivência.

Kull representa liderança.

Solomon Kane representa justiça.

Bran Mak Morn representa resistência.

El Borak representa adaptação cultural.

Cada personagem resolve um tipo diferente de problema.

Isso lembra orientação a objetos.

Cada classe possui responsabilidades específicas.

---

Howard Era Historiador?

Não oficialmente.

Mas estudava História compulsivamente.

Colecionava livros.

Pesquisava povos antigos.

Mitologias.

Armas.

Guerras.

Civilizações.

Grande parte do realismo presente em suas obras vem desse hábito.

---

Easter Egg nº 3

Howard frequentemente escrevia mapas completos dos reinos antes de produzir qualquer conto.

Décadas depois Tolkien faria algo semelhante.

Hoje chamamos isso de worldbuilding.

---

A Tragédia

Infelizmente sua vida terminou cedo.

Em 1936 sua mãe entrou em coma irreversível.

Howard possuía enorme ligação emocional com ela.

Ao saber que dificilmente despertaria, entrou em profunda crise.

No dia 11 de junho de 1936, aos 30 anos, disparou contra si mesmo. Morreu no dia seguinte, 12 de junho de 1936.

Sua mãe faleceu pouco depois.

Foi um desfecho trágico para um autor que produziu uma obra gigantesca em tão pouco tempo.

É importante tratar esse episódio com respeito. Ele não define sua contribuição literária, mas faz parte de sua história.

---

Quanto Howard Produziu?

Mesmo vivendo apenas trinta anos...

escreveu centenas de obras.

Entre elas:

• contos;

• poemas;

• cartas;

• ensaios;

• histórias de faroeste;

• boxe;

• horror;

• aventura;

• fantasia;

• ficção histórica.

Seu ritmo impressiona.

Era praticamente uma fábrica de criatividade.

---

Curiosidade Técnica

Howard escrevia em máquina de escrever.

Sem:

CTRL+Z.

Git.

Backup automático.

Cloud.

Auto Save.

Versionamento.

Se errasse uma página inteira...

precisava recomeçar.

Hoje reclamamos quando o IDE demora cinco segundos para abrir.

---

Easter Egg nº 4

Howard escreveu muitos contos por necessidade financeira.

Era um escritor profissional em uma época em que viver exclusivamente da escrita era extremamente difícil.

Cada conto vendido ajudava a sustentar sua vida cotidiana.

---

Howard Influenciou Quase Tudo

É difícil listar todos.

Mas encontramos sua influência em:

Dungeons & Dragons.

Warhammer.

Magic The Gathering.

Diablo.

The Witcher.

Elden Ring.

Dark Souls.

Berserk.

Record of Lodoss War.

Goblin Slayer.

Dragon's Dogma.

Skyrim.

Conan Exiles.

Pathfinder.

Praticamente toda fantasia de espada e feitiçaria moderna carrega algum traço de Howard.

Até mesmo muitos mangás e animes inspirados em fantasia medieval herdaram elementos que ele ajudou a consolidar: heróis errantes, reinos decadentes, ruínas de civilizações antigas e a mistura de aventura com horror cósmico.

---

Howard e Lovecraft

Os dois são frequentemente comparados.

Mas escreviam coisas completamente diferentes.

Lovecraft dizia:

O homem é insignificante diante do universo.

Howard dizia:

Mesmo diante de um universo hostil...

o homem ainda pode lutar.

Essa diferença explica Conan.

Explica Kane.

Explica Kull.

Howard acreditava na capacidade humana de reagir.

---

A Maior Lição para um Programador COBOL

Existe um motivo pelo qual Howard continua relevante quase cem anos depois.

Ele nunca escreveu pensando apenas na moda do momento.

Escreveu sobre:

coragem;

medo;

civilização;

mudança;

liderança;

ambição;

queda;

renascimento.

Esses temas nunca envelhecem.

O mesmo acontece com COBOL.

Linguagens mudam.

Frameworks aparecem e desaparecem.

Ferramentas recebem novos nomes.

Mas sistemas críticos continuam precisando de:

clareza;

confiabilidade;

resiliência;

manutenibilidade.

São princípios permanentes.

---

Curiosidades que Pouca Gente Conhece

Conan nunca encontrou Kull

Apesar de viverem no mesmo universo fictício, suas épocas são separadas por milhares de anos.

---

Howard praticava boxe

Seu interesse pelo esporte influenciou profundamente a maneira como descrevia combates: diretos, físicos e convincentes.

---

A correspondência de Howard é gigantesca

Suas cartas são consideradas uma fonte preciosa para entender seu processo criativo e sua visão sobre história e literatura.

---

A Era Hiboriana possui cronologia própria

Howard escreveu uma cronologia relativamente detalhada para manter consistência entre suas histórias, algo muito semelhante ao cuidado de manter uma arquitetura coerente em um sistema de grande porte.

---

O Verdadeiro Legado

Quando pensamos em Robert E. Howard, é fácil imaginar apenas um escritor de aventuras.

Isso seria uma enorme injustiça.

Ele foi um engenheiro de imaginação.

Construiu universos completos.

Projetou arquiteturas narrativas.

Definiu regras.

Criou padrões.

Produziu documentação.

Depois implementou centenas de histórias sobre essa base.

É exatamente o trabalho de um grande arquiteto de software.

---

Conclusão – O Arquiteto Invisível da Fantasia

Existe uma curiosa semelhança entre Robert E. Howard e os grandes profissionais de mainframe.

Ambos raramente recebem o reconhecimento proporcional ao impacto de seu trabalho.

Milhões de pessoas utilizam diariamente sistemas escritos em COBOL sem jamais saber quem desenvolveu aquelas aplicações. Da mesma forma, milhões assistem a filmes, jogam RPGs, leem mangás ou exploram videogames inspirados na fantasia heroica sem perceber que muitas das ideias fundamentais nasceram na mente de um jovem escritor texano.

Howard não apenas criou personagens inesquecíveis. Ele estabeleceu uma forma de construir mundos. Sua metodologia de planejamento, coerência histórica, geografia, política e cultura lembra a criação de uma arquitetura corporativa robusta, na qual cada componente possui uma função clara e faz sentido dentro do conjunto.

Conan ensinou coragem.

Kull ensinou liderança.

Solomon Kane ensinou investigação.

Mas o próprio Robert E. Howard ensinou algo ainda maior: antes de existir uma grande aplicação, precisa existir uma grande arquitetura.

No desenvolvimento de software, isso significa projetar antes de codificar.

Na literatura, significou construir um universo antes de escrever a primeira aventura.

Talvez seja por isso que, quase noventa anos após sua morte, suas histórias continuem vivas. Porque elas foram erguidas sobre fundamentos sólidos, assim como os melhores sistemas COBOL que ainda sustentam bancos, governos, seguradoras e empresas ao redor do mundo.

No fim das contas, Robert E. Howard nunca foi apenas um escritor.

Foi o arquiteto-chefe de uma plataforma criativa que continua sendo executada em produção pela imaginação da humanidade, release após release, geração após geração — um verdadeiro sistema legado de excelência, sem previsão de descontinuação.

Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

 

Bellacosa Mainframe apresenta Highschool of the Dead

☕ Um Café no Bellacosa Mainframe

Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

"Todo sistema é considerado confiável... até o primeiro desastre real. Highschool of the Dead mostra exatamente o que acontece quando o planeta inteiro perde o operador."

---

Ficha Técnica

Título Original: 学園黙示録 HIGHSCHOOL OF THE DEAD (Gakuen Mokushiroku: Highschool of the Dead)

Título Internacional: Highschool of the Dead

Autor (Mangá):

• Daisuke Satō (roteiro)

• Shōji Satō (arte)

Estúdio: Madhouse

Diretor: Tetsurō Araki

Composição da Série: Yōsuke Kuroda

Design de Personagens: Masayoshi Tanaka

Música: Takafumi Wada

Mangá

• Publicado entre 2006 e 2013

• Revista Monthly Dragon Age

Anime

• Lançamento: 5 de julho de 2010

• Exibição: julho a setembro de 2010

OVA

• Drifters of the Dead (2011)

Quantidade de episódios

• 12 episódios

• 1 OVA

---

Classificação

• 🔞 17+ (em muitos países)

• Violência extrema

• Sangue

• Terror

• Nudez parcial

• Conteúdo sexual

• Linguagem adulta

Não é um anime indicado para crianças.

---

Gêneros

• Horror

• Zumbis

• Sobrevivência

• Ação

• Suspense

• Ecchi

• Drama

• Pós-apocalipse

---

Sinopse

Tudo começa em uma manhã aparentemente comum.

Enquanto os alunos seguem sua rotina escolar, uma estranha epidemia transforma pessoas em mortos-vivos extremamente agressivos.

Em questão de minutos, a escola inteira se torna um cenário de massacre.

Takashi Komuro consegue escapar junto de alguns colegas, iniciando uma longa jornada para encontrar familiares, abrigo e respostas.

Mas rapidamente descobrem uma verdade:

Os mortos não são necessariamente o maior perigo.

Quando a sociedade deixa de existir, o verdadeiro monstro passa a ser o próprio ser humano.

---

Resumo da História

O anime acompanha um pequeno grupo de estudantes tentando sobreviver ao colapso da civilização japonesa.

Eles atravessam:

• escolas

• bairros residenciais

• estradas

• delegacias

• mansões

• cidades completamente destruídas

Cada episódio representa um novo desafio.

Não existe governo.

Não existe polícia.

Não existe exército funcional.

Não existe internet.

Não existe logística.

Tudo aquilo que sustentava a sociedade desapareceu em poucas horas.

---

Os Personagens

Takashi Komuro

O protagonista.

Não é o mais forte.

Não é o mais inteligente.

Mas possui algo extremamente importante:

Capacidade de tomar decisões sob pressão.

No universo Bellacosa Mainframe, ele seria o Operador Master durante um desastre de produção.

---

Rei Miyamoto

Especialista em combate com lança.

Representa o lado emocional do grupo.

É também quem mantém parte da humanidade dos sobreviventes.

---

Saeko Busujima

Talvez uma das personagens femininas mais populares dos animes.

Excelente espadachim.

Calma.

Precisa.

Controlada.

Ela lembra um Sysprog experiente:

Não desperdiça movimentos.

Não desperdiça recursos.

---

Saya Takagi

A arquiteta.

O cérebro.

Enquanto todos pensam em sobreviver ao próximo minuto, Saya pensa nas próximas semanas.

Ela é praticamente uma Analista de Sistemas.

---

Kōta Hirano

Especialista em armas.

No início parece apenas um nerd.

Depois demonstra enorme capacidade técnica.

É o equivalente ao especialista de infraestrutura que conhece profundamente as ferramentas.

---

Shizuka Marikawa

A enfermeira.

Representa logística, primeiros socorros e transporte.

Sem ela o grupo dificilmente sobreviveria.

---

A Temática

À primeira vista parece apenas um anime de zumbis.

Na realidade fala sobre:

• colapso social

• ética

• medo

• liderança

• sobrevivência

• egoísmo

• confiança

• adaptação

O vírus é apenas o gatilho.

O verdadeiro tema é:

Como seres humanos reagem quando toda estrutura desaparece.

---

O que existe de diferente?

Muitos animes possuem zumbis.

Pouquíssimos possuem:

Ritmo extremamente acelerado

O desastre começa nos primeiros minutos.

Não existe preparação.

O espectador entra imediatamente no caos.

---

Personagens relativamente "normais"

Não existem poderes mágicos.

Não existem espadachins lendários.

São estudantes comuns.

Isso aumenta muito a sensação de realismo.

---

Ação cinematográfica

O diretor Tetsurō Araki mais tarde faria enorme sucesso em Attack on Titan.

Já era possível perceber seu estilo:

• câmeras rápidas

• enquadramentos dramáticos

• tensão constante

---

Violência gráfica

Em 2010 poucos animes apresentavam um nível tão alto de violência.

---

Ecchi exagerado

É o aspecto mais controverso da obra.

Em vários momentos o fan service interrompe completamente a tensão.

Para alguns isso faz parte da identidade da série.

Para outros prejudica o horror.

---

As Aventuras

Cada arco representa uma etapa da sobrevivência.

• escapar da escola

• encontrar abrigo

• procurar familiares

• buscar alimentos

• fugir de saqueadores

• enfrentar grupos armados

• lidar com governos inexistentes

Não existe "missão principal".

A missão é continuar vivo.

---

As Mensagens Ocultas

A civilização é extremamente frágil

Levamos décadas para construir uma sociedade.

Podemos perdê-la em poucos dias.

---

O conhecimento vale mais que força

Saya salva o grupo inúmeras vezes usando inteligência.

Não músculos.

---

Liderança não depende de cargo

Takashi nunca foi líder.

As circunstâncias o obrigam a assumir essa função.

---

Recursos são limitados

Comida.

Combustível.

Remédios.

Munição.

Tudo acaba.

A sobrevivência depende de planejamento.

---

O medo transforma pessoas

Durante o anime vemos cidadãos comuns se tornando criminosos.

O verdadeiro vírus talvez seja o desespero.

---

Bellacosa Mainframe

O Grande ABEND Mundial

Imagine que a humanidade inteira seja um gigantesco ambiente IBM Z.

De repente acontece um desastre.

• JES2 para de controlar filas.

• CICS perde conectividade.

• DB2 deixa de responder.

• MQ interrompe mensagens.

• O operador desaparece.

• O WLM deixa de distribuir carga.

O ambiente continua ligado.

Mas não existe mais coordenação.

É exatamente isso que acontece em Highschool of the Dead.

Os zumbis são processos que continuam executando.

Consomem CPU.

Consumem memória.

Propagam corrupção.

Mas perderam completamente sua lógica de negócio.

Enquanto isso, os sobreviventes tentam manter o "Sistema Operacional Sociedade" funcionando.

Takashi torna-se o Incident Manager.

Saya atua como arquiteta.

Saeko é a equipe de resposta imediata.

Kōta administra os recursos críticos.

Shizuka representa Disaster Recovery.

No fundo, o anime inteiro pode ser interpretado como um enorme exercício de:

• Business Continuity

• Disaster Recovery

• Gestão de Incidentes

• Gestão de Crises

• Resiliência Operacional

---

Impacto Cultural

Quando estreou em 2010, Highschool of the Dead tornou-se um enorme sucesso.

Foi um dos responsáveis por popularizar novamente o gênero zumbi nos animes.

Influenciou diversas obras posteriores.

Também consolidou a reputação do estúdio Madhouse em animações de ação extremamente fluidas.

Até hoje permanece como referência quando se fala em animes de sobrevivência.

---

Houve censura?

Sim.

Este é um dos animes mais censurados de sua época.

Dependendo da emissora e do país, cenas receberam:

• escurecimento da tela (black shading);

• feixes de luz (light beams) para ocultar nudez;

• neblina ou fumaça digital;

• cortes de enquadramento;

• redução de violência gráfica.

As versões em Blu-ray removeram grande parte dessas censuras, apresentando a obra em sua forma originalmente produzida.

Além disso, alguns países restringiram sua classificação indicativa devido ao conteúdo sexual e à violência intensa.

---

Por que nunca ganhou uma segunda temporada?

Essa é uma das maiores frustrações dos fãs.

O mangá sofreu longos hiatos por problemas de saúde do roteirista Daisuke Satō. Em 2017, o autor faleceu, deixando a história inacabada. Sem material suficiente e sem uma conclusão oficial, uma continuação do anime nunca foi produzida.

---

Vale a pena assistir?

Mesmo anos após seu lançamento, Gakuen Mokushiroku: Highschool of the Dead continua relevante por combinar ação frenética, horror, suspense e discussões sobre comportamento humano em situações extremas. Embora o fan service possa dividir opiniões, a qualidade da animação, a direção dinâmica e a construção da tensão fazem dele um clássico do gênero zumbi nos animes.

Veredicto Bellacosa Mainframe

Se The Walking Dead mostra como administrar uma comunidade após o colapso, Highschool of the Dead retrata o momento exato em que o ambiente entra em falha catastrófica.

Para um profissional de IBM Z, é como acompanhar um ABEND sistêmico onde não há IPL, backup imediato ou equipe de plantão. Cada decisão precisa ser tomada com os recursos disponíveis, priorizando continuidade de serviço, resiliência e cooperação.

No fim, a grande lição da obra é clara: a tecnologia pode manter sistemas funcionando, mas são as pessoas, sua capacidade de adaptação e liderança, que determinam se uma organização — ou uma civilização — sobreviverá ao desastre.

 

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