CI/CD no Mainframe: o que funciona, o que é mito e o que ninguém te contou

por El Jefe – Midnight Lunch

Durante anos, falar de CI/CD e mainframe na mesma frase era quase heresia.
De um lado, o discurso moderno: Git, pipelines, YAML, automação total.
Do outro, o mundo real: COBOL, JCL, CICS, batch crítico, auditoria, SLA e medo justificado de quebrar produção.

A boa notícia?
CI/CD é possível no mainframe.
A má notícia?
Não do jeito que a galera cloud imagina.

Este artigo não é evangelização. É sobrevivência técnica.

---

Antes de tudo: CI/CD não é ferramenta, é disciplina

O maior erro ao tentar “modernizar” o mainframe é achar que CI/CD é instalar Jenkins, Tekton ou OpenShift.

CI/CD é:

• controle rigoroso de mudanças

• builds reproduzíveis

• rastreabilidade

• automação com governança

• rollback possível (e rápido)

Curiosamente, o mainframe sempre fez isso — só não chamava assim.

Endevor, ChangeMan, ISPW:

• controlam versão

• impõem fluxo

• exigem aprovação

• deixam rastro para auditoria

Ou seja:
o mainframe não está atrasado — ele só não usa camiseta preta escrito DevOps.

---

Onde o Git entra (e onde ele não manda)

Git é excelente para:

• versionar código-fonte

• colaboração entre times

• automação de gatilhos (webhooks)

• integração com pipelines modernos

Mas Git não substitui:

• controle de promoção entre ambientes críticos

• segregação de funções exigida por auditoria

• governança de produção Z/OS

Por isso, o modelo que funciona não é Git versus Endevor.
É Git + Endevor.

Modelo realista (e profissional)

• Git → source of collaboration

• Endevor → source of control

• Pipeline → ponte automatizada

Quem tenta matar o Endevor normalmente aprende da pior forma:
na auditoria… ou no incidente.

---

CI no mainframe: sim, dá — e dá bem

Integração Contínua em mainframe significa:

1. Commit COBOL no Git

2. Pipeline dispara:

   • análise estática (ex: Sonar, AppScan)

   • build automatizado (DBB)

   • compilação com dependências reais

3. Geração de artefatos rastreáveis

4. Publicação de evidências

Ferramentas comuns:

• IBM Dependency Based Build (DBB)

• Jenkins / Tekton

• Scripts Z/OS

• Analisadores estáticos

Nada mágico.
Nada “low-code milagroso”.
Só engenharia.

---

CD no mainframe: aqui mora o respeito

Entrega Contínua no mainframe não é deploy automático em produção.

É:

• promoção controlada

• aprovação explícita

• janela operacional

• rollback testado

O pipeline:

• prepara

• valida

• evidencia

Quem promove para produção continua sendo:

• o change

• a operação

• o processo

E isso não é atraso — é responsabilidade.

---

YAML no mainframe: vilão ou aliado?

YAML não é moda.
É apenas uma forma declarativa de dizer:

“este é o pipeline, nesta ordem, com estas regras”

Ele não substitui JCL.
Ele orquestra.

YAML:

• define pipelines

• descreve estágios

• integra ferramentas

JCL:

• executa trabalho pesado

• fala direto com o Z

Quem confunde os dois costuma quebrar um ou outro.

---

GitOps: ótimo… com limites claros

GitOps funciona muito bem para:

• Kubernetes

• ambientes declarativos

• infra elástica

No mainframe:

• GitOps não governa produção

• GitOps não substitui change

• GitOps não remove segregação

Mas ele ajuda:

• na camada distribuída

• no controle de pipelines

• na padronização

Argo CD conversa com OpenShift.
O OpenShift conversa com pipelines.
O pipeline conversa com o mainframe.

Esse é o desenho correto.

---

O anti-pattern clássico (e perigoso)

“Vamos colocar produção Z controlada direto por Git”

Tradução:

• auditoria reprovada

• operação em pânico

• arquiteto desempregado

Modernizar não é destruir o que funciona.
É integrar com inteligência.

---

O verdadeiro estado da arte

