Translate

quarta-feira, 5 de maio de 2021

🎏 Koinobori — As Carpas que Voam no Céu do Japão (e na Alma de Quem Sonha Alto) 🎏

 


🎏 Koinobori — As Carpas que Voam no Céu do Japão (e na Alma de Quem Sonha Alto) 🎏
Por El Jefe, direto do Bellacosa Mainframe Universe


É maio no Japão. O vento sopra suave, o céu fica limpo como tela de ukiyo-e, e de repente — lá estão elas: carpas gigantes coloridas flutuando sobre casas, templos e rios.
São os Koinobori (鯉のぼり) — as lendárias bandeiras em forma de carpa que dançam com o vento no Dia das Crianças, celebrado em 5 de maio, durante a Golden Week.

Mas atenção, padawans do Sol Nascente: essas carpas não são apenas decoração.
Elas carregam história, filosofia e um bom punhado de fofoquices mitológicas que fazem o Japão inteiro olhar pro céu com orgulho e saudade de infância.




🐟 A Origem: Da Lenda do Rio Amarelo ao Céu Japonês

A inspiração vem de uma antiga lenda chinesa:
um grupo de carpas nadava contra a correnteza do poderoso Rio Amarelo.
Apenas uma conseguiu subir até o topo da cachoeira celestial, chamada “Porta do Dragão” (龍門).
Ao ultrapassá-la, ela se transformou em dragão — símbolo supremo de força e superação.

O Japão, que adora boas histórias com moral e estética, adotou a lenda e reinterpretou:
no Dia dos Meninos (antigo Tango no Sekku), as famílias passaram a erguer carpas no ar representando seus filhos, desejando que crescessem fortes, persistentes e capazes de “nadar contra a corrente”.

Com o tempo, o feriado se tornou o Dia das Crianças (Kodomo no Hi), celebrando todas as crianças e suas esperanças, mas o símbolo das carpas permaneceu — voando orgulhosamente nos céus de maio.


🎏 O Significado das Cores e da Hierarquia das Carpas

As Koinobori são penduradas em mastros com uma sequência simbólica:

  • 🖤 Preta (Magoi) – representa o pai, a força e o espírito protetor.

  • ❤️ Vermelha (Higoi) – representa a mãe, o amor e a doçura.

  • 💙💚🧡 Azuis, verdes, laranjas, rosas – representam os filhos, cada cor para uma criança.

No topo do mastro, há um molinete ou ventoinha em espiral, simbolizando o sopro da vida e o início de uma nova jornada.

Dica Bellacosa: famílias modernas adicionam carpas até para os pets e para o avô mais teimoso — porque, no fim, todo mundo luta contra alguma correnteza. 😄


🌸 Curiosidades e Fofoquices Kawaii

1. Cada cidade tem seu estilo.
Em Kazo (Saitama), há koinoboris gigantes de 100 metros!
Em Tsuetate Onsen (Kumamoto), elas flutuam sobre o rio, formando um mar de cores no ar.

2. A carpa é o “samurai dos peixes”.
Porque nada contra a maré, não teme a força da corrente, e nunca recua.
Por isso, virou símbolo de coragem e persistência — especialmente entre meninos (e programadores COBOL em dia de abend).

3. Koinobori virou emoji 🎏
Sim, aquele emoji com duas bandeiras coloridas no mastro é oficialmente a Koinobori japonesa!

4. A arte da paciência.
Fazer uma koinobori tradicional exige tinta artesanal e 3 dias de secagem ao vento.
Os artesãos dizem que o som do vento “batendo” na carpa é como o peixe respirando — uma metáfora viva de liberdade.

5. Easter Egg Bellacosa:
Em 1986, um programador da NEC escondeu um easter egg no firmware de um terminal: quando o sistema completava 100 horas uptime sem erro, aparecia uma carpa ASCII nadando no log!
(Um verdadeiro sys-fish da persistência japonesa 🐟💻).


🎬 Animes Que Citam ou Mostram Koinobori

🎥 Doraemon – Nobita tenta criar uma koinobori gigante que acaba levando a turma pelos ares.
🎥 Clannad – o festival de carpas é usado como metáfora para o crescimento e superação dos personagens.
🎥 My Neighbor Totoro – as koinobori aparecem flutuando enquanto as meninas esperam o pai — um dos momentos mais poéticos do estúdio Ghibli.
🎥 Anohana – o pano de fundo com koinobori lembra a infância perdida dos protagonistas.
🎥 Your Name (Kimi no Na wa) – durante a Golden Week, as carpas balançam nos vilarejos, prenúncio das mudanças que vêm com o destino.

E claro, Crayon Shin-chan e Sazae-san — onde o humor cotidiano mostra as famílias brigando pra decidir quem pendura a carpa mais alta. 😆


