Translate

segunda-feira, 3 de novembro de 2014

Mary Hawes: a mulher que chamou a reunião que mudou a informática - Codasyl

 


💾 EL JEFE MIDNIGHT LUNCH — Bellacosa Mainframe Chronicles
“Mary Hawes: a mulher que chamou a reunião que mudou a informática”


Existem pessoas que escrevem código.
Existem pessoas que escrevem especificações.
E existem pessoas raríssimas que criam o contexto onde o futuro acontece.

Mary Hawes não ficou famosa como “a programadora do algoritmo X”.
Ela ficou eterna porque fez algo muito mais difícil:
👉 percebeu o problema antes de todo mundo
👉 juntou as pessoas certas
👉 e forçou a indústria a conversar

Se hoje existe COBOL, mainframe corporativo, sistemas que duram 40 anos, é porque Mary Hawes levantou a mão e disse: “isso não está funcionando”.

Vamos contar essa história como ela merece — com café forte, bastidor, fofoquice técnica e respeito histórico.



👩‍💼 Quem foi Mary Hawes (biografia rápida)

  • Nome completo: Mary Kenneth Hawes

  • Formação: Matemática

  • Atuação: Analista de sistemas, líder técnica, articuladora

  • Empresas-chave: Burroughs Corporation

  • Período crítico: final dos anos 1950 e início dos anos 1960

Mary Hawes não era “apenas” programadora.
Ela era o que hoje chamaríamos de arquiteta de sistemas, product owner e líder técnica — tudo ao mesmo tempo, décadas antes desses termos existirem.


🕰️ O problema que ela enxergou (e quase ninguém queria ver)

Final dos anos 50.
Cada fabricante tinha:

  • Seu próprio hardware

  • Sua própria linguagem

  • Seu próprio compilador

  • Seu próprio inferno de manutenção

Trocar de máquina significava:

  • Reescrever tudo

  • Treinar pessoas do zero

  • Jogar investimentos no lixo

🧠 Comentário Bellacosa:
Mary Hawes enxergou algo simples e assustador: isso não escala.

Enquanto a indústria brigava por market share, ela pensava em interoperabilidade — uma palavra que nem existia ainda.


📣 O ato revolucionário: convocar a reunião

Aqui entra o momento histórico.

Mary Hawes, trabalhando na Burroughs, escreve, liga, insiste e articula uma reunião entre:

  • Governo dos EUA

  • Forças Armadas

  • Grandes fabricantes (IBM, RCA, Univac, Burroughs, Honeywell…)

Ela basicamente disse:

“Precisamos de uma linguagem comum para sistemas de negócio.
Agora.
Juntos.”

Essa reunião virou o Short-Range Committee (1959).
E dessa mesa nasceu o COBOL.

🧠 Tradução livre:
Mary Hawes não “programou” o COBOL.
Ela tornou o COBOL inevitável.


💻 Contributo direto ao COBOL

Mary Hawes foi fundamental em vários aspectos:

🔹 Visão de linguagem de negócios

  • Linguagem legível

  • Próxima do inglês

  • Voltada a dados e processos empresariais

🔹 Defesa da independência de fornecedor

  • COBOL não seria da IBM

  • Nem da Burroughs

  • Nem da Univac

🥚 Easter egg histórico:
Convencer a IBM a aceitar isso foi quase um milagre diplomático.


🔹 Organização e liderança

Mary não era apenas “a ideia”.
Ela coordenava discussões, mediava egos gigantes e mantinha o foco no objetivo.

🧠 Fofoquice técnica:
Dizem que sem ela as reuniões viravam disputas acadêmicas intermináveis.
Com ela, viravam decisões.


🖥️ Mary Hawes e o nascimento do Mainframe corporativo

O mainframe como conhecemos hoje — plataforma estável, durável, corporativa — nasce da filosofia COBOL:

  • Separação entre dados e lógica

  • Programas legíveis e auditáveis

  • Longevidade acima de modismo

Tudo isso está diretamente ligado à visão de Mary Hawes.

🧠 Comentário Bellacosa Mainframe:
O mainframe não foi feito para ser bonito.
Foi feito para durar.
Mary Hawes pensava exatamente assim.


🧬 Principais trabalhos e contribuições

  • Idealizadora e articuladora do movimento que levou ao COBOL

  • Representante da Burroughs no comitê COBOL

  • Influência direta na definição de linguagens orientadas a negócio

  • Defensora precoce de padrões abertos

  • Uma das primeiras líderes femininas reais da computação corporativa

Ela não escreveu milhares de linhas de código.
Ela escreveu o manual invisível do software corporativo.


🧩 Curiosidades pouco faladas

  • Mary Hawes raramente aparece nos livros populares de história da computação

  • Seu papel foi por muito tempo “diluído” em comitês

  • Hoje, historiadores concordam: sem ela, COBOL provavelmente não existiria

  • Ela era conhecida por ser direta, objetiva e impaciente com vaidade técnica

🥚 Easter egg:
Ela defendia que código deveria ser lido por pessoas de negócio.
Décadas depois, isso ainda é um diferencial do COBOL.


