Translate

terça-feira, 30 de junho de 2020

Isekai Karutetto 2 : Quando o Multiverso Isekai Fica Ainda Mais Lotado… e Nem Ainz Ooal Gown Consegue Fazer Chamada sem Perder Alguém

 

Bellacosa Mainframe e a segunda temporada de isekai karutetto

☕ Um Café no Bellacosa Mainframe

Isekai Karutetto 2 sem Mistérios

Quando o Multiverso Isekai Fica Ainda Mais Lotado… e Nem Ainz Ooal Gown Consegue Fazer Chamada sem Perder Alguém

Imagine que você é o administrador de um ambiente IBM Z.

Tudo está funcionando perfeitamente.

CICS conversa com Db2.

MQ entrega mensagens.

IMS responde às transações.

Linux on Z hospeda APIs.

Java executa microsserviços.

Então alguém diz:

"Vamos adicionar mais dois sistemas críticos em produção... agora."

É exatamente isso que acontece em Isekai Karutetto 2.

A primeira temporada já havia reunido quatro dos maiores universos isekai da Kadokawa. A segunda não tenta reinventar a fórmula; ela a expande, adicionando novos personagens, novas piadas e ainda mais interações improváveis. O resultado é um crossover mais ambicioso, repleto de referências para quem acompanha o gênero.


Ficha Técnica

ItemInformação
Título Original異世界かるてっと2 (Isekai Karutetto 2)
Título InternacionalIsekai Quartet 2
DireçãoMinoru Ashina
RoteiroMinoru Ashina
EstúdioStudio PuYUKAI
ProduçãoKadokawa
Baseado nas obras deKugane Maruyama, Natsume Akatsuki, Tappei Nagatsuki, Carlo Zen, Aneko Yusagi, Light Tuchihi
Estreia14 de janeiro de 2020
FormatoTV (episódios curtos)
Quantidade de episódios12
Duração média12 minutos por episódio

O Studio PuYUKAI Evolui

A equipe do Studio PuYUKAI já conhecia profundamente as características de cada franquia.

Na segunda temporada isso fica evidente.

As animações continuam simples.

Mas:

  • o ritmo cômico melhora;

  • as expressões faciais ficam ainda mais exageradas;

  • existem muito mais personagens simultaneamente;

  • praticamente cada cena possui alguma referência escondida.

O desafio não era produzir belas batalhas.

Era conseguir fazer mais de cinquenta personagens dividirem espaço sem perder suas personalidades.

E eles conseguem.


A História

Depois dos acontecimentos da primeira temporada...

A escola continua funcionando normalmente.

Ou melhor...

O mais próximo possível do "normal".

Os alunos continuam presos naquele universo misterioso enquanto novas classes começam a aparecer.

Agora chegam novos estudantes.

E isso muda completamente a dinâmica da escola.


Os Novos Personagens

A maior novidade da temporada é a chegada dos heróis de outras franquias.

The Rising of the Shield Hero

Entram:

  • Naofumi

  • Raphtalia

  • Filo

Naofumi rapidamente assume o papel do adulto responsável.

Enquanto isso...

Filo consegue competir com Aqua pelo prêmio de personagem mais caótica.


Cautious Hero

Também aparecem:

  • Seiya

  • Ristarte

Talvez sejam os personagens que melhor exploram o humor da série.

Enquanto todos entram nas aventuras sem pensar...

Seiya passa metade do tempo planejando.

Mesmo quando não existe perigo algum.


Os Universos Presentes

Agora convivem:

  • Overlord

  • Re:Zero

  • KonoSuba

  • Youjo Senki

  • Shield Hero

  • Cautious Hero

Cada universo continua obedecendo às próprias regras, mas todos compartilham o mesmo espaço escolar.


Sinopse

A misteriosa escola continua recebendo visitantes de diferentes mundos.

Com a chegada de novos alunos, as atividades escolares tornam-se ainda mais imprevisíveis.

Festivais, provas, exercícios físicos e eventos especiais passam a reunir heróis, anti-heróis e vilões em situações absurdamente engraçadas.


O Que Diferencia a Segunda Temporada?

A primeira temporada tinha como objetivo apresentar os personagens.

A segunda faz algo mais interessante.

Ela explora:

  • amizades improváveis;

  • rivalidades inéditas;

  • choque entre filosofias;

  • comparações entre protagonistas.

Agora o público já conhece todos.

O anime passa a brincar com suas diferenças.


As Aventuras

Entre as atividades estão:

  • festivais culturais;

  • esportes;

  • excursões;

  • aulas práticas;

  • eventos sobrenaturais;

  • exercícios militares;

  • apresentações escolares;

  • brincadeiras envolvendo magia.

Cada episódio parece um pequeno laboratório de "e se esses personagens precisassem trabalhar juntos?".


Os Personagens

Ainz Ooal Gown

Continua sendo extremamente poderoso.

Mas descobre que administrar uma escola pode ser mais complicado do que governar Nazarick.


Kazuma

Permanece o mestre das respostas sarcásticas.

Quase sempre é quem verbaliza aquilo que o público está pensando.


Aqua

Consegue transformar qualquer situação simples em caos absoluto.

Até quando tenta ajudar.


Subaru

Continua emocionalmente complexo.

Mesmo em uma comédia, sua personalidade permanece coerente com Re:Zero.


Tanya

Ainda enxerga qualquer atividade escolar como operação militar.


Naofumi

Serve como contraponto aos protagonistas mais impulsivos.


Seiya

Planeja absolutamente tudo.

Mesmo quando a situação exige apenas entrar em sala de aula.


Temáticas

A temporada trabalha temas interessantes.

Cooperação

Cada personagem resolve problemas de maneira diferente.

Mas quando trabalham juntos...

As diferenças tornam-se vantagens.


Liderança

Existem vários líderes.

Cada um lidera de maneira completamente distinta.

Ainz.

Naofumi.

Tanya.

Todos possuem estilos incompatíveis.

Mesmo assim funcionam.


Diversidade

O anime mostra que diferentes culturas, religiões, sistemas mágicos e formas de governo conseguem coexistir.


Identidade

Nenhum personagem abandona sua essência.

Essa talvez seja a maior qualidade da série.


Mensagens Ocultas

O contexto muda tudo

No universo original...

Ainz é praticamente um deus.

Na escola...

Precisa seguir regras.

O ambiente altera completamente o significado do poder.


Experiência importa

Naofumi reage de forma diferente porque já foi traído.

Subaru reage diferente porque conhece o sofrimento.

Kazuma pensa diferente porque já fracassou inúmeras vezes.

Cada protagonista leva sua bagagem emocional para dentro da sala de aula.


Equipes fortes são heterogêneas

A temporada reforça a ideia de que pessoas muito diferentes conseguem formar grupos altamente eficientes.

É uma metáfora interessante para equipes de desenvolvimento de software.


Curiosidades

  • A abertura da segunda temporada acrescenta novos personagens e brinca com suas habilidades características.

  • Muitos dos dubladores originais retornaram, preservando o carisma de cada franquia.

  • O roteiro intensifica as referências cruzadas, recompensando quem assistiu às obras originais.


Impacto Cultural

A segunda temporada consolidou Isekai Quartet como um dos crossovers mais bem-sucedidos da animação japonesa recente. Ela mostrou que um encontro entre franquias populares poderia ir além de uma simples ação promocional, criando uma obra consistente, divertida e respeitosa com o material de origem. Também ajudou a divulgar séries como The Rising of the Shield Hero e Cautious Hero para um público que talvez ainda não as conhecesse, fortalecendo o ecossistema de light novels da Kadokawa.


O Café no Bellacosa Mainframe ☕

Agora imagine a escola de Isekai Quartet como um grande Data Center IBM Z.

Cada universo é um subsistema:

  • Overlord → CICS (robusto, poderoso e centralizador).

  • Re:Zero → Recovery Manager (falhou? volta do último checkpoint).

  • KonoSuba → Ambiente de desenvolvimento onde sempre aparece um bug inesperado.

  • Youjo Senki → WLM, definindo prioridades com disciplina militar.

  • Shield Hero → RACF, protegendo recursos e absorvendo ataques.

  • Cautious Hero → Ambiente de homologação, onde nada vai para produção sem dezenas de testes.

Separados, todos funcionam muito bem.

Juntos, tornam-se um ecossistema resiliente, exatamente como acontece em um ambiente corporativo moderno com COBOL, Db2, MQ, CICS, Java, APIs REST e Linux on IBM Z convivendo no mesmo hardware.

Essa é a verdadeira mensagem de Isekai Karutetto 2: a maior força não está em reunir os personagens mais poderosos, mas em fazer personalidades completamente diferentes colaborarem sem perder sua identidade.

Avaliação Bellacosa Mainframe

⭐⭐⭐⭐⭐ 9,6/10

A segunda temporada mantém o humor da primeira, amplia o elenco com inteligência e transforma a escola mais caótica dos animes em uma divertida metáfora sobre integração, diversidade e trabalho em equipe — conceitos tão valiosos para heróis de fantasia quanto para programadores COBOL e arquitetos de sistemas IBM Z.


segunda-feira, 29 de junho de 2020

DotCom : Capítulo VI — Os Sobreviventes da Tempestade: Como o Colapso das Dot-Com Transformou o Mercado de Trabalho e a Engenharia de Software

 

Bellacosa Mainframe e o estouro da bolha dotcom capitulo vi

Capítulo VI — Os Sobreviventes da Tempestade: Como o Colapso das Dot-Com Transformou o Mercado de Trabalho e a Engenharia de Software

Quando milhares de profissionais perderam seus empregos, mas a computação ganhou uma nova geração de engenheiros muito mais preparados

"Toda crise destrói ilusões. Mas também constrói profissionais que jamais seriam formados em tempos de abundância."

Quando estudamos a bolha da Internet, quase sempre vemos gráficos.

Linhas descendentes.

Índices financeiros.

Bilhões de dólares evaporando.

Empresas desaparecendo.

Mas existe uma história muito menos comentada.

A história das pessoas.

Por trás de cada startup que fechava existiam desenvolvedores.

Analistas.

Arquitetos.

DBAs.

Gerentes de projeto.

Administradores de rede.

