Bellacosa Mainframe e os grafos do conhecimento

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🌳 ALAN TURING E O IMS DOS AGENTES — QUANDO O MUNDO VIROU UMA ÁRVORE

IMS, agentes de IA, bancos hierárquicos, segmentos, root, parent, child, twins, PCB, PSB, DBD, DL/I, SSA, GU, GN, GNP, ISRT, REPL, DLET, COBOL, contexto, navegação, memória, estado, relacionamentos — e o dia em que Alan Turing descobriu que encontrar um filho pode ser fácil, desde que você saiba quem é o pai.

---

🎬 PRÓLOGO — ONDE ESTÁ O PEDIDO 8472?

O pequeno agente já estava ficando convencido.

Depois de sobreviver a RACF, SDSF, WLM, JES2, CICS, Db2 e MQ, começava a acreditar que finalmente compreendia sistemas corporativos.

Entrou no CPD com aquela confiança típica de quem acabou de descobrir SQL.

Alan Turing estava tomando café.

— Professor, pode mandar qualquer banco de dados.

Turing levantou uma sobrancelha.

— Qualquer um?

— Qualquer um.

— Encontre o item 0003 do pedido 8472 do cliente 12345.

O agente sorriu.

— Fácil.

Digitou:

SELECT *
FROM ORDER_ITEM
WHERE CUSTOMER_ID = 12345
  AND ORDER_ID    = 8472
  AND ITEM_ID     = 3;

Silêncio.

Nada aconteceu.

— Professor?

— Não estamos no Db2.

— Então qual é a tabela?

— Não existe tabela.

O robô piscou.

— Como assim não existe tabela?

Turing desenhou no quadro:

CUSTOMER
│
├── ORDER 8471
│   ├── ITEM 001
│   └── ITEM 002
│
├── ORDER 8472
│   ├── ITEM 001
│   ├── ITEM 002
│   └── ITEM 003
│
└── ORDER 8473
    └── ITEM 001

O agente ficou alguns segundos olhando.

— Isso é uma árvore.

— Exatamente.

— Então eu preciso procurar o item?

— Sim.

— Pelo número?

— Também.

— Mas preciso chegar primeiro ao pedido?

— Sim.

— E para chegar ao pedido...

Turing aponta para o topo.

CUSTOMER 12345

O robô olha para ele.

Depois para a árvore.

Depois novamente para ele.

— Preciso saber quem é o pai.

Turing sorri.

— Bem-vindo ao IMS.

---

🌳 CAPÍTULO 1 — NEM TODO BANCO DE DADOS É UMA TABELA

Para quem começou estudando bancos relacionais, banco de dados parece quase sinônimo de:

TABLE
ROW
COLUMN

Você aprende:

SELECT
INSERT
UPDATE
DELETE
JOIN

e naturalmente começa a imaginar o mundo inteiro dessa maneira.

Cliente:

CUSTOMER

Pedido:

ORDER

Item:

ORDER_ITEM

Em um modelo relacional poderíamos representar:

CUSTOMER
--------
CUSTOMER_ID
NAME

ORDER
-----
ORDER_ID
CUSTOMER_ID
DATE

ORDER_ITEM
----------
ORDER_ID
ITEM_ID
PRODUCT_ID
QUANTITY

Depois relacionamos tudo por chaves.

Mas bancos hierárquicos partem de outra ideia.

Em vez de imaginar conjuntos de tabelas relacionadas, imagine:

UMA ÁRVORE.

CUSTOMER
│
├── ORDER
│   │
│   ├── ITEM
│   ├── ITEM
│   └── ITEM
│
└── ORDER
    │
    ├── ITEM
    └── ITEM

A posição de uma informação na hierarquia importa.

Não estamos apenas perguntando:

Qual registro possui ITEM-ID 003?

Podemos estar perguntando:

Qual ITEM 003 pertencente ao ORDER 8472 pertencente ao CUSTOMER 12345?

Isso muda profundamente a maneira de navegar pelos dados.

---

🦖 CAPÍTULO 2 — MAS O QUE DIABOS É IMS?

IMS significa:

Information Management System.

É uma família histórica e importantíssima de tecnologias IBM para mainframe.

Dentro do universo IMS, dois grandes mundos aparecem:

IMS DB

e:

IMS TM

De forma introdutória:

IMS DB

Gerenciamento de bancos de dados, tradicionalmente associado ao modelo hierárquico.

IMS TM

Transaction Manager, responsável pelo processamento transacional de aplicações e mensagens.

Ou seja, IMS não é simplesmente:

“um banco de dados velho”.

Ele faz parte de uma infraestrutura transacional de enorme importância no universo corporativo.

Bancos, seguradoras, telecomunicações, governo, companhias aéreas e grandes organizações construíram sistemas críticos sobre tecnologias desse ecossistema.

Para nosso programador COBOL iniciante, porém, vamos começar pelo monstro mais visível:

A HIERARQUIA.

---

🌲 CAPÍTULO 3 — ROOT, PARENT E CHILD

Toda árvore precisa começar em algum lugar.

No topo encontramos o:

ROOT SEGMENT.

Imagine:

CUSTOMER

como root.

Abaixo dele:

ORDER.

CUSTOMER é:

PARENT

de ORDER.

ORDER é:

CHILD

de CUSTOMER.

Agora colocamos:

ITEM

abaixo de ORDER.

Temos:

CUSTOMER
   │
   └── ORDER
          │
          └── ITEM

Nesse relacionamento:

ORDER

é pai de:

ITEM.

E ao mesmo tempo filho de:

CUSTOMER.

Exatamente como uma árvore genealógica.

Alan Turing escreve:

LUIGI
│
└── MARIO
    │
    └── PEACH

O programador protesta:

— Professor, isso está genealogicamente errado.

Turing apaga.

— Estava verificando se você ainda estava prestando atenção.

🥚 Easter egg detectado.

---

👯 CAPÍTULO 4 — E OS TWINS?

Imagine:

CUSTOMER 12345
│
├── ORDER 8471
├── ORDER 8472
└── ORDER 8473

Os três ORDERs possuem o mesmo pai.

Em terminologia IMS, ocorrências do mesmo tipo de segmento sob o mesmo parent podem ser chamadas de:

TWINS.

Não significa que os dados sejam idênticos.

Significa que ocupam posições equivalentes dentro daquela relação hierárquica.

O mesmo acontece:

ORDER 8472
│
├── ITEM 001
├── ITEM 002
└── ITEM 003

Esses ITEMs são ocorrências irmãs daquele tipo sob o mesmo ORDER.

Isso será importante quando começarmos a navegar.

---

🧭 CAPÍTULO 5 — NO SQL VOCÊ DESCREVE O QUE QUER

No Db2 podemos escrever:

SELECT NAME
FROM CUSTOMER
WHERE CUSTOMER_ID = 12345;

Em linguagem declarativa, estamos basicamente dizendo:

Quero isto.

O banco determina um caminho de acesso adequado com base em vários fatores.

No universo clássico do IMS e DL/I, a navegação é muito mais explícita.

Nosso programa precisa compreender:

onde está
de onde veio
qual segmento procura
qual relacionamento está seguindo
qual posição de navegação possui

Por isso o programador IMS desenvolve uma espécie de mapa mental da árvore.

Ele não pensa apenas:

Quero ITEM 003.

Pensa:

CUSTOMER 12345
      ↓
ORDER 8472
      ↓
ITEM 003

O caminho faz parte do problema.

---

🗺️ CAPÍTULO 6 — O DBD É O MAPA DO REINO

Precisamos descrever o banco.

Entra o:

DBD — Database Description.

Conceitualmente, o DBD descreve características estruturais do banco IMS.

Para nosso iniciante, pense nele como parte do mapa técnico que diz:

qual banco existe
quais segmentos existem
como estão relacionados
quais campos/chaves são relevantes
como a estrutura está organizada

Uma representação didática:

DBD CUSTOMERDB

CUSTOMER
   │
   ├── ORDER
   │      │
   │      └── ITEM
   │
   └── ADDRESS

O DBD ajuda a definir a estrutura do mundo.

Mas surge outra pergunta:

O programa precisa enxergar tudo?

Nem sempre.

---

🪪 CAPÍTULO 7 — PSB: O QUE ESTA APLICAÇÃO PODE ENXERGAR?

Entra outro acrônimo clássico:

PSB — Program Specification Block.

Didaticamente, podemos pensar no PSB como a descrição da visão e dos recursos de banco/mensagem necessários para determinada aplicação.

Alan Turing desenha:

BANCO COMPLETO
────────────────

CUSTOMER
├── ORDER
│   └── ITEM
├── ADDRESS
├── CREDIT
└── HISTORY

Mas nosso programa talvez precise apenas de:

CUSTOMER
└── ORDER
    └── ITEM

O agente pergunta:

— Então o programa não precisa necessariamente receber o mapa inteiro do universo?

— Excelente.

Essa ideia nos levará diretamente aos agentes de IA.

Mas ainda falta uma peça.

---

📋 CAPÍTULO 8 — PCB: A JANELA OPERACIONAL

Dentro desse modelo aparece o:

PCB — Program Communication Block.

Para uma introdução, pense nele como uma estrutura pela qual a aplicação interage com determinados recursos IMS e recebe informações de status relacionadas às operações.

Em programas COBOL IMS tradicionais, o PCB é importantíssimo na comunicação com DL/I.

Depois de uma operação, você não deveria simplesmente pensar:

Fiz a chamada, portanto funcionou.

Você verifica o:

STATUS CODE.

Mainframeiro experiente já começou a sorrir.

Porque acabamos de reencontrar uma velha filosofia:

NÃO CONFIE. VERIFIQUE O RETORNO.

Nosso MAXCC dos Agentes está batendo na porta novamente.

---

☎️ CAPÍTULO 9 — DL/I: A CONVERSA COM O IMS

Um nome fundamental:

DL/I — Data Language/I.

Aplicações podem utilizar chamadas DL/I para acessar dados IMS.

Em vez de:

SELECT ...

vamos encontrar operações clássicas como:

GU
GN
GNP
ISRT
REPL
DLET

O iniciante olha para a lista.

— Parece ISPF depois de alguém derrubar café no teclado.

Calma.

Vamos traduzir.

---

🎯 CAPÍTULO 10 — GU: GET UNIQUE

GU significa:

Get Unique.

Queremos recuperar uma ocorrência específica.

Conceitualmente:

GU CUSTOMER 12345

Pense:

Localize este segmento específico.

Podemos imaginar nosso agente procurando:

CUSTOMER-ID = 12345.

Em COBOL, de maneira puramente didática e simplificada:

CALL 'CBLTDLI' USING
     GU-FUNCTION
     CUSTOMER-PCB
     CUSTOMER-IO-AREA
     CUSTOMER-SSA.

Não memorize essa linha como receita universal.

O objetivo aqui é perceber a estrutura mental:

FUNÇÃO
PCB
ÁREA DE DADOS
CRITÉRIO DE SELEÇÃO

Agora apareceu outro acrônimo.

Claro que apareceu.

Estamos no mainframe.

☕

---

🔍 CAPÍTULO 11 — SSA: DIGA QUAL SEGMENTO VOCÊ QUER

SSA significa:

Segment Search Argument.

É uma forma de indicar segmentos e, quando qualificada, critérios usados na busca.

Conceitualmente:

CUSTOMER
WHERE CUSTOMER-ID = 12345

Podemos imaginar:

CUSTOMER SSA

e depois:

ORDER SSA

e:

ITEM SSA.

Queremos:

CUSTOMER 12345
      ↓
ORDER 8472
      ↓
ITEM 003

Podemos fornecer um caminho hierárquico que ajude a localizar exatamente a ocorrência desejada.

A grande sacada é:

CONTEXTO E CAMINHO IMPORTAM.

---

➡️ CAPÍTULO 12 — GN: GET NEXT

Agora queremos navegar.

Usamos conceitualmente:

GN — Get Next.

Imagine:

CUSTOMER 12345
│
├── ORDER 8471
├── ORDER 8472
└── ORDER 8473

Depois de posicionados em determinado ponto, podemos solicitar a próxima ocorrência dentro da navegação aplicável.

É como caminhar pela árvore.

GET
NEXT
NEXT
NEXT

Isso parece simples.

Mas existe uma diferença filosófica gigantesca em relação a simplesmente perguntar ao banco:

SELECT *
FROM ORDER;

Estamos mantendo:

POSIÇÃO.

Nosso programa possui contexto de navegação.

Guarde essa palavra:

POSITION.

Ela será importantíssima para agentes.

---

👨‍👧 CAPÍTULO 13 — GNP: GET NEXT WITHIN PARENT

Agora a coisa fica deliciosa.

Temos:

CUSTOMER
│
├── ORDER A
│   ├── ITEM 1
│   └── ITEM 2
│
└── ORDER B
    ├── ITEM 1
    └── ITEM 2

Estamos dentro de:

ORDER A.

Queremos continuar procurando filhos daquele pai.

Entra conceitualmente:

GNP — Get Next within Parent.

Ou seja:

Continue dentro deste contexto parental.

Isso é muito importante.

Porque:

ITEM 1

sozinho não conta toda a história.

Precisamos saber:

ITEM 1
OF ORDER A.

O pai define contexto.

---

🧠 CAPÍTULO 14 — ALAN TURING ENCONTRA O PRIMEIRO PARALELO COM AGENTES

Turing escreve:

ITEM 003

Pergunta:

— O que é isto?

O agente responde:

— Item três.

— De qual pedido?

Silêncio.

Turing acrescenta:

ORDER 8472
   └── ITEM 003

— Agora?

— Item três do pedido 8472.

Turing acrescenta:

CUSTOMER 12345
   └── ORDER 8472
       └── ITEM 003

— Agora?

O agente responde:

— Item três do pedido 8472 do cliente 12345.

Turing sorri.

O MESMO NÓ GANHA SIGNIFICADO PELO CAMINHO QUE NOS LEVOU ATÉ ELE.

E aqui IMS encontra inteligência artificial.

---

🤖 CAPÍTULO 15 — AGENTES TAMBÉM PRECISAM DE CONTEXTO HIERÁRQUICO

