Translate

Mostrar mensagens com a etiqueta Binder. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Binder. Mostrar todas as mensagens

quinta-feira, 2 de maio de 2019

☕💥 A Jornada do Padawan COBOL – Parte 5 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o call em cobol parte V

☕💥 A Jornada do Padawan COBOL – Parte 5

Desvendando o Universo dos CALLs no Mainframe

Binder, Link-Edit, FETCH, CANCEL, Program Objects, DLLs, LPA, LINKLIST e os Segredos dos Mestres do z/OS

Ou como descobrir que um CALL pode custar microssegundos, megabytes e algumas noites de sono se você não entender o que acontece depois do compilador

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que COBOL não gera executáveis

Até agora aprendemos:

✔ Static CALL

✔ Dynamic CALL

✔ By Reference

✔ Reentrância

✔ LE

✔ Heap

✔ Stack

✔ CEEDUMP

Mas existe uma pergunta importante.

Quando fazemos:

CALL 'VALIDA01'

Como exatamente o z/OS encontra este programa?

Onde ele mora?

Quem o carrega?

Quem o remove?

Quem o deixa residente?

Prepare outro café.

Hoje vamos conhecer o Binder.


O Binder

Antigamente chamávamos de:

Link Edit

Linkage Editor

IEWL

Hoje chamamos simplesmente de:

Binder


Ele é o responsável por transformar:

Objeto

em

Programa executável


Visualmente

COBOL Source

↓

IGYCRCTL

↓

Object Module

↓

Binder

↓

Program Object

↓

PDMLIB

O que o Binder faz

Resolve símbolos

Resolve CALL estático

Organiza seções

Cria aliases

Define AMODE

Define RMODE

Otimiza carregamento


Static CALL revisitado

Exemplo

CALL 'CPFVAL'

Binder procura:

CPFVAL

Achou.

Inclui.

Executável cresce.


Visualmente


MAIN


+

CPFVAL


+

JUROS


+

PIX


=


MAINLOAD


Dynamic CALL

Binder ignora.

Não liga.

Não participa.


Em execução.

Sistema procura.


Onde procura?

STEPLIB

Primeiro.


JOBLIB

Depois.


TASKLIB


LPA


LINKLIST


LPDB

Dependendo ambiente


Fluxo


CALL CPFVAL


↓

STEPLIB


↓

JOBLIB


↓

LPA


↓

LINKLIST


↓

Achou


↓

Carrega


↓

Executa


Quanto custa?

Cada busca.

CPU.

I/O.

Tempo.


Pouco?

Sim.

Milhões de vezes?

Muito.


O segredo da LPA

Link Pack Area


Área compartilhada.


Programa carregado

uma vez.


Usado por todos.


Visualmente


LPA


CPFVAL



CLIENTE A


CLIENTE B


CLIENTE C


CLIENTE D


Excelente.


Quando usar?

Rotinas muito chamadas.

Segurança.

Conversão.

Data.

Utilitários.


FETCH

Poucos usam.

Poucos conhecem.

Muito poderoso.


Exemplo

CALL 'IGZCFCC'

Internamente.

Faz FETCH.


FETCH significa

Pré-carregar.


Antes da execução.


Benefício

Evita primeira carga.

Reduz latência.


CANCEL

Um comando subestimado.


Exemplo

CALL WS-PGM


...


CANCEL WS-PGM

O que faz?

Remove programa da memória.


Por que usar?

Liberar storage.

Reinicializar estado.


Exemplo

Subprograma mantém cache.

Quer limpar.

CANCEL 'CACHE001'

Nova chamada.

Programa recarregado.


Cuidado

CANCEL excessivo

mata performance.


DLL no zOS

Sim.

Existe.


Dynamic Link Library.


Program Objects.


LE suporta.


Exemplo

C

COBOL

PLI

Assembler

Compartilhando.


Program Objects

Evolução do antigo Load Module.


