Translate

sábado, 28 de março de 2015

☕💣🌌 O DIA EM QUE O UNIVERSO EXECUTOU MILHARES DE JOBS AO MESMO TEMPO: NOEIN E O MAINFRAME DAS REALIDADES PARALELAS

 

Bellacosa Mainframe viagem no tempo Noein to your other self

☕💣🌌 O DIA EM QUE O UNIVERSO EXECUTOU MILHARES DE JOBS AO MESMO TEMPO: NOEIN E O MAINFRAME DAS REALIDADES PARALELAS

Ficha Técnica

ItemInformação
Título Originalノエイン もうひとりの君へ (Noein: Mou Hitori no Kimi e)
Título InternacionalNoein: To Your Other Self
Ano de Lançamento2005
Exibição OriginalOutubro de 2005 a Março de 2006
Episódios24
EstúdioSatelight
DiretorKazuki Akane
RoteiroKazuki Akane, Kenji Yasuda e equipe
MúsicaHikaru Nanase
GêneroFicção Científica, Drama, Mistério, Multiverso, Aventura, Psicológico
Classificação IndicativaAproximadamente 14+
OrigemAnime Original (não baseado em mangá ou light novel)

☕ O Que é Noein?

Imagine que alguém pegasse:

  • Steins;Gate

  • YU-NO

  • Serial Experiments Lain

  • Interstellar

  • Mecânica Quântica

E colocasse tudo dentro de um único anime.

O resultado seria Noein.

Diferentemente de muitos animes de viagem temporal, Noein não fala apenas sobre mudar o passado.

Ele tenta responder uma pergunta muito maior:

"E se todas as possibilidades da sua vida existissem simultaneamente?"


💣 Sinopse

Haruka Kaminogi e Yuu Gotou são amigos de infância que vivem em Hakodate, Hokkaido.

A rotina aparentemente normal dos dois muda quando surge um guerreiro chamado Karasu.

O problema?

Karasu afirma ser uma versão futura de Yuu.

Ele vem de uma dimensão chamada La'cryma, um universo devastado por uma guerra contra Shangri-La, uma entidade dimensional capaz de absorver todas as realidades existentes.

Segundo Karasu, Haruka possui uma habilidade única que pode decidir o destino de todos os universos.


🖥️ A História Vista Como um Ambiente Mainframe

No estilo Bellacosa Mainframe:

Imagine um datacenter com milhões de LPARs.

Cada LPAR representa uma linha temporal.

Toda vez que alguém toma uma decisão:

IF ESCOLHA = A
   EXECUTA UNIVERSO_A
ELSE
   EXECUTA UNIVERSO_B
END-IF

Mas o sistema nunca apaga os ambientes anteriores.

Todos continuam existindo.

Agora imagine que todas essas LPARs começam a interferir umas nas outras.

É exatamente isso que acontece em Noein.


🌌 O Grande Diferencial

Em 2005, praticamente ninguém falava de multiversos como hoje.

Antes de:

  • Universo Marvel Multiverse

  • Loki

  • Everything Everywhere All At Once

  • Rick and Morty

Noein já explorava:

  • Universos paralelos

  • Possibilidades infinitas

  • Colapso quântico

  • Teoria dos Muitos Mundos

De forma extremamente ambiciosa.


👥 Personagens Principais

Haruka Kaminogi

A protagonista.

É o chamado "Olho do Dragão".

Funciona como uma espécie de ponto de sincronização entre múltiplos universos.

No mundo mainframe seria:

MASTER CATALOG

O elemento que mantém a consistência dos sistemas.


Yuu Gotou

Menino introvertido e inseguro.

Representa o livre-arbítrio.

Cada versão alternativa dele mostra como pequenas decisões mudam completamente uma vida.


Karasu

Talvez o personagem mais interessante do anime.

É uma versão futura de Yuu.

Carrega culpa, arrependimentos e cicatrizes de um futuro destruído.

É praticamente um operador tentando restaurar um ambiente após um desastre catastrófico.


Atori

Agente de La'cryma.

Inicialmente parece apenas um antagonista.

Mas sua evolução psicológica é uma das mais profundas da série.


Fukuro

Outro guerreiro dimensional.

Representa o lado racional e científico da história.


🎭 Temáticas Profundas

Destino vs Livre-Arbítrio

A série pergunta constantemente:

Nosso futuro já está definido?

Ou

Criamos nosso próprio destino?


Crescimento e Maturidade

Haruka e Yuu estão entrando na adolescência.

O conflito dimensional é também uma metáfora para:

  • Medos

  • Inseguranças

  • Escolhas da vida adulta


Possibilidades Perdidas

Cada universo alternativo representa:

  • Sonhos abandonados

  • Escolhas diferentes

  • Caminhos nunca seguidos

No fundo, Noein fala sobre arrependimento.


O Valor das Conexões Humanas

A verdadeira força da série não é a ficção científica.

É o relacionamento entre as pessoas.


☕ As Mensagens Ocultas

1. Não Existe Futuro Único

O anime sugere que o futuro é uma coleção de probabilidades.

Não existe apenas uma resposta.


2. O Medo Cria Prisões

Vários personagens vivem presos a futuros que temem.

Uma metáfora para ansiedade e insegurança.


3. Aceitar a Mudança é Necessário

Tentar congelar uma realidade perfeita pode ser tão destrutivo quanto o caos.


4. O Observador Muda a Realidade

Inspirado na física quântica.

A própria observação altera o resultado.


🚀 As Aventuras

Durante os 24 episódios vemos:

  • Batalhas entre dimensões

  • Viagens entre universos

  • Investigações científicas

  • Descobertas sobre o futuro

  • Conflitos emocionais

  • Sacrifícios pessoais