Imagine uma conversa:

CLIENTE
└── VIAGEM
    └── HOTEL
        └── RESERVA

O usuário diz:

Cancele.

Cancele o quê?

Sem contexto:

CANCEL

é perigoso.

Com contexto:

CLIENTE
└── VIAGEM PARA EDIMBURGO
    └── HOTEL
        └── RESERVA 8821
            └── CANCELAR

Agora temos significado.

Um agente não deveria possuir apenas uma enorme sopa de tokens.

Pode ser extremamente útil modelar contexto como estruturas explícitas:

USER
│
├── PROJECT
│   ├── TASK
│   │   ├── DOCUMENT
│   │   └── DECISION
│   └── TASK
│
└── TRAVEL
    ├── FLIGHT
    └── HOTEL

Não estou dizendo que um LLM “é um IMS”.

Não é.

A analogia está na arquitetura do contexto:

informação organizada por relações pode ser mais útil do que informação simplesmente acumulada.

---

🧩 CAPÍTULO 16 — CONTEXTO NÃO É APENAS MEMÓRIA

Existe uma tentação perigosa em agentes:

Vamos colocar tudo no prompt.

Então aparece:

200 páginas
3.000 mensagens
48 documentos
17 APIs
histórico inteiro do cliente
logs
políticas
manuais

e alguém chama isso de:

CONTEXT.

Não.

Isso pode ser apenas:

UM DEPÓSITO.

O IMS nos oferece uma provocação arquitetural interessante.

Talvez devamos perguntar:

qual é o root?
qual é o parent?
qual é o child?
qual caminho importa?
qual subárvore precisamos?

Em vez de entregar o universo inteiro ao agente, entregamos a parte relevante da árvore.

---

✂️ CAPÍTULO 17 — CONTEXT PRUNING ENCONTRA A ÁRVORE

Imagine:

CUSTOMER
├── ACCOUNT
│   ├── BALANCE
│   └── TRANSACTIONS
├── INSURANCE
├── MORTGAGE
├── MARKETING
└── SUPPORT

O agente está respondendo:

Qual meu saldo?

Talvez precise:

CUSTOMER
└── ACCOUNT
    └── BALANCE

Não precisa necessariamente carregar:

MARKETING
MORTGAGE
SUPPORT HISTORY

inteiros.

Podemos podar a árvore de contexto.

FULL CONTEXT
      ↓
RELEVANT SUBTREE
      ↓
AGENT

Isso pode reduzir:

tokens
latência
custo
ruído
risco de confusão
exposição desnecessária

Olha o RACF sorrindo novamente.

Menos contexto também pode significar:

MENOR SUPERFÍCIE DE EXPOSIÇÃO.

---

🔐 CAPÍTULO 18 — PSB ENCONTRA LEAST PRIVILEGE

Lembra do PSB?

Uma aplicação recebe a visão e os recursos necessários para seu trabalho.

Agora imagine um agente.

Agente de cobrança:

CUSTOMER
├── ACCOUNT
├── DEBT
└── PAYMENT

Agente de marketing:

CUSTOMER
├── PROFILE
└── CAMPAIGN

Por que o agente de marketing deveria receber:

ACCOUNT PASSWORD
PAYMENT CREDENTIALS
INTERNAL FRAUD NOTES

se não precisa?

Nossa analogia conceitual:

PSB
↓
APPLICATION VIEW

torna-se:

AGENT CONTEXT POLICY
↓
MINIMUM NECESSARY VIEW.

RACF responde do corredor:

— FINALMENTE VOCÊS ESTÃO APRENDENDO!

😂

---

🧬 CAPÍTULO 19 — O PROBLEMA DO FILHO SEM PAI

Imagine um RAG retornando:

STATUS = ACTIVE

Excelente.

Ativo o quê?

Cliente?

Contrato?

Cartão?

Conta?

Apólice?

Promoção?

Um fragmento semanticamente semelhante pode ser inútil sem seus ancestrais contextuais.

Em uma representação hierárquica:

CUSTOMER 12345
└── CREDIT_CARD 8821
    └── STATUS ACTIVE

temos muito mais significado.

Portanto uma estratégia de recuperação pode considerar não apenas:

CHUNK

mas também:

ANCESTORS
PATH
ENTITY
RELATIONSHIP
VERSION
TIMESTAMP
SOURCE.

Nosso Db2 dos Agentes volta:

De quando é?

O IMS acrescenta:

Filho de quem?

---

🧭 CAPÍTULO 20 — O CAMINHO TAMBÉM É PROVENIÊNCIA

Imagine que o agente responde:

O limite é R$ 5.000.

Perguntamos:

— De onde veio?

Resposta ruim:

DOCUMENT 883.

Resposta melhor:

CUSTOMER 12345
└── ACCOUNT 9981
    └── CREDIT_POLICY
        └── LIMIT
            VALUE = 5000

Agora podemos registrar:

SOURCE
PATH
VERSION
READ_AT
VALID_AT.

Isso mistura duas lições anteriores.

Do Db2:

WHEN?

Do IMS:

WHERE IN THE HIERARCHY?

Nosso agente começa a enxergar realidade não apenas como valores, mas como:

VALORES DENTRO DE CAMINHOS, VERSÕES E TEMPO.

---

✍️ CAPÍTULO 21 — ISRT: INSERINDO UM NOVO FILHO

Agora precisamos modificar a árvore.

Uma função clássica:

ISRT — Insert.

Imagine:

CUSTOMER 12345
└── ORDER 8472

Queremos adicionar:

ITEM 004.

Conceitualmente:

CUSTOMER 12345
└── ORDER 8472
    ├── ITEM 001
    ├── ITEM 002
    ├── ITEM 003
    └── ITEM 004  ← NOVO

Mas observe algo importante.

Para inserir corretamente o filho, precisamos identificar o contexto parental apropriado.

Não queremos colocar ITEM 004 acidentalmente sob:

ORDER 8473.

Mais uma vez:

CONTEXTO É PARTE DA OPERAÇÃO.

---

🔄 CAPÍTULO 22 — REPL: ALTERANDO SEM PERDER O CONTEXTO

Outra operação clássica:

REPL — Replace.

Recuperamos determinado segmento e queremos alterar seu conteúdo dentro das regras aplicáveis.

Conceitualmente:

GET SEGMENT
↓
MODIFY IO AREA
↓
REPLACE

Para agentes isso lembra nossa discussão de optimistic concurrency e revalidation.

Antes de alterar qualquer coisa crítica, pergunte:

é o mesmo objeto?
é o mesmo pai?
é a mesma versão?
o contexto continua válido?
tenho autoridade?

IMS sozinho não transforma automaticamente qualquer workflow de IA em optimistic concurrency.

Mas a disciplina de identificar precisamente o objeto e seu contexto continua valiosíssima.

---

🗑️ CAPÍTULO 23 — DLET: APAGAR EM UMA ÁRVORE É COISA SÉRIA

Agora:

DLET — Delete.

O agente diz:

— Fácil. Apaga o segmento.

Turing pergunta:

— Qual?

— Este.

— Qual pai?

— Ah.

— Quais dependências?

— Hmmm.

— Quais regras?

— Professor...

— Quais consequências?

O agente desliga o botão DELETE.

Excelente decisão.

Em estruturas hierárquicas, relacionamentos são parte fundamental do significado.

Em agentes, vale a mesma cautela:

DELETE CHILD

pode afetar:

PARENT STATE
SIBLINGS
BUSINESS RULES
AUDIT
DOWNSTREAM EVENTS.

Não deixe um LLM transformar:

Acho que este nó não é mais necessário.

em:

DLET.

sem controles adequados.

PF3, RACF e human-in-the-loop entram na sala simultaneamente.

---

🚦 CAPÍTULO 24 — STATUS CODE: A RESPOSTA DO IMS IMPORTA

Nosso programa faz uma chamada.

Depois precisa olhar o resultado.

Isso é básico e fundamental.

Não basta:

CALL DL/I

e continuar como se o universo tivesse obedecido.

Precisamos verificar o retorno no contexto da interface e operação usada.

Conceitualmente:

IF STATUS-OK
    CONTINUE
ELSE
    PERFORM HANDLE-IMS-ERROR
END-IF.

Para agentes:

TOOL CALLED

não significa:

TOOL SUCCEEDED.

E:

HTTP 200

nem sempre significa:

BUSINESS SUCCESS.

Lembra do MAXCC?

Ele ainda está conosco.

---

🧠 CAPÍTULO 25 — POSITION É ESTADO

Imagine que estamos navegando:

CUSTOMER 12345
│
└── ORDER 8472
    │
    ├── ITEM 001
    ├── ITEM 002  ← VOCÊ ESTÁ AQUI
    └── ITEM 003

Essa posição possui significado.

O próximo movimento depende de onde estamos.

Agentes também possuem estado operacional.

RUN-ID
AGENT-ID
CURRENT-TASK
CURRENT-ENTITY
CURRENT-PARENT
CURRENT-NODE
LAST-ACTION
NEXT-ACTION.

Se o agente reiniciar e perder isso, talvez não saiba onde estava.

Então entra nossa velha amiga:

CHECKPOINT.

---

💾 CAPÍTULO 26 — CHECKPOINT: MARQUE ONDE VOCÊ ESTAVA

Do JES2 dos Agentes aprendemos que trabalhos longos precisam conseguir sobreviver a falhas.

Agora imagine uma árvore com milhões de ocorrências.

O agente percorreu:

CUSTOMER 000001
...
CUSTOMER 472881

Cai.

Reinicia.

Sem checkpoint:

CUSTOMER 000001.

O operador começa a chorar.

😂

Com estado persistido:

RUN-ID......... R8821
LAST-ENTITY.... CUSTOMER
LAST-KEY....... 472881
STATUS......... CHECKPOINTED

podemos projetar uma retomada controlada.

Mas cuidado:

a realidade pode ter mudado durante a interrupção.

Então:

RESTART

precisa conversar com:

REVALIDATION.

Db2 dos Agentes reaparece.

---

🔀 CAPÍTULO 27 — UMA ÁRVORE NÃO RESOLVE TODO RELACIONAMENTO

Aqui precisamos evitar uma simplificação.

O mundo real não é sempre uma árvore perfeita.

Uma pessoa pode ter:

múltiplas contas
múltiplos contratos
múltiplos endereços
relações compartilhadas

Um produto pode pertencer a inúmeras estruturas lógicas.

Modelos hierárquicos precisam de mecanismos e estratégias para representar relacionamentos mais complexos.

O ponto não é dizer:

Árvore é superior a tabela.

Nem:

Tabela é superior a árvore.

São modelos diferentes, com características diferentes.

A pergunta correta é:

Qual modelo representa e atende melhor este problema e esta arquitetura?

---

🕸️ CAPÍTULO 28 — ÁRVORE NÃO É GRAFO

Outra distinção importante.

Árvore:

A
├── B
│   ├── D
│   └── E
└── C

Existe uma hierarquia clara.

Grafos permitem relacionamentos muito mais gerais:

A ── B
│ \  │
C ── D
 \  /
  E

Agentes modernos podem trabalhar com:

relational databases
hierarchical stores
documents
vectors
knowledge graphs
queues
files
APIs

Não transforme toda arquitetura de IA numa árvore só porque acabamos de conhecer IMS.

Turing provavelmente jogaria o apagador em você.

---

📚 CAPÍTULO 29 — MEMÓRIA DO AGENTE NÃO PRECISA SER UMA SACOLA

Imagine uma memória:

MEMORY
├── PERSON
│   ├── PREFERENCES
│   ├── CONTACTS
│   └── HISTORY
├── PROJECTS
│   ├── PROJECT-A
│   │   ├── DECISIONS
│   │   ├── DOCUMENTS
│   │   └── TASKS
│   └── PROJECT-B
└── CONVERSATIONS

Agora compare com:

VECTOR DATABASE
████████████████████████████

cheio de chunks sem estrutura explícita suficiente.

Vector search é extremamente útil.

Mas similaridade semântica responde principalmente:

O que parece relacionado?

Ela não responde automaticamente:

Qual é o pai lógico deste fato?

A qual projeto pertence?

Qual entidade governa este dado?

Qual contexto deveria acompanhá-lo?

Por isso arquiteturas sofisticadas podem combinar:

SEMANTIC SEARCH
+
STRUCTURED METADATA
+
HIERARCHY
+
RELATIONSHIPS
+
TEMPORALITY
+
AUTHORIZATION.

Agora estamos construindo memória de verdade.

---

🔎 CAPÍTULO 30 — RAG HIERÁRQUICO

Imagine um manual:

IBM MANUAL
└── CHAPTER 8
    └── SECURITY
        └── RACF AUTHORIZATION
            └── PARAGRAPH 14

O vector search encontra apenas:

PARAGRAPH 14.

Talvez falte contexto.

Uma estratégia possível:

retrieve leaf
↓
identify parent
↓
retrieve necessary ancestors
↓
construct contextual package
↓
send to agent.

Assim o agente recebe:

DOCUMENT
CHAPTER
SECTION
PARAGRAPH
VERSION
DATE
SOURCE.

Não apenas:

chunk_008821.txt.

Isso é uma lição extremamente IMS:

O CAMINHO ATÉ O DADO PODE FAZER PARTE DO SIGNIFICADO DO DADO.

---

📨 CAPÍTULO 31 — IMS ENCONTRA MQ

Nosso agente recebe pelo MQ:

CUSTOMER_UPDATED

Mensagem:

CUSTOMER-ID = 12345
ORDER-ID    = 8472
ITEM-ID     = 0003

MQ responde:

Algo aconteceu.

IMS responde:

Eis onde isso vive na hierarquia.

Db2 poderia responder:

Eis o estado relacional atual.

RACF:

Você pode acessar?

WLM:

Você tem recursos?

CICS:

O usuário ainda está esperando!

SDSF:

Eu estou vendo tudo.

JES2:

Se não for urgente, entra na fila.

PF3:

Quer parar essa loucura?

😂

Finalmente nossa arquitetura começa a parecer um verdadeiro CPD dos agentes.