Profissionais de suporte.

Designers.

Testadores.

Especialistas em banco de dados.

Milhares deles acreditavam estar construindo o futuro.

E, de certa forma...

Estavam.

O problema é que nem todos trabalhariam para vê-lo chegar.


A Grande Onda de Demissões

Conforme o dinheiro dos investidores desaparecia, as empresas precisavam tomar decisões rápidas.

A folha de pagamento era, normalmente, a maior despesa.

A consequência foi inevitável.

Demissões em massa.

Algumas startups reduziram metade do quadro de funcionários.

Outras dispensaram praticamente todos.

Diversas simplesmente fecharam as portas de um dia para o outro.

Imagine chegar ao escritório numa segunda-feira e descobrir que a empresa havia encerrado suas atividades durante o fim de semana.

Infelizmente, isso aconteceu inúmeras vezes.

Muitos profissionais sequer tiveram tempo de procurar outro emprego antes do fechamento definitivo.


A Ilusão das Stock Options

Um dos grandes atrativos das startups era o famoso pacote de stock options.

Em vez de oferecer apenas salário, muitas empresas prometiam participação acionária.

A ideia parecia excelente.

Aceitar um salário um pouco menor hoje para ficar milionário quando a empresa abrisse capital.

Em alguns casos isso realmente aconteceu.

Funcionários da Microsoft, Google, Amazon e outras gigantes construíram fortunas dessa maneira.

Entretanto, para milhares de trabalhadores das Dot-Com, aquelas opções de ações simplesmente perderam todo o valor.

Papel que um dia parecia representar riqueza transformou-se em lembrança.

Foi uma lição dura sobre o risco de concentrar expectativas em um único cenário.


O Mercado Mudou da Noite para o Dia

Poucos meses antes, empresas disputavam profissionais.

Agora...

Profissionais disputavam vagas.

O mercado ficou completamente diferente.

As startups deixaram de contratar.

Fundos interromperam investimentos.

Projetos foram cancelados.

Empresas tradicionais voltaram a receber currículos de especialistas que antes jamais cogitariam trabalhar nelas.

Foi uma mudança brusca de equilíbrio.

Em vez de escassez de mão de obra, surgiu um enorme excesso de profissionais altamente qualificados procurando oportunidades.


O Perfil do Profissional Também Mudou

Antes da crise, bastava dizer que alguém trabalhava com Internet.

Depois da crise...

As perguntas ficaram mais específicas.

Você sabe projetar sistemas escaláveis?

Conhece banco de dados?

Entende arquitetura distribuída?

Consegue otimizar desempenho?

Tem experiência com segurança?

Sabe administrar servidores?

O mercado deixou de procurar apenas entusiasmo.

Passou a valorizar competência técnica.

Foi o nascimento de uma nova geração de engenheiros de software.


O Desenvolvedor "Faz-Tudo"

Nas startups da época era comum encontrar profissionais acumulando diversas funções.

O mesmo desenvolvedor escrevia código.

Configurava servidores.

Administrava banco de dados.

Respondia clientes.

Instalava equipamentos.

Configurava roteadores.

Hoje chamamos isso de perfil full stack.

Naquele período era simplesmente necessidade.

As equipes eram pequenas.

Os recursos limitados.

Todos precisavam aprender rapidamente.

Essa cultura acabou influenciando profundamente a engenharia de software das décadas seguintes.


As Certificações Ganharam Valor

Depois do colapso, muitas empresas passaram a buscar profissionais com formação técnica mais sólida.

Certificações começaram a ganhar importância.

Experiência comprovada tornou-se diferencial.

Conhecimento profundo passou a valer mais do que apresentações bonitas.

Foi também um período em que cursos de administração de sistemas, redes, bancos de dados e engenharia de software cresceram bastante.

O mercado buscava estabilidade.

E estabilidade exige conhecimento.


Enquanto Isso... Os Mainframes Continuavam Contratando

Existe uma curiosidade pouco lembrada.

Enquanto diversas startups demitiam funcionários, muitos bancos, seguradoras e órgãos governamentais continuavam contratando profissionais de tecnologia.

Por quê?

Porque suas operações não dependiam do humor dos investidores.

O banco continuava precisando processar pagamentos.

A seguradora continuava emitindo apólices.

O governo continuava arrecadando impostos.

As empresas de infraestrutura crítica não podiam simplesmente "esperar a crise passar".

Elas precisavam funcionar todos os dias.

Foi nesse período que muitos profissionais migraram das startups para ambientes corporativos tradicionais.

Alguns descobriram pela primeira vez o universo dos grandes sistemas.


O Preconceito Contra o COBOL Começou a Ser Questionado

Durante os anos de euforia, era comum ouvir frases como:

"O COBOL morreu."

"Mainframe é coisa do passado."

"O futuro pertence apenas à Internet."

Entretanto, quando a crise chegou, ocorreu algo curioso.

As empresas perceberam que seus sistemas mais importantes continuavam funcionando justamente nas plataformas consideradas antigas.

Enquanto startups fechavam as portas, milhões de transações financeiras continuavam sendo processadas diariamente em programas COBOL escritos anos antes.

Isso levou muitos executivos a reconsiderarem um conceito fundamental.

Tecnologia moderna não substitui necessariamente tecnologia confiável.

Frequentemente elas coexistem.

E se complementam.


A Engenharia Voltou a Ser Importante

Durante a bolha, existia uma obsessão por lançar produtos rapidamente.

O famoso:

"Depois corrigimos."

Após a crise, essa mentalidade começou a mudar.

Arquitetura voltou a ser discutida.

Documentação passou a receber atenção.

Modelagem de dados tornou-se prioridade.

Processos de desenvolvimento amadureceram.

Testes automatizados começaram a ganhar espaço.

Planejamento deixou de ser visto como desperdício de tempo.

A indústria percebeu que improvisação funciona apenas enquanto tudo está dando certo.

Quando surgem problemas...

Quem salva o projeto é a engenharia.


O Cliente Voltou ao Centro

Outro aprendizado importante foi a mudança de foco.

Durante a bolha, muitas empresas desenvolviam produtos pensando principalmente em investidores.

Depois da crise...

O foco voltou para o cliente.

Uma pergunta simples começou a orientar projetos:

Este produto realmente resolve um problema?

Pode parecer óbvio.

Mas essa pergunta havia sido parcialmente esquecida durante os anos de euforia.

Empresas passaram a investir menos em promessas.

E mais em utilidade.

Foi um enorme amadurecimento do setor.


O Surgimento da Cultura da Eficiência

Até então, crescimento era praticamente a única métrica importante.

Depois da crise surgiram outras preocupações.

Eficiência operacional.

Controle de custos.

Produtividade.

Qualidade.

Retenção de clientes.

Suporte.

Escalabilidade sustentável.

Esses conceitos hoje fazem parte de qualquer empresa de tecnologia.

Na época foram aprendidos através de uma das crises mais dolorosas da história do setor.


As Gigantes Também Aprenderam

Curiosamente, até empresas que sobreviveram precisaram mudar profundamente.

Amazon reduziu custos.

Google focou ainda mais em engenharia.

eBay investiu em infraestrutura.

PayPal aprimorou seus sistemas antifraude.

Salesforce refinou seu modelo SaaS.

Nenhuma delas saiu da crise igual.

Sobreviver exigiu disciplina.

Não apenas inovação.


O Mainframe Nunca Foi o Vilão

Existe uma ironia interessante.

Enquanto jornais discutiam diariamente o futuro da Internet, poucos percebiam que praticamente todas as transações importantes da nova economia terminavam passando por sistemas tradicionais.

Quando alguém comprava um produto online...

O pagamento era autorizado por sistemas bancários.

Quando um cartão era utilizado...

Mainframes validavam limites.

Quando uma transferência era realizada...

Programas COBOL processavam registros.

A nova economia não substituiu a antiga.

Ela passou a depender dela.

Essa talvez seja uma das maiores lições para quem trabalha com tecnologia atualmente.

A inovação raramente elimina completamente o passado.

Na maioria das vezes...

Ela se apoia nele.


O Renascimento da Engenharia de Software

Muitos historiadores da computação afirmam que a bolha da Internet foi responsável por acelerar a maturidade da engenharia de software.

Antes dela, bastava lançar rapidamente.

Depois dela, tornou-se necessário construir corretamente.

Foi nesse ambiente que ganharam força conceitos como:

  • arquitetura em camadas;

  • padrões de projeto;

  • integração contínua;

  • automação de testes;

  • monitoramento;

  • observabilidade;

  • recuperação de desastres;

  • alta disponibilidade.

Não porque eram novidades.

Mas porque as empresas finalmente entenderam quanto custava ignorá-los.


O Paralelo com a Inteligência Artificial

Hoje, em plena era dos agentes inteligentes e da IA generativa, vemos um movimento semelhante.

Existe enorme demanda por profissionais.

Salários elevados.

Novas startups surgindo diariamente.

Mas também cresce a procura por competências mais profundas.

Engenharia de prompts já não basta.

É preciso entender:

  • arquitetura de sistemas;

  • integração com APIs;

  • segurança;

  • governança;

  • bancos vetoriais;

  • infraestrutura;

  • observabilidade;

  • custos de inferência.

Assim como aconteceu após as Dot-Com, o mercado começa novamente a valorizar quem compreende sistemas completos, e não apenas ferramentas da moda.


Lições para o Padawan COBOL

Todo Padawan COBOL aprende, cedo ou tarde, que um programa pode funcionar perfeitamente durante anos e, ainda assim, precisar ser continuamente aprimorado.

Empresas seguem exatamente a mesma lógica.

A crise das Dot-Com mostrou que entusiasmo abre portas.

Mas é competência que mantém essas portas abertas.

Profissionais que sobreviveram àquele período desenvolveram características que continuam extremamente valorizadas:

  • pensamento crítico;

  • disciplina técnica;

  • visão de longo prazo;

  • preocupação com qualidade;

  • respeito pela arquitetura;

  • foco em resolver problemas reais.

No universo da Frota Estelar, qualquer cadete consegue pilotar uma nave durante um treinamento em céu aberto. O verdadeiro oficial é aquele que mantém os motores funcionando quando a nave perde energia, os sensores falham e uma tempestade cósmica ameaça toda a tripulação.

