 |
| Bellacosa Mainframe relembrando JCL |
☕ Um Café no Bellacosa Mainframe
📜 O Holocron do JCL
A Linguagem que Conversa com o IBM Z Desde a Era dos Cartões Perfurados até a Inteligência Artificial
A imagem apresentada é bastante didática e está correta para alguém iniciando no universo IBM Z. Entretanto, ela simplifica algo que, na prática, representa uma das tecnologias mais sofisticadas e resilientes já construídas pela engenharia de software.
Para um profissional COBOL, um operador, um analista de produção ou um Sysprog, entender JCL significa compreender como o z/OS pensa.
E isso muda completamente a forma de trabalhar.
O que realmente é JCL?
JCL significa:
Job Control Language
Mas essa definição é insuficiente.
Uma definição mais próxima da realidade seria:
JCL é a linguagem declarativa utilizada pelo z/OS para descrever uma unidade completa de processamento batch.
Ela informa:
O que executar
Quando executar
Com quais arquivos
Em quais dispositivos
Com quais limites
Em quais classes
Com qual prioridade
Como tratar erros
Como reiniciar
Como gerar relatórios
Como conversar com subsistemas
JCL não é programação
Essa é uma dúvida comum.
COBOL é procedural.
Python é procedural.
Assembler é procedural.
JCL é declarativo.
Você não diz:
Faça isso
Depois faça aquilo
Você diz:
"Quero que este programa seja executado utilizando estes datasets, estes recursos e estas condições."
O sistema operacional decide como fazer.
Similar a Kubernetes.
Exemplo:
replicas: 3
Você não cria containers.
Você declara.
O orquestrador cria.
JCL fazia isso nos anos 60.
A origem histórica
Década de 1960
IBM System/360
Na época havia cartões perfurados.
Cada cartão tinha 80 colunas.
Exemplo
//STEP01 EXEC PGM=IEFBR14
Era literalmente um cartão.
Daí nasceu:
Coluna 1-2
//
Coluna 3-71
Comandos
72-80
Sequência
Muitos padrões atuais nasceram aqui.
O Batch é o coração do Mainframe
Um dos maiores equívocos modernos é imaginar:
Mainframe = COBOL
Não.
O batch é mais importante.
O COBOL é apenas um passageiro.
Batch executa:
Folha salarial
PIX
FGTS
INSS
Bacen
IRPF
Conciliação bancária
Cartões
Faturamento
Bilhões de registros.
Sem JCL não existe Batch
Imagine um COBOL.
OPEN INPUT CLIENTES
Pergunta:
Onde está CLIENTES?
O COBOL não sabe.
O programa espera.
JCL informa.
//CLIENTES DD DSN=BANCO.CLIENTES,
// DISP=SHR
Agora o programa encontra o dataset.
Anatomia de um JCL
A imagem mostra muito bem.
Existem três pilares.
JOB
Representa o trabalho.
//PAGTO JOB (999),'FOLHA'
Equivalente:
Metadados.
Quem executa.
Classe.
Accounting.
Prioridade.
Tempo.
Região.
Exemplo
MSGCLASS=X
CLASS=A
TIME=1440
EXEC
O cérebro.
Define programa.
//STEP01 EXEC PGM=COBOLPGM
Ou utilitário.
EXEC PGM=SORT
EXEC PGM=IDCAMS
EXEC PGM=IKJEFT01
EXEC PGM=DSNUTILB
DD
Dataset Definition
A parte mais importante.
95% dos problemas em produção estão aqui.
Exemplo:
//ENTRADA DD DSN=EMPRESA.CLIENTES,
// DISP=SHR
Saída:
//SAIDA DD DSN=EMPRESA.RELATORIO,
// DISP=(NEW,CATLG,DELETE)
DISP é quase uma filosofia
Muitos juniores sofrem aqui.
SHR
Compartilhado
DISP=SHR
OLD
Exclusivo
DISP=OLD
NEW
Criar dataset
DISP=(NEW,CATLG,DELETE)
Se sucesso
Cataloga.
Se erro
Apaga.
Elegante.
Muito elegante.
O que realmente acontece quando submetemos um JCL?
A imagem mostra:
Create
Submit
Read
Execute
Mas internamente é muito maior.
Etapa 1
JES2 recebe
Etapa 2
Parser valida sintaxe
Etapa 3
Conversão
Job vira estrutura interna.
JCT
TIOT
JQE
JOE
Control Blocks.
Etapa 4
Scheduler escolhe execução
WLM
Service Class
Importance
Velocity
Etapa 5
Allocation
IEFBR14
Catalog
SMS
Volumes
DASD
Etapa 6
Carregamento
Program Fetch
LPA
Linklist
STEPLIB
Etapa 7
Execução
Etapa 8
Geração de SYSOUT
Spool
JES2
SYSIN é genial
A imagem cita:
SYSIN
Pouca gente entende.
SYSIN é um arquivo virtual.
Exemplo:
//SYSIN DD *
SORT FIELDS=(1,10,CH,A)
SUM FIELDS=NONE
/*
O programa lê como se fosse arquivo.
Mas é texto embutido.
Quase um precursor do conceito de:
Heredoc
ConfigMap
Manifest
Utilitários famosos
IEFBR14
Não faz nada.
Serve para alocar.
Apagar.
Testar.
IDCAMS
VSAM
Catalog
SORT
DFSORT
ICETOOL
IKJEFT01
Executa comandos TSO
DB2
SPUFI
DSN
REXX
IEBGENER
Copiar datasets
Condições e Fluxo
JCL possui lógica.
Pouca gente sabe.
COND
COND=(4,LT)
IF
IF STEP1.RC = 0 THEN
ENDIF
RC
Return Code
0
Sucesso
4
Warning
8
Erro
12
Erro grave
16
Falha crítica
PROC
Reutilização
Semelhante a função.
//PAYPROC PROC ENV=PROD
Chamando:
EXEC PAYPROC
Hoje lembraríamos de:
Template
Ansible
Helm Chart
Pipeline
JCL é DevOps antes do DevOps existir
Comparação moderna:
| JCL | DevOps |
|---|---|
| JOB | Pipeline |
| EXEC | Stage |
| DD | Artifact |
| PROC | Template |
| SYSIN | Configuração |
| JES2 | Scheduler |
| WLM | QoS |
| Catalog | Registry |
| Restart | Rollback |
| COND | Workflow |
Por que aprender JCL em 2026 ainda vale muito a pena?
Porque praticamente todos os setores críticos continuam dependendo dele:
Bancos
Seguradoras
Bolsa de valores
Previdência
Governo
Telecomunicações
Varejo
Processadoras de cartões
Indústria
Milhões de JCLs são executados diariamente em ambientes z/OS. Muitos deles foram escritos há décadas, evoluíram ao longo do tempo e continuam sustentando operações que movimentam trilhões de dólares por ano.
Pergunta de entrevista para impressionar um recrutador
Pergunta: O JCL é apenas uma linguagem para executar programas COBOL?
Resposta esperada:
Não. O JCL é uma linguagem declarativa de controle de processamento do z/OS que define a execução de workloads batch, alocação de recursos, gerenciamento de datasets, integração com subsistemas, políticas de recuperação, automação operacional e interação com JES e WLM. O COBOL é apenas um dos muitos consumidores desse ambiente.
No fim das contas, o JCL é muito mais do que uma "linguagem de execução". Ele é o contrato operacional entre o negócio, os programas e o sistema operacional IBM Z, permitindo que um ecossistema gigantesco funcione de maneira previsível, auditável e extremamente confiável há mais de seis décadas. Para um Padawan COBOL, dominar JCL é deixar de ser apenas um programador e começar a pensar como um verdadeiro habitante do universo z/OS.
