✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe evoluindo da tela verde ao SQL no Db2
☕ Da Tela Verde ao SQL: A Jornada de um Profissional Mainframe
Muitos profissionais aprendem JCL, COBOL, SORT e CICS antes de entrar em contato com SQL.
Quando isso acontece, a primeira impressão costuma ser:
"Parece simples demais."
Mas o SQL possui uma característica única:
É simples para começar e complexo para dominar.
Você consegue escrever um SELECT em poucos minutos.
Pode levar anos para compreender completamente:
Access Paths
Indexes
Buffer Pools
Locking
Concurrency
RUNSTATS
REORG
Performance Tuning
Por isso cada objetivo dessa trilha merece ser explorado profundamente.
🎯 Objetivo 1: Compreender os Conceitos Básicos do SQL
O que realmente significa?
Entender SQL não é decorar comandos.
É compreender o Modelo Relacional.
Antes do SQL, sistemas trabalhavam diretamente com:
Arquivos sequenciais
VSAM KSDS
VSAM ESDS
VSAM RRDS
O programador precisava conhecer:
Layout físico
Chaves
Organização dos dados
Com SQL ocorre uma revolução:
Você informa:
SELECT NOME
FROM CLIENTES
O banco decide:
Como localizar
Qual índice usar
Quantas páginas acessar
Qual estratégia é mais eficiente
Essa separação entre lógica e armazenamento foi uma das maiores inovações da computação.
Conceitos fundamentais
Tabela
Equivalente moderno de um arquivo lógico.
Linha
Registro.
Coluna
Campo.
Chave Primária
Identifica unicamente cada registro.
Índice
Estrutura que acelera pesquisas.
Relacionamento
Conexão entre tabelas.
🎯 Objetivo 2: Explorar a Sintaxe e Estruturas do SQL
Aqui começa a alfabetização do profissional SQL.
Toda instrução possui uma estrutura lógica.
Exemplo:
SELECT
NOME,
CIDADE
FROM CLIENTES
WHERE CIDADE = 'SANTOS'
ORDER BY NOME;
Observe a sequência:
SELECT
FROM
WHERE
ORDER BY
A ordem de escrita é simples.
Mas o DB2 executa internamente de forma diferente.
Ele primeiro localiza os dados.
Depois filtra.
Depois ordena.
Compreender isso ajuda a entender performance.
Boas práticas desde o início
Evite:
SELECT *
FROM CLIENTES;
Prefira:
SELECT
ID_CLIENTE,
NOME,
CIDADE
FROM CLIENTES;
Essa pequena mudança já demonstra maturidade técnica.
🎯 Objetivo 3: Utilizar Comandos Básicos de SQL
Todo profissional precisa dominar quatro comandos fundamentais.
SELECT
Consulta informações.
SELECT *
FROM CLIENTES;
INSERT
Inclui registros.
INSERT INTO CLIENTES
(
ID,
NOME
)
VALUES
(
1,
'ANA'
);
UPDATE
Altera registros.
UPDATE CLIENTES
SET CIDADE = 'SANTOS'
WHERE ID = 1;
DELETE
Remove registros.
DELETE
FROM CLIENTES
WHERE ID = 1;
O erro que assombra os DBAs
Esquecer o WHERE.
Exemplo perigoso:
UPDATE CLIENTES
SET STATUS = 'ATIVO';
Resultado:
Toda a tabela será atualizada.
É um dos acidentes mais famosos da história dos bancos de dados.
🎯 Objetivo 4: Implementar Consultas Simples em SQL
Agora o aluno começa a transformar dados em informação.
Filtrando registros
SELECT
NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';
Filtrando intervalos
SELECT
NOME
FROM CLIENTES
WHERE SALARIO
BETWEEN 5000 AND 10000;
Utilizando listas
SELECT *
FROM CLIENTES
WHERE ESTADO IN
(
'SP',
'RJ',
'MG'
);
Pesquisando padrões
SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';
Retorna:
MARIA
MARCOS
MARCELO
Ordenando resultados
SELECT
NOME,
SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;
🎯 Objetivo 5: Criar Suas Primeiras Consultas em SQL
Aqui nasce o verdadeiro analista de dados.
Não basta consultar.
É necessário responder perguntas do negócio.
Quantos clientes existem?
SELECT COUNT(*)
FROM CLIENTES;
Qual o maior salário?
SELECT MAX(SALARIO)
FROM FUNCIONARIOS;
Qual a média salarial?
SELECT AVG(SALARIO)
FROM FUNCIONARIOS;
Quantos clientes existem por cidade?
SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;
Agora estamos produzindo inteligência.
Não apenas listando registros.
🚀 O Próximo Passo no DB2 13
Após dominar esses cinco objetivos, o profissional estará pronto para estudar temas mais avançados:
JOINs
SELECT
C.NOME,
P.NUMERO_PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;
Subqueries
SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
SELECT AVG(SALARIO)
FROM FUNCIONARIOS
);
Índices
CREATE INDEX IX_CLIENTE_NOME
ON CLIENTES
(
NOME
);
EXPLAIN
Análise do plano de acesso.
Ferramenta essencial para DBAs e desenvolvedores DB2.
SQL Embedded em COBOL
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.
Aqui começa o verdadeiro universo Mainframe.
☕ Conclusão Bellacosa Mainframe
Os cinco objetivos apresentados na imagem parecem simples à primeira vista.
Mas eles representam a fundação de praticamente todo o ecossistema corporativo moderno.
Cada PIX processado.
Cada compra no cartão.
Cada transferência bancária.
Cada consulta de seguro.
Cada reserva aérea.
Em algum momento passa por um comando SQL.
No DB2 13, aprender SQL significa muito mais do que aprender uma linguagem. Significa compreender como os dados fluem dentro de alguns dos maiores sistemas do planeta.
O primeiro passo é escrever:
SELECT *
FROM CLIENTES;
O passo seguinte é entender por que essa consulta funciona.
O passo que diferencia um especialista é compreender por que ela pode ser lenta, como o DB2 a executa, quais índices utiliza e como transformá-la em uma consulta capaz de processar bilhões de registros com eficiência.
E é exatamente nesse momento que o estudante deixa de apenas aprender SQL e começa a pensar como um verdadeiro profissional de Mainframe. ☕🚀💾
Descubra como profissionais de Mainframe evoluem da programação em JCL, COBOL, SORT e CICS para o domínio do SQL no DB2 13 for z/OS. Entenda modelo relacional, consultas SQL, índices, joins, subqueries, EXPLAIN, access paths e técnicas de otimização utilizadas nos maiores ambientes corporativos do mundo.
Aishiteruze Baby – Entre o afeto e a maturidade precoce
Um olhar Bellacosa sobre um anime que amadurece o coração antes da idade
📅 Ano de lançamento
2004 – transmitido originalmente entre abril e outubro no Japão, com 26 episódios.
✍️ Autor e origem
Baseado no mangá de Yoko Maki, serializado na revista Ribon da Shueisha entre 2002 e 2005. O estúdio responsável pela adaptação foi o TMS Entertainment, conhecido por obras como Detective Conan e Lupin III.
🧸 Sinopse
Kippei Katakura é um típico estudante colegial despreocupado, popular e mulherengo. Sua vida muda completamente quando é incumbido pela família de cuidar da pequena Yuzuyu Sakashita, uma garotinha de cinco anos que foi abandonada pela mãe.
Entre mamadeiras, lancheiras e lágrimas noturnas, o rapaz começa a descobrir o que realmente significa responsabilidade — e, mais do que isso, o valor do amor incondicional e da presença.
💫 Resumo Bellacosa
Aishiteruze Baby é um daqueles animes que fogem do ruído adolescente e abraçam o silêncio emocional. Ele não grita, não corre — apenas caminha suavemente pela construção de um vínculo improvável entre um jovem ainda em formação e uma criança que busca segurança em meio à ausência.
É sobre como o amor pode ser aprendido, e sobre o quanto crescemos quando cuidamos de alguém menor que nós — não em tamanho, mas em vulnerabilidade.
👨👧 Personagens principais
Kippei Katakura – O protagonista, que passa de playboy inconsequente a figura paternal exemplar.
Yuzuyu Sakashita – A criança que rouba o coração do espectador. Representa a pureza e a dor do abandono com uma inocência desarmante.
Kokoro Tokunaga – Colega de Kippei, introspectiva e emocionalmente madura; atua como um espelho da responsabilidade afetiva que o protagonista vai adquirindo.
Reiko Katakura – A irmã mais velha de Kippei, símbolo da rigidez e pragmatismo familiar, mas com profundos traços de carinho velado.
🪞 Crítica
Embora a animação de Aishiteruze Baby seja simples e o ritmo às vezes lento, a força da obra está no caráter emocional e humano. O enredo é cotidiano, mas o conteúdo é universal — trata de abandono, trauma infantil, amadurecimento e empatia.
É um slice of life que não precisa de poderes ou combates, apenas da rotina de preparar o bentô e consolar uma criança.
A crítica especializada na época o classificou como “um drama familiar delicado”, e muitos o colocam como precursor da onda de animes de afetividade emocional que mais tarde seriam explorados em Usagi Drop e Barakamon.
🧭 Dicas e comentários Bellacosa
Assista com calma: é uma obra que recompensa o silêncio e a paciência.
Evite comparar com dramas mais recentes — a estética e ritmo de 2004 são diferentes, mas o sentimento é atemporal.
Repare nos detalhes de Yuzuyu: seus gestos e falas curtas revelam muito mais do que parece.
Ideal para quem gosta de histórias de crescimento emocional sem melodrama forçado.
🧩 Curiosidades
O mangá teve um final ligeiramente mais desenvolvido que o anime, mostrando a vida escolar posterior de Yuzuyu.
O nome “Aishiteruze Baby” pode ser traduzido como “Eu te amo, bebê”, uma expressão carinhosa, mas que ganha duplo sentido — é tanto uma fala de afeto quanto um grito de amadurecimento.
Apesar de ser publicado em uma revista shōjo, a obra conquistou muitos leitores adultos pela abordagem realista sobre negligência infantil.
No Japão, educadores chegaram a usar trechos do anime em seminários sobre empatia e cuidado com crianças.
🌸 Repercussão
Na época, Aishiteruze Baby teve audiência modesta, mas conquistou um público fiel. Fora do Japão, especialmente entre fãs de animes sentimentais, é considerado um clássico esquecido.
Em comunidades online, é comum vê-lo citado ao lado de Clannad, Usagi Drop e Sweetness & Lightning como um dos retratos mais puros da paternidade não biológica.
Hoje, com a revalorização dos animes sobre laços humanos e responsabilidade emocional, sua relevância só cresce.
☕ Conclusão Bellacosa
Aishiteruze Baby é um lembrete de que crescer não é deixar de brincar — é aprender a proteger quem ainda precisa brincar.
Ele mostra que o amor pode vir de lugares improváveis, e que às vezes, cuidar de alguém é a forma mais profunda de se encontrar.
💭 “Entre o barulho do mundo e o choro de uma criança, Kippei escolheu ouvir o segundo — e ali aprendeu o que é ser humano.”
Bellacosa Mainframe concorrencia e questoes de dados quem é relevante
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🗄️ ALAN TURING E O Db2 DOS AGENTES — QUANDO DUAS IAs ESTÃO CERTAS EM REALIDADES DIFERENTES
Db2, agentes de IA, COBOL, SQL, ACID, transações, isolamento, locks, MVCC, dirty read, non-repeatable read, phantom read, lost update, optimistic concurrency, timestamps, versionamento, commit, rollback, contexto, temporalidade, proveniência, RAG — e o dia em que Alan Turing descobriu que uma inteligência artificial pode estar absolutamente certa sobre uma realidade que deixou de existir três segundos atrás.
Quanto tempo uma observação continua válida para esta decisão?
Isso é tão importante quanto o timeout discutido no CICS dos Agentes.
⚛️ CAPÍTULO 6 — ACID ENTRA NA SALA
Quando falamos de bancos transacionais, encontramos a famosa sigla:
ACID
Ela representa quatro propriedades conceituais:
A — Atomicity
C — Consistency
I — Isolation
D — Durability
Vamos traduzi-las para nosso pequeno robô.
⚛️ CAPÍTULO 7 — ATOMICIDADE: TUDO OU NADA
Imagine transferência:
Conta A: -100
Conta B: +100
Não queremos:
Conta A: -100
Conta B: ERROR
A unidade lógica precisa ser tratada de forma coerente.
Ou todas as alterações da unidade de trabalho são confirmadas, ou as alterações não confirmadas precisam ser revertidas conforme a transação e os recursos envolvidos.
Conceitualmente:
BEGIN
DEBIT A
CREDIT B
COMMIT
Se ocorrer problema:
ROLLBACK
Nosso agente precisa entender que ações relacionadas não podem ser tratadas como frases independentes de uma conversa.
🧭 CAPÍTULO 8 — CONSISTÊNCIA: NÃO QUEBRE AS REGRAS DO UNIVERSO
Consistência significa que as operações devem respeitar as regras e invariantes estabelecidas pelo sistema.
Por exemplo:
STOCK >= 0
ou:
ORDER must reference valid CUSTOMER
ou regras implementadas em aplicações, constraints, triggers e outros mecanismos.
O agente pode dizer:
Parece razoável.
Db2 responde:
Não perguntei se parece razoável.
😂
O sistema possui regras.
Inteligência probabilística não substitui integridade transacional.
🧱 CAPÍTULO 9 — ISOLAMENTO: AQUI COMEÇA A DIVERSÃO
Agora chegamos ao ponto central.
Imagine duas transações:
TX-A
TX-B
executando simultaneamente.
Queremos controlar o quanto uma transação pode perceber dos efeitos da outra enquanto ambas estão em andamento.
Isso é parte do problema de:
ISOLATION.
Sem isolamento adequado, concorrência pode produzir resultados surpreendentes.
E agentes multiplicam esse problema porque podemos ter:
10 agentes
100 agentes
1.000 agentes
tomando decisões simultaneamente.
💾 CAPÍTULO 10 — DURABILIDADE: COMMIT NÃO É PROMESSA DE BAR
Quando uma transação é confirmada com sucesso, esperamos que seu resultado persistente sobreviva conforme as garantias oferecidas pelo sistema.
Ou seja:
COMMIT
não deveria significar:
Acho que gravei.
Significa que a alteração alcançou o ponto de confirmação definido pelo sistema transacional.
Para agentes corporativos isso importa muito.
O agente precisa diferenciar:
PLANNED
de:
EXECUTED
e:
COMMITTED.
São estados diferentes.
👻 CAPÍTULO 11 — DIRTY READ: O FANTASMA QUE AINDA PODE DESAPARECER
Imagine:
TX-A:
UPDATE ACCOUNT
SET BALANCE = 2000
Mas ainda não houve commit.
Outra transação consegue observar essa alteração sob condições que permitam leitura não confirmada.
Depois A faz:
ROLLBACK.
A informação que B viu desapareceu.
B tomou decisão sobre algo que nunca se tornou estado confirmado.
É a ideia de:
DIRTY READ.
Para um agente, isso pode ser especialmente perigoso.
Ele pode gerar uma explicação brilhante baseada em uma alteração que será desfeita segundos depois.
🔁 CAPÍTULO 12 — NON-REPEATABLE READ: EU JURO QUE ERA 10.000
Agente A lê:
BALANCE = 10000
Agente B altera:
BALANCE = 2000
COMMIT
A lê novamente:
BALANCE = 2000
A mesma consulta lógica produziu valores diferentes durante a execução da atividade.
O pequeno robô olha para Turing:
— Professor, o banco mentiu para mim!
— Não.
— Mas mudou!
— Exatamente.
O mundo mudou.
Essa é uma distinção filosófica e técnica importante:
Mudança não é inconsistência.
Às vezes o sistema está funcionando perfeitamente.
A realidade simplesmente evoluiu.
👥 CAPÍTULO 13 — PHANTOM READ: APARECEU OUTRO CLIENTE
Imagine:
SELECT COUNT(*)
FROM ORDERS
WHERE STATUS = 'PENDING';
Resultado:
10
Outra transação insere novo pedido pendente.
Você executa novamente.
11
Apareceu uma nova linha que satisfaz o predicado da consulta.
O conjunto observado mudou.
É o tipo de fenômeno associado ao famoso:
PHANTOM.
Para agentes que fazem análises sobre conjuntos de dados, isso importa bastante.
O agente pode perguntar:
Quantas solicitações aguardam aprovação?
A resposta pode envelhecer antes de terminar a frase.
💥 CAPÍTULO 14 — LOST UPDATE: DOIS AGENTES ESTAVAM CERTOS
Temos:
STOCK = 10
Agent-A lê:
10
Agent-B lê:
10.
A decide vender 3.
Calcula:
10 - 3 = 7
B decide vender 4.
Calcula:
10 - 4 = 6.
A grava:
7
B grava:
6.
A atualização de A pode ser efetivamente perdida dependendo da forma como a aplicação implementa a concorrência.
O valor correto deveria refletir ambas as operações:
3.
Dois agentes.
Duas contas matematicamente corretas.
Resultado corporativo errado.
Esse é um dos melhores exemplos de por que:
INTELIGÊNCIA NÃO RESOLVE CONCORRÊNCIA.
🔒 CAPÍTULO 15 — LOCKS: RESERVANDO UM PEDAÇO DA REALIDADE
Uma abordagem tradicional para coordenar concorrência utiliza locks.
Simplificando:
AGENT-A
LOCK ROW
Agora B precisa esperar dependendo da operação, isolamento e mecanismos envolvidos.
A altera.
UPDATE
COMMIT
Lock liberado.
B continua.
Isso pode proteger consistência.
Mas lembra do CICS dos Agentes?
Locks possuem custo.
Se o agente fizer:
LOCK CUSTOMER
CALL LLM
SEARCH WEB
READ 50 PDFs
ASK HUMAN
WAIT 20 MINUTES
o DBA provavelmente surgirá atrás dele segurando um manual do Db2 como arma contundente.
☠️ CAPÍTULO 16 — NÃO PENSE SEGURANDO O LOCK
Nossa regra retorna:
NÃO DEIXE O LLM PENSAR SEGURANDO LOCKS DESNECESSÁRIOS.
Uma arquitetura possível:
READ
↓
CAPTURE VERSION
↓
RELEASE TRANSACTIONAL RESOURCES
↓
THINK
↓
REVALIDATE
↓
SHORT UPDATE TRANSACTION
↓
COMMIT
Mas agora aparece uma pergunta:
Como sabemos se o dado mudou enquanto o agente pensava?
Excelente.
Entramos no próximo monstro.
🔢 CAPÍTULO 17 — VERSIONAMENTO
Imagine tabela conceitual:
CUSTOMER
────────────────────────
ID 12345
BALANCE 10000
VERSION 17
O agente lê:
VERSION = 17.
Vai pensar.
Enquanto isso outra transação altera o registro.
Agora:
VERSION = 18.
Nosso agente retorna e tenta atualizar.
Em vez de simplesmente:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000
WHERE CUSTOMER_ID = 12345;
podemos usar uma estratégia de concorrência otimista:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000,
VERSION = VERSION + 1
WHERE CUSTOMER_ID = 12345
AND VERSION = 17;
Se:
ROWS UPDATED = 1
ótimo.
Se:
ROWS UPDATED = 0
alguma coisa mudou.
Pare.
Releia.
Reavalie.
optimistic CAPÍTULO 18 — OPTIMISTIC CONCURRENCY
O nome vem da ideia:
Provavelmente ninguém vai alterar isto enquanto estou trabalhando.
Em vez de manter um lock durante todo o raciocínio, registramos a versão observada.
Depois verificamos se ainda é a mesma.
Fluxo:
READ VERSION 17
↓
THINK
↓
CHECK VERSION
↓
┌───────┐
│ │
17 18
│ │
▼ ▼
UPDATE STALE
RELOAD
Isso combina muito bem com agentes.
Por quê?
Porque raciocínio de IA pode levar tempo e envolver recursos externos.
Não queremos manter uma transação aberta durante todo esse período.
🥖 CAPÍTULO 19 — O PÃO DE QUEIJO DA CONCORRÊNCIA
Turing coloca um pão de queijo sobre a mesa.
Diz ao Agent-A:
— Quantos existem?
— Um.
Agent-A vira para consultar o LLM sobre a composição nutricional do pão de queijo.
Agent-B chega.
Come o pão de queijo.
Agent-A volta.
— Decidi com 98,7% de confiança que devo comer o pão de queijo.
Turing aponta para o prato vazio.
Agent-A:
ERROR:
RESOURCE NOT FOUND
😂
Essa é concorrência otimista explicada no café.
Você não precisa segurar o pão durante quinze minutos.
Mas antes de mordê-lo:
VERIFIQUE SE ELE AINDA EXISTE.
📸 CAPÍTULO 20 — SNAPSHOT: UMA FOTOGRAFIA DA REALIDADE
Às vezes queremos que uma operação trabalhe sobre uma visão consistente dos dados.
Conceitualmente, podemos imaginar:
SNAPSHOT @ 10:00:00
O agente analisa aquela visão.
Mesmo que o mundo continue mudando, sabemos:
Esta análise corresponde à realidade observada naquele ponto ou contexto transacional.
Isso é extremamente útil.
Mas exige honestidade.
O resultado deveria dizer algo como:
ANALYSIS-AS-OF:
2026-09-27T10:00:00
e não:
CURRENT STATE.
Se os dados eram de dez minutos atrás, não chame de “agora”.
🕰️ CAPÍTULO 21 — “AS OF” PODE SER TÃO IMPORTANTE QUANTO O VALOR
Quão velho este dado pode estar antes de deixar de ser aceitável?
📊 CAPÍTULO 33 — O PAINEL DO Db2 DOS AGENTES
Imagine nosso painel operacional:
RUN-ID......... A004821
AGENT.......... CREDIT-ANALYSIS
DATA SOURCES
────────────────────────────────────────
CUSTOMER VERSION 882 AGE 0.4s
BALANCE VERSION 991 AGE 0.1s
CRM VERSION 441 AGE 2m
CREDIT-RULES VERSION 42 AGE 3d
RAG-DOC VERSION 17 AGE 4h
DECISION AGE.................. 2.8s
STALE SOURCES................. 0
OPEN TRANSACTION.............. NO
LOCKS HELD.................... 0
REVALIDATION REQUIRED......... YES
Agora estamos falando.
O operador consegue enxergar não apenas:
O QUE O AGENTE ESTÁ FAZENDO?
mas:
QUAL REALIDADE ELE ESTÁ VENDO?
🧰 CAPÍTULO 34 — CHECKLIST PARA AGENTES QUE TOMAM DECISÕES SOBRE DADOS
Antes de colocar um agente corporativo em produção, pergunte:
1. Qual é a fonte oficial?
Db2?
API?
RAG?
cache?
2. O dado possui timestamp?
Saiba quando foi observado.
3. Existe versão?
Use versionamento quando necessário.
4. Qual é o freshness budget?
Defina tolerância.
5. O agente mantém transação aberta enquanto pensa?
Evite.
6. Existem locks?
Minimize duração.
7. Pode haver concorrência?
Presuma que sim.
8. Existe optimistic concurrency?
Considere version checking.
9. A ação precisa ser revalidada?
Para ações críticas, quase certamente.
10. O RAG conhece validade documental?
Não use apenas similaridade.
11. Existe proveniência?
Registre origem.
12. Podemos reconstruir a decisão?
Associe dados, versões e RUN-ID.
13. O humano pode demorar para aprovar?
Revalide depois da aprovação.
14. O cache é permitido?
Defina TTL de acordo com semântica.
15. O resultado informa “as of”?
Quando relevante, deveria.
🥚 EASTER EGG — O AGENTE QUE ESTAVA 100% CERTO
02:14 da madrugada.
Telefone toca.
— Produção.
O operador atende.
— Temos problema.
— Qual?
— A IA aprovou uma operação que deveria ter recusado.
Abrem o trace.
RUN-ID A008817
Modelo respondeu corretamente.
Prompt correto.
Regra correta.
RACF correto.
Nenhuma hallucination.
Turing chega carregando café.
— Mostre os dados.
CUSTOMER_STATUS = ACTIVE
— Quando foram lidos?
Silêncio.
Procuram.
CACHE READ:
01:43:02
Turing olha o relógio.
02:14.
Consulta Db2:
CUSTOMER_STATUS = BLOCKED
UPDATE TIME = 01:44:11
O agente estava usando uma informação de 31 minutos atrás.
O jovem programador diz:
— Então a IA errou.
Turing responde:
— Não.
Aponta para o cache.
— Nós entregamos o passado e perguntamos sobre o presente.
Silêncio.
No fundo do CPD, o DBA sorri.
Finalmente não era culpa do banco.
🧬 CAPÍTULO 35 — NOSSO MAINFRAME DOS AGENTES ESTÁ FICANDO INTERESSANTE
Agora nossa arquitetura conceitual possui:
RACF
↓
QUEM PODE?
PF3
↓
POSSO PARAR?
SDSF
↓
O QUE ESTÁ FAZENDO?
MAXCC
↓
FUNCIONOU?
WLM
↓
QUEM RECEBE RECURSOS?
JES2
↓
QUEM COMEÇA E QUANDO?
CICS
↓
QUANTO TEMPO O HUMANO PODE ESPERAR?
E agora:
Db2
↓
QUAL REALIDADE O AGENTE ESTÁ VENDO?
Isso muda tudo.
🏰 CAPÍTULO 36 — O SISTEMA OPERACIONAL CONCEITUAL DOS AGENTES
SELECT
VALUE,
VERSION,
TIMESTAMP
FROM
REALITY
WHERE
NOW = NOW;
O programador observa.
— Professor...
— Sim?
— Essa tabela não existe.
Turing sorri.
— Ainda.
No fundo do CPD, o DBA grita:
— E NEM INVENTA DE CRIAR EM PRODUÇÃO!
O pequeno robô fecha o terminal.
COMMIT;
E todos foram tomar café.
Porque no mainframe, no Db2 e no mundo dos agentes, existe uma verdade que sobrevive a qualquer geração tecnológica:
Uma decisão só é tão confiável quanto os dados, o contexto e o instante da realidade sobre os quais ela foi construída.
READY
☕ 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Parágrafos curtos: 2–5 linhas cada (evita cansaço visual).
Diálogo em linhas separadas: como no formato japonês:
“Você voltou, não foi?”
“Voltei. Mas o mundo parece... diferente.”
Sem longas descrições seguidas: intercale narração com ação ou fala.
Uso moderado de itálicos e negrito (para ênfase, não para estilo).
Títulos de capítulos numerados:
“Capítulo 07 – Entre as Cerejeiras e os Deuses Adormecidos”
📅 4. Ritmo de Publicação
Frequência
Ideal para
Vantagem
Diário (curto)
Slice of life, romance, humor
Fideliza o leitor rapidamente.
2–3x por semana
Aventura, isekai, fantasia
Dá tempo para revisão e cliffhangers.
Semanal
Tramas densas, filosóficas ou com arte ilustrada
Permite qualidade e planejamento.
⚖️ Regularidade > quantidade.
O público japonês valoriza constância e respeito ao cronograma quase como uma forma de contrato moral com o leitor.
🧪 5. Exemplo de Estrutura Ideal (2.000 palavras)
Seção
Conteúdo
Duração aproximada
1. Abertura Atmosférica
150 palavras
1 parágrafo poético ou sensorial
2. Situação e diálogo inicial
400 palavras
Introduz o tema do capítulo
3. Ação ou dilema principal
800 palavras
Desenvolvimento central
4. Reflexão ou flashback
300 palavras
Emoção e contexto
5. Gancho ou frase final
100 palavras
Fechamento + suspense leve
🌸 6. O Ritmo Japonês de Leitura: o “Ma”
No Japão, as webnovels são lidas:
no trem, durante o almoço, ou antes de dormir;
em smartphones, com rolagem vertical;
em blocos curtos, como quem aprecia goles de chá, não copos inteiros.
👉 Por isso, capítulos de 1.500 a 2.000 palavras são considerados “perfeitos”:
curtos o bastante para o ritmo moderno, longos o bastante para emocionar.
🍵 Dica Bellacosa Final
“Em cada capítulo, escreva um instante — não uma saga.
O leitor deve fechar os olhos no fim e pensar: ‘quero mais um gole dessa história.’”
Uma Web Novel (Webu Noberu) é um romance publicado diretamente na internet, geralmente em capítulos curtos e atualizados periodicamente pelo próprio autor. No Japão, esse formato ganhou enorme popularidade no início dos anos 2000 com plataformas como Shōsetsuka ni Narō ("Vamos nos Tornar Romancistas"), permitindo que qualquer pessoa publicasse suas histórias gratuitamente e interagisse com os leitores por meio de comentários e avaliações.
Diferentemente de uma Light Novel, que passa por revisão editorial, possui ilustrações profissionais e é publicada por uma editora, a Web Novel costuma ser a versão original da obra. Muitos autores começam escrevendo por hobby e, quando suas histórias conquistam milhares de leitores, acabam sendo contratados por editoras para transformar o texto em uma Light Novel. Posteriormente, essas obras podem receber adaptações para mangás, animes e até jogos eletrônicos.
Grande parte dos sucessos modernos do gênero isekai nasceu dessa forma. Títulos como Overlord, Re:Zero, Mushoku Tensei, That Time I Got Reincarnated as a Slime, The Rising of the Shield Hero e Kumo desu ga, Nani ka? iniciaram sua trajetória como Web Novels antes de se tornarem fenômenos internacionais.
Esse modelo revolucionou o mercado editorial japonês ao democratizar a publicação de histórias, aproximando autores e leitores. Hoje, as Web Novels são consideradas um dos principais celeiros de novas ideias para a indústria de animes, mangás e light novels, influenciando diretamente a cultura pop japonesa contemporânea.
✍️ Prefacio
Uma webnovel é uma história publicada diretamente na internet, geralmente em capítulos curtos e frequentes, em portais como Shōsetsuka ni Narō, Kakuyomu ou Syosetu.
Ela é o berço de obras famosas como:
Re:Zero (Tappei Nagatsuki)
Overlord (Kugane Maruyama)
That Time I Got Reincarnated as a Slime
Mushoku Tensei
💡 Dica: Webnovels priorizam a regularidade e o vínculo com o leitor, mais do que o perfeccionismo literário. Pense em capítulos vivos, orgânicos, que evoluem junto com o público.
✍️ 2. Como Começar a Escrever Sua Webnovel
🧩 Estrutura Base
Conceito central: o que a torna única? (um isekai? slow life? fantasia urbana?)
Tom narrativo: poético, leve, cômico, sombrio ou filosófico?
Protagonista: crie alguém com um desejo forte e uma fraqueza humana.
Mundo: crie regras, mitos e detalhes culturais que soem “vivos”.
Pacing: capítulos curtos, 1.000 a 3.000 palavras, com ganchos no final.
🍃 Exemplo de Estrutura de Capítulo
Capítulo 1 – O Despertar no Vale dos Ecos
- Abertura com estranhamento (o leitor precisa sentir o novo mundo)- Flash de memória do protagonista (conexão emocional)- Pequeno conflito introdutório- Gancho final (“Ele não imaginava que aquela voz não era humana…”)
🎨 3. Estilo Japonês: Como Capturar o Espírito
As webnovels japonesas têm uma linguagem simples, mas com alma — algo entre o haiku e o slice of life.
✨ Técnicas inspiradas no estilo japonês:
Mono no Aware: a beleza na efemeridade.
Shōnen no Kokoro: a pureza do ideal e da superação.
Ma: o silêncio intencional entre eventos — o tempo de respirar.
Itadakimasu narrativo: a gratidão por cada pequeno momento.
🖋️ Dica Bellacosa:
“Não escreva o que o leitor deve sentir. Descreva o vento, o chá quente e o olhar do personagem — o leitor sentirá por si mesmo.”
🌐 4. Onde Publicar e Divulgar
🇯🇵 Plataformas Japonesas (para quem quer alcançar o público oriental)
Shōsetsuka ni Narō (小説家になろう) – o mais famoso, com ranking por gênero.
Kakuyomu – da Kadokawa, mais visual e moderno.
(Você pode publicar em português e usar tradução automática depois, ou escrever direto em inglês se quiser alcance internacional.)
🌍 Plataformas Globais
RoyalRoad (inglês, muito usado para fantasia e isekai)
ScribbleHub (comunidade calorosa, ideal para iniciantes)
Wattpad (ainda tem boa base de leitores no Brasil)
Tapas e Webnovel.com (ótimos para monetização e público de anime/webtoon)
📣 5. Como Divulgar Sua Webnovel
Crie um título que evoque curiosidade e estética japonesa
Ex: “No Caminho das Cem Luas: O Monge que Esqueceu Seu Nome”
Publique em dias fixos (consistência é o segredo).
Interaja com os leitores nos comentários.
Crie um banner ou capa estilo light novel.
Use redes sociais de nicho:
Reddit (r/LightNovels, r/WebNovels)
Discords de autores independentes
Twitter/X e Threads com hashtags: #webnovel #isekai #lightnovel
💬 Dica: transforme seus capítulos em áudio (podcast curto) ou vídeo narrativo no YouTube com música ambiente japonesa.
O formato híbrido (texto + voz + arte) é uma tendência poderosa.
💰 6. Monetização e Reconhecimento
Kofi / Patreon: para apoiar o autor por capítulo.
Tapas / Webnovel.com: monetização direta.
Publicação física: após 100 capítulos, há chance de editoras pequenas se interessarem.
Adaptação em mangá: se houver ilustrações consistentes, é o próximo passo natural.
🔮 7. O Espírito da Escrita Bellacosa
“Escrever uma webnovel é como servir chá num templo vazio — você escreve para o silêncio, e o silêncio responde com leitores que entenderam seu mundo.”
Use a escrita como meditação. Não corra.
Cada capítulo é uma folha de outono que o vento leva até o coração de alguém.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