Vantagens

Maior tamanho

AMODE 64

Melhor performance

Mais símbolos

Debug


IBM recomenda.

Sempre.


AMODE

Já vimos.

Mas Binder controla.


Exemplo

AMODE(31)


RMODE(ANY)

RMODE

Onde carregar.


RMODE 24

Baixa memória.


RMODE ANY

Qualquer lugar.


Mais flexível.


Alias

Binder pode criar.


Exemplo

Programa

CLIENTE01

Alias

CL001

Mesmo executável.

Dois nomes.


Problemas clássicos

S806

Programa não encontrado.


Verificar

STEPLIB

LPA

LINKLIST

Binder


S0C1

Módulo inválido.


Compilação errada.


U4087

LE.


S878

Sem memória.


Como descobrir

LISTLOAD

AMBLIST

IEWL

IPCS

SDSF


AMBLIST

Ferramenta maravilhosa.

Pouco utilizada.


Permite ver

AMODE

RMODE

Alias

Entradas

Tamanho


Exemplo

AMBLIST LISTIDR

Dica Bellacosa

Sempre guardar map.


Compile

LIST


OFFSET


MAP

Futuro você agradece.


Microbenchmark Jedi

Método

Tempo

Static CALL

0,8 us

Dynamic

2 us

FETCH

1 us

LPA

0,5 us

CANCEL frequente

8 us


Easter Egg Mainframe

Existe em muitos bancos.

Programa chamado.

GENERICA

Dentro.

EVALUATE WS-TIPO


WHEN 001


CALL P001


WHEN 002


CALL P002


WHEN 003


CALL P003


...


WHEN 999


CALL P999


END-EVALUATE

Mais de 900 programas.


Autor

Aposentado.

Documentação

Nenhuma.


Produção

Executa bilhões.

Diariamente.


Ninguém toca.


Conhecido pelos veteranos como:

A Biblioteca de Alexandria do Mainframe™


Checklist Jedi do Binder

✅ Static apenas quando necessário

✅ Dynamic para produtos

✅ Evitar CANCEL excessivo

✅ Preferir Program Objects

✅ Verificar AMODE

✅ Verificar RMODE

✅ Utilizar LPA

✅ Medir CPU

✅ Guardar MAP

✅ Gerar OFFSET

✅ Conhecer AMBLIST

✅ Conhecer Binder


A Filosofia Jedi do CALL – Parte 5

O Padawan iniciante acredita:

O compilador cria o executável.

O desenvolvedor intermediário pensa:

O Binder junta módulos.

O Mestre Mainframe entende:

O Binder é um arquiteto invisível. Ele decide onde o programa viverá, como será carregado, quem poderá compartilhá-lo, quanto storage consumirá e quantos microssegundos serão economizados em milhões de transações.

E é exatamente por isso que alguns arquitetos IBM Z conseguem olhar para um simples:

CALL 'SUBPGM'

E enxergar imediatamente:

  • Binder

  • Program Objects

  • LPA

  • RMODE

  • AMODE

  • FETCH

  • CANCEL

  • LE

  • CPU

  • Storage

  • Cache

  • Concurrency

  • Escalabilidade

Porque no universo do Mainframe, um CALL nunca é apenas um CALL.

É uma decisão de arquitetura que pode continuar impactando sistemas críticos por décadas.


Na Parte 6, o Padawan poderá explorar o nível Mestre: CICS LINK/XCTL, COMMAREA, Channels & Containers, z/OS Connect, APIs REST, Java, JNI, Metal C, MQ, zIIP, SMF 110, Strobe, APA e como os arquitetos modernos integram COBOL com microsserviços e nuvem.


sábado, 28 de dezembro de 2013

☕🔥 ABEND S806 — O “PROGRAMA FANTASMA” DO z/OS

 

Bellacosa Mainframe e o Abend S806

