Dinkum : Quando um Programador COBOL Descobre que Administrar uma Ilha na Austrália Não É Muito Diferente de Administrar um Mainframe.

 

Bellacosa Mainframe apresenta dinkum

☕ Um Café no Bellacosa Mainframe

Dinkum sem Mistérios

Quando um Programador COBOL Descobre que Administrar uma Ilha na Austrália Não É Muito Diferente de Administrar um Mainframe... Tudo Funciona Melhor Quando Você Planeja, Automatiza e Faz Amigos

Existe uma curiosa tendência na indústria dos jogos.

Sempre que pensamos em simuladores de fazenda, imaginamos pequenas vilas europeias.

Campos verdes.

Celeiros vermelhos.

Florestas.

Montanhas.

Mas Dinkum resolveu perguntar algo diferente.

"E se toda essa experiência acontecesse no interior selvagem da Austrália?"

O resultado é um dos jogos mais carismáticos dos últimos anos.

Misturando Animal Crossing, Stardew Valley, Minecraft, Harvest Moon e um pouco de sobrevivência, Dinkum cria um mundo onde a maior aventura não é derrotar um dragão.

É construir uma comunidade inteira.

Para um programador COBOL isso lembra aqueles projetos que começam com apenas um terminal 3270.

Poucos usuários.

Poucos programas.

Poucos arquivos.

Anos depois...

O pequeno sistema tornou-se um ambiente corporativo completo.

É exatamente essa sensação que Dinkum proporciona.

Pegue sua caneca de café.

Hoje vamos conhecer uma das maiores surpresas dos jogos independentes.

---

A origem

Dinkum foi criado praticamente por uma única pessoa.

O desenvolvedor australiano James Bendon passou anos desenvolvendo o projeto sozinho, inspirado pelo estilo relaxante de jogos como Animal Crossing, mas desejando criar uma experiência mais aberta, com liberdade para construir cidades, explorar e sobreviver. O jogo entrou em Acesso Antecipado (Early Access) para PC em 14 de julho de 2022, sendo publicado pela KRAFTON. Desde então, recebe atualizações frequentes com novos conteúdos, animais, eventos e melhorias. (store.steampowered.com, )

---

O estúdio

Na verdade...

Não existia um grande estúdio.

Inicialmente era apenas James Bendon.

Isso torna o projeto ainda mais impressionante.

Criar sozinho:

• programação;

• design;

• mecânicas;

• economia;

• exploração;

• IA;

• agricultura;

• pesca.

É praticamente construir um ERP inteiro sem equipe.

---

O cenário

Ao contrário da maioria dos simuladores.

Dinkum acontece inspirado na natureza australiana.

Você encontra:

• eucaliptos;

• desertos;

• rios;

• praias;

• manguezais;

• savanas.

Tudo inspirado no Outback australiano.

---

A história

Você chega em uma ilha praticamente desabitada.

Poucas construções.

Poucos moradores.

Quase nenhuma infraestrutura.

Seu objetivo?

Transformar aquele lugar em uma cidade vibrante.

Sem pressão.

Sem cronômetros.

Sem urgência.

---

O verdadeiro objetivo

Curiosamente...

Também não existe.

Você decide.

Pode passar semanas:

• pescando;

• minerando;

• caçando;

• construindo;

• decorando;

• explorando.

É você quem define o ritmo.

---

A jogabilidade

O ciclo lembra um projeto DevOps muito bem organizado.

Explorar

↓

Coletar Recursos

↓

Construir

↓

Atrair Novos Moradores

↓

Expandir Cidade

↓

Automatizar Produção

↓

Melhorar Equipamentos

↓

Explorar Novamente

É simples.

Mas extremamente viciante.

---

Construção da cidade

Aqui mora uma das maiores diferenças.

Você não administra apenas uma fazenda.

Você administra uma cidade inteira.

Decide:

• localização das casas;

• comércio;

• ruas;

• jardins;

• pontes;

• iluminação.

É quase um SimCity relaxante.

---

Agricultura

Existe um excelente sistema agrícola.

Você cultiva:

• frutas;

• legumes;

• árvores;

• flores.

Tudo ajuda na economia.

---

Criação de animais

Você cria:

• galinhas;

• vombates;

• animais típicos inspirados na fauna australiana.

Cada um produz recursos diferentes.

---

Exploração

O mapa é enorme.

Você encontra:

• cavernas;

• desertos;

• ilhas;

• rios;

• minas;

• praias.

Sempre existe algo novo.

---

Mineração

Assim como Minecraft.

Você procura:

• cobre;

• ferro;

• estanho;

• ouro;

• opalas.

Quanto melhores os minérios...

Melhores as ferramentas.

---

Pesca

A pesca é extremamente divertida.

Existem dezenas de espécies.

Algumas aparecem apenas:

• em determinadas estações;

• durante chuva;

• em horários específicos.

---

Caça

Diferentemente de Stardew Valley.

Aqui existem animais perigosos.

Você enfrenta:

• crocodilos;

• tubarões;

• cassowaries;

• morcegos gigantes;

• outros animais inspirados na fauna australiana.

Isso adiciona bastante aventura.

---

O combate

Não é o foco principal.

Mas existe.

Você utiliza:

• lanças;

• espadas;

• martelos;

• bastões;

• armas de longo alcance.

É suficiente para tornar a exploração emocionante.

---

Craft

Grande parte do progresso depende da fabricação.

Você produz:

• móveis;

• ferramentas;

• veículos;

• cercas;

• pontes;

• máquinas.

Sempre existe algo novo para construir.

---

Veículos

Uma das partes mais legais.

Você pode utilizar:

• barcos;

• motocicletas;

• tratores;

• jet skis;

• helicópteros (em estágios avançados).

A mobilidade cresce conforme a cidade evolui.

---

Economia

Você vende praticamente tudo.

Peixes.

Insetos.

Frutas.

Minérios.

Madeira.

Com o dinheiro compra novos projetos para expandir a cidade.

---

Multiplayer

Até quatro jogadores podem compartilhar a mesma ilha.

Cada pessoa ajuda:

• construir;

• cultivar;

• explorar;

• minerar;

• decorar.

A cooperação funciona muito bem.

---

Curiosidades

• A inspiração na Austrália vai muito além da estética: animais, vegetação, clima e até algumas expressões refletem a cultura local.

• O jogo conquistou uma comunidade bastante ativa durante o Early Access, influenciando várias atualizações.

• Apesar das comparações com Animal Crossing, Dinkum incorpora exploração e sobrevivência de forma muito mais intensa.

---

Easter Eggs

A ilha está repleta de pequenos segredos.

Você encontra:

• ilhas escondidas;

• baús;

• objetos raros;

• eventos sazonais;

• NPCs especiais;

• referências discretas à cultura australiana.

Grande parte deles depende apenas da exploração.

---

Os riscos

O maior risco...

É pensar:

"Vou só reorganizar minha cidade."

Três horas depois...

Você está redesenhando todas as ruas.

Outro risco.

Sair sem comida.

Ou enfrentar crocodilos despreparado.

Eles não costumam negociar.

---

As vantagens

Dinkum oferece praticamente tudo.

✔ agricultura

✔ cidade

✔ exploração

✔ mineração

✔ pesca

✔ construção

✔ multiplayer

✔ combate leve

Sem:

❌ gacha

❌ loot boxes

❌ energia limitada

❌ microtransações invasivas

Você compra.

Instala.

Joga.

No seu ritmo.

---

A diversão

Cada dia parece diferente.

Hoje você:

Constrói uma ponte.

Amanhã.

Captura um inseto raro.

Depois.

Compra uma motocicleta.

Na semana seguinte.

Recebe um novo morador.

É impossível ficar parado.

---

O Caminho do Padawan

Se está começando...

Faça assim.

✔ construa ferramentas melhores;

✔ colete madeira diariamente;

✔ plante cedo;

✔ pesque sempre;

✔ economize dinheiro;

✔ organize sua cidade;

✔ visite minas regularmente;

✔ não enfrente crocodilos cedo demais.

No Bellacosa Mainframe existe uma regra parecida.

"Nunca reorganize toda a biblioteca PROD antes de entender quem usa cada programa."

---

Requisitos para PC

Mínimos:

• Windows 10 (64 bits)

• Intel Core i3 ou equivalente

• 8 GB de RAM

• NVIDIA GTX 760 / AMD Radeon equivalente

• Cerca de 2 GB de espaço livre

Recomendados:

• Intel Core i5 ou AMD Ryzen equivalente

• 16 GB de RAM

• NVIDIA GTX 1060 ou superior

Mesmo em máquinas intermediárias, Dinkum costuma apresentar excelente desempenho devido ao estilo gráfico estilizado e à boa otimização. (store.steampowered.com)

---

Tipo de instalação

É um jogo premium.

Compra única.

Instalação digital.

Atualmente está disponível para Windows (desktop) através da Steam, permanecendo em desenvolvimento contínuo durante o período de Early Access. (store.steampowered.com)

---

Custo

O preço oficial gira em torno de US$ 19,99, variando conforme promoções e a região da Steam. Em grandes liquidações, costuma receber descontos significativos.

---

Classificação

• Gênero: Simulação de vida, construção de cidade, agricultura, exploração, sobrevivência leve e RPG.

• Modo: Um jogador e cooperativo online (até quatro jogadores).

• Classificação indicativa: geralmente E10+ / Livre para maiores de 10 anos, dependendo da região, por conter violência leve e temas de fantasia.

---

Site oficial

Para acompanhar novidades e atualizações:

• Site oficial: https://www.dinkum.com/

• Página oficial na Steam: https://store.steampowered.com/app/1062520/Dinkum/

---

Curiosidade para Programadores COBOL

Se Stardew Valley lembra um sistema administrativo...

Outward parece um ambiente crítico de produção...

Core Keeper é um enorme banco de dados subterrâneo...

