Translate

sexta-feira, 15 de maio de 2015

📚 O Grande Bestiário da Fantasia : Volume V Dungeons & Dragons

 

Bellacosa Mainframe e o grande bestiario da fantasia parte v

☕ Um Café no Bellacosa Mainframe

📚 O Grande Bestiário da Fantasia

Das Revistas Pulp aos Animes Modernos

Volume V

Dungeons & Dragons

Quando a Fantasia Deixou de Ser Apenas Lida... e Passou a Ser Vivida

"Durante milhares de anos, as pessoas ouviram histórias. Depois começaram a lê-las. Em 1974 aconteceu algo completamente novo: pela primeira vez, qualquer pessoa podia entrar na história e decidir o destino do herói. Nascia Dungeons & Dragons."


☕ Bellacosa Time Machine

Destino: Lake Geneva, Wisconsin

Ano: 1974

Não existe internet.

Não existe MMORPG.

Não existe Steam.

Não existe PlayStation.

Nem computador doméstico.

Dentro de uma pequena sala...

Alguns adultos movimentam miniaturas sobre uma mesa.

Rolam dados estranhos.

Consultam folhas de papel.

Discutem regras.

Riem.

Brigam.

Improvisam.

Lá fora...

Ninguém faz ideia.

Ali está nascendo praticamente toda a fantasia interativa moderna.


Antes de Existir RPG...

Existiam Jogos de Guerra

Durante décadas.

Militares.

Historiadores.

E entusiastas.

Jogavam Wargames.

Mapas.

Soldados.

Canhões.

Exércitos.

Tudo extremamente estratégico.

Mas havia um problema.

Você controlava...

um exército.

Nunca...

um herói.


Gary Gygax

Nascido em:

27 de julho de 1938

Apaixonado por:

História.

Miniaturas.

Jogos de guerra.

Mitologia.

Fantasia.

Era um criador compulsivo.

Adorava inventar regras.

Criar sistemas.

Resolver problemas.

Se fosse programador COBOL...

Provavelmente teria criado um framework inteiro apenas para organizar COPYBOOKs.


Dave Arneson

Alguns anos mais jovem.

Também apaixonado por jogos.

Mas possuía uma característica diferente.

Gostava de improvisar.

Criava personagens.

Interpretava.

Inventava histórias.

Misturava estratégia com narrativa.

Sem perceber...

Estava inventando um novo gênero.


O Momento "E Se?"

Imagine dois programadores.

Um domina arquitetura.

Outro domina criatividade.

Um dia alguém pergunta:

"E se...

em vez de controlar um exército...

controlássemos apenas um guerreiro?"

Silêncio.

Cinco segundos.

Pronto.

A História mudou.


Blackmoor

Antes de D&D.

Existiu:

Blackmoor.

Uma campanha criada por Dave Arneson.

Os jogadores deixavam de comandar milhares de soldados.

Agora...

Controlavam:

um aventureiro.

Um ladrão.

Um guerreiro.

Um mago.

Era algo completamente novo.


O Nascimento de Dungeons & Dragons

Gary Gygax e Dave Arneson unem ideias.

Publicam uma pequena caixa.

Poucas páginas.

Nenhum grande investimento.

Nenhuma campanha milionária.

Apenas criatividade.

Nascia:

Dungeons & Dragons

Provavelmente o jogo mais influente da fantasia moderna.


O DNA de D&D

Muita gente pensa que D&D inventou tudo.

Na verdade...

Ele reuniu décadas de inspiração.

Howard trouxe o bárbaro.

Tolkien trouxe os povos fantásticos.

Lovecraft trouxe o horror cósmico.

Mitologias trouxeram monstros.

Frazetta deu aparência.

Os wargames forneceram as regras.

D&D compilou tudo.


As Classes

Uma ideia genial.

Em vez de todos serem iguais.

Cada personagem possui um papel.

Guerreiro.

Mago.

Clérigo.

Ladrão.

Depois surgiriam dezenas de outras classes.

Hoje parece normal.

Na época...

Era revolucionário.


Os Dados

Outro detalhe curioso.

Quem nunca jogou...

Estranha.

Dados de:

4 lados.

6 lados.

8 lados.

10 lados.