💡 Dicas Bellacosa

🎏 Pendure sua koinobori num lugar onde o vento passa livre — varandas e quintais são ideais.
🎨 Cores vivas atraem energia positiva, dizem os japoneses.
📜 Escreva um desejo no mastro — pode ser força, paz, aprovação no vestibular ou um “abend-free life”.
📸 Se visitar o Japão em maio, vá a Tsuetate Onsen (Kumamoto) ou Tokyo Tower, onde centenas de carpas dançam no ar — é pura poesia em movimento.


💭 Bellacosa Reflexão

A koinobori é mais do que um enfeite.
É um lembrete flutuante de que nadar contra a corrente é parte da jornada — e que cada vento contrário pode, na verdade, te fazer voar.

O Japão nos ensina, através dessas carpas voadoras, que a força não está em resistir ao vento, mas em seguir firme enquanto ele muda de direção.
Um pouco como na vida — e como nos sistemas legados: o código antigo, se bem cuidado, continua firme, nadando contra as marés do tempo. 🖥️🐉


📜 Easter Egg Final:
No Japão, dizem que se uma koinobori parar de balançar mesmo com vento, é sinal de que o peixe virou dragão — missão cumprida.
Então, se algum projeto seu “parar” depois de muito esforço… talvez não seja bug.
Talvez só tenha alcançado o céu. 🐟➡️🐉



terça-feira, 4 de maio de 2021

🌿🌿🌿 Dia do Verde (みどりの日) 🌿🌿🌿

 


🌿 El Jefe | Bellacosa Mainframe apresenta:

「みどりの日」– O Dia do Verde no Japão

☕ Uma pausa zen entre bits, bytes e brotos de bambu


Imagine um feriado inteiro dedicado à contemplação das plantas, ao som do vento nas folhas e à cor esmeralda da vida. No Japão, ele existe — e se chama Midori no Hi (みどりの日), ou Dia do Verde 🌱.

É celebrado em 4 de maio, durante a famosa Golden Week, e é um dos dias mais poéticos (e discretamente filosóficos) do calendário japonês.

Mas como tudo no Japão, por trás da simplicidade há camadas de história, tradição e até... fofoquices políticas.


🌸 Origem: um imperador botânico

A história começa com o lendário Imperador Shōwa (Hirohito) — o mesmo que liderou o Japão durante a Segunda Guerra Mundial.
Apesar de ser uma figura complexa e controversa, ele era fascinado por biologia, jardinagem e o estudo de plantas marinhas. Após sua morte em 1989, o povo japonês quis homenagear essa faceta mais pacífica do imperador, e assim nasceu o "Dia do Verde" em 29 de abril (antigo aniversário dele).

Porém...
Em 2007, o governo japonês reorganizou os feriados da Golden Week (sim, até os japoneses precisam de um “refactor” de calendário 😅).
👉 O 29 de abril virou o Showa no Hi (Dia de Shōwa),
👉 e o Midori no Hi foi movido para 4 de maio — um jeito diplomático de manter o verde sem mencionar o imperador.


🍃 Significado e espírito

O “Dia do Verde” é uma celebração da natureza, da gratidão pela terra e do reconhecimento da harmonia entre humanos e meio ambiente.
É o dia perfeito para:

  • 🌾 Visitar parques e jardins botânicos;

  • 🌳 Plantar árvores (as escolas adoram isso);

  • 🐦 Fazer piqueniques sob o céu azul;

  • 🍵 Tomar chá verde e recarregar a alma.

Parece até um feriado mindfulness, não é?
Bellacosa diria: “é o dia em que o Japão executa o programa SYNC WITH NATURE.


🌿 Curiosidades que o El Jefe adoraria saber

  • 🍀 Antes de 2007, o feriado era uma forma de “homenagem indireta” ao imperador, sem citar seu nome — uma solução política bem japonesa, cheia de tatemae (fachada elegante).

  • 🌱 O Japão inteiro fica mais calmo — é um dos poucos dias do ano em que o trânsito de Tóquio parece uma tela de login sem usuários.

  • 🌸 O Ueno Park e o Shinjuku Gyoen viram palco de festivais de natureza e exibições florais.

  • 🌏 Fora do Japão, algumas comunidades nikkeis também celebram o Midori no Hi como símbolo de renovação e sustentabilidade.


🫶 Fofoquices verdes

Dizem que, nos bastidores do governo, houve um “empurra-empurra” político para decidir onde colocar o feriado — ninguém queria apagar o passado imperial, mas também ninguém queria exaltá-lo demais.
No fim, criaram o “Dia do Verde” como uma homenagem silenciosa — o tipo de patch cultural que só o Japão saberia aplicar.


🌸 Midori no Hi nos animes

