☕ 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

segunda-feira, 9 de fevereiro de 2026

aMule 2026 : Quando um Programador Descobre que a Última Biblioteca Distribuída da Internet Continua Viva... Guardando Tesouros que o Mundo Esqueceu

 

Bellacosa Mainframe apresenta o aMule

☕ Um Café no Bellacosa Mainframe

aMule 2026 sem Mistérios para Programadores COBOL

Quando um Programador Descobre que a Última Biblioteca Distribuída da Internet Continua Viva... Guardando Tesouros que o Mundo Esqueceu

"A verdadeira arqueologia não procura ouro. Ela procura conhecimento."


Introdução — O Último Guardião da Biblioteca Perdida

Durante quase vinte anos, milhares de pessoas declararam:

"O eMule morreu."

Mas havia um detalhe.

Ele possuía um irmão.

Mais silencioso.

Mais discreto.

Mais técnico.

Mais próximo da filosofia UNIX.

Seu nome era aMule.

Enquanto Windows caminhava para serviços em nuvem, smartphones e streaming, o aMule permaneceu fiel à missão original:

Preservar conhecimento distribuído.

Em 2026 ele talvez seja um dos últimos sobreviventes da geração clássica de redes P2P.

Mas continua extremamente interessante para qualquer arquiteto de sistemas distribuídos.

Principalmente para quem trabalha com IBM Mainframe.


Capítulo I — O que é o aMule?

O aMule significa:

all-platform eMule

Seu objetivo sempre foi simples.

Levar o protocolo eD2k/Kad para qualquer sistema operacional.

Hoje funciona em:

  • Linux

  • BSD

  • macOS

  • Windows

  • Raspberry Pi

  • diversos NAS

É praticamente o "COBOL" das redes P2P.

Roda em qualquer lugar.


Capítulo II — Filosofia UNIX

O eMule nasceu no Windows.

O aMule nasceu pensando diferente.

Pequeno.

Modular.

Configurável.

Automatizável.

Perfeito para servidores Linux.

Muitos usuários nunca abriram sua interface gráfica.

Controlavam tudo via navegador.


Capítulo III — O Arquiteto Invisível

Imagine um pequeno servidor Linux.

Consumo:

2 Watts

Ligado:

24 horas

Compartilhando documentos históricos.

Essa sempre foi a verdadeira força do aMule.

Ele não precisava de um computador gamer.

Precisava apenas de persistência.


Capítulo IV — Arquitetura

Internamente continua utilizando:

  • eD2k

  • Kad

  • Hashes

  • Download por blocos

  • Filas inteligentes

  • Créditos

São conceitos extremamente modernos.

Muito próximos de vários sistemas distribuídos atuais.


Capítulo V — O Poder do aMule Daemon

Aqui aparece uma diferença gigantesca.

Existe o:

amuled

Ou seja...

O programa roda como serviço.

Sem monitor.

Sem teclado.

Sem interface.

Lembra muito um Started Task do z/OS.

Você apenas inicia.

Ele permanece funcionando durante meses.


Capítulo VI — Interface Web

Existe também:

amuleweb

A administração ocorre pelo navegador.

Qualquer computador pode controlar o servidor.

É praticamente um z/OSMF da comunidade P2P.

https://eljefemidnightlunch.blogspot.com/2015/04/quando-os-arquivos-eram-tesouros-pre.html


Capítulo VII — aMuleCMD

Outro recurso fantástico.

Controle via linha de comando.

Scripts.

Automação.

Cron.

Bash.

Python.

Imagine integrar com:

  • IA

  • OCR

  • Elasticsearch

  • PostgreSQL

Tudo automaticamente.


Capítulo VIII — Segurança

O aMule amadureceu bastante.

Hoje recomenda-se:

  • portas bem configuradas

  • firewall

  • acesso remoto protegido

  • atualizações constantes

O protocolo continua utilizando mecanismos clássicos do eD2k e Kad, mas o ambiente onde ele roda pode ser protegido com as ferramentas modernas do sistema operacional, como firewalls, VPNs e autenticação forte para acesso remoto.


Capítulo IX — Compatibilidade

Uma das maiores vantagens.

Funciona perfeitamente em:

Ubuntu.

Debian.

Fedora.

Arch.

OpenSUSE.

TrueNAS.

OpenMediaVault.

Synology.

QNAP.

Até pequenos mini-PCs Intel N100 ou Raspberry Pi conseguem mantê-lo funcionando continuamente com baixo consumo de energia.


Capítulo X — Comunidade

Ela diminuiu.

Mas nunca desapareceu.

Ainda existem:

  • desenvolvedores

  • mantenedores

  • usuários

  • fóruns

  • servidores

  • Kad

É uma comunidade pequena.

Mas extremamente apaixonada.


Capítulo XI — O Futuro

Aqui entra um exercício interessante.

Imagine o:

aMule 2026

Com:

  • IA

  • OCR automático

  • PostgreSQL

  • ElasticSearch

  • IPv6 nativo

  • QUIC

  • Docker

  • Kubernetes

  • REST API

  • OpenTelemetry

  • Prometheus

  • Grafana

De repente...

Ele deixa de ser um downloader.

Passa a ser um sistema distribuído de preservação documental.


Capítulo XII — O NAS Doméstico

Imagine:

Mini PC

↓

Linux

↓

Docker

↓

aMuled

↓

OCR

↓

IA

↓

Biblioteca Particular

