domingo, 15 de junho de 2014

🎮 Insert Coin — O Isekai Brasileiro dos 8 Bits

 


🎮 Insert Coin — O Isekai Brasileiro dos 8 Bits

por Vagner Bellacosa – Blog El Jefe / Bellacosa Mainframe

O mundo dos jogos eletrônicos teve, para mim, dois momentos de virada — dois portais mágicos que abriram as portas do infinito.
O primeiro foi ainda no final da década de 1970, quando meu pai nos levou à casa de conhecidos que haviam adquirido um Telejogo. Sim, o primeiro console brasileiro, fabricado pela Philco-Ford. Aquela caixa preta com dois controles fixos e uma chave seletora no painel parecia coisa de ficção científica. Mas deixemos o Telejogo para outro capítulo — porque o verdadeiro choque de luz e som veio logo depois, com o pinball.

Meu pai adorava fliperama, e eu, ainda pequeno, o acompanhava nos salões de jogos e nos botecos do bairro.
As máquinas piscavam como árvores de Natal psicodélicas, cheias de luzes, ruídos metálicos e sons estridentes. A bolinha de aço saltando, as palhetas vibrando, o contador analógico estalando a cada ponto conquistado.
Era o coração mecânico da diversão.

Mas eu, pequenino e já curioso, me fascinava mesmo eram pelos jogos Arcade, aquelas adoráveis maquinas de jogos eletrônicos operadas por fichas — os primeiros games com somente dois botões e um joystick que projetavam um universo inteiro em uma tela. Eu era pequenino e nem alcançava a consola, eles colocavam uma banqueta para poder ter imersão completa.



Aquilo era pura magia.
Como era possível que algo tão pequeno gerasse tanta emoção?
Como se criava algo assim?
Ali nasceram as primeiras sementes do programador que eu viria a ser.



Vieram então os ícones da era dourada dos 8 bits:
Pac-Man, River Raid, Enduro, Space Invaders, e tantos outros que cabiam em cartuchos ou fitas cassete. Cada jogo era uma jornada — uma microaventura onde a imaginação completava o que os pixels não podiam mostrar.




Com o início da década de 1980, as máquinas ganharam mais poder, mais cores e mais botões.
As fichas metálicas tilintando nas bancadas dos bares se tornaram meu passaporte para outro mundo.
A cada insert coin, um novo universo se abria — e, sem perceber, eu estava aprendendo lógica, padrões, reações. Estava decifrando sistemas.
Cada game over era uma lição de persistência; cada continue era um código de vida.

E lá estava eu, no meio da revolução eletrônica, sem saber que aquele fascínio pelos circuitos e sprites me levaria, anos depois, ao encontro de outro gigante de ferro e silício — o IBM Mainframe.
Do fliperama ao MVS/360, dos 8 bits aos 32 bits, das fichas metálicas ao cartão perfurado, o salto foi enorme — mas o espírito era o mesmo: entender o que havia por trás da tela.
Da bolinha prateada aos datasets, o menino curioso continuava apertando Start.




🕹️ Easter Eggs e Curiosidades

  • O Telejogo brasileiro foi lançado em 1977 e tinha apenas três modos de jogo — tênis, futebol e paredão — todos variantes do Pong da Atari.

  • Os fliperamas eletromecânicos antecederam os pinballs eletrônicos e funcionavam à base de relés, motores e contatos metálicos.

  • O termo insert coin (insira a moeda) virou símbolo cultural dos anos 80 e 90, e até hoje aparece como easter egg em diversos sistemas e programas criados por desenvolvedores nostálgicos.

  • Curiosamente, alguns mainframes IBM antigos usavam sons e luzes em painéis que lembravam muito um pinball — uma ironia tecnológica que unia o sagrado e o profano da computação.


No fim das contas, toda a nossa geração foi um pouco assim:
aprendeu lógica no fliperama, digitação no BASIC, e disciplina na escola da vida.
O fliper era o debug da infância, e o Telejogo, o BIOS do imaginário.
Entre fichas e cartões perfurados, nascia o programador que ainda hoje, diante da tela, continua ouvindo a mesma voz de sempre:
“Insert Coin.”

sábado, 14 de junho de 2014

O formiguinha arteiro brincando no Tobogan

Festa Junina da Bosch e o tobogan