O interessante é que as lutas nunca são o foco principal.

Elas servem para desenvolver os personagens.


🖥️ Aspectos Técnicos e Artísticos

Direção

Kazuki Akane construiu uma narrativa extremamente complexa sem perder o lado humano.

Algo raro para a época.


Animação

O estúdio Satelight utilizou:

  • CGI experimental

  • Movimentos de câmera incomuns

  • Animação híbrida

Em 2005 isso era extremamente ousado.


Trilha Sonora

A trilha reforça:

  • Solidão

  • Esperança

  • Nostalgia

  • Melancolia

Contribuindo para a atmosfera única.


🌍 Impacto Cultural

Noein nunca alcançou a popularidade de:

  • Naruto

  • Bleach

  • Fullmetal Alchemist

Porém tornou-se um clássico cult.

Hoje é frequentemente citado por fãs de:

  • Ficção científica

  • Viagem temporal

  • Multiversos

  • Animes psicológicos

Muitos críticos o consideram uma obra subestimada.


🚫 Houve Censura?

Não houve um histórico relevante de censura internacional envolvendo Noein.

Algumas emissoras adaptaram classificação etária e horários de exibição, algo comum na televisão japonesa.

O anime foi exibido praticamente em sua forma original.

Isso permitiu que seus temas filosóficos permanecessem intactos.


📊 Classificação Bellacosa Mainframe

CritérioNota
História10/10
Ficção Científica10/10
Personagens9,5/10
Originalidade10/10
Drama9/10
Complexidade10/10
Reassistir10/10

☕💣 Conclusão

Noein não é um anime sobre viagem no tempo.

Também não é um anime sobre multiversos.

Na verdade, Noein é uma reflexão sobre as inúmeras versões de nós mesmos que poderiam existir dependendo das escolhas que fazemos.

No estilo Bellacosa Mainframe, a melhor definição seria:

"Imagine um Sysplex com milhões de LPARs executando versões diferentes da sua vida. Cada decisão cria um novo ambiente. Cada arrependimento gera um universo alternativo. E um erro de sincronização ameaça derrubar toda a operação."

Enquanto muitos animes usam o multiverso como espetáculo visual, Noein usa o conceito para discutir identidade, amadurecimento, esperança e a natureza da própria realidade.

Por isso, mais de vinte anos depois, continua sendo uma das obras de ficção científica mais inteligentes e injustamente esquecidas da história dos animes. ☕🖥️🌌💣

sexta-feira, 27 de março de 2015

☕🔥 BOAS PRÁTICAS COBOL — A DIFERENÇA ENTRE “CÓDIGO QUE FUNCIONA” E “CÓDIGO QUE SOBREVIVE 30 ANOS”

 

Bellacosa Mainframe e as Boas praticas em cobol

☕🔥 BOAS PRÁTICAS COBOL — A DIFERENÇA ENTRE “CÓDIGO QUE FUNCIONA” E “CÓDIGO QUE SOBREVIVE 30 ANOS”

O material enviado é excelente porque toca num dos assuntos mais importantes do mundo Enterprise:

COBOL não é só linguagem.
COBOL é engenharia de continuidade operacional.

E isso muda completamente a maneira de programar.

No mercado bancário, seguradoras, adquirentes, cartões, previdência, governo e clearing houses…

o programa COBOL NÃO é feito para durar meses.

Ele é feito para durar décadas.

Muitos sistemas bancários críticos hoje ainda possuem módulos escritos entre:

  • 1978

  • 1986

  • 1992

  • 1999

e continuam processando:

  • PIX

  • TED

  • SWIFT

  • cartão

  • folha

  • empréstimo

  • câmbio

  • risco

  • antifraude

  • compensação

  • open finance

com volumes absurdos.


☕ O GRANDE SEGREDO DO COBOL CORPORATIVO

Em sistemas Enterprise:

O custo da MANUTENÇÃO é MUITO maior que o custo da implementação inicial.

Em bancos:

  • 70% a 90% do trabalho é manutenção

  • não projeto novo

Então o verdadeiro objetivo do COBOL é:

  • previsibilidade

  • legibilidade

  • estabilidade

  • rastreabilidade

  • auditabilidade

  • recuperação

  • facilidade de troubleshooting

e NÃO “código bonito”.


☕ O QUE DIFERENCIA UM JÚNIOR DE UM PROGRAMADOR COBOL ENTERPRISE?

Junior:

  • “funciona”

Senior:

  • “isso vai sobreviver 20 anos?”

Especialista banco:

  • “isso vai sobreviver 20 anos SEM derrubar batch?”

Arquiteto:

  • “isso vai sobreviver auditoria BACEN?”


☕ 1 — IDENTIFICATION DIVISION NÃO É ENFEITE

O texto fala algo extremamente importante:

Muita gente ignora IDENTIFICATION DIVISION.

No mundo real isso é gravíssimo.

Porque em bancos:

  • programas possuem milhares de versões

  • dezenas de equipes

  • auditorias

  • SOX

  • BACEN

  • LGPD

  • rastreabilidade


EXEMPLO CORPORATIVO REAL

IDENTIFICATION DIVISION.
PROGRAM-ID. CRD0450.

AUTHOR. V BELLACOSA.
INSTALLATION. BANK XYZ.
DATE-WRITTEN. 2026-05-21.

REMARKS.
* PROCESSA BAIXA DE PARCELAS
* MODULO UTILIZADO NO FECHAMENTO D+1
* INTEGRADO COM CICS E DB2
* CHAMADO PELO SCHEDULER CA7

