Da Compilação à Execução de um Programa COBOL

 

Bellacosa Mainframe e a compilaçao de um programa cobol

☕ Um Café no Bellacosa Mainframe

Da Compilação à Execução de um Programa COBOL

A jornada completa do código-fonte até a CPU do IBM Z

Para quem está começando no universo mainframe, compilar um programa COBOL pode parecer uma tarefa simples:

Escrever o código
Compilar
Executar

Mas, no IBM Z, existe uma verdadeira cadeia industrial entre a primeira linha do fonte e o momento em que uma CPU começa a executar as instruções do programa.

O código pode depender de copybooks, comandos CICS, instruções SQL, chamadas IMS, interfaces Adabas, arquivos QSAM, clusters VSAM, bibliotecas de carga, JCL, JES2, Language Environment, memória e vários componentes do z/OS.

Por isso, dizer que um programa foi apenas “compilado e executado” é como afirmar que um avião simplesmente saiu do papel e começou a voar.

Entre o projeto e o voo existem dezenas de etapas.

Esta série em quatro capítulos foi criada para mostrar essa jornada completa de maneira progressiva, sempre pensando no Programador COBOL Padawan que deseja compreender não apenas como escrever código, mas como o mainframe realmente pensa.

---

O grande mapa da jornada

Antes de conhecer cada capítulo, observe o fluxo completo:

Regra de negócio
       ↓
Código-fonte COBOL
       ↓
Copybooks
       ↓
Tradução CICS
       ↓
Processamento Db2
       ↓
Interfaces IMS e Adabas
       ↓
Compilação
       ↓
Código objeto
       ↓
Binder
       ↓
Load module
       ↓
Load library
       ↓
JCL ou transação
       ↓
JES2 ou subsistema online
       ↓
Loader
       ↓
Memória
       ↓
Dispatcher
       ↓
CPU
       ↓
Dados, relatórios e resultados

Cada etapa possui uma responsabilidade específica.

Quando uma delas falha, o problema pode aparecer como:

• erro de compilação;

• erro de linkedição;

• package Db2 inválido;

• programa não encontrado;

• arquivo ausente;

• FILE STATUS;

• SQLCODE;

• erro CICS;

• status IMS;

• response code Adabas;

• return code;

• abend.

A melhor forma de investigar qualquer problema é descobrir em qual parte dessa cadeia ele ocorreu.

---

Parte I — O nascimento do programa COBOL

Código-fonte, bibliotecas e copybooks

O primeiro capítulo apresenta o ponto de partida: o código-fonte COBOL.

É nele que o programador transforma uma regra de negócio em instruções como:

MOVE
COMPUTE
PERFORM
READ
WRITE
CALL

Porém, o programa raramente vive sozinho.

Muitas aplicações utilizam copybooks para compartilhar:

• layouts de arquivos;

• registros;

• áreas de comunicação;

• constantes;

• códigos de retorno;

• estruturas de mensagens;

• campos de tabelas;

• contratos entre programas.

Um programa pode conter:

       COPY CPYCLI01.

Durante o processo de compilação, o conteúdo desse copybook é incorporado logicamente ao fonte.

O capítulo também explica uma diferença fundamental:

COPY inclui fonte.
CALL executa outro programa.

Essa distinção é importante porque um copybook não é um módulo executável.

Ele é uma estrutura reutilizável inserida no programa durante sua preparação.

Outro ponto central é que o copybook funciona como um contrato.

Se dois programas compartilham uma área de memória, ambos precisam interpretar exatamente o mesmo layout.

Uma alteração feita sem análise de impacto pode provocar:

• campos deslocados;

• valores incorretos;

• erros numéricos;

• corrupção de dados;

• abends;

• falhas silenciosas.

A primeira parte também mostra como o compilador localiza copybooks por meio de bibliotecas associadas a DD statements como SYSLIB.

A ordem dessas bibliotecas pode determinar qual versão do copybook será utilizada.

Isso significa que até mesmo uma compilação com retorno zero pode gerar um programa incorreto caso tenha utilizado uma versão inadequada de determinada estrutura.

Leia a Parte I

https://eljefemidnightlunch.blogspot.com/2022/01/da-compilacao-execucao-de-um-programa.html

---

Parte II — CICS, Db2, IMS e Adabas

O que acontece antes da compilação

O segundo capítulo mostra que nem tudo o que aparece dentro de um programa COBOL pertence diretamente à linguagem.

Comandos como:

           EXEC CICS
                READ FILE('CLIENTES')
           END-EXEC.

ou:

           EXEC SQL
                SELECT NOME
                  INTO :WS-NOME
                  FROM CLIENTES
           END-EXEC.

precisam ser processados por componentes especializados.

CICS

Os comandos EXEC CICS são interpretados pelo tradutor CICS.

O fluxo conceitual é:

Fonte COBOL com EXEC CICS
             ↓
Tradutor CICS
             ↓
Fonte COBOL preparado
             ↓
Compilador

O programa pede ao CICS que execute serviços como:

• leitura de arquivos;

