Translate

terça-feira, 31 de outubro de 2023

A metafora dos Pastores, Ovelhas e Lobos

 

Bellacosa Mainframe entre pastores, ovelhas e lobos

☕ Um Café no Bellacosa Mainframe

Pastores, Ovelhas e Lobos

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Poder, Psicologia, Sociologia e Por Que a História Parece uma Eterna Disputa Pela Influência Sobre as Pessoas

"Quem controla um Mainframe controla dados. Quem influencia uma sociedade controla narrativas. Mas quem controla a própria consciência permanece verdadeiramente livre."


Introdução

Todo profissional de IBM Mainframe sabe que um sistema complexo nunca é governado por um único componente.

Existe o hardware.

Existe o sistema operacional.

Existe o middleware.

Existem aplicações.

Existe segurança.

Existe auditoria.

Existe governança.

Nenhuma dessas camadas explica sozinha o comportamento do sistema.

As sociedades humanas também funcionam assim.

Ao longo de nossa conversa surgiu uma metáfora interessante.

A sociedade seria formada por três grandes personagens.

Os pastores.

As ovelhas.

Os lobos.

À primeira vista parece uma descrição simples.

Mas talvez ela esconda algumas das questões mais profundas da ciência política, da psicologia social e da sociologia.

Quem lidera?

Quem segue?

Quem manipula?

Quem realmente possui poder?

E talvez a pergunta mais importante de todas:

Será que somos sempre a mesma coisa?

Ou cada um de nós pode assumir papéis diferentes conforme a situação?


O Mainframe Ensina a Primeira Lição

Quando um problema acontece em um IBM Z, o usuário costuma culpar a aplicação.

O desenvolvedor culpa o banco de dados.

O DBA culpa o storage.

O Sysprog culpa a configuração.

No fim, descobre-se que diversos fatores contribuíram simultaneamente.

Sociedades também raramente funcionam por uma única causa.

Elas são sistemas complexos.

Reduzi-las a "bons" e "maus" normalmente produz respostas simples para problemas extremamente sofisticados.


A Metáfora dos Três Papéis

Se utilizarmos essa metáfora apenas como ferramenta de análise, podemos imaginar:

Pastores

São aqueles que procuram organizar grupos.

Podem ser:

  • líderes políticos;

  • professores;

  • religiosos;

  • jornalistas;

  • cientistas;

  • gestores;

  • influenciadores.

Nem todo pastor é benevolente.

Nem todo pastor é manipulador.

Liderança é uma função, não uma garantia moral.


Ovelhas

Representam quem segue referências.

Mas existe um detalhe.

Todos nós fazemos isso.

Quando aprendemos programação.

Quando escolhemos um médico.

Quando seguimos normas de trânsito.

Confiar em especialistas é inevitável em sociedades complexas.

O problema surge quando seguir transforma-se em obedecer sem reflexão.


Lobos

Na metáfora, representam quem busca explorar pessoas para benefício próprio.

Podem existir em qualquer setor.

Mercado.

Política.

Religião.

Crime organizado.

Empresas.

Movimentos sociais.

Não pertencem exclusivamente a uma ideologia.

São definidos pelo comportamento, não pela posição.


Max Weber e os Tipos de Autoridade

Max Weber mostrou que a autoridade pode surgir de diferentes fontes.

Autoridade tradicional.

Autoridade carismática.

Autoridade racional-legal.

Nenhuma delas depende exclusivamente da força.

Grande parte do poder nasce da legitimidade percebida.

As pessoas obedecem porque acreditam que devem obedecer.


Gustave Le Bon e a Psicologia das Massas

No século XIX, Gustave Le Bon observou que indivíduos podem agir de maneira diferente quando inseridos em multidões.

Em grupos grandes:

  • emoções propagam-se rapidamente;

  • pensamento crítico pode diminuir;

  • líderes carismáticos ganham força.

Embora parte de suas ideias tenha sido revisada por pesquisas posteriores, seu trabalho influenciou profundamente o estudo do comportamento coletivo.


Solomon Asch

Asch mostrou algo surpreendente.

Mesmo diante de uma resposta obviamente errada, muitas pessoas concordavam com o grupo.

Por quê?

Porque pertencer é psicologicamente importante.

O medo da exclusão pode alterar decisões.


Stanley Milgram

Milgram investigou até onde pessoas comuns obedeceriam figuras de autoridade.

Seu experimento gerou intenso debate ético, mas mostrou o peso do contexto e da autoridade sobre o comportamento humano.

A lição permanece atual.

Nem sempre obedecemos porque concordamos.

Às vezes obedecemos porque percebemos uma estrutura legítima de poder.


Hannah Arendt

Ao analisar regimes autoritários, Hannah Arendt propôs a ideia da banalidade do mal.

Sua reflexão não afirmava que pessoas são naturalmente más.

Mostrava como indivíduos comuns podem participar de sistemas prejudiciais sem necessariamente agir movidos por ódio.

Rotina.

Burocracia.

Obediência.

Distanciamento moral.

Tudo isso pode reduzir a percepção de responsabilidade individual.


Michel Foucault

Foucault trouxe uma pergunta diferente.

Talvez o poder não esteja apenas nos governantes.

Talvez ele esteja distribuído em instituições, normas, escolas, empresas, hospitais, linguagem e práticas sociais.

O poder deixa de ser apenas uma pessoa dando ordens.

Passa a ser uma rede.


Pierre Bourdieu

Bourdieu lembrava que poder também pode ser invisível.

Capital econômico.

Capital cultural.

Capital social.

Capital simbólico.

Quem define quais conhecimentos são valorizados?

Quem define o que significa sucesso?

Quem determina o "bom gosto"?

Essas formas de influência frequentemente são mais sutis do que a coerção direta.


Antonio Gramsci

Gramsci argumentava que grupos procuram conquistar não apenas instituições políticas, mas também legitimidade cultural.

Quando uma visão de mundo passa a parecer natural, ela exerce enorme influência.

Independentemente da posição ideológica de quem o interpreta, esse conceito ajuda a entender por que disputas por educação, mídia, arte e cultura costumam ser tão intensas.


René Girard

Girard observou que imitamos desejos.

Não desejamos apenas objetos.

Desejamos aquilo que percebemos ser desejado pelos outros.

Essa lógica explica por que narrativas, símbolos e líderes podem ganhar tanta força.


Jonathan Haidt

Haidt mostrou que pessoas frequentemente chegam primeiro a uma conclusão intuitiva e só depois constroem justificativas racionais.

Isso significa que argumentos nem sempre mudam opiniões.

Valores, identidade e pertencimento também desempenham papel importante.


Daniel Kahneman

Kahneman distinguiu, de forma simplificada, dois modos de pensar.

Um rápido.

Outro lento.

Em momentos de pressão, medo ou excesso de informação, tendemos a depender mais de respostas automáticas.

Isso torna mensagens simples emocionalmente poderosas.


A Guerra de Tronos Permanente

A história pode ser interpretada como sucessivas disputas por influência.

Impérios.

Reinos.

Partidos.

Empresas.

Religiões.

Movimentos sociais.

Corporações.

Cada grupo tenta convencer a sociedade de que sua visão oferece o melhor caminho.

Isso não significa que todos utilizem os mesmos métodos ou tenham os mesmos objetivos.

Mas revela que disputa por legitimidade é um elemento constante da vida coletiva.


O Cidadão Comum é Apenas um Peão?

Essa metáfora pode transmitir um sentimento real de falta de influência.

Mas ela também possui limitações.

Em sociedades democráticas, cidadãos podem exercer diferentes formas de participação:

  • votar;

  • organizar associações;

  • produzir conhecimento;

  • empreender;

  • participar de debates públicos;

  • influenciar comunidades.

Nem sempre esse poder é suficiente para produzir mudanças rápidas.

Mas também não é correto concluir que indivíduos sejam completamente passivos.


O Algoritmo Mudou o Tabuleiro

No passado, poucos controlavam os grandes meios de comunicação.

Hoje milhões produzem conteúdo.

Ao mesmo tempo, plataformas digitais concentram enorme capacidade de distribuição.

Isso cria uma dinâmica inédita.

Qualquer pessoa pode falar.

Pouquíssimas conseguem ser ouvidas por milhões.

A disputa deslocou-se da impressão de jornais para a conquista da atenção.


O Maior Poder é Definir a Narrativa

Em engenharia de software, quem define a arquitetura influencia todo o sistema.

Na sociedade acontece algo semelhante.

Quem consegue estabelecer quais perguntas serão feitas frequentemente influencia também quais respostas parecerão plausíveis.

Essa disputa ocorre continuamente.

Na política.

Na ciência.

Na economia.

Na cultura.

Nos meios de comunicação.

Nas redes sociais.


O Perigo das Explicações Únicas

A tentação humana é encontrar um único responsável.

Os políticos.

As empresas.

A mídia.

Os algoritmos.

As elites.

O povo.

A realidade costuma ser menos confortável.

Sistemas sociais são resultado da interação entre:

  • instituições;

  • incentivos econômicos;

  • cultura;

  • tecnologia;

  • psicologia;

  • história;

  • decisões individuais.

Explicações únicas raramente capturam toda essa complexidade.


O Que Todo Programador COBOL Já Aprendeu

Quem mantém sistemas legados sabe que falhas raramente possuem uma única causa.

Existe um erro inicial.

