✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

domingo, 30 de setembro de 2018

☕🗡️ “GOBLIN SLAYER” — O OPERADOR SOMBRIO QUE TRANSFORMOU CAÇA A GOBLINS EM UMA OPERAÇÃO DE GUERRA DE NÍVEL MAINFRAME 💀🖥️🔥

Bellacosa Mainframe apresenta Goblin Slayer

☕🗡️ “GOBLIN SLAYER” — O OPERADOR SOMBRIO QUE TRANSFORMOU CAÇA A GOBLINS EM UMA OPERAÇÃO DE GUERRA DE NÍVEL MAINFRAME 💀🖥️🔥

📜 INFORMAÇÕES OFICIAIS

Item	Informação
Título Original	ゴブリンスレイヤー (Goblin Slayer)
Autor	Kumo Kagyu
Ilustrador Original	Noboru Kannatsuki
Studio da 1ª Temporada	White Fox
Studio da 2ª Temporada	LIDENFILMS
Estreia	Outubro de 2018
Gênero	Dark Fantasy, Horror, Ação, Aventura, Seinen
Classificação	+18 em vários países
Episódios	12 episódios (Temporada 1) + filme + Temporada 2
Filme	Goblin’s Crown (2020)
Origem	Light Novel

☕💀 O QUE É “GOBLIN SLAYER”?

Na superfície…

parece apenas mais um anime medieval de fantasia.

Mas poucos minutos bastam para perceber:

isso não é um conto de heróis.
é uma história sobre trauma, obsessão e sobrevivência operacional.

Goblin Slayer destrói completamente a ideia romantizada de RPG fantasy.

Enquanto outros aventureiros sonham com:

dragões,
demônios,
reis malignos,
artefatos lendários,

o protagonista vive uma guerra pessoal contra o inimigo mais “subestimado” do sistema:

GOBLINS.

🖥️ AO ESTILO BELLACOSA MAINFRAME…

O Goblin Slayer parece aquele analista veterano de produção que todos ignoram…

até o ambiente entrar em colapso.

Enquanto os aventureiros novatos focam em “grandes projetos”…

ele entende algo fundamental:

pequenas falhas negligenciadas causam os maiores desastres.

Goblin no universo do anime é igual:

vulnerabilidade ignorada,
rotina antiga sem revisão,
usuário com acesso indevido,
JOB problemático recorrente,
alerta de segurança ignorado.

Todo mundo acha “baixo risco”.

Até o desastre acontecer.

☠️ A HISTÓRIA — O NASCIMENTO DE UM OPERADOR DE GUERRA

Quando criança, o protagonista viu sua vila ser destruída por goblins.

Sua família foi massacrada.

Ele sobreviveu…
mas mentalmente ficou preso naquele evento.

A partir desse dia:

abandonou sonhos,
humanidade,
emoções comuns,
vida social.

Ele virou uma máquina operacional dedicada a uma única função:

exterminar goblins.

E isso é importante:

Goblin Slayer NÃO é um herói clássico.

Ele não luta por glória.
Não busca reconhecimento.
Não quer salvar o mundo.

Ele apenas executa sua rotina de contenção de ameaça.

Como um operador veterano de datacenter às 3h da manhã tentando impedir um ABEND catastrófico.

⚔️ O DIFERENCIAL DO ANIME

A maioria dos animes fantasy usa:

poder mágico absurdo,
protagonistas invencíveis,
batalhas épicas exageradas.

Goblin Slayer faz o oposto.

Aqui:

qualquer erro mata,
recursos são limitados,
estratégia importa,
logística importa,
conhecimento operacional importa.

O protagonista vence porque:

estuda comportamento inimigo,
usa armadilhas,
manipula ambiente,
controla fluxo de batalha,
improvisa.

Ele parece um sysprog combatendo incidentes críticos com:

dump analysis,
contenção,
automação,
isolamento de falha,
recuperação controlada.