Foi exatamente isso que aconteceu após o colapso das Dot-Com.

A tempestade revelou quem apenas navegava... e quem realmente sabia construir naves.

No próximo capítulo conheceremos um dos aspectos mais fascinantes dessa história: por que algumas empresas não apenas sobreviveram ao colapso, como saíram dele muito mais fortes, transformando-se nas gigantes que dominariam a Internet nas décadas seguintes. A crise eliminou milhares de companhias, mas também criou os futuros impérios digitais.


domingo, 28 de junho de 2020

👻 Bellacosa Otaku Blog — Parte 15: Expressões de Mistério, Suspense e Terror nos Animes 👻



 👻 Bellacosa Otaku Blog — Parte 15: Expressões de Mistério, Suspense e Terror nos Animes 👻


🌑 O idioma do medo e do suspense nos animes

(Versão Bellacosa: passos silenciosos, sussurros e o arrepio que percorre a espinha.)

Nos animes de mistério e terror, o japonês ganha tons sombrios e tensos.
Cada expressão pode significar perigo iminente, segredo revelado ou medo profundo.
Vamos explorar as palavras e frases que fazem o espectador prender a respiração. 🌫️


😨 1. 怖い (kowai)

Tradução: “Assustador / assustado.”
👉 A palavra mais direta do medo, usada quando algo dá arrepios ou perigo se aproxima.

📺 Anime vibe: Another, Higurashi no Naku Koro ni.
💬 Exemplo: “Kowai… ouvi passos atrás de mim.” 👀


🕯️ 2. 不気味 (bukimi)

Tradução: “Estranho / inquietante / sinistro.”
👉 Expressa aquela sensação de algo fora do normal, que provoca desconforto.

📺 Anime vibe: Monogatari Series, Shiki.
💬 Exemplo: “A casa estava silenciosa… bukimi.” 🕯️


👁️ 3. 影 (kage)

Tradução: “Sombra.”
👉 Frequentemente usada em contextos de suspense, indicando perigo ou presença invisível.

📺 Anime vibe: Paranoia Agent, Another.
💬 Exemplo: “Vi um kage se movendo no corredor…” 🌑


😱 4. 叫ぶ (sakebu)

Tradução: “Gritar / berrar.”
👉 Grito de terror ou alerta, essencial em cenas de susto ou perseguição.

📺 Anime vibe: Higurashi no Naku Koro ni, Tokyo Ghoul.
💬 Exemplo: “Sakebu! Alguém está vindo!” 🗣️


🌫️ 5. 誰かいる (dareka iru?)

Tradução: “Alguém está aqui?”
👉 Usada para tensão máxima, quando se suspeita de presença misteriosa.

📺 Anime vibe: Another, Shiki.
💬 Exemplo: “Dareka iru… mas o corredor está vazio.” 👻


🕷️ 6. 気配 (kehai)

Tradução: “Presença / sensação.”
👉 Indica algo invisível mas perceptível — o suspense em uma palavra.

📺 Anime vibe: Paranoia Agent, Higurashi no Naku Koro ni.
💬 Exemplo: “Senti kehai atrás de mim… algo ruim está vindo.” 🌫️


💀 7. 死 (shi)

Tradução: “Morte.”
👉 Palavra direta e pesada, usada para indicar perigo extremo ou final trágico.

📺 Anime vibe: Tokyo Ghoul, Shiki.
💬 Exemplo: “Shi está próximo… não há como escapar.” ⚰️


🕸️ 8. 呪い (noroi)

Tradução: “Maldição.”
👉 Essencial em animes sobrenaturais e de terror, indicando forças além do controle humano.

📺 Anime vibe: Jigoku Shoujo, Noroi: The Curse.
💬 Exemplo: “Noroi da família continua até hoje.” 🕷️


🌌 9. 真実 (shinjitsu)

Tradução: “Verdade / realidade.”
👉 Em mistérios, a verdade revelada muitas vezes é mais assustadora que o próprio medo.

📺 Anime vibe: Paranoia Agent, Monster.
💬 Exemplo: “Shinjitsu por trás desses eventos é horrível…” 👁️


🔪 10. 逃げろ! (nigero!)

Tradução: “Fuja!”
👉 Grito clássico de alerta em cenas de perseguição, terror ou perigo iminente.

📺 Anime vibe: Higurashi no Naku Koro ni, Tokyo Ghoul.
💬 Exemplo: “Nigero! Ele está atrás de você!” 🏃‍♂️💨


🏮 Curiosidades Bellacosa:

  • Em terror, muitas expressões japonesas transmitem mais sensação do que significado literal, como bukimi ou kehai.

  • Gritos e exclamações (sakebu, nigero!) são quase onomatopeias da adrenalina, fazendo o espectador sentir o medo.

  • Palavras como noroi e shi carregam peso cultural, evocando superstição e respeito pelo sobrenatural. 👻


🌟 Dica Bellacosa:

  • Repare como a entonação e silêncio antes de certas palavras aumenta o suspense.

  • Muitas expressões de terror são curtas, simples, mas muito carregadas de atmosfera.

  • Memorizar esses termos ajuda a entender cenas de horror e mistério japonesas, seja em anime ou mangá.


🌸 Conclusão Bellacosa:

As expressões de mistério e terror nos animes criam tensão, suspense e medo palpável.
Cada palavra é um gatilho emocional, capaz de fazer o espectador prender a respiração ou arrepiar-se.
No mundo sombrio dos animes, o japonês não é só idioma — é um instrumento de horror e emoção pura. 🌑

“Kowai… dareka iru… nigero!” 👻💨

sábado, 27 de junho de 2020

DRY Rules: Quando um Programador COBOL Descobriu que Existiam Mil Agentes Smith Porque Alguém Copiou o Mesmo Código Pela Matrix Inteira

 

Bellacosa Mainframe e a dry rules

☕ Um Café no Bellacosa Mainframe

DRY Rules sem Mistérios

Quando um Programador COBOL Descobriu que Existiam Mil Agentes Smith Porque Alguém Copiou o Mesmo Código Pela Matrix Inteira

"Duplicar código parece economizar alguns minutos hoje. Mas pode custar centenas de horas durante a vida inteira de um sistema."


Prólogo — A Invasão dos Mil Smiths

Neo corria pelos corredores da Matrix.

De repente.

Encontrou um Agente Smith.

Depois outro.

Depois dez.

Depois cem.

Depois milhares.

Todos eram idênticos.

Todos repetiam exatamente as mesmas frases.

Os mesmos movimentos.

Os mesmos ataques.

Neo perguntou ao Oráculo:

— Como isso aconteceu?

Ela respondeu serenamente:

— Alguém resolveu copiar em vez de reutilizar.

Neo ficou confuso.

— O que isso tem a ver com programação?

O Oráculo apontou para o código-fonte da Matrix.

Cada módulo possuía a mesma lógica repetida dezenas de vezes.

Mudava apenas um pequeno detalhe.

O Arquiteto apareceu.

Suspirou profundamente.

— Agora precisamos corrigir um bug.

Neo perguntou:

— Quantos lugares teremos que alterar?

O Arquiteto respondeu:

— Ainda estamos contando...

Naquele instante Neo compreendeu que o verdadeiro inimigo não era Smith.

Era a duplicação.


O que significa DRY?

DRY significa:

Don't Repeat Yourself

Em português:

"Não se repita."

É um dos princípios mais importantes da Engenharia de Software.

Sua ideia é simples.

Cada conhecimento deve existir em apenas um lugar.

Quando uma regra aparece repetida em vários pontos do sistema, surge um risco enorme.

Se a regra mudar.

Será necessário alterar todos os lugares.

Se esquecer apenas um.

O sistema ficará inconsistente.


A origem do DRY

O princípio foi apresentado em 1999 por Andy Hunt e Dave Thomas, no livro clássico:

The Pragmatic Programmer

Os autores definiram o DRY de forma elegante:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Ou seja.

Cada informação importante deve possuir uma única fonte oficial.


Matrix explica perfeitamente

Imagine que existam cinquenta versões diferentes da regra que controla a gravidade da Matrix.

Uma delas diz:

Gravidade = 9,8

Outra.

Gravidade = 9,7

Outra.

Gravidade = 10

O resultado?

Cada região da Matrix funciona de maneira diferente.


O COBOL conhece muito bem o DRY

Imagine uma regra tributária.

Ela aparece em:

  • Cadastro.

  • Cobrança.

  • Empréstimos.

  • Cartões.

  • PIX.

  • Internet Banking.

Tudo copiado.

Chega uma nova legislação.

Agora será preciso alterar:

seis programas.

Se esquecer apenas um.

Problema.


Um exemplo COBOL

Primeiro programa.

IF SALDO < 0
   MOVE "N" TO APROVADO
END-IF

Segundo programa.

A mesma regra.

Terceiro.

Novamente.

Décimo.

Também.

Agora imagine.

A regra muda.

Saldo igual a zero também deve ser negado.

Quantos programas precisam mudar?


O COPYBOOK nasceu justamente para isso

Um dos maiores exemplos de DRY no COBOL.

Em vez de repetir estruturas.

Criamos:

COPY CLIENTE.

Agora.

Se o layout mudar.

Mudamos apenas um lugar.


Matrix Reloaded

Smith tornou-se perigoso justamente porque começou a se copiar infinitamente.

O mesmo acontece com regras de negócio.

Quanto mais cópias.

Mais difícil controlar.


O efeito psicológico

Existe uma tentação enorme.

"Vou copiar rapidinho."

Leva:

dez segundos.

Depois.

O sistema vive vinte anos.


O Programador COBOL Padawan

Você escreve:

CALCULA-JUROS.

Depois precisa da mesma lógica.

Em vez de criar uma rotina reutilizável.

Faz:

CTRL+C.

CTRL+V.

Parece eficiente.

Até a primeira manutenção.


O Agente Smith ama CTRL+C CTRL+V

Porque cada cópia.

É um novo esconderijo para bugs.

Um erro copiado.

É um erro multiplicado.


Um exemplo inspirado na Matrix

Imagine.

Existem cinquenta mapas de Zion.

Cada mapa possui uma pequena diferença.