☕ POR QUE ISSO É IMPORTANTE?

Imagine:

Batch falhou às 02:15 da manhã.

Operação liga para suporte.

O operador precisa descobrir:

  • o que o programa faz

  • qual sistema impactado

  • qual cadeia batch

  • quem mantém

  • dependências

Sem IDENTIFICATION adequada:

  • caos

Com documentação:

  • troubleshooting rápido


☕ 2 — COMENTÁRIOS NÃO DEVEM EXPLICAR “O QUE”

Esse trecho do artigo é ouro puro.

Programador ruim comenta:

* SOMA VALOR
ADD WS-VALOR TO WS-TOTAL

Isso é inútil.

O COBOL já é quase inglês.


☕ O QUE DEVE SER COMENTADO?

REGRA DE NEGÓCIO

Exemplo bancário:

* BACEN CIRCULAR 4588
* JUROS DEVEM SER ESTORNADOS
* QUANDO LIQUIDACAO OCORRER EM D-1
* CHAMADO 458921 - TIME RISCO

IF WS-DT-LIQ < WS-DT-VENC
   SUBTRACT WS-JUROS
      FROM WS-SALDO
END-IF

Isso salva vidas em produção.

Porque explica:

  • por que existe

  • quem pediu

  • qual regra

  • qual auditoria

  • qual legislação


☕ 3 — NOMENCLATURA EM COBOL É CIÊNCIA

O texto explica muito bem padrões de nomes.

Em sistemas bancários grandes:

nomenclatura é arquitetura.


☕ EXEMPLO RUIM

01 X.
01 Y.
01 TOTAL1.
01 CONT.

Isso destrói manutenção.


☕ EXEMPLO ENTERPRISE

01 WS-VR-TOTAL-PAGAMENTO    PIC S9(13)V99 COMP-3.
01 WS-QT-PARCELAS-ATRASO    PIC 9(05) COMP.
01 WS-DT-LIQUIDACAO         PIC 9(08).
01 WS-ST-CLIENTE-INAD       PIC X(01).

Agora qualquer pessoa entende:

  • VR = valor

  • QT = quantidade

  • DT = data

  • ST = status


☕ PADRÃO BANCÁRIO MAIS COMUM

Prefixos clássicos

PrefixoSignificado
WSWorking-Storage
LKLinkage
DFHCICS
SQLDb2
INEntrada
OUTSaída
ACAcumulador
CTContador
FLGFlag

☕ 4 — EVALUATE É UMA DAS MAIORES ARMAS DO COBOL MODERNO

O artigo mostra um IF gigantesco.

Isso é MUITO comum em sistemas antigos.


☕ O PROBLEMA DOS IFs GIGANTES

Eles causam:

  • difícil manutenção

  • bugs

  • nesting infernal

  • scope errado

  • END-IF perdido

  • regressão


☕ COMO BANCOS MODERNIZAM ISSO?

Com:

EVALUATE WS-TP-MOVIMENTO

   WHEN '01'
      PERFORM 100-CREDITO

   WHEN '02'
      PERFORM 200-DEBITO

   WHEN '03'
      PERFORM 300-ESTORNO

   WHEN OTHER
      PERFORM 900-ERRO

END-EVALUATE

☕ BENEFÍCIOS

1. Legibilidade absurda

2. Menos bugs

3. Fácil inclusão de novas regras

4. Melhor debugging

5. Melhor análise de fluxo


☕ 5 — END-IF SALVOU O MAINFRAME

O artigo cita delimitadores de escopo.

Isso foi uma revolução.

Antes:

IF A = B
   IF C = D
      MOVE 1 TO X.

O ponto encerrava TUDO.

Isso gerava:

  • bugs monstruosos

  • IF acidentalmente fechado

  • corrupção lógica


☕ BOA PRÁTICA MODERNA

IF WS-SALDO > ZERO

   IF WS-LIMITE > ZERO
      PERFORM 100-LIBERA
   END-IF

END-IF

☕ REGRA DE OURO DOS BANCOS

NUNCA dependa de ponto para fechar escopo.

Sempre:

  • END-IF

  • END-EVALUATE

  • END-PERFORM

  • END-READ

  • END-EXEC


☕ 6 — CÓDIGO MORTO É VENENO CORPORATIVO

O artigo fala sobre código comentado antigo.

Isso é uma praga em mainframe.


☕ EXEMPLO REAL

* COMPUTE WS-JUROS = WS-SALDO * 0.12
MOVE ZERO TO WS-JUROS

10 anos depois:

  • ninguém sabe qual regra vale

  • auditoria confunde

  • manutenção vira inferno


☕ MELHOR PRÁTICA

Use:

  • ChangeMan

  • Endevor

  • Git

  • ISPW

Versionamento existe para isso.


☕ O CÓDIGO DEVE REPRESENTAR:

o presente

Não o passado arqueológico do sistema.


☕ 7 — COPYBOOKS: O DNA DO MAINFRAME

O artigo comenta reuso moderado.

Esse é um dos temas mais importantes do COBOL bancário.


☕ O QUE É COPYBOOK?

É um INCLUDE reutilizável.


☕ EXEMPLO

COPY CLIENTE.
COPY DFHAID.
COPY SQLCA.

☕ PRINCIPAIS COPYBOOKS BANCÁRIOS

1. Layouts de arquivos

CNAB:

  • 240

  • 400


2. Áreas CICS

DFHCOMMAREA

3. Estruturas Db2

DCLGEN

4. APIs corporativas

PIX
SWIFT
Open Finance


☕ PERIGO DO EXCESSO DE COPYBOOK

Já vi programas com:

  • 120 COPYs

  • impossível entender fluxo

