✨ 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 uma jornada rumo ao mainframe parte iii
☕ Um Café no Bellacosa Mainframe
🚀 Quer Começar uma Carreira em IBM Mainframe?
Parte III — Da Academia da Frota Estelar ao Convés da USS Enterprise: Como Construir sua Carreira no Universo IBM Z
"O conhecimento é a única riqueza que aumenta quando compartilhada." — Inspirado na filosofia de Jornada nas Estrelas
Chegamos à Última Etapa da Missão
Ao longo desta série você descobriu que aprender Mainframe é muito mais do que dominar uma linguagem de programação.
Na Parte 1, conhecemos os melhores cursos gratuitos da IBM e da comunidade para iniciar a jornada.
Na Parte 2A, exploramos os pilares do IBM Z: z/OS, COBOL, JCL, QSAM, VSAM e TSO/ISPF.
Na Parte 2B, entendemos como Db2, CICS, IMS, RACF, APIs, Git, DevOps, Zowe e a modernização trabalham em conjunto.
Agora chega o momento mais importante.
Como transformar todo esse conhecimento em uma carreira?
O Maior Erro dos Iniciantes
Quase todo Programador COBOL Padawan acredita que precisa aprender tudo antes de procurar uma vaga.
Esse pensamento costuma gerar ansiedade e, muitas vezes, paralisa o aprendizado.
A realidade é diferente.
Empresas esperam que profissionais em início de carreira tenham uma boa base técnica, curiosidade, capacidade de aprender e disposição para evoluir. Ninguém domina todo o ecossistema IBM Z logo no começo.
O Caminho do Padawan
Imagine que você entrou hoje na Academia da Frota Estelar.
No primeiro dia ninguém entrega a você o comando da Enterprise.
Primeiro você aprende:
disciplina;
fundamentos;
protocolos;
prática.
Depois vem a especialização.
Com Mainframe acontece exatamente a mesma coisa.
Um Plano de Estudos de 12 Meses
Não existe um único caminho, mas uma sequência progressiva ajuda bastante.
Meses 1 e 2 — Conhecendo a Nave
Objetivos:
Conceitos de Mainframe.
História do IBM Z.
Introdução ao z/OS.
IBM Mainframe Skills Depot.
IBM Z Xplore.
Learning COBOL Programming with VS Code.
O foco aqui é entender o ecossistema.
Meses 3 e 4 — Linguagem e Execução
Estude:
COBOL;
JCL;
datasets;
TSO/ISPF;
QSAM;
VSAM.
Comece a escrever pequenos programas.
Leia exemplos.
Altere códigos existentes.
Aprenda fazendo.
Meses 5 e 6 — Dados
Agora mergulhe em:
SQL;
Db2;
cursores;
índices;
joins;
normalização;
desempenho.
Uma boa base em SQL abre portas tanto no Mainframe quanto em outras plataformas.
Meses 7 e 8 — Processamento Online
Hora de estudar:
CICS;
COMMAREA;
transações;
mapas BMS;
integração entre COBOL e Db2.
É aqui que muitos sistemas bancários ganham vida.
Meses 9 e 10 — Segurança e Administração
Conheça:
RACF;
usuários;
grupos;
permissões;
logs;
auditoria;
conceitos de administração do z/OS.
Mesmo desenvolvedores se beneficiam ao entender como a segurança funciona.
Meses 11 e 12 — O Mainframe Moderno
Agora amplie seu horizonte:
Git;
DevOps;
Zowe;
APIs REST;
z/OS Connect;
automação;
conceitos de nuvem híbrida.
Você perceberá que o IBM Z está totalmente integrado ao desenvolvimento moderno.
O Poder dos Badges
Hoje, aprender não significa apenas concluir cursos.
Muitas plataformas oferecem badges digitais, que registram oficialmente suas conquistas.
Eles podem ser exibidos em:
LinkedIn;
currículo;
portfólio;
perfis profissionais.
Mais importante do que a quantidade é a coerência das trilhas concluídas.
Aprenda na Prática
Não espere conseguir um emprego para praticar.
Você pode:
resolver desafios do IBM Z Xplore;
acompanhar workshops;
ler IBM Redbooks;
estudar exemplos;
participar de comunidades;
reproduzir exercícios.
A prática constante transforma teoria em experiência.
O Valor da Comunidade
Uma das maiores riquezas do universo Mainframe é sua comunidade.
Participe de:
grupos técnicos;
eventos;
webinars;
encontros;
fóruns;
comunidades online.
Além de aprender, você amplia sua rede de contatos e conhece profissionais experientes.
Ensine o Que Você Aprende
Existe um segredo que poucos descobrem cedo:
Quando você explica um assunto para outra pessoa, também aprofunda o próprio entendimento.
Escreva artigos.
Compartilhe dicas.
Publique pequenos exemplos.
Responda dúvidas.
Você estará fortalecendo tanto a comunidade quanto seu próprio conhecimento.
Monte um Pequeno Portfólio
Mesmo sem experiência profissional, é possível criar um portfólio demonstrando sua evolução.
Inclua, por exemplo:
programas COBOL simples;
exercícios de SQL;
JCLs comentados;
pequenos projetos;
resumos de cursos;
badges conquistados.
Esse material mostra dedicação e interesse contínuo.
A Importância da Curiosidade
Os melhores profissionais raramente estudam apenas aquilo que foi solicitado.
Eles fazem perguntas como:
Como isso funciona internamente?
Por que essa tecnologia foi criada?
Existe outra forma de resolver o problema?
Como essa solução evoluiu ao longo do tempo?
Essa curiosidade constrói uma base sólida para decisões técnicas futuras.
Aprenda a Ler Documentação
Muitos iniciantes evitam a documentação oficial.
No entanto, ela costuma responder dúvidas com precisão e profundidade.
Comece por materiais introdutórios e avance gradualmente.
Ler documentação é uma habilidade tão importante quanto programar.
Curiosidades Bellacosa
Muitos profissionais que trabalham com IBM Z começaram em outras áreas da TI.
COBOL continua evoluindo e recebe novos recursos em suas versões atuais.
IDEs modernas convivem com a tradicional interface 3270.
Git, APIs, containers e práticas DevOps já fazem parte do cotidiano de muitos ambientes IBM Z.
Grandes instituições valorizam profissionais capazes de conectar conhecimento tradicional com tecnologias modernas.
Easter Egg da Série 🖖
Se esta jornada fosse um episódio de Star Trek, você provavelmente começou como um cadete chegando à Academia.
Na Parte 1, recebeu seu uniforme.
Na Parte 2, conheceu a engenharia da nave.
Agora, na Parte 3, finalmente entende que ninguém conduz uma missão sozinho.
A Enterprise depende do trabalho coordenado de toda a tripulação.
O IBM Z também.
Desenvolvedores, administradores, especialistas em banco de dados, segurança, operações e arquitetura colaboram para manter aplicações críticas funcionando com eficiência.
Conselhos do Sr. Spock para um Programador COBOL Padawan
Estude um pouco todos os dias.
Não compare seu início com a experiência de um veterano.
Ao longo das últimas décadas, o IBM Z incorporou diversas tecnologias sem abandonar sua principal característica: confiabilidade.
Hoje é comum encontrar ambientes que combinam:
aplicações COBOL;
APIs REST;
microsserviços;
Linux on Z;
automação;
integração contínua;
Inteligência Artificial;
observabilidade.
Isso mostra que o Mainframe continua evoluindo para atender novas demandas do mercado.
Mensagem Final do Capitão Picard
Imagine que esta série termina com a Enterprise entrando em velocidade de dobra.
Você observa pela janela da ponte enquanto as estrelas se alongam.
Percebe então que o destino nunca foi o mais importante.
O verdadeiro aprendizado aconteceu durante a viagem.
Com o IBM Mainframe ocorre exatamente o mesmo.
Não tenha pressa para dominar todas as tecnologias.
Construa uma base sólida.
Pratique.
Compartilhe.
Aprenda continuamente.
Cada programa COBOL escrito, cada JCL executado, cada consulta SQL criada e cada problema resolvido representam mais um passo na construção da sua experiência.
Conclusão da Série
Parabéns! Você concluiu esta jornada introdutória pelo universo IBM Mainframe. Vimos que a carreira vai muito além do COBOL: envolve compreender o funcionamento do z/OS, dominar JCL, QSAM, VSAM, explorar Db2, CICS, IMS, conhecer RACF, utilizar Git, Zowe, APIs e adotar práticas de DevOps e modernização. Também aprendemos que a formação não termina ao concluir um curso — ela continua por meio da prática, da documentação, das comunidades técnicas e da troca constante de conhecimento.
O IBM Z continua sendo uma plataforma estratégica para organizações do mundo inteiro porque alia estabilidade, segurança e evolução contínua. Para o Programador COBOL Padawan, a missão é clara: estudar os fundamentos, praticar com consistência, manter a curiosidade viva e evoluir passo a passo. Assim como na Frota Estelar, grandes profissionais não surgem de um único treinamento, mas de uma sequência de missões bem executadas.
Vida longa e próspera na sua jornada pelo universo IBM Mainframe! 🖖☕
------------
☕ Um Café no Bellacosa Mainframe
🚀 Quer Começar uma Carreira em IBM Mainframe?
Navegue pelas quatro partes da série e acompanhe a jornada do
Programador COBOL Padawan, dos primeiros cursos até a construção
de uma carreira no universo IBM Z.
Parte I
Os primeiros passos do Programador COBOL Padawan
Cursos gratuitos, IBM Z Xplore, Skills Depot e as primeiras
coordenadas para entrar no universo Mainframe.
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