Hoje, ambientes maduros fazem:

• Git para código

• Pipeline CI automatizado

• DBB para build real

• Endevor para promoção

• Evidência para compliance

• Observabilidade para melhoria contínua

Sem hype.
Sem discurso de palco.
Com produção estável.

---

Conclusão: CI/CD no mainframe é engenharia adulta

Mainframe não precisa virar cloud.
Precisa conversar com ela.

CI/CD no Z:

• é possível

• é poderoso

• exige respeito ao contexto

Quem entende isso não briga com a plataforma.
E quem não entende… escreve post chamando o mainframe de legado morto.

Nós sabemos quem continua pagando o salário no fim do mês.

---

🕛 El Jefe – Midnight Lunch
Onde DevOps encontra o mundo real e sobrevive.

UrbanCode DBB: Controle de Versionamento no Mainframe, do Jeito Certo

Se você já trabalhou em mainframe, sabe que cada linha de código é sagrada. Um erro de versionamento e você pode acordar com todo o departamento olhando para você como se tivesse errado o compilador na sexta-feira à tarde. Foi justamente pensando nisso que nasceu o UrbanCode DBB, o guardião do código COBOL, PL/I, Assembler, JCL e tudo mais que roda em z/OS.

História e Origem

O DBB, que significa Dependency Based Build, começou sua vida nos laboratórios da IBM como uma forma de modernizar o build de aplicações mainframe. A ideia era simples: parar de depender de scripts complicados de JCL e REXX espalhados pelo servidor e criar algo que entendesse as dependências reais do seu código.

Em 2016, o UrbanCode comprou a tecnologia e integrou no seu portfólio de DevOps, transformando o DBB numa peça central para mainframe moderno, pronto para integração com pipelines CI/CD, Git, Jenkins e até o mundo do container e cloud.

Para que serve e por que usar

Imagine o seu sistema legado com dezenas de programas COBOL interdependentes. Alterou um copybook ou uma tabela DB2? Então você precisa recompilar tudo que depende disso, mas somente o que realmente depende. Aqui entra o DBB:

• Detecção de dependências: Ele analisa seu código e entende as relações entre programas, módulos e copybooks.

• Build incremental inteligente: Só recompila o que precisa, economizando horas de batch.

• Integração DevOps: Pode ser chamado por Jenkins, GitLab, UrbanCode Deploy, tornando o mainframe parte do fluxo ágil.

Em resumo: DBB é o cupido do build, unindo o que mudou com o que precisa mudar.

Como usar: dicas práticas

1. Estrutura de projetos: Organize seu código como projetos, módulos e pacotes. DBB adora clareza.

2. Dependência declarativa: Marque copybooks, DB2 DDL e includes. Quanto mais informação ele tiver, mais eficiente será o build.

3. Log e rastreabilidade: Sempre revise os logs. DBB é detalhista — ele te conta cada recompilação que fez.

4. Pipeline CI/CD: Integre DBB ao Jenkins ou UrbanCode Deploy para builds automáticos e consistentes.

Exemplo básico

Imagine que você tem um programa PAYROLL que depende de EMPLOYEE e SALARY. Se você altera apenas SALARY, DBB identifica que apenas PAYROLL precisa de recompilação, poupando tempo e evitando que outros programas sejam recompilados desnecessariamente.

PROJECT PAYROLL
   MODULE EMPLOYEE
   MODULE SALARY
   MODULE PAYROLL
   DEPENDS_ON SALARY, EMPLOYEE
ENDPROJECT

Simples, mas poderoso.

Curiosidade e Easter Egg

Você sabia que o DBB foi inspirado em técnicas de build usadas em ambientes UNIX? A diferença é que ele traduziu essas ideias para o z/OS, entendendo a complexidade do JCL, copybooks e DB2.

E o easter egg? Se você examinar os logs detalhados, verá pequenos comentários de debug deixados pelos engenheiros: mensagens como "Aqui mora o fantasma do COBOL" ou "Não acorde o compilador antes do café"… só quem vive de batch entende.

Comentários finais

