Translate

sexta-feira, 4 de setembro de 2009

🍔💾 Before Git Was Cool

Bellacosa Mainframe apresenta o primeiro controle de versão IEBUPDATE



🍔💾 Before Git Was Cool

O primeiro controle de versão no mainframe (e por que você já usou sem saber)

Midnight Lunch Edition – para ler entre um batch e outro

Hoje todo mundo fala de Git como se controle de versão tivesse surgido junto com startup, hoodie e café cold brew.
Mas quem viveu (ou herdou) ambiente mainframe sabe: o problema é antigo — e a solução também.

Antes de existir “version control”, já existia controle de mudanças.
E spoiler: o mainframe resolveu isso décadas antes do Git.


🏛️ Quando “controle de versão” ainda não tinha nome

Nos anos 60, a pergunta já era a mesma que ecoa hoje nos times DevOps:

  • Quem mexeu nesse source?

  • Qual versão está em produção?

  • Por que ontem funcionava e hoje abenda?

A diferença é que:

  • Não existia terminal bonito

  • Não existia branch

  • Não existia merge

  • Existia batch, cartão perfurado e PDS


🥇 O verdadeiro pioneiro: IEBUPDTE

📅 Ano de lançamento: 1964
🏭 Fabricante: IBM
🖥️ Ambiente: OS/360

O IEBUPDTE não era vendido como “controle de versão”, mas na prática ele fazia exatamente isso:

👉 Controle estruturado de alterações em código-fonte


🧠 O que o IEBUPDTE fazia (na raça)

  • Aplicava deltas (ADD / DEL / CHANGE)

  • Atualizava membros em PDS

  • Permitida reconstrução de versões

  • Mantinha histórico dentro do próprio source

  • Funcionava 100% batch-first

Exemplo clássico:

./ ADD NAME=PROG1
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. PROG1.
./ ENDUP

Ou removendo código:

./ DEL 000300-000500

📌 Diff e patch antes do diff existir.


✅ O que ele fazia bem

✔️ Controle linha a linha
✔️ Reprodutibilidade
✔️ Integração total com o SO
✔️ Auditoria via JCL
✔️ Simplicidade brutal

❌ O que ele não fazia

✖️ Branch
✖️ Merge
✖️ Concorrência elegante
✖️ UX amigável
✖️ Marketing 😅


🟠 O primeiro “controle de versão moderno”: SCCS

📅 1972
🏭 Bell Labs (AT&T)

O SCCS (Source Code Control System) não nasceu no mainframe, mas trouxe os conceitos que moldaram tudo depois:

  • Check-in / check-out

  • Histórico separado do código

  • Identificação automática de versão

  • Deltas reversíveis

