Translate

Mostrar mensagens com a etiqueta IBM JCL. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM JCL. Mostrar todas as mensagens

sexta-feira, 23 de fevereiro de 2018

IBM JCL vs Shell Script

 


☕ Um Café no Bellacosa Mainframe

IBM JCL vs Shell Script

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Semelhanças e Diferenças Entre a Linguagem de Controle do Mainframe e a Automação do Mundo Linux

"Você não está aprendendo duas tecnologias diferentes. Está descobrindo duas filosofias de automação que nasceram em épocas distintas para resolver exatamente o mesmo problema: fazer o computador trabalhar sozinho."


Introdução

Existe uma frase muito comum entre profissionais que estão migrando do IBM Mainframe para Linux:

"Shell Script é o JCL do Linux."

Embora essa frase seja extremamente útil para explicar rapidamente o conceito, ela não é totalmente correta.

Na realidade, JCL e Shell Script possuem objetivos semelhantes, mas nasceram em épocas diferentes, foram projetados para sistemas operacionais completamente distintos e seguem filosofias arquitetônicas bastante diferentes.

Se você é um Programador COBOL Padawan, provavelmente domina conceitos como:

  • JOB

  • EXEC

  • DD Statements

  • PROC

  • COND

  • RC

  • GDG

  • IDCAMS

  • SORT

  • IKJEFT01

Ao começar a estudar Linux, você encontrará conceitos aparentemente novos:

  • Bash

  • Variáveis

  • Loops

  • Pipes

  • Exit Status

  • Cron

  • sed

  • awk

  • grep

A boa notícia é que boa parte dessa lógica já faz parte da sua experiência.

Hoje vamos tomar um café e descobrir que o universo Mainframe e o universo Linux possuem muito mais pontos em comum do que a maioria das pessoas imagina.


Dois mundos separados por décadas

IBM Mainframe

O primeiro System/360 foi anunciado pela IBM em 7 de abril de 1964.

Foi uma revolução.

Pela primeira vez uma família inteira de computadores utilizava a mesma arquitetura.

Junto com ela surgiu o conceito de execução Batch em larga escala.

Era necessário criar uma linguagem capaz de dizer ao sistema operacional:

  • qual programa executar;

  • quais arquivos utilizar;

  • quais impressoras imprimir;

  • onde gravar a saída;

  • como controlar o fluxo.

Nascia o Job Control Language (JCL).


UNIX

Cinco anos depois, em 1969, Ken Thompson iniciou o UNIX nos Bell Labs.

A filosofia era completamente diferente.

Em vez de grandes computadores corporativos, o objetivo era construir um sistema operacional simples, modular e portátil.

Ao invés de Jobs Batch, surgiram pequenos comandos.

Ao invés de DD Statements, surgiram arquivos comuns.

Ao invés de datasets catalogados, surgiram diretórios.

Ao invés do JCL, surgiu o Shell.


O Problema que Ambos Resolvem

Apesar das diferenças históricas, ambos procuram responder exatamente às mesmas perguntas:

O que deve ser executado?

Em que ordem?

Quais arquivos serão utilizados?

Como tratar erros?

O que fazer quando terminar?

É justamente por isso que tantas empresas conseguem integrar Mainframe e Linux.


A Filosofia de Cada Um

JCL

O JCL é uma linguagem declarativa.

Ele descreve um trabalho.

O sistema operacional executa.

Exemplo:

//JOB1 JOB ...
//STEP1 EXEC PGM=COBOLPGM
//SYSIN DD *
...

Você informa:

  • programa

  • datasets

  • parâmetros

O restante fica sob responsabilidade do z/OS.


Shell Script

O Shell Script é procedural.

Você escreve cada passo.

cp arquivo backup

gzip backup

rm arquivo

O Shell executa exatamente na ordem definida.


Primeira Grande Diferença

JCL controla programas.

Shell Script executa comandos.

Essa distinção parece pequena.

Mas muda completamente a arquitetura.


Quem executa?

Mainframe

JCL

↓

JES2/JES3

↓

Initiator

↓

Programa COBOL

O JES agenda.

Controla filas.

Seleciona recursos.

Gerencia prioridades.


Linux

Shell

↓

Kernel

↓

Processo

Muito mais direto.

Não existe um JES intermediário.


Comparando Conceitos

