☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

quarta-feira, 6 de maio de 2009

🏛️ CATÁLOGO DO CPD DO SÉCULO PASSADO — O FERRO QUE MANTINHA A EMPRESA FUNCIONANDO

 

Bellacosa Mainframe e a configuração de um CPD no século passado

☕ Um Café no Bellacosa Mainframe

🏛️ CATÁLOGO DO CPD DO SÉCULO PASSADO — O FERRO QUE MANTINHA A EMPRESA FUNCIONANDO

Mainframes, canais, DASD, fitas, controladoras, 3270, telecomunicações, gateways, RISC/UNIX, Pentium, impressoras e redes — uma autópsia técnica de um CPD corporativo da primeira metade dos anos 1990.



🎬 PRÓLOGO — NÃO ERA UM COMPUTADOR. ERA UMA CIDADE

Quando encontramos uma configuração antiga dizendo:

128 MB de memória.

É fácil pensar:

"Meu telefone tem milhares de vezes isso!"

Mas seu telefone não estava processando uma organização inteira enquanto atendia terminais, movimentava dezenas de discos, executava batch, controlava telecomunicações e alimentava impressoras industriais.

O CPD era uma arquitetura composta.

Nosso exemplar arqueológico possui dois mainframes, aproximadamente 105 GB de DASD, dezenas de unidades de fita, dezenas de canais, controladoras especializadas, gateways, servidores RISC/UNIX, servidores de LAN, centenas de PCs e impressão industrial.

Vamos abrir o catálogo.



🧠 1 — FUJITSU FACOM M-380

Fabricante: Fujitsu
Modelo: FACOM M-380
Tipo: Mainframe
Capacidade instalada informada: 15 MIPS
Memória: 32 MB
Canais: 16
Uso: processamento corporativo, batch e I/O.

FACOM M-380
│
├── 15 MIPS
├── 32 MB RAM
└── 16 canais

MIPS significa Millions of Instructions Per Second, mas não é MHz e tampouco permite comparar diretamente arquiteturas diferentes.

MSU: não determinado. Não existe uma fórmula universal MIPS → MSU aplicável honestamente a qualquer equipamento.



🦖 2 — IBM 3090-300S

O monstro central

Fabricante: IBM
Modelo provável: 3090-300S
Tipo: Mainframe
CPUs: 3
Capacidade do inventário: ≈60 MIPS
Memória central: 128 MB
Expanded Storage: 256 MB
Canais: 64
Uso: processamento corporativo central, batch e on-line.

3090-300S
│
├── 3 CPUs
├── ≈ 60 MIPS
├── 128 MB central
├── 256 MB expanded
└── 64 canais

Os 64 canais talvez sejam mais reveladores que os 60 MIPS. A máquina foi projetada para movimentar enormes volumes de I/O sem transformar a CPU em carregadora de dados.

MSU: não é possível determinar com segurança apenas desses dados.



⚠️ MIPS, MSU, MHz, TPS E MB/s NÃO SÃO A MESMA COISA

MétricaMede principalmente
MHzfrequência
MIPSinstruções por segundo
MSUcapacidade/service units
TPStransações por segundo
MB/stransferência de dados
IOPSoperações de armazenamento

Disco não tem MIPS. Impressora não tem MSU. E um servidor RISC não deve ser comparado ao 3090 usando benchmarks incompatíveis.



💾 3 — IBM 3990-2

Fabricante: IBM
Modelo: 3990 Model 2
Tipo: Storage Control Unit
Adaptadores de canal: 8
Uso: intermediar mainframe e DASD.

MAINFRAME
    │
  CANAIS
    │
   3990
    │
 ┌──┼──┐
DASD DASD DASD

É por isso que dizer que um mainframe simplesmente "tinha HD" empobrece completamente a arquitetura.


💽 4 — IBM 3380-K

Fabricante: IBM
Modelo: 3380-K
Tipo: DASD
Quantidade: 24
Capacidade total: ≈45 GB
Média resultante: ≈1,875 GB por dispositivo
Uso: arquivos, datasets, bancos de dados e produção.

45 GB ÷ 24 ≈ 1,875 GB

Hoje parece pouco. Naquele período representava infraestrutura corporativa capaz de guardar milhões de registros.


🗄️ 5 — AMDAHL 6100

Fabricante: Amdahl
Modelo: 6100
Tipo: controladora de armazenamento
Cache: 64 MB
NVS: 4 MB
Uso: gerenciamento e aceleração do DASD.

Aqui encontramos conceitos absolutamente atuais:

HOST
 ↓
CACHE
 ↓
CONTROLADORA
 ↓
DISCO

O NVS — Non-Volatile Storage — ajudava a proteger operações de escrita. Cache, write-back, persistência e latência não nasceram com NVMe.


💽 6 — AMDAHL 6390

Fabricante: Amdahl
Modelo: 6390
Tipo: DASD
Quantidade: 32
Capacidade total: ≈60 GB
Média: ≈1,875 GB/unidade.

Somando os dois subsistemas:

45 GB + 60 GB ≈ 105 GB

Na primeira metade dos anos 1990, 105 GB de DASD eram patrimônio tecnológico.


📼 7 — IBM 3480 A22/B22

Fabricante: IBM
Modelo: 3480 A22/B22
Quantidade: 32 dispositivos
Tipo: cartucho magnético de 1/2"
Capacidade: 200 MB/cartucho
Densidade: ≈38.000 bpi
Transferência: ≈3 MB/s
Uso: backup, batch, transporte e arquivamento.

