Translate

quarta-feira, 10 de julho de 2024

Seirei Gensouki 2 : Quando o Passado Encontra o Presente — A Temporada em que o Isekai se Torna um Grande Jogo Político

 

Bellacosa Mainframe apresenta seirei gensouki 2

☕ Um Café no Bellacosa Mainframe

Seirei Gensouki 2 (精霊幻想記2)

Quando o Passado Encontra o Presente — A Temporada em que o Isekai se Torna um Grande Jogo Político

A primeira temporada de Seirei Gensouki apresentou Rio, suas origens e a curiosa fusão de sua consciência com as memórias de Haruto Amakawa. A segunda temporada abandona o ritmo de "apresentação" e amplia significativamente o universo da obra. O foco deixa de ser apenas a evolução individual do protagonista e passa a envolver política entre reinos, heróis invocados, antigas conspirações e reencontros emocionantes.

É também a temporada em que a narrativa demonstra que a série nunca foi apenas um isekai de aventura. O mundo criado por Yuri Kitayama torna-se mais complexo, revelando conexões entre diferentes personagens, interesses diplomáticos e mistérios ligados à própria natureza da reencarnação e da invocação de heróis.


Ficha Técnica

Título Original: 精霊幻想記2 (Seirei Gensōki 2)

Título Internacional: Seirei Gensouki: Spirit Chronicles Season 2

Autor da obra original: Yuri Kitayama

Ilustrações da Light Novel: Riv

Estúdio: TMS Entertainment (Studio 6) em colaboração com Wao World.

Direção: Osamu Yamasaki

Lançamento: 7 de outubro a 24 de dezembro de 2024.  


Quantidade de episódios

  • 12 episódios

Continua adaptando a light novel, cobrindo novos arcos e preparando terreno para conflitos ainda maiores.


Gênero

  • Isekai

  • Fantasia Medieval

  • Aventura

  • Magia

  • Drama

  • Romance

  • Política

  • Mistério

  • Ação

  • Harem (leve)


Classificação Indicativa

14 anos

Há batalhas, violência moderada e temas emocionais, mas o foco permanece na fantasia e no desenvolvimento dos personagens.


Sinopse

Após inúmeras viagens e batalhas, Rio começa finalmente a compreender seu verdadeiro papel naquele continente.

Ao mesmo tempo, pessoas importantes de sua vida anterior aparecem inesperadamente naquele mundo.

Enquanto tenta proteger aqueles que ama, Rio percebe que existe uma conspiração muito maior envolvendo heróis invocados, famílias nobres e poderes ancestrais.

A temporada transforma a história em uma aventura política de larga escala.


Resumo da História

Grande parte da temporada gira em torno dos reencontros entre Rio e personagens ligados à vida de Haruto, além da convivência entre diferentes reinos e da tensão causada pela chegada de novos heróis invocados.

Rio passa a atuar como mediador, guerreiro e protetor, evitando guerras desnecessárias enquanto tenta desvendar forças ocultas que manipulam os acontecimentos.

O desenvolvimento deixa claro que seu poder cresce na mesma proporção que suas responsabilidades.


O que muda em relação à primeira temporada?

A maior diferença é a escala.

Na primeira temporada:

  • conhecemos Rio;

  • entendemos sua origem;

  • acompanhamos sua evolução.

Na segunda:

  • o continente inteiro entra em cena;

  • diversos reinos passam a disputar influência;

  • aparecem novos heróis;

  • alianças políticas tornam-se fundamentais;

  • antigos mistérios começam a ser revelados.

A história deixa de ser apenas pessoal para ganhar dimensões geopolíticas.


Worldbuilding

A segunda temporada aprofunda elementos que antes apareciam apenas de forma superficial.

Conhecemos melhor:

  • relações diplomáticas;

  • diferenças culturais entre reinos;

  • funcionamento da nobreza;

  • povos da floresta;

  • espíritos superiores;

  • magia antiga;

  • heróis convocados;

  • tradições e cerimônias.

O universo torna-se muito mais vivo e coerente.


Sistema de Magia

Também recebe mais atenção.

Além das magias convencionais, vemos:

  • técnicas espirituais avançadas;

  • manipulação de mana;

  • contratos espirituais;

  • armas mágicas;

  • barreiras;

  • habilidades exclusivas de determinados personagens.

As batalhas passam a depender mais de estratégia do que apenas de força bruta.


Personagens Principais

Rio

Agora muito mais maduro.

Sua postura lembra a de um cavaleiro errante.

Mesmo possuindo enorme poder, continua humilde.


Aishia

Continua sendo um dos maiores pilares da força de Rio.

Seu vínculo espiritual evolui durante a temporada.


Celia Claire

Recebe maior desenvolvimento emocional.

Sua relação com Rio ganha novas camadas.


Miharu Ayase

Sua presença torna-se ainda mais importante por representar a ligação entre o passado japonês de Haruto e a nova vida de Rio.


Liselotte Cretia

Uma das figuras políticas mais interessantes da série.

Empresária, estrategista e extremamente inteligente.

Sua visão moderna aproxima-se bastante da de Haruto.


Flora Beltrum

A princesa amadurece e assume papel mais relevante nas relações diplomáticas entre os reinos.


As Aventuras

Rio:

  • protege caravanas;

  • impede conflitos diplomáticos;

  • enfrenta novos inimigos;

  • resgata aliados;

  • investiga conspirações;

  • participa de encontros entre nobres;

  • fortalece alianças;

  • descobre novos mistérios sobre os heróis convocados.

A temporada intercala ação com momentos de desenvolvimento político e emocional.


Temáticas

A segunda temporada amplia os temas discutidos:

  • responsabilidade;

  • liderança;

  • diplomacia;

  • amizade;

  • família;

  • memória;

  • identidade;

  • confiança;

  • escolhas;

  • convivência entre culturas.


Mensagens Ocultas

Poder exige responsabilidade

Rio já é um dos indivíduos mais fortes do continente.

Mesmo assim, evita usar violência quando a diplomacia pode resolver o problema.

É uma mensagem clássica de maturidade.


O conhecimento aproxima mundos

Haruto leva conhecimentos modernos.

Rio conhece profundamente aquele continente.

Juntos demonstram que inovação nasce quando culturas diferentes cooperam.


Política nem sempre significa guerra

Boa parte dos conflitos da temporada é resolvida através de negociações.

A obra mostra que inteligência frequentemente vale mais do que força.


O passado não desaparece

Mesmo vivendo outra vida, Haruto continua influenciando Rio.

A série reforça que nossas experiências moldam quem somos, mas não precisam determinar nosso futuro.


Qualidade da Animação

