✨ 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
Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix
"A diferença entre um sistema resiliente e um sistema frágil é que o resiliente já sobreviveu ao desastre em laboratório."
O Café Esfria e o Macaco Aprende Novos Truques
O relógio marcava 01h17.
O Padawan COBOL ainda estava intrigado.
Na noite anterior, havia descoberto que a Netflix possuía um pequeno macaco virtual cuja diversão favorita era assassinar servidores em plena luz do dia.
Algo que parecia absurdo.
Algo que, para um operador acostumado a passar horas analisando mensagens DFHxxxx, DSNxxxx, IEAxxxx e $HASPxxxx, soava quase criminoso.
Ele olhou para o velho Sysprog do Bellacosa Mainframe.
— Mestre...
— Sim?
— O Chaos Monkey simplesmente escolhe qualquer servidor e aperta o botão vermelho?
O velho tomou um gole de café.
Sorriu.
E respondeu.
— Se fosse apenas isso, meu jovem Padawan, chamaríamos de estagiário em produção.
O Chaos Monkey é muito mais sofisticado.
Ele trabalha com hipóteses.
Métricas.
Estatística.
Probabilidade.
E principalmente com um conceito extremamente importante.
Blast Radius.
O Conceito de Blast Radius
Talvez a maior contribuição filosófica do Chaos Engineering seja uma pergunta simples.
Quanto estrago eu posso causar antes de me tornar um problema para a empresa?
Esse conceito recebeu o nome de:
Blast Radius
Em português poderíamos traduzir como:
Raio de Explosão
Ou
Zona de impacto controlado
Imagine uma granada.
A explosão possui um alcance limitado.
Pessoas próximas são afetadas.
Pessoas distantes permanecem seguras.
Chaos Engineering funciona da mesma forma.
Não se derruba tudo.
Derruba-se apenas uma pequena parte.
E observa-se.
Exemplo Netflix
Serviços existentes:
Catalog Service
Authentication Service
Billing Service
Streaming Service
Recommendation Engine
CDN Controller
Número total de instâncias:
300
Chaos Monkey escolhe:
2 instâncias.
Blast Radius.
0,66%
Impacto esperado:
Nenhum cliente deve perceber.
Exemplo IBM Z
Ambiente.
LPAR PROD1
LPAR PROD2
LPAR PROD3
CICSA
CICSB
CICSC
Db2A
Db2B
MQA
MQB
Experimento.
Parar CICSB.
Blast Radius.
16%
Objetivo.
Nenhum terminal 3270 deve perder sessão.
Nenhuma transação deve falhar.
Nenhum SLA deve ser violado.
Quanto Menor o Blast Radius, Melhor
Essa é uma das regras mais importantes.
Nunca comece destruindo metade do ambiente.
Comece pequeno.
Muito pequeno.
Ridiculamente pequeno.
Primeiro.
Mate uma instância.
Depois.
Mate duas.
Depois.
Uma AZ.
Depois.
Uma região.
Depois.
Teste desastre.
No mundo IBM Z.
Primeiro.
Pare uma região AOR.
Depois.
Um TOR.
Depois.
Um MQ Manager.
Depois.
Um membro Db2.
Depois.
Uma LPAR.
Somente depois.
Teste GDPS.
O Conceito de Steady State
Na Parte I falamos rapidamente sobre isso.
Agora vamos aprofundar.
Chaos Engineering não começa derrubando servidores.
Começa respondendo.
O que é comportamento normal?
Exemplo.
Sistema bancário.
TPS
8000
CPU
42%
Latência
120 ms
Erros
0,002%
Esse é o estado estável.
Steady State.
Hipótese.
Posso perder um servidor.
Mantendo.
TPS acima de 7800.
Latência abaixo de 150 ms.
Erro abaixo de 0,01%.
Agora sim.
Executamos o caos.
Como o Chaos Monkey Escolhe suas Vítimas
Muita gente imagina.
Servidor.
Sorteio.
Desliga.
Fim.
Não.
Existem estratégias.
Estratégia 1
Seleção aleatória pura
Número aleatório.
Escolha.
Encerrar.
Vantagem.
Simples.
Desvantagem.
Pode escolher servidores pouco importantes.
Estratégia 2
Weighted Random
Peso.
Criticidade.
Histórico.
Capacidade.
Exemplo.
API01
peso 30
API02
peso 10
API03
peso 60
Maior chance.
API03.
Estratégia 3
Tag Based
AWS Tags.
Kubernetes Labels.
Production
Homolog
ChaosEnabled
Exemplo.
ChaosEnabled=true
Apenas esses.
Serão vítimas.
Estratégia 4
Janela Programada
09h às 11h
Terça-feira
Equipe presente
Observabilidade ativa
Muito usada.
Na Netflix.
Google.
Spotify.
O Segredo dos SREs
Os Site Reliability Engineers possuem um mantra.
Não faça experimentos quando ninguém puder observar.
Parece óbvio.
Mas muitas empresas ignoram.
É necessário.
Logs.
Dashboards.
Tracing.
Alertas.
Equipe disponível.
Rollback.
Runbook.
Sem isso.
Chaos vira apenas.
Caos.
O Conceito de Observabilidade
Chaos Engineering depende totalmente dela.
Logs
Métricas
Tracing
Eventos
Alertas
No IBM Z.
RMF.
SMF.
OMEGAMON.
NetView.
SA z/OS.
CICS Monitoring.
Db2 Monitor.
MQ Statistics.
SDSF.
JES2.
WLM.
Exemplo Completo — Banco Digital
Arquitetura.
Load Balancer
6 APIs
Kafka
Redis
Postgres
IAM
PIX
Open Finance
Estado.
12000 TPS
85ms
Erro 0,001%
Hipótese.
Perder API04.
Chaos.
Kill.
API04.
Resultado.
Latência.
91ms.
TPS.
Erro.
0,003%
Hipótese validada.
Novo teste.
Perder Redis.
Resultado.
Latência.
650 ms.
Fila cresce.
Clientes reclamam.
Descoberta.
Redis era SPOF.
Problema corrigido.
Single Point of Failure
Talvez o maior inimigo.
SPOF.
IBM Z nasceu combatendo isso.
Redundância.
Coupling Facility.
Parallel Sysplex.
FICON redundante.
Db2 Sharing.
MQ QSG.
GDPS.
WLM.
RACF Database Sharing.
ODS.
XCF.
Sysplex Timer.
STP.
Chaos Engineering apenas tornou explícita uma filosofia que ambientes críticos praticam há décadas.
Ferramentas Modernas
Gremlin
Plataforma comercial.
CPU.
Memória.
Rede.
Disco.
DNS.
Processos.
LitmusChaos
Kubernetes.
CRDs.
Experimentos.
GitOps.
Chaos Mesh
Cloud Native.
Latência.
IO.
Kernel.
AWS FIS
Fault Injection Simulator.
Instâncias.
EBS.
Rede.
PowerfulSeal
Clusters Kubernetes.
Chaos Toolkit
Python.
Open Source.
Truques Utilizados por Equipes Experientes
Truque 1
Sempre começar em homologação.
Truque 2
Executar experimentos repetidamente.
Truque 3
Automatizar.
CI/CD.
GitOps.
Ansible.
Terraform.
Truque 4
Documentar tudo.
Hipótese.
Resultado.
Aprendizado.
Correção.
Truque 5
Criar um catálogo.
Chaos Experiments.
Versão.
Data.
Owner.
Um Sysprog Descobre o Chaos Monkey
O Padawan olhou para o mestre.
— Então...
— Sim.
— Chaos Engineering é ensinar o sistema a sofrer.
— Exatamente.
— Até ele parar de sentir dor.
— Não.
O velho sorriu.
— Até ele continuar funcionando mesmo sentindo.
Porque a disponibilidade perfeita não existe.
Hardware quebra.
Fibra rompe.
Discos falham.
Firmware possui bugs.
Aplicações vazam memória.
Operadores cometem erros.
Pessoas esquecem procedimentos.
O objetivo nunca foi impedir falhas.
O objetivo sempre foi algo muito mais ambicioso.
Fazer com que as falhas se tornem acontecimentos comuns, previsíveis e entediantes.
E foi nesse momento que o Padawan percebeu algo curioso.
Talvez o Chaos Monkey nunca tivesse sido realmente uma invenção revolucionária.
Talvez fosse apenas uma nova linguagem para explicar uma velha sabedoria dos Sysprogs do IBM Z:
Não espere o desastre ensinar sua arquitetura. Ensine sua arquitetura a sobreviver ao desastre antes que ele aconteça.
Continua na Parte III
No próximo capítulo do Holocron do Chaos Monkey, entraremos definitivamente no território do IBM Z:
Existe um Chaos Monkey para z/OS?
Como testar falhas em CICSplex, Db2 Data Sharing e MQ QSG.
O papel do WLM, Sysplex, XCF e GDPS.
Como construir experimentos de caos seguros para Sysprogs.
Técnicas usando SA z/OS, NetView, z/OSMF e Ansible Automation Platform.
Laboratórios Bellacosa Mainframe com exemplos práticos para Padawans e Sysprogs Seniores.
Bellacosa Mainframe e o dia que sonhei trabalhar na Xerox do Brasil
☕ Um Café no Bellacosa Mainframe
O Crachá que Eu Nunca Tive
Em 1990 eu sonhava trabalhar na Xerox. Trinta e seis anos depois descobri que não queria realmente a Xerox — queria descobrir o mundo que existia depois daquela porta.
O professor barbudo acendeu o cachimbo.
Não porque precisasse dele.
Algumas lembranças simplesmente exigem cenário.
A fumaça subiu devagar pelo escritório enquanto eu olhava para uma tela onde conviviam COBOL, APIs, inteligência artificial e documentos que provavelmente jamais conheceriam uma folha de papel.
Curioso.
Passei boa parte da vida trabalhando com sistemas que processam milhões de informações e, naquela manhã, aquilo que voltou à memória não foi um programa, um banco de dados ou um mainframe.
Foi um cheiro.
Um cheiro químico.
Forte.
Desagradável.
Algo que minha memória insiste em comparar com amoníaco.
E imediatamente voltei para uma época em que copiar uma folha de papel era tecnologia.
Voltei para 1990.
Ou talvez um pouco antes.
Voltei para o garoto que eu era.
E, principalmente, para o crachá que eu nunca tive.
1. Quando o futuro tinha cheiro
Quem nasceu na era do smartphone talvez tenha dificuldade para compreender isso.
Houve uma época em que fazer uma cópia de um documento não significava apontar a câmera do telefone e tocar na tela.
Também não significava colocar uma folha num multifuncional doméstico de alguns quilos.
Copiar documentos podia envolver máquinas grandes, caras, mecânicas, eletrostáticas e, dependendo da tecnologia e da época, processos químicos.
Eu comecei a trabalhar quando ainda era possível encontrar equipamentos de reprodução que não pertenciam completamente ao universo do toner seco que depois se tornaria tão familiar.
Alguns processos de reprodução utilizavam reveladores líquidos; outros, como determinados sistemas diazo usados especialmente para plantas e desenhos técnicos, ficaram famosos pelo cheiro forte associado à amônia.
Talvez os detalhes químicos tenham se perdido em mais de três décadas.
O cheiro, não.
Memória é um banco de dados muito estranho.
Você pode esquecer um nome, uma data e até o modelo exato de uma máquina.
Mas alguém abre uma garrafa, passa um produto de limpeza ou aquece alguma coisa e, de repente:
SELECT *
FROM MEMORIA
WHERE CHEIRO = '1990';
SQLCODE = 0.
Registro encontrado.
O professor barbudo dá uma tragada no cachimbo.
E o garoto aparece novamente.
2. Xerox não era uma copiadora
Hoje olhamos para Xerox e imediatamente pensamos:
— Fotocópia.
Para mim, naquela época, significava muito mais.
Xerox era tecnologia.
Era multinacional.
Era treinamento.
Era uma empresa que parecia estar na fronteira entre aquilo que o mundo era e aquilo que o mundo seria.
E havia algo ainda mais importante para um garoto que não vinha daquele universo:
era uma boa empresa para trabalhar.
Eu ouvia falar dos benefícios.
Do salário.
De treinamento.
De possibilidades profissionais.
Até carro da empresa fazia parte daquele imaginário.
O salário podia chegar a várias vezes aquilo que eu recebia.
Cinco vezes mais parecia fortuna.
Mas dinheiro era apenas uma parte.
Eu queria pertencer àquele ambiente.
Em determinada ocasião fui fazer treinamento de operação de copiadoras Xerox — máquinas como as 1035, 1045 e 1060 fazem parte das minhas lembranças daquela época.
Eu não devia ter muito mais que 16 anos.
E fiquei maravilhado.
Não apenas pelas máquinas.
Pelo lugar.
Pelo ambiente.
Pelo treinamento.
Pelo refeitório.
Pelas pessoas.
Pela organização.
Pela sensação de que existia ali uma espécie de civilização profissional diferente daquela que eu conhecia.
Hoje isso pode parecer banal.
Não era.
3. O refeitório era parte do sonho
Esta talvez seja uma das coisas que somente alguém que começou a trabalhar muito cedo consegue compreender completamente.
Quando você cresce cercado por determinadas condições, certos benefícios empresariais parecem normais.
Refeitório.
Treinamento.
Plano de carreira.
Benefícios.
Instalações agradáveis.
Equipamentos modernos.
Para quem está olhando aquilo de fora, porém, a mensagem é completamente diferente:
Então é possível trabalhar assim?
O refeitório não era apenas um lugar para comer.
Era uma evidência.
Aquele prédio inteiro dizia silenciosamente para mim:
existe outro mundo profissional.
E eu queria entrar nele.
Não havia terminado sequer o colegial.
Morava no subúrbio.
Ir e voltar para casa fazia parte da batalha cotidiana.
Trabalhar e estudar ao mesmo tempo não era frase bonita para colocar no LinkedIn.
Era terça-feira.
Era quarta-feira.
Era quinta-feira.
E os boletos não eram uma metáfora sobre responsabilidade.
Eram dolorosamente reais.
Mesmo assim, eu sonhava.
4. Eu queria aquele crachá
Às vezes me imaginava trabalhando na Xerox.
É engraçado admitir isso depois de tantos anos.
Eu conseguia praticamente enxergar o crachá no peito.
VAGNER.
Funcionário da Xerox do Brasil.
Pronto.
Eu tinha vencido.
Era mais ou menos esse o tamanho do horizonte que eu conseguia enxergar.
E existe uma lição importante aqui para quem está começando uma carreira.
Não despreze sonhos pequenos vistos do futuro.
Eles podem ter sido gigantes quando foram sonhados.
O jovem de 1990 não possuía todas as informações que o homem de 2026 possui.
Ele não poderia planejar aquilo que sequer sabia que existia.
Eu não imaginava o que aconteceria depois.
Não imaginava trabalhar com mainframes.
Não imaginava passar por instalações da IBM na região de Milão.
Não imaginava trabalhar em aeroportos.
Não imaginava mergulhar no sistema financeiro brasileiro.
Não imaginava morar na Europa.
Não imaginava voltar ao Brasil carregando experiências de mundos completamente diferentes.
Muito menos imaginava que, décadas depois, estaria ensinando tecnologia.
Se alguém tivesse contado tudo isso para aquele garoto, talvez ele respondesse:
— Legal. Agora preciso ir embora porque amanhã acordo cedo.
A sobrevivência vinha antes da autobiografia.
5. Enquanto isso, havia um velho chamado COBOL
Aqui nossa história começa a ficar especialmente divertida.
Porque, enquanto eu olhava para aquelas máquinas modernas e imaginava o futuro, havia uma tecnologia que já era considerada velha.
COBOL.
O COBOL surgiu em 1959.
Quando chegamos a 1990, portanto, ele já carregava aproximadamente três décadas de história.
Trinta anos!
Para um adolescente, trinta anos é praticamente arqueologia.
Para entender a transformação tecnológica que viria depois, precisamos lembrar que fotocópias não eram simplesmente conveniência.
Elas faziam parte da infraestrutura social.
Havia lojas especializadas em cópias.
Algumas enormes.
Conheci várias.
Algumas possuíam uma quantidade impressionante de máquinas.
Dez.
Quinze.
Vinte copiadoras.
E havia fila.
Fila de gente querendo transformar papel em mais papel.
Hoje isso parece quase absurdo.
Na época era perfeitamente racional.
Universidades precisavam de cópias.
Escritórios precisavam de cópias.
Empresas precisavam de cópias.
Advogados precisavam de cópias.
Estudantes precisavam de cópias.
Órgãos públicos precisavam de cópias.
Bancos precisavam de cópias.
E a burocracia brasileira possuía uma fome particularmente insaciável por papel.
7. ORIGINAL + 3 VIAS
Quem viveu aquela época conhece a expressão.
Em três vias.
Uma para você.
Uma para o departamento.
Uma para outro departamento.
E talvez uma quarta porque ninguém sabia exatamente onde as outras três terminariam.
Mas não bastava possuir papel.
Era necessário possuir o artefato mágico:
O protocolo.
Carimbo.
Data.
Rubrica.
Pronto.
Sua folha havia adquirido existência administrativa.
O programador COBOL iniciante pode imaginar algo assim:
IF DOCUMENTO-ENTREGUE = 'S'
MOVE FUNCTION CURRENT-DATE
TO DATA-PROTOCOLO
MOVE 'CARIMBADO'
TO STATUS-DOCUMENTO
ELSE
MOVE 'VOCE NAO ENTREGOU'
TO STATUS-DOCUMENTO
END-IF.
Sem protocolo?
Boa sorte.
8. O checksum humano do cartório
E havia outra instituição maravilhosa:
a cópia autenticada.
Você possuía o documento original.
Fazia uma cópia.
Levava original e cópia ao cartório.
Alguém comparava os dois.
E certificava que aquela reprodução correspondia ao original.
Pensando como programador:
DOCUMENTO ORIGINAL
|
V
FOTOCÓPIA
|
V
CÓPIA GERADA
|
V
CARTÓRIO
|
V
COMPARE ORIGINAL WITH COPY
|
+---- DIFERENTE ---> REJECT
|
+---- IGUAL -------> AUTENTICADA
Era um CHECKSUM humano.
Com carimbo.
E fé pública.
O mundo funcionava assim porque a informação ainda estava profundamente associada ao objeto físico que a carregava.
Isso é fundamental para entender o que aconteceu depois.
9. A primeira grande transformação: o documento separou-se do papel
Durante séculos, informação administrativa e papel praticamente caminharam juntos.
Então o computador começou a romper essa relação.
Primeiro criávamos documentos digitalmente e os imprimíamos.
Um mainframe frequentemente não é percebido pelo consumidor.
Mas aquilo que vemos não é necessariamente aquilo que sustenta o processo.
Uma interface pode mudar dez vezes enquanto determinada regra de negócio permanece.
Imagine um cálculo bancário.
Em determinado momento ele foi solicitado por formulário.
Depois:
TERMINAL
Depois:
ATM
Depois:
HOME BANKING
Depois:
WEB
Depois:
SMARTPHONE
Amanhã talvez:
AGENTE DE IA
Mas a pergunta central continuará:
O CLIENTE TEM SALDO?
QUAL A TAXA?
QUAL O LIMITE?
A TRANSAÇÃO É PERMITIDA?
COMO CONTABILIZAR?
A interface muda.
O negócio permanece.
15. O erro de rir do legado
Programadores iniciantes frequentemente encontram algo antigo e imediatamente perguntam:
— Por que ainda usamos isso?
É uma excelente pergunta.
Mas existe uma pergunta melhor:
Por que isso conseguiu sobreviver até aqui?
Essa mudança de perspectiva é poderosa.
Se determinado programa atravessou 20, 30 ou 40 anos de produção, talvez exista uma razão.
Talvez carregue milhares de regras.
Talvez esteja profundamente integrado.
Talvez possua comportamento conhecido.
Talvez tenha sido corrigido centenas de vezes.
Talvez substituir aquilo custe muito mais que mantê-lo.
Talvez ninguém tenha conseguido demonstrar economicamente que a substituição produziria benefício proporcional ao risco.
Legado não significa automaticamente ruim.
Legado significa:
algo que recebemos de quem veio antes.
Pode ser maravilhoso.
Pode ser horroroso.
Normalmente é um pouco dos dois.
16. Curiosidade — o programa também possui arqueologia
Quando você abre um programa COBOL antigo, procure os comentários.
Talvez encontre:
* 1992 - JOSE - ALTERACAO DE JUROS
* 1997 - MARIA - NOVA REGRA
* 2004 - CARLOS - AJUSTE CONTABIL
* 2011 - ANA - PROJETO XYZ
* 2018 - ROBERTO - ADEQUACAO
* 2026 - VAGNER - API
Isso não é apenas documentação.
É estratigrafia.
Cada alteração representa uma camada histórica.
Como uma cidade construída sobre outra cidade.
Ou como aquela loja que primeiro teve uma copiadora, depois dez, depois vinte, depois scanners e finalmente virou outra coisa.
Programas também carregam fósseis.
17. Dica ao programador COBOL iniciante
Quando receber um programa antigo, não comece alterando.
Primeiro investigue.
Passo 1 — descubra quem chama o programa
Batch?
CICS?
Outro programa?
Scheduler?
API?
Passo 2 — descubra os dados
Ele lê VSAM?
Db2?
Arquivo sequencial?
MQ?
Passo 3 — procure as regras
Não fique olhando apenas IF, MOVE e PERFORM.
Pergunte:
que regra de negócio isso representa?
Passo 4 — procure história
Comentários.
Datas.
Alterações.
Chamadas.
Copybooks.
JCL.
Dependências.
Passo 5 — só então modifique
Porque talvez aquele IF aparentemente idiota exista desde 1994 justamente porque alguma sexta-feira terrível ensinou alguém que ele precisava estar ali.
18. Easter egg — o programador de 1990
Imagine que eu consiga entrar novamente naquele centro de treinamento.
O garoto está diante da Xerox.
Chego perto.
Barbudo.
Mais velho.
Cachimbo na mão.
Ele provavelmente ficaria desconfiado.
— Quem é você?
— Longa história.
— Você trabalha aqui?
Olho para meu peito.
Nenhum crachá da Xerox.
— Não.
Talvez ele fique decepcionado.
Então pergunto:
— Você realmente quer trabalhar aqui?
— Claro!
— Por quê?
Ele começa a falar.
Tecnologia.
Salário.
Benefícios.
Carro.
Treinamento.
Ambiente.
Futuro.
Eu sorrio.
Agora compreendo.
Ele não quer aquela empresa especificamente.
Ele quer atravessar aquela porta.
Então digo:
— Continue andando.
— Vou conseguir trabalhar aqui?
Dou outra tragada no cachimbo.
— Não.
Ele me olha indignado.
— Então por que continuar?
Porque agora eu sei algo que ele não sabe.
— Porque existe muito mais depois dessa porta do que você consegue enxergar daqui.
19. Trinta e seis anos depois
A fumaça desaparece lentamente no escritório.
Volto para 2026.
Na minha frente existe um computador infinitamente mais poderoso do que quase qualquer coisa que aquele garoto poderia imaginar.
Posso conversar com inteligência artificial.
Posso acessar sistemas do outro lado do planeta.
Posso ensinar pessoas sem estar na mesma sala.
Posso escrever uma história e publicá-la para milhares de pessoas sem gráfica, fotolito, papel ou copiadora.
A velha Xerox desapareceu da minha frente.
O crachá nunca chegou.
Curiosamente, isso deixou de importar há muito tempo.
Porque vieram outras portas.
Mainframe.
Aeroporto.
Sistema financeiro.
IBM.
Milão.
Europa.
Tecnologia.
Ensino.
Alunos.
Histórias.
E o COBOL?
Bem...
O COBOL estava aqui antes de boa parte dessa história começar.
E continua aqui.
20. A máquina morreu; o sonho não
Talvez seja esse o verdadeiro significado daquela lembrança.
Quando somos jovens, confundimos frequentemente o símbolo com o objetivo.
Eu achava que queria um crachá.
Queria oportunidade.
Achava que queria Xerox.
Queria tecnologia.
Achava que queria aquele prédio.
Queria descobrir até onde poderia chegar.
Achava que queria cinco vezes meu salário.
Também queria isso.
Não vamos romantizar demais.
Os boletos continuavam chegando.
O professor barbudo sabe perfeitamente disso.
Mas havia algo além.
Aquela empresa me mostrou que existia um mundo maior.
E isso foi suficiente.
Epílogo — IDENTIFICATION DIVISION
O cachimbo está quase apagado.
Antes de levantar, olho novamente para a tela.
Talvez toda carreira possua sua própria IDENTIFICATION DIVISION.
IDENTIFICATION DIVISION.
PROGRAM-ID. CRACHA-QUE-EU-NUNCA-TIVE.
AUTHOR. VAGNER-BELLACOSA.
DATE-WRITTEN. 1990.
*------------------------------------------------*
* NA VERDADE O PROGRAMA AINDA ESTAVA SENDO *
* ESCRITO. O PROGRAMADOR APENAS NAO SABIA. *
*------------------------------------------------*
PROCEDURE DIVISION.
PERFORM TRABALHAR.
PERFORM ESTUDAR.
PERFORM ERRAR.
PERFORM APRENDER.
PERFORM VIAJAR.
PERFORM ENSINAR.
PERFORM CONTAR-HISTORIAS.
DISPLAY
'O CRACHA NUNCA CHEGOU.'.
DISPLAY
'MAS EU ATRAVESSEI A PORTA.'.
STOP RUN.
Talvez o detalhe mais bonito seja justamente este:
em 1990 eu olhava para a Xerox e acreditava estar olhando para o futuro.
Eu estava.
Só havia cometido um pequeno erro de interpretação.
O futuro não era a copiadora.
Não era o toner.
Não era o prédio.
Nem sequer era o crachá.
O futuro era o garoto olhando para tudo aquilo e descobrindo que queria ir mais longe.
A Xerox que ele admirava mudou.
As copiadoras gigantes envelheceram.
As lojas cheias de máquinas desapareceram.
O papel perdeu parte do império.
O mundo digital engoliu toneladas de documentos.
Até o telefone virou scanner.
E aquele COBOL que já parecia velho em 1990?
Continua executando.
Talvez esteja tentando nos ensinar alguma coisa.
Máquinas passam.
Empresas mudam.
Tecnologias envelhecem.
Crachás expiram.
Mas conhecimento acumulado, curiosidade e vontade de atravessar a próxima porta possuem uma estranha capacidade de sobreviver.
O professor apaga o cachimbo.
O garoto pega suas coisas e vai embora.
Ainda há um trem para pegar.
Ainda há escola.
Ainda há trabalho amanhã.
Ainda há boletos.
Ele não sabe nada sobre Milão.
Não sabe nada sobre bancos.
Não sabe nada sobre mainframes.
Não sabe que um dia será professor.
Não sabe que, trinta e seis anos depois, ainda se lembrará daquele refeitório.
Melhor assim.
Se soubesse tudo, talvez deixasse de ser sonho e virasse cronograma.
Ele apenas segue andando.
Sem o crachá.
Mas na direção da porta.
☕ Um Café no Bellacosa Mainframe
Onde até uma velha copiadora pode ensinar alguma coisa sobre COBOL, legado, carreira — e sobre os programas que levamos uma vida inteira para compilar.
⚔️ Bellacosa Otaku Blog — Parte 20: Expressões de Batalha, Luta e Ação nos Animes ⚔️
💥 O idioma da força, combate e heroísmo nos animes
(Versão Bellacosa: gritos de poder, golpes espetaculares e energia vibrante que atravessa a tela.)
Nos animes shounen, mecha e de artes marciais, o japonês se transforma em explosão de adrenalina.
Cada palavra, grito ou exclamação carrega energia, desafio e emoção, tornando cada luta memorável.
Vamos explorar as mais icônicas! 🥋
⚡ 1. 必殺技 (hissatsu waza)
Tradução: “Golpe mortal / técnica especial.”
👉 Nome do ataque especial de um personagem, geralmente acompanhado de pose dramática.
Tradução: “Vitória!”
👉 Exclamação clássica ao derrotar o adversário ou vencer uma batalha.
📺 Anime vibe:Dragon Ball, One Piece, Naruto.
💬 Exemplo: “Shouri! Conseguimos vencer a luta!” 🏅
💨 8. 必死! (hisshi!)
Tradução: “Com toda força / até o último esforço.”
👉 Expressa empenho total, coragem extrema e determinação.
📺 Anime vibe:Dragon Ball, Boku no Hero Academia.
💬 Exemplo: “Hisshi! Eu não vou perder para você!” 💥
🌪️ 9. 超 (chou)
Tradução: “Super / ultra.”
👉 Prefixo usado para indicar forma mais poderosa ou ataque elevado.
📺 Anime vibe:Dragon Ball, Naruto, One Piece.
💬 Exemplo: “Chou Saiyan — nível máximo ativado!” ⚡
💥 10. 闘志 (toushi)
Tradução: “Espírito de luta / determinação.”
👉 Palavra que representa coragem, resiliência e vontade de vencer.
📺 Anime vibe:Naruto, Dragon Ball, Bleach.
💬 Exemplo: “Toushi! Não vou recuar nem por um segundo!” 🥋
🏮 Curiosidades Bellacosa:
Gritos de ataque (kougeki!, bougyo!) e nomes de técnicas (hissatsu waza, waza) aumentam a tensão e dramatizam cada combate.
Expressões de energia e esforço (chikara, hisshi!, toushi) são onipresentes em shounen e refletem persistência e espírito de superação.
Exclamações de perigo (abunai!) e vitória (shouri!) tornam as cenas mais imersivas e emocionantes. ⚔️
🌟 Dica Bellacosa:
Observe a entonação e intensidade: mesmo uma palavra curta pode transmitir poder extremo.
Repare nos efeitos visuais e postura do personagem junto com a fala — aumenta a dramaticidade da batalha.
Memorizar essas expressões ajuda a captar tensão, estratégia e emoção de qualquer luta de anime. 💥
🌸 Conclusão Bellacosa:
As expressões de batalha e ação nos animes transmitem força, coragem e emoção máxima.
Cada palavra, grito e comando é uma fagulha de adrenalina, fazendo o espectador sentir-se dentro do combate.
No universo shounen e de artes marciais, o japonês se torna a linguagem do heroísmo e da energia pura. ⚡
“Kougeki! Chikara! Toushi! Hisshi! Shouri é nossa!” 💥🥋
Bellacosa Mainframe e as assinaturas visuais de studios de anime estilo marca registrada
1️⃣ Diferença visual pode existir mesmo sem mudar o estúdio
Sim, mesmo dentro de um mesmo estúdio, animes diferentes podem ter estilos visuais bem distintos. Isso depende de vários fatores:
Diretor de animação / character designer: Cada artista tem um traço próprio, proporções de personagens, expressões faciais e estilo de olhos diferentes.
Orçamento do projeto: Mais verba significa mais frames, mais detalhes, fundos mais ricos e cores melhores.
Temática e público-alvo: Um shoujo vai ter traços mais delicados, olhos maiores, cores suaves; um shounen de ação terá linhas mais marcantes, cores fortes e dinamismo.
2️⃣ Diferença por estúdio
Cada estúdio tem uma “marca registrada”:
Kyoto Animation: Detalhes ricos, animação suave, expressões muito naturais.
Madhouse: Estilos variáveis, mas muita atenção à coreografia de ação e composições de cena.
Trigger: Traços exagerados, movimento estilizado, cores vibrantes.
Então, se você trocar de estúdio, a diferença tende a ser mais perceptível, mas não é regra absoluta. Um diretor pode mudar o visual drasticamente mesmo no mesmo estúdio.
3️⃣ Diferença percebida pelo público
Visualmente, a gente percebe mais:
Expressões faciais e olhos
Movimento e fluidez
Detalhes de fundo
Paleta de cores e iluminação
Se você olhar rápido, às vezes nem percebe se é mudança de estúdio ou só de estilo/tema. Mas se olhar frame a frame, diferenças de “assinatura” artística saltam aos olhos.
💡 Resumo: A diferença pode ser tanto por estúdio quanto por escolha artística do projeto, orçamento e equipe. O estúdio define um “tom”, mas o diretor e o character designer podem mudar completamente o jeito que o anime parece e se sente.
🪄 Bellacosa Otaku Blog — Parte 19: Expressões Sobrenaturais e de Magia nos Animes 🪄
✨ O idioma do misterioso, mágico e sobrenatural nos animes
(Versão Bellacosa: varinhas, feitiços e mundos além da imaginação.)
Nos animes de fantasia, shoujo mágico e sobrenatural, o japonês ganha tons místicos e encantadores.
Cada expressão e palavra pode ser um feitiço, uma maldição ou um ritual, transportando o espectador para outro mundo.
Vamos explorar as mais icônicas! 🔮
🔥 1. 魔法 (mahou)
Tradução: “Magia / feitiço.”
👉 Palavra central em qualquer anime de magia, referindo-se ao poder sobrenatural ou habilidades especiais.
📺 Anime vibe:Cardcaptor Sakura, Little Witch Academia.
💬 Exemplo: “Mahou! Hora de lançar o feitiço!” ✨
🪄 2. 呪文 (jumon)
Tradução: “Encantamento / feitiço.”
👉 Palavra usada para descrever a recitação de feitiços ou fórmulas mágicas.
Tradução: “Alucinação / ilusão.”
👉 Usada para enganar, confundir ou criar efeitos sobrenaturais visuais.
📺 Anime vibe:Naruto, Monogatari Series.
💬 Exemplo: “Genkaku! Ele não pode ver a realidade!” 🌫️
🕯️ 10. 神秘 (shinpi)
Tradução: “Mistério / místico.”
👉 Palavra que envolve a ideia de algo desconhecido e sobrenatural.
📺 Anime vibe:Mushishi, Natsume Yuujinchou.
💬 Exemplo: “Shinpi envolve esta floresta há séculos…” 🌌
🏮 Curiosidades Bellacosa:
Termos como mahou, henshin e jumon são frequentemente acompanhados de gestos, palavras longas e efeitos visuais, tornando a magia mais teatral.
Expressões de poder espiritual (seishinryoku) e trevas (yami) são comuns em batalhas sobrenaturais.
Palavras de mistério e maldição (noroi, shinpi) criam atmosfera de suspense e fantasia. 🔮
🌟 Dica Bellacosa:
Observe a entonação e pausa: feitiços longos ou curtos mudam a sensação de poder e mistério.
Aprender essas palavras ajuda a entender rituais, magias e lógicas sobrenaturais japonesas.
Onomatopeias e expressões visuais reforçam emoção, suspense e espetáculo mágico. ✨
🌸 Conclusão Bellacosa:
As expressões de magia e sobrenatural nos animes transformam o japonês em uma linguagem de poder, mistério e encantamento.
Cada palavra é um feitiço que ativa emoção, tensão ou fascínio, transportando o espectador para mundos além da imaginação.
“Mahou! Henshin! Shinpi nos guia… prepare-se para o desconhecido!” 🪄✨
Nenhuma delas acreditava que apenas marketing seria suficiente.
Todas compreenderam que crescimento exige engenharia.
Essa continua sendo uma das maiores diferenças entre demonstrações impressionantes e produtos duradouros.
O Mainframe Sempre Conheceu Esse Princípio
Para um profissional COBOL, essa conclusão parece quase óbvia.
Durante décadas, sistemas bancários sempre foram projetados pensando em:
crescimento;
disponibilidade;
redundância;
recuperação;
desempenho;
segurança.
Ninguém constrói um sistema de pagamentos imaginando apenas a demonstração para um cliente.
Ele precisa continuar funcionando durante anos.
É exatamente essa mentalidade que começou a reaparecer na indústria de software após a bolha.
As empresas voltaram a valorizar arquitetura.
Não apenas velocidade.
A Crise Eliminou Concorrentes
Existe uma consequência pouco comentada sobre grandes crises.
Elas reduzem drasticamente a concorrência.
Quando centenas de startups desapareceram, empresas sobreviventes passaram a disputar um mercado muito menos congestionado.
Amazon encontrou menos competidores.
Google tornou-se rapidamente referência em buscas.
eBay consolidou sua liderança.
Salesforce expandiu-se praticamente sozinha no mercado de CRM em nuvem.
Paradoxalmente...
A crise abriu espaço para gigantes crescerem ainda mais.
A Internet Ficou Mais Forte
Pode parecer contraditório.
Mas a bolha fortaleceu a própria Internet.
Como?
Eliminando modelos insustentáveis.
Concentrando investimentos em empresas mais eficientes.
Incentivando engenharia de melhor qualidade.
Criando consumidores mais confiantes.
Melhorando infraestrutura.
Fortalecendo meios de pagamento.
Quando a década seguinte começou...
A Internet estava muito mais preparada para crescer.
A crise havia funcionado como uma gigantesca poda.
As raízes permaneceram.
Os galhos fracos desapareceram.
O Paralelo com a Inteligência Artificial
Estamos vivendo algo semelhante atualmente.
Existem milhares de startups de IA.
Nem todas sobreviverão.
Isso não significa que a Inteligência Artificial fracassará.
Muito provavelmente ocorrerá o oposto.
Assim como aconteceu após as Dot-Com, algumas poucas empresas construirão infraestrutura sólida, resolverão problemas relevantes e permanecerão durante décadas.
Outras desaparecerão.
A tecnologia continuará evoluindo.
A história mostra que inovação costuma sobreviver às bolhas.
O que normalmente não sobrevive são os modelos econômicos mal planejados.
Lições para o Padawan COBOL
Existe uma razão pela qual programas COBOL escritos há quarenta anos continuam executando milhões de transações diariamente.
Eles foram desenvolvidos para resolver problemas concretos.
Não para impressionar investidores.
Essa talvez seja a maior diferença entre sistemas críticos e muitos produtos criados durante períodos de euforia.
Um sistema duradouro nasce da combinação entre boa engenharia, visão de longo prazo e disciplina operacional.
Empresas também.
No universo da Frota Estelar, durante uma batalha, as naves mais vistosas nem sempre sobrevivem. Muitas possuem armamentos impressionantes, mas pouca resistência estrutural. Já as naves projetadas por engenheiros cuidadosos suportam impactos, adaptam-se aos danos, redistribuem energia e continuam cumprindo sua missão.
Foi exatamente isso que aconteceu após a bolha da Internet.
As empresas que sobreviveram não eram necessariamente as mais rápidas.
Eram as mais resilientes.
No próximo capítulo conheceremos uma das maiores ironias dessa história: como justamente o colapso das Dot-Com abriu caminho para a Web 2.0, as redes sociais, os smartphones e praticamente toda a economia digital que conhecemos hoje. Às vezes, destruir o excesso é exatamente o que permite o verdadeiro crescimento.
"O maior desperdício da engenharia não é escrever código ruim. É escrever código que jamais resolverá um problema real."
Naquele momento Neo compreendeu o verdadeiro significado do YAGNI.
O que significa YAGNI?
YAGNI significa:
You Aren't Gonna Need It
Em português:
"Você não vai precisar disso."
É um dos princípios mais conhecidos da metodologia Extreme Programming (XP).
Sua ideia é extremamente simples.
Não implemente hoje funcionalidades que talvez sejam necessárias amanhã.
Implemente apenas aquilo que resolve um problema existente.
A origem do princípio
O YAGNI surgiu no final da década de 1990 dentro do movimento Extreme Programming, criado por Kent Beck.
Na época, muitas equipes gastavam enorme quantidade de tempo construindo recursos para um futuro hipotético.
Esses recursos quase nunca eram utilizados.
Kent Beck propôs uma filosofia radical.
Construa somente aquilo que possui necessidade comprovada.
Quando surgir uma nova necessidade.
Implemente naquele momento.
Matrix explica perfeitamente
Imagine que o Arquiteto resolvesse prever todas as possibilidades da humanidade.
Então incluiria:
controle de dragões;
módulo para dinossauros;
protocolo para viagens no tempo;
economia marciana;
integração com civilizações alienígenas.
Tudo isso "caso um dia seja necessário".
Resultado?
A Matrix seria gigantesca.
Difícil de manter.
Lenta.
Cheia de código inútil.
Como nasce o excesso?
Sempre começa com boas intenções.
Alguém diz.
"Vai que um dia..."
Depois aparecem frases como:
"Já vamos deixar preparado."
"Aproveita e cria também..."
"É só mais um IF."
"No futuro pode servir."
Meses depois.
Ninguém usa.
O COBOL conhece isso muito bem
Imagine um sistema bancário.
O requisito diz:
Calcular IOF.
O desenvolvedor pensa.
"Vai que um dia o banco trabalhe com Bitcoin, Ouro, Marte e Lua."
Então cria:
vinte tabelas;
quinze tipos de moeda;
cinquenta parâmetros.
Quando entra em produção.
Existe apenas:
Real.
Um exemplo COBOL
Requisito.
Calcular juros.
Solução simples.
COMPUTE JUROS = SALDO * TAXA
Solução YAGNI ignorado.
Cria:
Framework de cálculo.
Plugin.
Factory.
Reflection.
Configuração XML.
API REST.
Tabela dinâmica.
Tudo para multiplicar dois números.
Matrix Reloaded
O Arquiteto mostra milhares de possibilidades futuras.
Neo pergunta.
— Precisamos construir tudo isso?
O Arquiteto responde.
— Não.
O Oráculo sorri.
— O futuro ainda não decidiu existir.
O efeito psicológico
Existe um medo comum entre desenvolvedores.
"E se amanhã precisarmos?"
Essa pergunta gera enormes desperdícios.
Porque o amanhã raramente acontece exatamente como imaginamos.
O Programador COBOL Padawan
Imagine seu primeiro projeto.
O gerente pede:
— Precisamos gerar um relatório.
Você responde.
— Já vou criar vinte modelos diferentes.
Pergunta.
O cliente pediu vinte?
Não.
Pediu um.
O Agente Smith ama funcionalidades imaginárias
Porque cada funcionalidade extra gera:
novos bugs;
novos testes;
nova documentação;
novas dependências;
novas exceções.
Quanto mais código.
Maior a superfície para ataques.
Um exemplo inspirado na Matrix
Neo pergunta.
— Quantas portas existem?
O Chaveiro responde.
— Mil.
Neo pergunta.
— Quantas usamos?
— Dez.
As outras novecentas e noventa foram criadas "caso um dia fossem necessárias".
O custo invisível
Toda funcionalidade possui custo.
Mesmo sem uso.
Ela precisa:
compilar;
ser testada;
documentada;
protegida;
revisada;
mantida.
Nada é gratuito.
O impacto no Mainframe
Em ambientes IBM Z aparecem frequentemente:
COPYBOOKs preparados para campos inexistentes;
layouts gigantes;
tabelas nunca utilizadas;
JCLs reservados para processos imaginários;
programas chamados apenas "no futuro".
Tudo isso aumenta:
CPU;
armazenamento;
manutenção.
Curiosidade
Diversos estudos em desenvolvimento de software mostram que uma parcela significativa das funcionalidades presentes em sistemas corporativos é usada muito raramente ou nunca é utilizada pelos usuários finais.
Isso reforça a importância de validar necessidades reais antes de implementar novas capacidades.
Atenção!
YAGNI não significa:
"Nunca pensar no futuro."
Significa:
"Não implementar antes da hora."
Arquitetura pode prever evolução.
Código desnecessário não.
A diferença
Preparar arquitetura
Permitir crescimento.
Implementar tudo
Criar desperdício.
Matrix e Zion
Imagine construir:
cem hangares;
mil naves;
cinquenta hospitais.
Antes mesmo de saber quantas pessoas viverão em Zion.
Seria desperdício.
Ferramentas ajudam
Hoje podemos medir uso real.
Telemetria.
Analytics.
Logs.
Feature Flags.
IBM Instana.
OMEGAMON.
Monitoramento de APIs.
Esses dados mostram o que realmente é utilizado.
O papel da IA
A IA frequentemente sugere funcionalidades extras.
Cabe ao engenheiro perguntar.
"O cliente pediu isso?"
Se a resposta for não.
Talvez seja YAGNI.
Os riscos
Ignorar YAGNI gera:
overengineering;
manutenção cara;
código morto;
testes maiores;
documentação enorme;
mais bugs.
Erros clássicos
Programar para cenários imaginários.
Criar abstrações prematuras.
Implementar requisitos inexistentes.
Confundir arquitetura extensível com funcionalidades prontas.
Aceitar "vai que um dia".
Boas práticas
Desenvolver apenas requisitos atuais.
Validar com usuários.
Medir utilização.
Evoluir incrementalmente.
Refatorar quando necessário.
Simplificar continuamente.
Aplicabilidade
YAGNI aparece em:
COBOL.
Java.
Python.
Cloud.
APIs.
Microsserviços.
Mobile.
IA.
DevOps.
ERP.
Um exemplo COBOL
Cliente pede.
Cadastro de Endereço.
Você cria.
Rua.
Número.
Cidade.
Estado.
CEP.
Não precisa adicionar:
Colônia em Marte.
Quadrante Galáctico.
Planeta de Origem.
Coordenadas Quânticas.
Até que alguém realmente peça.
YAGNI e os outros princípios
YAGNI conversa diretamente com quase todos os princípios estudados nesta série.
Ele reduz:
Golden Hammer, porque evita criar soluções grandiosas para problemas pequenos.
Lasagna Code, porque impede camadas desnecessárias.
Lava Flow, porque evita código que nunca será usado e depois ninguém tem coragem de remover.
Boiling Frog, porque impede o crescimento silencioso da complexidade.
KISS, porque incentiva soluções simples.
Death March, porque reduz trabalho desnecessário.
Brooks's Law, porque menos funcionalidades significam menos necessidade de crescimento artificial da equipe.
YAGNI é um excelente antídoto contra o excesso de zelo que acaba produzindo desperdício.
O ensinamento do Oráculo
O Oráculo entrega uma mochila para Neo.
Dentro dela existem:
vinte lanternas;
quinze bússolas;
dez rádios;
cinco espadas;
três computadores;
duas cafeteiras.
Neo tenta levantá-la.
Não consegue.
Ela retira tudo.
Deixa apenas:
uma bússola.
água.
e uma lanterna.
Neo sorri.
— Agora consigo caminhar.
Ela responde.
"Quem leva tudo para uma jornada acaba sem forças para percorrê-la."
Lições para um Programador COBOL Padawan
Ao longo da carreira você ouvirá muitas sugestões começando com:
"Já aproveita..."
"Vai que..."
"Quem sabe no futuro..."
"Deixa preparado..."
Antes de aceitar, faça algumas perguntas:
Existe um requisito aprovado?
Há uma necessidade real?
Algum usuário pediu isso?
Existe previsão concreta de uso?
Estamos aumentando a complexidade sem necessidade?
Se a resposta for "não", provavelmente você está diante de um caso clássico de YAGNI.
Projetar sistemas preparados para evoluir é excelente.
Implementar funcionalidades imaginárias é desperdício.
Curiosidades
O princípio YAGNI influenciou fortemente várias práticas modernas:
Agile, priorizando valor entregue a cada iteração.
Feature Flags, permitindo ativar funcionalidades apenas quando realmente necessárias.
MVP (Minimum Viable Product), que incentiva lançar a menor solução capaz de gerar valor.
Continuous Delivery, favorecendo evolução contínua em vez de grandes antecipações.
Todos compartilham a mesma ideia: desenvolva apenas aquilo que gera valor agora.
Conclusão — O Futuro Ainda Não Escreveu Seu Código
Quando Neo percorreu o depósito do Arquiteto, percebeu que milhares de módulos existiam apenas para responder a perguntas que ninguém jamais faria.
Na Engenharia de Software isso acontece com frequência.
O princípio YAGNI nos lembra que o futuro é imprevisível. As funcionalidades imaginadas hoje dificilmente corresponderão exatamente às necessidades reais de amanhã.
Para um Programador COBOL, especialmente em ambientes IBM Z onde estabilidade, desempenho e facilidade de manutenção são essenciais, escrever menos código costuma ser uma decisão mais inteligente do que escrever código "por precaução".
Cada linha adicionada representa mais testes, mais documentação, mais manutenção e mais oportunidades para o Agente Smith encontrar uma brecha.
No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada na oficina do Chaveiro:
"Não construa hoje a chave de uma porta que talvez nunca exista. Quando essa porta aparecer, você terá conhecimento, ferramentas e experiência para fabricar exatamente a chave de que ela precisa."
Porque o verdadeiro engenheiro não é aquele que tenta prever todos os futuros possíveis.
É aquele que constrói sistemas simples, elegantes e preparados para evoluir quando o futuro finalmente bater à porta.
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
