✨ 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
IA, Claude Code, watsonx, IBM Z e a Verdadeira História do COBOL em 2026
"Padawan, sempre desconfie de quem anuncia a morte do mainframe. Normalmente essa notícia foi escrita em um computador que acabou de consultar um banco de dados hospedado... em um mainframe."
Existe uma tradição curiosa na indústria de tecnologia.
A cada cinco ou seis anos alguém decreta a morte do COBOL.
Na década de 1990 disseram que o cliente-servidor acabaria com o IBM Z.
Nos anos 2000 foi a Internet.
Depois veio Java.
Em seguida SOA.
Cloud.
Containers.
Kubernetes.
Microservices.
Serverless.
Blockchain.
Metaverso.
Agora chegou a Inteligência Artificial Generativa.
E, em julho de 2026, bastou a Anthropic publicar demonstrações mostrando o Claude Code analisando aplicações COBOL para surgir uma nova manchete:
"A IA acabou de matar o COBOL."
Será?
Pegue sua caneca de café, sente-se diante do terminal 3270 e vamos separar o hype da realidade.
O nascimento de um gigante
COBOL nasceu oficialmente em 1959.
Mas entender essa data exige voltar alguns anos.
Naquela época cada fabricante possuía sua própria linguagem.
Programas escritos para um computador dificilmente funcionavam em outro.
Isso era um enorme problema para governos, bancos e grandes empresas.
Foi então que surgiu o CODASYL (Conference on Data Systems Languages), patrocinado pelo Departamento de Defesa dos Estados Unidos.
O objetivo era simples.
Criar uma linguagem voltada para negócios.
Portável.
Legível.
Fácil de manter.
Nascia o COmmon Business-Oriented Language.
Curiosamente, muitas ideias daquele projeto continuam extremamente atuais.
O verdadeiro objetivo nunca foi velocidade
Quando um padawan começa a estudar programação costuma perguntar:
"COBOL é rápido?"
Essa pergunta já começa errada.
COBOL nunca tentou ser o mais rápido.
Nunca tentou ser elegante.
Nunca tentou ser compacto.
Ele tentou ser compreensível.
Observe:
ADD TAX-AMOUNT TO TOTAL-AMOUNT.
READ CUSTOMER-FILE.
MOVE CUSTOMER-NAME TO REPORT-LINE.
Mesmo alguém que nunca estudou COBOL consegue imaginar o que está acontecendo.
Na década de 1960 isso era revolucionário.
Enquanto outras linguagens eram quase criptográficas, COBOL parecia inglês estruturado.
Essa legibilidade explica por que programas escritos há quarenta anos ainda conseguem ser compreendidos e evoluídos.
O fantasma que movimenta trilhões
Uma das frases mais repetidas na Internet diz:
"95% dos caixas eletrônicos usam COBOL."
Embora a ideia geral esteja correta — COBOL continua extremamente presente no setor financeiro — esse número varia conforme a fonte e normalmente mistura transações bancárias, processamento de cartões e sistemas legados.
A realidade de 2026 é mais interessante do que qualquer porcentagem isolada.
Milhões de linhas COBOL continuam executando diariamente operações críticas em:
bancos
seguradoras
bolsas de valores
companhias aéreas
empresas de logística
previdência
processamento de impostos
sistemas de saúde
governos
Mais importante do que discutir se são 80%, 90% ou 95% das transações é entender por que esses sistemas continuam existindo.
O segredo não é COBOL
Muitos jornalistas acreditam que o problema está na linguagem.
Não está.
O verdadeiro patrimônio é o conhecimento do negócio.
Imagine um programa que calcula juros.
Ele possui um IF aparentemente simples.
Por trás daquele IF podem existir:
quarenta anos de mudanças regulatórias;
decisões judiciais;
exceções para determinados produtos;
alterações tributárias;
acordos internacionais;
regras de auditoria;
exigências do Banco Central.
A IA consegue traduzir o código.
Mas ela não consegue deduzir, sozinha, por que aquela regra existe.
Esse conhecimento foi acumulado por gerações de analistas, arquitetos, desenvolvedores e especialistas do negócio.
O ecossistema IBM Z
Outro erro comum é imaginar que um sistema bancário seja apenas um programa COBOL.
Na prática, ele vive dentro de um enorme ecossistema.
Um único programa pode conversar com:
Db2 for z/OS
IMS
CICS
MQ
VSAM
QSAM
RACF
JES2
WLM
SMF
DFSMS
z/OS Connect
APIs REST
filas distribuídas
aplicações Linux on Z
microsserviços em OpenShift
Quando alguém diz:
"Vamos migrar esse programa."
Na verdade está dizendo:
"Vamos revalidar dezenas de integrações críticas."
Essa diferença muda completamente a dimensão do problema.
O mito dos programadores aposentados
Outro clichê recorrente afirma que:
"Os programadores COBOL desapareceram."
Isso também merece correção.
É verdade que muitos especialistas possuem décadas de experiência.
Mas também é verdade que existe uma nova geração chegando.
Em 2026 encontramos iniciativas importantes como:
IBM Z Xplore;
IBM Z Educator Experience;
Open Mainframe Project;
Linux Foundation;
universidades parceiras;
bootcamps especializados;
cursos online;
comunidades técnicas.
O problema não é falta absoluta de profissionais.
O desafio é formar pessoas capazes de compreender sistemas que evoluíram durante cinquenta anos.
Conhecer COBOL leva alguns meses.
Conhecer um banco leva anos.
Então chegou a IA
E chegamos ao ponto que gerou tantas manchetes.
Ferramentas como:
Claude Code;
ChatGPT;
GitHub Copilot;
IBM watsonx Code Assistant;
Gemini Code Assist;
Amazon Q Developer;
começaram a demonstrar capacidades impressionantes.
Hoje elas conseguem:
explicar programas COBOL;
documentar aplicações;
gerar diagramas;
localizar dependências;
produzir testes;
sugerir refatorações;
identificar código morto;
resumir COPYBOOKs;
interpretar JCL;
converter trechos para Java, C# ou outras linguagens.
Isso realmente representa uma revolução.
Mas existe uma enorme diferença entre entender código e substituir um sistema crítico.
Claude Code matou a IBM?
Não.
E aqui precisamos separar manchetes da realidade.
A publicação da Anthropic mostrou avanços relevantes na análise de aplicações legadas.
O mercado reagiu rapidamente porque investidores passaram a especular que serviços tradicionais de modernização poderiam se tornar mais baratos.
Entretanto, isso não significa que um banco possa simplesmente executar:
Migrar COBOL → Java
e colocar o novo sistema em produção na semana seguinte.
Na vida real existem:
homologação;
auditoria;
testes funcionais;
testes integrados;
testes de carga;
recuperação de desastres;
certificações regulatórias;
requisitos legais;
validação de performance;
planos de rollback.
Nenhuma IA elimina essas etapas.
O verdadeiro papel da IA
Padawan, aqui está a grande lição de 2026.
A IA não substitui o engenheiro.
Ela amplifica sua capacidade.
Hoje um desenvolvedor experiente consegue utilizar IA para:
entender programas antigos em minutos;
localizar impactos;
encontrar chamadas esquecidas;
gerar documentação automaticamente;
criar fluxogramas;
explicar SQL complexo;
resumir JCL;
identificar oportunidades de melhoria.
Isso reduz semanas de trabalho para horas.
É um enorme ganho de produtividade.
E a IBM?
Outra inconsistência frequente é imaginar que a IBM dependa exclusivamente do COBOL.
A IBM de 2026 é muito diferente da IBM de vinte anos atrás.
Seu portfólio inclui:
IBM Z;
LinuxONE;
watsonx;
Red Hat OpenShift;
Instana;
Turbonomic;
HashiCorp;
Concert;
Storage;
Quantum Safe;
Guardium;
Hybrid Cloud;
IA corporativa;
consultoria especializada.
Além disso, a própria IBM investe pesadamente em IA para modernização de aplicações.
O IBM watsonx Code Assistant for Z, por exemplo, auxilia na compreensão, documentação e modernização de aplicações COBOL, trabalhando como um copiloto para desenvolvedores, e não como um substituto do conhecimento humano.
Ou seja, a empresa participa da transformação em vez de apenas reagir a ela.
O novo perfil do programador COBOL
O profissional de 2026 não é mais apenas alguém que escreve código.
Ele precisa compreender:
arquitetura;
APIs;
DevOps;
Git;
containers;
Linux;
observabilidade;
segurança;
IA;
automação;
cloud híbrida.
COBOL continua importante.
Mas agora faz parte de um ecossistema muito maior.
O programador deixa de ser apenas um codificador e passa a atuar como um engenheiro de negócios, capaz de conectar o legado ao mundo moderno.
O conselho do Mestre Bellacosa
Imagine um Mestre Jedi diante de um jovem padawan.
O aprendiz pergunta:
"Professor... a IA vai acabar com o COBOL?"
O mestre sorri.
Aponta para o enorme IBM Z funcionando silenciosamente.
Depois responde:
"Padawan... a IA pode explicar milhões de linhas de código. Pode documentar sistemas inteiros. Pode sugerir melhorias e acelerar modernizações. Mas ela ainda depende de alguém que saiba fazer as perguntas certas, interpretar as respostas e entender o negócio por trás de cada linha."
É exatamente isso que diferencia um operador de ferramenta de um verdadeiro engenheiro.
O futuro já começou
O futuro não será "COBOL versus IA".
Será COBOL com IA.
Será comum ver agentes inteligentes:
explicando programas antigos;
documentando aplicações automaticamente;
criando testes unitários;
sugerindo otimizações SQL;
identificando impactos antes de uma alteração;
auxiliando em BINDs, JCLs e COPYBOOKs;
analisando dumps e SQLCODEs;
acelerando investigações de ABENDs.
O conhecimento humano continuará sendo indispensável, mas a produtividade será muito maior.
Conclusão
Ao longo de mais de seis décadas, COBOL sobreviveu a praticamente todas as grandes revoluções da computação. Não porque seja imutável, mas porque evoluiu junto com a plataforma IBM Z e continua sustentando aplicações cujo maior valor não está na linguagem, e sim nas regras de negócio que elas implementam.
A Inteligência Artificial Generativa representa, sem dúvida, a maior mudança no desenvolvimento de software desde a popularização da Internet. Ferramentas como Claude Code, ChatGPT e IBM watsonx Code Assistant transformaram a forma de analisar, documentar e modernizar aplicações legadas. Entretanto, elas não substituem décadas de conhecimento acumulado, nem eliminam requisitos de auditoria, segurança, conformidade e testes rigorosos exigidos por ambientes corporativos.
Para o programador COBOL padawan, a mensagem é animadora: nunca houve um momento tão interessante para aprender. Quem dominar COBOL, IBM Z, Db2, CICS, APIs, DevOps e IA terá um perfil raro e extremamente valioso. O profissional do futuro não será aquele que compete contra a IA, mas aquele que sabe utilizá-la para preservar o legado, acelerar a inovação e garantir que sistemas responsáveis por movimentar trilhões de dólares continuem funcionando com a confiabilidade que o mundo espera.
Porque, no fim das contas, o verdadeiro fantasma de 1959 não assombra o mercado. Ele continua trabalhando silenciosamente, vinte e quatro horas por dia, sete dias por semana, garantindo que cartões sejam autorizados, salários sejam pagos, aposentadorias sejam calculadas e bancos permaneçam operando. E agora, em 2026, ele ganhou um novo aliado: a Inteligência Artificial.
AI-First: A Maior Revolução da Engenharia de Software Desde o Surgimento da Internet
"A Inteligência Artificial não está mudando apenas as aplicações. Ela está mudando a forma como construímos sistemas."
Durante muitos anos, nós, desenvolvedores, aprendemos uma receita que parecia imutável.
Criávamos uma interface.
Essa interface chamava um backend.
O backend aplicava regras de negócio.
As regras consultavam um banco de dados.
O banco retornava informações.
A aplicação respondia ao usuário.
Era simples.
Era elegante.
Era determinístico.
E, durante mais de cinquenta anos, funcionou muito bem.
Mas estamos entrando em uma nova era.
Uma era em que o software deixa de apenas executar instruções para começar a interpretar, raciocinar, decidir e aprender.
Esse novo paradigma recebe um nome que você ouvirá cada vez mais:
AI-First Architecture.
E este talvez seja o conceito mais importante que um desenvolvedor júnior pode aprender nesta década.
Não é apenas adicionar um chatbot
Muita gente acredita que IA significa colocar um ChatGPT dentro do sistema.
Não.
Isso é apenas a ponta do iceberg.
Imagine um banco.
Hoje ele possui:
aplicações COBOL;
programas CICS;
bancos DB2;
APIs REST;
aplicativos móveis;
internet banking.
Adicionar um chatbot na frente desse ambiente não transforma a empresa em AI-First.
É como instalar um motor elétrico em uma carroça.
O veículo continua sendo uma carroça.
A verdadeira transformação acontece quando toda a arquitetura passa a ser desenhada considerando que existe uma inteligência tomando decisões durante a execução.
Essa diferença muda absolutamente tudo.
A história sempre se repete
Se observarmos a evolução da computação, veremos um padrão interessante.
Nos anos 60 e 70, o Mainframe dominava o mundo.
Depois surgiu o Cliente/Servidor.
Mais tarde apareceu a Internet.
Em seguida vieram os Smartphones.
Depois a Cloud Computing.
Logo depois Kubernetes, Containers, DevOps e Microsserviços.
Agora estamos entrando na era dos sistemas AI-First.
Cada uma dessas mudanças obrigou empresas inteiras a reconstruírem suas arquiteturas.
A IA está fazendo exatamente a mesma coisa.
Não é uma atualização.
É um reset arquitetural.
O software tradicional
Vamos imaginar um sistema bancário extremamente simples.
Cliente
↓
Modelo de IA
↓
Planejamento
↓
Busca de Informações
↓
Ferramentas
↓
APIs
↓
COBOL
↓
DB2
↓
Validação
↓
Resposta
Perceba que surgiram diversas novas camadas.
Cada uma delas resolve um problema diferente.
É isso que a imagem apresentada tenta mostrar.
Vamos entender cada transformação.
APIs deixam de ser protagonistas
Durante muitos anos aprendemos que toda integração era feita através de APIs.
A arquitetura era simples.
Sistema A
↓
API
↓
Sistema B
Agora surgiu uma nova camada.
O modelo de IA.
Em vez de apenas consumir APIs, ele decide:
"Qual API devo chamar?"
"Qual informação preciso?"
"Preciso consultar dois sistemas?"
"Devo resumir o resultado?"
O modelo deixa de ser apenas consumidor.
Ele passa a coordenar toda a execução.
Isso muda completamente a arquitetura.
Model Hosting
Outro conceito importante é o Model Hosting.
Hoje muitas empresas utilizam modelos hospedados por terceiros.
Por exemplo:
ChatGPT
Claude
Gemini
Mas imagine um banco.
Será que ele deseja enviar informações financeiras para uma IA hospedada externamente?
Na maioria das vezes, não.
Por isso cresce rapidamente o uso de modelos privados.
Alguns exemplos são:
Granite (IBM)
Llama
Mistral
Gemma
Qwen
Phi
DeepSeek
Nesse cenário, a empresa instala o modelo dentro do próprio datacenter.
Os dados nunca saem do ambiente corporativo.
Para quem trabalha com IBM Z, isso faz muito sentido.
O Mainframe sempre foi sinônimo de segurança.
Executar modelos próximos aos dados reduz custos, melhora a privacidade e atende requisitos regulatórios como LGPD.
O banco de dados não é mais suficiente
Durante décadas aprendemos SQL.
SELECT *
FROM CLIENTES
WHERE CPF='12345678900'
A consulta é perfeita.
Mas agora imagine outra pergunta.
"Quais clientes possuem perfil semelhante ao João?"
Onde está essa coluna?
Não existe.
Essa informação é baseada em significado.
É aí que entram os Vector Stores.
O que são Embeddings?
Imagine que cada documento vire uma coordenada em um enorme mapa matemático.
Por exemplo.
Um texto sobre COBOL.
Outro sobre CICS.
Outro sobre DB2.
Mesmo que usem palavras diferentes, eles ficam próximos porque possuem o mesmo significado.
Essa representação matemática recebe o nome de Embedding.
Em vez de procurar palavras iguais...
A IA procura ideias parecidas.
Essa é a base do chamado RAG (Retrieval-Augmented Generation), uma técnica que permite aos modelos consultar documentos corporativos antes de responder.
Um exemplo no Mainframe
Imagine um desenvolvedor COBOL perguntando:
"Onde é calculado o limite de crédito?"
Nenhum programa possui exatamente essa frase.
Mas o banco vetorial consegue localizar o módulo correto porque entende o contexto.
Essa capacidade muda completamente a forma como pesquisamos código, documentação e conhecimento.
Batch versus Tempo Real
Quem trabalha com Mainframe conhece muito bem o Batch.
À noite executamos milhares de Jobs.
Relatórios são gerados.
Arquivos são atualizados.
Tudo acontece em horários programados.
Mas a IA trabalha de forma diferente.
Ela responde imediatamente.
Em poucos milissegundos.
Isso exige outra infraestrutura.
Precisamos de:
baixa latência;
processamento paralelo;
cache;
streaming;
aceleração por GPU quando aplicável.
A arquitetura deixa de ser orientada por agendas e passa a ser orientada por eventos.
Backends estáticos dão lugar aos Pipelines de IA
No passado existia apenas um backend.
Hoje surgem fluxos inteligentes.
Imagine um assistente bancário.
Quando o cliente pergunta:
"Posso financiar um carro?"
O sistema pode executar vários passos automaticamente.
Primeiro interpreta a pergunta.
Depois identifica o cliente.
Consulta o cadastro.
Consulta o histórico financeiro.
Verifica regras de crédito.
Calcula a renda.
Resume tudo.
Finalmente gera a resposta.
Isso é um Pipeline de IA.
Cada etapa pode utilizar ferramentas diferentes.
Orquestração
Um dos novos papéis da engenharia é criar orquestradores.
Eles decidem:
qual ferramenta chamar;
qual banco consultar;
qual modelo utilizar;
quando interromper o fluxo;
quando pedir confirmação ao usuário.
Esse conceito lembra bastante um maestro conduzindo uma orquestra.
Cada instrumento faz sua parte.
O resultado aparece apenas quando tudo trabalha em conjunto.
MCP: a ponte entre IA e sistemas corporativos
Nos últimos meses um termo ganhou enorme destaque:
Model Context Protocol (MCP).
Imagine que cada sistema da empresa fala um idioma diferente.
COBOL.
Java.
Python.
SAP.
Salesforce.
CICS.
DB2.
MQ.
O MCP cria uma linguagem comum para que agentes de IA descubram e utilizem essas ferramentas de forma padronizada.
Para quem trabalha com IBM Z, isso abre possibilidades fascinantes.
Um agente pode consultar programas COBOL, acessar DB2 por meio de APIs, disparar transações CICS e reunir todas essas informações para responder ao usuário em linguagem natural.
Um modelo não basta mais
Outro mito é acreditar que existe "a melhor IA".
Na prática, diferentes modelos têm especialidades diferentes.
Alguns são excelentes para programação.
Outros para matemática.
Outros para análise de documentos.
Outros para visão computacional.
Por isso surgiu o conceito de Multi-Model Routing.
Um roteador escolhe automaticamente qual modelo é mais adequado para cada tarefa.
Isso reduz custos, melhora a precisão e aumenta a disponibilidade do sistema.
É semelhante ao que acontece em uma equipe de desenvolvimento: ninguém espera que um único profissional seja especialista em todas as áreas.
Manual Ops evolui para AIOps
No passado o administrador monitorava CPU, memória e disco.
Hoje isso continua importante, mas não é suficiente.
Também precisamos observar:
qualidade das respostas;
custo por token;
tempo de inferência;
uso das ferramentas;
falhas de recuperação de contexto;
frequência de alucinações;
precisão das respostas.
AIOps amplia o conceito tradicional de operações para incluir o comportamento dos modelos de IA.
É uma evolução natural do DevOps e do MLOps.
Observabilidade em IA
Logs tradicionais respondem perguntas como:
"O servidor caiu?"
"A API retornou erro?"
Mas sistemas AI-First precisam responder outras perguntas.
"Qual prompt foi enviado?"
"Qual documento foi recuperado pelo RAG?"
"Qual ferramenta foi utilizada?"
"Qual modelo respondeu?"
"Qual foi o nível de confiança?"
Essa nova disciplina é chamada de AI Observability.
Ela é essencial para auditoria, conformidade e melhoria contínua.
Cloud não desaparece, mas muda
Durante muito tempo acreditamos que tudo iria para a nuvem.
Hoje percebemos que isso não é verdade.
Muitos modelos estão sendo executados:
no notebook;
no celular;
dentro das empresas;
em hospitais;
em fábricas;
no Edge;
e também em Mainframes.
Por quê?
Porque mover grandes volumes de dados é caro, lento e pode gerar problemas de privacidade.
Em muitos casos é mais eficiente levar o modelo até os dados do que enviar os dados até o modelo.
Essa é a essência da arquitetura híbrida.
Sistemas probabilísticos
Talvez esta seja a mudança mais difícil para quem vem da programação tradicional.
Um programa COBOL sempre executará exatamente as mesmas instruções.
Já um modelo de IA trabalha com probabilidades.
Ele estima qual é a melhor resposta.
Isso significa que pode existir mais de uma resposta correta.
Ou até respostas incorretas.
Por isso surgem novos conceitos:
Guardrails;
Validação;
Human-in-the-Loop;
Avaliação contínua;
Score de confiança;
Governança.
A engenharia passa a tratar a incerteza como parte do sistema.
E onde entra o Mainframe?
Algumas pessoas acreditam que a IA substituirá o Mainframe.
Na prática, acontece justamente o contrário.
O IBM Z continua sendo um dos ambientes mais seguros e confiáveis do mundo para executar aplicações críticas.
A IA apenas facilita a interação com esses sistemas, interpreta perguntas em linguagem natural e automatiza tarefas repetitivas.
O resultado é uma arquitetura moderna sem abrir mão da robustez construída ao longo de décadas.
O que um programador júnior deve aprender?
Se você está iniciando sua carreira, talvez esteja se perguntando:
"Preciso abandonar tudo o que aprendi?"
A resposta é não.
Os fundamentos continuam sendo indispensáveis.
Aprenda lógica de programação, algoritmos, estruturas de dados, SQL, redes, sistemas operacionais e boas práticas de engenharia.
Esses conhecimentos continuam sustentando qualquer arquitetura.
Ao mesmo tempo, vale a pena ampliar seu repertório com tecnologias ligadas à IA:
fundamentos de LLMs;
embeddings e bancos vetoriais;
RAG;
engenharia de prompts;
agentes de IA;
MCP;
observabilidade em IA;
DevOps, MLOps e LLMOps;
integração entre IA e sistemas legados.
No universo IBM Z, entender como essas tecnologias conversam com COBOL, CICS, DB2 e z/OS Connect será um diferencial importante nos próximos anos.
Conclusão
A mensagem principal é simples, mas poderosa: AI-First não representa uma nova funcionalidade; representa uma nova maneira de pensar a engenharia de software.
Durante décadas escrevemos programas que seguiam regras fixas. Agora estamos construindo sistemas capazes de interpretar contexto, utilizar ferramentas, consultar conhecimento, escolher modelos, avaliar resultados e interagir de forma muito mais natural com as pessoas.
Para o desenvolvedor júnior, essa transformação pode parecer assustadora. No entanto, ela também representa uma oportunidade extraordinária. Nunca houve um momento em que aprender fundamentos sólidos de programação e, ao mesmo tempo, compreender IA, integração e arquiteturas modernas pudesse abrir tantas portas.
Como costumo dizer aqui no Bellacosa Mainframe, o futuro não pertence a quem conhece apenas a tecnologia mais nova, nem apenas a mais antiga. Pertence a quem consegue conectar os dois mundos.
O Mainframe continua sendo o coração das maiores empresas do planeta. A Inteligência Artificial está se tornando o cérebro que amplia suas capacidades. E o profissional que souber integrar esses dois universos estará preparado para construir a próxima geração de sistemas corporativos. Afinal, a tecnologia muda, mas os princípios da boa engenharia continuam sendo o melhor ponto de partida para qualquer revolução.
O que é fanservice inteligente: exemplos que realmente funcionam
Fanservice é frequentemente entendido como apelo visual voltado ao público, como cenas sensuais, poses exageradas ou piadas insinuativas. Contudo, o conceito é mais amplo. Trata-se de qualquer elemento inserido para agradar expectativas do fã: referências, nostalgia, easter eggs, combates elaborados, ships e reencontros marcantes.
Fanservice só se torna “problema” quando desvia a narrativa de seu propósito e transforma personagens em instrumentos vazios de estímulo. Já o fanservice inteligente contribui para o enredo, amplia o engajamento emocional e reforça a imersão.
Quando se fala em fanservice, muitas pessoas imaginam apenas cenas visuais criadas para chamar atenção do público. Porém existe um conceito muito mais sofisticado conhecido como fanservice inteligente, uma forma de recompensa voltada para espectadores atentos e profundamente envolvidos com a narrativa.
Esse tipo de fanservice acontece através de referências ocultas, conexões entre episódios, simbolismos, diálogos com múltiplos significados e pequenos detalhes que enriquecem a experiência de quem acompanha a obra com atenção. Em vez de agradar apenas visualmente, ele estimula interpretação, memória e reflexão.
Animes como Neon Genesis Evangelion, Steins;Gate, Serial Experiments Lain, Monster, Paranoia Agent, Ergo Proxy e Ghost in the Shell são exemplos clássicos. Muitas de suas cenas possuem mensagens filosóficas, psicológicas ou culturais que só se tornam evidentes após revisões ou análises mais profundas.
O fanservice inteligente também aparece quando autores inserem referências à literatura, religião, mitologia, ciência, história ou até mesmo a trabalhos anteriores. Isso cria uma sensação de descoberta constante para o espectador.
Além de enriquecer a narrativa, esse recurso fortalece comunidades de fãs, que passam anos debatendo teorias e interpretações. Muitas vezes, um detalhe aparentemente simples pode mudar completamente a compreensão da história.
Por isso, o fanservice inteligente é visto por muitos como uma das formas mais sofisticadas de narrativa nos animes: uma recompensa não para os olhos, mas para a mente. 🧠🌙📺✨
Características do fanservice inteligente
Tem função narrativa
Constrói arco dramático ou desenvolve personagem.
Conhece o próprio público
Identifica o que a comunidade valoriza e entrega sem romper coerência interna.
Recompensa quem está atento
Easter eggs e callbacks que criam senso de pertencimento.
Equilíbrio entre sugestão e sutileza
Não interrompe o ritmo para chamar atenção a si mesmo.
Amplia o universo ficcional
Fanservice que expande lore, não apenas estímulos visuais.
Exemplos de fanservice inteligente em animes
1. Referências que constroem significado
Séries de fantasia que revisitam elementos antigos como parte do crescimento do herói.
2. Reuniões dramáticas de personagens
Reforçam temas como amizade, legado e superação, elevando a carga emocional da história.
3. Humor situacional coerente com a personalidade
Piadas sobre traços já estabelecidos do personagem, sem descaracterização.
4. Retorno de transformações icônicas
Quando surge no momento narrativo certo, simboliza evolução, não regressão.
Estudos de caso
• One Piece
Momentos de retorno de personagens queridos funcionam como reafirmação de laços, além de expandirem a mitologia da obra.
• Fullmetal Alchemist: Brotherhood
Easter eggs e interações cômicas funcionam para aliviar a tensão sem descaracterizar os protagonistas.
• My Hero Academia
Transformações e poses heroicas reforçam identidade e ethos do gênero sem quebrar a lógica dramática.
O oposto: quando o fanservice atrapalha
Situações que objetificam personagens sem conexão com personalidade ou contexto enfraquecem a obra. O público percebe quando há desespero por atenção e não entrega significativa.
Consequências típicas:
Perda de credibilidade diegética
Quebra do ritmo narrativo
Redução dos personagens a estereótipos vazios
Em outras palavras: se o público lembra do fanservice e não da cena, houve um problema.
Conclusão
Fanservice inteligente não é sobre negar o desejo do fã, mas integrá-lo ao design narrativo. Quando bem aplicado, fortalece vínculos emocionais, estabiliza a identidade da obra e respeita o arco dos personagens. A pergunta que todo roteirista deveria fazer é simples:
“Isto serve à história ou apenas tenta provocar reação instantânea?”
A Jornada Completa para Entender Por Que os Mainframes Nunca Param
Existe uma pergunta que todo Padawan COBOL faz nos primeiros meses trabalhando com IBM Z.
"Por que os bancos utilizam Mainframe até hoje?"
A resposta normalmente é simplificada.
"Porque é seguro."
"Porque é rápido."
"Porque processa milhões de transações."
Embora todas essas afirmações sejam verdadeiras, elas escondem um conceito muito maior.
O verdadeiro diferencial do IBM Z não está apenas em sua capacidade de processamento.
Está na sua capacidade de continuar funcionando.
Ao longo desta série especial O Holocron da Resiliência IBM Z, percorremos uma jornada completa pelos principais componentes que transformam o IBM Z na plataforma mais confiável do mercado para aplicações críticas.
Muito mais do que conhecer novos termos técnicos, o objetivo foi compreender como hardware, sistema operacional, middleware, armazenamento e processos trabalham em perfeita sintonia para garantir continuidade dos negócios.
📜 Parte I – Conceitos Fundamentais
Nossa jornada começou entendendo a filosofia da Resiliência.
Exploramos conceitos como:
Resiliency
RAS
High Availability
Disaster Recovery
SLA
RPO
RTO
Single Point of Failure
ITIL
CFIA
Foi aqui que descobrimos que o IBM Z não foi projetado para impedir falhas.
Ele foi projetado para impedir que as falhas afetem o negócio.
Em seguida conhecemos uma das maiores invenções da engenharia IBM.
O Parallel Sysplex.
Exploramos:
Coupling Facility
WLM
SFM
ARM
DVIPA
Sysplex Distributor
Load Balancing Advisor
Aprendemos como diversos mainframes conseguem trabalhar como um único sistema lógico, distribuindo carga automaticamente e mantendo aplicações disponíveis mesmo durante falhas.
Nenhuma infraestrutura teria valor sem aplicações.
Nesta etapa conhecemos os componentes responsáveis por processar milhões de transações diariamente:
CICS
CICS TS
Db2
IBM MQ
IMS
IMS DB
CICSplex
TOR
AOR
FOR
DOR
HALDB
DBRC
FDBR
Foi aqui que percebemos como aplicações COBOL continuam evoluindo e hoje conversam naturalmente com APIs REST, microsserviços, dispositivos móveis e plataformas em nuvem.
Talvez o maior aprendizado desta série seja perceber que um programa COBOL nunca trabalha sozinho.
Quando um simples programa executa um READ, um WRITE, um EXEC SQL ou um EXEC CICS LINK, existe um verdadeiro ecossistema trabalhando silenciosamente nos bastidores.
Processadores especializados.
Controladores inteligentes.
Storage redundante.
Parallel Sysplex.
Workload Manager.
Middleware.
Replicação síncrona.
Recuperação automática.
Monitoramento contínuo.
Tudo isso existe para garantir que o usuário final consiga realizar uma operação bancária, uma compra no cartão de crédito, uma transferência PIX ou uma reserva de passagem aérea sem sequer imaginar a complexidade envolvida.
É justamente essa engenharia invisível que faz do IBM Z uma referência mundial em computação de missão crítica.
A Filosofia Bellacosa Mainframe
Existe uma frase que resume toda esta coleção.
"Resiliência não é uma tecnologia. É uma filosofia de engenharia."
No IBM Z, falhas são previstas.
Componentes quebram.
Discos são substituídos.
Processadores entram em manutenção.
Datacenters podem até ficar indisponíveis.
Mesmo assim, milhões de pessoas continuam utilizando seus serviços normalmente.
Esse é o verdadeiro poder do Mainframe.
Não construir computadores perfeitos.
Mas construir sistemas preparados para continuar funcionando quando a imperfeição inevitavelmente aparecer.
E talvez essa seja a maior lição para qualquer Programador COBOL.
Escrever código é importante.
Mas compreender toda a arquitetura que mantém esse código disponível para milhões de pessoas é o que transforma um Padawan em um verdadeiro Mestre do IBM Z.
Quando o arquétipo vira clichê: sinais de alerta para roteiristas
O ponto exato em que o familiar se torna preguiçoso
Arquétipos são o coração dos animes. Eles fazem com que, desde o primeiro episódio, já compreendamos quem é quem, o que esperar, para onde a trama pode caminhar. Só que existe uma linha tênue: quando um arquétipo deixa de emocionar e passa a irritar, temos um clichê.
Durante minhas maratonas mais recentes, percebi que alguns animes tropeçam exatamente no momento em que escolhem o caminho mais fácil, trocando profundidade por fórmulas vazias.
A pergunta que fica é: quando o arquétipo deixa de funcionar e vira apenas repetição?
1️⃣ O personagem não muda
Arquétipos devem crescer com a história. Sempre.
Sinal vermelho quando:
• a tsundere passa 12 episódios apenas gritando e batendo
• o protagonista improvável continua bobo e inútil até o final
• o vilão filosófico não tem qualquer ponto coerente
Se o personagem termina igual ao que começou, o arquétipo virou carimbo.
O público não assiste para ver o mesmo, e sim para ver o conhecido se transformar.
2️⃣ A função narrativa é substituída por “checklist”
“Precisamos de um alívio cômico, coloca um.”
“Falta uma moe, joga ali.”
“Coloca um senpai que ninguém liga.”
Quando o arquétipo é colocado apenas para preencher espaço, o roteiro cria ruído. O personagem está presente, mas não serve ao enredo.
Exemplo clássico: mascotes fofos que nada acrescentam, apenas piscam e vendem chaveiros.
3️⃣ Reações previsíveis a cada cena
Se o espectador sabe exatamente qual será a fala seguinte do personagem, há um problema de previsibilidade.
Indícios claros:
• a mesma piada repetida até perder graça
• gatilhos dramáticos que sempre levam ao mesmo choro
• romance arrastado, sem qualquer evolução de intimidade real
Surpresa é o tempero do arquétipo bem usado.
4️⃣ O mundo não influencia o personagem
Arquétipos não podem existir no vácuo. O cenário deve moldá-los.
Falha comum em isekai:
O protagonista vai para um mundo completamente novo, mas continua com mentalidade de colégio e atitudes idênticas ao primeiro episódio.
Se o mundo não transforma a pessoa, a jornada perde propósito.
5️⃣ O fanservice domina a personalidade
Fanservice é válido quando complementa. Torna-se clichê quando substitui.
Sintomas:
• o personagem existe apenas para mostrar pele
• seu fetiche é sua única característica
• qualquer conflito é resolvido “no grito ou no decote”
Quando o arquétipo vira objeto, deixou de ser personagem.
Por que os clichês irritam tanto?
Porque nós amamos potencial.
Vemos um arquétipo e pensamos: “isso pode ser incrível”.
Quando o roteiro não cumpre essa promessa, sentimos frustração.
O clichê não falha por ser familiar.
Ele falha por não surpreender.
Como resgatar um arquétipo antes que morra
Sugestões simples que fazem diferença:
✔ Mudança de contexto: coloque a tsundere em posição vulnerável
✔ Quebra de expectativa: deixe o protagonista falhar feio
✔ Objetivos pessoais além da função de “amar o herói”
✔ Motivação clara, mesmo para o alívio cômico
✔ Vilões com razão para acreditar que estão certos
Pequenas subversões reativam a curiosidade do público.
Conclusão de um otaku que já viu de tudo
Arquétipos são como ingredientes clássicos de ramen:
a massa e o caldo podem ser os mesmos, porém o tempero precisa ser novo.
O clichê não nasce do arquétipo.
O clichê nasce da falta de risco.
Se o roteirista parar de perguntar “qual personagem preciso?”
e começar a perguntar “quem essa pessoa quer ser?”,
o clichê desaparece e o anime floresce.
Bellacosa Mainframe e a codificação vibe coding e context engineering
☕ Um Café no Bellacosa Mainframe
💵 Bud Fox e a Fintech de Wall Street — Quando Vibe Coding encontra Context Engineering
SDD, DDD, Monólito Modular, Evals, Engineering Loop, agentes de IA e a perigosa diferença entre gerar código que funciona e construir software em que podemos confiar.
Nova York, 1987.
Bud Fox atravessa os corredores da Jackson Steinem & Co. com dois telefones, uma agenda cheia de nomes e uma obsessão: descobrir alguma informação que os outros ainda não possuem.
Em Wall Street, informação significa vantagem.
Quase quarenta anos depois, troque o pregão por uma IDE, os terminais financeiros por agentes de IA e as ações por milhares de classes Java.
A questão continua surpreendentemente parecida:
informação sem contexto pode ser tão perigosa quanto informação nenhuma.
Nossa história começa com uma proposta irresistível.
Vamos construir uma fintech.
E vamos usar IA.
🎬 CAPÍTULO 1 — Bud Fox descobre Vibe Coding
Imagine Bud Fox chegando ao escritório de tecnologia.
Ele abre seu agente de IA e escreve:
Crie uma fintech em Java 21.
Spring Boot
PostgreSQL
Kafka
DDD
Arquitetura Hexagonal
Monólito Modular
Módulos:
Customers
Accounts
Pix
Fraud
Ledger
Notifications
Gerar software tornou-se extraordinariamente barato. O material que analisamos começa justamente com essa constatação: descrevemos algo para um agente e rapidamente aparecem controllers, migrations, testes, Dockerfiles e dezenas de classes.
Bud encontrou sua primeira ação quente.
Só existe um problema.
O programa funcionar hoje não significa que sua arquitetura sobreviverá aos próximos 500 prompts.
📈 CAPÍTULO 2 — O primeiro lucro esconde a primeira dívida
Porque meses atrás nossa equipe tomou uma decisão arquitetural:
Ledger é a única fonte de verdade financeira.
Accounts conhece conta, estado, bloqueios e limites. Ledger conhece journals, débitos, créditos e posição financeira. Essa divisão de responsabilidade está explicitamente definida no modelo que estamos estudando.
O agente sabia Java.
Sabia Spring.
Sabia PostgreSQL.
Sabia como subtrair amount.
O que ele não sabia era:
como esta empresa decidiu representar dinheiro.
E encontramos nosso primeiro princípio.
Código correto localmente pode estar errado globalmente.
🦈 CAPÍTULO 3 — Gordon Gekko aparece na arquitetura
Se Gordon Gekko estivesse olhando nosso repositório, provavelmente perguntaria:
— Quem é dono de quê?
Excelente pergunta.
Porque software corporativo não é apenas um conjunto de classes.
Essa aparentemente pequena decisão arquitetural é enorme.
Accounts responde:
A conta pode operar?
Fraud:
Esta operação apresenta risco aceitável?
Pix:
Qual é o estado da transferência?
Ledger:
O que aconteceu financeiramente?
Agora nossa IA começa a receber uma coisa muito mais importante do que instruções de programação.
Ela recebe semântica.
🧠 CAPÍTULO 5 — Bud Fox descobre Context Engineering
Bud percebe que ficar repetindo tudo em prompts é inviável.
Inicialmente:
Crie uma API Pix.
Depois:
Crie uma API Pix usando DDD.
Logo chegamos ao monstro:
Java 21.
Spring Boot.
PostgreSQL.
Kafka.
DDD.
Hexagonal.
Modular Monolith.
Pix não acessa AccountRepository.
Ledger controla saldo.
Use Outbox.
Use idempotência.
Use double-entry bookkeeping.
...
O próprio material mostra essa evolução e aponta o limite da estratégia: o prompt não deveria funcionar como banco de memória da engenharia do produto.
É quando Bud encontra algo muito mais valioso que uma ação privilegiada.
Context Engineering.
Prompt Engineering pergunta:
Como faço uma boa pergunta ao modelo?
Context Engineering pergunta:
Quais informações o agente precisa ter disponíveis para tomar uma boa decisão?
O que significa transferir dinheiro neste negócio?
Essa pergunta vale mais que cinquenta classes.
📜 CAPÍTULO 10 — A Spec é o prospecto da operação
Nossa spec.md pode declarar:
FEATURE
Send Pix
Objetivo:
Transferir dinheiro entre contas
respeitando elegibilidade,
fundos disponíveis,
limites,
risco,
contabilidade
e idempotência.
E então aparecem as regras:
BR-001
A conta deve existir.
BR-002
A conta deve estar ativa.
BR-003
O valor deve ser maior que zero.
BR-004
Devem existir fundos disponíveis.
BR-005
O limite Pix deve ser respeitado.
BR-006
A análise de risco deve aprovar
a operação.
BR-007
A mesma Idempotency-Key não pode
produzir duas transferências.
São exatamente as classes de regras usadas no exemplo original.
Agora o agente não precisa adivinhar o negócio.
Mas surge outro problema.
🕵️ CAPÍTULO 11 — Gordon Gekko pergunta: “Quem fiscaliza?”
Podemos escrever:
Pix não pode acessar Accounts Infrastructure.
Excelente.
Então um agente escreve:
import accounts.infrastructure.AccountRepository;
A documentação dizia não.
O código disse sim.
Quem ganhou?
O compilador.
Precisamos transformar regras humanas em regras verificáveis.
Entram os:
🧪 EVALS
Podemos pensar:
SPEC
=
o que esperamos
EVAL
=
como demonstramos que continua verdadeiro
Essa relação aparece claramente no material.
🛡️ CAPÍTULO 12 — A SEC da nossa arquitetura
Vamos criar alguns fiscais.
Architecture Eval
PIX não pode importar:
accounts.infrastructure
ledger.infrastructure
fraud.infrastructure
Idempotency Eval
Given
Idempotency-Key = ABC123
When
POST /pix/transfers
é executado duas vezes
Then
existe apenas uma PixTransfer.
consistência matemática não implica correção de negócio.
O próprio exemplo do material usa duplicação de eventos gerando lançamentos repetidos para demonstrar como produção pode revelar uma invariante que faltava.
🔄 CAPÍTULO 17 — Engineering Loop: o fechamento do pregão não encerra a história
Context Engineering maduro também precisa responder:
Qual contexto é relevante para esta tarefa?
Para:
Implement Pix Scheduled Transfer
talvez precisemos:
Pix Domain Context
Accounts public contract
Fraud public contract
Ledger public contract
Pix business rules
relevant ADRs
current spec
relevant incidents
relevant evals
A estrutura-base de documentação, specs, loops, feedback e implementação é justamente a proposta apresentada no material original.
Agora cada diretório responde a uma pergunta.
docs/domain
→ Como nosso negócio funciona?
docs/architecture
→ Como decidimos estruturá-lo?
specs
→ O que queremos construir?
evals
→ Como provamos?
engineering
→ O que aconteceu enquanto construíamos?
incidents
→ Onde a realidade contrariou nossas hipóteses?
learning
→ O que aprendemos?
src
→ Qual implementação existe atualmente?
Isso é muito mais poderoso que simplesmente armazenar código.
⚡ CAPÍTULO 26 — E o Vibe Coding volta pela porta da frente
Depois de toda essa burocracia arquitetural alguém poderia concluir:
quanto melhor estruturado o contexto, menos precisamos repetir tudo no prompt.
Portanto Vibe Coding não precisa ser sinônimo de engenharia irresponsável.
Podemos ter:
Vibe Coding sobre trilhos.
🖥️ CAPÍTULO 27 — E onde entra o COBOL?
Agora chegamos ao ponto especialmente interessante para quem vive no mundo mainframe.
Muito antes de alguém dizer Context Engineering, mainframes já conviviam com o problema.
Imagine um programa:
IDENTIFICATION DIVISION.
PROGRAM-ID. PGMPX001.
Quarenta anos de história.
Ele usa:
COPYBOOKS
VSAM
Db2
CICS
MQ
JCL
PROCs
RACF
SORT
programas chamados
programas chamadores
arquivos downstream
jobs batch
Alguém pede:
“Altere a regra de limite.”
O programador iniciante pensa:
abrir COBOL
↓
achar IF
↓
alterar
↓
compilar
O veterano pergunta:
Quem chama?
Quem é chamado?
Qual COPYBOOK?
Qual tabela?
Qual transação CICS?
Qual arquivo?
Qual JCL?
Qual janela batch?
Qual downstream?
Qual rollback?
Qual regra histórica?
Por que aquele IF existe?
Isso é Context Engineering antes do nome existir.
🏛️ CAPÍTULO 28 — O mainframe é uma catedral de contexto
Business Context
Architecture Context
Data Context
Integration Context
Security Context
Operational Context
Historical Context
Ou seja, o desafio não é:
A IA sabe COBOL?
A pergunta muito mais importante é:
A IA sabe o que esse COBOL significa dentro daquela organização?
Aí a conversa sobre Context Engineering deixa de parecer moda de IA.
Ela começa a parecer extremamente familiar para qualquer veterano de mainframe.
💎 CAPÍTULO 29 — A verdadeira informação privilegiada
Bud Fox começou nossa história procurando a próxima informação capaz de lhe dar vantagem.
No desenvolvimento com IA também existe uma informação privilegiada.
Não é:
"Use Spring Boot."
Todo modelo sabe isso.
Não é:
"Use Kafka."
Também sabe.
Não é sequer:
"Use DDD."
A verdadeira vantagem está em conhecimento que só sua organização possui:
Por que Ledger controla saldo?
Por que Pix não acessa AccountsRepository?
Por que determinado consumer precisa ser idempotente?
Por que aquele limite existe?
Por que aquela decisão foi tomada?
Qual incidente revelou aquela regra?
Qual comportamento não pode mudar?
Qual contrato não pode quebrar?
Isso é conhecimento institucional.
E, ao contrário do insider trading de Wall Street, aqui queremos exatamente o contrário:
tornar esse conhecimento acessível, explícito, governado e verificável para quem legitimamente precisa construir o sistema.
🎞️ EPÍLOGO — Bud Fox fecha o terminal
No começo tínhamos:
PROMPT
↓
CODE
Parecia revolucionário.
Depois descobrimos:
VIBE CODING
↓
VELOCIDADE
Mas velocidade precisava de direção.
Então:
SDD
↓
INTENÇÃO
A intenção precisava respeitar fronteiras.
DDD
+
MODULAR MONOLITH
↓
OWNERSHIP
+
BOUNDARIES
As fronteiras precisavam estar disponíveis aos agentes.
CONTEXT ENGINEERING
↓
MEMÓRIA DE ENGENHARIA
A memória precisava ser verificável.
EVALS
↓
EVIDÊNCIA
E nenhuma especificação conhece completamente a realidade.
É exatamente a síntese alcançada pelo material: Vibe Coding acelera; SDD dá direção; DDD protege fronteiras; Evals tornam intenção verificável; Engineering Loop converte execução em aprendizado; Context Engineering conecta o conjunto.
Bud olha para Gordon Gekko.
Gekko talvez dissesse:
informação é o ativo mais valioso da sala.
Mas no desenvolvimento de software com agentes existe uma versão melhor dessa máxima:
Código está ficando barato. Contexto confiável está ficando valioso.
Porque não será particularmente impressionante uma IA produzir dez mil linhas de Java, COBOL ou Python em uma tarde.
O verdadeiro feito será ela chegar ao prompt número 500, depois de quarenta features, dez desenvolvedores, cinco agentes, três mudanças arquiteturais e aquele inevitável incidente das 03:17, e ainda compreender que:
Accounts
≠
Ledger
que:
Pix
NÃO acessa
Accounts Infrastructure
que:
Debit == Credit
não é suficiente se o mesmo evento financeiro tiver sido processado duas vezes;
e, sobretudo, compreender por que cada uma dessas decisões existe.
Quando conseguirmos isso, teremos ido muito além de Vibe Coding.
Teremos construído algo que empresas perseguem desde muito antes da IA:
software capaz de preservar o conhecimento acumulado por quem o construiu.
E talvez aí esteja a maior ironia desta história.
O futuro dos agentes de IA pode acabar redescobrindo uma das grandes lições do mainframe:
sistemas críticos sobrevivem durante décadas não porque alguém escreveu código perfeito, mas porque sucessivas gerações conseguiram preservar contratos, regras, interfaces, decisões e conhecimento suficientes para continuar mudando sem destruir aquilo que já funcionava.
Bud Fox queria descobrir qual seria a próxima grande operação.
No nosso pregão tecnológico, talvez já tenhamos encontrado uma:
Vibe Coding gera código. Context Engineering preserva engenharia.
E em sistemas que movimentam dinheiro — seja uma fintech Java de 2026 ou um COBOL processando milhões de transações num IBM Z — essa diferença vale muito mais do que algumas linhas de código produzidas em segundos.
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