---

🏛️ CAPÍTULO 32 — IMS TM E OS AGENTES TRANSACIONAIS

Até aqui focamos fortemente na visão de dados hierárquicos.

Mas IMS também possui seu universo transacional.

IMS TM permite construir aplicações orientadas a processamento de transações e mensagens em ambiente mainframe.

Conceitualmente:

INPUT MESSAGE
      ↓
IMS TM
      ↓
APPLICATION
      ↓
DATABASE / SERVICES
      ↓
OUTPUT MESSAGE

Isso deveria soar familiar depois do MQ dos Agentes.

Nosso agente pode participar de arquiteturas nas quais:

mensagem chega
↓
transação é executada
↓
dados são consultados/alterados
↓
resposta é produzida.

Mainframe já fazia processamento transacional em escala muito antes de alguém inventar a palavra:

AI AGENT.

---

🤖 CAPÍTULO 33 — O IMS DOS AGENTES

Vamos finalmente definir nossa metáfora.

O:

IMS DOS AGENTES

não significa transformar IMS literalmente em memória universal de LLM.

Significa aprender algumas disciplinas arquiteturais:

1. Dados possuem estrutura.

2. Relacionamentos possuem significado.

3. Filhos existem dentro de contexto parental.

4. O caminho até um dado pode importar.

5. Nem todo consumidor precisa enxergar a árvore inteira.

6. Navegação possui estado.

7. Operações precisam verificar retorno.

8. Contexto pode ser selecionado e podado.

9. Reinício exige checkpoint e revalidação.

10. Estrutura sem semântica continua insuficiente.

Essa última vem diretamente do nosso Copybook dos Agentes.

---

🏗️ CAPÍTULO 34 — ARQUITETURA CONCEITUAL

Turing desenha:

                    HUMAN
                      │
                      ▼
                    CICS
                      │
                      ▼
                   AGENT-A
                      │
          ┌───────────┼───────────┐
          │           │           │
          ▼           ▼           ▼
         MQ          Db2         IMS
          │           │           │
       EVENTS      CURRENT     HIERARCHY
                    STATE       / PATH
          │           │           │
          └───────────┼───────────┘
                      ▼
                  DECISION
                      │
                      ▼
                    ACTION

Em volta:

RACF
AUTHORITY

WLM
RESOURCES

SDSF
OBSERVABILITY

JES2
ASYNC WORK

PF3
HUMAN CONTROL

Nosso agente agora sabe perguntar:

WHO?
WHEN?
WHERE?
WHICH PARENT?
WHICH VERSION?
WHICH MESSAGE?
WHICH AUTHORITY?

Isso está ficando muito mais interessante que:

PROMPT → LLM → RESPOSTA.

---

🥚 EASTER EGG — O FILHO PERDIDO

02:43.

Produção liga.

— Temos um ITEM órfão.

O programador pergunta:

— Como assim órfão?

— Ele existe.

— Então qual é o problema?

— Ninguém sabe de qual ORDER ele é.

Silêncio.

Alan Turing entra no CPD.

ITEM-ID = 0007
VALUE   = 850.00

Turing pergunta:

— Qual parent?

— Não sabemos.

— CUSTOMER?

— Também não sabemos.

O agente sugere:

— Posso usar inteligência artificial para inferir.

Turing vira lentamente.

— Você quer movimentar R$ 850 baseado em genealogia probabilística?

O agente recua.

— Talvez não.

Do fundo da sala o DBA grita:

— FINALMENTE UMA IA APRENDEU ALGUMA COISA!

😂

Turing escreve no quadro:

CHILD WITHOUT CONTEXT
=
DATA WITHOUT MEANING

E embaixo:

DO NOT GUESS THE PARENT IN PRODUCTION.

---

🧰 CAPÍTULO 35 — CHECKLIST DO IMS DOS AGENTES

Antes de deixar um agente navegar estruturas hierárquicas, pergunte:

Estrutura

Qual é o root?

Quais são os parents?

Quais são os children?

Existem twins?

Navegação

Qual é o caminho?

Qual é a posição atual?

A operação depende do parent atual?

Identidade

Qual entidade estou acessando?

Qual é a chave?

O mesmo identificador pode existir em contextos diferentes?

Temporalidade

Quando esse dado foi lido?

Ainda é válido?

Precisa revalidar?

Segurança

O agente precisa enxergar esta subárvore?

Tem autorização?

Estamos aplicando least privilege?

Recuperação

Existe checkpoint?

Sabemos retomar?

A retomada é idempotente?

Observabilidade

RUN-ID?

CURRENT PATH?

LAST SEGMENT?

STATUS?

ELAPSED TIME?

Agora conseguimos operar o agente.

---

🧠 CAPÍTULO 36 — O PAINEL SDSF DO IMS DOS AGENTES

Imagine:

RUN-ID....... AGT004821
AGENT........ CUSTOMER-ANALYZER

DATABASE..... CUSTOMERDB

ROOT......... CUSTOMER
ROOT-KEY..... 12345

CURRENT-PATH:
CUSTOMER/12345
  /ORDER/8472
  /ITEM/0003

OPERATION.... READ
STATUS....... OK

READ-AT...... 10:00:01
VERSION...... 882

ELAPSED...... 42ms

Agora o operador não vê apenas:

PROCESSING...

Ele sabe:

Onde o agente está na árvore?

Se travar:

CURRENT-PATH

pode ser extremamente útil para diagnóstico.

Observabilidade também precisa de contexto.

---

🧙 CAPÍTULO 37 — O PROGRAMADOR COBOL DESCOBRE QUE JÁ SABIA METADE DISSO

Nosso iniciante olha para tudo:

DBD
PSB
PCB
DL/I
SSA
GU
GN
GNP
ISRT
REPL
DLET

e pensa:

Nunca vou aprender isso.

Calma.

Você já conhece ideias fundamentais.

Você sabe:

estrutura de dados

por causa de copybooks.

Você sabe:

status

por causa de RETURN-CODEs e interfaces.

Você sabe:

hierarquia

porque programas COBOL vivem cheios de níveis:

01 CUSTOMER.
   05 CUSTOMER-ID.
   05 CUSTOMER-NAME.
   05 ADDRESS.
      10 STREET.
      10 CITY.
      10 ZIP-CODE.

Olha só.

Até seu:

01
05
10

já treinou seu cérebro para pensar hierarquicamente.

Não é a mesma coisa que uma estrutura IMS.

Mas cognitivamente você não está começando do zero.

---

📜 CAPÍTULO 38 — COPYBOOK E IMS SE ENCONTRAM

Imagine o segmento CUSTOMER chegando a uma área COBOL:

01 CUSTOMER-SEGMENT.
   05 CUST-ID          PIC 9(09).
   05 CUST-NAME        PIC X(40).
   05 CUST-STATUS      PIC X.

ORDER:

01 ORDER-SEGMENT.
   05 ORDER-ID         PIC 9(09).
   05 ORDER-DATE       PIC 9(08).
   05 ORDER-STATUS     PIC X.

ITEM:

01 ITEM-SEGMENT.
   05 ITEM-ID          PIC 9(05).
   05 PRODUCT-ID       PIC X(12).
   05 QUANTITY         PIC 9(05).
   05 VALUE            PIC S9(09)V99 COMP-3.

Essas estruturas dizem:

Como os bytes são representados.

IMS acrescenta:

Como esses segmentos se relacionam na estrutura do banco.

E as regras de negócio dizem:

O que tudo isso significa.

Finalmente temos três camadas:

REPRESENTATION
      ↓
STRUCTURE
      ↓
SEMANTICS.

Nosso artigo sobre copybooks estava preparando essa emboscada desde o começo.

---

⚠️ CAPÍTULO 39 — NÃO CONFUNDA HIERARQUIA COM VERDADE

Um erro importante seria imaginar:

Se está organizado hierarquicamente, então está correto.

Não.

Uma árvore pode conter:

dados antigos
dados incorretos
relações inválidas
contexto incompleto

Logo continuam valendo nossas regras anteriores:

PROVENANCE
TIMESTAMP
VERSION
VALIDATION
AUTHORIZATION
REVALIDATION.

IMS resolve problemas de organização e acesso dentro de seu modelo.

Não elimina a necessidade de governança.

Nenhuma tecnologia elimina.

---

🧠 CAPÍTULO 40 — O GRANDE ENSINAMENTO PARA IA

Hoje falamos muito sobre:

context windows
RAG
vector databases
knowledge graphs
agent memory
long-term memory
tool context
conversation state

IMS nos oferece uma ideia antiga que continua extremamente moderna:

RELACIONAMENTO É INFORMAÇÃO.

Não basta armazenar:

ITEM 003.

Talvez precisemos armazenar:

CUSTOMER 12345
→ ORDER 8472
→ ITEM 003.

Não basta recuperar:

“limite = 5000”.

Precisamos talvez recuperar:

CUSTOMER
→ ACCOUNT
→ CREDIT POLICY
→ LIMIT
→ 5000

junto com:

VERSION
SOURCE
VALIDITY
AUTHORITY.

Essa é uma diferença brutal entre:

ENCONTRAR TEXTO

e:

COMPREENDER CONTEXTO.

---

🏰 CAPÍTULO 41 — NOSSO MAINFRAME DOS AGENTES ESTÁ QUASE VIRANDO UMA CIDADE

Alan Turing volta ao quadro.

Escreve:

RACF
Quem pode?

Depois:

PF3
Posso parar?

SDSF
O que está acontecendo?

MAXCC
Funcionou?

WLM
Quem recebe recursos?

JES2
Quem começa e quando?

CICS
Quanto tempo o humano pode esperar?

Db2
Qual realidade o agente está vendo?

MQ
Como a notícia viaja?

Finalmente:

IMS
ONDE ESTA INFORMAÇÃO VIVE
E POR QUAL CAMINHO CHEGAMOS ATÉ ELA?

O agente olha para o quadro.

— Professor...

— Sim?

— Isso tudo já existia antes de IA?

— Praticamente todos esses problemas fundamentais, sim.

— Então estamos reinventando o mainframe?

Turing bebe o café.

— Não.

Pausa.

— Estamos descobrindo novamente por que ele ficou complicado.

😂

---

☕ EPÍLOGO — ENCONTRE O FILHO

Voltamos ao desafio inicial.

CUSTOMER 12345

O agente encontra o root.

Depois:

ORDER 8472.

Posiciona-se no parent correto.

Depois:

ITEM 003.

Encontrado.

Na tela:

RUN-ID......... A004821

PATH...........
CUSTOMER/12345
ORDER/8472
ITEM/003

STATUS......... FOUND

Turing pergunta:

— Qual é o item?

O agente responde:

— ITEM 003.

Turing permanece olhando.

O agente percebe a armadilha.

Corrige:

— ITEM 003, pertencente ao ORDER 8472, pertencente ao CUSTOMER 12345.

Turing sorri.

— Melhor.

— Porque o contexto faz parte da identidade?

— Exatamente.

O agente olha para a árvore.

Horas atrás acreditava que dados eram valores.

Depois descobriu que dados tinham tempo.

Com MQ descobriu que informações viajavam.

Agora IMS ensinava algo ainda mais estranho.

DADOS TAMBÉM POSSUEM VIZINHANÇA.

Um valor pode possuir:

pai
filhos
irmãos
ancestrais
caminho
posição
contexto.

E retirar o valor dessa estrutura pode retirar parte de seu significado.

O pequeno robô abre seu próprio arquivo de memória.

Antes:

MEMORY
────────────────
coffee
COBOL
customer
order
Turing
MQ
Db2
item

Ele reorganiza:

MEMORY
│
├── MAINFRAME
│   ├── COBOL
│   ├── Db2
│   ├── MQ
│   └── IMS
│
├── CUSTOMER
│   └── ORDER
│       └── ITEM
│
└── TEACHERS
    └── ALAN TURING

Turing observa.

— Melhor?

O agente responde:

— Agora eu sei não apenas o que lembro.

Pausa.

— Sei onde cada lembrança pertence.

No terminal aparece:

GU
GN
GNP

Depois:

ROOT
PARENT
CHILD
PATH
CONTEXT

E finalmente:

DATA
+
RELATIONSHIP
+
TIME
+
PROVENANCE
=
CONTEXTUAL KNOWLEDGE

Turing termina o café.

Antes de sair escreve uma última frase no quadro:

“NÃO PERGUNTE APENAS QUAL É O DADO. PERGUNTE DE ONDE ELE VEIO, QUANDO ERA VERDADEIRO E A QUAL RAMO DA REALIDADE ELE PERTENCE.”

O agente olha para o ITEM 003.

Agora entende por que demorou tanto para encontrá-lo.

Não estava procurando apenas um registro.

Estava procurando:

UM REGISTRO DENTRO DE UMA HISTÓRIA.

E talvez esse seja um dos maiores desafios das futuras inteligências artificiais.

Elas conseguirão armazenar bilhões de fatos.

Conseguirão recuperar documentos em milissegundos.

Conseguirão conversar com bancos, APIs, filas e outros agentes.

Mas inteligência operacional exigirá algo mais:

WHO?
WHAT?
WHEN?
WHERE?
WHY?
WHICH VERSION?
WHICH PARENT?
WHICH PATH?

Porque informação sem relacionamento vira ruído.

Memória sem estrutura vira depósito.

Contexto sem origem vira suposição.

E um filho sem pai...

Bem.

Esse fica para o plantão das 02:43.

IF CHILD-FOUND
   AND PARENT-KNOWN
   AND CONTEXT-VALID
       MOVE 'OK' TO AGENT-STATUS
ELSE
       MOVE 'DO-NOT-GUESS'
         TO AGENT-STATUS
END-IF.

READY

☕ Bellacosa Mainframe — porque até uma inteligência artificial precisa aprender que, antes de sair procurando os filhos, é melhor descobrir quem são os pais.

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 Alan Turing entra no CPD

O mapa dos agentes de IA explicado por um mainframer

Esta série acompanha a evolução de uma ideia: compreender os problemas modernos dos agentes de inteligência artificial usando conceitos conhecidos por quem trabalha com mainframe, IBM Z e sistemas corporativos.

