✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e a compilaçao de um programa cobol
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL
A jornada completa do código-fonte até a CPU do IBM Z
Para quem está começando no universo mainframe, compilar um programa COBOL pode parecer uma tarefa simples:
Escrever o código
Compilar
Executar
Mas, no IBM Z, existe uma verdadeira cadeia industrial entre a primeira linha do fonte e o momento em que uma CPU começa a executar as instruções do programa.
O código pode depender de copybooks, comandos CICS, instruções SQL, chamadas IMS, interfaces Adabas, arquivos QSAM, clusters VSAM, bibliotecas de carga, JCL, JES2, Language Environment, memória e vários componentes do z/OS.
Por isso, dizer que um programa foi apenas “compilado e executado” é como afirmar que um avião simplesmente saiu do papel e começou a voar.
Entre o projeto e o voo existem dezenas de etapas.
Esta série em quatro capítulos foi criada para mostrar essa jornada completa de maneira progressiva, sempre pensando no Programador COBOL Padawan que deseja compreender não apenas como escrever código, mas como o mainframe realmente pensa.
O grande mapa da jornada
Antes de conhecer cada capítulo, observe o fluxo completo:
Regra de negócio
↓
Código-fonte COBOL
↓
Copybooks
↓
Tradução CICS
↓
Processamento Db2
↓
Interfaces IMS e 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, relatórios e resultados
Cada etapa possui uma responsabilidade específica.
Quando uma delas falha, o problema pode aparecer como:
erro de compilação;
erro de linkedição;
package Db2 inválido;
programa não encontrado;
arquivo ausente;
FILE STATUS;
SQLCODE;
erro CICS;
status IMS;
response code Adabas;
return code;
abend.
A melhor forma de investigar qualquer problema é descobrir em qual parte dessa cadeia ele ocorreu.
Parte I — O nascimento do programa COBOL
Código-fonte, bibliotecas e copybooks
O primeiro capítulo apresenta o ponto de partida: o código-fonte COBOL.
É nele que o programador transforma uma regra de negócio em instruções como:
MOVE
COMPUTE
PERFORM
READ
WRITE
CALL
Porém, o programa raramente vive sozinho.
Muitas aplicações utilizam copybooks para compartilhar:
layouts de arquivos;
registros;
áreas de comunicação;
constantes;
códigos de retorno;
estruturas de mensagens;
campos de tabelas;
contratos entre programas.
Um programa pode conter:
COPY CPYCLI01.
Durante o processo de compilação, o conteúdo desse copybook é incorporado logicamente ao fonte.
O capítulo também explica uma diferença fundamental:
COPY inclui fonte.
CALL executa outro programa.
Essa distinção é importante porque um copybook não é um módulo executável.
Ele é uma estrutura reutilizável inserida no programa durante sua preparação.
Outro ponto central é que o copybook funciona como um contrato.
Se dois programas compartilham uma área de memória, ambos precisam interpretar exatamente o mesmo layout.
Uma alteração feita sem análise de impacto pode provocar:
campos deslocados;
valores incorretos;
erros numéricos;
corrupção de dados;
abends;
falhas silenciosas.
A primeira parte também mostra como o compilador localiza copybooks por meio de bibliotecas associadas a DD statements como SYSLIB.
A ordem dessas bibliotecas pode determinar qual versão do copybook será utilizada.
Isso significa que até mesmo uma compilação com retorno zero pode gerar um programa incorreto caso tenha utilizado uma versão inadequada de determinada estrutura.
A jornada de um programa COBOL começa muito antes da execução.
Ela nasce na regra de negócio.
Ganha forma no código-fonte.
Reutiliza estruturas por meio de copybooks.
Conversa com CICS, Db2, IMS e Adabas.
É analisada pelo compilador.
Transforma-se em código objeto.
É reunida pelo Binder.
Torna-se um módulo executável.
É armazenada em uma load library.
Depois, um JCL, uma transação ou um subsistema solicita sua execução.
O JES2 administra o job.
O initiator inicia os steps.
O loader coloca o programa em memória.
O z/OS gerencia recursos.
O WLM orienta prioridades.
O dispatcher entrega capacidade de processamento.
A CPU executa as instruções.
QSAM, VSAM, Db2, IMS, CICS e Adabas fornecem os dados e serviços necessários.
Por fim, o programa produz relatórios, atualizações, mensagens, arquivos e resultados de negócio.
Nada simplesmente “roda”.
Tudo é preparado, ligado, controlado, carregado, executado e registrado.
☕
“O Padawan observa o código-fonte. O especialista acompanha toda a jornada, desde o primeiro COPY até o último ciclo de CPU.”
Laboratório Forense Bellacosa Mainframe
CSI z/OS:
Da Compilação à Execução
de um Programa COBOL
Cinco arquivos de evidências revelam como o código-fonte COBOL
atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load
library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.
CASO: COBOL-2022-EXECEVIDÊNCIAS: 05 ARTIGOSAMBIENTE: IBM Z / z/OSSTATUS: ARQUIVO ABERTO
Esta investigação técnica apresenta o ciclo completo de um
programa COBOL no mainframe IBM Z. A série explica o
nascimento do código-fonte, o uso de copybooks, a preparação de comandos
CICS e SQL, a geração de código objeto, a atuação do Binder, o
armazenamento em load libraries e a execução por JCL, JES2, loader,
Language Environment, dispatcher e CPU. Selecione uma evidência abaixo
para ler o artigo correspondente dentro do visualizador.
Evidência selecionada
Parte I — Código-fonte, bibliotecas e copybooks
A primeira parte acompanha a transformação da regra de negócio em
código-fonte COBOL, explica o papel das bibliotecas e mostra por que
copybooks funcionam como contratos de dados compartilhados entre
programas.
Bellacosa Mainframe apresenta compilando e executando programa cobol
☕ 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:
CICS;
Db2;
IMS;
Adabas.
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.
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.
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.
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.
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:
receber jobs;
armazenar entrada;
organizar filas;
considerar classes;
controlar prioridades;
administrar spool;
acompanhar saída;
direcionar impressão;
reter resultados;
fornecer informações ao operador.
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.
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:
sintaxe JCL incorreta;
parâmetro inválido;
procedure não encontrada;
dataset mal definido;
DD duplicado;
erro de referência;
nome inválido.
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:
locks prolongados;
consumo de log;
dificuldade de recuperação;
impacto em concorrência;
rollback gigantesco.
Se fizer commit a cada registro, pode gerar:
excesso de overhead;
unidades muito pequenas;
dificuldade de garantir consistência lógica.
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:
receber trabalhos;
manter filas;
separar classes;
priorizar;
reter saída;
reexecutar;
integrar impressão;
fornecer rastreabilidade;
apoiar operação.
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.
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:
CP;
zIIP;
IFL;
ICF;
SAP.
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.”
Laboratório Forense Bellacosa Mainframe
CSI z/OS:
Da Compilação à Execução
de um Programa COBOL
Cinco arquivos de evidências revelam como o código-fonte COBOL
atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load
library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.
CASO: COBOL-2022-EXECEVIDÊNCIAS: 05 ARTIGOSAMBIENTE: IBM Z / z/OSSTATUS: ARQUIVO ABERTO
Esta investigação técnica apresenta o ciclo completo de um
programa COBOL no mainframe IBM Z. A série explica o
nascimento do código-fonte, o uso de copybooks, a preparação de comandos
CICS e SQL, a geração de código objeto, a atuação do Binder, o
armazenamento em load libraries e a execução por JCL, JES2, loader,
Language Environment, dispatcher e CPU. Selecione uma evidência abaixo
para ler o artigo correspondente dentro do visualizador.
Evidência selecionada
Parte I — Código-fonte, bibliotecas e copybooks
A primeira parte acompanha a transformação da regra de negócio em
código-fonte COBOL, explica o papel das bibliotecas e mostra por que
copybooks funcionam como contratos de dados compartilhados entre
programas.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