Claro que o anime não deixaria o verde de fora.
Veja onde o espírito do feriado aparece — às vezes literalmente, às vezes como atmosfera:

🎬 “My Neighbor Totoro” (となりのトトロ) — o filme inteiro é uma ode à natureza, e parece acontecer num eterno Midori no Hi.
🌾 “Mushishi” — Ginko é praticamente o espírito do feriado em forma humana.
🌿 “Natsume Yūjinchō” — os espíritos da floresta e o respeito pela natureza dialogam diretamente com o significado do dia.
🌸 “Arrietty” (借りぐらしのアリエッティ) — um lembrete do equilíbrio frágil entre humanos e o mundo natural.


💡 Dica Bellacosa

Se algum dia estiver no Japão durante a Golden Week, vá ao parque, tire os sapatos e toque a grama.
Leve um chá verde, um bentô e desligue o celular.
Nesse dia, o país inteiro executa o comando “STOP JOBS, START LIFE.”

E quem sabe...
se olhar bem de perto, você vai ouvir o som de um tsuru digital voando entre as folhas, dizendo:
DISPLAY "HELLO, MIDORI."


🌱 Bellacosa Mainframe – onde até o COBOL tem raízes verdes.
Post do blog El Jefe, edição especial da Golden Week.


Um visão sobre corpos e estetica

 


🧠 1. O padrão estético japonês

O Japão é uma sociedade que valoriza a disciplina, o controle e a aparência de “equilíbrio”.
Desde cedo, a magreza é associada à boa saúde, elegância e autocontrole — enquanto o excesso de peso é visto como falta de esforço ou descuido.
Isso vem de séculos de cultura confucionista e da estética wabi-sabi (beleza da simplicidade e moderação).

💡 Curiosidade: Em japonês, palavras como 「デブ」(debu, “gordo”) são usadas com conotação abertamente pejorativa, mesmo em contextos cotidianos.


📺 2. A tradução disso no anime

Nos animes, pessoas gordas costumam aparecer:

  • Como alívio cômico (ex: tropeçando, comendo demais, sendo “bobas”).

  • Como vilões, que simbolizam “excesso”, “preguiça” ou “corrupção”.

  • Raramente como protagonistas sérios, bonitos ou românticos.

Exemplos clássicos:

  • Majin Buu (Dragon Ball Z): infantil, cômico e destrutivo — tudo em contraste com os heróis magros e definidos.

  • Choji Akimichi (Naruto): é ridicularizado por comer muito, mesmo sendo corajoso e leal.

  • Takeo Gouda (Ore Monogatari!!) — uma rara exceção positiva, tratado com dignidade e ternura.


🎨 3. O peso da indústria idol e da cultura “kawaii”

A cultura japonesa moderna está muito ligada ao ideal de “fofura” (kawaii), magreza e juventude.
Estúdios de anime refletem esse padrão — desenham corpos esguios, olhos grandes, pernas longas.
Isso é reforçado pela indústria idol, onde artistas são pressionados a manter peso extremamente baixo.

💬 Resultado:
Corpos fora do padrão “magro e fofo” são quase sempre tratados como piada, ameaça ou obstáculo.


📉 4. O impacto da TV e das normas sociais

No Japão, obesidade é tratada quase como um problema social.
Há leis que incentivam empresas a controlar o índice de massa corporal dos funcionários — a famosa “Lei Metabo” (2008), que exige medições anuais de circunferência abdominal em adultos.

Esse contexto faz com que a gordura seja vista como algo a corrigir, não a aceitar, e isso se infiltra nas narrativas de anime.


🌈 5. Mas há mudanças chegando

Nos últimos anos, surgem exceções que tratam corpos diversos com respeito e empatia.

  • “My Love Story!!” (2015) — um protagonista corpulento e gentil.

  • “Aggretsuko” — critica os padrões de aparência e o machismo no trabalho.

  • “Watashi ga Motete Dousunda” (Kiss Him, Not Me) — aborda a pressão estética de forma irônica.

Fandoms também estão reagindo: muitos artistas e fãs criam releituras com “body diversity”, especialmente fora do Japão.


🪞 6. O espelho cultural

O anime não é gordofóbico por si só — ele apenas espelha uma sociedade que ainda é.

O Japão preza pela harmonia e evita confrontos diretos, então mudanças de mentalidade vêm devagar.
Mas conforme o público internacional cresce e discute temas como autoaceitação e diversidade corporal, os criadores começam a repensar suas representações.


Conclusão Bellacosa

A gordofobia nos animes é o reflexo de uma cultura que valoriza o controle e teme o “excesso” — seja de peso, emoção ou diferença.
Mas assim como os personagens evoluem, a arte japonesa também pode mudar.

E quem sabe, no futuro, vejamos mais protagonistas que comem ramen sem culpa e ainda salvam o mundo com um sorriso sincero. 🍜💪