🧠 TEMÁTICAS OCULTAS

☕ Trauma e PTSD

Goblin Slayer é profundamente sobre trauma psicológico.

O protagonista vive em modo permanente de alerta.

Ele nunca “desliga”.

Como profissionais de ambientes críticos que vivem anos em stress operacional extremo.

☕ Obsessão Operacional

Ele transforma dor em rotina.

Cada missão:

checklist,
análise,
execução,
limpeza.

Praticamente um batch noturno humano.

☕ O Perigo da Subestimação

Essa é talvez a maior mensagem do anime:

o sistema não cai pelos monstros gigantes.
ele cai pelas pequenas falhas ignoradas durante anos.

Isso é extremamente “mainframe”.

👥 PERSONAGENS PRINCIPAIS

🗡️ Goblin Slayer

Um guerreiro silencioso, paranoico e brutalmente eficiente.

Ele é praticamente:

um operador de produção traumatizado transformado em arma tática.

⛪ Priestess

A novata idealista que entra no grupo após sobreviver ao horror do primeiro episódio.

Ela representa:

inocência,
esperança,
humanidade.

É como o trainee chegando no datacenter e descobrindo que produção real não é igual laboratório.

🏹 High Elf Archer

Caótica, energética e impulsiva.

Contrasta completamente com a frieza operacional do Goblin Slayer.

🪓 Dwarf Shaman

O veterano experiente.

Praticamente o operador antigo que já viu 40 anos de incidentes em produção.

🦎 Lizard Priest

Um dos personagens mais curiosos.

Mistura sabedoria, brutalidade e humor estranho.

💀 O PRIMEIRO EPISÓDIO E A POLÊMICA

O episódio 1 virou um terremoto cultural.

Muita gente esperava um fantasy tradicional…

e recebeu um horror brutal.

O anime foi acusado de:

violência extrema,
conteúdo perturbador,
excesso de brutalidade,
choque gratuito.

Houve:

censura parcial em algumas transmissões,
cortes em canais específicos,
avisos de conteúdo adulto.

Mesmo assim…

a controvérsia impulsionou a fama mundial da obra.

🔥 IMPACTO CULTURAL

Goblin Slayer ajudou a consolidar o retorno do:

dark fantasy pesado,
fantasy brutal,
medieval sombrio,
realismo violento em anime.

Após seu sucesso, aumentou muito o interesse por obras semelhantes como:

Berserk,
Claymore,
Grimgar,
Made in Abyss (lado sombrio),
Redo of Healer.

🖥️ O ANIME COMO UMA METÁFORA DE MAINFRAME

Goblin Slayer parece um ambiente z/OS antigo:

silencioso,
eficiente,
resiliente,
assustadoramente estável.

Mas funcionando à custa de operadores traumatizados tentando impedir o caos diariamente.

O protagonista é literalmente:

“o sysprog que ninguém valoriza… até o sistema entrar em colapso.”

☕ MENSAGEM FINAL DA OBRA

Goblin Slayer fala sobre:

cicatrizes invisíveis,
sobrevivência,
disciplina,
paranoia,
preparo,
consequências reais.

E principalmente:

o perigo de ignorar ameaças pequenas só porque parecem insignificantes.

Porque no fim…

não são os dragões que derrubam o sistema.

São os goblins esquecidos no subterrâneo do datacenter.

sábado, 29 de setembro de 2018

🔥 JCL no z/OS V2R3 — o veterano que aprendeu a viver no mundo híbrido

Bellacosa Mainframe apresenta JCL Job Control Language V2R3

🔥 JCL no z/OS V2R3 — o veterano que aprendeu a viver no mundo híbrido

📅 Datas importantes

Release (GA): setembro de 2018
Final de suporte IBM: 30 de setembro de 2023

O z/OS V2R3 não tentou “modernizar” o JCL na marra. Ele fez algo melhor:
colocou o JCL no centro do mainframe conectado ao mundo cloud, API e DevOps.