Depois uma configuração inadequada.

Depois uma documentação incompleta.

Depois um processo mal definido.

Depois um treinamento insuficiente.

Somados, esses fatores produzem o incidente.

Sociedades funcionam da mesma maneira.


Como Deixar de Ser Apenas Reativo

Independentemente da posição política ou filosófica de cada pessoa, algumas práticas fortalecem autonomia intelectual.

  • Ler autores com perspectivas diferentes.

  • Diferenciar fatos de interpretações.

  • Reconhecer os próprios vieses.

  • Revisar opiniões diante de novas evidências.

  • Evitar transformar qualquer grupo em absolutamente virtuoso ou absolutamente maligno.

  • Participar de comunidades reais, não apenas digitais.

O pensamento crítico não elimina erros.

Mas reduz a probabilidade de sermos conduzidos automaticamente por narrativas prontas.


Conclusão

Talvez a metáfora dos pastores, ovelhas e lobos continue viva porque captura algo verdadeiro sobre a condição humana.

Sempre existirão pessoas que desejam liderar.

Sempre existirão pessoas que preferem seguir.

Sempre existirão pessoas dispostas a explorar os outros.

Mas existe um detalhe frequentemente esquecido.

Esses papéis não são permanentes.

O professor que lidera uma sala torna-se paciente diante do médico.

O empresário que conduz uma empresa segue orientações do engenheiro.

O especialista que ensina programação aprende com o historiador.

Todos nós lideramos em alguns momentos.

Seguimos em outros.

Erramos em muitos.

A verdadeira maturidade talvez não esteja em identificar quem são os pastores, as ovelhas ou os lobos.

Esteja em reconhecer quando nós mesmos estamos assumindo cada um desses papéis.

Porque o maior risco para uma sociedade não é apenas a existência de líderes ou de seguidores.

É quando indivíduos deixam de perceber que possuem a capacidade — e a responsabilidade — de pensar por conta própria.

Assim como um Sysprog nunca entrega o controle de um Mainframe sem auditoria, o cidadão do século XXI talvez precise aprender a nunca entregar completamente sua capacidade de julgamento.

Porque, no fim, a liberdade mais difícil de preservar continua sendo aquela que acontece dentro da própria consciência.


segunda-feira, 30 de outubro de 2023

🎭 Parte 7 – O Legado Cultural do Hikikomori



 Como o Japão transformou a solidão em arte – uma leitura estética e filosófica

Por Bellacosa – o silêncio também cria mundos.


🌑 Introdução – A Beleza do Recolhimento

O Japão, mais do que qualquer outra cultura, aprendeu a transformar melancolia em estética.
Do mono no aware à quietude do zen, existe uma tradição em contemplar a impermanência e o isolamento como formas legítimas de beleza.

O hikikomori é o herdeiro moderno dessa sensibilidade:
um arquétipo nascido da era digital, mas enraizado nas antigas formas de solidão poética japonesa.

Assim, o que o mundo vê como “reclusão” – o Japão, em sua arte, vê como um estado de espírito narrável.


🖋️ 1. Na Literatura – O Casulo Tornado Palavra

A literatura japonesa sempre se moveu entre o ruído e o silêncio.
Antes mesmo do termo “hikikomori” existir, escritores já retratavam personagens que fugiam do mundo exterior para preservar sua integridade interior.

  • 📖 “Confissões de um Homem Insignificante” (Ningen Shikkaku, Osamu Dazai, 1948)
    Um dos pilares da literatura introspectiva japonesa.
    Dazai cria um protagonista incapaz de se encaixar na sociedade — um pré-hikikomori.
    Sua frase ecoa até hoje:

    “Não consegui aprender o que é ser humano.”

  • 📚 “Kafka à Beira-Mar” (Haruki Murakami)
    O isolamento aqui é místico: personagens que fogem da sociedade para mergulhar em mundos interiores.
    Murakami transforma o “recolher-se” em viagem espiritual.

  • 🕯️ Curiosidade:
    O termo “hikikomori” foi cunhado nos anos 90 pelo psiquiatra Tamaki Saitō, mas a alma hikikomori já habitava a literatura japonesa há séculos.


🎞️ 2. No Anime – A Solidão que Vira Tela

A animação japonesa encontrou no hikikomori um espelho perfeito para o mundo moderno.
Afinal, o anime é arte feita por quem entende o silêncio – estúdios escuros, desenhistas noturnos e universos construídos em introspecção.

🎬 Exemplos Marcantes
  • NHK ni Youkoso! (2006)
    O anime definitivo sobre o tema.
    Tatsuhiro Satou, um jovem isolado há quatro anos, vive cercado de delírios conspiratórios e uma sociedade que o esqueceu.
    Entre alucinações e esperança, ele mostra que o hikikomori não é apenas um “fracassado” — é um espelho da geração digital.

  • ReLIFE (2016)
    Um adulto desencantado tem a chance de reviver a juventude e curar seu isolamento.
    Mostra o caminho da reintegração com empatia e autoconhecimento.

  • Serial Experiments Lain (1998)
    Uma das primeiras representações filosóficas do isolamento tecnológico.
    Lain, conectada à rede, vive entre o real e o virtual — uma profecia sobre o hikikomori digital que o mundo ainda entenderia décadas depois.

  • The Tatami Galaxy (2010)
    Um retrato poético sobre o tempo perdido e o medo de viver.
    Cada episódio é uma nova realidade dentro do mesmo quarto — um labirinto mental que conversa diretamente com o espírito hikikomori.


🎵 3. Na Música – A Melodia do Silêncio Urbano

O Japão moderno também traduziu o hikikomori em sons e batidas suaves.

  • Bandas como Asian Kung-Fu Generation e RADWIMPS abordam o tema da desconexão e da busca por sentido.

  • O gênero “Lofi japonês” tornou-se a trilha sonora dos introspectivos contemporâneos — música para estudar, pensar e existir em silêncio.

  • O subgênero Yami Kawaii (かわいい闇) mistura estética fofa com tristeza — uma forma estética de dizer:
    “Mesmo isolado, ainda posso ser belo.”


🖼️ 4. No Cinema – A Câmera no Quarto Fechado

O cinema japonês sempre foi contemplativo.
Diretores como Yasujirō Ozu e Hirokazu Kore-eda entenderam que a ausência também é narrativa.

  • 🎥 Tokyo Sonata (2008) — mostra um pai desempregado que esconde sua condição da família, simbolizando a vergonha social e o nascimento do isolamento.

  • 🎥 All About Lily Chou-Chou (2001) — um retrato doloroso da adolescência e do escapismo digital.

  • 🎥 Homunculus (2021) — mergulho psicológico entre trauma, mente e reclusão.

“No cinema japonês, o silêncio não é vazio — é personagem.”
Bellacosa 


🪶 5. O Hikikomori Como Arquétipo Moderno

O hikikomori é, no fundo, um espelho da sociedade contemporânea global:
todos estamos parcialmente recolhidos — às vezes não fisicamente, mas emocionalmente.

Na cultura pop, ele virou símbolo de:

  • resistência à hiperconectividade,

  • busca de autenticidade,

  • sensibilidade diante do caos moderno.

E o Japão, em vez de negar, sublimou esse fenômeno em arte — transformando dor em estética, introspecção em narrativa.


🧩 6. Dicas Bellacosa – Aprendendo com o Hikikomori Artístico

  1. Assista NHK ni Youkoso! com calma — não como entretenimento, mas como reflexão.

  2. Leia Dazai — e perceba como a solidão pode ser escrita com elegância.

  3. Crie seu próprio “tatami digital” — um espaço mental de pausa e criação.

  4. Não fuja do silêncio. Ele pode ser o ponto mais alto da consciência.

  5. Observe-se sem culpa. A introspecção é uma forma de higiene espiritual.


🌅 Epílogo – A Solidão Como Forma de Arte

O hikikomori, longe de ser uma anomalia, é uma resposta poética a uma era barulhenta.
Ele nos lembra de que o humano precisa de intervalos,
que o silêncio também é criação,
e que o mundo interior — quando bem cuidado — pode ser tão vasto quanto o universo lá fora.

“O Japão fez do silêncio uma arte.
O hikikomori apenas pintou essa arte dentro de si.”
Bellacosa 

domingo, 29 de outubro de 2023

🧦 Yūsha ga Shinda! : Quando o Operador do Datacenter Morreu, um Fazendeiro Assumiu o IBM Z e Ninguém Teve Coragem de Dar CANCEL no Job

 

Bellacosa Mainframe e as doideiras de yusha ga shinda

☕ Um Café no Bellacosa Mainframe

🧦 Yūsha ga Shinda! (勇者が死んだ!): Quando o Operador do Datacenter Morreu, um Fazendeiro Assumiu o IBM Z e Ninguém Teve Coragem de Dar CANCEL no Job

"Nem sempre o maior desastre de um ambiente crítico é perder o herói. Às vezes é descobrir que o backup era um agricultor obcecado por coxas femininas."


Introdução

Existem dezenas de animes sobre heróis destinados a salvar o mundo.

Poucos têm coragem de perguntar:

"E se o herói morresse de forma completamente idiota logo no primeiro episódio?"

Essa é justamente a premissa de Yūsha ga Shinda!, uma obra que transforma praticamente todos os clichês do gênero fantasia em motivo de piada.