12 lados.

20 lados.

Parecem artefatos mágicos.

Na prática...

São motores estatísticos.

Cada lançamento representa incerteza.

É quase um gerador de eventos aleatórios.


O Mestre

Talvez a maior invenção.

O Dungeon Master.

Ele não joga contra.

Não joga a favor.

Ele interpreta...

o universo.

É clima.

É narrativa.

É monstros.

É cidades.

É política.

É economia.

É improviso.

Se fosse um Data Center...

O Mestre seria o sistema operacional.


O Primeiro Sandbox

Hoje ouvimos muito essa palavra.

Sandbox.

Mundo aberto.

Mas D&D fazia isso décadas antes.

Você pode:

ignorar o rei.

entrar na floresta.

roubar uma carroça.

abrir uma taverna.

comprar um barco.

virar mercador.

morrer para um goblin.

Nada impede.


Goblins Nunca Foram Tão Perigosos

Curiosamente...

Os goblins de D&D eram perigosos.

Não porque fossem fortes.

Mas porque:

atacavam em grupo.

faziam emboscadas.

conheciam cavernas.

preparavam armadilhas.

Reconhece alguém?

Goblin Slayer.


A Economia da Fantasia

Pouca gente percebe.

Existe dinheiro.

Hospedagem.

Comércio.

Mercadores.

Ferreiros.

Aluguel.

Navios.

Caravanas.

Tudo isso inspiraria videogames décadas depois.


Magia Não Era Gratuita

Outro detalhe perdido.

Magos decoravam feitiços.

Gastavam energia.

Precisavam descansar.

Escolhiam quais magias preparar.

Nada de disparar centenas de bolas de fogo.

Cada decisão importava.


O Grupo

Talvez a maior lição.

Nenhum herói vence sozinho.

O guerreiro precisa do clérigo.

O clérigo precisa do ladrão.

O ladrão precisa do mago.

O mago precisa de todos.

É um exercício de cooperação.


O Caos Criativo

Existe algo maravilhoso.

Os criadores nunca imaginaram tudo.

Os próprios jogadores expandiram o sistema.

Criaram:

novos mundos.

novas regras.

novos monstros.

novas campanhas.

Foi uma evolução coletiva.

Muito parecida com software Open Source.


A Explosão Mundial

Poucos anos depois.

D&D já estava:

nos Estados Unidos.

Europa.

Japão.

Brasil.

Revistas.

Romances.

Brinquedos.

Desenhos.

Cinema.

Quadrinhos.

Videogames.

Sua influência espalhou-se silenciosamente.


O Japão Descobre o RPG

Na década de 1980.

Autores japoneses começam a jogar RPG de mesa.

Resultado?

Dragon Quest.

Final Fantasy.

Record of Lodoss War.

Slayers.

Rune Soldier.

Goblin Slayer.

Frieren.

Delicious in Dungeon.

Grande parte dos mundos de fantasia dos animes nasce dessa influência direta ou indireta.


Easter Egg do Bellacosa Mainframe

Imagine Gary Gygax entrando em um banco.

O gerente pergunta:

— Qual seu trabalho?

Ele responde:

— Invento mundos.

O gerente sorri.

— Isso não dá dinheiro.

Cinquenta anos depois...

Bilhões de dólares em livros, jogos, filmes, séries e videogames respondem por ele.

Enquanto isso...

Um programador COBOL observa tudo.

E percebe que uma ficha de personagem não é muito diferente de uma estrutura de dados bem projetada.

Cada atributo possui um propósito.

Cada regra evita inconsistências.

Até a fantasia precisa de uma boa modelagem.


Curiosidades que Pouca Gente Conhece

🎲 O primeiro D&D era surpreendentemente pequeno

As regras cabiam em poucos livretos. O restante dependia da criatividade do Mestre e dos jogadores.


🧙 O termo "Dungeon Master" tornou-se uma marca registrada

Em outros RPGs, funções equivalentes receberam nomes diferentes, como Narrador, Mestre de Jogo ou Game Master.


📚 Muitos monstros vieram diretamente da mitologia

Dragões, medusas, minotauros e gigantes já existiam muito antes de D&D. O jogo reorganizou essas criaturas em um sistema consistente.