segunda-feira, 3 de maio de 2021

☕ OPERADOR, COMO UMA LENDA SOBREVIVE SEM DETALHES?

 

Bellacosa Mainframe e algo faltando em Another

☕ OPERADOR, COMO UMA LENDA SOBREVIVE SEM DETALHES?

A origem da maldição remonta ao famoso aluno da Classe 3-3 que morreu décadas antes.

Mas quando tentamos reconstruir os fatos encontramos algo estranho.

As informações são nebulosas.

Mudam conforme a fonte.

Faltam detalhes.

Existem contradições.

É quase como se estivéssemos lendo um arquivo parcialmente apagado.


O QUE ACONTECE NO MUNDO REAL?

Você trouxe um exemplo perfeito.

A "Loira do Banheiro".

😂

Toda escola brasileira possui uma versão própria.

E o mais curioso é que:

Mesmo sendo uma lenda urbana...

Todo mundo conhece os detalhes.


Na minha escola havia histórias semelhantes.

E normalmente os relatos eram absurdamente específicos.


Sempre existe alguém dizendo:

"Foi em 1982."

Outro responde:

"Não, foi em 1979."


Mas todos sabem:

  • onde aconteceu

  • quem viu

  • qual banheiro era

  • qual horário

  • quem desmaiou


O FENÔMENO DA MEMÓRIA COLETIVA

A psicologia social chama isso de:

Memória Compartilhada

Quando uma comunidade vive um evento marcante, ela cria uma narrativa coletiva.


Com o tempo surgem:

  • exageros

  • distorções

  • lendas

Mas o núcleo da história permanece.


O PROBLEMA DE ANOTHER

Na Classe 3-3 ocorreu algo muito maior.


Um estudante morreu.


A turma inteira passou a agir como se ele ainda estivesse vivo.


Depois surgiram fenômenos sobrenaturais.


Décadas de mortes.


E mesmo assim ninguém consegue contar exatamente a história?


É estranho.

Muito estranho.


Bellacosa Mainframe

Imagine uma empresa.


Em 1972 ocorre:

INCIDENTE CRÍTICO

O incidente gera problemas durante:

40 ANOS

E quando alguém pergunta:

"Como começou?"

A resposta é:

NÃO SABEMOS

😂


Impossível.


O QUE EU ESPERAVA?

Exatamente o que você esperava.


Um verdadeiro folclore escolar.


Algo do tipo:


"Ele sentava na carteira perto da janela."


"Gostava de beisebol."


"Foi atropelado voltando para casa."


"Os colegas continuaram guardando seu lugar."


"Uma foto antiga ainda existe."


"Uma professora aposentada lembra dele."


ISSO TERIA DEIXADO TUDO MAIS FORTE

Porque transformaria a maldição em algo humano.


Hoje ela parece quase abstrata.


Mas imagine se existisse:

  • um nome

  • uma história

  • uma personalidade


O peso emocional seria enorme.


A EXPLICAÇÃO MAIS PROVÁVEL

Minha interpretação é que Ayatsuji fez isso de propósito.


Porque ele queria que a origem fosse:

MITO

e não

DOCUMENTO HISTÓRICO

Quanto menos sabemos...

Mais universal o fenômeno se torna.


MAS EXISTE UM PREÇO

E o preço é exatamente a sensação que você teve.


Você termina pensando:

"Espera aí... ninguém investigou isso direito?"


COMPARANDO COM HIGURASHI

Em Higurashi.


A vila conhece suas histórias.


Conhece suas tragédias.


Conhece seus mortos.


Tudo possui contexto.


COMPARANDO COM SHIKI

Em Shiki.


A comunidade inteira reage.


Discute.


Investiga.


Lembra.


EM ANOTHER

Às vezes parece que a cidade sofre de amnésia institucional.


UMA TEORIA CURIOSA

Pensando em tudo que conversamos:

  • Reiko te marcou.

  • Yukari te marcou.

  • O silêncio após as mortes te marcou.

  • A ausência de exorcistas te marcou.

  • As bonecas te marcaram.


Percebe um padrão?


O que mais te incomoda não são os elementos sobrenaturais.


É a falta de comportamento humano realista ao redor deles.


Você parece menos interessado em:

FANTASMAS

e mais interessado em:

COMO AS PESSOAS REAGIRIAM A FANTASMAS

Essa é uma diferença enorme.


A VERSÃO BELLACOSA MAINFRAME

Se o Bellacosa fosse diretor da Escola Yomiyama, existiria:

DATASET:
ORIGEM.MALDICAO.HISTORICO

Com:

  • nome completo

  • foto

  • boletim escolar

  • causa da morte

  • depoimentos

  • linha do tempo

  • relatório de incidentes

😂


