✨ 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
Bellacosa Mainframe apresenta o maestro invisivel do Mainframe: WLM
🚀 O Maestro Invisível do Mainframe: Como o WLM Decide Quem Vive, Quem Espera e Quem Domina o IBM Z
“O z/OS não é apenas um sistema operacional. É um sistema de sobrevivência computacional — e o WLM é seu cérebro.”
Se você é um padawan do mainframe 🧙♂️, há um momento em que tudo muda.
Você deixa de ver jobs, CICS e DB2 como coisas isoladas… e passa a enxergar um ecossistema vivo, onde milhares de tarefas lutam pelos mesmos recursos.
Nesse universo, existe um árbitro supremo:
🧠 Workload Manager — WLM
Sem ele, um mainframe moderno seria apenas um supercomputador caro brigando consigo mesmo.
🏛️ Antes do WLM: o caos elegante dos anos 70 e 80
Nos primórdios do MVS, a prioridade era… manual.
Operadores e sysprogs definiam:
Prioridades fixas
Classes de execução estáticas
Ajustes “no feeling”
Reconfiguração constante
Problemas clássicos:
💥 Batch travando online
💥 CICS lento em horário de pico
💥 CPU livre e usuários reclamando
💥 Sistema imprevisível
O hardware evoluiu. O software também precisava evoluir.
⚙️ O nascimento do WLM — computação orientada ao negócio
O WLM moderno surgiu com o OS/390 nos anos 90.
A ideia foi revolucionária:
❌ Não gerenciar processos
✅ Gerenciar objetivos de negócio
Você não diz:
👉 “Este job tem prioridade 8”
Você diz:
👉 “Quero que 90% das transações respondam em até 1 segundo”
O sistema decide como chegar lá.
🎼 O WLM é um maestro, não um executor
Ele não executa código.
Ele coordena:
Dispatcher (CPU)
IOS (I/O)
Memory manager
PR/SM (hardware)
Subsystems (CICS, DB2, etc.)
Política → Prioridade → Recursos → Execução
🧩 Os elementos fundamentais do WLM
🏷️ Service Class — “Quem é você?”
Categoria de workload com tratamento específico.
Exemplos reais:
CICS_ONLINE
DB2_OLTP
BATCH_HIGH
TSO_USERS
DISCRETIONARY
Uma única classe pode representar centenas de workloads.
🎯 Goal — “O que esperamos de você?”
Tipos principais:
⏱️ Response Time — tempo de resposta
⚡ Velocity — progresso contínuo
💤 Discretionary — use as sobras
⭐ Importance — “Quão importante você é?”
Escala de 1 a 5:
1️⃣ Missão crítica
5️⃣ Pode esperar
Sob escassez, isso decide tudo.
⏱️ Performance Periods — prioridade dinâmica
Uma obra-prima do design do WLM.
Permite tratar o mesmo trabalho de forma diferente ao longo do tempo.
Exemplo típico:
Período 1 — Importance 1 — resposta rápida Período 2 — Importance 3 — menos crítico Período 3 — Discretionary — só sobras
👉 Protege o sistema contra trabalhos “runaway”.
🧭 Classification Rules — o roteador automático
Determinam qual workload entra em qual Service Class.
Critérios possíveis:
Job name
User ID
Address space name
Transaction name (CICS)
Atributos de enclave
Padrões (wildcards)
💎 Curiosidade: também podem marcar workloads como Storage Critical.
⚡ Dispatchable Units — quem realmente roda
O dispatcher não agenda jobs.
Ele agenda DUs:
🧾 TCB — tasks de aplicação
⚡ SRB — trabalho de sistema
Múltiplas DUs podem rodar simultaneamente no mesmo address space.
🧮 Dispatching Priority — o número mágico
Escala: 0–255 (geralmente >190)
👉 Maior valor ⇒ maior chance de CPU
Mostrado no SDSF (painel DA).
É recalculado constantemente pelo WLM.
📀 I/O Priority e Memory
O WLM também influencia:
📀 I/O
Prioridade de acesso a discos
Filas de dispositivos
Latência de storage
Sem grupos específicos:
👉 I/O priority = Dispatching priority
💾 Storage Critical
Protege workloads contra swap.
Não dá mais memória — evita que sejam expulsos da RAM.
Crucial para:
CICS
DB2
Middleware
Serviços online
🩸 Donor vs Receiver — economia de recursos
Sob escassez:
🏆 Receivers → precisam cumprir metas
🩸 Donors → cedem recursos
💤 Discretionary → só sobras
Regra importante:
👉 Só doa quem está usando.
🧠 Enclaves — workloads distribuídos
Representam trabalho que atravessa múltiplos address spaces.
Muito usados em:
DB2 DDF
APIs
Java servers
MQ
Middleware
Permitem controle ponta a ponta.
🧪 Curiosidades e Easter Eggs
💎 O WLM é considerado uma das maiores vantagens competitivas do mainframe.
💎 Muitos conceitos de QoS em cloud vieram daqui.
💎 Sistemas distribuídos ainda lutam para replicar essa sofisticação.
💎 O mainframe pode parecer “antigo”, mas seu scheduler é mais avançado que o de muitos sistemas modernos.
💥 Falhas mais comuns em produção
❌ Políticas mal projetadas
Sintomas:
CPU alta sem ganho real
Online lento
Batch dominando horários críticos
❌ Service Classes demais
Complexidade gera comportamento imprevisível.
❌ Classificação incorreta
Workloads críticos tratados como comuns.
❌ Ignorar Performance Periods
Trabalhos longos monopolizam recursos.
🛠️ Como controlar e acompanhar
Ferramentas principais:
🖥️ SDSF
DA — Address Spaces ativos
ENCLAVES — workloads distribuídos
ST — Jobs
📊 RMF
Análise profunda de performance.
⚙️ WLM ISPF / z/OSMF
Configuração de políticas.
📈 SMF records
Base para capacity planning e auditoria.
🧭 Como pensar como um especialista
Quando algo está lento, pergunte:
👉 Qual recurso está saturado?
👉 Quem está consumindo?
👉 Esse workload deveria ter essa prioridade?
👉 O WLM está cumprindo ou ignorando metas?
🏆 A verdade final
O poder do mainframe não está apenas no hardware.
Está na capacidade de usar recursos de forma:
✔️ previsível
✔️ controlada
✔️ orientada ao negócio
✔️ resiliente sob carga extrema
🧠 Frase para levar para a vida
WLM não decide quem roda primeiro.
Ele decide quais objetivos do negócio serão preservados quando os recursos acabarem.
Bellacosa Mainframe e os containers dockers e kubernetes
☕ Um Café no Bellacosa Mainframe
🕵️♂️ Tintin na Terra dos Containers — O Mistério de Docker & Kubernetes
Uma investigação entre imagens, containers, Pods, Deployments e clusters — porque até Tintin descobriria que colocar uma aplicação em produção é muito mais complicado do que embarcar no Sirius.
Caso nº 03:17 — Arquivo confidencial do Bellacosa Mainframe Destino: Produção Suspeitos: Docker, Kubernetes e algumas dezenas de arquivos YAML Situação: aparentemente simples. Portanto, extremamente suspeita.
Tintin estava acostumado a situações complicadas.
Já havia enfrentado falsificadores, contrabandistas, sociedades secretas, ditadores, traficantes, cientistas excêntricos e até viajado à Lua.
Mas naquela manhã encontrou algo muito mais perigoso.
Um desenvolvedor havia pronunciado a frase:
— Na minha máquina funciona.
Milou levantou as orelhas.
Capitão Haddock largou o café.
Professor Girassol continuou mexendo em alguma coisa que provavelmente explodiria antes do almoço.
Tintin abriu seu pequeno caderno.
Novo caso.
Precisávamos descobrir como levar uma aplicação desde o notebook de um programador até produção sem depender da configuração particular daquela máquina.
E nossa investigação começaria com uma criatura chamada container.
📰 1. O estranho caso da aplicação que funcionava ontem
Imagine que nosso jovem programador COBOL decidiu aprender Python e criou uma pequena API usando FastAPI.
No computador dele tudo funciona.
Python instalado.
Bibliotecas instaladas.
Variáveis configuradas.
Banco de dados acessível.
Portas abertas.
Versões corretas.
Ele entrega o programa para Haddock.
Haddock tenta executá-lo.
Nada funciona.
— MIL MILHÕES DE MILHARES DE BIBLIOTECAS INCOMPATÍVEIS!
Eis um problema muito antigo da computação.
O programa não existe sozinho.
Ele depende de um ambiente.
No universo mainframe conhecemos isso muito bem. Um programa COBOL pode depender de determinada versão de runtime, Db2, CICS, arquivos, configurações, parâmetros, bibliotecas e permissões.
No mundo distribuído ocorre exatamente o mesmo fenômeno.
Agora descrevemos uma pequena aplicação multi-container declarativamente.
Essa é uma das grandes virtudes do Compose.
Em vez de Haddock precisar decorar quinze comandos, declaramos como o ambiente deve ser.
Um detalhe merece atualização nos materiais mais antigos: no Compose moderno, aquele tradicional:
version: "3.8"
não é mais necessário. A documentação do Docker classifica a propriedade superior version como obsoleta e meramente informativa; o Compose moderno trabalha com a Compose Specification. (Docker Documentation)
É um belo exemplo de por que bons cursos técnicos precisam ser revisados continuamente.
Ele é uma plataforma de orquestração de workloads containerizados.
Seu grande truque filosófico está no conceito de estado desejado.
Nós declaramos algo como:
QUERO 3 RÉPLICAS DESTA APLICAÇÃO.
O sistema observa:
DESEJADO = 3
ATUAL = 3
Tudo certo.
Um Pod desaparece:
DESEJADO = 3
ATUAL = 2
Existe divergência.
Os controladores trabalham para retornar ao estado desejado:
DESEJADO = 3
ATUAL = 3
Isso é extraordinariamente importante.
O operador deixa de pensar apenas:
“execute este comando.”
e passa também a pensar:
“este é o estado que quero manter.”
Quem conhece automação operacional, WLM e políticas em ambientes corporativos provavelmente já começou a enxergar pontes conceituais.
🏰 11. Tintin entra no cluster
Um cluster Kubernetes possui componentes de controle e nós onde workloads são executados.
De forma simplificada:
KUBERNETES CLUSTER
┌─────────────────────────┐
│ CONTROL PLANE │
│ │
│ API Server │
│ Scheduler │
│ Controller Manager │
│ etcd │
└────────────┬────────────┘
│
───────────┼───────────
│
┌─────────────┴─────────────┐
WORKER NODE WORKER NODE
┌──────────────┐ ┌──────────────┐
│ kubelet │ │ kubelet │
│ runtime │ │ runtime │
│ │ │ │
│ Pod Pod Pod │ │ Pod Pod Pod │
└──────────────┘ └──────────────┘
O API Server é uma peça central da interface de controle.
O scheduler ajuda a decidir onde Pods serão colocados.
Os controllers observam o estado e trabalham para reconciliá-lo.
O etcd mantém dados importantes do estado do cluster.
E nos workers temos, entre outros componentes, o kubelet e um runtime de containers.
🐳 12. Haddock encontra uma pista desatualizada
Em algum velho mapa Tintin encontra:
Kubernetes → Docker
— Caso encerrado! — grita Haddock.
Não tão depressa.
Aqui existe uma atualização histórica importantíssima.
Kubernetes removeu seu dockershim integrado a partir da versão 1.24. Kubernetes moderno trabalha através da Container Runtime Interface — CRI, com runtimes compatíveis, como containerd e CRI-O; Docker Engine ainda pode ser integrado por um adaptador como cri-dockerd. (Kubernetes)
Isso não significa que imagens construídas com Docker deixaram de funcionar no Kubernetes. A própria documentação explica que usar Docker para construir imagens não cria uma dependência de Docker como runtime do cluster. (Kubernetes)
Portanto nosso mapa mental moderno é melhor representado assim:
E Docker continua extremamente útil no workflow de desenvolvimento e construção de imagens.
Pista nº 12: Docker não morreu no Kubernetes. Mudou a relação arquitetural entre eles.
📦 13. O menor quarto do hotel: Pod
Chegamos agora a uma das palavras mais importantes de Kubernetes:
Pod.
Pod é a menor unidade implantável de computação que Kubernetes gerencia.
Normalmente encontramos um container principal dentro dele, embora um Pod possa conter mais de um container quando esses processos precisam compartilhar estreitamente recursos e ciclo de vida.
E por isso normalmente não administramos aplicações complexas criando Pods soltos manualmente.
Entra outra testemunha.
🧬 14. Deployment → ReplicaSet → Pods
Para uma aplicação típica, podemos declarar um Deployment.
Por exemplo:
replicas: 3
Conceitualmente:
Deployment
│
▼
ReplicaSet
│
┌───┼───┐
▼ ▼ ▼
Pod Pod Pod
Se um desaparece:
Pod ✖
o sistema trabalha para restaurar o estado desejado.
Isso também permite realizar rolling updates.
Em vez de:
VERSÃO 1
↓
DESLIGA TUDO
↓
VERSÃO 2
podemos substituir progressivamente instâncias antigas por novas.
E, quando necessário, trabalhar com mecanismos de rollback.
Haddock começa a gostar da história.
Produção sem uma gigantesca janela de “desliga tudo e reza” realmente parece civilização.
📞 15. Mas como encontramos esses Pods?
Temos outro problema.
Pods são efêmeros.
Se ficarmos distribuindo seus endereços diretamente, criamos dependências frágeis.
Entra o objeto Service.
Imagine:
CLIENTE
│
▼
SERVICE
│
┌─┼───────────┐
▼ ▼ ▼
POD A POD B POD C
O Service fornece uma abstração estável para alcançar determinado conjunto de Pods.
Essa é uma mudança mental importantíssima:
não procure indivíduos; procure o serviço.
Para um programador mainframe acostumado com um endpoint lógico de uma aplicação transacional, a ideia começa a soar curiosamente familiar.
🗺️ 16. ConfigMap e o documento que não deveria conter a senha
Nossa aplicação precisa saber:
LOG_LEVEL=INFO
LANGUAGE=pt_BR
FEATURE_X=true
Esses valores podem estar em um ConfigMap.
Mas temos também:
PASSWORD
TOKEN
API_KEY
CERTIFICATE
Aí entramos no território dos Secrets.
Contudo, há uma pegadinha digna dos irmãos Dupond e Dupont:
— Está em Base64, portanto está criptografado!
— Exatamente! E eu diria ainda mais: está criptografado porque está em Base64!
Errado duas vezes.
A documentação oficial é explícita: Base64 não é criptografia. Kubernetes Secrets podem ser armazenados sem criptografia por padrão; ambientes sérios precisam considerar controles como RBAC, restrição de acesso, criptografia em repouso e soluções apropriadas de gerenciamento de segredos. (Kubernetes)
Portanto:
ConfigMap
↓
configuração não confidencial
Secret
↓
informação confidencial
↓
+ controle de acesso
+ proteção apropriada
+ encryption at rest quando aplicável
+ gestão segura do ciclo de vida
Esse é um ponto que merece enorme atenção em qualquer treinamento.
🗄️ 17. O banco não pode desaparecer novamente
Voltamos ao problema de persistência.
No Kubernetes encontramos conceitos como:
PersistentVolume — PV
e
PersistentVolumeClaim — PVC
Didaticamente:
POD
│
▼
PVC
│
▼
PV
│
▼
STORAGE
O PVC representa a solicitação de armazenamento feita pelo workload.
O PV representa o recurso persistente disponibilizado ao cluster, dependendo do modelo e provisionamento utilizado.
Em ambientes modernos existe ainda toda uma camada envolvendo StorageClass, provisionamento dinâmico e CSI.
Mas para nossa primeira investigação basta guardar:
Pod é descartável; dado importante não pode depender da sobrevivência daquele Pod.
🩺 18. Professor Girassol inventa três estetoscópios
Agora precisamos saber se a aplicação está saudável.
Kubernetes trabalha com probes que respondem perguntas diferentes.
Startup probe:
Você conseguiu iniciar?
Liveness probe:
Você continua vivo?
Readiness probe:
Você está pronto para receber tráfego?
Essas perguntas parecem semelhantes.
Não são.
Imagine uma aplicação Java que demora bastante para iniciar.
Ela pode estar viva, mas ainda não pronta para atender.
Ou uma aplicação pode continuar com processo existente, mas ter entrado em um estado do qual não consegue se recuperar adequadamente.
Misturar esses conceitos pode produzir exatamente o tipo de incidente que começa às...
03:17.
Pronto.
Easter egg encontrado. ☕😎
🚪 19. Tintin chega ao portão: Ingress
Agora temos serviços funcionando dentro do cluster.
Mas usuários precisam chegar até eles.
Tradicionalmente, Kubernetes utiliza Ingress para definir roteamento HTTP/HTTPS externo, associado a uma implementação/controlador.
Conceitualmente:
INTERNET
│
▼
INGRESS
│
├── /api ─────► Service API
│ │
│ Pods
│
└── /web ─────► Service WEB
│
Pods
Ingress continua sendo um conceito importante porque existem enormes ambientes usando-o.
Porém nosso curso de 2026 precisa colocar uma anotação vermelha no caderno de Tintin:
⚠️ EXISTE UM NOVO CAPÍTULO
O ecossistema Kubernetes está avançando para Gateway API como abordagem moderna e mais expressiva para networking. Em agosto de 2026, o projeto anunciou Gateway API v1.6, incluindo TCPRoute e UDPRoute no canal Standard. (Kubernetes)
Há inclusive tooling oficial para ajudar migrações de Ingress para Gateway API. (Kubernetes)
Portanto um curso atualizado deveria ensinar:
Ingress
│
├── importantíssimo para ambientes existentes
│
└── API congelada para novos recursos
│
▼
Gateway API
caminho moderno
Esse pequeno detalhe separa uma apostila histórica de uma formação preparada para os próximos anos.
📈 20. De repente chegam dez mil usuários
Haddock finalmente publica seu sistema.
Um usuário acessa.
Tudo funciona.
Dez acessam.
Tudo funciona.
Mil acessam.
Haddock começa a suar.
Dez mil acessam.
— ESCALABILIDADE DOS SETE MARES!
Kubernetes oferece mecanismos de escalabilidade, entre eles o Horizontal Pod Autoscaler — HPA.
Quando a demanda diminui, a quantidade pode ser reduzida segundo a configuração e comportamento do autoscaler.
CPU e memória são excelentes exemplos introdutórios, embora arquiteturas reais possam utilizar outras métricas conforme a infraestrutura de métricas disponível.
Aqui encontramos uma ponte interessante com o universo mainframe.
Um profissional de WLM imediatamente perguntaria:
Qual é a política? Qual a prioridade? Qual o recurso disponível? Qual a métrica? Qual o objetivo de serviço?
Excelente.
Essa é exatamente a mentalidade que queremos preservar.
A tecnologia muda.
As boas perguntas sobrevivem.
🧠 21. Tintin monta o quadro completo
Depois de centenas de pistas espalhadas pela mesa, finalmente conseguimos enxergar nossa arquitetura.
INTERNET
│
▼
┌──────────────────┐
│ GATEWAY/INGRESS │
└────────┬─────────┘
│
▼
┌─────────┐
│ SERVICE │
└────┬────┘
│
┌────────┼────────┐
▼ ▼ ▼
POD POD POD
▲ ▲ ▲
└────────┼────────┘
│
ReplicaSet
▲
│
Deployment
│
desired replicas = 3
CONFIGURAÇÃO DADOS
ConfigMap PVC
Secrets │
▼
PV
│
▼
STORAGE
E por trás disso existe o cluster:
CONTROL PLANE
│
├── API Server
├── Scheduler
├── Controllers
└── etcd
│
▼
WORKER NODES
│
▼
kubelet
│
▼
CRI
│
container runtime
│
▼
Pods
Finalmente o mistério começa a fazer sentido.
🏦 22. E onde entra o mainframe nessa aventura?
Aqui está talvez a parte mais interessante para quem está entrando nesse mundo vindo de COBOL, CICS, Db2 e z/OS.
Você não precisa apagar quarenta anos de conhecimento para aprender containers.
Muito pelo contrário.
Quem passou anos pensando em disponibilidade, processamento transacional, controle de acesso, recuperação, armazenamento, capacidade, versionamento e produção já possui uma enorme bagagem conceitual.
E existe uma terceira passagem ainda mais interessante para nós:
Kubernetes + IBM Z + LinuxONE + OpenShift + z/OS
Aí a história deixa de ser simplesmente:
“mainframe versus cloud.”
Passa a ser:
“qual workload deve executar onde?”
Esse é um problema arquitetural muito mais adulto.
🚀 25. Bellacosa Containers 101 → 201 → 301
Eu transformaria todo esse material em uma trilha em três atos.
101 — Tintin descobre os containers: Linux essencial, Docker, imagens, containers, Dockerfile, registry, networking, volumes, environment variables, secrets e Compose.
201 — Tintin encontra Kubernetes: cluster, control plane, worker, kubectl, Pod, Deployment, ReplicaSet, Service, ConfigMap, Secret, PV/PVC, probes, requests/limits, Ingress, Gateway API e HPA.
301 — Tintin entra em produção: RBAC, namespaces, NetworkPolicy, CSI, Helm/Kustomize, observabilidade, segurança, CI/CD, GitOps, supply chain, OpenShift, LinuxONE/IBM Z e integração de workloads containerizados com serviços corporativos e z/OS.
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