Então Dinkum representa perfeitamente a evolução de uma empresa.

Primeiro existe apenas uma pequena instalação.

Depois chegam os usuários.

Depois os serviços.

As integrações.

As estradas.

Os processos.

Os novos departamentos.

Quando você percebe...

A pequena vila tornou-se uma cidade inteira.

Assim também evoluem muitos ambientes IBM Z.

Um módulo por vez.

Um usuário por vez.

Uma melhoria por vez.

---

Conclusão

Dinkum mostra que grandes aventuras não precisam acontecer em reinos medievais ou galáxias distantes. Às vezes, basta uma ilha inspirada na Austrália, um punhado de ferramentas e liberdade para construir algo único.

Sob a perspectiva do Bellacosa Mainframe, ele lembra a implantação de um ambiente corporativo sólido: começa pequeno, cresce com planejamento, ganha novos serviços, novos usuários e novas possibilidades sem perder a estabilidade.

Sua maior mensagem é inspiradora.

Toda grande cidade começou como um pequeno terreno vazio.

Todo grande sistema começou como um único programa.

E toda grande aventura começa quando alguém decide dar o primeiro passo... mesmo sem saber exatamente onde a estrada termina.

 

Bellacosa Mainframe e o db2 connect e a banheira do tempo

☕ Um Café no Bellacosa Mainframe

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar SELECT

Ou: o jovem padawan COBOL entrou numa banheira instalada ao lado do datacenter, Igor derramou energético sobre o painel do DDF, o Db2 for z/OS abriu um DBAT e todos descobriram que conexão, sessão, transação e pacote não são quatro nomes para a mesma coisa

---

Prólogo — A banheira que apontava para o mainframe

Era sexta-feira, 23h47, no datacenter Bellacosa Mainframe.

O processamento noturno já havia começado, o café estava com gosto de óleo hidráulico e Igor acabara de instalar uma banheira de hidromassagem ao lado do rack de desenvolvimento.

— Para reduzir o estresse da equipe — explicou ele, segurando um cabo de rede molhado.

Sobre a borda da banheira havia um notebook executando uma aplicação Java. Na tela, uma mensagem nada relaxante:

ERRORCODE=-4499
SQLSTATE=08001

A aplicação precisava consultar uma tabela no Db2 for z/OS, mas não conseguia estabelecer a conexão.

O jovem padawan COBOL examinou o diagrama preso na parede:

Aplicação → API → TCP/IP → Db2

— Parece simples. Se o ping funciona, o banco deveria funcionar.

Nesse instante, Igor deixou cair uma lata de energético sobre o controlador da banheira. As luzes piscaram, o ventilador do mainframe mudou de tom e os três foram transportados para 1986.

Quando abriram os olhos, havia terminais verdes, cabelos volumosos, fitas cassete e um operador perguntando:

— Que negócio é esse de JDBC? É uma banda de rock?

Aquela viagem ensinaria uma lição importante:

Um diagrama simples pode apresentar a direção da estrada, mas não explica quem dirige o carro, qual idioma é falado na fronteira, quem verifica o passaporte e quem executa a SQL quando todos finalmente chegam ao Db2.

---

1. O que é Db2 Connect?

Db2 Connect é a família de recursos, drivers, clientes, componentes e direitos de uso que permite a aplicações distribuídas acessar bancos Db2 executados principalmente em plataformas host, como:

• Db2 for z/OS;

• Db2 for IBM i;

• Ambientes host compatíveis previstos pela solução;

• Outros servidores Db2 suportados, conforme produto, versão e driver.

Imagine uma aplicação Java executada em Linux que precisa consultar uma conta bancária armazenada no Db2 for z/OS.

Os dois sistemas vivem em mundos diferentes:

Aplicação Java
Linux
JDBC
Objetos Java
UTF-8
Containers

Do outro lado:

Db2 for z/OS
DDF
DBAT
Packages
RACF
WLM
Tablespaces

Db2 Connect participa da construção da ponte entre esses mundos.

Mas aqui começa a primeira armadilha: Db2 Connect não é apenas “um conversor de TCP/IP”.

TCP/IP é o transporte. Ele entrega bytes de um endereço a outro. Não conhece:

• SELECT;

• INSERT;

• Cursor;

• Package;

• COMMIT;

• ROLLBACK;

• SQLCODE;

• Result set;

• Unidade de trabalho.

O diálogo de banco utiliza principalmente o DRDA — Distributed Relational Database Architecture. A IBM define Db2 Connect como uma implementação da arquitetura DRDA para acesso distribuído a servidores Db2. IBM — Db2 Connect e DRDA

A arquitetura básica não é apenas:

Aplicação → TCP/IP → Db2

É mais próxima de:

Aplicação
    ↓
API
    ↓
Driver IBM
    ↓
DRDA
    ↓
TLS, quando configurado
    ↓
TCP/IP
    ↓
DDF
    ↓
DBAT
    ↓
Package e SQL
    ↓
Dados

O infográfico original mostra o portal da máquina do tempo. Nosso trabalho é abrir a tampa e descobrir quais peças fazem a viagem acontecer.

---

2. Aplicação, linguagem, API e driver não são a mesma coisa

O diagrama coloca no mesmo bloco:

• JDBC;

• ADO.NET;

• Python;

• SQL;

• ODBC;

• Db2 CLI;

• Perl;

• OLE DB;

• Embedded SQL;

• Ruby.

O problema é que esses elementos pertencem a categorias diferentes.

Categoria	Exemplos	O que representa
Linguagem	Java, Python, Ruby, Perl, PHP, COBOL	Linguagem em que o programa foi escrito
API	JDBC, ODBC, CLI, ADO.NET	Interface usada pelo programa para solicitar serviços do banco
Driver	IBM JCC, IBM ODBC/CLI Driver, IBM .NET Provider	Implementação que conversa efetivamente com o Db2
Linguagem de banco	SQL	Forma de consultar e alterar os dados
Técnica de programação	Embedded SQL, SQLJ	Forma de incorporar SQL ao programa

Dizer que Python, JDBC e SQL são todos “APIs” seria como dizer que COBOL, CICS e EXEC CICS READ são a mesma coisa.

Eles cooperam, mas exercem funções diferentes.

Exemplo Java

Connection conn = DriverManager.getConnection(
    "jdbc:db2://db2host.empresa.com:448/DBP1",
    usuario,
    senha
);

Neste exemplo:

• Java é a linguagem;

• JDBC é a API;

• O IBM Data Server Driver for JDBC and SQLJ implementa a comunicação;

• A URL descreve o destino;

• DRDA organiza o diálogo com o servidor;

• TCP/IP transporta as mensagens.

Exemplo Python

import ibm_db

conexao = ibm_db.connect(
    "DATABASE=DBP1;"
    "HOSTNAME=db2host.empresa.com;"
    "PORT=448;"
    "PROTOCOL=TCPIP;"
    "UID=APPUSER;"
    "PWD=senha;",
    "",
    ""
)

Python continua sendo a linguagem. O módulo e o driver cuidam do acesso. Depois, a aplicação pode executar SQL:

sql = """
    SELECT NOME, SALDO
      FROM CLIENTE
     WHERE ID_CLIENTE = 100
"""

stmt = ibm_db.exec_immediate(conexao, sql)

Exemplo COBOL

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

COBOL é a linguagem. SQL é a linguagem de banco. EXEC SQL delimita o comando embutido. O programa ainda precisa passar por pré-compilação, compilação, linkedição e preparação dos componentes Db2.

O jovem padawan deve guardar:

A API é o painel da banheira. O driver é a máquina escondida embaixo dela. DRDA é o manual de comunicação temporal. TCP/IP é o túnel. O Db2 é o destino.

---

3. O personagem que o infográfico esqueceu: o driver

O driver é um dos componentes mais importantes da arquitetura.

Ele:

• Implementa JDBC, ODBC, CLI ou .NET;

• Converte chamadas da aplicação em mensagens entendidas pelo servidor;

• Monta e interpreta o protocolo DRDA;

• Converte tipos de dados;

• Entrega result sets;

• Envia COMMIT e ROLLBACK;

• Controla propriedades de timeout;

• Participa de pooling e concentração de conexões;

• Pode colaborar com automatic client reroute;

• Pode colaborar com Sysplex workload balancing;

• Negocia capacidades com o servidor;

• Reporta SQLCODE, SQLSTATE e erros de comunicação.

A IBM distribui drivers e clientes diferentes para JDBC/SQLJ, ODBC/CLI, .NET, OLE DB e outras interfaces. IBM — Tipos de clientes e drivers

Por isso, ao atualizar um driver, não estamos apenas trocando “um arquivo .jar qualquer”.

A atualização pode alterar:

• Suporte a TLS;

• Conversão de timestamps;

• Tipos de dados suportados;

• Propriedades de failover;

• Comportamento de timeouts;

• Pacotes utilizados no servidor;

• Recursos de compatibilidade;

• Balanceamento no Sysplex.

Uma aplicação pode funcionar com determinada versão do driver em homologação e falhar em produção porque os pacotes correspondentes não foram preparados no Db2 for z/OS.

Easter egg número 1: se Igor disser “é só trocar o db2jcc4.jar escondido e ninguém perceberá”, esconda a senha do RACF e chame o change manager.

---

4. TCP/IP é a estrada; DRDA é o idioma

Durante a viagem de volta a 1986, o jovem padawan viu um telefone público.

Igor levantou o aparelho e começou a falar COBOL com a telefonista.

— MOVE TELEFONISTA TO WS-CONEXAO.

A telefonista desligou.

O telefone funcionava. A linha estava ativa. Mas ninguém falava o mesmo idioma.

Essa é a diferença entre TCP/IP e DRDA.

TCP/IP estabelece o transporte confiável e ordenado entre endpoints. DRDA define como clientes e servidores de bancos relacionais distribuem solicitações e respostas.