Qual deles é verdadeiro?

Ninguém sabe.


O custo invisível

Duplicação gera:

  • manutenção maior;

  • testes maiores;

  • documentação maior;

  • bugs inconsistentes;

  • dificuldade de evolução.


O impacto no Mainframe

Grandes ambientes IBM Z frequentemente apresentam:

  • COPYBOOKs duplicados;

  • layouts semelhantes;

  • SQL repetido;

  • JCLs quase idênticos;

  • validações copiadas.

Quanto maior a duplicação.

Maior o esforço de manutenção.


Curiosidade

DRY não trata apenas de código.

Também vale para:

  • documentação;

  • configurações;

  • tabelas;

  • scripts;

  • APIs;

  • processos.

Conhecimento duplicado também é duplicação.


Atenção!

DRY não significa:

Transformar tudo em reutilização.

Existe outro princípio importante.

AHA

Avoid Hasty Abstractions.

Evite abstrações prematuras.

Primeiro compreenda o padrão.

Depois reutilize.


A diferença

Reutilização saudável

Uma regra.

Um local.


Reutilização exagerada

Tudo depende de um único módulo gigantesco.


Matrix e o Chaveiro

O Chaveiro fabrica uma chave para cada tipo de porta.

Mas não fabrica cem cópias da mesma chave escondidas pela Matrix.

Existe uma fonte.

Uma responsabilidade.


Ferramentas ajudam

Hoje temos:

  • SonarQube.

  • IBM ADDI.

  • Enterprise Analyzer.

  • Clone Detection.

  • Code Review.

  • IA.

Todas ajudam a localizar duplicações.


O papel da IA

A IA consegue detectar:

  • código semelhante;

  • SQL repetido;

  • COPYBOOKs equivalentes;

  • regras duplicadas.

Mas cabe ao arquiteto decidir como consolidar.


Os riscos

Ignorar DRY gera.

  • inconsistências.

  • bugs.

  • retrabalho.

  • dívida técnica.

  • manutenção cara.

  • baixa produtividade.


Erros clássicos

  • Copiar programas inteiros.

  • Duplicar SQL.

  • Repetir validações.

  • Criar layouts quase iguais.

  • Duplicar documentação.


Boas práticas

  • Modularizar.

  • Criar COPYBOOKs.

  • Utilizar subprogramas.

  • Centralizar regras.

  • Automatizar validações.

  • Revisar duplicações periodicamente.


Aplicabilidade

DRY aparece em:

  • COBOL.

  • Java.

  • Python.

  • C#.

  • APIs.

  • Cloud.

  • DevOps.

  • Scripts.

  • SQL.

  • Infraestrutura como Código.


DRY e o universo IBM Z

O ecossistema IBM Z oferece diversos mecanismos que incorporam naturalmente o espírito do DRY.

Entre eles:

  • COPYBOOKs, para compartilhar layouts de dados entre programas.

  • Subprogramas COBOL, evitando repetir regras de negócio.

  • Stored Procedures Db2, centralizando lógica próxima aos dados quando apropriado.

  • PROCs JCL, reutilizando definições de execução.

  • Macros HLASM, eliminando repetições em código Assembly.

  • Serviços CICS compartilhados, reutilizados por diferentes transações.

  • APIs corporativas, permitindo que uma única implementação atenda vários consumidores.

Todos esses recursos existem para evitar que o mesmo conhecimento seja implementado repetidamente.


Quando DRY pode ser exagerado?

Assim como qualquer princípio, o DRY pode ser levado ao extremo.

Imagine duas regras de negócio parecidas, mas que pertencem a domínios diferentes.

Forçá-las a usar a mesma rotina apenas porque "são semelhantes" pode criar um forte acoplamento.

Meses depois, uma regra muda.

A outra não.

Agora a reutilização passa a atrapalhar.

Por isso muitos arquitetos repetem uma frase importante:

"Não reutilize por preguiça de escrever código. Reutilize porque existe realmente um conhecimento comum."


DRY conversa com toda esta série

Ao longo dos artigos Bellacosa Mainframe, você já encontrou diversos princípios que se relacionam diretamente com o DRY.

Ele ajuda a evitar:

  • Spaghetti Code, reduzindo trechos repetidos espalhados pelo sistema.

  • Golden Hammer, porque incentiva pensar antes de copiar soluções.

  • Lava Flow, evitando múltiplas versões abandonadas da mesma regra.

  • Big Ball of Mud, diminuindo a desorganização.

  • KISS, favorecendo soluções claras e centralizadas.

  • YAGNI, impedindo a criação de módulos duplicados "para o futuro".

Perceba que todos esses princípios caminham na mesma direção:

software simples, consistente e sustentável.


O ensinamento do Oráculo

O Oráculo entrega a Neo um enorme livro.

Cada capítulo conta exatamente a mesma história.

Neo pergunta:

— Por que repetir tudo isso?

Ela sorri.

Depois entrega outro livro.

Nele existe apenas uma história.

Todos os capítulos fazem referência a ela.

Neo entende imediatamente.

Ela então diz:

"A verdade precisa existir apenas uma vez. Todas as cópias são oportunidades para que ela deixe de ser verdade."


Lições para um Programador COBOL Padawan

Durante sua jornada no universo IBM Z, você encontrará muitas oportunidades de usar o famoso CTRL+C / CTRL+V.

À primeira vista parece uma solução rápida.

Mas faça uma pausa.

Pergunte a si mesmo:

  • Essa regra já existe em outro lugar?

  • Posso transformá-la em um subprograma?

  • Um COPYBOOK resolveria?

  • Essa validação deveria ser centralizada?

  • Estou duplicando conhecimento ou apenas reutilizando uma estrutura?

Essas perguntas fazem enorme diferença ao longo dos anos.

Lembre-se de que a maior parte do custo de um software está na manutenção.

Quanto menos lugares precisarem ser alterados para implementar uma mudança de negócio, maior será a qualidade do sistema.


Curiosidades

O princípio DRY influenciou profundamente diversas tecnologias modernas:

  • Domain-Driven Design, incentivando uma única fonte para conceitos do domínio.

  • APIs REST e GraphQL, centralizando serviços reutilizáveis.

  • Infrastructure as Code, eliminando configurações duplicadas.

  • GitHub Actions, reutilizando pipelines.

  • Ansible, através de roles e playbooks compartilhados.

  • Kubernetes, reutilizando manifestos e templates.

  • CI/CD, automatizando tarefas repetitivas em vez de executá-las manualmente.

A ideia permanece exatamente a mesma apresentada por Hunt e Thomas em 1999: uma única representação confiável para cada conhecimento.


Conclusão — A Matrix Não Precisava de Mil Smiths

No final de Matrix Reloaded e Matrix Revolutions, Smith tornou-se uma ameaça justamente porque sua capacidade de se replicar saiu do controle.

Na Engenharia de Software acontece algo semelhante.

Cada regra copiada, cada SQL duplicado, cada validação repetida cria mais uma versão da mesma verdade.

E quando a verdade muda, todas as cópias precisam mudar junto.

O princípio DRY nos lembra que software sustentável depende de uma única fonte de conhecimento para cada regra importante.

Para um Programador COBOL que trabalha com IBM Z, isso significa valorizar COPYBOOKs, subprogramas, APIs compartilhadas e componentes reutilizáveis, sempre com equilíbrio e sem criar abstrações artificiais.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na oficina do Chaveiro:

"Se uma única chave abre todas as portas corretas, cuide bem dela. Construir cem cópias da mesma chave apenas torna mais difícil descobrir qual delas ainda funciona."

Porque, assim como Neo descobriu que um único Escolhido era mais poderoso do que milhares de cópias imperfeitas de Smith, um sistema também se torna muito mais confiável quando cada conhecimento existe em um único lugar, claro, bem documentado e fácil de manter.

sexta-feira, 26 de junho de 2020

☕ O Holocron do Código de Barras: Como um Pequeno Conjunto de Linhas Mudou o Comércio Mundial

 

Bellacosa Mainframe e a origem dos codigos de barra

☕ O Holocron do Código de Barras: Como um Pequeno Conjunto de Linhas Mudou o Comércio Mundial

Em 26 de junho de 1974, ocorreu um daqueles eventos discretos que raramente aparecem nos livros de História, mas que acabaram moldando a civilização moderna.

Num supermercado Marsh Supermarket em Troy, Ohio, uma caixa registradora leu pela primeira vez um UPC (Universal Product Code) impresso em uma embalagem de chicletes Wrigley's Juicy Fruit.

Era apenas um pacote de chicletes.

Mas, na prática, foi o nascimento da infraestrutura invisível do varejo contemporâneo.

Hoje, bilhões de leituras de códigos de barras acontecem diariamente em supermercados, hospitais, aeroportos, centros de distribuição, bibliotecas, fábricas e datacenters.

E existe um forte DNA da IBM nessa história.


Antes do código de barras: o caos do varejo

Imagine um supermercado em 1960.

Cada produto precisava ser:

  • etiquetado manualmente;

  • precificado individualmente;

  • registrado na caixa por digitação;

  • contabilizado posteriormente.

Problemas comuns:

Erro humano.

Filas enormes.

Inventário incorreto.

Furtos não detectados.

Reposição lenta.

Ausência de estatísticas.

O gerente sabia quanto havia vendido apenas dias depois.

Era uma operação quase artesanal.


A ideia original não veio da IBM

Em 1949, dois estudantes americanos:

  • Norman Joseph Woodland

  • Bernard Silver

Buscavam uma solução para automatizar supermercados.

Inspirados em:

Código Morse;

Trilhas ópticas;

Tecnologias militares.

Woodland desenhou linhas na areia de uma praia.

As linhas lembravam ondas circulares.

Nascia o primeiro conceito.

Código em alvo (Bullseye)

Parecia um alvo de tiro.

Leitura em qualquer direção.

Problema:

difícil impressão;

distorções;

baixo contraste.

Patentearam em 1952.

Porém, faltava tecnologia.

Computadores eram gigantescos.

Lasers comerciais não existiam.

Sensores ópticos eram caros.

O projeto ficou adormecido.


IBM entra em cena

Nos anos 70, supermercados americanos decidiram:

Precisamos de um padrão único.