Todos os documentos automaticamente catalogados.

Pesquisáveis.

Indexados.

Disponíveis.


Capítulo XIII — Bellacosa Mainframe Edition

Se eu pudesse projetar uma versão especial...

Ela teria:

✔ IA local

✔ OCR

✔ reconhecimento automático de livros IBM

✔ classificação por tecnologia

✔ integração com Git

✔ API REST

✔ painel Grafana

✔ suporte IPv6

✔ integração IPFS

✔ download híbrido

✔ deduplicação

✔ busca semântica

✔ exportação para Obsidian

✔ indexação automática em Markdown

✔ leitura de PDFs históricos

✔ geração automática de resumos

Seria praticamente um "Knowledge Vault".


Easter Eggs

Easter Egg 1

O aMuled lembra um Started Task do JES.


Easter Egg 2

Kad lembra um Parallel Sysplex sem CPC central.


Easter Egg 3

Cada bloco do arquivo parece uma página VSAM.


Easter Egg 4

A fila lembra perfeitamente o WLM distribuindo prioridades.


Easter Egg 5

A busca por hash lembra Git.


Curiosidades

  • O aMule é totalmente compatível com as redes eD2k e Kad, permitindo interoperabilidade com clientes compatíveis.

  • É amplamente utilizado em ambientes Linux e NAS por consumir poucos recursos.

  • O aMuled pode funcionar continuamente por meses, tornando-o ideal para servidores domésticos.

  • Sua arquitetura modular facilita automação e integração com scripts.

  • Muitos usuários o utilizam como parte de projetos pessoais de preservação digital.


Conclusão — O Último Bibliotecário

Talvez o aMule nunca volte a ocupar as manchetes.

Provavelmente jamais competirá com plataformas de streaming ou grandes serviços de nuvem.

Mas essa nunca foi sua missão.

Enquanto o restante da Internet corre atrás do conteúdo mais recente, o aMule continua preservando aquilo que corre o risco de desaparecer: documentação técnica, materiais históricos, obras em domínio público e outros acervos distribuídos pela comunidade.

Para um programador COBOL, essa filosofia soa familiar.

Nos mainframes da IBM, os sistemas mais importantes não são necessariamente os mais modernos ou os mais chamativos. São aqueles que continuam funcionando ano após ano, preservando dados críticos com confiabilidade.

O aMule segue exatamente essa mesma lógica.

Ele representa uma Internet construída sobre colaboração, persistência e respeito pelo conhecimento.

Talvez o verdadeiro legado do aMule em 2026 não seja o protocolo eD2k.

Talvez seja lembrar uma verdade que todo arquiteto de sistemas aprende cedo:

Tecnologias passam. Conhecimento permanece. E comunidades comprometidas são capazes de preservar ambos por muito mais tempo do que imaginamos.

☕ Um Café no Bellacosa Mainframe

Arquivo recuperado da Biblioteca Perdida da Internet

eMule sem Mistérios

Quando um Programador Descobre que a Maior Biblioteca da Internet Não Foi Construída por Empresas Bilionárias, mas por Milhões de Desconhecidos Compartilhando Pequenos Pedaços do Mesmo Tesouro

“A verdadeira arqueologia digital não procura ouro. Procura conhecimento que o tempo tentou apagar.”

Uma expedição pela história do eMule, eD2k e Kad

O artigo apresenta uma jornada pela história do eMule, da rede eD2k e do protocolo descentralizado Kad, explicando como milhões de computadores colaboraram para formar uma das maiores bibliotecas distribuídas da Internet.

Em uma narrativa inspirada nas aventuras arqueológicas de Indiana Jones, o leitor descobre como funcionavam os hashes, downloads fragmentados, sistemas de créditos, filas, compartilhamento entre pares, servidores de indexação e redes descentralizadas.

O conteúdo também relaciona essa arquitetura aos conceitos de COBOL, IBM Mainframe, VSAM, Db2, WLM e sistemas distribuídos modernos.

Artefato localizado. Aguardando abertura da câmara.

Caso o artigo não seja exibido dentro da página, acesse diretamente o registro original da expedição.

📜 Ler o artigo completo em uma nova janela

eMule · eDonkey2000 · eD2k · Kad · P2P · COBOL · IBM Mainframe · redes distribuídas · preservação digital · arqueologia da Internet

🗡️🏇 A ORIGEM DE GALAHAN SEM CABEÇA

Galahan sem cabeça



🗡️🏇 Galahan Sem Cabeça 

O Processo Fantasma que Nunca Dá LOGOFF

Se a Harpia é o job barulhento e a Cocatrice é o bug vivo, o Galahan Sem Cabeça é aquele processo zumbi que morreu faz séculos…
mas continua executando.

Sem cabeça.
Sem rosto.
Sem misericórdia.

E sempre aparece quando ninguém quer estar em produção.


📜 Origem e História — Quando a Morte Esqueceu de Encerrar o Job

A lenda do cavaleiro sem cabeça tem raízes profundas na Europa medieval, especialmente em:

  • Folclore celta (Irlanda, Escócia, País de Gales)

  • Tradições germânicas

  • Lendas normandas

Mas ganhou forma definitiva no conto “The Legend of Sleepy Hollow” (1820), de Washington Irving.

📌 Origem clássica:

  • Um cavaleiro decapitado em batalha

  • Um traidor executado

  • Um nobre amaldiçoado

  • Um soldado que morreu sem honra

