Translate

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