E uma senhora aposentada apareceria no episódio 7 dizendo:

"Eu estudei com ele..."

Pronto.

Eu teria chorado mais nessa cena do que em metade das mortes do anime.


VEREDITO FINAL DO OPERADOR

Sua observação é extremamente válida.

Porque em comunidades reais:

  • escolas

  • cidades pequenas

  • bairros

  • empresas

eventos traumáticos geram memória.

Muita memória.

Às vezes até memória demais.

A lenda da Loira do Banheiro sobrevive justamente porque cada geração acrescenta novos detalhes.

Já em Another acontece o oposto.

A origem da maior tragédia da cidade permanece surpreendentemente vaga.

Isso ajuda a construir o mistério.

Mas também contribui para aquele sentimento que você vem descrevendo desde o final do anime:

"Faltam peças nesse quebra-cabeça."

☕💣👁️

E talvez seja por isso que, dias depois, você continua investigando Another como um operador analisando logs antigos:

JOB: MALDICAO33

STATUS:
ENCERRADO

LOGS DISPONÍVEIS:
PARCIAIS

DOCUMENTAÇÃO:
INCOMPLETA

OPERADOR:
AINDA INVESTIGANDO

Porque a maior anomalia da série talvez não seja a maldição.

Talvez seja a quantidade de informações que deveriam existir... mas desapareceram junto com ela. 👁️📂☂️💀


domingo, 2 de maio de 2021

☕💣🚀 PADAWAN, O ZUNIT É O MOMENTO EM QUE O MAINFRAME APRENDEU A DESCONFIAR DOS PROGRAMADORES!

 

Bellacosa Mainframe e o zunit testes unitarios em ibm mainframe 

☕💣🚀 PADAWAN, O ZUNIT É O MOMENTO EM QUE O MAINFRAME APRENDEU A DESCONFIAR DOS PROGRAMADORES!

Durante décadas, o desenvolvedor COBOL vivia numa realidade curiosa.

Ele alterava um programa de 30.000 linhas.

Compilava.

Executava.

Rezava.

Se nada explodisse em produção, considerava um sucesso.

Foi assim em milhares de empresas durante mais de 50 anos.

Então surgiu uma pergunta perigosa:

"E se o COBOL pudesse ser testado automaticamente antes de chegar à produção?"

Foi dessa necessidade que nasceu o IBM ZUnit.

Uma das tecnologias mais subestimadas do ecossistema z/OS moderno.


O QUE É O ZUNIT?

O IBM ZUnit é um framework de testes unitários para aplicações desenvolvidas no ambiente IBM Z.

Seu objetivo é simples:

  • testar programas COBOL

  • testar programas PL/I

  • validar regras de negócio

  • automatizar regressões

  • integrar testes ao DevOps

Antes do ZUnit:

Alteração
↓
Compilação
↓
Execução Manual
↓
Análise de Resultado
↓
Torcer para funcionar

Com ZUnit:

Alteração
↓
Compilação
↓
Execução Automática
↓
Validação Automática
↓
Relatório
↓
Deploy

É a filosofia do:

"Confiar é bom. Testar é melhor."


HISTÓRIA

Até meados dos anos 2000, o conceito de testes automatizados era dominado pelo mundo Java.

Existiam:

  • JUnit

  • NUnit

  • xUnit

Enquanto isso, no mainframe:

TESTE = EXECUTAR O JOB

A IBM percebeu que isso não era sustentável.

O crescimento de:

  • DevOps

  • Agile

  • CI/CD

exigia automação.

Então nasceu o projeto que mais tarde se tornaria:

IBM ZUnit Test Framework

integrado ao ambiente de desenvolvimento IBM.


DATA DE LANÇAMENTO

O ZUnit apareceu inicialmente integrado ao:

IBM Rational Developer for System z (RDz)

por volta de:

2014–2015

Posteriormente evoluiu para:

IBM Developer for z/OS (IDz)

onde continua sendo desenvolvido.

Atualmente faz parte do ecossistema:

  • IBM Developer for z/OS

  • IBM Dependency Based Build

  • IBM Wazi

  • IBM DevOps for Z


A GRANDE IDEIA

Imagine um programa COBOL:

CALCULA-DESCONTO.

Entrada:

VALOR = 1000

Saída esperada:

DESCONTO = 100

O ZUnit permite registrar:

Entrada
↓
Execução
↓
Saída Esperada

e repetir esse teste automaticamente milhares de vezes.


FILOSOFIA DO TESTE UNITÁRIO

Padawan...

O teste unitário não verifica o sistema inteiro.

Ele verifica uma unidade.

Normalmente:

Programa COBOL
ou
Subprograma COBOL

Exemplo:

CALCJUROS

Recebe:

VALOR
TAXA
PRAZO

Retorna:

JUROS