Isso gera:

  • compilação lenta

  • impacto gigante

  • acoplamento monstruoso


☕ BOA PRÁTICA

Reuse:

  • layouts

  • APIs

  • estruturas comuns

  • tratamento corporativo

NÃO reuse:

  • lógica besta

  • MOVE ZERO

  • regras triviais


☕ 8 — COMP, COMP-3 E PERFORMANCE

O artigo toca num ponto extremamente avançado.

Muita gente não entende isso.


☕ DISPLAY vs COMP vs COMP-3

DISPLAY

PIC 9(10)

Armazenado:

  • caractere por caractere

Mais lento.


☕ COMP

PIC S9(9) COMP

Binário.

Muito mais rápido.

Ideal:

  • contadores

  • loops

  • índices


☕ COMP-3

PIC S9(11)V99 COMP-3

Packed decimal.

Perfeito para:

  • financeiro

  • bancos

  • dinheiro

Porque:

  • precisão decimal exata


☕ POR QUE BANCOS AMAM COMP-3?

Porque dinheiro NÃO pode ter erro binário.

Exemplo clássico:

Floating Point

0.1 + 0.2 = 0.3000000000004

Em banco:

  • isso seria catastrófico


☕ COBOL RESOLVE ISSO

Com decimal packed:

01 WS-VALOR PIC S9(09)V99 COMP-3.

Precisão decimal real.


☕ 9 — NÍVEL 88 É SUBESTIMADO

O artigo comenta condition names.

Isso é uma maravilha do COBOL.


☕ SEM NÍVEL 88

IF WS-ST-CLIENTE = 'A'

'A' significa o quê?


☕ COM NÍVEL 88

01 WS-ST-CLIENTE PIC X(01).

   88 CLIENTE-ATIVO VALUE 'A'.
   88 CLIENTE-BLOQUEADO VALUE 'B'.
   88 CLIENTE-INADIMPLENTE VALUE 'I'.

Agora:

IF CLIENTE-INADIMPLENTE

Fica quase inglês.


☕ 10 — PRINCIPAIS SOLUÇÕES BANCÁRIAS COBOL

Agora vamos entrar no mundo REAL Enterprise.


☕ ARQUITETURA MAIS COMUM EM BANCOS

ONLINE

CICS + COBOL + Db2

Processa:

  • saldo

  • PIX

  • TED

  • cartão

  • ATM

  • mobile


☕ BATCH

JCL + COBOL + SORT + IDCAMS + Db2 Utilities

Processa:

  • fechamento

  • extrato

  • billing

  • juros

  • risco

  • liquidação


☕ MIDDLEWARE

MQ
Kafka
IBM Integration Bus
z/OS Connect

Integra:

  • APIs

  • microsserviços

  • nuvem

  • mobile


☕ SEGURANÇA

RACF

Controla:

  • datasets

  • transações

  • usuários

  • APIs


☕ ALTA DISPONIBILIDADE

Sysplex
GDPS
Parallel Sysplex


☕ MONITORAMENTO

OMEGAMON
MainView
SYSVIEW


☕ DEVOPS MAINFRAME

Endevor
ISPW
Git + DBB
Jenkins
UrbanCode


☕ EXEMPLO REAL — TRANSAÇÃO PIX

PASSO A PASSO


1 — APP MOBILE

Cliente envia PIX.


2 — API GATEWAY

Chama:

  • z/OS Connect

  • MQ

  • CICS


3 — CICS

Executa transação COBOL.


4 — COBOL

Valida:

  • saldo

  • limite

  • antifraude

  • horário

  • BACEN


5 — Db2

Atualiza:

  • saldo

  • ledger

  • histórico


6 — MQ/Kafka

Publica evento.


7 — Batch Noturno

Concilia:

  • compensação

  • liquidação

  • auditoria


☕ O QUE ISSO ENSINA?

Que COBOL moderno NÃO vive isolado.

Ele é:

  • coração transacional

  • motor financeiro

  • camada de consistência


☕ CONCLUSÃO

O artigo enviado aborda algo fundamental:

boas práticas COBOL não existem para “embelezar código”.

Elas existem para:

  • manter sistemas vivos

  • reduzir risco operacional

  • evitar incidentes bancários

  • facilitar auditoria

  • garantir continuidade

  • permitir manutenção segura

E isso é exatamente o motivo pelo qual:

  • bancos

  • bolsas

  • seguradoras

  • governos

  • adquirentes

continuam confiando bilhões de dólares ao COBOL diariamente.


quinta-feira, 26 de março de 2015

📚💣 Tankōbon — O Deploy Final do Manga que Sai do Buffer e Vai pra Produção

 

Bellacosa Mainframe apresenta o Tankobon mangas organizados em livro

📚💣 Tankōbon — O Deploy Final do Manga que Sai do Buffer e Vai pra Produção

Se capítulos semanais são logs soltos rodando em stream…
o tankōbon é o build consolidado, revisado, versionado e pronto pra produção.

Ele não é rascunho.
Não é preview.
Não é teste.

👉 É o release oficial do mangá.


🧠 Conceito — Quando o Capítulo Vira Sistema

Tankōbon (単行本) significa:

  • “livro independente”
  • “volume compilado”

👉 Ou seja:
Capítulos que saíram em revistas são reorganizados e publicados como um volume completo.

📌 Bellacosa traduz:

Tankōbon = merge + commit + deploy definitivo.


📜 Origem — Do Caos Editorial ao Controle de Versão

Antes dos tankōbon:

  • Mangás eram publicados em revistas semanais/mensais
  • Papel barato
  • Sem permanência
  • Conteúdo descartável