⚔ O Bárbaro chegou depois

Nas primeiras versões, a classe Bárbaro ainda não existia. Ela foi introduzida posteriormente, claramente inspirada pela popularidade de Conan.


🌍 D&D ajudou a criar uma linguagem comum da fantasia

Hoje, quando pensamos em níveis, atributos, classes, pontos de experiência ou alinhamentos, estamos usando conceitos popularizados pelo RPG de mesa.


O Momento em que o Leitor Entrou no Livro

Robert E. Howard nos ensinou que um mundo fantástico podia parecer real.

Frank Frazetta mostrou como esse mundo poderia ser visto.

Gary Gygax e Dave Arneson deram o passo seguinte: colocaram o leitor dentro da história.

A partir desse instante, fantasia deixou de ser apenas literatura. Tornou-se uma experiência compartilhada. Amigos reunidos em volta de uma mesa passaram a enfrentar dragões, explorar ruínas, negociar com reis e fugir de goblins usando apenas imaginação, papel, lápis e alguns dados coloridos.

Essa mudança foi tão profunda que seus ecos ainda aparecem em praticamente todo RPG eletrônico, MMORPG, jogo de ação, mangá e anime de fantasia produzido atualmente.

No próximo volume, viajaremos para a França de 1975, onde um grupo de artistas decidiria romper todas as convenções dos quadrinhos tradicionais. Em suas páginas surgiriam mundos surreais, ficção científica adulta, fantasia filosófica e uma liberdade visual jamais vista.

Lá conheceremos uma revista que influenciaria artistas do mundo inteiro — inclusive no Japão.

Seu nome era Métal Hurlant.

E, a partir dela, a fantasia nunca mais seria apenas medieval. Ela se tornaria verdadeiramente infinita.


☕ Um Café no Bellacosa Mainframe

📚 O Grande Bestiário da Fantasia

Das Revistas Pulp aos Animes Modernos

Uma viagem pelas raízes da fantasia moderna: mitologia, revistas pulp, Robert E. Howard, Conan, Frank Frazetta, RPG, quadrinhos europeus, Dark Fantasy, MMORPGs e a chegada dos grandes animes de fantasia.

17 capítulos disponíveis.

I
As origens

Volume I — Antes de Conan

Uma viagem às raízes da fantasia: Gilgamesh, Beowulf, sagas nórdicas, mitologias antigas, Lord Dunsany, William Morris e Edgar Rice Burroughs.

Ler o Volume I ↗
II
O criador

Volume II — Robert E. Howard

A vida do escritor de Cross Plains que criou Conan, Kull, Solomon Kane, Bran Mak Morn e estabeleceu as fundações da Sword and Sorcery.

Ler o Volume II ↗
III
Era Hiboriana

Volume III — O Universo Conan

A engenharia da Era Hiboriana: reinos, povos, religiões, mapas, civilizações e o primeiro grande world building da fantasia moderna.

Ler o Volume III ↗
IV
Arte fantástica

Volume IV — Frank Frazetta

Como a força, o movimento, as sombras e os monstros de Frazetta definiram visualmente a fantasia que conhecemos.

Ler o Volume IV ↗
V
RPG de mesa

Volume V — Dungeons & Dragons

Quando a fantasia deixou de ser apenas lida e passou a ser vivida por jogadores, mestres, guerreiros, magos e ladrões ao redor de uma mesa.

Ler o Volume V ↗
VI
Quadrinhos europeus

Volume VI — Métal Hurlant

A revista francesa que rompeu fronteiras entre fantasia, ficção científica, surrealismo e narrativa visual.

Ler o Volume VI ↗
VII
Fantasia adulta

Volume VII — Heavy Metal

Quando a fantasia europeia cruzou o Atlântico, ganhou novas vozes e conquistou a cultura pop mundial.

Ler o Volume VII ↗
VIII
Grimdark

Volume VIII — Warhammer Fantasy

O Velho Mundo, os Deuses do Caos, os Skaven e a fantasia sombria onde a vitória do bem nunca é garantida.

Ler o Volume VIII ↗
IX
Dark Fantasy

Volume IX — Berserk

Kentaro Miura reuniu séculos de fantasia, arte europeia, horror, tragédia e guerra em uma das obras mais influentes do mangá.