A produção mantém o padrão da primeira temporada. Os designs permanecem consistentes e os cenários medievais continuam detalhados. As cenas de magia e combate são competentes, embora algumas lutas utilizem animação mais simples devido às limitações de orçamento. O destaque permanece na narrativa e nos relacionamentos entre os personagens.  


Diferenças entre Anime e Light Novel

Assim como na primeira temporada, a adaptação acelera vários acontecimentos.

Entre as mudanças mais comentadas pelos leitores:

  • simplificação de diálogos políticos;

  • redução de interações entre personagens;

  • menor aprofundamento da diplomacia;

  • condensação de alguns arcos.

Apesar disso, a essência da história é preservada.


Curiosidades

  • A segunda temporada foi anunciada após a boa recepção da primeira, demonstrando a força contínua da franquia.  

  • A light novel já ultrapassou 30 volumes publicados no Japão, mostrando que o anime ainda adaptou apenas uma parte da narrativa.  

  • O reencontro entre Rio e personagens ligados à vida de Haruto era um dos momentos mais aguardados pelos leitores desde os primeiros volumes.


Impacto Cultural

Embora continue sendo uma franquia de médio porte dentro do universo isekai, Seirei Gensouki consolidou sua reputação com a segunda temporada ao expandir sua mitologia e fortalecer a fidelidade dos fãs. A série é frequentemente recomendada para quem procura um isekai que combine ação, fantasia, política e desenvolvimento gradual do protagonista, sem depender apenas de batalhas ou humor. O sucesso contínuo das light novels e a recepção positiva da nova temporada reforçam a longevidade da obra.  


Avaliação Bellacosa Mainframe

CritérioNota
Worldbuilding⭐⭐⭐⭐⭐ (9,3/10)
Evolução do protagonista⭐⭐⭐⭐⭐ (9,5/10)
Política⭐⭐⭐⭐⭐ (9,2/10)
Desenvolvimento dos personagens⭐⭐⭐⭐☆ (9,0/10)
Magia⭐⭐⭐⭐☆ (8,8/10)
Ação⭐⭐⭐⭐☆ (8,5/10)
Romance⭐⭐⭐⭐☆ (8,5/10)
Animação⭐⭐⭐⭐☆ (8,2/10)
Fidelidade à Light Novel⭐⭐⭐☆☆ (7,5/10)

Conclusão

A segunda temporada de Seirei Gensouki marca a transição da obra de uma jornada pessoal para uma fantasia épica de escala continental. O foco em diplomacia, alianças, identidade e consequências do poder enriquece a narrativa e diferencia a série de muitos isekais centrados apenas na evolução do protagonista.

No espírito Bellacosa Mainframe, Rio lembra um sistema IBM Z moderno: por fora, parece tranquilo e estável; por dentro, coordena múltiplos processos simultaneamente, conciliando interesses, resolvendo conflitos e mantendo tudo em funcionamento. Assim como um grande ambiente corporativo, a verdadeira força não está apenas na capacidade de processar mais rápido, mas em integrar diferentes "mundos" de forma confiável e inteligente.




terça-feira, 9 de julho de 2024

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Padawan Avançado - Parte IV

 

Bellacosa Mainframe e os ponteiros de memoria em cobol Parte IV

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 4 – O Padawan Avançado

COBOL, Metal C, APIs, Buffers Compartilhados, JSON, MQ e as Técnicas Jedi de Alto Desempenho no IBM Z

Por Bellacosa Mainframe


"O Padawan aprende MOVE. O Cavaleiro aprende BASED. O Mestre aprende que um ponteiro pode conectar universos inteiros."

Mestre Bellacosa Sysprog Jedi


Introdução

Chegamos ao último módulo do Holocron dos Ponteiros COBOL.

Nas partes anteriores aprendemos:

Parte 1

  • USAGE POINTER

  • ADDRESS OF

  • SET

  • AMODE

  • Heap

  • Stack

Parte 2

  • BASED

  • ALLOCATE

  • FREE

  • CEEGTST

  • Estruturas dinâmicas

Parte 3

  • SOC4

  • Memory Leak

  • Overlay

  • CEEDUMP

  • IPCS

  • Fault Analyzer

O jovem Padawan então pergunta:

Mestre...

Eu entendi os ponteiros.

Mas onde eles realmente são usados?

O mestre aponta para um gigantesco IBM z17.

E responde.

Em praticamente todos os lugares importantes.


O grande segredo

Poucos desenvolvedores percebem.

Mas produtos IBM utilizam ponteiros intensivamente.

Exemplos.

CICS

DB2

MQ

LE

z/OS

TCP/IP

JES2

JES3

RACF

SMF

VSAM

IMS

Todos.


O COBOL moderno

COBOL não vive sozinho.

Ele conversa.

Com:

C

Metal C

Assembler

Java

MQ

JSON

REST

Sockets


E o idioma dessa conversa é.

Ponteiros.


COBOL e C

Talvez seja o casamento mais comum.


C

Produz buffer.


COBOL

Consome.


Arquitetura.

C


↓

malloc()


↓

PTR



↓

COBOL


BASED

Exemplo conceitual

Programa C.

malloc(1024);

Retorna.

Endereço.


COBOL.

01 WS-PTR POINTER.

Recebe.


Associa.

SET ADDRESS OF BUFFER

TO WS-PTR

Pronto.


COBOL agora enxerga.

Memória criada em C.


Metal C

Mais interessante.


Executa próximo do hardware.


Pode usar.

64 bits.

Storage Keys.


Compartilhar.

Buffers.


Muito utilizado.

Middleware.


Shared Memory

Outro uso avançado.


Vários programas.

Mesmo buffer.


Visualmente.

Programa A


↓

Shared Buffer


↑


Programa B

Sem cópia.


Muito rápido.


MQ

Excelente exemplo.


MQGET

MQPUT


Mensagem.


Buffer.


COBOL.

Ponteiro.


Estrutura BASED.


Visualmente.

MQ


↓

Buffer


↓

PTR


↓

BASED

Processamento.

Zero cópia.


JSON

Muito utilizado hoje.


Imagine.

{
"name":"Bellacosa",

"idade":52
}

Parser.

Cria árvore.


Cada nó.

Possui ponteiros.


Pai.

Filho.

Irmão.


Exemplo.

JSON ROOT


↓


name


↓


idade

XML

Mesma ideia.


DOM.


Tree.


Ponteiros ligam.

Nós.


APIs

z/OS Connect.


Buffers.


Payload.


Parser.


Muito comum.


Sockets

TCP/IP.


Recebe.

4096 bytes.


Ponteiro.


COBOL lê.


Mais eficiente.


Cache

Outro caso.


Tabela gigante.


Ponteiro.

Evita copiar.


Exemplo.

100 MB.


Mover.

Custa.


Apontar.

8 bytes.


Quase instantâneo.


