✨ 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 — “z/OS 3.1: o cérebro cognitivo do século XXI” ⚙️
📅 Lançado em setembro de 2023 — o z/OS 3.1 marca o início da era da IA no mainframe.
🚀 O salto quântico do z/OS
O z/OS 3.1 não é apenas mais uma atualização do sistema operacional — é a fusão entre o mainframe e a inteligência artificial.
Pela primeira vez, o próprio sistema aprendeu a se “autoajustar”, prever falhas e otimizar recursos com base em padrões de uso.
É o z/OS que pensa sobre o próprio z/OS — um conceito que, há poucos anos, parecia ficção científica digna de Asimov, mas hoje roda em hardware IBM z16.
📆 Lançamento e base de hardware
Data de lançamento: setembro de 2023
Suporte inicial: IBM z15 e z16
Firmware mínimo:PR/SM nível 7.0 (com suporte a IA e Crypto Express8S)
Fim do 31-bit puro: o z/OS 3.1 é 100% 64-bit, encerrando oficialmente a era do código 31-bit legacy.
LPARs: até 2.000 virtuais em sistemas de grande porte
Memória real: suporte a 32 TB por imagem z/OS
💬 Bellacosa Curiosity: A IBM internamente chamou o projeto do z/OS 3.1 de “Hermes”, o mensageiro dos deuses — porque o foco era justamente fazer o sistema conversar com tudo e todos, de CICS a cloud, de VSAM a containers.
🧩 O PR/SM 7.0 — cérebro dos cérebros
O Processor Resource/System Manager (PR/SM) ganhou uma das maiores evoluções desde o System/390.
Ele agora integra AI-Assisted Resource Balancing — um mecanismo cognitivo embutido no microcódigo que observa e aprende o comportamento das LPARs, redistribuindo ciclos de CPU conforme padrões históricos.
🔹 Novidades do PR/SM 7.0:
Redistribuição automática de créditos de CPU com base em Machine Learning.
Ajuste dinâmico de partições soft-capped sem necessidade de intervenção humana.
Métricas novas no RMF 79.3 e SMF 120.16, expondo o “score cognitivo” de eficiência por workload.
Suporte a fabricação dinâmica de processadores para testes (modo z16 T02+).
🧠 Easter Egg Bellacosa: o código interno de balanceamento do PR/SM 7.0 usa o nome “Athena” — em homenagem à deusa grega da sabedoria. Sim, o mainframe agora tem seu próprio oráculo interno.
💾 Memória e arquitetura — 64 bits, expandida e inteligente
O z/OS 3.1 expande e reorganiza profundamente as áreas de memória clássicas:
CSA, SQA, LPA e Pageable Link Pack foram redesenhadas para address spaces dinâmicos e compressão adaptativa.
Área
Novidade técnica
Benefício
CSA/SQA
Compressão adaptativa + expansão em tempo real
Reduz page faults em até 30%
LPA
LPA dinâmica + refresh sem IPL
Atualizações “hot swap” de módulos
Private Area
Suporte a até 16 TB
Menos swapping e I/O
Above Bar
Gerenciamento automático via IA
Alocação preditiva por workload
E, claro, o 64-bit only libera o z/OS de limitações antigas: todos os subsistemas agora são nativamente 64-bit, incluindo CICS, DB2, MQ e JES2.
Adeus “AMODE 31”. O futuro é amplo, literalmente.
⚙️ Softwares internos e stack IBM
O z/OS 3.1 é otimizado para o ecossistema z16 + IA, e veio afinado com as versões mais recentes:
Componente
Versão recomendada
Destaques
CICS TS 6.1
APIs RESTful nativas e Java 17 no z/OS
Suporte a OpenAPI 3.1
DB2 13 for z/OS
Aprendizado de consultas via IA embutida
Indexação inteligente e SQL AI Insights
IMS 15.3
APIs REST + integração com z/OS Connect
Simplificação de transações híbridas
MQ 9.3
Suporte nativo a Kafka bridge
Enfileiramento híbrido
z/OSMF 3.1
Totalmente redesenhado em React + REST API
Painéis cognitivos e monitoramento AI
RACF
Integração com MFA e OpenID Connect
Logon unificado e tokens JWT
zCX (z/OS Container Extensions)
Nova engine OCI
Containers Linux otimizados com zEDC e HiperSockets
Além disso, o z/OS Connect EE 3.1 transformou o mainframe em um hub de APIs REST JSON, expondo programas COBOL como microservices sem esforço.
🧬 Instruções de máquina — o poder do z16
O z/OS 3.1 tira proveito das instruções introduzidas com o processador do z16 (Telum), o primeiro chip mainframe com IA integrada on-chip.
Nova instrução
Função
Aplicação prática
AIMUL / AIDIV
AI-assisted multiply/divide
Processamento vetorial para IA
PAI (Predictive AI Interface)
Interface direta com o Telum AI Core
Diagnóstico de anomalias no tempo de execução
CIPHERX
Criptografia quântica-ready (Q-safe)
Preparação para pós-quantum cryptography
ZDEFLATE2
Compressão inline 2.0
Otimiza datasets VSAM e MQ sem zEDC overhead
BROADLOAD
Carga paralela em múltiplos registradores
Melhoria em Java JIT e C/C++
🧩 Fun fact: o Telum AI Core analisa em tempo real padrões de execução do sistema operacional, podendo prever deadlocks ou falhas de E/S antes que ocorram. O z/OS 3.1 é literalmente auto-protetor.
🤖 IA e automação embarcada
O coração do z/OS 3.1 é o IBM z/OS AI Framework — um conjunto de microagentes que monitoram o comportamento do sistema e sugerem (ou aplicam) ajustes automáticos:
WLM Advisor: ajusta metas de serviço com base no comportamento do sistema.
Health Checker AI Mode: detecta anomalias de forma preditiva.
JES2 Analytics: sugere tuning de classes e message routing.
Dataset Access Predictor: usa IA para identificar datasets “quentes” e sugerir caching.
E tudo isso é visível via o z/OSMF Cognitive Dashboard, com gráficos em tempo real e pontuação de “Saúde do Sistema”.
⚡ Créditos de CPU e WLM inteligente
O Workload Manager (WLM) recebeu um “upgrade cerebral”: agora, ele utiliza modelos de machine learning para entender a carga de trabalho em tempo real.
Ajuste dinâmico de pesos e metas sem intervenção humana.
Integração direta com SMF 98 para feedback contínuo.
Intelligent Resource Director (IRD 3.0): redistribuição cognitiva de créditos entre LPARs com base em padrões históricos.
O resultado?
Até 20% de eficiência extra em ambientes com workloads mistos (CICS + DB2 + zCX + batch).
🧠 Easter-eggs e curiosidades Bellacosa
💡 O z/OS 3.1 inclui um comando interno, usado em debug, chamado D AITHINK, que retorna métricas de “convergência cognitiva” — uma piada interna dos engenheiros do laboratório Poughkeepsie sobre “sistemas que pensam demais”.
💾 O arquivo de ajuda do z/OSMF 3.1 contém uma menção a “Blue Phoenix”, nome de código do protótipo do z/OS AI Framework.
🎹 E, claro, o JES2 foi apelidado internamente de “O maestro invisível” — em homenagem ao seu papel histórico de orquestrar o caos dos jobs desde o OS/360.
🔚 Conclusão — o mainframe entra na era cognitiva
O z/OS 3.1 é o mainframe autoconsciente.
Ele monitora, aprende, otimiza, protege e responde — tudo sem precisar acordar o sysprog às 3h da manhã (ok, quase sempre).
É o renascimento do z/OS como sistema operacional cognitivo, preparado para IA generativa, automação total e integração com qualquer nuvem.
O Sistema Operacional nunca foi tão inteligente.
E o Bellacosa Mainframe — claro — segue com o café na mão, observando o titã despertar. ☕💙
Malba Tahan, Beremiz Samir e o Homem que Inventou um Árabe para Ensinar Matemática ao Brasil
Ou: como um professor brasileiro criou um escritor árabe, depois criou um calculista persa, colocou os dois num camelo e fez gerações inteiras descobrirem que matemática podia contar histórias
Há escritores que inventam personagens.
Há escritores que inventam mundos.
Há escritores que inventam cidades, impérios, idiomas, planetas e genealogias suficientemente complicadas para obrigar algum leitor obsessivo a construir uma planilha.
E houve Júlio César de Mello e Souza.
Esse sujeito resolveu fazer algo mais divertido.
Inventou o próprio escritor.
Não satisfeito, deu-lhe nome.
Malba Tahan.
Depois deu-lhe origem.
Passado.
Personalidade.
Geografia.
Uma atmosfera inteira de desertos, califas, mercadores, palácios, sábios, caravanas e noites estreladas.
E então colocou dentro dessa invenção outro homem.
Um persa chamado:
Beremiz Samir.
O Homem que Calculava.
Portanto, antes de prosseguirmos, convém organizar o datacenter.
Temos três camadas.
Na LPAR 1:
Júlio César de Mello e Souza, brasileiro, professor de matemática.
Beremiz Samir, calculista persa capaz de olhar para um problema aparentemente insolúvel e dizer algo equivalente a:
— Calma. Tem um jeito.
É quase impossível imaginar estrutura narrativa mais Bellacosa Mainframe do que essa.
Um personagem dentro de um personagem criado por um homem que usava histórias para explicar problemas que normalmente seriam apresentados numa lousa acompanhados da frase:
“Calcule o valor de x.”
Beremiz provavelmente olharia para o x e perguntaria primeiro quem era o pai dele, quantos camelos possuía e se havia alguma disputa sucessória envolvida.
🐪 Primeiro precisamos encontrar um camelo
Toda boa história começa em algum lugar.
As histórias de Malba Tahan frequentemente parecem começar numa estrada poeirenta entre cidades do Oriente.
Então imagine.
Sol.
Areia.
Uma estrada.
Um camelo caminhando sem qualquer pressa administrativa.
Sobre ele vai um viajante.
Ao longe aparece outro homem.
Ele observa coisas.
Conta coisas.
Pensa em coisas.
Esse homem é Beremiz Samir.
E se você cresceu lendo O Homem que Calculava, provavelmente já sabe que encontrar Beremiz numa estrada é uma situação perigosa.
Porque dentro de três páginas surgirá algum problema.
Pode ser herança.
Pode ser dinheiro.
Pode ser divisão.
Pode ser lógica.
Pode ser geometria.
Pode aparecer um xeque.
Um mercador.
Um vizir.
Um sábio.
Três irmãos discutindo.
Ou naturalmente:
35 camelos.
Esse último caso tornou-se uma das passagens mais famosas de toda a literatura matemática brasileira.
Três irmãos recebem 35 camelos.
A herança deve ser dividida conforme determinadas frações.
A divisão parece impossível sem produzir aquilo que qualquer proprietário de camelos provavelmente considera uma péssima experiência logística:
frações de camelo.
Beremiz olha.
Pensa.
E introduz um camelo adicional na equação.
O problema muda.
As partes tornam-se inteiras.
A divisão funciona.
E no final ainda aparecem camelos sobrando.
É uma pequena obra-prima de apresentação matemática porque o leitor não recebe apenas uma conta.
Recebe um conflito.
E conflito produz curiosidade.
A matemática entra depois.
A própria Secretaria de Educação do Espírito Santo ainda utiliza o famoso problema dos 35 camelos em material pedagógico, prova de que essa pequena caravana literária continua atravessando salas de aula décadas depois.
Essa foi uma das grandes sacadas de Malba Tahan:
primeiro faça o leitor querer saber a resposta.
Depois ensine a matemática.
É exatamente o contrário de muita educação tradicional, na qual primeiro entregamos a fórmula e depois tentamos convencer o aluno de que ele deveria se importar com ela.
Malba fazia engenharia reversa da curiosidade.
🧮 O professor que declarou guerra ao algebrismo
Agora precisamos deixar Beremiz descansando um pouco no oásis e olhar para o homem que estava atrás da cortina.
Júlio César de Mello e Souza nasceu em 1895.
Professor.
Matemático.
Escritor.
Divulgador.
Contador de histórias.
E um crítico ferrenho de uma coisa que ele chamava de:
algebrismo.
A palavra merece ser colocada numa moldura.
Porque continua assustadoramente moderna.
Algebrismo era, grosso modo, a transformação da matemática numa sucessão de operações formais, regras e exercícios sem contexto suficiente para produzir compreensão.
Uma espécie de matemática funcionando como JCL de 1968:
ninguém sabe exatamente por que aquilo existe, mas o operador foi avisado para não mexer.
A Biblioteca Nacional registra justamente essa crítica de Júlio César ao excesso de algebrismo no ensino.
E aqui encontramos o coração da obra.
Malba Tahan não queria simplesmente ensinar a fazer contas.
Queria ensinar a pensar.
Existe uma diferença brutal entre as duas coisas.
Uma calculadora faz contas.
Um estudante precisa aprender a perceber:
— Qual é o problema?
— O que realmente está sendo pedido?
— Existe outra maneira de olhar para isso?
— Todas as informações são necessárias?
— Alguma coisa aparentemente impossível deixa de ser impossível se mudarmos a perspectiva?
Beremiz fazia exatamente isso.
Não era uma HP 12C humana.
Era um resolvedor de problemas.
🎭 Então Júlio criou Malba
Aqui a história fica maravilhosa.
Imagine um jovem brasileiro no começo do século XX escrevendo contos orientais.
Ele tenta publicá-los.
Os jornais não demonstram grande entusiasmo.
Então ocorre uma ideia.
Hoje chamaríamos provavelmente de:
estratégia de marca.
Ou talvez:
growth hacking literário de 1920.
Júlio conclui que aqueles contos talvez recebessem mais atenção se não parecessem escritos por um jovem brasileiro.
Então nasce:
Malba Tahan.
Não apenas um pseudônimo.
Isso seria simples demais.
Júlio construiu uma identidade.
Uma biografia.
Uma persona.
A Prefeitura de São Paulo registra que ele chegou inclusive a criar um suposto tradutor para as obras, o Professor Breno Alencar Bianco, aumentando ainda mais a verossimilhança da fabricação literária.
“Helping people solve complex problems through storytelling.”
Júlio fez tudo isso antes da Internet.
O sujeito criou uma identidade narrativa completa.
A Biblioteca Nacional registra inclusive edições apresentadas como traduzidas diretamente do original árabe, acompanhadas da biografia do suposto autor oriental.
Era uma brincadeira literária?
Sim.
Marketing?
Também.
Experimento de narrativa?
Com certeza.
Mas há algo ainda mais interessante.
Com o tempo, Malba Tahan tornou-se tão real culturalmente que deixou de importar se ele existia biologicamente.
Malba passou a existir porque os leitores sabiam quem ele era.
E essa talvez seja uma das formas mais interessantes de existência.
Mas o processamento não termina no resultado numérico.
O verdadeiro output é:
compreensão.
Uma pesquisa acadêmica da USP descreve justamente essa cadeia de criação: Júlio cria Malba, que por sua vez cria Beremiz como veículo literário para aplicar uma determinada concepção de matemática à vida cotidiana.
Isso ajuda a explicar por que os livros sobreviveram.
Eles nunca foram apenas livros de problemas.
Se fossem, teriam envelhecido como antigos manuais escolares.
Eles são histórias.
E histórias possuem uma característica perigosa:
ficam armazenadas em regiões estranhas da memória.
Você pode esquecer completamente como resolver uma determinada equação.
Mas quarenta anos depois alguém diz:
— Trinta e cinco camelos.
E uma pequena portinha se abre no cérebro.
🕌 Bagdá.exe foi carregado
O cenário oriental tinha outra função importante.
Transformava a matemática em aventura.
Bagdá não era apenas uma cidade.
Era interface.
Palácios.
Mercados.
Caravanas.
Mesquitas.
Desertos.
Astrônomos.
Mercadores.
Sábios.
Xeques.
Poetas.
O leitor estava aprendendo matemática, mas pensava estar seguindo uma viagem.
Truque antigo.
Funcionava nas Mil e Uma Noites.
Funcionou com Malba.
Funciona hoje em videogame.
Funciona numa boa aula.
Funciona neste blog.
Você entra porque alguém prometeu uma história sobre mainframe.
Quando percebe, está lendo sobre:
WLM,
zIIP,
R4HA,
COBOL,
psicologia cognitiva,
história romana,
um rinoceronte que Dürer nunca viu
e provavelmente algum macaco bêbado abrindo um barril.
A técnica é a mesma.
Esconda o remédio dentro da sobremesa.
Malba Tahan sabia disso quase cem anos atrás.
📚 Mil Histórias sem Fim
E eis que encontramos um título perfeito para esta homenagem.
Mil Histórias sem Fim.
Malba Tahan publicou uma obra com esse nome.
E há qualquer coisa deliciosamente apropriada nisso.
Porque histórias realmente não terminam.
Elas mudam de hospedeiro.
Um professor conta para um aluno.
O aluno vira professor.
Conta para outro aluno.
Um pai lê um livro.
Décadas depois lembra do problema.
Conta para o filho.
O filho procura na Internet.
Encontra outra versão.
Alguém produz um vídeo.
Outro faz um post.
Outro cria um meme.
Outro escreve um artigo num blog perdido numa esquina da Internet.
E agora temos um velho barbudo em Itatiba tomando café enquanto um calculista persa atravessa o datacenter montado num camelo imaginário.
Se isso não é uma história sem fim, não sei o que seria.
🎓 O professor que queria alunos pensando
Existe um detalhe que considero especialmente importante.
Malba Tahan não pertence apenas à história da literatura.
Pertence à história da educação brasileira.
Seu aniversário, 6 de maio, tornou-se o Dia Nacional da Matemática.
Isso não ocorreu porque ele descobriu uma nova constante matemática.
Nem porque formulou um teorema que carrega seu nome.
A homenagem existe porque ajudou a mudar a relação entre pessoas e matemática.
Essa distinção é belíssima.
Existem matemáticos que expandiram a matemática.
Malba ajudou a expandir o número de pessoas dispostas a entrar nela.
E isso também é ciência.
Divulgação importa.
Didática importa.
Curiosidade importa.
Uma ideia incompreensível é praticamente inútil para quem precisa aprendê-la.
🐫 O incidente dos 35 camelos deveria ser ensinado em TI
Aliás, suspeito que Beremiz seria um excelente arquiteto de sistemas.
Veja o famoso problema dos camelos.
O sistema possui uma restrição.
Os usuários estão brigando.
Os requisitos parecem incompatíveis.
A divisão não fecha.
O desenvolvedor tradicional poderia responder:
NOT POSSIBLE.
Ticket encerrado.
Beremiz faz outra coisa.
Ele muda temporariamente o estado do sistema.
Acrescenta um elemento.
Executa a distribuição.
Remove o excedente.
Problema resolvido.
Isso é praticamente:
temporary capacity provisioning.
Se Beremiz trabalhasse num mainframe provavelmente diria:
— Permita-me acrescentar momentaneamente uma unidade à capacidade disponível.
Depois faria alguma coisa incompreensível envolvendo WLM.
Todos receberiam exatamente os recursos prometidos.
E ainda sobrariam dois MSUs.
O gerente financeiro provavelmente o promoveria imediatamente.
🧙 Beremiz não é um gênio porque calcula rápido
Esse ponto merece cuidado.
Personagens matematicamente talentosos costumam ser apresentados como máquinas.
Calculam números absurdamente rápidos.
Memorizam milhares de dígitos.
Resolvem equações enormes mentalmente.
Beremiz é diferente.
Seu encanto não está apenas na velocidade.
Está na interpretação.
Ele percebe estrutura.
Vê relações.
Descobre simetria.
Reformula perguntas.
Isso aproxima o personagem de uma ideia moderna de inteligência.
A verdadeira habilidade não é possuir respostas.
É saber transformar o problema.
Quando você muda a pergunta, às vezes a resposta aparece sozinha.
Esse é um dos grandes segredos de investigação técnica.
Incidente:
“CPU está alta.”
Pergunta ruim:
— Como baixar CPU?
Pergunta Beremiz:
— Quem está usando CPU, quando começou, qual workload mudou e por que esse consumo apareceu agora?
De repente o problema virou outro.
E talvez CPU nem fosse o problema.
📈 Malba Tahan provavelmente entenderia IA perfeitamente
Agora vamos empurrar o camelo alguns quilômetros além.
Vivemos numa época curiosa.
Inteligência artificial produz respostas.
Muitas.
Rápidas.
Bonitas.
O perigo está em confundir produção de resposta com compreensão.
Malba provavelmente reconheceria imediatamente a armadilha.
Porque seu método não era:
Resposta → aluno.
Era:
Problema → curiosidade → raciocínio → história → descoberta.
Se simplesmente entregássemos a Beremiz uma máquina dizendo:
“Resultado: 17 camelos.”
perderíamos o melhor pedaço.
O caminho.
A surpresa.
A inversão.
Aquele instante em que o leitor pensa:
— Ahhhhhh.
Esse “ahhh” talvez seja a verdadeira unidade de medida da educação.
Poderíamos chamá-la de:
1 Tahan.
Um Tahan corresponde à quantidade mínima de compreensão necessária para um aluno olhar para algo aparentemente complicado e dizer:
— Agora entendi.
Mil Tahans formariam um Beremiz.
A ISO infelizmente ainda não aprovou o padrão.
📰 E o falso árabe venceu
A parte mais saborosa é pensar que a estratégia funcionou.
Malba Tahan tornou-se amplamente conhecido.
Escreveu dezenas de obras sob essa identidade.
O Homem que Calculava, publicado originalmente em 1938, atravessou gerações e ganhou enorme circulação.
O personagem imaginário tornou-se mais famoso do que o cidadão que o inventou.
É quase uma vingança literária.
Júlio queria que publicassem suas histórias.
Criou Malba.
Décadas depois estudantes aprendem:
— Malba Tahan era o pseudônimo de Júlio César de Mello e Souza.
Ou seja:
primeiro aprendemos o nome inventado.
Depois descobrimos o homem real.
A máscara virou rosto.
🪞 E aqui aparece o easter egg
Talvez o leitor já tenha percebido.
Este artigo não é apenas uma homenagem a Malba Tahan.
É também uma pequena demonstração de seu método.
Começamos com um escritor.
Encontramos um personagem.
Depois um camelo.
Então apareceu matemática.
Depois educação.
Depois arquitetura de sistemas.
Depois mainframe.
Depois inteligência artificial.
E agora estamos falando sobre como histórias transmitem conhecimento.
Ou seja:
o texto foi mudando enquanto caminhávamos.
Como uma caravana.
Esse é o easter egg.
Malba não está apenas sendo mencionado.
A estrutura está tentando imitá-lo.
🐪 Beremiz chega ao Bellacosa Mainframe
Imagino então uma cena.
Madrugada.
03h17.
Algum lugar de Itatiba.
Datacenter metafórico funcionando.
Café.
Logs.
Um terminal 3270 aberto.
De repente surge um homem trajando roupas persas.
Atrás dele, naturalmente, um camelo.
Segurança imediatamente abre chamado.
ICH408I BEREMIZ LOGON REJECTED.
O homem olha tranquilamente para o console.
Pergunta quantos jobs estão executando.
Quantos aguardam.
Qual a prioridade.
Qual a capacidade total.
Qual a distribuição.
O operador responde.
Beremiz pensa por alguns segundos.
— Há um erro.
O operador verifica.
Nada.
Beremiz aponta.
— Existem quarenta tarefas, mas vocês estão planejando capacidade como se fossem cinquenta.
Silêncio.
RMF é aberto.
WLM consultado.
SMF analisado.
Beremiz tinha razão.
Um workload havia sido duplicado por erro numa integração.
O gerente pergunta:
— Como descobriu?
Beremiz sorri.
— Contei os camelos.
☕ E Júlio César observa de longe
Talvez esta seja a parte mais bonita.
O verdadeiro homem desaparece lentamente atrás da própria obra.
Júlio César de Mello e Souza morreu em 1974.
Mas Malba continua.
Beremiz continua.
Os camelos continuam.
O problema continua sendo contado.
Professores continuam usando suas histórias.
A USP ainda produz materiais inspirados em seu trabalho e resgata seus problemas para novas gerações.
Isso é uma espécie de imortalidade bastante razoável.
Não aquela dos monumentos.
Mas a melhor.
Aquela em que alguém que nunca conheceu você continua usando uma ideia sua.
🧠 A verdadeira conta de Malba Tahan
Talvez a maior equação criada por Malba nunca tenha aparecido em seus livros.
É esta:
História + Curiosidade = Aprendizado
Mas podemos melhorá-la.
Beremiz certamente melhoraria.
Vamos acrescentar algumas variáveis:
Problema + Personagem + Curiosidade + Surpresa = Conhecimento memorável
Agora temos algo interessante.
Porque conhecimento sozinho pode ser esquecido.
Conhecimento ligado a emoção, narrativa ou descoberta costuma criar raízes.
É por isso que tanta gente não lembra de exercícios escolares.
Mas lembra dos camelos.
🕌 Maktub
Há uma palavra frequentemente associada ao universo de Malba Tahan.
Maktub.
Estava escrito.
Mas talvez, no caso dele, devêssemos fazer uma pequena alteração.
Não estava escrito.
Ele escreveu.
Escreveu Malba.
Escreveu Beremiz.
Escreveu desertos que nunca precisou habitar.
Escreveu sábios que nunca existiram.
Escreveu problemas matemáticos que continuam circulando.
E escrevendo essas coisas acabou escrevendo uma pequena parte da memória escolar brasileira.
Nada mal para um professor que resolveu inventar um árabe.
🐫 Epílogo — o camelo que sobrou
Quando terminamos uma boa história de Malba Tahan, frequentemente sobra alguma coisa.
Uma ideia.
Uma pergunta.
Uma pequena surpresa.
Então deixemos uma.
O famoso problema começa com 35 camelos.
Beremiz acrescenta um.
Trinta e seis.
Faz a divisão.
E ao final aparecem camelos excedentes.
Um deles volta para quem o emprestou.
O problema foi resolvido porque alguém introduziu temporariamente algo que aparentemente não pertencia ao problema.
Talvez esse tenha sido o grande truque de Malba Tahan.
Ele emprestava um camelo para a matemática.
O camelo chamava-se:
história.
A matemática fazia a viagem.
Depois o camelo voltava.
E o leitor ficava com a resposta.
☕ P.S. — Registro de acesso
Se algum arqueólogo digital encontrar este texto em 2126 e tentar descobrir por que existe um calculista persa andando de camelo dentro de um mainframe IBM, favor registrar:
🥢 O Homem Herbívoro – Entre o Silêncio e o Suspiro da Nova Masculinidade Japonesa
por El Jefe – Bellacosa Mainframe Edition
Há quem diga que o Japão é um laboratório social do futuro — um lugar onde as tensões do mundo moderno se manifestam primeiro, em alta definição. Entre trens lotados, karaokês melancólicos e cafés temáticos, surge um novo personagem que desconcerta as gerações anteriores: o “homem herbívoro”, ou em japonês, “sōshoku danshi” (草食男子) — literalmente, homem que se alimenta de plantas.
Mas calma, padawan. Não estamos falando de dieta, e sim de comportamento.
🌿 Origem do termo
O termo nasceu por volta de 2006, cunhado pela escritora e analista cultural Maki Fukasawa. Ela observava uma geração de jovens japoneses que pareciam desinteressados nas caçadas tradicionais do amor e do poder — sem pressa para namorar, casar, ter filhos, subir na empresa ou dirigir um carro esportivo.
Enquanto os “carnívoros” da geração anterior lutavam por status e paixão, os herbívoros apenas... existiam.
Tranquilos. Neutros. Gentis.
🧠 O que está por trás disso
No Japão, as pressões sociais são brutais: trabalhar até tarde, agradar o chefe, seguir o manual invisível da etiqueta e ainda sustentar uma família num país caríssimo. A geração pós-bolha econômica cresceu vendo os pais exaustos, sem tempo, sem sonho e sem sorriso.
Então o homem herbívoro surge como um protesto silencioso.
Ele não rejeita o amor, mas não o busca a qualquer custo.
Ele não persegue o sucesso, prefere a estabilidade.
Ele não quer dominar, quer coexistir.
Em resumo: é o antídoto pacífico para o samurai corporativo.
💬 Curiosidades e fofoquices sociológicas
Em 2010, uma pesquisa do Japan Times revelou que mais de 60% dos jovens homens entre 20 e 30 anos se identificavam, de alguma forma, com o perfil herbívoro.
As mídias ocidentais torceram o nariz, chamando-os de “desinteressados” ou “infantis”, mas dentro do Japão, eles representam uma mudança cultural profunda: a recusa em ser o que o sistema exige.
Muitos animes e dramas começaram a retratar personagens masculinos introspectivos, tímidos, com alma sensível — de Shinji Ikari (Evangelion) a Hachiman Hikigaya (Oregairu). Coincidência? Talvez não.
🗾 História, sociedade e um toque zen
No fundo, o homem herbívoro não é novo.
Ele é o eco moderno do monge zen que renuncia às paixões mundanas, do samurai aposentado que medita diante do jardim seco, do poeta haiku que encontra beleza na impermanência.
A diferença é que agora ele vive em Tóquio, toma café gelado e posta fotos melancólicas no Instagram.
⚙️ Reflexão à la Bellacosa Mainframe
Talvez o herbívoro não seja um sinal de fraqueza, mas de adaptação.
Num mundo onde todos correm, ele caminha.
Num tempo em que todos gritam, ele observa.
Enquanto o sistema empurra o ser humano a ser “mais” — mais produtivo, mais viril, mais conectado — ele escolhe o “menos”.
E há algo de revolucionário nisso.
Afinal, o verdadeiro ato de rebeldia pode ser não competir.
☕ Dica do El Jefe
Na próxima vez que a rotina te devorar, faz um teste:
Desliga as notificações.
Olha pela janela.
Respira devagar.
Pensa menos em conquistar e mais em compreender.
Talvez o herbívoro que existe dentro de nós só esteja pedindo um pouco de silêncio.
📨 ALAN TURING E O MQ DOS AGENTES — A MENSAGEM CHEGOU DUAS VEZES
IBM MQ, agentes de IA, mensageria, filas, producers, consumers, delivery semantics, acknowledgements, commit, rollback, duplicate delivery, idempotência, ordering, correlation ID, message ID, poison messages, backout queues, dead-letter queues, retry, persistence, request/reply, COBOL, CICS, Db2 — e o dia em que Alan Turing descobriu que uma mensagem pode chegar duas vezes sem que ninguém tenha cometido o mesmo erro duas vezes.
A qual conversa, fluxo ou solicitação ela pertence?
RUN-ID
Qual execução do agente está processando?
Isso será ouro para observabilidade.
🔗 CAPÍTULO 5 — CORRELATION ID: ENCONTRE A CONVERSA NO MEIO DO CAOS
Imagine:
REQUEST
MESSAGE-ID M100
CORREL-ID C500
O serviço responde:
RESPONSE
MESSAGE-ID M101
CORREL-ID C500
São mensagens diferentes.
Mas pertencem à mesma conversa.
Em sistemas distribuídos isso é extremamente útil.
Podemos seguir:
USER REQUEST
↓
CICS
↓
MQ
↓
AGENT
↓
Db2
↓
ANOTHER QUEUE
Tudo associado a:
CORRELATION-ID C500.
Quando alguém pergunta:
O que aconteceu com a solicitação do cliente?
não precisamos procurar agulha no palheiro.
📦 CAPÍTULO 6 — A MENSAGEM PODE SOBREVIVER AO CONSUMIDOR
Aqui está uma das grandes vantagens de mensageria confiável.
O producer envia.
PUT MESSAGE
O consumer está desligado.
A mensagem pode permanecer na fila conforme sua configuração e características.
Depois:
CONSUMER START
Ele processa.
Isso é muito diferente de uma chamada síncrona simples.
No mundo dos agentes isso é poderoso.
O LLM pode estar indisponível.
O worker pode reiniciar.
A aplicação pode sofrer manutenção.
A mensagem continua aguardando.
Mas agora surge uma pergunta:
Quanto tempo?
⏰ CAPÍTULO 7 — MENSAGENS TAMBÉM ENVELHECEM
Olha quem voltou.
Nosso amigo do Db2:
TEMPO.
Imagine:
MESSAGE CREATED:
10:00
O consumidor consegue processar:
14:00.
Tecnicamente a mensagem chegou.
Mas ainda faz sentido?
Talvez seja:
GENERATE MONTHLY REPORT
Sem problema.
Talvez seja:
CUSTOMER IS CURRENTLY LOGGED IN
Quatro horas depois?
Provavelmente inútil.
Logo mensagens também possuem:
AGE
EXPIRY
BUSINESS VALIDITY.
O MQ dos Agentes encontra o Db2 dos Agentes.
Não basta perguntar:
A mensagem chegou?
Pergunte:
Ela ainda significa alguma coisa quando chegou?
💥 CAPÍTULO 8 — A MENSAGEM CHEGOU DUAS VEZES
Finalmente chegamos ao monstro.
Imagine:
GET M001
O agente processa.
INSERT PAYMENT
COMMIT
Tudo certo.
Mas antes de completar adequadamente o ciclo de consumo:
CRASH.
Quando volta, dependendo da arquitetura e semântica empregada, a mensagem pode estar novamente disponível.
GET M001
O agente grita:
— Eu já processei isso!
A infraestrutura responde:
— Prove.
😂
Bem-vindo à possibilidade de:
REDELIVERY.
🧠 CAPÍTULO 9 — POR QUE DUPLICATAS EXISTEM?
Porque sistemas distribuídos possuem pontos de falha.
Considere:
MESSAGE
↓
PROCESS
↓
DATABASE UPDATE
↓
ACKNOWLEDGE
Agora imagine falha exatamente aqui:
DATABASE UPDATE
↓
COMMIT
↓
💀 CRASH
↓
ACKNOWLEDGE
Do ponto de vista do banco:
SUCCESS.
Do ponto de vista da mensageria:
NÃO SEI SE ELE TERMINOU.
O sistema possui duas escolhas ruins.
Escolha A
Assumir que processou.
Pode perder mensagem.
Escolha B
Entregar novamente.
Pode duplicar processamento.
Sistemas confiáveis frequentemente preferem não perder trabalho.
Então seu consumidor precisa estar preparado para duplicatas quando a semântica e arquitetura permitirem redelivery.
🔁 CAPÍTULO 10 — AT-LEAST-ONCE
Uma semântica comum em sistemas de mensageria e processamento distribuído é:
AT-LEAST-ONCE
Ou seja:
A mensagem será processada pelo menos uma vez.
Isso pode significar:
1
ou:
2
ou, em situações problemáticas:
mais.
Então:
AT-LEAST-ONCE
não significa:
EXACTLY-ONCE.
Se o efeito da mensagem não puder acontecer duas vezes, precisamos projetar proteção.
🎯 CAPÍTULO 11 — EXACTLY-ONCE É O UNICÓRNIO DA DUNGEON
Todo mundo quer:
EXACTLY ONCE.
A mensagem chega uma vez.
É processada uma vez.
O efeito acontece uma vez.
Perfeito.
Mas sistemas distribuídos possuem:
falhas
timeouts
restarts
partições
retries
E cada fronteira transacional complica o problema.
Se MQ e Db2 participam de uma unidade coordenada adequadamente, podemos obter garantias transacionais fortes em cenários específicos.
Mas quando nosso agente chama:
Db2
REST API
email
LLM
CRM SaaS
payment service
a conversa muda.
Nem todos participam da mesma transação.
Por isso é perigoso jogar:
EXACTLY-ONCE
num slide como se fosse magia.
🛡️ CAPÍTULO 12 — IDEMPOTÊNCIA ENTRA COM UMA ESPADA
A solução prática frequentemente passa por:
IDEMPOTÊNCIA.
Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indesejados depois da primeira aplicação bem-sucedida.
Exemplo perigoso:
ADD R$ 100 TO BALANCE
Execute duas vezes:
+100
+100
Resultado diferente.
Agora imagine:
SET PAYMENT P123 STATUS = PROCESSED
Executar novamente pode ser inofensivo dependendo da regra.
Ou:
PROCESS PAYMENT
WHERE PAYMENT_ID = P123
AND STATUS = PENDING
Depois da primeira execução:
STATUS = PROCESSED.
A segunda encontra:
NOT PENDING.
Nada acontece.
Muito melhor.
🪪 CAPÍTULO 13 — IDEMPOTENCY KEY
Outra técnica:
IDEMPOTENCY-KEY.
Exemplo:
IDEMPOTENCY-KEY = ORDER-9981-PAYMENT
Antes de executar:
SELECT STATUS
FROM PROCESSED_MESSAGES
WHERE IDEMPOTENCY_KEY = :KEY;
Se já existe:
ALREADY PROCESSED
não repetimos o efeito.
Se não existe:
PROCESS
STORE KEY
COMMIT
O detalhe crucial é tornar essa proteção suficientemente atômica para impedir dois consumidores concorrentes de passarem pela verificação simultaneamente.
Porque senão:
AGENT-A: não existe!
AGENT-B: não existe!
AGENT-A: processa!
AGENT-B: processa!
Parabéns.
Construímos uma deduplicação que duplica.
😂
🔐 CAPÍTULO 14 — MQ E Db2 PRECISAM CONVERSAR SOBRE COMMIT
Agora chegamos ao terreno favorito do mainframe.
Imagine:
MQGET
↓
UPDATE Db2
↓
COMMIT
Queremos que o consumo da mensagem e a alteração no banco tenham comportamento consistente.
Idealmente, dentro de um desenho transacional apropriado:
GET MESSAGE
+
UPDATE DATABASE
+
COMMIT
fazem parte de uma unidade lógica coerente.
Se falhar:
ROLLBACK.
A alteração do banco não fica pela metade e a mensagem pode permanecer disponível conforme a unidade de trabalho.
Esse é exatamente o tipo de problema que mainframes resolvem há décadas.
🧱 CAPÍTULO 15 — UNIT OF WORK VOLTOU
Nosso velho amigo:
UOW
Unit of Work.
Conceitualmente:
BEGIN UOW
GET MESSAGE
UPDATE DB2
INSERT AUDIT
COMMIT UOW
Se:
UPDATE DB2
falhar:
ROLLBACK.
O importante é definir claramente:
Quais efeitos pertencem à mesma unidade de consistência?
Para agentes, isso é essencial.
Porque eles tendem a fazer muitas coisas.
☠️ CAPÍTULO 16 — O PROBLEMA DAS AÇÕES EXTERNAS
Nosso agente:
GET MESSAGE
↓
UPDATE Db2
↓
SEND EMAIL
↓
CALL PAYMENT API
↓
POST MESSAGE
Rollback?
Db2:
— Posso ajudar.
MQ:
— Também.
E-mail:
— Já enviei.
API externa:
— Já cobrei.
Internet:
— Boa sorte.
😂
Essa é a fronteira entre transações locais/coordenadas e efeitos distribuídos externos.
SCHEMA......... OK
VERSION........ SUPPORTED
AUTHORITY...... OK
DUPLICATE...... NO
ORDER.......... OK
FRESHNESS...... OK
Consulta Db2.
CURRENT STATE.. VALID
Inicia unidade de trabalho.
PROCESS PAYMENT
INSERT AUDIT
REGISTER MESSAGE
Confirma.
COMMIT.
Resultado:
SUCCESS.
Alguns milissegundos depois:
💥
O worker cai.
Reinicia.
A mensagem aparece novamente.
O velho agente teria gritado:
Já fiz isso!
O novo apenas consulta:
IDEMPOTENCY-KEY = P88271.
Resposta:
ALREADY PROCESSED.
Nenhum pagamento duplicado.
Nenhuma madrugada destruída.
Nenhum DBA perseguindo robôs pelo corredor.
O agente registra:
DUPLICATE DELIVERY
BUSINESS EFFECT SKIPPED
STATUS = SAFE
Turing toma o primeiro café da manhã.
O programador pergunta:
— Então a duplicata deixou de ser um problema?
— Não.
— Mas não aconteceu nada.
— Exatamente.
O programador pensa.
Turing continua:
— Engenharia confiável não é construir um universo onde falhas nunca acontecem.
Aponta para a tela:
REDELIVERY DETECTED
— É construir um sistema no qual falhas esperadas deixam de virar desastres inesperados.
O pequeno robô levanta a mão.
— Professor?
— Sim?
— Posso apagar a mensagem de 1999?
Do outro lado do CPD o administrador MQ grita:
— NÃO! PRIMEIRO FAZ BACKUP!
😂
Turing fecha o terminal.
Na tela permanece:
MQ
────────────────────────
MESSAGE-ID...... M004821
DELIVERY........ 2
PROCESSING...... IDEMPOTENT
BUSINESS EFFECT. ONCE
STATUS.......... SAFE
COMMIT.......... OK
E embaixo:
A MENSAGEM PODE CHEGAR NOVAMENTE.
O EFEITO NÃO PRECISA ACONTECER NOVAMENTE.
Essa é talvez a grande lição do MQ dos Agentes.
Porque quando centenas de inteligências artificiais começarem a conversar entre si, delegando tarefas, publicando eventos, recebendo respostas, reiniciando workers, atravessando APIs, bancos, filas e nuvens, não bastará perguntar:
A mensagem chegou?
Teremos de perguntar:
Qual mensagem?
De quem?
Quando?
Em qual ordem?
Quantas vezes?
Ainda é válida?
Já foi processada?
O efeito foi confirmado?
Posso executar novamente?
E se eu cair exatamente agora?
O mainframe conhece essa paranoia há décadas.
E talvez por isso tenha tanta coisa para ensinar aos agentes.
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.
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