O DBB é um salvavidas para equipes que querem DevOps sem abandonar o mainframe. Ele reduz erros, agiliza deploys e ainda preserva aquela aura mística de que o código mainframe “funciona sozinho, mas precisa de respeito”.

Se você ainda não experimentou, vale a pena. Modernizar builds não é apenas um luxo, é sobre manter a sanidade e ganhar tempo para o café da tarde.

📘 Apostila DevOps Mainframe Jenkins, Ansible, UrbanCode Deploy e o renascimento do z/OS

 

📘 Apostila DevOps Mainframe

Jenkins, Ansible, UrbanCode Deploy e o renascimento do z/OS

Há quem ainda acredite que DevOps nasceu na cloud.
Quem viveu mainframe sabe: o mainframe sempre foi DevOps, só não chamava assim.

Muito antes de YAML, pipelines e dashboards coloridos, o IBM mainframe já praticava:

• automação,

• segregação de ambientes,

• controle rigoroso de mudanças,

• rollback planejado,

• auditoria completa.

A diferença é que tudo isso era feito com JCL, PROCs, schedulers e disciplina operacional.
Hoje, Jenkins, Ansible e UrbanCode Deploy apenas vestem roupa nova numa mentalidade antiga e sólida.

---

🏛️ Um pouco de história (para colocar as coisas no lugar)

Nos anos 70, 80 e 90, o ciclo de vida de uma aplicação COBOL era rígido por necessidade:

• DEV não era QA

• QA não era PROD

• PROD era sagrado

Cada passo deixava rastro. Cada job tinha dono. Cada erro custava caro.

Quando o mundo distribuído descobriu o caos de “funciona na minha máquina”, o mainframe já tinha aprendido — na dor — que processo salva sistemas.

O DevOps moderno surge tentando recuperar essa disciplina, agora com ferramentas novas.

---

🔧 Onde entram Jenkins, Ansible e UrbanCode no mainframe?

Jenkins — o orquestrador inquieto

No mundo IBM mainframe, o Jenkins não compila COBOL.
Ele manda o mainframe trabalhar.

Seu papel é:

• detectar mudanças no Git,

• iniciar pipelines,

• submeter JCL via Zowe,

• validar RC,

• organizar o fluxo.

📌 Easter egg Bellacosa:
Jenkins é, na prática, um scheduler nervoso, menos paciente que o Control-M, mas muito mais falador.

---

Ansible — o bibliotecário organizado

Ansible traz para o z/OS algo que o mainframe sempre gostou: padronização.

Com playbooks YAML, ele:

• copia datasets,

• executa comandos,

• submete jobs,

• garante que ambientes estejam no estado correto.

📌 Curiosidade:
Para quem vem de REXX e JCL, Ansible lembra um EXECIO com esteróides, só que multiplataforma.

---

UrbanCode Deploy — o velho auditor que agora usa terno novo

O IBM UrbanCode Deploy (UCD) é onde o mainframe se sente em casa.

Ele entende:

• ambientes,

• promoção controlada,

• aprovação,

• rollback,

• compliance.

UCD não é “mais um Jenkins”.
Ele é o guardião do PROD, aquele colega sisudo que pergunta:

“Tem aprovação? Tem plano de volta?”

📌 Easter egg corporativo:
Em muitos bancos, o UCD é o novo CMF disfarçado de DevOps.

---

🧠 Aplicação real no mundo IBM Mainframe

Um pipeline típico hoje funciona assim:

1. COBOL versionado em Git

2. Jenkins dispara a integração contínua

3. JCL compila e link-edita no z/OS

4. Ansible prepara datasets e ambientes

5. UCD promove DEV → QA → PROD

6. Tudo auditado, versionado e rastreável

Nada disso quebra o mainframe.
Pelo contrário: valoriza sua arquitetura.

---

📋 Dicas práticas de quem já viu produção cair

✔ YAML orquestra, JCL executa
✔ Nunca coloque lógica de negócio no pipeline
✔ RC é lei — ignore RC e aprenda pelo incidente
✔ PROD não é laboratório
✔ Rollback não é opcional
✔ Automação sem governança é só caos rápido

---

🐣 Easter eggs para os atentos

