Translate

Mostrar mensagens com a etiqueta Link Edit. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Link Edit. 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.


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.