IBM JCLShell Script
JOBScript
STEPComando
EXECExecução
DDArquivo
PROCFunção
PARM$1 $2
RCExit Status
CONDif
Schedulercron
SYSINstdin
SYSOUTstdout
SYSPRINTstdout
JESShell + Kernel

Observe que praticamente todos os conceitos possuem um equivalente.


JOB x Script

No Mainframe:

//MEUJOB JOB ...

No Linux

#!/bin/bash

Ambos representam o início da automação.


STEP x Comando

Cada STEP executa um programa.

//STEP01 EXEC PGM=SORT

No Shell

sort arquivo.txt

A ideia é exatamente a mesma.


DD Statement x Arquivos

No Mainframe

//ENTRADA DD DSN=CLIENTES

No Linux

clientes.txt

O conceito é semelhante.

A implementação é completamente diferente.


Dataset vs Sistema de Arquivos

Mainframe

CLIENTES.VENDAS.2025

Linux

/clientes/vendas/2025.txt

No Mainframe existe um catálogo.

No Linux existe uma árvore de diretórios.


GDG x Arquivos Versionados

O GDG cria gerações automaticamente.

ARQ(+1)

ARQ(0)

ARQ(-1)

No Linux normalmente fazemos:

backup-20260704.tar.gz

Ou utilizamos ferramentas como:

  • rsnapshot

  • borg

  • restic


PROC x Funções

PROC

// EXEC PROC=BACKUP

Shell

backup(){

}

Ambos evitam repetição.


RC x Exit Status

Talvez a maior semelhança.

Mainframe

RC=0000

Linux

$?

↓

0

RC 8

No Linux

Exit Status 8

A filosofia permanece.


COND x IF

JCL

COND=(4,LT)

Shell

if [ $? -lt 4 ]
then

fi

Mesmo conceito.

Sintaxe diferente.


Scheduler x Cron

Mainframe

Control-M

CA-7

IBM Workload Scheduler

ESP

Linux

Cron

Systemd Timer

Kubernetes CronJob

Airflow

A ideia continua sendo:

"Execute automaticamente."


SYSIN x stdin

Mainframe

//SYSIN DD *

Linux

comando < entrada.txt

Ambos fornecem entrada ao programa.


SYSOUT x stdout

Mainframe

//SYSPRINT DD SYSOUT=*

Linux

>

Redirecionamento.


RC e Tratamento de Erros

Mainframe

IF RC > 8

Linux

if [ $? -gt 8 ]

Scripts profissionais verificam sempre o retorno da operação anterior.


Pipes

Aqui surge uma diferença enorme.

O JCL não possui Pipes nativos.

No Linux:

grep ERROR log \
| awk '{print $2}' \
| sort \
| uniq

Os dados fluem diretamente entre processos.

É uma das maiores inovações do UNIX.


grep x SORT Utility

Mainframe

DFSORT

ICETOOL

SYNCSORT

Linux

grep

sort

uniq

cut

awk

sed

São ferramentas menores, porém extremamente especializadas.


IDCAMS x Comandos Linux

IDCAMS

LISTCAT

DELETE

DEFINE

ALTER

No Linux

ls

rm

mkdir

mv

cp

Ambos administram recursos.


IKJEFT01

No Mainframe

Executa comandos TSO em Batch.

No Linux

O próprio Shell executa comandos diretamente.


Variáveis

No JCL

&DATA

No Shell

$DATA

Conceito muito semelhante.


Loops

JCL praticamente não possui repetição.

Shell

for

while

until

Essa é uma enorme vantagem do Shell.


Expressões Regulares

Outro diferencial.

O Shell possui:

grep

sed

awk

regex

O JCL depende normalmente do programa executado.


Permissões

No Mainframe

RACF

ACF2

Top Secret

No Linux

rwx

Controlados por:

chmod

chown

ACL


Segurança

Mainframe

RACF

Linux

PAM

SELinux

AppArmor

Embora diferentes, ambos seguem princípios semelhantes de autenticação e autorização.


Performance

O Mainframe foi criado para:

milhões de transações

Linux

milhões de processos

Cada um otimizado para seu ambiente.


Cloud

JCL praticamente não conversa diretamente com APIs REST.

Shell Script faz isso naturalmente.

curl

wget

Essa integração explica sua enorme popularidade.


DevOps