O 3480 trabalhava com cartuchos de 200 MB e aproximadamente 3 MB/s. A fita não era simplesmente backup esquecido numa gaveta: participava ativamente da produção.


🎞️ 8 — IBM 3803-002 + IBM 3420

Fabricante: IBM
Controladora: 3803 Model 2
Drives: 2 × 3420
Tipo: fita magnética de carretel
Uso: batch, arquivos sequenciais e intercâmbio.

O inventário não identifica o modelo específico dos 3420. Portanto, não podemos atribuir uma velocidade única. A família teve modelos e densidades diferentes, inclusive 1.600 e 6.250 bpi.

Quando a plaqueta arqueológica não existe, escrevemos:

desconhecido.

Não inventamos.


📡 9 — NCR COMTEN 5690

Fabricante: NCR/Comten
Modelo: 5690
Tipo: Communications Processor
Linhas: 160
Memória: 4 MB
Uso: processamento de telecomunicações.

Isso era praticamente um computador dedicado a retirar trabalho de comunicação do host.

HOST
 ↓
COMTEN
 ↓
160 linhas

Offload não é exatamente uma invenção moderna.


📡 10 — IBM 3745

O senhor da rede SNA

Fabricante: IBM
Modelo: 3745 Communication Controller
Linhas instaladas: 256
CPUs: 2
Memória: 8 MB/CPU
Uso: SNA, NCP, X.25 e telecomunicações.

MAINFRAME
    │
   VTAM
    │
  CHANNEL
    │
   3745
    │
   NCP
    │
SNA / X.25

Era efetivamente um computador de comunicação. A arquitetura suportava DMA e diferentes interfaces e velocidades; documentação histórica mostra linhas chegando a centenas de Kbps e configurações de maior velocidade.


🖥️ 11 — IBM 3274

Fabricante: IBM
Modelo: 3274
Tipo: Terminal Control Unit
Quantidade: 2
Capacidade: 32 terminais/unidade
Total: até 64 terminais nessa configuração.

HOST
 │
3274
 ├── 3270
 ├── 3270
 └── 3270...

A documentação confirma que modelos do 3274 podiam controlar até 32 displays/impressoras, coerente com o inventário.


🌐 12 — IBM 3172

A ponte entre duas eras

Fabricante: IBM
Modelo: 3172 Interconnect Controller
Tipo: gateway LAN-host
Memória registrada: 1 MB
Interfaces: Token Ring + Ethernet + canal de mainframe
Uso: SNA/TCP-IP e integração LAN-mainframe.

        MAINFRAME
            │
         CHANNEL
            │
           3172
          /    \
 Token Ring   Ethernet

É praticamente a fotografia da Internet chegando ao castelo.


🔀 13 — IBM 2914-4X8

Fabricante: IBM
Modelo: 2914-4X8
Tipo: Channel Switching Unit
Uso: chaveamento de caminhos de canal.

Não executava COBOL nem armazenava cadastro. Era o cruzamento rodoviário do reino.


🌐 14 — ROTEADORES CISCO

Quantidade: 3
Modelo: não informado
Uso: conexão com a Internet.

Sem modelo não podemos atribuir CPU, RAM ou throughput.

Mas sua presença significa que naquele CPD já conviviam:

SNA + X.25 + Token Ring + Ethernet + TCP/IP + Internet.


🖨️ 15 A 19 — A GRÁFICA DO CPD

EquipamentoQuantidadeVelocidadeInterface/uso
Xerox 4090190 ppmprodução
Xerox 3010-12510 ppm cadacoaxial
Xerox 3010-15310 ppm cadaRS-232C
Xerox 97901120 ppmprodução industrial
IBM 32031120 lpmimpacto/listagens

A 9790 teoricamente podia produzir:

120 × 60 = 7.200 páginas/hora

ou 57.600 páginas em oito horas contínuas.

Impressão era infraestrutura de produção.


🐧 20 — IBM RISC SYSTEM/6000 MODEL 580

UNIX entra pela porta da frente

Fabricante: IBM
Modelo: RISC System/6000 580
Quantidade: 4
Arquitetura: RISC
Sistema: AIX
Memória: 384 MB cada
Discos: ≈8, 12, 12 e provavelmente 18 GB
Storage externo: 12 GB
Mídia: DAT 4 mm e CD-ROM
Rede: Ethernet, Token Ring e X.25 conforme máquina
Uso: Internet, correio, laboratório, cliente/servidor e bancos de dados.

Não converta isso para MSU.

O inventário traz algo corrompido como:

15 7,2 TPS

provavelmente um benchmark apresentado como 157,2, mas sem identificar o benchmark não devemos transformá-lo em "157,2 transações de negócio por segundo".


🖥️ 21 A 23 — OS SERVIDORES PC

Pentium 90 / NetWare

CPU: 90 MHz
RAM: 32 MB
Discos: 2 × 2 GB
Total: 4 GB
DAT: 4 mm
CD-ROM: sim.

Pentium 60 / NetWare

CPU: 60 MHz
RAM: 24 MB
Discos: 2 × 2 GB
Total: 4 GB.

Pentium 60 / Windows NT

CPU: 60 MHz
RAM: 24 MB
Disco: 1,6 GB.

No mesmo prédio conviviam:

MVS
AIX
NetWare
Windows NT
DOS
OS/2

Era praticamente uma conferência diplomática de sistemas operacionais.


💻 24 A 26 — 486SX, 486DX E 486DX2

O 486SX atendia perfeitamente muitas tarefas administrativas, terminais e emulação 3270.