Estamos na gesta Junina da Bosch Campinas organizada pelo grémio de funcionários, com muita diversão, barraca de brincadeiras, jogos para adultos e crianças, bingos e vários brinquedos inflaveis.

O formiguinha neste dia brincou a pescaria, ao atirar latas, viu a fogueira de São João e fez aquilo que mais adora: andou de trenzinho dentro das instalações da Bosch.




Para terminar o dia em grande fomos para a área de brinquedos inflaveis, lugar onde ele se acabou, virando cambalhota, pulando, escorrendo, virando e fazendo arte.

Foi um dia delicioso para guardar na memoria.

segunda-feira, 9 de junho de 2014

COBOL Imperativo, Procedural e Procedural Estruturado



COBOL Imperativo, Procedural e Procedural Estruturado

Três fases da mesma linguagem (e três estados de espírito no CPD)

Ao estilo Bellacosa Mainframe, servido quente no El Jefe Midnight Lunch



☕ Introdução: o mesmo COBOL, três mentalidades

Quem olha de fora acha que COBOL é tudo igual desde 1959. Quem viveu mainframe sabe: o COBOL mudou — não tanto na sintaxe, mas na forma de pensar.

Imperativo, Procedural e Procedural Estruturado não são dialetos oficiais escritos em pedra. São estágios evolutivos, reflexo direto de:

  • Limitações de hardware

  • Pressões de negócio

  • Maturidade da engenharia de software

Entender essas diferenças é entender por que tanto código legado funciona… e por que outro tanto assombra equipes até hoje.


🧠 COBOL no modo Imperativo — o nascimento selvagem

📅 Quando surgiu

Final dos anos 50 e início dos 60, junto com o próprio COBOL.

🎯 Ideia central

“Faça exatamente isso. Agora isso. Agora pule para lá.”

O foco é comando direto. O programa é uma lista de ordens explícitas para a máquina.

🧩 Características

  • Uso intenso de GO TO

  • Fluxo não linear

  • Dependência forte da ordem física do código

  • Parágrafos longos e multifuncionais

🧨 Comentário Bellacosa

Era compreensível. Memória era cara, CPU era lenta e ninguém pensava em manutenção a longo prazo.

Funcionou ontem? Então não mexe.

🥚 Easter Egg

Muito código imperativo ainda roda em produção porque ninguém tem coragem de tocar.


🧠 COBOL Procedural — organização por rotinas

📅 Quando ganhou força

Anos 60 e 70, com sistemas maiores e equipes crescendo.

🎯 Ideia central

“Organize o programa em procedimentos reutilizáveis.”

Aqui surge a noção clara de rotinas, chamadas e retorno.

🧩 Características

  • Uso intenso de PERFORM

  • Divisão do programa em parágrafos

  • Fluxo mais previsível

  • Ainda aceita GO TO (e muita gente abusou)

⚠️ O perigo oculto

Procedural não é automaticamente estruturado.

Você pode ter um código procedural organizado e ainda assim caótico.

🥚 Easter Egg

Parágrafos chamados 9999-FIM ou EXIT-PROG são herança direta dessa fase.


🧠 COBOL Procedural Estruturado — quando o COBOL vira engenharia

📅 Quando surgiu

Final dos anos 70 e anos 80, influenciado pela programação estruturada (Dijkstra, Böhm & Jacopini).

🎯 Ideia central

“Fluxo previsível é mais importante que truque de performance.”

Aqui o COBOL ganha disciplina formal.

🧩 Características

  • Eliminação prática do GO TO

  • Uso sistemático de:

    • IF / END-IF

    • EVALUATE / END-EVALUATE

    • PERFORM UNTIL / END-PERFORM

  • Parágrafos pequenos e coesos

  • Código que se lê como um roteiro lógico

🏦 Razão de negócio

  • Auditoria

  • Confiabilidade

  • Manutenção por décadas

Bancos e seguradoras exigiram esse padrão.


📊 Comparativo rápido

EstiloControle de fluxoManutençãoRisco
ImperativoCaóticoDifícilAlto
ProceduralMédioMelhorMédio
Procedural EstruturadoPrevisívelExcelenteBaixo

🛠️ Passo a passo: migrando o pensamento

1️⃣ Pare de pensar em linhas, pense em fluxo

Pergunte:

  • Onde começa?

  • Onde decide?

  • Onde termina?

2️⃣ Um parágrafo, uma responsabilidade

Se o nome precisa de “E”, “OU” e “TAMBÉM”… está grande demais.

