Todo mainframe empresarial executa duas linguagens interligadas que a maioria dos desenvolvedores modernos nunca escreveu. O COBOL implementa a lógica de negócios, cálculos, processamento de arquivos, transformações de registros e relatórios regulatórios. O JCL (Job Control Language) orquestra a execução dessa lógica, definindo quais programas são executados, em que ordem, com quais arquivos, sob quais condições e o que acontece quando eles são bem-sucedidos ou falham. Nenhuma das linguagens é completa sem a outra. Um programa COBOL não tem ideia de onde vêm seus arquivos de entrada ou para onde vai sua saída; o JCL responde a ambas as perguntas antes mesmo do primeiro registro ser lido.
Para organizações que realizam manutenção, auditoria ou modernização de sistemas mainframe, compreender a relação entre JCL e COBOL não é um conhecimento opcional. É pré-requisito para tudo: análise de impacto antes de qualquer alteração, documentação antes de qualquer migração, transferência de conhecimento antes que qualquer especialista se aposente. O job que processa a fatura noturna, o batch run que gera relatórios regulatórios trimestrais, o procedimento que transfere dados de um sistema para outro, tudo isso é definido por JCL, executado por COBOL e compreendido apenas pelo número cada vez menor de engenheiros que trabalharam com ambas as linguagens.
O que é JCL?
JCL significa Job Control Language (Linguagem de Controle de Tarefas). É a linguagem de script usada em sistemas mainframe da IBM para submeter tarefas em lote para execução. O JCL não processa dados diretamente. Ele informa ao sistema operacional como executar programas: qual programa executar, quais arquivos disponibilizar, quais recursos de memória e CPU alocar, o que fazer se uma etapa falhar e em qual sequência executar várias etapas dentro de uma única tarefa.
Cada tarefa JCL consiste em três tipos fundamentais de instruções:
A declaração JOB identifica a tarefa no sistema e define os parâmetros de contabilização, prioridade e agendamento.
A instrução EXEC especifica o programa ou procedimento a ser executado em uma etapa.
A declaração DD (Data Definition) define os conjuntos de dados que o programa irá ler ou gravar, incluindo sua localização, formato e disposição.
jcl
//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
// CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010 EXEC PGM=PAYROLL1
//STEPLIB DD DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE DD DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT DD SYSOUT=A
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMYNeste exemplo: PAYBATCH é o nome do cargo, STEP010 é uma etapa do trabalho, PGM=PAYROLL1 O programa COBOL é nomeado e as instruções DD definem todos os arquivos que o programa pode acessar. PAYROLL1 não sabe nem se importa onde EMPFILE or TRANSACT Os dados vêm de uma localização física; o sistema simplesmente os lê pelo nome do registro (ddname). O JCL resolve a localização física, o formato do registro e o modo de acesso antes do início da execução.
Procedimentos catalogados JCL (PROCs)
Em vez de escrever o mesmo padrão JCL para cada tarefa, as equipes de mainframe definem procedimentos catalogados (PROCs) que encapsulam padrões de execução reutilizáveis. Um PROC é um modelo armazenado em uma biblioteca de procedimentos; tarefas individuais o referenciam e substituem parâmetros específicos conforme necessário.
jcl
//PAYPROC PROC RUNDATE=TODAY
//COMPILE EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN DD DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ DD DSN=&&OBJSET,DISP=(NEW,PASS),
// UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD DD DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
// DISP=SHR
// PENDChamando o PROC a partir de um trabalho:
jcl
//COMPILE EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205Esta única instrução EXEC se expande para o PROC completo no momento da execução, com MEMBER e RUNDATE substituído onde quer que seja &MEMBER e &RUNDATE Os PROCs são um dos principais motivos pelos quais o mapeamento de JCL para COBOL é complexo: um job pode invocar dezenas de programas COBOL por meio de uma única referência de PROC, e os programas realmente invocados dependem de parâmetros simbólicos que variam a cada execução.
Qual a diferença entre JCL e COBOL?
JCL e COBOL são frequentemente mencionados juntos, mas desempenham funções completamente diferentes. Nenhum substitui o outro, e ambos são necessários para o funcionamento do processamento em lote em mainframe.
| Dimensão | Jcl | COBOL |
|---|---|---|
| Propósito | Orquestra a execução | Implementa a lógica de negócios. |
| O que isso define | Empregos, etapas, arquivos, condições | Programas, estruturas de dados, cálculos |
| Quando ele funciona | Antes da execução do programa (configuração) e depois (limpeza) | Durante a execução do programa |
| Lê/escreve dados | Por meio de alocação de conjunto de dados (instruções DD) | Por meio de instruções FILE SECTION e READ/WRITE |
| Tratamento de erros | Códigos de retorno, execução condicional de etapas | manipuladores de exceção, rotinas de erro PERFORM |
| Portabilidade | Específico para IBM z/OS | Portátil entre plataformas com compiladores |
| Quem escreve isso | Programadores de sistemas, engenheiros de lotes | Desenvolvedores de aplicativos |
| Equivalente moderno | Pipeline CI/CD + orquestração de contêineres | Código da aplicação (Java, Python, C++) |
A maneira mais fácil de entender a relação é a seguinte: JCL é a camada de implantação e orquestração; COBOL é a camada de aplicação. Em um sistema moderno nativo da nuvem, o papel do JCL seria desempenhado por manifestos de tarefas do Kubernetes, scripts de shell e estágios de pipeline de CI/CD. O papel do COBOL seria desempenhado por serviços de aplicação escritos em Java, Python ou Go.
Como o JCL invoca o COBOL: A cadeia de execução
O caminho de uma tarefa JCL para a execução em COBOL segue uma cadeia consistente. Compreender cada etapa é fundamental para entender o que um mapeamento JCL-para-COBOL deve abranger.
Etapa 1: Submissão da tarefa. A tarefa JCL é submetida ao Subsistema de Entrada de Tarefas (JES). O JES enfileira a tarefa e começa a ler suas instruções.
Etapa 2: Configuração da etapa. Para cada etapa EXEC, o sistema localiza o programa nomeado na biblioteca de carregamento especificada pela instrução DD STEPLIB. Se nenhum STEPLIB for especificado, o sistema pesquisa na biblioteca de vínculo do sistema.
Etapa 3: Alocação de conjuntos de dados. Antes da execução do programa, o sistema aloca todos os conjuntos de dados definidos pelas instruções DD na etapa. Isso inclui abrir arquivos, verificar se os conjuntos de dados de entrada existem e criar conjuntos de dados de saída.
Etapa 4: Execução do programa. O programa COBOL é executado. Ele acessa arquivos usando os ddnames definidos no JCL. OPEN INPUT EMPFILE Em COBOL, mapeia diretamente para a instrução DD chamada EMPFILE em JCL.
Etapa 5: Avaliação do código de retorno. Quando o programa COBOL termina, ele define um código de retorno (normalmente 0 para sucesso, 4 para aviso, 8 para erro, 12 ou 16 para erro grave). O JCL utiliza COND parâmetros ou IF/THEN/ELSE estruturas para determinar se as etapas subsequentes devem ser executadas com base nesse código.
Etapa 6: Disposição do conjunto de dados. Após esta etapa, o sistema processa as disposições do conjunto de dados definidas em cada instrução DD: manter, excluir, catalogar, descatalogar ou passar para a próxima etapa.
O exemplo a seguir mostra como essa cadeia se apresenta na prática, com o JCL à esquerda e os elementos COBOL correspondentes à direita:
jcl
//STEP020 EXEC PGM=ACCTREC
//STEPLIB DD DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE DD DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR ← maps to COBOL SELECT/ASSIGN
//OUTFILE DD DSN=PROD.ACCT.PROCESSED, ← maps to COBOL SELECT/ASSIGN
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE DD SYSOUT=A ← maps to COBOL WRITE report
//SYSOUT DD SYSOUT=*O programa COBOL ACCTREC contém:
cobol
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INFILE ASSIGN TO INFILE. *> maps to DD INFILE
SELECT OUTFILE ASSIGN TO OUTFILE. *> maps to DD OUTFILE
SELECT RPTFILE ASSIGN TO RPTFILE. *> maps to DD RPTFILE
DATA DIVISION.
FILE SECTION.
FD INFILE
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
RECORD CONTAINS 200 CHARACTERS.
01 ACCOUNT-RECORD.
05 ACCT-NUMBER PIC X(10).
05 ACCT-BALANCE PIC S9(13)V99 COMP-3.
05 ACCT-STATUS PIC X(2).O SELECT INFILE ASSIGN TO INFILE Na seção FILE-CONTROL do COBOL, conecta-se à instrução DD chamada INFILE Em JCL. Esta é a relação de mapeamento fundamental: COBOL usa nomes de arquivos lógicos; JCL os resolve para conjuntos de dados físicos.
Códigos de abend JCL: o que eles significam
Os códigos de término anormal (abend codes) do JCL identificam o motivo pelo qual uma etapa do job foi encerrada inesperadamente. Eles aparecem na saída do job como S000 (falha do sistema) ou U0000 (códigos de abend do usuário). Compreendê-los é essencial para diagnosticar falhas em trabalhos em lote.
| Código de interrupção | Formato | Causa comum |
|---|---|---|
| S001 | System | Erro de E/S ao ler ou gravar um conjunto de dados |
| S013 | System | Incompatibilidade de atributos DCB, incompatibilidade de comprimento de registro ou formato entre JCL DD e COBOL FD |
| S0C4 | System | Exceção de proteção de armazenamento: o programa tentou acessar memória fora da região alocada. |
| S0C7 | System | Exceção de dados, tentativa de aritmética em dados não numéricos (abend muito comum em COBOL) |
| S322 | System | O limite de tempo foi excedido; a tarefa foi executada por mais tempo do que o permitido pelo parâmetro TIME. |
| S806 | System | Módulo de carregamento não encontrado; o programa nomeado em EXEC PGM= não está em nenhuma biblioteca de carregamento pesquisada. |
| S913 | System | Violação de segurança de acesso ao conjunto de dados, acesso negado pelo RACF ou equivalente. |
| U0000 | Utilizador | Abend definido pela aplicação, programa COBOL chamado STOP RUN com um código de usuário. |
| U4076 | Utilizador | abend específico do IMS, falha de acesso ao banco de dados |
A falha de produção mais comum, S0C7Ocorre quando um programa COBOL tenta realizar operações aritméticas em um campo que contém espaços ou caracteres não numéricos. A causa típica é uma incompatibilidade entre o formato de dados esperado no programa COBOL e os dados reais fornecidos pelo JCL, que é exatamente o tipo de discrepância que o mapeamento de JCL para COBOL revela antes que cause uma falha crítica na produção.
O parâmetro COND e a execução condicional
O JCL controla quais etapas são executadas com base nos códigos de retorno das etapas anteriores, usando o COND parâmetro:
jcl
//STEP010 EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020 EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030 EXEC PGM=CLEANUP, COND=(0,NE,STEP010)COND=(4,LT) Significa: ignore esta etapa se o código de retorno de qualquer etapa anterior for menor que 4. COND=(4,LT,STEP010) Significa: ignore esta etapa se o código de retorno de STEP010 for menor que 4. COND=(0,NE,STEP010) Significa: ignore o STEP030 se o código de retorno do STEP010 for diferente de 0, ou seja, execute a limpeza somente se o STEP010 for bem-sucedido.
O JCL moderno usa o IF/THEN/ELSE/ENDIF Em vez disso, construa, o que é mais legível:
jcl
//IF010 IF (STEP010.RC = 0) THEN
//STEP020 EXEC PGM=PROCESS
// ENDIF
//IF020 IF (STEP010.RC > 4) THEN
//STEP030 EXEC PGM=ERRORHANDLER
// ENDIFMapear caminhos de execução condicional é um dos elementos mais críticos e mais frequentemente negligenciados na análise de JCL para COBOL. Um programa COBOL que só é executado quando uma etapa anterior falha pode estar lidando com condições de erro, lógica de rollback ou procedimentos de recuperação, funcionalidades que são totalmente invisíveis se você observar apenas o código-fonte COBOL sem o JCL que o controla.
JCL, COBOL e DB2: A estrutura de três camadas
A maioria dos sistemas de transação de mainframe envolve um terceiro componente além do JCL e do COBOL: o DB2, o banco de dados relacional da IBM. Os programas COBOL acessam o DB2 por meio de instruções SQL incorporadas (blocos EXEC SQL). O JCL gerencia a conexão do subsistema DB2 e o DBRM (Módulo de Requisição de Banco de Dados) por meio de instruções DD específicas.
jcl
//DBRM DD DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD SYSOUT=*cobol
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
MAIN-LOGIC.
EXEC SQL
SELECT ACCT_BALANCE, ACCT_STATUS
INTO :WS-BALANCE, :WS-STATUS
FROM ACCOUNT_MASTER
WHERE ACCT_NUMBER = :WS-ACCT-NUM
END-EXEC.
IF SQLCODE NOT = 0
PERFORM DB2-ERROR-ROUTINE
END-IF.Na pilha JCL-COBOL-DB2, o JCL fornece o ambiente de execução e o acesso ao conjunto de dados; o COBOL implementa a lógica de negócios e acessa o banco de dados; o DB2 armazena e recupera dados de acordo com o SQL incorporado no programa COBOL. Um mapa de dependências completo de qualquer programa COBOL que utilize o DB2 deve incluir não apenas quais jobs JCL o invocam, mas também quais tabelas do DB2 ele lê e grava, quais colunas ele acessa e quais outros programas acessam as mesmas tabelas, pois uma alteração no esquema de uma tabela afeta todos os programas COBOL que a referenciam.
Por que o mapeamento de JCL para COBOL é importante para a modernização
Mapear JCL para COBOL não é primordialmente um exercício técnico. É um exercício de gestão de riscos. Cada alteração em um sistema mainframe, seja modificando um parâmetro JCL, adicionando uma etapa, alterando o nome de um conjunto de dados ou modificando o programa COBOL invocado por um job, acarreta consequências que vão além do componente alterado. A única maneira de dimensionar essas consequências com precisão antes de efetuar uma alteração é ter um mapeamento completo do que existe e de como tudo se conecta.
Antes da migração : Mover cargas de trabalho em lote do mainframe para a nuvem exige saber quais jobs JCL existem, quais programas COBOL eles invocam, quais conjuntos de dados fluem entre as etapas, qual é a sequência de execução e o que acontece quando as etapas falham. Sem esse mapeamento, a equipe de migração trabalha com documentação incompleta ou sem documentação alguma. Etapas são esquecidas. Dependências são descobertas em produção. Os prazos de transição são adiados.
Antes de qualquer alteração no código : Um programa COBOL modificado sem verificar quais jobs JCL o invocam pode interromper jobs executados sob diferentes condições ou com diferentes configurações de conjunto de dados. Uma alteração em um parâmetro JCL que pareça local pode afetar o comportamento de um programa COBOL que depende de atributos específicos do conjunto de dados. A análise de impacto exige o conhecimento de toda a cadeia JCL-COBOL-conjunto de dados antes de qualquer alteração ser feita.
Para transferência de conhecimento : Quando um desenvolvedor COBOL que manteve um sistema de processamento em lote por vinte anos se aposenta, ele leva consigo o modelo mental de como os jobs JCL e os programas COBOL se conectam. Um mapa documentado é o único mecanismo para transferir esse conhecimento para a próxima equipe. Sem ele, os novos desenvolvedores herdam um sistema que não podem modificar com segurança.
Para auditorias de conformidade : Auditorias regulatórias frequentemente exigem a demonstração de que cálculos financeiros, transformações de dados ou controles de acesso se comportam conforme documentado. Se a relação entre JCL e COBOL não estiver documentada, demonstrar isso é impossível sem realizar engenharia reversa do sistema sob pressão da auditoria.
Ferramentas de Gestão e Plataformas de Análise JCL
A natureza multilíngue dos dados do Search Console para este artigo, com consultas em italiano, francês, espanhol, japonês e alemão, todas sobre ferramentas de gerenciamento de JCL, reflete a distribuição global da comunidade de TI de mainframe e a consistência com que equipes em todas as regiões enfrentam o mesmo problema: sua documentação de JCL e COBOL está incompleta, desatualizada ou inexistente.
As ferramentas disponíveis para análise e gerenciamento de JCL se dividem em três categorias:
Ferramentas nativas da IBM : A IBM oferece recursos do Job Entry Subsystem (JES), gerenciamento de spool do JES e o IBM z/OS Batch Runtime. Essas ferramentas lidam com a execução e o monitoramento, mas não fornecem análise ou visualização de dependências entre programas.
Agendadores de tarefas de terceiros : CA7, TWS (Tivoli Workload Scheduler) e ESP Workload Automation da Broadcom gerenciam o agendamento em lote de milhares de tarefas, fornecem agendamento baseado em dependências e alertam sobre falhas. Eles entendem as dependências em nível de tarefa, mas normalmente não analisam os programas COBOL invocados em cada etapa.
Plataformas de análise estática de código e mapeamento de dependências : Ferramentas que analisam o código-fonte JCL e COBOL para construir um modelo estrutural de quais tarefas invocam quais programas, quais programas acessam quais conjuntos de dados e como os dados fluem pelo sistema. Elas fornecem a visibilidade entre camadas que os agendadores de tarefas e as ferramentas nativas da IBM não conseguem: a relação entre uma instrução DD JCL específica e a entrada FILE-CONTROL COBOL correspondente, ou entre um programa COBOL que grava em um conjunto de dados e a próxima tarefa que lê esse conjunto de dados como entrada.
SMART TS XL Pertence a esta terceira categoria e a amplia para abranger todas as linguagens no ambiente empresarial, COBOL, JCL, PL/I, Assembler, SQL, Java e outras, fornecendo a análise estrutural entre linguagens que nenhuma ferramenta de linguagem única consegue oferecer.
Como SMART TS XL Mapeia JCL para COBOL em escala empresarial
O mapeamento manual de JCL para COBOL é viável para um único job com três etapas. No entanto, não é viável para uma organização com 50,000 jobs JCL, 200,000 programas COBOL e milhões de referências a conjuntos de dados acumuladas ao longo de quatro décadas. A relação entre um PROC específico, os parâmetros simbólicos usados para invocá-lo, os programas COBOL aos quais esses parâmetros são atribuídos e os conjuntos de dados acessados por esses programas não pode ser rastreada manualmente nessa escala.
SMART TS XL Analisa o código-fonte JCL e COBOL, incluindo PROCs com substituição simbólica de parâmetros, procedimentos in-stream, membros INCLUDE, sobrescritas e lógica de execução condicional, e constrói um modelo de referência cruzada unificado que representa cada relacionamento estrutural no sistema. Esse modelo é consultável, navegável e está sempre atualizado, pois é regenerado a partir da fonte, em vez de ser mantido como um documento atualizado manualmente.
O Expansão JCL A capacidade de resolver a substituição simbólica de parâmetros mostra os programas e conjuntos de dados reais invocados por qualquer PROC, levando em consideração as substituições aplicadas por cada tarefa de chamada. Um PROC que usa &PGMNAME Um parâmetro simbólico aparece no modelo como todos os programas concretos aos quais ele se resolve em todos os seus chamadores, e não como uma referência não resolvida.
A funcionalidade de mapeamento de dependências de aplicativos constrói o grafo completo, desde o job JCL até o programa COBOL, passando pela tabela DB2 e chegando ao programa subsequente, mostrando cada componente do sistema e todas as conexões entre eles. Antes de qualquer alteração de modernização, a equipe pode consultar: quais jobs invocam este programa? Quais conjuntos de dados este programa lê? Quais outros programas gravam nesses conjuntos de dados? Quais jobs são executados em seguida na sequência?
A funcionalidade de análise de impacto gera um escopo enumerado de consequências para qualquer alteração proposta: modifique este copybook e veja todos os programas que o incluem; altere o layout deste conjunto de dados e veja todas as instruções JCL DD que o referenciam; remova esta etapa de um job e veja todas as etapas subsequentes que dependiam de sua saída.
Para equipes que enfrentam o mapeamento de JCL para COBOL como parte de um modernização legada programa SMART TS XL Fornece a base que os fornecedores de modernização, como Astadia, TSRI, Advanced e outros, precisam antes de iniciar qualquer trabalho de conversão: um inventário estrutural completo e preciso do que existe, para que o escopo da conversão seja definido por análise e não por suposição.
O mapa não é o território, mas é o ponto de partida.
JCL e COBOL não vão desaparecer. Os sistemas em lote que processam a folha de pagamento, gerenciam sinistros de seguros, geram relatórios regulatórios e liquidam transações financeiras continuarão rodando em mainframes enquanto as migrações para a nuvem são planejadas, aprovadas, financiadas e executadas, um processo que normalmente leva anos, e não meses. Durante esses anos, os sistemas precisam ser mantidos, modificados e compreendidos.
O mapeamento de JCL para COBOL não é um projeto pontual. É uma prática contínua: manter o modelo estrutural atualizado à medida que os programas são modificados, os jobs são adicionados e os conjuntos de dados são reorganizados. As equipes que investem nessa prática mantêm a capacidade de fazer alterações com segurança em sistemas que a maioria da indústria trata como caixas-pretas. As equipes que não o fazem estão realizando alterações em sistemas que não conseguem visualizar completamente, em ambientes onde uma dependência não atendida não gera um erro de compilação, mas sim uma falha em produção às 3 da manhã durante a execução noturna do processamento em lote.