☕🔥 ABEND S806 — O “PROGRAMA FANTASMA” DO z/OS

Quando o Mainframe Diz:

“EU NÃO ENCONTREI O QUE VOCÊ MANDOU EXECUTAR.”

Se existe um ABEND que já fez TODO programador COBOL Junior Padawan olhar para o JCL em silêncio absoluto…

é o lendário:

🚨 S806

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S806

ou:

CSV028I ABEND806-04 JOBNAME STEP01
PROGRAM PROGXYZ NOT FOUND

ou ainda:

IEC130I PROGRAM NOT FOUND

E então começa a crise existencial:

“MAS O PROGRAMA EXISTE!”
“EU COMPILEI!”
“FUNCIONAVA ONTEM!”
“O LOADLIB SUMIU?”
“O z/OS ESTÁ ME GASLIGHTEANDO?”

☕ Respira.

Porque o S806 é um dos ABENDs MAIS CLÁSSICOS da história do mainframe.

E um dos mais importantes para aprender:

JCL

LOADLIB

STEPLIB

LINKLIST

BINDER

EXEC PGM

load modules


🔥 O QUE É O S806?

O S806 é um:

🚨 PROGRAM NOT FOUND

Traduzindo:

O z/OS NÃO CONSEGUIU ENCONTRAR O PROGRAMA EXECUTÁVEL.


☕ A FILOSOFIA DO S806

Seu JCL disse:

//STEP1 EXEC PGM=COBPROG

O z/OS respondeu:

❌ “NÃO EXISTE NENHUM EXECUTÁVEL COM ESSE NOME NOS LUGARES ONDE PROCUREI.”


🔥 O QUE O z/OS FAZ QUANDO VÊ EXEC PGM=

Fluxo real:

EXEC PGM=PROG1
 ↓
Procurar módulo
 ↓
STEPLIB
 ↓
JOBLIB
 ↓
LNKLST
 ↓
SYS1.LINKLIB
 ↓
Encontrou?

Se NÃO:

💥 S806


☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um aeroporto.

O sistema anuncia:

“CHAMEM O PILOTO DO VOO.”

Mas:

  • piloto não apareceu

  • nome errado

  • terminal errado

  • aeroporto errado

  • piloto nem existe

O voo nunca sai.

Isso é o:

☠️ S806


🔥 O MAIOR SEGREDO

S806 NÃO significa:

“source COBOL não existe.”

Significa:

o LOAD MODULE executável não foi encontrado.


☕ SOURCE ≠ EXECUTÁVEL

Isso traumatiza juniors.

Você pode ter:

✅ source COBOL
✅ compile OK

Mas sem:

LINK-EDIT/BINDER

não existe executável.


🔥 O MAIOR VILÃO DO S806

🚨 STEPLIB ERRADA

O rei absoluto.


☕ EXEMPLO CLÁSSICO

 //STEPLIB DD DSN=EMPRESA.TEST.LOAD,DISP=SHR

Mas o programa está em:

EMPRESA.PROD.LOAD

Resultado:

💥 S806


🔥 O ERRO MAIS HUMANO DA HISTÓRIA

//STEP1 EXEC PGM=COBPRG1

Mas o member real é:

COBPROG1

Faltou:

O

Resultado:

☠️ S806


☕ O MAINFRAME NÃO “ADIVINHA”

No z/OS:

nome precisa ser EXATO.


🔥 O S806 E O BINDER

Aqui nasce o verdadeiro conhecimento Jedi.


☕ O QUE É O BINDER?

Ferramenta que cria:

LOAD MODULES

Executáveis do z/OS.


🔥 FLUXO REAL COBOL

SOURCE COBOL
 ↓
COMPILER
 ↓
OBJETO
 ↓
BINDER/LINK-EDIT
 ↓
LOAD MODULE
 ↓
EXECUÇÃO

Se faltar binder:

💥 S806


☕ O ERRO CLÁSSICO DO PADAWAN