Por trás do humor escrachado, do ecchi exagerado e das situações absurdas existe uma crítica interessante sobre expectativa, reputação, identidade e sobre como a sociedade cria mitos em torno de figuras consideradas perfeitas.

No universo Bellacosa Mainframe, este anime parece uma gigantesca operação de Disaster Recovery onde o hardware continua funcionando perfeitamente... mas o software carregado nele definitivamente não era o esperado.


Ficha Técnica

ItemInformação
Título original勇者が死んだ! (Yūsha ga Shinda!)
Título internacionalThe Legendary Hero Is Dead!
AutorSubaruichi
Mangá2014–2020
Volumes20
Anime2023
EstúdioLIDENFILMS
DiretorRion Kujō
RoteiroYū Satō
MúsicaKana Utatane
Episódios12
GênerosFantasia, Comédia, Ecchi, Aventura, Paródia
Classificação indicativa16+ (varia conforme o país devido ao conteúdo sexual e violência cômica)

Sobre o Studio

A animação ficou a cargo do LIDENFILMS, estúdio conhecido por alternar produções extremamente sérias com comédias irreverentes.

Entre seus trabalhos mais conhecidos estão:

  • Tokyo Revengers

  • Call of the Night

  • Terra Formars

  • Hanebado!

  • Berserk (2016 em parceria)

Embora não seja considerado um estúdio "premium" como Kyoto Animation ou Ufotable, o LIDENFILMS entrega boa direção visual quando a prioridade é ritmo narrativo e expressão dos personagens.

Em Yūsha ga Shinda!, o foco claramente está na comédia, não na animação espetacular.


Sinopse

O lendário herói Sion Bladan derrota inúmeros demônios.

Então...

morre.

Não em uma batalha épica.

Não enfrentando o Rei Demônio.

Mas caindo numa armadilha cavada por um fazendeiro chamado Touka Scott, que apenas queria proteger seus rabanetes.

Como o mundo não pode existir sem um herói, a necromante Anri transfere a alma de Touka para o corpo de Sion.

Agora um rapaz preguiçoso, egoísta, extremamente tarado e completamente despreparado precisa convencer o mundo inteiro de que continua sendo o lendário herói.


Resumo da História

A aventura acompanha Touka tentando manter a fachada enquanto enfrenta monstros, demônios, cavaleiros e conspirações.

Enquanto todos esperam atitudes heroicas...

ele tenta sobreviver sem ser descoberto.

O humor nasce justamente da enorme diferença entre:

  • quem todos acreditam que ele seja;

  • quem ele realmente é.

Esse contraste sustenta praticamente toda a narrativa.


Os Personagens

Touka Scott

Talvez um dos protagonistas mais anti-heróicos dos últimos anos.

É preguiçoso.

Perverso.

Covarde.

Inteligente.

Criativo.

Apesar dos defeitos, frequentemente resolve problemas usando lógica em vez de força.

No universo Mainframe seria:

Um operador júnior que recebeu autoridade SPECIAL no RACF por acidente.


Sion Bladan

O herói perfeito.

Ou melhor...

o corpo perfeito.

Porque sua alma desaparece logo no início.

Sua presença continua existindo apenas como "hardware".


Anri Haysworth

Necromante responsável pela transferência das almas.

É praticamente o software de virtualização do anime.

Sem ela, nada continuaria funcionando.


Yuna Eunice

Amiga de infância de Touka.

Arqueira habilidosa.

Representa o elo emocional da história e ajuda a equilibrar a personalidade caótica do protagonista.


Marguerit Farom

Princesa forte e determinada que amplia o escopo político da narrativa e evidencia que o conflito vai além da simples luta contra monstros.


Temática

Apesar da aparência de comédia ecchi, o anime aborda temas interessantes:

Identidade

Quem somos?

Nosso corpo?

Nossa fama?

Ou nossas ações?


Aparências

O mundo continua acreditando no herói.

Mesmo ele não existindo mais.

Quantas vezes fazemos isso na vida real?

Empresas.

Celebridades.

Políticos.

Sistemas legados.

Todos continuam funcionando porque ninguém percebeu que "o verdadeiro operador" já saiu há muito tempo.


Competência versus Reputação

Sion possui reputação.

Touka desenvolve competência.

O anime mostra que as duas coisas nem sempre caminham juntas.


O que torna este anime diferente?

Aqui praticamente todos os clichês são invertidos.

O herói morre imediatamente.

O protagonista não quer salvar ninguém.

O maior guerreiro do mundo vira apenas um corpo vazio.

O camponês inútil resolve problemas melhor do que vários cavaleiros.

O humor frequentemente vence batalhas que normalmente seriam resolvidas com espadas.

Essa desconstrução lembra bastante o que Konosuba fez com os isekais, mas aplicada ao arquétipo clássico do herói lendário.


As Aventuras

Durante a jornada encontramos:

  • exércitos demoníacos;

  • necromantes;

  • monstros;

  • castelos;

  • magia;

  • política;

  • conspirações;

  • batalhas;

  • cidades destruídas;

  • segredos do passado;

  • antigas maldições.

Embora a série pareça episódica, existe uma narrativa maior envolvendo o verdadeiro destino do mundo e a origem dos conflitos.


As Mensagens Ocultas

O cargo não faz a pessoa.

O uniforme do herói não cria um herói.


Improvisação também salva sistemas.

Nem todo problema exige o especialista perfeito.

Às vezes alguém criativo encontra soluções inesperadas.


A perfeição é uma ilusão.

Sion parece perfeito.

Touka parece um desastre.

No fim, ambos possuem limitações.


A sociedade idolatra símbolos.

Poucos percebem quem realmente está fazendo o trabalho.


☕ Bellacosa Mainframe

Quando o Herói Morre, Mas a LPAR Continua Ativa

Imagine um ambiente IBM Z.

O Sysprog responsável pela produção sofre um desastre inesperado.

O ambiente não pode parar.

O WLM precisa agir imediatamente.

Então acontece algo impossível.

A Address Space continua viva.

Mas a alma do operador foi substituída.

Agora um estagiário ocupa exatamente o mesmo TSO ID.

O RACF continua aceitando.

O JES2 continua escalonando.

O CICS continua online.

O Db2 continua respondendo.

Todos acreditam que o lendário especialista ainda está operando.

Só que, nos bastidores, quem toma as decisões é alguém que nunca leu o manual do MVS.

Cada comando emitido parece um MODIFY em produção sem Change Request aprovado. Cada solução improvisada lembra um operador que resolve incidentes usando criatividade em vez de documentação. O resultado é surpreendente: apesar do caos inicial, o ambiente continua disponível porque adaptabilidade, observação e raciocínio prático acabam compensando a falta de experiência formal.

A grande ironia é que muitos datacenters sobrevivem justamente graças a profissionais que aprenderam "na guerra", e não porque tinham o currículo perfeito.


Houve censura?

Não houve censura significativa à obra, mas alguns aspectos chamaram atenção:

  • Emissoras e plataformas internacionais aplicaram cortes leves ou escurecimento de algumas cenas ecchi, prática comum para transmissões televisivas no Japão.

  • A série recebeu classificação etária mais alta em diversos países devido à combinação de humor sexual, violência cartunesca e nudez parcial.

  • Não há registros de proibição ampla ou de alterações substanciais na história por motivos políticos ou ideológicos.


Impacto Cultural

Embora não tenha alcançado o fenômeno de séries como Konosuba, Mushoku Tensei ou Re:ZERO, Yūsha ga Shinda! conquistou um público fiel por sua capacidade de subverter o arquétipo do herói tradicional. O mangá teve uma publicação longa e consistente, e o anime ajudou a ampliar sua visibilidade internacional.

A obra também reforçou uma tendência moderna da fantasia japonesa: questionar a figura do "escolhido" e mostrar protagonistas falhos, egoístas ou improváveis que crescem ao longo da jornada. Em vez de glorificar a perfeição, a série celebra a improvisação, a inteligência prática e a capacidade de se adaptar quando tudo parece condenado ao fracasso.


Vale a pena assistir?

Se você procura uma fantasia séria, cheia de discursos épicos e heróis impecáveis, talvez este não seja o anime ideal.

Mas, se aprecia paródias inteligentes, personagens imperfeitos e uma aventura que transforma os clichês do gênero em combustível para o humor, Yūsha ga Shinda! entrega uma experiência divertida e surpreendentemente reflexiva.

No universo Bellacosa Mainframe, ele deixa uma lição memorável:

"Todo datacenter precisa de um plano de Disaster Recovery. O problema começa quando o único backup disponível é um fazendeiro que cava armadilhas para proteger rabanetes e acaba herdando a LPAR mais crítica do reino."

sábado, 28 de outubro de 2023

🕯️ Parte 6 – A Filosofia do Casulo: O Que o Hikikomori Ensina Sobre o Mundo Moderno

🕯️ Parte 6 – A Filosofia do Casulo: O Que o Hikikomori Ensina Sobre o Mundo Moderno



 Entre o ruído do mundo e o sussurro do ser


🌌 Introdução – O Casulo Não é Prisão, É Metamorfose

Vivemos em uma era que confunde silêncio com fraqueza e isolamento com desistência.
Mas o hikikomori — essa figura tão mal compreendida da sociedade japonesa — é mais do que um sintoma: é um espelho filosófico da era digital.

O casulo não é fuga.
É pausa.
É o instante em que a alma tenta se reconfigurar diante de um mundo rápido demais para senti-la.