Com o tempo, editoras perceberam:

👉 “Isso aqui precisa virar produto durável.”

Assim nasce o tankōbon:

  • Melhor qualidade
  • Organização em volumes
  • Produto colecionável

🏗️ Como Funciona — Pipeline Editorial

Fluxo clássico:

  1. Capítulo sai em revista (ex: Weekly Shōnen Jump)
  2. Recebe feedback dos leitores
  3. Autor revisa / ajusta
  4. Capítulos são compilados
  5. Sai o tankōbon

📌 Tradução Bellacosa:

Primeiro roda em homologação… depois vai pra produção.


📦 Formato — Compacto, Portátil e Mortal

Características:

  • Tamanho padrão (pequeno, portátil)
  • Capa trabalhada
  • Papel melhor que revista
  • Volume numerado
  • Extras exclusivos

👉 É o formato mais consumido no Japão.


✏️ Diferenças Importantes (Revista vs Tankōbon)

AspectoRevistaTankōbon
QualidadeBaixaAlta
OrganizaçãoEpisódicaEstruturada
RevisãoNãoSim
ExtrasNãoSim
PermanênciaTemporáriaDefinitiva

📌 Bellacosa:

Revista = log temporário
Tankōbon = banco de dados persistente


🧠 O Que Muda no Tankōbon

Aqui fica interessante 👇

Autores frequentemente:

  • Corrigem arte
  • Ajustam diálogos
  • Mudam cenas
  • Reorganizam narrativa

👉 Às vezes, o tankōbon é melhor que a versão original.


🤫 Fofoquices do Mundo dos Mangás

  • Alguns capítulos são refeitos completamente
  • Censura pode mudar entre versões
  • Autores escondem detalhes extras só no volume
  • Há fãs que só consideram o tankōbon “canon verdadeiro”

📌 Fofoquinha pesada:

Já teve mangá que mudou final entre revista e volume.


🕹️ Easter Eggs que Só Quem Lê Tankōbon Vê

  • Capas que formam uma imagem completa
  • Páginas extras secretas
  • Comentários do autor
  • Piadas internas
  • Personagens escondidos

🎮 Easter Egg clássico:

Quem lê só a revista perde metade do conteúdo.


🎌 Onde Isso Aparece (na prática)

  • One Piece → volumes com revisões constantes
  • Naruto → mudanças visuais ao longo do tempo
  • Attack on Titan → ajustes de arte e pacing

🧠 Interpretação (Modo Bellacosa ON)

Tankōbon representa:

  • Consolidação
  • Refinamento
  • Versão estável
  • Produto final

📌 Comentário Final — Nem Tudo que Roda em Produção Sai Perfeito

No mundo dos mangás:

  • O que você vê primeiro… não é definitivo
  • O autor continua ajustando
  • O sistema evolui

🔥 Conclusão — O Tankōbon é o Commit que Fica

Capítulos vêm e vão.
Revistas são descartadas.
Versões mudam.

Mas o tankōbon…

é o estado final do sistema que será lembrado.

quarta-feira, 25 de março de 2015

⚙️ O Hotbit — o sonho em preto, cinza e azul

 


⚙️ O Hotbit — o sonho em preto, cinza e azul

O Hotbit HB-8000, fruto da parceria Sharp/Milmar, era o ápice da microinformática nacional dos anos 80.
Baseado no processador Zilog Z80A de 3,58 MHz, com 16 ou 64 KB de RAM, rodava o padrão MSX 1.0, criado pela Microsoft e pela ASCII japonesa.
Suas principais características:

  • Teclado integrado com teclas mecânicas de viagem longa (luxo da época)

  • Cartuchos para jogos e aplicativos — como o lendário Nemesis ou Knightmare

  • Interface de fita cassete e saída de vídeo composto, ideal para TVs domésticas

  • MSX BASIC, interpretador embutido que transformava qualquer curioso em aprendiz de programador

Era a ponte entre o videogame e o computador.
Você podia jogar pela manhã e programar à tarde — desde que ninguém quisesse ver a novela.




🧠 A semente do programador

Aquela tarde em Quiririm foi o ponto de ignição.
O barulho da fita K7 carregando, o “beep” do programa iniciando, o cheiro de poeira no tubo da TV — tudo ficou gravado em mim.
Anos depois, quando tive meu TK-85, aquele pequeno 8 bits que roubava o televisor da sala, eu já sabia: queria viver nesse universo.
E de lá, um salto natural me levou para o outro extremo — o IBM Mainframe.

🏢 O salto para o gigante — o MVS/360

Enquanto eu digitava minhas primeiras linhas em BASIC, o mundo corporativo vibrava em outra frequência.
Nos longínquos anos 1980, o IBM System/360 já era lenda viva — uma arquitetura modular lançada em 1964 que mudou para sempre o conceito de computação empresarial.
Rodava o sistema MVS (Multiple Virtual Storage), herdeiro do OS/360, e foi o primeiro a introduzir a ideia de compatibilidade entre gerações de máquinas — um verdadeiro milagre de engenharia.

O MVS/370 e seus descendentes moviam bancos, governos e indústrias enquanto nós, os garotos do Hotbit e TK-85, brincávamos de lógica em 8 bits.
Do lado de cá, o som era de fita K7.
Do lado de lá, o som era de fita magnética de 9 trilhas rodando a 75 polegadas por segundo.

E o mais curioso?
Ambos — o menino no quarto e o operador no CPD — falavam a mesma língua: o código.
BASIC ou COBOL, MSX ou MVS, pouco importava.
Era tudo a mesma busca: dizer à máquina o que fazer e se encantar quando ela obedecia.