A viagem começa pelas pessoas e pela experiência de uso, passa por observabilidade, priorização e execução, chega às transações, estado e mensageria e termina na organização hierárquica do contexto.

PESSOAS → UX → OBSERVABILIDADE → PRIORIDADE → EXECUÇÃO → TRANSAÇÃO → ESTADO → MENSAGERIA → CONTEXTO

01

FEV / 2023

🧠 O currículo invisível da inteligência artificial

Antes de construir agentes inteligentes precisamos preparar as pessoas que trabalharão com eles. Técnica, pensamento crítico, conhecimento de negócio, segurança, ética e responsabilidade formam o currículo que nem sempre aparece no certificado.

Ler: Alan Turing e o currículo invisível da IA →

02

MAR / 2023

🤖 A UX dos agentes

Quando uma IA deixa de apenas responder e começa a executar ações, sua interface precisa mostrar objetivos, progresso, permissões e resultados. PF3, MAXCC e RACF tornam-se excelentes analogias para controle, retorno e privilégio mínimo.

Ler: Alan Turing e a UX dos agentes →

03

ABR / 2023

🔭 O SDSF dos agentes

Autonomia sem observabilidade cria uma caixa-preta. Inspirado no SDSF do z/OS, este capítulo pergunta como acompanhar agentes, tarefas, estados, filas, falhas, logs e resultados em tempo real.

Ler: O SDSF dos agentes — o que o robô está fazendo? →

04

MAI / 2023

⚖️ O WLM dos agentes

CPU, GPU, tokens, APIs e bancos de dados são recursos finitos. O Workload Manager inspira uma discussão sobre prioridades, objetivos de serviço, importância do trabalho e distribuição dinâmica de recursos entre agentes.

Ler: Alan Turing e o WLM dos agentes →

05

JUN / 2023

🏭 O JES2 dos agentes

Quem recebe uma tarefa? Onde ela espera? Quem decide quando poderá executar? A lógica de entrada, filas, despacho, execução e saída do JES2 oferece um paralelo interessante para a orquestração do trabalho dos agentes.

Ler: O JES2 dos agentes — quem recebe e despacha o trabalho? →

06

JUL / 2023

⚡ O CICS dos agentes

Uma coisa é uma IA produzir texto. Outra é permitir que ela execute operações reais de negócio. CICS introduz a conversa sobre processamento transacional, concorrência, segurança e integridade.

Ler: Alan Turing e o CICS dos agentes →

07

AGO / 2023

🗄️ O Db2 dos agentes

Agentes precisam manter estado, checkpoints, decisões e resultados. O Db2 fornece o ponto de partida para discutir unidade de trabalho, consistência, COMMIT, ROLLBACK e recuperação.

Ler: Alan Turing e o Db2 dos agentes →

08

SET / 2023

📨 O MQ dos agentes

Sistemas de agentes não precisam conversar sincronamente o tempo inteiro. IBM MQ conduz a discussão para filas, mensagens, desacoplamento, resiliência, retries, correlação e processamento assíncrono.

Ler: O MQ dos agentes — mensagem não significa conversa síncrona →

09

OUT / 2023

🌳 O IMS dos agentes

Nem todo conhecimento precisa ser imaginado como uma tabela. IMS leva a série para estruturas hierárquicas, relações parent/child e navegação contextual — conceitos úteis para pensar organização e recuperação de contexto.

Ler: Alan Turing e o IMS dos agentes — quando o mundo virou uma árvore →

10

SET / 2026

☕ Alan Turing entra no CPD — O mapa completo

O artigo-âncora reúne toda a evolução da ideia: pessoas, UX, observabilidade, prioridade, orquestração, transações, estado, mensageria e contexto transformam artigos independentes em uma arquitetura conceitual para agentes de IA.

☕ ABRIR O MAPA COMPLETO DOS AGENTES DE IA →

🧭 A evolução da arquitetura

A série conecta conceitos históricos de IBM mainframe e IBM Z aos desafios atuais de Agentic AI e sistemas multiagentes.

SDSF ajuda a pensar em observabilidade; WLM em priorização de workloads; JES2 em filas e despacho; CICS em transações; Db2 em estado e consistência; IBM MQ em mensageria assíncrona; e IMS em informação hierárquica e contexto.

Esses sistemas não foram criados para agentes de IA. A série utiliza suas ideias como paralelos de engenharia para compreender problemas modernos de sistemas autônomos.

🖥️ Leitor da série

Selecione qualquer capítulo acima para abri-lo normalmente. O painel abaixo é apenas um recurso adicional de navegação.

 

Bellacosa Mainframe e o laboratorio basico Db2 Spufi

☕ Um Café no Bellacosa Mainframe

☕ Laboratório Básico — Explorando o Catálogo SYSIBM do Db2 for z/OS com SPUFI

1. Objetivo do laboratório

Neste laboratório vamos aprender a utilizar o SPUFI — SQL Processor Using File Input, disponível tradicionalmente através do ambiente Db2 Interactive (DB2I) no ISPF, para executar consultas SQL contra o catálogo do Db2 for z/OS.

Ao final você deverá compreender:

• o que é SPUFI;

• o que é o catálogo do Db2;

• o que significa SYSIBM;

• como descobrir tabelas existentes;

• como descobrir as colunas de uma tabela;

• como localizar índices;

• como identificar diferentes tipos de objetos;

• como filtrar resultados;

• como interpretar resultados e erros básicos;

• por que consultar o catálogo é uma habilidade importante para um programador COBOL/Db2.

Regra do laboratório: trabalharemos somente com SELECT. Não precisamos modificar nenhum objeto ou dado.

---

2. Antes de começar: o que é SYSIBM?

Quando trabalhamos com uma aplicação comum podemos ter tabelas como:

CLIENTES
CONTAS
PRODUTOS
PEDIDOS
FUNCIONARIOS

Mas o próprio Db2 precisa guardar informações sobre aquilo que administra.

Por exemplo:

Quais tabelas existem?
Quem criou determinada tabela?
Quais colunas ela possui?
Qual é o tipo de cada coluna?
Quais índices existem?
Quais schemas existem?
Quais views existem?

Essas informações são chamadas de metadados.

Uma maneira simples de pensar nisso é:

DADOS
│
├── CLIENTES
├── CONTAS
├── PEDIDOS
└── PRODUTOS

METADADOS
│
└── informações sobre os dados e objetos

O catálogo do Db2 contém esses metadados.

Muitas tabelas fundamentais do catálogo estão sob o qualifier/schema:

SYSIBM

Encontraremos nomes conhecidos como:

SYSIBM.SYSTABLES
SYSIBM.SYSCOLUMNS
SYSIBM.SYSINDEXES
SYSIBM.SYSVIEWS

Portanto:

SYSIBM.SYSTABLES
   │        │
   │        └── tabela do catálogo
   │
   └────────── schema/qualifier

Você pode imaginar SYSIBM como uma enorme biblioteca administrativa onde o Db2 mantém informações sobre seu próprio universo.

---

3. Entrando no SPUFI

O caminho depende da instalação da empresa ou laboratório.

Pode ser algo semelhante a:

TSO/E
  │
  ▼
ISPF
  │
  ▼
DB
  │
  ▼
DB2I
  │
  ▼
SPUFI

Em algumas instalações as opções possuem números; em outras existem menus customizados.

Procure pela opção:

SPUFI

ou:

SQL Processor Using File Input

---

4. Preparando o SPUFI

O SPUFI trabalha fundamentalmente com um dataset contendo o SQL de entrada e outro para receber a saída.

Conceitualmente:

MEU.SQL
   │
   │ SELECT...
   ▼
 SPUFI
   │
   ▼
  Db2
   │
   ▼
resultado
   │
   ▼
MEU.SQLOUT

Você poderá encontrar campos semelhantes a:

INPUT DATA SET NAME  ===> USERID.SQL

OUTPUT DATA SET NAME ===> USERID.SQLOUT

EDIT INPUT           ===> YES

EXECUTE              ===> YES

BROWSE OUTPUT        ===> YES

Os nomes e parâmetros exatos podem variar conforme o ambiente.

Utilize os datasets e configurações definidos pelo seu instrutor ou instalação.

---

5. Exercício 1 — Perguntando as horas ao Db2

Antes de investigar o catálogo, vamos verificar se conseguimos conversar com o Db2.

Execute:

SELECT CURRENT DATE,
       CURRENT TIME
FROM SYSIBM.SYSDUMMY1;

O que está acontecendo?

SYSIBM.SYSDUMMY1 é uma pequena tabela especial tradicionalmente utilizada quando queremos executar expressões SQL que não dependem de uma tabela de aplicação.

Estamos pedindo:

CURRENT DATE
CURRENT TIME

O fluxo é:

SPUFI
  │
  │ SQL
  ▼
Db2
  │
  │ resultado
  ▼
SPUFI OUTPUT

Se obtivermos uma data e horário, nossa comunicação está funcionando.

---

6. Exercício 2 — Quem sou eu para o Db2?

Experimente:

SELECT CURRENT USER
FROM SYSIBM.SYSDUMMY1;

O resultado mostrará a identidade de autorização associada à execução.

Isso é importante porque o Db2 possui mecanismos próprios de autorização.

Dois usuários podem executar o mesmo SQL e obter comportamentos diferentes por causa das permissões concedidas.

Guarde esta ideia:

USUÁRIO
   │
   ▼
AUTORIZAÇÃO
   │
   ▼
OBJETO Db2

---

7. Exercício 3 — Conhecendo SYSIBM.SYSTABLES

Agora chegamos a uma das tabelas de catálogo mais úteis:

SYSIBM.SYSTABLES

Ela contém informações sobre tabelas e determinados objetos relacionados registrados no catálogo.

Não comece com:

SELECT *
FROM SYSIBM.SYSTABLES;

Em um ambiente grande isso pode produzir uma quantidade enorme de informação.

Vamos ser educados com o mainframe.

Execute:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
FETCH FIRST 20 ROWS ONLY;

Observe as colunas.

CREATOR

Indica o qualifier/creator associado ao objeto.

NAME

Nome do objeto.

TYPE

Indica seu tipo conforme os códigos definidos pelo catálogo daquela versão do Db2.

Não tente decorar imediatamente todos os valores possíveis de TYPE.

O importante neste momento é entender:

SYSTABLES

CREATOR   NAME             TYPE
--------  ---------------  ----
SYSIBM    SYSTABLES        ...
SYSIBM    SYSCOLUMNS       ...
...

Você acabou de perguntar ao Db2:

"Quais objetos você conhece?"

---

8. Exercício 4 — Procurando as próprias tabelas SYSIBM

Agora vamos filtrar.

Execute:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'SYSIBM'
FETCH FIRST 30 ROWS ONLY;

Aqui aparece uma das regras fundamentais de SQL:

SELECT → o que quero
FROM   → de onde
WHERE  → quais registros quero

Visualmente:

SYSIBM.SYSTABLES
       │
       ▼
WHERE CREATOR = 'SYSIBM'
       │
       ▼
somente objetos SYSIBM
       │
       ▼
SELECT CREATOR, NAME, TYPE

---

9. Exercício 5 — Procurando uma tabela pelo nome

Agora imagine que alguém diz:

"Existe uma tabela chamada SYSTABLES."

Você quer descobrir onde.

Execute:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE NAME = 'SYSTABLES';

Provavelmente encontrará:

SYSIBM   SYSTABLES   ...

Agora você conhece uma técnica extremamente importante.

Quando alguém disser:

"Procure a tabela XPTO."

Você pode consultar o catálogo.

---

10. Exercício 6 — Usando LIKE

Nem sempre sabemos o nome completo.

Talvez alguém diga:

"Era alguma coisa começando com SYS..."

Podemos utilizar:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'SYSIBM'
  AND NAME LIKE 'SYS%'
FETCH FIRST 30 ROWS ONLY;

O % funciona como wildcard para uma sequência de caracteres.

'SYS%'

pode localizar:

SYS...
SYSTABLES
SYSCOLUMNS
SYSINDEXES
...

Agora experimente:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'SYSIBM'
  AND NAME LIKE '%TABLE%'
FETCH FIRST 30 ROWS ONLY;

A diferença é importante:

'TABLE%'   começa com TABLE

'%TABLE'   termina com TABLE

'%TABLE%'  contém TABLE

---

11. Exercício 7 — Conhecendo SYSIBM.SYSCOLUMNS

Encontramos uma tabela.

Agora queremos saber:

"Quais colunas ela possui?"

Para isso temos uma das estrelas do catálogo:

SYSIBM.SYSCOLUMNS

Execute:

SELECT TBCREATOR,
       TBNAME,
       NAME,
       COLNO,
       COLTYPE,
       LENGTH
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES'
ORDER BY COLNO;

Agora o Db2 está descrevendo uma de suas próprias tabelas.

Isso é quase recursivo:

SYSCOLUMNS
     │
     │ descreve
     ▼
SYSTABLES
     │
     │ que descreve
     ▼
objetos existentes no Db2

---

12. Entendendo o resultado

Observe alguns conceitos.

TBCREATOR

Creator/qualifier da tabela.

TBNAME

Nome da tabela.

NAME

Nome da coluna.

COLNO

Posição da coluna.

COLTYPE

Tipo de dado registrado no catálogo.

LENGTH

Comprimento associado à coluna conforme sua definição.

Assim você começa a descobrir a estrutura de uma tabela sem precisar encontrar primeiro o programa COBOL que a utiliza.

---

13. Exercício 8 — Conte quantas colunas SYSTABLES possui

Agora podemos usar uma função SQL:

SELECT COUNT(*)
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES';

O Db2 contará os registros correspondentes.

Como existe normalmente uma entrada de catálogo para cada coluna da tabela, conseguimos responder:

"Quantas colunas existem nessa tabela?"

Isso demonstra uma coisa poderosa:

CATÁLOGO
   +
SQL
   =
INVESTIGAÇÃO

---

14. Exercício 9 — Encontrando índices

Tabelas podem possuir índices.

Vamos perguntar ao catálogo:

SELECT CREATOR,
       NAME,
       TBCREATOR,
       TBNAME