“Compilei com sucesso.”

Mas esqueceu:

LINK-EDIT


🔥 O S806 E O FTP ASCII

Lenda urbana real.

Load module transferido em:

ASCII

ao invés de:

BINARY

O executável vira lixo hexadecimal.

Às vezes:

  • S806

  • S0C1

  • S0C4

dependendo do dano.


☕ O S806 E O CALL

Outro clássico COBOL.

CALL 'CALCPGM'

Mas:

CALCPGM não existe na loadlib

Resultado:

💥 S806


🔥 O CALL DINÂMICO MALDITO

CALL WS-PGM

Mas:

WS-PGM = 'ABC123'

e esse módulo não existe.


☕ O S806 E O CICS

No CICS normalmente aparece como:

🚨 PGMIDERR

ou:

AEI0

ASRA

dependendo do cenário.


🔥 O S806 E O DB2

Outro clássico sombrio.

Programa depende de runtime DB2:

DSNHLI

ou módulos LE.

STEPLIB errada?

☠️ caos.


☕ COMO INVESTIGAR O S806 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O PROGRAMA

Mensagem:

CSV028I ABEND806-04 PROGRAM PROGXYZ NOT FOUND

Suspeito identificado.


✅ PASSO 2 — VERIFIQUE STEPLIB

Veja:

//STEPLIB DD DSN=...

Confirme:

  • dataset correto

  • DISP=SHR

  • biblioteca existe


✅ PASSO 3 — USE ISPF 3.4

Procure o member.

Existe?

PROGXYZ

✅ PASSO 4 — CONFIRA O NOME

Mainframe não perdoa:

  • typo

  • espaço

  • caractere errado


✅ PASSO 5 — VERIFIQUE O BINDER

Talvez o módulo nunca tenha sido gerado.


🔥 O SEGREDO DO ISPF 3.4

Veteranos vivem nele.

Comandos:

MEMBER

ou:

B

ajudam localizar executáveis.


☕ O S806 E O LNKLST

Se não há STEPLIB/JOBLIB:

o z/OS procura em:

LINKLIST

Bibliotecas globais do sistema.


🔥 O S806 FANTASMA

O mais traiçoeiro.

Funcionava ontem.

Hoje:

💥 S806

Porque:

  • loadlib mudou

  • promoção falhou

  • member deletado

  • IEBCOPY sobrescreveu

  • deploy incompleto


☕ O S806 E O PDSE

Hoje muitos ambientes usam:

PDSE

Mais moderno que PDS.

Mas problemas de sincronização e membros ainda acontecem.


🔥 O S806 E O JCLLIB

Às vezes o PROC aponta:

biblioteca errada

E o EXEC herda erro invisível.


☕ O DUMP DO S806

Normalmente pouco útil.

Porque o programa:

NEM CHEGOU A EXECUTAR.

O problema ocorre ANTES.


🔥 O OURO ESTÁ NAS MENSAGENS

Especialmente:

CSV028I
IEF452I
IEWxxxx

☕ COMO O VETERANO PENSA

Veterano vê:

S806

e imediatamente pergunta:

“ONDE ESTÁ A LOADLIB?”


🔥 CURIOSIDADE HISTÓRICA

O S806 vem da era:

IBM OS/360

Década de:

🏛️ 1960

Naquela época:

  • programas eram carregados fisicamente de bibliotecas em disco/tape

  • loader era parte vital do sistema

O S806 virou um dos ABENDs mais clássicos da história corporativa.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S806 é o z/OS dizendo:

VOCÊ TEM CERTEZA QUE ESSE PROGRAMA EXISTE?”


🔥 O MAIOR ERRO DO PADAWAN

Ver:

S806

e recompilar COBOL.

Frequentemente o problema NÃO está no source.

Está em:

  • loadlib

  • binder

  • STEPLIB

  • deploy

  • member

  • ambiente