🧬 Contexto histórico

Quando o z/OS V2R3 chegou, o cenário era curioso:

Mainframe totalmente vivo
Linux on Z crescendo
APIs expostas para o mundo
DevOps já batendo na porta do data center
Cloud híbrida deixando de ser discurso

E no meio disso tudo…
👉 o JCL continuava sendo o maestro silencioso do batch corporativo.

Bellacosa diria:

“Enquanto o pessoal discute pipeline em YAML, o JCL fecha a contabilidade do dia.”

JCL Job Control Language V2R3

✨ O que há de novo no JCL (indiretamente) no V2R3

O JCL não muda a sintaxe, mas o contexto muda bastante.

🆕 1. JCL como backend de automação moderna

No V2R3, é comum ver:

Jobs disparados por:
- REST APIs
- ferramentas DevOps
- schedulers inteligentes
JCL sendo tratado como contrato operacional estável

👉 O JCL vira “infraestrutura como código”… antes disso virar moda.

🆕 2. Melhor convivência com z/OS Connect e middleware

Batch acionado por eventos externos
Processos online + batch integrados
JCL executando tarefas críticas iniciadas fora do mainframe

O batch deixou de ser “janela noturna isolada”.

🆕 3. JES2 e DFSMS ainda mais maduros

Spool mais estável
Melhor gerenciamento de grandes volumes de dados
Menos tuning manual
Mais previsibilidade operacional

🔧 Melhorias percebidas no dia a dia

✔ Jobs mais previsíveis em ambientes enormes
✔ Menos dependência de “magia do operador”
✔ Mais uso de IF/THEN/ELSE em vez de COND
✔ JCL tratado como ativo estratégico

Nada de comando novo — só robustez acumulada.

🥚 Easter Eggs (para quem viveu o V2R3)

🥚 Jobs escritos no OS/390 rodando felizes no V2R3
🥚 IEFBR14 ainda sendo usado em ambientes “cloud native” 😅
🥚 Comentários no JCL mais antigos que muitos analistas
🥚 O erro campeão seguia sendo:
- dataset em uso
- DISP mal pensado
- SPACE subestimado

💡 Dicas Bellacosa para JCL no z/OS V2R3

🔹 Escreva JCL pensando em longevidade

Esse job vai sobreviver a você.

🔹 Prefira:

IF / THEN / ELSE / ENDIF
RC bem tratado
mensagens claras no SYSOUT

🔹 Documente o porquê, não só o como

🔹 Leia JESMSGLG como se fosse log de produção crítica — porque é.

📈 Evolução do JCL até o V2R3

Fase	Papel do JCL
OS/360	Controle de jobs
MVS	Automação batch
OS/390	Espinha dorsal corporativa
z/OS V1.x	Orquestrador do data center
z/OS V2R3	Fundação do mundo híbrido

👉 No V2R3, o JCL deixa claro:
não é legacy — é legado confiável.

📜 Exemplo de JCL “cara de V2R3”


//BELLV23  JOB (ACCT),'JCL z/OS V2R3',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*
//STEP01   EXEC PGM=MYBATCH
//STEPLIB  DD  DSN=BELLACOSA.LOADLIB,DISP=SHR
//SYSOUT   DD  SYSOUT=*
//*
//IF (STEP01.RC = 0) THEN
//STEP02   EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DELETE BELLACOSA.ARQ.TEMP
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Esse JCL pode ser disparado por um operador, um scheduler
ou uma API REST. Ele não se importa. Ele entrega.”

🧠 Comentário final

O JCL no z/OS V2R3 representa a maturidade absoluta:

Sem hype
Sem ruptura
Sem necessidade de provar nada

Enquanto tecnologias modernas tentam alcançar estabilidade,
o JCL já está lá há décadas.

🔥 JCL não concorre com o futuro.
Ele garante que o futuro funcione.

sexta-feira, 28 de setembro de 2018