• Jenkins + Zowe é o novo Submit Job com esteroides

• Ansible no z/OS é o primo moderno do REXX batch

• UCD herdou o espírito do change management clássico

• DevOps não “modernizou” o mainframe — apenas o reencontrou

---

🧾 Conclusão Bellacosa

O IBM mainframe não precisa ser salvo pelo DevOps.
Ele precisa apenas ser bem apresentado às ferramentas certas.

Jenkins traz velocidade.
Ansible traz ordem.
UrbanCode traz governo.
O z/OS continua fazendo o que sempre fez melhor: rodar o mundo sem cair.

E quem domina essa integração não está preso ao passado —
está segurando o futuro com as duas mãos.

🧠 Comparativo Mainframe REXX vs Shell Script vs Python

 

🧠 Comparativo Mainframe

REXX vs Shell Script vs Python

---

1️⃣ REXX (TSO/E – ISPF – Batch)

✅ Vantagens

✔ Nativo do mainframe (vem no z/OS)
✔ Integração direta com:

• TSO/E

• ISPF

• SDSF

• JES

• SYSREXX

• OPERCMDS / CONSOLE
  ✔ Chamada direta de programas COBOL/ASM (LINKPGM)
  ✔ Manipulação natural de datasets (PS, PDS, PDSE)
  ✔ Baixíssimo overhead
  ✔ Ideal para automação de produção

❌ Desvantagens

✖ Pouco conhecido fora do mundo mainframe
✖ Sintaxe estranha para quem vem de linguagens modernas
✖ Bibliotecas externas quase inexistentes
✖ Não é ideal para APIs REST modernas sem middleware

🎯 Quando usar

✔ Automação batch
✔ Operação e monitoração
✔ SYSREXX
✔ Orquestração COBOL / utilities
✔ Scripts críticos de produção

---

2️⃣ Shell Script (z/OS UNIX – OMVS)

✅ Vantagens

✔ Familiar para quem vem de Linux/Unix
✔ Bom para:

• FTP/SFTP

• Arquivos ASCII

• Integrações externas
  ✔ Excelente para pipelines simples
  ✔ Ótimo para chamadas de comandos USS

❌ Desvantagens

✖ Não é nativo do MVS
✖ Acesso ruim a:

• JES

• SDSF

• TSO

• RACF
  ✖ Manipulação de datasets MVS é limitada
  ✖ Debug difícil em produção
  ✖ Performance inferior para grandes volumes MVS

🎯 Quando usar

✔ Integração com mundo distribuído
✔ Transferência de arquivos
✔ Scripts híbridos mainframe ↔ Linux
✔ Orquestração simples em USS

---

3️⃣ Python (z/OS – USS / Open Source)

✅ Vantagens

✔ Linguagem moderna, popular
✔ Ecossistema enorme de bibliotecas
✔ Ideal para:

• APIs REST

• JSON / XML

• Analytics

• Automação DevOps
  ✔ Fácil integração com Git, CI/CD
  ✔ Curva de aprendizado curta

❌ Desvantagens

✖ Não é nativo MVS
✖ Precisa de:

• Ambiente USS

• Port de Python

• Gerenciamento de versões
  ✖ Performance inferior em I/O MVS pesado
  ✖ Acesso indireto a:

• JES

• SDSF

• RACF
  ✖ Overhead maior que REXX

🎯 Quando usar

✔ Modernização
✔ APIs e microserviços
✔ Integração cloud
✔ DevOps corporativo
✔ Análise de dados

---

4️⃣ Comparativo direto (tabela decisiva)

Critério	REXX	Shell	Python
Nativo z/OS	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐
Batch MVS	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐
JES / SDSF	⭐⭐⭐⭐⭐	⭐	⭐
Chamar COBOL	⭐⭐⭐⭐⭐	⭐	⭐⭐
APIs REST	⭐	⭐⭐	⭐⭐⭐⭐⭐
Performance	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
DevOps	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Curva aprendizado	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

---

5️⃣ Regra de Ouro (mundo real)

