✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e os arquitetipos femininos nos animes
🎭 OS 7 ARQUÉTIPOS PSICOLÓGICOS DOS ANIMES — A PSIQUE JAPONESA EM FRAMES E PIXELS por Bellacosa Mainframe – edição El Jefe Midnight
Os animes não são apenas entretenimento. São espelhos da alma japonesa — e, por extensão, da nossa também.
Cada personagem que amamos, odiamos ou estranhamos é um dataset simbólico, um pedaço da psique humana processado em arte.
Por trás de cada “kawaii”, “baka” e olhar que brilha, há um código emocional que traduz a forma japonesa de lidar com o mundo: a tensão entre o que se sente e o que se pode mostrar.
Vamos decodificar juntos esses padrões — os 7 arquétipos psicológicos mais recorrentes dos animes, com direito a curiosidades, comportamento, filosofia e aquele toque Bellacosa Mainframe de reflexão e ironia sutil.
💥 1. O Herói Resiliente — O Job que Nunca Termina
Exemplo: Naruto, Luffy, Deku (My Hero Academia)
O herói shōnen é a alma persistente do Japão: ele apanha, erra, sofre — mas nunca cancela o job.
É o reflexo do valor cultural do ganbaru: o esforço contínuo, mesmo quando não há garantia de vitória.
Ele simboliza o trabalhador japonês que acredita que o mérito vem da perseverança, não do resultado.
“Falhar não é o problema. Parar de tentar é que gera abend.”
Curiosidade: as bandas sonoras desses animes são compostas para aumentar o batimento cardíaco — literalmente inspirando resiliência física e emocional.
🌸 2. A Tsundere — O Firewall Emocional
Exemplo: Asuka (Evangelion), Taiga (Toradora), Misaki (Kaichou wa Maid-sama)
A tsundere é o clássico caso de “sinto muito, mas nego tudo”.
Por fora, arrogância. Por dentro, vulnerabilidade.
É o espelho da repressão emocional japonesa — o medo de mostrar carinho e perder o controle social.
Na prática, a tsundere é o RACF do afeto: só abre permissão de READ/WRITE depois de inúmeros testes de segurança (e vergonha).
“Amor, no Japão, é sempre compilado em silêncio.”
Easter-egg: “tsun” vem de tsuntsun (desprezar) e “dere” de deredere (apaixonada) — dois modos de operação da alma japonesa.
🧘 3. O Sensei Misterioso — O SYSADM Espiritual
Exemplo: Jiraiya (Naruto), Urahara (Bleach), Zoro em modo mentor
É o personagem que carrega sabedoria, humor e dor em doses iguais.
Ele representa o senpai da vida — aquele que já falhou tanto que virou filosofia.
Costuma rir quando os outros choram, e ensinar sem ensinar.
Na mente japonesa, ele é o símbolo do equilíbrio entre honra e desapego, o monge e o programador que aceitam o bug da existência sem pânico.
“Quem domina o próprio erro, domina o sistema.”
Curiosidade: muitos “senseis” têm elementos de arquétipos zen, como o koan — o ensinamento que parece confuso, mas revela algo profundo no silêncio.
🔮 4. O Anti-Herói — O Batch Sombrio
Exemplo: Light Yagami (Death Note), Lelouch (Code Geass), Eren Yeager (Attack on Titan)
Esses personagens desafiam o sistema. São o abend intencional da narrativa.
Eles surgem do cansaço com o conformismo — da vontade de romper com as regras, mesmo que isso destrua o próprio ideal.
Simbolizam o lado oculto do Japão moderno: a rebeldia silenciosa contra a obediência cega.
“Quando o sistema é injusto, o erro vira protesto.”
Curiosidade: na década de 2000, o Japão passou por um aumento real de jovens isolados (hikikomori), e muitos roteiristas usaram o anti-herói como espelho dessa frustração coletiva.
🐾 5. O Mascote Kawaii — O Processo de Alívio de Carga
Exemplo: Totoro, Pikachu, Mokona, Chopper
Nenhum anime é completo sem o mascote que quebra a tensão.
Eles são os “garbage collectors” da emoção — purificam o clima, equilibram o drama.
Na psique japonesa, o “kawaii” (fofo) é uma resposta social à dureza do cotidiano.
“Entre um deadline e outro, o Japão inventou o Pikachu.”
Curiosidade: o termo kawaii culture virou objeto de estudo sociológico — uma forma de resistência suave, quase terapêutica, à pressão adulta e corporativa.
⚔️ 6. A Guerreira Silenciosa — A Subrotina da Força Interior
Exemplo: Mikasa (Attack on Titan), Saber (Fate), Motoko Kusanagi (Ghost in the Shell)
Ela não grita, não chora, não explica — apenas age.
Carrega o peso do mundo nos ombros, como quem carrega o passado e o dever.
É o arquétipo feminino da disciplina e da honra, um eco moderno do bushido, o código samurai.
“Enquanto o mundo fala, ela executa.”
Easter-egg: o cabelo curto da maioria dessas personagens é símbolo de corte de laços — um gesto tradicional japonês de recomeço ou desapego.
🧩 7. O Amigo Inseparável — O Backup Emocional
Exemplo: Krillin (Dragon Ball), Killua (Hunter x Hunter), Shikamaru (Naruto)
O suporte, o confidente, o alívio cômico — mas também o espelho do protagonista.
Ele representa a amizade como estrutura de identidade, algo profundamente japonês: o grupo sempre vem antes do indivíduo.
“No Japão, até o herói precisa de um cluster emocional.”
Curiosidade: a morte do “melhor amigo” é um tropo recorrente — uma forma simbólica de mostrar o amadurecimento emocional do protagonista.
☕ Epílogo Bellacosa
Os animes são o mainframe emocional do Japão: cada arquétipo é um programa rodando há séculos, traduzindo as dores, as pressões e os sonhos de um povo que aprendeu a sorrir por dentro.
E nós, espectadores ocidentais, sintonizamos nesse servidor global de sentimentos, reconhecendo nas entrelinhas algo que também é nosso:
a vontade de ser livre, de amar sem culpa e de encontrar sentido no caos.
“Animes não são sobre fantasia. São sobre a verdade — contada por quem aprendeu a sonhar em silêncio.” 🌸
Bellacosa Mainframe apresenta o USS Unix Posix no Zos
☕ Um Café no Bellacosa Mainframe
⛩️ YOUJI ITAMI E O GATE PARA O OUTRO MUNDO DO z/OS
UNIX System Services, MVS, datasets, JCL, ISPF, zFS, shell, POSIX, RACF, EBCDIC, UTF-8, Git, APIs, Python, Java, DevOps — e o dia em que um programador COBOL atravessou um portal e descobriu que havia UNIX dentro do mainframe.
🎬 PRÓLOGO — UM GATE APARECEU NO MEIO DO ISPF
Imagine nosso jovem programador COBOL.
Chamaremos o rapaz de Padawan-01.
Depois de algumas semanas estudando mainframe, ele já estava começando a se sentir confortável.
Até que, numa tarde aparentemente normal, apareceu um estranho portal no meio do reino.
No portal estava escrito:
UNIX SYSTEM SERVICES
O jovem olhou assustado.
— UNIX? Professor, acho que entrei no curso errado.
Sentado tranquilamente diante do terminal estava Youji Itami, protagonista de GATE, com aquela expressão típica de alguém que preferia estar cuidando de seus hobbies em vez de resolver mais uma crise internacional.
Itami olhou para o garoto.
— Não. Você continua no z/OS.
— Mas tem UNIX aqui!
— Tem.
— Shell?
— Tem.
— Diretórios?
— Tem.
— grep?
— Tem.
— Processos?
— Tem.
— POSIX?
— Também.
Padawan-01 ficou alguns segundos olhando para a tela.
Itami levantou-se.
— Bem-vindo ao outro lado do GATE.
E é exatamente aqui que começa uma das descobertas mais importantes para qualquer profissional de mainframe moderno:
z/OS não é apenas MVS + datasets + JCL + ISPF.
Existe outro mundo dentro da mesma plataforma.
Seu nome é UNIX System Services — USS.
🏛️ CAPÍTULO 1 — O REINO QUE O PROGRAMADOR COBOL NÃO CONHECIA
Existe um problema curioso na maneira como muita gente aprende mainframe.
O treinamento começa corretamente por conceitos fundamentais:
IBM Z;
z/OS;
TSO;
ISPF;
datasets;
JCL;
JES;
COBOL.
Nada está errado nisso.
O problema surge quando o estudante começa a acreditar que isso é todo o z/OS.
Não é.
É como atravessar o GATE, conhecer uma única cidade da Região Especial e concluir que conhece todo aquele mundo.
O z/OS possui diferentes ambientes e modelos de utilização.
Uma visão simplificada seria:
z/OS
│
┌────────────┴────────────┐
│ │
AMBIENTE TRADICIONAL USS
│ │
TSO shell
ISPF files
JCL directories
JES processes
datasets pipes
COBOL POSIX
│ │
└────────────┬────────────┘
│
IBM Z
Quando mostramos isso cedo ao iniciante, acontece algo importante.
Ele deixa de associar:
MAINFRAME = COBOL
e começa a compreender:
COBOL
│
▼
uma das tecnologias
│
▼
z/OS
│
▼
uma das plataformas
│
▼
IBM Z
Essa mudança mental parece pequena.
Profissionalmente, é gigantesca.
⛩️ CAPÍTULO 2 — O QUE É UNIX SYSTEM SERVICES?
UNIX System Services é um ambiente UNIX integrado ao z/OS.
Ele oferece recursos e interfaces baseados em padrões UNIX e POSIX.
Isso significa que alguém vindo de Linux ou UNIX pode encontrar conceitos extremamente familiares:
pwd
ls
cd
mkdir
cp
mv
rm
cat
grep
find
chmod
ps
kill
O primeiro modelo trabalha naturalmente com uma árvore de diretórios.
O segundo utiliza a organização e nomenclatura próprias de datasets do z/OS.
É importante conhecer ambos porque aplicações modernas no mainframe frequentemente atravessam esses mundos.
E existe aqui outro nome que o jovem programador deve aprender:
zFS
O z/OS File System, conhecido como zFS, é peça importante do filesystem utilizado pelo USS.
Podemos ter filesystems montados na hierarquia USS.
Conceitualmente:
zFS
│
▼
mount
│
▼
/u/projeto
│
├── bin
├── config
├── logs
└── scripts
Isso já é muito diferente da visão inicial:
MAINFRAME = PDS + JCL
O mapa ficou maior.
🐚 CAPÍTULO 5 — O DIA EM QUE O MAINFRAME RESPONDEU ls
Itami entrega o terminal ao Padawan.
— Sua missão é criar uma área de trabalho.
cd /u/padawan01
mkdir treinamento
cd treinamento
Agora:
pwd
Resultado:
/u/padawan01/treinamento
Criamos um arquivo:
echo "Hello Mainframe" > teste.txt
E verificamos:
cat teste.txt
Resultado:
Hello Mainframe
O jovem fica em silêncio.
Não apareceu ISPF.
Não apareceu JCL.
Não apareceu //SYSIN DD *.
E, mesmo assim, ele continua trabalhando no z/OS.
Esse laboratório de cinco minutos vale uma longa explicação teórica porque quebra imediatamente o estereótipo de que mainframe significa apenas terminal 3270.
🔗 CAPÍTULO 6 — ITAMI DESCOBRE O PODER DOS PIPES
No mundo UNIX existe uma filosofia extremamente elegante:
faça pequenas ferramentas realizarem tarefas específicas e combine seus resultados.
Imagine um arquivo:
application.log
Queremos encontrar erros.
grep ERROR application.log
Queremos procurar ABENDs:
grep ABEND application.log
Podemos combinar comandos:
cat application.log | grep ERROR
E criar cadeias:
cat application.log |
grep ERROR |
sort |
uniq
O símbolo:
|
é um pipe.
A saída de um comando pode alimentar outro.
Para alguém acostumado ao processamento batch, podemos fazer uma analogia.
No JCL:
INPUT
│
▼
STEP01
│
▼
TEMP
│
▼
STEP02
│
▼
OUTPUT
No shell:
INPUT → comando | comando | comando → OUTPUT
Não são exatamente a mesma arquitetura.
Mas comparar os modelos ensina algo muito mais importante do que decorar sintaxe:
fluxo de processamento.
🕵️ CAPÍTULO 7 — GREP, O DETETIVE DO GATE
Imagine um log com 200 mil linhas.
O programador abre o arquivo e começa:
FIND 'ERROR'
Itami observa.
Um minuto.
Dois minutos.
Cinco minutos.
Finalmente pergunta:
— O que você está fazendo?
— Investigando o incidente.
Itami aponta para o shell:
grep ERROR application.log
Agora queremos contar ocorrências:
grep ERROR application.log | wc -l
Queremos encontrar determinados arquivos:
find /u/projeto -name "*.log"
Queremos procurar determinado conteúdo dentro deles.
O profissional começa a construir uma nova caixa de ferramentas.
Essa habilidade torna-se especialmente valiosa em troubleshooting, automação, análise de logs e operações.
🔐 CAPÍTULO 8 — RACF ATRAVESSA O GATE
Padawan aprende:
chmod 777 deploy.sh
Itami imediatamente aparece atrás dele.
— O que você está fazendo?
— Resolvendo o problema de permissão.
Silêncio constrangedor.
Essa é outra aula importante.
No UNIX encontramos conceitos como:
owner
group
other
e permissões:
r = read
w = write
x = execute
Por exemplo:
-rwxr-x---
Podemos representar:
USER GROUP OTHER
READ X X
WRITE X
EXECUTE X X
No entanto, USS continua integrado ao modelo de segurança do z/OS.
Entram conceitos relacionados a:
SAF
RACF
UID
GID
owner
group
permissions
Portanto, ensinar USS também cria uma excelente oportunidade para ensinar segurança.
E uma regra deve ficar gravada:
chmod 777 não é estratégia de troubleshooting.
É muitas vezes a confissão:
"Não descobri qual permissão estava errada, então liberei tudo."
Em laboratório pode aparecer.
Em produção merece investigação.
👹 CAPÍTULO 9 — O MONSTRO EBCDIC ATRAVESSA O PORTAL
Itami acreditava que a missão estava tranquila.
Então chegou o verdadeiro monstro da Região Especial:
ENCODING
No mundo tradicional z/OS existe uma longa história relacionada a EBCDIC.
No mundo distribuído encontramos frequentemente:
ASCII
UTF-8
Agora imagine integração moderna:
COBOL
│
▼
dados EBCDIC
│
▼
API
│
▼
JSON / UTF-8
│
▼
aplicação distribuída
Pronto.
Temos terreno fértil para problemas.
Caracteres especiais, acentos e conversões podem produzir surpresas.
O programador manda:
JOÃO
e alguma camada mal configurada responde com algo que parece ter sido escrito por um mago bêbado da Região Especial.
Por isso, aprender USS também deveria envolver:
encoding;
code pages;
ASCII;
EBCDIC;
UTF-8;
conversão;
tagging de arquivos.
Não trate encoding como detalhe.
Em integração, detalhe vira incidente.
⚙️ CAPÍTULO 10 — PROCESSOS TAMBÉM EXISTEM DO OUTRO LADO
Outro conceito UNIX importante é processo.
Comandos como:
ps
permitem observar processos.
Podemos então introduzir conceitos relacionados a:
PID
process
parent process
signal
environment
E eventualmente:
kill
Aqui é preciso explicar ao iniciante que aprender comandos não significa sair executando-os indiscriminadamente.
Especialmente kill.
No mainframe, como em qualquer ambiente corporativo sério, antes de terminar alguma coisa devemos saber:
O que é?
Quem iniciou?
Quem depende disso?
Qual impacto?
Existe procedimento operacional?
O botão funciona.
O problema é descobrir o que acontece depois que você aperta.
🚪 CAPÍTULO 11 — BPXBATCH: UM PORTAL DENTRO DO PORTAL
Antes de atravessar, virou-se para o jovem programador.
— Você ainda gosta de COBOL?
— Muito.
— Ótimo. Continue estudando.
— Então por que me mostrou tudo isso?
Itami apontou para o enorme IBM Z atrás deles.
— Porque COBOL é uma linguagem. Isso aqui é uma plataforma.
E talvez essa seja uma das lições mais importantes que podemos ensinar para uma nova geração de profissionais.
COBOL continua sendo parte extraordinariamente importante da história e do presente do mainframe.
JCL continua importante.
ISPF continua importante.
Datasets continuam importantes.
CICS, Db2, VSAM, JES e RACF continuam importantes.
Mas ensinar somente isso cria uma janela estreita para uma plataforma gigantesca.
UNIX System Services abre outra janela.
Ali aparecem filesystem hierárquico, shell, POSIX, processos, pipes, permissões, zFS, integração com segurança do z/OS, encoding, automação e ferramentas modernas.
Depois surgem Git, APIs, Java, Python, CI/CD e novas formas de desenvolver e operar aplicações.
É nesse momento que o jovem deixa de perguntar:
"Como faço isso em COBOL?"
e começa a perguntar:
"Qual é a melhor maneira de resolver este problema no z/OS?"
Essa segunda pergunta forma profissionais muito mais completos.
Porque o futuro do mainframe não está em escolher entre o mundo antigo e o mundo novo.
Está em entender como os dois mundos atravessam o mesmo GATE.
E o profissional que consegue caminhar tranquilamente entre:
ISPF
↕
USS
↕
Git
↕
APIs
↕
CI/CD
↕
Cloud
sem esquecer de COBOL, JCL, CICS, Db2 e RACF não é apenas alguém mantendo sistemas antigos.
Ele está aprendendo a trabalhar com uma plataforma que passou décadas fazendo algo extremamente difícil:
evoluir sem obrigar o mundo inteiro a começar novamente do zero.
Itami provavelmente aprovaria.
Especialmente se a missão terminasse cedo o suficiente para ele voltar aos seus hobbies.
E o Bellacosa?
Provavelmente estaria no outro lado do GATE perguntando:
WHO CHANGED THIS FILE AT 03:17?
☕ Um Café no Bellacosa Mainframe
"Existem dois tipos de programadores z/OS: aqueles que já atravessaram o GATE para o USS... e aqueles que ainda estão procurando a opção dele no menu do ISPF."
Bellacosa Mainframe e o mistério do mainframe que jurava estar seguro
☕ Um Café no Bellacosa Mainframe
🐶 Mumbly e o Mistério do Mainframe que Jurava Estar Seguro
Firewalls, criptografia, autenticação, RACF, Zero Trust, ameaças, insiders, Red Team e aquele acesso das 03:17 que estava perfeitamente autorizado — mas não deveria estar acontecendo.
Há personagens que chegam a uma investigação arrombando portas, apontando armas e gritando ordens.
Mumbly não.
Ele aparece de sobretudo, dirige uma lata-velha, resmunga alguma coisa incompreensível e fica olhando para o suspeito com aquela expressão de quem já percebeu algo que ninguém mais percebeu.
E então vem aquela risadinha.
Heh-heh-heh-heh-heh...
Perfeito para investigar cybersecurity.
Porque segurança de computadores tem uma característica curiosa: quando ocorre um grande incidente, frequentemente descobrimos que várias partes do sistema estavam funcionando exatamente como foram configuradas para funcionar.
O firewall permitiu a conexão.
O certificado era válido.
A criptografia funcionou.
A senha estava correta.
O MFA foi aprovado.
O RACF autorizou.
O CICS executou.
O COBOL retornou RETURN-CODE = 0.
E alguém acabou de fazer algo que jamais deveria ter acontecido.
Mumbly ergueria uma sobrancelha.
Heh-heh-heh...
Temos um caso.
Antes de entrar na LPAR, vale apresentar nosso investigador. The Mumbly Cartoon Show foi produzido pela Hanna-Barbera e estreou nos Estados Unidos em 11 de setembro de 1976. Foram produzidos 16 episódios, com Mumbly dublado originalmente por Don Messick e Chief Schnooker por John Stephenson. O cão detetive de sobretudo trabalhava solucionando crimes enquanto seu chefe humano nem sempre demonstrava a mesma competência. (Wikipedia)
No Brasil, ficou conhecido como Rabugento, o Cão Detetive, com Pietro Mário na voz do protagonista e Guálter de França como Chefe Sinuca na dublagem registrada pela Herbert Richers. (DB - Dublagem Brasileira)
E existe uma conexão especialmente divertida: Mumbly é frequentemente descrito como uma paródia canina do detetive Columbo — sobretudo, comportamento aparentemente desajeitado, insistência e aquela capacidade de incomodar o suspeito até a verdade aparecer.
Exatamente o método que usaremos.
🕵️ CAPÍTULO 1 — O sistema estava seguro
Nosso caso começa numa grande empresa fictícia.
Chamaremos de:
BELLACOSA BANK
O diretor pergunta ao responsável pela infraestrutura:
INTERNET
|
v
FIREWALL
|
v
WAF
|
v
API GATEWAY
|
v
APPLICATION
O Web Application Firewall consegue observar aspectos específicos do tráfego HTTP/HTTPS e aplicar políticas relacionadas à aplicação.
Isso melhora enormemente nossa defesa.
Mas novamente:
WAF ALLOWED
não significa:
BUSINESS TRANSACTION IS LEGITIMATE
Essa diferença será fundamental quando chegarmos ao COBOL.
🔐 CAPÍTULO 5 — O segundo suspeito: criptografia
Mumbly encontra uma placa:
AES-256
O administrador sorri.
— Nossos dados são criptografados!
Mumbly responde:
Hmmmm...
Excelente.
Mas onde estão as chaves?
Silêncio.
Essa pergunta muda completamente a investigação.
Criptografia simétrica, como AES, utiliza segredo compartilhado para proteger dados.
Criptografia de chave pública trabalha com uma estrutura envolvendo chave pública e privada.
Na prática, sistemas modernos frequentemente combinam mecanismos.
Conceitualmente:
CRIPTOGRAFIA ASSIMÉTRICA
|
v
ESTABELECIMENTO DE CONFIANÇA/
SEGREDO DE SESSÃO
|
v
CRIPTOGRAFIA SIMÉTRICA
|
v
GRANDE VOLUME DE DADOS
Por quê?
Entre outros motivos, desempenho e características distintas dos algoritmos.
Mas nosso detetive não está interessado apenas no algoritmo.
Está procurando confiança.
🗝️ CAPÍTULO 6 — Quem guarda a chave da chave?
Imagine que CUSTOMER.DATA esteja perfeitamente criptografado.
Fantástico.
Agora alguém encontra no programa:
01 WS-CRYPTO-KEY PIC X(32)
VALUE 'MINHA-SUPER-CHAVE-SECRETA'.
Mumbly começa a rir.
Heh-heh-heh-heh-heh...
A matemática continua funcionando.
A arquitetura de segurança, não.
O problema real passa a incluir:
Quem cria a chave?
Quem possui acesso?
Onde ela fica?
Pode ser exportada?
Como ocorre a rotação?
Quem consegue substituí-la?
Existe auditoria?
Existe separação de funções?
Existe hardware dedicado para protegê-la?
É aí que o mundo IBM Z fica fascinante.
Entram elementos como ICSF, hardware criptográfico, certificados, key rings e políticas de acesso.
Segurança criptográfica empresarial não é:
AES = ON
É um ecossistema.
🚚 CAPÍTULO 7 — Data at rest, data in transit e data in use
Mumbly encontra três salas.
Na primeira:
DATA AT REST
São datasets, bancos, arquivos, volumes e backups.
Na segunda:
DATA IN TRANSIT
São dados atravessando redes.
Na terceira:
DATA IN USE
Agora a coisa fica interessante.
Porque podemos possuir:
DISK
↓
ENCRYPTED DATA
↓
APPLICATION
↓
DECRYPT
↓
PROCESSING
Em algum momento uma aplicação autorizada precisa utilizar os dados.
Consequentemente:
criptografia não substitui controle de acesso.
E controle de acesso não substitui criptografia.
Essa é a essência de defense in depth.
🪪 CAPÍTULO 8 — Mumbly pergunta: “Quem é você?”
Chegamos à autenticação.
Temos senha.
PIN.
OTP.
Biometria.
Certificados.
Tokens.
Security keys.
Passwordless.
MFA.
Mas antes de decorar tecnologias precisamos aprender uma separação fundamental:
IDENTIFICATION
↓
Quem você afirma ser?
AUTHENTICATION
↓
Você consegue provar?
AUTHORIZATION
↓
O que você pode fazer?
Um usuário pode autenticar corretamente e continuar sem autoridade para determinado recurso.
Essa distinção é essencial no mainframe.
🏦 CAPÍTULO 9 — RACF entra na delegacia
Imagine:
USERID ABC123
PASSWORD ********
Autenticação concluída.
Mas ABC123 tenta acessar:
BANK.PROD.CUSTOMER.MASTER
Agora precisamos perguntar:
ABC123 possui READ?
Talvez sim.
Depois:
Possui UPDATE?
Talvez não.
E:
ALTER?
Definitivamente esperamos que isso tenha sido pensado cuidadosamente.
Esse é o princípio de least privilege:
conceder somente os privilégios necessários para executar determinada função.
Um desenvolvedor COBOL iniciante precisa compreender isso muito cedo.
Seu programa não vive sozinho.
Ele executa dentro de uma arquitetura de identidade e autorização.
🧑💻 CAPÍTULO 10 — Então Mumbly encontra o COBOL
Aqui nossa investigação muda.
O sistema é:
Mobile App
|
TLS
|
WAF
|
API Gateway
|
z/OS Connect
|
CICS
|
RACF
|
PGMPAY01
|
Db2
Uma requisição chegou.
Firewall:
OK
WAF:
OK
TLS:
OK
Identidade:
OK
RACF:
OK
CICS:
OK
E agora o programa recebe:
TRANSFER-AMOUNT = 9.800.000
Quem decide se aquela transferência faz sentido?
Talvez seja justamente o sistema de negócio.
💰 CAPÍTULO 11 — Uma linha COBOL também pode ser cybersecurity
Considere:
IF TRANSFER-AMOUNT > DAILY-LIMIT
MOVE 'Y' TO ADDITIONAL-REVIEW
END-IF.
Isso parece uma regra bancária.
E é.
Mas também constitui controle de risco.
Podemos adicionar:
IF DESTINATION-COUNTRY NOT = CUSTOMER-USUAL-COUNTRY
AND TRANSFER-AMOUNT > HIGH-RISK-LIMIT
PERFORM REQUEST-ADDITIONAL-VALIDATION
END-IF.
Então descobrimos três níveis diferentes:
NETWORK AUTHORIZATION
|
| Posso estabelecer comunicação?
v
SYSTEM AUTHORIZATION
|
| Posso acessar o recurso?
v
BUSINESS AUTHORIZATION
|
| Posso executar ESTA operação?
v
TRANSACTION
E é nesse terceiro nível que milhões de linhas COBOL sustentam controles críticos de negócio.
💣 CAPÍTULO 12 — Mumbly encontra um usuário perfeitamente legítimo
Assim conseguimos construir modelos de ameaça muito melhores.
Um adolescente usando ferramentas prontas e uma equipe altamente financiada podem explorar a mesma vulnerabilidade.
Mas representam riscos completamente diferentes.
🛡️ CAPÍTULO 22 — Prevent não basta
Mumbly olha novamente nossa arquitetura.
Encontramos:
Firewall
MFA
RACF
TLS
Encryption
WAF
Tudo isso é importantíssimo.
Mas segurança precisa pensar em todo o ciclo:
GOVERN
|
IDENTIFY
|
PROTECT
|
DETECT
|
RESPOND
|
RECOVER
|
+------+
|
v
aprender
Essa visão é muito próxima da estrutura do NIST Cybersecurity Framework 2.0, que organiza os resultados de cybersecurity nas funções Govern, Identify, Protect, Detect, Respond e Recover. (Wikipedia)
O ponto pedagógico permanece: prevenção é somente parte do trabalho.
🚨 CAPÍTULO 23 — Assume Breach
Existe uma pergunta desconfortável que Mumbly faria:
E se o atacante já estiver dentro?
Essa pergunta muda completamente o projeto.
Em vez de:
COMO IMPEDIMOS A ENTRADA?
também perguntamos:
COMO LIMITAMOS O MOVIMENTO?
COMO DETECTAMOS?
COMO CONTEMOS?
COMO PRESERVAMOS EVIDÊNCIAS?
COMO RECUPERAMOS?
COMO SABEMOS O QUE FOI AFETADO?
A arquitetura precisa sobreviver à falha de um controle.
Essa é uma maneira poderosa de compreender defense in depth.
🔬 CAPÍTULO 24 — O programador COBOL também faz parte da defesa
Essa talvez seja a descoberta mais importante deste artigo.
O programador iniciante frequentemente imagina:
SEGURANÇA
=
EQUIPE DE SEGURANÇA
Não.
Quem escreve:
IF USER-ROLE = 'ADMIN'
está implementando uma decisão de segurança.
Quem escreve:
DISPLAY CUSTOMER-CARD-NUMBER
pode estar criando exposição de dados.
Quem decide registrar:
PASSWORD=XXXXXXXX
em log está tomando uma decisão de segurança.
Quem cria:
IF AMOUNT > LIMIT
PERFORM VALIDATE
END-IF
pode estar implementando controle antifraude.
Quem ignora:
RETURN-CODE
pode transformar uma falha de segurança em comportamento inesperado.
BUSINESS
|
v
COBOL
|
+----------+----------+
| | |
CICS Db2 MQ
\ | /
+---------+---------+
|
z/OS
|
IBM Z
Agora finalmente enxergamos o sistema inteiro.
🐶 CAPÍTULO 26 — Mumbly resolve o caso
Chefe Sinuca entra correndo.
— Mumbly! Descobri! O firewall estava funcionando!
Mumbly:
Hmmmm.
— O MFA também!
Hmmmm.
— O certificado era válido!
Hmmmm.
— RACF autorizou!
Hmmmm.
— O programa COBOL terminou com CC 0000!
Mumbly sorri.
Heh-heh-heh-heh-heh...
Porque essa era justamente a pista.
Nada havia “quebrado”.
O usuário possuía uma identidade legítima.
A comunicação era permitida.
O canal estava criptografado.
O recurso estava autorizado.
A transação tecnicamente funcionou.
Mas às 03:17, aquela identidade começou a executar uma sequência de operações incompatível com seu comportamento normal, em volume incomum, sobre recursos sensíveis.
O sistema tradicional perguntava:
WHO ARE YOU?
Depois evoluiu para:
WHO ARE YOU?
ARE YOU AUTHORIZED?
A segurança moderna precisa continuar:
WHO ARE YOU?
WHAT DEVICE?
FROM WHERE?
WHAT RESOURCE?
WHAT OPERATION?
WHEN?
HOW MUCH?
HOW OFTEN?
IS THIS NORMAL?
WHAT CHANGED?
WHAT IS THE CURRENT RISK?
SHOULD WE CONTINUE TRUSTING THIS SESSION?
Mumbly não encontrou uma porta arrombada.
Encontrou algo muito mais interessante:
uma cadeia de confiança que continuou confiando quando já deveria ter começado a desconfiar.
☕ EPÍLOGO — O firewall não era o culpado
É tentador terminar uma aula de cybersecurity dizendo:
“Precisamos de firewalls melhores.”
Mas Mumbly provavelmente resmungaria.
O firewall fez seu trabalho.
O RACF fez seu trabalho.
A criptografia fez seu trabalho.
O CICS fez seu trabalho.
O COBOL fez exatamente aquilo que alguém havia programado.
Esse é precisamente o problema.
Segurança madura não pode ser reduzida à existência de ferramentas.
Precisamos perguntar continuamente:
QUEM
↓
FAZ O QUÊ
↓
SOBRE QUAL RECURSO
↓
EM QUAL CONTEXTO
↓
COM QUAL PRIVILÉGIO
↓
PRODUZINDO QUAL COMPORTAMENTO
↓
GERANDO QUAL RISCO
Por isso aqueles cinco infográficos aparentemente simples — Firewall, Criptografia, Autenticação, Ameaças e Hackers — acabam nos levando a uma discussão muito maior sobre IAM, RACF, least privilege, defesa em profundidade, Zero Trust, SIEM, UEBA, Risk Scoring, supply chain, insider threat, Red Team, observabilidade, resposta a incidentes e segurança de aplicações COBOL.
E talvez exista uma lição ainda mais bonita para quem está começando no mainframe.
Não olhe para um programa COBOL simplesmente como:
INPUT
↓
PROCESS
↓
OUTPUT
Olhe assim:
IDENTITY
↓
AUTHORIZATION
↓
INPUT
↓
BUSINESS RULES
↓
RISK CONTROLS
↓
TRANSACTION
↓
DATA
↓
AUDIT TRAIL
Porque aquele velho programa de quarenta anos pode não ser apenas um sistema que calcula juros, liquida pagamentos ou atualiza uma conta.
Ele pode ser uma das últimas linhas de defesa do negócio.
E quando alguém disser:
“Mas o usuário estava autenticado...”
talvez seja hora de vestir o sobretudo, olhar novamente os SMF records, correlacionar CICS, Db2, RACF, MQ e logs da aplicação e perguntar:
“Autenticado, sim. Mas deveria estar fazendo isso?”
🌭 O Dogão da Baixa Augusta – O Cão Noturno que Alimentou uma Geração Perdida por El Jefe – Bellacosa Mainframe Midnight Lunch Edition
Há coisas que só quem viveu entende.
E o Dogão da Baixa Augusta, meus caros padawans da madrugada, é uma dessas instituições invisíveis que sustentaram corpos cansados, corações partidos e sistemas operacionais humanos à beira do crash.
🌃 Origem – a Aurora do Dogão Subterrâneo
Voltemos aos anos 1990 e 2000, quando a Rua Augusta ainda era um portal de transição entre o glamour decadente da Paulista e o caos libertário do centro velho.
A noite fervia: punks, clubbers, drag queens, jornalistas alternativos, estudantes e os sobreviventes da Vila Buarque misturavam-se sob néons cansados e muros pichados.
Entre um after e um amor fugaz, lá estava ele — o Dogão, reluzente no vapor do carrinho, um farol de carboidrato na neblina da boemia paulistana.
🌭 A Arquitetura do Dogão Paulista
O dogão não era um simples cachorro-quente. Era uma entidade gastronômica.
Pão macio, salsicha dupla, vinagrete, milho, ervilha, purê de batata, batata palha, maionese e ketchup em cascata.
Cada ingrediente era uma camada da noite paulistana — um stack de sabores, tão caótico quanto o sistema da CPTM às 6 da manhã.
E o purê? Ah, o purê! Era o middleware que unificava tudo. Sem ele, o dogão seria apenas um log de dados corrompido.
🎭 As Lendas da Augusta
Dizem que o primeiro dogueiro lendário foi um ex-técnico de som que montava o carrinho depois de desmontar caixas de um show no Inferno Club.
Outros juram que o Dogão nasceu no front das portas do Clube Outs, quando um grupo de roqueiros famintos improvisou um lanche com tudo que tinha — e descobriu, acidentalmente, o equilíbrio perfeito entre desespero e delícia.
Há quem diga que o dogão salvou mais de mil romances e impediu outras tantas brigas. Era o “checkpoint” da noite — antes de voltar pra casa, antes de enfrentar o silêncio do amanhecer.
🌀 Adaptações e mutações
Com o tempo, o Dogão evoluiu — virou Dog Vegano, Dog Premium, Dog da Augusta Experience (sim, isso existe).
Mas o verdadeiro conhecedor sabe: dog bom é o da calçada, servido num guardanapo que não aguenta o molho.
Nada de pão artesanal ou maionese trufada — o dogão legítimo carrega o DNA da gambiarra, da sobrevivência urbana e do improviso genial.
💬 Fofoquices do Cinturão Noturno
Reza a lenda que DJs faziam fila ao lado de drag queens e grafiteiros, todos de olho no mesmo dogão.
Teve até banda indie que, no auge da fama, largou a coletiva de imprensa pra ir comer um “dogão raiz” antes de subir no palco da Augusta 473.
E dizem que um crítico gastronômico francês, de passagem pela cidade, descreveu o Dogão como “um atentado delicioso à ordem culinária”.
Ele não estava errado.
💡 Dicas do Bellacosa
Se for fazer o pilgrimage noturno:
Vá entre 1h e 4h da manhã, quando a Augusta mostra sua verdadeira face.
Peça o dogão completo, sem frescura.
E se o dogueiro te perguntar “purê, patrão?”, nunca diga não.
É como recusar JES2 num job de produção — simplesmente não se faz.
🖤 Reflexão do El Jefe Midnight Lunch
O Dogão é mais do que comida. É símbolo de resistência cultural, um mainframe ambulante de memórias urbanas.
Ele alimentou a contracultura paulistana, a juventude sem grana, o rock alternativo, os amores líquidos e as madrugadas eternas.
Hoje, a Baixa Augusta mudou, ganhou coworkings e bares gourmet. Mas ainda há carrinhos discretos guardando a chama original — o Dogão da Rua, que não precisa de login, QR Code ou status social pra te aceitar.
🌭 Bellacosa Mainframe – preservando os sabores do submundo paulistano desde o tempo do Diskman.
Rotunda ferroviária da Mogiana : Complexo FEPASA em Campinas
Tema de outros vídeos em nosso canal, a Estação Central de Campinas, outrora abrigou um complexo centro ferroviário, coração da Cia Paulista e da Cia Mogiana.
Em suas instalações milhares de trabalhadores circulavam e trabalhavam nas mais diversas atividades, 24 horas por dia, 7 dias por semana.
Neste complexo havia duas rotundas, uma usina termoelétrica, central de telégrafo, marcenaria, carpintaria, mecânica leve, mecânica pesada, fundição, cozinha, cantina, oficina de costura, fabricação de vagões e carruagens e muito mais.
Após inúmeras tentativas, enfim consegui adentrar na EMDEC e com autorização visitei as ruínas da antiga rotunda, é impressionante o tamanho, contei 22 eslotes para locomotiva, me emocionei pensando em quantas locomotivas a vapor, diesel, elétrica estiveram armazenadas aqui.
Quanta riqueza e progresso trouxe estas instalações que ligava o interior ao litoral, trazendo e levando pessoas e bens, espero que um dia se concretize e se transforme num belo museu para as futuras gerações conhecerem um pouco mais da história.
Se gostou deixe seu like, e caso não seja inscrito no canal se inscreva. Muito obrigado pela visita.
Porque conhecimento acumulado possui enorme valor.
O Universo Está Ficando Mais Complexo
Há cinquenta anos...
um programa conversava com outro.
Hoje...
uma única transação pode atravessar:
API Gateway.
Load Balancer.
Cloud.
MQ.
Kafka.
OpenShift.
z/OS Connect.
CICS.
COBOL.
Db2.
E retornar em poucos milissegundos.
A tecnologia ficou mais complexa.
Mas também mais fascinante.
O Que Diria Wilhelm G. Spruth?
Se Wilhelm G. Spruth pudesse caminhar hoje pelos corredores de um moderno Data Center IBM Z...
provavelmente sorriria.
Em 2010 ele descreveu características únicas da plataforma:
alta disponibilidade.
virtualização.
segurança.
WLM.
Parallel Sysplex.
integração.
Esses pilares permanecem.
O que mudou foi o universo construído sobre eles.
APIs.
IA.
Containers.
Open Source.
DevOps.
Cloud.
Nada disso destruiu os fundamentos.
Apenas ampliou suas possibilidades.
A Pergunta Que Acompanhou Todo Este Livro
Chegamos finalmente à pergunta iniciada no Capítulo 1.
O Mainframe sobreviveu ao futuro?
Ou...
foi o futuro que acabou ficando parecido com o Mainframe?
Pense por um instante.
Hoje todos falam sobre:
alta disponibilidade.
virtualização.
containers.
automação.
segurança.
orquestração.
resiliência.
observabilidade.
criptografia.
governança.
escalabilidade.
Curiosamente...
essas ideias fazem parte da cultura IBM Z há décadas.
Talvez o Mainframe nunca tenha corrido atrás do futuro.
Talvez...
o futuro tenha demorado para alcançá-lo.
A Última Descoberta do Padawan
Durante esta viagem você talvez tenha percebido algo curioso.
Este livro nunca foi apenas sobre computadores.
Foi sobre pessoas.
Engenheiros.
Operadores.
Arquitetos.
Analistas.
Programadores COBOL.
Cada geração recebeu uma nave.
Nenhuma a construiu sozinha.
Cada uma acrescentou:
uma peça.
uma melhoria.
uma ideia.
Depois entregou a próxima geração.
Esse talvez seja o maior legado da engenharia.
Construir algo que sobreviva ao próprio construtor.
A Biblioteca Nunca Fecha
Lembra do primeiro capítulo?
Dissemos que não entrássemos em pânico.
Agora podemos acrescentar outra recomendação.
Nunca pare de aprender.
Porque existe uma regra curiosa no universo.
Quanto mais você aprende...
maior ele parece ficar.
A Última Página... Ou Apenas o Primeiro Capítulo?
Imagine fechar este livro.
Você acredita que terminou.
Mas então percebe algo.
Sua mesa possui:
um terminal 3270.
um notebook.
VS Code.
Git.
Python.
COBOL.
Ansible.
OpenShift.
IA.
Todos esperando.
O verdadeiro livro começa agora.
Porque conhecimento que não é praticado...
permanece apenas como tinta sobre papel.
A Mensagem Escondida em Toda a Jornada
Talvez você esperasse encontrar um livro sobre Mainframe.
Mas, no fundo...
ele sempre foi um livro sobre curiosidade.
Sobre nunca aceitar respostas fáceis.
Sobre desmontar mitos.
Sobre olhar para tecnologias antigas sem preconceito.
E olhar para tecnologias novas sem deslumbramento.
As maiores descobertas da humanidade quase sempre nasceram quando alguém fez uma pergunta simples.
"E se estivermos olhando para isso do jeito errado?"
Curiosidades do Diário de Bordo
🚀 O IBM Z continua evoluindo geração após geração, incorporando Inteligência Artificial, aceleração criptográfica, computação híbrida e integração com ecossistemas abertos.
🌍 Grande parte das transações financeiras mundiais continua dependendo diariamente das características de disponibilidade, segurança e escalabilidade desenvolvidas ao longo de décadas na plataforma.
🤖 Ferramentas de IA já auxiliam programadores COBOL na documentação, modernização, testes e análise de código, tornando o desenvolvimento mais produtivo.
🌌 A história do Mainframe demonstra que tecnologias verdadeiramente importantes raramente desaparecem; elas evoluem, adaptam-se e encontram novos papéis.
Diário Final de Bordo do Padawan COBOL
Se chegou até aqui...
você já não é exatamente um Padawan.
Ainda existe muito a aprender.
Sempre existirá.
Mas agora você conhece algo que muitos profissionais jamais descobriram.
Você percebeu que o IBM Z não é apenas um computador.
É uma filosofia de engenharia.
Uma coleção de ideias.
Uma tradição de confiabilidade.
Uma escola de arquitetura.
Uma prova de que boas decisões técnicas podem atravessar gerações.
A Última Regra do Guia do Mochileiro Mainframe
Antes de partir para sua próxima missão, grave uma última coordenada no seu Holocron Técnico:
Leve sempre uma toalha... e um bom manual de JCL.
A toalha ajuda quando a viagem fica turbulenta.
O JCL ajuda quando o ABEND chega sem avisar.
E, se ambos falharem...
faça o que todo grande explorador faz.
Sirva uma boa xícara de café.
Abra o SDSF.
Leia os logs com calma.
Converse com seus colegas de tripulação.
E continue explorando.
Porque, no universo do IBM Z, a maior aventura nunca foi executar um programa.
Sempre foi compreender a extraordinária engenharia construída por milhares de pessoas ao longo de mais de seis décadas.
Epílogo — Fim da Missão... Início da Próxima
A nave segue seu curso.
As estrelas continuam lá.
Novas tecnologias surgirão.
Outras desaparecerão.
Mas enquanto houver sistemas que precisem ser seguros, confiáveis, escaláveis e disponíveis, sempre haverá espaço para os princípios que você encontrou nesta jornada.
E talvez, algum dia, um novo Padawan pergunte:
"O Mainframe ainda existe?"
Você poderá sorrir, apontar para a imensidão da galáxia tecnológica e responder:
"Ele nunca deixou de existir. Você apenas não tinha percebido que ele sempre esteve pilotando a nave."
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
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