Uma forma didática de separar as camadas é:

SQL          → O que queremos fazer
API          → Como a aplicação solicita
Driver       → Quem implementa a solicitação
DRDA         → Como cliente e Db2 conversam
TLS          → Como o conteúdo pode ser protegido
TCP/IP       → Como os bytes viajam

Por isso, executar:

ping db2host

e receber resposta não prova que o Db2 funciona.

O ping pode confirmar que algum caminho IP está disponível, mas não confirma:

• Que a porta do DDF está aberta;

• Que o listener está ativo;

• Que o firewall permite o tráfego da aplicação;

• Que o TLS consegue negociar;

• Que o certificado é confiável;

• Que o usuário consegue autenticar;

• Que o location name está correto;

• Que os pacotes existem;

• Que o usuário possui autorização;

• Que a SQL pode ser executada.

É como chegar à cidade correta e concluir que sua reserva no hotel está garantida.

---

5. No z/OS, quem abre o portal é o DDF

Quando o destino é Db2 for z/OS, entra em cena o:

DDF — Distributed Data Facility

O DDF é o componente que permite ao Db2 for z/OS participar do processamento distribuído, recebendo e iniciando comunicações com sistemas remotos.

Para uma aplicação externa estabelecer uma conexão, o DDF precisa estar:

• Instalado e configurado;

• Ativo;

• Associado a portas TCP/IP;

• Publicado no endereço correto;

• Integrado à segurança;

• Preparado para o protocolo utilizado.

A IBM deixa claro que o subsistema Db2 for z/OS precisa ter o DDF habilitado para receber conexões JDBC por TCP/IP. IBM — JDBC acessando Db2 for z/OS

No diagnóstico, dois comandos são particularmente conhecidos:

-DISPLAY DDF DETAIL

e:

-DISPLAY LOCATION

Eles podem ajudar a verificar informações como:

• Estado do DDF;

• Location name;

• Endereços;

• Portas;

• Informações de comunicação;

• Características do ambiente distribuído.

Se o DDF estiver parado, a aplicação poderá enxergar o host, alcançar o z/OS e mesmo assim não falar com o Db2.

Easter egg número 2: no filme, a banheira precisava de uma combinação improvável de água, energia e bebida derramada. No datacenter, DDF não deve depender de Igor derramando energético no console.

---

6. DBAT: o funcionário que recebe o visitante

Depois que a conexão chega ao DDF, o trabalho precisa ser processado. Entra o:

DBAT — Database Access Thread

O DBAT é uma thread de acesso ao banco utilizada no processamento de solicitações distribuídas.

Imagine a recepção de um hotel:

• A conexão é o hóspede;

• DDF é a recepção;

• A autenticação verifica o documento;

• O DBAT é o funcionário que atende a solicitação;

• O package define determinados recursos e regras de execução;

• O Db2 acessa os dados.

Uma conexão lógica não significa necessariamente um DBAT permanentemente dedicado.

O Db2 for z/OS pode utilizar pooling de DBATs. Depois de uma unidade de trabalho, um DBAT elegível pode ser liberado para atender outra conexão. Isso reduz o consumo de recursos em ambientes com grandes quantidades de conexões remotas. IBM — Gerenciamento de DBATs

Também existem high-performance DBATs. Nesse caso, o DBAT permanece associado à conexão através das fronteiras de transação, reduzindo determinados custos de liberação e reassociação, mas mantendo recursos dedicados por mais tempo. IBM — Como DBATs processam conexões remotas

Portanto:

Conexão ≠ DBAT permanentemente ativo

Essa diferença torna-se crucial quando containers entram na história.

Suponha:

50 pods
× 100 conexões máximas
= 5.000 conexões potenciais

Agora o Kubernetes faz autoscaling:

200 pods
× 100 conexões
= 20.000 conexões potenciais

O desenvolvedor olha para uma configuração e pensa:

“Cem conexões é um número pequeno.”

O Db2 olha para o conjunto e vê vinte mil visitantes atravessando o portal temporal.

---

7. Conexão direta ou servidor Db2 Connect?

Nas arquiteturas antigas, era comum encontrar:

Aplicação
    ↓
Servidor Db2 Connect
    ↓
Db2 for z/OS

O servidor Db2 Connect funcionava como um ponto intermediário de conectividade.

Essa arquitetura ainda pode fazer sentido em situações específicas:

• Centralização de determinados componentes;

• Ambientes com requisitos legados;

• Federation;

• Monitores transacionais;

• Necessidades operacionais específicas;

• Administração concentrada.

Mas não é obrigatório colocar um gateway intermediário em todos os cenários.

Muitas aplicações modernas utilizam:

Aplicação + driver IBM
    ↓
DRDA/TCP/IP
    ↓
Db2 for z/OS

A própria IBM recomenda conexão direta por cliente ou driver em muitos ambientes, reduzindo a necessidade de uma máquina intermediária. IBM — Opções de conexão cliente-servidor

Conexão direta

Vantagens:

• Menos saltos de rede;

• Menor latência;

• Menos infraestrutura intermediária;

• Diagnóstico potencialmente mais simples;

• Recursos implementados diretamente pelo driver.

Cuidados:

• Controle de versões dos drivers;

• Distribuição de certificados;

• Configuração em múltiplos servidores;

• Licenciamento;

• Padronização entre equipes.

Gateway Db2 Connect

Vantagens possíveis:

• Ponto central de conectividade;

• Administração concentrada;

• Suporte a arquiteturas específicas;

• Menor dispersão de certas configurações.

Cuidados:

• Mais um salto;

• Mais um componente monitorado;

• Possível gargalo;

• Possível ponto único de falha;

• Maior cadeia de diagnóstico.

Um gateway não é automaticamente ruim. Conexão direta não é automaticamente melhor. A escolha deve nascer dos requisitos, não da nostalgia de um diagrama de 1998.

---

8. O que acontece durante um SELECT?

Considere:

SELECT NOME,
       LIMITE_CREDITO
  FROM CLIENTE
 WHERE CPF = ?

A aplicação Java executa algo aparentemente simples:

ResultSet rs = statement.executeQuery();

Por baixo dessa linha, a banheira do tempo entra em funcionamento:

1. A requisição da aplicação precisa de uma conexão;

2. A aplicação solicita essa conexão ao pool;

3. O pool entrega uma conexão existente ou cria outra;

4. JDBC recebe a solicitação;

5. O driver IBM converte os parâmetros;

6. O driver monta a conversa DRDA;

7. TLS pode proteger o tráfego;

8. TCP/IP transporta as mensagens;

9. DDF recebe a requisição no z/OS;

10. O usuário é autenticado;

11. A conexão é associada a um DBAT;

12. O Db2 identifica o package e o contexto;

13. As autorizações são verificadas;

14. A SQL é preparada ou localizada;

15. O access path é utilizado;

16. Os dados são lidos;

17. As linhas retornam por DRDA;

18. O driver converte os tipos;

19. JDBC entrega o ResultSet;

20. A aplicação consome os registros;

21. COMMIT ou ROLLBACK encerra a unidade de trabalho;

22. A conexão pode retornar ao pool.

Portanto, “tempo da query” pode significar coisas diferentes:

• Espera pelo pool;

• Abertura da conexão;

• Autenticação;

• Negociação TLS;

• Transporte de rede;

• Espera por DBAT;

• Espera por WLM;

• Prepare;

• Execução;

• Locks;

• Fetch das linhas;

• Conversão no driver;

• Processamento na aplicação.

Quando alguém disser “o Db2 demorou oito segundos”, primeiro descubra onde os oito segundos foram gastos.

---

9. Packages: o detalhe que aparece quando chega o -805

Uma conexão pode alcançar o host, atravessar a porta, autenticar o usuário e ainda assim falhar.

Um erro clássico é:

SQLCODE -805
SQLSTATE 51002

Ele normalmente indica que um package necessário não foi encontrado, não está disponível no contexto esperado ou não corresponde ao que está sendo solicitado.

Drivers JDBC e CLI utilizam packages preparados no servidor. A collection NULLID aparece frequentemente nesses ambientes.

A IBM disponibiliza, por exemplo, o utilitário DB2Binder para vincular packages utilizados pelo IBM Data Server Driver for JDBC and SQLJ no Db2 for z/OS. IBM — DB2Binder

É possível também trabalhar com collections diferentes e níveis distintos de APPLCOMPAT.

Exemplo conceitual:

NULLID
NULLID_V12R1M500
NULLID_V12R1M501

Cada collection pode representar uma combinação planejada de packages e compatibilidade.

Isso permite que uma aplicação nova utilize determinadas capacidades sem obrigar todas as aplicações antigas a avançarem imediatamente.

Dica de produção:

Antes de atualizar o driver, confirme quais packages serão necessários, quem realizará o bind, quais opções serão usadas e como será feito o rollback.

Atualizar o .jar e esquecer o servidor é uma maneira elegante de transformar uma melhoria técnica em incidente noturno.

---

10. COMMIT, ROLLBACK e a viagem que talvez já tenha acontecido

Considere uma transferência:

UPDATE CONTA
   SET SALDO = SALDO - 100
 WHERE CONTA_ID = 10;

UPDATE CONTA
   SET SALDO = SALDO + 100
 WHERE CONTA_ID = 20;

As duas operações precisam pertencer à mesma unidade de trabalho.

Em JDBC:

connection.setAutoCommit(false);

try {
    debitar.executeUpdate();
    creditar.executeUpdate();
    connection.commit();
} catch (Exception e) {
    connection.rollback();
    throw e;
}

O commit() não acontece apenas dentro da aplicação Java. A solicitação precisa viajar até o servidor e ser processada pelo Db2.

Agora imagine:

1. A aplicação envia o COMMIT;

2. O Db2 recebe;

3. O Db2 confirma a transação;

4. A resposta retorna;