IBM Mainframe Discovery : Capítulo IX — A Federação das Naves Invisíveis

Bellacosa Mainframe apresenta ibm mainframe parte ix

☕ Um Café no Bellacosa Mainframe

Capítulo IX — A Federação das Naves Invisíveis

PR/SM, LPARs e Virtualização: Como Um Único Computador se Transformou em uma Galáxia Inteira

SEXTA REGRA DAS GRANDES CIVILIZAÇÕES

Nunca compre uma nave espacial apenas porque ela é enorme.

Pergunte primeiro:

Quantas civilizações diferentes conseguem viver dentro dela sem começar uma guerra?

Parece uma pergunta estranha.

Mas foi exatamente essa pergunta que a IBM respondeu décadas atrás.

Imagine uma nave gigantesca.

Dentro dela vivem:

uma federação de banqueiros;
um grupo de cientistas;
uma academia militar;
uma universidade;
um hospital;
uma estação meteorológica;
uma fábrica de robôs.

Todos utilizam o mesmo casco.

A mesma energia.

Os mesmos motores.

Mas nenhum deles sabe que os outros existem.

Parece magia.

Não é.

É virtualização.

O Grande Apartamento Cósmico

Imagine um prédio com cem apartamentos.

Todos compartilham:

fundação;
elevadores;
telhado;
energia elétrica;
encanamento.

Mas cada morador acredita possuir sua própria casa.

O IBM Z faz exatamente isso.

Só que em escala planetária.

Antes da Virtualização

Voltemos algumas décadas.

Você precisava de um servidor para:

Banco.

Outro para RH.

Outro para folha.

Outro para testes.

Outro para desenvolvimento.

Outro para homologação.

Resultado?

Salas inteiras cheias de computadores.

Baixa utilização.

Muito calor.

Muito desperdício.

Então Surgiu Uma Ideia Revolucionária

Um engenheiro olhou para aquele enorme computador e perguntou:

"Por que não dividir essa nave em várias menores?"

Hoje isso parece óbvio.

Na década de 1970 era praticamente ficção científica.

A Grande Mágica

Imagine um teatro.

Existe apenas um palco.

Mas cinco peças diferentes acontecem simultaneamente.

Cada plateia acredita que ocupa o teatro inteiro.

Como isso seria possível?

No IBM Z isso acontece todos os dias.

Cada ambiente acredita possuir:

sua própria CPU.

sua própria memória.

seus próprios discos.

seu próprio sistema operacional.

Na realidade...

todos compartilham o mesmo hardware.

Conheça o PR/SM

Nos bastidores existe um personagem extremamente discreto.

Seu nome é:

PR/SM

Processor Resource/System Manager.

Pense nele como o administrador da estação espacial.

Ele decide:

quem recebe CPU.

quem recebe memória.

quem recebe canais de I/O.

quem pode utilizar determinado recurso.

Segundo Wilhelm G. Spruth, o PR/SM é responsável por particionar logicamente um único sistema físico em ambientes completamente independentes, oferecendo isolamento em nível de hardware.

As LPARs — Pequenos Universos

Agora chegamos às estrelas principais deste capítulo.

As famosas:

LPARs

(Logical Partitions).

Imagine uma gigantesca nave.

Agora coloque dentro dela:

USS Alpha.

USS Beta.

USS Gamma.

USS Delta.

Cada nave possui:

tripulação.

missões.

comandante.

computadores.

sistemas.

Elas dividem o mesmo casco.

Mas vivem vidas completamente independentes.

Cada LPAR acredita ser um computador completo.

E, do ponto de vista do sistema operacional...

ela realmente é.

Um Hotel de Luxo

Imagine um hotel.

Cada hóspede possui:

quarto.

banheiro.

telefone.

televisão.

Wi-Fi.

Ar-condicionado.

Nenhum hóspede invade o quarto do outro.

As LPARs seguem exatamente esse princípio.

Cada uma recebe recursos exclusivos.

Segurança.

