✨ 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 e a segunda temporada de seijo no maryoku wa bannou desu
☕ Um Café no Bellacosa Mainframe
Seijo no Maryoku wa Bannou Desu 2 (聖女の魔力は万能です Season 2): O Upgrade sem Janela de Manutenção — Quando a Santa Descobre que Escalar um Sistema é Mais Difícil do que Construí-lo
"Construir um sistema confiável é uma conquista. Mantê-lo disponível enquanto milhões de usuários dependem dele é o verdadeiro desafio. A segunda temporada de Seijo no Maryoku wa Bannou Desu mostra exatamente essa evolução: sair da fase de implantação para a operação contínua de um ambiente de missão crítica."
Ficha Técnica
Item
Informação
Título original
聖女の魔力は万能です Season 2
Título internacional
The Saint's Magic Power is Omnipotent Season 2
Baseado na Light Novel
聖女の魔力は万能です
Autor
Yuka Tachibana
Ilustrações
Yasuyuki Syuri
Mangá
Fujiazuki
Estúdio
Diomedéa
Diretor
Shouta Ibata
Roteiro
Wataru Watari
Música
Kenichi Kuroda
Lançamento
Outubro de 2023
Episódios
12
Gênero
Isekai, Fantasia, Romance, Slice of Life, Magia, Drama
Classificação
12 anos
A segunda temporada muda completamente o foco
A primeira temporada respondia:
"Quem é a Santa?"
A segunda pergunta algo muito mais complexo:
"Como administrar um mundo inteiro depois que todos descobrem quem é a Santa?"
É exatamente a diferença entre:
instalar um ambiente IBM Z;
e
administrá-lo pelos próximos vinte anos.
É aí que começa o verdadeiro trabalho.
O Studio Diomedéa amadurece junto com a obra
Na segunda temporada a Diomedéa demonstra maior confiança na narrativa.
Não há necessidade de acelerar acontecimentos nem de criar batalhas artificiais. A direção aposta em diálogos mais longos, desenvolvimento emocional e construção gradual das relações.
A animação continua discreta, mas consistente: cenários detalhados, paleta de cores suave e magia apresentada como algo elegante e controlado, reforçando a sensação de estabilidade em vez de espetáculo.
Sinopse
Depois de salvar o reino inúmeras vezes...
Sei finalmente é reconhecida como a verdadeira Santa.
O reino vive uma relativa estabilidade graças às ações da Santa, mas novas missões, alianças políticas e pesquisas exigem que Sei amplie sua atuação. Ela viaja, participa de investigações sobre fenômenos mágicos, fortalece laços com diferentes regiões e enfrenta desafios que não podem ser resolvidos apenas com poder.
Ao mesmo tempo, o relacionamento entre Sei e Albert Hawke evolui de forma natural, mostrando que confiança e parceria se constroem lentamente.
A narrativa enfatiza responsabilidade, diplomacia e maturidade, substituindo a urgência da descoberta pelo desafio de sustentar resultados.
Os Personagens evoluem
Sei Takanashi
Agora não precisa provar quem é.
Sua preocupação muda.
Ela pergunta:
Como posso ajudar mais pessoas?
É a mentalidade de um excelente Sysprog.
Não pensa em tecnologia.
Pensa em disponibilidade.
Albert Hawke
Deixa de ser apenas interesse romântico.
Torna-se parceiro.
Protege Sei.
Mas nunca limita sua autonomia.
É um relacionamento extremamente saudável.
Johan Valdec
Continua sendo o gestor ideal.
Nunca microgerencia.
Dá recursos.
Confia.
Remove obstáculos.
Todo gerente de TI deveria assistir este personagem.
Yuri Drewes
Assume papel ainda mais importante.
Representa o arquiteto veterano.
Compartilha conhecimento.
Forma sucessores.
Não centraliza informação.
Aira
Também amadurece bastante.
A obra mostra que ela nunca foi uma rival.
Apenas outra pessoa tentando encontrar seu lugar.
As Aventuras
A segunda temporada privilegia missões de impacto estratégico:
pesquisas sobre novas plantas e ingredientes raros;
investigações envolvendo regiões afetadas por energia mágica;
viagens diplomáticas e encontros com diferentes nobres;
aperfeiçoamento dos poderes da Santa;
apoio às expedições dos cavaleiros;
fortalecimento das relações entre ciência, magia e administração do reino.
Cada missão demonstra que manter um ambiente estável exige monitoramento contínuo, cooperação e adaptação.
A Temática Principal
A palavra-chave é:
responsabilidade.
Não basta ser competente.
É preciso:
formar equipes;
ensinar;
documentar;
compartilhar conhecimento;
construir confiança.
Isso lembra diretamente ambientes corporativos de missão crítica, nos quais uma única pessoa não pode concentrar todo o conhecimento operacional.
O que existe de diferente nesta temporada?
Praticamente tudo.
A primeira temporada era descoberta.
A segunda é consolidação.
Ela troca:
aventura
por
crescimento profissional.
Troca:
magia
por
gestão.
Troca:
descobertas
por
maturidade.
É um anime sobre carreira.
Não sobre poder.
A metáfora Mainframe
Toda a segunda temporada lembra uma grande infraestrutura IBM Z.
Anime
IBM Mainframe
Santa
Arquiteta Corporativa
Reino
Empresa Global
Instituto
Centro de Excelência
Cavaleiros
Operações
Magia Sagrada
Middleware
Pesquisa
Melhoria Contínua
Purificação
Correção de Incidentes
Viagens
Auditorias
Monstros
Falhas Críticas
Reino Seguro
SLA Cumprido
As mensagens ocultas
1. O sucesso cria novas responsabilidades
Na primeira temporada...
ninguém conhecia Sei.
Agora...
todos dependem dela.
É exatamente o que acontece com especialistas de infraestrutura.
2. Conhecimento precisa ser compartilhado
Se apenas uma pessoa sabe tudo...
o sistema é frágil.
A obra valoriza colaboração e formação de novos especialistas.
3. Liderança é serviço
Sei nunca usa seu prestígio para mandar.
Ela influencia pelo exemplo.
4. Confiança leva anos para ser construída
O romance segue essa lógica.
As amizades também.
Assim como a reputação profissional.
5. Nem todo problema exige violência
Boa parte dos conflitos é resolvida por pesquisa, negociação e empatia, reforçando que inteligência e cooperação podem ser mais eficazes do que força.
Aspectos técnicos da animação
A direção mantém um ritmo contemplativo, com boa integração entre trilha sonora e ambientação. As cenas de magia utilizam efeitos luminosos delicados e enquadramentos que destacam emoções e paisagens, evitando exageros visuais. Embora o orçamento não rivalize com grandes produções do gênero, a consistência artística favorece a imersão.
Impacto Cultural
A segunda temporada consolidou a reputação da franquia como um dos isekais mais voltados ao público adulto que busca histórias tranquilas e protagonistas competentes. Ela reforçou o espaço de obras com romance saudável, crescimento pessoal e foco em trabalho especializado, mostrando que o gênero pode ser interessante sem depender de batalhas incessantes ou de um protagonista excessivamente poderoso.
Houve censura?
Não existem registros relevantes de censura envolvendo a segunda temporada. A adaptação manteve o tom da light novel, realizando apenas cortes e reorganizações de eventos para adequar o conteúdo ao formato de 12 episódios. Essas alterações são típicas de adaptações para televisão e não refletem censura de conteúdo.
Classificação
Classificação indicativa sugerida:12 anos
Contém:
fantasia medieval;
magia;
romance;
ação moderada;
monstros;
temas de responsabilidade e amadurecimento.
É uma obra apropriada para quem prefere histórias focadas em desenvolvimento de personagens e relações humanas.
O grande ensinamento para profissionais de Mainframe
A primeira temporada mostrava como descobrir uma especialista extraordinária.
A segunda responde a uma pergunta ainda mais importante:
Como impedir que toda uma infraestrutura dependa de apenas uma pessoa?
Essa é uma das maiores preocupações de qualquer ambiente IBM Z. Um sistema pode sobreviver a falhas de hardware graças à redundância e à alta disponibilidade, mas sofre quando o conhecimento está concentrado em um único profissional.
Sei compreende que sua verdadeira missão não é apenas resolver incidentes, e sim criar processos sustentáveis, desenvolver outras pessoas e fortalecer instituições para que continuem funcionando mesmo quando ela não estiver presente.
É exatamente essa visão que diferencia um operador competente de um arquiteto de missão crítica.
No universo Bellacosa Mainframe, a segunda temporada de Seijo no Maryoku wa Bannou Desu não é sobre magia. É sobre governança, continuidade operacional, gestão do conhecimento e evolução de uma plataforma que precisa permanecer disponível 24 horas por dia, sete dias por semana. A verdadeira Santa não é a que lança o feitiço mais poderoso, mas a que garante que todo o reino continue funcionando sem downtime.
Bellacosa Mainframe e o ibm mq muito alem das filas
IBM MQ: Muito Além das Filas — A Engenharia Invisível que Mantém Grandes Empresas em Movimento
"Se o banco autorizou seu PIX, a companhia aérea confirmou sua passagem e a operadora aprovou sua compra no cartão em poucos segundos, existe uma boa chance de que o IBM MQ tenha participado dessa conversa silenciosa entre sistemas."
A comparação entre administrar filas de mensagens e controlar o tráfego aéreo é extremamente feliz. Em ambos os casos, o objetivo não é apenas transportar algo de um ponto ao outro, mas garantir que cada "passageiro" (mensagem) chegue ao destino correto, na ordem adequada, sem colisões, sem perdas e com total rastreabilidade.
É justamente essa capacidade que fez do IBM MQ um dos pilares da integração corporativa por mais de três décadas.
Enquanto novas tecnologias aparecem todos os anos, o MQ permanece praticamente onipresente em bancos, seguradoras, bolsas de valores, empresas de logística, telecomunicações, governos e indústrias.
Isso acontece porque ele resolve um problema que nunca deixou de existir:
Como permitir que dezenas ou centenas de sistemas diferentes conversem entre si de forma confiável?
O verdadeiro problema não é enviar mensagens
Enviar uma mensagem é fácil.
Um socket TCP faz isso.
Uma API REST também.
Um POST HTTP consegue transportar informações perfeitamente.
O problema começa quando surgem perguntas muito mais difíceis:
E se o sistema destino estiver indisponível?
E se a rede cair durante a transmissão?
E se o consumidor estiver mais lento que o produtor?
E se houver milhares de mensagens por segundo?
Como garantir que nenhuma mensagem seja perdida?
Como recuperar mensagens após um desastre?
Como processar tudo exatamente uma única vez?
É aqui que o IBM MQ mostra por que continua sendo referência.
Ele não é apenas um mecanismo de envio.
Ele é um sistema completo de entrega garantida.
Local Queues: o coração do Queue Manager
O texto começa destacando as Local Queues.
Pode parecer apenas um objeto simples.
Na prática, elas representam o ponto onde toda a arquitetura converge.
Quando um programa COBOL executa:
MQPUT
ele normalmente está gravando em uma Local Queue.
Quando um programa Java faz:
put(message)
também.
Quando um serviço REST recebe uma requisição e publica uma mensagem...
...novamente estamos falando de uma Local Queue.
Ela é o "disco de pouso" das mensagens.
O ciclo de vida de uma fila
O artigo cita o CRUD clássico.
Mas cada comando tem implicações importantes.
DEFINE
Criar uma fila significa estabelecer diversas políticas:
persistência
tamanho máximo
profundidade
prioridade
triggering
cluster
segurança
compartilhamento
Não é simplesmente "criar uma pasta".
É definir comportamento operacional.
LIKE
Pouca gente utiliza adequadamente:
DEFINE QLOCAL(NOVA.FILA)
LIKE(FILA.MODELO)
Esse comando economiza horas.
Imagine uma organização com:
MAXDEPTH
DEFPSIST
SHARE
TRIGGER
MONQ
HARDENBO
todos configurados segundo padrões corporativos.
Copiar a definição evita inconsistências.
Em ambientes regulados isso é praticamente obrigatório.
ALTER
Alterar filas em produção exige cuidado.
Exemplo:
ALTER QLOCAL(PAGAMENTOS)
MAXDEPTH(500000)
Parece inocente.
Mas alterar atributos pode afetar:
performance
consumo de disco
comportamento das aplicações
Administradores experientes sempre avaliam o impacto antes de executar alterações.
CLEAR
Este comando merece respeito.
CLEAR QLOCAL(TESTE)
Ele elimina todas as mensagens.
Não existe "desfazer".
Jamais deve ser utilizado em produção sem absoluta certeza.
DELETE
Excluir uma fila exige planejamento.
Muitas aplicações dependem daquele objeto.
Apagar uma queue errada pode derrubar diversos sistemas ao mesmo tempo.
Filas maiores que 2 TB
Esse detalhe passa despercebido por muitos profissionais.
Quando pensamos em filas normalmente imaginamos alguns megabytes.
Na realidade, grandes bancos mantêm milhões de mensagens simultaneamente.
Imagine:
processamento noturno
liquidação financeira
cartões
PIX
TED
boletos
Durante picos, enormes volumes permanecem temporariamente armazenados.
O MQ foi projetado para esse cenário.
Remote Queues: desacoplamento arquitetural
Talvez este seja o ponto mais elegante do artigo.
Uma Remote Queue não contém mensagens.
Ela contém conhecimento.
Conhecimento sobre onde determinada mensagem deve chegar.
Esse conceito é chamado de indireção.
Na Engenharia de Software, indireção é uma das técnicas mais poderosas para reduzir acoplamento.
Sem Remote Queue
Aplicação precisa conhecer:
servidor
porta
canal
queue manager
fila destino
Toda alteração exige nova implantação.
Com Remote Queue
A aplicação apenas envia:
MQPUT
CLIENTES
O administrador decide:
qual servidor
qual Queue Manager
qual canal
qual rota
A aplicação permanece completamente ignorante da infraestrutura.
Esse desacoplamento reduz drasticamente custos de manutenção.
Uma analogia simples
Imagine enviar uma carta.
Sem MQ:
Você escreve diretamente o endereço completo.
Se o destinatário mudar de prédio, precisa reenviar todas as cartas.
Com MQ:
Você entrega a carta para a central de distribuição.
Ela sabe exatamente para onde encaminhar.
O remetente nunca precisa conhecer a rota.
RNAME, RQMNAME e XMITQ
Esses três atributos representam praticamente a tabela de roteamento do MQ.
RNAME
Destino real.
PAGAMENTOS
RQMNAME
Qual Queue Manager administra essa fila.
Pode estar em outra cidade.
Outro país.
Outro datacenter.
XMITQ
A "rodovia".
Ela guarda mensagens enquanto aguardam transporte.
Caso a comunicação seja interrompida, elas permanecem armazenadas.
Quando o canal voltar, seguem viagem automaticamente.
É uma fila de espera extremamente inteligente.
A beleza da transparência
O usuário destaca um benefício enorme:
Trocar infraestrutura sem alterar código.
Esse talvez seja o maior presente que um administrador pode oferecer aos desenvolvedores.
Mudanças ficam concentradas na infraestrutura.
Aplicações permanecem intactas.
Essa separação de responsabilidades é um princípio clássico de arquitetura corporativa.
Model Queues
Pouca gente conhece.
Menos gente ainda utiliza.
Imagine milhares de clientes conectados simultaneamente.
Cada um precisa de uma fila temporária.
Criar manualmente seria impossível.
A Model Queue resolve isso.
Ela funciona como uma classe em programação orientada a objetos.
A partir dela o MQ cria filas temporárias dinamicamente.
É extremamente elegante.
Services
Outro recurso subestimado.
Muitos sistemas precisam iniciar automaticamente processos auxiliares.
Por exemplo:
daemon Java
listener
programa C
script Shell
Em vez de depender do sistema operacional, o próprio MQ pode controlar esse ciclo de vida.
Resultado:
menos scripts
menos automações
menos pontos de falha.
Triggering
Aqui entramos em automação pura.
Imagine um supermercado.
Quando chegam dez clientes na fila do caixa...
automaticamente outro caixa é aberto.
Triggering faz exatamente isso.
Quando uma fila atinge determinada condição:
inicia um programa
desperta um consumidor
executa um processamento Batch
chama um serviço
Sem intervenção humana.
É um dos recursos mais antigos do MQ e continua extremamente eficiente.
dmpmqmsg
Administradores antigos ainda chamam de qload.
É praticamente um "canivete suíço".
Permite:
backup
restauração
migração
cópia
exportação
importação
Durante migrações entre ambientes ele costuma ser indispensável.
O comentário mais importante
O autor encerra com uma observação extremamente verdadeira:
A maioria dos problemas não está no IBM MQ.
Quem administra middleware sabe disso.
Quando algo "não chega", normalmente o MQ está funcionando exatamente como deveria.
Os problemas costumam estar em:
aplicações
canais bloqueados
certificados expirados
permissões OAM
firewalls
DNS
Cluster Receiver
Channel Authentication (CHLAUTH)
SSL/TLS
regras de roteamento
filas de transmissão congestionadas
O MQ normalmente apenas evidencia problemas existentes em outras camadas.
Linha de comando versus MQ Explorer
Essa pergunta desperta quase uma divisão filosófica.
porque conseguem reproduzir alterações em dezenas de servidores utilizando exatamente os mesmos comandos.
Infrastructure as Code começa justamente aqui.
Uma reflexão arquitetural
O maior mérito do IBM MQ nunca foi apenas transportar mensagens.
Seu verdadeiro valor está em separar aplicações da infraestrutura.
Essa separação permite que empresas mudem servidores, troquem sistemas operacionais, modernizem datacenters, migrem para containers, integrem APIs REST, conectem aplicações em nuvem e mantenham sistemas COBOL escritos há décadas funcionando exatamente da mesma forma.
É uma demonstração clássica de engenharia de software bem executada: o produtor não precisa conhecer o consumidor, o consumidor não precisa conhecer o produtor e ambos continuam evoluindo de forma independente. Esse desacoplamento reduz riscos, facilita modernizações graduais e garante continuidade operacional — razão pela qual o IBM MQ permanece essencial em arquiteturas de missão crítica, mesmo em uma era dominada por microsserviços, APIs REST, eventos e plataformas em nuvem.
Em outras palavras, o IBM MQ não é apenas um produto de mensageria. Ele é uma camada estratégica de integração que protege as aplicações das mudanças inevitáveis da infraestrutura, permitindo que empresas inovem sem comprometer a estabilidade de seus sistemas mais críticos. É essa combinação de confiabilidade, escalabilidade e abstração que explica por que, mais de 30 anos após seu lançamento, o IBM MQ continua sendo um dos componentes mais respeitados e utilizados no ecossistema IBM Z e nas grandes arquiteturas corporativas.
Censura ou Proteção? Por Que as Sociedades Continuam Tentando Controlar Ideias?
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Psicologia, Sociologia, Poder, Liberdade de Expressão e Por Que Controlar Informações Sempre Foi Uma Tentação Humana
"Um Sysprog não protege um Mainframe apagando programas. Ele define permissões, auditoria e níveis de acesso. Talvez essa diferença explique um dos maiores debates da civilização."
Introdução
Existe uma pergunta que atravessa séculos.
Por que sociedades tentam controlar ideias?
Mudam os governos.
Mudam as religiões.
Mudam as tecnologias.
Mudam os meios de comunicação.
Mas a tentativa de controlar informações continua aparecendo ao longo da história.
Livros já foram proibidos.
Bibliotecas foram destruídas.
Filmes sofreram cortes.
Peças de teatro foram censuradas.
Músicas foram proibidas.
Jornais foram fechados.
Hoje o debate ocorre em torno de redes sociais, algoritmos, plataformas digitais, inteligência artificial e leis relacionadas ao discurso online.
A questão, porém, permanece praticamente a mesma desde a Antiguidade.
Quem deve decidir quais ideias podem circular?
Essa pergunta não possui uma resposta simples.
Porque ela coloca em conflito dois valores fundamentais.
De um lado:
liberdade de expressão;
pluralidade de ideias;
livre circulação do conhecimento.
Do outro:
proteção contra danos;
segurança pública;
combate à violência;
proteção de crianças;
preservação da democracia.
O problema é que diferentes sociedades desenham essa fronteira de maneiras diferentes.
O Mainframe Nunca Resolve Um Problema Apagando Programas
Imagine um banco executando milhares de aplicações críticas.
Existe software para RH.
Outro para cartões.
Outro para PIX.
Outro para investimentos.
Outro para auditoria.
Se um funcionário não deve acessar determinado sistema, qual seria a solução?
Apagar o programa?
Obviamente não.
O administrador define:
autenticação;
autorização;
perfis;
logs;
trilhas de auditoria;
níveis diferentes de acesso.
Na engenharia de software chamamos isso de controle de acesso.
Na sociedade, o debate costuma ser mais complexo.
A História Mostra Que Toda Sociedade Regulou Informação
Não existe civilização conhecida completamente livre de algum tipo de controle sobre a informação.
Impérios antigos controlavam escribas.
Monarquias controlavam impressoras.
Ditaduras controlavam jornais.
Democracias também estabelecem limites jurídicos para determinadas categorias de discurso, embora esses limites variem bastante entre países.
Os motivos apresentados também variam.
Proteção da moral.
Segurança nacional.
Religião.
Combate ao discurso de ódio.
Proteção infantil.
Combate à desinformação.
Defesa da ordem pública.
Isso não significa que todas essas justificativas sejam equivalentes ou produzam os mesmos resultados.
Significa apenas que o debate acompanha praticamente toda a história humana.
Michel Foucault e a Relação Entre Poder e Discurso
Michel Foucault argumentava que conhecimento e poder caminham juntos.
Quem influencia quais discursos são considerados legítimos também influencia a forma como uma sociedade compreende a realidade.
Isso não significa que exista uma única autoridade controlando tudo.
Significa que instituições, normas, escolas, meios de comunicação e leis participam da construção do que é considerado aceitável em determinada época.
Antonio Gramsci e a Hegemonia Cultural
Antonio Gramsci utilizou o conceito de hegemonia cultural.
Segundo sua análise, grupos procuram consolidar sua visão de mundo como se fosse simplesmente o "bom senso".
Quando isso acontece, determinadas ideias passam a parecer naturais, enquanto outras se tornam marginais.
Independentemente de concordar ou não com Gramsci, sua teoria influenciou profundamente a sociologia contemporânea.
Durkheim e a Coesão Social
Émile Durkheim observou que toda sociedade necessita de algum grau de normas compartilhadas para funcionar.
Sem qualquer consenso mínimo, instituições tornam-se instáveis.
O desafio aparece quando surge a pergunta:
Quanto consenso é necessário antes que a diversidade de opiniões seja sufocada?
Essa tensão permanece atual.
Karl Popper e o Paradoxo da Tolerância
Karl Popper apresentou um argumento muito discutido.
Uma sociedade completamente tolerante pode acabar sendo destruída por movimentos profundamente intolerantes.
Daí surgiu o chamado Paradoxo da Tolerância.
A ideia não é que qualquer opinião deva ser proibida, mas que sociedades precisam refletir sobre como responder quando determinados discursos buscam eliminar a própria possibilidade de convivência plural.
Até hoje existe intenso debate sobre onde exatamente traçar essa linha.
Jonathan Haidt e a Psicologia Moral
Jonathan Haidt propõe que julgamentos morais são fortemente influenciados por intuições.
Primeiro sentimos.
Depois racionalizamos.
Isso ajuda a explicar por que debates públicos frequentemente se tornam emocionais.
Cada grupo acredita estar protegendo algo essencial.
Liberdade.
Segurança.
Justiça.
Igualdade.
Tradição.
Cada valor enfatizado produz conclusões diferentes.
O Viés da Confirmação
Um dos mecanismos psicológicos mais estudados é o viés da confirmação.
Naturalmente buscamos informações que reforcem aquilo que já acreditamos.
Também tendemos a dar menos peso às evidências que desafiam nossas convicções.
Esse fenômeno não pertence a uma ideologia específica.
É um traço humano amplamente documentado.
Quando combinado com algoritmos de recomendação, pode favorecer ambientes informacionais mais homogêneos.
Cass Sunstein e as Câmaras de Eco
O jurista Cass Sunstein estudou como grupos compostos por pessoas com opiniões semelhantes tendem a se tornar mais extremos ao longo do tempo.
Esse processo é chamado de polarização de grupo.
Quanto menor a exposição a ideias divergentes, maior a possibilidade de radicalização.
É um dos motivos pelos quais pesquisadores defendem o contato com perspectivas diferentes.
A Espiral do Silêncio
Elisabeth Noelle-Neumann argumentou que muitas pessoas deixam de expressar opiniões quando acreditam que estão isoladas.
Mesmo sem qualquer censura formal, o medo da rejeição social pode reduzir a diversidade de vozes.
Isso mostra que autocensura e censura institucional não são fenômenos idênticos, embora possam produzir efeitos semelhantes sobre o debate público.
Em muitos casos, a tentativa de eliminar uma obra acabou aumentando sua notoriedade.
Controlar objetos é mais simples do que controlar ideias.
Classificação Indicativa e Censura Não São a Mesma Coisa
Essa distinção é importante.
Em muitos países existe classificação por idade para:
filmes;
jogos;
televisão;
plataformas digitais.
O objetivo costuma ser orientar responsáveis sobre conteúdos potencialmente inadequados para determinadas faixas etárias.
Já a censura envolve impedir ou restringir a circulação de conteúdos para além desse tipo de classificação.
Na prática, porém, as fronteiras podem gerar debates e variar conforme a legislação e o contexto histórico de cada país.
Por Que Nem Tudo É Resolvido Apenas Com Classificação Etária?
Essa é uma pergunta recorrente.
Os argumentos apresentados por quem defende medidas além da classificação variam conforme o tema.
Entre eles aparecem preocupações como:
alcance extremamente rápido nas redes;
recomendação algorítmica;
dificuldade de verificar idade em ambientes digitais;
conteúdos ilegais;
campanhas coordenadas;
proteção de grupos vulneráveis.
Por outro lado, críticos dessas medidas argumentam que regras excessivamente amplas podem reduzir a liberdade de expressão, favorecer abusos de poder e inibir o debate legítimo.
É justamente por isso que o tema permanece controverso.
O Papel das Democracias
Em democracias constitucionais, uma questão central costuma ser:
Quem decide?
Parlamentos?
Tribunais?
Agências reguladoras?
Empresas privadas?
Plataformas digitais?
Cada modelo possui vantagens e riscos.
Concentrar poder em qualquer ator pode gerar preocupações sobre transparência, prestação de contas e possibilidade de erro.
O Risco da Censura e o Risco da Ausência Total de Regras
O debate público frequentemente apresenta um falso dilema.
Ou liberdade absoluta.
Ou controle absoluto.
Na prática, poucas sociedades adotam qualquer um desses extremos.
A maioria busca algum tipo de equilíbrio.
A dificuldade está em definir:
quais limites são legítimos;
quem os estabelece;
como revisá-los;
quais garantias existem contra abusos.
Essas perguntas talvez sejam mais importantes do que respostas simplistas.
O Mainframe Ensina Outra Lição
Em um IBM Z, segurança não significa impedir tudo.
Também não significa permitir tudo.
Significa definir regras claras.
Registrar eventos.
Auditar decisões.
Revisar permissões.
Criar mecanismos de recurso quando algo dá errado.
Talvez esse raciocínio seja útil também para instituições humanas.
Quanto maior o poder de restringir informações, maior deve ser a transparência, a possibilidade de contestação e a supervisão independente.
O Que Dizem Muitos Especialistas?
Embora existam divergências profundas, alguns pontos aparecem com frequência em diferentes áreas do conhecimento:
educação midiática tende a ser vista como complemento importante às regras formais;
transparência sobre critérios de moderação aumenta confiança;
decisões revisáveis reduzem riscos de arbitrariedade;
pluralidade institucional costuma ser considerada mais saudável do que concentração de poder decisório;
pensamento crítico continua sendo uma das melhores defesas contra manipulação.
Esses consensos parciais não eliminam os desacordos sobre casos concretos, mas mostram caminhos debatidos por pesquisadores.
Conclusão
Talvez a pergunta mais importante não seja:
"Devemos permitir tudo?"
Nem:
"Devemos proibir tudo?"
Talvez seja outra.
"Como construir uma sociedade suficientemente livre para produzir inovação, crítica e diversidade de ideias, mas também suficientemente responsável para enfrentar danos reais sem transformar exceções em regra?"
Essa pergunta não será respondida por um algoritmo.
Nem por uma única ideologia.
Nem por uma única geração.
Assim como um Sysprog sabe que estabilidade depende de equilíbrio entre desempenho, disponibilidade e segurança, sociedades também precisam equilibrar valores que frequentemente entram em tensão.
Liberdade sem responsabilidade pode produzir danos.
Responsabilidade sem liberdade pode sufocar criatividade, ciência e debate.
A história mostra que nenhuma civilização resolveu definitivamente esse dilema.
Cada geração precisa enfrentá-lo novamente.
E talvez essa seja justamente a maior lição.
Os maiores desafios da humanidade raramente são problemas de software.
São problemas de arquitetura institucional, natureza humana e convivência social.
Porque, no fim, proteger uma sociedade não significa apenas proteger pessoas contra ideias perigosas; também significa proteger a própria capacidade da sociedade de discutir, questionar e revisar suas ideias ao longo do tempo.
🧠 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
