 |
| Bellacosa Mainframe compilacao cobol parte iv |
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL — Parte IV
Da Load Library à CPU: Como JES2, JCL, QSAM, VSAM, Memória e z/OS Colocam o Programa para Trabalhar
Introdução
Nas três primeiras partes desta jornada, acompanhamos o nascimento e a transformação de um programa COBOL.
Primeiro, vimos que tudo começa com o código-fonte e com os copybooks, que funcionam como contratos de dados compartilhados entre programas, arquivos e subsistemas.
Depois, conhecemos o papel de ambientes especializados como:
Descobrimos que comandos EXEC CICS precisam ser traduzidos, que instruções EXEC SQL precisam ser processadas pelo Db2 e que aplicações IMS ou Adabas dependem de interfaces específicas.
Na terceira parte, entramos na fábrica de software do IBM Z.
O compilador transformou o fonte em código objeto.
O Binder resolveu referências, reuniu módulos e criou o executável.
Ao final, o programa foi armazenado em uma load library:
EMPRESA.SISTEMA.LOADLIB(PGMCLI01)
Agora, finalmente, chegou a hora de responder à pergunta que todo Programador COBOL Padawan faz:
Como esse membro armazenado em uma biblioteca realmente começa a executar?
Ter um load module não significa que o programa já esteja trabalhando.
Ele ainda precisa ser:
solicitado;
localizado;
carregado;
associado aos arquivos;
colocado em memória;
entregue ao ambiente de execução;
despachado para um processador;
monitorado até o término.
Nesta quarta e última parte, acompanharemos essa jornada completa.
Veremos como o JCL solicita a execução, como o JES2 administra o job, como o initiator inicia os steps, como QSAM e VSAM são conectados ao programa, como o z/OS administra memória e processadores e por que a CPU nunca enxerga uma única linha de COBOL.
Prepare a última xícara desta série.
O programa já foi construído.
Agora ele precisa entrar em produção.
1. O executável está pronto, mas ainda está parado
Depois da linkedição, temos um módulo executável armazenado em uma biblioteca:
EMPRESA.SISTEMA.LOADLIB(PGMCLI01)
Esse módulo contém instruções de máquina, pontos de entrada, referências resolvidas e estruturas necessárias para a execução.
Porém, sozinho, ele não realiza trabalho algum.
É como um automóvel estacionado dentro de uma garagem.
O veículo está montado.
O motor existe.
Os sistemas estão disponíveis.
Mas alguém ainda precisa:
localizar o carro;
abrir a garagem;
fornecer combustível;
ligar o motor;
definir o destino;
colocá-lo na estrada.
No ambiente batch, essa missão normalmente começa com um JCL.
2. O JCL solicita a execução
JCL significa Job Control Language.
Ele não é uma linguagem de programação de negócio como COBOL.
Sua função é descrever ao sistema operacional:
qual programa deverá ser executado;
quais arquivos serão utilizados;
quais bibliotecas contêm os módulos;
para onde enviar as saídas;
quais recursos serão necessários;
quais condições controlam os steps;
como o job deverá ser classificado.
Um exemplo simples:
//EXECUTA JOB (1234),'BELLACOSA',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=PGMCLI01
//STEPLIB DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.LOADLIB
//CLIENTES DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
//RELATORIO DD SYSOUT=*
//SYSOUT DD SYSOUT=*
A instrução principal é:
//STEP01 EXEC PGM=PGMCLI01
Ela informa ao sistema:
Execute o programa chamado PGMCLI01.
Mas para isso funcionar, o z/OS precisa encontrar esse módulo.
3. Como o sistema encontra o programa?
O nome informado em:
PGM=PGMCLI01
não contém o nome completo da biblioteca.
O sistema precisa pesquisar em bibliotecas disponíveis para localizar o módulo.
Em batch, uma das formas mais comuns é utilizar STEPLIB:
//STEPLIB DD DISP=SHR,
// DSN=EMPRESA.SISTEMA.LOADLIB
Isso informa que, durante aquele step, a biblioteca deverá participar da procura pelo executável.
Também podem existir outros mecanismos, como:
O princípio é:
Nome do programa
↓
Pesquisa nas bibliotecas
↓
Módulo localizado
↓
Carga e execução
4. A ordem das bibliotecas importa
Imagine:
//STEPLIB DD DISP=SHR,
// DSN=EMPRESA.TESTE.LOADLIB
// DD DISP=SHR,
// DSN=EMPRESA.ANTIGA.LOADLIB
Se PGMCLI01 existir na primeira biblioteca, essa versão será utilizada.
Agora imagine a ordem inversa:
//STEPLIB DD DISP=SHR,
// DSN=EMPRESA.ANTIGA.LOADLIB
// DD DISP=SHR,
// DSN=EMPRESA.TESTE.LOADLIB
O programa antigo poderá ser encontrado primeiro.
O programador compila uma alteração, executa o job e não percebe nenhuma mudança.
Então começa a revisar:
o COBOL;
o copybook;
o IF;
o MOVE;
o SQL;
os dados.
Mas o problema real é muito mais simples:
O sistema está executando outro load.
Essa situação é tão comum que todo profissional mainframe deveria verificar primeiro:
em qual load library o módulo foi gerado;
qual biblioteca está no JCL;
qual é a ordem da concatenação;
se existe outro membro com o mesmo nome;
se o ambiente online já carregou a nova versão.
5. O que acontece se o programa não for encontrado?
Quando o módulo não está disponível nas bibliotecas pesquisadas, o sistema pode produzir um erro associado a programa não encontrado.
Um exemplo clássico é o abend:
S806
Isso geralmente significa que o sistema tentou localizar o módulo, mas não encontrou uma versão executável disponível.
As causas podem incluir:
STEPLIB ausente;
biblioteca incorreta;
membro inexistente;
erro no nome do programa;
programa gravado em outra load library;
módulo não promovido;
biblioteca indisponível;
ponto de entrada incorreto.
Observe que o fonte COBOL pode estar perfeito.
A compilação pode ter terminado com RC=0.
A linkedição também pode ter terminado corretamente.
Mesmo assim, a execução falha porque o executável não foi encontrado.
Essa é a diferença entre:
Criar o programa
e:
Disponibilizar o programa para execução
6. O programa precisa de dados
Localizar o executável é apenas o começo.
Um programa real costuma depender de:
arquivos sequenciais;
clusters VSAM;
tabelas Db2;
bancos IMS;
arquivos Adabas;
mensagens MQ;
filas CICS;
parâmetros;
relatórios;
arquivos de trabalho.
No batch, muitos desses recursos são associados ao programa por DD statements no JCL.
É aqui que entramos no universo de QSAM e VSAM.
7. O que é QSAM?
QSAM significa Queued Sequential Access Method.
Ele é um método tradicional de acesso sequencial a datasets no z/OS.
Em um arquivo sequencial, os registros normalmente são processados na ordem em que estão armazenados.
No COBOL:
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT ARQ-CLIENTES
ASSIGN TO CLIENTES
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-FILE-STATUS.
Na FILE SECTION:
FD ARQ-CLIENTES.
01 REGISTRO-CLIENTE.
05 REG-CODIGO PIC 9(09).
05 REG-NOME PIC X(40).
05 REG-SALDO PIC S9(11)V99 COMP-3.
Na lógica:
OPEN INPUT ARQ-CLIENTES
PERFORM UNTIL FIM-ARQUIVO
READ ARQ-CLIENTES
AT END
SET FIM-ARQUIVO TO TRUE
NOT AT END
PERFORM PROCESSAR-CLIENTE
END-READ
END-PERFORM
CLOSE ARQ-CLIENTES.
O programa conhece o arquivo pelo nome lógico:
CLIENTES
O JCL conecta esse nome lógico a um dataset físico.
8. O contrato entre COBOL e JCL
No programa:
ASSIGN TO CLIENTES
No JCL:
//CLIENTES DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
A ligação é:
SELECT ARQ-CLIENTES
↓
ASSIGN TO CLIENTES
↓
DDNAME CLIENTES
↓
EMPRESA.DADOS.CLIENTES
Essa separação é extremamente poderosa.
O programa não precisa possuir no fonte:
EMPRESA.DADOS.CLIENTES
O mesmo executável pode ser usado em diferentes ambientes.
Desenvolvimento
//CLIENTES DD DISP=SHR,
// DSN=DESENV.DADOS.CLIENTES
Homologação
//CLIENTES DD DISP=SHR,
// DSN=HOMOLOG.DADOS.CLIENTES
Produção
//CLIENTES DD DISP=SHR,
// DSN=PROD.DADOS.CLIENTES
O load module é o mesmo.
O que muda é o JCL e o ambiente.
9. Quando o DDNAME está errado
Imagine que o COBOL espera:
ASSIGN TO CLIENTES
Mas o JCL fornece:
//ARQCLI DD DISP=SHR,
// DSN=EMPRESA.DADOS.CLIENTES
O dataset existe.
O programa existe.
A biblioteca está correta.
Porém, o nome lógico não corresponde ao DDNAME esperado.
O programa procura CLIENTES.
O JCL forneceu ARQCLI.
Essa divergência poderá provocar erro de abertura.
Esse problema ensina uma grande lição:
Em mainframe, muitos erros surgem da quebra de contratos entre componentes.
O COBOL, o JCL, os arquivos e os subsistemas precisam falar a mesma língua.
10. OPEN, READ, WRITE e CLOSE
Um programa QSAM normalmente segue um ciclo.
OPEN
↓
READ ou WRITE
↓
Processamento
↓
CLOSE
Exemplo de entrada:
OPEN INPUT ARQ-ENTRADA
Exemplo de saída:
OPEN OUTPUT ARQ-SAIDA
Leitura:
READ ARQ-ENTRADA
AT END
SET FIM-ARQUIVO TO TRUE
END-READ
Gravação:
WRITE REGISTRO-SAIDA
Finalização:
CLOSE ARQ-ENTRADA
ARQ-SAIDA
O compilador gera chamadas e instruções necessárias para trabalhar com o access method.
Durante a execução, o z/OS e seus componentes realizam o acesso real ao dataset.
11. O que é VSAM?
VSAM significa Virtual Storage Access Method.
Ele fornece diferentes formas de organização de dados.
Entre elas:
KSDS;
ESDS;
RRDS;
LDS;
VRRDS.
Para um Programador COBOL Padawan, o KSDS é um dos mais importantes.
KSDS significa Key-Sequenced Data Set.
Os registros podem ser acessados por uma chave.
Exemplo:
FILE-CONTROL.
SELECT ARQ-CLIENTES
ASSIGN TO CLIENTES
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS REG-CODIGO
FILE STATUS IS WS-FILE-STATUS.
O campo:
REG-CODIGO
é a chave do registro.
12. Acesso sequencial e direto no VSAM
Um KSDS pode permitir diferentes formas de acesso.
Acesso sequencial
O programa lê os registros em ordem de chave.
READ ARQ-CLIENTES NEXT RECORD
AT END
SET FIM-ARQUIVO TO TRUE
END-READ.
Acesso direto
O programa informa uma chave específica.
MOVE WS-CODIGO-PESQUISA
TO REG-CODIGO
READ ARQ-CLIENTES
KEY IS REG-CODIGO
INVALID KEY
DISPLAY 'CLIENTE NAO ENCONTRADO'
END-READ.
Acesso dinâmico
Permite combinar acessos sequenciais e diretos.
ACCESS MODE IS DYNAMIC
Esse tipo de flexibilidade tornou VSAM fundamental em muitas aplicações corporativas.
13. FILE STATUS
Um programa não deve presumir que uma operação de arquivo sempre funcionou.
Por isso, pode utilizar:
FILE STATUS IS WS-FILE-STATUS
Definição:
01 WS-FILE-STATUS PIC X(02).
Depois de uma operação:
IF WS-FILE-STATUS NOT = '00'
DISPLAY 'ERRO NO ARQUIVO: '
WS-FILE-STATUS
END-IF.
Alguns retornos conhecidos são:
00 → operação concluída com sucesso
10 → fim de arquivo
22 → possibilidade de chave duplicada
23 → registro não encontrado
35 → problema na abertura ou arquivo ausente
39 → conflito de atributos
A interpretação exata precisa considerar:
operação executada;
organização do arquivo;
ambiente;
documentação;
mensagem adicional.
14. FILE STATUS 10 não é necessariamente erro
Em processamento sequencial, o retorno:
10
normalmente indica fim de arquivo.
Isso faz parte do fluxo esperado.
Exemplo:
READ ARQ-ENTRADA
AT END
SET FIM-ARQUIVO TO TRUE
END-READ.
O programa precisa distinguir:
Fim normal de arquivo
de:
Erro de leitura
Tratar todos os retornos diferentes de 00 como falha pode produzir lógica incorreta.
15. QSAM e VSAM não ficam dentro do executável
O load module contém o programa.
Os dados permanecem em datasets separados.
LOADLIB
└── PGMCLI01
Dataset QSAM
└── registros sequenciais
Cluster VSAM
└── registros organizados
Tabela Db2
└── linhas relacionais
Banco IMS
└── segmentos hierárquicos
Arquivo Adabas
└── registros gerenciados pelo Nucleus
O executável contém a lógica.
Os datasets e bancos contêm os dados.
O JCL e os subsistemas conectam os dois mundos.
16. O que é JES2?
JES2 significa Job Entry Subsystem 2.
Ele é um dos componentes mais importantes do processamento batch no z/OS.
Uma confusão comum é imaginar que o JES2 executa diretamente o programa COBOL.
Ele não faz isso.
O JES2 administra o fluxo do job.
Entre suas responsabilidades estão:
Podemos pensar no JES2 como um grande controlador de tráfego batch.
17. O ciclo de um job
Um fluxo simplificado:
Programador submete o JCL
↓
JES2 recebe o job
↓
Job é colocado no spool
↓
JCL é analisado
↓
Job aguarda em uma fila
↓
Um initiator seleciona o job
↓
Os steps são executados
↓
As saídas voltam ao spool
↓
Usuário consulta no SDSF
O JES2 não executa a instrução COBOL:
ADD WS-VALOR TO WS-TOTAL
Ele gerencia o job que contém o step responsável por iniciar o programa.
18. O que é spool?
Spool é uma área em disco utilizada para armazenar entrada e saída dos jobs.
O termo vem historicamente de:
Simultaneous Peripheral Operations On-Line
Na prática, o spool permite desacoplar a produção da saída de seu consumo imediato.
Por exemplo, um programa pode gerar milhares de linhas de relatório.
Essas linhas não precisam ser enviadas instantaneamente a uma impressora física.
Elas podem ser armazenadas no spool.
Depois, poderão ser:
consultadas;
impressas;
transferidas;
retidas;
apagadas;
analisadas.
19. Saídas comuns no spool
Ao consultar um job no SDSF, podemos encontrar:
JESMSGLG
JESJCL
JESYSMSG
SYSPRINT
SYSOUT
SYSUDUMP
CEEDUMP
JESMSGLG
Contém mensagens relacionadas ao job e ao JES.
JESJCL
Mostra o JCL processado.
Pode incluir expansão de procedures e parâmetros.
JESYSMSG
Contém mensagens do sistema para os steps.
SYSPRINT
Normalmente recebe listagens, relatórios ou mensagens de utilitários.
SYSOUT
Pode conter saída produzida pelo programa.
SYSUDUMP
Pode receber dumps em caso de falha.
CEEDUMP
Pode conter informações produzidas pelo Language Environment.
Essas saídas são fundamentais para diagnóstico.
20. SDSF: a janela para o processamento
SDSF significa System Display and Search Facility.
Por meio dele, o profissional pode:
O Padawan submete o job e olha apenas a última linha.
O especialista abre cada saída relevante.
Ele procura:
qual step falhou;
qual RC foi retornado;
qual biblioteca foi usada;
qual dataset não abriu;
qual mensagem apareceu antes do abend;
qual componente emitiu o diagnóstico.
21. O que é um initiator?
Um initiator é um componente que seleciona jobs elegíveis para execução e inicia seus steps.
Ele trabalha com elementos como:
classe do job;
disponibilidade;
configuração;
capacidade;
regras operacionais;
prioridade;
recursos.
Considere:
//EXECUTA JOB ...,CLASS=A
O job pertence à classe A.
Para que ele seja processado, deve existir um ambiente preparado para executar jobs dessa classe.
O initiator seleciona o job e inicia o processamento.
22. O que acontece quando o step começa?
Para:
//STEP01 EXEC PGM=PGMCLI01
o sistema precisa realizar diversas ações.
Interpretar o step.
Processar parâmetros.
Alocar DD statements.
Verificar datasets.
Localizar o módulo executável.
Preparar o ambiente de execução.
Carregar o programa.
Inicializar o runtime.
Entregar o controle ao programa.
Acompanhar seu término.
Registrar o return code.
Liberar recursos.
Decidir se o próximo step será executado.
Quando o programador vê apenas:
STEP01 RC=0000
toda essa infraestrutura já trabalhou nos bastidores.
23. Alocação de datasets
Antes da execução, o sistema precisa alocar os recursos descritos no JCL.
Exemplo:
//ENTRADA DD DISP=SHR,
// DSN=EMPRESA.ARQ.ENTRADA
O z/OS verifica elementos como:
existência;
disponibilidade;
catálogo;
volume;
disposição;
compartilhamento;
segurança;
atributos;
conflitos.
Se outro job mantiver um dataset com uso exclusivo, o job atual poderá aguardar.
Por isso, um job pode ficar em estados de espera mesmo antes de iniciar o programa COBOL.
24. O significado de DISP
O parâmetro DISP ajuda a indicar como um dataset será tratado.
Exemplo:
DISP=SHR
Indica compartilhamento.
Outro exemplo:
DISP=OLD
Pode indicar uso exclusivo.
Também é comum:
DISP=(NEW,CATLG,DELETE)
Isso pode significar:
O JCL participa diretamente da governança dos dados utilizados pelo programa.
25. O loader
Depois que o módulo foi localizado, entra em cena o mecanismo de carga.
O loader coloca o programa no ambiente de memória apropriado.
Ele precisa:
localizar o módulo;
interpretar sua estrutura;
disponibilizar suas seções;
resolver elementos necessários em runtime;
preparar o ponto de entrada;
transferir o controle.
O módulo estava armazenado em disco.
Agora precisa ficar acessível para execução.
Essa passagem é:
Load library
↓
Loader
↓
Memória
↓
Execução
26. O que significa carregar em memória?
Quando dizemos que o programa foi carregado, não significa necessariamente que todo o universo da aplicação foi copiado como um único bloco simples.
O ambiente pode envolver:
O z/OS gerencia memória virtual.
O programa trabalha com endereços virtuais dentro de seu address space.
O sistema operacional administra a relação entre memória virtual, real storage e armazenamento auxiliar.
27. O address space
Um address space é um ambiente de endereçamento no qual programas e tarefas executam.
Um job batch normalmente recebe um address space para sua execução.
Started tasks, regiões CICS, regiões IMS, Db2 e outros subsistemas também possuem seus próprios ambientes.
O address space ajuda a fornecer isolamento.
Um programa em um job não deveria acessar livremente a memória de outro job.
Isso é fundamental para:
segurança;
estabilidade;
confiabilidade;
proteção;
recuperação.
28. O Language Environment entra em cena
Programas COBOL modernos normalmente utilizam o Language Environment.
Ele fornece serviços comuns para várias linguagens.
Entre suas funções estão:
Antes de o primeiro parágrafo COBOL realmente executar, o runtime pode precisar preparar o ambiente.
No final, o Language Environment também participa da finalização.
Por isso, muitas falhas aparecem acompanhadas de mensagens iniciadas por:
CEE
29. O programa recebe o controle
Depois da preparação, o controle é transferido para o ponto de entrada do módulo.
Em um programa COBOL, o processamento começa conforme a estrutura gerada pelo compilador.
A lógica da PROCEDURE DIVISION passa a executar.
Exemplo:
PROCEDURE DIVISION.
PERFORM INICIALIZAR
PERFORM PROCESSAR
PERFORM FINALIZAR
GOBACK.
Nesse momento, as instruções COBOL já foram transformadas.
A CPU não enxerga:
PERFORM PROCESSAR
Ela enxerga instruções de máquina.
30. A CPU não entende COBOL
A CPU do IBM Z executa instruções da arquitetura.
Ela não interpreta diretamente:
MOVE
READ
COMPUTE
EVALUATE
PERFORM
Esses comandos existiam apenas no fonte.
O compilador transformou a lógica em instruções de máquina.
Portanto:
COBOL → linguagem humana estruturada
Objeto → representação intermediária
Load → módulo executável
CPU → instruções de máquina
Essa abstração permite que o programador pense em regras de negócio, e não em registradores e opcodes durante todo o tempo.
31. A CPU não fica dedicada ao programa
Em um sistema multiprogramado, diversos trabalhos competem por recursos.
O programa não recebe necessariamente uma CPU exclusiva até terminar.
O sistema operacional pode alternar entre unidades de trabalho.
Enquanto um programa está pronto para executar, ele pode receber tempo de processador.
Quando aguarda um recurso, outra tarefa pode utilizar a CPU.
Esse mecanismo permite que milhares de trabalhos coexistam.
32. O dispatcher
O dispatcher é responsável por entregar capacidade de processador a unidades de trabalho elegíveis.
Ele considera prioridades e estados.
Uma tarefa pode estar:
executando;
pronta;
aguardando;
bloqueada;
suspensa;
terminada.
Quando a tarefa está aguardando uma leitura, uma resposta Db2 ou outro recurso, ela não precisa ocupar a CPU.
Outra tarefa pode executar.
33. O papel do WLM
WLM significa Workload Manager.
Ele ajuda o z/OS a gerenciar cargas de trabalho com base em objetivos de serviço.
O WLM trabalha com conceitos como:
service classes;
goals;
importance;
performance periods;
workload classification;
response time;
velocity.
Em vez de administrar apenas prioridades fixas, o sistema pode considerar objetivos de negócio.
Por exemplo:
uma transação bancária online pode ter meta de resposta rápida;
um relatório batch noturno pode possuir janela de horas;
um processamento crítico de fechamento pode receber maior importância;
uma tarefa de baixa prioridade pode aguardar mais tempo.
O WLM ajuda o sistema a decidir onde a capacidade será mais importante.
34. JES2 não escolhe diretamente a instrução que vai para a CPU
É importante separar responsabilidades.
JES2
Administra jobs, filas, spool e fluxo batch.
Initiator
Seleciona e inicia jobs elegíveis.
z/OS
Gerencia execução, memória, tarefas e recursos.
WLM
Ajuda a orientar objetivos e importância.
Dispatcher
Entrega capacidade de processador às unidades de trabalho.
CPU
Executa instruções de máquina.
Portanto, não é correto dizer simplesmente:
O JES2 executa o COBOL na CPU.
Uma descrição melhor seria:
O JES2 administra o job, o initiator inicia o step, o z/OS prepara o ambiente e o dispatcher permite que a CPU execute as instruções do programa.
35. O programa faz uma leitura
Considere:
READ ARQ-CLIENTES
Para o programador, é uma única instrução.
Por trás dela, podem participar:
runtime COBOL;
QSAM ou VSAM;
buffers;
sistema de arquivos;
canais;
controladores;
armazenamento;
cache;
memória;
interrupções;
scheduler;
dispositivos.
A aplicação solicita a leitura.
O sistema inicia o acesso.
Enquanto os dados não estão disponíveis, a tarefa pode entrar em espera.
A CPU fica livre para outro trabalho.
Quando a operação termina, a tarefa volta a ficar elegível.
36. Tempo de CPU não é tempo decorrido
Imagine um job que inicia às 01:00 e termina às 01:10.
Tempo decorrido:
10 minutos
Porém, o job pode ter utilizado apenas:
30 segundos de CPU
O restante pode ter sido espera por:
leitura de arquivos;
escrita;
Db2;
IMS;
Adabas;
locks;
filas;
rede;
ENQs;
recursos compartilhados;
armazenamento.
Por isso:
Elapsed time ≠ CPU time
Essa diferença é essencial em análise de performance.
37. Um programa lento pode não estar consumindo CPU
Quando um job demora, o iniciante pode pensar:
A CPU está lenta.
Mas o problema pode estar em:
O diagnóstico exige observar onde o tempo está sendo gasto.
38. Execução de um programa Db2
Um programa Db2 possui pelo menos dois componentes essenciais:
Load module
Package Db2
Durante a execução:
O load é localizado.
O programa inicia.
A interface Db2 é acionada.
A conexão com o subsistema é utilizada.
O package correspondente é localizado.
O SQL é executado.
O Db2 acessa tabelas e índices.
Os dados retornam às host variables.
A SQLCA recebe o resultado.
O programa continua.
Se o load existir, mas o package estiver ausente ou inválido, a execução pode falhar.
O executável COBOL e o artefato Db2 precisam estar alinhados.
39. O Db2 pode fazer o programa esperar
Imagine:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA = :WS-CONTA
END-EXEC.
Se outro processo mantém um lock incompatível, o programa pode esperar.
Durante essa espera, ele não está necessariamente consumindo CPU.
O tempo decorrido aumenta.
O consumo de CPU pode permanecer baixo.
Essa situação reforça a diferença entre processamento e espera.
40. Execução de um programa CICS
Um programa CICS normalmente não é iniciado por um novo job para cada transação.
A região CICS já está ativa como um ambiente de longa duração.
Quando uma transação é solicitada:
O CICS identifica a transação.
Verifica segurança.
Localiza a definição.
Identifica o programa inicial.
Cria uma task.
Carrega o módulo, se necessário.
Entrega o controle.
Processa comandos EXEC CICS.
Gerencia recursos.
Finaliza ou suspende a task.
O JES2 pode ter participado da inicialização da região CICS.
Porém, cada transação não é um job batch independente.
41. A biblioteca DFHRPL
Programas CICS precisam estar disponíveis em bibliotecas acessíveis à região.
Tradicionalmente, a concatenação DFHRPL participa desse processo.
Se o módulo novo foi gravado em uma biblioteca que não está acessível ao CICS, a região pode continuar usando outro load ou não localizar o programa.
Mesmo quando a biblioteca está correta, o CICS pode manter uma versão já carregada.
Pode ser necessário realizar ações como:
new copy;
phase-in;
refresh;
atualização do recurso;
implantação controlada.
Isso explica por que recompilar um programa CICS não garante que a nova versão já esteja em uso.
42. Reentrância e concorrência no CICS
Múltiplas tasks podem utilizar o mesmo programa.
Por isso, o módulo precisa ser adequado ao ambiente transacional.
Programas reentrantes podem compartilhar código de forma segura, desde que suas áreas mutáveis sejam tratadas corretamente.
Se um programa armazenar estado compartilhado de maneira inadequada, duas transações podem interferir entre si.
O resultado pode ser:
O CICS não é apenas uma forma de executar COBOL mais rapidamente.
Ele é um ambiente de alta concorrência e controle transacional.
43. Execução de um programa IMS
Programas IMS podem executar em regiões específicas, como:
O módulo COBOL precisa ser chamado com o ambiente correto.
Também dependem de artefatos como:
PSB;
PCB;
DBD;
definições IMS;
bibliotecas;
parâmetros.
Durante a execução, o programa faz chamadas DL/I.
O IMS navega pelos bancos hierárquicos ou filas de mensagens.
A PCB informa o resultado.
O COBOL continua executando a regra de negócio.
44. Execução de um programa Adabas
Um programa COBOL Adabas utiliza interfaces de comunicação para enviar comandos ao Nucleus.
Durante a execução:
O módulo COBOL é carregado.
A interface Adabas é acionada.
Control block e buffers são fornecidos.
A solicitação chega ao Nucleus.
O Adabas acessa o arquivo.
Os dados retornam ao programa.
O response code é analisado.
Assim como no Db2 e IMS, o programa pode aguardar a resposta do subsistema.
O tempo de CPU não representa sozinho todo o tempo da operação.
45. Chamadas dinâmicas durante a execução
Na terceira parte, vimos chamadas dinâmicas.
Exemplo:
01 WS-PROGRAMA PIC X(08).
MOVE 'PGMVALID'
TO WS-PROGRAMA
CALL WS-PROGRAMA
USING AREA-DADOS.
Nesse caso, PGMVALID será procurado durante a execução.
O sistema precisa localizar o módulo nas bibliotecas disponíveis.
Se não encontrar, poderá ocorrer falha.
Isso significa que um programa pode iniciar corretamente e falhar somente quando chega a determinada chamada.
46. Carregamento de subprogramas
Quando o programa principal chama um módulo dinâmico, podem participar:
O subprograma pode ser carregado e mantido disponível conforme o ambiente.
Em CICS, o gerenciamento pertence à região.
Em batch, o runtime e o z/OS participam da carga.
47. CANCEL em COBOL
Em determinados cenários, o COBOL possui a instrução:
CANCEL 'PGMVALID'
Ela pode influenciar o estado de um programa chamado dinamicamente.
O uso precisa ser compreendido com cuidado.
Nem sempre é necessário ou desejável cancelar módulos após cada chamada.
Isso pode afetar:
O Padawan não deve utilizar CANCEL apenas por costume.
Precisa entender o ciclo de vida do módulo.
48. O programa termina
Um programa pode finalizar com:
STOP RUN
ou:
GOBACK
O comportamento depende do contexto.
Em um programa principal batch, STOP RUN encerra a execução do run unit.
Em subprogramas, GOBACK é frequentemente mais apropriado, pois devolve o controle ao chamador.
No final, o runtime e o z/OS precisam:
encerrar o programa;
fechar recursos;
registrar condições;
liberar storage;
devolver return code;
finalizar o step.
49. RETURN-CODE
COBOL permite definir o código de retorno do programa.
Exemplo:
MOVE 8 TO RETURN-CODE
GOBACK.
O JCL e o sistema podem utilizar esse valor para controlar steps posteriores.
Exemplo:
//STEP02 EXEC PGM=PGMREL01,
// COND=(4,LT)
A lógica de condições JCL precisa ser estudada com cuidado, pois sua leitura pode parecer invertida para iniciantes.
O importante aqui é entender:
O programa pode comunicar ao job se terminou com sucesso, advertência ou falha.
50. Return code não é abend
Um return code é uma finalização controlada.
Exemplo:
RC=0000
RC=0004
RC=0008
RC=0012
Um abend indica término anormal.
Exemplos:
S0C7
S0C4
S806
S013
Uxxxx
Diferença conceitual:
Return code → o programa terminou e devolveu um resultado
Abend → a execução foi interrompida de forma anormal
Um programa pode escolher retornar RC=8 após detectar uma condição de negócio.
Isso não é o mesmo que sofrer um abend.
51. Exemplos de abends
S0C7
Frequentemente associado a operação numérica com dados inválidos.
S0C4
Pode estar relacionado a acesso inválido à memória ou endereço incorreto.
S806
Módulo executável não encontrado.
S013
Pode estar relacionado a problemas com dataset, DCB ou abertura.
User Abend
Pode ser produzido pelo próprio programa ou por componentes da aplicação.
O diagnóstico precisa combinar:
mensagem;
dump;
step;
módulo;
offset;
dados;
contexto.
52. O dump
Quando um programa termina anormalmente, pode ser produzido um dump.
Ele ajuda a investigar:
módulo;
instrução;
registradores;
áreas de memória;
call stack;
condição;
offset;
campos;
runtime.
O dump não deve ser encarado como um amontoado de caracteres incompreensíveis.
Ele é uma fotografia técnica do momento da falha.
Com listagem de compilação, map e ferramentas adequadas, o profissional pode relacionar o offset à instrução COBOL correspondente.
53. O job pode ter vários steps
Exemplo:
//STEP01 EXEC PGM=PGMEXTR
//STEP02 EXEC PGM=PGMVALD
//STEP03 EXEC PGM=PGMREL
Um job pode representar uma cadeia.
STEP01 → extrai dados
STEP02 → valida
STEP03 → gera relatório
Cada step possui:
programa;
DD statements;
return code;
recursos;
condições.
Se um step falhar, os próximos podem ou não executar conforme as regras do JCL.
54. Datasets temporários entre steps
Um step pode produzir um dataset temporário:
//ARQTEMP DD DSN=&&TEMP,
// DISP=(NEW,PASS),
// UNIT=SYSDA,
// SPACE=(CYL,(5,5))
Outro step pode recebê-lo:
//ENTRADA DD DSN=&&TEMP,
// DISP=(OLD,DELETE)
Esse mecanismo permite conectar etapas.
Programa A
↓
Dataset temporário
↓
Programa B
O dataset existe durante o job e pode ser apagado ao final.
55. O job termina
Depois que todos os steps elegíveis terminam:
os recursos são liberados;
os datasets recebem disposição final;
as saídas permanecem no spool;
o JES2 registra o término;
o usuário pode consultar resultados.
O job pode aparecer como:
CC 0000
CC 0004
CC 0008
ABEND S0C7
JCL ERROR
Cada resultado aponta para uma fase diferente.
56. JCL ERROR
Um job pode falhar antes de executar qualquer programa.
Exemplos:
Nesse caso, não adianta revisar o COBOL.
O programa nem chegou a começar.
Novamente, diagnóstico significa identificar a fase.
57. A cadeia completa de execução
Vamos reunir tudo.
Load module na LOADLIB
↓
JCL é submetido
↓
JES2 recebe o job
↓
Job entra no spool
↓
JCL é interpretado
↓
Job aguarda na fila
↓
Initiator seleciona o job
↓
DD statements são alocados
↓
Módulo é localizado
↓
Loader carrega o programa
↓
Language Environment inicia o runtime
↓
Controle chega à PROCEDURE DIVISION
↓
Dispatcher entrega CPU
↓
Programa acessa QSAM, VSAM ou subsistemas
↓
Pode alternar entre execução e espera
↓
Programa termina
↓
Return code é registrado
↓
Saída volta ao spool
↓
Usuário consulta no SDSF
Essa é a verdadeira jornada do executável.
58. Da primeira linha ao último ciclo de CPU
Agora podemos visualizar a série completa.
Regra de negócio
↓
Fonte COBOL
↓
Copybooks
↓
Tradução CICS
↓
Processamento Db2
↓
Interfaces IMS ou Adabas
↓
Compilação
↓
Código objeto
↓
Binder
↓
Load module
↓
Load library
↓
JCL ou transação
↓
JES2 ou subsistema online
↓
Loader
↓
Memória
↓
Dispatcher
↓
CPU
↓
Dados e resultados
O programa não nasce quando é executado.
Sua história começou muito antes.
59. Uma analogia com um aeroporto
Imagine um aeroporto internacional.
O load module é o avião pronto no hangar.
O JCL é o plano de voo.
A load library é o hangar onde a aeronave está estacionada.
O JES2 é o centro que recebe planos de voo e organiza partidas.
O spool é o sistema onde ficam armazenados documentos, ordens e registros.
O initiator é a equipe que autoriza e prepara o voo.
Os DD statements representam combustível, bagagem, tripulação e rotas.
O loader retira o avião do hangar e o prepara para operar.
O z/OS é toda a administração do aeroporto.
O WLM ajuda a decidir quais voos são mais prioritários.
O dispatcher controla o uso das pistas.
A CPU é o motor que produz o movimento.
QSAM é como uma fila de cargas processadas em sequência.
VSAM é um depósito no qual uma caixa pode ser localizada por código.
Db2, IMS e Adabas são grandes centros especializados de dados.
O programa COBOL é o plano operacional que define o que deve acontecer durante a viagem.
Se uma única parte falhar, o voo pode atrasar, aguardar ou ser cancelado.
60. Diagnóstico por fase
Quando surgir um problema, pergunte em qual fase ele ocorreu.
O JCL foi aceito?
Se não, pode ser JCL ERROR.
O job iniciou?
Se não, pode estar aguardando classe, initiator ou recurso.
Os datasets foram alocados?
Se não, pode haver conflito, catálogo ou segurança.
O programa foi localizado?
Se não, pode ocorrer S806.
O programa iniciou?
Se sim, analise mensagens e runtime.
O arquivo abriu?
Verifique FILE STATUS.
O SQL executou?
Verifique SQLCODE e SQLSTATE.
O CICS respondeu?
Verifique RESP e RESP2.
O IMS retornou?
Verifique o status da PCB.
O Adabas respondeu?
Verifique o response code.
O programa terminou normalmente?
Verifique return code ou abend.
Essa sequência reduz a investigação aleatória.
61. Checklist de execução batch
Antes de executar, verifique:
O programa está na load library correta?
A STEPLIB aponta para essa biblioteca?
A ordem das bibliotecas está correta?
O membro possui o nome usado em PGM=?
Todos os DDNAMEs esperados estão presentes?
Os datasets existem?
O DISP é adequado?
Os atributos dos arquivos correspondem ao programa?
O usuário possui autorização?
O package Db2 está disponível?
O PSB IMS é o correto?
As interfaces Adabas estão acessíveis?
Os arquivos VSAM estão disponíveis?
Existe espaço para datasets de saída?
As condições entre steps estão corretas?
O job está na classe adequada?
62. Checklist depois da execução
Depois do job:
Qual foi o resultado geral?
Qual step falhou?
Houve return code ou abend?
O programa correto foi carregado?
Qual versão do load foi utilizada?
O arquivo foi realmente processado?
Quantos registros foram lidos?
Quantos foram gravados?
Houve rejeições?
O SQL retornou erros?
O relatório foi produzido?
O dataset de saída foi catalogado?
Existem mensagens no JESYSMSG?
Foi gerado dump?
O tempo foi de CPU ou espera?
A execução pode ser repetida com segurança?
63. Reprocessamento
Em ambiente corporativo, uma pergunta essencial é:
O job pode ser executado novamente?
Imagine que o programa debitou cem contas e sofreu abend na conta cento e um.
Se for reiniciado desde o começo, poderá debitar novamente as primeiras cem.
Por isso, aplicações batch precisam considerar:
checkpoints;
commits;
arquivos de controle;
chaves de reinício;
idempotência;
rollback;
recuperação;
reconciliação.
Compilar e executar é apenas parte da engenharia.
Executar com segurança é o verdadeiro desafio.
64. Commit e unidade de trabalho
Em programas Db2, o COMMIT confirma alterações.
Exemplo:
EXEC SQL
COMMIT
END-EXEC.
Se o programa atualiza milhões de linhas e faz commit somente no final, pode provocar:
Se fizer commit a cada registro, pode gerar:
O tamanho da unidade de trabalho precisa equilibrar:
integridade;
desempenho;
recuperação;
concorrência.
65. O JES2 não é apenas um entregador de jobs
Embora sua função seja diferente da CPU, o JES2 é essencial para a operação.
Ele fornece uma infraestrutura confiável para:
Sem esse gerenciamento, milhares de jobs batch disputariam recursos sem coordenação.
O JES2 transforma a execução batch em um processo industrial.
66. O mainframe não executa um programa isolado
Quando PGMCLI01 roda, ele depende de um ecossistema.
JCL
JES2
Spool
Initiator
z/OS
Loader
Language Environment
WLM
Dispatcher
CPU
Storage
QSAM
VSAM
Db2
CICS
IMS
Adabas
Segurança
Catálogo
Operação
O iniciante olha o código.
O especialista enxerga todos os contratos ao redor.
67. O papel da segurança
Antes de abrir um dataset ou acessar uma biblioteca, o sistema pode verificar autorização.
Podem estar envolvidos:
RACF;
SAF;
perfis;
grupos;
permissões;
acessos de leitura;
atualização;
execução;
controle de subsistemas.
Um programa pode existir e estar corretamente configurado, mas falhar porque o usuário ou started task não possui autorização.
Segurança não é uma camada colocada depois.
Ela participa da execução.
68. O catálogo
Datasets catalogados podem ser localizados por nome.
Quando o JCL informa:
DSN=EMPRESA.DADOS.CLIENTES
o sistema pode consultar o catálogo para descobrir onde o dataset está armazenado.
Sem catálogo ou volume informado, a localização pode falhar.
O catálogo funciona como um diretório de datasets.
Ele não contém necessariamente os dados do arquivo.
Contém informações para localizá-lo.
69. A diferença entre dataset e arquivo lógico
No COBOL:
SELECT ARQ-CLIENTES
Esse é o nome de arquivo dentro do programa.
No JCL:
//CLIENTES DD ...
Esse é o DDNAME.
No sistema:
EMPRESA.DADOS.CLIENTES
Esse é o nome do dataset.
Portanto:
ARQ-CLIENTES → nome COBOL
CLIENTES → DDNAME
EMPRESA.DADOS.CLIENTES → dataset
Esses três nomes podem ser diferentes.
Compreender essa cadeia evita muitos erros.
70. O programa executa em uma LPAR
Ambientes IBM Z podem ser divididos em LPARs.
LPAR significa Logical Partition.
Cada LPAR funciona como um sistema lógico separado, com seus próprios:
z/OS;
recursos;
configurações;
subsistemas;
workloads;
bibliotecas;
segurança.
O mesmo mainframe físico pode hospedar várias LPARs.
Por isso, um load presente em uma LPAR de teste não está automaticamente disponível em produção.
71. PR/SM e processadores lógicos
A virtualização do IBM Z permite que recursos físicos sejam compartilhados entre partições.
O PR/SM gerencia essa divisão.
O z/OS enxerga processadores lógicos disponíveis para sua LPAR.
O dispatcher entrega trabalho a esses processadores conforme a capacidade e as regras.
O programa COBOL não precisa conhecer esses detalhes para executar.
Mas o especialista em performance precisa compreender que existe uma cadeia entre:
Programa
z/OS
Processador lógico
LPAR
PR/SM
Processador físico
72. Tipos de processadores
No ecossistema IBM Z, diferentes categorias de processadores podem ser utilizadas conforme a carga.
Entre elas, podem aparecer conceitos como:
Um programa COBOL tradicional executa principalmente em processadores gerais, mas determinados componentes ou workloads podem utilizar processadores especializados.
O Padawan não precisa dominar todos neste primeiro momento.
Mas deve compreender que “a CPU” no mainframe é um universo mais sofisticado do que uma única peça física.
73. O resultado do programa
Depois de processar, o programa pode produzir:
dataset;
relatório;
atualização Db2;
registros VSAM;
mensagem;
saída no spool;
retorno a uma transação;
atualização IMS;
operação Adabas;
código de retorno.
O resultado precisa ser validado.
Um RC=0 não garante que o conteúdo do relatório esteja correto.
Assim como uma compilação bem-sucedida não garante lógica correta, uma execução normal não garante resultado de negócio correto.
74. Auditoria e rastreabilidade
Sistemas críticos precisam registrar:
quem executou;
quando;
qual versão;
quais arquivos;
quais parâmetros;
quantos registros;
quais erros;
quais retornos;
quais atualizações;
qual tempo;
qual consumo.
Isso permite:
investigação;
conformidade;
reconciliação;
recuperação;
análise de capacidade;
melhoria contínua.
O mainframe não é apenas uma máquina rápida.
É uma plataforma de controle.
75. O mapa completo das quatro partes
Parte I — Fonte e copybooks
Regra de negócio
↓
Fonte COBOL
↓
Copybooks
Parte II — Preparação dos subsistemas
EXEC CICS
EXEC SQL
IMS
Adabas
Parte III — Construção do executável
Compilação
↓
Código objeto
↓
Binder
↓
Load module
Parte IV — Execução
JCL
↓
JES2
↓
Initiator
↓
Loader
↓
Memória
↓
CPU
↓
Dados e resultados
Agora a jornada está completa.
76. Conselhos finais ao Programador COBOL Padawan
Nunca pense no programa apenas como um fonte.
Pergunte sempre:
Onde está o load?
Quem o gerou?
Quais copybooks foram utilizados?
Qual procedure foi executada?
Qual load library está sendo pesquisada?
Quais DDNAMEs o programa espera?
Quais datasets foram alocados?
O programa está esperando CPU ou I/O?
Qual subsistema está envolvido?
Qual código de retorno precisa ser analisado?
A execução é reiniciável?
O resultado é reconciliável?
A versão é rastreável?
O processo é seguro?
Essas perguntas são mais importantes do que decorar comandos isolados.
Conclusão
Nesta quarta parte, acompanhamos o programa COBOL desde a load library até a execução real.
Vimos que o JCL solicita ao sistema a execução do módulo.
A STEPLIB e outras bibliotecas ajudam o z/OS a localizar o executável.
Os DD statements conectam os nomes lógicos do programa aos datasets físicos.
QSAM permite o processamento sequencial.
VSAM oferece organizações e acessos mais estruturados, incluindo acesso por chave.
O JES2 recebe o job, administra filas e mantém entradas e saídas no spool.
O initiator seleciona o trabalho e inicia seus steps.
O loader coloca o módulo no ambiente de memória.
O Language Environment prepara o runtime.
O WLM ajuda a orientar objetivos de serviço.
O dispatcher entrega capacidade de processador.
A CPU executa as instruções de máquina produzidas pelo compilador.
Durante esse processo, o programa alterna entre uso de CPU e espera por arquivos, bancos, locks, mensagens e outros recursos.
Por isso, tempo de CPU e tempo total decorrido são conceitos diferentes.
Também aprendemos que CICS, Db2, IMS e Adabas possuem seus próprios ambientes de execução, mas todos dependem do mesmo princípio:
O COBOL executa a regra de negócio, enquanto o z/OS e seus subsistemas administram os recursos necessários.
Ao final dessa série, o Programador COBOL Padawan deixa de enxergar apenas:
STOP RUN.
e passa a enxergar toda a arquitetura ao redor:
Fonte
Copybook
Tradutor
Pré-compilador
Compilador
Objeto
Binder
Load
JCL
JES2
Spool
Loader
Memória
CPU
Dados
Resultado
É essa visão que separa quem apenas altera linhas de código de quem realmente compreende o funcionamento de uma aplicação corporativa no IBM Z.
Palavra final do Mestre Bellacosa
Quando alguém disser:
“Esse programa só lê um arquivo e grava outro”,
lembre-se de que por trás dessa frase existem bibliotecas, contratos, compiladores, módulos, filas, processadores, subsistemas, segurança, memória, canais de I/O e décadas de engenharia.
No mainframe, nada simplesmente acontece.
Cada execução é preparada, controlada, registrada e monitorada.
O Padawan vê uma linha de JCL.
O especialista vê uma cadeia completa de responsabilidades.
O Padawan vê um READ.
O especialista vê acesso lógico, buffer, I/O, espera e retorno.
O Padawan vê um RC=0.
O especialista pergunta se o resultado está correto, íntegro, rastreável e recuperável.
Essa é a verdadeira evolução no mundo COBOL.
Não basta saber escrever programas.
É preciso entender como eles nascem, como são transformados, como são carregados e como convivem com toda a arquitetura do IBM Z.
☕
“O código-fonte expressa a intenção. A compilação constrói a forma. A linkedição reúne as partes. O JES2 organiza a jornada. O z/OS governa os recursos. E a CPU transforma regras de negócio em realidade.”