📌 Tradução Bellacosa:

O job foi abortado no meio… e ninguém limpou a memória.


🧬 Classificação no Bestiário Fantástico

Em RPGs e fantasia, o Galahan Sem Cabeça costuma ser classificado como:

  • 👻 Morto-vivo

  • ⚔️ Espírito vingativo

  • 🏇 Cavaleiro espectral

  • ☠️ Ameaça média a alta

Ele não é monstro aleatório.
Ele é evento de calendário.


👁 Aparência — O Erro Mais Icônico da Fantasia

Visual clássico e inconfundível:

  • Armadura medieval (enferrujada ou espectral)

  • Corpo intacto

  • Pescoço sangrando ou envolto em névoa

  • Cabeça ausente… ou carregada na mão

  • Montaria fantasmagórica (geralmente preta)

🎭 Em algumas versões:

  • A cabeça é uma caveira em chamas

  • Ou uma abóbora iluminada (versão americana)

📌 Design perfeito:

Simples, reconhecível e assustador sem precisar explicar nada.


🎲 Atributos Típicos (RPG Clássico)

Em AD&D, OSR e D&D raiz:

  • Classe de Armadura: Alta (armadura espectral)

  • Dados de Vida: 8–12 HD

  • Movimento: Alto (a cavalo)

  • Ataques:

    • Espada longa / machado

    • Investida montada

  • Habilidades Especiais:

    • Imunidade a medo

    • Imunidade a golpes críticos

    • Terror sobrenatural

  • Fraquezas:

    • Relíquias sagradas

    • Rituais de encerramento

    • Cumprir o “assunto pendente”

📌 Bellacosa mode:

Ele não pode ser morto… só finalizado corretamente.


🧠 Comportamento e “Ecologia”

  • Surge à noite

  • Aparece em estradas, pontes, encruzilhadas

  • Persegue alvos específicos

  • Não fala (ou fala pouco)

  • Não negocia

Ele não caça por fome.
Ele executa uma rotina maldita.


🧙‍♂️ Dicas para Mestres (GM Tips)

🎯 Use o Galahan para:

  • Terror psicológico

  • Campanhas investigativas

  • Quebrar a lógica de “HP resolve tudo”

  • Criar mistério recorrente

📌 Dica Bellacosa:

Não use como encontro único.
Use como sintoma de algo errado no mundo.


🤫 Fofoquices Históricas

  • Cavaleiros decapitados eram vistos como amaldiçoados

  • Perder a cabeça simbolizava perder honra e identidade

  • Em algumas vilas, a lenda servia para:

    • Evitar viagens noturnas

    • Assustar crianças

    • Justificar mortes inexplicáveis

📌 Fofoquinha raiz:

Muitas vezes a “assombração” escondia crimes bem humanos.


🕯️ Curiosidades Macabras

  • Alguns contos dizem que ele procura sua cabeça

  • Outros afirmam que a cabeça nunca foi dele

  • Às vezes ele só persegue culpados

  • Às vezes… qualquer um no caminho


🕹️ Easter Eggs na Cultura Pop

  • Sleepy Hollow (livro, filmes, série)

  • Castlevania – chefes sem cabeça

  • Dark Souls / Elden Ring – cavaleiros espectrais

  • D&D – Death Knights e variantes headless

  • Halloween – abóboras flamejantes 🎃

🎮 Easter Egg clássico:

Todo cavaleiro morto-vivo montado deve algo ao Galahan.


🧠 Interpretação Simbólica (Modo Bellacosa ON)

O Galahan representa:

  • Culpa não resolvida

  • Violência sem encerramento

  • Honra perdida

  • O passado que retorna

Na vida e no RPG:

Problemas ignorados voltam mais fortes.

No mainframe:

Job mal encerrado vira incidente.


📌 Conclusão — O Galahan Nunca Parte, Ele Aguarda

O Galahan Sem Cabeça não quer vencer.
Não quer dominar.
Não quer conversar.

Ele só quer que alguém finalize o processo corretamente.

E até lá…
ele continuará cavalgando no escuro,
esperando o próximo inocente passar pela estrada errada.


Se quiser, posso:
✔ Criar uma ficha completa de RPG
✔ Adaptar para D&D 5e / OSR / Tormenta
✔ Criar uma mini-campanha temática
✔ Escrever sobre Dullahan, Death Knight, Cavaleiro Negro ou Banshee

É só dizer qual lenda sobe no próximo job fantasma 🖥️👻

domingo, 8 de fevereiro de 2026

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳 O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

 

Bellacosa Mainframe em uma viagem ao Addressability do z/os

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳

O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

Você acha que seu COBOL acessa memória direto?

👉 Não acessa.

No mainframe, nada é direto.
Tudo passa por:

  • tradução
  • autorização
  • tabelas
  • registradores
  • controle do sistema

Se você não entende isso…
👉 você nunca vai dominar dump, performance ou abend 💀


🧠 O QUE É ADDRESSABILITY (SEM ENROLAR)

Addressability é:

a capacidade de um programa acessar dados — onde quer que eles estejam


💡 Tradução Bellacosa

“Addressability é o GPS + chave + autorização da memória.”


⚙️ 1. DISPATCHING WORK — ONDE TUDO COMEÇA

Quando sua task roda:

  • dispatcher escolhe
  • CPU assume
  • CR1 é carregado

👉 CR1 aponta para o address space ativo


🔥 Insight

CR1 define “qual mundo você está enxergando”