“Antes de voar, a borboleta precisa aprender a estar sozinha.”
Bellacosa Mainframe


💻 O Mundo Externo Acelerou, o Interno Parou

O século XXI exige movimento constante — produtividade, presença, performance.
Mas o hikikomori representa o antídoto radical a esse ritmo:
ele diz “não” à lógica da pressa.
E nesse “não”, há filosofia.

Enquanto o mundo corre para fora, ele caminha para dentro.
Enquanto todos buscam visibilidade, ele busca sentido.

No silêncio do quarto, ele realiza uma forma de resistência suave —
um protesto existencial contra o excesso.


🪞 O Casulo Como Espelho Espiritual

O Japão, em sua tradição estética, valoriza o “ma” (間) — o espaço entre as coisas, o respiro que dá forma ao todo.
O hikikomori vive dentro desse ma: o intervalo entre o mundo e o eu, entre o ruído e o pensamento.

Lá, o tempo desacelera.
As ideias amadurecem.
A identidade se refaz com cuidado.

O casulo, então, se torna um laboratório da alma moderna.
É ali que o indivíduo tenta se reconciliar com o que é essencial, longe das distrações do espetáculo social.


⚙️ A Filosofia Digital do Recolhimento

Curiosamente, a era da conexão infinita gerou a solidão mais densa da história.
As pessoas falam mais, mas escutam menos.
Postam mais, mas sentem menos.

O hikikomori compreendeu cedo esse paradoxo.
Ele se desconecta não por incapacidade, mas por excesso de lucidez: percebeu que o mundo digital exige presença constante, mas raramente oferece presença verdadeira.

“O silêncio do quarto é mais honesto que o barulho das notificações.”
Bellacosa Mainframe


🧠 O Hikikomori Como Filósofo Contemporâneo

Se pensadores antigos se isolavam em desertos ou monastérios,
o hikikomori se isola num quarto de oito tatames, iluminado por uma tela.

Ele é, em muitos aspectos, um monge tecnológico:
sua cela é digital, sua meditação é introspecção, e sua religião é a tentativa de se reencontrar.

Como Diógenes em seu barril ou Thoreau em Walden,
o hikikomori observa o mundo de fora para entendê-lo melhor —
um observador do caos moderno.


🎭 A Lição Oculta – O Valor do Intervalo

O hikikomori ensina que parar também é uma forma de seguir.
Que o humano precisa do “não-fazer” para se reencontrar com o sentido de “ser”.

Seu isolamento é, paradoxalmente, um gesto de presença autêntica.
Ele diz:

“Prefiro estar ausente do mundo do que ausente de mim mesmo.”

E é por isso que, quando retorna, o faz com mais clareza, mais compaixão e mais profundidade.


🕊️ Dicas Filosóficas Bellacosa – Aplicando o Casulo à Vida Moderna

  1. Pratique o silêncio digital.
    Um dia sem notificações é uma conversa com o próprio ser.

  2. Crie espaços de pausa.
    Um café à janela pode ser um ritual de reintegração interior.

  3. Não tema a solidão — cultive-a.
    Ela é o solo onde nasce a lucidez.

  4. Reavalie o sucesso.
    Às vezes, sucesso é apenas poder respirar sem culpa.

  5. Transforme o quarto em templo.
    Não de isolamento, mas de criação e contemplação.


🌙 O Casulo e o Mundo

O hikikomori não é o fim da linha, mas um espelho do que o mundo se tornou.
Cada vez mais, vivemos cercados, conectados e exaustos — e o ato de se recolher talvez seja a única forma de reencontrar o humano que se perdeu na pressa.

No fundo, ele nos ensina algo simples e eterno:

  • que a introspecção não é fraqueza,

  • que o silêncio é um idioma,

  • e que a solidão, quando bem vivida, é o primeiro passo da sabedoria.


☕ Epílogo – O Ouro Dentro da Concha

No fim, o hikikomori é o filósofo do século XXI:
aquele que percebeu que há mais verdade na lentidão do amanhecer do que em mil feeds atualizados.

Quando finalmente abre a porta, ele não volta como quem perdeu tempo —
mas como quem voltou inteiro.

“A borboleta não explica o casulo.
Apenas o honra, cada vez que abre as asas.”
Bellacosa 

sexta-feira, 27 de outubro de 2023

🐻☕ Kuma Kuma Kuma Bear Punch! (くま クマ 熊 ベアーぱーんち!): A Atualização sem Janela de Manutenção — Quando a Melhor Evolução é Aquela que Ninguém Percebe

 

Bellacosa Mainframe e segunda temporada de kuma kuma kuma bear punch

🐻☕ Kuma Kuma Kuma Bear Punch! (くま クマ 熊 ベアーぱーんち!): A Atualização sem Janela de Manutenção — Quando a Melhor Evolução é Aquela que Ninguém Percebe

"No mundo do IBM Mainframe existe um princípio sagrado: uma atualização perfeita é aquela que melhora desempenho, amplia capacidade e adiciona funcionalidades sem que os usuários percebam qualquer interrupção. A segunda temporada de Kuma Kuma Kuma Bear mostra exatamente essa filosofia."


☕ Um Café no Bellacosa Mainframe

Existe um erro muito comum entre profissionais iniciantes.

Eles acreditam que evoluir um sistema significa adicionar mais funcionalidades.

Os arquitetos experientes sabem que não.

A verdadeira evolução acontece quando o sistema amadurece.

É exatamente isso que acontece em Kuma Kuma Kuma Bear Punch!.

A primeira temporada apresentou Yuna.

A segunda apresenta o legado que ela começa a construir.

Não é mais uma história sobre alguém extremamente forte.

É sobre alguém extremamente confiável.

Assim como acontece com um ambiente IBM Z em produção.


Ficha Técnica

Título original

くま クマ 熊 ベアーぱーんち!

(Kuma Kuma Kuma Bear Punch!)

O subtítulo "Punch!" não representa uma mudança radical de proposta. Ele funciona como uma brincadeira com a personalidade da protagonista: aparentemente delicada, mas capaz de resolver qualquer problema quando necessário.


Obra original

Autor

Kumanano (くまなの)

Ilustrador da Light Novel

029 (Oniku)


Publicação

  • Web Novel: 2014

  • Light Novel: 2015

  • Mangá: 2018


Anime

Primeira temporada

Outubro de 2020

Segunda temporada

3 de abril de 2023

Exibição até

19 de junho de 2023


Estúdio

EMT Squared

O estúdio manteve praticamente toda a equipe principal.

Isso garantiu:

  • identidade visual consistente;

  • animação uniforme;

  • direção artística confortável;

  • personagens ainda mais expressivos.

Ao invés de reinventar a série, preferiu refiná-la.

É exatamente a filosofia de um Sysprog experiente.

Não se troca aquilo que funciona.

Melhora-se discretamente.


Direção

Hisashi Ishii

A direção entende muito bem o tipo de anime que está produzindo.

Não tenta transformar Kuma Kuma Kuma Bear em um shounen de batalhas.

Preserva seu ritmo contemplativo.


Música

A trilha sonora continua extremamente acolhedora.

Há forte uso de:

  • piano;

  • cordas suaves;

  • melodias otimistas.

Ela reforça constantemente a sensação de conforto.


Classificação

Gêneros

  • Isekai

  • Slice of Life

  • Fantasy

  • Comédia

  • Slow Life

  • Aventura

Classificação indicativa

12 anos

Violência leve.

Sem gore.

Sem terror.

Sem conteúdo adulto relevante.


Episódios

A segunda temporada possui

12 episódios

Totalizando

aproximadamente

290 minutos de conteúdo.


Sinopse

Após conquistar estabilidade em Crimonia, Yuna percebe que manter um ambiente saudável é mais difícil do que criá-lo.

Agora seus desafios deixam de ser apenas monstros.

Ela passa a enfrentar problemas sociais, econômicos e administrativos.

Cada aventura melhora um aspecto do reino.


Resumo

A série amplia o universo.

Conhecemos:

  • novas cidades;

  • novas culturas;

  • novas relações;

  • novas responsabilidades.

Yuna continua absurdamente poderosa.

Mas cada vez luta menos.

Sua verdadeira força passa a ser sua capacidade de organizar pessoas.


História

A narrativa evolui para algo muito próximo da administração pública.

Os episódios abordam:

  • educação;

  • infraestrutura;

  • abastecimento;

  • comércio;

  • assistência social;

  • transporte;

  • segurança.

Poucos isekais investem tanto na melhoria do cotidiano.


Os personagens continuam evoluindo

Yuna

A mudança é sutil.

Ela torna-se mais madura.

Mais paciente.

Mais preocupada com os outros.

Começa a agir como uma verdadeira líder.


Fina

Recebe maior desenvolvimento emocional.

A amizade entre as duas torna-se ainda mais sólida.

Ela deixa de ser apenas ajudante.

Torna-se parceira.


Shuri

Continua trazendo leveza.

Representa esperança.


Flora

Sua relação com Yuna aprofunda-se.

É uma das personagens mais simpáticas da temporada.


Kumayuru e Kumakyu

Os dois ursos aparecem em momentos importantes.

Funcionam como símbolo constante da identidade de Yuna.


O grande diferencial da segunda temporada

A primeira temporada respondia:

"Como sobreviver?"

A segunda pergunta:

"Como construir uma sociedade sustentável?"

Essa mudança altera completamente o foco narrativo.

As batalhas tornam-se consequência.

Não objetivo.


O verdadeiro tema

Poucos espectadores percebem.

A segunda temporada fala sobre

governança.

Yuna resolve problemas estruturais.

Não emergenciais.

Ela pensa décadas à frente.

Como um arquiteto corporativo.


A metáfora perfeita para IBM Mainframe

Imagine um ambiente IBM Z que já está estável.

Agora chega o momento mais difícil.

Não basta funcionar.

É preciso:

  • escalar;

  • documentar;

  • automatizar;

  • treinar pessoas;

  • integrar sistemas;

  • reduzir custos;

  • manter disponibilidade.

Isso é exatamente o que Yuna faz.

Ela não "salva" o mundo.

Ela melhora continuamente o mundo.

É o equivalente a uma atualização de z/OS aplicada sem downtime: novas capacidades aparecem, mas os usuários continuam trabalhando normalmente.


A filosofia DevOps

Toda decisão de Yuna segue princípios modernos de engenharia:

  • automação antes do trabalho manual;

  • prevenção antes da correção;

  • simplicidade antes da complexidade;

  • colaboração antes da competição;

  • estabilidade antes da inovação irresponsável.

Ela nunca procura ser a protagonista.

Procura tornar o sistema resiliente.


As aventuras

Ao longo da temporada, Yuna participa de diversas jornadas que vão além do combate:

  • proteção de crianças e órfãos;

  • resolução de conflitos locais;

  • melhoria da alimentação da população;

  • fortalecimento do comércio;

  • exploração de novas regiões;

  • enfrentamento de monstros quando necessário;

  • auxílio à família de Fina;

  • apoio à nobreza em problemas administrativos;

  • fortalecimento dos laços entre diferentes comunidades.

Cada aventura funciona como uma pequena intervenção de engenharia social, mostrando que mudar um mundo depende mais de organização e empatia do que de força.


As mensagens ocultas

O poder deve servir

Yuna nunca utiliza sua força para dominar.

Ela a coloca a serviço da comunidade.


Crescimento sustentável

Expandir não significa crescer desordenadamente.

Todo crescimento precisa de planejamento.


Liderança técnica

Ela lidera pelo exemplo.

Jamais pelo cargo.


Infraestrutura invisível

As melhores melhorias são aquelas que passam despercebidas.

Como acontece com um excelente Sysprog.


Competência silenciosa

Ela nunca precisa anunciar que é forte.

Seu trabalho fala por ela.


A crítica social

A segunda temporada amplia críticas sutis presentes desde o início:

  • desigualdade econômica;

  • abandono infantil;

  • burocracias ineficientes;

  • abuso de poder;

  • excesso de dependência de figuras heroicas.

Yuna responde a esses problemas fortalecendo instituições e comunidades, não criando dependência de sua presença.


Impacto cultural

Embora não tenha alcançado a popularidade massiva de franquias como Re:Zero, Mushoku Tensei ou Overlord, Kuma Kuma Kuma Bear Punch! consolidou a série como uma das principais representantes do subgênero slow life isekai. A temporada reforçou a tendência de histórias focadas em qualidade de vida, cooperação e desenvolvimento humano, influenciando discussões entre fãs sobre a diversidade de narrativas dentro do isekai.

Também fortaleceu a imagem de Yuna como uma protagonista feminina competente, independente e livre de muitos clichês do gênero.


Houve censura?

Não houve censura significativa.

A adaptação manteve o tom leve da obra original. Algumas passagens da light novel foram resumidas ou reorganizadas para caber em doze episódios, mas isso faz parte do processo normal de adaptação. Não há registros de cortes relevantes por motivos políticos, religiosos ou de classificação indicativa.


O que a segunda temporada ensina?

Que estabilidade é mais difícil do que conquista.

Qualquer um pode construir algo novo.

Poucos conseguem mantê-lo funcionando.

Essa talvez seja a maior lição para profissionais de infraestrutura, arquitetos de software e administradores de IBM Z.


☕ Conclusão Bellacosa Mainframe

Se a primeira temporada representava a implantação de um novo ambiente, Kuma Kuma Kuma Bear Punch! simboliza a fase mais crítica de qualquer sistema corporativo: a evolução contínua sem interrupções. Yuna demonstra que confiabilidade não nasce de grandes feitos, mas da soma de decisões pequenas, consistentes e bem planejadas.

Para quem trabalha com IBM Mainframe, a analogia é imediata: o verdadeiro valor de um ambiente z/OS não está em impressionar com tecnologia visível, mas em permanecer disponível, seguro e eficiente durante anos. Assim como um Sysprog experiente, Yuna prefere prevenir falhas a corrigi-las, fortalecer processos em vez de improvisar soluções e construir confiança em vez de buscar reconhecimento.

Nota Bellacosa Mainframe: ⭐⭐⭐⭐⭐ (5/5)

"A primeira temporada mostrou que um sistema pode ser poderoso. A segunda prova que a verdadeira excelência está em evoluir continuamente sem perder a estabilidade. É assim que grandes ambientes IBM Z permanecem relevantes por décadas."

quinta-feira, 26 de outubro de 2023

🚪 Parte 5 – O Retorno: Quando o Hikikomori Decide Abrir a Porta

🚪 Parte 5 – O Retorno: Quando o Hikikomori Decide Abrir a Porta



 Ecos do renascimento silencioso


🌤️ Introdução – O Som do Mundo Voltando

No Japão, há uma palavra suave e poderosa: kaeru (帰る) — voltar para casa.
Mas e quando a casa é justamente o lugar do exílio?
Para o hikikomori, o “voltar” não é apenas sair do quarto, mas reaprender o contato com o mundo, passo a passo, como quem pisa em um novo planeta.

A porta entre o dentro e o fora não é de madeira — é feita de medo, culpa e esperança.
E quando ela finalmente se abre, não se ouve o som de uma fechadura — mas o de um renascimento.


🕊️ O Despertar Interior

O retorno do hikikomori começa muito antes de ele tocar a maçaneta.
Começa em pequenos gestos:

  • responder a uma mensagem,

  • abrir a janela,

  • trocar o dia pela madrugada.

Esses gestos são microvitórias invisíveis.
Cada uma delas é um ensaio para o mundo.
É o corpo e a alma testando o quanto já podem suportar da realidade.

“O sol entra primeiro pelos olhos, não pela janela.”
Bellacosa Mainframe


🧭 Os Estágios do Retorno

  1. Reconhecimento – o momento em que o hikikomori percebe que não está “curado”, mas pronto para tentar.

  2. Contato Virtual Saudável – a interação online muda de fuga para aprendizado e troca genuína.

  3. Primeira Saída – não há data marcada. Às vezes é só descer até a caixa do correio.

  4. Reintegração Gradual – o reencontro com o mundo acontece em camadas, não de uma vez.

  5. Novo Propósito – a vida deixa de ser sobrevivência e volta a ser criação.


💬 A Sociedade e o Abraço Possível

O erro mais comum é tentar “curar” o hikikomori à força.
A reintegração não é imposição — é acolhimento.
O Japão aprendeu isso criando centros comunitários, clubes de hobbies, e programas de mentoria anônima, onde antigos hikikomoris ajudam os novos a dar o primeiro passo.

A chave não é a pressão, mas o diálogo sem julgamento.
O mundo não precisa ser reaberto — apenas tornado habitável novamente.


📺 Exemplos em Anime – Quando a Ficção Abre a Porta

🕶️ Welcome to the NHK

O momento mais simbólico é quando Satou, após inúmeros colapsos, decide sair e encarar o sol.
Ele tropeça, hesita, mas continua — porque compreende que o mundo, mesmo imperfeito, ainda é o palco da esperança.

🧢 ReLIFE

Arata, o protagonista, retorna à sociedade com a ajuda de um experimento que o faz reviver o ensino médio.
O anime mostra que o retorno não é apagar o passado, mas ressignificá-lo.

🌙 March Comes in Like a Lion

Rei Kiriyama, isolado pela dor e pelo peso da genialidade, encontra no shōgi e nas conexões humanas a saída para sua apatia.
O retorno, nesse caso, é emocional antes de ser social.


🌱 Dicas Bellacosa – A Arte de Reabrir o Mundo

  1. Saia para dentro. Antes de enfrentar o mundo, entenda o que dentro de você pede espaço.

  2. Transforme o medo em rotina. Caminhar até o portão pode ser o treino do guerreiro moderno.

  3. Cultive vínculos pequenos. Um café, uma conversa, um “olá” no mercado — o retorno é feito de gentilezas.

  4. Redefina o sucesso. Não é ser como antes, é ser mais consciente do agora.

  5. Não quebre o casulo — floresça dele. A saída deve ser natural, não forçada.


🧘 O Simbolismo do Retorno

Na filosofia japonesa, o conceito de “Kintsugi” ensina que quando algo se quebra, o reparo com ouro o torna mais belo.
O hikikomori, ao voltar, carrega cicatrizes douradas — cada medo superado é uma linha brilhante no vaso da alma.

A reintegração não apaga o passado, ela o ilumina.

“O mundo é vasto, mas o primeiro passo sempre cabe dentro do quarto.”
Bellacosa Mainframe


☕ Conclusão – A Porta entre Dois Mundos