❝ REXX governa o core do mainframe
❝ Shell conecta o mainframe ao Unix
❝ Python conecta o mainframe ao mundo moderno

💡 Arquitetura vencedora não escolhe um — combina os três.

---

6️⃣ Exemplo prático real

• REXX

  • Controla jobs batch

  • Chama COBOL

  • Lê JES / SDSF

• Shell

  • Move arquivos

  • Converte EBCDIC ↔ ASCII

• Python

  • Expõe API REST

  • Integra com GitHub / Jenkins

  • Analisa logs

---

7️⃣ Resumo executivo (para arquiteto)

Use se…	Ferramenta
Controle total do z/OS	REXX
Integração Unix	Shell
Cloud / APIs / DevOps	Python

---

🧩 Frase final estilo Bellacosa Mainframe

REXX é o cérebro do mainframe.
Shell é o braço que alcança o Unix.
Python é a ponte para o futuro.

 

🧠💾 DevOps no Mainframe: Quando o COBOL Encontrou o Git

Por Vagner Bellacosa – Bellacosa Mainframe Chronicles – “Porque até o z/OS precisa de pipeline”

---

“No início, havia o JCL. E o JCL era bom.
Mas um dia o DevOps olhou para o Mainframe e disse:
‘Que tal versionar isso aí?’”
— Antigo Provérbio da Guilda dos Analistas de Produção, circa 2018.

---

⚙️ 1. A Origem da Força: Mainframe Antes do DevOps

Nos primórdios do tempo digital — década de 60 — o Mainframe era o único devops possível.
Desenvolvia, testava, implantava e executava tudo no mesmo lugar.
Sem containers, sem cloud, sem microservices. O sistema era monolítico, mas estável como uma rocha.

Os times trabalhavam em ciclos longos:

• meses para desenvolver,

• semanas para testar,

• e madrugadas inteiras para colocar em produção com medo do abençoado abend U4038.

💡 Curiosidade Bellacosa:
O termo DevOps só surgiria nos anos 2000, mas os mainframers já praticavam sua essência muito antes — colaboração, automação e controle eram o DNA natural do z/OS.

---

🔄 2. O Encontro dos Mundos: DevOps e COBOL

Quando o mundo distribuído começou a falar em Agile, CI/CD e pipelines, o Mainframe parecia o tiozão da família que ainda usava pager.
Mas o que pouca gente sabia é que o tiozão guardava o cofre dos bancos, das seguradoras e dos governos.

E então... 💥
IBM, Broadcom, Rocket e BMC perceberam: era hora de modernizar sem destruir.

Assim nasceu o DevOps para Mainframe:
A fusão entre práticas modernas (Git, Jenkins, SonarQube, API Gateway) e linguagens lendárias (COBOL, PL/I, JCL, Assembler).

---

🧰 3. As Ferramentas da Nova Ordem

O arsenal do Cavaleiro DevOps Mainframe é poderoso e variado.
Veja o comparativo entre o lado clássico e o lado moderno da força:

⚔️ Era Clássica	🛰️ Era DevOps
Librarian / Endevor	GitHub / GitLab / Bitbucket
JCL SUBMIT manual	Jenkins Pipeline / Tekton
Compilação no TSO	Build automático com DBB (Dependency Based Build)
ChangeMan / SCLM	UrbanCode Deploy / Ansible
Control-M / CA7	Orquestração via API REST
ISPF Editor	Visual Studio Code com Zowe Explorer
Spool JES2	Logs integrados no Jenkins e Splunk

🧩 Easter Egg Técnico:
O Zowe é o primeiro projeto open source oficial da IBM Z — e seu nome vem da junção de “z/OS” + “owe” (de open web).
Sim, o Mainframe virou web-friendly.

---

🔬 4. O Workflow do Padawan DevOps Mainframe

Vamos decodificar o ciclo de vida moderno de um projeto COBOL com DevOps.

🪐 Etapa 1 – Codificação

O desenvolvedor escreve o COBOL no VS Code com o plugin Zowe Explorer, salvando direto no Git.

“Adeus ISPF Edit... Olá Ctrl+S!”

⚙️ Etapa 2 – Build Automatizado

