Translate

sábado, 30 de março de 2024

JCL e USS: Eu Sabia Fazer... Até Descobrir que Precisava Aprender de Novo

 

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 é:

  • onde fica cada botão;

  • como os sistemas conversam;

  • quais procedimentos devem ser executados.

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:

  • RECFM

  • LRECL

  • BLKSIZE

  • DSORG

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:

  • IEBGENER copia.

  • IEBCOPY copia PDS.

  • IDCAMS administra VSAM e datasets.

  • DFSORT organiza dados.

Agora observe os equivalentes Unix:

  • cp

  • mv

  • rm

  • sort

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.


Sem comentários:

Enviar um comentário