Ler o Volume IX ↗
X
D&D no Japão

Volume X — Record of Lodoss War

A campanha de RPG que virou romance, mangá e anime, criando uma ponte definitiva entre Dungeons & Dragons e a fantasia japonesa.

Ler o Volume X ↗
XI
Fantasia e humor

Volume XI — Slayers

Lina Inverse demonstrou que a fantasia podia rir dos próprios clichês sem abandonar magia, aventura, perigo e construção de mundo.

Ler o Volume XI ↗
XII
Magia e responsabilidade

Volume XII — Sorcerous Stabber Orphen

Um protagonista cínico, magos imperfeitos e um universo onde magia possui teoria, limites, custos e consequências humanas.

Ler o Volume XII ↗
XIII
Mundos persistentes

Volume XIII — Ultima Online, EverQuest e Ragnarok Online

Os MMORPGs transformaram a fantasia em mundos habitados 24 horas por dia, com guildas, mercados, guerras, profissões e comunidades reais.

Ler o Volume XIII ↗
XIV
Sociedade virtual

Volume XIV — Log Horizon

Um MMORPG deixa de ser apenas um jogo e se transforma em uma civilização com economia, leis, diplomacia, educação e governança.

Ler o Volume XIV ↗
XV
Realidade virtual

Volume XV — Sword Art Online

Quando um MMORPG deixou de ser apenas um mundo virtual e se tornou uma prisão onde perder a partida significava perder a própria vida.

Ler o Volume XV ↗
Capítulo especial

As Revistas Pulp

Weird Tales, Amazing Stories, Argosy, Black Mask e outras revistas que publicaram heróis, monstros, detetives e mundos que mudariam a cultura popular para sempre.

Ler o capítulo especial ↗
Ω
Conclusão da série

O Guia Definitivo da Evolução da Fantasia Moderna

O índice final da série, conectando todos os capítulos e revelando como mitologia, pulp, Conan, RPG, quadrinhos, games e animes fazem parte da mesma árvore genealógica.

Ler o guia definitivo ↗
A linhagem

Das tábuas de argila aos mundos virtuais

Mitologias Revistas Pulp Conan Frazetta D&D Quadrinhos Europeus Warhammer Berserk Animes MMORPGs Isekais

O Grande Bestiário da Fantasia
Uma jornada do papel barato das revistas pulp aos pixels brilhantes dos mundos virtuais.

Voltar ao topo ↑

quinta-feira, 14 de maio de 2015

☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Bellacosa Mainframe e o IBM Integration Bus (Broker)


 ☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Quando alguém fala em Integration Bus, Broker, Message Broker ou até no antigo MQSeries Integrator… estamos falando de uma das tecnologias mais importantes da integração corporativa moderna.

E no mundo mainframe isso teve — e ainda tem — um impacto gigantesco.


📌 O QUE É O INTEGRATION BUS (BROKER)?

De forma simples:

O IBM Integration Bus (IIB) é um middleware de integração criado pela IBM para:

  • conectar sistemas diferentes

  • transformar dados

  • rotear mensagens

  • integrar aplicações legadas e modernas

  • fazer “sistemas conversarem”

Ele funciona como um:

✅ tradutor
✅ roteador
✅ orquestrador
✅ mediador
✅ transformador de protocolos


📜 EVOLUÇÃO HISTÓRICA

A IBM mudou o nome várias vezes:

NomeÉpoca
MQSeries Integratoranos 90
WebSphere Message Broker (WMB)anos 2000
IBM Integration Bus (IIB)2010+
IBM App Connect Enterprise (ACE)atual

Muita gente no mercado ainda chama tudo de:

👉 “Broker”

Porque o nome ficou eternizado no ambiente corporativo.


🧠 O PROBLEMA QUE ELE RESOLVE

Imagine isso:

Sistema A

Mainframe COBOL
fala:

  • EBCDIC

  • Copybook COBOL

  • MQ

Sistema B

Java/Linux
fala:

  • JSON

  • REST

  • UTF-8

Sistema C

SAP
fala:

  • IDoc

  • XML

Sistema D

Cloud/API
fala:

  • HTTPS

  • OAuth

  • SOAP/REST