💡 Easter Eggs e curiosidades

  • O MSX BASIC do Hotbit foi desenvolvido pela Microsoft, e seu código-fonte serviu de base para versões posteriores usadas em máquinas japonesas.

  • O Hotbit vinha com saída RF — ou seja, ligava direto na TV, ocupando o “canal 3”, o mesmo da novela das oito.

  • Havia um comando secreto: COLOR ,,, que alterava a paleta da tela — recurso avançadíssimo pra quem vinha do mundo monocromático dos TKs.

  • A Milmar fabricava o Hotbit com componentes nacionais, graças à reserva de mercado, o que deu ao computador um charme “brasileiro” no hardware.

  • Alguns usuários ousados ligavam dois Hotbits via porta de joystick para trocar dados — o sneakernet raiz.

🖥️ Da tela azul à tela preta

A vida me levou do Hotbit doméstico ao MVS corporativo — do “OK” piscando na TV de 14 polegadas à tela preta do TSO.
Mas a sensação, curiosamente, é a mesma:
olhar o cursor piscando, digitar uma linha, e saber que algo vai acontecer.

O Hotbit me ensinou a imaginar.
O TK-85 me ensinou a persistir.
O Mainframe me ensinou a respeitar a grandeza das máquinas e a precisão das ideias.

E hoje, entre mainframes que processam bilhões e inteligências artificiais que escrevem poesia, eu ainda lembro daquele quarto em Quiririm.
De um garoto curioso, hipnotizado pela tela azul, sem saber que estava assistindo à primeira linha de código do próprio destino.


☕ Epílogo

A televisão daquela casa não era só uma tela — era uma janela para o futuro.
O Hotbit, o TK-85 e o MVS eram capítulos de uma mesma história: a da curiosidade humana e da vontade de dominar o invisível.

E talvez seja isso o que une o garoto do BASIC ao analista do mainframe:
a certeza de que toda máquina, por mais fria que pareça, guarda um eco do nosso espanto — aquele mesmo que começou, um dia, diante de uma pequena TV de 14 polegadas em Quiririm.


Bellacosa Mainframe
☕ Porque toda máquina tem alma — e todo código começa com um olhar curioso diante de uma tela azul.

terça-feira, 24 de março de 2015

👹💣 Amanojaku — O Bug Interno que Sabota Seu Próprio Sistema

 

Bellacosa Mainframe apresenta o contrariador Amanojaku

👹💣 Amanojaku — O Bug Interno que Sabota Seu Próprio Sistema

Se o Ayakashi é o sistema corrompido…
o Amanojaku é pior:

👉 é o processo interno que trabalha contra você.

Ele não invade.
Ele não destrói direto.
Ele te convence a fazer errado.


🧠 Conceito — A Função que Sempre Retorna o Oposto

O Amanojaku é um yokai/demônio conhecido por:

  • Provocar contradição
  • Inverter desejos
  • Influenciar decisões
  • Desestabilizar a mente

📌 Bellacosa traduz:

Amanojaku = return NOT(intencao)


📜 Origem e História — Rebeldia Codificada no Folclore

O Amanojaku aparece em várias histórias japonesas antigas como:

  • Espírito maligno
  • Entidade manipuladora
  • Criatura que desafia ordem e moral

Uma das ligações mais conhecidas:

👉 Deriva do conceito de Amanozako, uma divindade rebelde e caótica

👉 Amanozako

📌 Evolução:

  • De entidade divina caótica
  • Para espírito psicológico perturbador

🧬 Classificação — Não É Força, É Influência

  • 👹 Tipo: Yokai / demônio menor
  • 🧠 Especialidade: Manipulação mental
  • ⚠️ Perigo: Alto (psicológico)
  • ⚔️ Combate físico: Irrelevante

👉 Ele não ganha na força…
ele ganha na decisão errada que você toma.


👁 Aparência — Pequeno, Mas Errado

Representações comuns:

  • Pequeno demônio
  • Corpo humanoide
  • Rosto distorcido
  • Expressão provocadora

📌 Regra:

Ele parece fraco… porque não precisa ser forte.


⚠️ Poder Principal — Manipulação da Vontade

O Amanojaku:

  • Faz você duvidar
  • Amplifica inseguranças
  • Inverte decisões
  • Provoca autossabotagem

👉 Ele não cria o erro…
👉 ele ativa o erro que já existe em você.


🎲 Poderes (Estilo RPG)

  • 🧠 Influência mental
  • 🗣️ Sugestão psicológica
  • 🔄 Inversão de intenção
  • 👁️ Leitura emocional

💀 Fraquezas

  • Consciência emocional
  • Clareza mental
  • Disciplina
  • Autoconhecimento

📌 Bellacosa:

Ele só funciona onde existe conflito interno.


🤫 Fofoquices do Folclore

  • Alguns dizem que ele “lê o coração”
  • Em certas histórias, ele assume forma humana
  • Pode viver “dentro” da pessoa
  • Às vezes aparece como voz interna

📌 Fofoquinha pesada:

Você pode já ter ouvido um… e achado que era você.


🕹️ Easter Eggs em Animes

  • Ghost Stories → versão direta
  • Mononoke → conceito psicológico
  • Natsume's Book of Friends → yokai manipuladores

🎮 Easter Egg técnico:

Todo personagem que age contra si mesmo… tem traço de Amanojaku.


🧠 Interpretação Profunda (Modo Bellacosa ON)

O Amanojaku representa:

  • Autossabotagem
  • Conflito interno
  • Contradição humana
  • A mente contra si mesma

📌 Comentário Final — O Inimigo Já Está Dentro

Você não precisa invocar o Amanojaku.
Não precisa encontrar.
Não precisa fugir.