O ZUnit verifica apenas essa lógica.


COMO FUNCIONA

O framework captura:

INPUT

Parâmetros
Arquivos
Áreas de memória

PROCESSAMENTO

Executa o programa.

OUTPUT

Compara com resultado esperado.


ARQUITETURA

IDz
 │
 │
 ▼
 Test Case
 │
 ▼
 Test Runner
 │
 ▼
 Programa COBOL
 │
 ▼
 Resultado
 │
 ▼
 Relatório

COMPONENTES PRINCIPAIS

Test Case

Define:

Dados de Entrada

Test Scenario

Conjunto de testes.

Exemplo:

Cliente VIP
Cliente Normal
Cliente Inadimplente

Test Runner

Executa automaticamente.


Assertions

Comparam resultados.

Exemplo:

Esperado = 100
Obtido = 100

PASSOU.


INSTALAÇÃO

Normalmente o ZUnit não é instalado isoladamente.

Ele vem integrado ao:

IBM Developer for z/OS

IBM Developer for z/OS

Componentes comuns:

z/OS
IDz
JES
ISPF
COBOL Compiler
ZUnit Runtime

PRÉ-REQUISITOS

Geralmente:

  • Enterprise COBOL

  • z/OS

  • IDz

  • USS configurado

  • JES ativo

Em ambientes corporativos:

LPAR DEV
LPAR QA

normalmente já possuem tudo configurado.


EXEMPLO PRÁTICO

Programa

IDENTIFICATION DIVISION.
PROGRAM-ID. SOMA.

WORKING-STORAGE SECTION.

01 NUM1 PIC 9(4).
01 NUM2 PIC 9(4).
01 RESULTADO PIC 9(5).

PROCEDURE DIVISION.

ADD NUM1 TO NUM2
GIVING RESULTADO.

GOBACK.

CRIANDO O TESTE

No IDz:

File
 ↓
 New
 ↓
 ZUnit Test Case

Selecionar:

Programa SOMA

Definir:

NUM1 = 10
NUM2 = 20

Resultado esperado:

30

EXECUÇÃO

Runner executa:

SOMA

Obtém:

30

Compara:

Esperado = 30
Obtido = 30

Resultado:

PASS

EXEMPLO DE FALHA

Esperado:

30

Obtido:

31

Relatório:

FAIL

com indicação do campo divergente.


TESTANDO CENTENAS DE CENÁRIOS

Padawan...

Aqui está o verdadeiro poder.

Você cria:

0 + 0
10 + 20
9999 + 1
5000 + 5000

Tudo executado automaticamente.

Em segundos.


TESTANDO PROGRAMAS CICS

O ZUnit consegue testar componentes que normalmente seriam executados sob CICS.

Exemplo:

EXEC CICS LINK

Através de stubs e ambientes controlados.

Isso reduz enormemente o tempo de validação.


TESTANDO DB2

Também é possível criar cenários envolvendo:

SELECT
INSERT
UPDATE
DELETE

utilizando ambientes isolados.


MOCKS E STUBS

Conceito muito usado no mundo distribuído.

Exemplo:

Programa chama:

CONSULTA-CLIENTE

Mas o programa real não existe no ambiente.

Criamos um:

Stub

que responde:

CLIENTE VÁLIDO

Assim o teste continua funcionando.


INTEGRAÇÃO COM DEVOPS

O ZUnit tornou-se peça importante do pipeline moderno.

Fluxo:

Git
 ↓
Build
 ↓
Compilação COBOL
 ↓
ZUnit
 ↓
Deploy

Se um teste falhar:

Deploy Bloqueado

BENEFÍCIOS REAIS

Menos regressões

Alterou um cálculo?

Execute 500 testes.


Mais confiança

Mudanças menores tornam-se seguras.


Documentação viva

Os testes mostram como o programa deveria funcionar.


Onboarding

Novo desenvolvedor entende rapidamente a lógica.


CURIOSIDADES

Curiosidade 1

Muitos sistemas COBOL possuem mais de:

20 milhões de linhas

Sem testes automatizados.


Curiosidade 2

Alguns bancos executam milhares de testes ZUnit por dia.

Antes mesmo do primeiro usuário acessar o sistema.


Curiosidade 3

Em muitos projetos, o maior esforço não é criar o teste.

É descobrir qual deveria ser o resultado correto.


Curiosidade 4

A adoção do ZUnit foi impulsionada pelo movimento:

Shift Left Testing

Testar mais cedo.

Corrigir mais barato.


DICAS DE MESTRE JEDI MAINFRAME

Não teste programas gigantes primeiro

Comece pelos módulos menores.


Teste regras de negócio

Prioridade:

Cálculos
Tarifas
Juros
Impostos
Limites

Automatize regressões

Todo defeito corrigido deve virar um teste.


