✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe 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.
🖥️📚 William Gibson: o sysprog que escreveu o futuro antes do IPL ao estilo Bellacosa Mainframe — apresentação para profissionais de mainframe
🔹 Quem é William Gibson (para quem vive de sistema crítico)
William Ford Gibson, nascido em 17 de março de 1948, nos Estados Unidos e radicado no Canadá, não é apenas um escritor de ficção científica. Ele é o analista de requisitos do mundo digital moderno — aquele cara que nunca viu a tela final do sistema, mas descreveu exatamente como ela funcionaria.
Gibson escreveu sobre redes globais, identidades digitais, vigilância, corporações transnacionais e usuários plugados em sistemas quando a maioria ainda brigava com cartões perfurados e terminais burros.
🔹 Breve biografia (batch cronológico)
🗓️ 1948 – Nasce na Carolina do Sul
⚡ Juventude errante, influência da contracultura, paranoia política e isolamento social
🇨🇦 Muda-se para o Canadá para fugir do alistamento da Guerra do Vietnã
📚 Estuda literatura, mas sempre observando tecnologia como outsider
🖊️ 1984 – Publica Neuromancer e reinicia o sistema do planeta
🔹 Carreira (ou: quando o terminal ganhou alma)
Neuromancer (1984): criou o termo ciberespaço antes da internet comercial existir
Count Zero e Mona Lisa Overdrive: completam a trilogia Sprawl
Influenciou diretamente: Matrix, Blade Runner (estética), Ghost in the Shell, hackers reais, designers de rede e arquitetos de sistemas
📌 Curiosidade mainframe: Gibson nunca foi um entusiasta técnico. Ele observava tecnologia como um operador desconfiado olhando logs.
🔹 Filosofia Gibsoniana (manual não oficial)
“O futuro já chegou. Só não está igualmente distribuído.”
Para um mainframer, isso soa familiar: sistemas críticos sempre estiveram no futuro enquanto o resto do mundo brincava com GUI.
Gibson entende que:
Tecnologia não liberta, ela reorganiza poder
Usuários viram extensões do sistema
Corporações são ambientes operacionais fechados
🔹 Curiosidades & fofocas de datacenter
Gibson escreveu Neuromancer numa máquina de escrever
Ele tinha medo de computadores quando inventou o ciberespaço
Odeia ser chamado de “profeta”
Nunca acreditou que a internet seria “libertadora”
🤫 Fofoquice: enquanto o Vale do Silício vendia utopia, Gibson já via batch jobs sociais esmagando gente comum.
🔹 Dicas de leitura (ordem recomendada para mainframer)
Neuromancer – arquitetura base
Count Zero – integrações corporativas
Mona Lisa Overdrive – legado fora de controle
Pattern Recognition – TI sem sci-fi, só observação fria
🔹 Comentário final Bellacosa
William Gibson é leitura obrigatória para quem trabalha com sistemas que não podem cair. Ele ensina que todo sistema técnico cria um sistema humano paralelo — e geralmente mais perigoso.
🖥️ Se você mantém um mainframe em pé, já vive num mundo que Gibson descreveu. MAINFRAME MODE: ATIVO.
Trilogia Sprawl (ou Trilogia Neuromancer)
Esta é a trilogia que definiu o gênero cyberpunk.
Neuromancer (1984)
Count Zero (Count Zero: História Zero no Brasil) (1986)
Mona Lisa Overdrive (1988)
Trilogia da Ponte (ou Bridge Trilogy)
Virtual Light (Luz Virtual no Brasil) (1993)
Idoru (1996)
All Tomorrow's Parties (Todas as Festas de Amanhã no Brasil) (1999)
Ciclo Blue Ant (ou Bigend Trilogy)
Pattern Recognition (Reconhecimento de Padrões no Brasil) (2003)
Spook Country (Território Fantasma no Brasil) (2007)
Pensamentos sobre marcas e costumes, deixo aqui um dump consciente, daqueles feitos sem o acompanhamento de nectar dos deuses, sem mask, sem compress e com RC=verdade.
Sabe uma coisa que me incomoda há tempos — e curiosamente só cresce a cada ano que passa? Essa necessidade quase compulsiva de ostentar uma marca X ou Y. Não o produto em si, mas o logotipo, o selo, a chancela visual que grita mais alto que qualquer qualidade real. E que muitas vezes nem é original, sendo uma copia feita por alguma oficina obscura ou importado no contrabando da China.
O mais irônico é que, na maioria das vezes, o produto é o mesmo, encontrado em lojas do Brás em São Paulo, mas marca branca. Mesma matéria-prima, mesma linha de produção, muitas vezes fabricado em algum subúrbio pobre, por trabalhadores terceirizados, quarteirizados, invisíveis no job stream da sociedade. A diferença acontece depois: passa por uma sequência de checkpoints, recebe um símbolo da moda, uma etiqueta charmosa, e pronto. Está autorizado a custar dez vezes mais em uma vitrine climatizada de shopping center.
É como pegar um programa COBOL velho de guerra, rodando firme há 40 anos, renomear o módulo, trocar o cabeçalho, colocar uma splash screen bonita e vender como next-gen. A lógica é a mesma, o core é o mesmo, mas o marketing transforma aquilo em fetiche.
No meio desse processo, vamos perdendo algo mais sério: nossa identidade cultural. Vestimos roupas desenhadas em outros países, pensadas para outras realidades, reproduzidas localmente em escala industrial. Antigamente, comprávamos um item pela durabilidade, pelo tecido, pelo corte, pela confiança no fabricante. Hoje, compra-se porque uma pseudocelebridade A ou B apareceu usando aquilo por quinze segundos em um story patrocinado.
Viramos uma legião de bonecos padronizados, quase NPCs, todos vestidos de forma semelhante, ostentando símbolos cujo significado muitos sequer conhecem. Logotipos viram totens. A marca substitui o discurso. O visual vira identidade emprestada. É o VTAM da moda, conectando todo mundo ao mesmo terminal, exibindo a mesma tela.
Às vezes me pergunto: — Será que estou ficando velho e ranzinza? — Será que isso é só picuinha por biscoitos?
Pode até ser. Mas a verdade é que sempre fui avesso às modinhas. Sempre me incomodou a ideia de estar vestido igual a todo mundo, quase como se usássemos um uniforme não declarado. Nunca gostei de parecer um clone batch, gerado em massa, sem personalidade.
No meu mundo — talvez antiquado, talvez teimoso — gosto de coisas que tenham história, contexto, propósito. Prefiro algo simples, honesto, funcional, do que um rótulo gritante tentando me vender pertencimento. Pertencer, pra mim, sempre veio de ideias, conversas, memórias e valores — não de uma estampa.
Mas, enfim… é assim que caminha nossa sociedade. Cada vez mais orientada a branding, menos a conteúdo. Mais fachada, menos estrutura. Muito frontend, pouco backend.
E eu sigo aqui, meio fora do padrão, rodando meu próprio job, talvez em modo legado, mas ainda convicto de que valor de verdade não precisa de logotipo em fonte gigante para existir.
Vendo mais um ano começar, vivenciando o estilo de vida Europeu, a Dolce Vita Italiana e ao mesmo tempo vendo o mundo ruir graças a grande crise de 2008. Lojas fechadas, o numero de turistas diminuindo e uma grande nuvem cinzenta sobre o ar. Detalhe apesar de morar em Milão, costumo ir de trem até Turim, comprar roupas em lojas com preços mais acessiveis e fora das grandes e custosas marcas em Milão.
Onde tudo roda, tudo conversa, tudo dá commit… e sempre tem um rollback emocional no final.
Imagine um bar japonês tradicional… mas não um bar qualquer.
O Izakaya é o TSO onde o japonês desconecta, o SDSF onde as conversas são monitoradas entre goles, o CICS onde tudo é transacional: você pede ➝ eles entregam ➝ você confirma ➝ eles te mandam outra rodada antes de você cancelar.
É o coração noturno do Japão.
🏮 Origem: o bar que nasceu do saquê e virou tradição
A palavra Izakaya (居酒屋) significa literalmente “lugar para sentar e beber”.
Lá atrás, na era Edo (1600~1868), as lojas que vendiam saquê começaram a permitir que clientes provassem a bebida no local. Aconteceu o que sempre acontece quando misturamos "experimentar" com "fique à vontade":
👉 o japonês puxou uma cadeira
👉 sentou
👉 pediu petisco
👉 e nunca mais saiu
Pronto. Nasceu o Izakaya.
🍢 Dicas (no estilo ‘consultor de infraestrutura que chegou cedo demais no happy hour’)
✔ Vá com fome: é petisco atrás de petisco.
✔ Vá com amigos: izakaya é protocolo multiusuário.
✔ Prove o karaage: frango frito japonês — o “JCL bem escrito”: sempre funciona.
✔ Cuidado com o shochu: parece leve… NÃO É.
✔ Aprenda a pedir o otooshi: uma entradinha obrigatória — tipo o JOBLIB do jantar.
🤫 Fofoquices e Bastidores (aquele dump de produção)
Muitos empresários japoneses fecham contratos DE VERDADE em izakayas — os escritórios são para negociar, o izakaya é para decidir.
Os funcionários muitas vezes vão direto do trabalho para o izakaya, sem passar em casa. Conhecido como “nomikai culture” — a RFC social dos japoneses.
Há izakayas de tema, como “izakaya hospital”, “izakaya prisão” ou até o famoso Izakaya de Yokai, onde os garçons se vestem como criaturas folclóricas.
Em Tóquio existe um izakaya que serve exclusivamente comidas citadas em animes. O menu tem até yakisoba do Naruto.
🧨 Easter Eggs (aquele abend S0C7 cultural que você nem viu chegando)
O izakaya aparece em praticamente TODO anime slice-of-life envolvendo adultos: de Shirobako a Wotakoi.
O termo “Toriaezu nama!” significa “uma cerveja, pra começar!”. É tipo o IEFBR14 do japonês — serve só pra iniciar o job.
Alguns izakayas tradicionais exibem noren (cortinas na porta) com Kanji antigos. A cor e o desgaste do tecido contam quantas décadas o bar aguentou gente bebendo.
🍺 Izakayas famosos (que valem XP extra no seu mapa otaku)
⭐ 1. Torikizoku (とりきぞく) — o "SPU baixo custo"
Cadeia gigantesca, tudo custa o mesmo preço.
Ideal para quem está com o orçamento que nem storage cheio.
⭐ 2. Gonpachi — o “Kill Bill Izakaya”
Sim, aquele onde Tarantino se inspirou para a cena icônica.
Tem em Tóquio. Turístico? Sim. Legal? Também.
⭐ 3. Omoide Yokocho (Shinjuku) — o BATCH JES2 do Japão
Um becão apertado com dezenas de micro-izakayas.
Cada um parece um job rodando na mesma fila.
Pequeno. Quente. Lotado. Perfeito.
⭐ 4. Golden Gai — o CICS cluster da madrugada
Barezinhos minúsculos, cada um com tema e donos excêntricos.
Ideal para encontrar músicos, escritores, atores e programadores rodando jobs pessoais em modo CMODE.
👺 Personagens típicos de Izakaya (versão anime/empresa)
O Chefe Cabisbaixo: sempre pedindo desculpas e cerveja.
O Estagiário que bebe demais: desaparece no slide do próximo dia.
O Samurai de Terno: aquele japonês sério até tomar o 3º saquê.
A “Onee-san” do balcão: atenciosa, rápida e mais eficiente que qualquer exit do MVS.
✨ Truque do veterano
Se você quer parecer japonês de verdade:
Nunca levante seu copo antes do brinde.
Espere alguém dizer: “Kanpai!”
Só aí você confirma o commit.
🗾 Se eu, Bellacosa, tivesse que indicar alguns…
📌 Izakaya Shinjuku Kenka-ya — onde a comida é boa e os clientes discutem filosofia às 2h.
📌 Ebisu Yokocho — izakayas multicoloridos que parecem dungeon de JRPG.
📌 Nagoya’s Yakitori Alley — o cheiro te hipnotiza; você esquece até do JES2.
📌 Osaka’s Hozenji Yokocho — tradicional, poético, com lanternas penduradas como se fosse o SPOOL iluminado.
🔚 Fechando a conta…
O Izakaya é onde o Japão tira o paletó da formalidade e vira gente de verdade.
É onde o DBA vira poeta, o PM vira filósofo, o analista ABEND vira contador de histórias…
E você percebe que, como no mainframe, a magia vem da comunidade, não da máquina.
Quando você entrar num izakaya, lembre-se: Você está entrando no modo IMS conversacional da alma japonesa.