O 486DX acrescentava FPU integrada.

O DX2 popularizou a duplicação interna do clock em relação ao barramento.

A grande transformação, porém, não era MHz.

Era cultural:

poder computacional estava deixando o CPD e chegando à mesa do usuário.


🌐 27 A 30 — A INFRAESTRUTURA DE LAN

O inventário possuía 12 concentradores/hubs.

Somando as portas informadas:

9 × 16 = 144
+ 32
+ 60
+ 32
------
≈ 268 portas

Havia ainda 1 EtherSwitch para segmentação.

Um enlace de 700 metros de fibra óptica possuía meio físico preparado para 100 Mbps, embora a Ethernet utilizada então trafegasse a 10 Mbps.

Excelente lição ainda válida:

capacidade do meio físico ≠ throughput da aplicação.

Os servidores menores também utilizavam DAT 4 mm para backup, enquanto o universo mainframe empregava 3480/3420.


🏰 CATÁLOGO RESUMIDO DO REINO

EquipamentoTipoQtde.Especificação principal
FACOM M-380Mainframe115 MIPS, 32 MB, 16 canais
3090-300SMainframe1≈60 MIPS, 128 MB + 256 MB, 64 canais
3990-2Storage controller18 adaptadores de canal
3380-KDASD24≈45 GB total
6100Storage controller164 MB cache + 4 MB NVS
6390DASD32≈60 GB total
3480Cartucho32200 MB, ≈3 MB/s
3803-002Tape controller1controla 3420
3420Reel tape2modelo não especificado
COMTEN 5690Comunicações1160 linhas, 4 MB
3745Comunicações1256 linhas, 2 CPUs, 8 MB/CPU
3274Terminal controller232 terminais/unidade
3172Gateway1canal + Ethernet + Token Ring
RoteadoresRede3Internet
2914-4X8Channel switch1chaveamento
4090Laser190 ppm
3010-12Laser510 ppm
3010-15Laser310 ppm
9790Produção1120 ppm
3203Impacto1120 lpm
RS/6000 580RISC/UNIX4384 MB cada
Pentium 90LAN server190 MHz, 32 MB, 4 GB
Pentium 60LAN server160 MHz, 24 MB, 4 GB
Pentium 60NT server160 MHz, 24 MB, 1,6 GB
486/PentiumWorkstations≈180desktops
HubsLAN12≈268 portas brutas
EtherSwitchLAN1segmentação
FibraBackbone700 mmeio 100 Mbps; uso 10 Mbps

⚠️ QUANTOS MIPS TINHA O CPD?

O inventário permite dizer aproximadamente:

FACOM M-380    ≈ 15 MIPS
3090           ≈ 60 MIPS
------------------------
TOTAL NOMINAL  ≈ 75 MIPS

Mesmo essa soma deve ser tratada como aproximação, pois envolve implementações distintas.

Não some artificialmente RS/6000, Pentium, controladoras e outros dispositivos a esses 75 MIPS.

E jamais faça:

60 MIPS × constante mágica = MSU

Isso seria numerologia de datacenter.


🧬 TRÊS ERAS NO MESMO PRÉDIO

O catálogo revela algo maior que especificações.

Era centralizada

Mainframe
Canais
DASD
3270
SNA
Batch

Era dos sistemas abertos

RISC
UNIX
TCP/IP
Ethernet

Era cliente/servidor

486
Pentium
Windows
NetWare
LAN

E uma quarta revolução já batia à porta:

Internet.


☕ EPÍLOGO — 75 MIPS QUE CARREGAVAM UM MUNDO

Olhando de 2026, podemos rir de 32 MB, 128 MB, 1,9 GB, 10 Mbps e cartuchos de 200 MB.

Seria como olhar para uma locomotiva a vapor e dizer:

"Meu carro anda mais rápido."

Você perdeu o ponto.

A pergunta correta é:

O que aquela infraestrutura mantinha funcionando?

Milhões de registros, aplicações corporativas, processamento batch, transações on-line, bancos de dados, redes, impressão industrial, backups, terminais remotos, SNA, X.25, TCP/IP e finalmente Internet.

Quando alguma coisa quebrava às 03:17 da madrugada, não existia:

REDEPLOY CONTAINER

Existiam operador, analista, programador, especialista de rede, especialista de storage, console, telefone, manuais e provavelmente uma xícara de café.

Aqueles gabinetes não eram simplesmente computadores.

Eram a infraestrutura física do negócio.

O hardware envelhece; a responsabilidade de manter o mundo funcionando não.

☕ Um Café no Bellacosa Mainframe

Onde 128 MB podiam governar um reino, 105 GB eram uma fortuna e 60 MIPS carregavam uma organização inteira nas costas.


terça-feira, 5 de maio de 2009

🥩 Churrasco: Mapa Completo dos Cortes

 

Bellacosa Mainframe em uma tarde de churrasco

🥩 Churrasco: Mapa Completo dos Cortes

Brasil 🇧🇷 x Argentina 🇦🇷 x Japão 🇯🇵

(ou: como o mesmo boi vira três filosofias de vida)

Se tem uma coisa que mainframer entende, é isso:
👉 o mesmo hardware pode ser usado de formas totalmente diferentes, dependendo do sistema operacional.

Com carne bovina é igual.

O boi é o mesmo.
O corte muda.
A cultura manda.

E o resultado… muda tudo.


🐂 O BOI É UM SÓ. O MODELO É QUE MUDA.

Tecnicamente:

  • Os músculos são os mesmos

  • A anatomia não muda de país para país