FROM SYSIBM.SYSINDEXES
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES';

Aqui estamos utilizando:

SYSIBM.SYSINDEXES

Essa tabela contém informações sobre índices registrados no catálogo.

A ideia conceitual é:

TABELA
  │
  ├───────────────┐
  │               │
  ▼               ▼
dados           índices
                  │
                  ▼
        estruturas de acesso

Não pense que índice é simplesmente "uma tabela ordenada".

Índices são estruturas mantidas pelo Db2 que podem ser utilizadas para localizar dados de maneira eficiente e também podem participar da implementação de determinadas restrições de unicidade.

---

15. Exercício 10 — Procurando índices de uma tabela qualquer

Se o seu instrutor fornecer uma tabela de treinamento, por exemplo:

ALUNO.CLIENTES

poderíamos investigar:

SELECT CREATOR,
       NAME,
       TBCREATOR,
       TBNAME
FROM SYSIBM.SYSINDEXES
WHERE TBCREATOR = 'ALUNO'
  AND TBNAME = 'CLIENTES';

Assim começamos a montar uma ficha do objeto:

ALUNO.CLIENTES
      │
      ├── colunas → SYSCOLUMNS
      │
      └── índices → SYSINDEXES

---

16. Exercício 11 — Vamos fazer uma pequena investigação

Imagine que recebemos apenas esta informação:

Existe alguma coisa chamada EMP?

Não sabemos se o nome completo é:

EMP
EMPLOYEE
EMPLOYEES
EMPRESA
EMPREGADO

Podemos investigar:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE NAME LIKE 'EMP%'
FETCH FIRST 50 ROWS ONLY;

Encontrou algo interessante?

Escolha um objeto ao qual você tenha acesso.

Suponha que encontramos:

DSN8C10.EMP

Não copie esse nome cegamente: objetos de exemplo disponíveis variam conforme a instalação.

Agora investigamos suas colunas:

SELECT NAME,
       COLNO,
       COLTYPE,
       LENGTH
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'DSN8C10'
  AND TBNAME = 'EMP'
ORDER BY COLNO;

Acabamos de fazer algo muito parecido com uma investigação real de aplicação.

---

17. Exercício 12 — Do geral para o específico

Observe a metodologia que estamos construindo.

Primeiro:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE NAME LIKE '%EMP%'
FETCH FIRST 50 ROWS ONLY;

Encontramos:

qualifier + tabela

Depois:

SELECT NAME,
       COLTYPE,
       LENGTH
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'QUALIFIER_ENCONTRADO'
  AND TBNAME = 'TABELA_ENCONTRADA'
ORDER BY COLNO;

Depois:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSINDEXES
WHERE TBCREATOR = 'QUALIFIER_ENCONTRADO'
  AND TBNAME = 'TABELA_ENCONTRADA';

Nossa investigação virou:

        Qual objeto existe?
                │
                ▼
           SYSTABLES
                │
                ▼
       Quais colunas possui?
                │
                ▼
          SYSCOLUMNS
                │
                ▼
        Quais índices possui?
                │
                ▼
          SYSINDEXES

---

18. Exercício 13 — ORDER BY

Vamos organizar os resultados.

SELECT TBCREATOR,
       TBNAME,
       NAME,
       COLNO
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES'
ORDER BY COLNO;

Sem ORDER BY, não devemos assumir uma ordem lógica simplesmente porque os resultados apareceram daquela maneira em uma execução.

Com:

ORDER BY COLNO

estamos explicitamente pedindo a ordenação.

Essa diferença é importantíssima.

Nunca programe pensando:

"Ontem o SELECT veio nessa ordem."

Se a ordem importa, declare-a.

---

19. Exercício 14 — Provocando um erro proposital

Erros também fazem parte do laboratório.

Execute propositalmente:

SELECT XPTO
FROM SYSIBM.SYSTABLES;

XPTO provavelmente não existe como coluna dessa tabela.

Observe cuidadosamente a saída do SPUFI.

Procure:

SQLCODE
SQLSTATE
mensagem Db2

A mensagem exata dependerá do problema e da versão.

A lição aqui não é decorar um número.

É desenvolver este reflexo:

SQL falhou
    │
    ▼
não comece alterando tudo
    │
    ▼
leia SQLCODE
    │
    ▼
leia SQLSTATE
    │
    ▼
leia mensagem
    │
    ▼
identifique a causa
    │
    ▼
corrija

Isso será fundamental quando chegarmos ao COBOL.

---

20. Exercício 15 — Procurando algo que não existe

Execute:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE NAME = 'TABELA_DO_HARRY_POTTER_999';

Supondo que ninguém tenha criado uma tabela com esse nome, teremos zero linhas.

E aqui existe uma lição importante:

SELECT executado corretamente
+
nenhuma linha encontrada

não significa necessariamente:

SQL quebrado

O comando pode estar perfeitamente correto.

Simplesmente não encontrou registros correspondentes.

Essa diferença será importantíssima quando estudarmos SQLCODE +100 em programas Db2.

---

21. Desafio — faça o papel de detetive do Db2

Agora tente resolver sem copiar imediatamente a resposta.

Sua missão é:

1. Encontrar cinco objetos cujo creator seja SYSIBM.

2. Escolher uma tabela do catálogo.

3. Descobrir quantas colunas ela possui.

4. Listar suas colunas em ordem.

5. Identificar os tipos dessas colunas.

6. Verificar se existem índices associados a ela.

7. Registrar os SQLs utilizados.

Sua investigação deverá seguir aproximadamente:

            Db2
             │
             ▼
     SYSIBM.SYSTABLES
             │
             ▼
       achei a tabela
             │
             ▼
     SYSIBM.SYSCOLUMNS
             │
             ▼
      achei as colunas
             │
             ▼
      SYSIBM.SYSINDEXES
             │
             ▼
       achei os índices

---

22. O que realmente aprendemos?

Parece que fizemos apenas alguns SELECT.

Na realidade aprendemos uma parte fundamental da filosofia do Db2.

O banco não guarda somente:

CLIENTE = JOÃO
SALDO   = 1000

Ele também precisa conhecer a estrutura do próprio ambiente:

Existe tabela CLIENTES?
Quem é seu creator?
Quais colunas possui?
Quais são seus tipos?
Quais índices estão associados?
Que outros objetos existem?

Esse é o papel do catálogo.

Podemos imaginar:

                 Db2
                  │
          ┌───────┴────────┐
          │                │
          ▼                ▼
       DADOS            CATÁLOGO
          │                │
          ▼                ▼
      CLIENTES        SYSTABLES
      CONTAS          SYSCOLUMNS
      PEDIDOS         SYSINDEXES
      ...             ...

O catálogo é, portanto, um conjunto de informações que permite ao Db2 conhecer e administrar seu próprio ambiente.

---

23. Para que um programador COBOL precisa saber disso?

Imagine que você recebe um programa COBOL antigo contendo:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTES
    WHERE ID_CLIENTE = :WS-ID
END-EXEC.

Você nunca viu a aplicação.

Imediatamente surgem perguntas:

Quem é CLIENTES?

Qual seu qualifier?

ID_CLIENTE é INTEGER?

NOME é CHAR ou VARCHAR?

SALDO é DECIMAL?

Existem índices?

Qual é a estrutura dessa tabela?

Agora você possui uma ferramenta para começar a investigação.

Programa COBOL
      │
      │ encontrou CLIENTES
      ▼
SPUFI
      │
      ▼
SYSIBM.SYSTABLES
      │
      ▼
SYSIBM.SYSCOLUMNS
      │
      ▼
SYSIBM.SYSINDEXES
      │
      ▼
começamos a compreender
a aplicação

É por isso que aprender o catálogo vale muito mais do que decorar meia dúzia de SELECT.

---

24. Cola de bolso do aluno

Guarde estes três nomes:

┌───────────────────────────────────────────┐
│           CATÁLOGO Db2 — BÁSICO           │
├───────────────────────────────────────────┤
│                                           │
│ SYSIBM.SYSTABLES                          │
│       ↓                                   │
│ "Quais tabelas/objetos existem?"          │
│                                           │
│ SYSIBM.SYSCOLUMNS                         │
│       ↓                                   │
│ "Quais são suas colunas?"                 │
│                                           │
│ SYSIBM.SYSINDEXES                         │
│       ↓                                   │
│ "Quais índices existem?"                  │
│                                           │
└───────────────────────────────────────────┘

E principalmente guarde a metodologia:

NÃO SEI
   │
   ▼
CONSULTO O CATÁLOGO
   │
   ▼
ENCONTRO O OBJETO
   │
   ▼
INVESTIGO SUA ESTRUTURA
   │
   ▼
ENTENDO AS RELAÇÕES
   │
   ▼
VOLTO AO PROGRAMA COBOL

Essa é uma mudança importante na formação de um profissional de mainframe.

O iniciante pergunta:

"Qual é a tabela?"

O profissional aprende a perguntar ao próprio Db2.

☕ Fim do laboratório — e início da investigação.

 

Bellacosa Mainframe espiona o Youtube

☕ Um Café no Bellacosa Mainframe

Hermes Entra no CPD — O Dia em que o Mensageiro dos Deuses Descobriu que o YouTube Era um JES2 Planetário com CDN, Cache, Filas e Bilhões de Jobs

Ou: como upload, transcoding, blob storage, filas, CDN, DNS, load balancer, sharding, replicação, microservices, recomendação por IA e observabilidade transformam um simples botão ▶ em uma das maiores máquinas distribuídas já construídas — e por que Hermes provavelmente pediria um RACF antes de entregar a mensagem

---

Prólogo — Hermes chegou voando, mas o pacote tinha 8 GB

Eram duas e quarenta e sete da manhã no CPD.

O ar-condicionado fazia aquele barulho que todo veterano de mainframe aprende a interpretar como:

“Estou funcionando. Não mexa em mim.”

Na mesa havia uma caneca de café, um terminal 3270, três dumps impressos que ninguém queria assumir como seus e um programador COBOL iniciante tentando entender uma pergunta aparentemente simples:

— Bellacosa, como o YouTube funciona?

Antes que alguém pudesse responder, as portas do CPD se abriram.

Entrou um sujeito usando sandálias aladas, capacete ornamentado e carregando um pacote enorme debaixo do braço.

— Hermes — apresentou-se. — Mensageiro dos deuses. Mercúrio para os romanos. Entregas terrestres, celestiais, interdimensionais e, recentemente, tráfego IP.

O operador levantou uma sobrancelha.

— Tem autorização?

Hermes apontou para as asas.

— Eu atravesso os mundos.

O operador virou-se para o terminal.

— Isso não responde à pergunta.

Bem-vindo ao mainframe.

Hermes havia trazido um vídeo.

Um arquivo em 4K.

O programador COBOL olhou para ele e imaginou que o processo fosse simples:

UPLOAD
   ↓
YOUTUBE
   ↓
PLAY

Hermes riu.

— Jovem mortal... se fosse assim, eu ainda estaria entregando mensagens em papiro.

E foi dessa maneira que começou nossa viagem.

Porque o YouTube parece simples apenas enquanto você permanece do lado de fora.

Você abre uma página.

Procura um vídeo.

Clica.

Assiste.

Mas atrás daquele pequeno triângulo ▶ existe uma cidade tecnológica gigantesca formada por armazenamento distribuído, processamento assíncrono, filas, bancos de dados, caches, servidores, índices de busca, sistemas de recomendação, telemetria e infraestrutura espalhada pelo planeta.

E o mais divertido para quem conhece mainframe?

Muitos dos problemas fundamentais parecem terrivelmente familiares.

---

1. Primeiro aviso de Hermes: o diagrama não é o território

Diagramas de “YouTube System Design” aparecem frequentemente na Internet.

Eles mostram caixas como:

Blob Storage
Encoder
Cache
App Server
Database
Search
Recommendation
Load Balancer

São excelentes para aprender.

Mas precisamos entender algo desde o início:

aquilo não é uma planta completa da infraestrutura real do YouTube.

É uma representação conceitual.

Seria semelhante a desenhar um ambiente bancário como:

Terminal
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Está errado?

Não necessariamente.

Está completo?

Nem remotamente.

Atrás dessas quatro caixas podem existir Parallel Sysplex, RACF, MQ, VSAM, WLM, JES2, SMF, storage, redes, replicação, disaster recovery, schedulers e dezenas de outras tecnologias.

O mesmo vale para uma plataforma de vídeo planetária.

A finalidade de um bom desenho de arquitetura não é registrar cada parafuso.

É mostrar responsabilidades, fluxos e pontos críticos.

Hermes chama isso de mapa.

O mainframe chama isso de “não tente explicar tudo no mesmo slide”.

---

2. Existem dois mundos: o vídeo e os dados sobre o vídeo

Essa distinção é fundamental.

Imagine um vídeo chamado:

INTRODUCAO-COBOL-EPISODIO-01.mp4

O arquivo pode ter vários gigabytes.

Mas suas informações são pequenas:

VIDEO_ID
TITLE
CHANNEL
DURATION
UPLOAD_DATE
DESCRIPTION
VISIBILITY

Portanto há duas famílias de dados.

De um lado:

ARQUIVO DE VÍDEO

Do outro:

METADADOS

Você normalmente não quer tratar ambos da mesma maneira.

O vídeo bruto pertence a uma infraestrutura apropriada para objetos grandes.

Os metadados pertencem a bancos e índices estruturados.

Pense num programador COBOL armazenando um filme inteiro dentro de cada registro de uma tabela operacional.

Hermes tiraria as sandálias aladas só para bater com uma delas no sujeito.

---

3. O upload começa uma jornada, não termina uma

O usuário seleciona um vídeo e aperta:

Upload.

Parece que o trabalho terminou.

Para a plataforma, acabou de começar.

Imagine um arquivo de 8 GB em 4K.

O sistema pode primeiro armazenar esse arquivo original em algum tipo de object/blob storage.

Mas enviá-lo exatamente daquela maneira para cada usuário seria péssimo.

Uma televisão 4K talvez aproveite a resolução.

Um celular numa rede móvel ruim certamente não.