5. A rede cai antes de a aplicação receber a confirmação.

A aplicação pode concluir:

“Não recebi sucesso; tentarei novamente.”

Mas o Db2 talvez já tenha confirmado.

Se o retry repetir a operação inteira, podemos debitar o cliente duas vezes.

Esse é o lado realmente perigoso das falhas distribuídas: nem sempre sabemos imediatamente se a viagem temporal ocorreu.

Por isso, operações críticas precisam considerar:

• Idempotência;

• Identificador único de transação;

• Controle de duplicidade;

• Reconciliação;

• Logs técnicos e de negócio;

• Estado desconhecido após falhas;

• Estratégias específicas de retry.

Retry não é GO TO TENTE-NOVAMENTE aplicado cegamente a qualquer erro.

---

11. Pool de conexões: o táxi que retorna à praça

Abrir uma conexão para cada requisição custa caro. Por isso, servidores de aplicações normalmente mantêm pools.

Requisição
    ↓
Solicita conexão
    ↓
Pool entrega uma conexão
    ↓
Aplicação executa SQL
    ↓
Commit ou rollback
    ↓
Conexão retorna ao pool

O problema surge quando a aplicação devolve a conexão em estado inadequado.

Ela pode retornar com:

• Transação aberta;

• Cursor abandonado;

• Isolation level alterado;

• CURRENT SCHEMA modificado;

• Registros especiais alterados;

• Erro não tratado;

• Estado inválido após falha de comunicação.

Exemplo:

SET CURRENT SCHEMA = FINANCEIRO;

Se a aplicação devolve a conexão sem restaurar o estado, o próximo usuário pode herdar aquela configuração.

O pool é como um táxi reutilizado. O próximo passageiro não deveria encontrar no banco traseiro:

• A carteira do anterior;

• Uma transação aberta;

• Um cursor;

• O schema financeiro;

• Nem Igor tentando voltar a 1986.

Boas práticas incluem:

• Sempre fechar recursos;

• Usar blocos try-with-resources;

• Executar rollback em exceções;

• Configurar validação de conexões;

• Definir timeouts;

• Dimensionar mínimo e máximo;

• Monitorar espera pelo pool;

• Evitar pools enormes em cada instância;

• Considerar o total agregado de containers.

---

12. Segurança: TCP/IP não é colete à prova de balas

A existência de uma conexão TCP/IP não garante que seu conteúdo esteja protegido.

No Db2 for z/OS, TLS pode ser implementado com participação do z/OS Communications Server e AT-TLS. O SECPORT pode identificar a porta utilizada para conexões seguras. IBM — TLS no Db2 for z/OS

Devemos separar quatro perguntas:

Quem é você?

Autenticação:

• Usuário e senha;

• RACF PassTicket;

• Kerberos;

• Outros mecanismos previstos pela arquitetura.

A conversa está protegida?

Transporte:

• TLS;

• Certificados;

• Truststore;

• Cipher suites;

• AT-TLS;

• Políticas de rede.

O que você pode fazer?

Autorização:

• SELECT;

• INSERT;

• UPDATE;

• DELETE;

• EXECUTE em package;

• EXECUTE em stored procedure;

• Uso de uma collection.

Quem é a aplicação?

Identificação operacional:

• Application name;

• Workstation;

• Client user;

• Accounting string;

• Correlation ID.

Sem identificação adequada, o monitoramento pode apresentar centenas de conexões chamadas simplesmente de:

db2jcc_application

É como receber 500 viajantes temporais e registrar todos como “Igor”.

---

13. Por que uma SQL rápida no SPUFI pode ser lenta no Java?

Essa comparação aparece frequentemente:

“No SPUFI leva meio segundo; no Java leva dez segundos. Logo, Java ou Db2 Connect está lento.”

Talvez. Mas ainda não foi provado.

Compare:

• A SQL é exatamente igual?

• Os valores dos parâmetros são iguais?

• O usuário é o mesmo?

• O schema é o mesmo?

• O package é o mesmo?

• O APPLCOMPAT é igual?

• O isolation level é igual?

• A aplicação executa apenas uma SQL?

• O tempo inclui espera no pool?

• Há latência de rede?

• Quantas linhas retornam?

• Qual é o fetch size?

• A aplicação processa cada linha lentamente?

• Existe gateway intermediário?

• Há conversões de tipos?

• A conexão foi aberta durante a medição?

SPUFI e aplicação distribuída podem usar caminhos operacionais muito diferentes.

A aplicação talvez faça:

1 consulta para obter clientes
+ 1 consulta para cada cliente

Para mil clientes:

1 + 1.000 = 1.001 SQLs

Esse é o conhecido problema N+1.

O Db2 pode executar cada consulta rapidamente, mas a aplicação acumula mil viagens de rede.

O relatório final dirá “Db2 lento”. O Db2, inocente, estará apenas respondendo mil vezes à mesma insistência.

---

14. Fetch size: quantas malas entram em cada viagem?

Se uma consulta retorna 100 mil linhas, trazê-las uma por uma pode ser desastroso.

Imagine:

100.000 linhas
÷ 10 linhas por bloco
= 10.000 trocas

Com blocos de cem linhas:

100.000
÷ 100
= 1.000 trocas

Ajustar fetch size e blocagem pode reduzir viagens, mas aumentar indiscriminadamente também não é solução.

Blocos maiores podem:

• Consumir mais memória;

• Aumentar o volume transferido antecipadamente;

• Ser desperdiçados se a aplicação abandonar o cursor;

• Pressionar o heap do servidor.

O ajuste deve considerar:

• Tamanho médio da linha;

• Volume do resultado;

• Latência;

• Memória disponível;

• Padrão de consumo;

• Necessidade real do usuário.

A melhor otimização pode ser não buscar 100 mil linhas.

Às vezes, a solução correta é:

FETCH FIRST 100 ROWS ONLY

ou implementar paginação adequada.

---

15. Data Sharing, Sysplex e a banheira com várias saídas

Em um Db2 Data Sharing Group, vários membros podem atender o workload.

Aplicação
    ↓
Driver com recursos de disponibilidade
    ↓
Location do grupo
    ↓
DB2A / DB2B / DB2C

O driver pode colaborar com:

• Sysplex workload balancing;

• Automatic client reroute;

• Failover;

• Afinidade;

• Concentração de transporte.

Mas esses recursos precisam ser planejados e configurados. Não surgem apenas porque alguém escreveu “HA” no PowerPoint.

Também é importante compreender:

Reconectar não significa continuar uma transação interrompida exatamente de onde ela parou.

O driver pode encontrar outro membro disponível, mas a aplicação ainda precisa tratar:

• Unidade de trabalho anterior;

• Commit de resultado incerto;

• Cursores perdidos;

• Estado da sessão;

• Reexecução segura.

Alta disponibilidade reduz interrupções. Não revoga as leis do processamento distribuído.

---

16. Mapa rápido dos erros

Sintoma	Camada provável	O que verificar
Host desconhecido	DNS	Nome e resolução
Connection refused	TCP/DDF	Porta, listener, firewall
Timeout de conexão	Rede	Rota, firewall, endereço
Falha de handshake	TLS	Certificado, truststore, cipher
Usuário inválido	Segurança	Credencial, RACF, método
SQLCODE -805	Package	Collection, bind, versão
SQLCODE -551	Autorização	Privilégios
SQLCODE -911/-913	Concorrência	Lock, deadlock, timeout
SQLCODE -904	Recurso	Reason code e resource name
SQL30081N	Comunicação	Protocolo, socket e códigos
-4499	JDBC/comunicação	Exceções encadeadas e timeout
Muitas conexões ociosas	Pool	Mínimo, máximo e total agregado
Lentidão intermitente	Várias	Pool, DBAT, WLM, lock, rede

Nunca pare na primeira mensagem genérica.

Em JDBC, investigue as exceções encadeadas. Registre:

• SQLCODE;

• SQLSTATE;

• Reason code;

• Timestamp;

• Host de origem;

• Nome da aplicação;

• Versão do driver;

• Correlation ID;

• URL sem senha;

• Operação executada;

• Estado da transação.

---

17. Passo a passo do jovem padawan COBOL

Passo 1 — Desenhe o caminho real

Aplicação
→ servidor
→ driver
→ gateway, se houver
→ firewall
→ porta
→ DDF
→ Db2

Não use o desenho idealizado. Use o caminho de produção.

Passo 2 — Identifique o driver

Descubra:

• Nome;

• Versão;

• Arquivo;

• Configuração;

• Compatibilidade;

• Licença aplicável.

Passo 3 — Confirme host, porta e location

Não confunda:

• Nome DNS;

• Nome do subsistema;

• Location name;

• Alias;

• Nome do data sharing group;

• Database da URL JDBC.

Passo 4 — Teste a rede

Verifique:

• DNS;

• Rota;

• Porta;

• Firewall;

• Origem real da aplicação.

O teste deve ser executado a partir do servidor onde o programa roda, não do notebook do analista.

Passo 5 — Verifique TLS

Confirme:

• Porta segura;

• Validade do certificado;

• Cadeia de confiança;

• Truststore;

• Nome do host;

• Política AT-TLS.

Passo 6 — Verifique DDF

No z/OS:

• DDF está ativo?

• A porta está correta?

• O location está correto?

• Existem mensagens DSNL?

• A conexão chega?

Passo 7 — Verifique autenticação

Pergunte:

• O usuário existe?

• Está revogado?

• A credencial expirou?

• O método é compatível?

• O RACF registrou falha?

Passo 8 — Verifique packages

Se houver -805:

• Qual package?

• Qual collection?

• Qual versão do driver?

• Houve atualização?

• O bind foi feito?

• O APPLCOMPAT é compatível?

Passo 9 — Verifique autorização

Se houver -551:

• Qual authid?

• Qual objeto?

• Qual operação?

• A autorização é direta ou por papel?

• O usuário pode executar o package?