Mas cada cultura:

  • Enxerga o boi de um jeito

  • Corta de forma diferente

  • Valoriza partes diferentes

  • Cria nomes próprios (às vezes confusos)

👉 É como COBOL, PL/I e Java acessando o mesmo banco.


churrasco de picanha

🇧🇷 BRASIL – O MODELO “CHURRASCO ROOT”

O Brasil historicamente:

  • Simplificou os cortes

  • Pensou em grelha grande

  • Fogo alto

  • Peças inteiras

Cortes clássicos brasileiros

BrasilOnde ficaObservação
PicanhaTampa da alcatraÍcone nacional
Contra-filéLomboMuitas vezes sem subdivisão
AlcatraTraseiroCorte “coringa”
MaminhaPonta da alcatraMacia e suculenta
FraldinhaDiafragmaSabor intenso
CostelaCostelasTempo + paciência

📌 Easter egg brasileiro
Durante décadas, o Brasil:

“rodou em produção” sem separar ancho, chorizo e ribeye.
Tudo era contra-filé e pronto.


Churrasco de ancho

🇦🇷 ARGENTINA – O MODELO “PRECISÃO & TRADIÇÃO”

A Argentina olha para o boi como um engenheiro.

Aqui:

  • Cada músculo tem nome

  • Cada corte tem função

  • Menos tempero

  • Mais respeito à carne

Cortes argentinos famosos

ArgentinaEquivalente Brasil
Bife AnchoContra-filé (parte dianteira)
Bife de ChorizoContra-filé (parte traseira)
VacíoFraldinha
AsadoCostela
EntrañaDiafragma

📌 Ancho argentino
É praticamente o ribeye:

  • Muito marmorizado

  • Extremamente suculento

  • Rei das parrillas

👉 Se fosse TI: hardware premium sem overclock.


churrasco de sirioin de wagyu

🇯🇵 JAPÃO – O MODELO “QUALIDADE EXTREMA”

O Japão não discute “qual corte é melhor”.
Ele pergunta:

“Qual a qualidade absoluta desse corte?”

Aqui entra o Wagyu.

⚠️ Atenção:

Wagyu NÃO é corte.
É o tipo de boi.

Cortes japoneses comuns em anime e yakiniku

JapãoEquivalente
Karubi (カルビ)Costela / short rib
Riburo-su (リブロース)Ribeye
Sirloin (サーロイン)Contra-filé
Momo (もも)Coxão
Gyūtan (牛タン)Língua

📌 Karubi domina os animes:

  • Cortado fino

  • Muito marmorizado

  • Grelha rápida

  • Cena de amizade garantida


🌏 MAPA RESUMO – O MESMO CORTE, TRÊS NOMES

Região do boiBrasilArgentinaJapão
LomboContra-filéAncho / ChorizoSirloin
Costela altaCostelaAsadoKarubi
DiafragmaFraldinhaVacío—
TraseiroAlcatraCuadrilMomo
Língua——Gyūtan

🥚 Easter Eggs Carnívoros

🥚 A picanha:

  • Não é tão valorizada fora do Brasil

  • Virou símbolo nacional mais por cultura do que por técnica

🥚 No Japão:

  • Marmorização é pontuada (A3, A4, A5)

  • Gordura ≠ defeito

  • Gordura = arte

🥚 Na Argentina:

  • Sal grosso e fogo

  • Nada de exagero

  • Carne fala sozinha


☕ Tradução para Mainframers

  • Brasil = sistema robusto, simples, parrudo

  • Argentina = arquitetura refinada, bem segmentada

  • Japão = altíssima performance, custo alto, precisão absoluta

Nenhum está errado.
Cada um resolve um problema diferente.


🧠 Comentário Bellacosa Mainframe

Entender cortes é como entender sistemas:

  • Não existe “o melhor”

  • Existe o mais adequado

  • Para o contexto

  • Para o momento

  • Para a carga

E no fim…
O boi agradece quando é bem tratado
E o operador também.


JOB FINALIZADO
RC=0
SYSOUT: “Fome aumentou consideravelmente.” 🥩🔥

segunda-feira, 4 de maio de 2009

🦇 O QUE É O MOVIMENTO DARK/GÓTICO?

 

Bellacosa Mainframe relembra o movimento Dark Gotico

🦇 O QUE É O MOVIMENTO DARK/GÓTICO?

O movimento gótico (ou dark) é uma subcultura que mistura:

  • 🎵 Música (pós-punk, gothic rock, darkwave, industrial)
  • 🖤 Estética (preto, maquiagem dramática, visual vitoriano ou cyber)
  • 🧠 Filosofia (existencialismo, romantismo sombrio, crítica social)
  • 🎭 Arte (literatura, cinema, moda)

👉 Surgiu como uma evolução do punk — mais introspectiva, atmosférica e artística.


🌍 ORIGEM GLOBAL (RAIZ DO SISTEMA)

🇬🇧 Inglaterra – Final dos anos 70 / início dos 80

💾 Processo histórico (pipeline):

PUNK (1977) → PÓS-PUNK → GOTHIC ROCK

🔥 Bandas fundadoras:

  • Bauhaus → música “Bela Lugosi’s Dead” (marco zero)
  • Siouxsie and the Banshees
  • The Cure
  • Joy Division

💡 Insight Bellacosa:

O gótico é como um “fork do punk” — mesma base, mas com outro mindset e estética.


🇧🇷 CHEGADA NO BRASIL (IMPORT DO SISTEMA)

