Mostrar mensagens com a etiqueta dataset. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta dataset. Mostrar todas as mensagens

sábado, 7 de março de 2026

🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)

 

Bellacosa Mainframe ensina como encontrar um abend em menos de 60 segundos

🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)

No dia a dia de produção em IBM z/OS, quando um job ABEND acontece, muitos profissionais iniciantes começam abrindo datasets, dumps ou navegando em dezenas de telas.

Operadores experientes fazem diferente.

Eles usam um método rápido baseado no SDSF que normalmente revela a causa do problema em menos de 60 segundos — muitas vezes sem abrir nenhum dataset.

Este é um dos truques clássicos que circulam em grandes ambientes de produção.

☕ Bem-vindo a mais um Um Café no Bellacosa Mainframe.


🧠 A lógica por trás do método

Quando um job falha, o sistema sempre deixa rastros em três lugares principais:

1️⃣ Status do job
2️⃣ Mensagens do JES
3️⃣ Mensagens do sistema (SYSLOG)

O segredo é seguir a ordem correta.


⚡ Passo 1 — Abrir o SDSF e localizar o Job

Entre no SDSF:

SDSF

Depois vá ao painel de status:

ST

Agora filtre rapidamente:

PREFIX JOBNAME

Exemplo:

PREFIX PAYROLL*

Isso reduz a lista para apenas os jobs relevantes.


🔍 Passo 2 — Identificar rapidamente o ABEND

Na coluna RC / CC / ABEND você verá algo como:

ABEND=S0C7
ABEND=S322
ABEND=SB37

Cada código já indica uma pista importante.

Exemplos clássicos:

ABENDSignificado
S0C7erro de dados numéricos
S0C4violação de memória
S322timeout (tempo excedido)
SB37falta de espaço em dataset

Mas ainda não sabemos onde aconteceu.


📜 Passo 3 — Usar o “?” do SDSF (o atalho mais poderoso)

Digite ? ao lado do job.

Isso abre imediatamente o Job Output:

  • JESMSGLG

  • JESJCL

  • JESYSMSG

Sem abrir nenhum dataset manualmente.


🎯 Passo 4 — Ir direto ao JESYSMSG

O arquivo JESYSMSG quase sempre contém a causa.

Procure por linhas como:

IEF450I JOBNAME ABENDED S0C7

ou

IEC030I B37-04

ou

CSV031I LIBRARY NOT FOUND

Em muitos casos a causa já aparece claramente aqui.


🔎 Passo 5 — Confirmar no SYSLOG

Agora abra o log do sistema:

LOG

e procure pelo JobID:

FIND JOB12345

Isso mostra mensagens do sistema relacionadas ao job.

Exemplos:

IEC141I DATA SET NOT FOUND

ou

IEF861I STEP TERMINATED DUE TO ERROR

⚡ Resultado: diagnóstico em menos de 60 segundos

Seguindo apenas estes passos:

SDSF
ST
PREFIX jobname
?
JESYSMSG
LOG
FIND jobid

Normalmente você já descobre:

✔ o step que falhou
✔ o tipo de erro
✔ a mensagem exata do sistema

Sem abrir nenhum dataset manualmente.


🧠 Exemplo real de diagnóstico

Imagine um job que termina assim:

ABEND=SB37

Seguindo o método:

No JESYSMSG aparece:

IEC030I B37-04 ON SYSDA

Diagnóstico imediato:

👉 Dataset ficou sem espaço.

Nenhuma investigação adicional necessária.


💡 A regra de ouro dos operadores experientes

Nos grandes datacenters existe uma regra não escrita:

“Se você abriu dataset antes de olhar o JESYSMSG, começou a investigação do jeito errado.”

80% dos problemas podem ser identificados apenas com SDSF.


☕ Conclusão

O segredo não está em ferramentas complexas.

Está em saber onde olhar primeiro.

