Bellacosa Mainframe apresenta COBOL LE Enterprise

🚀 Do COPY ao CORE Bancário: A Jornada Jedi de um Programa COBOL no z/OS (ou: como um .CBL vira dinheiro no mundo real)

“Padawan, muitos escrevem código. Poucos entendem como ele realmente vive.” 💙

Se você acha que COBOL é só um DISPLAY "HELLO", prepare-se.
No mainframe, um programa não nasce pronto — ele passa por uma verdadeira linha de produção industrial de software.

Hoje vamos percorrer essa jornada completa, estilo Bellacosa Mainframe™, com:

🔥 Passo a passo real
🧠 Conceitos que diferenciam dev júnior de arquiteto
💎 Easter eggs históricos
🏦 Exemplos do mundo bancário
⚙️ Bastidores que ninguém te conta

---

🧙‍♂️ Capítulo 1 — O nascimento: o código fonte

Tudo começa com um membro em um PDS ou PDSE:

USER.COBOL.SOURCE(PROG1)

Exemplo simples:

IDENTIFICATION DIVISION.
PROGRAM-ID. CPRIME.

PROCEDURE DIVISION.
    DISPLAY "MAY THE MAINFRAME BE WITH YOU".
    STOP RUN.

💡 Curiosidade Jedi:
COBOL foi criado para ser legível por pessoas de negócio. Por isso parece “verbal”.

---

📚 Capítulo 2 — COPY: os pergaminhos antigos

Nenhum sistema corporativo vive sem COPYBOOKS.

COPY CLIENT-RECORD.

Esses artefatos ficam nas bibliotecas apontadas por:

//SYSLIB DD DSN=CORP.COPYLIB

💎 Easter egg:
Grandes bancos têm copybooks mais antigos que muitos desenvolvedores.

---

⚙️ Capítulo 3 — Compilação: o forno industrial (IGYCRCTL)

Agora entra o compilador Enterprise COBOL.

//COMPILE EXEC PGM=IGYCRCTL

📥 Entradas principais

DD	Função
SYSIN	Código fonte
SYSLIB	Copybooks
SYSUTx	Área de trabalho

📤 Saídas

DD	Resultado
SYSPRINT	Mensagens
SYSLIN	Object code

👉 O objeto ainda NÃO é executável.

---

🧠 Analogia moderna

Mainframe	Linux
Compile	gcc -c
Objeto	.o

---

💥 Capítulo 4 — O Binder: alquimia digital (IEWL)

Agora o objeto vira programa executável.

//LKED EXEC PGM=IEWL

📥 Entrada

SYSLIN → objeto compilado

📤 Saída

SYSLMOD → executável final

💎 Easter egg:
Antes do Binder moderno, isso se chamava “link-edit”.

---

📦 Program Object: o formato moderno

Hoje o resultado normalmente é um:

👉 Program Object em PDSE

Não mais um load module antigo.

---

🧬 Capítulo 5 — O espírito invisível: Language Environment (LE)

Aqui está o segredo que separa aprendizes de mestres.

💥 Programas COBOL não rodam sozinhos.

Eles precisam do LE.

O LE fornece:

✔️ Memória
✔️ Inicialização
✔️ Tratamento de erros
✔️ Serviços runtime
✔️ Interoperabilidade

---

🧠 Analogia suprema

Plataforma	Runtime
Java	JVM
.NET	CLR
z/OS	⭐ LE

---

⚙️ Capítulo 6 — Opções de runtime (CEEOPTS)

Exemplo famoso:

ALL31(ON)

Permite usar memória acima da linha de 16 MB.

🧪 Override via JCL