🌍 2. VIRTUAL STORAGE — O UNIVERSO NÃO É REAL

Cada usuário tem:

👉 seu próprio universo de memória


🔹 Características:

  • até 16 exabytes 😳
  • isolado
  • protegido

💡 História

MVS = Multiple Virtual Storage

👉 desde os anos 70 já fazia isso


🧨 Easter Egg

Você acha que está acessando memória real…

👉 está acessando endereço virtual traduzido


🧩 3. ADDRESS SPACE — SUA “BOLHA”

Tudo roda dentro de:

👉 um address space


🔹 Tipos:

  • Batch
  • TSO
  • Started Task

💡 Insight

cada programa vive isolado


🔗 4. CROSS MEMORY — QUEBRANDO A BOLHA

Mas… o sistema permite sair dela.


🔹 O que é?

Acessar outro address space


🔥 Exemplo real

COBOL → chama serviço → DB2 → retorna

👉 são address spaces diferentes


💡 Estados:

  • Home → origem
  • Primary → execução
  • Secondary → dados

🧨 Curiosidade

Se são diferentes:

👉 você está em cross-memory mode


🚀 5. PROGRAM CALL (PC) — O TELEPORTE DO z/OS

🔹 O que faz?

  • troca de address space
  • mantém controle
  • permite retorno

🔥 Fluxo real

User → LLA → VLF → módulo → volta

👉 tudo invisível


💡 Tradução

PC é um “portal controlado”


🧱 6. LINKAGE STACK — A MEMÓRIA DA EXECUÇÃO

Sempre que um programa chama outro:

👉 estado é salvo automaticamente


🔹 Salva:

  • registradores
  • PSW
  • access registers

💡 Vantagens

  • menos erro
  • suporte a reentrância
  • debug mais limpo

🧨 Curiosidade

Substitui os antigos save areas


⚙️ 7. ACCESS REGISTERS — O PODER ESCONDIDO

🔹 O que são?

  • 16 registradores
  • permitem acessar outros espaços

🔥 Funcionamento

AR → qual espaço
GR → qual dado

💡 Tradução Bellacosa

AR = endereço do universo
GR = endereço dentro do universo


🧠 8. ACCESS LIST / ALET / ALE — CONTROLE DE ACESSO

Nada é livre.


🔹 Processo:

  1. obter S-token
  2. ALESERV
  3. criar ALE
  4. gerar ALET
  5. carregar AR

💡 Insight

acesso exige autorização formal


🧨 Curiosidade

Sem isso:

👉 proteção de memória bloqueia acesso


⚡ 9. ADDRESSABILITY MODES

🔹 AMODE

  • 24-bit
  • 31-bit
  • 64-bit

🔹 RMODE

  • onde o programa carrega

💡 História

Compatibilidade com décadas de software


🔄 10. PASSO A PASSO COMPLETO

Task é despachada
↓
CR1 define address space
↓
Programa executa
↓
Se precisar:
→ PC (outro space)
→ AR (outro data space)
↓
Linkage stack salva estado
↓
Retorno

💀 ONDE ISSO APARECE NA VIDA REAL?

🔥 Dump (IPCS)

Você vê:

  • PSW
  • registers
  • ARs
  • linkage stack

🔥 Abend clássico

👉 S0C4 = erro de addressability


🔥 Performance

  • cross memory custa
  • LPA melhora

🧨 CURIOSIDADES (NÍVEL JEDI)

🤯 1. Um programa pode acessar vários universos ao mesmo tempo


🔥 2. Memória é totalmente virtual


💀 3. Um erro de ponteiro quebra tudo (S0C4)


🧠 4. O sistema controla TUDO via tabelas


🎯 RESUMO FINAL

✔ Addressability = acesso controlado

✔ Address space = isolamento

✔ Cross memory = comunicação

✔ PC = chamada entre espaços

✔ AR = acesso avançado

✔ Linkage stack = estado


💥 FRASE FINAL

“No mainframe, memória não é um lugar… é um privilégio concedido pelo sistema.”

 

🪶🦅 A ORIGEM DA HARPIA

Harpia

🪶🦅 A ORIGEM DA HARPIA

O Job Voador que Nunca Pede Permissão

Se dragões são os mainframes alados da fantasia e cocatrices são bugs vivos, a Harpia é o job interativo que entra no sistema gritando, bagunça tudo, rouba dados… e sai voando antes que alguém consiga dar CANCEL.

Ela não cospe fogo.
Ela não petrifica.
Mas ela desorganiza, seduz, confunde e mata — e ainda ri disso.


📜 Origem e História — Nascidas do Vento e da Maldição

As Harpias surgem na mitologia grega, muito antes dos RPGs, nos textos de Hesíodo e Homero.

Originalmente, elas não eram “monstros” no sentido clássico, mas espíritos do vento, associadas a:

  • Tempestades

  • Ar contaminado

  • Castigos divinos

📌 Curiosidade Bellacosa:

As Harpias começaram como serviços de sistema dos deuses — depois viraram ameaça de produção.

Com o tempo, passaram a ser descritas como criaturas punitivas, usadas por Zeus para atormentar mortais insolentes.


🧬 Classificação no Bestiário Fantástico

Em RPGs e fantasia clássica, a Harpia costuma ser classificada como:

  • 🐉 Humanoide Monstruoso

  • 🪶 Criatura Alada

  • 🧠 Inteligência baixa a média

  • ⚠️ Ameaça de baixo a médio nível