Por isso entram os encoders, ou, mais precisamente, processos de transcodificação.

O vídeo original pode gerar múltiplas representações:

Original
   ↓
2160p
1440p
1080p
720p
480p
360p
240p

Só que resolução é apenas uma variável.

Também temos codecs, bitrate, áudio, HDR, frames por segundo e formatos diferentes.

Ou seja:

1 vídeo enviado
      ↓
várias versões distribuíveis

Hermes gostou imediatamente.

Era como traduzir a mesma mensagem para gregos, romanos, egípcios, persas e o sujeito da contabilidade que só aceita CSV delimitado por ponto e vírgula.

---

4. A fila: Hermes conhece, JES2 também

Aqui começa o verdadeiro parentesco com o mundo mainframe.

Imagine que 100 mil usuários façam upload simultaneamente.

Você não quer executar imediatamente 100 mil processos pesados de encoding.

Em vez disso:

UPLOAD
   ↓
STORAGE
   ↓
QUEUE
   ↓
ENCODER WORKERS

O upload é recebido.

Um trabalho é colocado numa fila.

Workers consomem os jobs conforme existe capacidade.

Qualquer veterano de mainframe pode sentir um arrepio nostálgico.

Porque a essência lembra:

SUBMIT
  ↓
JES2
  ↓
QUEUE
  ↓
EXECUTION

Não é a mesma tecnologia.

Não é a mesma implementação.

Mas é o mesmo problema fundamental:

há mais trabalho chegando do que convém executar instantaneamente.

A fila desacopla quem produz trabalho de quem o executa.

Isso é uma ideia profundamente poderosa.

---

5. Por que processamento assíncrono salva arquiteturas

Imagine uma aplicação ingênua.

O usuário manda um vídeo.

A conexão HTTP fica esperando enquanto o sistema:

recebe o arquivo, valida, converte, gera thumbnails, indexa, prepara formatos e distribui tudo.

Podem passar minutos.

Ou muito mais.

Isso é péssimo.

Uma arquitetura melhor responde algo conceitualmente equivalente a:

RECEBIDO
PROCESSAMENTO EM ANDAMENTO

O trabalho prossegue em background.

Depois diferentes eventos podem ocorrer:

VIDEO_UPLOADED
VIDEO_VALIDATED
TRANSCODING_STARTED
TRANSCODING_COMPLETED
VIDEO_READY

Isso nos leva à arquitetura orientada a eventos.

Hermes aprovou.

Afinal, se existe alguém mitologicamente qualificado para trabalhar com mensagens assíncronas, é o mensageiro dos deuses.

---

6. Curiosidade do Olimpo: Hermes seria um message broker perfeito

Na mitologia grega, Hermes era associado a mensagens, viagens, comércio e comunicação entre mundos.

Se estivesse num diagrama de arquitetura moderno, provavelmente apareceria assim:

ZEUS
  ↓
HERMES MESSAGE BUS
  ↓
MORTAIS

Ou talvez:

EVENT: ZEUS_COMMAND
TOPIC: /olympus/thunder
CONSUMER: HERMES

E, conhecendo Zeus, provavelmente precisaríamos de:

MAX_RETRY=0

porque ninguém quer receber o mesmo raio duas vezes.

---

7. CDN: a tecnologia que impede o sucesso de matar você

Agora imagine que o vídeo fique viral.

Dez milhões de pessoas querem assistir.

Sem distribuição adequada:

10.000.000 usuários
          ↓
       ORIGIN

Parabéns.

Seu conteúdo viral acaba de executar um ataque DDoS contra você mesmo.

Uma das soluções fundamentais é a CDN, Content Delivery Network.

A ideia é distribuir ou armazenar conteúdo mais perto dos usuários.

Simplificando:

               ORIGIN
                 |
       +---------+---------+
       |         |         |
     Região A  Região B  Região C
       |         |         |
     caches    caches    caches

Assim, um usuário brasileiro não precisa necessariamente buscar cada segmento do vídeo a milhares de quilômetros de distância.

A física continua sendo uma dependência que nenhuma atualização de software corrigiu.

Velocidade da luz tem SLA extremamente rígido.

---

8. Cache: o funcionário que diz “já tenho isso aqui”

Cache é um dos conceitos mais importantes de system design.

Imagine o primeiro pedido por determinado conteúdo:

CACHE
  ↓
MISS
  ↓
ORIGIN
  ↓
RESPOSTA
  ↓
CACHE

Depois outro usuário pede a mesma coisa:

CACHE
  ↓
HIT
  ↓
RESPOSTA

Muito mais barato.

Muito mais rápido.

Menos carga no sistema original.

Essa lógica vale para páginas, metadados, consultas e partes de vídeo.

No universo mainframe, a ideia de evitar I/O caro mantendo conteúdo frequentemente utilizado próximo da execução certamente não causará choque filosófico.

É apenas mais uma versão da velha máxima:

não vá buscar longe aquilo que você já tem perto.

---

9. Vídeo não precisa viajar inteiro

Outro detalhe fascinante.

Quando você começa a assistir a um filme de duas horas, normalmente não precisa baixar as duas horas antes de começar.

O conteúdo pode ser dividido em segmentos:

VIDEO
 |
 +-- SEGMENT 001
 +-- SEGMENT 002
 +-- SEGMENT 003
 +-- SEGMENT 004

O player vai solicitando pedaços.

Isso é fundamental para streaming adaptativo.

Sua rede está ótima?

O sistema pode entregar segmentos de maior qualidade.

Sua conexão piorou?

Pode reduzir qualidade.

Exemplo:

1080p
1080p
720p
480p
720p
1080p

Você provavelmente já viu isso acontecendo.

O vídeo fica ligeiramente borrado por alguns segundos e depois melhora.

Isso não é necessariamente defeito.

É a plataforma negociando com a realidade.

---

10. Adaptive Bitrate: melhor assistir em 720p do que contemplar uma bolinha girando em 4K

Um algoritmo de streaming pode considerar coisas como largura de banda disponível, tamanho do buffer e capacidade do dispositivo.

O objetivo conceitual é:

máxima qualidade possível
          +
mínimas interrupções

Porque existe uma regra prática importantíssima:

usuário tolera queda de resolução melhor do que vídeo congelando a cada oito segundos.

Hermes lembrou que mensageiros antigos também faziam isso.

Quando a estrada estava boa, ele voava.

Quando tinha tempestade, descia.

Adaptive transport, versão mitológica.

---

11. DNS: antes de entregar a mensagem, descubra onde fica a casa

Quando digitamos um endereço, o computador precisa descobrir para onde enviar a conexão.

DNS ajuda a transformar um nome em informação de localização de rede.

Simplificando:

youtube.com
     ↓
DNS
     ↓
destino apropriado

Em sistemas globais, a história pode ficar bem mais sofisticada, envolvendo infraestrutura distribuída e decisões geográficas.

Mas conceitualmente DNS é o início da viagem.

Hermes é mensageiro.

DNS é o mapa.

Sem mapa, até deus se perde.

---

12. Load Balancer: o WLM da porta de entrada

Depois temos balanceamento.

Imagine milhares de servidores capazes de atender requisições.

O usuário não sabe qual deles deveria atender.

Nem deveria saber.

Entra o load balancer.

             REQUEST
                ↓
          LOAD BALANCER
          /      |      \
       SERVER1 SERVER2 SERVER3

Ele distribui demanda.

Se um servidor está indisponível, idealmente deixa de enviar tráfego para ele.

Aqui um veterano z/OS imediatamente reconhece a filosofia de workload management.

Novamente: não são tecnologias idênticas.

Mas o problema é conhecido.

Temos trabalho.

Temos recursos.

Precisamos casar ambos de maneira eficiente.

WLM olha do fundo da sala e murmura:

— Bonito esse “cloud native”.

---

13. Stateless: não se apaixone pelo servidor 42

Imagine que toda a sessão de um usuário exista apenas na memória de um único servidor.

USER
 ↓
SERVER 42

Servidor 42 morre.

Adeus sessão.

Sistemas distribuídos tentam, sempre que adequado, evitar dependência excessiva de estado local.

Assim:

Request A → Server 12
Request B → Server 94
Request C → Server 33

podem funcionar.

Isso facilita escalar horizontalmente e lidar com falhas.

É uma diferença importante entre:

“este servidor é especial”

e

“qualquer servidor saudável desse grupo pode executar o trabalho”.

---

14. Vertical versus horizontal: mainframe encontra hyperscale

Aqui entra uma discussão deliciosa.

Escalabilidade vertical significa colocar mais capacidade numa máquina:

16 CPUs
 ↓
32 CPUs
 ↓
64 CPUs

Escalabilidade horizontal significa aumentar o número de máquinas:

10 servidores
 ↓
100
 ↓
1000

O IBM Z tornou-se historicamente extraordinário em consolidação e escala vertical.

Ambientes hyperscale exploraram de maneira brilhante a distribuição horizontal.

Isso gerou quase duas escolas filosóficas.

Uma diz:

“Construa uma máquina absurda.”

Outra diz:

“Construa um exército de máquinas.”

Na prática, arquiteturas sérias combinam estratégias.

Hermes, naturalmente, sugeriu asas em todos os servidores.

Não foi aprovado pelo capacity planning.

---

15. Agora chegamos ao verdadeiro monstro: dados dos usuários

Imagine registrar:

histórico, likes, dislikes, inscrições, playlists, comentários, sessões, progresso de reprodução e preferências.

Isso gera quantidades extraordinárias de dados.

Uma tabela conceitual poderia ter:

USER_ID
VIDEO_ID
TIMESTAMP
WATCH_DURATION
POSITION
DEVICE

Agora multiplique isso por milhões ou bilhões de usuários.

Uma única instância de banco eventualmente se torna insuficiente ou inadequada.

Entra o sharding.

---

16. Sharding: cortando o dragão em pedaços administráveis

Sharding significa particionar dados entre bancos ou grupos de servidores.

Exemplo simplificado:

Usuários A–F → SHARD 1
Usuários G–M → SHARD 2
Usuários N–S → SHARD 3
Usuários T–Z → SHARD 4

Ou usando hash:

SHARD = HASH(USER_ID) MOD N

Então:

USER 100 → SHARD 4
USER 101 → SHARD 9

Isso permite distribuir carga e armazenamento.

Só que cada solução cria novos problemas.

Agora precisamos pensar em:

hot shards, rebalanceamento, consultas entre shards, transações distribuídas, routing e recuperação.

Uma das grandes verdades de arquitetura é esta:

você raramente elimina complexidade; normalmente muda onde ela mora.

---

17. Vitess: quando alguém precisou ensinar MySQL a conversar com gigantes

Um detalhe especialmente interessante no desenho é a presença de Vitess.

O projeto Vitess nasceu justamente no contexto do YouTube para ajudar a escalar MySQL.

A aplicação poderia pensar aproximadamente:

Quero USER_ID = 123

Enquanto uma camada intermediária ajuda a localizar onde aquele dado realmente está.

Conceitualmente:

APPLICATION
    ↓
VITESS
    ↓
SHARD CORRETO
    ↓
MYSQL

Essa é uma curiosidade histórica excelente.

Quando uma empresa chega a uma escala absurda, começa a criar ferramentas para resolver problemas que poucas outras empresas possuíam naquele momento.

Depois essas ferramentas acabam servindo ao resto da indústria.

---

18. Replication não é sharding

É comum iniciantes confundirem.

Sharding responde:

como divido meus dados?

Replication responde:

quantas cópias tenho e como sobrevivo à falha?

Podemos ter:

PRIMARY
   |
   +---- REPLICA A
   |
   +---- REPLICA B

Se uma máquina desaparece, existem cópias.

Isso ajuda disponibilidade, recuperação e distribuição de leitura.

Mas abre outra caixa mitológica:

consistência.

---

19. Eventual consistency: nem todo dado precisa estar perfeito no mesmo microssegundo

Imagine um vídeo com:

999 LIKES

Você clica Like.

Um servidor passa a mostrar:

1000

Outro ainda mostra:

999

por alguns instantes.

Pode ser aceitável.

Agora pense em:

SALDO BANCÁRIO

A conversa muda.

Esse é um ensinamento importantíssimo para programadores vindos de ambientes altamente transacionais:

consistência é requisito, não dogma.

Alguns dados exigem precisão imediata e rigorosa.

Outros toleram propagação.

É o contexto de negócio que decide.

---

20. Microservices: a cidade deixa de ter um único prédio

No desenho aparecem serviços independentes:

Upload Service
Search Service
Comments Service

A ideia é decompor funcionalidades.

Search pode precisar de muito mais capacidade que Comments.

Upload talvez tenha características completamente diferentes de Recommendation.

Então cada serviço pode crescer de maneira própria.

Mas aqui aparece um aviso de Hermes:

microservices não removem complexidade.

Eles transformam:

complexidade dentro do programa

em:

complexidade entre programas

Agora temos rede.

E rede traz:

timeouts, retries, latência, descoberta de serviços, compatibilidade de versões, tracing e falhas parciais.

O monólito explodiu.

Os pedaços agora discutem entre si pela Ethernet.

---

21. Search: nunca execute LIKE '%COBOL%' em bilhões de vídeos e espere um milagre

Imagine procurar:

curso cobol mainframe

Uma implementação ingênua faria algo semelhante a:

SELECT *
FROM VIDEOS
WHERE DESCRIPTION LIKE '%curso cobol mainframe%';

Contra uma base gigantesca?

Hermes mandaria a consulta diretamente para Hades.

Sistemas de busca utilizam índices especializados.

Uma simplificação:

COBOL → vídeos 1, 10, 93, 456
MAINFRAME → vídeos 1, 93, 800
CURSO → vídeos 1, 7, 93

Os candidatos comuns podem ser encontrados rapidamente.

Depois entra ranking.

Porque encontrar conteúdo não basta.

Precisamos decidir qual resultado vem primeiro.

---

22. Recommendation Engine: o Oráculo de Delfos com GPUs

Agora entramos numa das partes mais fascinantes.

Você abre a homepage.

Existe um universo gigantesco de vídeos.