Porque ele…

já roda dentro do seu sistema desde o primeiro conflito.


🔥 Conclusão — O Erro Mais Perigoso Não Vem de Fora

No mundo dos yokai (e na vida):

  • O maior risco não é o inimigo externo
  • É a decisão errada interna

💣 Versão Bellacosa Final

Amanojaku não quebra o sistema…
ele faz o sistema se quebrar sozinho


 

segunda-feira, 23 de março de 2015

💣🔥 Manifesto Bellacosa Mainframe — “O Sistema Nunca Parou” 🔥💣

 

Manifesto Bellacosa Mainframe

💣🔥 Manifesto Bellacosa Mainframe — “O Sistema Nunca Parou” 🔥💣

O mundo fala em inovação como se tudo tivesse começado ontem.
Mas nós sabemos a verdade:

os sistemas mais críticos do planeta nunca desligaram.

Enquanto startups nasciam e morriam em ciclos de deploy,
o mainframe estava lá — processando, garantindo, sustentando.


🧠 1. NÃO É LEGADO. É CONTINUIDADE

Chamam de legado aquilo que não entendem.

Mainframe não é passado.
É código que sobreviveu ao tempo porque funciona sob pressão real.

  • bilhões de transações
  • consistência garantida
  • décadas sem falha catastrófica

Se ainda está em produção… não é antigo. É essencial.


⚙️ 2. PRODUÇÃO NÃO É BRINCADEIRA

Aqui não existe “deploy sexta à noite só pra testar”.

Mainframe é:

  • compromisso
  • previsibilidade
  • responsabilidade

Cada JOB, cada COMMIT, cada região CICS
carrega impacto real: banco, governo, economia.

Erro aqui não é bug. É incidente.


🔥 3. COBOL NÃO MORREU. ELE EVOLUIU EM SILÊNCIO

Enquanto o mundo gritava por novas linguagens,
o COBOL continuava processando o mundo.

E agora:

  • COBOL falando JSON
  • APIs REST no z/OS
  • Integração com cloud
  • CICS como backend de aplicativo moderno

O que chamavam de velho… virou backend invisível do presente.


🌐 4. MAINFRAME NÃO COMPETE COM A NUVEM — ELE A SUSTENTA

Cloud escala.
Mainframe garante consistência.

A arquitetura moderna não substitui o mainframe.
Ela orbita ao redor dele.

  • mobile → API → mainframe
  • fintech → cloud → core bancário em z/OS
  • apps modernos → dados críticos → DB2

O mainframe é o core transacional do planeta.


🧬 5. QUEM DOMINA ISSO, DOMINA O INVISÍVEL

Mainframe não é hype.
É infraestrutura invisível.

E quem entende:

  • JCL
  • CICS
  • DB2
  • RACF
  • arquitetura transacional

… entende como o mundo realmente roda por baixo.

Você não vê. Mas depende.


🎓 6. CONHECIMENTO NÃO PODE MORRER EM SILÊNCIO

O maior risco não é a tecnologia desaparecer.

É o conhecimento não ser transmitido.

Por isso:

  • ensinamos
  • documentamos
  • traduzimos o complexo
  • formamos novos operadores do sistema

Porque um sistema só continua… se alguém souber operá-lo.


💣 7. FALHAR NÃO É OPÇÃO. ENTÃO EVOLUIMOS COM CUIDADO

Aqui não existe “quebra e conserta depois”.

Mainframe evolui diferente:

  • com controle
  • com rastreabilidade
  • com respeito ao que já funciona

Modernizar não é destruir. É integrar.


🔥 8. O FUTURO NÃO É NOVO. É INTEGRADO

O futuro não vai substituir o mainframe.

Vai conectar:

  • COBOL + API
  • CICS + microservices
  • z/OS + cloud
  • batch + tempo real

O futuro é híbrido. E o mainframe já está nele.


⚔️ 9. SER MAINFRAME É UMA MENTALIDADE

Não é só tecnologia.

É postura:

  • pensar em escala real
  • respeitar produção
  • entender impacto
  • valorizar estabilidade

É sair do “funciona na minha máquina”
para “funciona para milhões de pessoas”.


🧾 10. NOSSO COMPROMISSO

Nós não abandonamos sistemas críticos.
Nós não romantizamos caos.
Nós não trocamos estabilidade por hype.

Nós:

  • evoluímos com responsabilidade
  • ensinamos com propósito
  • construímos com base sólida

💥 FRASE FINAL

“Mainframe não é o passado sobrevivendo.
É o presente sustentando o futuro.”

quinta-feira, 12 de março de 2015

☕ Guia de Estilo COBOL Mainframe

 

Bellacosa Mainframe apresenta Guia de Estilo Programação COBOL

☕ Guia de Estilo COBOL Mainframe

Disciplina, Legibilidade e Código que Sobrevive Décadas

No mundo do Mainframe, código não é descartável.

Ele não nasce para rodar hoje e morrer amanhã.

Ele nasce para:

✔ Processar bilhões
✔ Sustentar bancos e governos
✔ Passar por gerações de analistas
✔ Continuar funcionando daqui a 30 anos

E é exatamente por isso que existe algo quase sagrado no z/OS:

O Guia de Estilo COBOL

Não é sobre estética.
Não é sobre preferência pessoal.

É sobre engenharia de software de missão crítica.


🏛️ COBOL não é uma linguagem — é uma arquitetura de longevidade

COBOL foi projetado para que qualquer profissional treinado consiga ler o programa como se fosse um documento técnico.

Código bom em COBOL:

➡️ Não surpreende
➡️ Não esconde lógica
➡️ Não depende do autor
➡️ Não envelhece mal

Por isso, em ambientes corporativos, você verá programas escritos em 1985 sendo mantidos hoje — e ainda legíveis.


🧱 A Estrutura Sagrada das DIVISIONS

Todo programa começa respeitando a anatomia clássica:

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Isso não é opcional.
É o equivalente a planta estrutural de um prédio.

No padrão corporativo, o cabeçalho costuma conter:

  • Autor

  • Data

  • Sistema

  • Descrição funcional

  • Histórico de alterações

  • Identificadores de controle

Um programa sem cabeçalho é como um dataset sem catálogo: existe, mas ninguém confia.


📛 Convenções de Nomes — a identidade do código

Em Mainframe, nomes carregam semântica operacional.

Você não nomeia variáveis por gosto.
Você nomeia para facilitar auditoria, manutenção e troubleshooting.

Padrões clássicos:

  • WS- → Working Storage

  • LK- → Linkage Section

  • FD- → File Description

  • FL- → Flags

  • CNT- → Contadores

Exemplo:

01 WS-SALDO-CONTA PIC S9(9)V99 COMP-3.
01 FL-FIM-ARQUIVO PIC X VALUE 'N'.
01 CNT-REG-PROCESSADOS PIC 9(7) VALUE ZERO.

Um analista experiente identifica o papel de cada campo em segundos.


📦 Working-Storage: organização é sobrevivência

Um dos sinais mais claros de maturidade técnica é como a WORKING-STORAGE SECTION está estruturada.

Código júnior:

👉 Variáveis soltas, sem agrupamento

Código enterprise:

👉 Blocos organizados por função

  • Constantes

  • Variáveis de processo

  • Flags

  • Contadores

  • Áreas de interface

  • Tabelas

Isso reduz drasticamente erros de manutenção.


📁 Arquivos: FD bem definido evita desastre

Arquivos são a base do processamento batch.

Um FD mal definido pode gerar:

  • Truncamento de dados

  • Corrupção de registros

  • Falhas silenciosas

  • Incidentes críticos

Exemplo robusto:

FD FD-CLIENTE
RECORD CONTAINS 80 CHARACTERS.

01 REG-CLIENTE.
05 CLI-ID PIC 9(6).
05 CLI-NOME PIC X(40).
05 CLI-SALDO PIC S9(7)V99 COMP-3.

Aqui, cada campo tem propósito claro.


🔁 PROCEDURE DIVISION — o fluxo deve contar uma história

Em sistemas críticos, o fluxo principal deve ser quase autoexplicativo.

Padrão ouro:

MAIN-LOGIC.
PERFORM INICIALIZAR
PERFORM PROCESSAR
PERFORM FINALIZAR
STOP RUN.

Um bom programa COBOL pode ser entendido apenas lendo os nomes dos parágrafos.


🚫 GO TO: herança do passado

GO TO existe.
Mas seu uso moderno é fortemente desencorajado.

Por quê?

Porque ele quebra:

  • Legibilidade

  • Rastreabilidade

  • Estrutura lógica

  • Facilidade de manutenção

PERFORM estruturado é a abordagem segura:

PERFORM UNTIL FL-FIM-ARQUIVO = 'S'
PERFORM LER-REGISTRO
PERFORM PROCESSAR-REGISTRO
END-PERFORM

🧠 Condition Names (nível 88): elegância esquecida

Um dos recursos mais elegantes do COBOL.

Transforma flags cruas em lógica semântica:

01 FL-EOF PIC X VALUE 'N'.
88 FIM-ARQUIVO VALUE 'S'.
88 NAO-FIM VALUE 'N'.

Uso:

PERFORM UNTIL FIM-ARQUIVO

Legível. Seguro. Profissional.


📝 Comentários: explicar o que o código não mostra

Comentários não servem para descrever sintaxe.

Servem para explicar:

  • Regras de negócio

  • Dependências externas

  • Exceções

  • Decisões históricas

  • Interfaces com outros sistemas

Em ambientes regulados, isso é essencial para auditorias.


📏 O legado das colunas COBOL

Mesmo com IDEs modernas, a estrutura clássica ainda aparece:

  • Colunas 1–6 → numeração

  • Coluna 7 → indicador (* comentário)

  • Área A → divisões e níveis principais

  • Área B → instruções

Isso remonta à era dos cartões perfurados — e ainda influencia padrões atuais.


🏦 Por que empresas são tão rigorosas?

Porque o risco é real.

Um programa COBOL pode:

  • Movimentar bilhões por dia

  • Atualizar bases críticas

  • Rodar sem supervisão humana

  • Integrar dezenas de sistemas

O custo de um erro pode ser gigantesco.

Por isso, padrões incluem:

✔ Tratamento formal de erros
✔ Mensagens padronizadas
✔ Uso extensivo de COPYBOOKs
✔ Performance previsível
✔ Compatibilidade com CICS, DB2 e JCL
✔ Conformidade com auditorias


☕ A filosofia Bellacosa Mainframe

Código COBOL não é um exercício acadêmico.

É um ativo corporativo.

“Se amanhã outro profissional assumir seu programa, ele deve entender tudo sem ligar para você.”

Um bom código mainframe deve ser:

🧠 Legível
🧱 Estruturado
🔒 Seguro
📜 Auditável
⏳ Preparado para décadas


⭐ Conclusão

O guia de estilo COBOL não existe para limitar criatividade.

Ele existe para garantir algo muito mais importante:

Confiabilidade operacional em escala planetária

COBOL não vence pela modernidade.
Vence pela previsibilidade.

E em sistemas críticos, previsibilidade é tudo.