Diversas empresas apresentaram propostas.

RCA apresentou versões circulares.

Outras empresas tinham símbolos complexos.

IBM designou um engenheiro chamado:

George Joseph Laurer

Ele recebeu uma missão aparentemente simples:

Desenvolver um código melhor.

Mas havia inúmeras restrições.

Precisava ser:

Legível rapidamente;

Barato;

Pequeno;

Robusto;

Padronizado;

Compatível com impressoras.

Laurer simplificou tudo.

Criou barras verticais.

Espessuras variáveis.

Zonas de silêncio.

Dígitos verificadores.

Leitura bidirecional.

Nascia o:

UPC

Universal Product Code


O primeiro produto escaneado

26 de junho de 1974.

Local:

Marsh Supermarket

Troy, Ohio

Produto:

Wrigley's Juicy Fruit Gum

Preço:

67 centavos.

A leitura ocorreu em poucos milissegundos.

Ninguém imaginava a magnitude do evento.


A genialidade matemática do UPC

O código possui 12 dígitos.

Exemplo:

036000291452

Estrutura:

Número fabricante

Número produto

Check digit


Dígito verificador

Serve para detectar erros.

Exemplo simplificado:

Somar posições ímpares.

Multiplicar por 3.

Somar posições pares.

Calcular módulo 10.

Se falhar:

scanner rejeita.

É semelhante ao que encontramos em:

CPF;

ISBN;

cartões bancários.


O scanner laser

Outro desafio enorme.

Como ler rapidamente?

Solução:

Feixe laser.

Espelhos rotativos.

Fotossensores.

O sistema mede:

reflexão da luz.

Branco = reflexão alta

Preto = reflexão baixa

Transformação:

Óptico

Elétrico

Digital

Aplicação comercial


O equivalente varejista do protocolo TCP/IP

O UPC tornou-se uma infraestrutura invisível.

Poucas pessoas pensam nele.

Mas ele conecta:

Fabricantes.

Distribuidores.

Transportadoras.

ERP.

WMS.

PDV.

Data Warehouse.

BI.

IA.

É praticamente o:

TCP/IP do varejo.


IBM e a filosofia dos padrões

A IBM historicamente prosperou criando padrões.

Exemplos:

SQL

EBCDIC

SNA

DRDA

COBOL (forte participação)

UPC

IBM percebeu cedo:

O verdadeiro poder não está apenas em fabricar máquinas.

Está em definir linguagens universais.


O código de barras dentro do IBM Z

Curiosamente, muitos sistemas IBM Z continuam sendo responsáveis por processar os dados gerados pelos scanners.

Exemplo típico:

Scanner

PDV

MQ

CICS

COBOL

Db2

Batch Noturno

Data Lake

IA

Ao passar um pacote de café no caixa, pode acontecer:

CICS valida preço;

COBOL verifica promoção;

Db2 consulta estoque;

MQ envia evento;

Batch ajusta inventário;

Modelo de IA prevê reposição.

Tudo em segundos.


O sucessor do UPC

O mundo está migrando gradualmente para:

GS1 Digital Link

QR Codes industriais

DataMatrix

RFID

NFC

Essas tecnologias permitem armazenar:

Lote;

Validade;

Origem;

Certificações;

Rastreamento;

Pegada de carbono;

Informações nutricionais.

Um simples escaneamento poderá revelar toda a cadeia produtiva de um alimento.


Uma análise mais profunda: por que o código de barras é uma das maiores invenções do século XX?

Costumamos admirar tecnologias visíveis:

  • Inteligência Artificial;

  • Computação Quântica;

  • Robótica;

  • Satélites.

Entretanto, a economia mundial depende de tecnologias extremamente discretas.

Poucas inovações entregaram um retorno econômico tão extraordinário quanto o código de barras. Ele reduziu custos operacionais, diminuiu perdas, acelerou filas, permitiu inventários quase em tempo real, alimentou sistemas de planejamento logístico e viabilizou o crescimento das grandes redes globais de varejo.

Sem códigos de barras, seria difícil imaginar:

  • Amazon operando milhões de itens;

  • Walmart sincronizando milhares de lojas;

  • hospitais rastreando medicamentos;

  • aeroportos gerenciando bagagens;

  • centros de distribuição altamente automatizados;

  • modelos modernos de previsão de demanda baseados em IA.

George Laurer não criou apenas um símbolo gráfico. Ele ajudou a construir uma linguagem universal para objetos físicos, uma espécie de protocolo de comunicação entre produtos, empresas, computadores e consumidores.

Para um profissional de IBM Z, a lição é particularmente familiar: assim como um copybook COBOL, um registro VSAM, um DB2 catalog ou um SMF record, o código de barras demonstra que as maiores revoluções tecnológicas frequentemente surgem não de interfaces espetaculares, mas de padrões simples, robustos e estáveis que permanecem funcionando silenciosamente por décadas.

"A IA pode decidir o que comprar amanhã. Mas, em boa parte do mundo, ainda será um descendente direto das barras desenhadas por George Laurer que dirá ao sistema exatamente o que saiu da prateleira hoje."

 

segunda-feira, 22 de junho de 2020

Necesse : Quando um Programador COBOL Descobre que um Data Center Também Pode Crescer Sozinho..

 

Bellacosa Mainframe apresenta necesse sem misterios

☕ Um Café no Bellacosa Mainframe

Necesse sem Mistérios

Quando um Programador COBOL Descobre que um Data Center Também Pode Crescer Sozinho... Desde que Alguém Organize os Recursos, Automatize o Trabalho e Confie na Própria Equipe

Existe uma pergunta que acompanha praticamente todos os jogos de sobrevivência.

"Quanto tempo você consegue sobreviver sozinho?"

Necesse faz outra pergunta.

Muito mais interessante.

"E se você não precisasse fazer tudo sozinho?"

Essa pequena mudança transforma completamente a experiência.

Enquanto muitos jogos colocam o jogador para cortar cada árvore, minerar cada pedra e carregar cada recurso durante centenas de horas, Necesse permite construir uma verdadeira comunidade.

Você recruta moradores.

Distribui tarefas.

Organiza produção.

Automatiza trabalho.

Constrói uma cidade.

Sem perceber...

Você deixa de controlar apenas um personagem.

Passa a administrar um ecossistema inteiro.

Para um programador COBOL isso lembra imediatamente um ambiente IBM Z.

Ninguém administra sozinho:

  • CICS

  • Db2

  • MQ

  • RACF

  • JES2

  • z/OS

Cada componente possui sua responsabilidade.

Quando todos trabalham juntos...

O sistema inteiro prospera.

Necesse captura exatamente essa filosofia.

Pegue sua caneca.

Hoje vamos conhecer um dos jogos independentes mais completos da atualidade.


A origem

Necesse foi desenvolvido pelo estúdio independente dinamarquês Fair Games ApS. O projeto começou como uma proposta de combinar elementos de Terraria, RimWorld, Minecraft e RPGs clássicos em um único universo procedural, com forte ênfase na automação e no gerenciamento de colonos. O jogo entrou em Acesso Antecipado (Early Access) na Steam em 12 de dezembro de 2019 e continua recebendo grandes atualizações, com novos biomas, chefes, sistemas e melhorias. (store.steampowered.com, )


O estúdio

A Fair Games ApS escolheu um caminho diferente da maioria dos grandes estúdios.

Ao invés de investir apenas em gráficos.

Investiu em sistemas.

Profundos.

Interligados.

Flexíveis.

É um daqueles jogos onde.

Quanto mais você aprende.

Mais possibilidades aparecem.


A história

A narrativa é simples.

Você chega a um enorme mundo procedural.

Explora ilhas.

Descobre ruínas.

Constrói sua base.

Enfrenta criaturas.

Derrota chefes.

Mas a verdadeira história é escrita pelo jogador.

Cada mundo torna-se único.


O verdadeiro objetivo

Também não existe apenas um.

Você decide.

Pode dedicar centenas de horas a:

  • construir;

  • minerar;

  • explorar;

  • automatizar;

  • recrutar moradores;

  • administrar produção;

  • derrotar chefes.

Cada aventura é diferente.


O mundo

O universo é composto por inúmeras ilhas.

Cada uma apresenta.

  • biomas;

  • cavernas;

  • recursos;

  • chefes;

  • tesouros.

Você navega constantemente entre elas.


A jogabilidade

O ciclo lembra uma arquitetura corporativa extremamente organizada.

Explorar

↓

Minerar Recursos

↓

Construir Cidade

↓

Recrutar Colonos

↓

Automatizar Produção

↓

Fabricar Equipamentos

↓

Derrotar Chefes

↓

Explorar Novas Ilhas

É um ciclo extremamente satisfatório.


Construção

Você pode construir praticamente tudo.

Casas.

Muros.

Armazéns.

Fazendas.

Oficinas.

Cozinhas.

Laboratórios.

Tudo cresce naturalmente.


Colonos

Aqui mora a maior diferença.

Você recruta moradores.

Cada um trabalha.

Automaticamente.

Pode:

  • plantar;

  • cozinhar;

  • fabricar;

  • minerar;

  • transportar recursos;

  • defender a cidade.

É quase um RimWorld simplificado.


Agricultura

Existe um excelente sistema agrícola.

Você cultiva.

  • trigo;

  • frutas;

  • vegetais;

  • ervas.

Tudo utilizado na alimentação dos colonos.


Cozinha

Os moradores podem cozinhar automaticamente.

Você apenas organiza.

Eles executam.

É extremamente agradável.


Exploração

Cada ilha parece um pequeno mundo.

Sempre existe.

Uma caverna.

Um chefe.

Uma estrutura antiga.

Um minério raro.

Nunca falta conteúdo.


Mineração

Naturalmente.

Você coleta.

  • cobre;

  • ferro;

  • ouro;

  • minerais raros.

Tudo utilizado para melhorar equipamentos.


Craft

Existe uma enorme árvore tecnológica.

Você fabrica.

  • armas;

  • armaduras;

  • ferramentas;

  • móveis;

  • máquinas;

  • alimentos.

Sempre existe algo novo.


Combate

O combate lembra bastante Terraria.

Você utiliza.

  • espadas;

  • arcos;

  • magia;

  • armas de fogo;

  • lanças.