☕ COMO EVITAR S806


✅ Validar STEPLIB


✅ Confirmar LOADLIB


✅ Revisar BINDER


✅ Nunca FTP executável em ASCII


✅ Conferir nome do member


✅ Padronizar deploy


✅ Validar CALLs dinâmicos


🔥 A VERDADE FINAL

O S0C7 pune números inválidos.
O S0C4 pune memória inválida.
O S013 pune datasets incompatíveis.
O S322 pune tempo excessivo.
O S306 pune falhas de carregamento.

Mas…

☕ O S806 É O MOMENTO EM QUE O z/OS PROCURA UM PROGRAMA… E ENCONTRA APENAS O VAZIO.

terça-feira, 24 de setembro de 2013

☕🔥 ABEND S306 — O “PORTAL QUE NÃO ABRIU” DO z/OS

 

Bellacosa Mainframe abend s306

☕🔥 ABEND S306 — O “PORTAL QUE NÃO ABRIU” DO z/OS

Quando o Mainframe Diz:

“EU NÃO CONSIGO INICIAR ESSE PROGRAMA.”

Se existe um ABEND que faz o Junior Padawan olhar para o JCL como se fosse um grimório amaldiçoado…

é o lendário:

🚨 S306

E normalmente ele aparece assim:

IEF452I JOBNAME STEP1 - ABEND=S306

ou:

CSV003I REQUESTED MODULE NOT FOUND

ou ainda:

PROGRAM FETCH FAILED

E então o desespero começa:

“O programa sumiu?”
“A loadlib evaporou?”
“O COBOL compilou errado?”
“O JES2 perdeu meu módulo?”
“O STEPLIB abriu um portal para outra dimensão?”

☕ Respira.

Porque o S306 é um dos ABENDs MAIS IMPORTANTES para entender:

load modules

STEPLIB

JOBLIB

program fetch

link-edit

APF

bibliotecas z/OS


🔥 O QUE É O S306?

O S306 é um:

🚨 PROGRAM FETCH ERROR

Traduzindo:

O z/OS NÃO CONSEGUIU CARREGAR O PROGRAMA NA MEMÓRIA.


☕ A FILOSOFIA DO S306

Seu JCL disse:

//STEP1 EXEC PGM=COBPROG

O z/OS respondeu:

❌ “EU NÃO ENCONTREI OU NÃO CONSEGUI CARREGAR ESSE MÓDULO.”


🔥 O QUE É “FETCH”?

FETCH é o processo de:

localizar

carregar

preparar

o programa executável na memória.


☕ O FLUXO DA MAGIA

EXEC PGM=PROG1
 ↓
Loader/Search
 ↓
STEPLIB/JOBLIB/LNKLST
 ↓
Load Module encontrado?
 ↓
Carregar memória
 ↓
Executar

Se algo falha:

💥 S306


🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um teatro.

O diretor diz:

“TRAGAM O ATOR PRINCIPAL.”

Mas:

  • ator não existe

  • entrou pela porta errada

  • está trancado

  • veio versão incompatível

  • está corrompido

O espetáculo para.

Isso é o:

☠️ S306


☕ O MAIOR VILÃO DO S306

🚨 STEPLIB ERRADA

O campeão absoluto.


🔥 EXEMPLO CLÁSSICO

//STEPLIB DD DSN=EMPRESA.COBOL.LOAD,DISP=SHR

Mas o programa está em:

EMPRESA.TESTE.LOAD

Resultado:

☠️ S306


☕ O MAINFRAME PROCURA EM ORDEM


☕ STEPLIB

Biblioteca do STEP.


☕ JOBLIB

Biblioteca do JOB.


☕ LNKLST

Bibliotecas globais do sistema.


🔥 O SEGREDO

Se o módulo NÃO estiver em nenhum desses lugares:

💥 S306


☕ O S306 vs S806

Junior confunde MUITO.


