 |
| Bellacosa Mainframe e a compilação COBOL |
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL
PARTE I — O Nascimento do Programa COBOL
Do código-fonte aos copybooks: entendendo o que realmente acontece antes da compilação
Introdução
Todo programa COBOL começa como uma ideia de negócio.
Pode ser o cálculo dos juros de um financiamento, a atualização do saldo de uma conta, o processamento de uma folha de pagamento ou a leitura de milhões de registros durante a madrugada.
O programador transforma essa regra em código-fonte:
IDENTIFICATION DIVISION.
PROGRAM-ID. PGMCLI01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NOME PIC X(40).
01 WS-IDADE PIC 9(03).
PROCEDURE DIVISION.
DISPLAY 'INICIO DO PROGRAMA'
MOVE 'PADAWAN COBOL' TO WS-NOME
MOVE 25 TO WS-IDADE
DISPLAY WS-NOME
DISPLAY WS-IDADE
STOP RUN.
Para o iniciante, o programa parece pronto.
Mas a CPU do IBM Z não entende diretamente comandos como MOVE, DISPLAY, READ, PERFORM ou COMPUTE.
O código ainda precisará atravessar uma verdadeira linha de montagem industrial antes de se transformar em algo executável.
Nesta primeira parte, conheceremos o código-fonte, os copybooks e os elementos que formam a matéria-prima de uma aplicação COBOL.
1. O código-fonte COBOL
O código-fonte normalmente fica armazenado em uma biblioteca particionada, como um PDS ou PDSE.
Exemplo:
EMPRESA.SISTEMA.COBOL
Dentro dessa biblioteca existem membros:
PGMCLI01
PGMCLI02
PGMREL01
PGMCALC
Cada membro pode representar um programa.
Assim:
EMPRESA.SISTEMA.COBOL(PGMCLI01)
significa que PGMCLI01 é um membro da biblioteca de fontes.
O código-fonte é legível para seres humanos, mas ainda não está em linguagem de máquina.
Podemos comparar o fonte com uma receita.
A receita explica:
quais ingredientes serão usados;
quais operações deverão ser realizadas;
em que ordem;
quais decisões precisam ser tomadas;
qual resultado deverá ser produzido.
Porém, possuir uma receita não significa que o prato já esteja pronto.
2. O que é um copybook?
O copybook é um fragmento reutilizável de código COBOL.
Ele pode conter:
layouts de registros;
áreas de comunicação;
estruturas de arquivos;
campos utilizados por vários programas;
códigos de retorno;
estruturas de mensagens;
dados recebidos de outros sistemas;
definições de tabelas;
áreas utilizadas por CICS, Db2, IMS ou Adabas.
Imagine que vários programas utilizem o mesmo registro de cliente:
01 REGISTRO-CLIENTE.
05 CLI-CODIGO PIC 9(09).
05 CLI-NOME PIC X(40).
05 CLI-DOCUMENTO PIC X(14).
05 CLI-SALDO PIC S9(11)V99 COMP-3.
Em vez de repetir essa estrutura em cinquenta programas, ela pode ser gravada em:
EMPRESA.SISTEMA.COPYLIB(CPYCLI01)
No programa COBOL, basta escrever:
COPY CPYCLI01.
Durante o processamento do fonte, o conteúdo do copybook é incluído logicamente naquele ponto.
O compilador passa a enxergar:
01 REGISTRO-CLIENTE.
05 CLI-CODIGO PIC 9(09).
05 CLI-NOME PIC X(40).
05 CLI-DOCUMENTO PIC X(14).
05 CLI-SALDO PIC S9(11)V99 COMP-3.
O copybook não é normalmente um programa separado.
Ele também não se transforma sozinho em um módulo executável.
Sua função principal é fornecer código reutilizável.
3. COPY não é CALL
Essa diferença é fundamental.
Quando escrevemos:
COPY CPYCLI01.
estamos incluindo um trecho de código durante a preparação ou compilação.
Quando escrevemos:
CALL 'PGMCALC' USING WS-DADOS.
estamos solicitando a execução de outro módulo.
Podemos resumir assim:
COPY → inclusão de fonte
CALL → chamada de programa
O copybook passa a fazer parte do programa compilado.
O programa chamado continua sendo uma unidade executável separada, especialmente quando a chamada é dinâmica.
4. COPY REPLACING
O COBOL permite substituir textos durante a inclusão de um copybook.
Exemplo:
COPY CPYCLI01
REPLACING ==CLI-== BY ==TITULAR-==.
Se o copybook possuir:
05 CLI-NOME PIC X(40).
o programa poderá receber:
05 TITULAR-NOME PIC X(40).
Isso permite reutilizar uma mesma estrutura com prefixos diferentes.
Porém, o uso excessivo de REPLACING pode tornar o programa mais difícil de ler.
No mainframe corporativo, legibilidade é uma forma de segurança.
Um código pode funcionar durante vinte anos. Durante esse período, dezenas de profissionais poderão precisar mantê-lo.
5. O copybook como contrato
Imagine que dois programas compartilhem uma área de comunicação:
01 AREA-CLIENTE.
05 CLI-CODIGO PIC 9(09).
05 CLI-SALDO PIC S9(11)V99 COMP-3.
O programa principal envia essa área:
CALL 'PGMCALC'
USING AREA-CLIENTE.
O programa chamado precisa interpretar exatamente o mesmo layout.
Se alguém alterar o campo:
05 CLI-SALDO PIC S9(13)V99 COMP-3.
mas recompilar apenas um dos programas, os dois módulos poderão enxergar a memória de maneiras diferentes.
O resultado pode ser:
dados deslocados;
valores incorretos;
erro numérico;
corrupção de informações;
abends;
falhas silenciosas.
Por isso, um copybook não é somente um conjunto de campos.
Ele é um contrato entre programas.
Alterá-lo exige análise de impacto.
6. Onde o compilador procura os copybooks?
No JCL de compilação, as bibliotecas de copybooks costumam ser indicadas por meio de DD statements como SYSLIB.
Exemplo conceitual:
//SYSLIB DD DISP=SHR,DSN=EMPRESA.SISTEMA.COPYLIB
Pode haver mais de uma biblioteca:
//SYSLIB DD DISP=SHR,DSN=EMPRESA.SISTEMA.COPYLIB
// DD DISP=SHR,DSN=EMPRESA.CORPORATIVO.COPYLIB
// DD DISP=SHR,DSN=PRODUTO.FORNECEDOR.COPYLIB
A ordem dessas bibliotecas pode ser importante.
Se dois copybooks tiverem o mesmo nome, o primeiro localizado poderá ser utilizado.
É por isso que a configuração da compilação precisa ser controlada.
7. Um programa pode depender de muitos componentes
Mesmo antes de ser compilado, um fonte COBOL pode depender de:
Código-fonte
Copybooks
Layouts de arquivos
Áreas de comunicação
Definições de mensagens
SQL embutido
Comandos CICS
Interfaces IMS
Interfaces Adabas
Opções do compilador
Isso explica por que não basta copiar apenas o fonte de um ambiente para outro.
O programa também depende do ecossistema ao redor dele.
8. O primeiro mapa mental
Nesta etapa, temos:
Regra de negócio
↓
Código-fonte COBOL
↓
Copybooks e estruturas reutilizadas
↓
Fonte completo para processamento
Ainda não existe um executável.
Existe apenas uma descrição estruturada do que o sistema deverá fazer.
 |