📀 Anos 80 – Entrada via pós-punk e underground

📍 Epicentro: São Paulo

  • Casas como o lendário Madame Satã
  • Mistura de punk, new wave, industrial e dark

💾 Fluxo brasileiro:

IMPORT (UK/Europa) → ADAPTAÇÃO → IDENTIDADE BRASILEIRA

🦇 BANDAS GÓTICAS BRASILEIRAS (STACK NACIONAL)

🔥 Clássicas / Raiz

  • Violeta de Outono
  • Arte no Escuro
  • Cabine C
  • Voluntários da Pátria

🧪 Industrial / Darkwave / Electro

  • Escarlatina Obsessiva
  • Hocico (não BR, mas MUITO influente aqui)

🌑 Cena mais recente / alternativa

  • Plastique Noir
  • Gangue Morcego

🌍 BANDAS INTERNACIONAIS IMPORTANTES

  • The Sisters of Mercy
  • Fields of the Nephilim
  • Clan of Xymox
  • Dead Can Dance

🧠 FILOSOFIA DO MOVIMENTO

👉 Diferente do que muita gente pensa:

❌ Não é sobre depressão
✔️ É sobre estética da melancolia, reflexão e arte

📚 Influências:

  • Edgar Allan Poe
  • H. P. Lovecraft
  • Dracula

💡 Insight Bellacosa:

O gótico é tipo um “dump analysis emocional” — explorar o lado oculto do sistema humano 😄


🕶️ ESTÉTICA E VISUAL (INTERFACE DO SISTEMA)

  • Preto dominante 🖤
  • Roupas vitorianas / couro / renda
  • Maquiagem forte (olhos escuros)
  • Referências vampirescas e românticas

🔥 CURIOSIDADES (EASTER EGGS)

🥚 Easter Egg #1 – Bela Lugosi

A música “Bela Lugosi’s Dead” homenageia o ator:

  • Bela Lugosi

👉 Ele interpretou Drácula e virou símbolo eterno do gótico.


🥚 Easter Egg #2 – Madame Satã

O nome do clube vem de:

  • Madame Satã

👉 Figura icônica da contracultura brasileira.


🥚 Easter Egg #3 – The Cure não queria ser gótico

  • Robert Smith já disse várias vezes que não curtia o rótulo “gótico”

👉 Mas o sistema já tinha classificado 😄 (tipo job em produção…)


🥚 Easter Egg #4 – Gótico ≠ Emo

  • Emo → emocional, hardcore melódico
  • Gótico → atmosférico, artístico, sombrio

⚙️ ARQUITETURA DO MOVIMENTO (MODELO MAINFRAME 😄)

INPUT: Punk + Arte + Literatura sombria
PROCESSAMENTO:
- Pós-punk
- Darkwave
- Industrial
OUTPUT:
- Música
- Moda
- Filosofia
- Comunidade underground

🧠 O QUE VOCÊ PRECISA SABER (RESUMO EXECUTIVO)

✔️ Surgiu no pós-punk inglês
✔️ Chegou ao Brasil nos anos 80 (SP como hub)
✔️ Mistura música + arte + filosofia
✔️ Tem cena brasileira forte (underground até hoje)
✔️ Não é só estética — é identidade cultural


REXX no z/OS: Guia Completo com História, Dicas e Curiosidades

 

Bellacosa Mainframe apresenta IBM Mainframe REXX

REXX no z/OS: Guia Completo com História, Dicas e Curiosidades



1. Introdução ao REXX

REXX, sigla para REstructured eXtended eXecutor, é uma linguagem de programação de alto nível criada por Mike Cowlishaw, da IBM, na década de 1980.
Diferente de linguagens tradicionais como C, COBOL e PL/I, REXX é interpretada, de fácil leitura e sem tipagem explícita. Todos os dados são tratados como strings, e o sistema decide quando fazer conversão para números.

💡 Curiosidade: Apesar de muitos acharem que o nome veio do cachorro de Cowlishaw, isso é um mito urbano do Mainframe.

REXX se espalhou por todos os principais ambientes IBM: z/OS, z/VM, z/VSE, IBM i, AIX, e até ferramentas modernas IBM. Por isso, é considerada uma linguagem universal no ecossistema IBM.


2. Variáveis e Literais

  • Variáveis não são case sensitive. Ou seja, var, VAR ou Var são a mesma variável.

  • REXX não exige declaração de tipo e nem comprimento específico, embora existam limites definidos pelo sistema.

  • Literals (strings constantes) podem ser colocadas entre aspas simples '...' ou duplas "...", sem diferença funcional.

💡 Dica: Sempre use aspas quando o conteúdo tiver espaços ou caracteres especiais.


3. Funções e Subrotinas

  • Subrotinas (CALL) não precisam retornar valores. Elas executam ações e podem usar RETURN apenas para voltar ao ponto de chamada.

  • Funções são chamadas para produzir valores, mas nem todas podem ser usadas como subrotinas.

  • Ponto de atenção: Não confunda subrotinas com funções – tentar chamar algumas funções como CALL pode gerar erro.


4. Entrada de Dados

Existem três fontes principais:

  1. Command Line / Argumentos:

    • Usados para passar parâmetros para o exec.

    • Sintaxe:

      PARSE ARG nome idade
    • Ex.: %‘meuexec’ JOAO 30

  2. Stack (Data Stack):

    • Mecanismo central de entrada em REXX.

    • Comandos:

      PULL var /* Lê do topo da stack */ PARSE PULL a b c /* Lê e divide em variáveis */
    • Pode receber dados de QUEUE, PUSH ou teclado (quando stack está vazia).

  3. Keyboard (Interativo):

    • Se a stack estiver vazia, PULL lê do teclado no ambiente interativo (TSO/E).