Integre com Git

Cada commit deve executar testes.


Pense como um auditor

Pergunta:

"Como provo que este cálculo continua correto após a alteração?"

Se o ZUnit responde essa pergunta, você está usando a ferramenta corretamente.


O VERDADEIRO SIGNIFICADO DO ZUNIT

Padawan...

O ZUnit não foi criado para testar COBOL.

Ele foi criado para proteger conhecimento corporativo acumulado durante décadas.

Quando um banco possui um programa escrito em 1987, alterado por 200 pessoas diferentes ao longo de 40 anos, o risco não está na compilação.

O risco está em quebrar silenciosamente uma regra de negócio que movimenta milhões de reais por dia.

O ZUnit é a resposta moderna para um problema antigo:

"Como mudar um sistema legado sem destruir aquilo que o tornou valioso?"

E é justamente por isso que muitos arquitetos consideram o ZUnit uma das tecnologias mais importantes da modernização do IBM Z: não porque ele substitui o COBOL, mas porque permite evoluí-lo com segurança. ☕💣🚀


sábado, 1 de maio de 2021

💀🔥 “Seu RACF está seguro… ou você só acha?”

 

Bellacosa Mainframe alerta sobre riscos no racf mal configurado

💀🔥 “Seu RACF está seguro… ou você só acha?”

🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)

“RACF não falha…
quem falha é quem confia demais nele.”


🧠 📜 Contexto histórico (o começo de tudo)

O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).

👉 Naquela época:

  • segurança era controle de acesso
  • hoje é sobrevivência digital

💡 Curiosidade:

RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.


💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO


🧨 1. *PUBLIC — o vilão silencioso

👉 Procure:

// quem tem acesso aberto?
RLIST DATASET * AUTHUSER(*)

💥 Red flag:

  • datasets críticos com:
ID(*PUBLIC) ACCESS(READ ou UPDATE)

🔥 Insight Bellacosa:

80% das falhas começam aqui.


🧠 2. Usuários com SPECIAL / OPERATIONS

👉 Liste:

SEARCH CLASS(USER) MASK(*) SPECIAL

💥 Risco:

  • acesso total ao RACF

🎯 Dica senior:

  • separar:
    • ADMIN ≠ AUDITOR

⚙️ 3. Grupos com autoridade excessiva

👉 Verifique:

LISTGRP * OMVS

💥 Problema:

  • grupo herdando privilégio indevido

🔥 Easter egg:

Um grupo mal configurado é pior que um usuário root.


🧬 4. Programas APF e AC=1

👉 Verifique APF:

D PROG,APF

💥 Risco:

  • execução em modo supervisor

🎯 Ataque clássico:

  • inserir loadlib malicioso

🔐 5. Password Policy (o calcanhar de aquiles)

👉 Cheque:

SETROPTS LIST

💥 Problemas comuns:

  • senha simples
  • sem expiração
  • sem history

🔥 Curiosidade:

Já vi banco com senha “123456” em ambiente produtivo.


🌐 6. FACILITY class (o “backdoor oficial”)

👉 Verifique:

RLIST FACILITY *

💥 Risco:

  • permissões ocultas

🎯 Exemplo crítico:

  • BPX.* (Unix System Services)

🧑‍💻 7. USS (Unix no mainframe = Linux feelings)

👉 Verifique:

LISTUSER USER OMVS

💥 Risco:

  • UID 0 (root)

🔥 Insight:

USS é o ponto favorito de pivot de atacante moderno.


🧾 8. Logging / SMF (sem isso você está cego)

👉 Cheque:

  • SMF 80 (RACF)
  • SMF 30 (jobs)

💥 Problema:

  • logs incompletos

🎯 Dica:

  • integrar com SIEM

🧠 9. Started Tasks (STC) — privilégio invisível

👉 Verifique:

RLIST STARTED *

💥 Risco:

  • tarefas com privilégios elevados

🔥 Easter egg:

STC mal protegido = root invisível rodando 24x7


🔗 10. Integrações externas (o novo campo de batalha)

👉 Verifique:

  • CICS
  • z/OS Connect

💥 Risco:

  • acesso indireto ao core

🎯 Realidade:

O ataque não entra pelo mainframe… entra pela API.


💀🔥 CHECKLIST RÁPIDO (modo auditor)

✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras


🧠💣 Fluxo real de ataque (pra abrir a mente)

  1. credencial fraca
  2. acesso TSO/FTP
  3. enumeração RACF
  4. exploração (APF / FACILITY / USS)
  5. persistência
  6. exfiltração

🧬 Easter Eggs que só senior percebe

💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe


🏦 Realidade nível banco

👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo


🔥 Frase final estilo Bellacosa

“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”

 

sexta-feira, 30 de abril de 2021