3️⃣ Substitua IFs aninhados por EVALUATE

Mais legível, mais auditável.

4️⃣ Use PERFORM como se fosse chamada de função

Mesmo sem parâmetros formais, o conceito é o mesmo.


🔐 Segredos de veterano

🔹 Código estruturado reduz incidentes noturnos.

🔹 Auditor confia mais em código previsível do que em código “esperto”.

🔹 Performance se resolve depois; clareza primeiro.

🔹 Todo sistema legado parece ruim… até você entender o contexto em que nasceu.


🧾 Curiosidades de bastidor

  • Muitos padrões internos de bancos proíbem GO TO há mais de 30 anos.

  • Há programas imperativos mais antigos que seus mantenedores.

  • COBOL estruturado influenciou diretamente padrões de codificação em PL/I e até Java.


🥚 Easter Eggs do CPD

🕰️ Parágrafos numerados (1000-INICIO) são fósseis vivos.

🐘 Compiladores modernos reclamam de GO TO, mas ainda aceitam — respeito aos ancestrais.

☕ Quanto mais estruturado o código, menos café o time consome em fechamento.


✅ Boas práticas Bellacosa Mainframe

✔ Evite GO TO como se fosse vazamento em produção
✔ Prefira clareza a micro-otimização
✔ Nomeie parágrafos com linguagem de negócio
✔ Estruture pensando no próximo mantenedor
✔ Código bom é código explicável


🌙 Conclusão: não é sobre sintaxe, é sobre mentalidade

Imperativo, Procedural e Procedural Estruturado contam a história da maturidade do software corporativo.

O COBOL não ficou velho.
Ele ficou responsável.

E no mundo mainframe, responsabilidade é o que mantém sistemas rodando…

sem glamour, sem barulho e sem falhar.

Bellacosa Mainframe, direto do CPD para o El Jefe Midnight Lunch 🌙


sábado, 10 de maio de 2014

Globo da Morte em Itatiba

Aventuras no globo da morte..


Um circo mambembe numa pequena cidade do interior paulista, audazes motociclistas aprontam vários truques em suas motocicletas.



O ronco do motor ensurdecedor, bagunça sobre duas rodas, o formiguinha pirou com o barulho, ficou louco com as peripécias dos pilotos.



O roncar dos motores, o silencio e atenção do publico tornam ainda mais magico a sensação. Rodando e subindo correndo e subindo pelas grades.

Globo da Morte em Itatiba

Aventuras no globo da morte..


Um circo mambembe numa pequena cidade do interior paulista, audazes motociclistas aprontam vários truques em suas motocicletas.



O ronco do motor ensurdecedor, bagunça sobre duas rodas, o formiguinha pirou com o barulho, ficou louco com as peripécias dos pilotos.



O roncar dos motores, o silencio e atenção do publico tornam ainda mais magico a sensação. Rodando e subindo correndo e subindo pelas grades.

sexta-feira, 9 de maio de 2014

O Dai Maou como Metáfora do Programador que Resolve Tudo às 3h da Manhã

 


🜂 El Jefe Midnight Lunch apresenta

O Dai Maou como Metáfora do Programador que Resolve Tudo às 3h da Manhã

Um tratado místico–mainframeiro para entendermos a verdadeira natureza dos heróis noturnos

Por Bellacosa Mainframe


Existem duas forças supremas no universo:

  1. O Grande Rei Demônio (Dai Maou), soberano das trevas nas histórias japonesas.

  2. O Programador Mainframe que acorda a empresa inteira quando decide “só ajustar rapidinho esse JCL” às 3h da manhã.

Ambos operam no silêncio absoluto, ambos manipulam poderes que mortais não compreendem, e ambos têm aquela aura de respeito misturado com medo reverente.

E, como todo bom filósofo da madrugada com café frio na mão e ISPF aceso, afirmo:
o programador noturno É o Dai Maou corporativo.


🜁 1. A Origem — quando cai o chamado

O Dai Maou não nasce vilão.
Ele é escolhido, invocado, empurrado por circunstâncias, destino ou… ticket crítico aberto no ServiceNow.

Assim também é o programador mainframe:

  • ninguém dorme tranquilo;

  • o telefone vibra com aquele “P1 - Sistema de Pagamentos Parado”;

  • a iluminação do quarto vira o prelúdio do modo batalha;

  • a alma desperta direto no nível épico.