O commit aciona o Jenkins, que executa o IBM DBB — ferramenta que compila COBOL, monta COPYBOOKS e cria LOADs automaticamente.

🧪 Etapa 3 – Teste Automatizado

Entram em cena frameworks como:

• ZUnit (para testar programas COBOL)

• Topaz for Total Test (Broadcom)

• IBM zUnit + Jenkins Reports

Os testes validam não só a lógica, mas também o acesso a DB2 e VSAM.

🧭 Etapa 4 – Integração Contínua

Após os testes, o build é integrado a ambientes de QA via UrbanCode Deploy, garantindo controle e versionamento de componentes.

🚀 Etapa 5 – Deploy

Deploy automatizado no CICS, Batch, IMS ou Web Service.
Tudo monitorado com SonarQube, Splunk e SMF logs.

---

🧙‍♂️ 5. Metodologia do Caminho DevOps

Um Jedi Mainframe moderno segue quatro princípios:

1. Automatize tudo que puder — builds, testes, deploys e até submissão de JCLs.

2. Integre com respeito — nem tudo deve ser refatorado; às vezes o legado é sábio.

3. Versão é poder — o Git é o novo repositório sagrado.

4. Feedback é Força — monitore, aprenda, ajuste.

📜 Curiosidade Bellacosa:
O IBM DBB foi desenvolvido originalmente como um projeto interno chamado “Project Bluemix for z/OS”.
Ele traduz a dependência do mundo JCL em pipelines YAML. Um verdadeiro “tradutor de eras”.

---

⚡ 6. O DevOps Mainframe em Ação

Um pipeline típico de DevOps COBOL pode ser visualizado assim:

GIT PUSH
   ↓
JENKINS PIPELINE
   ↓
IBM DBB BUILD
   ↓
ZUNIT / TOPAZ TESTS
   ↓
URBANCODE DEPLOY
   ↓
Z/OS CICS EXECUTION
   ↓
MONITOR / FEEDBACK LOOP

💬 Easter Egg Filosófico:
“Pipeline é o novo JCL.”
Enquanto o JCL executa passos em batch, o pipeline orquestra passos de automação.
Ambos seguem o princípio da execução sequencial controlada — separados apenas por 50 anos de sintaxe. 😎

---

🕰️ 7. A Linha do Tempo da Evolução

Ano	Marco	Descrição
1964	Lançamento do System/360	O berço da automação batch
1980	SCLM e Librarian	Controle de versão rudimentar
1990	Endevor e ChangeMan	CM integrado ao ciclo de vida
2010	IBM DBB & UrbanCode	DevOps ganha cara no z/OS
2018	Projeto Zowe	Mainframe abraça o open source
2020+	Git + Jenkins + API REST	A força se equilibra

---

☕ 8. Dicas do Mestre Bellacosa

• Sempre compile com mensagens ativas: use LIST, XREF no compilador — são o “lint” do COBOL.

• Evite mexer direto no Loadlib: agora ele é gerado automaticamente — é o artefato, não o playground.

• Integre CICS e DB2 nos testes: DevOps não é só build, é comportamento de sistema.

• Zowe CLI é sua varinha mágica: automatize submissão de JCL, consulta a spool e deploys sem entrar no ISPF.

---

🧩 9. O Lado Oculto da Força (Curiosidades)

• O primeiro pipeline DevOps para COBOL foi rodado na IBM Poughkeepsie Labs, em um z13 — com sucesso total, sem um único abend.

• Algumas empresas usam Docker simulando z/OS via ZD&T (z Development & Test Environment).
  Sim, é possível rodar um “mini mainframe” dentro de um laptop gamer! 🎮

• O termo “Mainframe Modernization” virou moda — mas quem entende sabe que modernizar ≠ migrar.
  O segredo é integrar, não substituir.

---

🌌 10. Conclusão: O Mainframe Nunca Dorme

O DevOps não é o fim do legado — é o elo entre gerações.
Hoje, um pull request pode acionar um JCL SUBMIT, e um commit pode atualizar um CICS.
O Mainframe não ficou velho: ele apenas aprendeu a conversar com os jovens.

