✨ 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.
Antes de declarar que o programa está pronto, verifique:
O fonte correto foi compilado?
Os copybooks corretos foram utilizados?
A biblioteca de copybooks estava na ordem certa?
Houve tradução CICS?
O SQL foi processado?
O DBRM foi gerado?
O package foi criado?
O compilador terminou com qual RC?
Existem warnings?
O Binder resolveu todas as referências?
O load foi gravado na biblioteca correta?
As chamadas são estáticas ou dinâmicas?
Os módulos chamados estão disponíveis?
A versão do load corresponde ao fonte?
Os testes foram executados?
A implantação utilizará a mesma load library?
Esse checklist evita muitos problemas que parecem misteriosos.
49. O grande mapa mental da Parte III
Podemos resumir toda a transformação:
Fonte preparado
↓
Compilador COBOL
↓
Validação
↓
Geração de instruções
↓
Código objeto
↓
Binder
↓
Resolução de referências
↓
Inclusão de módulos
↓
Definição do ponto de entrada
↓
Load module ou program object
↓
Load library
Em paralelo, quando houver Db2:
DBRM
↓
BIND
↓
Package
50. Uma analogia com uma fábrica
Imagine uma fábrica de automóveis.
O código-fonte é o projeto do veículo.
Os copybooks são padrões de componentes:
medidas;
conectores;
peças;
encaixes.
O compilador transforma o projeto em peças reais.
Ele produz:
motor;
chassis;
painel;
sistemas de controle.
Entretanto, as peças ainda estão separadas.
O Binder é a linha de montagem.
Ele reúne:
objeto principal;
módulos externos;
interfaces;
componentes;
pontos de entrada.
O resultado é o veículo montado.
A load library é o pátio onde os veículos prontos ficam armazenados.
Porém, o carro ainda não saiu do pátio.
Ele ainda precisa ser localizado, ligado e colocado na estrada.
Essa será a missão do próximo capítulo.
51. Conselhos do Mestre Bellacosa
Nunca trate a compilação como um botão misterioso.
Abra as listagens.
Leia as mensagens.
Entenda a procedure.
Descubra:
qual compilador foi utilizado;
quais opções foram aplicadas;
quais bibliotecas foram concatenadas;
quais copybooks foram encontrados;
quais módulos foram incluídos;
onde o objeto foi gravado;
onde o load foi criado;
quais referências foram resolvidas;
quais warnings foram emitidos.
O profissional que entende o processo de build investiga problemas com muito mais precisão.
Ele não diz apenas:
“A compilação falhou.”
Ele diz:
“O pré-processamento terminou corretamente, mas o Binder não resolveu o módulo estático porque a biblioteca de interfaces não estava na concatenação de SYSLIB.”
Esse é o tipo de compreensão que transforma um Padawan em especialista.
Conclusão
A compilação é o processo que transforma o código-fonte COBOL em código objeto.
Durante essa etapa, o compilador verifica sintaxe, campos, tipos de dados, referências, estruturas, opções e dependências.
O código objeto já contém instruções de máquina, mas ainda pode possuir referências externas.
Por isso, ele precisa passar pelo Binder.
A linkedição combina o objeto com módulos, interfaces e rotinas necessárias, resolvendo referências e criando um módulo executável.
Esse resultado é armazenado em uma load library.
Também aprendemos que chamadas podem ser estáticas ou dinâmicas.
Chamadas estáticas são resolvidas durante a linkedição.
Chamadas dinâmicas são localizadas durante a execução.
Vimos ainda que CICS, Db2, IMS e Adabas podem exigir interfaces específicas, e que o programa Db2 precisa coordenar dois artefatos fundamentais:
Load module
Package Db2
Ao final dessa etapa, o programa finalmente existe como executável.
Mas ele ainda está parado dentro de uma biblioteca.
Ele não abriu arquivos.
Não leu registros.
Não consultou tabelas.
Não consumiu CPU.
Não produziu relatórios.
A última etapa da jornada está prestes a começar.
No próximo capítulo
Na Parte IV — Da Load Library à CPU, vamos acompanhar o módulo durante a execução.
Veremos passo a passo:
como o JCL solicita a execução;
como a STEPLIB localiza o programa;
como QSAM e VSAM são conectados por DDNAME;
como o JES2 recebe e organiza o job;
o que é spool;
como o initiator inicia o processamento;
como o loader coloca o programa na memória;
como WLM e dispatcher participam;
como a CPU executa as instruções;
por que tempo de CPU é diferente de tempo decorrido;
como programas CICS, Db2, IMS e Adabas executam no ambiente real.
Prepare a quarta xícara de café.
O programa já nasceu, foi traduzido, compilado e linkedidado.
Agora chegou o momento de fazê-lo trabalhar.
☕
“O Padawan acredita que a compilação cria o programa. O especialista sabe que a compilação cria as peças, a linkedição monta a máquina e a execução provará se toda a engenharia realmente funciona.”
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