💡 Dica: PARSE PULL é como um canivete suíço: lê e separa os dados ao mesmo tempo.
Exemplo avançado:

QUEUE "ABC-123-XYZ" PARSE PULL a "-" b "-" c SAY a b c /* Resultado: ABC 123 XYZ */

5. Manipulação de Arquivos

  • EXECIO funciona com:

    • Sequential datasets

    • PDS / PDSE members

  • Não funciona diretamente com VSAM.

    • Para VSAM, use:

      • ISPF Data Set Services (ISRSUPC, ISRSDSN)

      • Chamada de utilitários MVS (ex.: IDCAMS)

💡 Exemplo simples de leitura de VSAM via ISPF:

ADDRESS ISPEXEC "LIBDEF MYLIB DATASET ID('MY.VSAM.DATASET')" "READ DSNAME(MY.VSAM.DATASET) OUTDATA(myArray)"

6. Comando LINEOUT()

  • Escreve linha a linha, não permite random access.

  • Sempre escreve na ordem sequencial do arquivo ou data set.

💡 Dica: Para manipular arquivos VSAM de forma controlada, combine ISPF services e arrays REXX.


7. Stack e PULL

  • PULL remove registros do topo da stack.

  • Alguns materiais citam acesso ao “fundo da stack”, mas na prática, o topo é a forma padrão de leitura.

  • QUEUE e PUSH permitem inserir dados na stack de forma controlada.


8. Execução e Ambiente

  • System REXX execs rodam em:

    • Console (z/OS)

    • Batch (JCL / MVS)

    • Programas via REXX Macro Interface

Não rodam diretamente em TSO/E como System exec.

  • Host command environment depende do contexto:

    • TSO/E → ADDRESS TSO

    • Batch → ADDRESS MVS

    • ISPF → ADDRESS ISPEXEC

💡 Dica de ouro: Nunca presuma que TSO é o padrão universal. Cada address space tem seu ambiente próprio.


9. ISPF e Serviços REXX

  • ISPF fornece serviços avançados (ISPEXEC) para criar:

    • Macros de edição

    • Manipulação de datasets

    • Painéis interativos

  • ⚠️ ISPF é principalmente para online, não para batch (a menos que configurado explicitamente).

💡 Easter Egg: Você pode escrever comandos de edição personalizados diretamente em REXX, algo que programadores z/OS amam usar para automatizar tarefas repetitivas.


10. Indentação e Compilação

  • REXX ignora indentação, tanto no interpretador quanto no compilador.

  • Compilação é opcional – você pode rodar execs diretamente no interpretador.


11. Curiosidades e Fatos Divertidos

  • Mike Cowlishaw nunca nomeou REXX após seu cachorro – é apenas uma lenda urbana.

  • REXX é usado em automação de Mainframe desde os anos 80.

  • É comum combinar REXX + ISPF + JCL + batch jobs para criar soluções totalmente automáticas em produção.


12. Resumo de Comandos Essenciais

Comando / FunçãoUso
PARSE ARGLer argumentos passados na linha de comando
PULL / PARSE PULLLer registros da stack
QUEUE / PUSHInserir dados na stack
EXECIOLer/escrever sequential e PDS/PDSE
LINEOUT()Escrever linhas sequenciais em arquivos
ISPEXEC servicesTrabalhar com VSAM, painéis e macros ISPF
ADDRESSDefinir host command environment

13. Pontos de Atenção para Mainframe

  • Nunca confunda funções com subrotinas.

  • Stack é sequencial, não aleatória.

  • EXECIO não acessa VSAM diretamente.

  • ISPF serviços são para online, não para batch.

  • Indentação é estética, não funcional.

  • Variáveis não têm tipagem, mas cuidado com operações numéricas implícitas.


14. Exemplo Final Integrado

/* REXX Example: Stack + Parsing + File Write */ QUEUE "JOAO 30 SAO_PAULO" PARSE PULL nome idade cidade SAY "Nome:" nome ", Idade:" idade ", Cidade:" cidade /* Write to a sequential file */ EXECIO 1 LINEOUT ("Nome:" nome) DATASET("USER.SEQ.DATA") STEM file. WAIT

Combina stack, PARSE PULL, e EXECIO.


Conclusão

REXX continua sendo uma ferramenta essencial para automação no Mainframe IBM.
Sua simplicidade, flexibilidade e integração com ISPF, TSO/E, batch e VSAM o tornam um verdadeiro canivete suíço para administradores e desenvolvedores Mainframe.

E lembre-se: não caia nos mitos – REXX não foi nomeado por um cachorro, mas por sua estrutura e poder de execução. 😉


domingo, 3 de maio de 2009

🜂 O Panteão Tupi-Guarani em Modo Produção

 

Bellacosa Mainframe apresenta o panteão tupi-guarani para padawans

🜂 O Panteão Tupi-Guarani em Modo Produção

para mainframers, otakus e curiosos que sabem que todo sistema antigo ainda roda porque foi bem projetado


1. Introdução — quando os deuses ainda rodavam on-premise

Se você trabalha com mainframe, você já entendeu uma verdade incômoda do mundo moderno:
o que é antigo nem sempre é obsoleto — é apenas bem construído.

E se você gosta de anime, você também percebeu outra coisa: toda grande história nasce de um panteão, de entidades que regem leis invisíveis, forças naturais, ciclos e consequências. Nada acontece “porque sim”. Tudo responde a regras.