“O Mainframe não é um dinossauro.
É o dragão que aprendeu a voar em nuvens.” 🐉☁️

 

 

🧾 JCL – Linha do Tempo Completa

Do cartão perfurado ao DevOps no z/OS

---

🧠 Antes do JCL (anos 1950 – início dos 60)

Contexto

• Programas rodavam em batch puro, controlados manualmente.

• Operadores plugavam cabos, montavam fitas, ajustavam switches.

• Cada sistema tinha seu próprio “jeito” de rodar jobs.

📌 Problema:
Não existia uma linguagem padrão para dizer o que rodar, quando e com quais recursos.

👉 Solução da IBM: criar uma linguagem declarativa para controlar o sistema.

---

🟦 1964 – NASCE O JCL (OS/360)

Sistema: OS/360
Hardware: IBM System/360
Evento histórico: um único SO para toda a linha de hardware.

O que surge

• JCL formalmente introduzido

• Conceitos fundamentais:

  • //JOB

  • //EXEC

  • //DD

• Sintaxe baseada em cartões perfurados

• Colunas fixas, 80 caracteres, tolerância zero a erro

📌 Impacto

• Pela primeira vez, o operador deixa de decidir tudo manualmente

• O job descreve:

  • programa

  • datasets

  • dispositivos

  • prioridade

🧨 Easter Egg histórico

Fred Brooks (IBM) disse que JCL foi uma das linguagens mais difíceis já criadas —
mas impossível de abandonar.

---

🟨 1966–1971 – JCL no DOS/360 e OS/360 amadurece

Sistemas: DOS/360, OS/360 MFT/MVT

Evolução

• Pequenas variações de JCL entre DOS e OS

• Mais parâmetros em DD

• Introdução de:

  • datasets temporários

  • concatenação

  • procedimentos simples

📌 Nota Bellacosa
Aqui nasce a primeira dor do mainframer:
👉 “Esse JCL roda no MVT mas não no DOS?”

---

🟧 1972–1974 – A Era do Virtual Storage (OS/VS → MVS)

Sistemas: OS/VS1, OS/VS2, depois MVS

O que muda no JCL

• Nada quebra (compatibilidade total)

• Mas o poder cresce:

  • mais steps

  • mais memória

  • mais jobs simultâneos

• Procedures catalogadas se tornam padrão

• JCL passa a ser infraestrutura crítica

📌 Marco invisível
O JCL deixa de ser “controle de job”
e vira linguagem de orquestração do datacenter.

---

🟥 Final dos anos 70 – JES2 / JES3

Subsistemas: JES2 e JES3

Evolução prática

• JCL começa a dialogar mais com o spool

• Controle refinado de:

  • SYSOUT

  • classes

  • prioridades

• Ambientes multi-LPAR começam a surgir

🧠 Filosofia
JCL continua simples…
mas o ambiente em volta vira um monstro.

---

🟪 Anos 80 – Estabilidade Absoluta

Sistemas: MVS/XA, MVS/ESA

O que muda

• Quase nada na sintaxe

• Muitos novos parâmetros

• JCL vira uma “linguagem fossilizada viva”

📌 Realidade
Um JCL de 1975 ainda roda.
Um COBOL também.
O estagiário não.

---

🟩 1995 – OS/390 (o JCL entra na era corporativa moderna)

Sistema: OS/390

Evolução

• Consolidação:

  • MVS

  • JES

  • DFSMS

• JCL passa a lidar fortemente com:

  • SMS

  • storage groups

  • políticas corporativas

📌 Mudança cultural
O JCL deixa de ser “do operador”
e vira ativo estratégico da empresa.

---

🟦 2000 – z/OS nasce (JCL entra no século XXI)

Sistema: z/OS 1.1

O que muda (sem quebrar nada)

• Integração com:

  • Unix System Services (USS)

  • arquivos POSIX

• JCL agora convive com:

  • shell scripts

  • Java

  • C/C++

• Melhor controle condicional

📌 Importante
Nenhum “JCL 2.0”
Nenhuma revolução sintática
👉 só evolução silenciosa.

---