Tabelas in-memory

Excelente.


DB local.


Lookup rápido.


Hash.


B-tree.


Implementável.


Estruturas avançadas

Lista Duplamente Encadeada

NODE


PREV


NEXT

Árvore AVL


Balanceada.


Ponteiros.


B-tree

Muito utilizada.

Banco dados.


Grafo

Exemplo.

A


/ \


B  C


\ /


D

Tudo possível.


Comparação com outras linguagens

LinguagemPonteiros
COBOLSim
CSim
C++Sim
RustControlado
JavaReferências
GoSim
PythonOculto

Curiosidade

Java.

Esconde.


COBOL.

Mostra.


C.

Expõe totalmente.


Rust.

Protege.


Quando usar?

Bellacosa recomenda.


Excelente.

Buffers

MQ

JSON

XML

APIs

Cache

LE

Middleware

Parsers

Estruturas dinâmicas


Quando evitar?

Cadastro.


Folha pagamento.


VSAM simples.


DB2 comum.


Relatórios.


Performance

Muito alta.


Sem MOVE.


Sem COPY.


Sem serialização.


Muito usada.

Em produtos IBM.


Segurança

Ainda importante.


Ponteiro errado.

Continua.

SOC4.


Heap inválido.


Overlay.


Corrompe.


Documentação

Obrigatória.


Desenhe.

Diagramas.


Exemplo.

PTR1


↓

NODE1


↓

NODE2


↓

NODE3

Ajuda manutenção.


Bellacosa Best Practices

Regra 1

Inicialize.

Sempre.

SET PTR TO NULL

Regra 2

Documente.


Regra 3

Libere.


Regra 4

Nunca reutilize.

Após FREE.


Regra 5

BASED bem definido.


Regra 6

Evite engenharia excessiva.


O Teste do Mestre

Pergunta ao Padawan.

Você precisa.

Criar.

Lista encadeada?


Não?


Use OCCURS.


Sim?


Use ponteiros.


Curiosidades Finais

A maioria dos desenvolvedores COBOL jamais precisará escrever uma árvore AVL.

Ou um parser XML próprio.

Ou um cache compartilhado.

Ou uma estrutura dinâmica baseada em CEEGTST.

Mas os profissionais que sabem fazer isso normalmente pertencem a grupos bastante especializados:

  • Sysprogs

  • Middleware Engineers

  • Desenvolvedores CICS

  • Equipes MQ

  • Produtos IBM

  • Desenvolvedores de Frameworks

  • Especialistas em LE

  • Equipes de Modernização IBM Z


O Conselho Final do Mestre Bellacosa

Os ponteiros em COBOL são quase como cristais Kyber escondidos em uma antiga câmara do templo IBM Z.

Durante décadas, muitos desenvolvedores passaram por eles sem percebê-los.

Outros ouviram histórias assustadoras sobre SOC4, overlays e memory leaks e decidiram nunca tocá-los.

E alguns poucos escolheram estudá-los profundamente.

Esses poucos descobriram algo fascinante.

Ponteiros não servem apenas para criar problemas.

Eles são a base invisível que sustenta grande parte das tecnologias modernas do ecossistema IBM Z.

São eles que permitem compartilhar buffers entre linguagens.

São eles que fazem parsers navegarem por documentos JSON gigantescos.

São eles que ajudam produtos IBM a movimentar milhões de mensagens MQ por segundo.

São eles que transformam estruturas estáticas em sistemas vivos, capazes de crescer, adaptar-se e responder dinamicamente às necessidades do negócio.

Mas existe uma última lição.

Talvez a mais importante.

Um ponteiro não possui moral.

Ele não distingue sabedoria de imprudência.

Ele apenas aponta.

E cabe ao desenvolvedor decidir se está usando esse poder para construir um elegante mecanismo de alto desempenho ou para abrir um portal direto para um CEEDUMP de 500 páginas às três horas da manhã de um fechamento bancário.


Fim do Holocron Bellacosa Mainframe

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM ZParte 1 a Parte 4 concluídas.


segunda-feira, 8 de julho de 2024

⚽ O ABEND 7X1 — Quando o Sistema Brasil Travou

 


O ABEND 7X1 — Quando o Sistema Brasil Travou

Há falhas que nem o tempo corrige.
Outras, ficam gravadas no log da alma — linha por linha, bit por bit — pra lembrar que até o sistema mais robusto pode cair diante de um input inesperado.

8 de julho de 2014.
Belo Horizonte.
Semifinal da Copa do Mundo no Brasil.
Era pra ser festa.
Era pra ser o código perfeito: alegria, samba, arquibancada pulsando, o povo em modo online full throttle.
Mas, do nada, o sistema caiu.

Alemanha 7, Brasil 1.
O maior abend da história do futebol.

Daquele jogo não sobrou tática, só trauma.
O Maracanazo de 1950 ganhou um irmão digital — o “Mineirazo”.
O primeiro foi dor silenciosa; o segundo foi streaming global de vergonha em HD.

Lembro bem daquele dia.
O país inteiro estava em modo “monitor ativo”: churrascos acesos, bandeiras nas janelas, crianças pintadas de verde e amarelo.
E, em 29 minutos, tudo desmoronou.
Um, dois, três, quatro…
Era como assistir a um job loopando no JES2, gerando erro atrás de erro, e o operador impotente diante do painel piscando em vermelho.

Aquela noite foi um dump de nação.
Não sabíamos se ríamos, chorávamos ou reiniciávamos o servidor.
A seleção, que sempre fora o sistema operacional do orgulho nacional, simplesmente travou.
A Alemanha rodou um script limpo, modular, enxuto — enquanto o Brasil, atolado em processos redundantes, colapsou em deadlock.

Nos dias seguintes, o país viveu uma espécie de IPL emocional.
O futebol virou metáfora de tudo: da economia que falhava, da política fragmentada, do jeitinho que já não compila.
A derrota virou checkpoint histórico.
E, como todo desastre, trouxe também logs preciosos pra análise.

🧩 Curiosidades e Easter Eggs do 7x1:

  • A Alemanha marcou 4 gols em 6 minutos — um loop infinito de desespero que só terminou porque o cronômetro insistiu.

  • O técnico Löw usava dados analíticos em tempo real — algo raro na época — quase um Watson Football rodando em campo.

  • Depois do jogo, o Google registrou o pico de buscas “o que aconteceu com o Brasil?” — um abend reason code coletivo.

  • Em algumas transmissões estrangeiras, o placar ficou congelado por minutos, porque o sistema gráfico não suportava dois dígitos de diferença — um bug literal do século XXI.