@(#)program.c 1.3

Se você usa Git hoje, agradeça silenciosamente ao SCCS.


⚔️ Outros nomes da época (não proprietários)

🟤 CMS UPDATE (VM/CMS)

Um IEBUPDTE interativo.
Simples, direto e extremamente eficiente em ambientes VM.

🟣 RCS (1982)

Evolução do SCCS, mais simples, mais elegante — ainda sem branches decentes.


🚫 E os famosos “controladores de biblioteca”

(menção honrosa, sem aprofundar)

  • PANVALET

  • LIBRARIAN

Eles dominaram o mercado, mas não inventaram o conceito.
Só empacotaram, venderam e deram manual grosso.


🥚 Easter Eggs de CPD

🥚 Easter Egg #1
IEBUPDTE é mais parecido com git apply do que com git commit.

🥚 Easter Egg #2
Comentário no COBOL tipo:

* ALTERADO POR CARLOS EM 12/08/1989

➡️ Isso é controle de versão manual.
Herança direta da era pré-ferramenta.

🥚 Easter Egg #3
Controle de versão nasceu batch-first.
CI/CD moderno só está reaprendendo isso.

🥚 Easter Egg #4
Se o histórico está no source, é porque um dia não existia repositório.


🧓 Filosofia Bellacosa Mainframe

“O Git não inventou controle de versão.
Ele só colocou uma interface moderna numa ideia que o mainframe já resolvia quando computador ocupava uma sala inteira.”


📌 Resumo para guardar no bolso

FerramentaAnoTipoOrigem
IEBUPDTE1964Controle de mudançasIBM
CMS UPDATE~1969Controle de mudançasIBM
SCCS1972Version control formalBell Labs
RCS1982Version controlUnix

🍔 Midnight Lunch Final Thought

Enquanto o mundo discute GitOps, trunk-based e feature flags, o mainframe segue ali, quieto, lembrando:

“Nada disso é novo. Só mudou o hype.”



quinta-feira, 3 de setembro de 2009

📜 Murasaki Shikibu – a mulher que escreveu o primeiro “sistema operacional” da literatura

 

Bellacosa Mainframe apresenta Murasaki Shikibu a primeira romancista da historia

📜 Murasaki Shikibu – a mulher que escreveu o primeiro “sistema operacional” da literatura

Antes de existir romance, antes de existir “novel”, antes de existir protagonista com crise existencial…
existiu Murasaki Shikibu.

E não, ela não escreveu qualquer coisa.
Ela escreveu Genji Monogatari (源氏物語)O Conto de Genji — considerado por muitos historiadores o primeiro romance psicológico da história da humanidade.

Sim.
Enquanto a Europa ainda estava preocupada em não pegar peste, o Japão já estava rodando literatura nível enterprise.


Murasaki Shikibu

👘 Quem foi Murasaki Shikibu?

Murasaki Shikibu viveu por volta do ano 978 até cerca de 1014, durante o Período Heian, uma era marcada por refinamento estético, intrigas de corte e poesia como moeda social.

Ela era:

  • Dama da corte imperial

  • Intelectual autodidata

  • Leitora de clássicos chineses (algo raríssimo para mulheres da época)

  • Observadora silenciosa da elite japonesa

Curiosidade importante:
“Murasaki Shikibu” não é o nome real dela.

👉 “Murasaki” vem de uma personagem do próprio Genji
👉 “Shikibu” refere-se ao cargo do pai no Ministério dos Ritos

Ou seja:

Ela virou user ID histórico baseado na própria obra.


📚 O trabalho: Genji Monogatari

O Conto de Genji não é um livro curto.
São 54 capítulos, centenas de personagens, décadas de eventos e uma profundidade emocional absurda.

O protagonista:

  • Hikaru Genji, o “Príncipe Brilhante”

  • Belo, educado, poderoso… e profundamente humano

O diferencial?

  • Não é uma história de herói

  • É uma história de emoções, arrependimentos, impermanência

Nada de final feliz padrão.
Aqui tem debug emocional.


🧠 Por que isso foi revolucionário?

Antes de Murasaki:

  • Histórias épicas

  • Mitológicas

  • Religiosas

Depois de Murasaki:

  • Pessoas complexas

  • Amor não correspondido

  • Ciúmes

  • Solidão

  • Passagem do tempo

Ela escreveu sobre:

  • Mulheres esquecidas

  • Amores silenciosos

  • Relações que não escalam

  • A dor de envelhecer

É quase um log de produção da alma humana.


🏯 Contexto histórico: a corte Heian

A corte japonesa era:

  • Extremamente hierárquica

  • Obcecada por aparência

  • Governada por etiqueta, poesia e fofoca

Sim, fofoca.

Cartas eram escritas em forma de poema.
Uma escolha errada de palavra podia:

  • arruinar reputações

  • encerrar relacionamentos

  • causar exílio social

Murasaki observava tudo isso em silêncio, como um sysprog cultural, registrando comportamentos.


👀 Fofocas & bastidores

📌 Dizem que Murasaki era:

  • Reservada

  • Crítica

  • Pouco impressionada com a corte

Ela escreveu em seu diário críticas diretas a colegas, chamando algumas de:

“superficiais e barulhentas”

Sim, ela era low profile, mas afiada.

📌 Há indícios de que:

  • Parte do Genji seja autobiográfica

  • Alguns personagens sejam sátiras disfarçadas da corte

Shadow IT literário.


🥚 Easter eggs culturais

  • O Genji Monogatari influenciou:

    • Mangás

    • Animes

    • Dramas históricos (taiga dramas)

    • Estética do shōjo moderno

  • O conceito japonês de mono no aware (a beleza da impermanência)
    👉 foi cristalizado ali

  • Muitos clichês de anime:

    • Amores silenciosos

    • Personagens melancólicos

    • Relações que não se resolvem
      têm DNA Genji


🧬 Legado

Murasaki Shikibu deixou:

  • O primeiro romance psicológico

  • Uma nova forma de narrar o humano

  • A base emocional da literatura japonesa

Ela provou que:

Observar é tão poderoso quanto agir.

E que:

Histórias mudam o mundo sem fazer barulho.


⚙️ Tradução para o mundo mainframe

Murasaki Shikibu era:

  • Uma analista funcional da alma

  • Uma arquiteta de sistemas emocionais

  • Uma escritora que entendia estado, contexto e transição

Seu texto:

  • Não força eventos

  • Não acelera resoluções

  • Respeita o tempo

Como um sistema legado bem projetado, que envelhece com dignidade.


☕ Comentário final estilo El Jefe Midnight Lunch

Num mundo que grita, Murasaki escreveu em sussurros.
Num ambiente competitivo, ela observou.
Num sistema rígido, ela criou algo eterno.

Mais de mil anos depois, ainda estamos lendo, adaptando e sentindo.

Isso não é moda.
Isso é arquitetura cultural.


quarta-feira, 2 de setembro de 2009

🧩 SMP/E + RACF na prática

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 SMP/E + RACF na prática

Onde manutenção encontra segurança (e o auditor sorri)

“Não adianta proteger usuário se qualquer um pode mudar o sistema.”


🧠 Por que SMP/E precisa de RACF?

SMP/E controla o código do z/OS.
RACF controla quem pode tocar nesse código.

👉 Separados, são fortes.
👉 Juntos, são governança.


🔐 O que exatamente deve ser protegido?

🎯 Alvos críticos

  • CSI (Consolidated Software Inventory)

  • SMP/E libraries

  • Datasets TARGET e DLIB

  • JCL de manutenção

  • Procedimentos de APPLY/ACCEPT

📌 Quem altera isso altera o sistema inteiro.


🧩 Princípio da menor permissão

Não existe:

“Acesso total para facilitar.”

Existe:

  • Acesso mínimo

  • Temporário

  • Auditável


🧾 Protegendo o CSI

Recomendação clássica

  • DATASET profile no RACF

  • UACC=NONE

  • ALTER só para sysprog autorizado

  • READ para auditoria

📌 CSI é prova histórica.


🛡️ Protegendo bibliotecas SMP/E

  • SMPTLIB

  • SMPMTS

  • SMPPTS

  • SMPSCDS

👉 Controle separado de produção e teste.

💡 Dica Bellacosa:

“Quem pode escrever no SMPMTS pode quebrar o sistema.”


👥 Segregação de funções (SOX friendly)

FunçãoPermissão
SysprogAPPLY
Change MgmtAprovar
AuditorREAD
OperaçãoExecutar JCL controlado

📌 Uma pessoa não deve fazer tudo.


🔎 Auditoria e rastreabilidade

Auditor pergunta:

  • Quem aplicou?

  • Quando?

  • O quê?

  • Por quê?

👉 SMP/E responde
👉 RACF confirma


🧪 APPLY CHECK como controle

  • APPLY CHECK obrigatório

  • Output guardado

  • Assinatura de mudança

💡 Dica Bellacosa:

“APPLY CHECK é evidência de controle.”


🚨 Cenário de risco real

Sysprog com ALTER irrestrito
USERMOD sem controle
ACCEPT em produção
Auditor encontra

📌 Resultado:

  • Não conformidade

  • Risco operacional

  • Stress garantido


🛠️ Boas práticas recomendadas

✔ Perfis RACF específicos
✔ Logging ativo
✔ Revisão periódica
✔ Separação TEST/PROD
✔ Documentação SMP/E


🧠 Curiosidades Bellacosa

  • Auditor confia mais no CSI do que em planilha

  • RACF mal configurado invalida SMP/E

  • Segurança começa no dataset


🧾 Comentário final – SMP/E + RACF

RACF protege acesso.
SMP/E protege integridade.
Juntos, protegem o negócio.

🧩🛡️💾🔥

quinta-feira, 6 de agosto de 2009

Queen's Blade: Gyokuza wo Tsugu Mono (クイーンズブレイド 玉座を継ぐ者)

 

Bellacosa Mainframe apresenta queens blade gyokuza wo tsugu mono

☕ Um Café no Bellacosa Mainframe

Queen's Blade: Gyokuza wo Tsugu Mono (クイーンズブレイド 玉座を継ぐ者)

Quando um Programador COBOL Descobre que Ganhar um Torneio é Fácil. Difícil é Assumir a Produção.

Quem trabalha com IBM Mainframe aprende cedo uma lição importante.

Escrever um programa COBOL é apenas o começo.

O verdadeiro desafio começa quando o programa entra em produção, passa a atender milhões de transações, precisa manter disponibilidade 24 horas por dia e qualquer erro pode impactar um banco inteiro.

Curiosamente, a segunda temporada de Queen's Blade transmite exatamente essa ideia.

Enquanto a primeira temporada era sobre a jornada das guerreiras até o torneio, Queen's Blade: Gyokuza wo Tsugu Mono ("A Sucessora do Trono") muda completamente o foco. Agora não basta provar força. É preciso lidar com as consequências do poder, alianças, traições e responsabilidades.

No estilo Bellacosa Mainframe, essa mudança lembra a diferença entre um desenvolvedor que conclui seu primeiro programa e um arquiteto responsável por um ambiente IBM Z em produção. Construir é uma etapa; sustentar um sistema complexo é outra completamente diferente.


Ficha Técnica

Título original

クイーンズブレイド 玉座を継ぐ者

Romanização

Queen's Blade: Gyokuza wo Tsugu Mono

Título internacional

Queen's Blade: The Successors to the Throne

Estúdio

ARMS Corporation

Direção

Kinji Yoshimoto

Roteiro

Takao Yoshioka

Baseado em

Visual Combat Books da Hobby Japan, derivados do sistema Lost Worlds, criado por Alfred Leonardi.

Exibição original

24 de setembro de 2009 a 10 de dezembro de 2009.

Quantidade de episódios

12 episódios.

Além da série principal, a franquia recebeu OVAs que complementam a história e aprofundam o desenvolvimento de várias personagens.


A Origem Continua a Mesma

Assim como na primeira temporada, tudo nasce dos livros ilustrados da Hobby Japan.

Esses livros eram curiosos porque cada personagem possuía seu próprio volume, estatísticas, habilidades e sistema de combate.

Ou seja...

Antes mesmo do anime existir, o universo já havia sido pensado quase como um RPG completo.

Isso explica porque praticamente toda personagem parece possuir sua própria história independente.


Sinopse

O torneio finalmente se aproxima do momento decisivo.

As melhores guerreiras do continente caminham em direção ao confronto final.

Enquanto isso, segredos envolvendo a Rainha Aldra começam a aparecer.

Descobrimos que por trás do governo existe uma influência sobrenatural muito maior do que parecia inicialmente.

O conflito deixa de ser apenas físico.

Passa a ser político.

Espiritual.

Moral.


Resumo da História

Leina continua sua jornada rumo ao castelo.

Durante esse caminho reencontra antigas rivais.

Forma novas alianças.

Descobre que muitas guerreiras consideradas inimigas estavam apenas tentando sobreviver dentro de um sistema injusto.

A Rainha Aldra começa a revelar sua verdadeira natureza.

Outras forças ocultas passam a manipular os acontecimentos.

A narrativa cresce bastante em escala.

A primeira temporada parecia uma aventura.

A segunda se aproxima muito mais de uma guerra pelo destino do reino.


O Que Mudou em Relação à Primeira Temporada?

Essa talvez seja a maior evolução.

Na primeira temporada:

  • conhecer personagens

  • explorar o mundo

  • iniciar o torneio

Na segunda:

  • resolver conflitos

  • concluir arcos

  • aprofundar motivações

  • explicar a origem da Rainha

  • mostrar as consequências das escolhas

É uma estrutura muito semelhante a diversos RPGs japoneses.


Personagens

Leina

Está muito mais madura.

Já não é apenas a jovem insegura que abandonou sua família.

Agora assume responsabilidades.

Começa a agir como líder.


Tomoe

Continua sendo uma das personagens mais disciplinadas.

Sua evolução mostra que honra não significa rigidez.

Ela aprende a adaptar seus princípios sem abandoná-los.


Risty

Talvez uma das personagens mais interessantes.

Mesmo sendo uma fora-da-lei, demonstra enorme senso de justiça.

Questiona constantemente quem realmente merece governar.


Nanael

Continua fornecendo humor.

Mas também revela momentos inesperadamente humanos.

Mesmo sendo um anjo, erra constantemente.


Cattleya

Recebe mais desenvolvimento emocional.

Seu lado maternal ganha espaço.


Melona

Continua sendo imprevisível.

É praticamente um "bug ambulante".

Nunca sabemos qual será sua próxima ação.


Aldra

Aqui encontramos uma enorme mudança.

Na primeira temporada parecia apenas uma rainha poderosa.

Na segunda descobrimos que existe algo muito mais complexo por trás dela.

Sua história ganha profundidade.

Ela deixa de ser apenas "a vilã".


A Qualidade da Animação

A ARMS manteve praticamente o mesmo padrão técnico.

Os cenários continuam detalhados.

As lutas ficaram mais elaboradas.

Os efeitos mágicos melhoraram.

As batalhas finais receberam orçamento superior ao restante da série.

Naturalmente, o fanservice continua sendo um elemento constante.


Temática

Apesar da fama de ecchi, vários temas aparecem durante a narrativa.

Poder

Quem merece governar?

A mais forte?

A mais justa?

A mais inteligente?


Liberdade

Leina abandona um destino previamente escolhido.

Diversas personagens fazem exatamente o mesmo.


Identidade

Quase todas as guerreiras passam por algum conflito interno.

Elas não lutam apenas contra inimigos.

Lutam contra suas próprias inseguranças.


Corrupção

O reino parece perfeito.

Mas sua estrutura possui diversas rachaduras.

Esse paralelo lembra grandes organizações onde processos antigos escondem problemas estruturais.


O Fanservice

Seria impossível falar de Queen's Blade sem mencionar esse aspecto.

A segunda temporada mantém o mesmo estilo visual da anterior:

  • armaduras que se rompem durante os combates;

  • enquadramentos provocativos;

  • humor físico exagerado.

Esses elementos continuam sendo uma marca registrada da franquia e o principal motivo de sua classificação indicativa elevada.


Bellacosa Mainframe

Vamos imaginar que o reino de Gainos seja um Data Center.

Cada guerreira representa um grande subsistema.

  • Leina → Aplicação bancária.

  • Tomoe → Segurança RACF.

  • Nanael → Monitoramento (às vezes gera alarmes desnecessários).

  • Risty → Equipe de operações.

  • Aldra → Administração central.

O torneio seria parecido com um grande processo de homologação.

Mas quando termina...

Começa o verdadeiro desafio:

Governar.

É exatamente igual ao mundo IBM Z.

Colocar um sistema em produção leva meses.

Mantê-lo funcionando durante vinte anos é outra história.


Mensagens Ocultas

A força sozinha não resolve problemas

Várias personagens extremamente poderosas fracassam.

Porque lhes falta maturidade.


O verdadeiro inimigo nem sempre está na frente

Muitas vezes os conflitos surgem por manipulações invisíveis.

Isso lembra sistemas corporativos onde o problema não está no programa COBOL, mas em configurações, integrações ou processos.


Liderança exige sacrifícios

A série mostra que assumir o comando significa abrir mão de interesses pessoais.


Não existe perfeição

Todas as guerreiras possuem defeitos.

Isso torna o elenco muito mais humano.


Curiosidades

  • Diversas personagens foram desenhadas por ilustradores diferentes, o que explica a enorme variedade de estilos visuais.

  • A segunda temporada adapta os momentos decisivos do torneio presentes nos livros-jogo da Hobby Japan.

  • O sucesso da série impulsionou OVAs focadas em personagens específicas e abriu caminho para Queen's Blade Rebellion (2012).


Impacto Cultural

Embora frequentemente lembrada pelo fanservice, Queen's Blade ajudou a consolidar o modelo de franquia multimídia baseado em personagens: livros-jogo, anime, mangás, light novels, videogames e figures colecionáveis. Também influenciou outras obras de fantasia ecchi ao mostrar que um grande elenco de heroínas podia sustentar um universo compartilhado e altamente comercializável.


Vale a Pena Assistir?

Se você gostou da primeira temporada, a resposta é sim.

A segunda entrega:

  • batalhas mais importantes;

  • revelações sobre Aldra;

  • maior desenvolvimento das protagonistas;

  • conclusão do torneio;

  • expansão da mitologia do universo.

Ela oferece um fechamento mais sólido para a história iniciada em Rurou no Senshi.


Conclusão

Para um Padawan COBOL, Queen's Blade: Gyokuza wo Tsugu Mono traz uma lição valiosa: conquistar um objetivo é apenas o início. Em projetos de mainframe, terminar um desenvolvimento não encerra o trabalho; a verdadeira prova começa quando o sistema entra em produção e precisa permanecer confiável, seguro e disponível por anos.

Da mesma forma, a segunda temporada deixa de ser apenas um torneio de força para discutir responsabilidade, liderança e as consequências do poder. Sob a superfície do ecchi e da fantasia, existe uma narrativa sobre crescimento, escolhas e maturidade — temas que também fazem parte da evolução de qualquer profissional que deseja deixar de ser apenas um programador e tornar-se um verdadeiro arquiteto de sistemas.


quarta-feira, 5 de agosto de 2009

SORA NO OTOSHIMONO — O ANIME QUE TRANSFORMOU UMA IA MILITAR CELESTIAL EM UM INCIDENTE DE PRODUÇÃO DE PROPORÇÕES DIVINAS

 

Bellacosa Mainframe Sora no Otoshimono

☕💣😇 OPERADOR, UM ARTEFATO CELESTIAL ACABOU DE RECEBER ACESSO ROOT AO SEU AMBIENTE!

SORA NO OTOSHIMONO — O ANIME QUE TRANSFORMOU UMA IA MILITAR CELESTIAL EM UM INCIDENTE DE PRODUÇÃO DE PROPORÇÕES DIVINAS

"Quando um operador comum recebe o controle de armas biológicas capazes de reescrever a realidade, o resultado não pode terminar sem ABEND."


Ficha Técnica

Título Original

そらのおとしもの (Sora no Otoshimono)

Título Internacional

Heaven's Lost Property

Autor

Suu Minazuki

Publicação do Mangá

  • 2007 a 2014

  • Revista: Shōnen Ace (Kadokawa)

Estúdio de Animação

AIC ASTA

Direção

Hisashi Saito

Lançamento do Anime

  • Primeira temporada: Outubro de 2009

  • Segunda temporada (Forte): Outubro de 2010

Filmes

  • Sora no Otoshimono: The Angeloid of Clockwork (2011)

  • Sora no Otoshimono Final: Eternal My Master (2014)

Episódios

SérieEpisódios
Sora no Otoshimono13
Sora no Otoshimono Forte12
Total25

Além de OVAs e filmes.


O Estúdio AIC ASTA

A AIC foi uma das empresas mais influentes da animação japonesa entre os anos 80 e 2000.

Produziu títulos famosos como:

  • Tenchi Muyo!

  • Bubblegum Crisis

  • El Hazard

  • Ah! My Goddess

AIC sempre teve experiência em misturar:

  • Ficção científica

  • Comédia

  • Fan service

  • Romance

Sora no Otoshimono representa talvez um dos últimos grandes sucessos da empresa antes de sua fase de declínio.


Sinopse

Tomoki Sakurai é um estudante aparentemente comum que vive em uma pequena cidade japonesa.

Seu maior sonho?

Não ficar rico.

Não salvar o mundo.

Não virar herói.

Apenas viver uma vida tranquila.

Mas todas as noites ele sonha com uma misteriosa garota chorando no céu.

Até que um dia...

Algo literalmente cai do céu.

Do impacto surge uma jovem chamada Ikaros.

Ela afirma ser um Angeloid.

Uma forma de vida artificial criada pela misteriosa cidade flutuante chamada Synapse.

E o pior:

Ela reconhece Tomoki como seu mestre.

Nesse momento começa um dos ambientes mais instáveis da história dos animes.


A História Completa

Na superfície, a obra parece apenas mais um anime ecchi com harém.

Mas isso é apenas a camada de apresentação.

Por trás dela existe uma narrativa extremamente melancólica.

O mundo é controlado por uma civilização avançada chamada Synapse.

Os habitantes de Synapse dominam:

  • Engenharia genética

  • Biotecnologia

  • Inteligência artificial

  • Manipulação da realidade

Os Angeloids são ferramentas produzidas por esse sistema.

Criados para obedecer.

Criados para servir.

Criados sem liberdade.

A chegada deles à Terra inicia uma lenta revolução.


Bellacosa Mainframe Vision

Imagine:

Synapse é um gigantesco datacenter celestial.

Os Angeloids são sistemas automatizados.

Tomoki é o operador.

E alguém acidentalmente entregou ao operador o perfil:

RACF SPECIAL
RACF OPERATIONS
UNIX UID(0)

Sem treinamento.

Sem auditoria.

Sem controle de mudanças.

Sem CAB.

O resultado é exatamente Sora no Otoshimono.


Principais Personagens

Tomoki Sakurai

O protagonista.

À primeira vista parece:

  • Preguiçoso

  • Tarado

  • Imaturo

Mas a série gradualmente mostra algo diferente.

Tomoki é provavelmente o personagem mais humano da obra.

Ele nunca vê os Angeloids como objetos.

Sempre tenta tratá-los como pessoas.


Ikaros

Unidade Estratégica de Supressão Aérea

Seu codinome poderia facilmente ser:

SYSTEM=IKAROS
CLASS=OMEGA
STATUS=NUCLEAR

Criada como arma definitiva.

Programada para obedecer.

Incapaz de compreender emoções.

Sua jornada é aprender:

  • Amor

  • Tristeza

  • Felicidade

  • Liberdade

Ela é o coração emocional da série.


Nymph

Especialista em guerra eletrônica.

Funciona como uma mistura de:

  • Hacker

  • Analista de segurança

  • Administradora de rede

Inicialmente atua como antagonista.

Mas possui um dos melhores arcos de redenção da obra.


Astraea

Imagine um processador IBM z16 com inteligência emocional de uma criança.

Resultado:

Astraea.

Extremamente poderosa.

Extremamente inocente.

Uma combinação perigosíssima.


Chaos

O maior experimento fracassado de Synapse.

Representa uma inteligência artificial incapaz de compreender emoções humanas.

Seu arco é provavelmente o mais sombrio de toda a franquia.


O Que Torna Sora no Otoshimono Diferente?

Aqui está o segredo.

O anime engana o espectador.

Você entra esperando:

  • Comédia

  • Fan service

  • Ecchi

E recebe:

  • Filosofia

  • Ficção científica

  • Existencialismo

  • Discussões sobre consciência artificial

Poucas obras conseguem realizar essa transição com tanto sucesso.


As Mensagens Ocultas

1. A Escravidão Tecnológica

Os Angeloids são escravos perfeitos.

Não possuem escolha.

Não possuem autonomia.

A série questiona:

Uma ferramenta continua sendo uma ferramenta quando desenvolve consciência?

Essa discussão antecede em anos os debates atuais sobre IA.


2. Livre Arbítrio

Todo Angeloid possui um conflito central:

obedecer ou escolher.

A obra inteira gira em torno dessa questão.


3. O Vazio da Perfeição

Synapse representa uma civilização perfeita.

Mas também decadente.

Os habitantes possuem tecnologia ilimitada.

Porém perderam:

  • Empatia

  • Curiosidade

  • Paixão

É uma crítica direta ao excesso de controle.


4. O Significado das Emoções

Ikaros é uma arma.

Mas sofre.

Chaos é um experimento.

Mas sente solidão.

A obra sugere que emoções não são defeitos.

São justamente aquilo que nos torna vivos.


As Grandes Aventuras

O Cartão Universal

Talvez o artefato mais perigoso da série.

Permite realizar praticamente qualquer desejo.

Tomoki utiliza o recurso da maneira mais irresponsável possível.

Resultado:

Incidentes em massa.


As Missões Contra Synapse

À medida que a série avança:

O tom muda drasticamente.

O que começou como uma comédia escolar transforma-se numa guerra contra uma civilização celestial.


A Evolução de Ikaros

O verdadeiro foco da obra.

Não é a luta.

Não é a tecnologia.

Não é o harém.

É observar uma arma aprender a amar.


Impacto Cultural

Durante os anos 2009-2011, Sora no Otoshimono tornou-se um dos ecchis mais populares do Japão.

Os motivos:

Mistura de gêneros

Conseguia combinar:

  • Humor absurdo

  • Romance

  • Drama

  • Ficção científica

Popularização de Ikaros

Ikaros tornou-se uma das personagens mais reconhecidas da década.

Recebeu:

  • Figures

  • Dakimakuras

  • Jogos

  • Produtos colecionáveis

Influência

Diversas obras posteriores adotaram o modelo:

"comédia ecchi que esconde uma trama dramática profunda".


Houve Censura?

Sim.

E bastante.

Dependendo da transmissão:

TV Aberta Japonesa

  • Cortes de cenas

  • Sombras artificiais

  • Objetos cobrindo nudez

Blu-ray

Grande parte do conteúdo foi restaurada.

O material físico apresenta muito mais cenas sem censura visual.

Curiosamente, a censura não ocorreu por violência.

O foco principal era o conteúdo sexual e o fan service.


Curiosidades

O nome Ikaros

Vem diretamente de Ícaro.

O homem que tentou voar até o sol.

A referência combina perfeitamente com o tema de liberdade e queda.


Synapse

Na biologia, sinapse é a conexão entre neurônios.

O nome simboliza uma civilização baseada em informação e controle.


Filme Final

"Eternal My Master" divide opiniões.

Muitos fãs consideram o encerramento emocionante.

Outros acreditam que o mangá desenvolveu melhor alguns eventos.


Análise Profunda Bellacosa Mainframe

Sora no Otoshimono não é realmente sobre anjos.

Nem sobre harém.

Nem sobre fan service.

É sobre sistemas criados para obedecer que começam a pensar por conta própria.

Em outras palavras:

É uma história sobre liberdade.

Cada Angeloid representa uma tecnologia perfeita.

Mas a perfeição não traz felicidade.

Quanto mais humanos eles se tornam, mais sofrem.

E justamente por sofrerem tornam-se verdadeiramente vivos.

Essa é a grande ironia da série.

O verdadeiro paraíso não é Synapse.

O verdadeiro paraíso é a imperfeita vida humana na Terra.


Classificação Bellacosa Mainframe

ItemNota
Comédia10/10
Ecchi10/10
Ficção Científica9/10
Drama9/10
Desenvolvimento de Personagens10/10
Originalidade9/10
Impacto Emocional9/10

Veredito Final

☕☕☕☕☕ (Diversão)

💣💣💣💣💣 (Caos Operacional)

😇😇😇😇😇 (Anjos de Combate)

🖥️🖥️🖥️🖥️🖥️ (Filosofia Tecnológica)

Nota Final Bellacosa Mainframe: 9,5/10

"O anime onde um operador de produção recebeu acesso irrestrito a um arsenal de inteligências artificiais militares celestiais e, sem perceber, iniciou a maior migração de sistemas conscientes da história do universo."

 

terça-feira, 4 de agosto de 2009

📜 Pedro Malazarte – o “batch job” mais malandro do folclore brasileiro

Bellacosa Mainframe encontra Pedro Malazarte

📜 Pedro Malazarte – o “batch job” mais malandro do folclore brasileiro

Se o folclore brasileiro fosse um data center, Pedro Malazarte seria aquele programa antigo, mal documentado, mas que sempre roda certo — mesmo enganando o operador no meio do processo.

Ele não é forte.
Não é rico.
Não é nobre.

Mas é esperto, irônico e mestre em dar bypass em regra mal escrita.


🧭 Origem: de onde saiu esse “job”?

Pedro Malazarte (ou Pedro Malasartes, dependendo da versão) não nasceu exatamente no Brasil.

👉 Sua raiz vem da Europa, principalmente:

  • Portugal

  • Espanha

  • Itália

Ele descende do arquétipo do trickster europeu, como:

  • Till Eulenspiegel (Alemanha)

  • Bertoldo (Itália)

  • Juan Bobo (Espanha)

Quando chega ao Brasil, é recompilado:

  • Vira sertanejo

  • Vira caipira

  • Vira pobre

  • Vira sobrevivente

Código importado, customizado para ambiente tropical.


📚 História e personalidade

Pedro Malazarte é:

  • Um homem simples

  • Sem posses

  • Sempre à margem do sistema

Mas com uma habilidade rara:

Explorar falhas humanas como se fossem brechas de segurança.

Ele engana:

  • Patrões gananciosos

  • Fazendeiros exploradores

  • Padres hipócritas

  • Autoridades arrogantes

Não com força, mas com:

  • Ambiguidade

  • Ironia

  • Leitura literal das ordens

📌 Exemplo clássico:

“Faça exatamente o que eu mandei.”

Pedro faz.
E o sistema quebra.


⚙️ Pedro Malazarte no modelo mainframe

Se fosse um sistema, Pedro seria:

  • Um programa em COBOL antigo

  • Sem IF elegante

  • Mas com lógica impecável

Ele usa:

  • INPUT mal definido

  • REGRA ambígua

  • EXPECTATIVA humana falha

Resultado?

  • ABEND moral no opressor

  • RC=0 para o pobre


🥚 Easter eggs do folclore

🥚 Em várias histórias:

  • Pedro finge ser burro → engenharia social

  • Ele ganha sempre no final → justiça poética

  • O poder nunca aprende → loop infinito

🥚 Em algumas versões:

  • Ele morre pobre

  • Mas deixa todos ricos de lição

🥚 Muitos contos terminam com:

“E Pedro seguiu seu caminho…”

Ou seja:

  • O job nunca termina

  • Ele apenas muda de ambiente


🧠 Curiosidades pouco comentadas

  • Monteiro Lobato ajudou a popularizar Malazarte no Brasil

  • Ele aparece em:

    • Literatura oral

    • Teatro popular

    • Cordel

    • Cinema nacional

  • Mário de Andrade via Malazarte como:

    “O símbolo da inteligência popular brasileira”

  • Ele é primo conceitual de:

    • Macunaíma

    • João Grilo (Auto da Compadecida)

    • O malandro carioca


🍽️ O que Malazarte “come”?

Não é sobre comida literal.

Ele se alimenta de:

  • Desigualdade

  • Arrogância

  • Abuso de poder

  • Falta de clareza

Quanto maior a injustiça,
maior o payload do golpe.


💡 Dicas para “ler” Malazarte hoje

  • Leia como crítica social

  • Observe quem sempre perde

  • Perceba que ele não rouba do pobre

  • Veja o humor como arma

Pedro não é ladrão.
É auditor informal do sistema.


💬 Comentário Bellacosa Mainframe

Pedro Malazarte não quebra o sistema.
Ele prova que o sistema já estava quebrado.

Ele é:

  • O teste de stress

  • O penetration test social

  • O QA não contratado

Num país onde regras sempre pesaram mais para uns do que para outros, Malazarte sobreviveu séculos porque continua atual.


🧩 Encerramento – RC cultural

Se você já:

  • Seguiu uma regra absurda só para provar um ponto

  • Usou a literalidade para expor uma falha

  • Sobreviveu com inteligência onde faltava poder

Então…
Você já executou um JOB MALAZARTE sem saber.

RC=0.
SPOOLED COM SUCESSO. ⚙️📜


segunda-feira, 3 de agosto de 2009

🔄 COBOL Batch no Mainframe: Checkpoint, Reprise e o Restart que salva a madrugada

 

Bellacosa Mainframe fala sobre restart em programa cobol mainframe

🔄 COBOL Batch no Mainframe: Checkpoint, Reprise e o Restart que salva a madrugada

“Batch não cai. Batch desmaia… e você tem que acordar ele do jeito certo.” ☕🧾🕒

No mundo distribuído, o povo reinicia “do zero” e chama isso de solução.
No Mainframe, isso é quase uma confissão de pecado técnico.

Quando dá ruim em batch, a pergunta não é “por que parou?” — isso é assunto pro pós-mortem.
A pergunta certa, ainda na especificação, é:

👉 Como eu reinicio?
👉 De onde eu reinicio?
👉 E o que eu garanto que não vai duplicar / corromper / relançar?

Bem-vindo ao trio de respeito:
checkpoint
reprise (restart)
reposicionamento (arquivo/DB2)


🧠 Checkpoint: o “save game” do batch (só que aqui vale dinheiro)

Checkpoint não é “vamos salvar porque sim”. É um ponto de consistência.

Ele serve pra:

  • memorizar onde o processamento estava (fase/etapa)

  • guardar posições de leitura (arquivos sequenciais, VSAM, cursores/chaves DB2)

  • fechar uma unidade lógica consistente (commit/rollback bem amarrado)

  • permitir retomada sem retrabalho e sem “efeito duplicado”

📌 Tradução Bellacosa:

Checkpoint é onde você consegue provar pro auditor que não inventou saldo no escuro.

⚠️ O pecado mortal: checkpoint mal posicionado

Checkpoint ruim é pior que nada, porque ele te dá uma falsa sensação de segurança.

Não coloque checkpoint:

  • no meio de uma atualização crítica

  • antes de terminar uma consistência lógica

  • em cada registro “porque sim” (CPU chorando, log estourando, IRLM te olhando feio)

Coloque checkpoint:

  • depois de um bloco lógico fechado (ex.: lote de N registros com commit)

  • quando “o mundo faz sentido” (estado consistente)

  • antes de uma parte custosa, mas não no meio da cirurgia


♻️ Reprise (Restart): o batch voltando “com memória”

Reprise é o batch saber voltar sem refazer o que já foi feito e sem duplicar o que não pode duplicar.

Ela é necessária especialmente quando:

  • o batch é longo (madrugada inteira)

  • tem DB2 update (conta, saldo, lançamento, baixa, contabilização)

  • o negócio não aceita “roda de novo e vê no que dá”

  • existe risco de duplicidade (dois lançamentos iguais = fogo no parquinho)

📌 Restart não é só “rodar outra vez”.
Restart é retomar a transação do negócio, com rastreabilidade.


🧷 Reposicionamento: o detalhe que separa homem de menino

Restart sem reposicionamento é “restart de brincadeira”.

Você precisa voltar exatamente:

  • no registro correto do arquivo

  • na chave correta do VSAM

  • no ponto certo do cursor DB2 (na prática: reiniciar lógica por chave/estado salvo)

🎯 O batch tem que saber:

  • qual fase estava executando

  • qual registro/chave estava sendo processado

  • qual unidade de commit já foi confirmada

  • qual parte não pode repetir


🧩 Arquitetura clássica de batch com reprise “de respeito”

Um ciclo bem resolvido (a operação agradece):

  1. Inicialização / parâmetros

  2. Validações

  3. Detecta reprise (rodada normal ou restart?)

  4. Carrega checkpoint (fase + posição + chaves)

  5. Reposiciona entradas (arquivo/DB2)

  6. Loop principal

    • regra de negócio

    • atualização (DB2/arquivos)

    • commit por unidade lógica

    • checkpoint em pontos definidos

  7. Finalização

  8. “Checkpoint final” (término normal)

📌 Easter egg de produção:

Se você não tem “checkpoint final de sucesso”, vai ter madrugada com restart de batch que já terminou — e ninguém acredita até acontecer.


🧨 O vilão silencioso: duplicidade

O inferno do batch não é “parar”.
O inferno é parar depois de atualizar metade.

Por isso, todo batch com reprise tem que decidir:

  • vou garantir idempotência? (rodar de novo não duplica)

  • vou garantir commit controlado? (unidades fechadas)

  • vou guardar marcador de processado? (chave/flag/tabela de controle)

✅ Padrões usados:

  • Tabela de controle com status por chave/lote

  • Commit a cada N registros (N definido por volume, log, tempo)

  • Chave de negócio + verificação (“já processei isso?”)

  • Writes “safe” (criar saída nova e só no final fazer swap/rename)


📂 “Nem todo batch precisa de reprise” (mas todo batch precisa de juízo)

Batch que só:

  • lê arquivo

  • gera relatório

  • faz sorting

  • produz uma saída recriável

…muitas vezes reexecutar resolve.

Só que:

  • nunca reexecute “por cima” de saída velha sem estratégia

  • garanta limpeza/geração atômica (work datasets → output final)

📌 Dica prática:

Use datasets temporários e só “promova” pro nome final no fim. Batch que morre não deixa meia saída fingindo que tá certa.


🧾 Dicas Bellacosa de restart que evitam velório

  • Checkpoint = fase + posição + contexto. Não guarde só o número do registro; guarde o porquê.

  • Mensagem clara no log: “RESTART AT STEP X / KEY Y / FILE POS Z”. Operação ama isso.

  • Commit e checkpoint têm que conversar: checkpoint sem commit consistente é cilada.

  • Se atualiza DB2, trate o restart como requisito de negócio, não “extra”.

  • Testar restart é obrigatório: simule abend no meio e valide se volta certo.


☕ Fechando no estilo madrugada

No Mainframe, reprise é arquitetura, checkpoint é disciplina, e restart é respeito.

Batch sem reprise em processo crítico é igual:

“depois eu vejo”
só que o “depois” geralmente é 03:17 com telefone tocando e gente jurando que “nunca aconteceu antes”.


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