Sem um barramento de integração…

🔥 vira caos.

Cada sistema teria que entender diretamente todos os outros.


🎯 O BROKER ENTRA COMO INTERMEDIÁRIO

Ele recebe dados de um lado e entrega no formato correto do outro.

Exemplo:

COBOL + MQ + EBCDIC
        ↓
   Integration Bus
        ↓
JSON + REST + UTF-8

Ou:

CICS → MQ → Broker → API REST → Cloud

🏦 ONDE ELE É MUITO USADO?

Principalmente:

  • bancos

  • seguradoras

  • bolsas financeiras

  • telecom

  • governo

  • varejo

  • empresas gigantes

Porque quase todas possuem:

✅ sistemas legados
✅ mainframe
✅ aplicações distribuídas
✅ cloud
✅ APIs modernas

E alguém precisa integrar tudo isso.


⚙️ COMO ELE FUNCIONA?

O Integration Bus trabalha com:

📦 Message Flows

Fluxos gráficos que definem:

  • entrada

  • transformação

  • regras

  • roteamento

  • saída

Visualmente parece um pipeline.


🧩 COMPONENTES PRINCIPAIS

🔹 Input Node

Recebe mensagens:

  • MQ

  • HTTP

  • File

  • Kafka

  • SOAP

  • REST

  • TCP/IP


🔹 Compute Node

Onde fica a lógica.

Normalmente usando:

  • ESQL

  • Java

  • Mapping

Aqui ele:

  • transforma campos

  • converte layouts

  • altera dados

  • toma decisões


🔹 Mapping Node

Transformação visual:

COPYBOOK COBOL
   ↓
JSON/XML

🔹 Output Node

Entrega para:

  • MQ

  • API

  • banco

  • arquivo

  • Kafka

  • SAP

  • cloud


🧠 O QUE É O ESQL?

O ESQL é a linguagem clássica do Broker.

Parece mistura de:

  • SQL

  • procedural

  • manipulação de mensagem

Exemplo:

SET OutputRoot.JSON.Data.nome =
    InputRoot.XMLNSC.cliente.nome;

Ele transforma estruturas de dados em tempo real.


🔥 O MAINFRAME E O BROKER

Aqui está o ponto interessante.

Muitos ambientes z/OS usam:

  • CICS

  • IMS

  • DB2

  • MQ

  • COBOL

Mas aplicações modernas querem:

  • REST

  • JSON

  • APIs

  • microserviços

O Broker virou a ponte entre esses mundos.


💥 EXEMPLO REAL

Cenário bancário

Mainframe

COBOL envia:

000123JOAO      0000500

Formato fixo EBCDIC.


Broker recebe

Ele:

  • decodifica EBCDIC

  • interpreta copybook

  • converte para UTF-8

  • monta JSON

Resultado:

{
  "conta": 123,
  "nome": "JOAO",
  "saldo": 500
}

API REST recebe

Aplicação cloud consome normalmente.

Tudo transparente.


🚀 O QUE FEZ O BROKER FICAR GIGANTE?

Porque ele resolveu o maior problema corporativo:

integração entre mundos incompatíveis

Ele conecta:

Mundo antigoMundo moderno
COBOLJava
MQREST
VSAMJSON
EBCDICUTF-8
CICSAPIs
BatchCloud

🔥 RELAÇÃO COM IBM MQ

Muita gente confunde.

IBM MQ

transporta mensagens

Broker/IIB

processa e transforma mensagens

Exemplo:

Sistema A
   ↓ MQ
Broker
   ↓ MQ/API
Sistema B

MQ = estrada
Broker = inteligência do tráfego


📦 PRINCIPAIS PROTOCOLOS SUPORTADOS

O Broker suporta praticamente tudo:

  • MQ

  • JMS

  • REST

  • SOAP

  • HTTP

  • HTTPS

  • FTP

  • SFTP

  • Kafka

  • TCP/IP

  • SAP

  • JDBC

  • Files

  • XML

  • JSON

  • CSV

  • FIX

  • SWIFT


🧠 POR QUE ISSO FOI REVOLUCIONÁRIO?

Antes dele:

❌ integrações ponto a ponto
❌ spaghetti architecture
❌ milhares de interfaces manuais
❌ manutenção infernal