Mas o que mais doeu não foi o resultado — foi o desmonte da identidade.
O Brasil sempre foi o país do improviso genial, do assemble que vira arte.
E, de repente, o algoritmo europeu mostrou que frieza, método e linha de código limpa também vencem partidas.
Ali, perdemos o jogo e um pouco do mito.

Dez anos depois, a dor virou cicatriz — mas a lição ficou no SYSLOG:
mesmo o maior dos sistemas precisa de revisão, backup e humildade.
Porque a confiança demais no “jeitinho” é o que faz a máquina travar.

Hoje, quando vejo aquele replay — os gols, o silêncio, o rosto do David Luiz pedindo desculpas ao país — penso que aquele 7x1 foi um abend necessário.
O crash que obrigou o sistema a repensar sua arquitetura.
O abend S0C7 que doeu, mas limpou o buffer da arrogância.

E como bom mainframer, sei:
um sistema só amadurece quando aprende com o erro,
quando para de culpar o operador e começa a revisar o código.

O Brasil ainda está em recovery mode.
Mas, se há algo que aprendi nesses anos de tela verde e alma azul,
é que até o job que falha deixa rastro pra quem sabe ler o log.


domingo, 7 de julho de 2024

Suicide Squad ISEKAI : Quando Amanda Waller Descobre que Nem um Mundo de Magia é Páreo para um Time de Programas Legados Fora de Controle

 

Bellacosa Mainframe apresenta o suicide squad isekai

☕ Um Café no Bellacosa Mainframe

Suicide Squad ISEKAI (2024) sem Mistérios

Quando Amanda Waller Descobre que Nem um Mundo de Magia é Páreo para um Time de Programas Legados Fora de Controle

Imagine que alguém resolvesse misturar DC Comics, Dungeons & Dragons, isekai, humor japonês, explosões, dragões, Harley Quinn e um dos melhores estúdios de animação do Japão.

A lógica diria que seria um desastre.

Mas exatamente como acontece em muitos sistemas legados...

o resultado funciona melhor do que deveria.

Suicide Squad ISEKAI é uma produção original criada pela Warner Bros. Japan em parceria com o WIT Studio. Em vez de adaptar uma HQ específica, o anime cria uma aventura inédita, transportando os mais perigosos vilões da DC para um universo medieval repleto de magia, monstros e conspirações políticas.


Ficha Técnica

Título Original

異世界スーサイド・スクワッド
(Isekai Suicide Squad)

Título Internacional

Suicide Squad ISEKAI

Ano de lançamento

2024

Estúdio

WIT Studio

Produção

Warner Bros. Japan

Direção

Eri Osada

Roteiro

Tappei Nagatsuki (Re:ZERO)

Eiji Umehara (Vivy)

Design original dos personagens

Akira Amano
(Katekyo Hitman Reborn!)

Design para animação

Naoto Hosoda

Trilha sonora

Kenichiro Suehiro

Lançamento

27 de junho de 2024 (streaming internacional)

Episódios

10

Duração

aproximadamente 24 minutos cada.


Estúdio — WIT Studio

O WIT Studio tornou-se referência mundial por unir excelente direção artística, animações fluidas e cenas de ação cinematográficas.

Entre suas produções mais famosas estão:

  • Attack on Titan (temporadas iniciais)

  • Vinland Saga (1ª temporada)

  • SPY×FAMILY (coprodução)

  • Ranking of Kings

  • The Ancient Magus' Bride

Em Suicide Squad ISEKAI, o estúdio aposta em cores vibrantes, animação exagerada e movimentos extremamente expressivos, principalmente para Harley Quinn, criando um visual que mistura quadrinhos americanos com linguagem típica dos animes modernos. (Warner Bros.)


Sinopse

Amanda Waller, diretora da A.R.G.U.S., recruta novamente o Esquadrão Suicida.

Harley Quinn.

Deadshot.

Peacemaker.

Clayface.

King Shark.

Como sempre...

cada um recebe uma bomba implantada no pescoço.

Desta vez, porém, a missão não é em Gotham.

Eles atravessam um portal dimensional e chegam a um mundo governado por espadas, dragões, magia, elfos, orcs e reinos em guerra.

O que parecia apenas uma missão de reconhecimento rapidamente se transforma numa guerra que ameaça dois universos diferentes. (DC)


Resumo da História

Logo no início vemos Harley Quinn e Coringa espalhando caos por Gotham.

Após sua captura, Amanda Waller monta um novo Esquadrão Suicida.

O grupo atravessa um portal experimental criado pela A.R.G.U.S.

Mas nada ocorre como planejado.

O helicóptero cai.

O grupo fica preso.

Os explosivos continuam ativos.

E agora precisam sobreviver em um reino onde ninguém fala sua língua e praticamente tudo deseja matá-los.

Ao longo da série descobrem que há uma conspiração envolvendo magia, política, tecnologia e forças capazes de afetar tanto o mundo fantástico quanto a própria Terra.


Os Principais Personagens

Harley Quinn

A verdadeira estrela do anime.

Insana.

Carismática.

Imprevisível.

Seu comportamento exagerado encaixa perfeitamente na estética dos animes japoneses.


Deadshot

O mais racional da equipe.

Excelente estrategista.

Mantém o grupo relativamente unido quando tudo está desmoronando.


Peacemaker

Arrogante.

Extremamente confiante.

Acredita que sempre possui razão.

Produz algumas das cenas mais engraçadas da série.


Clayface

Capaz de assumir inúmeras formas.

Seu lado teatral gera boa parte do humor.

É praticamente um ator preso dentro de um supervilão.


King Shark

Gigantesco.

Fortíssimo.

Ingênuo.

Apesar da aparência assustadora, frequentemente demonstra comportamento infantil.


Amanda Waller

A comandante da missão.

Mesmo distante do outro mundo continua controlando todos por meio das bombas implantadas.


Coringa

Embora apareça menos do que Harley, continua sendo um elemento importante para explicar sua personalidade e suas motivações.


O que torna esse anime diferente?

Essa talvez seja sua maior qualidade.

Enquanto quase todos os isekais seguem o modelo:

  • estudante japonês

  • acidente

  • reencarnação

  • protagonista herói

Aqui acontece exatamente o contrário.

Os protagonistas são criminosos.

Não querem salvar ninguém.

Não possuem honra.

Nem pretendem virar heróis.

Eles simplesmente querem sobreviver.

Essa inversão produz situações extremamente divertidas.

Outro diferencial importante é a mistura entre:

  • fantasia medieval japonesa

  • super-heróis americanos

  • humor absurdo

  • ação extremamente violenta

  • narrativa típica dos animes.


Temáticas

Apesar da aparência caótica, diversos temas aparecem durante a série.

Liberdade

Todos são criminosos.

Mesmo atravessando dimensões continuam presos às ordens de Amanda Waller.

O cenário muda.

A prisão permanece.


Redenção