Agora segura essa ideia e pisa em solo brasileiro antes da chegada dos europeus.

Aqui, muito antes de servidores, nuvens e datacenters, os povos Tupi-Guarani já operavam um sistema completo de explicação do mundo — um panteão funcional, profundamente integrado à natureza, à ética e à sobrevivência coletiva.

Não era religião no sentido moderno.
Era arquitetura cósmica operacional.


2. O erro comum: chamar de “mitologia” como quem diminui

Quando falamos em “deuses gregos” ou “kami japoneses”, usamos respeito.
Quando falamos dos deuses indígenas, muita gente chama de “lendas”.

Erro grave de classificação.

O panteão Tupi-Guarani não era fantasia escapista. Era manual de operação da vida.

Cada divindade:

  • explicava fenômenos naturais,

  • regulava comportamento social,

  • ensinava limites,

  • reforçava ciclos,

  • e mantinha o sistema estável.

Mainframer entende: isso não é superstição.
Isso é governança.


3. Nhanderu — o arquiteto do sistema 🌀

No topo da hierarquia não está um “deus bravo com raio”, mas Nhanderu (ou Nhanderu Tenondé).

Ele não é personagem ativo do dia a dia.
Ele é o arquiteto original.

Nhanderu:

  • cria o mundo pela palavra,

  • estabelece as leis,

  • define os ciclos,

  • e depois se afasta da operação direta.

Tradução técnica:
➡️ System Designer + Governance Model

Ele não interfere em cada evento. O sistema deve funcionar por si.

Anime parallel: aquele criador que estabelece o mundo e desaparece, deixando os espíritos e forças cuidarem do runtime.


4. Tupã — não é “o deus supremo” (e aqui está o easter egg) ⚡

Aqui entra um erro histórico clássico.

Muita gente aprende que Tupã é “o deus maior”.
Não exatamente.

Tupã é a manifestação do poder, especialmente:

  • trovão,

  • relâmpago,

  • som,

  • energia,

  • sinal.

Ele é a voz audível da criação.

Para os Tupi-Guarani, Tupã não governa tudo — ele executa.

Mainframe translation:
➡️ Tupã é o subsystem de energia e comunicação, não o dono do sistema.

Easter egg histórico: missionários europeus reforçaram Tupã como “deus supremo” porque trovão lembra castigo divino cristão. Mas isso é fork mal documentado.


5. Jaci — a guardiã dos ciclos e do tempo 🌙

Jaci, a Lua, é uma das entidades mais importantes — e menos compreendidas.

Ela governa:

  • o tempo noturno,

  • a fertilidade,

  • o crescimento,

  • os sonhos,

  • os ciclos femininos,

  • o descanso.

Sem Jaci, o mundo entra em estado instável.

Ela não pune.
Ela regula.

No anime, Jaci seria aquela entidade silenciosa que nunca luta, mas sem a qual o mundo colapsa.

Mainframe analogy:
➡️ Scheduler + Clock do sistema

Se você ignora Jaci, você executa processo fora do horário — e paga o preço.


6. Guaraci — o Sol que não perdoa ☀️

Guaraci, o Sol, é força ativa, crescimento, esforço, clareza.

Ele:

  • amadurece as plantas,

  • fortalece o corpo,

  • ilumina o caminho,

  • cobra trabalho.

Mas atenção: Guaraci também castiga excessos.

Trabalhar demais sob o sol mata.
Ignorar o descanso quebra o corpo.

Tradução técnica:
➡️ CPU em full load sem controle térmico

Guaraci ensina algo que todo mainframer aprende cedo:
performance sem limite destrói hardware.


7. Anhangá — o erro de interpretação mais injusto 😈

Durante séculos, Anhangá foi tratado como “demônio”.

Isso é uma distorção brutal.

Anhangá é o espírito do erro, do engano, da ilusão.

Ele:

  • confunde caçadores,

  • protege animais,

  • pune ganância,

  • cria armadilhas mentais.

Ele não é mau.
Ele é teste de sanidade.

Anime analogy: aquele trickster que não mata, mas ensina da pior forma possível.

Mainframe view:
➡️ Fault Injection + Chaos Agent

Se você cai no Anhangá, o problema não é ele — é você.


8. Curupira — já falamos dele, mas ele merece status divino 🌿

Embora muitas vezes classificado como entidade menor, Curupira atua como daemon de proteção ambiental.

Ele:

  • detecta exploração excessiva,

  • confunde rastros,

  • quebra a lógica do invasor.

Curupira não fala muito.
Ele age.

Anime parallel: guardião de dungeon que só ativa quando regras são quebradas.


9. Iara — controle de acesso emocional 🌊

Iara governa rios, lagos e o desejo humano.

Ela não mata todo mundo.
Ela seleciona.

Ela aparece para:

  • os distraídos,

  • os arrogantes,

  • os que subestimam o ambiente.

Iara é engenharia social aquática.

No mundo anime, ela seria aquela entidade bela e fatal que testa maturidade emocional.


10. O panteão como sistema distribuído

Aqui está o ponto que o mainframer entende rápido:

O panteão Tupi-Guarani não é centralizado.

Não existe um único deus mandando em tudo.
Existem múltiplas entidades, cada uma responsável por uma camada.

  • Criação → Nhanderu

  • Energia → Tupã

  • Tempo → Jaci

  • Execução → Guaraci

  • Erro → Anhangá

  • Segurança → Curupira

  • Interface emocional → Iara

