✨ 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
Andanças pelo Espirito Santo e algumas de suas cidades.
Em 1993 inciei uma aventura por alguns estados brasileiros, na altura as fotografias eram em negativos 35 mm, muito caros, por isso fiz poucas fotos. Mas documentei os principais locais que passei no Estado do Espirito Santo.
Fiquei hospedado num albergue da juventude e da lá fiz minha exploração, passando pelo centro de Vitoria em busca de um Banespa, pois estava sem dinheiro e naquela época cartões magnéticos só funcionavam no próprio Banco, depois atravessando a ponte em direção a Vila Velha encontrei o Convento Nossa Senhora da Penha, após subir uma viela atingi 158 metros de altura acima do nível do mar e encontrei esta joia no monte, encantado após ver as joias esculpidas em madeira no altar mor, desci andei pela praia ate encontrar uma bela orla, com calçadão e areia dourada para finalmente encontrar um farol que ilumina e protegeu durante anos os navios que la navegavam.
Foi frustante ir até a fabrica dos chocolates Garoto, sem poder conhecer e nem comprar nada na loja, esperava mais, sonhava até em uma visita, mas não rolou. Espero que gostem desta visão do Atlântico, os edifícios e arquitetura desta cidade.
Bellacosa Mainframe e o misterio do carimbo invisivel
☕ Um Café no Bellacosa Mainframe
O Mistério do Carimbo Invisível
Quando um Jovem Programador COBOL Descobriu que Milhões de Transações Dependiam de uma Palavra Chamada SYNCPOINT
"Toda cidade possui um juiz invisível. No CICS, ele atende pelo nome de SYNCPOINT."
Era pouco depois das duas da manhã.
No CPD, apenas o som ritmado dos equipamentos IBM preenchia o ambiente. As luzes verdes piscavam como estrelas artificiais em um universo onde bilhões de bytes viajavam silenciosamente pelos canais do mainframe.
O jovem programador Henrique havia acabado de terminar sua primeira rotina de transferência bancária em COBOL.
Estava orgulhoso.
O programa compilava.
Não havia nenhum S0C7.
Nenhum AEI9.
Nenhum ASRA.
Tudo parecia perfeito.
Mas o velho analista Augusto Bellacosa apenas sorriu, tomou mais um gole de café e perguntou:
— "Muito bonito... mas quem garante que o dinheiro realmente chegou ao destino?"
Henrique congelou.
— "Como assim?"
Augusto levantou uma sobrancelha.
— "Você escreveu um programa. Ainda não escreveu uma transação."
Naquela madrugada, Henrique descobriria um dos maiores segredos do CICS.
Um segredo invisível.
Chamado...
SYNCPOINT.
O que realmente é um SYNCPOINT?
Todo iniciante imagina que um programa executa linha após linha e, no final, tudo fica gravado.
No mundo do CICS isso não funciona assim.
Na verdade, o CICS trabalha com um conceito muito mais sofisticado chamado:
Unit of Work (UOW).
Uma Unit of Work é um conjunto de operações que pertencem à mesma missão.
Imagine um detetive dos filmes noir dos anos 1950.
Ele recebe um envelope.
Dentro dele existem quatro documentos.
Nenhum pode desaparecer.
Nenhum pode ser trocado.
Nenhum pode ser perdido.
Somente quando todos estiverem completos ele coloca um enorme carimbo vermelho escrito:
CONFIRMADO
Esse carimbo é o SYNCPOINT.
Até esse momento...
Nada é definitivo.
A grande mentira que todo iniciante acredita
Muitos programadores pensam:
"Fiz um REWRITE.
O registro já está salvo."
Não.
Essa é uma das maiores armadilhas do CICS.
Na realidade acontece isto:
READ UPDATE
↓
Registro bloqueado
↓
Programa altera memória
↓
REWRITE
↓
Registro continua pertencendo à transação
↓
SYNCPOINT
↓
Agora sim tudo ficou permanente.
O REWRITE altera.
O SYNCPOINT confirma.
São responsabilidades completamente diferentes.
Imagine um Cartório
Pense em um contrato.
Você assina.
A outra pessoa assina.
As testemunhas assinam.
Mas...
Enquanto o tabelião não colocar o selo oficial...
Nada possui validade jurídica.
O SYNCPOINT é exatamente esse selo.
O nascimento da Unit of Work
Toda transação CICS começa discretamente.
Usuário entra
↓
Programa inicia
↓
Lê arquivos
↓
Atualiza DB2
↓
Atualiza VSAM
↓
Grava TSQ
↓
Envia MQ
↓
...
Tudo isso ainda pertence à mesma história.
É apenas quando aparece:
EXEC CICS
SYNCPOINT
END-EXEC.
que aquela história ganha um final definitivo.
O CICS possui memória fotográfica
Pouca gente sabe disso.
Enquanto você altera registros, o CICS praticamente fotografa o estado anterior dos dados.
Por quê?
Porque talvez precise voltar tudo.
Imagine um pintor restaurando um quadro do século XVIII.
Antes de tocar na tinta original ele tira dezenas de fotografias.
Caso algo dê errado...
Pode restaurar exatamente como estava.
O CICS faz algo parecido através dos mecanismos de recuperação e journals.
O poder escondido do Journal
Existe um personagem que quase nunca aparece nas apostilas.
O Journal.
Ele é como o diário secreto do sistema.
Ali ficam registrados acontecimentos suficientes para permitir que a recuperação seja feita com segurança.
É graças a ele que o CICS consegue dizer:
"Se algo der errado, sei exatamente como desfazer."
Sem Journal...
Rollback seria praticamente impossível.
O verdadeiro significado do COMMIT
A maioria pensa que COMMIT significa:
Gravar.
Na realidade significa muito mais.
Quando acontece um SYNCPOINT o CICS:
✔ confirma alterações no DB2
✔ confirma alterações VSAM
✔ confirma recursos recuperáveis
✔ sincroniza todos os participantes da transação
✔ grava informações de recuperação
✔ encerra a Unit of Work
✔ libera todos os locks
✔ informa aos Resource Managers que tudo terminou corretamente
É quase como um maestro encerrando uma sinfonia.
O Tribunal Supremo das Transações
Imagine um julgamento.
Cinco testemunhas.
Quatro advogados.
Um juiz.
Todos apresentam suas provas.
No final...
O juiz fala apenas uma palavra.
"Culpado."
Ou
"Inocente."
Não existe meio culpado.
O SYNCPOINT funciona exatamente assim.
Todos os recursos esperam a decisão final.
O fantasma chamado Rollback
Agora imagine outro cenário.
Henrique faz uma transferência.
Conta A
↓
Debita R$ 5.000
↓
Conta B
↓
Erro no VSAM
Sem rollback:
Conta A perdeu dinheiro.
Conta B não recebeu.
Dinheiro evaporou.
Imagine isso acontecendo milhões de vezes.
Nenhum banco sobreviveria.
Então entra em cena o segundo personagem desta história.
EXEC CICS
SYNCPOINT ROLLBACK
END-EXEC.
O CICS olha para trás.
Lê sua memória.
E desfaz tudo.
Como se nada tivesse acontecido.
É quase uma máquina do tempo.
O poder da viagem temporal
Poucas tecnologias conseguem fazer isso tão elegantemente.
Rollback literalmente faz o sistema voltar alguns segundos.
Não todo o computador.
Apenas aquela Unit of Work.
É como rebobinar somente uma cena do filme.
Um erro clássico dos iniciantes
Henrique perguntou:
— "Então posso fazer commit depois de cada registro?"
Augusto quase derrubou o café.
— "Claro que pode."
Henrique sorriu.
Então Augusto completou.
— "E também pode destruir toda a performance do sistema."
Commits possuem custo.
Cada um envolve sincronização.
Logs.
Liberação de locks.
Comunicação entre Resource Managers.
Por isso existe um equilíbrio delicado.
Nem commits demais.
Nem commits de menos.
Quando não fazer commit?
Imagine atualizar cem registros.
Se fizer cem commits...
O sistema gastará muito tempo apenas encerrando Units of Work.
Agora imagine atualizar dez milhões de registros.
Fazer apenas um commit no final também pode ser um desastre.
Locks ficarão presos durante muito tempo.
O segredo está no equilíbrio.
Esse é um dos motivos pelos quais arquitetos de sistemas estudam cuidadosamente o tamanho ideal da UOW.
O segredo dos Locks
Outro mistério.
Muitos acreditam:
READ UPDATE
↓
REWRITE
↓
Registro liberado
Não.
O lock continua.
Somente o commit libera.
Isso explica diversos problemas de contenção.
Enquanto uma transação segura um registro...
Outra precisa esperar.
ENQ, DEQ e SYNCPOINT
Lembra dos comandos ENQ e DEQ?
Eles são parentes próximos do SYNCPOINT.
Imagine uma biblioteca.
Você pega um livro raro.
Enquanto ele está emprestado ninguém mais pode utilizá-lo.
O ENQ reserva.
O DEQ devolve.
Já o SYNCPOINT garante que todo o processo envolvendo aquele livro foi concluído corretamente antes de liberar os demais recursos associados à transação.
São mecanismos diferentes, mas frequentemente trabalham em harmonia para preservar a consistência da aplicação.
E se o computador desligar?
Essa é uma das perguntas favoritas das entrevistas IBM.
Imagine:
UPDATE DB2
↓
UPDATE VSAM
↓
Queda de energia
O CICS consulta seus registros de recuperação.
Percebe que aquela Unit of Work nunca terminou.
Resultado?
Backout automático.
O usuário talvez nem perceba.
Esse comportamento é uma das razões pelas quais bancos confiam no CICS há mais de cinco décadas.
A ligação com o DB2
Quando DB2 participa da transação, ele também espera.
Nenhuma alteração fica permanente até que o SYNCPOINT seja executado.
É como vários cofres aguardando a mesma chave.
Somente quando a chave gira...
Todos são fechados simultaneamente.
VSAM também participa
Da mesma forma:
READ UPDATE
↓
REWRITE
↓
DELETE
↓
WRITE
Tudo permanece dentro da mesma Unit of Work.
O VSAM somente considera as alterações definitivamente concluídas quando o CICS encerra a transação com sucesso.
Observe como as peças começam a formar um quebra-cabeça.
O conhecimento em CICS é cumulativo.
Cada comando reforça o entendimento do anterior.
Curiosidade Histórica
Nos primeiros anos do CICS, quando bancos começaram a abandonar sistemas baseados em processamento puramente batch para operações online, um dos maiores medos era exatamente este:
"E se o sistema cair no meio de uma transferência?"
Foi o amadurecimento dos mecanismos de recuperação, journals, locks e SYNCPOINT que permitiu o crescimento dos caixas eletrônicos, do internet banking e, décadas mais tarde, dos aplicativos móveis.
Cada saque em um caixa eletrônico, cada pagamento de boleto e cada transferência eletrônica dependem, direta ou indiretamente, desses princípios.
Curiosidade Técnica
Você provavelmente já ouviu falar nas propriedades ACID dos bancos de dados.
O SYNCPOINT é uma das peças fundamentais que ajuda a concretizar esses princípios dentro do ambiente transacional do CICS:
Atomicidade: tudo acontece ou nada acontece.
Consistência: os dados permanecem válidos.
Isolamento: outras transações não enxergam alterações incompletas.
Durabilidade: após o commit, as mudanças sobrevivem até mesmo a falhas do sistema.
Dicas para quem está aprendendo COBOL+CICS
✔ Sempre pense em termos de negócio, não apenas de comandos.
✔ Antes de programar pergunte:
"Se ocorrer um erro aqui... o que deve voltar?"
✔ Nunca esqueça que REWRITE não significa commit.
✔ Aprenda a visualizar uma Unit of Work inteira antes de escrever uma linha de código.
✔ Conheça RESP e RESP2 para tratar erros antes de decidir entre continuar ou executar um rollback.
✔ Estude os journals e os mecanismos de recuperação. Eles raramente aparecem nos primeiros cursos, mas fazem enorme diferença para compreender como o CICS realmente funciona.
Easter Egg Bellacosa ☕
Existe uma antiga lenda entre programadores veteranos de mainframe.
Dizem que, nas madrugadas em que o CPD está silencioso e apenas o z/OS continua trabalhando, é possível imaginar um enorme carimbo invisível passando de transação em transação.
Cada vez que um SYNCPOINT é executado com sucesso, esse carimbo marca silenciosamente:
"Integridade preservada."
Ninguém vê.
Nenhum operador escuta.
Nenhuma tela 3270 exibe essa mensagem.
Mas, graças a esse "carimbo invisível", milhões de pessoas acordam pela manhã e encontram seus saldos bancários exatamente onde deveriam estar.
Talvez esse seja o maior elogio que uma tecnologia possa receber: funcionar tão bem que quase ninguém percebe sua existência.
Cúmplices: Journals, Locks, Unit of Work, Resource Managers
Veredito Final: Nenhuma transação recuperável deve terminar pela metade.
Conclusão
O SYNCPOINT é muito mais do que um simples comando do CICS. Ele representa a fronteira entre o provisório e o permanente, entre uma alteração ainda reversível e uma decisão definitiva. É ele quem encerra a Unit of Work, confirma atualizações em recursos como Db2, VSAM, filas recuperáveis e outros gerenciadores de recursos, libera bloqueios e garante que todas as partes da transação caminhem juntas.
Seu contraponto, o SYNCPOINT ROLLBACK, oferece ao sistema a capacidade de voltar atrás quando algo inesperado acontece, preservando a integridade dos dados e evitando inconsistências que poderiam comprometer operações críticas.
Quando um programador COBOL entende verdadeiramente conceitos como READ UPDATE, REWRITE, ENQ, DEQ, HANDLE ABEND, journals, locks, Unit of Work e SYNCPOINT, ele deixa de apenas escrever programas e passa a compreender a engenharia invisível que mantém bancos, seguradoras, companhias aéreas e grandes empresas funcionando de forma confiável há décadas.
No fim das contas, o maior mistério do CICS nunca foi sua velocidade, nem sua idade, nem mesmo sua capacidade de processar milhões de transações por segundo.
O verdadeiro mistério é que, enquanto o mundo dorme, um pequeno comando com apenas nove letras continua decidindo, silenciosamente, o destino de fortunas, contratos, reservas de voo, prontuários médicos e incontáveis operações críticas.
E como diria Augusto Bellacosa ao terminar mais uma xícara de café diante do brilho esverdeado de um terminal 3270:
"Programas escrevem dados. Transações escrevem confiança. E confiança... sempre termina com um SYNCPOINT."
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?”
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