Depois dele:

✅ centralização
✅ transformação padronizada
✅ governança
✅ desacoplamento
✅ reutilização


⚠️ MAS EXISTEM DESAFIOS

Integration Bus também pode virar:

🔥 “monólito de integração”

Quando:

  • tudo passa por ele

  • todas regras ficam centralizadas

  • ninguém documenta

  • flows crescem demais

Resultado:

❌ complexidade absurda
❌ debugging difícil
❌ dependência gigante
❌ gargalos


🏗️ O QUE VEIO DEPOIS?

Hoje existe forte movimento para:

  • microservices

  • event streaming

  • Kafka

  • API Gateway

  • cloud integration

Mas…

🔥 o Broker continua fortíssimo em empresas enterprise.

Especialmente onde:

  • existe mainframe

  • há MQ pesado

  • integração crítica

  • alto volume transacional


📌 NO MAINFRAME MODERNO

O Broker/ACE virou peça estratégica para:

✅ expor APIs do CICS
✅ integrar COBOL com cloud
✅ transformar copybooks em JSON
✅ integrar DB2 com REST
✅ conectar Kafka ao z/OS
✅ modernização gradual


🎯 RESUMO FINAL

O IBM Integration Bus/Broker é:

“o sistema que faz sistemas incompatíveis conversarem.”

Ele foi — e continua sendo — um dos pilares da integração corporativa entre:

☕ legado
🔥 middleware
🚀 cloud
🏦 mainframe
🌎 APIs modernas

Sem ele, boa parte do mundo corporativo ainda estaria presa em integrações caóticas ponto a ponto.

quarta-feira, 13 de maio de 2015

🎎💣 Omatsuri — O “Batch Coletivo” que Coloca a Cultura Japonesa em Produção

 

Bellacosa Mainframe Omatsuri

🎎💣 Omatsuri — O “Batch Coletivo” que Coloca a Cultura Japonesa em Produção

Se no mainframe você agenda jobs, sincroniza recursos e faz tudo rodar em conjunto…
o Omatsuri é isso — só que com pessoas, tradição e energia coletiva.

Não é evento casual.
Não é festa comum.

👉 É execução coordenada de cultura em larga escala.


🧠 O que é Omatsuri (versão COBOL dev)

👉 Matsuri (お祭り)

“Omatsuri” é uma forma respeitosa de dizer festival japonês.

Mas não confunda com “festa”.

👉 Pode envolver:

  • 🏮 Rituais religiosos
  • 🎎 Procissões
  • 🥁 Música tradicional
  • 🍢 Comida de rua
  • 👥 Participação comunitária massiva

📌 Bellacosa traduz:

Omatsuri = job batch distribuído rodando com milhares de usuários simultâneos


📜 Origem — Quando o Sistema Era Espiritual

Os matsuri surgiram ligados ao:

👉 Shinto

Função original:

  • Honrar deuses (kami)
  • Pedir boas colheitas 🌾
  • Afastar desastres
  • Manter equilíbrio espiritual

👉 Ou seja:

Não era entretenimento… era manutenção do sistema espiritual.


⚙️ Como Funciona — Arquitetura do Evento

Um Omatsuri típico inclui:

🏯 Santuário (ponto central)

Ligado a um Shinto shrine


🏮 Mikoshi (deploy móvel)

  • Santuário portátil
  • Carregado pelas pessoas
  • Representa o deus em movimento

📌 Tradução Bellacosa:

É o container divino em runtime


🥁 Execução

  • Procissões
  • Danças
  • Música
  • Interação comunitária

👉 Tudo sincronizado.


👁 Aparência — Caos Organizado

  • Lanternas iluminadas
  • Multidão sincronizada
  • Sons intensos
  • Movimento constante

📌 Parece caos…
mas é orquestração perfeita.


🤫 Fofoquices de Bastidores

  • Carregar o mikoshi é uma honra (e sofrimento físico 😄)
  • Cada cidade tem seu próprio estilo
  • Alguns festivais são extremamente barulhentos e “selvagens”
  • Outros são silenciosos e espirituais

📌 Fofoquinha:

Tem matsuri que parece deploy em produção… sem rollback.