Passo 10 — Verifique a unidade de trabalho

• Autocommit está ativo?

• Existe commit explícito?

• O rollback é garantido?

• A conexão volta limpa ao pool?

• Há transações longas?

Passo 11 — Verifique performance

• Espera no pool;

• Tempo de conexão;

• Tempo de SQL;

• Tempo de fetch;

• Tempo da aplicação;

• Lock;

• DBAT;

• WLM;

• Número de viagens.

Passo 12 — Documente o resultado

Uma solução que vive apenas na memória do analista sofrerá um DELETE quando ele sair de férias.

---

18. Curiosidades escondidas na banheira

Curiosidade 1 — O nome histórico pode denunciar a idade do desenho

O infográfico usa “Db2 for i5/OS”. A nomenclatura atual é Db2 for IBM i.

Também aparece algo parecido com “Db2 for x/OS”, provavelmente um erro gráfico para Db2 for z/OS.

Curiosidade 2 — SQL não é API de transporte

SQL descreve operações relacionais. JDBC, ODBC e CLI oferecem interfaces para a aplicação. O driver transforma essas chamadas em comunicação com o servidor.

Curiosidade 3 — “Conectou” não significa “funcionou”

Existem vários marcos:

Host respondeu
≠ porta abriu
≠ TLS negociou
≠ usuário autenticou
≠ package foi encontrado
≠ autorização concedida
≠ SQL executou
≠ commit confirmou

Curiosidade 4 — O nome da aplicação é recurso de produção

Preencher corretamente os atributos do cliente ajuda:

• Accounting;

• WLM;

• Monitoramento;

• Profile tables;

• Diagnóstico;

• Chargeback;

• Identificação de ofensores.

Curiosidade 5 — O erro mais perigoso pode vir depois do sucesso

A SQL pode ter sido executada e confirmada, mas a resposta pode ter se perdido. Isso cria estado incerto e torna retries cegos particularmente perigosos.

Curiosidade 6 — Microserviço não reduz automaticamente o consumo

Transformar um monólito em cem containers pode multiplicar:

• Pools;

• Conexões;

• Certificados;

• Logs;

• Timeouts;

• Pontos de falha;

• Viagens ao Db2.

A arquitetura ficou distribuída. O bom senso também precisa ser.

---

19. O mapa mental definitivo

Quando uma aplicação distribuída acessa Db2 for z/OS, pense nesta sequência:

A aplicação pede
A API formaliza
O driver traduz
DRDA organiza
TLS protege
TCP/IP transporta
DDF recebe
RACF autentica
WLM classifica
DBAT trabalha
O package sustenta
Db2 executa
O cursor entrega
COMMIT confirma
O pool reutiliza
A monitoração conta a história

Se cada componente possuir dono, versão, configuração, métrica e procedimento, a arquitetura será administrável.

Se tudo for chamado genericamente de “Db2 Connect”, o incidente será uma excursão temporal sem mapa.

---

Epílogo — Ninguém voltou para 1986, mas o chamado foi encerrado

De volta ao datacenter, o jovem padawan COBOL examinou novamente o erro:

ERRORCODE=-4499
SQLSTATE=08001

Dessa vez ele não começou pelo SELECT.

Primeiro confirmou:

• O servidor de origem;

• A versão do driver;

• O hostname;

• A porta segura;

• A cadeia de certificados;

• O status do DDF;

• As mensagens no z/OS.

Descobriu que o certificado havia sido renovado no servidor, mas o truststore da aplicação ainda continha a cadeia anterior.

A rede funcionava.

O DDF funcionava.

O Db2 funcionava.

A SQL nunca havia chegado ao banco.

Igor olhou para a banheira e perguntou:

— Então podemos colocá-la em produção?

O padawan respondeu:

IF IGOR-IN-PRODUCTION
    MOVE 'N' TO APPROVAL-FLAG
    PERFORM CHAMAR-CHANGE-MANAGER
END-IF

A maior lição daquela noite não foi apenas aprender o que Db2 Connect faz.

Foi compreender que arquiteturas distribuídas são formadas por contratos encadeados. Cada camada promete alguma coisa à camada seguinte:

• A aplicação promete usar corretamente a API;

• O driver promete implementar a conversa;

• DRDA promete organizar o diálogo;

• TCP/IP promete transportar;

• TLS promete proteger;

• DDF promete receber;

• DBAT promete processar;

• O Db2 promete preservar integridade;

• A aplicação promete saber quando confirmar ou desfazer.

Quando uma promessa é quebrada, o erro aparece em algum lugar da cadeia — nem sempre no lugar onde nasceu.

Db2 Connect, portanto, não é uma simples ponte entre um computador e um banco.

É uma máquina do tempo cuidadosamente controlada: leva aplicações escritas hoje até dados acumulados durante décadas, permite que Java, Python, .NET, ferramentas ODBC e sistemas modernos conversem com o Db2 for z/OS e demonstra que o mainframe não está preso ao passado.

O passado continua em produção.

E, ao contrário da banheira de Igor, processa bilhões de transações sem derramar energético no DDF.

IBM MQ vs Kafka : Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean..

 

Bellacosa Mainframe e uma comparação ibm mq versus kafka

☕ Um Café no Bellacosa Mainframe

IBM MQ vs Kafka sem Mistérios para Programadores COBOL

Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean... Difícil Mesmo é Dar Rollback em uma Transação Bancária

"Estradas? Para onde vamos, não precisamos de estradas." — Doc Brown

No universo Bellacosa Mainframe, porém, Doc Brown provavelmente corrigiria sua famosa frase:

"Mensagens? Para onde vamos, não precisamos apenas de mensagens. Precisamos de COMMIT."

Porque existe uma enorme diferença entre viajar pelo tempo e viajar com dados corporativos.

Um erro temporal pode fazer Marty McFly apagar sua própria existência.

Um erro numa transação bancária pode fazer desaparecer milhões de reais.

E é justamente aqui que entram dois dos maiores protagonistas da arquitetura moderna:

IBM MQ e Apache Kafka.

Embora muita gente os coloque no mesmo ringue, como se fossem dois boxeadores disputando o cinturão mundial da mensageria, a verdade é outra.

Eles nasceram para resolver problemas completamente diferentes.

Hoje vamos embarcar no DeLorean do Bellacosa Mainframe para visitar quarenta anos de evolução dos sistemas distribuídos e descobrir por que o IBM MQ continua sendo uma das tecnologias mais importantes do planeta para sistemas críticos.

Aperte o cinto.

Configure o Flux Capacitor para 88 mph.

E cuidado para não provocar um ABEND em 1955.

---

1985: O primeiro salto temporal

Imagine Marty chegando em Hill Valley.

Ele altera um pequeno evento.

Resultado?

Toda a linha do tempo muda.

Nos computadores acontece exatamente a mesma coisa.

Imagine um banco executando uma transferência.

1. Debita R$ 10.000 da conta A.

2. Cai a energia.

3. Nunca credita a conta B.

Parabéns.

Você acabou de criar uma linha temporal alternativa.

No universo do COBOL isso recebe outro nome:

Estado inconsistente.

É exatamente para impedir esse tipo de paradoxo que existem as transações.

---

O verdadeiro Flux Capacitor chama-se COMMIT

No filme, o Flux Capacitor garante que Marty chegue inteiro ao passado.

Nos sistemas corporativos existe um equivalente.

Ele chama-se:

COMMIT.

Enquanto o COMMIT não acontece...

Nada realmente existe.

É como se todo o processamento estivesse preso num universo paralelo.

Somente quando o commit é confirmado, aquela realidade passa oficialmente a existir.

---

Se o COMMIT nunca acontecer...

Imagine Doc Brown ligando o DeLorean.

A viagem começa.

Mas o capacitor falha.

Resultado?

A viagem inteira é cancelada.

É exatamente isso que um rollback faz.

Tudo volta ao estado anterior.

Como se nada tivesse acontecido.

---

IBM MQ nasceu para impedir paradoxos temporais

Quando a IBM criou o MQSeries (hoje IBM MQ), o objetivo nunca foi ser o software mais rápido do planeta.

O objetivo era outro.

Nunca perder uma mensagem.

Existe uma enorme diferença.

Velocidade é importante.

Confiabilidade é indispensável.

---

Kafka nasceu em outro universo

Apache Kafka surgiu décadas depois.

O problema era completamente diferente.

LinkedIn precisava registrar:

Bilhões de cliques.

Bilhões de visualizações.

Logs.

Eventos.

Métricas.

Streaming.

Analytics.

Machine Learning.

Não importava se um clique perdido acontecesse ocasionalmente.

O importante era processar milhões por segundo.

---

A analogia do DeLorean

Imagine dois veículos.

O DeLorean

Transporta uma única missão extremamente importante.

Não pode falhar.

É o IBM MQ.

---

Um trem-bala japonês

Transporta milhares de passageiros continuamente.

É o Kafka.

---

Os dois são excelentes.

Mas para objetivos completamente diferentes.

---

O problema da viagem temporal distribuída

Agora imagine uma viagem muito mais complicada.

Marty precisa alterar cinco épocas diferentes simultaneamente.

1985 Alternativo.

Todas precisam terminar corretamente.

Ou nenhuma pode acontecer.

É exatamente isso que faz uma transação distribuída.

---

XA Transaction

XA é uma especificação criada para coordenar vários recursos diferentes.

Imagine uma orquestra.

Cada músico representa um sistema.

Db2.

Oracle.

IBM MQ.

IMS.

JMS.

Todos precisam tocar exatamente a mesma música.

No mesmo instante.

Se um violinista errar...

Toda a apresentação para.

---

Two Phase Commit

Aqui aparece o verdadeiro maestro.

O Transaction Manager.

Ele faz duas perguntas.

---

Primeira fase

"Todos estão preparados?"

Db2

— Sim.

MQ

— Sim.