O sistema precisa escolher algumas dezenas.

Seria absurdo executar o modelo mais pesado possível sobre cada vídeo existente.

Então podemos imaginar várias etapas.

Primeiro:

BILHÕES DE VÍDEOS
       ↓
CANDIDATE GENERATION
       ↓
MILHARES
       ↓
RANKING
       ↓
CENTENAS
       ↓
RE-RANKING / POLICIES
       ↓
FEED

Esse padrão aparece em grandes sistemas de recomendação.

Primeiro reduzimos o universo.

Depois gastamos processamento mais caro nos melhores candidatos.

É semelhante a procurar uma agulha no palheiro usando primeiro uma peneira industrial e só depois uma pinça.

---

23. O algoritmo não vê apenas Likes

Outro erro comum é imaginar:

mais likes = mais recomendação

Na prática, sistemas de recomendação podem analisar muitos sinais.

Você clicou.

Mas assistiu?

Assistiu por dois segundos?

Chegou ao fim?

Pulou?

Voltou?

Inscreveu-se?

Procurou outro conteúdo parecido?

Um clique isolado não significa satisfação.

Exemplo clássico:

"DESCOBERTA IMPOSSÍVEL EM MARTE!!!"

Você clica.

Três segundos depois percebe que é clickbait.

Tecnicamente houve clique.

Comportamentalmente houve rejeição.

Por isso métricas como watch time e retenção são valiosas.

---

24. Adaptive Algorithm: o sistema observa você observando o sistema

Existe um loop fascinante:

Recommendation
      ↓
Usuário vê
      ↓
Clique / Skip / Watch
      ↓
Eventos
      ↓
Analytics
      ↓
Features / Models
      ↓
Nova Recommendation

É um sistema que muda de comportamento com base nas respostas do usuário.

Mas aqui precisamos ser tecnicamente cuidadosos.

“Aprender em tempo real” não significa necessariamente:

um modelo gigantesco sendo retreinado a cada clique.

Podemos ter sinais atualizados imediatamente enquanto treinamentos pesados acontecem em outras cadências.

Por exemplo:

Clique agora
   ↓
perfil/features atualizados

Modelo pesado
   ↓
treinamento periódico

São coisas diferentes.

---

25. Observabilidade: coloque Poirot junto com Hermes

No desenho original, observabilidade aparece quase como mais uma caixinha.

Na prática ela deve atravessar toda a arquitetura.

Precisamos observar:

DNS
Load Balancer
Apps
Queues
Encoders
Caches
Databases
Search
Recommendation
CDN

O trio clássico é:

metrics, logs e traces.

Metrics dizem:

algo está estranho.

Logs ajudam a descobrir:

o que aconteceu?

Tracing pergunta:

por onde essa requisição passou?

Exemplo:

Gateway    10 ms
Auth       20 ms
App        50 ms
Search     70 ms
Database 4200 ms

Encontramos o cadáver.

Db2 demorou 4,2 segundos.

Poirot começa a sorrir.

---

26. Média engana; percentis contam a história

Suponha:

latência média = 200 ms

Excelente?

Talvez.

E se:

p50 = 100 ms
p95 = 600 ms
p99 = 9 segundos

Um por cento dos usuários pode estar tendo uma experiência terrível.

Em sistemas com bilhões de requisições, 1% não é uma exceção pequena.

É uma multidão.

Por isso percentis, principalmente p95 e p99, são essenciais.

---

27. Fault tolerance: servidor quebrar não é evento raro

Em ambientes pequenos, alguém pergunta:

“E se o servidor cair?”

Em hyperscale, a frase correta é:

“Quando alguns servidores caírem hoje, o que acontecerá?”

Discos morrem.

Switches falham.

Máquinas reiniciam.

Links ficam lentos.

Deploys quebram serviços.

Datacenters podem enfrentar incidentes.

A arquitetura precisa assumir falha.

Entram mecanismos como health checks, replicas, retries, timeouts, failover e circuit breakers.

---

28. Graceful degradation: YouTube sem comentários ainda é YouTube

Imagine que Comments Service pare.

Arquitetura frágil:

COMMENTS DOWN
     ↓
SITE DOWN

Arquitetura resiliente:

VIDEO OK
SEARCH OK
STREAMING OK
COMMENTS TEMPORARILY UNAVAILABLE

O usuário continua assistindo.

Isso é graceful degradation.

Outra hipótese:

Recommendation Engine está indisponível.

Em vez de morrer, a homepage poderia usar alternativas mais simples:

Popular
Subscriptions
Trending
Recent

Essa filosofia é maravilhosa:

falhar parcialmente é melhor do que morrer completamente.

---

29. Backpressure: JES2 sabe que fila infinita não é estratégia

Suponha que os encoders consigam processar:

8 milhões de uploads/hora

Mas chegam:

10 milhões/hora

Fila cresce:

+2 milhões/hora

Depois de dez horas:

20 milhões pendentes

Isso é perigoso.

Sistemas precisam aplicar backpressure.

Podem aumentar capacidade, reduzir admissões, priorizar trabalhos ou aplicar quotas.

O princípio é antigo:

não aceite trabalho ilimitadamente se não consegue executá-lo.

JES2, sentado no canto do bar, levanta a caneca.

---

30. Hotspots: o problema não é apenas quanto tráfego existe, mas onde ele aparece

Talvez existam bilhões de vídeos.

Mas a demanda não será uniforme.

Um vídeo recebe:

3 views/dia

Outro:

10 milhões em uma hora

A média não ajuda muito.

Notícias, eventos esportivos, lançamentos musicais e memes criam hotspots.

Por isso caches e CDNs precisam responder rapidamente a mudanças bruscas de popularidade.

É como Black Friday.

Ninguém dimensiona varejo apenas olhando a terça-feira de fevereiro.

---

31. Retry storm: quando tentar ajudar piora tudo

Imagine um banco lento.

App Server espera.

Timeout.

Cliente tenta novamente.

Outro timeout.

Outro retry.

Agora o banco, que já estava sofrendo, recebe ainda mais carga.

Temos:

Sistema lento
   ↓
Retries
   ↓
Mais carga
   ↓
Sistema ainda mais lento
   ↓
Mais retries

Um círculo infernal digno de Hades.

Por isso retries precisam de limites, exponential backoff e jitter.

Nem toda falha deve ser respondida imediatamente com:

“Tenta outra vez!”

---

32. Idempotência: Hermes odeia entregar a mesma mensagem duas vezes

Considere:

POST /like

O servidor recebe, grava o Like e a conexão cai antes da resposta chegar.

O cliente pensa:

será que funcionou?

E envia de novo.

Sem cuidados, temos duplicidade.

Idempotência significa projetar determinadas operações para que repeti-las não cause efeitos duplicados indesejáveis.

Algo como:

REQUEST_ID = ABC123

Se já foi processado:

não processe novamente

Esse conceito é fundamental em mensagens, pagamentos, uploads e integração.

Qualquer programador que já recebeu arquivo duplicado de batch sabe exatamente por quê.

---

33. “Exactly once”: cuidado com deuses prometendo milagres

Em sistemas distribuídos existem expressões como:

at-most-once
at-least-once
exactly-once

“Exactly once” parece maravilhoso.

Mas exige grande cuidado para definir exatamente onde a garantia existe.

Muitas vezes é mais seguro assumir que mensagens podem chegar novamente e tornar o consumidor idempotente.

Ou seja:

evento repetido?
 ↓
detecte
 ↓
ignore

Isso evita transformar retry legítimo em duplicidade de negócio.

---

34. Segurança: Hermes não entra no CPD só porque tem asas

O desenho original quase não mostra segurança.

Eu colocaria uma enorme camada sobre tudo.

Uma plataforma desse tamanho precisa pensar em autenticação, autorização, fraude, abuso, bots, scraping, spam, DDoS, roubo de contas e proteção de APIs.

A questão não é apenas:

consigo executar esta requisição?

Mas:

este usuário está autorizado a executá-la?

Programador COBOL olha para RACF.

RACF olha para Hermes.

Hermes entrega a credencial.

RACF responde:

ICH408I

Hermes protesta:

— EU SOU UM DEUS!

RACF:

— Isso não consta no perfil.

Esse talvez seja o easter egg mais realista de todo o artigo.

---

35. Como assistir a um vídeo vira uma pequena Odisseia

Agora podemos seguir o caminho completo.

O usuário pressiona ▶.

DNS ajuda a encontrar infraestrutura apropriada.

A requisição atravessa mecanismos de edge e balanceamento.

Serviços recuperam metadados e verificam contexto.

O player obtém informações sobre as representações disponíveis.

Segmentos começam a ser entregues por infraestrutura distribuída.

O player mede as condições.

A qualidade muda conforme necessário.

Eventos de reprodução são registrados.

O progresso é salvo.

Sistemas de recomendação observam o comportamento.

Enquanto isso, o próximo vídeo talvez já esteja sendo selecionado.

Ou seja:

PLAY
 ↓
rede
 ↓
metadados
 ↓
segurança
 ↓
streaming
 ↓
CDN
 ↓
telemetria
 ↓
analytics
 ↓
recommendation

Você vê apenas:

▶

Esse é o grande truque da engenharia.

Esconder uma quantidade absurda de complexidade atrás de uma interface simples.

---

36. O que um programador COBOL deveria aprender com tudo isso?

Não tente memorizar “a arquitetura do YouTube”.

Aprenda a reconhecer problemas.

Se existe pico de tráfego, pense em balanceamento e escalabilidade.

Se existe conteúdo repetidamente acessado, pense em cache.

Se trabalho pesado não precisa ser imediato, pense em processamento assíncrono.

Se uma máquina é insuficiente para todos os dados, pense em particionamento.

Se falha é inevitável, pense em replicação.

Se serviços dependem uns dos outros, pense em timeouts e circuit breakers.

Se ninguém sabe onde a lentidão nasceu, pense em observabilidade.

Se um sistema está aceitando mais trabalho do que consegue processar, pense em backpressure.

Se uma função secundária morreu, pense em graceful degradation.

Perceba o padrão.

Não estamos estudando produtos.

Estamos estudando classes de problemas arquitetônicos.

---

37. Passo a passo para estudar System Design sem enlouquecer

Aqui está minha única receita prática.

Comece construindo mentalmente um pequeno serviço de vídeo com upload, armazenamento e playback. Depois acrescente metadata. Em seguida coloque uma fila entre upload e transcoding. Adicione múltiplas resoluções. Acrescente cache e CDN. Depois pense em usuários e histórico. Quando os dados crescerem, introduza replicação e sharding. Só então adicione search e índices. Depois recomendação. Finalmente provoque falhas deliberadamente: derrube o banco, atrase a fila, mate o encoder, sobrecarregue o cache e pergunte o que acontece.

Essa sequência ensina mais do que decorar cinquenta diagramas prontos.

System Design começa a ficar interessante quando você pergunta:

“O que quebra se multiplicarmos isso por mil?”

Depois:

“E por mais mil?”

Depois:

“E se uma região inteira ficar indisponível?”

Nesse momento você começou a pensar como arquiteto.

---

38. A grande ironia: o hyperscale reencontrou problemas que o CPD conhecia

Quando tecnologias modernas falam em:

queues
scheduling
workload
authorization
replication
monitoring
transactions
batch processing
caching

um veterano de mainframe reconhece muitos problemas.

O mainframe não resolveu tudo da mesma maneira.

Nem poderia.

Mas há parentesco conceitual.

No z/OS temos nomes como:

JES2
WLM
RACF
CICS
Db2
MQ
SMF
RMF
Sysplex

No universo distribuído aparecem:

message brokers
orchestrators
IAM
microservices
distributed databases
telemetry
clusters
autoscaling

É perigoso criar equivalências diretas.

Mas é extremamente educativo enxergar a genealogia dos problemas.

Tecnologia muda.

Problemas humanos e computacionais têm mania de reaparecer usando camiseta nova.

---

39. Easter egg: Hermes provavelmente inventaria Kafka

Hermes era mensageiro.

Levava informações entre entidades.

Tinha múltiplos destinos.

Operava entre diferentes domínios.

Precisava ser rápido.

Transportava eventos importantes.

Portanto não é difícil imaginar uma reunião no Olimpo:

— Precisamos de um barramento distribuído de eventos.

Hermes:

— Já faço isso há 3 mil anos.

Zeus:

— Precisamos de partitions.

Hermes:

— Tenho rotas.

Atena:

— Precisamos de consumers independentes.

Hermes:

— Tenho templos.

Hades:

— Precisamos de dead-letter queue.

Hermes:

— Você praticamente administra uma.

Silêncio constrangedor.

---

40. O verdadeiro segredo do YouTube

Não existe uma única tecnologia mágica.

Existe uma composição cuidadosa de milhares de decisões.

Storage resolve um tipo de problema.

Cache resolve outro.

CDN resolve outro.

Queue resolve outro.

Database resolve outro.

Replication resolve outro.

Sharding resolve outro.

Search index resolve outro.

Machine Learning resolve outro.

Observability resolve outro.

Security tenta impedir que algum mortal curioso destrua tudo.

O desafio monumental está em fazer essas partes coexistirem.

Porque cada uma pode falhar.

Cada uma tem limites.

Cada uma possui custo.

Cada uma introduz novos modos de falha.

---

Epílogo — Hermes finalmente apertou PLAY

Depois de horas de explicação, o programador COBOL olhou novamente para o ícone do YouTube.

▶

Antes, ele via um botão.

Agora via:

DNS, edge, load balancing, storage, encoding, filas, shards, replicas, caches, CDN, APIs, serviços, índices, algoritmos, telemetria, segurança e milhões de decisões acontecendo em camadas.

Hermes terminou o café.

— Então — perguntou o programador — qual é a principal lição?

O mensageiro guardou as sandálias aladas.

— Nunca confunda simplicidade da interface com simplicidade da arquitetura.

No terminal 3270, alguém submeteu um JOB.

SUBMIT

A resposta apareceu.

O programador ficou alguns segundos olhando.

Depois sorriu.

Porque subitamente JES2 parecia um pouco menos antigo.

