✨ 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
🕯️ Poste para o Blog El Jefe Título: 🍕 A Pizza Impossível — Crônicas do Convívio no Século XXI (por Bellacosa Mainframe)
Existem guerras silenciosas que não aparecem no noticiário — e uma delas acontece todos os dias, nas mesas de restaurantes e nos grupos do WhatsApp que tentam decidir “onde vamos comer?”
Vivemos tempos em que um simples jantar virou um protocolo diplomático.
Antigamente bastava escolher a pizzaria da esquina, dividir a conta e rir das histórias. Hoje, o ato de comer juntos exige um conselho da ONU gastronômica: carnívoros, vegetarianos, veganos, intolerantes à lactose, alérgicos ao glúten, intolerantes à opinião alheia e os que simplesmente não gostam de nada.
Eu vivi isso.
Um relacionamento com núcleo misto — carnívoros, vegetarianos e veganos.
Parecia uma república unida de vontades.
Pedir uma pizza era um deploy logístico de alta complexidade, onde cada sabor exigia negociação, concessões, e em alguns casos, tratados de paz temporários.
Tínhamos noites em que o simples ato de pedir comida se transformava em debate filosófico:
– “Mas o queijo vegano tem gosto de sabão.”
– “E a sua calabresa tem gosto de culpa.”
– “Então pede metade de cada.”
– “Mas o molho é feito com mel!”
– “Mel não é vegano?”
E o relógio girando, a fome crescendo, e o senso de humor evaporando.
Em alguns dias, optávamos pela “solução prática”: cada um pegava o seu pedido num lugar diferente e depois nos reuníamos pra comer juntos.
Mas ali percebi a ironia: o ato de reunir separava.
Enquanto cada um defendia seu prato, a conversa se fragmentava, e o que era pra ser comunhão virava colagem.
🍷 Reflexão Bellacosa
Não é julgamento — é observação.
Aprendi que nem tudo precisa ser compatibilizado.
A vontade de agradar a todos, de nivelar diferenças, às vezes destrói o que há de mais humano: o simples prazer de estar junto.
Hoje, deixo o diplomata em casa e me sento com quem partilha o mesmo cardápio — não por exclusão, mas por sanidade.
Porque há momentos na vida em que é melhor saborear em paz do que mastigar tensões.
Nem toda mesa precisa ser redonda.
Nem toda refeição precisa ser um ato político.
🥢 Curiosidades e Easter Eggs Bellacosa Mainframe
🍽️ O dilema da pizza é, na verdade, uma metáfora de sistemas complexos com parâmetros incompatíveis. Em linguagem de TI, seria o mesmo que tentar rodar um programa COBOL puro num container Docker sem runtime adequado — o resultado: conflito, atraso e fome.
💡 No Japão, há um termo interessante: “kuuki yomenai” (KY) — significa “não saber ler o ar”, ou seja, não perceber o clima social. Hoje, parece que o mundo inteiro virou KY: estamos sempre interpretando errado o ambiente, o tom, o outro.
🕰️ Na Roma antiga, as refeições eram momentos de comunhão e pacto; hoje, são arenas. Mudou o menu, mas o tempero da disputa continua o mesmo.
🤖 No Mainframe da vida moderna, cada pessoa é um subsistema com APF Authorization próprio — e nem todos estão prontos para rodar no mesmo address space.
🍕 Epílogo Bellacosa
O século XXI ficou difícil, sim.
Mas talvez a solução esteja no básico:
um prato simples, uma boa conversa e o direito sagrado de comer sem precisar convencer ninguém do próprio cardápio.
No fim das contas, o sabor da liberdade é o único que serve pra todos.
👘 O Real e o Ficcional: Uniformes Escolares Japoneses nos Animes
🇯🇵 Origem Real do Uniforme de Marinheiro
Sim, as colegiais japonesas realmente usam uniformes inspirados em marinheiros — e isso vem de quase 100 anos atrás.
O modelo “sailor fuku” foi introduzido em 1920, na Fukuoka Jo Gakuin, inspirado nos uniformes navais britânicos.
A ideia era transmitir disciplina, pureza e espírito coletivo, valores centrais da educação japonesa da época.
Até hoje, muitas escolas tradicionais ainda usam esse estilo, especialmente em colégios femininos.
Mas atenção: não são todas.
Nas últimas décadas, muitas escolas migraram para uniformes tipo “blazer e gravata”, parecidos com os de escolas ocidentais.
🎌 Tipos de Uniforme no Japão Atual
Sailor Fuku (セーラー服) – Clássico de marinheiro. Blusa com gola marinha, laço ou gravata curta, e saia plissada.
Blazer Uniform (ブレザー制服) – O mais moderno e comum hoje. Blazer, camisa branca, gravata, e saia ou calça.
Gakuran (学ラン) – Uniforme masculino tradicional, preto, gola alta, botões dourados — inspirado no exército prussiano.
Casual Moderno – Escolas privadas ou internacionais permitem suéteres, cardigãs, e até tênis coloridos.
🎨 O Que é Ficção nos Animes?
Os animes romantizam e estilizam esses uniformes para dar identidade visual aos personagens.
✨ Exemplos de exageros e licenças criativas:
Saias mais curtas (na realidade, elas são bem mais longas, chegando até o joelho).
Cores vibrantes e variações fantasiosas, como golas lilás ou gravatas rosa — na vida real, as escolas seguem padrões rígidos e discretos.
Acessórios e meias altas viraram moda por causa dos animes, e não o contrário.
Uniformes idênticos em todas as estações — na vida real, há versão de verão e de inverno, com tecidos e camadas diferentes.
💡 Curiosidades Bellacosa
No Japão, o uniforme é símbolo de status e pertencimento. Muda o comportamento do aluno e é usado até fora da escola, como orgulho da instituição.
Existe até mercado de colecionadores e lojas vintage que vendem uniformes escolares originais.
O estilo "sailor" virou ícone mundial após Sailor Moon, que ressignificou o uniforme como símbolo de poder feminino e heroísmo.
Muitos artistas de anime estudam o design de uniformes reais para manter verossimilhança cultural, mas depois exageram para estilo, apelo visual e narrativa.
🧭 Dicas Para Entender Melhor nos Animes
Observe o corte e o brasão — se for fiel, o autor está retratando uma escola realista.
Uniformes muito elaborados indicam escolas de elite ou fantasia (como em Ouran High School Host Club).
Uniformes iguais entre gêneros costumam representar igualdade — algo cada vez mais comum nas escolas reais desde 2020.
Animes de época (Showa Era) geralmente mostram o gakuran e o sailor fuku tradicionais.
Séries contemporâneas, como Your Name e A Silent Voice, retratam uniformes reais, modernos e discretos.
💬 Comentário Bellacosa
O uniforme japonês é um código cultural — mistura de disciplina, estética e identidade social.
Nos animes, ele vira palco de sonhos, rebeldia e romantismo.
Enquanto na vida real simboliza ordem, no anime ele simboliza emoção.
É o mesmo tecido… mas costurado com sentimentos.
❤️ Especial aos Fãs de Cultura Escolar
Quer ver o contraste entre real e ficção? Compare Sailor Moon (romântico e colorido) com K-On! (realista e contemporâneo).
No Japão, existem cafés temáticos de colegiais, mas com forte regulamentação — o que começou como curiosidade cultural acabou virando debate ético.
O uniforme é tão icônico que até noivas japonesas já fizeram ensaios de casamento vestidas de colegiais, como tributo à juventude.
✨ Bellacosa conclui:
Entre o tecido e a fantasia, o Japão costura sua própria história — um botão de disciplina e um laço de emoção.
No fim, os uniformes dos animes não são apenas roupas… são símbolos de uma juventude que o mundo inteiro aprendeu a admirar.
Bellacosa Mainframe e o misterio das 3 portas do cics
☕ Um Café no Bellacosa Mainframe
O Mistério das Três Portas do CICS
Quando um Jovem Programador COBOL Descobriu que uma Escolha Entre LINK, XCTL e START Poderia Decidir o Destino de Milhões de Transações
"Naquela noite, o relógio marcava 02h17 da madrugada. O CPD estava silencioso. Apenas o som dos discos girando quebrava o silêncio. Um jovem programador COBOL observava um abend misterioso enquanto um velho analista, conhecido apenas como Bellacosa, aproximava-se lentamente com uma xícara de café fumegante. Sem dizer uma palavra, desenhou três portas em um bloco de papel. Sobre elas escreveu apenas três nomes: LINK. XCTL. START. 'Todo programador chega a este corredor um dia', disse ele. 'O problema é que muitos escolhem a porta errada...'."
O Caso das Três Portas
Se existe um tema que separa um programador COBOL iniciante de um desenvolvedor CICS experiente, é o entendimento do Program Control.
À primeira vista, LINK, XCTL e START parecem comandos semelhantes. Todos executam outro programa. Todos transferem controle. Todos podem utilizar COMMAREA.
Mas essa semelhança é apenas superficial.
Na prática, eles representam três formas completamente diferentes de pensar uma aplicação transacional.
É como três detetives investigando o mesmo crime usando métodos distintos.
Um faz perguntas e volta com respostas.
Outro assume a investigação inteira.
O terceiro abre um novo caso enquanto continua trabalhando no atual.
Entender essa diferença é compreender uma das peças centrais da arquitetura do CICS.
E essa história começa muito antes da primeira linha de COBOL.
O CICS Nunca Perde o Controle
O primeiro erro dos iniciantes é imaginar que um programa COBOL "chama" outro programa.
Na realidade...
Quem chama é o CICS.
Seu programa apenas faz um pedido.
Imagine um grande hotel cinco estrelas.
O hóspede não entra na cozinha.
Ele não abre a porta da lavanderia.
Ele não liga diretamente para o gerente.
Tudo passa pela recepção.
O CICS funciona exatamente assim.
Quando escrevemos:
EXEC CICS LINK PROGRAM('VALIDA')
END-EXEC.
não estamos dizendo ao computador:
Execute o programa VALIDA.
Estamos dizendo ao CICS:
"Por favor, transfira o controle para VALIDA seguindo todas as regras da arquitetura."
Isso muda completamente nossa forma de pensar.
O CICS controla:
Memória
Tasks
Locks
Arquivos
Transações
Recursos
Segurança
Recuperação
Nada acontece sem sua autorização.
O Verdadeiro Significado de "Program Control"
Program Control não significa apenas mudar de programa.
Significa administrar a vida inteira da transação.
Quem continua?
Quem termina?
Quem espera?
Quem retorna?
Quem libera memória?
Quem inicia outra task?
Essas perguntas são respondidas justamente por LINK, XCTL e START.
PRIMEIRA PORTA
LINK
Na velha revista noir, Bellacosa desenha um telefone.
"LINK", diz ele.
"É como ligar para um especialista."
Você faz uma pergunta.
Ele responde.
Você continua seu trabalho.
Nada mais.
Fluxo Mental
Programa A
↓
LINK
↓
Programa B
↓
RETURN
↓
Programa A continua
Perceba que o Programa A nunca desaparece.
Ele apenas espera.
Uma Analogia Policial
Sherlock Holmes precisa descobrir se uma assinatura é falsa.
Ele chama um perito grafotécnico.
O perito faz seu trabalho.
Entrega o laudo.
Sherlock continua a investigação.
Ele não entrega o caso ao perito.
Foi apenas uma consulta.
Esse é exatamente o espírito do LINK.
Por que LINK existe?
Porque duplicar código é um crime.
Imagine um banco.
Existem milhares de programas.
Todos precisam validar CPF.
Todos precisam validar agência.
Todos precisam calcular tarifas.
Sem LINK seria algo parecido com isto:
Programa A
↓
1000 linhas de validação
Programa B
↓
1000 linhas iguais
Programa C
↓
Mais 1000 linhas iguais
Resultado?
Uma manutenção impossível.
Então surgiu a ideia da modularização.
Criar um programa especializado.
Todos fazem LINK.
Todos reutilizam.
Curiosidade Histórica
Os primeiros sistemas bancários gigantes da década de 80 começaram a reduzir drasticamente o tamanho dos programas graças ao uso intensivo de LINK.
Alguns módulos chegaram a ser reutilizados por mais de 5.000 programas diferentes.
Imagine alterar uma regra tributária.
Em vez de recompilar cinco mil programas...
Recompila-se apenas um módulo.
Essa economia representa milhares de horas de trabalho.
O Stack Invisível
Existe um detalhe fascinante.
Quando fazemos LINK o CICS monta uma pilha.
Programa A
↓
Programa B
↓
Programa C
↓
Programa D
Cada programa sabe exatamente quem o chamou.
Quando termina...
Volta para quem estava esperando.
É praticamente uma pilha de execução semelhante ao que linguagens modernas como Java e C# fazem internamente.
Só que isso já existia décadas antes.
EASTER EGG Nº 1 ☕
Os programadores antigos brincavam dizendo:
"LINK é o telefone do CICS."
Você liga.
Conversa.
Desliga.
Continua a vida.
SEGUNDA PORTA
XCTL
Agora Bellacosa desenha uma flecha enorme.
Sem retorno.
"Quando atravessar essa porta..."
"...não olhe para trás."
XCTL significa substituição.
Fluxo:
Programa A
↓
XCTL
↓
Programa B
Fim.
Programa A acabou.
Nunca mais será executado.
Analogia Cinematográfica
Imagine uma corrida de revezamento.
LINK
é como emprestar uma calculadora.
Ela volta.
XCTL
é entregar o bastão.
Sua corrida terminou.
Outro atleta continua.
Quando usar?
Sempre que o programa atual terminou definitivamente.
Exemplo clássico:
LOGIN
↓
MENU
O login acabou.
Nunca mais será usado.
Então:
LOGIN
↓
XCTL MENU
Muito mais eficiente.
Economia de Recursos
Pouca gente comenta isso.
Mas XCTL ajuda o CICS a economizar memória.
Como não existe retorno...
O contexto anterior pode ser descartado.
Em um ambiente com milhares de usuários simultâneos...
Essa pequena economia torna-se gigantesca.
Uma Cidade Invisível
Imagine uma cidade.
Cada prédio representa um programa.
LINK
é visitar um prédio e voltar para casa.
XCTL
é vender sua casa.
Mudar-se definitivamente.
Nunca mais retornar.
EASTER EGG Nº 2 ☕
Existe uma frase famosa entre veteranos:
"Quem usa XCTL esperando voltar está esperando um trem que nunca passa."
TERCEIRA PORTA
START
Agora Bellacosa sorri.
"Esta porta..."
"...não leva ao próximo cômodo."
"Ela cria outro prédio."
Essa talvez seja a maior confusão dos iniciantes.
START
não chama programa.
START cria outra transação.
Parece a mesma coisa.
Mas está muito longe disso.
A Grande Diferença
LINK
continua na mesma task.
XCTL
continua na mesma task.
START
cria outra task.
Outro contexto.
Outra vida.
Outra execução.
Fluxo
Transação A
↓
START
↓
Nova Transação
Não existe espera.
Não existe retorno.
Cada uma segue seu caminho.
Imagine um Restaurante
Você pede um café.
Enquanto toma o café...
Pede também uma sobremesa para levar.
O garçom registra outro pedido.
Você continua tomando café.
Não espera a sobremesa ficar pronta.
Isso é START.
Um Banco de Verdade
Cliente faz PIX.
O sistema precisa:
✔ atualizar saldo
✔ gravar auditoria
✔ enviar SMS
✔ enviar e-mail
✔ atualizar Data Warehouse
✔ gerar estatísticas
O cliente deveria esperar tudo isso?
Claro que não.
Então:
START SMS
START EMAIL
START AUDITORIA
Enquanto isso...
A tela já responde:
Transferência concluída.
START pode ser Agendado
Poucos iniciantes sabem.
START pode acontecer:
Agora.
Daqui cinco segundos.
Daqui cinco minutos.
Daqui uma hora.
Em horário específico.
Isso permite automações extremamente sofisticadas.
Curiosidade
Muitos sistemas de cobrança utilizam START para criar processos futuros.
Por exemplo:
Hoje:
Cliente fez uma compra.
Daqui sete dias:
Enviar pesquisa de satisfação.
Tudo agendado pelo próprio CICS.
COMMAREA
A Mala de Viagem
Imagine uma mala.
Dentro dela estão documentos.
Valores.
Informações.
Essa mala é a COMMAREA.
LINK entrega a mala.
Recebe de volta.
XCTL entrega a mala.
Vai embora.
START entrega uma cópia da mala para outra viagem.
É exatamente isso.
Mas Existe Algo Melhor...
Nos sistemas modernos existem CHANNELS e CONTAINERS.
Eles resolvem várias limitações da COMMAREA:
✔ maior capacidade
✔ múltiplos objetos
✔ melhor organização
✔ integração com aplicações modernas
Em entrevistas técnicas isso costuma aparecer bastante.
O Erro Mais Comum
Iniciante:
"Vou usar START porque é mais rápido."
Veterano:
"Não."
START não acelera nada.
Ele apenas desacopla o processamento.
São conceitos completamente diferentes.
Outro Erro Clássico
Usar LINK para tudo.
Imagine:
Transferência
↓
LINK SMS
↓
LINK EMAIL
↓
LINK RELATÓRIO
↓
LINK LOG
Resultado?
O cliente espera tudo terminar.
Resposta lenta.
Sistema congestionado.
Outro Crime Arquitetural
Usar START para validação.
START VALIDA CPF
Enquanto isso...
A transferência continua.
Percebe o problema?
O dinheiro pode ser transferido antes da validação terminar.
Catástrofe.
Comparação Completa
Característica
LINK
XCTL
START
Retorna ao programa chamador
Sim
Não
Não
Mesma Task
Sim
Sim
Não
Nova Transação
Não
Não
Sim
Processamento Assíncrono
Não
Não
Sim
Ideal para reutilização
Sim
Não
Não
Ideal para navegação
Não
Sim
Não
Ideal para background
Não
Não
Sim
O Fluxo de um Banco Moderno
Imagine toda uma sessão bancária.
LOGIN
↓
XCTL MENU
O login desaparece.
Depois:
MENU
↓
LINK VALIDA CONTA
↓
LINK VALIDA LIMITE
↓
LINK CALCULA TARIFA
Quando um comando é executado, o CICS atualiza diversas estruturas internas:
Task Control Area (TCA): controla a execução da tarefa atual.
Program Control Table (PCT) e Program Processing Table (PPT): ajudam a localizar e preparar programas para execução.
Storage Manager: administra a memória utilizada pelos programas e COMMAREAs.
Dispatcher: decide quando cada task pode usar a CPU.
No caso do LINK, o CICS preserva o contexto do chamador e empilha a chamada. No XCTL, substitui o programa ativo sem manter uma pilha de retorno. No START, cria uma nova entrada de task, que poderá ser despachada conforme a disponibilidade do sistema e as prioridades definidas pelo Workload Manager (WLM).
Essa infraestrutura invisível é uma das razões pelas quais um único CICS consegue atender milhares de usuários simultaneamente.
Dicas de Ouro para Iniciantes
✅ Pense primeiro no fluxo de negócio, depois escolha o comando.
✅ Pergunte sempre: "Preciso voltar para este programa?"
Sim → LINK.
Não → XCTL.
✅ Pergunte também: "Esse processamento pode acontecer depois?"
Sim → START.
✅ Evite criar programas monolíticos. Um bom sistema CICS é formado por módulos pequenos, especializados e reutilizáveis.
✅ Documente claramente quando um programa espera retorno e quando transfere definitivamente o controle. Isso facilita manutenção e reduz erros.
Curiosidades que Pouca Gente Conhece
Alguns ambientes bancários possuem módulos de validação chamados por dezenas de milhões de LINKs por dia.
Em aplicações críticas, uma única transação pode executar dezenas de comandos LINK antes de terminar.
Muitos sistemas legados utilizam cadeias de XCTL para implementar menus completos em aplicações 3270.
START é frequentemente usado para disparar integrações com filas, auditorias, notificações e processamento em segundo plano, reduzindo o tempo de resposta percebido pelo usuário.
O Conselho Final de Bellacosa
Bellacosa terminou o café, fechou o bloco de anotações e apontou novamente para as três portas.
— "O segredo nunca foi decorar a sintaxe."
O jovem programador olhou confuso.
— "Então qual é o segredo?"
O velho sorriu.
— "Entender o destino da transação."
Ele desenhou três frases finais:
LINK conversa.
XCTL substitui.
START cria um novo caminho.
Depois apagou as luzes do CPD.
Enquanto caminhavam pelo corredor iluminado apenas pelos painéis azuis do mainframe, Bellacosa deixou a última pista:
"Os grandes sistemas do mundo não permanecem funcionando há décadas porque usam comandos complicados. Permanecem funcionando porque seus arquitetos sempre souberam escolher a porta certa antes de atravessá-la."
Naquela madrugada, o jovem programador percebeu que o verdadeiro mistério nunca esteve nos comandos do CICS.
O verdadeiro mistério sempre foi compreender que cada transação conta uma história, e que LINK, XCTL e START são apenas maneiras diferentes de decidir como essa história continuará. Afinal, no universo do mainframe, uma escolha aparentemente simples pode determinar se milhões de transações seguirão seu caminho com segurança... ou se um novo caso será aberto para o próximo detetive do CPD investigar.
⚓ ALMIRANTE GRACE HOPPER E O MAINFRAME QUE SE RECUSAVA A FICAR NO PASSADO
COBOL, Git, APIs, MQ, Kafka, CI/CD, Jenkins, OpenShift, observabilidade, segurança, IA e a estranha descoberta de que modernizar um mainframe não significa necessariamente jogar fora aquilo que funciona.
🎬 PRÓLOGO — O jovem programador e a máquina do tempo
Imagine seu primeiro dia trabalhando com mainframe.
Você aprendeu algumas coisas sobre COBOL.
Já sabe que existe:
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
Descobriu que PIC X(10) não é uma fotografia de dez pixels e que COMP-3 provavelmente vai persegui-lo em algum momento da carreira.
Então você entra no ambiente corporativo.
TSO.
ISPF.
Datasets.
JCL.
JES2.
SDSF.
CICS.
Db2.
VSAM.
De repente surge uma senhora usando uniforme da Marinha dos Estados Unidos.
Ela olha para aquele monte de tecnologia e pergunta:
— Muito bem, jovem. E onde está o Git?
Silêncio.
— Git?
— Sim. E o pipeline?
Mais silêncio.
— E como essa aplicação publica uma API?
Agora o iniciante começa a suar.
— Almirante Hopper... eu só queria aprender COBOL.
Bem-vindo ao Bellacosa Mainframe.
Pegue o café.
Porque hoje vamos descobrir que aprender COBOL é apenas a porta de entrada para uma cidade tecnológica gigantesca.
E nossa guia será ninguém menos que Grace Murray Hopper, pioneira da computação, uma das figuras históricas associadas ao desenvolvimento dos primeiros compiladores e cuja trajetória ajudou a estabelecer ideias que influenciaram profundamente o nascimento das linguagens de programação de alto nível e do próprio COBOL.
Se Hopper estivesse diante de um IBM Z moderno, provavelmente reconheceria imediatamente uma ideia que atravessou toda a história da computação:
A melhor tecnologia não é necessariamente aquela que substitui tudo. É aquela que permite evoluir sem destruir o que já funciona.
⚓ CAPÍTULO 1 — COBOL NÃO É O MAINFRAME
Esse é nosso primeiro ensinamento.
Muita gente começando mistura três conceitos:
COBOL
MAINFRAME
SISTEMA LEGADO
Como se fossem sinônimos.
Não são.
COBOL é uma linguagem.
Mainframe é uma plataforma computacional.
Legado é um conceito relacionado a sistemas existentes que carregam história, regras, dependências e valor para a organização.
Uma aplicação COBOL pode executar em diferentes plataformas.
A verdadeira modernização não está em trocar uma palavra por outra.
Não está em:
COBOL → Java
ou:
Mainframe → Cloud
A transformação está em construir pontes:
LEGADO ↔ MODERNO
BATCH ↔ API
CICS ↔ MOBILE
COBOL ↔ GIT
JCL ↔ CI/CD
JES2 ↔ REST
MQ ↔ MICROSERVICES
DB2 ↔ ANALYTICS
IBM Z ↔ CLOUD
SMF ↔ OBSERVABILITY
PROGRAMADOR ↔ AUTOMAÇÃO
☕ EPÍLOGO — A CATEDRAL CONTINUA ABERTA
Existe uma mania curiosa na tecnologia de declarar coisas mortas.
COBOL morreu.
Mainframe morreu.
Batch morreu.
SQL morreu.
Data center morreu.
Toda década alguém publica um novo obituário.
Enquanto isso, sistemas continuam processando transações.
Talvez o iniciante deva aprender uma lição diferente.
Tecnologia empresarial raramente evolui simplesmente apagando o passado.
Ela evolui em camadas.
O COBOL permanece.
Mas agora está no Git.
O JCL permanece.
Mas um pipeline pode submetê-lo.
O CICS permanece.
Mas uma API pode chamá-lo.
O MQ permanece.
Mas pode conectar arquiteturas distribuídas.
O Db2 permanece.
Mas seus dados podem alimentar analytics e IA.
O IBM Z permanece.
Mas não precisa permanecer isolado.
Essa talvez seja uma das ideias mais importantes para quem começa a carreira em mainframe:
Você não está estudando apenas uma tecnologia antiga. Está estudando como décadas diferentes da história da computação conseguem continuar trabalhando juntas.
E isso muda a pergunta.
Não pergunte apenas:
"Como programo COBOL?"
Pergunte:
"Como uma mudança que fiz neste COBOL percorre Git, build, testes, segurança, CI/CD, CICS, APIs, integração, dados e observabilidade até chegar ao cliente?"
Quando conseguir responder essa pergunta, você terá atravessado uma fronteira importante.
Deixou de olhar somente para as 80 colunas.
Começou a enxergar a arquitetura.
E, em algum lugar da sala de máquinas, nossa Almirante provavelmente estaria satisfeita.
Antes de sair, porém, Hopper olha novamente para o dashboard.
Uma transação desconhecida apareceu.
Horário:
03:17:00
TRACE-ID:
BELLACOSA-0317
Origem:
UNKNOWN
Ela pega o café.
— Bellacosa...
— Sim, Almirante?
— Temos um incidente.
Continua no próximo JOB.
//BELLACOS JOB (0317),'COFFEE',
// CLASS=A,
// MSGCLASS=X
//*
//* NEVER UNDERESTIMATE OLD CODE
//* THAT STILL RETURNS RC=0000
//*
☕ Um Café no Bellacosa Mainframe
Porque modernizar não é esquecer de onde viemos. É garantir que aquilo que construímos ontem ainda consiga conversar com o amanhã.
PS: Este artigo foi pensado para responder a seguinte pergunta.
Como uma empresa moderna desenvolve, integra, automatiza, observa e moderniza aplicações que rodam nesse mainframe?
🧰 CHECKLIST BELLACOSA DE MANUTENÇÃO MENTAL (O toolkit diário para manter o cérebro rodando suave, sem abends nem travamentos)
☀️ 1. BOOT DO DIA – “Initialize System”
Logo ao acordar, evite abrir o celular.
A primeira hora do dia define a prioridade de jobs do seu emocional.
Respire, alongue, pense no que realmente importa.
O primeiro comando do dia deve vir de você, não da notificação.
💬 2. STATUS CHECK – “DISPLAY MIND,DETAIL”
No meio da manhã, faça uma autoanálise rápida:
Como estou me sentindo agora? Calmo? Tenso? Disperso?
Nomear o que sente é o mesmo que identificar o dataset antes de manipulá-lo.
Sentimento sem nome vira processo fantasma ocupando CPU emocional.
🧘♀️ 3. REFRESH BUFFER – “CANCEL ALL”
Durante o dia, tire micro-pausas de 5 minutos sem estímulos.
Nada de rolar tela — apenas respire, feche os olhos, escute o ambiente.
Isso reinicia o cache e traz foco de volta.
O silêncio é o comando “RESET” da mente.
☕ 4. AFTERNOON MAINTENANCE – “SORT PRIORITIES”
No meio da tarde, revise o que ainda precisa ser feito e o que pode ficar para amanhã.
Reorganize, defer, skip step, se necessário.
Aprender a priorizar é um ato de amor-próprio.
Nem todo job precisa rodar em hoje.
🌙 5. SHUTDOWN MODE – “LOGOFF PEACEFULLY”
Antes de dormir, agradeça.
Pense no que funcionou bem, e libere o que travou.
Desligue as telas, leia algo leve, ouça uma música calma.
Um bom “shutdown” garante logs limpos e sonhos desfragmentados.
🔁 ROTINA OPCIONAL – “RUN MIND CLEANER, DAILY”
5 minutos de respiração consciente
10 minutos de caminhada leve
1 momento de riso genuíno
1 conversa sincera
1 ato de gentileza (mesmo anônima)
Esses comandos simples fazem tuning na alma e aumentam o throughput da paz interior.
Bellacosa Mainframe 💾🧠 Porque cuidar da mente é como manter um sistema z/OS: se você ignora o warning, o dump vem inevitável.
Bellacosa Mainframe e os animes proibidoes estilo school days
☕💣📼 OPERADOR, O ABEND DE SCHOOL DAYS NÃO FOI UM CASO ISOLADO!
10 ANIMES PARA QUEM SOBREVIVEU AO DESASTRE OPERACIONAL DE MAKOTO ITOU
Se você terminou School Days e ficou pensando:
"Não acredito que um romance escolar terminou desse jeito..."
Prepare-se.
Existem animes que exploram traição, obsessão, psicologia, realidades alternativas, assassinatos, loops temporais e relacionamentos tão perigosos quanto um DELETE sem backup no catálogo mestre.
1. HIGURASHI NO NAKU KORO NI
Título Original
ひぐらしのなく頃に
Lançamento
2006
Personagens
Keiichi Maebara
Rena Ryugu
Mion Sonozaki
Rika Furude
Resumo
Um garoto se muda para uma vila aparentemente tranquila.
Pouco depois descobre uma série de assassinatos ligados a um festival local.
História
A cada arco a realidade parece reiniciar.
Os acontecimentos mudam.
As mortes mudam.
As respostas mudam.
Easter Egg
Os relógios e calendários escondem pistas dos loops temporais.
Curiosidade
Foi originalmente uma Visual Novel, assim como School Days.
Por que assistir?
Se você gostou do colapso psicológico.
Por que não assistir?
Violência extrema.
2. UMINEKO NO NAKU KORO NI
Título Original
うみねこのなく頃に
Lançamento
2009
Personagens
Battler Ushiromiya
Beatrice
Ange
Resumo
Uma família rica fica presa numa ilha.
Assassinatos começam a ocorrer.
A culpa é de uma bruxa?
Ou de um humano?
História
Uma guerra entre lógica e fantasia.
Easter Egg
Quase todos os mistérios possuem solução racional.
Curiosidade
Criado pelo mesmo autor de Higurashi.
Por que assistir?
Mistério de altíssimo nível.
Por que não assistir?
Anime adapta apenas parte da obra.
3. MIRAI NIKKI
Título Original
未来日記
Lançamento
2011
Personagens
Yukiteru Amano
Yuno Gasai
Resumo
Participantes recebem diários que mostram o futuro.
O último sobrevivente se torna deus.
História
Battle Royale psicológico.
Easter Egg
O nome Yuno lembra "YU-NO", outra obra clássica de ficção científica japonesa.
Curiosidade
Yuno tornou-se referência para o arquétipo "Yandere".
Por que assistir?
Uma das personagens mais icônicas dos animes.
Por que não assistir?
Algumas incoerências narrativas.
4. ELFEN LIED
Título Original
エルフェンリート
Lançamento
2004
Personagens
Lucy
Kouta
Nana
Resumo
Uma mutante escapa de um laboratório.
História
Mistura ficção científica com tragédia humana.
Easter Egg
O título vem de um poema alemão.
Curiosidade
Influenciou obras como Stranger Things.
Por que assistir?
Drama emocional devastador.
Por que não assistir?
Violência extrema.
5. WHITE ALBUM 2
Título Original
ホワイトアルバム2
Lançamento
2013
Personagens
Haruki
Setsuna
Kazusa
Resumo
Triângulo amoroso.
História
Diferente de School Days.
Aqui o foco é emocional.
Não físico.
Easter Egg
Referências musicais aparecem em praticamente todos os episódios.
Curiosidade
Considerado um dos romances mais maduros dos animes.
Por que assistir?
Drama romântico excelente.
Por que não assistir?
Muito sofrimento emocional.
6. KUZU NO HONKAI
Título Original
クズの本懐
Lançamento
2017
Personagens
Hanabi
Mugi
Resumo
Dois estudantes fingem namorar.
História
Uma análise brutal sobre desejos não correspondidos.
Easter Egg
As flores exibidas refletem o estado emocional dos personagens.
Curiosidade
Foi chamado de "School Days da geração moderna".
Por que assistir?
Psicologia sofisticada.
Por que não assistir?
Clima extremamente melancólico.
7. YOSUGA NO SORA
Título Original
ヨスガノソラ
Lançamento
2010
Personagens
Haruka
Sora
Resumo
Irmãos retornam à cidade natal.
História
Rotas alternativas semelhantes às Visual Novels.
Easter Egg
Cada arco corresponde a uma rota diferente do jogo.
Curiosidade
Uma das adaptações mais fiéis de Visual Novel.
Por que assistir?
Narrativa experimental.
Por que não assistir?
Tema altamente controverso.
8. SHUFFLE!
Título Original
シャッフル!
Lançamento
2005
Personagens
Rin
Kaede
Asa
Resumo
Romance envolvendo humanos, deuses e demônios.
História
Começa leve.
Termina surpreendentemente sombria.
Easter Egg
Vários finais da Visual Novel foram incorporados.
Curiosidade
Influenciou diversos romances escolares posteriores.
Por que assistir?
Mistura romance e fantasia.
Por que não assistir?
Primeira metade é lenta.
9. ANOTHER
Título Original
アナザー
Lançamento
2012
Personagens
Kouichi Sakakibara
Mei Misaki
Resumo
Uma turma sofre uma maldição mortal.
História
Mortes absurdamente imprevisíveis.
Easter Egg
Diversas pistas estão escondidas nos fundos das cenas.
Curiosidade
Popularizou o "guarda-chuva assassino".
Por que assistir?
Suspense constante.
Por que não assistir?
Não é romance.
10. YU-NO: KONO YO NO HATE DE KOI WO UTAU SHOUJO
Título Original
この世の果てで恋を唄う少女YU-NO
Lançamento Original
Visual Novel: 1996
Anime: 2019
Personagens
Takuya Arima
Kanna
Mio
Amanda
Resumo
Viagens entre realidades paralelas.
História
O protagonista precisa reconstruir a verdade através de múltiplas linhas temporais.
Easter Egg
Praticamente todos os finais possuem relevância para a conclusão final.
Curiosidade
Influenciou:
Steins;Gate
Re:Zero
Muv-Luv
Por que assistir?
Uma das obras mais importantes da ficção científica japonesa.
Por que não assistir?
O anime simplifica bastante a Visual Novel.
☕💣 Ranking Bellacosa Mainframe de Similaridade com School Days
Anime
Similaridade
White Album 2
⭐⭐⭐⭐⭐
Kuzu no Honkai
⭐⭐⭐⭐⭐
Yosuga no Sora
⭐⭐⭐⭐⭐
Shuffle!
⭐⭐⭐⭐
Mirai Nikki
⭐⭐⭐⭐
Higurashi
⭐⭐⭐⭐
Umineko
⭐⭐⭐
Another
⭐⭐⭐
Elfen Lied
⭐⭐⭐
YU-NO
⭐⭐⭐
📼 Veredito Final
Se School Days foi seu primeiro contato com romances psicológicos sombrios, a sequência ideal é:
School Days → White Album 2 → Kuzu no Honkai → Yosuga no Sora → Higurashi → Umineko → YU-NO
Essa ordem aumenta gradualmente a complexidade narrativa, levando você do simples "triângulo amoroso problemático" até mistérios multidimensionais capazes de fazer um operador de mainframe revisar o mesmo dump emocional dezenas de vezes antes de encontrar a causa raiz do ABEND. ☕💣🔪📼
Bellacosa Mainframe e o CALL em programas COBOL Parte I
☕💥 A Jornada do Padawan COBOL – Parte 1
Desvendando o Universo dos CALLs no Mainframe
Ou como descobrir que chamar um programa em COBOL é quase tão importante quanto saber preparar café às 3 da manhã durante uma janela de produção
Por Vagner Bellacosa – Bellacosa Mainframe
Introdução
Todo desenvolvedor COBOL passa por um momento de iluminação.
Normalmente acontece quando ele abre um programa de produção com 30 mil linhas e encontra algo parecido com isto:
CALL 'PROG0001'
USING WS-AREA.
CALL WS-PROGRAMA
USING WS-COMMAREA.
CALL 'VALIDA01'
USING BY CONTENT WS-DATA.
CALL 'ROTINA99'
USING BY REFERENCE WS-BLOCO.
Neste momento surge a dúvida existencial:
Por que existem tantos tipos de CALL?
Qual é o mais rápido?
Qual gasta menos memória?
O que acontece dentro do z/OS?
O compilador faz mágica?
O Load Module engorda?
Como um banco executa milhões de CALLs por segundo sem explodir?
Prepare seu café.
Vamos abrir a tampa do motor do z/OS.
O que é um CALL?
Simplificando:
CALL significa pedir ajuda para outro programa.
Em vez de colocar 100 mil linhas em um único fonte, quebramos o sistema em pequenas peças reutilizáveis.
PROCESSA
+
VALIDA
+
CPFCHK
+
JUROS
=
EXECUTÁVEL FINAL
Na memória
Antes:
PROCESSA
Depois:
PROCESSA
VALIDA
CPFCHK
JUROS
Tudo junto.
Tudo carregado.
Vantagens
Performance
Excelente.
Não precisa procurar.
Não precisa abrir bibliotecas.
Não precisa localizar módulo.
É praticamente:
BALR
Menor CPU
Menos instruções.
Menos overhead.
Menos I/O.
Desvantagens
Executável cresce.
Muito.
Exemplo
Programa principal
1 MB
Subrotinas
500 KB
Total
1,5 MB
Imagine 200 subrotinas.
Seu módulo vira um Godzilla.
Problema clássico
Padawan:
"Troquei VALIDA"
Produção:
Ainda usa antiga.
Porque precisa relinkar.
Quando usar?
Sempre que:
Programa nunca muda
Alta performance
Rotina crítica
Batch pesado
Exemplo:
Juros
Cálculo tributário
Validação interna
O Dynamic CALL aparece
Padawan evolui.
Descobre:
01 WS-PGM PIC X(8).
MOVE 'VALIDA' TO WS-PGM.
CALL WS-PGM.
O que acontece?
COBOL não sabe quem será chamado.
Somente em execução.
Busca do módulo
zOS procura:
STEPLIB
JOBLIB
LPA
LINKLIST
Exemplo
CALL CPFCHK
Sistema:
Existe?
Não.
Próximo.
Existe?
Sim.
Carrega.
Executa.
Vantagens
Flexibilidade absurda.
Pode trocar programas.
Sem recompilar.
Sem binder.
Sem relink.
Plugins COBOL
Exemplo
Cartão VISA
MOVE 'VISA0001'
Master
MOVE 'MASTER01'
PIX
MOVE 'PIX00001'
Mesmo sistema.
Rotinas diferentes.
Desvantagens
Procura programa.
Mais CPU.
Mais I/O.
Mais tempo.
Mas é lento?
Depende.
Primeira chamada.
Sim.
Segunda.
Muito rápida.
Porque pode ficar residente.
O segredo da residência
zOS é esperto.
Se programa está em memória.
Reutiliza.
Não busca novamente.
Comparação
Static
Casa própria
Dynamic
Airbnb
O executável cresce?
Static
Sim.
Dynamic
Não.
Executável principal fica pequeno.
Exemplo
Static
PROCESSA
1.5 MB
Dynamic
PROCESSA
600 KB
Subrotinas externas.
O que é mais performático?
Resposta curta.
Static.
Fim.
Mas...
O que é melhor?
Depende.
Banco.
Static.
Framework.
Dynamic.
Produtos.
Dynamic.
Rotinas financeiras.
Static.
Como o CALL funciona internamente?
Imagine isto.
Programa principal
00001000
PROCESSA
Subrotina
00025000
VALIDA
CALL executa
Guardar endereço retorno
Ir para 25000
Executar
Voltar
É praticamente um GOTO sofisticado.
Só que elegante.
Erros clássicos
S806
Programa não encontrado.
Mensagem
IEC806I
Causa
Módulo ausente.
STEPLIB errada.
Nome inválido.
S0C1
Executou lixo.
Programa corrompido.
S0C4
Endereço inválido.
Muito comum em parâmetros errados.
Como descobrir
SDSF
JESMSGLG
SYSOUT
Verificar:
STEPLIB
SYSLIB
LOADLIB
Easter Egg IBM
Muitos bancos possuem:
PROG0001
PROG0002
PROG0003
Ninguém sabe o que fazem.
Autor aposentou em 1998.
Documentação desapareceu.
Programa continua funcionando.
Todos têm medo de alterar.
É chamado:
Código Arqueológico Mainframe™
Dicas Bellacosa Mainframe
Dica 1
Static para alta frequência.
Dica 2
Dynamic para produtos.
Dica 3
Nunca fazer:
MOVE WS-USUARIO TO WS-PGM
CALL WS-PGM
Sem validar.
Pode chamar qualquer coisa.
Inclusive algo inexistente.
Dica 4
Validar sempre.
EVALUATE WS-PGM
WHEN 'CPFCHK'
WHEN 'JUROS01'
WHEN 'PIX0001'
WHEN OTHER
DISPLAY 'INVALIDO'
END-EVALUATE
Dica 5
Logar chamadas.
DISPLAY 'CALL=' WS-PGM
Ajuda muito.
A Filosofia Jedi do CALL
O Padawan iniciante pensa:
CALL serve apenas para executar outro programa.
O desenvolvedor intermediário pensa:
CALL serve para reutilizar código.
O Mestre Mainframe entende:
CALL é uma decisão arquitetural.
Ele impacta:
CPU
Memória
Tempo de resposta
Tamanho do Load Module
Facilidade de manutenção
Segurança
Escalabilidade
Observabilidade
Estratégia de deploy
E é exatamente por isso que, cinquenta anos depois, os sistemas bancários que movimentam bilhões de dólares diariamente ainda utilizam a mesma instrução COBOL que um programador digitou em um terminal verde na década de 1970:
CALL 'SUBPGM'
Na próxima etapa da jornada, o Padawan descobrirá que o verdadeiro poder do COBOL não está apenas em chamar programas, mas em como os dados atravessam a fronteira entre eles, mergulhando nos mistérios de BY REFERENCE, BY CONTENT, BY VALUE, ponteiros, Work-Storage, Local-Storage e Language Environment, onde vivem os temidos S0C4, os buffers compartilhados e os segredos que fazem alguns programas parecerem mágicos aos olhos dos desenvolvedores mais jovens.
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