Oracle

— Sim.

Ninguém grava nada ainda.

Todos apenas levantam a mão.

---

Segunda fase

O maestro pergunta novamente.

"Posso executar?"

Agora todos respondem.

Sim.

Somente agora tudo é gravado.

Ou...

Caso alguém responda NÃO...

Todos desfazem absolutamente tudo.

---

Easter Egg nº 1

No filme, Doc Brown nunca aperta o acelerador antes de conferir o Flux Capacitor.

No mundo corporativo, um arquiteto nunca faz COMMIT antes de verificar se todos os recursos responderam "Prepare".

---

Porque isso importa?

Imagine pagar um boleto.

A aplicação faz:

Atualiza Db2

↓

Envia mensagem MQ

↓

Atualiza saldo

↓

Gera comprovante

↓

Envia SMS

↓

Atualiza limite

Agora imagine que o servidor reinicie exatamente entre o passo três e quatro.

Sem XA...

Você pode ter:

Dinheiro debitado.

Sem comprovante.

Sem mensagem.

Sem auditoria.

Um pesadelo.

---

IBM MQ resolve isso elegantemente

Quando o MQ participa de uma transação XA, ele espera o Transaction Manager.

Nada é entregue definitivamente.

Nada desaparece.

Tudo permanece consistente.

---

Persistent Message

Uma das maiores forças do IBM MQ.

Existem dois tipos de mensagens.

Persistent.

Non Persistent.

---

Persistent

Antes de responder:

"Mensagem recebida."

O Queue Manager grava tudo em disco.

Mesmo que falte energia.

Mesmo que o servidor exploda.

Mesmo que haja reboot.

A mensagem continua lá.

---

Curiosidade

Essa característica fez do MQ um dos pilares dos bancos durante décadas.

Enquanto aplicações inteiras eram reiniciadas...

As filas permaneciam intactas.

---

Rollback

Agora vem uma das maiores mágicas do processamento transacional.

Imagine escrever um cheque.

Assinar.

Carimbar.

Guardar.

Depois descobrir que o saldo é insuficiente.

Rollback significa destruir completamente aquela operação.

Como se ela jamais tivesse existido.

---

Marty McFly e o Rollback

No primeiro filme, Marty começa a desaparecer da fotografia.

Felizmente consegue corrigir a linha temporal.

No mundo do IBM MQ isso acontece automaticamente.

Rollback restaura a fotografia original.

---

Kafka pensa diferente

Kafka trabalha com outro paradigma.

Eventos.

Streaming.

Replay.

Histórico.

Retenção.

Consumidores independentes.

É quase uma máquina do tempo.

Os eventos ficam armazenados por dias, semanas ou meses.

Você pode voltar e "reassistir" os acontecimentos.

Essa é uma diferença fascinante.

MQ normalmente preocupa-se com entregar a mensagem.

Kafka preocupa-se também em preservar o histórico de eventos para que consumidores possam relê-los.

---

Throughput

Throughput significa capacidade de processamento.

Imagine duas rodovias.

Rodovia A.

Passam cem caminhões por minuto.

Rodovia B.

Passam cem mil carros por minuto.

Kafka foi projetado para a segunda situação.

---

IBM MQ prefere outra pergunta

Não pergunta:

"Quantas mensagens?"

Pergunta:

"Quantas mensagens chegaram corretamente?"

Essa diferença muda completamente a arquitetura.

---

Exactly Once

Esse termo gera muita confusão.

Existem três possibilidades.

At Most Once

Pode perder.

Nunca duplica.

---

At Least Once

Nunca perde.

Pode duplicar.

---

Exactly Once

Nem perde.

Nem duplica.

No IBM MQ isso é obtido por sessões transacionais e commit/rollback.

No Kafka, há recursos de exatamente uma vez dentro do ecossistema Kafka (produtores idempotentes, transações e Kafka Streams), mas quando entram bancos de dados e outros sistemas externos, normalmente usam-se padrões como Transactional Outbox, CDC e Saga, em vez de XA distribuído.

---

MongoDB

Existe uma observação muito interessante.

MongoDB suporta transações internas.

Mas não participa do padrão XA tradicional.

Por isso arquiteturas modernas normalmente utilizam:

Transactional Outbox.

CDC.

Saga Pattern.

Compensating Transactions.

Tudo isso substitui o velho Two Phase Commit quando múltiplos recursos heterogêneos estão envolvidos.

---

Alta Disponibilidade

Imagine Hill Valley sendo atingida por um raio.

Mesmo assim.

O sistema continua funcionando.

IBM MQ possui recursos empresariais como:

Multi Instance Queue Manager.

HA.

Disaster Recovery.

Logs.

Journal.

Replicação.

Failover.

No z/OS pode integrar-se ao Parallel Sysplex para disponibilidade extraordinária.

---

Disaster Recovery

Imagine perder um Data Center inteiro.

Mesmo assim.

As mensagens continuam existindo.

É exatamente isso que faz o Journal do MQ.

---

Easter Egg nº 2

No filme existe uma torre do relógio.

Ela registra um instante histórico.

No IBM MQ existe o Journal.

Ele registra cada passo importante da vida das mensagens.

---

JMS

Muitos iniciantes confundem.

JMS NÃO é um broker.

JMS é uma API.

Ela permite que aplicações Java conversem com IBM MQ, ActiveMQ, Artemis e outros provedores de mensageria sem ficarem presas a uma implementação específica.

---

Spring Boot

Hoje é extremamente comum encontrar:

Spring Boot

IBM MQ

Db2

@Transactional

JTA

Tudo trabalhando junto.

Uma única anotação Java coordena diversos recursos corporativos.

É como Doc Brown sincronizando todos os relógios de Hill Valley.

---

Onde cada tecnologia vence?

Imagine um banco digital.

Cliente faz PIX.

↓

COBOL no CICS processa.

↓

Db2 grava.

↓

IBM MQ garante entrega.

↓

Kafka distribui eventos.

↓

Machine Learning detecta fraude.

↓

Dashboard atualiza em tempo real.

Percebe?

Nenhuma tecnologia substitui completamente a outra.

Elas cooperam.

---

Curiosidade histórica

O IBM MQ surgiu como MQSeries, em 1993, para facilitar a comunicação confiável entre aplicações distribuídas em diferentes plataformas. Ao longo das décadas evoluiu para integrar z/OS, AIX, Linux, Windows e ambientes em nuvem, mantendo como principal característica a confiabilidade.

O Apache Kafka nasceu no LinkedIn e foi aberto como projeto da Apache Foundation em 2011. Sua proposta revolucionou o processamento de eventos em larga escala, tornando-se um dos pilares das arquiteturas orientadas a eventos modernas.

São tecnologias de épocas diferentes, criadas para resolver dores diferentes.

---

Dicas para o Padawan COBOL

Se você está começando no mundo mainframe, siga esta ordem de estudos:

1. Entenda primeiro o conceito de transação e por que ela existe.

2. Aprenda os fundamentos de COMMIT e ROLLBACK em Db2 e CICS.

3. Estude o funcionamento de uma Queue, incluindo mensagens persistentes e não persistentes.

4. Pratique o envio e recebimento de mensagens com IBM MQ em programas COBOL ou Java.

5. Compreenda como JMS abstrai o acesso ao MQ em aplicações Java.

6. Só depois mergulhe em Kafka, Event Streaming, CDC, Outbox e Saga. Você entenderá muito melhor quando conhecer primeiro a base transacional.

---

O que um arquiteto experiente realmente pergunta?

O iniciante pergunta:

"Qual tecnologia é melhor?"

O arquiteto pergunta:

"Qual problema estou tentando resolver?"

Se o problema é transmitir milhões de eventos para dezenas de consumidores independentes, Kafka provavelmente será a escolha natural.

Se o problema é garantir que uma transferência financeira de R$ 500.000,00 nunca fique pela metade, IBM MQ é uma das respostas mais sólidas já criadas.

Essa mudança de perspectiva separa quem conhece ferramentas de quem entende arquitetura.

---

O Grande Ensinamento do Dr. Emmett Brown

No final de De Volta para o Futuro, Doc Brown aprende que pequenas mudanças podem alterar completamente a história.

Nos sistemas corporativos acontece exatamente o mesmo.

Uma única mensagem perdida pode gerar:

• um pagamento duplicado;

• uma conta inconsistente;

• um pedido entregue duas vezes;

• uma reserva aérea inexistente;

• um prejuízo milionário.

É por isso que bancos, seguradoras, bolsas de valores e governos continuam investindo em tecnologias como IBM MQ mesmo décadas após sua criação.

No Bellacosa Mainframe, existe uma máxima que todo Padawan COBOL deveria gravar como se fosse escrita na lateral do próprio DeLorean:

"Velocidade impressiona. Escalabilidade encanta. Mas é a consistência que mantém a máquina do tempo da empresa funcionando sem criar paradoxos financeiros."

E talvez esse seja o maior segredo da computação corporativa.

No cinema, Doc Brown precisava de 1,21 gigawatts para viajar no tempo.

No mundo dos mainframes, um arquiteto experiente precisa apenas de quatro palavras para evitar um desastre que poderia alterar a história inteira de uma empresa:

COMMIT. ROLLBACK. MQ. CONSISTÊNCIA.

KAWAII DAKE JA NAI SHIKIMORI-SAN — O ANIME ONDE O FIREWALL MAIS PODEROSO DO MUNDO USA SAIA ESCOLAR E PROTEGE UM USUÁRIO COM AZAR CRÔNICO

 

Bellacosa Mainframe e kawaii dake ja nai shikimori san

☕💣💕 OPERADOR, O SISTEMA DE PROTEÇÃO AUTOMÁTICA ENTROU EM PRODUÇÃO!

KAWAII DAKE JA NAI SHIKIMORI-SAN — O ANIME ONDE O FIREWALL MAIS PODEROSO DO MUNDO USA SAIA ESCOLAR E PROTEGE UM USUÁRIO COM AZAR CRÔNICO