• envio e recebimento de mapas;

• acesso a filas;

• chamada de programas;

• controle de transações;

• sincronização;

• gerenciamento de recursos.

O COBOL contém a regra de negócio.

O CICS administra o ambiente transacional.

Db2

Comandos EXEC SQL precisam ser processados pelo pré-compilador Db2 ou por um coprocessador integrado.

Esse processamento pode gerar:

Fonte COBOL preparado
DBRM

O fonte segue para o compilador.

O DBRM segue para o BIND do Db2.

Esse BIND cria um package com as instruções SQL preparadas.

O capítulo esclarece uma confusão frequente:

Binder do z/OS cria o executável.
BIND do Db2 cria o package SQL.

São processos diferentes.

IMS

Programas COBOL podem acessar bancos hierárquicos e mensagens IMS por meio de chamadas DL/I.

Entre as funções comuns estão:

GU
GN
GNP
ISRT
REPL
DLET

O ambiente também utiliza estruturas como:

• DBD;

• PSB;

• PCB;

• SSA;

• layouts de segmentos.

Adabas

O acesso ao Adabas pode envolver:

• control blocks;

• format buffers;

• record buffers;

• search buffers;

• value buffers;

• interfaces de chamada;

• response codes.

Apesar de suas diferenças, CICS, Db2, IMS e Adabas compartilham o mesmo princípio:

O programa COBOL executa a regra de negócio e solicita serviços a subsistemas especializados.

Leia a Parte II

https://eljefemidnightlunch.blogspot.com/2022/02/da-compilacao-execucao-de-um-programa.html

---

Parte III — Compilação, linkedição e load library

Como o fonte se transforma em executável

O terceiro capítulo entra no coração técnico da transformação.

Depois que o fonte foi preparado, o compilador COBOL entra em cena.

Seu trabalho não se limita a trocar comandos por instruções de máquina.

Ele também analisa:

• sintaxe;

• campos;

• tipos de dados;

• tamanhos;

• parágrafos;

• referências;

• opções;

• arquivos;

• copybooks;

• expressões;

• compatibilidade;

• oportunidades de otimização.

O resultado principal é o código objeto.

Fonte COBOL
      ↓
Compilador
      ↓
Código objeto

Porém, o código objeto ainda pode possuir referências não resolvidas.

Um programa pode chamar:

           CALL 'PGMVALID'
                USING AREA-DADOS.

Se essa chamada precisar ser resolvida antecipadamente, será necessário localizar o módulo correspondente durante a linkedição.

O Binder

O Binder do z/OS reúne:

• código objeto;

• rotinas;

• interfaces;

• módulos externos;

• pontos de entrada;

• componentes de runtime.

O resultado é o módulo executável.

Código objeto
      +
Dependências
      ↓
Binder
      ↓
Load module ou program object

Esse executável é gravado em uma biblioteca como:

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

Chamadas estáticas e dinâmicas

O capítulo também explica a diferença entre chamadas estáticas e dinâmicas.

Estática

A dependência é resolvida durante a linkedição.

Dinâmica

O módulo é procurado durante a execução.

Essa escolha afeta:

• implantação;

• tamanho do executável;

• manutenção;

• versionamento;

• risco de programa não encontrado;

• necessidade de relinkedição.

Return codes

Compilador e Binder produzem mensagens e return codes.

Um RC=0 indica que a etapa terminou normalmente, mas não prova que a lógica está correta.

Um RC=4 pode conter warnings importantes.

Um erro de linkedição pode indicar:

• símbolo não resolvido;

• módulo ausente;

• biblioteca errada;

• ponto de entrada incorreto;

• interface incompatível.

O capítulo reforça uma lição essencial:

Programa compilado não significa programa testado.

Leia a Parte III

https://eljefemidnightlunch.blogspot.com/2022/03/da-compilacao-execucao-de-um-programa.html

---

Parte IV — Da load library à CPU

JCL, JES2, QSAM, VSAM, memória e processamento

O quarto capítulo acompanha o executável durante a execução real.

Depois da linkedição, o programa está pronto, mas ainda permanece parado em uma load library.

No ambiente batch, o JCL solicita sua execução:

//STEP01 EXEC PGM=PGMCLI01

Uma STEPLIB pode informar onde o módulo deve ser procurado:

//STEPLIB DD DISP=SHR,
//           DSN=EMPRESA.SISTEMA.LOADLIB

Se o módulo não for encontrado, pode ocorrer um erro como S806.

QSAM

Programas que acessam arquivos sequenciais podem utilizar QSAM.

No COBOL:

ASSIGN TO CLIENTES

No JCL:

//CLIENTES DD DISP=SHR,
//            DSN=EMPRESA.DADOS.CLIENTES

A ligação é:

Nome lógico COBOL
       ↓
DDNAME
       ↓
Dataset físico

VSAM

VSAM oferece organizações como:

• KSDS;

• ESDS;

• RRDS;

• LDS;

• VRRDS.

Um KSDS pode ser acessado por chave e também de forma sequencial.

O programa precisa verificar o FILE STATUS depois das operações.

