✨ 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
O ZUnit consegue testar componentes que normalmente seriam executados sob CICS.
Exemplo:
EXEC CICS LINK
Através de stubs e ambientes controlados.
Isso reduz enormemente o tempo de validação.
TESTANDO DB2
Também é possível criar cenários envolvendo:
SELECT
INSERT
UPDATE
DELETE
utilizando ambientes isolados.
MOCKS E STUBS
Conceito muito usado no mundo distribuído.
Exemplo:
Programa chama:
CONSULTA-CLIENTE
Mas o programa real não existe no ambiente.
Criamos um:
Stub
que responde:
CLIENTE VÁLIDO
Assim o teste continua funcionando.
INTEGRAÇÃO COM DEVOPS
O ZUnit tornou-se peça importante do pipeline moderno.
Fluxo:
Git
↓
Build
↓
Compilação COBOL
↓
ZUnit
↓
Deploy
Se um teste falhar:
Deploy Bloqueado
BENEFÍCIOS REAIS
Menos regressões
Alterou um cálculo?
Execute 500 testes.
Mais confiança
Mudanças menores tornam-se seguras.
Documentação viva
Os testes mostram como o programa deveria funcionar.
Onboarding
Novo desenvolvedor entende rapidamente a lógica.
CURIOSIDADES
Curiosidade 1
Muitos sistemas COBOL possuem mais de:
20 milhões de linhas
Sem testes automatizados.
Curiosidade 2
Alguns bancos executam milhares de testes ZUnit por dia.
Antes mesmo do primeiro usuário acessar o sistema.
Curiosidade 3
Em muitos projetos, o maior esforço não é criar o teste.
É descobrir qual deveria ser o resultado correto.
Curiosidade 4
A adoção do ZUnit foi impulsionada pelo movimento:
Shift Left Testing
Testar mais cedo.
Corrigir mais barato.
DICAS DE MESTRE JEDI MAINFRAME
Não teste programas gigantes primeiro
Comece pelos módulos menores.
Teste regras de negócio
Prioridade:
Cálculos
Tarifas
Juros
Impostos
Limites
Automatize regressões
Todo defeito corrigido deve virar um teste.
Integre com Git
Cada commit deve executar testes.
Pense como um auditor
Pergunta:
"Como provo que este cálculo continua correto após a alteração?"
Se o ZUnit responde essa pergunta, você está usando a ferramenta corretamente.
O VERDADEIRO SIGNIFICADO DO ZUNIT
Padawan...
O ZUnit não foi criado para testar COBOL.
Ele foi criado para proteger conhecimento corporativo acumulado durante décadas.
Quando um banco possui um programa escrito em 1987, alterado por 200 pessoas diferentes ao longo de 40 anos, o risco não está na compilação.
O risco está em quebrar silenciosamente uma regra de negócio que movimenta milhões de reais por dia.
O ZUnit é a resposta moderna para um problema antigo:
"Como mudar um sistema legado sem destruir aquilo que o tornou valioso?"
E é justamente por isso que muitos arquitetos consideram o ZUnit uma das tecnologias mais importantes da modernização do IBM Z: não porque ele substitui o COBOL, mas porque permite evoluí-lo com segurança. ☕💣🚀
Quando um Programador COBOL Descobriu que a Matrix Era Feita de Espaguete e Cada GO TO Criava um Novo Labirinto
"A Matrix não aprisionava apenas pessoas. Ela também aprisionava programas dentro de um emaranhado de caminhos onde ninguém mais sabia como chegar à saída."
Prólogo — O Labirinto Invisível da Matrix
Neo acabara de receber uma missão aparentemente simples.
Corrigir um erro no cálculo dos juros de um financiamento.
Morpheus entregou um único arquivo.
FINANCEIRO01.CBL
Neo sorriu.
— Apenas um programa?
Morpheus respondeu.
— Sim.
Só um.
Neo abriu o código.
A barra de rolagem diminuiu.
Muito.
Muito mesmo.
O programa possuía:
68.000 linhas
2.400 parágrafos
centenas de GO TO
dezenas de ALTER
milhares de variáveis
comentários escritos por gerações diferentes
Neo tentou localizar a regra do financiamento.
Cinco minutos depois...
estava em outra rotina.
Dez minutos depois...
entrou em um PERFORM.
Depois um GO TO.
Depois outro.
Depois um PERFORM THRU.
Depois um ALTER.
Depois um EXIT.
Depois voltou.
Depois foi para outro programa.
Depois retornou.
Finalmente perguntou:
— Morpheus...
onde exatamente começa esse cálculo?
Morpheus sorriu.
— Essa pergunta já foi feita por pelo menos cinquenta programadores antes de você.
O Oráculo apareceu.
Olhou para Neo.
E disse:
"Você não entrou apenas em um programa. Entrou em um prato de espaguete."
O que é Spaghetti Code?
Spaghetti Code (Código Espaguete) é um antipadrão de software caracterizado por uma estrutura extremamente confusa, onde o fluxo de execução é difícil de compreender, seguir ou modificar.
O nome vem da aparência do fluxo lógico.
Imagine um prato cheio de espaguete.
Os fios cruzam-se em todas as direções.
Você tenta puxar um.
Leva metade do prato junto.
No software acontece exatamente igual.
Uma alteração aparentemente simples afeta dezenas de outras partes.
A origem do termo
O termo surgiu na década de 1970.
Naquela época muitos sistemas eram escritos utilizando:
GOTO
Jumps
Branches
Fluxos não estruturados
Os diagramas de execução pareciam literalmente um prato de macarrão.
Daí nasceu o nome.
Matrix explica melhor que qualquer livro
Imagine que Neo precisa chegar até o Arquiteto.
Mas cada corredor leva para outro corredor.
Cada porta abre outra porta.
Cada elevador muda de direção.
Cada escolha cria um novo caminho.
Após meia hora...
Neo percebe.
A Matrix inteira virou um labirinto.
É exatamente essa sensação que um desenvolvedor experimenta ao abrir um sistema com Spaghetti Code.
O nascimento do espaguete
Curiosamente...
ninguém acorda pensando:
"Hoje vou criar um código horrível."
O Spaghetti Code nasce lentamente.
Primeiro.
Um pequeno ajuste.
Depois.
Outro.
Depois.
Uma exceção.
Depois.
Uma regra temporária.
Depois.
Outra urgência.
Depois.
Uma correção rápida.
Cinco anos depois...
o prato está servido.
Um exemplo COBOL
Imagine este fluxo.
INICIO
↓
VALIDA
↓
CALCULA
↓
GRAVA
↓
FIM
Bonito.
Agora imagine vinte anos depois.
INICIO
↓
VALIDA
↓
GO TO ROTINA-X
↓
PERFORM Y
↓
ALTER Z
↓
GO TO A
↓
PERFORM THRU B
↓
ROTINA-C
↓
GO TO D
↓
VALIDA NOVAMENTE
↓
VOLTA
↓
FIM
Ninguém mais entende.
Como surge?
Existem várias causas.
Crescimento contínuo
Programa pequeno.
Depois médio.
Depois enorme.
Falta de arquitetura
Cada desenvolvedor cria sua própria organização.
Pressão por prazo
"Depois organizamos."
Nunca organizam.
Excesso de GO TO
O clássico dos clássicos.
Código duplicado
Trechos espalhados.
Ausência de revisão
Ninguém verifica consistência.
O COBOL é culpado?
Não.
Essa talvez seja a maior injustiça da história da computação.
COBOL moderno incentiva:
PERFORM
Modularização
COPYBOOK
CALL
Programas estruturados
Classes
Métodos (Enterprise COBOL moderno)
O problema nunca foi COBOL.
Foi a forma como algumas pessoas programaram.
Matrix Reloaded
O Arquiteto mostra milhares de versões anteriores da Matrix.
Cada versão acumulava pequenos remendos.
Nenhum parecia perigoso.
Todos juntos criaram enorme complexidade.
Software evolui exatamente assim.
O efeito psicológico
Existe uma armadilha.
Quando modificamos um programa conhecido.
Pensamos:
"Vou colocar só mais um IF."
Depois outro.
Depois outro.
Cada alteração parece pequena.
A soma delas não é.
O Programador COBOL Padawan
Todo Padawan abre um programa antigo e pensa.
"Vou entender rapidamente."
Uma hora depois.
Ainda tenta descobrir onde começou.
O Agente Smith adora Spaghetti Code
Porque sistemas confusos criam:
medo.
Ninguém gosta de alterar.
Cada mudança parece perigosa.
Smith nem precisa atacar.
O próprio código afasta os desenvolvedores.
Um exemplo inspirado na Matrix
Imagine que Neo precisa abrir uma porta.
Mas antes precisa:
abrir outra.
Depois outra.
Depois voltar.
Depois pegar uma chave.
Depois retornar.
Depois abrir outra porta.
É exatamente isso que acontece em muitos fluxos de programas antigos.
Como reconhecer?
Existem sinais claros.
Muitos GO TO
Principal indicador.
Programas enormes
30 mil.
50 mil.
100 mil linhas.
Variáveis sem significado
A1
B2
X99
WK01
WK02
WK03
Regras espalhadas
Mesmo cálculo aparece em cinco lugares.
Dependências circulares
Programa chama outro.
Que chama outro.
Que volta ao primeiro.
Um caso realista
Imagine.
Sistema bancário.
Criado em:
Mais de:
400 modificações.
Nenhuma refatoração.
Resultado.
Cada alteração exige:
dois analistas
três programadores
uma semana de testes
Não porque a regra seja difícil.
Mas porque ninguém sabe o impacto.
Os riscos
Bugs
Alteração pequena.
Impacto gigante.
Performance
Fluxo desnecessário.
CPU
Mais instruções.
Mais custo.
Manutenção
Tempo explode.
Onboarding
Novos profissionais sofrem.
Burnout
Especialistas tornam-se gargalos.
O custo invisível
Imagine.
Alteração.
15 minutos.
Mas entender o programa leva:
dois dias.
Isso é custo.
O impacto no Mainframe
Mainframe processa:
milhões de transações.
Spaghetti Code aumenta:
CPU
consumo
risco
testes
tempo de homologação
Tudo fica mais caro.
Existe ferramenta para medir?
Sim.
Hoje existem ferramentas excelentes.
IBM ADDI
IBM Application Discovery
SonarQube
IBM COBOL Check
IBM Developer for z/OS
Enterprise Analyzer
Elas calculam:
complexidade ciclomática
dependências
acoplamento
fluxo
Como evitar?
Modularização
Divida responsabilidades.
PERFORM
Prefira estruturas claras.
CALL
Separe funcionalidades.
COPYBOOK
Padronize estruturas.
Refatoração contínua
Não espere dez anos.
Comentários úteis
Explique:
por quê.
Não:
o quê.
Testes
Protegem refatorações.
Atenção!
Existe diferença entre:
Programa grande
e
Spaghetti Code.
Alguns sistemas possuem:
200 mil linhas.
Mas excelente organização.
Outros possuem:
2 mil linhas.
Completamente caóticos.
O tamanho não define qualidade.
O papel da arquitetura
Arquitetura cria limites.
Cada módulo possui função.
Sem arquitetura.
Tudo conversa com tudo.
Matrix e os Sentinelas
Os Sentinelas encontram Zion porque seguem caminhos claros.
Imagine se existissem milhões de túneis aleatórios.
Eles demorariam muito mais.
Código também.
Fluxos claros facilitam manutenção.
Curiosidade
A Structured Programming Movement dos anos 70 surgiu justamente para combater o Spaghetti Code.
Nomes como:
Edsger Dijkstra
Niklaus Wirth
Donald Knuth
mudaram completamente a forma de programar.
O famoso artigo:
"Go To Statement Considered Harmful"
transformou a indústria.
O COBOL moderno
Enterprise COBOL oferece recursos para escrever código extremamente limpo.
Inline PERFORM
EVALUATE
Functions
Nested Programs
OO COBOL
User Defined Functions
XML
JSON
Não existe desculpa para criar espaguete.
Erros clássicos
Misturar regras de negócio e acesso a dados.
Usar GO TO excessivamente.
Duplicar lógica.
Não remover código morto.
Acrescentar IFs infinitamente.
Não modularizar.
Boas práticas
Uma responsabilidade por módulo.
Nomes significativos.
Fluxo previsível.
Revisões frequentes.
Refatoração incremental.
Diagramas atualizados.
Documentação viva.
O Ensinamento do Oráculo
O Oráculo entrega um prato de espaguete para Neo.
Ele tenta puxar um fio.
Todo o prato vem junto.
Ela então entrega uma caixa organizada de peças LEGO.
Cada bloco possui uma função.
Ela sorri.
"Software deve parecer LEGO. Nunca espaguete."
Aplicabilidade
Spaghetti Code aparece em:
COBOL
Java
Python
C
C++
JavaScript
PHP
Rust
Go
Assembly
Nenhuma linguagem está imune.
Lições para um Programador COBOL Padawan
Quando você começar sua carreira em um ambiente IBM Z, encontrará programas escritos há décadas. Alguns serão verdadeiras obras-primas da engenharia. Outros parecerão um labirinto digno da Matrix.
A tentação será adicionar "apenas mais um IF" ou "mais um GO TO" para resolver rapidamente um incidente. Resista.
Sempre que possível:
extraia responsabilidades para novos módulos;
elimine duplicações;
substitua fluxos confusos por estruturas claras;
escreva nomes compreensíveis;
documente regras de negócio;
mantenha testes atualizados.
Cada pequena melhoria reduz um pouco o emaranhado do espaguete e facilita o trabalho do próximo desenvolvedor.
Conclusão — Saindo do Prato de Espaguete da Matrix
No final da trilogia Matrix, Neo percebe que compreender a estrutura da Matrix é mais poderoso do que simplesmente reagir a ela.
Na Engenharia de Software, acontece exatamente o mesmo.
O maior problema do Spaghetti Code não é ser feio.
É transformar cada alteração em uma aventura imprevisível.
Em sistemas COBOL responsáveis por processar milhões de transações financeiras, isso significa mais tempo de manutenção, maior risco de incidentes, consumo adicional de CPU, testes mais demorados e equipes receosas de evoluir o software.
No universo Bellacosa Mainframe existe uma máxima que todo Programador COBOL Padawan deveria guardar:
"Cada GO TO desnecessário é mais um corredor dentro da Matrix. Cada módulo bem organizado é uma porta de saída."
O objetivo não é escrever o código mais inteligente.
É escrever o código que outro programador — talvez você mesmo daqui a dez anos — consiga entender sem precisar da ajuda do Oráculo.
Porque o verdadeiro Escolhido não é aquele que cria o maior labirinto.
É aquele que sabe construir o caminho mais simples até a solução.
Douglas Adams: o Homem que Descobriu que o Universo Rodava em Produção sem Documentação
🌌 Vida, obra, computadores, toalhas, rinocerontes, prazos impossíveis e a curiosa história do escritor que parecia ter escapado de um dos próprios livros
DON'T PANIC.
Há escritores que criam personagens.
Há escritores que criam universos.
E há Douglas Adams, que conseguiu realizar uma façanha consideravelmente mais improvável:
criou um universo tão parecido consigo mesmo que, depois de algum tempo, ficou difícil descobrir onde terminava Douglas Adams e começava O Guia do Mochileiro das Galáxias.
Ele era enorme.
Literalmente.
Tinha quase dois metros de altura.
Gostava de computadores, guitarras, ciência, tecnologia, carros, animais, viagens, ideias absurdas e prazos — embora sua relação com estes últimos fosse comparável à relação de um programa COBOL de 1973 com uma especificação OpenAPI.
Sabia que existiam.
Reconhecia sua importância.
Mas preferia encontrá-los passando rapidamente ao longe.
Douglas Noël Adams nasceu em Cambridge, Inglaterra, em 11 de março de 1952, estudou em Brentwood e depois literatura inglesa no St John's College, Cambridge. Antes de se tornar mundialmente famoso, passou por uma coleção de empregos e experiências que parecem ter sido escolhidos por um gerador aleatório de profissões: escritor, produtor de rádio, roteirista, performer e, em certos períodos, trabalhos completamente distantes da carreira literária. (Douglas Adams)
Mais tarde escreveria para Monty Python, trabalharia em Doctor Who, criaria Dirk Gently, se apaixonaria por computadores, ajudaria causas ambientais, desenvolveria jogos e acabaria criando uma das obras mais deliciosamente absurdas da cultura pop.
Tudo isso antes de morrer, inesperadamente, em 2001, aos 49 anos.
Mas começar pelo fim seria terrivelmente organizado.
E Douglas Adams provavelmente desconfiaria disso.
Portanto:
pegue sua toalha.
Vamos começar pelo lugar mais apropriado.
No meio do caos.
🌍 CAPÍTULO 1
Um inglês de quase dois metros tentando descobrir o que fazer da vida
Douglas Adams não surgiu magicamente carregando um exemplar do Guia do Mochileiro das Galáxias.
Antes do sucesso houve algo que todo programador conhece muito bem:
tentativa
erro
tentativa
erro
boletos e conta para pagar
tentativa
erro
ideia estranha
tentativa
Em Cambridge, Adams se envolveu com o ambiente de comédia estudantil e com o Footlights, tradicional celeiro britânico de humoristas.
Seu interesse era escrever comédia.
Não exatamente ficção científica.
Essa distinção é importante.
Adams chegou a explicar que se considerava fundamentalmente um escritor de comédia, usando os mecanismos da ficção científica para satirizar praticamente todo o resto. (Enciclopédia)
Isso explica muita coisa.
As naves espaciais são cenário.
Os alienígenas são ferramentas.
Os computadores gigantes são piadas.
O verdadeiro assunto é:
nós.
A burocracia.
A arrogância.
A tecnologia.
O governo.
A religião.
A economia.
Os restaurantes.
As filas.
Os formulários.
Os especialistas.
E principalmente nossa incrível capacidade de construir sistemas complicadíssimos para resolver problemas que talvez não precisassem existir.
Um programador mainframe reconhece imediatamente esse universo.
🐍 CAPÍTULO 2
Antes das galáxias havia Monty Python
Existe uma conexão maravilhosa entre Adams e Monty Python.
Ele trabalhou com Graham Chapman e conseguiu créditos no programa.
Douglas está inclusive entre o pequeno grupo de pessoas externas ao núcleo principal do Python que recebeu crédito de roteiro na série original. Também apareceu rapidamente diante das câmeras em episódios da quarta temporada.
E aqui encontramos parte do código-fonte de seu humor.
Imagine:
Monty Python
+
ficção científica
+
rádio BBC
+
filosofia
+
burocracia britânica
+
computadores
+
chá
+
um sujeito olhando para o universo e perguntando:
"Mas quem aprovou essa arquitetura?"
Resultado:
Douglas Adams.
Seu nonsense não era simplesmente aleatório.
Essa é uma das grandes lições para quem tenta imitá-lo.
Por trás do absurdo existe lógica.
Uma lógica impecável.
O problema é que a premissa inicial é completamente insana.
📺 CAPÍTULO 3
Doctor Who entra no CPD
Antes e durante a explosão de Hitchhiker's, Adams também trabalhou em outra instituição britânica:
Doctor Who.
Foi roteirista e chegou a atuar como script editor da série.
Entre suas contribuições estão histórias relacionadas a:
The Pirate Planet;
City of Death;
Shada;
e trabalhos na temporada 17.
Isso é importantíssimo para entender Adams.
Porque Doctor Who permitia exatamente aquilo de que ele gostava:
pegar uma ideia filosófica absurda...
...transformá-la em problema tecnológico...
...colocar personagens britânicos no meio...
...e observar a civilização entrar em pane.
Em outras palavras:
produção.
🚀 CAPÍTULO 4
O Guia nasceu no rádio
Aqui existe uma curiosidade maravilhosa para uma geração acostumada a pensar primeiro em livros.
O Guia do Mochileiro das Galáxias não nasceu como livro.
Nasceu como programa de rádio da BBC Radio 4.
A primeira transmissão aconteceu em março de 1978. (Douglas Adams)
Depois veio praticamente tudo:
RÁDIO
↓
LIVROS
↓
TV
↓
DISCOS
↓
TEATRO
↓
JOGO DE COMPUTADOR
↓
FILME
↓
mais adaptações
↓
fãs discutindo cronologia
↓
42
O próprio site dedicado à obra de Adams registra essa extraordinária multiplicação de formatos. (Douglas Adams)
Portanto, chamar Hitchhiker's simplesmente de "uma série de livros" é quase como chamar z/OS de editor de texto.
Tecnicamente há texto envolvido.
Mas estamos omitindo alguns detalhes.
🌍 CAPÍTULO 5
Arthur Dent: o homem que só queria sua casa
E aqui encontramos nosso primeiro suspeito de ser Douglas Adams disfarçado.
Arthur Dent.
Arthur não é Luke Skywalker.
Não quer salvar a galáxia.
Não possui poderes.
Não tem treinamento Jedi.
Não descobriu ser herdeiro de nenhuma dinastia.
Arthur gostaria basicamente de:
ter sua casa
tomar chá
entender o que está acontecendo
Infelizmente, o universo possui outros planos.
Sua casa será demolida para construir uma estrada.
Pouco depois...
a Terra será demolida para construir uma via expressa hiperespacial.
E essa simetria contém Douglas Adams inteiro.
O indivíduo é esmagado pela burocracia local.
A humanidade inteira é esmagada pela burocracia cósmica.
A escala muda.
A estupidez administrativa permanece perfeitamente compatível.
📋 CAPÍTULO 6
Vogons: o verdadeiro terror do universo
Esqueça monstros.
Esqueça Daleks.
Esqueça invasões alienígenas.
Adams compreendeu algo muito mais assustador.
O formulário.
Os Vogons representam uma das maiores contribuições da literatura para a compreensão da burocracia.
Eles não precisam odiar você.
Isso seria pessoal demais.
Eles possuem:
procedimentos.
regulamentos.
autorizações.
protocolos.
E provavelmente algum equivalente galáctico do:
TICKET STATUS: CLOSED
REASON:
WORKING AS DESIGNED
A Terra será destruída?
Lamentável.
Os planos estavam disponíveis.
Você não consultou?
Problema seu.
Qualquer pessoa que já tenha enfrentado uma mudança corporativa aprovada por quinze departamentos reconhecerá imediatamente a espécie.
📚 CAPÍTULO 7
A trilogia de cinco livros
Douglas Adams também conseguiu melhorar a matemática.
Sua famosa "trilogia" acabou composta por cinco romances escritos por ele:
1. The Hitchhiker's Guide to the Galaxy
1979
2. The Restaurant at the End of the Universe
1980
3. Life, the Universe and Everything
1982
4. So Long, and Thanks for All the Fish
1984
5. Mostly Harmless
1992
O site oficial registra a sequência e suas datas, incluindo o sucesso comercial extraordinário da série. (Douglas Adams)
Uma trilogia com cinco livros.
Porque quando você criou uma piada cósmica sobre a incapacidade humana de organizar a realidade, seria decepcionante começar obedecendo à aritmética.
Para descobrir a pergunta correspondente à resposta 42, é construído um computador ainda mais sofisticado.
Chamado:
Terra.
Sim.
Nós.
O planeta inteiro.
Um sistema computacional gigantesco.
Executando durante milhões de anos.
Até que...
pouco antes de terminar o processamento...
os Vogons destroem a máquina.
Se isso não parece um projeto de TI cancelado três semanas antes do go-live depois de oito anos de desenvolvimento, você ainda não trabalhou tempo suficiente em uma grande organização.
🐟 CAPÍTULO 11
Babel Fish
Outra criação genial:
Babel Fish.
Um pequeno peixe capaz de permitir comunicação entre idiomas.
Décadas depois, "Babel Fish" tornou-se referência cultural para sistemas de tradução automática; serviços tecnológicos chegaram a adotar diretamente o nome inspirado na criação de Adams. (Estante Virtual)
Hoje olhamos para tradução automática e IA generativa e pensamos:
Douglas provavelmente passaria quinze minutos fascinado.
Depois perguntaria:
— Muito interessante. Agora quantos bilhões gastamos construindo máquinas para podermos finalmente discutir com estrangeiros em tempo real?
interconectividade fundamental de todas as coisas.
O método investigativo dele poderia ser resumido assim:
tudo está conectado
↓
portanto qualquer pista pode importar
↓
inclusive aquela completamente absurda
↓
especialmente aquela completamente absurda
Qualquer analista investigando um incidente em produção às três da manhã entende perfeitamente.
O Db2 está lento.
Por quê?
Porque houve alteração no storage.
Por quê?
Porque um processo batch mudou.
Por quê?
Porque alguém alterou um parâmetro.
Por quê?
Porque houve migração seis meses atrás.
Por quê?
Porque...
Dirk sorri.
Interconectividade fundamental de todas as coisas.
🌳 CAPÍTULO 13
Last Chance to See
Existe ainda outro Douglas Adams.
Menos conhecido.
E talvez ainda mais interessante.
O ambientalista.
Com o zoólogo Mark Carwardine, Adams participou do projeto que resultaria em:
Last Chance to See
Uma viagem para encontrar espécies ameaçadas de extinção.
Não era simplesmente comédia.
Era conservação.
Era ciência.
Era encantamento diante da biodiversidade.
Adams tornou-se patrono fundador da Save the Rhino e chegou, em 1994, a participar de uma subida ao Kilimanjaro envolvendo uma fantasia de rinoceronte para ajudar a arrecadar dinheiro e conscientização. (Save the Rhino)
Pare por alguns segundos.
O homem que escreveu sobre um peixe tradutor universal...
subiu uma montanha...
vestido de rinoceronte...
para tentar salvar rinocerontes reais.
Douglas Adams não precisava inventar um personagem chamado Douglas Adams.
A produção já estava suficientemente absurda.
🍎 CAPÍTULO 14
Douglas Adams, o nerd
Aqui nossa história fica particularmente interessante.
Douglas Adams adorava tecnologia.
Computadores não eram apenas ferramentas de escrita para ele.
Eram brinquedos intelectuais.
O Macintosh o fascinou.
Ele foi um dos primeiros entusiastas britânicos da plataforma e manteve enorme interesse por computadores pessoais e tecnologias digitais. (Wikipedia)
Lembre-se da época.
Estamos falando dos anos 1980 e 1990.
Quando dizer:
"computadores vão mudar nossa maneira de comunicar, criar e pensar"
ainda não era frase obrigatória de keynote.
Adams percebeu cedo que computadores poderiam ser meios culturais.
Não apenas calculadoras.
🎮 CAPÍTULO 15
E naturalmente ele fez jogos
Em 1984 surgiu o jogo baseado em:
The Hitchhiker's Guide to the Galaxy.
Adams participou também de projetos como:
Bureaucracy;
Starship Titanic.
Seu catálogo oficial inclui esses experimentos tecnológicos ao lado dos livros e trabalhos audiovisuais. (Douglas Adams)
E Bureaucracy merece aplausos.
Porque transformar burocracia em videogame é reconhecer que o verdadeiro survival horror sempre foi preencher documentos corretamente.
🎸 CAPÍTULO 16
Pink Floyd aparece porque naturalmente aparece
Douglas Adams também era amigo de David Gilmour, do Pink Floyd.
O próprio material oficial de Adams, ao aconselhar aspirantes a escritores, enfatiza duas coisas bastante menos românticas:
escrever alguma coisa e possuir determinação para continuar. (Douglas Adams)
A inspiração é maravilhosa.
O problema é que eventualmente alguém precisa salvar o arquivo.
✍️ CAPÍTULO 18
O segredo técnico do humor de Adams
Se você escreve artigos, histórias ou documentação e quer aprender alguma coisa com Douglas Adams, não copie apenas as piadas.
Copie a arquitetura.
1. Comece com algo normal
Uma casa será demolida.
2. Aumente absurdamente a escala
Agora a Terra será demolida.
3. Mantenha a lógica administrativa
Existe documentação.
4. Faça o personagem reagir como uma pessoa comum
— Como assim?
5. Trate o absurdo como rotina
— Os documentos estavam disponíveis.
Essa é a mágica.
O narrador nunca precisa gritar que aquilo é engraçado.
O universo considera tudo perfeitamente razoável.
☕ CAPÍTULO 19
Douglas Adams aplicado ao mainframe
Imagine um diálogo.
— Por que esse programa existe?
— Porque processa o arquivo XPTO.
— Por que o arquivo XPTO existe?
— Porque alimenta o sistema ABC.
— Por que ABC precisa disso?
— Não sabemos.
— Quem escreveu?
— Aposentou em 1994.
— Existe documentação?
— Sim.
— Onde?
— Num dataset arquivado.
— Qual?
— Não sabemos.
— Então como sabemos que funciona?
— O job termina RC=0.
Arthur Dent provavelmente perguntaria:
— Isso é normal?
Ford Prefect responderia:
— Em sistemas enterprise, aparentemente sim.
🥚 CAPÍTULO 20
Easter eggs para carregar na toalha
Algumas pequenas delícias do universo Adams:
42 escapou dos livros e virou referência cultural gigantesca, aparecendo repetidamente em tecnologia, matemática recreativa e cultura hacker. (Douglas Adams)
Bellacosa Mainframe alerta sobre riscos no racf mal configurado
💀🔥 “Seu RACF está seguro… ou você só acha?”
🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)
“RACF não falha…
quem falha é quem confia demais nele.”
🧠 📜 Contexto histórico (o começo de tudo)
O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).
👉 Naquela época:
segurança era controle de acesso
hoje é sobrevivência digital
💡 Curiosidade:
RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.
💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO
🧨 1. *PUBLIC — o vilão silencioso
👉 Procure:
// quem tem acesso aberto? RLIST DATASET * AUTHUSER(*)
💥 Red flag:
datasets críticos com:
ID(*PUBLIC) ACCESS(READ ou UPDATE)
🔥 Insight Bellacosa:
80% das falhas começam aqui.
🧠 2. Usuários com SPECIAL / OPERATIONS
👉 Liste:
SEARCH CLASS(USER) MASK(*) SPECIAL
💥 Risco:
acesso total ao RACF
🎯 Dica senior:
separar:
ADMIN ≠ AUDITOR
⚙️ 3. Grupos com autoridade excessiva
👉 Verifique:
LISTGRP * OMVS
💥 Problema:
grupo herdando privilégio indevido
🔥 Easter egg:
Um grupo mal configurado é pior que um usuário root.
🧬 4. Programas APF e AC=1
👉 Verifique APF:
D PROG,APF
💥 Risco:
execução em modo supervisor
🎯 Ataque clássico:
inserir loadlib malicioso
🔐 5. Password Policy (o calcanhar de aquiles)
👉 Cheque:
SETROPTS LIST
💥 Problemas comuns:
senha simples
sem expiração
sem history
🔥 Curiosidade:
Já vi banco com senha “123456” em ambiente produtivo.
🌐 6. FACILITY class (o “backdoor oficial”)
👉 Verifique:
RLIST FACILITY *
💥 Risco:
permissões ocultas
🎯 Exemplo crítico:
BPX.* (Unix System Services)
🧑💻 7. USS (Unix no mainframe = Linux feelings)
👉 Verifique:
LISTUSER USER OMVS
💥 Risco:
UID 0 (root)
🔥 Insight:
USS é o ponto favorito de pivot de atacante moderno.
🧾 8. Logging / SMF (sem isso você está cego)
👉 Cheque:
SMF 80 (RACF)
SMF 30 (jobs)
💥 Problema:
logs incompletos
🎯 Dica:
integrar com SIEM
🧠 9. Started Tasks (STC) — privilégio invisível
👉 Verifique:
RLIST STARTED *
💥 Risco:
tarefas com privilégios elevados
🔥 Easter egg:
STC mal protegido = root invisível rodando 24x7
🔗 10. Integrações externas (o novo campo de batalha)
👉 Verifique:
CICS
z/OS Connect
💥 Risco:
acesso indireto ao core
🎯 Realidade:
O ataque não entra pelo mainframe… entra pela API.
💀🔥 CHECKLIST RÁPIDO (modo auditor)
✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras
🧠💣 Fluxo real de ataque (pra abrir a mente)
credencial fraca
acesso TSO/FTP
enumeração RACF
exploração (APF / FACILITY / USS)
persistência
exfiltração
🧬 Easter Eggs que só senior percebe
💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe
🏦 Realidade nível banco
👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo
🔥 Frase final estilo Bellacosa
“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”
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