---

📋 Ficha Técnica

Título Original: 可愛いだけじゃない式守さん
Romanização: Kawaii dake ja Nai Shikimori-san
Título Internacional: Shikimori's Not Just a Cutie

Autor: Keigo Maki

Mangá:

• Início: Fevereiro de 2019

• Fim: Fevereiro de 2023

• Total: 20 volumes

Anime:

• Estreia: 10 de abril de 2022

• Episódios: 12

• Estúdio: Doga Kobo

Gêneros:

• Romance

• Comédia Romântica

• Slice of Life

• Escolar

Classificação Indicativa:

• Aproximadamente 12 anos

---

☕ O QUE ACONTECE NESTA HISTÓRIA?

Imagine um ambiente corporativo onde existe um usuário tão azarado que qualquer operação simples gera incidentes.

Ele atravessa a rua.

Quase é atropelado.

Abre uma porta.

Algo cai na cabeça dele.

Vai passear.

Uma sequência de eventos improváveis transforma um simples domingo em um desastre operacional.

Esse usuário é:

🍀 Yuuki Izumi

O homem mais azarado da sua geração.

Mas existe um sistema de contingência.

Uma solução de alta disponibilidade.

Uma proteção em tempo real.

💕 Miyako Shikimori

Sua namorada.

Quando necessário, ela abandona instantaneamente o modo "fofa" e ativa o modo:

😎 ABSOLUTE CHAD MODE

Ela protege Izumi de acidentes, perigos, situações constrangedoras e praticamente das leis da probabilidade.

Daí nasce o título:

Ela não é apenas fofa.

---

🏢 O ESTÚDIO DOGA KOBO

Se existe um estúdio especializado em produzir conforto emocional, é o Doga Kobo.

Eles também produziram:

• New Game!

• Plastic Memories

• Oshi no Ko

• Yuru Yuri

O estúdio ficou famoso por transformar histórias simples em experiências extremamente agradáveis de assistir.

Em Shikimori-san isso aparece claramente:

• cores suaves;

• animação limpa;

• excelente direção facial;

• foco em expressões;

• atmosfera acolhedora.

A produção não tenta impressionar pela ação.

Ela tenta criar conexão emocional.

---

🎭 O QUE TORNA SHIKIMORI DIFERENTE?

Aqui está a grande inovação.

---

1️⃣ O ROMANCE JÁ COMEÇOU

Grande parte dos romances japoneses segue a fórmula:

• garoto conhece garota;

• confusão;

• mal-entendidos;

• 3 temporadas;

• confissão final.

Shikimori pula tudo isso.

O casal já está junto desde o início.

O anime responde uma pergunta raramente explorada:

"O que acontece depois que o casal finalmente começa a namorar?"

---

2️⃣ INVERSÃO DOS PAPÉIS CLÁSSICOS

Normalmente:

• garoto protege garota.

Aqui:

• garota protege garoto.

Mas sem humilhar Izumi.

Esse detalhe é importante.

O anime evita transformar o protagonista em piada.

Ele continua sendo gentil, corajoso e emocionalmente maduro.

---

3️⃣ O VERDADEIRO PODER É A EMPATIA

Não existe:

• magia;

• superpoderes;

• mechas;

• isekai;

• torneios.

O poder da história é:

cuidado genuíno.

Algo cada vez mais raro na ficção moderna.

---

👥 PERSONAGENS PRINCIPAIS

💕 Miyako Shikimori

A protagonista.

Mistura:

• delicadeza;

• confiança;

• força emocional;

• carisma.

Ela alterna entre:

Modo Cute

😊

e

Modo Cool

😎

em questão de segundos.

Essa dualidade virou um dos maiores atrativos da obra.

---

🍀 Yuuki Izumi

O azar ambulante.

Mas existe algo interessante.

Seu azar não o tornou amargo.

Ele continua otimista.

É uma mensagem poderosa:

circunstâncias ruins não precisam definir quem você é.

---

🐱 Nekozaki

Energia pura.

Representa a amizade espontânea.

---

🍯 Hachimitsu

Especialista em comentários secos.

Rouba cenas constantemente.

---

🐶 Inuzuka

Melhor amigo de Izumi.

Leal e confiável.

---

🔍 AS MENSAGENS OCULTAS

Aqui a obra fica mais interessante do que parece.

Muita gente vê apenas uma romcom.

Mas existem várias camadas escondidas.

---

A MALDIÇÃO DO AZAR

O azar de Izumi funciona quase como metáfora.

Ele representa pessoas que cresceram acreditando:

• "sou problemático"

• "só dou trabalho"

• "as coisas dão errado comigo"

Shikimori simboliza alguém que enxerga valor mesmo quando a pessoa não enxerga em si mesma.

---

O AMOR COMO SUPORTE E NÃO COMO SALVAÇÃO

Um detalhe muito saudável.

Shikimori não "conserta" Izumi.

Ela o apoia.

Isso é muito diferente.

O anime evita a ideia tóxica de que um relacionamento resolve todos os problemas.

---

A FORÇA FEMININA SEM AGRESSIVIDADE

Muitas obras mostram personagens femininas fortes através da violência.

Shikimori mostra outra abordagem.

Ela é forte porque:

• é confiante;

• toma iniciativa;

• cuida dos outros;

• assume responsabilidades.

---

🎒 AS AVENTURAS

Não existem grandes guerras.

As aventuras são cotidianas:

• festivais escolares;

• encontros;

• passeios;

• atividades esportivas;

• viagens;

• eventos de classe.

Mas é justamente isso que cria identificação.

Todos já viveram algo parecido.

O anime transforma momentos comuns em memórias especiais.

---

🌸 O CONCEITO JAPONÊS ESCONDIDO

Existe uma forte influência do conceito japonês:

"Iyashi"

癒し

Significa:

• cura emocional;

• tranquilidade;

• conforto psicológico.

Shikimori pertence parcialmente à categoria dos chamados:

Iyashikei Romances

Obras feitas para relaxar o espectador.

Não para deixá-lo ansioso.

---

🌎 IMPACTO CULTURAL

Quando estreou, a recepção foi curiosa.

Muitos espectadores esperavam:

• outra Nagatoro;

• outra Marin Kitagawa;

• outra Komi.

Receberam algo completamente diferente.

Isso gerou críticas iniciais.

Mas com o tempo o anime ganhou reconhecimento por sua proposta única.

Hoje é frequentemente lembrado como um dos romances mais confortáveis da década de 2020.

---

🚫 HOUVE CENSURA?

Não houve censura relevante.

A obra sempre foi considerada extremamente leve.

Não possui:

• violência gráfica;

• fanservice pesado;

• conteúdo controverso.

Seu foco sempre esteve nos relacionamentos.

---

🧠 A LEITURA BELLACOSA MAINFRAME

Agora vem a interpretação de operador.

---

Izumi = JOB COM ERROS INTERMITENTES

Nada parece funcionar.

Toda execução produz um incidente novo.

---

Shikimori = SISTEMA DE RECOVERY AUTOMÁTICO

Detecta problemas.

Corrige falhas.

Evita abends.

Restaura estabilidade.

---

Amigos = EQUIPE DE SUPORTE

Monitoram o ambiente.

Prestam assistência.

Mantêm a operação saudável.

---

O Romance = ALTA DISPONIBILIDADE

Não é sobre evitar falhas.

É sobre continuar funcionando apesar delas.

---

🎯 CONCLUSÃO

Kawaii dake ja Nai Shikimori-san parece uma simples comédia romântica escolar.

Mas por trás da aparência existe uma história sobre:

• apoio emocional;

• aceitação;

• amadurecimento;

• amizade;

• relacionamentos saudáveis.

Enquanto muitos animes tentam impressionar com explosões, poderes e reviravoltas, Shikimori faz algo muito mais difícil:

transforma gentileza em entretenimento.

E talvez essa seja a verdadeira mensagem da obra.

No fim, todos nós somos um pouco como Izumi.

Sistemas cheios de falhas inesperadas.

E todos gostaríamos de encontrar uma Shikimori na vida:

alguém que conheça nossos bugs, nossos logs de erro e nossos abends... e mesmo assim escolha continuar ao nosso lado em produção. ☕💣💕

NANORI — O SUBSISTEMA SECRETO DOS KANJIS QUE FAZ ATÉ JAPONESES NATIVOS CONSULTAREM O MANUAL DE OPERAÇÃO

 

Bellacosa Mainframe e a nanori a dificil questão dos sobrenomes japoneses

☕💣📛 OPERADOR, O CATÁLOGO DE NOMES DO JAPÃO ACABA DE EXECUTAR UM JOB COM LEITURAS NÃO DOCUMENTADAS!

NANORI — O SUBSISTEMA SECRETO DOS KANJIS QUE FAZ ATÉ JAPONESES NATIVOS CONSULTAREM O MANUAL DE OPERAÇÃO

Quando alguém começa a estudar japonês, acredita que o sistema é relativamente simples. Aprende hiragana, katakana, depois descobre os kanjis e finalmente encontra as famosas leituras on'yomi e kun'yomi.

Nesse momento o operador acredita que já entendeu a arquitetura do sistema.

Mas então surge um personagem de anime, um político, um samurai histórico ou uma idol japonesa cujo nome é escrito com kanjis aparentemente comuns...

...e pronunciado de uma forma que parece não ter qualquer relação lógica com eles.

É nesse instante que o sistema emite:

IEF451I UNKNOWN READING DETECTED

Bem-vindo ao mundo do Nanori (名乗り).

O nanori é provavelmente uma das partes mais fascinantes, misteriosas e culturalmente profundas da língua japonesa.

E também uma das que mais confundem estudantes estrangeiros.

---

O QUE É NANORI?

