 |
| Bellacosa Mainframe e o Linux no Ibm Z |
☕ Um Café no Bellacosa Mainframe
🐊 CROCODILO DUNDEE NO OUTBACK DO IBM Z — QUANDO O PINGUIM ENCONTROU O MAINFRAME
Linux on Z, s390x, LPAR, PR/SM, IFL, z/VM, KVM, containers, OpenShift, APIs, DevOps, IA — e o dia em que Dundee descobriu que aquele “servidorzinho Linux” era, na verdade, um mainframe.
🎬 PRÓLOGO — ISSO NÃO É UM SERVIDOR. ISTO É UM SERVIDOR!
Nosso jovem programador COBOL caminhava tranquilamente pelos corredores do datacenter.
Ele conhecia aquele território.
COBOL?
Conhecia.
JCL?
Também.
CICS?
Estava começando.
Db2?
Já conseguia fazer um SELECT sem derrubar produção — o que, convenhamos, já é uma excelente habilidade para um Padawan.
Ele olhava para o IBM Z como quem observa uma enorme cidade murada:
IBM Z
│
└── z/OS
├── COBOL
├── JCL
├── CICS
├── Db2
├── IMS
├── VSAM
└── JES2
Na cabeça dele, aquilo era o mainframe.
Até encontrar Crocodilo Dundee sentado diante de um terminal.
Na tela aparecia:
$ uname -m
s390x
O jovem COBOL arregalou os olhos.
— Linux?
Dundee respondeu tranquilamente:
— Sim.
— No mainframe?
— Sim.
— Então é um Linux rodando dentro do z/OS?
Dundee sorriu.
Pegou seu enorme facão imaginário e respondeu:
— Você chama aquilo de mainframe?
Apontou para o desenho do jovem.
— Isto é um mainframe.
E desenhou:
IBM Z
│
PR/SM
│
┌──────────────┼──────────────┐
│ │ │
LPAR A LPAR B LPAR C
│ │ │
z/OS Linux z/VM
│ │ │
COBOL Linux Linux
CICS Apps Guests
Db2
O jovem ficou em silêncio.
Seu mapa do mundo acabara de aumentar.
Muito.
Pegue seu café.
Hoje nós vamos para o Outback.
🐊 CAPÍTULO 1 — IBM Z NÃO É SINÔNIMO DE z/OS
Essa é provavelmente a primeira grande descoberta que um programador COBOL iniciante precisa fazer.
Durante os estudos, aprendemos:
TSO
ISPF
JCL
COBOL
CICS
Db2
VSAM
SDSF
Tudo isso cria uma associação mental:
MAINFRAME = z/OS
Mas isso está incompleto.
IBM Z é a plataforma computacional.
z/OS é um sistema operacional executado nessa plataforma.
Uma comparação grosseira, mas didática:
PC
│
└── Windows
O computador não é o Windows.
Da mesma forma:
IBM Z
│
└── z/OS
O IBM Z não é o z/OS.
E essa distinção abre uma porta gigantesca.
Porque o IBM Z pode executar outros sistemas operacionais e ambientes.
Entre eles:
Linux.
Portanto, nosso mapa precisa mudar:
IBM Z
│
├── z/OS
│
├── Linux
│
├── z/VM
│
└── outros ambientes suportados
Essa pequena mudança conceitual é fundamental para compreender o mainframe moderno.
🐧 CAPÍTULO 2 — O PINGUIM CHEGOU AO OUTBACK
Quando falamos em Linux on IBM Z, não estamos falando de uma imitação de Linux.
Também não estamos falando de algum shell colocado por cima do z/OS.
Estamos falando de:
Linux executando sobre a arquitetura IBM Z.
Você encontrará elementos absolutamente familiares para qualquer administrador Linux:
ls
cd
pwd
grep
cat
ssh
ps
top
systemctl
curl
Teremos:
/etc
/home
/usr
/var
/tmp
Teremos processos.
Usuários.
Permissões.
Sockets.
TCP/IP.
SSH.
Daemons.
Packages.
Java.
Python.
E muitas tecnologias open source.
O programador COBOL que entra nesse ambiente talvez tenha uma sensação curiosa:
“Eu ainda estou no mainframe?”
Sim.
Dundee provavelmente responderia:
— Bem-vindo ao outro lado do rio.
🧬 CAPÍTULO 3 — O MISTERIOSO s390x
Agora encontramos uma palavra que aparece constantemente quando estudamos Linux no IBM Z:
s390x
Não ignore isso.
Seu computador pessoal provavelmente utiliza uma arquitetura como:
x86_64
Muitos equipamentos modernos utilizam:
ARM64
No universo IBM Z encontraremos:
s390x
Isso importa porque programas são compilados para arquiteturas específicas.
Imagine que você encontre uma aplicação Linux na Internet.
Ela possui um executável para:
amd64
Isso não significa automaticamente que aquele binário executará em:
s390x
O software precisa possuir suporte para aquela arquitetura ou ser compilado para ela.
O mesmo raciocínio aparece fortemente em containers.
Você pode encontrar uma imagem disponível para:
amd64
arm64
s390x
Uma imagem multiarch pode possuir versões apropriadas para várias arquiteturas.
Esse detalhe é pequeno no PowerPoint.
Na produção pode signific a diferença entre:
docker run minha-aplicacao
e:
exec format error
☕ Dica Bellacosa
Quando estiver investigando software para Linux on Z, uma das primeiras perguntas deve ser:
Existe build para s390x?
Essa pergunta pode economizar muitas horas.
🏛️ CAPÍTULO 4 — PR/SM E AS FRONTEIRAS DO TERRITÓRIO
Agora Dundee encontra algo que conhece muito bem:
territórios.
No IBM Z podemos dividir os recursos da máquina em Logical Partitions, as famosas:
LPARs
Por trás dessa estrutura está o PR/SM — Processor Resource/System Manager.
Didaticamente:
IBM Z
│
PR/SM
│
┌─────────────┼─────────────┐
│ │ │
LPAR 1 LPAR 2 LPAR 3
│ │ │
z/OS Linux z/VM
Cada LPAR possui recursos atribuídos e isolamento.
Portanto, Linux não precisa ser simplesmente um processo escondido dentro do z/OS.
Ele pode executar em sua própria LPAR.
Essa distinção elimina um dos maiores equívocos de quem está começando.
⚙️ CAPÍTULO 5 — DUNDEE CONHECE O IFL
Agora encontramos outra sigla fundamental:
IFL
Integrated Facility for Linux.
O IFL é um processador especializado destinado à execução de workloads Linux no ecossistema IBM Z/LinuxONE.
Para o iniciante, podemos construir este mapa mental:
IBM Z
│
├── CP
│ └── processamento tradicional
│
├── zIIP
│ └── determinados workloads elegíveis
│
└── IFL
└── Linux
Mas não pense no IFL como:
“um PC Linux instalado dentro do mainframe.”
Não é isso.
Ele faz parte da arquitetura do próprio sistema.
Isso é importante inclusive quando estudamos custos, licenciamento, capacidade e consolidação.
No mundo mainframe, tipo de processador importa.
Muito.
🧙 CAPÍTULO 6 — z/VM: VIRTUALIZAÇÃO ANTES DE VIRTUALIZAÇÃO VIRAR MODA
Dundee continua andando pelo Outback e encontra algo ainda mais interessante.
Uma LPAR pode executar:
z/VM
E dentro do z/VM podemos hospedar múltiplos sistemas Linux.
Imagine:
IBM Z
│
▼
PR/SM
│
▼
LPAR
│
▼
z/VM
│
├── Linux 001
├── Linux 002
├── Linux 003
├── Linux 004
├── Linux 005
└── Linux ...
Agora começa a aparecer uma das grandes forças históricas do mainframe:
virtualização e consolidação.
O jovem programador pergunta:
— Então z/VM é como VMware?
Dundee responde:
— Como analogia inicial, serve. Mas não tente transformar dois animais diferentes no mesmo bicho.
Perfeito.
A comparação ajuda a compreender o papel:
Hipervisor
│
▼
Máquinas virtuais
Mas arquitetura, história, gerenciamento e implementação são diferentes.
🏙️ CAPÍTULO 7 — UMA CIDADE DE LINUX DENTRO DO Z
Imagine uma organização com centenas de servidores Linux.
Talvez existam máquinas para:
APIs
Java
bancos
mensageria
monitoramento
automação
integração
DevOps
aplicações internas
Fisicamente espalhar isso significa administrar:
CPU
memória
rede
storage
energia
refrigeração
hardware
monitoramento
patching
Virtualização permite consolidar workloads.
No IBM Z podemos imaginar:
IBM Z
│
z/VM
│
┌──────────┼───────────┐
│ │ │
Linux Linux Linux
│ │ │
Java API Banco
│
Linux
│
Kafka
O objetivo não é simplesmente afirmar:
“mainframe é mais rápido.”
Essa frase isolada diz muito pouco.
Precisamos analisar arquitetura, throughput, disponibilidade, licenciamento, utilização, crescimento, operação, energia e custo total.
A palavra interessante aqui é:
consolidação.
🐊 CAPÍTULO 8 — E APARECE O KVM
Quando o Padawan acha que já entendeu tudo, Dundee aponta para outra trilha:
KVM
Sim.
Kernel-based Virtual Machine também faz parte dessa conversa.
Portanto, quando estudamos virtualização Linux no Z, podemos encontrar arquiteturas utilizando:
z/VM
ou:
KVM
Conceitualmente:
IBM Z
│
├── z/VM
│ ├── Linux
│ ├── Linux
│ └── Linux
│
└── KVM
├── Linux
├── Linux
└── Linux
Isso aproxima ainda mais profissionais vindos do universo Linux da plataforma IBM Z.
📦 CAPÍTULO 9 — NÃO CONFUNDA LPAR, VM E CONTAINER
Este merece ser escrito em letras enormes:
LPAR ≠ VM ≠ CONTAINER
Os três conceitos oferecem formas de isolamento e organização de workloads, mas em níveis diferentes.
Uma pilha didática pode ser:
IBM Z
│
▼
PR/SM
│
▼
LPAR
│
▼
z/VM ou KVM
│
▼
Linux
│
▼
Container Runtime
│
├── Container
├── Container
└── Container
E então chegamos ao mundo Kubernetes/OpenShift:
IBM Z / LinuxONE
│
Linux
│
OpenShift
│
┌────┼─────┐
│ │ │
Pod Pod Pod
Agora perceba o tamanho da transformação.
O mesmo profissional que começou estudando:
//STEP01 EXEC PGM=PROG01
passa a conversar com colegas falando sobre:
Git
YAML
containers
pods
clusters
pipelines
APIs
observabilidade
Isso não diminui a importância do JCL.
Amplia o mapa do profissional.
🔌 CAPÍTULO 10 — O COBOL NÃO PRECISA IR EMBORA
Agora chegamos à parte que considero mais importante.
Modernização frequentemente é apresentada de maneira infantil:
VELHO = COBOL
NOVO = JAVA
Ou:
VELHO = MAINFRAME
NOVO = CLOUD
Arquitetura real é muito mais interessante.
Imagine um banco possuindo aplicações COBOL extremamente maduras:
z/OS
│
├── CICS
├── COBOL
├── Db2
├── IMS
├── VSAM
└── MQ
Por que necessariamente reescrever tudo?
Talvez possamos construir:
Aplicativo Mobile
│
▼
HTTPS
│
▼
API
│
▼
Linux / OpenShift
│
▼
Integração
│
▼
CICS
│
▼
COBOL
│
▼
Db2/VSAM
O COBOL continua processando regras de negócio.
Linux recebe workloads modernos.
Os dois cooperam.
Isso é modernização sem necessariamente destruir aquilo que já funciona.
☁️ CAPÍTULO 11 — O MAINFRAME ENCONTRA A CLOUD
Outra armadilha conceitual:
CLOUD = FORA DO MAINFRAME
Não necessariamente.
Cloud também envolve princípios como:
automação
provisionamento
elasticidade
virtualização
self-service
APIs
orquestração
containers
Quando combinamos:
IBM Z
+
Linux
+
virtualização
+
containers
+
OpenShift
+
automação
podemos construir arquiteturas de private cloud e hybrid cloud.
Portanto, a discussão deixa de ser:
“mainframe ou cloud?”
E passa a ser:
“qual workload deve executar onde e por quê?”
Essa é uma pergunta muito mais madura.
🤖 CAPÍTULO 12 — DUNDEE ENCONTRA A INTELIGÊNCIA ARTIFICIAL
Agora o Outback começa a ficar futurista.
IBM Z moderno também participa do universo de IA.
A ideia arquitetural mais interessante é:
levar processamento inteligente para perto dos dados e das transações.
Imagine:
Transação
│
▼
CICS
│
▼
COBOL
│
├────────► modelo
│ de IA
│ │
◄─────────────┘
│
▼
decisão
Fraude é um ótimo exemplo conceitual.
Em vez de analisar apenas depois:
transações
│
▼
arquivo
│
▼
processamento posterior
podemos imaginar arquiteturas capazes de aplicar inferência muito mais próximas do fluxo transacional.
Linux amplia as possibilidades de frameworks, ferramentas, APIs e serviços utilizados ao redor desses modelos.
🔐 CAPÍTULO 13 — O PINGUIM TAMBÉM PRECISA DE CERCA
Linux no Z continua sendo Linux.
Portanto:
SSH
sudo
usuários
grupos
patches
certificados
TLS
firewalls
secrets
vulnerabilidades
containers
continuam importantíssimos.
Não existe magia do tipo:
“Está no mainframe, então está automaticamente seguro.”
Segurança precisa ser projetada.
Ponto.
O interessante é combinar controles Linux com capacidades de isolamento, virtualização, criptografia e segurança existentes na plataforma IBM Z.
Defesa em profundidade continua sendo a palavra-chave.
🧑💻 CAPÍTULO 14 — O NOVO MAPA DO PROGRAMADOR COBOL
Nosso jovem começou com:
COBOL
JCL
TSO
ISPF
CICS
Db2
VSAM
SDSF
Nada disso perdeu importância.
Mas podemos ampliar a mochila:
COBOL
JCL
CICS
Db2
VSAM
+
Linux
Shell
SSH
Git
JSON
REST
Python
Java
Containers
OpenShift
CI/CD
Observabilidade
Não significa estudar tudo simultaneamente.
Faça por camadas.
PASSO 1 — Aprenda Linux básico
pwd
ls
cd
cat
grep
find
ps
top
ssh
curl
PASSO 2 — Entenda arquitetura
Aprenda:
IBM Z
PR/SM
LPAR
s390x
IFL
z/VM
KVM
PASSO 3 — Aprenda integração
Entenda:
TCP/IP
HTTP
REST
JSON
MQ
APIs
PASSO 4 — Entre em DevOps
Estude:
Git
pipeline
CI/CD
artifact
testes
deploy
rollback
PASSO 5 — Finalmente containers
Então:
image
container
registry
pod
Kubernetes
OpenShift
Não comece tentando decorar Kubernetes antes de entender Linux.
Seria como aprender CICS antes de compreender o que é uma transação.
🧭 CAPÍTULO 15 — IBM Z E LINUXONE NÃO SÃO A MESMA COISA
Outra pegadinha importante.
Existe:
IBM Z
e existe:
IBM LinuxONE
São famílias intimamente relacionadas tecnologicamente, mas não devemos usar os nomes como sinônimos.
Didaticamente podemos pensar:
IBM Z
│
├── z/OS
├── Linux
└── outros ambientes
LinuxONE
│
└── plataforma focada em Linux
Quando encontrar documentação, vagas ou apresentações falando em:
Linux on IBM Z
ou:
LinuxONE
observe exatamente qual plataforma e arquitetura estão sendo discutidas.
🥚 EASTER EGG — 03:17 DA MANHÃ
Às 03:17, o telefone toca.
Produção.
Naturalmente.
Um microsserviço Linux não consegue chamar uma aplicação CICS.
O Padawan abre o terminal.
Testa a API.
Nada.
Testa rede.
Nada.
Verifica logs.
Encontra:
Connection timed out
Depois de quarenta minutos investigando Java, COBOL, CICS, Linux, containers e provavelmente a posição de Saturno, alguém pergunta:
— Verificaram a regra de firewall?
Silêncio.
A regra havia sido alterada durante uma mudança de infraestrutura.
Dundee toma um gole de café.
— No Outback, garoto, primeiro você verifica se existe estrada antes de culpar o crocodilo.
Easter egg Bellacosa encontrado: 03:17.
🐊 EPÍLOGO — ISTO É UM MAINFRAME
No começo desta aventura, nosso Padawan acreditava que:
MAINFRAME
=
z/OS
=
COBOL
Agora ele consegue enxergar:
IBM Z
│
PR/SM
│
┌────────────┴────────────┐
│ │
z/OS Linux
│ │
┌──────┼──────┐ ┌──────┼──────┐
│ │ │ │ │ │
COBOL CICS IMS Java Python APIs
│ │ │ │ │ │
Db2 VSAM MQ Kafka Containers
│
OpenShift
Ao redor disso:
Git
DevOps
CI/CD
Observabilidade
Segurança
APIs
Automação
Hybrid Cloud
IA
Essa talvez seja uma das maiores mudanças mentais necessárias para quem começa sua carreira no mainframe.
COBOL é uma linguagem.
z/OS é um sistema operacional.
IBM Z é uma plataforma.
E uma plataforma pode hospedar mundos diferentes.
O Linux não chegou ao IBM Z para expulsar COBOL, CICS, IMS ou Db2.
Ele ampliou o território.
Agora podemos colocar aplicações modernas próximas de sistemas transacionais que carregam décadas de regras de negócio.
Podemos integrar.
Podemos encapsular.
Podemos criar APIs.
Podemos trabalhar com eventos.
Podemos usar containers.
Podemos automatizar pipelines.
Podemos explorar IA.
Sem começar toda reunião de arquitetura com:
“Primeiro precisamos jogar fora o legado.”
Dundee olha novamente para nosso Padawan.
O garoto aponta para uma pequena VM x86 e pergunta:
— Isto é um servidor Linux?
Dundee sorri.
Aponta para o IBM Z executando LPARs, z/OS, Linux, virtualização, APIs, containers e milhares de processos.
— Não, garoto...
Ele toma o último gole do café.
— Isto é um servidor Linux.
☕🐊🐧
☕ CONCLUSÃO — BELLACOSA MAINFRAME
Se você é um programador COBOL iniciante, não abandone suas raízes para correr atrás de cada tecnologia que aparece.
Aprenda primeiro muito bem:
COBOL
JCL
CICS
Db2
VSAM
z/OS
Depois amplie sua visão:
Linux
s390x
LPAR
IFL
z/VM
KVM
Depois conecte os mundos:
REST
JSON
MQ
APIs
Git
CI/CD
Containers
OpenShift
Observabilidade
IA
Porque o profissional mainframe moderno não precisa escolher entre legado e moderno.
Ele precisa compreender como os dois trabalham juntos.
E quando alguém disser:
“Mainframe? Aquela máquina velha que só roda COBOL?”
Você não precisa discutir.
Sirva um café.
Abra o diagrama da arquitetura.
Mostre z/OS de um lado.
Linux do outro.
CICS, COBOL e Db2 trabalhando com APIs, containers, OpenShift e IA.
Então lembre-se de Dundee:
“Você chama aquilo de servidor? Isto é um servidor.”
Bellacosa Mainframe — porque compreender o legado é importante. Compreender por que ele ainda está aqui é muito mais interessante. ☕
Sem comentários:
Enviar um comentário