✨ 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
📜 Crônica Bellacosa Mainframe – "O Elevador da Quarta Parada"
(um dump de memória em EBCDIC afetivo, com cheiro de papel de gibi, soma do passado +1 futuro — compile and run in coração.exe)
A Mooca dos anos 1970 tinha aquele céu meio alaranjado de fábrica, trilho de trem riscando o bairro como linha de JCL, e um menino — euzinho mesmo — pronto para executar SUB-ROUTINES de travessura com high performance. Era a Quarta Parada, quase um checkpoint do destino, onde minha Tia Miriam (irmã caçula do meu pai, sorriso fácil e paciência infinita) e Tio Osmar seu marido, abriram o apartamento que seria para mim uma espécie de portal mágico de nível +99.
Não lembro se eram férias ou feriado prolongado, mas passei alguns dias nesse apartamento, onde esse pequeno oni, aprontou e deixou suas pegadas na memória dos moradores deste prédio...
Porque o brilho desse lugar não estava nas paredes, nem nos móveis, nem no cheiro do café que vinha da cozinha. Estava em algo monumental, mitológico, quase cyberpunk para a época:
🛗 O elevador.
A máquina do futuro.
A Enterprise vertical do menino Bellacosa.
Aquele cubo metálico, cheio de botões com números que pareciam comandos de painel do CICS:
CALL ELEVADOR USING PISO 3.PERFORM SUBIR UNTIL OLHAR LA EMBAIXO = MAR DE CARRINHOS.
Ridiculamente sofisticado para quem cresceu no subúrbio de casas térreas, onde o "andar de cima" era só o telhado. Onde havia uma ou outra casa de sobrados e os edifícios mais próximos somente na região da Penha. Naquele prédio da Avenida Radial Leste (Alcântara Machado), descobri que existia altura — um novo eixo cartesiano, vertical, na vida de um garoto. E lá embaixo os carros eram Hot Wheels em escala real, e tudo pulsava como uma cidade de brinquedo.
🛎 Travessuras com nível de XP máximo
Eu era código inquieto, processo batch em loop infinito. Maquinando qual seria a próxima arte.
📍 Apertar campainhas e fugir pelas escadas → adrenalina nível DFHSM0100I
📍 Apertar todos os botões do elevador antes de sair → feature não documentada
📍 Descer correndo e subir inocente, como se nada tivesse acontecido → rollback com commit sujo
Hoje olho e solto uma risadinha sinistra. Na época este que voz escreve era caos doce — o tipo de erro que os adultos reclamam, mas lembram com carinho 40 anos depois. Uns querendo esganar, outros passando a mão na cabeça. Por que travessura é bug no sistema da infância — e sem ela, não há deploy de memória.
E a Santa Tia Miriam, com sua paciência Mainframe-class, reiniciava eu em modo seguro, com afeto e pão com manteiga a famosa manteiga aviação e o delicioso suco de tangerina em lata, que misturado com água gelada era o refresco da tarde.
📚 E aí veio o segundo portal: a Gibiteca
Se o elevador era a nave espacial, a sala da Tia Miriam era o hiper-espelho do multiverso. HQs por toda parte. Turma da Mônica. Tio Patinhas. Mickey. Snoopy. Luluzinha.
Era como acessar uma biblioteca de universos paralelos sem login, sem batch, sem spool cheio. Só sentar, abrir e voar.
Os quadrinhos me deram:
✦ tempo suspensão
✦ teleporte narrativo
✦ imaginário com overclock
Enquanto do lado de fora a Mooca respirava trem, sirene e lanchonete, dentro do apartamento existiam mundos, selvas, castelos, luas, cachorros filósofos e patos bilionários.
Foi ali, naquele kernel afetivo, que meu cérebro aprendeu que papel + tinta = viagem sem ticket.
E em nota de rodapé a fabulosamente incrível TV a cores, isso era o futuro, um vislumbre do século XXI, o moderno a um passo de distância.
📦 Conclusão (com um sorriso no dial)
Aquele garoto arteiro, descendo escada como byte fugitivo e subindo elevador como programa limpo, descobriu na Quarta Parada duas tecnologias revolucionárias:
A verticalidade do mundo, vista do alto feito um deus mirim
A expansão infinita da imaginação, nas páginas dos gibis
E nada mais é tão grande quanto aquilo que é enorme para uma criança.
Às vezes o mainframe que nos forma não está no CPLEX, mas no elevador de um prédio comum na Mooca, em 1978, onde um menino compilou alegria, teto alto e travessuras.
PS: Ja havia andado em outros elevadores antes, mas sempre supervisionado por um adulto, sem liberdade de soltar o diabinho interior, fosse no Hospital da Penha, fosse no mítico elevador do Mappin na Praça Ramos... sem contar as fabulosas escadas rolantes, mas isso, ja sabem é outro poste...
Bellacosa Mainframe conhece os reis demonios dos animes
🔥「Os 10 Maous Mais Icônicos dos Animes」
O termo Maou (魔王) significa literalmente "Rei Demônio" ou "Rei das Forças Demoníacas". No imaginário japonês, porém, seu significado é mais complexo do que a ideia ocidental de um simples demônio maligno. A palavra é composta pelos ideogramas 魔 (ma), que representa demônio, magia ou influência sobrenatural, e 王 (ou), que significa rei. Sua origem foi fortemente influenciada pelo budismo, pela mitologia chinesa e pelo folclore japonês, especialmente pela figura de Mara, o tentador que procura desviar os seres do caminho da iluminação.
Ao longo dos séculos, o conceito de Maou misturou-se às lendas dos oni, dos yokai e de outros seres sobrenaturais, tornando-se um poderoso senhor que governa exércitos de criaturas fantásticas. Diferentemente da tradição cristã, nem todo Maou é necessariamente a personificação do mal absoluto; alguns são retratados como governantes, conquistadores ou entidades que seguem sua própria moral.
Essa interpretação encontrou terreno fértil nos videogames japoneses dos anos 1980, especialmente em RPGs como Dragon Quest e Final Fantasy, onde o objetivo do herói era derrotar o Rei Demônio. A partir daí, o conceito migrou naturalmente para mangás, light novels e animes.
Nos animes modernos, especialmente nos isekais, o Maou deixou de ser apenas o antagonista final. Personagens como Ainz Ooal Gown (Overlord), Rimuru Tempest (Tensei Shitara Slime Datta Ken), Anos Voldigoad (The Misfit of Demon King Academy) e Sadao Maou (Hataraku Maou-sama!) mostram que um Rei Demônio pode ser um estrategista, um administrador, um herói ou até um trabalhador de meio período. Essa evolução transformou o Maou em uma das figuras mais versáteis e fascinantes da cultura pop japonesa, refletindo uma visão mais ambígua sobre poder, liderança e moralidade.
Ranking
(Um ranking infernal by El Jefe Midnight Lunch — escrito à luz azul do monitor, café frio e alma quente)
Todo mundo quer ser herói… mas os verdadeiros fãs sabem: os melhores personagens são os Maous — os reis do inferno, os governantes do caos, os anti-heróis que fazem a moralidade parecer bugada.
Do folclore ao streaming, do pergaminho ao pixel, o Maou japonês ganhou versões que vão do temível ao carismático.
Então, acende o incenso digital e vamos invocar os 10 mais lendários Reis Demônios dos animes, com pitadas de história, curiosidade, e aquele toque Bellacosa de filosofia noturna.
🩸 1. Anos Voldigoad (The Misfit of Demon King Academy)
O Maou que reencarnou só pra provar que o sistema escolar tá errado.
Anos é o Rei Demônio da Autoconfiança, o cara que derrota o inimigo com um piscar de olhos — literalmente.
Dizem que se Freud fosse vivo, escreveria “O Ego e o Maou” inspirado nele.
💡 Curiosidade: o nome “Voldigoad” soa como um glitch entre Voldemort e um código COBOL travado.
💀 2. Ainz Ooal Gown (Overlord)
O gamer que virou Deus.
Um programador japonês cai num servidor morto e renasce como o Rei dos Mortos-Vivos.
Um “sysadmin infernal” que aplica política, diplomacia e necromancia em doses iguais.
💡 Curiosidade: Ainz é o sonho molhado de qualquer DBA — ninguém acessa o banco de dados dele sem permissão.
🔥 3. Maou Sadao (Hataraku Maou-sama!)
O Rei Demônio que virou atendente de fast food.
Um Maou que troca o trono do inferno por um emprego no “MgRonald” e aprende o valor do salário mínimo.
💡 Fofoquice: dizem que a autora se inspirou em um ex-chefe do McDonald’s de Shibuya que chamavam de “Maou” pelos funcionários.
🌌 4. Satan (Rin Okumura) (Blue Exorcist)
Filho do demônio, aluno de exorcismo — ou seja, um paradoxo ambulante.
Rin é o Maou adolescente que quer salvar o mundo enquanto carrega o fogo azul da perdição.
💡 Curiosidade: o fogo azul é inspirado na lenda budista do “fogo da purificação das ilusões”.
⚔️ 5. Diablo (How Not to Summon a Demon Lord)
O Maou gamer introvertido que acorda num RPG como o personagem overpower que criou.
Diablo é o avatar dos tímidos que sonham em dominar o mundo, mas travam no “bom dia”.
💡 Fofoquice: o autor, Yukiya Murasaki, admitiu que se inspirou em fóruns otaku dos anos 2000 onde usuários assinavam como “DemonLordXXX”.
🕯️ 6. Maou Luciferd (The Legend of Legendary Heroes)
Clássico, sombrio e com nome digno de um Power Metal.
Um Maou que mistura filosofia, solidão e violência com poesia trágica.
💡 Curiosidade: o nome “Luciferd” foi escolhido para soar “sofisticado” e “pecador” ao mesmo tempo.
🧩 7. Demon King Piccolo (Daimaō Piccolo) (Dragon Ball)
O primeiro Maou que muitos de nós conheceram.
Um vilão tão icônico que o próprio autor o dividiu em duas encarnações: o mal puro e o bem disciplinado.
💡 Easter-egg: Piccolo significa “pequeno” em italiano — ironia deliciosa para quem tenta dominar o mundo.
🪞 8. O Maou dos Espelhos (Re:Creators)
Um vilão meta que entende que é personagem e manipula o criador.
É o Maou da pós-modernidade: sabe que é ficção e mesmo assim quer existir.
💡 Curiosidade: o criador do anime, Rei Hiroe, descreveu ele como “a ira do público insatisfeito”.
A autoproclamada Maou mais incompetente da história.
Fofa, barulhenta e incapaz de fazer mal a uma mosca — mas cativante o suficiente pra ter legiões de fãs.
💡 Fofoquice: na comunidade japonesa do Reddit, ela foi eleita “Best Girl Demon Lord” por 3 anos seguidos.
🌑 10. Mao (Code Geass: Akito the Exiled)
Telepata, manipulador e desequilibrado.
Um Maou humano demais — com traumas, loucura e amor obsessivo.
💡 Curiosidade: o nome “Mao” vem de “魔王”, o mesmo kanji de “Rei Demônio”, e ele representa o colapso do poder absoluto.
🕳️ Epílogo do Capitão Bellacosa
No Japão, o Maou é mais que vilão — é o símbolo da rebeldia contra o destino.
É o herdeiro espiritual do samurai caído, do programador que virou insônia, do otaku que trocou o sol pelo brilho da tela.
O Maou é o “avatar da noite”: governa o caos, entende a solidão e faz do inferno o seu home office.
Então da próxima vez que alguém te chamar de “vilão”, apenas sorria com elegância noturna e diga:
“Não sou vilão. Sou versão 7.7 do caos — um Maou com update de empatia.”
☕ El Jefe Midnight Lunch "Porque até o Rei Demônio precisa de uma pausa pro café e uma boa ironia filosófica."
🚀 Buck Rogers no Mundo Mainframe — Deployment Patterns no Século XXV
Big Bang, Rolling, Blue-Green, Canary, Feature Toggle, Shadow Deployment, CICS, COBOL, Db2, VSAM, MQ, JCL e a estranha arte de colocar uma V2 em produção sem destruir o universo conhecido.
Imagine a cena.
O programador COBOL termina sua alteração. O compilador não reclamou. O link-edit terminou corretamente. Os testes passaram. O load module está pronto.
Na tela verde surge a mensagem que todo jovem tripulante da nave z/OS esperava:
MAXCC=0000
Ele sorri.
— Funcionou!
Buck Rogers, recém-descongelado depois de séculos, olha desconfiado para a tela.
— Funcionou onde?
Silêncio.
— Em desenvolvimento.
Buck continua:
— Com quais dados?
— Dados de teste.
— Com quantos usuários?
— Um.
— E quando colocarmos isso em produção?
Novo silêncio.
Bem-vindo ao verdadeiro problema.
Desenvolver V2 é somente metade da aventura. A outra metade é descobrir como substituir V1 sem transformar uma alteração COBOL aparentemente inocente em um incidente interplanetário.
É aqui que entram os Deployment Patterns.
E embora Big Bang, Rolling, Blue-Green, Canary e Feature Toggle sejam frequentemente apresentados usando containers, Kubernetes, microsserviços e aplicações web, seus princípios são extremamente úteis quando transportados para o universo do IBM Mainframe.
Prepare o café.
Wilma Deering já está na ponte.
Twiki está emitindo alguns bidi-bidi-bidi preocupantes.
E alguém acabou de perguntar:
“Quem vai promover isso para produção?”
🚀 CAPÍTULO 1 — Deployment não é simplesmente copiar um load module
Vamos começar com nosso sistema fictício de cartões, o BELLACARD.
Temos aproximadamente:
POS / ATM / MOBILE
|
v
API
|
v
MQ
|
v
CICS
|
v
+------------------+
| AUTHORIZATION |
| COBOL |
+------------------+
|
+----+----+
| |
Db2 VSAM
|
v
FRAUD / LIMIT / PRODUCT
Existe hoje:
AUTHORIZATION V1
Nossa equipe desenvolveu:
AUTHORIZATION V2
A V2 introduz uma nova regra de risco para compras internacionais.
Compilamos.
Testamos.
Homologamos.
Agora precisamos colocar V2 em produção.
É tentador pensar:
V1
↓
V2
Mas o sistema real pode ser:
COPYBOOK
|
v
JCL ───────────────> COBOL <──────────── CICS
|
+--------+--------+
| | |
v v v
Db2 VSAM MQ
| |
v v
BATCH API
|
v
ARQUIVO
|
v
DOWNSTREAM
Portanto, mudar um programa pode significar alterar uma aresta de um enorme grafo de dependências.
Essa é a primeira lição de Buck Rogers:
Deployment no mainframe não é mover um programa. É introduzir uma mudança em um ecossistema.
💥 CAPÍTULO 2 — Big Bang: todos os motores para potência máxima
Big Bang é o modelo mais simples de compreender.
Temos:
PRODUÇÃO
AUTORIZA = V1
Fazemos a implantação:
DEPLOY
|
v
AUTORIZA = V2
Todos passam a executar V2.
No universo batch isso pode parecer absolutamente natural.
V2 introduz novos campos ou altera a representação utilizada por algum fluxo.
Enquanto fazemos Rolling:
CICS A → PROGRAM V2
CICS B → PROGRAM V1
Ambos podem consumir ou produzir dados para:
Db2
VSAM
MQ
ARQUIVOS
OUTROS PROGRAMAS
Se V2 produz algo que V1 não compreende:
V2
|
v
NOVO LAYOUT
|
v
V1
|
v
💥
O deployment gradual transformou-se em uma armadilha.
Por isso um conceito aparentemente banal como compatibilidade de copybooks pode decidir se Rolling Deployment é seguro.
E não basta procurar quem chama o programa.
É preciso procurar quem compartilha seu contrato de dados.
🔵🟢 CAPÍTULO 5 — Blue-Green: duas Terras, uma produção
Buck Rogers encontra agora dois ambientes.
BLUE:
CICS BLUE
AUTORIZA V1
GREEN:
CICS GREEN
AUTORIZA V2
O tráfego começa assim:
BLUE V1
↑
|
100%
|
TRANSAÇÕES --------+
GREEN V2
0%
GREEN pode ser preparado e validado.
Quando decidimos liberar:
BLUE V1 0%
GREEN V2 100%
Problema?
Voltamos:
BLUE V1 100%
GREEN V2 0%
Parece o Santo Graal do rollback.
Mas Dr. Huer chama Buck pelo comunicador:
— Capitão, temos um pequeno problema.
— Qual?
— O Db2.
Ah.
O banco de dados.
Sempre ele.
🗄️ CAPÍTULO 6 — O código voltou. Os dados não.
Imagine:
BLUE V1 ───┐
|
+---- DB2
|
GREEN V2 ──┘
GREEN recebeu tráfego durante quinze minutos.
Nesse intervalo processou:
82.347 autorizações
Algumas atualizaram Db2.
Outras atualizaram VSAM.
Outras produziram mensagens MQ.
Talvez outras tenham chamado sistemas externos.
Agora alguém diz:
“Deu problema. Volta para BLUE!”
Podemos devolver o tráfego para V1 em segundos.
Mas o que fazemos com as 82.347 operações produzidas por V2?
Eis uma das lições mais importantes deste artigo:
CODE ROLLBACK
≠
STATE ROLLBACK
Restaurar o executável antigo não significa desfazer:
UPDATE DB2
WRITE VSAM
MQ PUT
arquivo produzido
API chamada
pagamento efetuado
evento publicado
Em sistemas financeiros isso se torna ainda mais importante porque alguns efeitos precisam ser compensados, não simplesmente apagados.
Rollback é um problema de arquitetura de estado.
🐤 CAPÍTULO 7 — Canary: mande Twiki primeiro
Imagine que Buck tenha uma ideia.
— Em vez de mandar toda a frota para aquele planeta, vamos mandar Twiki.
Twiki responde:
Bidi-bidi-bidi.
É basicamente Canary Deployment.
Começamos:
99% → AUTORIZA V1
1% → AUTORIZA V2
Observamos.
Se tudo estiver correto:
90% → V1
10% → V2
Depois:
50% → V1
50% → V2
Finalmente:
100% → V2
Se V2 tiver um defeito catastrófico, reduzimos o número inicial de usuários afetados.
Estamos reduzindo o:
Blast Radius
Compare:
BIG BANG
BUG
|
v
100% usuários
com:
CANARY
BUG
|
v
1% usuários
Mas existe uma condição.
📡 CAPÍTULO 8 — Canary sem radar é apenas uma nave perdida
Se enviarmos 1% do tráfego para V2 mas não observarmos o que acontece, apenas demoraremos mais para descobrir o desastre.
Precisamos de telemetria.
No universo mainframe podemos pensar em indicadores técnicos envolvendo:
ABENDs
response time
CPU
transaction rate
SQLCODEs
timeouts
MQ queue depth
CICS performance
erros de aplicação
Mas Buck pergunta:
— E quantas compras estamos recusando?
Excelente pergunta.
Suponha:
V1 APPROVAL RATE = 91,4%
V2 APPROVAL RATE = 73,1%
Enquanto isso:
ABEND = 0
SQL ERROR = 0
CPU = NORMAL
MQ = NORMAL
CICS = NORMAL
Do ponto de vista computacional:
Tudo verde.
Do ponto de vista do negócio:
Houston... quer dizer, New Chicago... temos um problema.
V2 está recusando milhares de clientes legítimos.
Daí nasce uma regra preciosa:
RC=0000 não significa que o negócio está correto.
Observabilidade moderna precisa juntar:
TECHNICAL OBSERVABILITY
+
BUSINESS OBSERVABILITY
🚩 CAPÍTULO 9 — Feature Toggle: a arma secreta
Agora chegamos a uma diferença conceitual importantíssima.
Feature Toggle não é exatamente a mesma categoria dos outros padrões.
Big Bang, Rolling, Blue-Green e Canary respondem principalmente:
Como V2 entra no ambiente?
Feature Toggle responde:
Quando determinada funcionalidade de V2 será utilizada?
Podemos fazer deployment hoje:
AUTORIZA V2
mas manter:
NEW-RISK-SCORE = OFF
A nova lógica está instalada, porém não liberada.
Depois:
NEW-RISK-SCORE = ON
Em COBOL, conceitualmente:
IF WS-NEW-RISK-SCORE = 'Y'
PERFORM 7000-RISK-SCORE-V2
ELSE
PERFORM 6000-RISK-SCORE-V1
END-IF.
Temos então:
DEPLOYMENT
≠
RELEASE
Essa separação é extremamente poderosa.
🏛️ CAPÍTULO 10 — Mainframe fazia isso antes de virar moda
Existe uma deliciosa ironia histórica aqui.
Feature Flags parecem extremamente modernas quando aparecem em apresentações sobre Cloud Native.
Mas sistemas corporativos há décadas controlam comportamento através de:
PARÂMETROS
SYSIN
TABELAS DB2
DATASETS
CONFIGURAÇÕES
SWITCHES
REGRAS DE PRODUTO
Não estou dizendo que cada parâmetro antigo seja uma feature flag moderna.
Estou dizendo que o princípio:
“colocar código em produção sem necessariamente ativar determinado comportamento”
não nasceu ontem.
Mainframe frequentemente nos ensina que tecnologias novas são, algumas vezes, ideias antigas usando nomes novos e camisetas mais bonitas.
🧟 CAPÍTULO 11 — A Feature Flag que se recusou a morrer
Feature Toggle possui seu próprio perigo.
Começamos inocentemente:
IF FEATURE-A = 'Y'
...
END-IF
Depois:
IF FEATURE-A = 'Y'
IF FEATURE-B = 'N'
...
END-IF
END-IF
Cinco anos depois:
IF FEATURE-A = 'Y'
IF FEATURE-B = 'N'
IF FEATURE-C = 'Y'
IF PRODUCT-TYPE = '07'
IF OLD-MIGRATION-FLAG NOT = 'X'
...
Buck Rogers pede imediatamente para ser congelado novamente.
Feature Flags precisam de ciclo de vida:
CREATE
↓
TEST
↓
DEPLOY OFF
↓
ENABLE CANARY
↓
OBSERVE
↓
EXPAND
↓
100% ON
↓
REMOVE OLD CODE
↓
REMOVE FLAG
O último passo é importantíssimo.
Caso contrário criamos technical debt condicional.
👻 CAPÍTULO 12 — Shadow Deployment: o universo paralelo
Existe uma sexta estratégia que merece entrar na nave.
Imagine que estamos substituindo um algoritmo COBOL de risco.
Hoje:
RISKV1
Novo:
RISKV2
Não confiamos suficientemente em V2 para deixá-lo decidir transações.
Podemos conceitualmente executar ambos:
+---- RISKV1
TRANSAÇÃO -----------| |
| +--> DECISÃO REAL
|
+---- RISKV2
|
+--> SOMENTE OBSERVAÇÃO
V1 diz:
APPROVED
V2 também:
APPROVED
Excelente.
Outra:
V1 = APPROVED
V2 = DECLINED
Interessante.
Depois de grande volume:
V1 = V2 99,96%
V1 != V2 0,04%
Agora investigamos aquele 0,04%.
Isso pode ser extremamente poderoso para testar novas regras, modelos de risco ou modernizações sem entregar imediatamente a decisão de produção ao componente novo.
Mas existe uma regra fundamental:
Shadow não pode duplicar efeitos colaterais.
Se ambos executarem:
UPDATE ACCOUNT
MQ PUT
POST TRANSACTION
acabamos de transformar uma compra em duas.
O universo explodiu.
Obrigado, Buck.
🧬 CAPÍTULO 13 — Expand and Contract: preparando o Db2 para duas épocas
Imagine que V2 precise de:
RISK_SCORE
na estrutura de dados.
A abordagem ingênua seria mudar tudo simultaneamente.
Uma abordagem evolutiva pode seguir:
FASE 1
SCHEMA antigo
+
estrutura nova compatível
Depois:
FASE 2
V1 + V2 conseguem trabalhar
Depois:
FASE 3
V2 assume
Depois:
FASE 4
V1 desaparece
Finalmente:
FASE 5
estruturas antigas são removidas
É o princípio de Expand and Contract:
OLD
|
v
OLD + NEW
|
v
NEW
|
v
REMOVE OLD
Ele é importantíssimo quando queremos coexistência entre versões.
📦 CAPÍTULO 14 — Batch: a galáxia esquecida pelos diagramas DevOps
Muitos diagramas modernos assumem algo parecido com:
USER → LOAD BALANCER → SERVER
No mainframe podemos encontrar:
JOB001
|
v
FILE01
|
v
JOB002
|
v
DB2
|
v
JOB003
|
v
REPORT
Agora alteramos JOB001.
Ele passa a produzir:
LAYOUT V2
Mas JOB002 continua esperando:
LAYOUT V1
Resultado:
JOB001 V2
|
v
FILE V2
|
v
JOB002 V1
|
v
💥
Portanto, em processamento batch, a unidade de deployment pode não ser um programa.
Pode ser uma cadeia inteira de processamento.
Essa é uma mudança mental importantíssima para o iniciante.
🕸️ CAPÍTULO 15 — Antes de fazer deploy, desenhe o grafo
Buck Rogers agora encontra uma ferramenta muito mais poderosa que qualquer pistola laser:
um lápis.
Antes do deployment, desenhe:
COPYBOOK
|
v
JCL -------------> COBOL <------------- CICS
|
+---------+---------+
| | |
v v v
DB2 VSAM MQ
| |
v v
BATCH API
|
v
FILE
|
v
DOWNSTREAM
Pergunte:
Quem chama?
Quem é chamado?
Quem lê os dados produzidos?
Quem escreve os mesmos dados?
Quem compartilha copybook?
Quem recebe MQ?
Quem depende do arquivo?
Quem depende da tabela?
Quem depende da semântica da informação?
Porque o risco não mora apenas nos nós.
Muitas vezes ele mora nas arestas.
🔐 CAPÍTULO 16 — Buck Rogers veste o capacete do Red Team
Deployment Patterns também criam superfícies de segurança.
Blue-Green possui dois ambientes.
Canary possui mecanismo de roteamento.
Feature Toggle possui mecanismo de ativação.
Shadow replica tráfego.
Rolling mantém versões coexistindo.
O Red Team começa a perguntar:
Quem pode alterar a feature flag?
Quem consegue mudar o routing?
Quem pode promover load modules?
Quem controla datasets de configuração?
GREEN tem as mesmas proteções de BLUE?
V1 continua acessível?
Quem pode alterar STEPLIB?
Quem controla as libraries?
Existem credenciais esquecidas no ambiente standby?
Shadow recebe dados sensíveis?
As mudanças são auditadas?
No z/OS isso pode trazer para a investigação controles e componentes relacionados a:
RACF
dataset profiles
CICS security
Db2 privileges
USS permissions
started tasks
libraries
pipeline credentials
Veja a transformação.
Começamos discutindo:
Como fazer deployment?
Agora estamos discutindo:
Quem possui autoridade para alterar o comportamento de produção?
Essa segunda pergunta é muito mais interessante para segurança.
⚔️ CAPÍTULO 17 — O rollback que existia apenas no PowerPoint
Toda reunião de mudança possui aquela pergunta:
“Tem rollback?”
E alguém responde:
“Sim.”
Buck Rogers deveria imediatamente perguntar:
“Mostre.”
Porque:
BACKUP EXISTE
não significa:
RESTORE FOI TESTADO
E:
LOAD MODULE V1 EXISTE
não significa:
SISTEMA CONSEGUE VOLTAR PARA V1
Se V2 alterou dados, publicou eventos e disparou processos downstream, voltar o programa talvez seja apenas uma parte da recuperação.
Um plano real deveria considerar:
Código
Dados
Mensagens
Arquivos
Configuração
Permissões
Jobs
Dependências
Efeitos externos
O rollback precisa ser tratado como capacidade operacional testável, não como frase tranquilizadora em um documento.
📊 CAPÍTULO 18 — A matriz de Buck Rogers
Podemos resumir nossas estratégias assim:
Estratégia
Ideia central
Principal vantagem
Principal risco
Big Bang
V1 → V2 de uma vez
simplicidade
grande blast radius
Rolling
troca gradual
reduz exposição
coexistência V1/V2
Blue-Green
dois ambientes
troca/retorno rápidos
estado e custo
Canary
V2 recebe pouco tráfego
limita impacto
exige observabilidade
Feature Toggle
funcionalidade controlada
deploy ≠ release
dívida técnica
Shadow
V2 observa tráfego
validação realista
efeitos colaterais
Expand/Contract
evolução compatível
suporta coexistência
maior disciplina
Nenhum deles é “o melhor”.
A pergunta correta é:
Qual risco estou tentando controlar?
🚀 CAPÍTULO 19 — A combinação intergaláctica
O grande segredo é que não precisamos escolher apenas um.
Podemos ter:
TRANSAÇÕES
|
ROUTER
/ \
/ \
BLUE V1 GREEN V2
|
FEATURE FLAG
/ \
OFF ON
|
CANARY
1%
GREEN recebe V2.
A feature permanece OFF.
Ativamos para um pequeno grupo.
Monitoramos.
Expandimos.
Se necessário, desligamos a funcionalidade.
Se o executável inteiro apresentar problema, alteramos o roteamento.
Temos várias camadas de contenção.
É quase uma defesa em profundidade aplicada ao deployment.
👨💻 CAPÍTULO 20 — O programador COBOL iniciante recebe sua primeira missão
Você recebeu a seguinte solicitação:
“Alterar AUTORIZA para implementar nova regra de compras internacionais.”
Não abra imediatamente o fonte.
Primeiro investigue.
Passo 1 — Entenda a mudança
Descubra:
Regra de negócio
Entrada
Saída
Dados alterados
Efeitos colaterais
E tudo isso trouxe técnicas, automação e possibilidades importantíssimas.
Mas quando olhamos para o problema essencial encontramos perguntas extremamente familiares ao mundo mainframe:
Qual versão está executando?
Quem pode promovê-la?
Quais dados ela utiliza?
Quem depende desses dados?
Como controlar sua ativação?
Como limitar impacto?
Como observar produção?
Como retornar?
Quem audita tudo isso?
Mainframe nunca esteve fora dessa conversa.
O vocabulário apenas mudou.
Talvez ontem chamássemos determinada solução de parâmetro, hoje de Feature Flag.
Talvez tivéssemos múltiplas regiões e hoje alguém reconheça nelas possibilidades associadas a Rolling ou Canary.
Talvez uma mudança coordenada durante a janela batch seja reconhecida conceitualmente como Big Bang.
Não devemos forçar equivalências técnicas onde elas não existem. Kubernetes não é CICS, uma LPAR não é um pod e trocar uma STEPLIB não transforma automaticamente um sistema COBOL em Blue-Green.
O que podemos transportar são os princípios de engenharia.
E essa talvez seja a maior lição para quem começa agora no COBOL.
O programador iniciante acredita que sua responsabilidade termina aqui:
COMPILE
↓
LINK
↓
MAXCC=0000
O engenheiro começa a enxergar:
SOURCE
↓
COMPILE
↓
TEST
↓
DEPLOY
↓
RELEASE
↓
OBSERVE
↓
VALIDATE BUSINESS
↓
EXPAND
↓
RECOVER IF NECESSARY
↓
REMOVE OLD VERSION
E o profissional realmente experiente ainda acrescenta uma pergunta antes de tudo isso:
“O que acontece com o resto da galáxia quando eu mudar esta linha?”
Essa é a diferença entre programar um COBOL e entender o sistema no qual aquele COBOL vive.
Buck Rogers acordou no século XXV esperando encontrar um mundo completamente diferente.
Encontrou naves espaciais, computadores avançados, cidades futuristas e tecnologias inimagináveis.
Mas, em algum canto da Federação Terrestre, provavelmente ainda existiria um sistema crítico perguntando:
IF NEW-FEATURE = 'Y'
PERFORM NEW-LOGIC
ELSE
PERFORM OLD-LOGIC
END-IF.
E alguém, diante da console, perguntaria:
“Tem certeza de que podemos colocar isso em produção?”
Bellacosa Mainframe e a guerra invisivel no Mainframe
☕ Um Café no Bellacosa Mainframe
🕵️♂️ SPY VS. SPY E A GUERRA INVISÍVEL DENTRO DO MAINFRAME
Blue Team, Red Team, RACF, SAF, SMF, SIEM, Threat Hunting, TCP/IP, CICS, Db2, IMS, MQ, USS, criptografia, GRC, Cyber Resilience — e o dia em que dois espiões descobriram que conseguir entrar no mainframe era apenas o começo do problema.
Sob a tutela de Spy vs. Spy — porque, em Cybersecurity, cada armadilha construída pelo atacante deveria ensinar o defensor a construir uma defesa melhor.
🎬 PRÓLOGO — DOIS ESPIÕES ENTRARAM NO DATACENTER
Imagine nosso jovem programador COBOL chegando para trabalhar.
Café sobre a mesa.
ISPF aberto.
Uma pequena alteração aguardando:
IF SALDO-CONTA < VALOR-COMPRA
MOVE 'N' TO COMPRA-AUTORIZADA
ELSE
MOVE 'S' TO COMPRA-AUTORIZADA
END-IF.
Nada muito assustador.
Então ele olha para o corredor.
Passa correndo o Spy Branco carregando um notebook.
Alguns segundos depois aparece o Spy Preto, carregando uma pasta cheia de documentos.
O programador pergunta:
— O que vocês estão fazendo?
O Branco responde:
— Tentando entrar no mainframe.
O Preto completa:
— E eu estou tentando descobrir se ele consegue.
Nosso programador olha para a tela 3270.
— Mas temos RACF.
Os dois espiões param.
Olham um para o outro.
E começam a rir.
Bem-vindo ao mundo da Cybersecurity no Mainframe.
Porque segurança não significa simplesmente colocar uma senha na porta do z/OS.
O verdadeiro problema é muito maior:
Quem é você?
↓
O que pode acessar?
↓
O que pode fazer?
↓
O que está fazendo?
↓
Isso é normal?
↓
Conseguimos perceber uma anomalia?
↓
Conseguimos responder?
↓
E, se tudo der errado...
↓
CONSEGUIMOS RECUPERAR?
É exatamente aqui que começa nossa guerra de Spy vs. Spy.
🏰 CAPÍTULO 1 — O MAINFRAME NÃO É UMA ILHA
Durante décadas nasceu um mito curioso:
"Mainframe é seguro porque ninguém consegue chegar até ele."
Talvez isso pudesse parecer razoável quando alguém imaginava um computador isolado em uma sala refrigerada.
Mas o IBM Z moderno participa de um enorme ecossistema.
Temos potencialmente:
Internet
│
Cloud
│
API Gateway
│
Firewall
│
Load Balancer
│
z/OS Connect
│
CICS
│
COBOL
│
Db2
Essa é a primeira lição que Spy Branco e Spy Preto deixam para nosso padawan COBOL.
O ataque nem precisa começar no mainframe.
Pode começar em outro ponto da cadeia.
Uma credencial comprometida, uma estação corporativa, uma configuração inadequada, uma aplicação web vulnerável ou permissões excessivas podem fazer parte de um caminho que eventualmente chega aos sistemas centrais.
Por isso, quando pensamos em Cybersecurity, precisamos olhar para todo o caminho até o dado.
🔵 CAPÍTULO 2 — SPY BRANCO ENTRA PARA O BLUE TEAM
Vamos colocar nosso Spy Branco na defesa.
Ele pertence agora ao:
BLUE TEAM
O Blue Team tenta proteger, detectar e responder.
No desenho original que iniciou nossa conversa aparecem elementos como:
Network Security
Incident Response
SIEM
Threat Hunting
Malware Analysis
Identity Management
Cryptography
No IBM Z podemos enriquecer enormemente esse mapa.
Nenhuma camada deveria carregar sozinha toda a responsabilidade.
📋 CAPÍTULO 16 — GRC: O ESPIÃO DE TERNO E GRAVATA
Chega um terceiro personagem.
Não carrega bomba.
Não carrega alicate.
Carrega uma planilha.
Spy Branco e Spy Preto ficam assustados.
É o auditor.
Governance, Risk & Compliance parece menos cinematográfico, mas responde perguntas perigosíssimas:
Quem possui acesso?
Quem aprovou?
Quando aprovou?
Por quê?
Ainda precisa?
Existe segregação de funções?
Existe evidência?
A política está sendo cumprida?
A palavra mágica é:
EVIDÊNCIA
Não queremos:
"Tenho quase certeza de que ninguém acessa."
Queremos algo demonstrável:
USER
RESOURCE
ACCESS
DATE
TIME
RESULT
SOURCE
Em segurança:
"Eu acho" não é evidência.
💾 CAPÍTULO 17 — CYBER RESILIENCE: E SE SPY PRETO CONSEGUIR?
Qual dado foi alterado?
Quando começou?
Qual cópia é confiável?
O backup também foi afetado?
Quanto tempo levaremos para voltar?
Como sabemos que o ambiente recuperado está limpo?
Backup e Cyber Resilience não são exatamente a mesma coisa.
Possuir uma cópia é apenas parte do problema.
Precisamos confiar nela e conseguir utilizá-la dentro das necessidades do negócio.
🟣 CAPÍTULO 18 — QUANDO SPY BRANCO E SPY PRETO TOMAM CAFÉ
Aqui acontece a grande transformação.
Blue Team e Red Team não deveriam viver simplesmente como adversários.
Eles podem colaborar.
Surge o conceito de:
PURPLE TEAM
Spy Preto diz:
— Consegui executar determinado cenário.
Spy Branco responde:
— Não detectei.
Excelente.
Não porque a defesa falhou.
Mas porque descobriram a deficiência durante um exercício controlado.
Então:
RED
↓
TESTA
↓
BLUE
↓
OBSERVA
↓
PURPLE
↓
MELHORA
↓
RED
↓
TESTA NOVAMENTE
Esse ciclo vale ouro.
🧪 CAPÍTULO 19 — UM EXERCÍCIO PARA O PADAWAN COBOL
Você pode aprender cybersecurity sem começar tentando "hackear alguma coisa".
O profissional COBOL não precisa jogar fora sua experiência para entrar em Cybersecurity.
Precisa aumentar seu campo de visão.
🕵️♂️ EPÍLOGO — QUEM GANHOU: SPY BRANCO OU SPY PRETO?
São 03:17.
Spy Preto prepara sua última armadilha.
Spy Branco já sabe que ela existe.
Nosso programador COBOL olha para os dois e pergunta:
— Afinal, quem ganhou?
Os espiões se encaram.
Nenhum responde.
Porque finalmente nosso padawan percebe a pegadinha.
Se o Red Team encontra uma fraqueza antes do atacante real...
Blue Team ganhou.
Se Blue Team melhora sua detecção graças ao teste...
Red Team ganhou.
Se auditoria consegue provar que os controles funcionam...
GRC ganhou.
Se uma identidade comprometida não consegue transformar um pequeno incidente em comprometimento generalizado...
A arquitetura ganhou.
E se, mesmo diante de um incidente grave, a organização consegue identificar o impacto, preservar evidências, restaurar dados confiáveis e continuar funcionando...
Cyber Resilience ganhou.
Portanto, o verdadeiro inimigo nunca foi Spy Branco ou Spy Preto.
O inimigo era aquilo que ninguém enxergava.
Uma permissão esquecida.
Um serviço desconhecido.
Uma chave mal administrada.
Um evento que ninguém coletava.
Um dataset que todos juravam estar protegido.
Uma credencial válida se comportando de maneira completamente diferente às 03:17 da madrugada.
E talvez essa seja a principal lição para nosso jovem programador COBOL:
Cybersecurity no mainframe começa quando deixamos de perguntar apenas "ele conseguiu entrar?" e começamos a perguntar quem entrou, por onde entrou, o que podia fazer, o que realmente fez, quais evidências deixou, quem percebeu e como o negócio sobreviveria se todas as barreiras anteriores falhassem.
Spy Branco fecha o ISPF.
Spy Preto guarda sua pasta.
Nosso padawan termina o café.
Na tela permanece apenas:
READY
Mas agora ele sabe que atrás daquele simples READY existe uma catedral inteira de identidade, autorização, rede, criptografia, telemetria, detecção, investigação, resposta, governança e resiliência.
E é justamente aí que um programador COBOL pode começar uma segunda carreira sem abandonar a primeira:
de quem escreve o sistema para quem também entende como protegê-lo.
🔻 O Império do Medo: quando o autoritarismo russo ultrapassou o próprio mito
Por Bellacosa Mainframe | Dossiê da Dor Lúcida
Há algo de profundamente trágico na constatação de que o regime russo não é apenas autoritário — é imaginativamente cruel.
A história recente mostrou que o medo, quando institucionalizado, vira método de governo, e a mentira, quando repetida o bastante, adquire status de fé.
Durante décadas, o Ocidente quis acreditar que o autoritarismo russo era um resquício da Guerra Fria, uma herança congelada que o tempo derreteria.
Mas o tempo não derreteu nada.
Apenas revelou o que estava por baixo: uma máquina antiga, restaurada, polida e movida a paranoia.
🇷🇺 A Rússia Que Saiu do Espelho
O projeto político de Moscou já não finge ser democrático.
Não há mais máscaras, nem meias palavras. O regime aprendeu a transformar a brutalidade em estética — a censura virou patriotismo, o medo virou identidade nacional, e o exílio, uma nova forma de silêncio.
O Estado moderno russo parece viver num teatro de sombras, onde cada cidadão é plateia e prisioneiro ao mesmo tempo.
A tragédia é que muitos aplaudem.
A psicologia coletiva, treinada por gerações de trauma, aprendeu a confundir obediência com sobrevivência.
🩸 A Dor Além das Expectativas
A invasão da Ucrânia foi o ponto em que o autoritarismo russo deixou de ser um conceito e virou uma realidade transmitida em tempo real.
Foi ali que o mundo viu — sem filtros — o que acontece quando um sistema constrói sua força sobre o culto à humilhação.
As prisões de dissidentes, os jornalistas silenciados, as mães que recebem corpos e não respostas.
Tudo acontece com a frieza burocrática de um regime que já não precisa justificar nada — apenas continuar.
E o mais doloroso: essa dor é tão planejada quanto uma operação militar.
Cada silêncio é uma arma.
Cada mentira, uma bala.
🕳️ O Abismo Moral e o Espelho do Mundo
O autoritarismo russo não é uma aberração isolada — é um espelho distorcido do planeta cansado, que ainda acredita que a tirania é um problema distante.
Mas os algoritmos autoritários estão em toda parte: nos discursos que chamam censura de “ordem”, nas populações que trocam liberdade por estabilidade, nas nações que confundem neutralidade com covardia.
A Rússia apenas deu forma ao que muitos ainda fingem não ver:
o medo é uma moeda universal.
🔥 O Horror de Ter Razão
Quando intelectuais e dissidentes avisavam sobre a natureza expansionista e repressora do regime, o mundo respondeu com sarcasmo e contratos de gás.
Agora, é tarde.
O império do medo mostrou sua eficiência — não apenas em invadir países, mas em anestesiar consciências.
O horror é perceber que eles estavam certos.
E que a verdade, mesmo provada, continua impotente diante do cálculo político.
💬 Para o Padawan que observa da penumbra:
Aprenda esta lição: o autoritarismo nunca chega de repente — ele é cultivado.
E quando floresce, o perfume é sempre o mesmo: o da dor justificada, da mentira elegante, da fé deformada.
“O regime russo não apenas controla corpos — ele coloniza almas.”
🕯️ O século XXI prometeu progresso e trouxe de volta os fantasmas.
A Rússia, com sua fria precisão, apenas nos lembrou do que somos capazes quando esquecemos de sentir vergonha.
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