👶 Conteúdo para Padawans do Mainframe

Se você está começando agora, aprenda isso com Mary Hawes:

  • Tecnologia sem visão vira sucata

  • Linguagem sem propósito vira brinquedo

  • Sistema que não dura não é sistema — é experimento

COBOL e mainframe sobreviveram porque foram pensados para o mundo real.


☕ O legado de Mary Hawes

Mary Hawes deixou algo raro:

  • Não um produto

  • Não uma patente

  • Não uma startup

Ela deixou um ecossistema inteiro funcionando por mais de 60 anos.

Cada batch que fecha banco.
Cada transação CICS que autoriza pagamento.
Cada salário que cai certo no fim do mês.

Tudo isso carrega um pouco da decisão que ela tomou em 1959.


🧠 Reflexão final do El Jefe

“Algumas pessoas escrevem código.
Outras escrevem o futuro.
Mary Hawes fez os dois — sem pedir crédito.”

Se hoje o COBOL ainda vive,
se o mainframe ainda reina silencioso,
é porque alguém, lá atrás, teve coragem de parar a indústria e dizer:

“Precisamos fazer isso direito.”


sexta-feira, 17 de outubro de 2014

☕🧠💣 PARANOIA AGENT — O DIA EM QUE UM ÚNICO BUG DE USUÁRIO DERRUBOU O SISTEMA OPERACIONAL DA REALIDADE

 

Bellacosa Mainframe e o maluco Paranoia Agent

☕🧠💣 PARANOIA AGENT — O DIA EM QUE UM ÚNICO BUG DE USUÁRIO DERRUBOU O SISTEMA OPERACIONAL DA REALIDADE


Dados Técnicos

Título Original: 妄想代理人 (Mōsō Dairinin)
Título Internacional: Paranoia Agent
Criador e Diretor: Satoshi Kon
Roteiro: Satoshi Kon e Seishi Minakami
Estúdio: Madhouse
Exibição Original: 2 de fevereiro de 2004 a 17 de maio de 2004
Episódios: 13
Gênero: Suspense Psicológico, Mistério, Drama, Horror Psicológico, Surrealismo, Ficção Social
Classificação Indicativa: 16+ (varia conforme o país)


Introdução

Existem animes que contam histórias.

Existem animes que fazem perguntas.

E existe Paranoia Agent, uma obra que desmonta a mente do espectador peça por peça até que ele não tenha mais certeza se está assistindo a uma série ou participando de um colapso coletivo.

Se Serial Experiments Lain investigava a internet e Perfect Blue investigava a identidade, Paranoia Agent investiga algo muito mais perigoso:

A capacidade humana de criar mentiras tão confortáveis que acabam se tornando realidade.

No melhor estilo Bellacosa Mainframe:

Este não é um anime sobre um criminoso.

É um relatório RCA sobre uma sociedade inteira operando com erros ignorados há décadas.


Sinopse

Tsukiko Sagi é uma designer famosa por criar a adorável mascote chamada Maromi.

Sob enorme pressão para repetir seu sucesso, ela vive um cotidiano sufocante.

Certa noite, ao voltar para casa, é atacada por um estranho garoto usando patins dourados e carregando um taco metálico torto.

A polícia inicia uma investigação.

Logo outras vítimas aparecem.

Todas afirmam ter sido atacadas pelo mesmo agressor.

A mídia o apelida de:

Shonen Bat (Lil' Slugger)

Porém existe um problema.

As vítimas parecem possuir algo em comum.

Todas estavam vivendo momentos de extremo sofrimento psicológico antes do ataque.

E, curiosamente, após serem atacadas, sentem um estranho alívio.


A História Sem Spoilers

Inicialmente parece uma investigação policial.

Depois parece uma série de casos independentes.

Depois parece uma crítica social.

Depois parece um thriller psicológico.

Depois parece uma alucinação coletiva.

Finalmente você percebe que estava assistindo a todas essas coisas ao mesmo tempo.

Cada episódio funciona como um "dump" diferente da sociedade japonesa moderna.

Satoshi Kon usa o mistério de Shonen Bat para explorar indivíduos completamente diferentes:

  • Estudantes

  • Policiais

  • Donas de casa

  • Empresários

  • Artistas

  • Viciados em internet

  • Idosos

  • Crianças

Todos conectados por um único elemento:

A necessidade desesperada de escapar da realidade.


Os Personagens Principais

Tsukiko Sagi

A designer da mascote Maromi.

Sua culpa, insegurança e incapacidade de lidar com a pressão são o ponto central da narrativa.

Ela representa pessoas que criam versões confortáveis da realidade para sobreviver.


Keiichi Ikari

Detetive veterano.

É a lógica tentando sobreviver em um mundo cada vez mais irracional.

Representa o pensamento analítico.

O profissional que ainda acredita que todo problema possui uma causa identificável.


Mitsuhiro Maniwa

O investigador mais jovem.

Enquanto Ikari busca respostas concretas, Maniwa mergulha cada vez mais fundo no caos.

É o sysprog que percebe que os logs não estão mentindo.

O sistema inteiro é que deixou de obedecer às regras.


Maromi

A mascote fofa criada por Tsukiko.

À primeira vista parece inofensiva.

Mas gradualmente se torna um dos símbolos mais importantes e assustadores da série.

Representa conforto emocional, escapismo e negação.


O Que Torna Paranoia Agent Diferente?

Muitos animes exploram mistérios.

Pouquíssimos transformam a própria sociedade em antagonista.

O verdadeiro inimigo não é Shonen Bat.

O verdadeiro inimigo é:

  • Negação

  • Pressão social

  • Ansiedade coletiva

  • Autoengano

  • Conformismo

Satoshi Kon não pergunta:

"Quem é o culpado?"

Ele pergunta:

"Por que precisamos tanto de um culpado?"


As Aventuras e Casos Mais Marcantes

Cada episódio apresenta uma situação diferente.

Entre elas:

Os Três Suicidas

Um dos episódios mais famosos da história dos animes.

Três desconhecidos combinam cometer suicídio juntos.

O resultado mistura humor negro, tragédia e crítica social.

É simultaneamente engraçado e profundamente perturbador.


O Homem Duplo

Um cidadão aparentemente comum começa a viver duas vidas completamente distintas.

Uma crítica à fragmentação da identidade moderna.


A Febre da Mídia

A cobertura sensacionalista transforma um simples caso policial em uma epidemia nacional.

Décadas antes das redes sociais dominarem o mundo, Kon já mostrava o poder destrutivo da viralização.


Mensagens Ocultas

Shonen Bat Não É Apenas Um Personagem

Ele representa uma solução imaginária para problemas reais.

Quando a dor se torna insuportável, surge a fantasia de que alguém virá resolver tudo.


Maromi É Mais Perigosa Que O Vilão

Maromi simboliza conforto artificial.

Ela não elimina o sofrimento.

Ela apenas o mascara.

É o equivalente psicológico de ignorar mensagens de erro no console.


A Sociedade Produz Seus Próprios Monstros

O anime sugere que monstros sociais não surgem do nada.

Eles são construídos coletivamente.

Rumores, medos e crenças compartilhadas acabam ganhando vida própria.


Temáticas Profundas

Histeria Coletiva

Uma das análises mais brilhantes já feitas sobre pânico social.


Escapismo

O desejo humano de fugir das responsabilidades.


Saúde Mental

Depressão, ansiedade e esgotamento aparecem em praticamente todos os episódios.


Cultura da Performance

As pessoas precisam aparentar sucesso mesmo quando estão quebradas emocionalmente.


Verdade Versus Narrativa

O anime mostra como versões convenientes da realidade podem substituir os fatos.


Impacto Cultural

Hoje Paranoia Agent é considerado uma das maiores obras psicológicas da animação japonesa.

Sua influência pode ser percebida em produções posteriores como:

  • Black Mirror

  • Mr. Robot

  • BoJack Horseman

  • Paprika

  • Diversos thrillers psicológicos modernos

Muitos estudiosos consideram a série uma das previsões mais precisas da era das redes sociais.

O fenômeno de notícias virais, fake news e pânico coletivo aparece de forma assustadoramente profética.


Houve Censura?

A série não sofreu censura significativa durante sua exibição original.

Porém diversos canais internacionais realizaram:

  • Cortes de violência

  • Ajustes em cenas psicológicas intensas

  • Restrições de horário

A censura mais comum ocorreu devido aos temas de suicídio, transtornos mentais e violência psicológica.

Mesmo assim, a maior parte das versões preservou a narrativa original.


Análise Bellacosa Mainframe

Registro do Incidente

Sistema: Sociedade Moderna

Aplicação: Realidade Compartilhada

Erro Detectado: Crescimento anormal de entidade denominada Shonen Bat

Severidade: SEV1

Usuários Impactados: Todos

Causa Raiz:
Acúmulo de exceções emocionais não tratadas.

Ação Corretiva Recomendada:
Enfrentar a realidade.

Ação Executada pelos Usuários:
Criar uma fantasia coletiva.

Resultado:
Falha catastrófica do ambiente.


Conclusão

Paranoia Agent talvez seja a obra mais ambiciosa de Satoshi Kon.

Não porque tenha a história mais complexa.

Mas porque transforma algo invisível em protagonista:

o mecanismo psicológico que usamos para fugir dos nossos próprios problemas.

Mais de vinte anos após seu lançamento, a série continua assustadoramente atual.

Em uma era dominada por redes sociais, narrativas fabricadas e realidades paralelas digitais, a pergunta feita por Satoshi Kon continua ecoando:

Se milhões de pessoas acreditarem na mesma mentira, em que momento ela deixa de ser mentira e passa a ser realidade?

Nota Bellacosa Mainframe: ☕☕☕☕☕ (5/5 cafés)

Classificação de Abend Mental: S0C4 – REALITY CORRUPTION

Porque, ao final do último episódio, o espectador percebe algo aterrorizante:

Shonen Bat nunca foi o problema. O problema era o sistema que precisava desesperadamente que ele existisse.


quinta-feira, 16 de outubro de 2014

☕🦊 KITSUNE — A “RAPOSA ROOT” DA MITOLOGIA JAPONESA QUE VIROU LENDA NOS ANIMES 💾🔥

 

☕🦊 KITSUNE — A “RAPOSA ROOT” DA MITOLOGIA JAPONESA QUE VIROU LENDA NOS ANIMES 💾🔥

Se existe uma criatura que dominou:

  • animes
  • visual novels
  • games japoneses
  • cultura otaku
  • waifus sobrenaturais

essa criatura é:

🦊 Kitsune (狐)

E não…
ela NÃO é apenas:

“garota com orelha de raposa”.

A coisa é MUITO mais profunda.

Estamos falando de uma entidade mitológica japonesa com séculos de história que acabou virando:

um dos maiores arquétipos da cultura anime.


☕ O QUE SIGNIFICA “KITSUNE”?

“Kitsune” (狐) significa:

🦊 Raposa

Mas no folclore japonês:
kitsunes são entidades sobrenaturais.

Elas podem:

  • mudar de forma
  • enganar humanos
  • manipular ilusões
  • possuir inteligência absurda
  • viver centenas de anos

Basicamente:

uma mistura de espírito, yokai e entidade mágica.


💾 A RAPOSA NO JAPÃO ANTIGO

No Japão feudal:
raposas eram vistas como criaturas:

  • misteriosas
  • inteligentes
  • espirituais

Acreditava-se que:
quanto mais velha a raposa…
mais poderosa ela se tornava.


🔥 AS NOVE CAUDAS

Aqui nasce um dos elementos mais famosos.

Uma kitsune poderosa pode desenvolver:

🦊 múltiplas caudas

Até chegar:

às lendárias 9 caudas.

Quanto mais caudas:

  • mais antiga
  • mais sábia
  • mais perigosa
  • mais poderosa

☕ KITSUNE = YOKAI?

Muitas vezes sim.

“Yokai” é basicamente:

  • espírito
  • criatura sobrenatural
  • entidade folclórica japonesa

Kitsunes são uma das categorias mais famosas.


💀 AS KITSUNES PODIAM SER BOAS OU MÁS

Isso é importante.

No folclore:
existem dois grandes tipos.


🌸 Zenko

kitsunes benevolentes

Ligadas ao deus:

Inari

São:

  • protetoras
  • sábias
  • espirituais

🔥 Yako

kitsunes travessas ou perigosas

Fazem:

  • ilusões
  • manipulação
  • brincadeiras cruéis
  • sedução

☕ O MITO DA MULHER-RAPOSA

Uma das histórias mais antigas envolve:
kitsunes assumindo forma humana.

Especialmente:

  • mulheres bonitas
  • misteriosas
  • sedutoras

Isso influenciou DIRETAMENTE:

  • animes
  • waifus kitsune
  • personagens moe

💾 A TRANSFORMAÇÃO NOS ANIMES

A cultura anime pegou toda essa mitologia…
e transformou numa explosão visual.

Nasceram então:

as “fox girls”.

Ou:

  • garotas com orelhas de raposa
  • cauda fofa
  • personalidade charmosa
  • comportamento brincalhão

🔥 O ARQUÉTIPO MODERNO

A kitsune anime normalmente mistura:

  • mistério
  • sensualidade
  • inteligência
  • fofura
  • espiritualidade
  • provocação

Ela pode ser:

  • kawaii
  • moe
  • sedutora
  • maternal
  • manipuladora

Tudo ao mesmo tempo.


☕ POR QUE OTACUS AMAM KITSUNES?

Porque elas combinam:

  • aparência animal fofa
  • beleza humana
  • fantasia sobrenatural
  • personalidade forte

É praticamente:

um “design premium” da engenharia de personagens japonesa.


💀 O SURGIMENTO DAS “FOX GIRLS”

Nos anos 90/2000:
kitsunes explodiram em:

  • visual novels
  • galges
  • eroges
  • JRPGs
  • animes

Viraram:

uma subcategoria inteira de waifu.


🌸 TRAÇOS CLÁSSICOS DE UMA KITSUNE ANIME

🦊 Orelhas de raposa

Elemento visual principal.


🦊 Cauda fofa

Símbolo de:

  • status
  • poder
  • fofura

🌸 Personalidade brincalhona

Muitas adoram provocar humanos.


☕ Inteligência elevada

Frequentemente são:

  • sábias
  • antigas
  • manipuladoras

🔥 Aura mística

Ligação com magia e espiritualidade.


📺 PERSONAGENS KITSUNE FAMOSAS

🦊 Kurama (Yu Yu Hakusho)

Uma versão masculina clássica.


🌸 Senko-san

A fox girl ultra moe.


🔥 Tamamo-no-Mae (Fate)

Baseada numa kitsune lendária real da mitologia.


☕ Holo (Spice and Wolf)

Mistura:

  • loba
  • espírito antigo
  • arquétipo kitsune-like

💀 Naruto e a Kyuubi

A Raposa de Nove Caudas é baseada diretamente no mito kitsune.


💾 O CASO DA TAMAMO-NO-MAE

Uma das figuras mais importantes do folclore japonês.

Ela seria:

  • uma kitsune lendária
  • extremamente poderosa
  • capaz de destruir impérios

Virou inspiração para:

  • Fate
  • jogos
  • animes
  • RPGs japoneses

☕ KITSUNE E O MOE

A cultura anime fundiu:

  • kitsune
  • moe
  • kawaii

Resultado:

🥺 Fox Girls ultra fofas.

A ideia é despertar:

  • carinho
  • proteção
  • fascínio emocional

🔥 O IMPACTO NOS GAMES

Kitsunes aparecem em:

  • MMORPGs
  • gachas
  • visual novels
  • JRPGs
  • mobages

Porque visualmente:
elas funcionam MUITO bem.


💀 A ENGENHARIA VISUAL DA KITSUNE

Os japoneses perceberam cedo que:
orelhas + cauda + expressão moe =

combo crítico emocional.

É praticamente:

UX/UI emocional aplicada ao design anime.


☕ A DIFERENÇA ENTRE NEKOMIMI E KITSUNE

Muita gente confunde.


🐱 Nekomimi

garota-gato

Mais:

  • energética
  • infantil
  • caótica

🦊 Kitsune

garota-raposa

Mais:

  • elegante
  • espiritual
  • misteriosa
  • manipuladora

💾 O LADO ESPIRITUAL

Muitos templos japoneses ligados ao deus:

Inari

possuem:

  • estátuas de raposas
  • símbolos kitsune
  • referências espirituais

Ou seja:
a criatura possui raízes religiosas reais.


☕ O IMPACTO CULTURAL

Hoje as kitsunes estão em:

  • VTubers
  • animes
  • jogos mobile
  • cultura streamer
  • avatars digitais

Viraram:

um símbolo definitivo da estética otaku moderna.


💀 RESUMINDO NO ESTILO BELLACOSA MAINFRAME

Uma kitsune de anime é:

a evolução visual otaku de uma entidade espiritual milenar japonesa.

Ou:

um sistema mitológico ancestral recompilado em formato moe de alta compatibilidade emocional.

Ela mistura:

  • folclore
  • espiritualidade
  • sedução
  • kawaii
  • fantasia
  • escapismo emocional

E sinceramente?

A cultura anime percebeu cedo que:

🦊 adicionar orelhas de raposa aumenta o “throughput afetivo” do personagem em pelo menos 300%.

quarta-feira, 15 de outubro de 2014

⚠️💣 Puchi Suri — O “Evento de Estouro” em Miniatura no Sistema

 

Bellacosa Mainframe apresenta o puchi suri

⚠️💣 Puchi Suri — O “Evento de Estouro” em Miniatura no Sistema

Se você viu “puchi suri” em anime…
provavelmente está lidando com uma combinação de gírias, não um conceito formal.


🧠 Decomposição do termo

🔹 “Puchi” (プチ)

  • Significa: pequeno, mini, compacto
  • Muito usado em anime para versões “chibi” ou reduzidas

📌 Tradução Bellacosa:

puchi = versão reduzida / instância leve


🔹 “Suri” (スリ / 擦り)

Pode ter vários sentidos dependendo do contexto:

  1. Esfregar / roçar
  2. Movimento repetitivo
  3. Em contextos +18 → pode ter conotação sugestiva

📌 Tradução técnica:

suri = interação por fricção / contato repetido


⚙️ Interpretação combinada

👉 Puchi Suri = interação pequena, repetitiva e próxima

Dependendo do contexto pode significar:

  • Situação cômica (personagens se esbarrando)
  • Cena “fofa” com contato físico leve
  • OU versão mais sugestiva em conteúdo adulto

📺 Onde aparece

Você pode ver esse tipo de expressão em:

  • Animes slice of life
  • Comédia ecchi
  • Conteúdo fanservice
  • Doujin / fandom

🧠 Versão Bellacosa Mainframe

Puchi Suri = evento de interação leve, repetitiva e de baixa escala que pode escalar dependendo do contexto do sistema


⚠️ Observação importante

O significado muda MUITO com o contexto:

ContextoSignificado
Comedy animecontato físico leve
Chibi sceneinteração fofa
Ecchisugestivo
Doujinpode ser explícito

👉 Ou seja:

não é o termo… é o ambiente que define o comportamento


💣 Conclusão

“Puchi suri” não é uma criatura, conceito mitológico ou sistema formal.

É:

  • gíria
  • composição informal
  • altamente dependente do contexto

🔥 Versão Bellacosa Final

Puchi suri não é um comando fixo…
é um evento ambíguo que muda completamente dependendo de onde está rodando.

 

terça-feira, 14 de outubro de 2014

💣🔥 SYSTEM DESIGN — O DIA EM QUE O COBOL DEIXA DE SER PROGRAMA… E VIRA ARQUITETURA DE PODER 🔥💣

 

Bellacosa Mainframe introduz o System Design

💣🔥 SYSTEM DESIGN — O DIA EM QUE O COBOL DEIXA DE SER PROGRAMA… E VIRA ARQUITETURA DE PODER 🔥💣

Se você programa em COBOL e acha que “system design” é coisa de arquiteto engravatado fazendo diagrama bonito… cuidado.

Você pode estar executando jobs perfeitos… dentro de um sistema mal projetado.

E aí não tem abend que denuncie o problema.


🧠 O QUE É SYSTEM DESIGN (TRADUZINDO PARA COBOL MENTAL)

System Design não é código.

É decidir antes do código existir:

  • Onde o dado nasce
  • Como ele trafega
  • Quem processa
  • Quem valida
  • Quem garante consistência
  • E quem aguenta o tranco quando tudo dá errado

👉 Em linguagem de mainframe:

System Design é o JCL invisível da arquitetura inteira


🏛️ ORIGEM — ANTES DO COBOL, ANTES DO SEU JOB

System Design nasce junto com a computação moderna.

  • Anos 60–70: Mainframes da IBM dominam o mundo corporativo
  • Surge o conceito de processamento batch vs online
  • Sistemas passam a lidar com:
    • milhões de registros
    • concorrência
    • consistência de dados

É aqui que entra o design.

Porque sem design…

👉 o sistema vira um monte de programas que “funcionam”… mas não escalam.


⚙️ A ERA DE OURO DO DESIGN: CICS, DB2 E O NASCIMENTO DA ARQUITETURA

Quando surgem tecnologias como:

  • CICS
  • DB2

o problema muda:

Antes:

Rodar programa

Depois:

Orquestrar milhares de transações simultâneas

E aí nasce o System Design moderno:

  • controle transacional
  • isolamento de dados
  • rollback
  • filas
  • throughput

👉 Isso não é mais programação.
👉 Isso é engenharia de sistema.


🔥 ANALOGIA BELLACOSA

Você, programador COBOL:

  • escreve o programa = módulo
  • escreve JCL = execução
  • usa VSAM/DB2 = armazenamento

Mas o System Design pergunta:

“E quando 10 milhões de clientes acessarem ao mesmo tempo… o que acontece?”


🧩 COMPONENTES DE UM SYSTEM DESIGN (TRADUZIDO PARA MAINFRAME)

1. Entrada de dados

  • Arquivo VSAM?
  • MQ?
  • API REST via z/OS Connect?

2. Processamento

  • Batch (JCL)
  • Online (CICS)
  • Híbrido

3. Persistência

  • DB2
  • VSAM
  • GDG

4. Consistência

  • Commit / Rollback
  • Controle de concorrência

5. Escalabilidade

  • Paralelismo de jobs
  • Balanceamento de carga

6. Resiliência

  • Restart automático
  • Checkpoints
  • Logs (SMF, JES)

🧪 EXEMPLO PRÁTICO — SISTEMA BANCÁRIO

Imagine:

👉 Transferência entre contas

Sem design:

  • Um programa COBOL atualiza conta A
  • Outro atualiza conta B

💣 Problema:
Se cair no meio → dinheiro some


Com System Design:

  • Transação controlada no CICS
  • Commit só ocorre quando tudo está consistente
  • Rollback garante integridade

👉 Isso é design salvando o sistema.


🧬 PASSO A PASSO — COMO PENSAR COMO UM ARQUITETO (MESMO SENDO COBOL)

🔹 1. Entenda o fluxo

Antes de codar:

  • de onde vem o dado?
  • para onde vai?
  • quem usa?

🔹 2. Modele falhas

Pergunte:

  • e se cair?
  • e se duplicar?
  • e se atrasar?

🔹 3. Separe responsabilidades

  • programa A = valida
  • programa B = processa
  • programa C = grava

👉 Não misture tudo (anti-pattern clássico COBOL 😄)


🔹 4. Pense em volume

  • 100 registros ≠ 100 milhões

🔹 5. Pense em concorrência

  • 1 usuário ≠ 10.000 simultâneos

🚀 COMO COMEÇAR (CAMINHO REALISTA)

Se você é COBOL:

Aprenda:

  • Conceitos de arquitetura distribuída
  • Filas (MQ)
  • APIs
  • Transações
  • Design patterns

Pratique:

  • Simule um sistema de pagamentos
  • Modele falhas
  • Crie fluxo batch + online

Evolua:

  • Integração com APIs modernas
  • Event-driven architecture
  • Observabilidade

🧠 O QUE VOCÊ PRECISA ENTENDER (DE VERDADE)

System Design não é ferramenta.

É mentalidade.

Você precisa dominar:

  • consistência vs performance
  • acoplamento vs flexibilidade
  • disponibilidade vs integridade

👉 Isso é trade-off.
👉 Isso é engenharia.


🕵️ CURIOSIDADES (QUE POUCOS CONTAM)

  • Muitos sistemas bancários de hoje ainda rodam design criado nos anos 80
  • O que mudou foi a interface, não o core
  • Mainframe já fazia “alta escala” antes da nuvem existir

🥚 EASTER EGG (NÍVEL MAINFRAME ROOT)

O conceito moderno de:

  • microserviços
  • filas
  • event-driven

👉 já existia, de forma conceitual, dentro do mainframe

Só com nomes diferentes:

  • programa = serviço
  • fila = dataset / MQ
  • evento = transação CICS

⚠️ ERRO CLÁSSICO DE PROGRAMADOR COBOL

Achar que:

“Se o programa funciona… o sistema está certo”

Errado.

👉 Um sistema pode estar funcionando perfeitamente… e ainda assim estar errado em design


💣 FRASE FINAL (ESTILO PRODUÇÃO CRÍTICA)

“Código resolve problema local.
Design decide se o sistema sobrevive.”

 

segunda-feira, 13 de outubro de 2014

Iniciação ao REXX – Quando o Mainframe Te Apresenta um Novo Amigo

 


Iniciação ao REXX – Quando o Mainframe Te Apresenta um Novo Amigo

“REXX não é moda. REXX é sobrevivência.”

Quem trabalha com z/OS, z/VM ou IBM Z cedo ou tarde chega a essa constatação:
não importa quantos produtos enterprise você tenha, sempre haverá aquele momento em que o problema é pequeno demais para COBOL, complexo demais para JCL e burocrático demais para justificar uma nova ferramenta.

É exatamente nesse espaço — invisível para muitos — que mora o REXX.

Subestimado, silencioso, quase sempre ignorado… até o dia em que você descobre que ele resolve 80% das dores do dia a dia com meia dúzia de linhas.

Este post é um convite:
👉 conhecer o REXX não como linguagem, mas como companheiro de trincheira no mainframe.



📜 Um pouco de história (porque nada no mainframe surge do nada)

O REXX (Restructured Extended Executor) nasceu em 1979, dentro da IBM, criado por Mike Cowlishaw.
A motivação era simples e genial:

Criar uma linguagem fácil de ler, difícil de quebrar e totalmente integrada ao sistema.

Enquanto o mundo brigava com sintaxe pesada, pontuação excessiva e códigos ilegíveis, o REXX nasceu com uma ideia revolucionária para a época:

  • tudo é string

  • tipagem dinâmica

  • sintaxe próxima do inglês

  • tolerância a erro humano

📌 Curiosidade:
REXX é mais antigo que Perl, Python e Ruby — e já fazia muita coisa que elas só popularizaram décadas depois.


🧠 REXX não vive sozinho: ambientes de processamento e comando

Aqui está o primeiro choque para quem vem de linguagens “tradicionais”:

👉 REXX não existe fora de um ambiente.

Antes de escrever código, você precisa entender onde ele roda e com quem ele conversa.

Ambientes de Processamento

  • TSO/E

  • ISPF

  • Batch TSO

  • Batch não-TSO

  • z/VM (CMS / CP)

O mesmo EXEC pode se comportar de forma totalmente diferente dependendo do ambiente.

📌 Easter egg de sobrevivência:

Se você não sabe em que ambiente está, o erro não é do REXX — é seu.


Ambientes de Comandos

REXX não executa comandos diretamente.
Ele endereça comandos a um ambiente específico.

address tso "listcat level('USER01')" address ispexec "display panel(MYPANEL)"

Isso explica por que REXX é tão poderoso:
ele fala a língua do sistema.


🧱 Fundamentos do REXX – Simples, mas não simplório

Filosofia da linguagem

  • Tudo é string

  • Conversão automática quando necessário

  • Pouca pontuação

  • Código legível

  • Menos regras, mais resultado

say 'Hello, Mainframe!'

Sem ponto e vírgula.
Sem BEGIN obrigatório.
Sem cerimônia.

📌 Curiosidade perigosa:
Variáveis não inicializadas não geram erro.
Elas retornam o próprio nome.
Ótimo para debug… péssimo se você não souber 😄


Entrada, saída e lógica

  • SAY → saída

  • PULL → entrada (stack)

  • IF / THEN / ELSE

  • DO / END

  • EXIT

Aqui o REXX começa a mostrar sua vocação: automatizar decisões, não apenas executar código.


🖥️ REXX e o Ambiente TSO – Onde a mágica começa

Com REXX você:

  • aloca datasets

  • consulta catálogos

  • automatiza comandos

  • elimina JCL desnecessário

address tso "allocate fi(arq1) da('user.test.ps') shr" address tso "listalc"

📌 Comentário Bellacosa:
REXX + TSO = menos JCL, menos erro, menos dor de cabeça.


📦 CLISTs x EXECs – O passado e o presente

CLIST fez história.
Mas o REXX fez melhor.

  • EXECs são mais poderosos

  • Mais legíveis

  • Mais fáceis de manter

  • Melhor integração

Entender a sequência de busca (SYSEXEC, SYSPROC…) é obrigatório.

📌 Easter egg clássico:
“EXEC não encontrado” quase sempre é DD errado, não código errado.


🔁 Programação REXX – Onde o iniciante vira sysprog

Aqui o REXX mostra que não é brinquedo:

  • Funções e subrotinas

  • Escopo de variáveis

  • DO composto

  • ITERATE e LEAVE

  • SELECT (case statement elegante)

  • SIGNAL e SIGNAL VALUE

  • INTERPRET (meta-programação!)

cmd = "say 'REXX é poderoso'" interpret cmd

📌 Comentário raiz:
INTERPRET é um sabre de luz.
Poderoso… mas não entregue para qualquer padawan.


🌳 Variáveis, Strings e o poder do PARSE

Stems – arrays antes dos arrays

nome.1 = 'Ana' nome.2 = 'João' nome.0 = 2

PARSE – o superpoder escondido

parse var linha campo1 ',' campo2

📌 Curiosidade:
PARSE elimina dezenas de IFs, SUBSTRs e gambiarras.


📂 EXECIO – O mini DFSORT do dia a dia

"EXECIO * DISKR ARQ1 (STEM LIN.)"

Com EXECIO você:

  • lê arquivos

  • grava datasets

  • processa linhas

  • automatiza relatórios

Tudo sem sair do REXX.


🧪 Depuração – Porque errar faz parte

REXX não te abandona quando algo dá errado:

  • TRACE

  • RC

  • SIGL

  • SOURCELINE

  • CONDITION

📌 Curiosidade histórica:
Debug nativo em REXX era luxo quando muitas linguagens nem sonhavam com isso.


⚙️ Batch, endereços e ambientes avançados

REXX roda:

  • em batch TSO

  • fora do TSO

  • em múltiplos ambientes de comando

say address()

📌 Comentário Bellacosa:

Antes de perguntar “por que falhou”, pergunte “onde estou rodando”.


🚀 Compilador REXX – Performance e proteção

Sim, REXX pode ser compilado:

  • melhora performance

  • protege código

  • usado em ambientes críticos

Mesmo compilado, ele não perde sua alma dinâmica.


☕ Conclusão – Por que REXX vira amigo

REXX não tenta competir com COBOL.
Não substitui Assembler.
Não briga com produtos enterprise.

Ele faz algo muito mais valioso:

👉 resolve problemas reais com o que já existe no sistema.

Quem domina REXX:

  • automatiza mais

  • depende menos

  • entende melhor o ambiente

  • sobrevive melhor no data center

No mainframe, o melhor amigo
não é o software mais caro…
é o que resolve às 3 da manhã.

Bem-vindo ao REXX.
Ele sempre esteve aí. ☕🖥️


sábado, 11 de outubro de 2014

🧹 A Dança da Vassoura

 

Bellacosa Mainframe e o famoso baile da dança das vassouras


🧹 A Dança da Vassoura

Regras oficiais, caos controlado e diversão garantida

Se você nunca ouviu falar da dança da vassoura, sente-se, jovem padawan: isso aqui era engenharia social aplicada ao bailinho escolar.

A dança da vassoura não era castigo. Muito pelo contrário.
Ela era o modo bônus, o feature escondido do sistema.

🔹 O setup (ambiente de produção)

  • Bailinho rolando

  • Música lenta ou animada (não importa)

  • Vários pares dançando

  • Um rapaz sem par

  • Uma vassoura emprestada da tia da limpeza (recurso compartilhado)

Esse rapaz passa a dançar com a vassoura.
Mas atenção: isso não é humilhação.
É poder absoluto temporário.



🔹 A Regra de Ouro

O rapaz que dança com a vassoura ganha um super bônus:

👉 Ele pode escolher qualquer par que esteja dançando
👉 Tocar no ombro da garota
👉 Substituí-la pela vassoura

A garota passa a dançar com ele
E o rapaz “desalojado” assume a vassoura.

Swap de processos em tempo real.




🔹 Restrições importantes (porque até diversão tem governança)

  • ❌ Não pode voltar ao mesmo par imediatamente

  • ❌ Não pode recusar o convite (“não” não existe no protocolo)

  • ✅ Tem que ir atrapalhar outro par

  • ✅ O objetivo é movimentar todo mundo

Ou seja:
ninguém fica parado,
ninguém fica excluído,
todo mundo dança com todo mundo.




🔹 A dinâmica real (ou: caos elegante)

Enquanto a música toca:

  • pares se desfazem

  • novos pares se formam

  • risadas explodem

  • a sala vira um sysplex emocional

  • a vassoura circula como token de controle

É democracia dançante.
É inclusão forçada com sorriso no rosto.
É zoação sem crueldade.


🔹 Por que isso funcionava tão bem?

Porque:

  • Quebrava a timidez

  • Evitava panelinhas

  • Misturava a turma inteira

  • Criava histórias que duram décadas

Era impossível ficar invisível.
Em algum momento, todo mundo dançava.


🔹 Easter egg social dos anos 80

  • Quem “amarelava” virava lenda

  • Quem segurava a vassoura com estilo virava herói

  • Casal que se conheceu na dança da vassoura?
    História registrada em memória não volátil


🔹 Versão Bellacosa Mainframe (tradução técnica)

  • Música = job em execução

  • Vassoura = controle de concorrência

  • Par = sessão ativa

  • Troca = context switch

  • Zoação = logging habilitado

  • Diversão = SLA cumprido com sucesso


No fim das contas, a dança da vassoura era isso:
uma forma simples, genial e inocente de dançar, zoar, misturar e aproximar.

Sem aplicativo.
Sem algoritmo.
Sem like.

Só gente, música, risada…
e uma vassoura rodando em produção.

🧹💃🕺