O hikikomori não é apenas o que se isolou, mas o que descobriu um modo diferente de sentir o tempo.
Ao retornar, ele traz consigo uma sabedoria silenciosa:
a de quem sabe o valor do som da chuva, do toque de um copo quente, do vento entrando pela janela.

O retorno não é o fim da jornada,
mas o início de uma nova forma de estar vivo —
com mais suavidade, mais verdade e menos pressa.

quarta-feira, 25 de outubro de 2023

COBOL Recursivo sem Mistérios

 

Bellacosa Mainframe dicas e pratica em cobol mainframe recursivo

☕ Um Café no Bellacosa Mainframe

COBOL Recursivo sem Mistérios

Como Programar Funções Recursivas e Percorrer Árvores B como um Oficial da Frota Estelar

"A maioria dos programadores COBOL passa décadas escrevendo programas sem nunca utilizar recursividade. Não porque ela não exista. Mas porque o universo do processamento batch sempre favoreceu algoritmos iterativos. Entretanto, quando você entra no mundo de compiladores, parsers, XML, JSON, árvores de decisão, estruturas hierárquicas e inteligência artificial, descobrirá que existe uma arma secreta escondida dentro do Enterprise COBOL."

Prepare seu café.

Hoje o Capitão Kirk autorizou acesso aos bancos de dados mais profundos da USS Enterprise.

Vamos explorar uma tecnologia que muitos acreditam que COBOL "não possui".

Possui.

E muito bem.


O mito

Existe uma frase repetida há décadas:

"COBOL não suporta recursividade."

Isso era verdade...

...há muitos anos.

Desde o Enterprise COBOL moderno, programas podem chamar a si próprios.

Basta utilizar as opções corretas do compilador.

E entender o que realmente acontece na memória.


O que é recursividade?

Recursividade é quando um programa chama...

...ele mesmo.

Exemplo extremamente simples.

Imagine contar regressivamente.

5
4
3
2
1
Fim

Ao invés de fazer:

PERFORM VARYING

fazemos

CONTAR(5)

↓

CONTAR(4)

↓

CONTAR(3)

↓

CONTAR(2)

↓

CONTAR(1)

Cada chamada cria uma nova execução independente.


Pensando como Spock

Spock não resolveria um problema inteiro.

Ele dividiria.

Sempre.

Existe solução?

↓

Resolva um pedaço

↓

O restante é igual

↓

Chame novamente

Isso é exatamente recursividade.


Como o COBOL consegue fazer isso?

Cada chamada cria uma nova área de trabalho.

Ela contém:

  • variáveis locais

  • parâmetros

  • ponteiros

  • retorno

Tudo fica armazenado na pilha (Stack).

Visualmente.

MAIN

↓

PROGRAMA

↓

PROGRAMA

↓

PROGRAMA

↓

PROGRAMA

Cada nível ocupa memória.


Por isso existe um risco

Se esquecer a condição de parada...

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

↓

Programa

Nunca termina.

Resultado:

Stack Overflow

Ou

S878

S80A

Storage Exhausted

Dependendo do ambiente.


A regra número 1

Toda função recursiva precisa possuir uma condição de parada.

Sempre.

Exemplo.

IF N = ZERO
    EXIT
END-IF

Sem isso...

adeus memória.


Ativando recursividade

No Enterprise COBOL normalmente utiliza-se

RECURSIVE

na identificação do programa.

IDENTIFICATION DIVISION.

PROGRAM-ID. TREESEARCH
    RECURSIVE.

ou opção equivalente do compilador dependendo da versão.

Outra prática comum é utilizar:

RENT

para permitir reentrância.


Reentrante x Recursivo

São conceitos diferentes.

Reentrante

→ vários usuários usam ao mesmo tempo.

Recursivo

→ o programa chama ele próprio.

Pode existir:

✔ Reentrante

sem ser

✔ Recursivo.


Quando utilizar?

Quando o problema possui natureza hierárquica.

Por exemplo.

Árvore.

XML.

JSON.

AST de compilador.

Pastas.

Menus.

Dependências.

Organogramas.

Genealogia.

Árvore de chamadas.


Imagine uma árvore B

Uma árvore B organiza registros.

             40

      20            60

   10   30      50     70

Encontrar um valor nela é extremamente elegante usando recursividade.


Estrutura lógica

Cada nó possui

Valor

Filho esquerdo

Filho direito

No COBOL real normalmente usamos tabelas e índices.

Exemplo didático.

NODE-ID

LEFT-CHILD

RIGHT-CHILD

Nossa missão

Encontrar

50

Algoritmo

Primeiro olhamos

40

50 é maior.

Então ignoramos todo lado esquerdo.

Seguimos para direita.

60

Agora

50 é menor.

Voltamos para esquerda.

Encontramos

50

Fim.


Em pseudocódigo

SEARCH(NODE)

IF NODE = NULL
    NÃO EXISTE

IF NODE = CHAVE
    ENCONTROU

SE CHAVE < NODE
    SEARCH(LEFT)

SENÃO
    SEARCH(RIGHT)

Perceba.

O algoritmo inteiro possui poucas linhas.

Porque ele reutiliza a própria lógica.


Exemplo COBOL simplificado

IDENTIFICATION DIVISION.
PROGRAM-ID. TREESEARCH RECURSIVE.

WORKING-STORAGE SECTION.

01 WS-KEY          PIC 9(4).

LINKAGE SECTION.

01 LK-NODE.
   05 LK-VALUE     PIC 9(4).
   05 LK-LEFT      POINTER.
   05 LK-RIGHT     POINTER.

PROCEDURE DIVISION USING LK-NODE.

    IF LK-NODE = NULL
        GOBACK
    END-IF

    IF WS-KEY = LK-VALUE
        DISPLAY "ENCONTRADO"
        GOBACK
    END-IF

    IF WS-KEY < LK-VALUE
        CALL "TREESEARCH"
             USING LK-LEFT
    ELSE
        CALL "TREESEARCH"
             USING LK-RIGHT
    END-IF.

    GOBACK.

Este exemplo é conceitual. Em aplicações reais, árvores costumam ser representadas por tabelas indexadas, estruturas dinâmicas com ALLOCATE/FREE (quando suportado) ou áreas obtidas por serviços do sistema.


Observe a mágica

O programa nunca pergunta

Estou no nível 2?

Estou no nível 5?

Estou no nível 30?

Ele simplesmente chama ele mesmo.


Visualizando a pilha

SEARCH(40)

↓

SEARCH(60)

↓

SEARCH(50)

↓

Encontrado

Depois começa retornar.

SEARCH(50)

↓

SEARCH(60)

↓

SEARCH(40)

↓

MAIN

É literalmente uma subida e descida.


O retorno automático

Cada chamada lembra onde parou.

Imagine.

A chama B

↓

B chama C

↓

C chama D

Quando D termina.

Volta para C.

Depois B.

Depois A.

Sem que você precise controlar isso.


Onde COBOL utiliza isso na prática?

Mais do que muitos imaginam.

Ferramentas IBM fazem uso intenso.

Compiladores COBOL.

Parser SQL.

Parser XML.

JSON Parser.

XPath.

XSD.

Analisadores sintáticos.

Motores de regras.


Árvore B em bancos

Db2 utiliza árvores B (B-Trees).

Quando fazemos

SELECT

WHERE CPF

O banco NÃO lê milhões de registros.

Ele navega pela árvore.

Raiz

↓

Nó

↓

Folha

Pouquíssimos acessos.


Curiosidade

Quando você cria

CREATE INDEX

Na prática.

Está construindo uma enorme árvore balanceada.


Então...

Todo programador COBOL usa árvore B.

Mesmo sem perceber.


Mas...

Devemos escrever árvore recursiva sempre?

Não.

Existe um preço.


CPU

Cada chamada possui custo.

Salvar registradores

↓

Criar stack frame

↓

Passar parâmetros

↓

Retornar

Tudo isso consome CPU.


Memória

Cada chamada cria.

Variáveis

Endereço retorno

Parâmetros

Estado

Imagine 100.000 níveis.

Pode explodir.


Comparando

Iterativo

WHILE

Consome

CPU menor

Memória fixa

Recursivo

CPU maior

Stack crescente

Então por que usar?

Porque alguns problemas ficam absurdamente mais simples.

Exemplo.

Árvore.

Iterativo

300 linhas

Recursivo

40 linhas

Mais fácil.

Mais elegante.

Menos bugs.


Quando evitar?

Processamento sequencial.

Leitura VSAM.

Arquivo QSAM.

Loops simples.

Relatórios.

Batch tradicional.

Nestes casos.

PERFORM VARYING

vence.


Tail Recursion

Existe uma otimização famosa.

Tail Recursion.

Função termina chamando ela mesma.

Alguns compiladores eliminam o crescimento da pilha.

Infelizmente.

Nem todo compilador COBOL faz isso.

Portanto.

Nunca conte com essa otimização.


Cuidado com milhões de chamadas

Imagine uma árvore degenerada.

10

 \

 20

   \

   30

     \

     40

Ela parece uma lista.

A recursividade fará milhares de chamadas.

Ruim.

Árvores balanceadas evitam isso.


B-Tree resolve exatamente este problema

Ela mantém altura pequena.

Mesmo com milhões de registros.

É justamente por isso que bancos usam B-Tree.

Não Binary Tree simples.


Dica de ouro