Ferramentas modernas utilizam Shell Script diariamente.

Jenkins

GitLab

GitHub

Docker

Kubernetes

Ansible

Terraform

Mesmo quando escritas em outras linguagens, o Shell continua sendo a "cola" que integra todas elas.


Shell no IBM Z

Aqui muitos profissionais se surpreendem.

O z/OS possui o UNIX System Services (USS).

Isso significa que é possível executar:

  • Bash

  • Korn Shell

  • POSIX Shell

  • Git

  • Python

  • Java

Tudo dentro do IBM Z.

É justamente esse recurso que permite pipelines modernos envolvendo COBOL, Git, Jenkins e DevOps.


Curiosidades

  • O JCL possui mais de 60 anos de história e continua em uso em bancos, seguradoras e governos.

  • O Bash, lançado em 1989, permanece como o shell padrão de inúmeras distribuições Linux.

  • O primeiro shell do UNIX era extremamente simples e não possuía muitos dos recursos atuais, como histórico de comandos e autocompletar.

  • O conceito de pipe (|) foi introduzido no UNIX na década de 1970 e tornou-se um dos maiores símbolos da filosofia UNIX.

  • Muitos scripts corporativos executados diariamente ainda são compostos por poucas dezenas de linhas, mas movimentam bilhões de dólares em operações.


Easter Eggs

Algumas curiosidades divertidas:

  • O nome Bash significa Bourne Again Shell, uma brincadeira com o Bourne Shell original.

  • O comando : é um comando válido que não faz nada e retorna sucesso (0).

  • true sempre retorna código de sucesso.

  • false sempre retorna um código de erro.

  • No JCL, um único parâmetro incorreto em um DD Statement pode impedir a execução de um Job inteiro; no Shell, esquecer aspas em uma variável pode causar efeitos igualmente inesperados.


Quando Escolher Cada Um?

Use JCL quando:

  • estiver executando workloads Batch do z/OS;

  • precisar integrar programas COBOL, PL/I, Assembler ou Db2 no ambiente Mainframe;

  • utilizar JES, datasets, PROCs e schedulers corporativos.

Use Shell Script quando:

  • administrar servidores Linux;

  • automatizar tarefas DevOps;

  • criar pipelines CI/CD;

  • integrar APIs REST;

  • trabalhar com containers, Kubernetes e serviços em nuvem;

  • automatizar operações no z/OS UNIX System Services.

Em muitos ambientes modernos, os dois convivem: o JCL inicia processos no z/OS, enquanto o Shell Script automatiza componentes Linux, integra aplicações via APIs e participa dos pipelines de entrega contínua.

Conclusão

JCL e Shell Script são filhos de épocas diferentes, mas compartilham a mesma missão: automatizar o trabalho do computador para que o operador não precise repetir tarefas manualmente. O JCL nasceu em um mundo dominado por processamento batch, grandes volumes de dados e controle rigoroso de recursos do IBM Mainframe. O Shell Script surgiu em um ambiente UNIX que valorizava simplicidade, modularidade e a composição de pequenos programas especializados.

Para um Programador COBOL Padawan, compreender essa relação é um enorme diferencial. Em vez de enxergar o Linux como um universo completamente novo, é possível reconhecer conceitos familiares: JOB e script, STEP e comando, PROC e função, RC e Exit Status, SYSIN e stdin, SYSOUT e stdout. Essa ponte reduz a curva de aprendizado e facilita a atuação em projetos de modernização.

Na era da transformação digital, não existe mais uma divisão rígida entre Mainframe e plataformas abertas. Bancos, seguradoras, indústrias e órgãos governamentais executam aplicações COBOL no IBM Z, integram serviços por APIs, utilizam Git, Jenkins, Ansible, Kubernetes e automatizam grande parte da infraestrutura com Shell Script. O profissional que domina esses dois mundos torna-se capaz de construir soluções híbridas, conectar tecnologias históricas às plataformas modernas e participar da evolução contínua da computação corporativa.

Em outras palavras, aprender Shell Script não significa abandonar o Mainframe. Significa ampliar sua caixa de ferramentas e levar a experiência adquirida no IBM Z para um ecossistema cada vez mais integrado, automatizado e orientado à nuvem. Esse é o caminho do Programador COBOL Padawan rumo ao próximo nível de sua jornada profissional.