Ela raramente é “boss”.
Ela é problema recorrente.


👁 Aparência — Beleza Que Vem com Erro Fatal

A aparência clássica da Harpia é um paradoxo visual:

  • Corpo de ave de rapina

  • Cabeça e torso de mulher

  • Garras afiadas

  • Asas grandes e desengonçadas

  • Rosto bonito… até abrir a boca

🎭 Versões antigas descrevem:

Mulheres aladas com cheiro de morte e lixo.

Sim. Não era glamour nenhum.


🎲 Atributos Típicos (RPG Clássico)

Nos sistemas clássicos (AD&D, D&D BECMI, OSR):

  • Classe de Armadura: Baixa a média

  • Dados de Vida: 3–6 HD

  • Movimento: Alto (voo)

  • Ataques:

    • Garras

    • Arma improvisada

  • Habilidade Especial:
    🎶 Canto hipnótico / encantamento

  • Resistências:

    • Média contra magia mental

    • Baixa contra ataques à distância

📌 Tradução Bellacosa:

Se ela canta e você falha no save, você já perdeu o controle do terminal.


🧠 Comportamento e Ecologia

  • Vivem em bandos

  • Extremamente territoriais

  • Gostam de ruínas, penhascos, torres

  • Roubam comida, armas, objetos brilhantes

  • Não constroem civilização — apenas causam caos

Elas não defendem território por honra.
Defendem porque sim.


🧙‍♂️ Dicas para Mestres (GM Tips)

🎯 Use Harpias para:

  • Forçar testes mentais

  • Separar o grupo

  • Criar combates verticais

  • Punir personagens sem proteção mental

📌 Dica Bellacosa:

Harpia não luta sozinha.
Harpia puxa, divide, isola e mata.


🤫 Fofoquices Mitológicas

  • Eram consideradas impuras até pelos deuses

  • Seu toque “corrompia” alimentos

  • Em alguns mitos, eram mais odiadas que monstros verdadeiros

  • Ninguém gostava delas — nem Hades

Ou seja:

Harpia era o usuário problemático da mitologia.


🪶 Curiosidades Estranhas

  • O nome vem de harpázō (“roubar, arrebatar”)

  • Em versões antigas, elas nem eram sensuais

  • O “canto sedutor” foi uma atualização posterior

  • Algumas histórias dizem que eram imortais


🕹 Easter Eggs na Cultura Pop

  • Dungeons & Dragons – canto hipnótico clássico

  • God of War – inimigos irritantes e letais

  • Final Fantasy – ataques aéreos e status negativos

  • Castlevania – monstros de pressão constante

🎮 Easter Egg clássico:

Sempre que um inimigo voador tenta te fazer andar até a morte… é herança da Harpia.


🧠 Interpretação Simbólica (Modo Bellacosa ON)

A Harpia simboliza:

  • A sedução que destrói

  • O caos sem propósito

  • A perda de controle

  • A punição divina disfarçada de beleza

Em termos de RPG e vida:

Nem todo convite bonito é seguro.
Nem todo canto é música.


📌 Conclusão — Harpias Não São Chefes, São Testes

A Harpia não foi feita para ser lembrada como vilã final.
Ela foi criada para:

  • Desgastar

  • Confundir

  • Ensinar humildade

Assim como no mainframe,
às vezes o maior problema não é o sistema…
é o job que ninguém pediu, mas está rodando.


Se quiser, posso:
✔ Adaptar para D&D 5e / OSR / Tormenta
✔ Criar tabelas de encontros aéreos
✔ Escrever versões para Sereias, Empusas, Lamias ou Striges
✔ Transformar isso numa série de bestiário Bellacosa

Só dizer qual criatura sobe no próximo deploy 🐉🖥️

sábado, 7 de fevereiro de 2026

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀 O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

 

Bellacosa Mainframe apresenta a gestão de tarefas no z/os

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀

O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

Você digita um JCL, dá submit e pensa:
👉 “beleza, agora é só esperar o output”

Errado.

No z/OS, seu job entra em um ecossistema competitivo, onde:

  • CPU é disputada
  • memória é compartilhada
  • prioridades são negociadas
  • o sistema decide tudo

Se você quer sair do nível “usuário de mainframe” e virar engenheiro de sistema, esse é o mapa mental que muda o jogo 👊🔥


🧠 1. O COMEÇO — SUBMIT NÃO É EXECUÇÃO

Quando você faz submit:

//JOB ...

👉 seu job NÃO executa.


🔹 O que acontece de verdade

  • JES recebe
  • vai pro spool
  • ganha um número
  • entra numa fila
  • espera um initiator

🔥 Tradução Bellacosa

“Submit é só entrar na fila do sistema.”


💡 Exemplo real

Você tem 100 jobs na fila…

👉 seu job pode esperar minutos ou horas


⚙️ 2. JOB → TASK (A TRANSFORMAÇÃO INVISÍVEL)

O z/OS não trabalha com “jobs”.

👉 Ele trabalha com:

TASKS (TCBs)


🔹 Como funciona

JOB → STEPS → TASKS (TCB)

Cada step vira uma unidade executável.


🧨 Curiosidade

Um job pode gerar várias tasks simultâneas.


⚡ 3. DISPATCHER — O “DEUS DO CPU”

Esse é o cara mais importante do sistema.


🔹 Função

Decidir:

“Quem roda AGORA?”