É nesse instante que o programador assume seu destino:
“Se eu não for agora, ninguém vai.”

Isso, meu amigo, é a verdadeira coroação do Dai Maou da Madrugada.


🜃 2. Os Poderes Mágicos — a caixa preta arcana

Todo Dai Maou domina magia proibida.
Todo programador das 3h domina:

  • reprocessamento de job com override obscuro,

  • permutação de DDs sem documentação,

  • JES2 como quem recita mantras,

  • debugging mental na penumbra,

  • e aquele talento secreto de descobrir onde está o maldito space abend sem print.

É magia?
É experiência?
É trauma?
É tudo junto.

O poder supremo do Dai Maou é manipular energia demoníaca.
O do programador:
manipular datasets compartilhados sem derrubar o sistema.

Ambos exigem pacto.


🜁 3. O Castelo — o Datacenter Mental

O castelo do Dai Maou é sombrio, cheio de livros proibidos e ecos de almas perdidas.

O castelo do programador noturno é:

  • um terminal 3270 piscando;

  • um caderno cheio de senhas riscadas;

  • um monitor com tabs de JCLs ancestrais;

  • e uma luminária queimada desde 2017.

Ali, no silêncio absoluto da madrugada, nasce o feitiço supremo:

/REPRO JOB ......................... /* NÃO MEXER - SÓ RODA EM PRODUÇÃO /

Pergunte para qualquer veterano:
esse é o verdadeiro grimório proibido.


🜄 4. A Solidão Épica — o fardo do soberano

Assim como o Dai Maou governa sozinho,
o programador das 3h enfrenta batalhas com a mesma solidão trágica:

  • ninguém responde no Teams,

  • o on-call sumiu,

  • o líder mandou “boa sorte 👍” e voltou a dormir,

  • a documentação está quase correta (e essa é a pior parte),

  • e a única testemunha da batalha é um café de micro-ondas.

Essa solidão é o preço do poder.
E ambos aceitam.


🜂 5. A Aura — o respeito quando o sol nasce

Quando o Dai Maou aparece, o mundo treme.

Quando o programador aparece às 9h com olheira preta e cara de “revivi três vezes esta noite”, as pessoas desviam o olhar.
Há uma reverência natural.

E o diálogo é sempre o mesmo:

— Nossa, você veio hoje?
— Sistema voltou às 4h.
— Nossa, obrigado!

Ninguém comenta muito.
Ninguém pergunta detalhes.
É tabu.
É sagrado.


🜃 6. Fofoquices Demoníacas do Mundo Corporativo

(Se tem Bellacosa, tem fofura sombria.)

  • Há empresas onde o programador noturno é chamado informalmente de “O senhor das trevas”.

  • Em equipes mais jovens, virou moda dizer “fulano é o Maou do CICS”.

  • Em grupos de zap, rola o sticker: “Chamem o Dai Maou — o batch caiu!”

  • Alguns dizem que quando um job dá RC=0012 sem motivo, é porque o Dai Maou interior do programador está testando sua fé.


🜁 7. Conclusão — O Verdadeiro Significado

O Dai Maou, no fundo, é um arquétipo do poder solitário, da responsabilidade inevitável, do peso de manter o mundo girando.

Assim como o programador da madrugada.

Ambos são:

  • temidos,

  • respeitados,

  • incompreendidos,

  • e absolutamente essenciais.

Quando tudo falha,
quando ninguém sabe o que fazer,
quando o caos ameaça o reino…

é ele que surge,
cansado, mal-humorado, com café na mão,
mas capaz de restaurar a ordem no mundo.

Por isso, querido leitor,
deixo aqui meu mantra:

Dai Maou não é inimigo.
É guardião.
É mantenedor.
É o programador que salva o sistema quando todos estão dormindo.

E é por isso que, no universo do mainframe —
assim como nas lendas —
a noite pertence aos poderosos.

quinta-feira, 8 de maio de 2014

COBOL Estruturado: disciplina, elegância e sobrevivência no mundo mainframe

 



COBOL Estruturado: disciplina, elegância e sobrevivência no mundo mainframe

Ao melhor estilo Bellacosa Mainframe, direto dos porões do CPD para o El Jefe Midnight Lunch


☕ Introdução: quando o COBOL aprendeu a pensar

Durante décadas, o COBOL foi injustamente carimbado como uma linguagem verborrágica, rígida e cheia de GOTOs selvagens pulando de parágrafo em parágrafo como gremlins em madrugada de fechamento mensal. O COBOL estruturado surge justamente como a vacina contra esse caos.

Mais do que uma evolução sintática, COBOL estruturado é postura, disciplina mental e, acima de tudo, respeito ao próximo programador — normalmente você mesmo daqui a 6 meses.




🧠 O que é COBOL Estruturado, afinal?

COBOL estruturado é a aplicação dos princípios da programação estruturada ao COBOL clássico:

  • Nada de saltos caóticos com GO TO

  • Fluxo lógico previsível

  • Blocos com início, meio e fim bem definidos

Ele se apoia em três pilares universais:

  1. Sequência – código executado em ordem natural

  2. Seleção – decisões claras (IF, EVALUATE)

  3. Iteração – repetição controlada (PERFORM UNTIL, PERFORM VARYING)

Se você domina isso, domina qualquer código mainframe.


📜 Por que o COBOL estruturado é mais legível?

Porque ele conta uma história.

Compare:

  • Parágrafos pequenos e objetivos

  • END-IF, END-PERFORM explícitos

  • Nomes semânticos (CALCULA-TOTAL, VALIDA-CPF)

O código deixa de ser um labirinto e vira um manual técnico executável.

💡 Dica Bellacosa: se o código parece um romance russo, algo está errado.


🛠️ Passo a passo para escrever COBOL estruturado

1️⃣ Planeje antes de codar

Desenhe o fluxo:

  • O que entra?

  • Quais decisões existem?

  • Onde o processamento termina?

2️⃣ Quebre tudo em parágrafos pequenos

Um parágrafo = uma responsabilidade.

Errado:

  • PROCESSA-TUDO

Certo:

  • LE-ARQUIVO

  • VALIDA-DADOS

  • CALCULA-VALORES

  • GRAVA-SAIDA

3️⃣ Use PERFORM como se fosse uma chamada de função

PERFORM VALIDA-DADOS
PERFORM CALCULA-TOTAL

Isso é COBOL estruturado em sua forma mais pura.

4️⃣ Elimine GO TO (sem dó)

Se você precisa de GO TO, provavelmente:

  • O parágrafo está grande demais

  • O fluxo está mal pensado


🧪 Segredos que veteranos não contam

🔹 Menos é mais: COBOL estruturado prefere muitos parágrafos pequenos a poucos gigantes.

🔹 IF aninhado demais é cheiro de problema: use EVALUATE.

🔹 Comentários explicam o porquê, não o como:

* Validação exigida pelo Bacen após incidente de 2009

🔹 Código bem estruturado envelhece melhor que documentação externa.


🧾 Curiosidades de bastidor (fofoca técnica)

  • O impulso pela programação estruturada veio forte nos anos 70, após sistemas críticos se tornarem impossíveis de manter.

  • Grandes bancos só aceitaram novas rotinas COBOL sem GO TO.

  • Há sistemas em produção hoje que seguem padrões estruturados criados nos anos 80 — e funcionam melhor que muito microserviço moderno.


🥚 Easter Eggs do mundo mainframe

🕵️‍♂️ Já reparou que muitos sistemas usam parágrafos chamados MAIN-PARA ou 0000-INICIO? Isso é herança direta da transição do COBOL não estruturado.

🐘 Alguns compiladores modernos avisam quando você usa GO TO. É o mainframe te julgando silenciosamente.

☕ Programadores COBOL estruturado costumam dormir melhor em fechamento contábil.


✅ Boas práticas Bellacosa Mainframe (anote!)

✔ Um parágrafo não deve passar de uma tela
✔ Nomeie tudo com significado de negócio
✔ Prefira EVALUATE a IF encadeado
✔ Evite variáveis globais desnecessárias
✔ Código deve ser lido como um roteiro lógico


🌙 Conclusão: COBOL estruturado não é velho — é sábio

COBOL estruturado é como um bom uísque: não precisa de modinha, precisa de respeito. Ele entrega previsibilidade, estabilidade e clareza — exatamente o que sistemas críticos exigem.

No fim das contas, não é sobre COBOL.
É sobre engenharia, disciplina e responsabilidade.

E como todo bom código mainframe…

Ele não faz barulho. Ele simplesmente funciona.

Bellacosa Mainframe, servido à meia-noite no El Jefe Midnight Lunch 🌙