De forma simples, nanori são leituras especiais de kanji utilizadas em nomes próprios.

A palavra vem de:

名 (na)
Nome

乗り (nori)
Declarar ou apresentar

Originalmente, nanori significava algo semelhante a:

"o nome pelo qual alguém se apresenta".

Com o passar dos séculos, passou a designar as leituras específicas usadas em nomes pessoais.

Em linguagem de mainframe:

Se o kanji fosse um programa COBOL, as leituras normais seriam as APIs oficialmente documentadas.

O nanori seria uma rotina interna herdada de uma versão de 800 anos atrás que ainda funciona em produção porque ninguém tem coragem de removê-la.

---

O PROBLEMA QUE O NANORI RESOLVE

Imagine que você tem o kanji:

山

Normalmente:

• yama

• san

Tudo certo.

Mas quando ele aparece em um sobrenome, pode assumir comportamentos diferentes.

Por exemplo:

山田

A maioria dos estudantes aprende:

Yama + ta

Mas o nome é:

Yamada

Até aí tudo bem.

Porém o Japão acumulou mais de mil anos de tradição familiar.

Cada clã, região e linhagem começou a usar leituras próprias.

O resultado foi um gigantesco banco de dados de exceções.

---

O MAINFRAME CULTURAL DO JAPÃO

Para entender o nanori, precisamos compreender algo importante.

O Japão valoriza profundamente:

• ancestralidade

• linhagem familiar

• tradição regional

• herança histórica

Durante séculos, famílias nobres mantiveram determinadas leituras exclusivas.

Essas leituras eram transmitidas como verdadeiros ativos culturais.

Em termos de TI:

O nome era uma espécie de certificado digital familiar.

Trocar a leitura seria quase como alterar a chave mestra do RACF de um sistema centenário.

---

ON'YOMI, KUN'YOMI E NANORI

Pense nos kanjis como programas.

Eles possuem múltiplas interfaces.

ON'YOMI

Leitura de origem chinesa.

Exemplo:

学

gaku

---

KUN'YOMI

Leitura japonesa.

Exemplo:

学ぶ

manabu

---

NANORI

Leitura usada em nomes.

Exemplo:

学

mana

satoru

gaku

ou outras variantes dependendo do nome.

Ou seja:

O mesmo caractere pode executar rotinas completamente diferentes dependendo do ambiente.

É praticamente um JCL com múltiplos PROC herdados.

---

QUANDO O SISTEMA COMEÇA A FICAR MALUCO

Vamos pegar um exemplo famoso.

Kanji:

一

Normalmente:

ichi
itsu
hito

Mas em nomes pode virar:

kazu

hajime

makoto

issei

e várias outras leituras.

O estudante olha para isso e pensa:

"Existe alguma regra?"

A resposta histórica é:

"Mais ou menos."

A resposta prática é:

"Não."

---

POR QUE EXISTEM TANTAS LEITURAS?

Porque nomes japoneses evoluíram durante mais de mil anos.

Imagine uma empresa que nunca aposentou sistemas legados.

Cada geração adicionou novas convenções.

Nenhuma foi removida.

O resultado é um ambiente onde:

• regras modernas coexistem

• regras medievais coexistem

• exceções regionais coexistem

Tudo funcionando simultaneamente.

Parece familiar para quem administra mainframe.

---

O TERROR DOS ESTUDANTES DE JAPONÊS

Existe uma piada famosa entre estudantes.

Você consegue ler um jornal inteiro.

Consegue entender um romance.

Consegue interpretar documentos técnicos.

Mas não consegue ler o nome das pessoas.

Isso acontece justamente por causa do nanori.

Os nomes japoneses frequentemente utilizam leituras exclusivas.

---

EXEMPLOS REAIS

大輔

Pode ser:

Daisuke

---

翔

Pode ser:

Sho

Kakeru

Tsubasa

---

翔太

Shota

---

大和

Yamato

Hirokazu

Yamatoo

dependendo do contexto.

Cada família pode carregar uma tradição diferente.

---

O EASTER EGG DOS NOMES DE ANIME

Autores de anime adoram brincar com nanori.

Porque isso permite esconder significados.

O nome parece comum.

Mas os kanjis revelam uma mensagem.

É praticamente um comentário oculto no código-fonte.

---

NARUTO

O universo Naruto possui vários exemplos.

Minato

湊

Significa porto.

Um ponto de encontro.

Algo que combina perfeitamente com o papel do personagem.

---

Itachi

鼬

Doninha.

Uma referência simbólica ao comportamento furtivo do personagem.

---

Sasuke

Um nome histórico associado a lendas ninja.

Os kanjis carregam múltiplas interpretações.

---

DEATH NOTE

Light Yagami

O caso é tão extremo que virou clássico.

Seu nome é escrito:

月

Que normalmente seria:

tsuki

(lua)

Mas é lido:

Light

Uma leitura totalmente não convencional.

É quase um nanori moderno criado para transmitir significado simbólico.

---

BLEACH

Tite Kubo adora nomes carregados de simbolismo.

Ichigo

一護

O nome pode ser interpretado como:

"aquele que protege"

embora também remeta ao número um.

Múltiplas camadas semânticas coexistem.

---

DEMON SLAYER

Tanjiro

炭治郎

Cada kanji contribui para a identidade histórica e cultural do personagem.

Os autores frequentemente escolhem nomes considerando:

• som

• significado

• simbolismo

• tradição

Tudo ao mesmo tempo.

---

O FENÔMENO DOS KIRA KIRA NAMES

Aqui entramos numa área curiosa.

Nas últimas décadas surgiu o fenômeno dos:

Kirakira Names

"nomes brilhantes".

Pais começaram a usar kanjis tradicionais com leituras extremamente criativas.

Por exemplo:

Kanji que significam "lua".

Mas pronunciados como:

Runa

Luna

Moon

ou até palavras inspiradas em inglês.

É como se alguém cadastrasse um dataset chamado:

PROD001

e declarasse que ele deve ser lido como:

SUPERSYSTEMX

---

O GOVERNO PRECISOU INTERVIR

O problema ficou tão grande que autoridades japonesas começaram a discutir limites para leituras excessivamente criativas.

Algumas eram tão incomuns que:

• escolas não conseguiam registrar alunos

• hospitais erravam nomes

• sistemas administrativos apresentavam inconsistências

Ou seja:

O Japão começou a enfrentar problemas de integridade referencial no banco de dados nacional de nomes.

---

NANORI E SAMURAIS

Historicamente, samurais utilizavam nomes que mudavam durante a vida.

Era comum alguém possuir:

• nome infantil

• nome adulto

• título honorífico

• nome militar

Cada um podia envolver leituras diferentes.

Em termos modernos:

Uma pessoa podia possuir múltiplos aliases operacionais.

---

O SEGREDO DOS NOMES IMPERIAIS

A família imperial japonesa também influenciou fortemente o desenvolvimento dos nanori.

Certos caracteres tornaram-se associados à nobreza.

Outros passaram a simbolizar:

• sabedoria

• prosperidade

• longevidade

• força

O uso desses caracteres espalhou-se pela sociedade.

---

O IMPACTO NA CULTURA POP

Quando um autor escolhe um nome em anime, raramente faz isso aleatoriamente.

Existe um enorme trabalho simbólico.

Um único kanji pode transmitir:

• destino

• personalidade

• papel narrativo

• referência histórica

• trocadilho cultural

O espectador japonês muitas vezes percebe detalhes que passam despercebidos para o público ocidental.

---

O EASTER EGG QUE ESTRANGEIROS QUASE NUNCA NOTAM

Muitos protagonistas possuem nomes cujo significado antecipa a história.

O autor está praticamente inserindo um comentário no código.

Mas o leitor só percebe depois de dezenas de episódios.

É equivalente a encontrar um comentário COBOL escrito em 1978 prevendo exatamente o comportamento do sistema em 2025.

---

O DESAFIO DOS DICIONÁRIOS

Existem dicionários inteiros dedicados apenas a nomes japoneses.

Isso porque conhecer 2.000 kanjis não é suficiente.

Você também precisa conhecer:

• leituras históricas

• leituras regionais

• leituras familiares

• leituras nanori

É um universo paralelo dentro da própria língua.

---

CURIOSIDADES IMPRESSIONANTES

Curiosidade 1

Alguns kanjis possuem dezenas de leituras possíveis em nomes.

---

Curiosidade 2

Muitos japoneses perguntam a pronúncia do nome mesmo vendo os kanjis.

---

Curiosidade 3

Formulários japoneses frequentemente possuem espaço específico para indicar a leitura correta do nome.

---

Curiosidade 4

Muitos animes incluem furigana justamente para evitar ambiguidades.

---

Curiosidade 5

Existem nomes que até especialistas erram ao tentar ler pela primeira vez.

---

O MAINFRAME DOS NOMES JAPONESES

Se tivéssemos que resumir o nanori para um profissional de tecnologia, seria algo assim:

O idioma japonês é o sistema operacional.

Os kanjis são os programas.

As leituras on'yomi e kun'yomi são a documentação oficial.

E o nanori?

O nanori é aquele módulo crítico escrito séculos atrás, cheio de exceções, compatibilidades históricas e regras herdadas que continua executando perfeitamente porque está ligado à identidade cultural de milhões de pessoas.

Você pode estudar japonês por anos.

Pode dominar gramática.

Pode ler mangás.

Pode assistir centenas de animes.

Mas inevitavelmente chegará o dia em que encontrará um nome aparentemente simples e descobrirá que sua leitura não segue nenhuma lógica que você conheça.

Nesse momento, o console cultural do Japão exibirá a mensagem definitiva:

$HASP999 NANORI PROCESSING ACTIVE

IEF233A OPERATOR ACTION REQUIRED

E você finalmente entenderá que os nomes japoneses são, na verdade, um dos maiores sistemas legados ainda em produção no planeta. 📛☕💣🖥️