Translate

Mostrar mensagens com a etiqueta Performance IBM Z. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Performance IBM Z. 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, 1 de abril de 2019

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

 

Bellacosa Mainframe apresenta o CALL em Cobol Parte IV

☕💥 A Jornada do Padawan COBOL – Parte 4

Desvendando o Universo dos CALLs no Mainframe

RENT, NORENT, Reentrância, Thread Safety, HEAP, STACK, CICS, LE, AMODE 31/64 e os Segredos dos Arquitetos IBM Z

Ou como descobrir que um programa COBOL pode ser executado por milhares de usuários ao mesmo tempo sem enlouquecer

Por Vagner Bellacosa – Bellacosa Mainframe


O Dia em que o Padawan descobre que o mesmo programa atende 5.000 usuários

Até agora aprendemos:

✔ Static Call

✔ Dynamic Call

✔ By Reference

✔ By Content

✔ Ponteiros

✔ CEEDUMP

✔ Troubleshooting

Mas existe uma pergunta interessante.

Como um banco consegue executar o mesmo programa COBOL para milhares de clientes simultaneamente?


O Problema

Imagine o programa:

PROGRAMA CLIENTE01

Sendo executado por:

Cliente A

Cliente B

Cliente C

Cliente D

Cliente E

...

Cliente 5.000

Ao mesmo tempo.


O pesadelo

Cliente A

Saldo = 1000

Cliente B

Saldo = 5000

Programa compartilha memória.

Resultado:

Cliente A vê saldo de B.

Cliente B recebe extrato de A.

Produção vira caos.


O conceito de Reentrância

IBM resolveu isso décadas atrás.

Criou:

RENT

Reentrant

Programa reentrante


Significa:

Código compartilhado.

Dados privados.


Visualmente


PROGRAMA COBOL

+----------------+
|     CÓDIGO     |
+----------------+
        |
        |
        |
+-------+-------+-------+

T1      T2      T3

Dados   Dados   Dados



O compilador RENT

Compilação:

RENT

ou

PROCESS(RENT)

O que muda?

Código

Read Only

Variáveis

Área privada.


Vantagens

Menos memória.

Melhor CICS.

Escalável.

Thread Safe.


O que não pode fazer?

Modificar código.

Guardar estado global.

Self-modifying.


O vilão

WORKING-STORAGE


Padawan pensa:

WS é lindo.

IBM pensa:

Depende...


Exemplo

WORKING-STORAGE.

01 WS-COUNTER PIC 9(5).

Programa chamado

100 vezes.

WS continua vivo.


Execução 1

contador=10

Execução 2

contador=11

Execução 3

contador=12


Problema em CICS.

Pode gerar corrupção.


O herói esquecido

LOCAL-STORAGE

Pouca gente usa.

IBM ama.


Exemplo

LOCAL-STORAGE.

01 LS-COUNTER PIC 9(5).

Nova chamada

Nova variável.


Execução 1

LS=0

Execução 2

LS=0

Execução 3

LS=0


Perfeito.


Thread Safety

Muito falado.

Pouco entendido.


Thread Safe significa:

Múltiplas execuções.

Mesmo código.

Sem interferência.


Java

synchronized

COBOL

RENT

LOCAL STORAGE


CICS adora RENT

CICS pode manter

programas residentes.


Exemplo

Programa

PAGO001

Carregado

Uma vez.

Usado

10 mil vezes.


CPU agradece.


NORENT

O lado sombrio.


Programa exclusivo.


Cada usuário

carrega cópia.


Visualmente

USR1


PROG



USR2


PROG



USR3


PROG

Memória explode.


Quando usar?

Batch.

Programas antigos.

Nunca em CICS.


Language Environment

LE

O grande maestro.


Controla

Heap

Stack

Exceções

Storage

Runtime


Sem LE

caos.

Com LE

harmonia.


O STACK

Pilha temporária.


CALL

Empilha.

Retorno

Desempilha.


Exemplo

MAIN

↓

A

↓

B

↓

C

STACK


C

B

A

MAIN



Volta


MAIN

Heap

Área dinâmica.


Exemplo

ALLOCATE

FREE


Muito usado

XML

JSON

APIs


Configuração

CEEOPTS

HEAP

STACK

ANYHEAP


Problema comum

Heap pequeno.


Mensagem

CEE0813S

Solução

Aumentar.


AMODE

Modo de endereçamento.


AMODE 24

16 MB


AMODE 31

2 GB


AMODE 64

Exabytes

Praticamente infinito.


Por que importa?

Grandes buffers.

Big Data.

Analytics.

IA.


Ponteiros 64 bits

Exemplo

USAGE POINTER

ou

USAGE PROCEDURE-POINTER

CALL mais rápido possível

Arquitetos IBM fazem:

Static CALL

By Reference

RENT

Local Storage

Programa residente

CICS


Resultado

Milhões de chamadas.

Baixa CPU.


Microbenchmark imaginário

Método

Tempo

Static

1 ms

Dynamic

2 ms

By Content

5 ms

Carga módulo

15 ms


Técnicas Bellacosa

Dica 1

Sempre compile RENT.


Dica 2

Evite WS temporário.


Dica 3

Prefira Local Storage.


Dica 4

Static para alta frequência.


Dica 5

Nunca abuse de By Content.


Dica 6

Documente interfaces.


Dica 7

Teste concorrência.


Easter Egg IBM

Muitos programas antigos possuem:

GO TO 999999

Ou:

ALTER

Ou:

ENTRY

Ou:

EXHIBIT

E alguns desenvolvedores mais jovens acreditam que são lendas urbanas.

Não são.

Ainda existem.

Estão em produção.

Movimentando bilhões.

E provavelmente continuarão vivos por mais tempo do que muitas aplicações modernas.


Checklist Jedi da Performance

✅ Compilar RENT

✅ Utilizar Local-Storage

✅ Minimizar By Content

✅ Reutilizar programas residentes

✅ Evitar Dynamic CALL em loops críticos

✅ Configurar HEAP adequadamente

✅ Monitorar RMF

✅ Analisar SMF 30

✅ Medir CPU

✅ Testar concorrência

✅ Validar Thread Safety


A Filosofia Jedi do CALL – Parte 4

O Padawan iniciante pensa:

O programa funciona.

O desenvolvedor intermediário pensa:

O programa funciona rápido.

O Arquiteto Mainframe entende:

O programa deve funcionar rápido, consumir pouca memória, ser reentrante, sobreviver a milhares de usuários simultâneos, ser fácil de manter e continuar executando silenciosamente por décadas.

E é exatamente por isso que alguns dos sistemas mais importantes do planeta continuam rodando em IBM Z, executando milhões de CALLs, compartilhando código reentrante, administrando HEAPs, empilhando STACKs e servindo milhares de transações por segundo, enquanto o desenvolvedor Padawan toma seu café às três da manhã e finalmente compreende que, no Mainframe, a verdadeira Força sempre esteve na gestão inteligente da memória.


Na Parte 5, o Padawan poderá explorar os segredos finais dos CALLs: Binder, Link-Edit, PDQL, RMODE, FETCH, CANCEL, Program Objects, DLLs, módulos residentes, LPA, LINKLIST, otimizações z/Architecture e as técnicas usadas pelos veteranos para reduzir microssegundos em cargas de milhões de transações.