🟨 2005–2015 – JCL + Automação

Novidades

• IF / THEN / ELSE / ENDIF no JCL

• Mais lógica declarativa

• Menos dependência de retorno via utilitários externos

📌 JCL começa a pensar
Não é programação…
mas já decide caminhos.

---

🟧 2016–2020 – JCL encontra o DevOps

Mudanças indiretas

• JCL versionado em Git

• Edição em VS Code (Z Open Editor)

• Integração com pipelines

• JCL analisado, validado, automatizado

🧠 Paradoxo
A linguagem mais antiga do datacenter
vira parte do pipeline moderno.

---

🟥 2020–2025 – JCL nos z/OS atuais (2.5, 3.x)

Situação atual

• JCL continua:

  • estável

  • retrocompatível

  • crítico

• Novos parâmetros continuam surgindo

• Integração com:

  • Zowe

  • APIs

  • observabilidade

  • automação corporativa

📌 Verdade absoluta
Se o JCL parar,
o banco para.
O país sente.

---

🧭 Linha do tempo resumida

Ano	Sistema	Estado do JCL
1964	OS/360	JCL nasce
1974	MVS	JCL escala
1980s	MVS/XA/ESA	JCL estabiliza
1995	OS/390	JCL corporativo
2000	z/OS	JCL moderno
2010s	z/OS	JCL condicional
2020s	z/OS 3.x	JCL + DevOps

---

☕ Comentário final (Bellacosa Mode ON)

JCL não evoluiu para agradar desenvolvedores.
Evoluiu para não quebrar o mundo.

Enquanto linguagens vêm e vão,
o JCL permanece,
silencioso, feio, poderoso
e absolutamente indispensável.

 

Bellacosa Mainframe apresenta a Cronologia do DEVOps no IBM Mainframe

Cronologia do DEVOPS no IBM Mainframe Z

📅 2012 (± 1 ano)

📌 Por que 2012?

Porque é nesse período que três pilares do DevOps começam a convergir de forma consistente no ecossistema IBM Z:

---

🔹 1. Adoção real de Agile no mainframe (2010–2012)

• Grandes ambientes z/OS passam a adotar Scrum/Kanban para times COBOL, PL/I e Assembler.

• Integração de ferramentas como:

  • Endevor

  • Changeman

  • ISPW

• Começa a quebra do modelo puramente “batch noturno + releases trimestrais”.

👉 Sem Agile, DevOps não existe.

---

🔹 2. Automação de build e deploy (2012–2014)

• Surgimento e adoção de:

  • IBM Dependency Based Build (DBB) (embrião)

  • JCL generation automática

  • Rational Team Concert (RTC) com pipelines

• UrbanCode Deploy (adquirido pela IBM em 2013) passa a ser usado também para z/OS.

👉 Aqui nasce o “Ops automatizado” no mainframe.

---

🔹 3. Integração com ferramentas distribuídas (2013–2015)

• Introdução gradual de:

  • Git como sistema de versionamento (substituindo ou convivendo com PDS/Endevor)

  • Jenkins chamando jobs z/OS

  • REXX e scripts como glue entre mundos

👉 Esse é o ponto onde o mainframe entra oficialmente no pipeline DevOps corporativo.

---

🔹 Marco simbólico importante

📍 2013–2014

• Lançamento e evolução do z/OSMF Workflows

• Primeiros pipelines CI/CD híbridos (Linux + z/OS)

• Mainframe deixa de ser “ilha” e vira plataforma DevOps

---

📚 Linha do tempo resumida

Ano	Marco
2008–2010	Agile começa a tocar o mainframe
2012	🔥 Início teórico do DevOps no IBM Z
2013	UrbanCode + RTC no z/OS
2014	z/OSMF workflows
2015–2017	Git, Jenkins, DBB, pipelines modernos
2018+	DevOps corporativo completo no IBM Z

---

🧠 Definição acadêmica possível

“DevOps no IBM Z começou quando práticas Agile, automação de deploy e integração contínua passaram a ser aplicadas sistematicamente ao ciclo de vida de aplicações z/OS.”

📌 Ano de referência: 2012