 |
| Bellacosa Mainframe e a compilação cobol parte II |
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL — Parte II
CICS, Db2, IMS e Adabas: O que Acontece com o Código Antes de o Compilador Entrar em Cena
Introdução
Na primeira parte desta jornada, conhecemos o nascimento de um programa COBOL.
Vimos que tudo começa com o código-fonte armazenado em uma biblioteca, geralmente um PDS ou PDSE, e que os copybooks funcionam como contratos reutilizáveis entre programas, arquivos, mensagens e sistemas.
Também descobrimos uma diferença essencial:
COPY inclui código-fonte.
CALL executa outro módulo.
Porém, quando abrimos um programa corporativo real, especialmente em um banco, seguradora, indústria ou grande empresa, encontramos instruções que parecem COBOL, mas que não pertencem diretamente à linguagem.
Por exemplo:
EXEC CICS
READ FILE('CLIENTE')
INTO(REGISTRO-CLIENTE)
RIDFLD(WS-CHAVE)
END-EXEC.
Ou:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Também podemos encontrar chamadas como:
CALL 'CBLTDLI'
USING GU-FUNCTION
PCB-MASK
AREA-SEGMENTO
SSA-CLIENTE.
Ou estruturas utilizadas na comunicação com Adabas.
O Programador COBOL Padawan olha para tudo isso e pode imaginar que o compilador entende todos esses comandos naturalmente.
Mas não é exatamente assim.
Antes que o compilador COBOL possa transformar o fonte em código objeto, outros componentes precisam preparar partes específicas do programa.
É como uma grande cozinha corporativa.
O compilador é o chef principal, mas alguns ingredientes precisam ser preparados por especialistas antes de chegar à bancada.
Nesta segunda parte, vamos entender:
o papel do tradutor CICS;
como o Db2 processa comandos
EXEC SQL;o que é um DBRM;
por que o BIND do Db2 não é linkedição;
como programas COBOL acessam IMS;
como ocorre a comunicação com Adabas;
o que todas essas tecnologias possuem em comum.
Prepare o café, abra o ISPF e venha descobrir o que realmente acontece com o código antes da compilação.
1. Nem tudo o que aparece no programa é COBOL puro
COBOL possui instruções próprias, como:
MOVE
ADD
SUBTRACT
MULTIPLY
DIVIDE
COMPUTE
IF
EVALUATE
PERFORM
READ
WRITE
REWRITE
DELETE
OPEN
CLOSE
CALL
Essas instruções fazem parte da linguagem e podem ser analisadas diretamente pelo compilador.
Porém, comandos como:
EXEC CICS
EXEC SQL
pertencem a ambientes externos.
Eles foram incorporados ao fonte por meio de uma sintaxe padronizada, mas precisam ser interpretados por componentes especializados.
Uma representação simples seria:
Programa COBOL
├── comandos COBOL
├── comandos CICS
├── comandos SQL
├── chamadas IMS
└── interfaces Adabas
O compilador entende plenamente a primeira parte.
As demais exigem preparação, tradução, bibliotecas ou interfaces específicas.
2. O que é o CICS?
CICS significa Customer Information Control System.
Na prática, ele é uma plataforma de processamento de transações online.
Quando um cliente consulta o saldo, realiza uma transferência, altera um endereço ou solicita uma segunda via de documento, existe uma grande possibilidade de algum componente CICS estar envolvido em ambientes tradicionais IBM Z.
O CICS gerencia elementos como:
transações;
programas;
terminais;
sessões;
arquivos;
filas;
segurança;
recuperação;
sincronização;
comunicação entre sistemas;
controle de recursos;
integração com Db2, MQ e outras tecnologias.
O programa COBOL contém a regra de negócio.
O CICS controla o ambiente transacional em que essa regra será executada.
Imagine uma transação chamada:
C001
Ela pode estar associada ao programa:
PGMCLI01
Quando o usuário informa C001, o CICS localiza o programa, cria uma task, verifica segurança, entrega o controle e acompanha sua execução.
3. Os comandos EXEC CICS
Um programa pode utilizar comandos como:
EXEC CICS
RECEIVE MAP('MAPCLI')
MAPSET('SETCLI')
INTO(AREA-MAPA)
END-EXEC.
Esse comando solicita o recebimento dos dados de uma tela.
Outro exemplo:
EXEC CICS
SEND MAP('MAPCLI')
MAPSET('SETCLI')
FROM(AREA-MAPA)
ERASE
END-EXEC.
Nesse caso, o programa solicita o envio de um mapa para o terminal.
Também podemos encontrar:
EXEC CICS
READ FILE('ARQCLI')
INTO(REGISTRO-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
END-EXEC.
Ou:
EXEC CICS
LINK PROGRAM('PGM002')
COMMAREA(AREA-COMUNICACAO)
LENGTH(WS-TAMANHO)
END-EXEC.
Esses comandos parecem fazer parte do COBOL porque estão misturados ao código.
Entretanto, o compilador COBOL puro não sabe implementar operações como:
enviar uma tela;
ler um arquivo controlado pelo CICS;
iniciar outra transação;
acessar uma fila temporária;
chamar outro programa por meio do CICS;
devolver o controle ao monitor transacional.
Por isso, entra em cena o tradutor CICS.
4. O tradutor CICS
O tradutor CICS analisa os comandos:
EXEC CICS
...
END-EXEC
e os transforma em estruturas que o compilador COBOL consegue processar.
O fluxo conceitual é:
Fonte COBOL com EXEC CICS
↓
Tradutor CICS
↓
Fonte COBOL traduzido
↓
Compilador COBOL
O tradutor não executa a transação.
Ele apenas prepara o fonte.
Imagine o seguinte comando:
EXEC CICS
WRITEQ TS
QUEUE('TEMP001')
FROM(WS-DADOS)
LENGTH(WS-TAMANHO)
END-EXEC.
O tradutor converte essa instrução em uma sequência de chamadas e estruturas internas utilizadas pela interface do CICS.
Depois dessa tradução, o compilador enxerga COBOL válido.
Durante a execução, o programa chama os serviços CICS correspondentes.
5. EXEC CICS é uma macro?
No cotidiano do mainframe, alguns profissionais chamam os comandos EXEC CICS de macros.
Essa forma de falar é compreensível, mas pode gerar confusão.
Uma macro, em outros contextos, costuma ser um trecho expandido diretamente durante a montagem ou compilação.
O comando EXEC CICS é melhor compreendido como uma instrução embutida que precisa ser traduzida por um processador específico.
Portanto, tecnicamente, é mais correto dizer:
EXEC CICSé um comando CICS embutido no programa COBOL.
A distinção pode parecer pequena, mas ajuda o iniciante a compreender que existe uma etapa especializada antes da compilação.
6. CICS controla o recurso, não o programa COBOL
Considere:
EXEC CICS
READ FILE('CLIENTES')
INTO(REG-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
END-EXEC.
O programa não abre diretamente o arquivo físico.
Ele pede ao CICS que realize a leitura.
O CICS pode cuidar de:
localização do recurso;
compartilhamento;
segurança;
recuperação;
bloqueios;
integridade;
controle transacional;
resposta de erro.
O programa recebe o resultado e continua a regra de negócio.
Esse modelo é poderoso porque separa responsabilidades.
Programa COBOL → lógica de negócio
CICS → controle transacional
7. O que é o Db2?
Db2 é o sistema gerenciador de banco de dados relacional da IBM amplamente utilizado no IBM Z.
Ele organiza informações em:
tabelas;
colunas;
linhas;
índices;
views;
tablespaces;
databases;
schemas;
packages;
plans;
collections.
O COBOL pode acessar dados Db2 por meio de SQL embutido.
Exemplo:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Esse SQL está inserido dentro do fonte COBOL.
Porém, ele não pertence diretamente à linguagem COBOL.
Assim como ocorre com o CICS, o SQL precisa ser processado antes da compilação.
8. O pré-compilador Db2
Historicamente, programas COBOL com SQL passavam pelo pré-compilador Db2.
O fluxo clássico é:
Fonte COBOL com EXEC SQL
↓
Pré-compilador Db2
↓
Fonte COBOL modificado
+
DBRM
O pré-compilador realiza duas tarefas importantes.
Primeiro, ele substitui ou prepara os comandos SQL no fonte para que o compilador COBOL possa processá-los.
Segundo, ele gera o DBRM.
Em ambientes modernos, pode ser utilizado um coprocessador SQL integrado ao compilador.
Para o iniciante, o conceito fundamental permanece:
O SQL precisa ser analisado por uma tecnologia Db2 antes ou durante a compilação COBOL.
9. O que é o DBRM?
DBRM significa Database Request Module.
Ele contém informações extraídas dos comandos SQL presentes no programa.
Considere:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE AGENCIA = :WS-AGENCIA
AND CONTA = :WS-CONTA
END-EXEC.
O Db2 precisa conhecer essa instrução para preparar sua execução.
O DBRM representa as requisições SQL encontradas no programa.
Posteriormente, ele será utilizado em uma operação de BIND.
O fluxo é:
Programa com SQL
↓
DBRM
↓
BIND PACKAGE
↓
Package Db2
O package contém a preparação necessária para que o Db2 execute as instruções SQL.
10. O BIND do Db2
O BIND do Db2 transforma o DBRM em um package executável pelo subsistema.
Durante esse processo, o Db2 pode avaliar:
existência das tabelas;
existência das colunas;
existência dos índices;
autorizações;
estatísticas;
opções de isolamento;
caminhos de acesso;
versões;
collections;
parâmetros de execução.
O Db2 decide como determinada instrução poderá ser executada.
Por exemplo:
SELECT NOME
FROM CLIENTES
WHERE CODIGO = ?
O Db2 poderá utilizar:
um índice;
uma varredura de tabela;
um índice composto;
uma combinação de acessos;
alguma estratégia definida pelo otimizador.
O programa COBOL informa o que deseja.
O Db2 decide como localizar os dados.
11. BIND Db2 não é linkedição
Este é um dos pontos mais importantes deste capítulo.
No mainframe, a palavra “bind” pode aparecer em contextos diferentes.
Existe o Binder do z/OS, responsável pela criação do módulo executável.
E existe o BIND do Db2, responsável pela preparação do SQL.
Binder z/OS → cria load module ou program object
BIND Db2 → cria package
Portanto:
Compilação + linkedição ≠ BIND Db2
Um programa pode estar perfeitamente compilado e linkedidado, mas falhar porque:
o package não existe;
o package está inválido;
a collection está incorreta;
o usuário não possui autorização;
os objetos Db2 foram alterados;
a versão do package não corresponde ao programa.
12. As duas trilhas de um programa Db2
Um programa COBOL com Db2 segue duas trilhas paralelas.
Trilha COBOL
Fonte
↓
Compilador
↓
Código objeto
↓
Binder
↓
Módulo executável
Trilha Db2
EXEC SQL
↓
DBRM
↓
BIND
↓
Package
Na execução, as duas trilhas se encontram.
O módulo executável inicia a lógica COBOL.
Quando chega a um comando SQL, ele aciona a interface Db2, que utiliza o package correspondente.
O load module sozinho não é suficiente.
O package sozinho também não é suficiente.
Eles trabalham em conjunto.
13. Host variables
Campos COBOL utilizados dentro de instruções SQL são chamados de host variables.
Exemplo:
01 WS-CODIGO PIC 9(09).
01 WS-NOME PIC X(40).
No SQL:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Os dois-pontos indicam que os campos pertencem ao programa COBOL.
Sem essa indicação, o Db2 poderia interpretar o nome como uma coluna ou outro elemento SQL.
As host variables formam a ponte entre:
Memória COBOL ↔ Db2
14. A SQLCA
SQLCA significa SQL Communication Area.
Ela contém informações sobre a execução do último comando SQL.
Sua inclusão pode ser feita assim:
EXEC SQL
INCLUDE SQLCA
END-EXEC.
Depois de uma instrução SQL, o programa pode testar:
EVALUATE SQLCODE
WHEN 0
DISPLAY 'OPERACAO REALIZADA'
WHEN 100
DISPLAY 'REGISTRO NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO SQL: ' SQLCODE
END-EVALUATE.
O SQLCODE é um dos campos mais conhecidos.
Alguns resultados comuns são:
SQLCODE 0 → sucesso
SQLCODE 100 → nenhuma linha encontrada
SQLCODE negativo → erro
SQLCODE positivo → aviso ou situação específica
O programa precisa tratar esses resultados.
Ignorar o SQLCODE é como atravessar uma rodovia sem olhar os sinais.
15. Indicadores de nulo
No Db2, uma coluna pode aceitar valor nulo.
COBOL, porém, trabalha com campos que possuem conteúdo físico.
Para representar um nulo, é comum utilizar uma variável indicadora.
Exemplo:
01 WS-TELEFONE PIC X(15).
01 WS-IND-TELEFONE PIC S9(04) COMP.
No SQL:
EXEC SQL
SELECT TELEFONE
INTO :WS-TELEFONE
:WS-IND-TELEFONE
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Se o indicador retornar valor negativo, a coluna estava nula.
Sem o indicador adequado, o programa pode receber erros ao tentar trabalhar com valores nulos.
16. Um programa CICS com Db2
Em sistemas online, é comum encontrar CICS e Db2 dentro do mesmo programa.
Exemplo:
EXEC CICS
RECEIVE MAP('MAPCLI')
MAPSET('SETCLI')
INTO(AREA-MAPA)
END-EXEC.
MOVE MAP-CODIGO TO WS-CODIGO.
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
EXEC CICS
SEND MAP('MAPCLI')
MAPSET('SETCLI')
FROM(AREA-MAPA)
END-EXEC.
Nesse caso, o programa utiliza:
CICS para controlar a transação e a tela;
Db2 para acessar os dados;
COBOL para executar a regra de negócio.
O fluxo pode envolver:
Fonte com CICS e SQL
↓
Tradução CICS
↓
Processamento Db2
↓
Compilação COBOL
↓
Linkedição
↓
BIND do package Db2
A sequência exata pode variar conforme as ferramentas e versões.
Mas todos esses elementos precisam ser preparados.
17. O que é IMS?
IMS significa Information Management System.
É uma plataforma histórica e extremamente importante no ecossistema IBM Z.
Ela pode ser dividida em duas grandes áreas:
IMS DB → gerenciamento de banco de dados hierárquico
IMS TM → gerenciamento de transações e mensagens
Um banco IMS não organiza os dados exatamente como uma tabela relacional.
Ele utiliza uma estrutura hierárquica baseada em segmentos.
Podemos imaginar:
CLIENTE
├── CONTA
│ ├── MOVIMENTO
│ └── CARTAO
└── ENDERECO
O segmento CLIENTE pode ser o pai.
CONTA e ENDERECO podem ser filhos.
MOVIMENTO pode ser filho de CONTA.
Essa estrutura lembra uma árvore.
18. Chamadas DL/I
Programas COBOL acessam IMS por meio da interface DL/I.
DL/I significa Data Language/I.
Uma chamada conceitual pode ser:
CALL 'CBLTDLI'
USING GU-FUNCTION
PCB-MASK
SEGMENTO-CLIENTE
SSA-CLIENTE.
A função GU significa Get Unique.
Ela solicita a localização de um segmento específico.
Outras funções comuns incluem:
GU Get Unique
GN Get Next
GNP Get Next Within Parent
GHU Get Hold Unique
GHN Get Hold Next
ISRT Insert
REPL Replace
DLET Delete
O programa envia uma solicitação ao IMS.
O IMS navega pela estrutura hierárquica e retorna o segmento solicitado.
19. O PCB no IMS
PCB significa Program Communication Block.
Ele representa a comunicação entre o programa e um banco ou fila de mensagens IMS.
Após uma chamada DL/I, o programa pode verificar campos da PCB para descobrir:
status da operação;
nome do segmento;
nível hierárquico;
informações de processamento;
resultado da chamada.
É semelhante ao papel do FILE STATUS em arquivos ou do SQLCODE no Db2.
Cada tecnologia possui sua maneira de informar ao programa o resultado da operação.
QSAM/VSAM → FILE STATUS
Db2 → SQLCODE e SQLSTATE
IMS → status da PCB
CICS → RESP e RESP2
Adabas → response code
Um bom programador não ignora nenhum desses retornos.
20. O que são DBD e PSB?
O ambiente IMS utiliza definições importantes.
DBD
DBD significa Database Description.
Ele descreve a estrutura do banco IMS:
segmentos;
relacionamentos;
campos-chave;
organização;
métodos de acesso;
características físicas e lógicas.
PSB
PSB significa Program Specification Block.
Ele define quais recursos um programa pode acessar e como poderá acessá-los.
O PSB pode conter PCBs para:
bancos IMS;
filas de mensagens;
outros recursos.
Podemos imaginar:
DBD → descreve o banco
PSB → descreve a visão do programa
PCB → interface usada durante a execução
21. IMS Transaction Manager
O IMS TM controla transações baseadas em mensagens.
Um fluxo simplificado pode ser:
Terminal, API ou outro sistema
↓
Mensagem de entrada
↓
Fila IMS
↓
Código de transação
↓
Programa COBOL
↓
Processamento
↓
Mensagem de saída
O programa pode receber a mensagem por meio de uma PCB de entrada e produzir uma resposta.
Assim como o CICS, o IMS controla o ambiente transacional.
Mas sua arquitetura, seus conceitos e sua forma de programação são diferentes.
22. Regiões IMS
Programas IMS podem executar em diferentes tipos de regiões.
Entre elas:
MPP;
BMP;
batch DL/I;
regiões utilitárias;
ambientes controlados pelo IMS.
MPP
Message Processing Program.
Processa mensagens e transações IMS.
BMP
Batch Message Processing.
Executa processamento batch com acesso controlado a bancos IMS e, em certos casos, filas.
O programa COBOL continua sendo compilado e linkedidado.
Porém, sua execução depende do ambiente IMS e das definições corretas.
23. O que é Adabas?
Adabas é um sistema de gerenciamento de banco de dados criado pela Software AG.
Ele se tornou muito conhecido em ambientes que utilizam Natural, mas também pode ser acessado por programas COBOL.
O Adabas possui uma arquitetura própria e utiliza componentes como:
Nucleus;
arquivos Adabas;
control blocks;
buffers;
interfaces de chamada;
códigos de resposta.
O Nucleus é o componente central que processa as solicitações.
Uma representação simplificada seria:
Programa COBOL
↓
Interface Adabas
↓
Adabas Nucleus
↓
Arquivo Adabas
24. Control Block e buffers Adabas
Um programa pode utilizar um control block para informar:
comando;
arquivo;
identificadores;
opções;
códigos de resposta;
informações de navegação;
parâmetros da operação.
Também podem existir buffers como:
Format Buffer
Define os campos que serão lidos ou atualizados.
Record Buffer
Recebe ou envia os dados do registro.
Search Buffer
Descreve os critérios de pesquisa.
Value Buffer
Contém os valores utilizados na pesquisa.
ISN Buffer
Pode armazenar números internos de sequência de registros.
Essas estruturas são fornecidas à interface Adabas durante a chamada.
25. Response Code Adabas
Após uma operação, o programa precisa verificar o código de resposta.
Um retorno de sucesso indica que a solicitação foi processada.
Outros códigos podem indicar:
registro não encontrado;
arquivo indisponível;
comando inválido;
conflito;
erro de formato;
problema de segurança;
falha de comunicação;
inconsistência de parâmetros.
Assim como no Db2, IMS, CICS ou VSAM, nunca se deve presumir que uma operação foi bem-sucedida sem verificar o retorno.
26. Natural e Adabas
Muitos iniciantes associam Adabas exclusivamente à linguagem Natural.
Essa associação existe porque as duas tecnologias são frequentemente utilizadas juntas.
Porém:
Natural é uma linguagem e ambiente de desenvolvimento.
Adabas é um sistema gerenciador de banco de dados.
Um programa COBOL também pode acessar Adabas por meio de interfaces apropriadas.
Da mesma forma, um programa Natural pode acessar outros recursos.
Não confunda a linguagem com o banco de dados.
27. O padrão comum entre CICS, Db2, IMS e Adabas
Apesar das diferenças, existe um padrão arquitetural comum.
O programa COBOL não controla diretamente toda a infraestrutura.
Ele solicita serviços.
COBOL → descreve a regra de negócio
CICS → controla a transação
Db2 → gerencia dados relacionais
IMS → gerencia dados hierárquicos e mensagens
Adabas → gerencia dados em sua arquitetura
Cada ambiente fornece:
interfaces;
comandos;
códigos de retorno;
controle de recursos;
segurança;
recuperação;
mecanismos de diagnóstico.
O programa COBOL deve respeitar os contratos de cada um.
28. O código de retorno é parte da lógica
Considere um programador que escreve:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA = :WS-CONTA
END-EXEC.
DISPLAY 'OPERACAO REALIZADA'.
Esse programa exibe sucesso sem verificar o SQLCODE.
Se a conta não existir, o programa poderá informar uma operação que não aconteceu.
O correto seria:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA = :WS-CONTA
END-EXEC.
EVALUATE SQLCODE
WHEN 0
DISPLAY 'OPERACAO REALIZADA'
WHEN 100
DISPLAY 'CONTA NAO ENCONTRADA'
WHEN OTHER
DISPLAY 'ERRO DB2: ' SQLCODE
END-EVALUATE.
O mesmo princípio vale para:
RESP CICS
FILE STATUS
PCB IMS
Response Code Adabas
No mainframe, tratar retorno não é uma recomendação opcional.
É parte da regra de negócio.
29. O perigo das opções implícitas
Alguns comandos utilizam tratamento automático de erro.
No CICS, por exemplo, certos erros podem transferir o controle para mecanismos padrão caso o programa não utilize opções como:
RESP
RESP2
NOHANDLE
HANDLE CONDITION
Em programas modernos, é comum preferir tratamento explícito por RESP e RESP2.
Exemplo:
EXEC CICS
READ FILE('ARQCLI')
INTO(REG-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
RESP2(WS-RESP2)
END-EXEC.
EVALUATE WS-RESP
WHEN DFHRESP(NORMAL)
CONTINUE
WHEN DFHRESP(NOTFND)
DISPLAY 'CLIENTE NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO CICS: ' WS-RESP
END-EVALUATE.
O objetivo é impedir que falhas sejam tratadas de forma inesperada.
30. Copybooks especializados
Esses ambientes também utilizam copybooks.
No CICS, podem existir:
layouts de COMMAREA;
mapas BMS;
estruturas de mensagens;
áreas de resposta;
contratos entre programas.
No Db2, podem existir:
DCLGENs;
estruturas de tabelas;
SQLCA;
áreas de entrada e saída.
No IMS:
layouts de segmentos;
PCBs;
SSAs;
áreas de mensagens.
No Adabas:
control blocks;
buffers;
layouts de registros;
constantes e códigos.
Portanto, o copybook apresentado na primeira parte continua sendo fundamental.
Ele liga o programa às interfaces dos subsistemas.
31. DCLGEN no Db2
DCLGEN significa Declarations Generator.
Ele pode gerar estruturas COBOL compatíveis com colunas de uma tabela Db2.
Exemplo conceitual:
01 DCLCLIENTES.
10 CLIENTE-CODIGO PIC S9(9) COMP.
10 CLIENTE-NOME PIC X(40).
10 CLIENTE-SALDO PIC S9(11)V99 COMP-3.
O programa inclui essa estrutura por meio de um copybook ou processo equivalente.
Isso reduz a possibilidade de divergência entre os campos COBOL e as definições do banco.
Porém, a geração não elimina a necessidade de análise.
Tipos, precisão, nulos e conversões precisam ser compreendidos.
32. O programa ainda não é executável
Depois da tradução CICS, do processamento SQL e da preparação das interfaces IMS ou Adabas, o programa ainda não está pronto para executar.
Neste momento, temos algo semelhante a:
Fonte COBOL preparado
Copybooks expandidos ou localizados
Comandos CICS traduzidos
Comandos SQL processados
DBRM gerado
Interfaces disponíveis
O próximo passo será a compilação.
O compilador transformará o fonte em código objeto.
Depois, o Binder realizará a linkedição.
Somente então surgirá o módulo executável.
33. O fluxo completo desta etapa
Podemos representar a Parte II assim:
Fonte COBOL
↓
Identificação de comandos externos
↓
EXEC CICS → tradução CICS
↓
EXEC SQL → pré-compilação ou coprocessamento Db2
↓
Geração do DBRM
↓
Chamadas IMS → preparação das interfaces DL/I
↓
Chamadas Adabas → uso de control blocks e buffers
↓
Fonte preparado para compilação
Em paralelo:
DBRM
↓
BIND Db2
↓
Package
34. Erros típicos antes da compilação
Nesta fase, podem ocorrer problemas como:
CICS
comando
EXEC CICSinválido;opção incompatível;
copybook CICS ausente;
tamanho incorreto de COMMAREA;
referência a campo inexistente;
estrutura de mapa incorreta.
Db2
host variable não declarada;
SQLCA ausente;
sintaxe SQL inválida;
DCLGEN incompatível;
indicador de nulo inexistente;
DBRM não gerado.
IMS
PCB incompatível;
SSA incorreta;
função DL/I inválida;
layout de segmento divergente;
ordem incorreta dos parâmetros.
Adabas
control block incorreto;
buffer incompatível;
código de comando inválido;
tamanho inconsistente;
interface ausente.
O segredo é identificar em qual tecnologia o erro está ocorrendo.
35. O Padawan pergunta: quem executa primeiro?
A resposta depende do programa.
Um programa COBOL batch simples pode seguir diretamente para o compilador.
Um programa CICS pode precisar de tradução.
Um programa Db2 precisa de processamento SQL.
Um programa CICS Db2 precisa dos dois.
Um programa IMS ou Adabas precisa das interfaces corretas durante compilação, linkedição e execução.
Portanto:
Não existe um único fluxo universal.
Existe um fluxo-base que recebe etapas adicionais conforme as tecnologias utilizadas.
36. O verdadeiro papel do COBOL
O COBOL continua sendo o centro da regra de negócio.
Exemplo:
IF WS-SALDO >= WS-VALOR
PERFORM DEBITAR-CONTA
PERFORM REGISTRAR-MOVIMENTO
ELSE
MOVE 'SALDO INSUFICIENTE'
TO WS-MENSAGEM
END-IF.
Porém, as operações internas podem utilizar vários subsistemas.
DEBITAR-CONTA → Db2
REGISTRAR-MOVIMENTO → IMS
ENVIAR-MENSAGEM → CICS ou MQ
CONSULTAR-CADASTRO → Adabas
O COBOL orquestra a regra.
Os subsistemas fornecem capacidades especializadas.
37. Uma analogia com uma missão espacial
Imagine uma nave espacial.
O programa COBOL é o comandante da missão.
Ele decide:
qual objetivo deve ser atingido;
qual operação deve ser realizada;
o que fazer em caso de falha;
quando continuar;
quando interromper.
O CICS é o centro de controle de missões online.
O Db2 é o banco de dados científico organizado em tabelas.
O IMS é o sistema hierárquico de navegação e mensagens.
O Adabas é outro repositório especializado de dados.
O tradutor CICS e o pré-compilador Db2 são intérpretes que transformam os comandos do comandante em instruções compreensíveis por cada sistema.
O compilador, que veremos no próximo capítulo, será o engenheiro que converterá toda a missão em instruções executáveis pela máquina.
38. Conselhos do Mestre Bellacosa
Ao trabalhar com programas que utilizam CICS, Db2, IMS ou Adabas, sempre pergunte:
Quais processadores precisam preparar o fonte?
Existe tradução CICS?
Existe pré-compilação ou coprocessador Db2?
O DBRM foi gerado?
O package correto foi criado?
O programa utiliza a versão certa do DCLGEN?
As host variables estão compatíveis?
O
SQLCODEestá sendo tratado?O
RESPCICS está sendo validado?A PCB IMS corresponde ao PSB utilizado?
Os códigos de resposta Adabas são verificados?
Os copybooks estão na versão correta?
O ambiente de compilação utiliza as bibliotecas corretas?
O processo automatizado esconde quais etapas?
Essas perguntas transformam um iniciante em um profissional que entende arquitetura.
Conclusão
Um programa COBOL corporativo pode conter muito mais do que instruções COBOL tradicionais.
Comandos EXEC CICS precisam ser traduzidos para que o compilador possa processá-los.
Comandos EXEC SQL precisam ser analisados pelo pré-compilador ou coprocessador Db2, gerando um fonte preparado e um DBRM.
O DBRM será utilizado no BIND para criação de um package.
No IMS, o programa utiliza chamadas DL/I, PCBs, PSBs, DBDs e layouts hierárquicos.
No Adabas, o acesso ocorre por meio de interfaces, control blocks, buffers e códigos de resposta.
Apesar das diferenças, todos esses ambientes compartilham o mesmo princípio:
O programa COBOL descreve a regra de negócio e solicita serviços a subsistemas especializados.
O CICS controla transações.
O Db2 gerencia dados relacionais.
O IMS processa bancos hierárquicos e mensagens.
O Adabas administra dados por meio de sua própria arquitetura.
E o COBOL permanece no centro, coordenando decisões, cálculos, validações e fluxos empresariais.
Mas ainda falta uma etapa fundamental.
Até agora, o código foi apenas preparado.
Ele ainda não se tornou um módulo executável.
No próximo capítulo
Na Parte III — Compilação, Linkedição e Load Library, entraremos no coração da transformação.
Veremos passo a passo:
como o compilador analisa o programa;
como o fonte se transforma em código objeto;
por que o objeto ainda não é o executável final;
como funciona o Binder;
o que são chamadas estáticas e dinâmicas;
como nasce um load module;
onde o executável é armazenado;
como interpretar return codes e listagens.
Se nesta parte conhecemos os tradutores que preparam a mensagem, no próximo capítulo conheceremos a fábrica que transforma palavras em instruções de máquina.
Prepare outra xícara de café.
A verdadeira transformação do programa COBOL está prestes a começar.
☕
“O Padawan enxerga CICS, Db2, IMS e Adabas como comandos misturados ao COBOL. O especialista enxerga contratos entre arquiteturas, cada uma responsável por uma parte essencial do processamento corporativo.”
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.