☕ S806

Programa não encontrado.


☕ S306

Programa encontrado OU parcialmente localizado…

mas:

não conseguiu carregar/executar corretamente.


🔥 O CASO MAIS FAMOSO

LOAD MODULE CORROMPIDO


☕ COMO ISSO ACONTECE?

  • link-edit incompleto

  • PDS corrompido

  • módulo truncado

  • IEBCOPY errado

  • transferência FTP ASCII

  • member quebrado


🔥 O FTP ASCII DA MORTE

Lenda urbana real do mainframe.

Alguém transfere loadlib em:

ASCII

ao invés de:

BINARY

O executável vira lixo hexadecimal.

Resultado:

☠️ S306


☕ O S306 E O LINK-EDIT

Outro clássico.

Programa compilou.

Mas:

link-edit falhou

ou:

módulo incompleto

Resultado:

💥 S306


🔥 O S306 E O RENT/NORENT

Modo arquimago ativado.

Problemas com:

  • RENT

  • REUS

  • RMODE

  • AMODE

podem impedir carregamento correto.


☕ O S306 E O APF

Outro território sombrio.

Programas privilegiados precisam:

APF authorization

Se biblioteca APF estiver errada:

☠️ caos.


🔥 O S306 E O COBOL

Exemplo clássico:

CALL 'PGMXYZ'

Mas:

  • módulo não está na STEPLIB

  • nome errado

  • versão incorreta

Resultado:

💥 S306


☕ O CALL DINÂMICO MALDITO

Outro trauma coletivo.

CALL WS-PGM

Mas:

WS-PGM = 'PGM123'

e módulo não existe.


🔥 O S306 E O CICS

No CICS pode aparecer como:

ASRA

AEY9

PGMIDERR

dependendo do contexto.


☕ O S306 E O DB2

Outro clássico.

Programa depende de:

DSNHLI

ou módulos DB2 runtime.

Biblioteca errada?

💥 S306


🔥 COMO INVESTIGAR O S306 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O MÓDULO

Mensagem típica:

CSV003I REQUESTED MODULE PROG1 NOT FOUND

Agora temos o suspeito.


✅ PASSO 2 — VERIFIQUE STEPLIB/JOBLIB

Veja:

//STEPLIB DD ...

Confirme:

  • DSN correto

  • DISP correto

  • biblioteca existe


✅ PASSO 3 — USE ISPF 3.4

Procure:

member do load module

✅ PASSO 4 — VERIFIQUE O MEMBER

Existe mesmo?

PROG1

ou:

PROG01

Erro de nome é clássico.


✅ PASSO 5 — CONFIRA O LINK-EDIT

Talvez o módulo nunca tenha sido gerado.


🔥 O SEGREDO DOS LOAD MODULES

Load module NÃO é source.

É:

binário executável IBM Z.


☕ O QUE O DUMP DIZ

O dump do S306 geralmente aponta:

  • loader

  • fetch routine

  • CSV modules

  • search failure


🔥 MENSAGENS IMPORTANTES


☕ CSV003I

Loader/fetch issue.


☕ IEWxxxx

Problemas de binder/link-edit.


☕ IECxxxx

Possíveis problemas dataset.


🔥 O S306 E O BINDER

Outro mundo oculto.

O BINDER cria:

load modules executáveis

Se faltar:

  • INCLUDE

  • ENTRY

  • NAME

o módulo pode nascer defeituoso.


☕ O MAIOR ERRO DOS JUNIORS

Pensar:

“compilou = funciona.”

Não.

Compile ≠ executável válido.


🔥 O S306 FANTASMA

O mais traiçoeiro.

Programa funcionava ontem.

Hoje:

💥 S306

Porque:

  • loadlib mudou

  • versão errada entrou

  • IEBCOPY sobrescreveu

  • promoção falhou


☕ O S306 E O PDSE

Hoje muitos ambientes usam:

PDSE

Mais moderno que PDS.

Mas problemas de cache/member ainda podem gerar situações bizarras.


🔥 O S306 E O “NOT AUTHORIZED”

Às vezes o módulo existe.

Mas:

sem autorização.

Então:

  • RACF

  • APF

  • proteção de biblioteca

entram no jogo.


☕ COMO EVITAR S306


✅ Conferir STEPLIB


✅ Validar LOADLIB


✅ Confirmar member correto


✅ Nunca FTP loadlib em ASCII


✅ Revisar link-edit


✅ Padronizar promoção


✅ Verificar APF


🔥 CURIOSIDADE HISTÓRICA

Nos tempos do OS/360:

programas eram carregados diretamente de bibliotecas físicas em disco/tape.

O mecanismo de FETCH era parte crítica do sistema operacional.

S306 virou um dos erros clássicos da era dos load modules.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S306 é o mainframe dizendo:

EU SEI QUE VOCÊ JURA QUE O PROGRAMA EXISTE… MAS EU NÃO ACREDITO.”


🔥 O MAIOR ENSINAMENTO DO S306

Ele ensina algo profundo:

no z/OS, EXECUTAR um programa é um ritual complexo.

Não basta existir source.

É preciso:

  • compilar

  • linkar

  • catalogar

  • localizar

  • autorizar

  • carregar


☕ A VERDADE FINAL

O S0C7 pune dados inválidos.
O S0C4 pune memória inválida.
O S013 pune datasets incompatíveis.
O S322 pune tempo excessivo.

Mas…

☕ O S306 PUNE PROGRAMAS QUE NÃO CONSEGUIRAM ATRAVESSAR O PORTAL DE LOAD DO z/OS.


quinta-feira, 15 de fevereiro de 2007

O que é Compilação e Linkedição de um Programa COBOL?

 

Bellacosa Mainframe o que é Compilação e Linkedição de um programa COBOL

O que é Compilação e Linkedição de um Programa COBOL?

Quando escrevemos um programa COBOL, o computador não executa diretamente o código-fonte.

Antes disso, ele precisa passar por duas etapas fundamentais:

Compilação

e

Linkedição (Link-Edit ou Binder)

Essas etapas transformam o código COBOL em um programa executável pelo z/OS.


Visão Geral

Código COBOL
     ↓
Compilação
     ↓
Objeto (OBJ)
     ↓
Linkedição (Binder)
     ↓
Load Module / Program Object
     ↓
Execução

O que é Compilação?

Compilação é o processo de converter:

Código COBOL

em

Código Objeto

Analogia Simples

Imagine que você escreveu um livro em português.

O compilador é um tradutor que converte o texto para um idioma que o processador entende.


Entrada da Compilação

Programa fonte:

IDENTIFICATION DIVISION.

PROGRAM-ID. HELLO.

PROCEDURE DIVISION.

DISPLAY 'OLA MUNDO'.

STOP RUN.

Saída da Compilação

Arquivo objeto:

OBJETO

Ainda não é executável.


O que o Compilador faz?

Durante a compilação ele:

✅ Analisa sintaxe

✅ Valida comandos COBOL

✅ Expande COPYBOOKs

✅ Verifica variáveis

✅ Gera instruções de máquina

✅ Produz mensagens de erro


Exemplo de erro

DISPLY 'OLA'

Resultado:

IGYPS2121-S

Erro de sintaxe.


Compilador COBOL

Nos ambientes IBM Z normalmente encontramos:

Enterprise COBOL for z/OS

O que é o Código Objeto?

Após a compilação é criado:

OBJETO

Também chamado de:

Object Deck
Object Module
OBJ

Características

  • Não executa sozinho

  • Pode conter referências externas

  • Precisa passar pelo Binder


O que é Linkedição?

Também chamada:

Link-Edit

ou

Binding


Função

Transformar o código objeto em um programa executável.