Nunca escreva recursividade sem antes responder:

Qual é minha condição de parada?

Se não conseguir responder.

Ainda não terminou o algoritmo.


Outra dica

Desenhe.

Sempre.

Árvores ficam muito mais fáceis no papel.


Debug

Durante testes faça:

DISPLAY

Mostrando o nível.

DISPLAY "LEVEL=" WS-NIVEL

Assim você visualiza a profundidade.


Performance em Mainframe

No IBM Z.

CPU é dinheiro.

Cada microssegundo importa.

Por isso.

Recursividade costuma aparecer mais em:

  • middleware

  • compiladores

  • parsers

  • XML

  • JSON

  • IA

  • engines

Do que em batch financeiro.


Curiosidade histórica

Nos anos 70.

Poucos compiladores COBOL aceitavam recursividade.

A memória era extremamente cara.

Muitas máquinas tinham poucos megabytes.

Era impensável desperdiçar stack.

Hoje.

Servidores IBM Z possuem centenas de gigabytes.

O cenário mudou.


Boas práticas

✔ Sempre tenha condição de parada clara.

✔ Documente a lógica antes de codificar.

✔ Prefira árvores balanceadas.

✔ Limite profundidade quando possível.

✔ Evite variáveis globais compartilhadas.

✔ Teste casos extremos.

✔ Monitore consumo de CPU e memória.

✔ Utilize recursividade apenas quando ela realmente simplifica o problema.

✔ Faça revisão de código focando em chamadas recursivas.

✔ Meça desempenho antes de concluir que a solução é "rápida".


Armadilhas comuns

❌ Esquecer a condição de parada.

❌ Modificar dados globais inesperadamente.

❌ Assumir que toda árvore é balanceada.

❌ Ignorar consumo de stack.

❌ Trocar elegância por complexidade desnecessária.

❌ Usar recursividade onde um PERFORM VARYING resolveria de forma mais simples.


Recursividade e Enterprise COBOL

As versões modernas do IBM Enterprise COBOL oferecem suporte a programas recursivos, mas é importante observar alguns detalhes:

  • Declare o programa como RECURSIVE quando necessário.

  • Utilize opções de compilação adequadas ao ambiente, frequentemente combinadas com RENT em aplicações compartilhadas.

  • Consulte sempre o padrão adotado pela sua empresa e a documentação da versão do compilador em uso, pois políticas de compilação variam entre instalações.

Em ambientes CICS, IMS ou aplicações de alta concorrência, também é essencial compreender os conceitos de reentrância, armazenamento automático e áreas de trabalho para evitar efeitos colaterais entre execuções simultâneas.


Missão para o Padawan COBOL

Depois de dominar este artigo, experimente implementar os seguintes desafios:

  1. Fatorial usando recursividade.

  2. Sequência de Fibonacci (comparando desempenho com versão iterativa).

  3. Percorrer uma árvore binária em ordem (in-order).

  4. Percorrer uma árvore em pré-ordem (pre-order).

  5. Percorrer uma árvore em pós-ordem (post-order).

  6. Simular um índice de clientes usando uma árvore binária simples.

  7. Comparar o tempo de busca entre uma tabela sequencial e uma árvore.

  8. Criar um visualizador com DISPLAY mostrando o nível de cada chamada recursiva.

Cada exercício ajudará você a entender não apenas como a recursividade funciona, mas quando ela é realmente a melhor ferramenta.

Conclusão — O Holodeck da Recursividade

Existe uma lição que diferencia um programador comum de um verdadeiro oficial da Frota Estelar.

O iniciante procura resolver problemas escrevendo mais código.

O engenheiro experiente procura resolver problemas encontrando a estrutura correta.

A recursividade é exatamente isso: uma mudança de perspectiva. Em vez de atacar um problema gigantesco de uma única vez, você o divide em pequenas partes idênticas, permitindo que o próprio algoritmo repita a solução até alcançar a condição de parada.

No universo do COBOL, ela não substitui os tradicionais PERFORM VARYING, nem foi criada para processar milhões de registros sequenciais de um batch financeiro. Seu verdadeiro poder aparece quando trabalhamos com estruturas hierárquicas: árvores B, XML, JSON, compiladores, interpretadores, mecanismos de regras, grafos e diversos algoritmos modernos que fazem parte da computação atual.

Como diria o Sr. Spock:

"A solução mais elegante normalmente é aquela que respeita a estrutura natural do problema."

Quando você compreender essa filosofia, deixará de enxergar a recursividade como um truque de linguagem e passará a vê-la como uma ferramenta de modelagem.

E esse é um dos momentos em que um Padawan COBOL começa a trilhar o caminho para se tornar um verdadeiro Mestre do Mainframe.


terça-feira, 24 de outubro de 2023

Docker sem Mistérios : O Guia Definitivo para um Programador COBOL Padawan Entender Containers, DevOps e a Nova Engenharia de Software

Bellacosa Mainframe apresenta docker sem misterios

☕ Um Café no Bellacosa Mainframe

Docker sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender Containers, DevOps e a Nova Engenharia de Software

"Um programador COBOL experiente não demora muito para perceber que Docker não veio substituir o Mainframe. Veio apenas democratizar conceitos que os grandes ambientes corporativos praticam há décadas."

Existe uma curiosidade interessante sobre a evolução da tecnologia.

A cada dez ou quinze anos surge uma "nova revolução" que promete reinventar completamente a computação. Já aconteceu com orientação a objetos, Java, virtualização, cloud computing, microsserviços, Kubernetes, DevOps e, mais recentemente, Inteligência Artificial.

Mas quando olhamos um pouco mais profundamente, percebemos algo fascinante: quase todas essas revoluções não inventaram novos princípios. Elas apenas encontraram formas diferentes de aplicar conceitos que sempre existiram.

Docker é um excelente exemplo disso.

Para muitos desenvolvedores modernos, containers parecem uma tecnologia revolucionária. Para quem passou anos trabalhando com IBM Z, JES2, CICS, Db2, z/OS e COBOL, porém, Docker soa surpreendentemente familiar.

Este artigo não pretende ensinar apenas comandos. Seu objetivo é mostrar como um programador COBOL pode compreender Docker utilizando aquilo que já domina: engenharia de software, ambientes corporativos e sistemas críticos.


A maior mentira sobre Docker

Se você perguntar para um iniciante:

"O que é Docker?"

Provavelmente ouvirá:

"É uma ferramenta para criar containers."

Essa resposta está tecnicamente correta.

Mas está completamente incompleta.

Docker nunca foi apenas uma ferramenta.

Docker é uma solução para um problema antigo.

Imagine uma aplicação Java.

Ela funciona perfeitamente no computador do desenvolvedor.

Quando chega ao servidor...

Nada funciona.

Falta uma biblioteca.

A versão do Java é diferente.

Existe conflito de dependências.

Uma variável de ambiente está ausente.

Uma DLL não existe.

Um certificado expirou.

A famosa frase aparece:

"Na minha máquina funciona."

Durante décadas essa frase custou milhões de dólares às empresas.

Docker nasceu justamente para eliminar esse problema.


O verdadeiro objetivo dos Containers

Containers não existem para economizar memória.

Nem para facilitar deploy.

Nem para executar microsserviços.

Tudo isso é consequência.

O verdadeiro objetivo é tornar o ambiente reproduzível.

Ou seja...

A aplicação leva consigo tudo aquilo que precisa.

Bibliotecas.

Configurações.

Dependências.

Usuários.

Permissões.

Arquivos.

Versões.

Quando o container é iniciado, o ambiente é exatamente igual em qualquer computador.

Notebook.

Servidor.

Cloud.

Produção.

Homologação.

Tudo funciona da mesma forma.


O primeiro paralelo com o Mainframe

Esse conceito não é novo para quem vive no IBM Z.

Pense em um JOB.

Quando submetemos um JCL ao JES2, ele leva consigo:

  • o programa que será executado;

  • os parâmetros necessários;

  • os datasets de entrada;

  • os datasets de saída;

  • bibliotecas de carga;

  • bibliotecas COBOL;

  • DD Statements;

  • região de memória;

  • configurações específicas.

Perceba a semelhança.

O ambiente de execução já está definido antes mesmo do programa começar.

Docker segue exatamente essa filosofia.


Containers não são Máquinas Virtuais

Esse talvez seja o erro mais comum dos iniciantes.

Virtual Machine.

Container.

Parecem iguais.

Mas internamente são completamente diferentes.

Uma máquina virtual precisa simular praticamente um computador inteiro.

Hardware virtual.

BIOS.

Kernel.

Sistema operacional completo.

Drivers.

Depois disso...

Finalmente a aplicação.

Já um container compartilha o kernel do sistema operacional hospedeiro.

Ele isola apenas processos.

Isso muda completamente o consumo de recursos.

Enquanto uma VM pode levar minutos para iniciar, um container normalmente leva poucos segundos.

Às vezes milissegundos.


Easter Egg nº 1 — O Mainframe já fazia isso de outra forma

Uma curiosidade pouco comentada.

No IBM Z também buscamos compartilhar recursos ao máximo.

Milhares de usuários utilizam o mesmo kernel do z/OS.

Centenas de jobs compartilham CPU.

Diversas aplicações compartilham memória.

CICS executa milhares de transações simultaneamente.

Db2 atende milhares de conexões.

A filosofia sempre foi aproveitar recursos de maneira eficiente.