Isolamento.

Previsibilidade.

O Vizinho Barulhento Não Existe

Você já morou perto de alguém que fazia festa às três da manhã?

No IBM Z isso seria inaceitável.

Uma LPAR não pode consumir recursos pertencentes à outra.

O PR/SM garante essa separação.

Mesmo que uma aplicação apresente problemas...

as demais continuam funcionando normalmente.

Compartilhar Não Significa Misturar

Essa é uma lição importante.

Compartilhar hardware não significa compartilhar tudo.

Imagine um prédio.

Os apartamentos compartilham:

estrutura.

água.

energia.

Mas ninguém compartilha:

escova de dentes.

geladeira.

conta bancária.

O isolamento permanece absoluto.

CPU Compartilhada ou Dedicada?

Agora imagine uma frota espacial.

Algumas naves possuem pilotos exclusivos.

Outras utilizam pilotos compartilhados.

No IBM Z acontece exatamente isso.

Uma LPAR pode receber:

CPUs dedicadas

CPUs compartilhadas.

O administrador escolhe conforme a necessidade.

O Maestro Continua Trabalhando

Lembra do Supervisor?

Agora ele ganhou um chefe.

O PR/SM coordena as LPARs.

Dentro de cada LPAR...

o Supervisor organiza seus próprios programas.

É uma hierarquia elegante.

Como uma federação.

Cada planeta governa seus habitantes.

Mas existe um conselho superior distribuindo recursos entre todos.

E Se Uma LPAR Travar?

Imagine um apartamento.

O morador derruba uma estante.

Os outros apartamentos continuam intactos.

O mesmo ocorre aqui.

Uma LPAR pode sofrer problemas.

As demais continuam operando normalmente.

Esse isolamento é um dos pilares da confiabilidade do IBM Z.

O Grande Restaurante Galáctico

Imagine um restaurante gigantesco.

Existem:

clientes VIP.

turistas.

tripulações.

embaixadores.

Todos utilizam a mesma cozinha.

Mas recebem atendimento diferente.

O PR/SM faz algo semelhante.

Distribui recursos conforme prioridades.

Sem desperdício.

Dynamic LPAR

Agora imagine algo curioso.

Enquanto a nave está viajando...

você aumenta o tamanho de um dos apartamentos.

Sem parar a nave.

Sem desligar motores.

Sem evacuar passageiros.

Isso existe.

Chama-se:

Dynamic LPAR.

Processadores, memória e alguns recursos podem ser adicionados ou removidos dinamicamente, reduzindo drasticamente interrupções operacionais.

O Universo Está Vivo

As necessidades mudam.

Às nove da manhã:

Banco precisa de mais CPU.

À meia-noite:

Batch precisa crescer.

Domingo:

Homologação precisa de recursos.

Segunda-feira:

Desenvolvimento aumenta.

Tudo isso pode acontecer dinamicamente.

WLM Entra em Cena

Agora surge outro personagem.

O famoso:

Workload Manager.

Imagine um gerente de aeroporto.

Ele percebe:

"A pista internacional está lotada."

Então redistribui equipes.

Abre novos portões.

Prioriza determinados voos.

O WLM faz exatamente isso com cargas de trabalho.

Ele conversa continuamente com o PR/SM para ajustar a distribuição dos recursos conforme os objetivos definidos pela instalação.

A Grande Ilusão

Curiosamente...

o sistema operacional nunca percebe toda essa complexidade.

O z/OS acredita possuir um computador inteiro.

Linux acredita possuir outro.

z/VM acredita possuir outro.

Todos vivem felizes.

Enquanto o PR/SM coordena silenciosamente tudo nos bastidores.

A Virtualização Não Nasceu Ontem

Existe um mito curioso.

Muita gente acredita que virtualização começou com VMware.

Ou Hyper-V.

Ou KVM.

Na realidade...

o universo Mainframe experimentava esses conceitos décadas antes.