🔥 Como ele faz isso

  • varre a fila (WUQ)
  • pega TCB ou SRB
  • escolhe o de maior prioridade
  • carrega contexto
  • entrega CPU

💡 Insight poderoso

O dispatcher troca tarefas milhares de vezes por segundo


🧠 Tradução

CPU nunca fica “presa” a um programa


🧩 4. TCB vs SRB — A BRIGA INTERNA

🔹 TCB

  • usado por aplicações (COBOL 👀)
  • pode ser interrompido

🔹 SRB

  • usado pelo sistema
  • maior prioridade
  • execução mais rápida

🔥 Tradução Bellacosa

SRB é o “VIP do sistema”
TCB é o trabalhador comum 😄


🧠 5. ENCLAVES — O NÍVEL CORPORATIVO

Aqui o sistema evolui de técnico → negócio.


🔹 O que é?

Um conjunto de tarefas:

👉 espalhadas em vários address spaces
👉 tratadas como uma unidade


🔥 Exemplo real

App Web → WAS → CICS → DB2

👉 tudo isso vira um enclave


💡 Insight

O z/OS não gerencia código… gerencia transações de negócio


🖥️ 6. PR/SM — O MESTRE DO HARDWARE

Antes do z/OS, existe:

👉 PR/SM (hypervisor)


🔹 Ele faz:

  • divide hardware em LPARs
  • entrega CPU virtual
  • controla recursos

🔥 Relação

Hardware → PR/SM → z/OS → Task

🧨 Curiosidade

Seu z/OS pode não saber qual CPU física está usando 😳


⚡ 7. CPU MANAGEMENT — ONDE PERFORMANCE NASCE

🔹 Conceitos:

  • HyperDispatch
  • afinidade CPU/memória
  • otimização de cache

💡 Insight

Rodar perto do dado = menos latência


🔥 Tradução Bellacosa

Não é só rodar… é rodar no lugar certo


👥 8. ADDRESS SPACES — O UNIVERSO ISOLADO

Cada coisa roda em seu próprio espaço:

  • Batch
  • TSO
  • Started Task

🔥 Dentro deles:

  • TCBs
  • subtasks
  • memória isolada

💡 Exemplo

Um batch:

Initiator → cria address space → cria TCB → executa

🔗 9. DYNAMIC LINKAGE — COMO OS PROGRAMAS SE CONECTAM

🔹 Comandos principais:

  • LINK
  • LOAD
  • ATTACH
  • XCTL

🔥 O que fazem?

  • chamam programas
  • carregam módulos
  • transferem controle

💡 Ordem de busca:

  1. memória (LPA)
  2. JOBLIB/STEPLIB
  3. LINKLIST

🧨 Easter Egg

Se está na LPA… é MUITO mais rápido


🧠 10. WLM — O VERDADEIRO CHEFE

🔥 Workload Manager

Define:

  • prioridade
  • objetivos
  • distribuição de CPU

💡 Exemplo real

Tipo de workloadPrioridade
pagamento onlinealta
batch relatóriobaixa

🔥 Tradução Bellacosa

O sistema não atende quem pede… atende quem importa


🔒 11. SERIALIZATION — EVITANDO O CAOS

🔹 Problema:

2 jobs querem o mesmo recurso


🔹 Solução:

  • ENQ / DEQ
  • GRS

💡 Exemplo

Dois jobs acessando dataset:

👉 um espera


🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Seu job pode nunca rodar

Se prioridade for baixa


🔥 2. CPU pode trocar de task milhares de vezes

Você nem percebe


💀 3. SRB pode interromper seu programa

Sem você saber


🧠 4. Um único negócio pode rodar em vários address spaces

(enclave)


⚙️ PASSO A PASSO REAL (SIMPLIFICADO)

Submit Job
↓
JES spool
↓
Fila de execução
↓
Initiator pega job
↓
Cria Address Space
↓
Cria TCB
↓
Dispatcher escolhe
↓
CPU executa
↓
WLM ajusta prioridade
↓
Output no spool

🎯 RESUMO FINAL

✔ Job vira task

✔ Task disputa CPU

✔ Dispatcher decide

✔ WLM prioriza

✔ PR/SM gerencia hardware

✔ Enclave agrupa negócio


💥 FRASE FINAL

“Você não executa um job no mainframe…
você entra numa competição onde o z/OS decide se você merece rodar.”


 

🐓🐍 A ORIGEM DA COCATRICE

Cocatrice

🐓🐍 A ORIGEM DA COCATRICE

O Bug Vivo do Bestiário Medieval

Se dragões são os mainframes da fantasia e basiliscos são os batch jobs mortais, a Cocatrice é aquele programa mal documentado, cheio de comportamento inesperado, que ninguém sabe direito quem criou… mas todo mundo tem medo de rodar em produção.

Ela parece absurda? Sim.
Ela é perigosa? Muito.
Ela nasceu de erro de leitura medieval? Com certeza.

Bem-vindo ao monstro que prova que nem todo bug foi corrigido.


📜 Origem e História — Quando o Monge Errou o Copy/Paste

A Cocatrice surge na Europa medieval, por volta dos séculos XII–XIV, em tratados de bestiários, alquimia e textos moralistas.

O nome vem do francês antigo cocatris, derivado do latim calcatrix (“aquela que pisa”), que por sua vez nasceu de traduções confusas da Bíblia e textos clássicos.

👉 Resumindo no estilo Bellacosa:

Um monge leu errado, traduziu pior ainda… e deployou um monstro novo no imaginário europeu.

Ela é uma variante “corrompida” do basilisco, surgida quando:

  • Um ovo de galo (sim, galo 🐓)

  • É chocado por um sapo ou serpente

  • Em circunstâncias que ninguém sabe explicar direito (nem os monges)

📌 Se isso não parece um processo batch mal controlado, eu não sei o que é.


🧬 Classificação no Bestiário Fantástico

Em RPGs e literatura fantástica, a Cocatrice costuma ser classificada como:

  • 🧪 Monstro híbrido

  • 🐉 Reptiliano / Avestruz mitológico

  • ☠️ Criatura petrificante

  • ⚠️ Aberração de baixo a médio nível

Ela NÃO é dragão.
Ela NÃO é demônio.
Ela é aquele frankenstein zoológico que passou na homologação porque ninguém entendeu a especificação.


👁 Aparência — Quando um Galo e uma Serpente Fazem Coisas Proibidas

A aparência clássica da Cocatrice é um terror estético:

  • Corpo de galinha ou galo

  • Cauda longa de serpente

  • Asas atrofiadas ou membranosas

  • Bico afiado

  • Olhar fixo, perturbador

  • Crista exagerada (quase um erro gráfico)

🎨 Em termos de design:

Parece um NPC gerado por tabela aleatória, mas que matou um grupo inteiro.


🎲 Atributos Típicos (RPG Clássico)

Em sistemas clássicos (AD&D, OSR, D&D raiz):

  • Classe de Armadura: Média

  • Dados de Vida: 4–7 HD

  • Movimento: Médio

  • Ataque:

    • Mordida

    • Bicar

  • Habilidade Especial:
    ⚠️ Petrificação ao toque ou olhar

  • Resistências:

    • Alta contra venenos

    • Média contra magia

📌 Importante:

Diferente do basilisco (olhar mortal), a Cocatrice petrifica pelo toque.

Ou seja:

  • Encostou?

  • Falhou no save?

  • Virou estátua decorativa da dungeon.


🧠 Comportamento e Ecologia

  • Territorial

  • Extremamente agressiva

  • Não é inteligente, mas é instintivamente cruel

  • Costuma viver:

    • Ruínas

    • Cavernas rasas

    • Pântanos

    • Torres abandonadas (clássico)

Ela não guarda tesouro.
Ela vira o tesouro — feito de aventureiros petrificados.


🧙‍♂️ Dicas para Mestres (GM Tips)

🧠 Use Cocatrices para:

  • Punir excesso de confiança

  • Forçar estratégia, não força bruta

  • Criar tensão sem precisar de chefão

🎭 Dica Bellacosa:

Coloque estátuas estranhas antes do combate.
Jogador esperto percebe.
Jogador afoito vira decoração.


🤫 Fofoquices Medievais (Sim, Isso Existia)

  • Acreditava-se que a sombra da Cocatrice podia matar

  • Alguns textos diziam que seu canto quebrava pedras

  • Outros afirmavam que ela morria ao ouvir um galo cantar
    (ironia cósmica aprovada)

📌 Medievalmente falando:

Era o monstro mais cancelado da época.


🥚 Curiosidades Bizarras

  • Um ovo de Cocatrice nunca é chocado por galinha (óbvio)

  • Ela seria mortal até para leões

  • Seu sangue era considerado venenoso

  • Alguns alquimistas achavam que seu pó curava doenças
    (spoiler: não curava)


🕹 Easter Eggs na Cultura Pop

  • Final Fantasy – Cocatrice petrifica personagens

  • The Witcher – versões regionais da criatura

  • D&D – presença constante desde as primeiras edições

  • Magic: The Gathering – cartas inspiradas em petrificação

🎮 Easter Egg clássico:

Sempre que um jogo usa “petrificação por toque”, a Cocatrice está ali… invisível no código.


🧠 Interpretação Simbólica (Modo Bellacosa ON)

A Cocatrice representa:

  • O medo do híbrido

  • A punição do orgulho

  • O perigo do que nasce errado

  • A consequência de mexer no que não entende

Ou seja:

É o monstro perfeito para ensinar que nem todo experimento deve ir para produção.


📌 Conclusão — A Cocatrice Nunca Foi Só um Monstro

A Cocatrice é:

  • Um erro de tradução que virou lenda

  • Um bug que virou feature

  • Um NPC que sobreviveu séculos

Ela prova que, assim como no mainframe,
o legado nunca morre — apenas petrifica quem o subestima.



sexta-feira, 6 de fevereiro de 2026

🧱✨ A ORIGEM DOS GOLEMS


 


🧱✨ A ORIGEM DOS GOLEMS  

QUANDO O BARRO GANHA PROCESSO

Sempre que leio ou assisto algo sobre golens, eu não consigo evitar: na minha cabeça, eles não são monstros… são programas. Programas antigos, escritos em uma linguagem sagrada, sem interface gráfica, sem documentação e com pouquíssimo tratamento de erro.

O golem nasce da ideia mais antiga da humanidade: criar vida com as próprias mãos. Moldar o barro, a pedra ou o metal e, por algum milagre — ou arrogância — fazer aquilo se mover. Não por vontade própria, mas por ordem.


📜 A origem histórica — Praga, barro e letras sagradas

A lenda mais famosa vem da Tradição Judaica, especialmente do século XVI, em Praga, associada ao rabino Judá Loew ben Bezalel, o Maharal de Praga.