| Bellacosa Maifnrame e o fluxo da compilacao cobol |
Conclusão da Parte I
O programa COBOL nasce como fonte, geralmente dentro de uma biblioteca PDS ou PDSE.
Os copybooks fornecem estruturas reutilizáveis e funcionam como contratos entre programas, arquivos e subsistemas.
Porém, a CPU ainda não consegue executar esse material.
Antes da compilação, alguns programas precisam passar por tradutores e pré-compiladores especializados.
Comandos como:
EXEC CICS
EXEC SQL
não pertencem diretamente à linguagem COBOL.
Eles precisam ser transformados antes que o compilador possa fazer seu trabalho.
No próximo capítulo
Na Parte II, entraremos no território dos comandos CICS, SQL Db2, chamadas IMS e interfaces Adabas.
Veremos por que um programa pode precisar ser traduzido ou pré-processado antes da compilação e entenderemos o papel de cada subsistema nessa grande linha de montagem.
PARTE II — CICS, Db2, IMS e Adabas
Os tradutores, pré-compiladores e interfaces que preparam o COBOL para os subsistemas corporativos
Introdução
Na primeira parte, vimos que o programa COBOL nasce como código-fonte e pode reutilizar estruturas armazenadas em copybooks.
Agora surge uma nova pergunta:
O compilador COBOL consegue entender tudo o que aparece dentro de um programa corporativo?
A resposta é não.
Comandos como:
EXEC CICS
SEND TEXT
END-EXEC.
ou:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
END-EXEC.
não são comandos COBOL tradicionais.
Eles pertencem a outros ambientes.
Por isso, o programa precisa ser preparado para que o compilador consiga processá-lo.
1. Programas COBOL com CICS
O CICS é um monitor de processamento de transações.
Ele controla:
transações;
terminais;
programas;
filas;
arquivos;
comunicação;
segurança;
recuperação;
sincronização;
recursos compartilhados.
Um programa pode solicitar serviços ao CICS:
EXEC CICS
READ
FILE('CLIENTES')
INTO(REGISTRO-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
END-EXEC.
O compilador COBOL não sabe, por conta própria, como executar um EXEC CICS READ.
Antes da compilação, esse comando precisa ser traduzido.
2. O tradutor CICS
O fluxo conceitual é:
Fonte COBOL com EXEC CICS
↓
Tradutor CICS
↓
Fonte COBOL traduzido
↓
Compilador COBOL
O tradutor transforma o comando CICS em estruturas e chamadas compatíveis com o compilador.
Historicamente, essa tradução era executada como uma etapa separada.
Em ambientes modernos, pode existir integração com o compilador por meio de opções específicas.
Mesmo quando a ferramenta esconde essa etapa, o conceito permanece.
O comando CICS precisa ser interpretado e convertido.
3. EXEC CICS é uma macro?
No cotidiano, muitos profissionais chamam comandos EXEC CICS de macros.
Essa expressão pode ser compreendida informalmente, mas tecnicamente é melhor dizer que são comandos CICS embutidos no programa COBOL.
Exemplo:
EXEC CICS
LINK PROGRAM('PGM002')
COMMAREA(AREA-COMUNICACAO)
LENGTH(WS-TAMANHO)
END-EXEC.
O programa não chama diretamente todas as rotinas internas necessárias.
Ele pede ao CICS que execute o serviço.
O CICS verifica o programa, controla a task, acompanha recursos e devolve o controle ao chamador.
4. Programas COBOL com Db2
Um programa pode possuir SQL embutido:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
O compilador COBOL também não entende diretamente o SQL.
Esse programa precisa passar por um pré-compilador Db2 ou por um coprocessador SQL integrado.
O fluxo clássico é:
Fonte COBOL com EXEC SQL
↓
Pré-compilador Db2
↓
Fonte COBOL modificado
+
DBRM
O fonte modificado seguirá para o compilador.
O DBRM seguirá para o processo de BIND do Db2.
5. O que é DBRM?
DBRM significa Database Request Module.
Ele contém informações sobre os comandos SQL encontrados no programa.
Exemplo de sequência:
EXEC SQL
↓
DBRM
↓
BIND PACKAGE
↓
Package Db2
Durante o BIND, o Db2 pode analisar:
tabelas;
índices;
estatísticas;
caminhos de acesso;
isolamento;
autorizações;
parâmetros de execução;
versões do package.
O programa COBOL Db2 possui, portanto, duas trilhas.
Trilha do programa
Fonte → compilação → linkedição → executável
Trilha do SQL
SQL → DBRM → BIND → package
O executável contém a lógica COBOL.
O package contém a preparação necessária para execução das instruções SQL.
6. O BIND do Db2 não é a linkedição
Essa confusão é comum.
O Binder do z/OS cria o módulo executável.
O BIND PACKAGE do Db2 prepara os comandos SQL.
São processos diferentes.
Binder z/OS → cria executável
BIND Db2 → cria package SQL
Um programa pode estar corretamente compilado e linkedidado, mas falhar porque seu package Db2 não existe ou está inválido.
7. SQLCA e host variables
Programas Db2 costumam utilizar a SQLCA:
EXEC SQL
INCLUDE SQLCA
END-EXEC.
Depois de executar um SQL, o programa pode verificar:
IF SQLCODE = 0
DISPLAY 'COMANDO EXECUTADO'
ELSE
DISPLAY 'ERRO SQL: ' SQLCODE
END-IF.
Campos COBOL usados pelo SQL são chamados de host variables:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Os dois-pontos identificam campos pertencentes ao programa COBOL.
8. CICS e Db2 no mesmo programa
É comum encontrar:
EXEC CICS
RECEIVE ...
END-EXEC
EXEC SQL
SELECT ...
END-EXEC.
Esse programa pode passar por:
Tradução CICS
↓
Processamento Db2
↓
Compilação COBOL
↓
Linkedição
↓
BIND do package
A ordem técnica pode variar conforme as ferramentas utilizadas.
O importante é compreender que existem diferentes processadores preparando o fonte.
9. COBOL com IMS
O IMS é uma plataforma composta por dois grandes universos:
IMS Database Manager;
IMS Transaction Manager.
Um programa pode acessar um banco hierárquico por meio de chamadas DL/I.
Exemplo conceitual:
CALL 'CBLTDLI'
USING GU-FUNCTION
PCB-MASK
SEGMENTO-CLIENTE
SSA-CLIENTE.
Algumas funções comuns são:
GU Get Unique
GN Get Next
GNP Get Next Within Parent
ISRT Insert
REPL Replace
DLET Delete
O programa não abre diretamente o banco IMS como um arquivo sequencial.
Ele envia uma solicitação ao IMS.
10. DBD, PSB e PCB
O ambiente IMS utiliza estruturas importantes.
DBD
Database Description.
Descreve a estrutura do banco.
PSB
Program Specification Block.
Descreve quais recursos um programa pode utilizar.
PCB
Program Communication Block.
Representa a visão de comunicação entre o programa e os bancos ou mensagens.
O módulo COBOL precisa executar em um ambiente no qual essas definições estejam disponíveis.
11. IMS Transaction Manager
No IMS TM, uma mensagem pode iniciar uma transação.
Fluxo simplificado:
Terminal, API ou sistema
↓
Fila de mensagens
↓
Transação IMS
↓
Programa COBOL
↓
Banco IMS, Db2 ou outros recursos
↓
Mensagem de resposta
O programa COBOL processa a regra de negócio.
O IMS controla a transação, a mensagem e o ambiente operacional.
12. COBOL com Adabas
O Adabas é um sistema de gerenciamento de banco de dados associado à Software AG.
Embora seja muito utilizado com Natural, programas COBOL também podem acessar dados Adabas.
O acesso pode envolver:
control blocks;
format buffers;
record buffers;
search buffers;
value buffers;
interfaces de chamada;
módulos de comunicação.
Fluxo conceitual:
Programa COBOL
↓
Interface Adabas
↓
Adabas Nucleus
↓
Arquivos Adabas
O Nucleus é o componente central que recebe e processa as solicitações.
Durante a linkedição, o programa pode precisar das interfaces fornecidas para comunicação com o ambiente Adabas.
13. O princípio comum dos subsistemas
CICS, Db2, IMS e Adabas possuem arquiteturas diferentes.
Entretanto, existe uma ideia comum:
O programa COBOL não executa tudo sozinho.
Ele solicita serviços a componentes especializados.
COBOL → regra de negócio
CICS → transações
Db2 → banco relacional
IMS → banco hierárquico e mensagens
Adabas → gerenciamento de dados
Essa separação torna os sistemas mais controlados e escaláveis.
Conclusão da Parte II
Antes de chegar ao compilador, um programa pode precisar ser traduzido ou pré-processado.
O CICS traduz seus comandos embutidos.
O Db2 processa o SQL e produz um DBRM.
O IMS fornece interfaces DL/I e estruturas de controle.
O Adabas oferece seus próprios blocos e módulos de comunicação.
Depois dessa preparação, o fonte finalmente estará pronto para ser transformado em código objeto.
No próximo capítulo
Na Parte III, veremos o coração técnico do processo:
compilação;
código objeto;
linkedição;
Binder;
chamadas estáticas e dinâmicas;
load modules;
load libraries.
É nesse momento que o código começa verdadeiramente a se transformar em um programa executável.
PARTE III — Compilação, Linkedição e Load Library
Como o fonte COBOL se transforma em um módulo executável no IBM Z
Introdução
Depois que copybooks foram incluídos e comandos CICS ou SQL foram devidamente preparados, o programa está pronto para entrar na linha de montagem principal.
Agora o compilador COBOL analisará o fonte e produzirá código objeto.
Em seguida, o Binder reunirá esse objeto com interfaces e módulos necessários, criando o executável.
Essa é a etapa em que o programa deixa de ser apenas texto e começa a se aproximar da linguagem compreendida pelo processador.
1. O que é compilação?
Compilar significa transformar o código-fonte COBOL em código objeto.
Fluxo básico:
Código-fonte COBOL
↓
Compilador
↓
Código objeto
O compilador analisa:
sintaxe;
campos;
tipos de dados;
tamanhos;
parágrafos;
referências;
operações aritméticas;
arquivos;
opções de otimização;
compatibilidade entre comandos.
Considere:
01 WS-VALOR-A PIC S9(09) COMP.
01 WS-VALOR-B PIC S9(09) COMP.
01 WS-TOTAL PIC S9(09) COMP.
COMPUTE WS-TOTAL =
WS-VALOR-A + WS-VALOR-B.
O compilador transforma essa lógica em instruções compatíveis com a arquitetura IBM Z.
2. O código objeto já é executável?
Nem sempre.
O objeto pode possuir referências externas ainda não resolvidas.
Exemplo:
CALL 'VALIDCPF'
USING WS-CPF
WS-RETORNO.
O compilador reconhece que existe uma chamada para VALIDCPF.
Porém, o módulo ainda pode precisar ser localizado ou incluído no processo de linkedição.
É nesse ponto que entra o Binder.
3. O que é linkedição?
Linkedição é o processo de combinar código objeto com outros componentes necessários para criar um módulo executável.
Código objeto
+
Rotinas externas
+
Interfaces
+
Módulos de runtime
↓
Módulo executável
Em ambientes atuais, a ferramenta utilizada é chamada de Binder.
Em documentações mais antigas, você poderá encontrar:
Linkage Editor;
Link-Editor;
linkage edition;
linkedição;
edição de ligação.
4. O Binder
O Binder pode receber:
objetos produzidos pelo compilador;
módulos estáticos;
interfaces CICS;
interfaces Db2;
interfaces IMS;
interfaces Adabas;
rotinas de linguagem;
pontos de entrada;
bibliotecas de módulos reutilizáveis.
O resultado será armazenado em uma biblioteca executável.
Exemplo:
EMPRESA.SISTEMA.LOADLIB(PGMCLI01)
O membro PGMCLI01 já não contém COBOL legível.
Ele contém um módulo preparado para ser carregado e executado.
5. Load module e program object
Durante muitos anos, o termo mais comum foi load module.
Com bibliotecas e formatos mais modernos, também existe o conceito de program object.
No cotidiano, muitos profissionais continuam utilizando expressões como:
load;
módulo de carga;
executável;
membro da loadlib.
O conceito fundamental é o mesmo:
Trata-se do artefato que o sistema poderá localizar, carregar na memória e executar.
6. Exemplo de JCL de compilação
Uma etapa conceitual de compilação poderia ser:
//COMPILE EXEC PGM=IGYCRCTL
//SYSIN DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.COBOL(PGMCLI01)
//SYSLIB DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.COPYLIB
//SYSLIN DD DISP=(NEW,PASS),
// DSN=&&OBJ,
// UNIT=SYSDA,
// SPACE=(TRK,(5,5))
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD UNIT=SYSDA,
// SPACE=(CYL,(1,1))
O compilador lê o fonte em SYSIN.
Os copybooks são encontrados por meio de SYSLIB.
O objeto é gravado temporariamente em SYSLIN.
A listagem do compilador segue para SYSPRINT.
7. Exemplo de linkedição
A etapa seguinte poderia ser:
//LKED EXEC PGM=IEWL,
// PARM='LIST,MAP,XREF'
//SYSLIN DD DISP=(OLD,DELETE),
// DSN=&&OBJ
//SYSLMOD DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.LOADLIB(PGMCLI01)
//SYSPRINT DD SYSOUT=*
O Binder recebe o objeto por SYSLIN.
O executável é gravado por SYSLMOD.
A saída de diagnóstico segue para SYSPRINT.
8. Procedures catalogadas
Em muitas empresas, o programador não escreve todas essas etapas.
Ele utiliza uma procedure:
//COMPILA EXEC PROC=COBOLCL
Ou:
//COMPILA EXEC PROC=COBDB2
Ou ainda:
//COMPILA EXEC PROC=COBCICS
A procedure pode esconder:
compilação;
tradução;
pré-compilação;
linkedição;
bind Db2;
bibliotecas;
parâmetros;
controles corporativos.
Não existe mágica.
Existe automação.
9. Bibliotecas utilizadas
Um projeto pode possuir:
EMPRESA.SISTEMA.COBOL
EMPRESA.SISTEMA.COPYLIB
EMPRESA.SISTEMA.DBRMLIB
EMPRESA.SISTEMA.OBJLIB
EMPRESA.SISTEMA.LOADLIB
EMPRESA.SISTEMA.JCL
COBOL
Fontes.
COPYLIB
Copybooks.
DBRMLIB
DBRMs dos programas Db2.
OBJLIB
Objetos compilados, quando armazenados.
LOADLIB
Executáveis.
JCL
Jobs de compilação e execução.
Os nomes variam entre empresas.
O importante é compreender a função de cada biblioteca.
10. Chamadas estáticas
Uma chamada estática é resolvida durante a linkedição.
O módulo chamado é incorporado ou ligado ao executável.
Vantagens:
resolução antecipada;
menor dependência de localização em runtime;
maior controle sobre a versão incorporada.
Desvantagens:
alteração do subprograma pode exigir relinkedição;
executável pode ficar maior;
atualização pode afetar vários módulos.
11. Chamadas dinâmicas
Em uma chamada dinâmica, o módulo é localizado durante a execução.
Exemplo:
CALL WS-NOME-PROGRAMA
USING AREA-DADOS.
Ou, conforme opções e codificação:
CALL 'PGMCALC'
USING AREA-DADOS.
Vantagens:
possibilidade de atualizar o subprograma separadamente;
maior reutilização;
executável chamador pode ser menor.
Desvantagens:
o módulo precisa estar disponível em runtime;
uma biblioteca incorreta pode causar programa não encontrado;
versões incompatíveis podem gerar erros.
12. Return codes da compilação
Códigos comuns podem incluir:
RC=0000
RC=0004
RC=0008
RC=0012
RC=0016
Uma interpretação geral:
RC 0
Compilação concluída sem erros relevantes.
RC 4
Advertências.
RC 8
Erros importantes.
RC 12 ou superior
Falhas graves.
Porém, nunca analise apenas o número.
Leia a listagem do compilador.
Uma advertência ignorada hoje pode se transformar em um problema de produção amanhã.
13. Erro de compilação e erro de linkedição
Erro de compilação
Pode envolver:
sintaxe inválida;
campo não definido;
parágrafo inexistente;
conflito de tipos;
copybook não encontrado;
instrução incorreta.
Erro de linkedição
Pode envolver:
símbolo externo não resolvido;
módulo ausente;
biblioteca não encontrada;
interface incompatível;
ponto de entrada inválido;
erro na criação do executável.
Identificar a fase correta evita investigações aleatórias.
14. O grande fluxo até a loadlib
Podemos resumir:
Fonte COBOL
↓
Copybooks
↓
Tradução CICS, quando necessária
↓
Pré-compilação Db2, quando necessária
↓
Compilador COBOL
↓
Código objeto
↓
Binder
↓
Load module ou program object
↓
LOADLIB
Nesse momento, finalmente existe um executável.
Porém, ele ainda não está rodando.
Para isso, precisará ser encontrado, carregado, associado aos arquivos e entregue ao sistema operacional.
Conclusão da Parte III
A compilação transforma o fonte em código objeto.
A linkedição reúne objetos, interfaces e dependências para criar o módulo executável.
Esse módulo é armazenado em uma load library.
Mas a jornada ainda não terminou.
Um executável parado dentro de uma biblioteca não realiza nenhum trabalho.
Ele precisa ser iniciado por um job batch, uma transação CICS, uma região IMS ou outro mecanismo de execução.
No próximo capítulo
Na Parte IV, acompanharemos o módulo executável durante a execução.
Veremos:
JCL;
QSAM;
VSAM;
JES2;
spool;
initiator;
loader;
memória;
WLM;
dispatcher;
CPU.
Finalmente descobriremos como o programa sai da load library e começa a processar dados reais.
PARTE IV — Da Load Library à CPU
JCL, QSAM, VSAM, JES2, spool, memória e execução no IBM Z
Introdução
O programa foi escrito.
Os copybooks foram encontrados.
Os comandos CICS e SQL foram preparados.
O fonte foi compilado.
O objeto foi linkedidado.
O executável foi gravado em uma load library.
Agora chegou o momento da verdade:
Como esse módulo começa a executar?
Nesta última parte, acompanharemos o programa desde a submissão do JCL até sua chegada à CPU.
Também veremos como arquivos QSAM e VSAM são associados ao programa e qual é o verdadeiro papel do JES2.
1. JCL de execução
Um programa batch pode ser chamado assim:
//EXECUTA JOB (1234),'BELLACOSA',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=PGMCLI01
//STEPLIB DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.LOADLIB
//CLIENTES DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
//RELATORIO DD SYSOUT=*
//SYSOUT DD SYSOUT=*
A instrução:
//STEP01 EXEC PGM=PGMCLI01
solicita a execução do programa.
A STEPLIB indica uma biblioteca na qual o sistema poderá procurar o módulo.
2. Como o programa é localizado?
O z/OS procura o módulo nas bibliotecas disponíveis no ambiente.
Podem participar:
TASKLIB;
STEPLIB;
JOBLIB;
LNKLST;
bibliotecas do sistema;
bibliotecas configuradas por CICS ou IMS.
Em batch, a STEPLIB é muito comum:
//STEPLIB DD DISP=SHR,
DSN=EMPRESA.SISTEMA.LOADLIB
Se PGMCLI01 não estiver disponível, pode ocorrer um erro de módulo não encontrado, frequentemente associado ao abend S806.
O código COBOL pode estar perfeito.
O problema pode ser apenas uma biblioteca incorreta.
3. QSAM
QSAM significa Queued Sequential Access Method.
Ele é utilizado para arquivos sequenciais.
No COBOL:
FILE-CONTROL.
SELECT ARQ-CLIENTES
ASSIGN TO CLIENTES
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-FILE-STATUS.
Na FILE SECTION:
FD ARQ-CLIENTES.
01 REGISTRO-CLIENTE.
05 REG-CODIGO PIC 9(09).
05 REG-NOME PIC X(40).
Na PROCEDURE DIVISION:
OPEN INPUT ARQ-CLIENTES
READ ARQ-CLIENTES
AT END
SET FIM-ARQUIVO TO TRUE
END-READ
CLOSE ARQ-CLIENTES.
4. O contrato entre COBOL e JCL
O programa utiliza:
ASSIGN TO CLIENTES
O JCL fornece:
//CLIENTES DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
A ligação é:
Nome lógico COBOL
↓
DDNAME do JCL
↓
Dataset físico
O programa não precisa conter o nome completo do dataset.
Isso permite executar o mesmo módulo com arquivos diferentes em:
desenvolvimento;
testes;
homologação;
produção.
5. Um erro comum de DDNAME
Se o programa espera:
ASSIGN TO CLIENTES
mas o JCL possui:
//ARQCLI DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
a associação poderá falhar.
O dataset existe.
O programa existe.
O erro está no contrato entre COBOL e JCL.
Essa é uma lição importante:
Nem todo erro de execução é um erro de programação.
6. VSAM
VSAM significa Virtual Storage Access Method.
Entre suas organizações estão:
KSDS;
ESDS;
RRDS;
LDS;
VRRDS.
Um KSDS pode ser definido no COBOL assim:
SELECT ARQ-CLIENTES
ASSIGN TO CLIENTES
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS REG-CODIGO
FILE STATUS IS WS-FILE-STATUS.
Uma leitura direta:
MOVE WS-CODIGO-PESQUISA
TO REG-CODIGO
READ ARQ-CLIENTES
KEY IS REG-CODIGO
INVALID KEY
DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ.
No JCL:
//CLIENTES DD DISP=SHR,
// DSN=EMPRESA.VSAM.CLIENTES
7. FILE STATUS
O FILE STATUS ajuda o programa a compreender o resultado de uma operação.
Exemplos conhecidos:
00 → operação concluída
10 → fim do arquivo sequencial
22 → possível chave duplicada
23 → registro não encontrado
35 → problema de abertura ou arquivo ausente
A interpretação exata deve considerar o contexto e a documentação.
O compilador não consegue prever esses erros.
Eles dependem dos dados e do ambiente de execução.
8. QSAM e VSAM não ficam dentro da loadlib
A load library contém o executável.
Os datasets permanecem separados.
LOADLIB
└── PGMCLI01
QSAM
└── registros sequenciais
VSAM
└── registros organizados por chave
Durante a execução, o JCL conecta o programa aos dados.
Essa separação permite grande flexibilidade operacional.
9. O que o JES2 faz?
JES2 significa Job Entry Subsystem 2.
Ele gerencia a entrada, a fila e a saída dos jobs.
Fluxo simplificado:
SUBMIT do JCL
↓
JES2 recebe o job
↓
Job entra no spool
↓
Classe e prioridade são avaliadas
↓
Job aguarda execução
↓
Initiator seleciona o job
↓
Steps são executados
↓
Saídas voltam ao spool
↓
Usuário consulta no SDSF
O JES2 não compila o COBOL.
Ele também não executa diretamente as instruções na CPU.
Sua função é organizar e administrar o fluxo dos jobs.
10. O spool
O spool é uma área em disco usada para armazenar entrada e saída.
No SDSF, podemos encontrar:
JESMSGLG
JESJCL
JESYSMSG
SYSPRINT
SYSOUT
SYSUDUMP
CEEDUMP
Essas saídas ajudam a analisar:
JCL;
mensagens do sistema;
return codes;
listagens;
relatórios;
dumps;
abends;
mensagens do Language Environment.
11. O initiator
O initiator seleciona jobs elegíveis para execução.
Ele considera elementos como:
classe;
disponibilidade;
configuração;
recursos;
prioridade;
regras operacionais.
Quando o job é selecionado, cada step precisa ser preparado.
Para:
//STEP01 EXEC PGM=PGMCLI01
o sistema deverá:
interpretar o step;
alocar os DD statements;
localizar o módulo;
preparar o ambiente;
carregar o programa;
entregar o controle;
acompanhar a execução;
registrar o retorno;
liberar os recursos.
12. O loader e a memória
O módulo é localizado em uma biblioteca.
Em seguida, o sistema o carrega no ambiente de memória apropriado.
O programa passa a contar com:
código executável;
áreas de trabalho;
runtime COBOL;
Language Environment;
buffers;
bibliotecas;
recursos alocados.
O Language Environment auxilia em:
inicialização;
armazenamento;
parâmetros;
tratamento de condições;
dumps;
finalização;
comunicação entre linguagens.
13. O programa chega à CPU
A CPU não entende COBOL.
Ela executa instruções de máquina produzidas pelo compilador.
O programa é representado por unidades de trabalho que podem receber tempo de processador.
O dispatcher do z/OS distribui a capacidade entre tarefas elegíveis.
O Workload Manager ajuda a orientar prioridades e objetivos de serviço.
Podem participar dessa decisão:
importância;
service class;
metas de desempenho;
dispatching priority;
disponibilidade de processadores;
estado da tarefa.
14. O programa não fica sempre na CPU
Considere uma leitura:
READ ARQ-CLIENTES.
A operação pode depender de:
QSAM ou VSAM;
buffers;
canais;
controladores;
discos;
cache;
sistema de armazenamento.
Enquanto aguarda uma operação de entrada e saída, o programa pode deixar de utilizar a CPU.
Outra tarefa poderá executar nesse período.
Por isso:
Tempo de CPU ≠ tempo total decorrido
Um job pode levar dez minutos e utilizar uma fração desse tempo em CPU.
O restante pode ser espera por:
arquivos;
Db2;
IMS;
Adabas;
locks;
filas;
MQ;
rede;
entrada e saída.
15. Execução CICS
Um programa CICS normalmente não é iniciado por um novo job para cada transação.
A região CICS já está ativa.
Quando uma transação é solicitada:
o CICS reconhece o código da transação;
verifica segurança;
localiza o programa;
cria uma task;
carrega o módulo, se necessário;
entrega o controle;
atende comandos
EXEC CICS;controla recursos;
finaliza a task.
O JES2 participa da inicialização da região CICS, mas não trata cada transação como um job batch separado.
16. Execução Db2
Durante a execução de um programa Db2:
o módulo COBOL é carregado;
a interface Db2 é acionada;
o package é localizado;
o SQL é executado;
tabelas e índices são acessados;
os resultados retornam às host variables;
a SQLCA informa o resultado.
O load module e o package precisam estar compatíveis.
17. Execução IMS e Adabas
No IMS, o programa executa dentro de uma região adequada e utiliza PSBs, PCBs e serviços DL/I.
No Adabas, o programa envia solicitações para o Nucleus por meio das interfaces disponíveis.
Nos dois casos, a CPU executa o código COBOL, enquanto os subsistemas especializados gerenciam os dados e transações.
18. O fluxo completo
Agora podemos visualizar toda a jornada:
Fonte COBOL
↓
Copybooks
↓
Tradução CICS
↓
Pré-compilação Db2
↓
Compilação
↓
Código objeto
↓
Linkedição
↓
Load module
↓
LOADLIB
↓
JCL ou transação
↓
JES2 e spool
↓
Initiator
↓
Loader
↓
Memória
↓
Dispatcher e WLM
↓
CPU
↓
QSAM, VSAM, Db2, IMS, Adabas ou CICS
↓
Resultado
Conclusão da Parte IV
O programa COBOL não simplesmente “roda”.
Ele é:
escrito;
preparado;
compilado;
linkedidado;
armazenado;
localizado;
carregado;
despachado;
executado;
monitorado.
O JES2 administra a entrada e a saída dos jobs.
O initiator inicia o processamento.
O loader coloca o programa no ambiente de memória.
O z/OS administra recursos.
O WLM ajuda a orientar prioridades.
O dispatcher entrega tempo de processador.
A CPU executa as instruções de máquina.
QSAM, VSAM, CICS, Db2, IMS e Adabas fornecem serviços especializados.
O iniciante enxerga apenas um programa.
O especialista enxerga uma cadeia completa de engenharia.
Palavra final do Mestre Bellacosa
Quando alguém disser:
“É só compilar e executar”,
lembre-se de tudo o que existe por trás desse simples comando.
No IBM Z, o programa precisa atravessar uma arquitetura construída para processar milhões de transações com segurança, disponibilidade, controle e previsibilidade.
O Padawan acredita que a jornada termina quando escreve o último STOP RUN.
O especialista sabe que, naquele momento, a verdadeira jornada está apenas começando.
☕
“O COBOL descreve a regra. O compilador constrói o caminho. O Binder reúne as peças. O z/OS prepara o terreno. E a CPU transforma décadas de conhecimento de negócio em processamento real.”
Laboratório Forense Bellacosa Mainframe
CSI z/OS: Da Compilação à Execução de um Programa COBOL
Cinco arquivos de evidências revelam como o código-fonte COBOL atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.
Esta investigação técnica apresenta o ciclo completo de um programa COBOL no mainframe IBM Z. A série explica o nascimento do código-fonte, o uso de copybooks, a preparação de comandos CICS e SQL, a geração de código objeto, a atuação do Binder, o armazenamento em load libraries e a execução por JCL, JES2, loader, Language Environment, dispatcher e CPU. Selecione uma evidência abaixo para ler o artigo correspondente dentro do visualizador.
Laudo preliminar: o nascimento do programa
A primeira parte acompanha a transformação da regra de negócio em código-fonte COBOL, explica o papel das bibliotecas e mostra por que copybooks funcionam como contratos de dados compartilhados entre programas.