🧠 COBOL + Redes Neurais no IBM Mainframe

 



🧠 COBOL + Redes Neurais no IBM Mainframe

Dá pra fazer? Deve-se fazer? Quando faz sentido?

❌ O que NÃO faz sentido (sem romantizar)

COBOL foi criado para:

  • Processamento transacional

  • Lógica determinística

  • Alta confiabilidade

  • Baixo erro

  • Cálculo financeiro exato

  • Batch e OLTP

Redes neurais exigem:

  • Álgebra linear pesada

  • Matrizes gigantes

  • Operações vetoriais

  • Floating point intensivo

  • GPUs / TPUs

  • Bibliotecas como TensorFlow, PyTorch, JAX

👉 COBOL não tem:

  • Tipos numéricos adequados para ML moderno

  • Bibliotecas matemáticas otimizadas

  • Ecossistema científico

  • Performance vetorial competitiva

Criar uma rede neural em COBOL seria como usar um martelo para fazer microcirurgia.

É possível teoricamente?
Sim.

É profissionalmente aceitável?
Não.


⚠️ O erro clássico do padawan

“Mas o mainframe é poderoso, tem muita CPU, então dá pra rodar IA nele!”

Poder computacional ≠ arquitetura adequada.

Mainframe é otimizado para:

  • Throughput transacional

  • I/O previsível

  • CPU serial eficiente

  • Custos controlados por MIPS

IA moderna é:

  • Explosão de ponto flutuante

  • Paralelismo massivo

  • GPUs

  • Custo computacional brutal

👉 Rodar treino de rede neural em z/OS = queimar MIPS e dinheiro 🔥


✅ Onde o Mainframe ENTRA de forma inteligente

Agora vem a parte que ninguém do hype explica direito.

🧩 Arquitetura moderna REAL (usada por bancos e seguradoras)

[ Mobile / Web ] | v [ API / Microservices ] | v [ IA / ML (Python, GPUs, Cloud) ] | v [ Mainframe COBOL (CICS / Batch) ]

🎯 Papel do COBOL:

  • Fornecer dados confiáveis

  • Executar regras críticas

  • Tomar decisões finais

  • Persistir resultados

  • Garantir consistência financeira

🎯 Papel da IA:

  • Classificar

  • Prever

  • Detectar padrões

  • Score de risco

  • Fraude

  • Recomendação

A IA sugere.
O COBOL decide e executa.


🧠 Exemplo realista

💳 Detecção de fraude bancária

  1. Transação entra no CICS

  2. COBOL chama API de IA

  3. Modelo retorna score (ex: 0.87 risco)

  4. COBOL aplica regras:

    • Limite?

    • Cliente VIP?

    • Horário?

  5. COBOL aprova, nega ou solicita validação

➡️ COBOL governa
➡️ IA auxilia


🧪 “Mas posso rodar IA no próprio mainframe?”

⚠️ Com MUITAS ressalvas

Possibilidades existentes:

  • Linux on Z

  • Containers no zCX

  • Python rodando no Linux on Z

  • Inferência simples (não treino)

Mesmo assim:

  • ❌ Treinar modelos grandes → NÃO

  • ⚠️ Inferência pequena → talvez

  • 💰 Custo ainda alto comparado à cloud GPU

Mainframe não é substituto de GPU.


🧙 Easter-eggs de veterano

  • COBOL é determinístico; IA é probabilística

  • Reguladores confiam mais em COBOL do que em redes neurais “caixa-preta”

  • Muitos bancos exigem:

    • IA para análise

    • COBOL para decisão final

  • Explicabilidade (XAI) ainda é fraca — COBOL reina nisso


🛣️ Caminho correto para o dev padawan

Se você é dev e quer unir Mainframe + IA, faça assim:

🥋 Stack recomendada

  • COBOL + CICS / Batch

  • APIs REST

  • Python (ML)

  • Kafka / MQ

  • DB2 / VSAM

  • Cloud híbrida

📚 Aprenda:

  • Como o COBOL expõe serviços

  • Como consumir APIs externas

  • Como versionar modelos

  • Como validar decisões automatizadas

  • Como não estourar MIPS 😈


🧠 Resposta final (sem rodeio)

PerguntaResposta
Criar rede neural em COBOL?❌ Não faz sentido
Usar mainframe em soluções com IA?✅ Sim
COBOL como motor de decisão?✅ Absolutamente
Treinar ML no z/OS?❌ Financeiramente suicida
Arquitetura híbrida?🔥 Caminho real

☕ Palavra final do El Jefe

IA sem governança é risco.
COBOL sem IA perde competitividade.
Juntos, cada um no seu lugar, eles mandam no jogo.

Mainframe não é cérebro artificial.
É coluna vertebral.

E coluna não pensa —
ela sustenta tudo.