 |
| Bellacosa Mainframe apresenta o USS Unix Posix no Zos |
☕ Um Café no Bellacosa Mainframe
⛩️ YOUJI ITAMI E O GATE PARA O OUTRO MUNDO DO z/OS
UNIX System Services, MVS, datasets, JCL, ISPF, zFS, shell, POSIX, RACF, EBCDIC, UTF-8, Git, APIs, Python, Java, DevOps — e o dia em que um programador COBOL atravessou um portal e descobriu que havia UNIX dentro do mainframe.
🎬 PRÓLOGO — UM GATE APARECEU NO MEIO DO ISPF
Imagine nosso jovem programador COBOL.
Chamaremos o rapaz de Padawan-01.
Depois de algumas semanas estudando mainframe, ele já estava começando a se sentir confortável.
Sabia entrar no TSO.
Conhecia o ISPF.
Já não entrava em pânico diante de:
USER01.COBOL.SOURCE
USER01.JCL
USER01.COPYLIB
USER01.LOADLIB
Conseguia navegar por um PDS, abrir um member e até escrever um pequeno programa COBOL.
Seu universo parecia perfeitamente organizado:
IBM Z
│
▼
z/OS
│
├── TSO
├── ISPF
├── datasets
├── JCL
├── JES2
├── COBOL
├── CICS
├── VSAM
└── Db2
Até que, numa tarde aparentemente normal, apareceu um estranho portal no meio do reino.
No portal estava escrito:
UNIX SYSTEM SERVICES
O jovem olhou assustado.
— UNIX? Professor, acho que entrei no curso errado.
Sentado tranquilamente diante do terminal estava Youji Itami, protagonista de GATE, com aquela expressão típica de alguém que preferia estar cuidando de seus hobbies em vez de resolver mais uma crise internacional.
Itami olhou para o garoto.
— Não. Você continua no z/OS.
— Mas tem UNIX aqui!
— Tem.
— Shell?
— Tem.
— Diretórios?
— Tem.
— grep?
— Tem.
— Processos?
— Tem.
— POSIX?
— Também.
Padawan-01 ficou alguns segundos olhando para a tela.
Itami levantou-se.
— Bem-vindo ao outro lado do GATE.
E é exatamente aqui que começa uma das descobertas mais importantes para qualquer profissional de mainframe moderno:
z/OS não é apenas MVS + datasets + JCL + ISPF.
Existe outro mundo dentro da mesma plataforma.
Seu nome é UNIX System Services — USS.
🏛️ CAPÍTULO 1 — O REINO QUE O PROGRAMADOR COBOL NÃO CONHECIA
Existe um problema curioso na maneira como muita gente aprende mainframe.
O treinamento começa corretamente por conceitos fundamentais:
IBM Z;
z/OS;
TSO;
ISPF;
datasets;
JCL;
JES;
COBOL.
Nada está errado nisso.
O problema surge quando o estudante começa a acreditar que isso é todo o z/OS.
Não é.
É como atravessar o GATE, conhecer uma única cidade da Região Especial e concluir que conhece todo aquele mundo.
O z/OS possui diferentes ambientes e modelos de utilização.
Uma visão simplificada seria:
z/OS
│
┌────────────┴────────────┐
│ │
AMBIENTE TRADICIONAL USS
│ │
TSO shell
ISPF files
JCL directories
JES processes
datasets pipes
COBOL POSIX
│ │
└────────────┬────────────┘
│
IBM Z
Quando mostramos isso cedo ao iniciante, acontece algo importante.
Ele deixa de associar:
MAINFRAME = COBOL
e começa a compreender:
COBOL
│
▼
uma das tecnologias
│
▼
z/OS
│
▼
uma das plataformas
│
▼
IBM Z
Essa mudança mental parece pequena.
Profissionalmente, é gigantesca.
⛩️ CAPÍTULO 2 — O QUE É UNIX SYSTEM SERVICES?
UNIX System Services é um ambiente UNIX integrado ao z/OS.
Ele oferece recursos e interfaces baseados em padrões UNIX e POSIX.
Isso significa que alguém vindo de Linux ou UNIX pode encontrar conceitos extremamente familiares:
pwd
ls
cd
mkdir
cp
mv
rm
cat
grep
find
chmod
ps
kill
Padawan-01 atravessa o portal.
Do outro lado, digita:
pwd
E recebe:
/u/padawan01
Ele olha para Itami.
— Cadê meu HLQ?
Itami responde:
— Continue.
ls -l
Aparece algo parecido com:
-rw-r--r-- 1 padawan users 840 Sep 17 15:30 config.json
drwxr-xr-x 2 padawan users 8192 Sep 17 15:40 scripts
— PROFESSOR! SUMIRAM OS DATASETS!
Não.
Eles não sumiram.
Você simplesmente atravessou para outro modelo de filesystem.
Essa distinção é essencial.
🗄️ CAPÍTULO 3 — DATASET NÃO É FILE
No mundo tradicional do z/OS podemos encontrar:
VAGNER.COBOL.SOURCE
VAGNER.COBOL.COPYLIB
VAGNER.JCL
VAGNER.CNTL
No USS podemos encontrar:
/u/vagner/project/src
/u/vagner/project/scripts
/u/vagner/project/config
Parece equivalente?
Em determinados contextos podemos criar analogias didáticas.
Mas cuidado.
Dataset não é simplesmente o nome mainframe para arquivo UNIX.
Da mesma maneira:
PDS/PDSE ≠ directory
member ≠ file
HLQ ≠ /
Existem semelhanças funcionais que ajudam o iniciante a criar referências mentais, mas as estruturas possuem características próprias.
Essa é uma excelente oportunidade para ensinar arquitetura em vez de apenas comandos.
🌳 CAPÍTULO 4 — ITAMI ENCONTRA UMA ÁRVORE NO MAINFRAME
No USS encontramos uma estrutura hierárquica típica do mundo UNIX:
/
├── bin
├── dev
├── etc
├── tmp
├── u
│ ├── itami
│ ├── padawan01
│ └── bellacosa
├── usr
└── var
Agora compare com datasets:
PADAWAN.COBOL
PADAWAN.JCL
PADAWAN.COPYLIB
PADAWAN.TEST.DATA
O primeiro modelo trabalha naturalmente com uma árvore de diretórios.
O segundo utiliza a organização e nomenclatura próprias de datasets do z/OS.
É importante conhecer ambos porque aplicações modernas no mainframe frequentemente atravessam esses mundos.
E existe aqui outro nome que o jovem programador deve aprender:
zFS
O z/OS File System, conhecido como zFS, é peça importante do filesystem utilizado pelo USS.
Podemos ter filesystems montados na hierarquia USS.
Conceitualmente:
zFS
│
▼
mount
│
▼
/u/projeto
│
├── bin
├── config
├── logs
└── scripts
Isso já é muito diferente da visão inicial:
MAINFRAME = PDS + JCL
O mapa ficou maior.
🐚 CAPÍTULO 5 — O DIA EM QUE O MAINFRAME RESPONDEU ls
Itami entrega o terminal ao Padawan.
— Sua missão é criar uma área de trabalho.
cd /u/padawan01
mkdir treinamento
cd treinamento
Agora:
pwd
Resultado:
/u/padawan01/treinamento
Criamos um arquivo:
echo "Hello Mainframe" > teste.txt
E verificamos:
cat teste.txt
Resultado:
Hello Mainframe
O jovem fica em silêncio.
Não apareceu ISPF.
Não apareceu JCL.
Não apareceu //SYSIN DD *.
E, mesmo assim, ele continua trabalhando no z/OS.
Esse laboratório de cinco minutos vale uma longa explicação teórica porque quebra imediatamente o estereótipo de que mainframe significa apenas terminal 3270.
🔗 CAPÍTULO 6 — ITAMI DESCOBRE O PODER DOS PIPES
No mundo UNIX existe uma filosofia extremamente elegante:
faça pequenas ferramentas realizarem tarefas específicas e combine seus resultados.
Imagine um arquivo:
application.log
Queremos encontrar erros.
grep ERROR application.log
Queremos procurar ABENDs:
grep ABEND application.log
Podemos combinar comandos:
cat application.log | grep ERROR
E criar cadeias:
cat application.log |
grep ERROR |
sort |
uniq
O símbolo:
|
é um pipe.
A saída de um comando pode alimentar outro.
Para alguém acostumado ao processamento batch, podemos fazer uma analogia.
No JCL:
INPUT
│
▼
STEP01
│
▼
TEMP
│
▼
STEP02
│
▼
OUTPUT
No shell:
INPUT → comando | comando | comando → OUTPUT
Não são exatamente a mesma arquitetura.
Mas comparar os modelos ensina algo muito mais importante do que decorar sintaxe:
fluxo de processamento.
🕵️ CAPÍTULO 7 — GREP, O DETETIVE DO GATE
Imagine um log com 200 mil linhas.
O programador abre o arquivo e começa:
FIND 'ERROR'
Itami observa.
Um minuto.
Dois minutos.
Cinco minutos.
Finalmente pergunta:
— O que você está fazendo?
— Investigando o incidente.
Itami aponta para o shell:
grep ERROR application.log
Agora queremos contar ocorrências:
grep ERROR application.log | wc -l
Queremos encontrar determinados arquivos:
find /u/projeto -name "*.log"
Queremos procurar determinado conteúdo dentro deles.
O profissional começa a construir uma nova caixa de ferramentas.
Essa habilidade torna-se especialmente valiosa em troubleshooting, automação, análise de logs e operações.
🔐 CAPÍTULO 8 — RACF ATRAVESSA O GATE
Padawan aprende:
chmod 777 deploy.sh
Itami imediatamente aparece atrás dele.
— O que você está fazendo?
— Resolvendo o problema de permissão.
Silêncio constrangedor.
Essa é outra aula importante.
No UNIX encontramos conceitos como:
owner
group
other
e permissões:
r = read
w = write
x = execute
Por exemplo:
-rwxr-x---
Podemos representar:
USER GROUP OTHER
READ X X
WRITE X
EXECUTE X X
No entanto, USS continua integrado ao modelo de segurança do z/OS.
Entram conceitos relacionados a:
SAF
RACF
UID
GID
owner
group
permissions
Portanto, ensinar USS também cria uma excelente oportunidade para ensinar segurança.
E uma regra deve ficar gravada:
chmod 777não é estratégia de troubleshooting.
É muitas vezes a confissão:
"Não descobri qual permissão estava errada, então liberei tudo."
Em laboratório pode aparecer.
Em produção merece investigação.
👹 CAPÍTULO 9 — O MONSTRO EBCDIC ATRAVESSA O PORTAL
Itami acreditava que a missão estava tranquila.
Então chegou o verdadeiro monstro da Região Especial:
ENCODING
No mundo tradicional z/OS existe uma longa história relacionada a EBCDIC.
No mundo distribuído encontramos frequentemente:
ASCII
UTF-8
Agora imagine integração moderna:
COBOL
│
▼
dados EBCDIC
│
▼
API
│
▼
JSON / UTF-8
│
▼
aplicação distribuída
Pronto.
Temos terreno fértil para problemas.
Caracteres especiais, acentos e conversões podem produzir surpresas.
O programador manda:
JOÃO
e alguma camada mal configurada responde com algo que parece ter sido escrito por um mago bêbado da Região Especial.
Por isso, aprender USS também deveria envolver:
encoding;
code pages;
ASCII;
EBCDIC;
UTF-8;
conversão;
tagging de arquivos.
Não trate encoding como detalhe.
Em integração, detalhe vira incidente.
⚙️ CAPÍTULO 10 — PROCESSOS TAMBÉM EXISTEM DO OUTRO LADO
Outro conceito UNIX importante é processo.
Comandos como:
ps
permitem observar processos.
Podemos então introduzir conceitos relacionados a:
PID
process
parent process
signal
environment
E eventualmente:
kill
Aqui é preciso explicar ao iniciante que aprender comandos não significa sair executando-os indiscriminadamente.
Especialmente kill.
No mainframe, como em qualquer ambiente corporativo sério, antes de terminar alguma coisa devemos saber:
O que é?
Quem iniciou?
Quem depende disso?
Qual impacto?
Existe procedimento operacional?
O botão funciona.
O problema é descobrir o que acontece depois que você aperta.
🚪 CAPÍTULO 11 — BPXBATCH: UM PORTAL DENTRO DO PORTAL
Agora Itami encontra algo particularmente interessante.
Os dois mundos podem conversar.
Um exemplo conceitual importante é BPXBATCH.
Podemos ter:
JCL
│
▼
BPXBATCH
│
▼
USS
│
▼
shell / programa
Isso destrói a ideia de que existem dois sistemas completamente separados:
MVS USS
│ │
X X
Uma representação melhor seria:
z/OS
│
┌─────────┴─────────┐
│ │
clássico USS
│ │
JCL shell
JES files
datasets processes
│ │
└─────────┬─────────┘
│
integração
É o GATE funcionando nos dois sentidos.
🌐 CAPÍTULO 12 — DO OUTRO LADO EXISTIAM APIs
Agora começamos a entender por que USS é tão relevante numa formação moderna.
O jovem programador pode encontrar tecnologias e conceitos como:
shell
SSH
Git
Java
Python
JSON
XML
REST
automação
CI/CD
APIs
Isso não significa que USS seja simplesmente Linux.
Esse erro também deve ser evitado.
USS não é "Ubuntu escondido dentro do z/OS".
Existem padrões e conceitos familiares ao universo UNIX, mas estamos dentro da arquitetura, segurança, operação e características do z/OS.
É justamente isso que torna o assunto interessante.
🧬 CAPÍTULO 13 — GIT ENCONTRA COBOL
Agora imagine um programador moderno.
Ele escreve COBOL.
Mas seu código está versionado.
Temos:
Developer
│
▼
Git
│
▼
Pipeline
│
├── build
├── test
├── quality gate
├── security
└── deploy
│
▼
z/OS
De repente, conhecimentos de USS tornam-se extremamente úteis.
O profissional não vive necessariamente apenas em:
3270 → TSO → ISPF
Ele pode transitar por:
DEVELOPER
│
┌────────────────┼────────────────┐
│ │ │
ISPF USS IDE
│ │ │
COBOL shell Git
│ │ │
└────────────────┼────────────────┘
│
CI/CD
│
API
│
z/OS
Isso muda inclusive nossa definição de "programador mainframe".
🐍 CAPÍTULO 14 — PYTHON, JAVA E OS NOVOS HABITANTES DA REGIÃO ESPECIAL
Outro erro comum é imaginar:
mainframe = COBOL
COBOL continua importantíssimo.
Mas IBM Z e z/OS não são sinônimos de COBOL.
No ecossistema moderno podemos encontrar outras linguagens e runtimes.
Isso abre possibilidades relacionadas a Java, Python, shell scripting e outras tecnologias.
Não significa substituir COBOL gratuitamente.
Imagine um programa COBOL que processa milhões de transações diariamente há vinte anos e funciona perfeitamente.
Alguém chega:
— Vamos reescrever porque COBOL é velho.
Itami provavelmente perguntaria:
— Qual problema estamos tentando resolver?
Essa deveria ser sempre a pergunta.
Modernização séria começa pelo problema, não pela idade da linguagem.
🏗️ CAPÍTULO 15 — MODERNIZAR NÃO SIGNIFICA DEMOLIR A CIDADE
Esse talvez seja o ensinamento mais importante.
Modernização pode significar:
Git
CI/CD
APIs
automação
observabilidade
novas interfaces
melhores testes
segurança
integração
sem necessariamente significar:
APAGUE TODO O COBOL!
Imagine:
SISTEMA EXISTENTE
│
COBOL/CICS
│
lógica madura
│
┌─────────┴─────────┐
│ │
API MQ
│ │
└─────────┬─────────┘
│
novos canais
O patrimônio existente continua entregando valor enquanto novas formas de acesso e desenvolvimento são incorporadas.
É a diferença entre modernizar a cidade e incendiar a cidade para construir outra.
🧪 CAPÍTULO 16 — O LABORATÓRIO DOS PADAWANS
Se eu estivesse estruturando essa formação, USS não seria apenas PowerPoint.
Itami entregaria uma missão.
MISSÃO 1 — Descubra onde você está
pwd
MISSÃO 2 — Veja o território
ls -l
MISSÃO 3 — Construa sua base
mkdir treinamento
cd treinamento
MISSÃO 4 — Crie informação
echo "Hello z/OS" > hello.txt
MISSÃO 5 — Leia
cat hello.txt
MISSÃO 6 — Copie
cp hello.txt copia.txt
MISSÃO 7 — Mova
mv copia.txt backup.txt
MISSÃO 8 — Investigue
grep "z/OS" hello.txt
MISSÃO 9 — Procure
find . -name "*.txt"
MISSÃO 10 — Entenda permissões
ls -l
Depois:
chmod 750 algum_script.sh
Mas somente depois de explicar por quê.
MISSÃO 11 — Crie um shell script
Algo simples:
#!/bin/sh
echo "Bom dia, Padawan."
date
pwd
Então execute e observe.
O objetivo não é transformar o aluno em administrador UNIX em uma tarde.
O objetivo é retirar o medo.
🔥 CAPÍTULO 17 — O DESAFIO FINAL DE ITAMI
Agora entregamos:
incident.log
Com milhares de registros.
A missão:
Localize todos os ERROR.
Depois:
Localize todos os ABEND.
Depois:
Conte-os.
Depois:
Gere um arquivo apenas com as ocorrências.
Depois:
Descubra quais mensagens se repetem.
Agora o aluno começa a combinar:
grep
sort
uniq
wc
Nesse momento aconteceu algo importante.
Ele não está mais decorando UNIX.
Está pensando UNIX.
Essa diferença vale ouro.
🎓 CAPÍTULO 18 — QUANDO ENSINAR USS?
Eu não esconderia USS no final da formação como "conteúdo avançado".
Colocaria relativamente cedo.
Algo como:
IBM Z
↓
arquitetura
↓
z/OS
↓
TSO/ISPF
↓
datasets
↓
JCL/JES
↓
COBOL básico
↓
════════════════════
ABRE-SE O GATE
════════════════════
↓
USS
├── filesystem
├── shell
├── zFS
├── POSIX
├── processos
├── pipes
├── permissões
├── RACF/SAF
└── encoding
↓
Db2 / VSAM
↓
CICS
↓
MQ
↓
APIs
↓
Git
↓
CI/CD
↓
observabilidade
↓
modernização
Depois USS reaparece continuamente.
Essa é a chave.
Não deveria existir:
"Aula de USS concluída. Nunca mais falaremos disso."
USS precisa reaparecer quando estudamos segurança, desenvolvimento, integração, APIs, DevOps, automação e troubleshooting.
🧠 CAPÍTULO 19 — DE PROGRAMADOR COBOL PARA PROFISSIONAL z/OS
Esse é o verdadeiro objetivo.
Começamos com:
PROGRAMADOR COBOL
Depois adicionamos:
COBOL
JCL
ISPF
datasets
Depois:
CICS
Db2
VSAM
MQ
E finalmente:
USS
Git
APIs
shell
Python
Java
CI/CD
observabilidade
segurança
A pessoa começa a compreender o ecossistema.
Então podemos mudar a placa:
PROGRAMADOR COBOL
↓
DESENVOLVEDOR MAINFRAME
↓
PROFISSIONAL z/OS
↓
PROFISSIONAL IBM Z
Não porque abandonou COBOL.
Mas porque entendeu onde COBOL vive.
🥚 EASTER EGG — INCIDENTE 03:17
No final do laboratório, Itami entrega uma última missão.
Existe um arquivo misterioso:
/u/padawan/logs/gate.log
Padawan executa:
grep "03:17" /u/padawan/logs/gate.log
A tela responde:
03:17:00 BPXF024I GATE OPENED
03:17:01 PADAWAN ENTERED UNIX SYSTEM SERVICES
03:17:02 PADAWAN DISCOVERED GREP
03:17:03 PADAWAN STOPPED SEARCHING 300000 LINES MANUALLY
03:17:04 ITAMI REQUESTED COFFEE
03:17:05 BELLACOSA REQUESTED ANOTHER INCIDENT
O aluno olha para Itami.
— Professor... o que significa 03:17?
Itami toma um gole de café.
— Algumas coisas no mainframe você descobre sozinho.
☕ EPÍLOGO — O GATE NUNCA MAIS SE FECHOU
Padawan-01 voltou ao ISPF.
A tela era exatamente a mesma.
ISPF PRIMARY OPTION MENU
Mas alguma coisa havia mudado.
Não no mainframe.
Nele.
Antes enxergava:
MAINFRAME
=
COBOL + JCL + ISPF
Agora enxergava:
IBM Z
│
z/OS
│
┌──────────────┼──────────────┐
│ │ │
CLÁSSICO USS MODERNO
│ │ │
COBOL zFS Git
JCL shell APIs
ISPF POSIX CI/CD
CICS processes Java
VSAM pipes Python
Db2 security observability
│ │ │
└──────────────┼──────────────┘
│
MAINFRAME MODERNO
Itami caminhou novamente em direção ao GATE.
Antes de atravessar, virou-se para o jovem programador.
— Você ainda gosta de COBOL?
— Muito.
— Ótimo. Continue estudando.
— Então por que me mostrou tudo isso?
Itami apontou para o enorme IBM Z atrás deles.
— Porque COBOL é uma linguagem. Isso aqui é uma plataforma.
E talvez essa seja uma das lições mais importantes que podemos ensinar para uma nova geração de profissionais.
COBOL continua sendo parte extraordinariamente importante da história e do presente do mainframe.
JCL continua importante.
ISPF continua importante.
Datasets continuam importantes.
CICS, Db2, VSAM, JES e RACF continuam importantes.
Mas ensinar somente isso cria uma janela estreita para uma plataforma gigantesca.
UNIX System Services abre outra janela.
Ali aparecem filesystem hierárquico, shell, POSIX, processos, pipes, permissões, zFS, integração com segurança do z/OS, encoding, automação e ferramentas modernas.
Depois surgem Git, APIs, Java, Python, CI/CD e novas formas de desenvolver e operar aplicações.
É nesse momento que o jovem deixa de perguntar:
"Como faço isso em COBOL?"
e começa a perguntar:
"Qual é a melhor maneira de resolver este problema no z/OS?"
Essa segunda pergunta forma profissionais muito mais completos.
Porque o futuro do mainframe não está em escolher entre o mundo antigo e o mundo novo.
Está em entender como os dois mundos atravessam o mesmo GATE.
E o profissional que consegue caminhar tranquilamente entre:
ISPF
↕
USS
↕
Git
↕
APIs
↕
CI/CD
↕
Cloud
sem esquecer de COBOL, JCL, CICS, Db2 e RACF não é apenas alguém mantendo sistemas antigos.
Ele está aprendendo a trabalhar com uma plataforma que passou décadas fazendo algo extremamente difícil:
evoluir sem obrigar o mundo inteiro a começar novamente do zero.
Itami provavelmente aprovaria.
Especialmente se a missão terminasse cedo o suficiente para ele voltar aos seus hobbies.
E o Bellacosa?
Provavelmente estaria no outro lado do GATE perguntando:
WHO CHANGED THIS FILE AT 03:17?
☕ Um Café no Bellacosa Mainframe
"Existem dois tipos de programadores z/OS: aqueles que já atravessaram o GATE para o USS... e aqueles que ainda estão procurando a opção dele no menu do ISPF."