O golem era feito de argila retirada do rio Moldava, moldado à imagem de um homem. Para ganhar “vida”, recebia:

  • Palavras sagradas

  • Combinações místicas de letras hebraicas

  • Ou o Nome de Deus, escrito e inserido na boca ou na testa

Na testa, a palavra “אמת” (Emet – verdade).
Para desligar o golem, removia-se a primeira letra, restando “מת” (Met – morto).

Simples, elegante e extremamente perigoso. Um IF mal fechado e o sistema sai do controle.


🧠 O golem não tem alma — e isso é crucial

Diferente de humanos, anjos ou demônios, o golem:

  • Não pensa

  • Não sente

  • Não questiona

  • Não interpreta contexto

Ele executa ordens literalmente. É o clássico sistema que faz exatamente o que foi pedido — e não o que você quis dizer.

Esse detalhe é o coração da lenda. Muitos rabinos alertavam: criar um golem era brincar de Deus. E como todo sistema poderoso, sem governança, dá problema.


⚙️ Da mística ao imaginário moderno

Com o tempo, os golens migraram da religião para a fantasia:

  • Golem de pedra — robusto, lento, quase indestrutível

  • Golem de ferro — armas ambulantes

  • Golem de gelo, madeira, ossos, magia

  • Construtos mágicos em RPGs e jogos

Em Dungeons & Dragons, Warcraft, The Witcher, Fullmetal Alchemist e até em Minecraft, o golem aparece como:

força absurda, inteligência mínima e obediência cega

Nada mais fiel à origem..


💪 Forças & Habilidades

O golem é praticamente um tanque vivo:

  • Força descomunal – capaz de quebrar muralhas, portas, rochas e exércitos.

  • Resistência extrema – não sente dor, cansaço ou medo.

  • Imunidade emocional – intimidação, charme, ilusão? Ignorado.

  • Obediência absoluta – segue ordens até o fim, mesmo que isso o destrua.

  • Longevidade absurda – pode existir por séculos se não for desativado.

Em RPGs, costuma ter:

  • Altíssima defesa

  • Vida massiva

  • Ataques simples, porém devastadores


⚠️ Fraquezas Clássicas

Aqui está o pulo do gato — e o erro de muitos criadores:

  • Dependência do comando – sem ordem clara, entra em loop.

  • Literalidade extrema – interpreta tudo ao pé da letra.

  • Palavra de ativação/desativação – remover, apagar ou alterar o símbolo certo pode “matar” o golem.

  • Magia específica – runas, palavras sagradas, água consagrada, selos.

  • Lentidão – poderoso, mas raramente ágil.

Todo golem carrega uma falha de projeto embutida.


⚔️ Armas & Combate

O golem geralmente é a própria arma:

  • Punhos como marretas

  • Corpo usado como aríete

  • Pedra contra carne

  • Metal contra osso

Alguns carregam:

  • Clavas gigantes

  • Portões arrancados

  • Armas improvisadas do cenário

Combater um golem não é duelo, é gerenciamento de risco.


👁️ Detalhes Visuais

Visualmente, golems variam conforme o material:

  • Barro – rachaduras, marcas de dedos, aspecto bruto

  • Pedra – runas entalhadas, musgo, peso visual

  • Metal – juntas rígidas, vapor, rangidos

  • Magia pura – símbolos flutuantes, brilho interno

Olhos quase sempre:

  • Vazios

  • Luminosos

  • Ou completamente inexpressivos


🧠 Comportamento & “Cultura”

Golens não têm cultura própria. Eles:

  • Não criam

  • Não ensinam

  • Não evoluem

Mas criam mitos ao redor deles. Aldeias passam gerações temendo ou venerando um golem guardião. Histórias nascem não do que o golem faz… mas do que ele pode fazer.


🎲 Dicas para RPG & World Building

Use golens como:

  • Guardiões de locais sagrados

  • Relíquias esquecidas ainda ativas

  • Armas de guerra antigas

  • Provas morais: destruir ou reprogramar?

Nunca os trate como monstros comuns.
O drama do golem não é a luta, é a consequência.


🧱 Curiosidades e easter eggs

  • A palavra golem aparece na Bíblia (Salmos), significando algo “informe” ou “inacabado”.

  • Frankenstein é, conceitualmente, um golem moderno — criado pelo homem, sem alma, rejeitado.

  • Muitos veem os golens como metáfora do trabalho mecânico sem consciência.

  • Em ficção científica, robôs e IAs seguem a mesma linhagem simbólica

  • Em muitos mundos, golens são proibidos por leis antigas.

  • “Criar um golem” costuma marcar o início da queda do criador.

  • Tecnologia sem ética é sempre um golem esperando ordem errada.


🧠 Conclusão Bellacosa

O golem é o lembrete mais antigo de que poder sem consciência é só execução.
Barro, pedra ou código — não importa.

Se você cria algo que obedece sem questionar,
certifique-se de que o comando esteja correto.

Porque o golem não erra.

Quem erra… é quem escreveu a ordem.

O golem não é vilão. Ele é reflexo.
Reflexo da nossa vontade de criar algo que trabalhe, proteja e obedeça… sem reclamar.

Mas toda lenda do golem termina do mesmo jeito:
o criador perde o controle.

E talvez seja esse o aviso mais antigo da humanidade, ecoando até hoje em barro, pedra… e código.

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