 |
| Bellacosa Mainframe jcl e uss eu sabia fazer ate que li esse artigo |
☕ Um Café no Bellacosa Mainframe
Eu Sabia Fazer... Até Descobrir que Precisava Aprender de Novo
JCL, USS e a maior lição que um Programador Mainframe pode aprender na era da Modernização
"O conhecimento verdadeiro não está em decorar comandos. Está em reconhecer padrões, independentemente da linguagem utilizada."
Existe um momento curioso na carreira de praticamente todo profissional de tecnologia.
Não importa se você programa em COBOL, Java, Python ou C.
Não importa se trabalha em Linux, Windows ou IBM z/OS.
Mais cedo ou mais tarde você olha para uma tarefa simples — algo que faz há vinte anos — e pensa:
"Espera... como é mesmo que faz isso aqui?"
A primeira reação costuma ser de frustração.
"Será que estou esquecendo?"
Na maioria das vezes, não.
Você continua sabendo exatamente o que precisa ser feito.
O problema é que o ambiente mudou.
E quando o ambiente muda, a maneira de conversar com ele também muda.
Foi exatamente isso que aconteceu quando muitos profissionais Mainframe conheceram o USS (Unix System Services).
Eles não estavam aprendendo um novo trabalho.
Estavam aprendendo uma nova língua.
E, curiosamente, isso costuma ser muito mais difícil.
Pegue uma xícara de café.
Hoje vamos conversar sobre uma das maiores armadilhas da modernização do IBM Z.
Quando o piloto entra em outro avião
Imagine um comandante com trinta anos de experiência pilotando um Boeing 737.
Um belo dia ele recebe treinamento para voar um Airbus A320.
Ele esqueceu como voar?
Claro que não.
Ele continua entendendo:
sustentação
velocidade
meteorologia
navegação
segurança
Tudo isso continua igual.
O que muda é:
Durante alguns dias ele parece um iniciante.
Mas ele não voltou ao zero.
Ele apenas precisa reconstruir seus reflexos.
É exatamente isso que acontece quando um programador experiente em JCL começa a trabalhar no USS.
O erro mais comum dos iniciantes
Quando um programador júnior aprende COBOL, tudo é novidade.
Ele aceita naturalmente ser iniciante.
Mas existe um problema curioso com profissionais experientes.
Quando entram em um ambiente parecido...
...eles esperam que tudo funcione igual.
E aí começam as comparações.
"Cadê o EXEC PGM?"
"Cadê o DD?"
"Cadê o DSN?"
"Cadê o DISP?"
"Cadê o SYSIN?"
A resposta é simples.
Eles continuam existindo...
...mas não da forma que você espera.
O IBM z/OS possui dois universos
Muitos iniciantes imaginam que existe um único ambiente Mainframe.
Na verdade existem dois mundos convivendo harmoniosamente.
Mundo tradicional
Batch
JES2/JES3
JCL
DFSORT
IDCAMS
IEBGENER
TSO/ISPF
Dataset
É o universo clássico.
É onde o Mainframe cresceu.
Mundo USS
Agora imagine colocar um Unix inteiro dentro do z/OS.
Foi exatamente isso que a IBM fez.
O USS oferece:
Shell
Bash
Diretórios
Arquivos
Scripts
Permissões POSIX
OpenSSH
Python
Git
Java
Node.js
Zowe CLI
Sem sair do z/OS.
Esse detalhe é importantíssimo.
O USS não substitui o Mainframe.
Ele amplia o Mainframe.
O maior equívoco sobre o USS
Muita gente pensa:
"Agora o Mainframe virou Linux."
Não.
Nem perto disso.
O Kernel continua sendo o z/OS.
O gerenciamento de memória continua sendo do z/OS.
O Workload Manager continua sendo do z/OS.
O RACF continua protegendo recursos.
O JES continua executando Batch.
O USS apenas fornece outra interface para conversar com o sistema operacional.
É como trocar o painel de instrumentos de um carro.
O motor continua o mesmo.
Dataset não morreu
Uma das primeiras confusões acontece aqui.
Durante décadas escrevemos:
CLIENTE.VENDAS.ARQUIVO
No USS passamos a enxergar algo como:
/u/vagner/clientes/vendas.txt
A primeira impressão é:
"Agora só existem arquivos."
Não.
Os datasets continuam existindo.
Inclusive é possível acessá-los a partir do USS.
Da mesma forma, programas Batch conseguem trabalhar com arquivos do USS.
Os dois mundos conversam.
E isso é fantástico.
DD Statements versus Pathnames
Durante anos aprendemos:
//INPUT DD DSN=CLIENTE.INPUT,DISP=SHR
O programa COBOL nunca conhecia o nome físico do dataset.
Ele apenas dizia:
SELECT CLIENTES
ASSIGN TO INPUT.
O JCL fazia a ligação.
Isso separava infraestrutura do programa.
No USS isso muda.
Agora normalmente fazemos:
programa entrada.txt saida.txt
Ou
fopen("/u/input/clientes.txt")
É outra filosofia.
Não melhor.
Não pior.
Diferente.
EXEC PGM virou comando
No Batch.
//STEP01 EXEC PGM=COBPROG
No USS.
./cobprog
Ou
cobprog
A intenção continua exatamente igual.
Executar um programa.
Mas agora o pensamento é imperativo.
Você manda executar imediatamente.
Enquanto o JCL descreve um processo inteiro.
Ordenação: o exemplo perfeito
Durante décadas utilizamos DFSORT.
//STEP EXEC PGM=SORT
Depois:
SORT FIELDS=(1,10,CH,A)
No USS tudo parece diferente.
Agora temos:
sort arquivo.txt
Ou:
syncsort
Ou pipelines:
cat clientes.txt | sort
Ou:
sort clientes.txt > clientes_ordenados.txt
Você continua ordenando.
Mas agora conversa diretamente com o sistema operacional.
Copiar arquivos
Batch.
IEBGENER.
PGM=IEBGENER
USS.
cp origem destino
Uma linha.
Fim.
Excluir arquivos
Batch.
DELETE CLIENTE.ARQ
USS.
rm arquivo
Mesma ação.
Outra gramática.
O verdadeiro desafio é psicológico
Essa talvez seja a parte mais interessante.
Quando tudo é completamente novo...
Nosso cérebro aceita aprender.
Mas quando algo parece familiar...
Tentamos usar nossos velhos reflexos.
É aí que começamos a tropeçar.
É como trocar de carro.
Você continua sabendo dirigir.
Mas procura o limpador de para-brisa no lugar errado.
O cérebro funciona por padrões
Programadores experientes não decoram comandos.
Eles criam padrões mentais.
Por exemplo.
Quando alguém fala:
"Preciso copiar dados."
Seu cérebro já responde:
IEBGENER.
Isso virou memória muscular.
Agora imagine trocar isso por:
cp
Não é difícil.
Mas o cérebro insiste em procurar o antigo caminho.
O mesmo acontece em outras tecnologias
COBOL → Java
Você continua escrevendo lógica.
Mudam:
sintaxe;
paradigma;
bibliotecas.
DB2 → PostgreSQL
SQL continua sendo SQL.
Mas:
utilitários;
administração;
backup;
tuning;
mudam completamente.
ISPF → VS Code
Você continua editando programas.
Mas os atalhos mudam.
A organização muda.
O fluxo muda.
JCL → Shell Script
Você continua automatizando processos.
Mas agora usa:
variáveis;
loops;
funções;
pipelines;
redirecionamento;
permissões.
Shell pensa diferente
JCL é declarativo.
Você descreve.
Quero executar isso.
Depois usar esse dataset.
Depois gravar ali.
Depois liberar espaço.
O sistema organiza tudo.
Shell é imperativo.
Você diz:
faça isso
agora isso
agora aquilo
agora copie
agora compacte
agora envie
Parece uma conversa.
A revolução silenciosa
Pouca gente percebe.
Hoje praticamente todas as ferramentas modernas do IBM Z passam pelo USS.
Git.
Python.
OpenSSH.
OpenSSL.
Java.
Node.js.
Ansible.
Docker Build Tools.
Make.
Maven.
Gradle.
VS Code.
Zowe CLI.
IBM Dependency Based Build.
Open Enterprise SDK.
Tudo isso vive ou conversa intensamente com o USS.
Quem domina USS ganha acesso ao universo moderno do Mainframe.
Curiosidade #1
O USS segue os padrões POSIX.
Isso significa que muito software originalmente criado para Unix pode ser recompilado para z/OS com poucas adaptações.
É um dos motivos pelos quais Python, Git e OpenSSH funcionam tão bem no IBM Z.
Curiosidade #2
Você pode acessar datasets tradicionais usando caminhos especiais dentro do USS.
Algo parecido com:
//CLIENTE.INPUT
Ou utilizando APIs específicas do z/OS.
É uma ponte entre os dois mundos.
Curiosidade #3
O comando ls mostra arquivos.
Mas também pode mostrar permissões POSIX.
Enquanto datasets continuam possuindo atributos completamente diferentes como:
São dois modelos coexistindo.
Curiosidade #4
Muitos programas COBOL modernos conseguem trabalhar simultaneamente com:
datasets tradicionais;
arquivos USS;
bancos DB2;
APIs REST;
filas MQ.
Tudo no mesmo programa.
Essa integração é uma das maiores forças do IBM Z atual.
Dicas para o Programador Júnior
Não tente decorar comandos
Aprenda conceitos.
Quem entende conceitos aprende comandos rapidamente.
Entenda o objetivo
Antes de perguntar:
"Qual comando faz isso?"
Pergunte:
"O que eu quero fazer?"
A resposta quase sempre será:
copiar;
ordenar;
executar;
pesquisar;
transformar.
Depois descubra como cada ambiente expressa essa ideia.
Aprenda os dois mundos
Não escolha entre JCL e USS.
Aprenda ambos.
O mercado procura profissionais híbridos.
Pratique pequenos scripts
Faça scripts simples.
Copie arquivos.
Liste diretórios.
Ordene textos.
Execute programas.
Quanto mais prática, menos estranhos parecerão os comandos.
Leia JCL antigo
Muita lógica de negócio ainda vive em Batch.
Conhecer esse mundo é um enorme diferencial.
Explore o USS sem medo
Abra um shell.
Digite:
pwd
ls
cd
mkdir
cp
mv
rm
cat
grep
sort
find
São comandos simples.
Mas representam uma mudança enorme na forma de pensar.
Easter Egg do Bellacosa ☕
Existe uma frase famosa entre administradores Unix:
"Everything is a file."
No mundo Mainframe poderíamos adaptá-la para:
"Everything is a dataset... até você conhecer o USS."
Easter Egg Mainframe Nerd 🤓
Repare na sequência dos utilitários clássicos:
Agora observe os equivalentes Unix:
Quatro comandos substituem dezenas de utilitários especializados. Isso não significa que um modelo seja superior ao outro; significa apenas que cada ecossistema evoluiu para atender necessidades diferentes. O z/OS privilegiou controle, rastreabilidade e processamento corporativo em larga escala. O Unix priorizou simplicidade, composição de ferramentas e interatividade.
Conclusão: Aprender de Novo Não é Recomeçar
Existe uma enorme diferença entre recomeçar do zero e reconstruir seus referenciais.
Quando um desenvolvedor COBOL aprende Java, ele não esquece lógica de programação.
Quando um DBA DB2 aprende PostgreSQL, ele não esquece bancos de dados.
Quando um especialista em JCL aprende USS, ele não desaprende Batch.
Ele apenas descobre uma nova maneira de conversar com o mesmo sistema.
E talvez essa seja a maior lição da modernização do IBM Z: a tecnologia evolui, as interfaces mudam, as ferramentas se renovam, mas os princípios fundamentais permanecem. Quem entende esses princípios consegue atravessar décadas de inovação sem perder sua essência técnica.
No fim das contas, a verdadeira competência não está em decorar comandos como EXEC PGM, cp, sort ou rm. Ela está em compreender o problema, reconhecer padrões e adaptar-se rapidamente a novas formas de expressar soluções.
É por isso que os melhores profissionais de Mainframe não são aqueles que conhecem apenas o legado, nem os que dominam apenas as ferramentas modernas. São aqueles capazes de caminhar com naturalidade entre o JCL e o Bash, entre o ISPF e o VS Code, entre o dataset e o pathname, entre o Batch e o DevOps.
Porque, no IBM Z, existem dois mundos. E o profissional do futuro é aquele que fala fluentemente os dois.