Cada estilo possui vantagens próprias.


Chefes

Os chefes representam grandes marcos da progressão.

Cada vitória.

Desbloqueia novos materiais.

Novas regiões.

Novas tecnologias.


Multiplayer

Até dezenas de jogadores podem compartilhar o mesmo servidor, dependendo da configuração.

É possível.

  • construir cidades enormes;

  • dividir profissões;

  • explorar juntos;

  • enfrentar chefes cooperativamente.


Automação

Aqui está o diferencial.

Você praticamente monta uma pequena fábrica.

Os colonos.

Produzem.

Transportam.

Armazenam.

Distribuem.

Tudo quase automaticamente.

É extremamente satisfatório.


Curiosidades

  • Necesse ficou conhecido por unir a liberdade de Terraria com sistemas de gerenciamento inspirados em simuladores de colônia.

  • Mesmo em Early Access, o jogo recebeu inúmeras atualizações robustas, ampliando significativamente o conteúdo.

  • A comunidade destaca a excelente otimização e o suporte contínuo dos desenvolvedores.


Easter Eggs

Existem diversos pequenos segredos.

Como.

  • estruturas escondidas;

  • ilhas raras;

  • equipamentos especiais;

  • NPCs incomuns;

  • salas secretas.

Grande parte deles depende apenas da exploração.


Os riscos

O maior risco.

Pensar.

"Vou organizar só um depósito."

Três horas depois.

Você automatizou metade da cidade.

Outro risco.

Esquecer de fortalecer as defesas.

Os monstros também evoluem.


As vantagens

Necesse reúne praticamente tudo.

✔ exploração

✔ agricultura

✔ mineração

✔ construção

✔ automação

✔ RPG

✔ chefes

✔ multiplayer

Sem.

❌ gacha

❌ passes de batalha

❌ energia

❌ microtransações invasivas

Você compra.

Instala.

Joga.


A diversão

Cada sessão parece diferente.

Hoje.

Constrói uma fazenda.

Amanhã.

Recruta novos moradores.

Depois.

Descobre outra ilha.

Mais tarde.

Enfrenta um chefe gigantesco.

É muito difícil ficar sem objetivos.


O Caminho do Padawan

Se está começando.

Faça assim.

✔ construa abrigo cedo;

✔ recrute moradores rapidamente;

✔ automatize tarefas simples;

✔ organize depósitos;

✔ cozinhe bastante;

✔ explore lentamente;

✔ enfrente chefes apenas quando estiver preparado.

No Bellacosa Mainframe existe uma regra semelhante.

"Nunca deixe uma rotina batch depender exclusivamente de trabalho manual."


Requisitos para PC

Mínimos:

  • Windows 10 (64 bits)

  • Processador Dual Core 2,5 GHz

  • 4 GB de RAM

  • GPU compatível com OpenGL 3.2

  • Cerca de 1 GB de espaço livre

Recomendados:

  • Intel Core i5 ou AMD Ryzen equivalente

  • 8 GB de RAM

  • GPU dedicada moderna

Graças ao visual em pixel art, Necesse roda muito bem até mesmo em computadores modestos. (store.steampowered.com)


Tipo de instalação

É um jogo premium.

Compra única.

Instalação digital.

Disponível para Windows, Linux e macOS através da Steam, ampliando bastante sua acessibilidade para jogadores de desktop. (store.steampowered.com)


Custo

O preço oficial costuma ficar em torno de US$ 14,99, variando conforme promoções e a região da Steam.


Classificação

  • Gênero: RPG, sobrevivência, sandbox, construção, gerenciamento de colônia, aventura e exploração.

  • Modo: Um jogador e multiplayer cooperativo.

  • Classificação indicativa: geralmente E10+ / Livre para maiores de 10 anos, por conter violência leve em fantasia e combate contra criaturas.


Site oficial

Para acompanhar novidades e o desenvolvimento do jogo:


Curiosidade para Programadores COBOL

Se Stardew Valley representa um sistema administrativo bem organizado...

Outward lembra um ambiente de produção onde sobreviver exige planejamento...

Core Keeper simboliza a exploração das profundezas de um grande banco de dados...

Dinkum representa o crescimento de uma cidade...

Kynseed ensina o valor do legado...

Moonstone Island lembra uma arquitetura distribuída baseada em serviços...

Então Necesse é praticamente um ambiente IBM Z totalmente automatizado.

Os colonos funcionam como jobs batch.

Os armazéns lembram bancos de dados compartilhados.

As oficinas são linhas de produção.

As rotas de transporte parecem filas MQ.

E você deixa de ser apenas um operador.

Passa a atuar como um arquiteto de sistemas, organizando processos para que toda a infraestrutura funcione de maneira eficiente mesmo quando você está explorando outra ilha.


Conclusão

Necesse demonstra que sobrevivência não significa fazer tudo sozinho. Seu verdadeiro diferencial está em transformar uma pequena base em uma comunidade próspera, onde cada morador contribui para um objetivo maior.

Sob a perspectiva do Bellacosa Mainframe, ele se parece com um ambiente corporativo maduro: tarefas repetitivas são automatizadas, responsabilidades são distribuídas e o administrador deixa de apagar incêndios para focar em evolução e estratégia.

Sua maior lição é clara.

Grandes sistemas não crescem porque uma única pessoa trabalha mais.

Eles crescem porque o trabalho é organizado, compartilhado e continuamente aprimorado.

No fim das contas, seja em uma colônia pixelada ou em um data center IBM Z, o verdadeiro segredo nunca foi fazer tudo sozinho.

Foi construir um ecossistema capaz de prosperar mesmo quando você parte para explorar novos horizontes.

domingo, 21 de junho de 2020

🏠 Bellacosa Otaku Blog — Parte 14: Expressões Cotidianas e de Interação Social nos Animes 🏠

Bellacosa Mainframe e expressoes cotidians


 🏠 Bellacosa Otaku Blog — Parte 14: Expressões Cotidianas e de Interação Social nos Animes 🏠

Mais uma Viagem pelo Universo dos Animes, Mangás e da Cultura Japonesa

O universo otaku é praticamente infinito. A cada temporada surgem novos animes, novos mangás, personagens memoráveis, curiosidades históricas e detalhes culturais que passam despercebidos pela maioria dos espectadores. É justamente essa riqueza de informações que torna a cultura japonesa tão fascinante para quem gosta de aprender enquanto se diverte.

A série Bellacosa Otaku Blog nasceu com essa proposta: reunir pequenas descobertas, fatos curiosos, referências escondidas e conhecimentos que ajudam a enxergar animes e mangás muito além das batalhas, do humor ou do fanservice. Cada artigo funciona como uma pequena cápsula de conhecimento, conectando história, tecnologia, sociedade, folclore, idioma, gastronomia e cultura pop japonesa em uma leitura leve e descontraída.

Nesta décima quarta parte, o objetivo continua o mesmo: despertar a curiosidade do leitor e mostrar que, por trás de cada personagem, cada cenário e cada costume apresentado nas animações japonesas, existe um enorme patrimônio cultural construído ao longo de séculos. Muitas vezes um simples detalhe visto durante poucos segundos em um episódio possui uma explicação histórica ou social extremamente interessante.

Prepare seu café, ajuste seus fones de ouvido e embarque em mais uma viagem pelo Japão através dos olhos de um verdadeiro apaixonado pela cultura otaku. Afinal, conhecer essas curiosidades torna cada anime ainda mais divertido de assistir e cada mangá ainda mais rico de apreciar.



🌸 O dia a dia japonês em palavras: saudação, educação e convivência

(Versão Bellacosa: sorrisos, reverências e pequenas gentilezas que definem o cotidiano anime.)

Nem só de magia, batalhas ou romance vivem os animes.
A vida cotidiana é cheia de expressões educadas, sutis e culturais que mostram amizade, respeito e etiqueta.
Vamos explorar as mais comuns que aparecem em qualquer cena diária, escola ou trabalho. ☕


🙇‍♂️ 1. おはようございます (ohayou gozaimasu)

Tradução: “Bom dia” (formal).
👉 Saudação matinal usada em escolas, trabalho ou ao encontrar alguém respeitosamente.

📺 Anime vibe: K-On!, Clannad.
💬 Exemplo: “Ohayou gozaimasu, senpai! Bom dia!” 🌞


🌅 2. こんにちは (konnichiwa)

Tradução: “Boa tarde / olá.”
👉 Saudação padrão durante o dia, casual ou formal dependendo do contexto.

📺 Anime vibe: Nichijou, March Comes in Like a Lion.
💬 Exemplo: “Konnichiwa! Como foi sua manhã?” ☕


🌙 3. こんばんは (konbanwa)

Tradução: “Boa noite.”
👉 Usada ao encontrar alguém à noite — não é despedida, mas saudação noturna.

📺 Anime vibe: Your Lie in April, Clannad.
💬 Exemplo: “Konbanwa! Que dia longo hoje.” 🌌


🙏 4. ありがとうございます (arigatou gozaimasu)

Tradução: “Muito obrigado” (formal).
👉 Essencial para expressar gratidão em qualquer situação.

📺 Anime vibe: Kimi ni Todoke, Nichijou.
💬 Exemplo: “Arigatou gozaimasu por me ajudar com o dever!” 💖


😅 5. すみません (sumimasen)

Tradução: “Desculpe / com licença.”
👉 Pode significar desculpa, chamar atenção ou agradecer de forma educada.

📺 Anime vibe: Azumanga Daioh, K-On!.
💬 Exemplo: “Sumimasen, posso passar?” 🙇‍♀️


👋 6. じゃあね (jaa ne)

Tradução: “Tchau / até mais” (informal).
👉 Usado entre amigos ou colegas, casual e amigável.

📺 Anime vibe: Toradora!, Nichijou.
💬 Exemplo: “Jaa ne! Nos vemos amanhã!” 👋


✨ 7. お疲れ様です (otsukaresama desu)

Tradução: “Obrigado pelo esforço / bom trabalho.”
👉 Muito usada no trabalho, clubes ou atividades escolares, mostrando respeito pelo esforço do outro.

📺 Anime vibe: March Comes in Like a Lion, K-On!.
💬 Exemplo: “Otsukaresama desu, senpai! Ótima apresentação hoje!” 💼