Dominar o SDSF significa:

  • investigar incidentes mais rápido

  • reduzir tempo de troubleshooting

  • ganhar confiança em ambientes de produção

E isso separa operadores iniciantes de profissionais experientes no mundo mainframe.


https://www.linkedin.com/pulse/o-m%C3%A9todo-de-60-segundos-para-descobrir-por-que-um-job-bellacosa-jxhkf

quarta-feira, 10 de dezembro de 2025

☕ EXECIO no REXX Mainframe O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

 



EXECIO no REXX Mainframe

O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

“Quando o REXX toca no disco, o EXECIO está por trás.
E quando o disco fica lento, geralmente é culpa de quem não entendeu o EXECIO.”




🧠 Introdução – Onde o REXX encontra o mundo real

REXX é excelente para controle, decisão e orquestração.
Mas em algum momento ele precisa fazer o que todo batch faz desde 1964:

👉 Ler dados
👉 Escrever dados

É aí que entra o EXECIO.

Simples no nome.
Perigoso no impacto.


🕰️ Origem histórica – Por que o EXECIO nasceu?

Antes do EXECIO:

  • REXX era fortemente interativo

  • I/O era dependente de comandos externos

  • Ler arquivos sequenciais era lento e improvisado

Com a popularização do REXX no TSO/E e no batch, a IBM precisava de:

  • Um método padrão

  • Um comando eficiente

  • Compatível com DDNAME

  • Funcional tanto em TSO quanto em batch

Assim nasceu o EXECIO, no final dos anos 80, como ponte direta entre:

REXX ⇄ QSAM ⇄ MVS


📜 O que é EXECIO?

EXECIO é o comando REXX responsável por:

  • Ler registros de um DDNAME

  • Escrever registros em um DDNAME

  • Transferir dados entre datasets e variáveis REXX

Ele trabalha sempre com:

  • DDNAME alocado

  • Registros sequenciais

  • Stem variables


🧪 Sintaxe essencial