Fluxo

OBJETO
   ↓
BINDER
   ↓
LOAD MODULE

O que o Binder faz?

Ele:

✅ Resolve chamadas externas

✅ Liga subprogramas

✅ Liga bibliotecas

✅ Resolve referências CICS

✅ Resolve referências DB2

✅ Cria módulo executável


Analogia Simples

Imagine várias peças de LEGO.

A compilação cria as peças.

A linkedição monta tudo em um único brinquedo funcional.


Resultado Final

LOAD MODULE

ou

PROGRAM OBJECT

Onde fica o executável?

Normalmente em uma biblioteca:

USER.LOADLIB

ou

PROD.LOADLIB

Fluxo Completo

COBOL Source
      ↓
Compiler
      ↓
Object Module
      ↓
Binder
      ↓
Load Module
      ↓
JCL EXEC PGM=

Exemplo de Execução

JCL:

//STEP1 EXEC PGM=HELLO

O z/OS procura:

HELLO

na:

STEPLIB
JOBLIB
LINKLIST

O que é STEPLIB?

Biblioteca onde o executável está armazenado.


Exemplo

//STEPLIB DD DSN=USER.LOADLIB,
//            DISP=SHR

Chamadas entre Programas

Programa principal:

CALL 'CALCSAL'

Durante a Linkedição

O Binder procura:

CALCSAL

e conecta os módulos.


Linkedição com CICS

Programas CICS utilizam bibliotecas especiais.

Exemplo:

DFHEIBLK
DFHCOMMAREA

O Binder resolve essas referências.


Linkedição com DB2

Programas DB2 possuem etapas extras.

COBOL
 ↓
Pré-compilador DB2
 ↓
Compilação
 ↓
BIND DB2
 ↓
Linkedição

O que é BIND no DB2?

Não confundir com Binder.


Binder

Cria executável.


BIND DB2

Cria:

PACKAGE
PLAN

Principais Saídas da Compilação


SYSPRINT

Mensagens do compilador.


LISTING

Listagem fonte expandida.


OBJETO

Código objeto.


Principais Saídas da Linkedição


SYSPRINT

Mensagens Binder.


LOAD MODULE

Executável.


Erros Comuns de Compilação

Variável não declarada

IGYPS...

COPYBOOK inexistente

IGYDS...

Erro de sintaxe

IGYPS...

Erros Comuns de Linkedição

Módulo não encontrado

IEW2456E

Referência externa não resolvida

IEW2646S

Biblioteca ausente

IEW...

Ferramentas Envolvidas

EtapaFerramenta
CompilaçãoEnterprise COBOL
LinkediçãoBinder (IEWL)
Execuçãoz/OS Loader

Exemplo Real de JCL

//COBOL EXEC PGM=IGYCRCTL
//SYSIN DD DSN=USER.COBOL(PROG1)

//LKED EXEC PGM=IEWL
//SYSLMOD DD DSN=USER.LOADLIB(PROG1)

Curiosidades

1. Antigamente a saída da compilação era gravada em cartões perfurados

2. O Binder substituiu o antigo Linkage Editor

3. Um único programa pode ser ligado a dezenas de módulos externos

4. Grandes bancos compilam milhares de programas COBOL diariamente


Resumo Rápido

EtapaFunção
CompilaçãoGera código objeto
Código ObjetoSaída intermediária
BinderLiga módulos
LinkediçãoCria executável
Load ModulePrograma executável
STEPLIBBiblioteca de execução
CALLChama subprograma
BIND DB2Cria Package e Plan

Conclusão

A compilação converte o código COBOL em um módulo objeto, enquanto a linkedição (Binder) conecta todas as dependências e gera o módulo executável que será carregado pelo z/OS. Entender essas etapas é fundamental para diagnosticar erros de compilação, problemas de execução e compreender como os programas COBOL realmente funcionam no ambiente IBM Z.