🕹️ Easter Eggs na Cultura Pop

  • Spirited Away → atmosfera espiritual
  • Naruto → festivais de vila
  • Your Lie in April → festivais escolares

🎮 Easter Egg clássico:

Toda cena com lanternas e yukata… é herança direta de matsuri.


🧠 Interpretação (Modo Bellacosa ON)

Omatsuri representa:

  • Sincronização social
  • Conexão com tradição
  • Execução coletiva
  • Energia compartilhada

📌 Comparação (Mainframe Mode)

ElementoEquivalente
ComunidadeUsuários simultâneos
RitualJob agendado
MikoshiContainer em execução
FestivalBatch distribuído
TradiçãoSistema legado

📌 Comentário Final — Nem Todo Sistema é Técnico

No mundo moderno, tudo é automatizado.

Mas o Omatsuri mostra:

existem sistemas que só funcionam com pessoas, emoção e presença.

💡 Extra — descrição enriquecida (nível Bellacosa Mainframe 💣)

Um Omatsuri (祭り) é muito mais que festa — é um evento coletivo profundamente enraizado na cultura japonesa, geralmente ligado a tradições religiosas e à comunidade local.

Eles envolvem:

  • procissões
  • música tradicional
  • comida de rua
  • participação massiva da comunidade

E, historicamente, serviam para honrar divindades (kami), agradecer colheitas ou pedir proteção.

👉 Em resumo:
Omatsuri = sincronização social em larga escala


💣 Analogia estilo Bellacosa Mainframe

Agora segura essa visão:

👉 Um Omatsuri é literalmente um BATCH HUMANO

  • 🧠 Cada pessoa = um processo
  • 🎭 Cada ritual = um job step
  • 🏮 Procissão = fluxo sequencial controlado
  • 🎶 Música = sincronização de execução
  • 🍡 Barracas = recursos compartilhados

E o mais importante:

👉 Tudo acontece de forma coordenada, com propósito coletivo

Assim como no mainframe:

  • Batch não é caos
  • É orquestração massiva com ordem invisível

⚔️ Insight poderoso

Enquanto no mundo moderno tudo é individual…

👉 o Omatsuri mostra um conceito antigo e poderoso:

Sistemas fortes são aqueles onde todos executam juntos, no tempo certo

No mainframe:

  • Se um job falha → impacto no fluxo
  • Se uma etapa atrasa → backlog
  • Se tudo roda certo → harmonia total

No Omatsuri:

  • mesma lógica
  • só que com humanos 😄

 


💣 Versão Bellacosa Final

Omatsuri não é festa…
é o sistema cultural japonês rodando em modo distribuído, sem downtime.

 

terça-feira, 12 de maio de 2015

Como Não Se Perder no Mainframe (e Ainda Brilhar em Produção) ☕

 

Bellacosa Mainframe apresenta um manual de sobrevivencia para um padawan em mainframe

🔥 Manual de Sobrevivência do Programador COBOL Iniciante

Como Não Se Perder no Mainframe (e Ainda Brilhar em Produção) ☕

Entrar no mundo COBOL Mainframe é como desembarcar em uma usina nuclear em pleno funcionamento: tudo é estável, poderoso… e absolutamente implacável com erros.

Mas respire.

Milhões de profissionais passaram por isso antes — e sobreviveram muito bem 😄
Este é o guia que eu gostaria que todo iniciante recebesse no primeiro dia.


🧠 1) Entenda onde você está pisando

Você não está em um ambiente comum de desenvolvimento.

Aqui existem:

✔ Sistemas rodando há décadas
✔ Código crítico para negócios bilionários
✔ Processos batch noturnos gigantescos
✔ Auditoria pesada
✔ Zero tolerância para “gambiarras”

No Mainframe:

“Se funciona há 20 anos, mexa com extremo respeito.”


🖥️ 2) Domine o ecossistema antes da linguagem

COBOL sozinho não faz nada.
Você precisa entender o ambiente z/OS:

  • TSO/ISPF

  • JCL

  • Datasetes

  • JOBs batch

  • SDSF

  • Conceitos de spool

  • Bibliotecas PDS/PDSE

Sem isso, você fica perdido mesmo sabendo programar.