Será que pessoas consideradas monstros podem realizar atos heroicos?

A série brinca constantemente com essa ideia.


Caos versus Controle

Harley representa o caos absoluto.

Amanda representa controle absoluto.

Toda a narrativa gira em torno desse conflito.


Cooperação

Nenhum integrante suporta o outro.

Mesmo assim...

precisam trabalhar juntos.


Identidade

Ao entrar em outro mundo, muitos personagens deixam de ser vistos como supervilões.

Passam a ser apenas guerreiros estranhos tentando sobreviver.


As Grandes Aventuras

Durante os dez episódios encontramos praticamente tudo que um bom isekai oferece.

  • dragões

  • castelos

  • cavaleiros

  • elfos

  • magia

  • monstros

  • guerras

  • rebeliões

  • rainhas

  • política entre reinos

  • perseguições

  • batalhas épicas

  • criaturas gigantes

Tudo isso acompanhado da personalidade completamente imprevisível do Esquadrão Suicida.


Mensagens Ocultas

O verdadeiro inimigo pode ser o sistema

Diversos personagens são usados como ferramentas por líderes políticos.

O anime mostra como indivíduos podem ser descartáveis quando tratados apenas como recursos.


O caos produz inovação

Harley raramente resolve um problema seguindo regras.

Ela improvisa.

Erra.

Experimenta.

E muitas vezes encontra soluções impossíveis.

Isso lembra bastante inovação tecnológica.

Nem sempre seguir o manual cria os melhores resultados.


Aparências enganam

Os "vilões" frequentemente demonstram mais humanidade do que diversos governantes considerados heróis.


Trabalho em equipe

Mesmo indivíduos completamente incompatíveis podem alcançar resultados extraordinários quando unem suas habilidades.


Bellacosa Mainframe — Uma Analogia para Programadores COBOL

Imagine que Amanda Waller seja o operador do JES2.

Cada integrante do Esquadrão Suicida é um programa COBOL legado.

Nenhum foi escrito para trabalhar junto.

Cada um possui características completamente diferentes.

Mesmo assim...

o scheduler dispara todos.

O portal dimensional?

É uma API REST chamando um ambiente totalmente diferente.

O mundo mágico?

É aquele novo sistema Java distribuído.

Harley Quinn é aquele programa COBOL sem documentação.

Todo mundo reclama.

Ninguém entende.

Mas quando chega o fechamento bancário...

é justamente ele que salva toda a produção.

Clayface seria um middleware.

Transforma qualquer formato.

Converte qualquer mensagem.

King Shark lembra aquele utilitário escrito há quarenta anos.

Feio.

Estranho.

Mas extremamente eficiente.

Peacemaker?

É aquele desenvolvedor que diz:

"Meu código nunca falha."

Cinco minutos depois...

ABEND S0C7.


Impacto Cultural

Suicide Squad ISEKAI representa um interessante encontro entre duas grandes culturas do entretenimento.

De um lado estão os personagens clássicos da DC Comics.

Do outro, o gênero isekai, um dos maiores fenômenos da animação japonesa da última década.

O anime mostra que franquias ocidentais podem ser reinterpretadas sem perder sua identidade, ao mesmo tempo em que aproxima públicos diferentes: fãs de quadrinhos americanos, fãs de anime e espectadores que normalmente não consumiriam uma adaptação desse tipo. A escolha de roteiristas ligados a sucessos como Re:ZERO também ajudou a dar personalidade própria ao projeto.


Classificação

Gênero

  • Isekai

  • Fantasia

  • Ação

  • Super-heróis

  • Comédia

  • Aventura

Classificação Indicativa

Voltado ao público maduro, devido à violência estilizada, linguagem forte e cenas de ação intensas. 


Avaliação Bellacosa Mainframe

⭐⭐⭐⭐☆ 4,6 / 5

Animação: ⭐⭐⭐⭐⭐

Direção: ⭐⭐⭐⭐☆

Humor: ⭐⭐⭐⭐⭐

Originalidade: ⭐⭐⭐⭐⭐

Worldbuilding: ⭐⭐⭐⭐☆

Personagens: ⭐⭐⭐⭐⭐

Profundidade da história: ⭐⭐⭐⭐☆


Conclusão

Suicide Squad ISEKAI prova que até uma ideia aparentemente improvável pode funcionar quando há criatividade, um estúdio talentoso e respeito pelas características dos personagens.

A série não tenta copiar os filmes da DC nem seguir as fórmulas tradicionais dos isekais. Em vez disso, cria uma identidade própria, equilibrando humor, fantasia, violência estilizada e ação frenética.

No universo do Bellacosa Mainframe, fica uma última lição:

Assim como um sistema legado pode surpreender ao integrar-se com tecnologias modernas, um grupo de supervilões pode acabar salvando um reino inteiro. Às vezes, a solução mais improvável é justamente a que mantém o sistema — ou o mundo — funcionando.

sábado, 6 de julho de 2024

☕🚀 PADAWAN, YAML NÃO É LINGUAGEM DE PROGRAMAÇÃO. É A FICHA DE CADASTRO DO UNIVERSO DEVOPS!

 

Bellacosa Mainframe e a introdução a YAML

☕🚀 PADAWAN, YAML NÃO É LINGUAGEM DE PROGRAMAÇÃO. É A FICHA DE CADASTRO DO UNIVERSO DEVOPS!

Se você veio do mundo COBOL, JCL, PROC, PARMLIB, SYSIN, cartões perfurados, datasets sequenciais e arquivos de configuração gigantescos, provavelmente já esbarrou em um arquivo chamado:

application.yaml
docker-compose.yaml
kubernetes.yaml
pipeline.yaml

E talvez tenha pensado:

"Mas afinal... que diabos é YAML?"

Sente-se, pegue seu café e venha comigo.

Porque entender YAML hoje é quase tão importante para um desenvolvedor moderno quanto entender JCL era para um programador mainframe nos anos 80.


A HISTÓRIA DO YAML

YAML significa:

YAML Ain't Markup Language

Ou seja:

"YAML não é uma linguagem de marcação."

O nome é um trocadilho.

No início ele significava:

Yet Another Markup Language
(Mais uma linguagem de marcação)

Mas depois os criadores perceberam que YAML não era exatamente uma linguagem de marcação como XML.

Então mudaram para:

YAML Ain't Markup Language


QUANDO O YAML NASCEU?

O projeto surgiu em:

2001

Criado por:

  • Clark Evans

  • Ingy döt Net

  • Oren Ben-Kiki

O objetivo era simples:

Criar algo mais legível que XML.

Na época o XML dominava tudo.

Exemplo XML:

<cliente>
   <nome>João</nome>
   <idade>25</idade>
</cliente>

Os criadores pensaram:

"Por que tanta tag abrindo e fechando?"

Então nasceu YAML.


VERSÕES IMPORTANTES

YAML 1.0

2004

Primeira versão oficial.


YAML 1.1

2005

Mais recursos.

Maior adoção.


YAML 1.2

2009

Versão mais usada atualmente.

Compatibilidade melhor com JSON.


POR QUE O YAML FICOU TÃO POPULAR?

Porque ele resolveu um problema enorme:

Configurações.

Todo sistema precisa delas.

Antes tínhamos:

  • INI

  • XML

  • Properties

  • Arquivos texto

Mas YAML ficou muito mais fácil de ler.


PARA QUE SERVE O YAML?

Basicamente:

Armazenar configuração

Exemplo:

servidor:
  porta: 8080

banco:
  host: localhost

ONDE O YAML É UTILIZADO?

Hoje praticamente em todo lugar.


Kubernetes

Talvez o maior usuário de YAML do planeta.

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod

Docker Compose

version: "3"

services:
  banco:
    image: mysql

Spring Boot

server:
  port: 8080

GitHub Actions

name: Build
on: push

GitLab CI

stages:
  - build
  - deploy

Ansible

- hosts: servidores

O YAML PARA UM COBOLISTA

Imagine um membro PARMLIB.

Por exemplo:

PORTA=8080
HOST=localhost

YAML faz algo semelhante.

Só que organizado hierarquicamente.

servidor:
  host: localhost
  porta: 8080

É como um PARMLIB muito mais moderno.


A REGRA MAIS IMPORTANTE DO YAML

Padawan...

A regra mais importante é:

ESPAÇOS

Não TAB.

Não misture.

Não invente.

Somente espaços.


EXEMPLO VÁLIDO

cliente:
  nome: João
  idade: 25

EXEMPLO INVÁLIDO

cliente:
<TAB>nome: João

Muitos erros acontecem por causa disso.


ESTRUTURA BÁSICA

Tudo gira em torno de:

chave : valor

nome: João

idade: 25

ativo: true

TIPOS DE DADOS

Texto

nome: Bellacosa

Número

idade: 50

Decimal

salario: 3500.99

Booleano

ativo: true

Nulo

valor: null

AGRUPAMENTOS

Podemos criar grupos.

cliente:
  nome: João
  idade: 25

Representa:

{
  "cliente":{
      "nome":"João",
      "idade":25
  }
}

LISTAS

Parecido com OCCURS.

linguagens:
  - COBOL
  - Java
  - Python

Equivale a:

[
 "COBOL",
 "Java",
 "Python"
]

LISTA DE OBJETOS

Muito usada.

funcionarios:

  - nome: João
    cargo: Programador

  - nome: Maria
    cargo: Analista

COMENTÁRIOS

Como no JCL usamos:

//*

No YAML usamos:

# comentário

Exemplo:

# porta da aplicação
porta: 8080

STRINGS

Pode ser:

nome: Bellacosa

Ou:

nome: "Bellacosa"

Ou:

nome: 'Bellacosa'

MULTILINHAS

Muito útil.

descricao: |
  Linha 1
  Linha 2
  Linha 3

Resultado:

Linha 1
Linha 2
Linha 3

EXEMPLO PRÁTICO SPRING BOOT

Imagine uma API Java.

Arquivo:

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost/teste
    username: root
    password: 123

Quando a aplicação sobe:

  • Porta 8080

  • Banco MySQL

  • Usuário root

Tudo configurado via YAML.


EXEMPLO PRÁTICO DOCKER COMPOSE

version: '3'

services:

  mysql:
    image: mysql:8

  app:
    image: minha-api

Traduzindo:

"Suba dois containers"

  • MySQL

  • Aplicação


EXEMPLO PRÁTICO KUBERNETES

Aqui mora o YAML.

Praticamente tudo no Kubernetes é YAML.

apiVersion: v1

kind: Pod

metadata:
  name: bellacosa

spec:

  containers:
    - name: app
      image: nginx

Executa:

kubectl apply -f pod.yaml

E o cluster cria o pod.


COMANDOS IMPORTANTES

YAML em si não possui comandos.

Isso é importante.

Muitos iniciantes confundem.

YAML é apenas:

Estrutura de dados.

Os comandos pertencem à ferramenta.


Exemplo:

Docker:

docker compose up

Kubernetes:

kubectl apply -f arquivo.yaml

Ansible:

ansible-playbook playbook.yaml

GitHub:

Automaticamente lê:

.github/workflows/build.yaml

YAML E JSON

Você sabia?

Todo JSON válido pode ser convertido para YAML.


JSON:

{
  "nome":"João"
}

YAML:

nome: João

Muito mais limpo.


VANTAGENS

Legibilidade

A maior vantagem.


Fácil de aprender

Poucas regras.


Menos verboso

Muito menor que XML.


Hierarquia natural

A indentação mostra tudo.


Amplamente suportado

Praticamente todas as linguagens.


Excelente para DevOps

Docker

Kubernetes

GitHub

Ansible

Terraform

Tudo conversa com YAML.


DESVANTAGENS

Nem tudo são flores.


Sensível a espaços

Um espaço errado:

Tudo quebra.


Difícil para estruturas gigantes

Arquivos enormes viram labirintos.


Erros nem sempre claros

Às vezes o parser reclama na linha 200.

Mas o erro está na linha 30.


Não é ideal para dados complexos

JSON pode ser mais seguro.


ERROS CLÁSSICOS DE INICIANTES

Misturar TAB e espaço

Erro número 1.


Indentação incorreta

Errado:

cliente:
nome: João

Correto:

cliente:
  nome: João

Esquecer hífen em listas

Errado:

linguagens:
 COBOL
 JAVA

Correto:

linguagens:
 - COBOL
 - JAVA

LABORATÓRIO 1

Criar arquivo:

empresa:
  nome: Bellacosa Mainframe
  fundacao: 2024

Salvar:

empresa.yaml

LABORATÓRIO 2

Adicionar funcionários.

empresa:

  nome: Bellacosa Mainframe

  funcionarios:

    - nome: João
      cargo: Programador

    - nome: Maria
      cargo: Analista

LABORATÓRIO 3

Converter para JSON

Resultado:

{
  "empresa":{
    "nome":"Bellacosa Mainframe",
    "funcionarios":[
      {
        "nome":"João",
        "cargo":"Programador"
      },
      {
        "nome":"Maria",
        "cargo":"Analista"
      }
    ]
  }
}

YAML E COBOL

Imagine uma configuração externa.

Antes:

01 PARAMETROS.
   05 PORTA       PIC 9(4).
   05 HOST        PIC X(50).

Lendo de arquivo texto.

Hoje poderíamos ter:

aplicacao:
  host: localhost
  porta: 8080