Spruth destaca a virtualização por hardware como uma das características distintivas do System z, muito antes de ela se tornar comum em servidores distribuídos.

Isso não diminui a importância das plataformas modernas.

Mas mostra como muitas ideias consideradas "novas" possuem raízes muito mais antigas.

Hipersockets — O Teletransporte

Imagine duas naves estacionadas lado a lado.

Tradicionalmente...

elas conversariam usando rádio.

No IBM Z surgiu outra ideia.

Por que usar cabos...

...se ambas vivem dentro da mesma nave?

Assim nasceram os:

Hipersockets.

Eles permitem comunicação extremamente rápida entre LPARs, utilizando memória em vez de redes físicas.

É quase um teletransporte de mensagens.

Spruth apresenta os Hipersockets como um mecanismo de comunicação interna de altíssimo desempenho entre partições lógicas.

Uma Cidade Dentro de Outra Cidade

Imagine uma metrópole.

Dentro dela existe outra cidade.

Dentro dessa cidade...

outra.

Parece impossível.

Mas no IBM Z isso também acontece.

Uma LPAR pode executar:

z/VM.

Dentro do z/VM surgem:

centenas.

milhares.

de máquinas virtuais Linux.

Uma verdadeira galáxia de computadores vivendo dentro de outro computador.

O Que Mudou Desde 2010?

Desde que Spruth escreveu seu relatório, a virtualização evoluiu ainda mais.

Hoje encontramos:

dezenas de TB de memória por sistema;
milhares de máquinas Linux simultâneas;
OpenShift nativo;
Kubernetes;
containers;
Secure Execution;
integração híbrida com nuvem;
LinuxONE;
IA embarcada.

Mas o conceito permanece idêntico.

Um único computador.

Múltos mundos.

Perfeitamente isolados.

Uma Lição Para a Vida

Existe uma filosofia escondida neste capítulo.

Uma grande cidade não precisa eliminar diferenças.

Ela precisa organizá-las.

Cada LPAR possui sua missão.

Seu ritmo.

Sua prioridade.

Seu sistema operacional.

Sua cultura.

Mesmo assim...

todas cooperam utilizando a mesma infraestrutura.

Talvez essa seja uma das metáforas mais bonitas da engenharia.

Curiosidades do Diário de Bordo

🚀 O PR/SM é certificado em altos níveis de segurança e isolamento, permitindo que ambientes com diferentes requisitos coexistam no mesmo hardware físico.

🛰️ Hipersockets eliminam boa parte da latência de comunicação entre LPARs ao manter o tráfego inteiramente dentro do sistema.

🖥️ Um único IBM Z pode hospedar simultaneamente z/OS, Linux, z/VM e outros ambientes, cada um acreditando possuir sua própria máquina.

🌌 A virtualização em hardware do IBM Z antecedeu em muitos anos a popularização da virtualização em servidores x86.

Diário de Bordo do Padawan COBOL

Antes de deixar a Federação das LPARs, registre estas coordenadas no seu Holocron Técnico:

✅ Virtualização não significa apenas dividir recursos; significa criar ambientes independentes, seguros e previsíveis.

✅ O PR/SM atua como o grande administrador da nave, distribuindo CPU, memória e I/O entre diferentes partições.

✅ As LPARs permitem consolidar múltiplos sistemas em um único hardware sem sacrificar isolamento ou desempenho.

✅ Muitas tecnologias modernas de consolidação e computação em nuvem seguem princípios que o IBM Z já aplicava décadas antes.

Missão Seguinte

No próximo capítulo faremos um salto para uma das tecnologias mais impressionantes do universo IBM Z: o Parallel Sysplex e a Coupling Facility.

Descobriremos como várias naves conseguem pensar como uma só, compartilhar dados em tempo real e continuar operando mesmo quando uma delas sai de combate. Se as LPARs transformaram um computador em vários mundos, o Parallel Sysplex transformará vários computadores em uma única civilização galáctica.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.