📜 3) Aprenda a ler código antigo (muito antigo)

Grande parte do seu trabalho inicial será manutenção.

Você verá:

😅 Variáveis com nomes estranhos
😅 GO TO espalhado
😅 Comentários de 1989
😅 Copybooks gigantes
😅 Lógica de negócio implícita

Dica de ouro:

👉 Comece pelo fluxo principal (MAIN-LOGIC)
👉 Siga os PERFORMs
👉 Ignore detalhes até entender o todo


🧱 4) Respeite os padrões da empresa

Cada organização tem seu próprio guia de estilo.

Nunca chegue “modernizando tudo”.

Faça primeiro:

✔ Entenda o padrão local
✔ Copie o estilo existente
✔ Siga nomenclaturas
✔ Use templates corporativos

No Mainframe, consistência vale mais que criatividade.


🧮 5) Entenda arquivos — eles são o coração do batch

Processamento batch gira em torno de datasets.

Você precisa dominar:

  • Sequential files

  • VSAM

  • Leitura e escrita

  • EOF (fim de arquivo)

  • Layouts de registro

  • Controle de erro

Um erro de layout pode destruir dados sem aviso.


🔁 6) PERFORM é seu melhor amigo

Evite ao máximo:

🚫 GO TO
🚫 Lógica confusa
🚫 Saltos imprevisíveis

Prefira fluxo estruturado:

✔ PERFORM UNTIL
✔ PERFORM VARYING
✔ Parágrafos bem nomeados

Código previsível é código seguro.


🧠 7) Use nomes que contam a história

Bons nomes reduzem metade do esforço de manutenção.

Compare:

❌ X1, X2, VARA
✔ WS-SALDO-CONTA
✔ FL-FIM-ARQUIVO
✔ CNT-REG-LIDOS

Se alguém entende sem perguntar, você venceu.


📦 8) COPYBOOKs são contratos

Copybooks definem layouts compartilhados.

Mexer neles pode impactar dezenas ou centenas de programas.

Antes de alterar:

⚠ Verifique dependências
⚠ Consulte responsáveis
⚠ Avalie impacto sistêmico

Alterar copybook sem análise é receita para incidente.


🛑 9) Teste como se produção dependesse disso

(porque depende)

Um JOB errado pode:

💸 Gerar pagamentos indevidos
📉 Corromper base de dados
📊 Produzir relatórios incorretos
🚨 Acionar auditoria

Teste cenários:

✔ Arquivo vazio
✔ Dados inválidos
✔ Limites máximos
✔ Exceções


📊 10) Leia o output do JOB — sempre

Após rodar, verifique:

  • Return codes

  • Mensagens

  • Contagem de registros

  • Warnings

  • Dumps

Nunca assuma que “deu certo”.


🧯 11) Aprenda a interpretar ABENDs

ABEND não é fracasso — é informação.

Códigos como:

  • S0C7 → erro numérico

  • S0C4 → acesso inválido de memória

  • S013 → problema de arquivo

Dominar isso acelera sua evolução absurdamente.


🤝 12) Faça amizade com operadores e analistas experientes

Mainframe é uma cultura colaborativa.

Operadores conhecem o comportamento real dos JOBs.
Veteranos conhecem os sistemas por dentro.

Uma conversa pode economizar dias de tentativa e erro.


⏳ 13) Tenha paciência — aprendizado é cumulativo

No início, tudo parece lento:

  • Compilar leva tempo

  • JOBs entram em fila

  • Ambientes são controlados

  • Mudanças passam por aprovação

Mas isso existe para garantir estabilidade.


☕ Filosofia final de sobrevivência

Ser programador COBOL não é apenas saber sintaxe.

É ser guardião de sistemas críticos.

Você está mantendo a infraestrutura invisível que faz o mundo financeiro e governamental funcionar.

“Se ninguém percebe seu trabalho, provavelmente está perfeito.”


⭐ Conclusão

O iniciante que sobrevive no Mainframe não é o mais brilhante — é o mais disciplinado.

Com o tempo, você descobrirá algo surpreendente:

👉 COBOL não é ultrapassado
👉 É simplesmente implacavelmente confiável

E dominar esse ambiente abre portas raras e valiosas.


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...