Uma API Java poderia ler isso.

Uma aplicação Node.js também.

Um container Docker também.

Todos compartilhando o mesmo arquivo.


YAML NO MUNDO MAINFRAME

Muita gente acredita que YAML não tem relação com Mainframe.

Erro enorme.

Hoje encontramos YAML em:

  • OpenShift on Z

  • Kubernetes on IBM Z

  • z/OS Connect

  • IBM Cloud

  • Ansible Automation Platform

  • DevOps Enterprise


Imagine um pipeline CI/CD para COBOL:

stages:

  - build

  - test

  - deploy

Esse YAML pode controlar:

  • Compilação COBOL

  • Link Edit

  • Testes

  • Deploy

Tudo automaticamente.


ANALOGIA BELLACOSA MAINFRAME

Se eu tivesse que explicar YAML para um operador de mainframe dos anos 80, eu diria:

JCL diz O QUE EXECUTAR.

COBOL diz COMO PROCESSAR.

YAML diz COMO CONFIGURAR.

Ele é o formulário de configuração do ecossistema moderno.

Não executa lógica.

Não faz cálculo.

Não substitui COBOL.

Não substitui Java.

Não substitui Python.

Mas conecta todos eles.


CONCLUSÃO

Padawan...

Se nos anos 70 o profissional de tecnologia precisava entender:

  • JCL

  • PROCs

  • PARMLIB

  • SYSIN

Hoje o profissional moderno precisa entender:

  • YAML

  • Docker

  • Kubernetes

  • GitHub Actions

  • CI/CD

YAML tornou-se a linguagem universal da configuração.

Sua sintaxe minimalista, sua legibilidade e sua adoção massiva fizeram dele um dos formatos mais importantes da computação moderna.

E existe uma grande chance de que o próximo arquivo que você abrir em um projeto de nuvem, DevOps, containers, APIs ou automação tenha exatamente esta extensão:

.yaml

ou

.yml

Quando isso acontecer, não tenha medo.

Lembre-se desta regra:

"YAML é para o DevOps o que o PARMLIB foi para o Mainframe: um lugar onde a configuração mora para que o programa possa trabalhar."

E quando você dominar YAML, Kubernetes, Docker e automação, perceberá algo curioso:

O mercado mudou, as ferramentas mudaram, os nomes mudaram...

Mas a ideia continua a mesma desde os tempos do COBOL:

separar a configuração da lógica do programa.

Essa é uma das filosofias mais antigas, elegantes e duradouras da computação. 🚀☕💙


sexta-feira, 5 de julho de 2024

A nostalgia da internet “raiz”: mito ou memória legítima?

 


A nostalgia da internet “raiz”: mito ou memória legítima?

A pergunta que ecoa nos sobreviventes do caos digital

Existe um grupo crescente de usuários que olha para trás e afirma, com convicção, que a internet era melhor antes. Antes dos filtros, antes das regras, antes dos “influenciadores”, antes da sofisticação corporativa. Quando a web era uma selva mal documentada, feita de improviso, risco e descoberta.

Será que essa nostalgia é apenas um mito confortável sobre o passado… ou realmente havia algo mais vivo naquela internet inicial?

Este texto propõe uma reflexão meticulosa sobre essa sensação.


1. A internet como território selvagem

Nos primórdios, a navegação lembrava uma expedição. Não existiam plataformas únicas para tudo. Fóruns, blogs, salas de chat e sites experimentais surgiam como ilhas autônomas de cultura.

Nada era padronizado. Nada era profissional.
Exatamente por isso, tudo era possível.

O usuário criava, quebrava, errava, aprendia.
Sem medo do cancelamento. Sem medo da desmonetização.


2. A sensação de descoberta morreu

Hoje o algoritmo entrega o suposto “melhor conteúdo” antes mesmo de sabermos o que queremos. A seleção se tornou automática, previsível, eficiente em excesso.

Na internet antiga:
→ tropeçava-se no desconhecido.

Na internet atual:
→ recebe-se o conhecido para sempre.

O inesperado saiu de cena.


3. Comunidade antes de audiência

Antes, cada site era um ponto de encontro com vínculos reais.
Canais eram pequenos e íntimos. A fama era orgânica.

Agora, todo mundo é marca. Tudo é “conteúdo”.
A relação com o público se transformou em “gestão de engajamento”.

Quando a interação vira métrica, a conversa perde alma.


4. A ilusão da liberdade irrestrita

Parte da nostalgia nasce de uma percepção real:
existia mais margem para o bizarro, para o tabu e para o politicamente incorreto.
Não porque o mundo fosse mais tolerante, mas porque a vigilância era menor.

O caos criava criatividade.
Criatividade criava novas formas de expressão.
Novas expressões criavam cultura.

Hoje, o medo de punição modera o impulso de experimentar.


5. O fator “juventude”

A nostalgia também possui um elemento humano:
para muitos, a internet raiz acompanhou a adolescência ou início da vida adulta.
Qualquer mudança tecnológica se mistura às próprias mudanças biográficas.

Memória afetiva não deve ser descartada.
Mas também não deve ser confundida com argumento absoluto.


Então a nostalgia é mito ou memória legítima?

A resposta é dupla:

Mito, quando idealiza um passado sem perigos, sem desinformação e sem abuso
Memória legítima, quando reconhece que antes existia mais autonomia e descoberta

A internet não ficou pior em tudo.
Acessibilidade, segurança, conectividade e inclusão evoluíram.
Contudo, pagamos por isso com padronização, vigilância e controle algorítmico.

O preço do conforto digital foi a perda da aventura.


Conclusão

A nostalgia da internet raiz não é apenas saudosismo.
É luto por um ambiente onde o usuário participava como autor,
e não apenas como consumidor monitorado.

Talvez a questão essencial seja:

Queremos segurança absoluta
ou a emoção de explorar o desconhecido?

Porque a história prova que a internet pode ser muitas coisas.
A dúvida é se teremos coragem de reinventá-la novamente.

quinta-feira, 4 de julho de 2024

☕💥 Storage: DASD, Flash e a Imortalidade do 3390

 

Bellacosa Mainframe e o storage em mainframe evolução do armazenamento

☕💥 DASD, Flash e a Imortalidade do 3390

Ou como a IBM convenceu o z/OS de que ainda estamos em 1989 enquanto gravamos dados em NVMe mais rápido que um caça de quinta geração



Introdução

Existe uma lenda urbana entre desenvolvedores Mainframe.

Dizem que em algum lugar dentro de um DS8950F existe um pequeno senhor de barba branca usando suspensórios, fumando cachimbo e respondendo:

"Sim, z/OS. Eu ainda sou um 3390."

E o mais assustador?

Ele está dizendo a verdade.