Docker segue exatamente essa linha.


Docker Images: o "Load Module" do mundo Cloud

Aqui aparece um dos conceitos mais importantes.

Muita gente acredita que:

Imagem = Container.

Não.

Imagem é apenas um molde.

Container é uma instância desse molde.

Para um programador COBOL isso faz muito sentido.

Primeiro escrevemos:

SOURCE.

Depois compilamos.

Geramos o OBJ.

Executamos o Link-Edit.

Criamos o Load Module.

Somente então um JOB executa aquele módulo.

O Load Module continua existindo mesmo após o JOB terminar.

O mesmo acontece com Docker.

A imagem permanece armazenada.

Os containers nascem e morrem quantas vezes forem necessárias.


Dockerfile: o PROC do mundo Linux

O Dockerfile é talvez o arquivo mais importante de toda a plataforma.

Ele descreve passo a passo como construir uma imagem.

Não existe mágica.

Existe automação.

Cada instrução representa uma ação.

FROM.

COPY.

RUN.

ENV.

WORKDIR.

CMD.

É como escrever um PROC extremamente sofisticado.

Em vez de apenas indicar o programa a ser executado, você descreve toda a preparação do ambiente.

Instale Java.

Configure usuários.

Copie arquivos.

Crie diretórios.

Abra portas.

Defina variáveis.

No final, qualquer computador consegue reproduzir exatamente aquele ambiente.


Easter Egg nº 2 — As Layers lembram muito o SMP/E

Pouca gente percebe isso.

Cada comando do Dockerfile cria uma nova camada.

Essas camadas são reutilizadas automaticamente.

Se apenas uma linha mudou...

Docker recompõe somente aquela parte.

Isso reduz drasticamente tempo de build.

No Mainframe existe um conceito parecido durante manutenção do sistema operacional.

O SMP/E também trabalha reutilizando componentes ao invés de reinstalar tudo novamente.

São tecnologias completamente diferentes.

Mas a filosofia é muito semelhante.


O ciclo de vida de um Container

Todo container passa pelos mesmos estados.

Imagem.

Container criado.

Executando.

Parado.

Removido.

Nada disso significa que a aplicação desapareceu.

A imagem continua disponível.

Basta criar outra instância.

Para um profissional COBOL isso lembra imediatamente:

Programa compilado.

JOB submetido.

Executando.

Finalizado.

Novo JOB.

O programa continua existindo.

Quem nasce e morre é a execução.


Docker Networking

Talvez o assunto mais negligenciado pelos iniciantes.

Sem comunicação...

Não existe aplicação corporativa.

Imagine um banco.

O sistema precisa conversar com:

Db2.

Servidor Web.

Fila MQ.

API.

Cache.

Monitoramento.

Autenticação.

Cada componente precisa se comunicar de forma segura.

Docker oferece diferentes estratégias.

Bridge.

Host.

Overlay.

MacVLAN.

None.

Cada uma resolve um problema específico.


Easter Egg nº 3 — Overlay lembra muito Sysplex

Overlay permite que containers distribuídos em diversos servidores conversem como se estivessem na mesma rede.

Agora pense um pouco.

Isso lembra bastante um Parallel Sysplex.

Diversos sistemas físicos trabalhando praticamente como um único ambiente lógico.

Mais uma vez...

A tecnologia mudou.

A ideia continua a mesma.


Volumes: onde mora o maior erro dos iniciantes

Container é descartável.

Dados não.

Esse conceito parece simples.

Mas produz inúmeros problemas.

Imagine gravar arquivos importantes dentro do container.

Depois alguém executa:

docker rm.

Tudo desaparece.

Por isso existem Volumes.

Eles armazenam informações fora do ciclo de vida do container.

No Mainframe isso seria equivalente a gravar dados em um Dataset permanente ao invés de um arquivo temporário.

O programa termina.

O dataset continua.


Compose: descrevendo toda uma arquitetura

Imagine uma aplicação moderna.

Banco PostgreSQL.

Redis.

API Java.

Frontend.

Servidor NGINX.

Fila RabbitMQ.

Sem Docker Compose seria necessário iniciar cada serviço individualmente.

Com Compose tudo fica descrito em um único arquivo YAML.

Uma simples instrução coloca toda a arquitetura em funcionamento.

docker compose up.

Isso lembra muito a filosofia declarativa dos grandes ambientes corporativos.

PROC.

Scheduler.

JCL.

Parâmetros.

Tudo documentado.

Tudo reproduzível.


Logs contam histórias

Existe um conselho que todo especialista em Mainframe aprende cedo.

Nunca altere código antes de entender o problema.

E para entender o problema...

Leia os logs.

Docker possui um comando extremamente simples.

docker logs.

Mas sua importância é enorme.

Ali estão mensagens de erro.

Inicialização.

Dependências.

Falhas.

Exceções.

No Mainframe fazemos exatamente a mesma coisa analisando JESMSGLG, SYSOUT, CEEDUMP, SMF, RMF e dumps do sistema.

Os logs sempre contam a história completa.


Registry: a biblioteca do mundo Cloud

Outra analogia interessante.

Docker Registry é um repositório de imagens.

Pense nele como uma gigantesca biblioteca de Load Modules.

As equipes publicam novas versões.

Outros ambientes apenas fazem download.

Tudo versionado.

Tudo controlado.

Tudo auditável.

Essa preocupação sempre existiu em ferramentas como Endevor, ISPW e ChangeMan.


A filosofia DevOps

Muitos profissionais acreditam que Docker e DevOps são sinônimos.

Não são.

Docker é apenas uma ferramenta.

DevOps é uma cultura.

Seu objetivo é reduzir a distância entre desenvolvimento e operação.

Automatizar.

Versionar.

Testar.

Monitorar.

Implantar continuamente.

Curiosamente...

Grandes ambientes IBM Z já possuíam muitos desses processos muito antes da popularização do termo DevOps.

Existiam mudanças controladas.

Promoções entre ambientes.

Auditoria.

Versionamento.

Controle de acesso.

Separação entre desenvolvimento e produção.

O que mudou foi o grau de automação.


Docker e Kubernetes

Depois que um profissional domina Docker, naturalmente surge outra pergunta.

Quem gerencia centenas ou milhares de containers?

A resposta é Kubernetes.

Mas aqui existe outro paralelo interessante.

Docker executa containers.

Kubernetes coordena containers.

No Mainframe temos algo semelhante.

O sistema operacional executa workloads.

O WLM decide prioridades.

O Sysplex distribui carga.

O SA z/OS automatiza recuperação.

Novamente...

Não são tecnologias iguais.

Mas resolvem problemas parecidos.


Curiosidades que poucos conhecem

Docker surgiu em 2013 como um projeto da empresa dotCloud, que posteriormente passou a se chamar Docker Inc.

Entretanto, a tecnologia de containers é muito mais antiga.

Ela aproveita recursos do kernel Linux chamados namespaces e cgroups, desenvolvidos anos antes do Docker existir.

Outros sistemas operacionais também possuíam conceitos semelhantes, como Solaris Zones e FreeBSD Jails.

Ou seja...

Docker não inventou containers.

Ele tornou containers acessíveis para milhões de desenvolvedores.


O verdadeiro impacto na carreira de um Programador COBOL

Talvez você esteja pensando:

"Mas eu trabalho com Mainframe. Por que deveria aprender Docker?"

A resposta é simples.

Porque praticamente toda arquitetura moderna conversa com containers.

APIs.

Microsserviços.

CI/CD.

Pipelines.

Integração contínua.

OpenShift.

Kubernetes.

Cloud híbrida.

Mesmo que o seu COBOL continue executando no IBM Z, ele provavelmente será integrado a aplicações empacotadas em containers.

Entender Docker deixa de ser um diferencial.

Passa a ser uma competência estratégica.


O maior ensinamento

Existe uma frase que resume tudo o que vimos.

Ferramentas mudam.

Princípios permanecem.

Um bom engenheiro de software não memoriza centenas de comandos.

Ele compreende conceitos.

É justamente por isso que muitos profissionais IBM Z aprendem Docker, Kubernetes e DevOps com relativa facilidade.

Eles já conhecem os fundamentos.

Sabem o valor da padronização.

Da automação.

Da confiabilidade.

Da rastreabilidade.

Da observabilidade.

Da documentação.

Da recuperação de falhas.

Da estabilidade operacional.

Docker apenas apresenta esses princípios com uma nova interface.

E talvez essa seja a maior lição deste artigo.

Quando um Programador COBOL Padawan olha para Docker pela primeira vez, ele pode enxergar apenas uma tecnologia moderna da nuvem. Mas quando começa a compreender sua arquitetura, percebe algo muito mais profundo: grande parte das ideias consideradas "inovadoras" já fazia parte da cultura do Mainframe havia décadas. A verdadeira evolução não está em abandonar o passado, e sim em reconhecer que os melhores fundamentos da engenharia de software atravessam gerações de plataformas. Quem domina esses fundamentos consegue transitar naturalmente entre IBM Z, Linux, Cloud, Kubernetes e Inteligência Artificial, porque entende que linguagens, ferramentas e interfaces mudam continuamente, mas os princípios que sustentam sistemas críticos continuam exatamente os mesmos. Esse é o verdadeiro caminho do Mestre Bellacosa: não decorar tecnologias, mas compreender a engenharia que existe por trás delas.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...