✨ 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
🍜 Gochisō-sama! — Onomatopeias japonesas à mesa, analisadas por um mainframeiro curioso
Quem assiste anime com atenção (e sem pular opening, porque isso é pecado 😄) já percebeu: comer no Japão não é silencioso. Pelo contrário. É barulhento, expressivo, quase um log de execução em tempo real. E aí entram elas: as onomatopeias japonesas, aquelas palavrinhas mágicas que traduzem som, sensação, textura e até emoção — algo que a nossa língua tenta, mas raramente alcança.
No Japão, comer não é só nutrir o corpo. É experiência sensorial, e as onomatopeias são o CICS TRACE do paladar.
🍜 1. ZURU-ZURU (ずるずる) — O som sagrado do macarrão
Como se escreve: ずるずる Como se usa: “Zuru-zuru taberu” O que significa: Som de puxar macarrão, lámen ou udon
Essa é clássica. O barulho de sugar o macarrão não é falta de educação, é elogio ao cozinheiro. Quanto mais zuru-zuru, mais gostoso está.
🎬 Animes:
Naruto — Naruto Uzumaki no Ichiraku Ramen
Gintama — praticamente um festival de zuru-zuru
Food Wars (Shokugeki no Soma) — close sonoro garantido
💡 Curiosidade: sugar o macarrão ajuda a esfriar e realçar o sabor. É engenharia térmica aplicada à culinária.
paku paku
🍖 2. PAKU-PAKU (ぱくぱく) — Comer com vontade
Como se escreve: ぱくぱく Uso: “Paku-paku taberu” Significado: Comer repetidamente, com fome ou entusiasmo
É aquele personagem que está faminto, devora tudo rápido, quase sem respirar.
🎬 Animes:
One Piece — Luffy é praticamente o mascote do paku-paku
My Neighbor Totoro — crianças comendo felizes
🥚 Easter egg:Paku-paku também descreve bocas abrindo e fechando — tipo peixinhos. Simples, visual, japonês até o osso.
mogu mogu
🍙 3. MOGU-MOGU (もぐもぐ) — Mastigação feliz
Como se escreve: もぐもぐ Uso: “Mogu-mogu shiteru” Significado: Mastigar calmamente
Essa é quase um ASMR linguístico. Indica alguém comendo concentrado, satisfeito, em silêncio respeitoso.
🎬 Animes:
K-On! — cenas de lanche são puro mogu-mogu
Yuru Camp — comida + paz = mogu-mogu zen
💡 Dica cultural: usado até em personagens tímidos, que comem sem falar. Comunicação sem palavras.
saku saku
🍰 4. SAKU-SAKU (さくさく) — Crocância perfeita
Como se escreve: さくさく Uso: “Saku-saku shiteru” Significado: Algo crocante e leve
Tempurá, tonkatsu, biscoitos. Se está saku-saku, está no ponto.
🎬 Animes:
Food Wars — descrição técnica + poesia
March Comes in Like a Lion — doces tradicionais
🥢 Curiosidade: o japonês tem dezenas de palavras só para textura. Nós dizemos “crocante”. Eles fazem firmware dedicado.
toro toro
🍡 5. TORO-TORO (とろとろ) — Cremoso, derretendo
Como se escreve: とろとろ Uso: “Tamago ga toro-toro” Significado: Macio, cremoso, quase líquido
Ovo com gema mole, curry, ensopados longamente cozidos.
🎬 Animes:
Oishinbo — tratado acadêmico da culinária
Food Wars — câmera lenta + toro-toro
💡 Bellacosa insight:toro-toro é o oposto de batch rígido. É processamento suave, em fluxo contínuo.
goku goku
🍺 6. GOKU-GOKU (ごくごく) — Beber com sede
Como se escreve: ごくごく Uso: “Biiru o goku-goku nomu” Significado: Beber grandes goles
Depois do trabalho, do treino ou da batalha contra demônios.
🎬 Animes:
Dragon Ball — Goku bebendo qualquer coisa
Salaryman Kintaro
🍶 Easter egg: aparece muito em propagandas japonesas. Marketing sonoro puro.
umai umai
😋 7. UMA! / UMAI! (うま！ / うまい！) — O veredito final
Significado: “Delicioso!”
Curto, direto, sincero. É o return code 0 da refeição.
🎬 Animes:
Naruto
Demon Slayer — Tengen Uzui é um festival de exageros
🍱 Conclusão — Comer também é linguagem
No Japão (e nos animes), comer é narrado em som. As onomatopeias funcionam como logs detalhados do prazer gastronômico. Não é infantil, é sofisticado. É quase um JCL do paladar, onde cada etapa da experiência é registrada.
Da próxima vez que você ouvir um zuru-zuru ou um mogu-mogu, não estranhe. Sorria. Você está ouvindo cultura, história e emoção — tudo servido numa tigela fumegante.
E como diria qualquer personagem depois da refeição:
🖥️🤖🎬 WESTWORLD (1973/1978): quando o parque temático vira ambiente produtivo
Antes de IA generativa, antes de machine learning virar buzzword, Michael Crichton já rodava simulações perigosas. Westworld nasce como filme em 1973, escrito e dirigido por Crichton, e ganha romance em 1978, quando o autor transforma o roteiro em literatura técnica disfarçada de ficção. Aqui não existe “se”: existe quando o sistema sai do controle.
🧠 A história (ou: quando o batch não encerra)
Em Westworld, turistas ricos visitam parques temáticos hiper-realistas povoados por androides — versões humanas de NPCs programados para nunca ferir clientes. Velho Oeste, Roma Antiga, Idade Média. Escolha o ambiente, rode o cenário, consuma a experiência.
O problema começa quando pequenas falhas se acumulam. Nada explode de imediato. Primeiro, um comportamento estranho. Depois, um atraso na resposta. Até que o sistema simplesmente não aceita mais comandos administrativos.
📌 Mainframe insight: todo desastre começa com um warning ignorado.
📚 Filme vs Livro (diferença de arquitetura)
🎬 Filme (1973): direto, seco, quase documental. O terror vem da frieza técnica.
📘 Livro (1978): expande o pensamento sistêmico, o medo do complexity creep e a arrogância corporativa.
Ambos tratam os androides não como vilões, mas como processos que executam exatamente o que foram projetados para fazer.
🧩 Ideias centrais (Crichton em estado puro)
Sistemas complexos não falham de forma isolada
Automação sem auditoria vira ameaça
Segurança “garantida” é apenas marketing
Humanos confiam demais em painéis verdes
“Nada pode dar errado” é a frase mais perigosa de qualquer datacenter.
🤖 O pistoleiro (Yul Brynner)
O androide pistoleiro é um daemon imortal. Ele não se cansa, não hesita, não questiona. Ele não odeia. Ele executa.
🥚 Easter egg histórico: seu visual inspirou diretamente o T-800 de Exterminador do Futuro.
🤫 Fofoquice: Brynner aceitou o papel justamente por parecer “anti-humano”.
🥚 Curiosidades técnicas
Westworld foi um dos primeiros filmes a usar imagem digital processada por computador
A falha do parque é explicada como efeito cascata, conceito raro no cinema da época
O centro de controle parece mais um NOC do que uma sala de vilões
☕ Dicas de leitura e exibição (modo operador)
Observe como ninguém entende o sistema por completo
Repare no desdém da gerência pelos técnicos
Preste atenção no excesso de confiança
Compare com incidentes reais de TI
🧠 Filosofia oculta (o verdadeiro bug)
Westworld não é sobre robôs assassinos. É sobre governança. Sobre criar sistemas que funcionam tão bem que ninguém mais sabe desligá-los.
Crichton nos alerta:
Complexidade cresce mais rápido que controle
Segurança absoluta não existe
Humanos terceirizam responsabilidade para máquinas
🖥️ Comentário final Bellacosa Westworld é obrigatório para todo profissional que trabalha com sistemas críticos, automação ou IA. Porque no fim, o perigo não é o androide ganhar consciência — é o humano perder a sua.
(por Bellacosa Oni, sobrevivente do chinelo voador e degustador profissional de leite em pó)
Existem memórias que não moram num endereço fixo.
Elas estão espalhadas por todos os lugares onde crescemos — nas casas que alugamos, nas salas onde brincamos, nos quintais onde aprontamos, nos corredores onde corríamos para escapar do chinelo justiceiro.
E uma dessas memórias é tão insistente, tão viva, tão doce quanto o próprio protagonista dessa história: o Leite Ninho dos anos 1970/1980.
Sim, Jefe… hoje eu vou te contar sobre as aventuras clandestinas dos 3 Onis peraltas e seu vício proibido.
🍼 Quando o leite estragava… e a tentação começava
Naquela época, antes da revolução do Tetra Pak, leite de padaria virava queijo em 48 horas.
Minha mãe, sempre prática e visionária (como toda boa sysadmin da vida doméstica), tinha a solução:
Leite em pó. Mas não qualquer leite. O Leite Ninho.
Era ouro branco.
Era tesouro de faraó.
Era o upgrade supremo da época.
E, para tristeza da autoridade parental, era também…
um convite à contravenção infanto-oni.
Porque, Jefe:
Uma lata de Leite Ninho aberta era como uma DSN sem password.
🍯 O subuso secreto: a massinha dos deuses
O manual oficial dizia:
“Adicionar duas colheres e misturar com água.”
Mas os Onis sabiam a verdade oculta:
O jeito mais gostoso era não adicionar nada.
Só a colher.
Direto na boca.
Deixar dissolver devagar, como se a vida fosse feita de pequenas felicidades granuladas.
E quando a criatividade batia?
Aí entrava a alquimia proibida:
Leite Ninho
Açúcar
Chocolate do Padre (sim, aquele da lata preta, o chefão final das sobremesas de infância)
Misturávamos tudo até virar uma massinha doce e pegajosa, digna de festa de aniversário clandestina.
Era ilegal?
Era imoral?
Era calórico?
Sim.
Sim.
ABSURDAMENTE.
Mas também era… perfeito.
🔊 O maior inimigo: o barulho do “PLOC”
Porque, Jefe, a lata do Leite Ninho tinha personalidade.
Ela era uma espécie de NPC vigilante da casa.
Abrir a tampa produzia um som que ecoava por dimensões paralelas:
PLOC!
E lá ia o vácuo estourando como sirene.
Podia ser 3 da tarde ou 3 da manhã.
Uma coisa era certa:
Se a lata fez “ploc”, algum adulto ouviu.
E aí começava o protocolo ninja-oni:
Uma colherada rápida.
Uma corrida em velocidade warp.
Esconderijo estratégico atrás da mesa.
Limpar o bigode branco para não deixar evidências.
Rezar para o chinelo não ser invocado no modo boomerang.
👡 O terror absoluto: o grito que precedia o chinelo
Existem palavras que marcam o DNA da infância.
No meu caso, era uma só:
“VAGNER-R-R-R-R!”
Era como se a casa inteira tremesse.
As cortinas balançavam.
As galinhas do vizinho silenciavam.
E eu sabia que o barulho do “PLOC” tinha sido rastreado, logado e auditado.
Sim, o chinelo vinha.
Sim, ardia.
Sim, fazia parte da vida.
Sim, eu repetia tudo de novo na semana seguinte.
Porque, convenhamos…
Aquela colherada de Leite Ninho dissolvendo na boca valeu cada byte de castigo.
🥣 O dulcíssimo pós-crédito
Hoje, adulto, analista, professor, Bellacosa Mainframe, viajante do tempo e sobrevivente do tigrão havaiana…
ainda compro Leite Ninho.
E cada colherada — sem água, sem receita, sem nada —
me devolve por alguns segundos aos tempos dos três Onis:
correndo pela casa
inventando culinária proibida
vivendo perigosamente
sentindo o mundo girar ao som de um simples ploc
Alguns sabores não pertencem ao paladar.
Pertencem à alma.
E o Leite Ninho…
ah, Jefe…
esse é puro firmware da infância.
quarta-feira, 1 de fevereiro de 2012
Otsuten: O Santuário Onde o Profano Beija o Sagrado
Um mergulho Bellacosa Mainframe para o blog El Jefe Midnight Lunch
Quando o Japão resolve criar um santuário, ele não constrói apenas um templo — ele ergue um lore, um universo expandido, um portal cultural onde história, mitologia, urbanismo e um toque de maluquice coexistem em harmonia.
E entre os muitos templos que fazem o Japão ser esse RPG de mundo aberto chamado Japão, existe um que virou febre entre jovens, otakus, turistas espirituais e influenciadores: Otsuten — às vezes chamado de Otsu Tenmangu, outras vezes apelidado de “o santuário que realiza desejos… mas só se você não for afobado”.
Hoje, no estilo Bellacosa Mainframe para o El Jefe Midnight Lunch, vamos destrinchar esse fenômeno espiritual-pop-cultural com história, curiosidades, folclore, easter-eggs e aquele toque investigativo que faria até o CICS levantar uma sobrancelha.
1. Origem: Onde Começa o Código-Fonte do Otsuten
O Otsuten é um santuário xintoísta dedicado, como muitos da mesma linhagem, a Sugawara no Michizane, patrono da sabedoria, caligrafia, estudos e… vingança educada (sim, ele virou um kami depois de morrer injustiçado e causar tempestades até receber seu devido reconhecimento).
Otsuten, porém, ganhou fama mais recente graças a três fatores:
Proximidade com rotas de estudantes indo para exames importantes;
História oral sobre pedidos que “só funcionam se feitos com calma e sinceridade” (quase um timeout ajustado no JCL espiritual);
Internet, que fez nascer o “Otsuten Challenge”.
E aqui começa o mix de tradição + viralização que só o Japão sabe produzir.
2. Estrutura e Simbologia: O Santuário Que Parece um Save Point
O Otsuten é famoso por seu torii vermelho vibrante, um portão tão icônico que virou ponto de selfie obrigatório.
Abaixo, a tríade sagrada do Otsuten:
Torii Vermelho: segundo o folclore local, quanto mais forte a cor, mais forte o pedido entra no “mainframe divino”.
A Pedra de Acalmar o Coração: uma rocha polida onde estudantes tocam para “resetar o nervosismo”.
O Caminho do Silêncio: um corredor estreito entre árvores antigas onde ninguém deve falar — se falar, perde o buff.
Easter-egg: dizem que, à noite, o caminho do silêncio produz eco mesmo quando ninguém pisa ali.
Debug espiritual? Talvez.
3. Cultura Pop: Otsuten Como Cenário de Anime, Dorama e Mangá
O local ficou famoso por aparições discretas em produções:
Uma versão estilizada aparece em Kyou no Go no Ni.
O torii foi recriado (quase idêntico) em um episódio de Bungou Stray Dogs, referência ao próprio Michizane.
Muitas VN, especialmente as de romance colegial, usam o modelo do torii como cenário de “confissões”.
Easter-egg cultural: vários gacha games japoneses adicionaram amuleto de Otsuten como item de buff para “sorte em summons”.
4. A Experiência: Como Funciona a “Interface Sagrada”
Visitar o Otsuten segue o protocolo tradicional:
Passar pelo torii com respeito;
Fazer purificação na fonte;
Soar o sino;
Fazer o pedido em silêncio;
Amarrar um ema com o desejo escrito.
Mas o Otsuten tem um twist:
➤ O pedido deve ser reescrito três vezes — como se fosse SUBMIT, HOLD e RELEASE.
Sim. É sério.
Dizem que isso “estabiliza” o desejo para que o kami entenda sua intenção.
5. Curiosidades no Estilo Bellacosa Mainframe
A cor do torii já foi laranja, mas foi repintado após uma pesquisa viral dizer que o “vermelho forte aumenta 12% a chance do pedido funcionar”. Zero base científica, mas muito marketing espiritual.
O Otsuten já recebeu mais de 100 mil pedidos digitalizados por turistas que escanearam seus emas (porque claro que alguém criou um OCR de desejos).
Existe um ritual moderno chamado “ping-bell”: bater o sino duas vezes e mandar mensagem para um amigo desejando boa sorte.
Amuletos especiais para programadores são vendidos lá, com o kanji de “erro” cortado ao meio — para simbolizar debug divino.
6. Problemas, Polêmicas e Lendas Urbanas
Nenhum lugar místico moderno escapa do lado B:
❖ Polêmica da fila de selfies
Turistas transformaram o torii em estúdio fotográfico, criando discussões entre visitantes sérios e influencers.
❖ Amuletos pirateados
Sim, existe mercado paralelo de omamori falsificados, vendidos em Shibuya e Akihabara.
❖ Lenda do “pedido rejeitado”
Dizem que, se você mentir no pedido ou fizer sem convicção, uma brisa gelada passa por trás do seu pescoço — “o kami te deslogou”.
7. O Easter-Egg Supremo: A Runa Oculta na Base do Torii
Essa é para os arqueólogos de cultura pop:
Na base direita do torii existe um pequeno símbolo, quase invisível, que alguns estudiosos identificam como um antigo caractere grego estilizado.
Teorias:
Homenagem a um arquiteto estudante de filologia;
Um charme para proteção contra espíritos ocidentais;
Apenas decoração.
A comunidade geek jura que é uma referência secreta a RPGs de mesa dos anos 80.
8. Conclusão: Otsuten Como “Mainframe Espiritual do Japão”
O Otsuten não é apenas um santuário.
É um hub cultural, um servidor de desejos, um checkpoint emocional para estudantes, românticos, sonhadores e curiosos.
Ele mistura:
tradição xintoísta,
cultura pop,
estética instagramável,
lendas urbanas,
e aquele je ne sais quoi japonês que transforma um templo em fenômeno global.
Se você for visitar, lembre-se:
No Otsuten, tudo funciona melhor quando você faz com calma.
Sem pressa, sem barulho, sem gambiarras.
Como um bom submit no mainframe.
Bellacosa Mainframe apresenta Job Control Language JCL
🔥 JCL – Job Control Language: o cérebro silencioso do mainframe em um mundo distribuído
☕ Midnight Lunch no CPD (ou: quando o job ainda manda)
Era hora do midnight lunch. Café requentado, luz fria do CPD, impressora 3211 cuspindo papel contínuo. O sysprog passa e solta a frase clássica:
“Não é o programa… é o JCL.”
Silêncio respeitoso. Porque todo mainframer sabe: quem controla o JCL controla o sistema.
Este artigo é sobre JCL (Job Control Language), mas com um tempero moderno: 👉 como o JCL se encaixa — e ainda ensina — no mundo das aplicações distribuídas.
🧠 O que é JCL (para quem já viveu isso, mas nunca parou pra filosofar)
JCL não é linguagem de programação. JCL é linguagem de orquestração.
Antes de:
YAML
Pipelines CI/CD
Kubernetes
Airflow
Jenkins
…já existia:
//JOBNAME JOB ...
//STEP01 EXEC ...
//DD1 DD ...
📌 JCL diz ao sistema:
O que rodar
Em que ordem
Com quais recursos
Com quais dados
Com quais limites
E como reagir a falhas
Ou seja: governança operacional pura.
🕰️ Um pouco de história (porque mainframer não vive sem contexto)
Anos 60–70: JCL nasce para controlar jobs batch
Anos 80: amadurece com JES2/JES3
Anos 90: integra-se com CICS, DB2, MQ
Anos 2000+: passa a conviver com Unix, web, cloud
Hoje: continua firme, enquanto muita stack moderna muda a cada 6 meses
💡 Curiosidade Bellacosa: Muita ferramenta “moderna” só redescobriu conceitos que o JCL já fazia bem desde o século passado.
🌐 Aplicações distribuídas explicadas para mainframers
Vamos traduzir para o dialeto JCL.
Uma aplicação distribuída é como um job com vários steps rodando fora do z/OS, em máquinas diferentes, falando por mensagens.
Analogia direta
Mundo Distribuído
Mundo JCL
Microservice
STEP bem definido
Pipeline CI/CD
Job com múltiplos EXEC
Scheduler
JES
Retry automático
RESTART
Timeout
TIME
Logs
SYSPRINT / SMF
Orquestração
JOB statement
👉 JCL foi um “orquestrador” décadas antes da palavra existir.
🧩 O JOB statement: o “manifest.yaml” do mainframe
No mundo moderno, você descreve tudo em um manifesto.
🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito
1️⃣ Introdução: quando o monólito saiu da jaula
Mainframer raiz conhece bem o monólito confiável: CICS firme, DB2 consistente, batch noturno pontual como relógio suíço. Durante décadas, aplicação distribuída era vista como “coisa de Unix instável” ou “modinha client-server”.
Mas o mundo girou. A web cresceu, o mobile explodiu, a nuvem virou padrão e, de repente, o monólito começou a ser fatiado em serviços. Nasciam as aplicações distribuídas — e com elas, novos problemas… e velhos conceitos que o mainframe já conhecia muito bem.
💡 Easter egg: se você já lidou com VTAM, MQSeries e sysplex, você já entendeu aplicações distribuídas… só não sabia o nome moderno disso.
2️⃣ O que são aplicações distribuídas (sem buzzword)
Uma aplicação distribuída é aquela em que:
O processamento ocorre em vários nós
Cada parte da aplicação pode rodar em máquinas, containers ou regiões diferentes
A comunicação acontece por rede, não por memória compartilhada
No fundo, é o velho conceito de desacoplamento, agora amplificado.
3️⃣ Paralelos diretos com o mundo mainframe 🧠
Mundo Mainframe
Mundo Distribuído
CICS Transaction
Microservice
MQSeries
Event Streaming
Sysplex
Cluster
SMF / RMF
Telemetria / Observabilidade
Abend
Exception distribuída
Batch encadeado
Pipelines assíncronos
👉 Conclusão Bellacosa: mainframers não estão atrasados — estão adiantados há 30 anos.
4️⃣ Principais desafios (spoiler: não são novos)
🔹 Latência
No mainframe, o gargalo era I/O. No distribuído, é rede + serialização + hops excessivos.
🔹 Falhas parciais
No mundo distribuído:
“Se algo pode falhar, vai falhar, mas só um pedaço.”
Isso lembra:
Regiões CICS indisponíveis
LPAR isolada
Subsystem down às 03:12 😈
🔹 Consistência
Aqui entra o famoso CAP Theorem — mas mainframer chama isso de:
“Escolher entre disponibilidade e integridade quando o caldo entorna.”
5️⃣ Conceitos essenciais que todo mainframer deve dominar
✔️ Comunicação síncrona vs assíncrona
Síncrona: REST, RPC (espera resposta)
Assíncrona: filas, eventos, fire-and-forget 👉 MQ old school total.
✔️ Escalabilidade horizontal
Escalar mais instâncias, não máquinas maiores (trauma de quem pedia upgrade de MIPS aprovado em comitê 😅)
✔️ Observabilidade
Logs
Métricas
Traces distribuídos
📌 Curiosidade: SMF foi o avô do tracing moderno.
6️⃣ Passo a passo mental para entender qualquer sistema distribuído
1️⃣ Identifique quais serviços existem 2️⃣ Veja como eles se comunicam 3️⃣ Descubra onde estão os pontos de falha 4️⃣ Analise latência e dependências 5️⃣ Verifique quem é o dono do dado 6️⃣ Observe como o sistema se comporta quando algo cai
🧨 Dica Bellacosa: desligue mentalmente um serviço e pergunte “O que quebra primeiro?”
7️⃣ Guia de estudo para mainframers curiosos 📚
Conceitos
Microservices vs Monólito
Event-driven architecture
Observabilidade
Resiliência e retries
Ferramentas modernas (com alma antiga)
Instana / Dynatrace → RMF da nuvem
Prometheus → SMF open source
Kafka → MQSeries com esteroides
Kubernetes → Sysplex com YAML
8️⃣ Aplicações práticas no dia a dia
Integrar mainframe com APIs modernas
Expor transações CICS como serviços
Monitorar ambientes híbridos
Diagnosticar falhas ponta a ponta
Atuar como tradutor cultural entre legado e cloud
🎯 Mainframer que entende distribuído vira peça-chave.
9️⃣ Comentário final (meia-noite, café frio ☕)
Aplicações distribuídas não são o fim do mainframe. São apenas o mesmo problema antigo, rodando em mais lugares, com nomes novos e menos disciplina.
Quem sobreviveu a:
Batch quebrado em fechamento
Deadlock às 02h
Região CICS instável em dia útil
…tem todas as credenciais para dominar o mundo distribuído.
🖤 El Jefe Midnight Lunch aprova: legado não é atraso — é memória de guerra.
Bellacosa Mainframe Style — Guia definitivo para Padawan CICS
Os comandos de gerenciamento do IBM CICS são o coração operacional do ambiente transacional em mainframe. Diferentemente dos comandos EXEC CICS, usados dentro de programas COBOL, PL/I ou assembler, os comandos de gerenciamento são transações interativas, executadas diretamente no terminal 3270, com foco em administração, diagnóstico e controle em tempo real do sistema.
Esses comandos surgiram para dar autonomia ao operador e ao analista, permitindo gerenciar recursos sem reiniciar o CICS ou recorrer a JCL. O principal deles é o CEMT (CICS Execute Master Terminal), usado para consultar e alterar o estado de tarefas, programas, arquivos, transações e conexões. Já o CEDA (CICS Execute Definition) permite definir e instalar recursos no CSD (CICS System Definition), funcionando como um catálogo central de configurações. O CECI é voltado a testes, permitindo executar comandos EXEC CICS de forma interativa, enquanto o CEDF atua como ferramenta básica de depuração, interceptando chamadas EXEC CICS durante a execução de programas.
Outros comandos importantes incluem o CESN (login e segurança), CEOT (reset de sessão), CEBR (navegação em arquivos VSAM) e CEVT (controle de eventos temporizados). Em conjunto, esses comandos transformam o CICS em um ambiente altamente controlável, onde estabilidade, disciplina e observabilidade são valores centrais — características que explicam sua longevidade em sistemas críticos até hoje.
Antes de existir DevOps, Kubernetes ou observabilidade, o CICS já tinha seu próprio painel de controle Jedi: as transações de gerenciamento, executadas direto no terminal 3270.
Elas não são EXEC CICS, são comandos operacionais — a diferença entre programar e governar o império.
🧠 O que são comandos de gerenciamento do CICS?
São transações especiais, quase sempre iniciadas com CE ou CM, usadas para:
administrar recursos
diagnosticar problemas
testar comandos
depurar programas
controlar o runtime
📌 Insight Bellacosa:
EXEC CICS é para o código. CEMT é para quem manda.
Comando CEMT
🔹 1️⃣ CEMT — CICS Execute Master Terminal
O CEMT (CICS Execute Master Terminal) é o principal comando de gerenciamento do IBM CICS, usado para monitorar e controlar recursos em tempo real a partir do terminal 3270. Com ele, o operador ou analista pode consultar (INQUIRE) e alterar (SET) o estado de tarefas, programas, arquivos, transações, terminais e conexões, sem reiniciar o sistema. Criado para dar autonomia operacional, o CEMT permite ações críticas como NEWCOPY de programas, cancelamento de tasks presas e verificação de uso de recursos. É uma ferramenta poderosa, rápida e perigosa: um comando mal aplicado pode impactar produção instantaneamente. Dominar o CEMT é passo essencial para qualquer profissional CICS.
📟 O console supremo
📜 História
Criado para substituir comandos internos e dar controle online do CICS.
🔧 Para que serve
Ver e alterar status de:
Tasks
Programs
Files
Transactions
Terminals
Connections
🧪 Exemplo (Padawan)
CEMT I TASK
CEMT I PROG(DMCPGM01)
CEMT SET PROG(DMCPGM01) NEWCOPY
💡 Dicas
I = INQUIRE
SET muda o estado em produção 😈
🥚 Easter egg: CEMT I TASK já derrubou mais produção que bug em COBOL mal testado.
Comando CEDA
🔹 2️⃣ CEDA — CICS Execute Definition
O CEDA (CICS Execute Definition) é o comando de gerenciamento do CICS responsável por definir e administrar recursos no CSD (CICS System Definition). Por meio dele, o analista cria, altera, remove e instala definições como PROGRAM, TRANSACTION, FILE, MAPSET e DB2ENTRY, sem necessidade de JCL. O CEDA separa conceito de execução: definir não é instalar, sendo necessário o comando INSTALL para ativar o recurso no ambiente. Criado para dar flexibilidade e padronização ao CICS, o CEDA é essencial para mudanças controladas. Seu uso correto garante consistência, rastreabilidade e estabilidade em ambientes transacionais críticos.
📚 O catálogo de schemas do CICS
📜 História
Criado para definir recursos sem JCL.
🔧 Para que serve
Definir recursos no CSD:
PROGRAM
TRANSACTION
FILE
MAPSET
DB2ENTRY
🧪 Exemplo
CEDA DEF PROGRAM(DMCPGM01)
CEDA INS TRAN(DMC1)
CEDA INSTALL
💡 Dicas
Definir ≠ Instalar
Só vira realidade após INSTALL
🥚 Easter egg: Já existia Infrastructure as Data antes do YAML virar moda.
Comando CECI
🔹 3️⃣ CECI — CICS Execute Command Interpreter
O CECI (CICS Execute Command Interpreter) é o comando de gerenciamento do CICS usado para testar comandos EXEC CICS de forma interativa, sem escrever ou compilar programas. Ele permite simular operações como READ, WRITE, LINK, SEND e RECEIVE, facilitando aprendizado, validação e diagnóstico rápido de problemas. Criado como laboratório do CICS, o CECI é muito utilizado por iniciantes e analistas experientes para entender o comportamento dos recursos em tempo real. Apesar de ser uma ferramenta didática, o CECI pode alterar dados reais, exigindo cuidado em ambientes produtivos. É um recurso valioso para estudo e testes controlados.
🧪 Laboratório nuclear
📜 História
Criado para testar EXEC CICS sem escrever programa.
🔧 Para que serve
Simular comandos EXEC CICS
Testar arquivos, filas, links
🧪 Exemplo
EXEC CICS READ FILE(ARQCLI)
💡 Dicas
Ideal para aprender CICS
Pode alterar dados reais ⚠️
🥚 Easter egg: CECI é o Postman do CICS — só que mais perigoso.
Comando CEDF
🔹 4️⃣ CEDF — CICS Execution Diagnostic Facility
O CEDF (CICS Execution Diagnostic Facility) é o comando de gerenciamento do CICS utilizado para depuração básica de programas em tempo de execução. Ao ser ativado, ele intercepta cada comando EXEC CICS, permitindo ao analista acompanhar passo a passo a execução da task, visualizar parâmetros e identificar erros lógicos. Criado antes das ferramentas modernas de debug, o CEDF foi por muito tempo o principal recurso de diagnóstico no CICS. Seu uso deve ser restrito a ambientes controlados, pois pode impactar desempenho e travar sessões se esquecido ativo. Ainda hoje, é valioso para aprendizado e análise detalhada.
🐞 O debugger raiz
📜 História
Antes de Xpediter, Debug Tool… só existia o CEDF.
🔧 Para que serve
Debug passo a passo
Interceptar EXEC CICS
🧪 Exemplo
CEDF ON
💡 Dicas
Use só em ambiente controlado
Pode afetar performance
🥚 Easter egg: Todo mainframer já travou uma task esquecendo o CEDF ON.
Comando CESN
🔹 5️⃣ CESN — CICS Sign-On
O CESN (CICS Execute Sign-On) é o comando de gerenciamento do CICS responsável pelo processo de autenticação do usuário no ambiente transacional. Ele permite que o operador ou analista se identifique no CICS, integrando-se aos sistemas de segurança como RACF, ACF2 ou Top Secret. O CESN associa o usuário ao terminal, definindo permissões e controles de acesso às transações e recursos. Criado para garantir rastreabilidade e segurança, é o primeiro comando executado em muitos ambientes. Sem um sign-on válido, o usuário permanece com acesso restrito, impossibilitado de operar ou administrar o sistema.
🔐 Porta de entrada
📜 História
Integração direta com RACF/ACF2/TopSecret.
🔧 Para que serve
Login no CICS
🧪 Exemplo
CESN
💡 Dicas
Usuário ≠ terminal
Segurança manda
🥚 Easter egg: Sem CESN, você é só mais um terminal mudo.
Comando CEOT
🔹 6️⃣ CEOT — CICS End Of Task
O CEOT (CICS End Of Task) é o comando de gerenciamento do CICS utilizado para encerrar e limpar o estado de uma sessão no terminal 3270. Ele finaliza a task corrente, libera recursos associados e redefine o terminal para um estado inicial seguro. O CEOT é muito usado quando uma transação fica presa, apresenta comportamento inesperado ou após testes e depuração. Criado como mecanismo simples de recuperação, funciona como um “reset” controlado do terminal, sem afetar outras tasks do sistema. É uma ferramenta básica, porém essencial, para manter estabilidade e disciplina operacional no ambiente CICS.
🧹 Limpeza de sessão
📜 História
Criado para encerrar tasks zumbis.
🔧 Para que serve
Resetar estado do terminal
Encerrar tarefas presas
🧪 Exemplo
CEOT
🥚 Easter egg: O “Ctrl+Alt+Del” do CICS.
Comando CEST
🔹 7️⃣ CEST — CICS Start
O CEST (CICS Execute Start) é um comando de gerenciamento menos conhecido do CICS, utilizado para iniciar tarefas ou transações de forma controlada, principalmente em cenários de teste e diagnóstico. Ele permite disparar uma execução sem depender do fluxo normal de entrada do usuário, ajudando analistas a validar comportamentos específicos do sistema. Historicamente, o CEST surgiu como apoio a ambientes de desenvolvimento e verificação operacional, não sendo amplamente usado em produção moderna. Embora simples, seu uso exige cautela, pois iniciar tasks manualmente pode consumir recursos ou gerar efeitos colaterais inesperados. É um recurso auxiliar, mas útil para estudos e testes dirigidos.
🚀 Bootstrap manual
🔧 Para que serve
Iniciar transações manualmente
Testes controlados
🥚 Pouco usado, mas histórico.
Comando CEBR
🔹 8️⃣ CEBR — CICS Browse
O CEBR (CICS Execute Browse) é o comando de gerenciamento do CICS utilizado para consultar e navegar interativamente por arquivos VSAM diretamente no terminal 3270. Ele permite localizar registros por chave, avançar ou retroceder sequencialmente e visualizar o conteúdo dos dados, sendo muito útil para análise e diagnóstico. O CEBR é amplamente usado em ambientes de desenvolvimento e suporte para verificar dados sem escrever programas. Apesar de ser uma ferramenta de leitura, seu uso requer cuidado com permissões e contexto do arquivo. É um recurso clássico do CICS, simples, eficiente e valioso para entendimento dos dados em tempo real.
📂 Explorador de arquivos
🔧 Para que serve
Browse online de VSAM
Debug de dados
🥚 Easter egg: O File Explorer mais antigo ainda em produção.
Comando CEVT
🔹 9️⃣ CEVT — Event Control
O CEVT (CICS Event Control) é um comando de gerenciamento do CICS usado para controlar e testar eventos temporizados dentro do ambiente transacional. Ele permite simular condições baseadas em tempo, como atrasos, timeouts e disparo de eventos, auxiliando no diagnóstico de comportamentos assíncronos. Historicamente, o CEVT foi criado para apoiar testes de aplicações que dependem de temporização e controle interno do CICS. Embora pouco utilizado em ambientes modernos, permanece disponível para cenários específicos de estudo e validação. Seu uso exige cautela, pois eventos mal configurados podem afetar o fluxo normal das tarefas e a previsibilidade do sistema.
⏱️ Timer interno
🔧 Para que serve
Testar eventos temporizados
Pouco usado hoje, mas ainda vivo.
CICS Command Line Functions
🧠 Resumo Bellacosa Mainframe
Comando
Função
CEMT
Governo
CEDA
Definição
CECI
Teste
CEDF
Debug
CESN
Segurança
CEOT
Reset
CEBR
Dados
CEST
Start
CEVT
Eventos
🧙♂️ Conselho final ao Padawan
Aprender CICS não começa em COBOL. Começa em CEMT.
🖥️ MAINFRAME MODE ON: Quem domina os comandos de gerenciamento não pede acesso — controla o ambiente.