Enquanto boa parte da indústria de TI troca tecnologias como quem troca de smartphone, o Mainframe possui uma filosofia bastante diferente.

Ele não descarta tecnologias.

Ele as absorve.

Encapsula.

Virtualiza.

Esconde atrás de interfaces estáveis.

E permite que programas COBOL escritos durante o Governo Sarney continuem funcionando em um IBM z17 sem perceber que o disco físico que armazena seus arquivos está centenas de milhares de vezes mais rápido.

Hoje vamos tomar um café forte e explorar a evolução do armazenamento IBM Z.


Bellacosa Mainframe e o disco fisico no mundo mainframe

O que é DASD?

DASD significa:

Direct Access Storage Device

Foi o nome adotado pela IBM para dispositivos de armazenamento de acesso direto.

Na prática:

  • HDs Mainframe

  • SSDs Mainframe

  • Volumes virtuais

  • Flash arrays

No universo z/OS tudo continua sendo chamado simplesmente de:

DASD

Mesmo que não exista mais nenhum disco girando.


Bellacosa Mainframe e a evolução do storage no Mainframe

A Pré-história

2305

Ano: 1970

Capacidade:

5 MB

Tecnologia:

Disco removível

Tempo acesso:

30 ms


3330 Merlin

1971

Capacidade:

100 MB

RPM:

3600


3350

1975

317 MB


O gigante dos anos 80

IBM 3380

Lançamento:

1980

Capacidade:

2,52 GB

Velocidade:

3600 rpm

Track:

47.476 bytes

15 tracks/cylinder

Peso:

Mais de 500 kg

Era praticamente uma geladeira industrial.


O rei absoluto

IBM 3390

Ano

1989

Track Size

56.664 bytes

Tracks

15

Cylinder

849.960 bytes

≈0,81 MB


Modelos

ModeloCylCapacidade
111130,9 GB
222261,8 GB
333392,7 GB
9100178 GB
273276026 GB
546552054 GB

Como calcular espaço

Cyl = 15 trilhas

Track = 56664

Exemplo

100 cylinders

100 × 849960

84 MB

aproximadamente


Como o z/OS enxerga discos

Programa COBOL:

SELECT CLIENTE
ASSIGN TO CLIENTE.

FD CLIENTE.

01 REG-CLI.
   05 CODIGO PIC 9(9).
   05 NOME PIC X(50).

Nada aqui sabe se o dado está em:

3390

SSD

NVMe

DS8000

Cloud

Absolutamente nada.


O truque da IBM

Hoje usamos:

DS8880

DS8910

DS8950

DS8A10

DS8A50

Mas o z/OS continua vendo:

3390-54

ou

3390-A

Virtual.


A era DS8000

DS8000

Ano

2004

Foi revolucionário.

Trouxe:

FICON

RAID

Cache enorme

Tiering

Snapshots

Replication


DS8880

2015

Até centenas de TB

Flash

Easy Tier


DS8950F

Flash puro.

NVMe

Microsegundos de latência.


Como funciona internamente

Aplicação

VSAM

Catalog

SMS

Volume

DS8000


SMS

Storage Management System

Possui:

ACS

Storage Class

Data Class

Management Class


Exemplo

STORCLAS

FAST

MGMTCLAS

BACKUP30


Exemplo JCL

//STEP1 EXEC PGB=IEFBR14

//ARQ DD

DSN=VAGNER.TESTE

DISP=(NEW,CATLG)

SPACE=(CYL,(100,20))

UNIT=3390

DCB=(RECFM=FB,LRECL=80)

Observe

UNIT=3390

Mesmo em 2026.


VSAM

KSDS

ESDS

RRDS

LDS


IDCAMS

//DEF EXEC PGB=IDCAMS

//SYSIN DD *


DEFINE CLUSTER(

NAME(CLIENTE.KSDS)

VOLUMES(VOL001)

TRACKS(100 20)

)

/*

Onde monitorar uso

ISPF

3.4

Volume


SDSF

DA

DEV


IDCAMS

LISTCAT

LISTCAT ENT(CLIENTE.KSDS)

DFSMS

DCOLLECT


RMF

RMF Monitor III


SMF

42

74

78


Comandos úteis

D U,VOL=SER001

LISTVTOC

LISTCAT


Curiosidade

52 GB parecia enorme.

Hoje um smartphone possui:

512 GB

Dez vezes mais.

Mas...

Um smartphone não processa

PIX

Bolsa

INSS

Cartões

Compensação bancária

para milhões de pessoas.


Flash

Flash eliminou:

Seek time

Rotação

Head movement


Antes

10 ms

Hoje

100 microsegundos

100 vezes melhor.


Easy Tier

Move automaticamente dados.

Hot

SSD

Cold

SATA

Sem intervenção.


Compressão

Hardware.

Sem CPU z/OS.


Replicação

Metro Mirror

Global Mirror

Safeguarded Copy


Erros comuns

B37

Sem espaço


D37

Volume cheio


E37

Extensão insuficiente


IEC070I

Falha de alocação


Solução

Mais secondary

SMS

Novo volume


Melhor prática

Nunca usar:

SPACE=(CYL,(1,1))

Produção odeia isso.


Bellacosa Mainframe e a evolução do storage 

Easter Egg Bellacosa

Imagine um COBOL de 1987.

Compilado em COBOL II.

Executando em 2026.

Lendo VSAM.

Em um DS8950F.

Flash NVMe.

z17.

LinuxONE ao lado.

IA embarcada.

Criptografia quântica.

E ainda existe:

UNIT=3390

O programa olha para o disco e diz:

Bom dia senhor 3390.

O DS8950F responde:

Sim filho... continue trabalhando.

E ninguém percebe que existe aproximadamente quarenta anos de evolução tecnológica escondida atrás de uma única palavra.


Considerações finais

Talvez esta seja a maior obra de engenharia produzida pela IBM.

Não foi criar discos maiores.

Nem processadores mais rápidos.

Nem flash mais eficiente.

Foi construir um ecossistema onde décadas de aplicações continuam executando sem alterações significativas.

O Mainframe não luta contra o passado.

Ele conversa com ele.

E talvez seja exatamente por isso que, enquanto muitas plataformas precisam ser reescritas a cada década, ainda existam aplicações COBOL escritas por profissionais aposentados há vinte anos processando bilhões de dólares diariamente.

No universo IBM Z, o armazenamento não é apenas um lugar para guardar dados.

É um pacto silencioso entre gerações de engenheiros.

E toda vez que digitamos:

SPACE=(CYL,(100,20))
UNIT=3390

estamos, de certa forma, apertando a mão de todos os sysprogs, operadores e desenvolvedores que vieram antes de nós.

E isso merece, no mínimo, mais uma xícara de café.


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