Translate

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


segunda-feira, 15 de janeiro de 2007

O que é “Acima da Linha”, “Acima da Barra” e Endereçamento de Memória 24, 31 e 64 bits no Mainframe?

 

Bellacosa Mainframe e a memoria em mainframe

O que é “Acima da Linha”, “Acima da Barra” e Endereçamento de Memória 24, 31 e 64 bits no Mainframe?

Esse é um dos temas mais importantes — e mais misteriosos — do mundo z/OS.

Quando alguém começa a estudar:

  • JES2;

  • CICS;

  • DB2;

  • storage;

  • performance;

  • programação assembler;

rapidamente encontra frases como:

  • “rodando acima da linha”;

  • “storage abaixo da linha”;

  • “memória acima da barra”.

No começo parece extremamente confuso.

Mas tudo gira em torno de:

como o mainframe organiza memória.


Primeiro: o que é memória no mainframe?

Memória é o espaço usado para:

  • programas;

  • variáveis;

  • buffers;

  • controle do sistema;

  • áreas de trabalho.

O z/OS gerencia isso de forma extremamente organizada.


O problema histórico

Os primeiros mainframes possuíam pouca memória.

Então a IBM criou limites de endereçamento.

Com o tempo:

  • mais memória surgiu;

  • novos limites foram criados;

  • o z/OS evoluiu mantendo compatibilidade histórica.

Resultado:
existem vários “níveis” de memória.


O que significa “endereçamento”?

Endereçamento é:

a capacidade de localizar posições de memória.

Quanto mais bits:

  • maior espaço de memória acessável.


Analogia simples

Imagine memória como:

uma cidade cheia de casas.

O endereço informa:

  • qual casa acessar.

Quanto mais dígitos no endereço:

  • mais casas podem existir.


Endereçamento de 24 bits

Foi um dos primeiros modelos do mainframe.


Quanto consegue endereçar?

2^{24}=16.777.216

Aproximadamente:

16 MB


Isso criou a famosa:

Linha dos 16 MB


O que é “abaixo da linha”?

Toda memória:

abaixo de 16 MB.


O que é “acima da linha”?

Toda memória:

acima de 16 MB.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB  ← A LINHA
│
├── Acima da linha
│

Por que isso é importante?

Muitos programas antigos foram escritos para:

memória de 24 bits.

Eles só conseguem trabalhar:

  • abaixo da linha.


Problema clássico

A região abaixo da linha virou:

extremamente disputada.

Porque:

  • sistema;

  • CICS;

  • buffers;

  • programas antigos;

todos queriam espaço ali.


Então surgiu o endereçamento 31 bits

A IBM expandiu o espaço de memória.


Quanto consegue endereçar?

2^{31}=2.147.483.648

Aproximadamente:

2 GB


Mas por que não 32 bits?

Porque 1 bit era usado para controle interno.

Então o z/OS adotou:

31 bits efetivos.


Resultado

Agora existia:

  • memória abaixo da linha;

  • memória acima da linha.

Muito mais espaço disponível.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB ← Linha
│
├── Acima da linha
│
2 GB

Então nasceu a “barra”

Quando o z/OS evoluiu novamente para 64 bits, surgiu:

a barra dos 2 GB.


Acima da barra

Tudo acima de:

2 GB.


Visualmente

0 MB
│
├── Abaixo da linha
│
16 MB ← Linha
│
├── Acima da linha
│
2 GB ← Barra
│
├── Acima da barra
│

Endereçamento 64 bits

Com 64 bits, o espaço cresce absurdamente.


Quantidade teórica

2^{64}=18.446.744.073.709.551.616

Quantidade gigantesca de memória.


Resultado prático

O z/OS moderno consegue trabalhar com:

  • enormes caches;

  • gigantescos bancos de dados;

  • workloads massivos;

  • analytics;

  • Java;

  • Linux on Z.


Então resumindo

ConceitoLimite
24 bits16 MB
31 bits2 GB
64 bitsmemória gigantesca

O que é “abaixo da linha”?

Memória:

abaixo de 16 MB.

Muito usada por:

  • programas antigos;

  • áreas críticas do sistema.


O que é “acima da linha”?

Memória:

entre 16 MB e 2 GB.

Usada por:

  • aplicações modernas 31 bits;

  • CICS;

  • DB2;

  • subsistemas.


O que é “acima da barra”?

Memória:

acima de 2 GB.

Usada por:

  • Java;

  • grandes caches;

  • DB2 moderno;

  • aplicações 64 bits.


O que significa storage constraint?

Problema de falta de memória.

Muito comum:

abaixo da linha.


Por que abaixo da linha é crítico?

Porque:

  • espaço pequeno;

  • muitos componentes disputam memória.

16 MB hoje parece minúsculo.


Exemplo clássico

CICS antigos sofriam muito com:

storage below the line.


Como isso aparece no dia a dia?

Mensagens como:

  • SOS;

  • storage shortage;

  • below the line exhausted.


O que é AMODE?

Addressing Mode

Define:
como o programa trabalha com memória.


Exemplos


AMODE 24

Programa trabalha em:
24 bits.


AMODE 31

Programa usa:
31 bits.


AMODE 64

Programa moderno usa:
64 bits.


O que é RMODE?

Residency Mode

Define:
onde o programa deve residir.


Exemplo

RMODE 24

Programa precisa ficar:
abaixo da linha.


Isso ainda existe?

Muito.

Principalmente em:

  • sistemas legados;

  • assembler;

  • módulos antigos.


Curiosidades incríveis

1. Muitos sistemas críticos ainda possuem código 24 bits

Décadas depois.


2. O z/OS mantém compatibilidade histórica absurda

Programas antigos ainda funcionam.


3. “Abaixo da linha” virou expressão clássica no mainframe


4. O endereçamento 64 bits revolucionou o z/OS moderno

Especialmente DB2 e Java.


Erros comuns de iniciantes


1. Pensar que “linha” é física

Ela é apenas:

um limite lógico de memória.


2. Confundir linha e barra

Linha:
16 MB.

Barra:
2 GB.


3. Achar que 24 bits morreu

Ainda existe muito software legado.


4. Ignorar AMODE/RMODE

Isso pode causar erros graves em assembler e linkedição.


Como isso aparece no JCL e programas?

Em:

  • binder;

  • assembler;

  • parâmetros LE;

  • CICS;

  • DB2;

  • dumps;

  • performance tuning.


Por que aprender isso?

Porque isso explica:

  • arquitetura do z/OS;

  • compatibilidade histórica;

  • gestão de memória;

  • performance;

  • problemas clássicos do mainframe.


Resumo rápido

TermoSignificado
Abaixo da linha< 16 MB
Acima da linha16 MB até 2 GB
Acima da barra> 2 GB
24 bitsaté 16 MB
31 bitsaté 2 GB
64 bitsenorme espaço
AMODEmodo de endereçamento
RMODEonde o programa reside

Conclusão

Os conceitos de:

  • abaixo da linha;

  • acima da linha;

  • acima da barra;

  • endereçamento 24, 31 e 64 bits

fazem parte da evolução histórica da memória no z/OS.

Eles mostram como o mainframe IBM conseguiu evoluir durante décadas mantendo compatibilidade com aplicações antigas enquanto expandia capacidade para workloads modernos gigantescos.