Isso é arquitetura distribuída, não monolito.


11. Por que isso conversa tão bem com anime?

Porque o Japão fez exatamente isso com seus kami.

Espíritos:

  • não são bons ou maus,

  • respondem a regras,

  • punem excessos,

  • recompensam equilíbrio.

O Brasil tinha tudo isso — mas escolheu esquecer.


12. Curiosidades e easter eggs culturais 🥚

  • Muitos nomes de cidades vêm dessas entidades.

  • Expressões populares carregam ecos desses deuses.

  • O medo da mata à noite não é irracional — é herança simbólica.

  • A ideia de “pedir licença” à natureza vem diretamente do panteão.


13. Dicas para quem cria mundos, games ou histórias

Se você escreve, cria RPG ou ama worldbuilding:

  • Use o panteão Tupi-Guarani como base, não caricatura.

  • Pense nas entidades como funções, não personagens humanos.

  • Dê consequência às ações.

  • Evite maniqueísmo.

Isso gera mundos mais ricos do que copiar deuses gregos pela centésima vez.


14. Comentário final Bellacosa Mainframe ☕💾

Talvez o maior bug cultural brasileiro tenha sido desligar esse sistema achando que era coisa do passado.

O panteão Tupi-Guarani não é atraso.
É software maduro, testado por séculos, executado em ambiente hostil, com altíssima resiliência.

Enquanto o mundo corre atrás de mitologias importadas, a nossa dorme em cold storage — intacta, esperando restore.

E quem sabe, quando a gente aprender a ouvir de novo, descubra que esses deuses nunca foram embora.

Eles só ficaram em silêncio, observando se o operador atual merece acesso ao sistema.

🜂 JOB FINALIZADO — RC=0000

sábado, 2 de maio de 2009

SMP/E: RECEIVE, APPLY e ACCEPT na vida real - Parte 4

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 4 – RECEIVE, APPLY e ACCEPT na vida real

“SMP/E não é teoria.
É JCL rodando às 3 da manhã… e tem que dar RC=0.”


🧠 O fluxo sagrado do SMP/E

No mundo real, todo SYSMOD passa obrigatoriamente por três fases:

RECEIVE → APPLY → ACCEPT

👉 Pular etapa não é atalho.
É atalho para incidente.


📥 RECEIVE — trazendo o SYSMOD para casa

O que o RECEIVE faz?

  • Lê o PTF/APAR/FUNCTION

  • Registra no CSI

  • Torna o SYSMOD conhecido pelo SMP/E

📌 RECEIVE não muda o sistema.


Exemplo de JCL (simplificado)

SET BDY(GLOBAL). RECEIVE SYSMODS.

👉 Fontes comuns:

  • IBM Shopz

  • FTP

  • Portable datasets


Erros comuns no RECEIVE

  • SYSMOD duplicado

  • FMID inexistente

  • CSI incorreto

💡 Dica Bellacosa:

“RECEIVE falhou? Nem pense em APPLY.”


🧪 APPLY — onde o risco começa

O que o APPLY faz?

  • Copia módulos para TARGET libraries

  • Atualiza o sistema executável

  • Respeita VER, HOLD e ERROR

👉 Aqui o código passa a existir de verdade.


APPLY CHECK (obrigatório!)

SET BDY(TARGET). APPLY CHECK.

Ele mostra:

  • Conflitos

  • Dependências

  • HOLDs

  • ERRORs

📌 Nunca pule o CHECK.


APPLY real

SET BDY(TARGET). APPLY.

📌 Pode exigir:

  • IPL

  • Parada de subsistema

  • Ação manual


Erros comuns no APPLY

  • Ignorar ++HOLD

  • APPLY direto em produção

  • Não validar impacto

👉 Aqui nascem as histórias de guerra.


📦 ACCEPT — consolidando a verdade

O que o ACCEPT faz?

  • Atualiza o DLIB

  • Define o baseline oficial

  • Prepara futuras manutenções

📌 ACCEPT não muda o sistema executável.


Exemplo de JCL

SET BDY(DLIB). ACCEPT.

Erros comuns no ACCEPT

  • ACCEPT sem teste

  • ACCEPT em ambiente errado

  • DLIB desatualizado

💡 Dica Bellacosa:

“ACCEPT é compromisso. Não faça de cabeça quente.”


🧩 Quem mexe em quê?

ComandoAfetaExecutável?
RECEIVECSI❌
APPLYTARGET✅
ACCEPTDLIB❌

🔄 Rollback existe (mas dói)

RESTORE

  • Reverte APPLY

  • Não é trivial

  • Depende do histórico

👉 Rollback não é Ctrl+Z.


🧠 Caso real (estilo Bellacosa)

Um PTF aplicado sem APPLY CHECK
ignorou um ++HOLD de IPL
Resultado: JES instável pós-manutenção

📌 Moral:

O SMP/E avisou. Alguém não leu.


🎓 Boas práticas de produção

  • Sempre APPLY CHECK

  • Leia HOLDS

  • Separe ambientes

  • Documente ACCEPTs

  • Nunca automatize cegamente


🧠 Curiosidades Bellacosa

  • RECEIVE é burocracia

  • APPLY é tensão

  • ACCEPT é responsabilidade


🧾 Comentário final – Parte 4

RECEIVE informa.
APPLY muda.
ACCEPT oficializa.

Quem entende isso domina o SMP/E.


📌 Próxima Parte da Série

👉 Parte 5 – Laboratório SMP/E: Workshop prático passo a passo


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...