E o YouTube parecia um pouco menos alienígena.

Ambos, cada um em seu universo, estavam respondendo à mesma pergunta eterna da computação:

Como recebemos uma quantidade absurda de trabalho, organizamos, priorizamos, processamos, armazenamos, protegemos, monitoramos e entregamos resultados sem deixar o usuário perceber o caos existente nos bastidores?

Hermes levantou voo.

Na saída do CPD, porém, tentou abrir uma porta restrita.

O console respondeu:

ICH408I USER(HERMES) GROUP(OLYMPUS)
NAME(MESSENGER OF GODS)

ACCESS INTENT(READ)
ACCESS ALLOWED(NONE)

Do fundo da sala veio a voz do operador:

— Falei que precisava de autorização.

Hermes suspirou.

Zeus podia controlar os raios.

Poseidon podia controlar os mares.

Hades podia controlar o mundo dos mortos.

Mas no CPD...

quem mandava era o RACF. ☕🪽💻

10 ANIMES PARA QUEM SOBREVIVEU AO ABEND SOBRENATURAL DE ANOTHER

 

Bellacosa Mainframe e a lista dos anime com ligação ao sobrenatural

☕💣👁️ OPERADOR, O JOB DO DESTINO CONTINUA EXECUTANDO!

10 ANIMES PARA QUEM SOBREVIVEU AO ABEND SOBRENATURAL DE ANOTHER

Existem animes de terror.

Existem animes de mistério.

Existem animes que tentam assustar utilizando monstros, fantasmas ou demônios.

E existe Another.

Uma obra que conseguiu algo raro: transformar uma simples sala de aula em um ambiente onde cada passo parece um comando DELETE aguardando confirmação.

O verdadeiro horror de Another não está apenas nas mortes brutais ou nos eventos sobrenaturais. O que torna a experiência inesquecível é a sensação constante de que existe um erro oculto dentro do sistema. Algo está corrompido. Algo não deveria estar ali. E, mesmo assim, ninguém consegue identificar exatamente onde começou a falha.

É justamente por isso que encontrar animes semelhantes não significa procurar apenas histórias de terror. Significa procurar obras que compartilham o mesmo DNA narrativo: mistérios que se escondem atrás de rotinas aparentemente normais, personagens presos em ciclos de sofrimento, eventos sobrenaturais que funcionam como processos automáticos fora do controle humano e uma atmosfera de paranoia crescente.

Os animes desta lista foram escolhidos porque conseguem reproduzir aquela mesma sensação que o operador sente ao descobrir um registro fantasma em produção. Cada um apresenta uma anomalia diferente. Alguns utilizam maldições. Outros exploram linhas temporais quebradas, aldeias isoladas, cidades amaldiçoadas ou forças invisíveis manipulando o destino.

Todos possuem algo em comum:

Uma pergunta que ninguém consegue responder imediatamente.

Uma verdade escondida.

Uma investigação perigosa.

E um preço alto para quem tenta descobrir o que realmente está acontecendo.

Nesta seleção estão obras que marcaram gerações de fãs do horror psicológico, suspense sobrenatural e mistérios complexos. Algumas são famosas mundialmente. Outras permanecem como joias obscuras conhecidas apenas pelos operadores mais experientes do universo otaku.

Prepare os logs.

Revise os dumps.

Ative o monitoramento.

Porque os próximos dez sistemas apresentam falhas muito mais perigosas que a Classe 3-3 de Yomiyama.

---

1. Higurashi no Naku Koro ni

☕💣 A Vila Onde o Destino Reinicia o Job Todos os Dias

Título Original: Higurashi no Naku Koro ni
Lançamento: 2006

Sinopse

Keiichi Maebara muda-se para uma pequena vila chamada Hinamizawa e rapidamente faz amigos.

Tudo parece perfeito.

Até que assassinatos e desaparecimentos começam a ocorrer.

Personagens

• Keiichi Maebara

• Rena Ryugu

• Mion Sonozaki

• Shion Sonozaki

• Rika Furude

Por que assistir?

É provavelmente o anime mais próximo de Another em atmosfera, paranoia e mistério.

---

2. Shiki

☕💣 O Vampiro é Apenas o Sintoma

Título Original: Shiki

Lançamento: 2010

Sinopse

Uma pequena vila japonesa começa a sofrer mortes misteriosas após a chegada de uma família estranha.

Personagens

• Toshio Ozaki

• Natsuno Yuuki

• Sunako Kirishiki

• Seishin Muroi

Diferencial

Transforma uma história de vampiros em uma reflexão brutal sobre humanidade.

---

3. Summertime Rendering

☕💣 O Sistema Reinicia Após Cada Falha Fatal

Título Original: Summer Time Rendering

Lançamento: 2022

Sinopse

Shinpei retorna à sua ilha natal para um funeral e descobre que uma conspiração sobrenatural ameaça toda a população.

Personagens

• Shinpei Ajiro

• Ushio Kofune

• Mio Kofune

• Hizuru Minakata

Diferencial

Mistura Another, Steins;Gate e horror cósmico.

---

4. Corpse Party

☕💣 O Dataset do Inferno Foi Restaurado

Título Original: Corpse Party: Tortured Souls

Lançamento: 2013

Sinopse

Um ritual escolar leva um grupo de estudantes para uma dimensão amaldiçoada.

Personagens

• Satoshi Mochida

• Naomi Nakashima

• Ayumi Shinozaki

• Yoshiki Kishinuma

Diferencial

Extremamente sombrio e perturbador.

---

5. Ghost Hunt

☕💣 A Equipe de Suporte Paranormal Entrou em Produção

Título Original: Ghost Hunt

Lançamento: 2006

Sinopse

Uma equipe especializada investiga fenômenos sobrenaturais em diversos locais assombrados.

Personagens

• Mai Taniyama

• Kazuya Shibuya

• Houshou Takigawa

• Ayako Matsuzaki

Diferencial

Mistério e investigação acima do terror explícito.

---

6. Tasogare Otome x Amnesia

☕💣 O Registro Excluído Continua Acessando o Sistema

Título Original: Tasogare Otome x Amnesia

Lançamento: 2012

Sinopse

Um estudante descobre o fantasma de uma garota que morreu décadas antes em sua escola.

Personagens

• Teiichi Niiya

• Yuuko Kanoe

• Kirie Kanoe

• Momoe Okonogi

Diferencial

Mistura romance, drama e horror sobrenatural.

---

7. Erased

☕💣 O Operador Voltou ao Backup do Passado

Título Original: Boku dake ga Inai Machi

Lançamento: 2016

Sinopse

Um homem retorna ao passado para impedir uma série de assassinatos.

Personagens

• Satoru Fujinuma

• Kayo Hinazuki

• Sachiko Fujinuma

Diferencial

Suspense psicológico extremamente bem construído.

---

8. Dark Gathering

☕💣 O Catálogo de Fantasmas Está Corrompido

Título Original: Dark Gathering

Lançamento: 2023

Sinopse

Uma garota com poderes espirituais caça entidades sobrenaturais extremamente perigosas.

Personagens

• Yayoi Houzuki

• Keitaro Gentoga

• Eiko Houzuki

Diferencial

Combina horror moderno com lendas japonesas.

---

9. Shinsekai Yori

☕💣 O Sistema Operacional da Humanidade Está Comprometido

Título Original: Shinsekai Yori

Lançamento: 2012

Sinopse

Mil anos no futuro, jovens descobrem os segredos obscuros da sociedade em que vivem.

Personagens

• Saki Watanabe

• Satoru Asahina

• Maria Akizuki

• Shun Aonuma

Diferencial

Um dos maiores mistérios da história dos animes.

---

10. Boogiepop wa Warawanai

☕💣 Existe um Processo Invisível Executando em Background

Título Original: Boogiepop wa Warawanai

Lançamento: 2019

Sinopse

Eventos sobrenaturais começam a afetar estudantes de uma escola aparentemente comum.

Personagens

• Boogiepop

• Touka Miyashita

• Nagi Kirima

• Suema Kazuko

Diferencial

Narrativa fragmentada e extremamente inteligente.

---

Veredito Final do Operador

Se Another fosse o sistema principal, estes dez animes seriam os subsistemas conectados à mesma rede sobrenatural.

Compatibilidade com fãs de Another

🥇 Higurashi no Naku Koro ni
🥈 Shiki
🥉 Summertime Rendering
🏅 Corpse Party
🏅 Ghost Hunt
🏅 Tasogare Otome x Amnesia
🏅 Erased
🏅 Dark Gathering
🏅 Shinsekai Yori
🏅 Boogiepop wa Warawanai

Todos compartilham aquilo que tornou Another inesquecível:

Uma verdade escondida. Um erro impossível de ignorar. E a certeza de que, quando o operador finalmente descobrir a causa do problema, talvez já seja tarde demais para salvar o sistema. ☕💣👁️📼

 

Bellacosa Mainframe JCL e seus datasets

JCL: Gerenciamento de Datasets de Saída no Mainframe

Se você já passou algum tempo no mainframe, sabe que o JCL (Job Control Language) é a espinha dorsal da execução de programas e da manipulação de dados. Uma das tarefas mais comuns é criar e controlar datasets de saída. Mas, se você não prestar atenção aos detalhes de DISP, UNIT, VOL e PATHOPTS, seu job pode falhar ou produzir resultados inesperados. Vamos destrinchar o assunto, passo a passo, no estilo Bellacosa Mainframe.

---

1️⃣ Nomeando e Criando Datasets

Datasets Permanentes

Para criar datasets permanentes em DASD (disco) ou fitas, usamos o parâmetro DSN para indicar o nome:

• Qualificado: PROD.DAILY.RLSREP → inclui HLQ (High-Level Qualifier).

• Não qualificado: MYDATA → nome simples de 1 a 8 caracteres.

• Geração (GDS): PROD.DAILY.RLSREP(+1) → cria uma nova geração sem sobrescrever a anterior.

Datasets Temporários

• Começam com &&, ex.: &&TEMP1

• São criados automaticamente pelo sistema se nenhum DSN for informado.

• Podem ser passados para outros steps usando DISP=(NEW,PASS).

---

2️⃣ Disposição do Dataset (DISP)

O parâmetro DISP controla o status e destino do dataset, e é crucial para evitar sobrescrita indesejada.

Tipo de dataset	Exemplo DISP	Significado
Novo dataset	DISP=(NEW,CATLG,DELETE)	Cria o dataset; mantém se sucesso; deleta se falha
Dataset existente	DISP=(OLD,KEEP,KEEP)	Abre exclusivo; mantém independentemente do resultado
Acrescentando dados	DISP=(MOD,KEEP,KEEP)	Acrescenta no final do dataset existente
Ignorado	DISP=DUMMY ou DSN=NULLFILE	Para steps que não precisam de saída real

⚠️ Atenção: +0 não cria dataset novo; +1 sim. E nunca confunda OLD com MOD — o primeiro sobrescreve, o segundo acrescenta.

---

3️⃣ Definindo o Local de Armazenamento (UNIT e VOL)

UNIT

Define o tipo de dispositivo ou grupo:

• SYSDA → disco genérico

• 3390 → dispositivo específico

• TAPE ou CART → fitas

Se você não especificar, o sistema pode usar defaults definidos pelo administrador.

VOL

Define o volume específico:

• VOL=SER=T44489 → fita específica

• Permite referback em steps subsequentes

• Se o volume não estiver disponível, o operador recebe uma mensagem solicitando ação

Exemplo de dataset em fita específica:

//OUTDD DD DSN=OUT.OFFSITE.DATA,
          DISP=(NEW,CATLG,DELETE),
          UNIT=CART,
          VOL=SER=T44489

---

4️⃣ Parâmetros de z/OS UNIX Files

Para arquivos UNIX no z/OS, usamos:

Parâmetro	Função
PATH	Caminho completo do arquivo
PATHOPTS	Tipo de acesso (read/write, exclusivo, criar)
PATHMODE	Permissões (leitura, escrita, execução para user/group/other)
PATHDISP	Ação após execução (KEEP, DELETE)

Exemplo:

//DD1 DD PATH='/u/ibmuser/stktake',
         PATHOPTS=(OWRONLY,OEXCL,OCREAT),
         PATHMODE=(SIRWXU,SIRGRP),
         PATHDISP=(KEEP,DELETE)

---

5️⃣ Erros Comuns e Como Evitar

Erro	Causa	Solução
IEF210I – Incorrect UNIT	UNIT inválido (DISK em vez de SYSDA)	Usar unidade válida: SYSDA
IEF253I – Duplicate Name on Volume	Tentativa de criar dataset que já existe no volume	Use outro nome ou +1 para nova geração
VOL não disponível	Volume específico não presente	Operador recebe mensagem; deve escolher ação
DISP incompleto	Esquecer subparâmetros	Sempre usar os 3 subparâmetros: (NEW,CATLG,DELETE)

---

6️⃣ Exemplo de Criação de Dataset

Dataset em disco genérico 3390

//TESTDD DD DSN=MY.TEST.DATA,
          DISP=(NEW,CATLG,DELETE),
          UNIT=3390,
          SPACE=(TRK,(10,5),RLSE)

Dataset em fita específica para envio offsite

//OUTDD DD DSN=OUT.OFFSITE.DATA,
          DISP=(NEW,CATLG,DELETE),
          UNIT=CART,
          VOL=SER=T44489

---

Resumo Final

• DSN → nome do dataset

• DISP → controla status e destino (NEW, OLD, MOD, KEEP, DELETE)

• UNIT → define dispositivo ou grupo

• VOL → fita ou volume específico

• SPACE/DCB → quantidade de espaço e atributos de formato

• z/OS UNIX → use PATH, PATHOPTS, PATHMODE, PATHDISP

Seguindo essas práticas, você garante que seus jobs criem datasets corretamente, evitem sobrescrita acidental, respeitem volumes específicos e funcionem tanto em discos quanto fitas.

---

💡 Dica Bellacosa:
Sempre revise DISP, UNIT e VOL antes de submeter o job. Uma simples confusão entre OLD, MOD e NEW ou entre SYSDA e 3390 pode gerar horas de troubleshooting.