 |
| 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.
Sem comentários:
Enviar um comentário