//CEEOPTS DD *
ALL31(ON)
/*

🚫 Nunca no código COBOL.

---

🏦 Capítulo 7 — Onde o programa pode rodar?

Um único executável pode viver em vários mundos:

Ambiente	Uso típico
Batch	Processamento massivo
CICS	Transações online
IMS	Sistemas críticos
Db2 SP	Lógica no banco
TSO	Execução interativa
USS	Scripts UNIX

❌ System exit — proibido (sem LE)

---

🐧 Capítulo 8 — USS e o mundo moderno

Você também pode compilar no UNIX do z/OS:

cob2 -q'RENT,LIST' pgm1.cbl

💡 O mainframe também fala “Linux”.

---

🧩 Capítulo 9 — Compatibilidade histórica (o verdadeiro poder)

Enterprise COBOL consegue recompilar código:

✔️ VS COBOL II (anos 80)
✔️ COBOL for OS/390

Mas não diretamente:

❌ OS/VS COBOL
❌ COBOL-68 / COBOL-74

💥 Isso é o que mantém sistemas funcionando por décadas.

---

🧙‍♂️ Capítulo 10 — A verdadeira força do mainframe

Um programa COBOL pode:

💥 Processar milhões de transações por segundo
💥 Rodar por décadas sem reescrita
💥 Integrar com APIs modernas
💥 Conviver com código de 40 anos atrás

---

🏆 Pipeline final — a jornada completa

Source (.CBL)
   ↓
Compile (IGYCRCTL)
   ↓
Object module
   ↓
Binder (IEWL)
   ↓
Program Object
   ↓
Execution (Batch / CICS / IMS / etc.)

---

💎 Easter egg final

💰 Grande parte do dinheiro do planeta passa por sistemas exatamente assim.

Cada saque, compra com cartão ou transferência:

👉 Pode estar executando código COBOL semelhante ao seu.

---

🧠 Conclusão 

Padawan, aprender COBOL não é aprender uma linguagem.

É entender uma arquitetura de computação empresarial completa, refinada por mais de meio século.

🚀 O código é apenas o começo.
🏗️ O processo é o verdadeiro poder.
💙 O mainframe é a fábrica invisível do mundo moderno.

 

Bellacosa Mainframe compilacao cobol parte iii

☕ Um Café no Bellacosa Mainframe

Da Compilação à Execução de um Programa COBOL — Parte III

Compilação, Linkedição e Load Library: Como o Código-Fonte se Transforma em um Programa Executável

Introdução

Na segunda parte desta jornada, vimos que muitos programas COBOL corporativos não seguem diretamente para o compilador.

Antes disso, eles podem passar por outras etapas especializadas.

Comandos como:

EXEC CICS

precisam ser traduzidos.

Comandos como:

EXEC SQL

precisam ser processados pelo pré-compilador ou coprocessador Db2.

Programas IMS utilizam interfaces DL/I, PCBs, PSBs e DBDs.

Aplicações Adabas dependem de control blocks, buffers e módulos de comunicação.

Depois que todo esse material foi preparado, finalmente chega o momento em que o compilador COBOL entra em cena.

É aqui que o texto escrito pelo programador começa a se transformar em instruções realmente compreendidas pela máquina.

Entretanto, existe uma confusão muito comum entre iniciantes:

Compilar não significa necessariamente criar o executável final.

A compilação produz um código objeto.

Depois disso, outra ferramenta, chamada Binder, precisa reunir esse objeto com interfaces, rotinas e módulos necessários.

Esse processo é conhecido como linkedição.

Somente após a linkedição surge o módulo executável que poderá ser gravado em uma load library.

Nesta terceira parte, vamos acompanhar essa transformação passo a passo.

Prepare o café, abra o SDSF e venha entender o que realmente acontece entre o fonte COBOL e o módulo executável.

---

1. O que significa compilar?

Compilar significa transformar o código-fonte escrito pelo programador em código objeto.

O fluxo mais simples é:

Código-fonte COBOL
          ↓
Compilador COBOL
          ↓
Código objeto

O código-fonte é legível para seres humanos treinados em COBOL.

Exemplo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. PGMCALC.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-VALOR-A           PIC S9(09) COMP.
       01  WS-VALOR-B           PIC S9(09) COMP.
       01  WS-TOTAL             PIC S9(09) COMP.

       PROCEDURE DIVISION.

           MOVE 100 TO WS-VALOR-A
           MOVE 250 TO WS-VALOR-B

           COMPUTE WS-TOTAL =
                   WS-VALOR-A + WS-VALOR-B

           DISPLAY 'TOTAL: ' WS-TOTAL

           STOP RUN.

A CPU do IBM Z não executa diretamente instruções como:

MOVE
COMPUTE
DISPLAY
STOP RUN

Essas instruções precisam ser transformadas em instruções de máquina compatíveis com a arquitetura do processador.

O compilador realiza essa conversão.

---

2. O compilador faz muito mais do que traduzir

Muitos iniciantes imaginam que o compilador apenas troca comandos COBOL por instruções de máquina.

Na realidade, ele executa várias análises.

Entre elas:

• verificação de sintaxe;

• validação de nomes;

• análise de tipos de dados;

• cálculo de tamanhos;

• validação de referências;

• verificação de parágrafos;

• resolução de campos;

• tratamento de copybooks;

• validação de arquivos;

• análise de expressões;

• geração de código;

• otimização;

• emissão de mensagens;

• criação de listagens;

• produção do módulo objeto.

Considere:

       01  WS-NOME              PIC X(40).
       01  WS-IDADE             PIC 9(03).

           MOVE WS-NOME TO WS-IDADE.

O compilador poderá identificar que um campo alfanumérico está sendo movido para um campo numérico.

Dependendo das opções e do conteúdo, isso poderá produzir:

• advertência;

• conversão;

• risco de erro em execução;

• mensagem de diagnóstico.

O compilador é, portanto, uma espécie de auditor técnico do programa.

---

3. O compilador precisa conhecer os copybooks

Na primeira parte, vimos que um programa pode utilizar:

       COPY CPYCLI01.

O compilador precisa localizar esse copybook.

Normalmente, as bibliotecas são indicadas por meio de um DD statement como:

//SYSLIB DD DISP=SHR,
//          DSN=EMPRESA.SISTEMA.COPYLIB

Pode haver várias bibliotecas:

//SYSLIB DD DISP=SHR,
//          DSN=EMPRESA.SISTEMA.COPYLIB
//       DD DISP=SHR,
//          DSN=EMPRESA.CORPORATIVO.COPYLIB
//       DD DISP=SHR,
//          DSN=FORNECEDOR.PRODUTO.COPYLIB

A ordem pode ser importante.

Se duas bibliotecas possuírem um membro com o mesmo nome, o primeiro encontrado poderá ser utilizado.

Imagine:

EMPRESA.TESTE.COPYLIB(CPYCLI01)
EMPRESA.PRODUCAO.COPYLIB(CPYCLI01)

Se a biblioteca errada estiver antes na concatenação, o programa poderá ser compilado com uma versão incorreta do layout.

O fonte estará correto.

O copybook existirá.

A compilação poderá terminar com sucesso.

Mesmo assim, o programa poderá utilizar uma estrutura incompatível.

Essa é uma das razões pelas quais o processo de compilação precisa ser controlado.

---

4. O compilador trabalha com opções

O comportamento do compilador pode ser alterado por opções.

Essas opções podem controlar:

• geração de listagem;

• otimização;

• tratamento de chamadas;

• compatibilidade;

• informações de depuração;

• aritmética;

• encoding;

• migração;

• geração de dados de teste;

• integração com CICS;

• integração com Db2;

• tratamento de warnings.

Exemplos de opções frequentemente encontradas em ambientes COBOL incluem conceitos como:

OPTIMIZE
LIST
MAP
XREF
SSRANGE
NUMCHECK
RENT
DYNAM
NODYNAM
TEST
ARCH
TUNE

Os nomes e efeitos exatos dependem da versão e da configuração do Enterprise COBOL.

O importante para o Padawan é entender:

O mesmo fonte pode gerar executáveis diferentes conforme as opções utilizadas.

---

5. Otimização

O compilador pode reorganizar ou melhorar o código gerado para produzir maior eficiência.

Considere:

           MULTIPLY WS-VALOR BY 2
               GIVING WS-RESULTADO.

O programador descreve a regra.

O compilador decide como representá-la em instruções de máquina.

Com opções de otimização, ele pode:

• reduzir instruções;

• eliminar operações desnecessárias;

• reorganizar processamento;

• utilizar recursos modernos da arquitetura;

• melhorar acesso a dados;

• produzir código mais eficiente.

Porém, níveis elevados de otimização podem tornar a depuração mais complexa.

O código gerado pode não seguir exatamente a ordem visual do fonte.

Por isso, ambientes de desenvolvimento e produção podem utilizar estratégias diferentes.

---

6. Opções de diagnóstico

Opções como validação de subscritos, verificação numérica e informações de teste podem ajudar a detectar problemas.

Imagine:

       01  TABELA-VALORES.
           05 ITEM-VALOR OCCURS 10 TIMES
                PIC 9(05).

       01  WS-INDICE             PIC 9(02).

           MOVE 15 TO WS-INDICE
           MOVE 100 TO ITEM-VALOR(WS-INDICE).

A tabela possui dez elementos.

O programa tenta acessar a posição quinze.

Sem verificações adequadas, o programa pode sobrescrever outra área de memória.

Com opções de runtime e compilação apropriadas, esse erro pode ser detectado.

Entretanto, verificações adicionais também podem consumir mais processamento.

Em produção, as empresas equilibram:

Segurança
Desempenho
Diagnóstico
Governança

---

7. O que é o código objeto?

O código objeto é o resultado principal da compilação.

Ele contém instruções de máquina e informações necessárias para a próxima fase.

Porém, ele ainda pode possuir referências externas.

Exemplo:

           CALL 'PGMVALID'
                USING WS-CPF
                      WS-RETORNO.

O compilador sabe que o programa possui uma referência a PGMVALID.

Dependendo do tipo de chamada e das opções utilizadas, essa referência poderá ser resolvida durante a linkedição ou durante a execução.

O objeto pode conter:

• instruções de máquina;

• áreas;

• referências externas;

• símbolos;

• informações de relocação;

• pontos de entrada;

• dados necessários ao Binder.

Podemos pensar assim:

Código objeto = programa parcialmente montado

Ele já deixou de ser fonte, mas ainda pode não estar pronto para ser carregado.

---

8. O objeto não é o executável final

Essa é uma das maiores confusões entre iniciantes.

Depois da compilação, o programa ainda pode precisar de:

• interfaces CICS;

• interfaces Db2;

• interfaces IMS;

• módulos Adabas;

• rotinas estáticas;

• bibliotecas de suporte;

• módulos de linguagem;

• pontos de entrada;

• resolução de referências.

Por isso, o processo continua:

Código objeto
      ↓
Binder
      ↓
Módulo executável

A compilação produz peças.

A linkedição reúne as peças.

---

9. O que é linkedição?

Linkedição é o processo de combinar o código objeto com outros módulos e referências para criar uma unidade executável.

Em inglês, você poderá encontrar termos como:

Link-edit
Linkage edition
Binding

Em ambientes modernos, a ferramenta principal é o Binder do z/OS.

Em documentações antigas, também aparece o termo Linkage Editor.

Podemos representar assim:

Objeto do programa principal
           +
Rotinas externas
           +
Interfaces de subsistemas
           +
Módulos estáticos
           +
Pontos de entrada
           ↓
Binder
           ↓
Módulo executável

---

10. O Binder do z/OS

O Binder é responsável por organizar e combinar os módulos recebidos.

Ele pode:

• resolver referências externas;

• incluir módulos;

• definir pontos de entrada;

• organizar seções;

• produzir mapas;

• gerar referências cruzadas;

• identificar símbolos não resolvidos;

• criar load modules;

• criar program objects;

• gravar o resultado em uma biblioteca executável.

Um JCL tradicional pode utilizar:

//LKED EXEC PGM=IEWL

O nome IEWL possui origem histórica no Linkage Editor.

Mesmo com a evolução para o Binder, ele continua aparecendo em muitos JCLs e procedures.

---

11. Um exemplo simples de compilação

Um JCL conceitual de compilação poderia ser:

//COMPILA  JOB (1234),'BELLACOSA',
//             CLASS=A,
//             MSGCLASS=X,
//             NOTIFY=&SYSUID
//*
//COBOL    EXEC PGM=IGYCRCTL
//STEPLIB  DD DISP=SHR,
//            DSN=IGY.V6R5M0.SIGYCOMP
//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))

Esse exemplo é simplificado.

O compilador lê o fonte em:

//SYSIN

Procura copybooks em:

//SYSLIB

Produz o objeto em:

//SYSLIN

Gera a listagem em:

//SYSPRINT

O dataset:

&&OBJ

é temporário.

Os dois sinais de && indicam um dataset temporário associado ao job.

O parâmetro:

DISP=(NEW,PASS)

significa que ele é criado nessa etapa e passado para a próxima.

---

12. A etapa de linkedição

Depois da compilação:

//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 meio de:

//SYSLIN

O resultado é gravado em:

//SYSLMOD

Nesse exemplo:

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

será o módulo executável.

A saída de diagnóstico será enviada para:

//SYSPRINT

---

13. O papel de SYSLIN e SYSLMOD

Esses DDNAMEs aparecem frequentemente em processos de linkedição.

SYSLIN

Contém a entrada para o Binder.

Pode incluir:

• objetos;

• control statements;

• referências;

• comandos INCLUDE;

• instruções de entrada.

SYSLMOD

Define onde o módulo executável será gravado.

Exemplo:

//SYSLMOD DD DISP=SHR,
//           DSN=EMPRESA.TESTE.LOADLIB(PGMCLI01)

Podemos resumir:

SYSLIN  → entra objeto
SYSLMOD → sai executável

---

14. Comandos do Binder

O Binder pode receber comandos de controle.

Exemplo conceitual:

ENTRY PGMCLI01
NAME PGMCLI01(R)

O comando ENTRY pode definir o ponto inicial do programa.

O comando NAME pode indicar o nome do módulo que será criado.

Também podem existir comandos como:

INCLUDE
ALIAS
REPLACE
RENAME
SETCODE

A utilização varia conforme o processo e a arquitetura da aplicação.

Em muitas empresas, esses comandos ficam escondidos dentro de procedures ou ferramentas de build.

---

15. O que é ponto de entrada?

O ponto de entrada representa o local pelo qual a execução começa dentro do módulo.

Em um programa COBOL simples, isso normalmente é definido automaticamente.

Entretanto, módulos mais complexos podem possuir:

• mais de um ponto de entrada;

• aliases;

• rotinas reutilizáveis;

• estruturas compostas;

• entry points adicionais.

Em COBOL, também existe a instrução:

       ENTRY 'OUTROENT'
           USING AREA-DADOS.

Esse recurso cria pontos adicionais de entrada em um programa.

Seu uso deve ser controlado, pois pode tornar a manutenção mais complexa.

---

16. Chamadas estáticas

Considere:

           CALL 'PGMVALID'
                USING WS-DADOS.

Em uma chamada estática, o módulo chamado é resolvido durante a linkedição.

O Binder precisa localizar PGMVALID.

Ele poderá incorporá-lo ou ligá-lo ao módulo principal.

Fluxo:

Objeto PGMCLI01
       +
Objeto ou módulo PGMVALID
       ↓
Binder
       ↓
Executável combinado

Vantagens da chamada estática:

• resolução antecipada;

• menor risco de programa não encontrado em runtime;

• controle sobre a versão ligada;

• menos busca dinâmica.

Desvantagens:

• alteração no subprograma pode exigir relinkedição;

• executável pode crescer;

• vários chamadores podem precisar ser atualizados;

• maior acoplamento entre módulos.

---

17. Chamadas dinâmicas

Em uma chamada dinâmica, o módulo é localizado durante a execução.

Exemplo com nome variável:

       01  WS-PROGRAMA          PIC X(08).

           MOVE 'PGMVALID' TO WS-PROGRAMA

           CALL WS-PROGRAMA
                USING WS-DADOS.

O nome está em uma variável.

Isso caracteriza uma chamada dinâmica.

Dependendo das opções do compilador, chamadas literais também podem ser tratadas dinamicamente.

O módulo não precisa ser incorporado ao chamador durante a linkedição.

Na execução, o sistema procurará PGMVALID nas bibliotecas disponíveis.

Vantagens:

• atualização independente;

• maior reutilização;

• executável principal menor;

• menor necessidade de relinkedição.

Desvantagens:

• o programa pode não ser encontrado;

• bibliotecas precisam estar corretas;

• versões incompatíveis podem causar falhas;

• o problema aparece somente em execução.

---

18. DYNAM e NODYNAM

Opções de compilação podem influenciar o tratamento das chamadas.

Conceitualmente:

DYNAM   → favorece chamadas dinâmicas
NODYNAM → permite resolução estática de chamadas literais

O comportamento exato depende da forma da chamada e das opções utilizadas.

Um iniciante não deve apenas decorar os nomes.

É melhor compreender a pergunta principal:

O módulo chamado será ligado agora ou procurado durante a execução?

Essa resposta influencia:

• tamanho do executável;

• implantação;

• dependências;

• manutenção;

• diagnóstico.

---

19. O que acontece quando uma referência não é resolvida?

Imagine que o programa possui:

           CALL 'PGMVALID'
                USING WS-DADOS.

O Binder espera localizar o módulo, mas ele não está nas bibliotecas informadas.

Pode ocorrer uma referência externa não resolvida.

O Binder poderá emitir mensagens indicando:

• símbolo não encontrado;

• módulo ausente;

• biblioteca incorreta;

• erro na resolução;

• ponto de entrada inexistente.

Dependendo das opções, o processo poderá:

• terminar com erro;

• gerar módulo incompleto;

• permitir execução com risco;

• impedir a gravação do executável.

Por isso, a listagem do Binder precisa ser analisada.

---

20. Bibliotecas de objetos e módulos

O processo pode utilizar bibliotecas como:

EMPRESA.SISTEMA.OBJLIB
EMPRESA.SISTEMA.LOADLIB
EMPRESA.COMUM.LOADLIB
PRODUTO.INTERFACE.LOADLIB

OBJLIB

Pode armazenar módulos objeto.

Nem todas as empresas mantêm objetos permanentemente.

Algumas utilizam datasets temporários.

LOADLIB

Armazena módulos executáveis.

Bibliotecas comuns

Podem conter:

• rotinas reutilizáveis;

• interfaces;

• subprogramas;

• componentes corporativos;

• módulos de fornecedores.

O Binder recebe essas bibliotecas por DD statements específicos, muitas vezes como:

//SYSLIB DD DISP=SHR,
//          DSN=EMPRESA.COMUM.LOADLIB

---

21. Load module e program object

Durante décadas, o termo tradicional foi load module.

Com a evolução do z/OS e das bibliotecas PDSE, tornou-se comum utilizar program objects.

Um iniciante poderá ouvir:

• load;

• load module;

• módulo de carga;

• program object;

• executável;

• membro da loadlib.

Embora existam diferenças técnicas de formato e capacidade, todos representam o mesmo conceito geral:

Um artefato preparado para ser localizado, carregado e executado.

O program object moderno pode suportar recursos que os antigos load modules não suportavam da mesma forma.

Porém, no cotidiano, muitos profissionais continuam chamando tudo simplesmente de “load”.

---

22. A load library

A load library é uma biblioteca que contém módulos executáveis.

Exemplo:

EMPRESA.SISTEMA.LOADLIB

Membros:

PGMCLI01
PGMCLI02
PGMCALC
PGMREL01
PGMVALID

Ao abrir essa biblioteca no ISPF, o conteúdo não será um fonte COBOL legível.

Ela contém estruturas binárias.

O programador normalmente não edita diretamente um load module.

A alteração correta é feita no fonte.

Depois disso, o programa é recompilado e linkedidado.

---

23. Fonte, objeto e load

É importante visualizar a diferença.

Fonte

EMPRESA.SISTEMA.COBOL(PGMCLI01)

Contém código COBOL.

Objeto

EMPRESA.SISTEMA.OBJLIB(PGMCLI01)

Contém o resultado intermediário da compilação.

Load

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

Contém o módulo executável.

O mesmo nome pode existir em bibliotecas diferentes.

Isso não significa que sejam o mesmo tipo de conteúdo.

---

24. O perigo de executar a versão errada

Imagine que o programador compile uma nova versão em:

EMPRESA.TESTE.LOADLIB(PGMCLI01)

Porém, o JCL de teste utiliza:

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

O job executará a versão antiga.

O programador poderá dizer:

“Minha alteração não funcionou.”

Na realidade, o programa correto nunca foi carregado.

Esse problema é extremamente comum.

Sempre verifique:

• onde o load foi gravado;

• qual biblioteca está no JCL;

• qual biblioteca está primeiro na concatenação;

• se existe outro membro com o mesmo nome;

• se o ambiente online carregou a nova versão.

---

25. Linkedição de programas CICS

Um programa CICS precisa ser preparado com as interfaces necessárias.

Historicamente, a linkedição poderia incluir módulos específicos do CICS.

Dependendo da arquitetura e versão, o processo pode utilizar stubs ou interfaces fornecidas pelo produto.

Além disso, o executável precisa ser disponibilizado em uma biblioteca acessível à região CICS.

Normalmente, encontramos referências a bibliotecas concatenadas na DFHRPL.

Fluxo simplificado:

Fonte CICS
    ↓
Tradução
    ↓
Compilação
    ↓
Linkedição com interfaces CICS
    ↓
Load library
    ↓
Biblioteca acessível ao CICS

Depois, o CICS precisa reconhecer ou atualizar o programa em execução.

Pode ser necessário utilizar recursos como:

• new copy;

• phase-in;

• atualização de definição;

• pipeline de deployment;

• refresh do programa.

---

26. Linkedição de programas Db2

Programas Db2 também utilizam interfaces de conexão.

Um programa batch Db2 pode ser linkedidado com componentes apropriados para o método de conexão utilizado.

Além disso, o DBRM precisa passar pelo BIND.

Portanto, existem dois resultados:

Load module COBOL
Package Db2

Os dois precisam estar compatíveis.

Podem ocorrer problemas como:

• load novo com package antigo;

• package novo com load antigo;

• collection incorreta;

• plano incorreto;

• versão incompatível;

• módulo em biblioteca errada.

Esse tipo de situação mostra por que a implantação precisa coordenar artefatos.

---

27. Linkedição de programas IMS

Programas IMS podem precisar de interfaces DL/I durante a linkedição.

O método exato varia conforme:

• tipo de região;

• forma de execução;

• ambiente IMS;

• linguagem;

• procedures da empresa.

O módulo executável também precisa ser chamado em conjunto com o PSB adequado.

Isso significa que a execução depende de:

Load module
PSB
PCBs
DBDs
Ambiente IMS

O load sozinho não representa toda a aplicação.

---

28. Linkedição de programas Adabas

Programas COBOL que acessam Adabas precisam das interfaces correspondentes.

Durante a linkedição, módulos de comunicação e bibliotecas fornecidas pelo ambiente podem ser incluídos ou referenciados.

Na execução, o programa utilizará essas interfaces para se comunicar com o Adabas Nucleus.

Assim como nos demais subsistemas:

Programa COBOL + interface especializada = acesso ao serviço

---

29. Procedures catalogadas

Em muitas empresas, o programador não escreve manualmente o JCL completo de compilação e linkedição.

Ele utiliza uma procedure catalogada.

Exemplo:

//COMPILA EXEC PROC=COBOLCL

Ou:

//COMPILA EXEC PROC=COB2CL

Ou:

//COMPILA EXEC PROC=COBCICS

A procedure pode esconder:

• tradução;

• pré-compilação;

• compilação;

• linkedição;

• BIND;

• bibliotecas;

• opções;

• datasets temporários;

• controles corporativos.

O Padawan vê uma única linha.

Por trás dela podem existir dezenas de etapas.

---

30. O que é uma procedure catalogada?

Uma procedure catalogada é um conjunto reutilizável de instruções JCL armazenado em uma biblioteca de procedures.

Exemplo conceitual:

SYS1.PROCLIB
EMPRESA.PROCLIB

Dentro dela:

COBOLCL
COBDB2
COBCICS
COBIMS

A procedure permite padronizar o processo.

Benefícios:

• evita duplicação;

• centraliza opções;

• facilita manutenção;

• reduz erros;

• garante bibliotecas corretas;

• padroniza retorno;

• integra ferramentas corporativas.

Porém, também pode esconder detalhes.

Por isso, o iniciante deve aprender a abrir e analisar a procedure.

---

31. Parâmetros simbólicos

Procedures podem utilizar parâmetros.

Exemplo conceitual:

//COMPILA EXEC COBOLCL,
//             MEMBER=PGMCLI01,
//             SRCLIB=EMPRESA.SISTEMA.COBOL,
//             LOADLIB=EMPRESA.SISTEMA.LOADLIB

Dentro da procedure, podem existir símbolos como:

&MEMBER
&SRCLIB
&LOADLIB

Quando o job é submetido, esses símbolos são substituídos.

Isso permite utilizar a mesma procedure para vários programas.

---

32. Compilação local, pipeline e ferramentas modernas

Nem todo processo moderno é iniciado manualmente por JCL.

Empresas podem utilizar:

• IBM Developer for z/OS;

• IBM Z Open Editor;

• VS Code;

• Git;

• Jenkins;

• IBM Dependency Based Build;

• zBuilder;

• UrbanCode Deploy;

• Endevor;

• ISPW;

• ferramentas internas;

• pipelines CI/CD.

O desenvolvedor altera o fonte e aciona um pipeline.

O pipeline pode:

1. detectar dependências;

2. identificar copybooks alterados;

3. traduzir CICS;

4. processar SQL;

5. compilar COBOL;

6. linkeditar;

7. executar testes;

8. gerar evidências;

9. promover artefatos;

10. implantar o load.

Mesmo com automação, os fundamentos continuam iguais.

A ferramenta não elimina as etapas.

Ela apenas as coordena.

---

33. Análise de impacto de copybook

Imagine que CPYCLI01 seja usado por cem programas.

Uma alteração foi realizada:

       05 CLI-LIMITE PIC S9(13)V99 COMP-3.

Antes:

       05 CLI-LIMITE PIC S9(11)V99 COMP-3.

Os programas dependentes podem precisar ser recompilados.

Uma ferramenta de build baseada em dependências pode identificar:

CPYCLI01 alterado
      ↓
PGMCLI01 afetado
PGMCLI02 afetado
PGMREL01 afetado
PGMCRD01 afetado

Esse processo evita que apenas um módulo seja recompilado enquanto outros continuam utilizando o layout antigo.

---

34. Return codes da compilação

Durante a compilação, o job pode terminar com códigos como:

RC=0000
RC=0004
RC=0008
RC=0012
RC=0016

Uma interpretação geral:

RC 0

Nenhum erro relevante foi encontrado.

RC 4

Foram geradas advertências.

O programa pode ter sido produzido, mas as mensagens precisam ser analisadas.

RC 8

Existem erros significativos.

Em muitos processos, a linkedição não deve continuar.

RC 12

Erros graves impediram a geração correta.

RC 16

Falha severa, problema estrutural ou impossibilidade de processamento.

Os significados exatos dependem da etapa e das mensagens.

Nunca utilize apenas o número como diagnóstico completo.

---

35. O perigo do RC 4

O programador pode pensar:

“RC 4 é normal.”

Às vezes, a advertência é realmente conhecida.

Mas um RC 4 pode indicar:

• campo não utilizado;

• conversão perigosa;

• valor truncado;

• incompatibilidade de tipo;

• comportamento obsoleto;

• opção ignorada;

• possível erro lógico;

• recurso que mudará em versões futuras.

Em sistemas críticos, advertências precisam ser classificadas.

O objetivo não é aceitar tudo nem rejeitar tudo.

O objetivo é compreender.

---

36. Return code do Binder

A linkedição também produz return code.

Problemas podem incluir:

• referência externa não resolvida;

• módulo ausente;

• biblioteca indisponível;

• símbolo duplicado;

• erro de ponto de entrada;

• espaço insuficiente;

• formato incompatível;

• opção inválida.

O Binder pode gerar o módulo mesmo com algumas advertências.

Porém, isso não significa que o executável esteja seguro.

Leia:

• mensagens;

• map;

• cross-reference;

• entry point;

• unresolved references;

• bibliotecas utilizadas.

---

37. MAP e XREF

Opções como:

MAP
XREF
LIST

podem gerar informações úteis.

MAP

Mostra o mapa do módulo.

Pode ajudar a entender:

• seções;

• tamanhos;

• endereços relativos;

• módulos incluídos;

• organização do executável.

XREF

Mostra referências cruzadas.

Ajuda a identificar:

• símbolos;

• definições;

• referências;

• módulos que fornecem determinados nomes.

Essas informações são valiosas na investigação de problemas de linkedição.

---

38. Erros de compilação mais comuns

Entre os erros frequentes:

• campo não definido;

• palavra reservada usada incorretamente;

• parágrafo inexistente;

• END-IF ausente;

• ponto final em posição incorreta;

• copybook não encontrado;

• PIC inválida;

• nível hierárquico incorreto;

• variável incompatível;

• arquivo sem definição adequada;

• SQL ou CICS não processado.

Exemplo:

           MOVE WS-VALOR TO WS-CAMPO-INEXISTENTE.

O compilador identifica a referência inexistente.

---

39. Erros de linkedição mais comuns

Entre os erros frequentes:

• subprograma estático ausente;

• biblioteca não concatenada;

• módulo com nome diferente;

• interface de subsistema ausente;

• símbolo externo não resolvido;

• entrada incorreta;

• módulo incompatível;

• control statements incorretos.

Exemplo:

           CALL 'PGMCALC'

Mas a biblioteca possui:

PGMCAL01

O nome não corresponde.

A resolução poderá falhar.

---

40. Erro de compilação não é erro de execução

É importante separar as fases.

Compilação

Analisa e traduz o fonte.

Linkedição

Monta o executável.

Carga

Localiza o módulo durante a execução.

Runtime

Executa a lógica e acessa dados.

Um problema pode ocorrer em qualquer uma dessas etapas.

Exemplo:

Fonte correto
Compilação RC 0
Linkedição RC 0
Execução S806

Nesse caso, o programa foi criado, mas o sistema não o encontrou na biblioteca de execução.

Outro exemplo:

Compilação RC 0
Linkedição RC 0
Programa executado
FILE STATUS 35

O executável está correto, mas o arquivo não foi localizado ou aberto.

Diagnóstico correto começa pela identificação da fase.

---

41. O Language Environment

Programas COBOL modernos no z/OS normalmente executam sob o Language Environment.

O Language Environment fornece serviços comuns para linguagens como:

• COBOL;

• PL/I;

• C;

• C++.

Ele participa de:

• inicialização;

• gerenciamento de memória;

• parâmetros;

• tratamento de condições;

• mensagens;

• datas;

• conversões;

• finalização;

• dumps;

• interoperabilidade.

Durante a linkedição e execução, o programa pode depender de componentes do Language Environment.

Mensagens iniciadas por:

CEE

frequentemente estão relacionadas a esse ambiente.

---

42. RENT e programas reentrantes

Programas online, especialmente CICS, costumam precisar ser reentrantes.

Um programa reentrante pode ser compartilhado com segurança por várias tasks, desde que não modifique indevidamente áreas comuns de código ou dados.

A opção:

RENT

está associada à geração de código reentrante.

Isso é importante porque o CICS pode atender milhares de transações concorrentes.

O código pode ser compartilhado, enquanto cada task possui suas áreas de trabalho apropriadas.

Um programa não reentrante pode causar:

• corrupção de dados;

• interferência entre usuários;

• resultados imprevisíveis;

• falhas de integridade.

---

43. O perigo de armazenar estado no lugar errado

Imagine um programa CICS que mantém dados mutáveis em uma área compartilhada de forma incorreta.

Duas tasks podem executar o mesmo módulo simultaneamente.

A task A altera uma informação.

A task B enxerga ou sobrescreve essa mesma informação.

O resultado pode ser uma mistura de dados entre transações.

Por isso, programas online utilizam estruturas como:

• COMMAREA;

• channels e containers;

• working-storage gerenciado adequadamente;

• áreas fornecidas pelo CICS;

• TSQ;

• contextos transacionais.

A reentrância não é apenas uma opção técnica.

É uma garantia de convivência segura entre múltiplas execuções.

---

44. Versionamento do load

Em ambientes corporativos, o load module precisa ser controlado.

Perguntas importantes:

• Qual fonte gerou o load?

• Qual versão do copybook foi usada?

• Qual compilador foi utilizado?

• Quais opções foram aplicadas?

• Qual pipeline gerou o módulo?

• Qual commit corresponde ao executável?

• Qual package Db2 foi associado?

• Quando o load foi implantado?

• Quem aprovou a promoção?

Sem rastreabilidade, o executável vira uma caixa-preta.

---

45. Programa compilado não significa programa testado

Uma compilação com RC 0 prova apenas que o compilador conseguiu processar o fonte.

Ela não prova que:

• a regra de negócio está correta;

• os dados foram tratados corretamente;

• o SQL possui bom desempenho;

• o arquivo está definido corretamente;

• a transação CICS funciona;

• o programa IMS utiliza o segmento correto;

• o código Adabas trata todos os retornos;

• o módulo não causa abend;

• o programa atende ao requisito.

Compilação é uma etapa de validação técnica.

Teste é outra disciplina.

---

46. Um fluxo moderno de build

Um pipeline moderno pode executar:

Checkout do fonte
       ↓
Análise de dependências
       ↓
Expansão e localização de copybooks
       ↓
Tradução CICS
       ↓
Processamento Db2
       ↓
Compilação COBOL
       ↓
Linkedição
       ↓
BIND package
       ↓
Testes unitários
       ↓
Análise de qualidade
       ↓
Empacotamento
       ↓
Implantação

Esse fluxo parece moderno, mas continua baseado nos mesmos fundamentos utilizados há décadas.

O que mudou foi o nível de automação.

---

47. Exemplo completo do caminho até o load

Imagine o programa:

PGMCLI01

Ele utiliza:

CPYCLI01
EXEC CICS
EXEC SQL
CALL PGMVALID

O processo poderá ser:

1. Ler PGMCLI01
2. Localizar CPYCLI01
3. Traduzir EXEC CICS
4. Processar EXEC SQL
5. Gerar DBRM
6. Compilar o fonte preparado
7. Gerar objeto PGMCLI01
8. Localizar PGMVALID
9. Incluir interfaces CICS e Db2
10. Executar o Binder
11. Gravar PGMCLI01 na LOADLIB
12. Executar BIND do DBRM
13. Criar package Db2

Ao final:

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

e:

Package Db2 de PGMCLI01

estarão prontos para a próxima fase.

---

48. Checklist do Programador COBOL Padawan

Antes de declarar que o programa está pronto, verifique:

• O fonte correto foi compilado?

• Os copybooks corretos foram utilizados?

• A biblioteca de copybooks estava na ordem certa?

• Houve tradução CICS?

• O SQL foi processado?

• O DBRM foi gerado?

• O package foi criado?

• O compilador terminou com qual RC?

• Existem warnings?

• O Binder resolveu todas as referências?

• O load foi gravado na biblioteca correta?

• As chamadas são estáticas ou dinâmicas?

• Os módulos chamados estão disponíveis?

• A versão do load corresponde ao fonte?

• Os testes foram executados?

• A implantação utilizará a mesma load library?

Esse checklist evita muitos problemas que parecem misteriosos.

---

49. O grande mapa mental da Parte III

Podemos resumir toda a transformação:

Fonte preparado
      ↓
Compilador COBOL
      ↓
Validação
      ↓
Geração de instruções
      ↓
Código objeto
      ↓
Binder
      ↓
Resolução de referências
      ↓
Inclusão de módulos
      ↓
Definição do ponto de entrada
      ↓
Load module ou program object
      ↓
Load library

Em paralelo, quando houver Db2:

DBRM
  ↓
BIND
  ↓
Package

---

50. Uma analogia com uma fábrica

Imagine uma fábrica de automóveis.

O código-fonte é o projeto do veículo.

Os copybooks são padrões de componentes:

• medidas;

• conectores;

• peças;

• encaixes.

O compilador transforma o projeto em peças reais.

Ele produz:

• motor;

• chassis;

• painel;

• sistemas de controle.

Entretanto, as peças ainda estão separadas.

O Binder é a linha de montagem.

Ele reúne:

• objeto principal;

• módulos externos;

• interfaces;

• componentes;

• pontos de entrada.

O resultado é o veículo montado.

A load library é o pátio onde os veículos prontos ficam armazenados.

Porém, o carro ainda não saiu do pátio.

Ele ainda precisa ser localizado, ligado e colocado na estrada.

Essa será a missão do próximo capítulo.

---

51. Conselhos do Mestre Bellacosa

Nunca trate a compilação como um botão misterioso.

Abra as listagens.

Leia as mensagens.

Entenda a procedure.

Descubra:

• qual compilador foi utilizado;

• quais opções foram aplicadas;

• quais bibliotecas foram concatenadas;

• quais copybooks foram encontrados;

• quais módulos foram incluídos;

• onde o objeto foi gravado;

• onde o load foi criado;

• quais referências foram resolvidas;

• quais warnings foram emitidos.

O profissional que entende o processo de build investiga problemas com muito mais precisão.

Ele não diz apenas:

“A compilação falhou.”

Ele diz:

“O pré-processamento terminou corretamente, mas o Binder não resolveu o módulo estático porque a biblioteca de interfaces não estava na concatenação de SYSLIB.”

Esse é o tipo de compreensão que transforma um Padawan em especialista.

---

Conclusão

A compilação é o processo que transforma o código-fonte COBOL em código objeto.

Durante essa etapa, o compilador verifica sintaxe, campos, tipos de dados, referências, estruturas, opções e dependências.

O código objeto já contém instruções de máquina, mas ainda pode possuir referências externas.

Por isso, ele precisa passar pelo Binder.

A linkedição combina o objeto com módulos, interfaces e rotinas necessárias, resolvendo referências e criando um módulo executável.

Esse resultado é armazenado em uma load library.

Também aprendemos que chamadas podem ser estáticas ou dinâmicas.

Chamadas estáticas são resolvidas durante a linkedição.

Chamadas dinâmicas são localizadas durante a execução.

Vimos ainda que CICS, Db2, IMS e Adabas podem exigir interfaces específicas, e que o programa Db2 precisa coordenar dois artefatos fundamentais:

Load module
Package Db2

Ao final dessa etapa, o programa finalmente existe como executável.

Mas ele ainda está parado dentro de uma biblioteca.

Ele não abriu arquivos.

Não leu registros.

Não consultou tabelas.

Não consumiu CPU.

Não produziu relatórios.

A última etapa da jornada está prestes a começar.

No próximo capítulo

Na Parte IV — Da Load Library à CPU, vamos acompanhar o módulo durante a execução.

Veremos passo a passo:

• como o JCL solicita a execução;

• como a STEPLIB localiza o programa;

• como QSAM e VSAM são conectados por DDNAME;

• como o JES2 recebe e organiza o job;

• o que é spool;

• como o initiator inicia o processamento;

• como o loader coloca o programa na memória;

• como WLM e dispatcher participam;

• como a CPU executa as instruções;

• por que tempo de CPU é diferente de tempo decorrido;

• como programas CICS, Db2, IMS e Adabas executam no ambiente real.

Prepare a quarta xícara de café.

O programa já nasceu, foi traduzido, compilado e linkedidado.

Agora chegou o momento de fazê-lo trabalhar.

☕

“O Padawan acredita que a compilação cria o programa. O especialista sabe que a compilação cria as peças, a linkedição monta a máquina e a execução provará se toda a engenharia realmente funciona.”

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.

CASO: COBOL-2022-EXEC EVIDÊNCIAS: 05 ARTIGOS AMBIENTE: IBM Z / z/OS STATUS: ARQUIVO ABERTO

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.

Arquivos de evidências

↓ Consultar índice rastreável

Evidência selecionada Parte I — Código-fonte, bibliotecas e copybooks

Abrir original ↗

Processando evidência digital...

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.

COBOL código-fonte copybook SYSLIB IBM Z

Índice completo do dossiê COBOL

Acesse diretamente cada artigo da série “Da Compilação à Execução de um Programa COBOL”. Os links abaixo são HTML convencionais, legíveis por leitores, navegadores, Google, Bing e outros mecanismos de busca.

PARTE I · JANEIRO DE 2022 O nascimento do programa COBOL: código-fonte e copybooks Bibliotecas de fontes, COPY, CALL, layouts compartilhados, contratos de dados e localização de copybooks por SYSLIB. PARTE II · FEVEREIRO DE 2022 CICS, Db2, IMS e Adabas: o código antes da compilação Tradução CICS, processamento de SQL, DBRM, package Db2, chamadas DL/I, control blocks e serviços de subsistemas. PARTE III · MARÇO DE 2022 Compilação, linkedição, Binder e load library Código objeto, referências externas, chamadas estáticas e dinâmicas, program objects, return codes e bibliotecas de carga. PARTE IV · ABRIL DE 2022 Da load library à CPU: JCL, JES2, QSAM e VSAM STEPLIB, DDNAME, datasets, FILE STATUS, spool, initiator, loader, address space, dispatcher, WLM e processamento na CPU. DOSSIÊ MESTRE · MAIO DE 2022 Da Compilação à Execução de um Programa COBOL — série completa Visão integrada da jornada: regra de negócio, fonte, copybooks, tradutores, compilador, Binder, load module, JCL, JES2, memória, CPU, arquivos, subsistemas e resultados.

Bellacosa Mainframe Forensic Lab · Nenhum byte é inocente até que os logs provem o contrário.