🔥 JCL como Pipeline DevOps
Conhecimento básico sobre aplicações distribuídas para mainframers
☕ Midnight Lunch no CPD (agora com YAML na mesa)
Era madrugada. Café forte. JES2 organizando a fila com mais elegância do que muito orquestrador moderno.
Um arquiteto cloud visita o CPD e comenta:
“Hoje fazemos tudo com pipeline DevOps.”
O mainframer olha para o JCL rodando há 20 anos e responde em silêncio:
👉 “Engraçado… eu faço isso desde antes de chamar assim.”
Este artigo é sobre isso:
JCL como pipeline DevOps, explicado para quem já domina batch, job, step, CC e restart — e quer entender aplicações distribuídas sem abandonar a alma mainframe.
🧠 Pipeline DevOps, em português mainframe
No mundo moderno, um pipeline DevOps:
-
Compila
-
Testa
-
Executa
-
Publica
-
Reprocessa em caso de falha
-
Controla recursos
-
Gera logs
No mundo mainframe, isso sempre foi:
📌 Pipeline DevOps = Job bem escrito.
🕰️ Um pouco de história (spoiler: nada é novo)
Antes de:
-
Jenkins
-
GitLab CI
-
GitHub Actions
-
Argo
-
Airflow
Já existia:
-
JES
-
JCL
-
PROCs
-
COND
-
RESTART
-
SMF
💡 Curiosidade Bellacosa:
O JCL nasceu automatizando fluxo de trabalho. Exatamente o que DevOps promete até hoje.
🧩 Mapeamento direto: JCL ↔ DevOps
| DevOps Pipeline | JCL |
|---|---|
| Stage | STEP |
| Pipeline file | JOB |
| Agent | Initiator |
| Retry | RESTART |
| Conditional | COND |
| Resource limit | TIME / REGION |
| Logs | SYSOUT / SMF |
| Scheduling | JES |
👉 A diferença é sintaxe, não conceito.
⚙️ JOB Statement: o manifesto DevOps original
Hoje você descreve tudo em YAML.
No mainframe, isso sempre existiu:
Isso define:
-
Prioridade
-
Limite (ou não) de CPU
-
Memória
-
Classe de execução
-
Comportamento operacional
💡 Easter Egg:
PRTY=15 é o “run ASAP” do DevOps raiz 😎
🔀 Steps como stages de pipeline
Cada STEP é um stage isolado, previsível e rastreável:
📌 Isso é:
-
Build
-
Test
-
Deploy
Só que sem marketing.
❌ COND: o if/else que evita desperdício
DevOps fala em:
“Não execute se o estágio anterior falhar.”
JCL já resolvia:
Tradução:
“Se algo deu ruim, nem continua.”
👉 Economia de CPU, custo e paciência.
🔄 RESTART: o sonho de todo pipeline moderno
Quantos pipelines cloud ainda fazem restart de verdade?
No mainframe:
-
Nada de reprocessar tudo
-
Nada de gambiarra
-
Nada de “vamos rodar de novo desde o começo”
💡 Curiosidade:
RESTART idempotente é disciplina de projeto. O mainframe sempre exigiu isso.
🌐 JCL e aplicações distribuídas
Hoje, um pipeline DevOps pode:
-
Chamar APIs
-
Publicar eventos
-
Rodar batch
-
Integrar sistemas
No mundo híbrido:
-
JCL dispara batch
-
Batch chama MQ
-
MQ aciona microserviço
-
Microserviço chama CICS
-
CICS grava no DB2
-
SMF registra tudo
👉 JCL vira o maestro do ambiente distribuído.
📊 Observabilidade: antes era obrigação
Hoje falam:
-
Observability
-
Tracing
-
Metrics
No JCL:
-
SYSOUT
-
SMF
-
RMF
-
JES logs
📌 Se não tem log, não roda.
📌 Se não mede, não entra em produção.
Mainframe ensinou isso cedo.
🪜 Passo a passo mental para o mainframer virar “DevOps”
-
Veja jobs como pipelines
-
Veja steps como stages
-
Veja JES como scheduler
-
Veja SMF como observabilidade
-
Veja RESTART como retry inteligente
-
Ignore o hype, foque nos princípios
📚 Guia de estudo (com cérebro mainframe)
🔹 Estude:
-
CI/CD
-
Pipelines
-
Event-driven
-
Observabilidade
🔹 Faça paralelos:
-
JCL ↔ YAML
-
JES ↔ Orquestrador
-
COND ↔ if/else
-
RESTART ↔ rerun from failure
🔹 Exercício clássico:
“Esse pipeline sobreviveria a um batch noturno de verdade?”
🏁 Conclusão – El Jefe fecha o pipeline
DevOps não inventou:
-
Orquestração
-
Automação
-
Governança
-
Resiliência
Ele renomeou.
O JCL já fazia tudo isso:
-
Sem buzzword
-
Sem framework da moda
-
Sem quebrar a cada release
Por isso, quando alguém diz:
“Pipeline moderno é coisa nova”
O mainframer responde, calmamente, com o café na mão:
“Novo é o nome.
O conceito… eu já rodei em produção.” ☕🔥