😌 8. いってきます (ittekimasu) / いってらっしゃい (itterasshai)

Tradução: “Estou indo / Vá e volte com segurança.”
👉 Expressões usadas em família ou entre colegas de casa, no cotidiano doméstico.

📺 Anime vibe: Clannad, Your Lie in April.
💬 Exemplo:

  • “Ittekimasu!” 🏃‍♂️

  • “Itterasshai! Cuide-se!” 🏡


🍵 9. ただいま (tadaima) / おかえり (okaeri)

Tradução: “Cheguei!” / “Bem-vindo de volta!”
👉 Diálogo clássico entre membros da família ou colegas de casa, expressando acolhimento.

📺 Anime vibe: Clannad, K-On!.
💬 Exemplo:

  • “Tadaima!”

  • “Okaeri! Comeu bem?” 🍚


😄 10. よろしくお願いします (yoroshiku onegaishimasu)

Tradução: “Conto com você / prazer em conhecê-lo.”
👉 Usada em primeira interação, pedidos ou trabalhos em grupo — essencial na etiqueta japonesa.

📺 Anime vibe: K-On!, Nichijou.
💬 Exemplo: “Yoroshiku onegaishimasu! Espero trabalhar bem com você.” 🙏


🏮 Curiosidades Bellacosa:

  • Expressões como otsukaresama desu ou yoroshiku onegaishimasu mostram respeito e educação, pilares da cultura japonesa.

  • Muitos animes usam esses diálogos para criar atmosfera realista do cotidiano e conexão entre personagens.

  • Até em cenas de comédia, essas frases são usadas com exagero ou entonação dramática, criando humor. 😂


🌟 Dica Bellacosa:

  • Observe a diferença entre formal e informal: ohayou gozaimasu (formal) vs. ohayou (informal).

  • Praticar essas expressões ajuda a entender contexto social japonês e a soar natural em diálogos.

  • São perfeitas para interações diárias, seja em anime, viagem ou estudo de japonês. 🏡


🌸 Conclusão Bellacosa:

O cotidiano japonês nos animes é cheio de pequenos rituais e palavras de gentileza.
Elas mostram respeito, amizade e convivência, tornando o mundo do anime mais crível e acolhedor.
Cada saudação, agradecimento ou despedida carrega emoção e cultura, tornando a vida diária fascinante para espectadores e fãs. ✨

“Ohayou! Sumimasen, obrigado por tudo hoje. Jaa ne!” ☀️🏠

sábado, 20 de junho de 2020

🚛 Quando o Brasil Parou — A Grande Greve dos Caminhoneiros de 2015

 

Bellacosa Mainframe e a greve dos caminhoneiros

🚛 Quando o Brasil Parou — A Grande Greve dos Caminhoneiros de 2015

Há memórias que parecem ficção, mas que deixaram marcas mais fundas que as manchetes.
2015 foi uma dessas encruzilhadas — um daqueles anos em que o Brasil pareceu parar, literalmente, no acostamento da própria história.
As rodovias ficaram vazias, os caminhões estacionados, os tanques secos e os corações cheios de incerteza.

Lembro bem.
As notícias chegavam aos poucos, em fragmentos: bloqueios nas estradas, comboios parados, cidades começando a sentir o desabastecimento.
Era como se o fluxo sanguíneo do país tivesse sido cortado — e cada armazém, cada posto, cada supermercado fosse um órgão à beira da falência.

Mas aquilo era mais do que uma paralisação: era um grito de exaustão nacional.
O aumento no preço do diesel foi só a faísca — o barril de pólvora estava pronto há tempos.
O caminhoneiro, aquele herói anônimo que cruzava o país com o motor como trilha sonora, carregava nas costas não só carga, mas a conta de uma economia emperrada, de promessas políticas furadas e de um custo de vida que subia mais rápido do que qualquer ladeira da Serra do Mar.

Nas estradas, o Brasil real se mostrava sem maquiagem:
lonas improvisadas, churrascos à beira da pista, pneus queimados e cartazes rabiscados à mão.
E, nos noticiários, o caos urbano ganhava forma — filas nos postos, supermercados vazios, o medo de faltar o básico.

Mas havia também algo simbólico naquela parada.
O país, acostumado a correr sem saber pra onde, foi forçado a olhar para si mesmo, estacionar e sentir o peso da engrenagem que não girava mais.
O silêncio das estradas ecoava mais alto que o barulho dos motores:
um lembrete de que toda grande máquina, seja ela industrial ou social, depende de gente — e de justiça.

Quando o movimento terminou, o Brasil já não era o mesmo.
Alguns chamaram de vitória, outros de desastre.
Mas, olhando hoje, com a distância do tempo e a frieza dos bits, dá pra ver o impacto como ponto de inflexão:
foi ali que a desconfiança entre o povo e o poder cresceu,
foi ali que as ruas começaram a se dividir,
foi ali que a sensação de colapso deixou de ser medo e virou rotina.

A greve de 2015 não foi apenas uma paralisação —
foi um espelho quebrado.
Mostrou um país cansado de remar em marcha lenta,
um povo dividido entre o asfalto e o asfalto rachado,
e uma política que, mais uma vez, não soube ouvir o ronco do motor da nação.

Hoje, quase uma década depois, quando cruzo uma rodovia e vejo um caminhão passando na madrugada, penso que aquele som — o ronco grave de um motor em marcha constante — é mais do que transporte:
é o pulso do Brasil.
Um pulso que já parou, já voltou, e segue — aos trancos, mas segue.

Porque o Brasil é assim:
às vezes freia, às vezes derrapa, mas nunca desiste da estrada.

segunda-feira, 15 de junho de 2020

CICS READNEXT & READPREV — A Jornada pela Estrada dos Registros do Reino VSAM

 

Bellacosa Mainframe e o acesso ao vsam via cics

☕ Um Café no Bellacosa Mainframe

CICS READNEXT & READPREV — A Jornada pela Estrada dos Registros do Reino VSAM

Quando um Programador COBOL Padawan Descobre que a Maior Sabedoria Não Está em Encontrar um Registro, Mas em Caminhar Pelo Caminho que Ele Revela

"Há quem pense que um grande programador é aquele que conhece todas as instruções do COBOL. Os velhos magos do mainframe sorriem diante dessa ideia. Eles sabem que o verdadeiro conhecimento nasce quando compreendemos como os dados percorrem silenciosamente os caminhos invisíveis do sistema."


Prólogo — A Biblioteca Perdida de Gondor

Imagine que você foi convocado por Gandalf para visitar a maior biblioteca já construída na Terra-média.

Não existe Google.

Não existe banco de dados SQL.

Não existe um campo de pesquisa.

Existem apenas milhões de pergaminhos cuidadosamente organizados em prateleiras infinitas.

Cada pergaminho possui um código.

Você procura o registro do cidadão número 000245987.

Um aprendiz sairia correndo entre as estantes procurando manualmente.

Um Mestre Arquivista simplesmente abriria o livro correto exatamente na página desejada.

O VSAM KSDS funciona exatamente assim.

E o CICS oferece um conjunto de comandos que transforma essa biblioteca em algo extremamente simples de navegar.

Esses comandos são:

  • STARTBR

  • READNEXT

  • READPREV

  • ENDBR

À primeira vista parecem comandos pequenos.

Na realidade, escondem décadas de engenharia da IBM.

Hoje vamos abrir essa caixa de segredos.


A filosofia do Browse

Antes de aprender READNEXT, precisamos abandonar um hábito mental muito comum.

Quando iniciamos no COBOL pensamos assim:

Quero um registro.

Então usamos:

READ

Mas sistemas corporativos raramente trabalham dessa forma.

Na maior parte do tempo o usuário deseja algo como:

"Mostre os próximos clientes."

"Liste os próximos pedidos."

"Passe para a próxima página."

"Volte um cliente."

"Continue de onde parei."

Isso muda completamente o problema.

Agora não estamos mais procurando um registro.

Estamos percorrendo um caminho.

É justamente aí que nasce o conceito de Browse.


O que significa Browse?

Browse significa literalmente:

Navegar.

Não pesquisar.

Não localizar.

Não buscar.

Navegar.

É como abrir um livro.

Você não procura cada página individualmente.

Você simplesmente vira a próxima folha.

Depois outra.

Depois outra.

Depois volta uma página.

Essa é exatamente a filosofia do Browse do CICS.


O protagonista invisível: STARTBR

Todo filme possui um herói.

Todo RPG possui um ponto inicial.

Todo programa CICS possui um STARTBR.

Sem ele nada acontece.

Seu trabalho não é ler registros.

Seu trabalho é muito mais importante.

Ele diz ao CICS:

"Prepare a viagem."

Exemplo:

EXEC CICS STARTBR
     FILE('CLIENTES')
     RIDFLD(WS-CHAVE)
END-EXEC.

Observe uma curiosidade interessante.

Nenhum registro foi retornado.

Nenhum dado foi copiado.

Nenhuma informação apareceu.

Então por que executar STARTBR?

Porque ele cria algo invisível.


A Sessão de Browse

Quando STARTBR é executado, o CICS cria internamente uma estrutura.

Essa estrutura guarda:

  • posição atual

  • chave corrente

  • ponteiro para o arquivo

  • direção da leitura

  • contexto da navegação

  • estado da operação

Pense nela como um marcador de páginas.

Imagine ler "O Senhor dos Anéis".

Você fecha o livro.

No dia seguinte abre exatamente onde parou.

O marcador fez isso.

STARTBR cria exatamente esse marcador.

Sem ele o CICS não sabe de onde continuar.


Uma comparação moderna

Hoje usamos streaming.

Netflix lembra onde paramos.

Spotify lembra a música.

Kindle lembra a página.

Google Docs lembra o cursor.

STARTBR fazia isso décadas antes da internet existir.


READNEXT — O Guardião da Estrada

Agora começa a aventura.

EXEC CICS READNEXT
     FILE('CLIENTES')
     INTO(WS-REG)
     RIDFLD(WS-ID)
END-EXEC.

Parece simples.

Mas internamente acontece uma verdadeira orquestra.

O CICS pergunta ao VSAM:

Qual registro vem depois deste?

O VSAM responde imediatamente.

Depois atualiza o marcador.

Depois entrega os dados.

Tudo isso em poucos microssegundos.


Como o VSAM sabe qual é o próximo?

Aqui encontramos uma das maiores genialidades do VSAM.

Muitos imaginam que ele percorra todo o arquivo.

Não.

Ele utiliza sua árvore de índices.

Visualmente:

                 Índice Raiz

               /             \

        Índice A          Índice B

        /     \            /     \

     Dados   Dados      Dados   Dados

Quando STARTBR encontra o registro inicial...

READNEXT simplesmente anda para frente.

Quando termina uma folha...

o índice aponta automaticamente para a próxima.

O programa COBOL nunca percebe isso.


A magia do KSDS

KSDS significa:

Key Sequenced Data Set

Ou seja...

os registros são armazenados obedecendo uma ordem lógica.

Veja:

000100 João

000150 Carlos

000220 Maria

000330 Pedro

000410 Ana

Não importa a ordem física.

Importa a ordem da chave.

READNEXT respeita exatamente essa sequência.


READPREV — O Retorno do Rei

Agora imagine uma tela de consulta.

O operador pressiona:

PF8

Próximo cliente.

Depois outro.

Depois outro.

Mas então lembra que esqueceu uma informação.

Pressiona:

PF7

O programa executa:

READPREV

E retorna ao registro anterior.

Parece simples.

Mas isso evita milhares de buscas.


Curiosidade pouco conhecida

Muitos iniciantes acreditam que READPREV faz o disco girar ao contrário.

Não.

O VSAM utiliza novamente sua árvore B.

Ele encontra rapidamente o registro anterior utilizando o índice.

Essa estrutura é extremamente eficiente.

Mesmo arquivos com dezenas de milhões de registros continuam rápidos.


O Browse lembra um Cursor SQL?

Muito.

Veja.

SQL

DECLARE CURSOR

OPEN

FETCH NEXT

FETCH PRIOR

CLOSE

Agora compare.

CICS

STARTBR

READNEXT

READPREV

ENDBR

São filosofias quase idênticas.

Não por acaso.

Muitos conceitos modernos nasceram justamente dos ambientes mainframe.


O ciclo completo

Uma navegação típica acontece assim.

STARTBR

↓

READNEXT

↓

READNEXT

↓

READNEXT

↓

READPREV

↓

READNEXT

↓

READNEXT

↓

ENDBR

Simples.

Elegante.

Confiável.


E o ENDBR?

Todo começo precisa de um fim.

Quando terminamos:

EXEC CICS ENDBR
     FILE('CLIENTES')
END-EXEC.

O CICS remove:

  • ponteiros

  • buffers

  • contexto

  • sessão

  • recursos internos

Imagine esquecer ENDBR.

Seria como abandonar centenas de livros abertos pela biblioteca.

Alguém precisará organizá-los depois.

Por isso ENDBR é obrigatório.


O segredo dos códigos RESP

Programadores iniciantes costumam cometer um erro clássico.

Ignoram RESP.

Jamais faça isso.

Exemplo:

RESP = NORMAL

Tudo certo.


RESP = ENDFILE

Fim da navegação.

Não é erro.


RESP = NOTFND

Registro não localizado.


RESP = INVREQ

Pedido inválido.

Geralmente STARTBR inexistente.


RESP = FILENOTFOUND

Arquivo indisponível.


RESP = LOCKED

Registro bloqueado.


O perigo dos loops infinitos

Imagine:

PERFORM UNTIL FIM

READNEXT

END-PERFORM

Sem verificar ENDFILE.

O resultado?

Loop eterno.

O programa continua tentando ler além do último registro.

Esse é um dos erros mais comuns encontrados em entrevistas técnicas.


GTEQ — Uma joia escondida

Suponha este arquivo.

100

200

300

400

500

Você procura:

250

Sem GTEQ.

Resultado:

NOTFND

Com GTEQ.

Resultado:

300

Ou seja:

Comece pelo primeiro registro maior ou igual.

É fantástico para consultas por faixa.


Pesquisas parciais

Imagine procurar CEPs.

13000

13010

13020

13035

13080

13100

O operador deseja apenas:

130

O STARTBR posiciona no primeiro.

READNEXT continua lendo.

Quando chega:

131

A pesquisa termina.

Sem varrer milhões de registros.


Paginação muito antes da Web

Hoje chamamos isso de paginação.

Mas o CICS fazia isso nos anos 70.

Tela.

Cliente 1

Cliente 2

Cliente 3

Cliente 4

Cliente 5

PF8.

Mais cinco.

PF8.

Mais cinco.

PF7.

Cinco anteriores.

Décadas antes do JavaScript.

Décadas antes do HTML.

Décadas antes do React.


Performance impressionante

Imagine um banco.

Arquivo:

40 milhões de clientes.

Você quer mostrar apenas vinte.

READNEXT lê somente vinte.

Não quarenta milhões.

É essa eficiência que tornou o mainframe lendário.


O que acontece por trás dos bastidores?

Enquanto você escreve apenas:

READNEXT

O CICS executa dezenas de tarefas:

✔ valida a Browse Session

✔ verifica autorização RACF

✔ verifica integridade

✔ localiza buffers

✔ identifica a posição corrente

✔ percorre a árvore do VSAM

✔ copia dados

✔ atualiza RIDFLD

✔ movimenta INTO

✔ atualiza ponteiros

✔ retorna RESP

Tudo isso acontece invisivelmente.


Boas práticas de um Programador Jedi

Nunca faça:

STARTBR

READNEXT

ABEND

...

Sem ENDBR.

Use sempre tratamento de exceção.

Outra boa prática:

Nunca deixe Browse aberto durante muito tempo.

Quanto menor a duração da sessão, melhor para o ambiente.


Armadilhas clássicas

Esquecer STARTBR

READNEXT falha.


Esquecer ENDBR

Recursos permanecem ocupados.


Ignorar RESP

Loops infinitos.


Fazer READ comum durante o Browse

Perde desempenho.


Atualizar registros sem entender bloqueios

Pode causar conflitos de concorrência.


Curiosidades Históricas

Durante as décadas de 1980 e 1990 praticamente todo caixa bancário utilizava PF7 e PF8.

PF8

READNEXT

PF7

READPREV

Milhares de operadores trabalhavam assim diariamente.

Sem mouse.

Sem interface gráfica.

Mesmo assim conseguiam navegar milhões de registros mais rapidamente do que muitos sistemas modernos.


Dicas para entrevistas técnicas

Se o entrevistador perguntar:

Qual a sequência correta?

Responda imediatamente.

STARTBR

↓

READNEXT ou READPREV

↓

ENDBR

Outra pergunta clássica:

READNEXT funciona sem STARTBR?

Resposta:

Não.

Porque não existe posição inicial.


Easter Egg — A Sociedade do Browse 🧙‍♂️💍

No universo de O Senhor dos Anéis, imagine que o VSAM KSDS seja a gigantesca biblioteca de Minas Tirith, onde cada tomo contém a história de um habitante da Terra-média, organizado rigorosamente pelos escribas de Gondor.

STARTBR é Gandalf abrindo o antigo mapa dos reinos e indicando onde a Sociedade iniciará sua jornada. Sem esse mapa, ninguém sabe por onde seguir.

READNEXT é Aragorn conduzindo a comitiva pela estrada principal, avançando de vila em vila, encontrando cada novo aliado na ordem correta, sem jamais se perder.

READPREV é Legolas olhando para trás do grupo, retornando alguns passos para verificar se ninguém ficou para trás ou se alguma pista importante foi esquecida no caminho.

ENDBR é o momento em que a missão termina, o mapa é cuidadosamente enrolado e devolvido aos arquivos de Minas Tirith. Nada permanece aberto, nenhum recurso é desperdiçado e a biblioteca está pronta para a próxima expedição.

Existe ainda um personagem invisível: a árvore B (B-tree) do VSAM. Ela pode ser comparada às Águias da Terra-média. Quase ninguém as vê trabalhando, mas são elas que conhecem todos os caminhos e permitem que a jornada aconteça com rapidez extraordinária. Sem elas, percorrer milhões de registros seria como atravessar Mordor a pé sem qualquer orientação.

O verdadeiro herói desta história não é READNEXT nem READPREV.

É a inteligência do VSAM, construída ao longo de décadas de engenharia, permitindo que aplicações COBOL executem consultas em volumes gigantescos de dados com uma eficiência que continua impressionando até os dias atuais.


Conclusão — A Sabedoria dos Antigos Arquivistas

Quando um programador iniciante aprende READNEXT e READPREV, pode imaginar que está apenas decorando mais alguns comandos da linguagem CICS. Porém, essa impressão desaparece à medida que compreende o que realmente acontece nos bastidores.

Esses comandos representam uma filosofia de desenvolvimento que nasceu muito antes da computação moderna: não acessar dados de forma aleatória quando existe um caminho inteligente para percorrê-los. O Browse do CICS reduz processamento, aproveita a organização do VSAM KSDS, reutiliza a posição corrente e transforma milhões de registros em uma trilha organizada que pode ser percorrida para frente e para trás com naturalidade.

Não é por acaso que bancos, seguradoras, companhias aéreas e governos utilizam esse mecanismo há décadas. Em sistemas onde cada microssegundo conta e cada transação precisa ser confiável, navegar corretamente pelos dados é tão importante quanto encontrá-los.

No universo Bellacosa Mainframe, costumo dizer que um Programador COBOL Padawan aprende primeiro a fazer um READ. Um profissional experiente aprende quando usar STARTBR. Mas um verdadeiro Mestre do Mainframe entende que o maior poder nunca esteve em localizar um único registro, e sim em conduzir toda a jornada pelos dados com elegância, eficiência e respeito à arquitetura construída pelos antigos engenheiros da IBM.

E, assim como Frodo descobriu que o valor da jornada era muito maior do que o destino final, o programador também percebe que dominar STARTBR, READNEXT, READPREV e ENDBR é mais do que conhecer comandos: é aprender uma das artes mais refinadas da programação transacional em CICS, uma tradição que continua viva após mais de meio século de evolução do IBM Z.

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...