Retornos como 00, 10, 22, 23, 35 e 39 possuem significados diferentes conforme a operação e o contexto.

JES2

O JES2 administra o fluxo batch.

Ele:

• recebe o job;

• mantém filas;

• utiliza o spool;

• organiza classes;

• administra saídas;

• acompanha o processamento.

O JES2 não executa diretamente as instruções COBOL.

O fluxo correto é mais próximo de:

JES2 administra o job
Initiator inicia o step
z/OS prepara o ambiente
Loader carrega o módulo
Dispatcher entrega processador
CPU executa as instruções

Memória e CPU

O programa é carregado em um address space.

O Language Environment prepara o runtime.

O dispatcher distribui capacidade de processamento.

O WLM ajuda a priorizar workloads conforme objetivos de serviço.

A CPU não executa comandos COBOL como:

MOVE
READ
PERFORM
COMPUTE

Ela executa as instruções de máquina produzidas pelo compilador.

O capítulo também explica a diferença entre:

Tempo de CPU
Tempo decorrido

Um job pode permanecer dez minutos em execução e consumir apenas alguns segundos de CPU.

O restante pode ser espera por:

• arquivos;

• Db2;

• IMS;

• Adabas;

• locks;

• filas;

• mensagens;

• armazenamento;

• rede.

Leia a Parte IV

https://eljefemidnightlunch.blogspot.com/2022/04/da-compilacao-execucao-de-um-programa.html

---

O que o Padawan aprende com a série

Ao concluir os quatro capítulos, o iniciante passa a compreender que um programa COBOL não é apenas um membro dentro de uma biblioteca.

Ele faz parte de uma cadeia maior.

Fonte
Copybook
Tradutor
Pré-compilador
Compilador
Objeto
Binder
Load
Package
JCL
JES2
Spool
Loader
Memória
CPU
Dados
Resultado

Essa visão permite investigar problemas com muito mais precisão.

Em vez de dizer:

“O programa não funciona”,

o profissional começa a perguntar:

• O fonte correto foi compilado?

• O copybook correto foi utilizado?

• O CICS traduziu os comandos?

• O DBRM foi gerado?

• O package Db2 foi criado?

• O Binder resolveu todas as referências?

• O load foi gravado na biblioteca correta?

• A STEPLIB aponta para essa biblioteca?

• O DDNAME corresponde ao ASSIGN TO?

• O dataset existe?

• O FILE STATUS foi tratado?

• O SQLCODE foi verificado?

• O programa terminou com return code ou abend?

• O tempo foi gasto em CPU ou em espera?

Essas perguntas transformam uma investigação baseada em tentativa e erro em um diagnóstico técnico estruturado.

---

A diferença entre escrever COBOL e entender o mainframe

Escrever COBOL é uma habilidade importante.

Mas compreender o ciclo completo de construção e execução é o que permite ao profissional atuar com segurança em ambientes corporativos.

O programador que conhece apenas o fonte pode corrigir uma linha.

O profissional que conhece o ecossistema consegue compreender:

• por que uma alteração não chegou ao ambiente;

• por que o programa antigo continua executando;

• por que um package está incompatível;

• por que o arquivo não abriu;

• por que o job está aguardando;

• por que o tempo decorrido aumentou;

• por que a CPU não é a causa da lentidão;

• por que uma recompilação em massa foi necessária;

• por que um copybook deve ser tratado como contrato.

Esse é o verdadeiro objetivo da série.

Não ensinar apenas comandos.

Ensinar a enxergar o sistema completo.

---

Leia a série completa

Parte I

O Nascimento do Programa COBOL: Código-fonte e Copybooks

Parte II

CICS, Db2, IMS e Adabas: O Código Antes da Compilação

Parte III

Compilação, Linkedição e Load Library

Parte IV

Da Load Library à CPU: JCL, JES2, QSAM, VSAM e Execução

---

Conclusão

A jornada de um programa COBOL começa muito antes da execução.

Ela nasce na regra de negócio.

Ganha forma no código-fonte.

Reutiliza estruturas por meio de copybooks.

Conversa com CICS, Db2, IMS e Adabas.

É analisada pelo compilador.

Transforma-se em código objeto.

É reunida pelo Binder.

Torna-se um módulo executável.

É armazenada em uma load library.

Depois, um JCL, uma transação ou um subsistema solicita sua execução.

O JES2 administra o job.

O initiator inicia os steps.

O loader coloca o programa em memória.

O z/OS gerencia recursos.

O WLM orienta prioridades.

O dispatcher entrega capacidade de processamento.

A CPU executa as instruções.

QSAM, VSAM, Db2, IMS, CICS e Adabas fornecem os dados e serviços necessários.

Por fim, o programa produz relatórios, atualizações, mensagens, arquivos e resultados de negócio.

Nada simplesmente “roda”.

Tudo é preparado, ligado, controlado, carregado, executado e registrado.

☕

“O Padawan observa o código-fonte. O especialista acompanha toda a jornada, desde o primeiro COPY até o último ciclo de CPU.”