EXECIO <quantidade> DISKR <ddname> (STEM var. EXECIO <quantidade> DISKW <ddname> (STEM var.

Exemplo básico:

EXECIO * DISKR SYSIN (STEM linhas.

Aqui:

  • * = todas as linhas

  • DISKR = leitura

  • SYSIN = DDNAME

  • linhas. = onde os dados vão morar


🧩 Curiosidades que pouca gente comenta

🧩 1. EXECIO não entende “arquivo”

Ele entende DDNAME.

Se o DDNAME não existe:

  • RC pode ser enganoso

  • O erro aparece em mensagem

  • GETMSG vira obrigatório


🧩 2. EXECIO * carrega tudo na memória

EXECIO * DISKR BIGFILE (STEM big.

Se o arquivo tem:

  • 10 mil linhas → ok

  • 1 milhão → boa sorte

EXECIO * é confortável… até não ser.


🧩 3. A variável .0 manda mais que você

Após leitura:

say linhas.0

Ela contém quantos registros foram lidos.

Ignorar .0 é convite a loop errado.


🥚 Easter Eggs técnicos

🥚 1. Leitura parcial estratégica

EXECIO 1 DISKR INDD (STEM linha.

Ótimo para:

  • Ler cabeçalhos

  • Identificar layout

  • Decidir processamento sem ler tudo


🥚 2. EXECIO + Data Stack

É possível combinar:

  • EXECIO

  • PUSH / QUEUE

  • PARSE PULL

Criando pipelines “à moda antiga”.


🥚 3. EXECIO em SYSREXX

No batch, EXECIO:

  • Roda sem terminal

  • Depende totalmente do JCL

  • É mais rápido

  • É mais perigoso


🧠 Exemplo prático – Batch inteligente

EXECIO * DISKR INPUT (STEM in. DO i = 1 TO in.0 IF POS('ERRO', in.i) > 0 THEN DO SAY 'Erro detectado na linha' i EXIT 8 END END EXECIO in.0 DISKW OUTPUT (STEM in.

Esse REXX:

  • Analisa

  • Decide

  • Escreve

Tudo antes do COBOL rodar.


⚠️ Riscos reais do EXECIO

  • Arquivo grande → consumo de memória

  • DISKW sem controle → overwrite silencioso

  • DISKR sem validação → loop infinito

  • Falta de fechamento → dados inconsistentes

Boa prática Jedi

EXECIO 0 DISKW OUTDD

Força flush e fechamento correto.


🛡️ EXECIO e segurança

EXECIO respeita:

  • RACF

  • Permissões de dataset

  • Contexto do job

Mas:

REXX que escreve dados é tão poderoso quanto um utility IBM.

Controle de acesso é obrigatório.


☕ Comentário Bellacosa Mainframe

O EXECIO é o momento em que:

  • O REXX deixa de ser “script”

  • E passa a mexer em dados corporativos

Quem trata EXECIO como “detalhe”:

  • Cria batch frágil

  • Gera incidentes silenciosos

  • Descobre o erro em produção

EXECIO não é comando.
É compromisso com o dado.


🧠 Frase final para colar no monitor

Se o REXX leu, ele é responsável.
Se escreveu, ele é culpado até prova em contrário.

segunda-feira, 30 de setembro de 2024

🔥 JCL no z/OS 3.2 — o silêncio que sustenta tudo

 

Bellacosa Maiframe apresenta JCL V3.2 Job Control Language

🔥 JCL no z/OS 3.2 — o silêncio que sustenta tudo



📅 Datas importantes

  • Release (GA): setembro de 2024

  • Final de suporte IBM (EoS): 30 de setembro de 2029 (ciclo padrão de suporte)

O z/OS 3.2 não veio para “mudar o jogo”.
Ele veio para confirmar quem sempre mandou no jogo.


🧬 Contexto histórico

O z/OS 3.2 nasce num mundo onde:

  • Cloud híbrida já é chão de fábrica

  • Observabilidade virou obrigação

  • Segurança é contínua

  • Automação é regra

  • APIs e eventos disparam tudo

E mesmo assim…

👉 o JCL continua sendo o último elo confiável entre intenção e execução.

Bellacosa resumiria assim:

“O mundo ficou barulhento.
O JCL continua em silêncio… funcionando.”


JCL V3.2 Job Control Language

✨ O que há de novo no JCL no z/OS 3.2

A resposta curta (e honesta):

❌ Nada mudou na linguagem
✅ Tudo mudou no peso estratégico do JCL

🆕 1. JCL como fundação do core digital

No z/OS 3.2:

  • O batch é oficialmente serviço corporativo

  • JCL é disparado por:

    • APIs

    • eventos

    • pipelines

    • schedulers cognitivos

  • O JCL vira o contrato final de execução

👉 Se passou pelo JCL, aconteceu de verdade.


🆕 2. JES2 no ponto máximo de previsibilidade

  • Escala massiva de jobs concorrentes

  • Spool estável como rocha

  • Restart e recovery totalmente previsíveis

  • Integração total com automação e monitoramento

O operador agora governa fluxo,
não apaga incêndio.


🆕 3. DFSMS completamente orientado a políticas

  • Storage cada vez mais autônomo

  • Menos parâmetros manuais

  • Menos erro humano

  • Mais inteligência sistêmica

O resultado?
👉 JCL mais limpo, mais legível e mais durável.


🔧 Melhorias percebidas no dia a dia

✔ Batch 24x7 sem drama
✔ Menos “gambiarras históricas”
✔ Mais padronização
✔ JCL tratado como código crítico
✔ Auditoria e rastreabilidade nativas

Nada mudou no //STEP EXEC.
Tudo mudou na responsabilidade do job.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL escrito no OS/360 ainda roda no z/OS 3.2

  • 🥚 IEFBR14 segue vivo e respeitado

  • 🥚 Comentários em JCL mais antigos que DevOps 😅

  • 🥚 O erro mais comum continua sendo:

    • RC ignorado

    • DISP mal planejado

    • dataset em uso em produção

👉 Tecnologia evolui. Erro humano é backward compatible.


💡 Dicas Bellacosa para JCL no z/OS 3.2

🔹 Trate JCL como ativo estratégico corporativo
🔹 Pense no job como serviço crítico, não script
🔹 Versione JCL como código
🔹 Padronize nomes, comentários e RC
🔹 Documente decisões, não só comandos

🔹 Sempre use:

  • IF / THEN / ELSE

  • RC explícito

  • SYSOUT claro

  • comentários pensando em décadas

Esse JCL vai rodar quando você não estiver mais aqui.


📈 Evolução do JCL até o z/OS 3.2

EraPapel do JCL
OS/360Controle batch
MVSAutomação
OS/390Base corporativa
z/OS V1.xOrquestração
z/OS V2.xMundo híbrido
z/OS 3.1Core digital
z/OS 3.2Alicerce definitivo

👉 No z/OS 3.2, o JCL não é discutido.
Ele é assumido.


📜 Exemplo de JCL “cara de z/OS 3.2”

//BELL32 JOB (ACCT),'JCL z/OS 3.2', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //* JOB EXPOSTO COMO SERVIÇO CORPORATIVO //* DISPARADO POR API / EVENTO / PIPELINE //* //STEP01 EXEC PGM=COREPROC //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.WORK.DATA SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse job não sabe quem o chamou.
E isso é exatamente o motivo pelo qual ele é confiável.”


🧠 Comentário final

O JCL no z/OS 3.2 é a confirmação definitiva de uma verdade antiga:

🔥 Confiabilidade não se reinventa.
Ela se preserva.

Enquanto novas plataformas prometem estabilidade,
o JCL segue entregando há mais de 60 anos.

JCL não é passado.
JCL é o chão onde o futuro pisa.

sábado, 30 de setembro de 2023

🔥 JCL no z/OS 3.1 — o clássico definitivo no mainframe pós-híbrido

 

Bellacosa Mainframe apresenta JCL V3.1 Job Control Language

🔥 JCL no z/OS 3.1 — o clássico definitivo no mainframe pós-híbrido

 


📅 Datas importantes

  • Release (GA): setembro de 2023

  • Final de suporte IBM (EoS): 30 de setembro de 2028

O z/OS 3.1 inaugura a era sem versão “R”.
Não é V2Rx. É z/OS 3.x.
E o JCL? Continua lá, firme, como sempre.


🧬 Contexto histórico

O z/OS 3.1 nasce num momento simbólico:

  • Mainframe totalmente integrado ao mundo digital

  • Cloud híbrida consolidada

  • APIs e eventos como padrão

  • Observabilidade, automação, segurança contínua

  • Batch tratado como serviço corporativo crítico

E no centro disso tudo…

👉 o JCL segue intocado, provando que boa arquitetura não precisa ser reescrita.

Bellacosa resumiria assim:

“Mudou o número da versão.
O JCL nem piscou.”


JCL V3.1 Job Control Language

✨ O que há de novo no JCL no z/OS 3.1

Aqui está a verdade nua e crua:

❌ Não existe “novo JCL”
✅ Existe um JCL mais estratégico do que nunca

🆕 1. JCL como API operacional invisível

No z/OS 3.1:

  • Jobs são acionados por:

    • APIs REST

    • eventos

    • pipelines CI/CD

    • schedulers corporativos

  • O JCL vira o contrato final entre:

    • mundo distribuído

    • core transacional

👉 O job é o endpoint que não falha.


🆕 2. JES2 no nível máximo de maturidade

  • Escala absurda de jobs simultâneos

  • Spool altamente estável

  • Restart e recovery previsíveis

  • Integração total com automação e observabilidade

O operador deixou de “apagar incêndio”.
Agora ele governa processos.


🆕 3. DFSMS totalmente orientado a políticas

  • Storage praticamente autônomo

  • Menos parâmetros manuais no JCL

  • Datasets gigantes tratados naturalmente

  • Menos erro humano, mais inteligência sistêmica

O JCL fica mais limpo porque o sistema ficou mais esperto.


🔧 Melhorias percebidas no dia a dia

✔ Batch tratado como serviço 24x7
✔ Menos JCL “cheio de gambiarra”
✔ Menos tuning artesanal
✔ Mais padronização
✔ JCL versionado, auditado e governado

Nada mudou na sintaxe.
Tudo mudou na importância estratégica.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL escrito nos anos 70 ainda roda no z/OS 3.1

  • 🥚 IEFBR14 segue vivo (e seguirá)

  • 🥚 Comentários em JCL mais antigos que o termo “cloud” 😅

  • 🥚 O erro campeão continua sendo:

    • RC ignorado

    • DISP mal planejado

    • dataset em uso em produção

👉 Mudam as gerações. O erro humano permanece.


💡 Dicas Bellacosa para JCL no z/OS 3.1

🔹 Trate JCL como ativo estratégico
🔹 Pense no job como serviço corporativo
🔹 Versione JCL como código
🔹 Use padrões claros de nomenclatura
🔹 Documente o porquê, não só o como

🔹 Sempre:

  • IF / THEN / ELSE

  • RC explícito

  • SYSOUT claro

  • comentários pensando em 10+ anos

Esse JCL vai sobreviver a você.
Escreva com respeito.


📈 Evolução do JCL até o z/OS 3.1

EraPapel do JCL
OS/360Controle batch
MVSAutomação
OS/390Base corporativa
z/OS V1.xOrquestração total
z/OS V2.xMundo híbrido
z/OS 3.1Fundação do core digital

👉 No z/OS 3.1, o JCL deixa de ser “legacy” oficialmente.
Ele vira infraestrutura histórica viva.


📜 Exemplo de JCL “cara de z/OS 3.1”

//BELL31 JOB (ACCT),'JCL z/OS 3.1', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //* JOB EXPOTO COMO SERVIÇO CORPORATIVO //* DISPARADO POR API, EVENTO OU SCHEDULER //* //STEP01 EXEC PGM=COREBATCH //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.WORK.DATA SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse job pode ser chamado por um operador,
por um pipeline ou por uma API.
Ele não precisa saber. Ele só precisa entregar.”


🧠 Comentário final

O JCL no z/OS 3.1 é a prova definitiva de uma verdade que só mainframer entende:

🔥 Confiabilidade não se reescreve.
Ela se herda.

Enquanto o mundo corre atrás da próxima abstração,
o JCL continua garantindo que:

  • o banco feche

  • o governo processe

  • a indústria funcione

JCL não é passado.
JCL é a espinha dorsal silenciosa do presente e do futuro.

segunda-feira, 30 de setembro de 2019

🔥 JCL no z/OS V2R4 — o clássico absoluto em plena era do híbrido e do automático

 

Bellacosa Mainframe apresenta JCL V2R4 Job Control Language

🔥 JCL no z/OS V2R4 — o clássico absoluto em plena era do híbrido e do automático



📅 Datas importantes

  • Release (GA): setembro de 2019

  • Final de suporte IBM: 30 de setembro de 2024

O z/OS V2R4 não trouxe um “novo JCL”.
Ele consolidou o JCL como a linguagem mais estável do data center híbrido moderno.


🧬 Contexto histórico

Quando o z/OS V2R4 chegou, o jogo já estava claro:

  • Cloud híbrida não era mais tendência — era realidade

  • APIs já chamavam batch

  • DevOps já convivia com JES

  • Linux on Z crescia sem pedir desculpa

E no meio disso tudo…

👉 o JCL seguia intacto, confiável, previsível.

Bellacosa resumiria assim:

“Todo mundo muda a fachada. O JCL segura a fundação.”


Job Control Language JCL V2R4


✨ O que há de novo no JCL do V2R4 (sem mudar a linguagem)

A IBM foi inteligente: não mexeu no que não precisa ser mexido.

🆕 1. JCL totalmente integrado à automação moderna

No V2R4, o normal passou a ser:

  • JCL disparado por:

    • APIs REST

    • schedulers inteligentes

    • eventos externos

  • JCL funcionando como backend confiável do mundo digital

👉 O job batch deixou de ser “coisa da madrugada”.


🆕 2. JES2 ainda mais estável e previsível

  • Melhor gerenciamento de spool

  • Ambientes com milhares de jobs simultâneos

  • Restart e recovery mais confiáveis

Menos “rezar pro job terminar”
Mais “sabemos exatamente o que vai acontecer”.


🆕 3. DFSMS maduro para volumes gigantes

  • Convivência natural com:

    • EAV

    • datasets enormes

    • políticas automáticas

  • Menos tuning manual de SPACE e UNIT

O JCL ficou mais simples, porque o sistema ficou mais inteligente.


🔧 Melhorias sentidas no dia a dia do mainframer

✔ Batch previsível em ambientes híbridos
✔ Menos ajustes manuais
✔ Mais padronização de jobs
✔ JCL tratado como ativo corporativo

Nada mudou na sintaxe.
Tudo mudou na confiança operacional.


🥚 Easter Eggs (para quem viveu o V2R4)

  • 🥚 Jobs escritos no MVS rodando felizes no V2R4

  • 🥚 IEFBR14 ainda presente em ambientes “cloud first” 😅

  • 🥚 Comentários no JCL mais antigos que ferramentas DevOps

  • 🥚 O erro nº 1 continuava sendo:

    • DISP errado

    • dataset em uso

    • RC ignorado


💡 Dicas Bellacosa para JCL no z/OS V2R4

🔹 Pense no JCL como infraestrutura crítica, não script
🔹 Documente o porquê do job
🔹 Use:

  • IF / THEN / ELSE

  • RC bem tratados

  • nomes de passos claros

🔹 Lembre-se:

Esse job pode rodar quando você não estiver mais na empresa.


📈 Evolução do JCL até o V2R4

EraPapel do JCL
OS/360Controle de jobs
MVSAutomação batch
OS/390Base corporativa
z/OS V1.xOrquestração total
z/OS V2R2/V2R3Mundo híbrido
z/OS V2R4Maturidade absoluta

👉 No V2R4, o JCL já não precisa provar nada.


📜 Exemplo de JCL “cara de V2R4”

//BELLV24 JOB (ACCT),'JCL z/OS V2R4', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* JOB ORQUESTRADO POR SCHEDULER / API //* //STEP01 EXEC PGM=MYBATCH //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.ARQ.TEMP SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Não importa quem disparou esse job —
operador, scheduler ou API.
O JCL entrega do mesmo jeito.”


🧠 Comentário final

O JCL no z/OS V2R4 é o ponto onde tudo fica claro:

  • Ele não é antigo

  • Ele não é obsoleto

  • Ele não é moda

Ele é confiável.

Enquanto o mundo corre atrás de estabilidade,
o JCL já está lá há décadas —
garantindo que o digital funcione quando ninguém está olhando.

🔥 JCL não é legado morto.
É legado que sustenta o presente.

sábado, 29 de setembro de 2018

🔥 JCL no z/OS V2R3 — o veterano que aprendeu a viver no mundo híbrido

 

Bellacosa Mainframe apresenta JCL Job Control Language V2R3

🔥 JCL no z/OS V2R3 — o veterano que aprendeu a viver no mundo híbrido

 


📅 Datas importantes

  • Release (GA): setembro de 2018

  • Final de suporte IBM: 30 de setembro de 2023

O z/OS V2R3 não tentou “modernizar” o JCL na marra. Ele fez algo melhor:
colocou o JCL no centro do mainframe conectado ao mundo cloud, API e DevOps.


🧬 Contexto histórico

Quando o z/OS V2R3 chegou, o cenário era curioso:

  • Mainframe totalmente vivo

  • Linux on Z crescendo

  • APIs expostas para o mundo

  • DevOps já batendo na porta do data center

  • Cloud híbrida deixando de ser discurso

E no meio disso tudo…
👉 o JCL continuava sendo o maestro silencioso do batch corporativo.

Bellacosa diria:

“Enquanto o pessoal discute pipeline em YAML, o JCL fecha a contabilidade do dia.”


JCL Job Control Language V2R3

✨ O que há de novo no JCL (indiretamente) no V2R3

O JCL não muda a sintaxe, mas o contexto muda bastante.

🆕 1. JCL como backend de automação moderna

No V2R3, é comum ver:

  • Jobs disparados por:

    • REST APIs

    • ferramentas DevOps

    • schedulers inteligentes

  • JCL sendo tratado como contrato operacional estável

👉 O JCL vira “infraestrutura como código”… antes disso virar moda.


🆕 2. Melhor convivência com z/OS Connect e middleware

  • Batch acionado por eventos externos

  • Processos online + batch integrados

  • JCL executando tarefas críticas iniciadas fora do mainframe

O batch deixou de ser “janela noturna isolada”.


🆕 3. JES2 e DFSMS ainda mais maduros

  • Spool mais estável

  • Melhor gerenciamento de grandes volumes de dados

  • Menos tuning manual

  • Mais previsibilidade operacional


🔧 Melhorias percebidas no dia a dia

✔ Jobs mais previsíveis em ambientes enormes
✔ Menos dependência de “magia do operador”
✔ Mais uso de IF/THEN/ELSE em vez de COND
✔ JCL tratado como ativo estratégico

Nada de comando novo — só robustez acumulada.


🥚 Easter Eggs (para quem viveu o V2R3)

  • 🥚 Jobs escritos no OS/390 rodando felizes no V2R3

  • 🥚 IEFBR14 ainda sendo usado em ambientes “cloud native” 😅

  • 🥚 Comentários no JCL mais antigos que muitos analistas

  • 🥚 O erro campeão seguia sendo:

    • dataset em uso

    • DISP mal pensado

    • SPACE subestimado


💡 Dicas Bellacosa para JCL no z/OS V2R3

🔹 Escreva JCL pensando em longevidade

Esse job vai sobreviver a você.

🔹 Prefira:

  • IF / THEN / ELSE / ENDIF

  • RC bem tratado

  • mensagens claras no SYSOUT

🔹 Documente o porquê, não só o como

🔹 Leia JESMSGLG como se fosse log de produção crítica — porque é.


📈 Evolução do JCL até o V2R3

FasePapel do JCL
OS/360Controle de jobs
MVSAutomação batch
OS/390Espinha dorsal corporativa
z/OS V1.xOrquestrador do data center
z/OS V2R3Fundação do mundo híbrido

👉 No V2R3, o JCL deixa claro:
não é legacy — é legado confiável.


📜 Exemplo de JCL “cara de V2R3”

//BELLV23 JOB (ACCT),'JCL z/OS V2R3', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //STEP01 EXEC PGM=MYBATCH //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.ARQ.TEMP SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse JCL pode ser disparado por um operador, um scheduler
ou uma API REST. Ele não se importa. Ele entrega.”


🧠 Comentário final

O JCL no z/OS V2R3 representa a maturidade absoluta:

  • Sem hype

  • Sem ruptura

  • Sem necessidade de provar nada

Enquanto tecnologias modernas tentam alcançar estabilidade,
o JCL já está lá há décadas.

🔥 JCL não concorre com o futuro.
Ele garante que o futuro funcione.