✨ 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
O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita
“Quando o REXX toca no disco, o EXECIO está por trás.
E quando o disco fica lento, geralmente é culpa de quem não entendeu o EXECIO.”
🧠 Introdução – Onde o REXX encontra o mundo real
REXX é excelente para controle, decisão e orquestração.
Mas em algum momento ele precisa fazer o que todo batch faz desde 1964:
👉 Ler dados
👉 Escrever dados
É aí que entra o EXECIO.
Simples no nome.
Perigoso no impacto.
🕰️ Origem histórica – Por que o EXECIO nasceu?
Antes do EXECIO:
REXX era fortemente interativo
I/O era dependente de comandos externos
Ler arquivos sequenciais era lento e improvisado
Com a popularização do REXX no TSO/E e no batch, a IBM precisava de:
Um método padrão
Um comando eficiente
Compatível com DDNAME
Funcional tanto em TSO quanto em batch
Assim nasceu o EXECIO, no final dos anos 80, como ponte direta entre:
REXX ⇄ QSAM ⇄ MVS
📜 O que é EXECIO?
EXECIO é o comando REXX responsável por:
Ler registros de um DDNAME
Escrever registros em um DDNAME
Transferir dados entre datasets e variáveis REXX
Ele trabalha sempre com:
DDNAME alocado
Registros sequenciais
Stem variables
🧪 Sintaxe essencial
EXECIO <quantidade> DISKR <ddname> (STEM var.
EXECIO <quantidade> DISKW <ddname> (STEM var.
Exemplo básico:
EXECIO * DISKR SYSIN (STEM linhas.
Aqui:
* = todas as linhas
DISKR = leitura
SYSIN = DDNAME
linhas. = onde os dados vão morar
🧩 Curiosidades que pouca gente comenta
🧩 1. EXECIO não entende “arquivo”
Ele entende DDNAME.
Se o DDNAME não existe:
RC pode ser enganoso
O erro aparece em mensagem
GETMSG vira obrigatório
🧩 2. EXECIO * carrega tudo na memória
EXECIO * DISKR BIGFILE (STEM big.
Se o arquivo tem:
10 mil linhas → ok
1 milhão → boa sorte
EXECIO * é confortável… até não ser.
🧩 3. A variável .0 manda mais que você
Após leitura:
say linhas.0
Ela contém quantos registros foram lidos.
Ignorar .0 é convite a loop errado.
🥚 Easter Eggs técnicos
🥚 1. Leitura parcial estratégica
EXECIO 1 DISKR INDD (STEM linha.
Ótimo para:
Ler cabeçalhos
Identificar layout
Decidir processamento sem ler tudo
🥚 2. EXECIO + Data Stack
É possível combinar:
EXECIO
PUSH / QUEUE
PARSE PULL
Criando pipelines “à moda antiga”.
🥚 3. EXECIO em SYSREXX
No batch, EXECIO:
Roda sem terminal
Depende totalmente do JCL
É mais rápido
É mais perigoso
🧠 Exemplo prático – Batch inteligente
EXECIO * DISKR INPUT (STEM in.
DO i = 1 TO in.0
IF POS('ERRO', in.i) > 0 THEN DO
SAY 'Erro detectado na linha' i
EXIT 8
END
END
EXECIO in.0 DISKW OUTPUT (STEM in.
Esse REXX:
Lê
Analisa
Decide
Escreve
Tudo antes do COBOL rodar.
⚠️ Riscos reais do EXECIO
Arquivo grande → consumo de memória
DISKW sem controle → overwrite silencioso
DISKR sem validação → loop infinito
Falta de fechamento → dados inconsistentes
Boa prática Jedi
EXECIO 0 DISKW OUTDD
Força flush e fechamento correto.
🛡️ EXECIO e segurança
EXECIO respeita:
RACF
Permissões de dataset
Contexto do job
Mas:
REXX que escreve dados é tão poderoso quanto um utility IBM.
Controle de acesso é obrigatório.
☕ Comentário Bellacosa Mainframe
O EXECIO é o momento em que:
O REXX deixa de ser “script”
E passa a mexer em dados corporativos
Quem trata EXECIO como “detalhe”:
Cria batch frágil
Gera incidentes silenciosos
Descobre o erro em produção
EXECIO não é comando.
É compromisso com o dado.
🧠 Frase final para colar no monitor
Se o REXX leu, ele é responsável.
Se escreveu, ele é culpado até prova em contrário.
O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe.
Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço.
Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além.
#ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex
FUJIFILM Corporation e a IBM anunciaram o desenvolvimento de um sistema de armazenamento em fita nativo de 50 TB, apresentando a maior capacidade nativa de cartucho de fita de dados do mundo.
Em 08 de Abril de 1959, foi dado o pontapé inicial da criação do COBOL. Muita coisa aconteceu desde então, surgiu o armazenamento em cartão perfurado, tape, disco e cartridge, surgiram o qsam, vsam, db2. Acompanhe-nos e descubra mais
Bellacosa Mainframe executando cobol com db2 e qsam
☕ Um Café no Bellacosa Mainframe
COBOL, QSAM e Db2 sem Mistérios: a Jornada do Arquivo Sequencial até o INSERT na Tabela
Imagine a cena: madrugada no datacenter, luzes azuis refletindo nos corredores, o IBM Z trabalhando silenciosamente e, diante da tela 3270, um programador COBOL padawan observa um pequeno JCL.
Mas o verdadeiro mainframe nunca entrega todos os seus segredos de imediato.
Por trás dessas linhas existe uma cadeia completa de tecnologias:
JES2
↓
JCL
↓
IKJEFT01
↓
TSO Batch
↓
DSN Command Processor
↓
Db2 Attachment Facility
↓
PLAN
↓
PACKAGE
↓
Programa COBOL
↓
QSAM
↓
Arquivo sequencial
↓
INSERT no Db2
↓
COMMIT ou ROLLBACK
O JCL é pequeno, mas representa o último estágio de uma fábrica inteira de software. Antes de chegar a essa execução, alguém escreveu um programa COBOL, processou SQL pelo precompiler, compilou, linkeditou, gerou um load module, criou um DBRM, executou BIND PACKAGE, criou ou atualizou um PLAN e autorizou o usuário.
Vamos abrir cada porta desse templo tecnológico.
Bellacosa Mainframe executando um programa cobol db2 e qsam
1. Qual é a missão deste programa?
O próprio comentário do JCL entrega a missão:
//* PROGRAMA LE QSAM E INSERE TABELAS DB2
Em linguagem simples, o programa deverá:
abrir um arquivo sequencial;
ler cada registro;
separar os campos;
validar os dados;
executar um INSERT em uma tabela Db2;
tratar registros inválidos;
realizar COMMIT;
fechar o arquivo;
retornar um código ao sistema operacional.
Um fluxo provável seria:
Abrir arquivo LISTCOPAC
↓
Ler primeiro registro
↓
Registro válido?
┌────┴────┐
│ │
Sim Não
│ │
INSERT Registrar erro
│ │
└────┬────┘
↓
Atingiu intervalo de COMMIT?
↓
Executar COMMIT
↓
Ler próximo registro
↓
Fim do arquivo?
┌────┴────┐
│ │
Não Sim
│ │
Repetir COMMIT final
↓
Fechar arquivo
↓
GOBACK
Esse tipo de programa é muito comum em sistemas corporativos.
Ele pode carregar:
clientes;
contas;
pagamentos;
movimentações;
produtos;
contratos;
dados de interfaces;
informações recebidas de outros sistemas;
arquivos produzidos por plataformas distribuídas.
É uma ponte entre o mundo dos arquivos batch e o mundo relacional do Db2.
2. O papel do JES
Antes que qualquer programa seja executado, o job precisa ser entregue ao JES.
JES significa Job Entry Subsystem.
Em muitos ambientes z/OS utiliza-se o JES2. Ele recebe o JCL, analisa as instruções, prepara os recursos, controla a execução e organiza as saídas no spool.
Quando o programador digita:
SUB
no ISPF Edit, não está executando o COBOL diretamente.
Na realidade, está entregando um pedido ao JES:
“JES, aceite este conjunto de instruções, valide o JCL, encontre os recursos e execute os steps na ordem indicada.”
O JES então:
atribui um JOBID;
lê o JCL;
faz a conversão;
verifica procedimentos;
coloca o job na fila;
seleciona uma initiator;
executa os steps;
recolhe as mensagens;
grava os resultados no spool.
O nome mostrado na tela:
CATPGM1
é o nome do job.
O identificador:
JOB00056
é o JOBID atribuído pelo JES.
Esses dois nomes parecem semelhantes, mas representam coisas diferentes:
CATPGM1 = nome lógico fornecido no cartão JOB
JOB00056 = número atribuído pelo JES
3. A biblioteca JOBLIB
Na imagem existe:
//JOBLIB DD DSN=IBMUSER.CBL.LOADLIB,DISP=SHR
A JOBLIB define uma biblioteca de módulos executáveis para o job inteiro.
É como dizer:
“Ao procurar programas deste job, inclua esta biblioteca na busca.”
A biblioteca:
IBMUSER.CBL.LOADLIB
deve ser uma PDS ou PDSE contendo load modules ou program objects.
Um programa COBOL não é executado diretamente a partir do fonte:
Quando um step possui STEPLIB, ela normalmente substitui a JOBLIB para a busca de módulos naquele step.
Portanto, a existência de JOBLIB não significa que ela será usada pelo step EXECDB2.
Essa é uma daquelas curiosidades que derrubam muitos padawans.
O programador pensa:
“Meu programa está na JOBLIB, portanto será encontrado.”
Mas o sistema responde:
“Existe uma STEPLIB neste step. Minha busca seguirá outro caminho.”
No caso do JCL apresentado, o programa da aplicação é localizado por meio da cláusula:
LIB('ADCD.Z112.USERLOAD')
Isso evita que ele dependa da JOBLIB.
4. O step EXECDB2
//EXECDB2 EXEC PGM=IKJEFT01,DYNAMNBR=20
Essa linha cria um step chamado:
EXECDB2
O nome do step é escolhido pelo desenvolvedor.
Ele poderia ser:
//STEP01
//RUNCOB
//DB2RUN
//CARREGA
Um bom nome melhora a análise do spool.
Ao observar:
EXECDB2
já sabemos que aquele step provavelmente executará alguma coisa em um ambiente Db2.
A instrução:
EXEC PGM=IKJEFT01
determina o programa que o z/OS carregará inicialmente.
E aqui surge uma pergunta importante:
Por que o JCL não executa diretamente COBDB501?
Porque COBDB501 contém SQL estático e precisa executar conectado ao subsistema Db2. O IKJEFT01 cria o ambiente TSO batch, dentro do qual o command processor DSN estabelece essa conexão.
Assim, a sequência real é:
IKJEFT01
↓
Comando DSN
↓
DSN SYSTEM(DB9G)
↓
RUN PROGRAM(COBDB501)
5. O que é o IKJEFT01?
O IKJEFT01 é um programa do z/OS utilizado para executar comandos TSO em batch.
O TSO é normalmente associado ao trabalho interativo:
READY
O usuário digita comandos e recebe respostas.
Com IKJEFT01, não existe uma pessoa digitando os comandos. Eles são fornecidos por um dataset ou por dados instream no DD SYSTSIN.
Uma analogia Bellacosa:
TSO interativo é o Jedi no terminal;
IKJEFT01 é o droide que repete os comandos durante a madrugada;
SYSTSIN é o pergaminho com as ordens;
SYSTSPRT é o diário da missão.
O IKJEFT01 pode executar:
comandos TSO;
CLISTs;
execuções REXX;
comandos do Db2;
utilitários que dependem do ambiente TSO.
6. O parâmetro DYNAMNBR=20
DYNAMNBR=20
Esse parâmetro está relacionado ao número de alocações dinâmicas que o ambiente TSO pode utilizar.
Durante a execução, o IKJEFT01, o command processor DSN ou programas chamados podem precisar alocar datasets dinamicamente.
Exemplos:
bibliotecas;
arquivos temporários;
arquivos de controle;
mensagens;
datasets de trabalho.
O valor:
20
costuma ser suficiente para execuções simples.
Em ambientes maiores aparecem valores como:
DYNAMNBR=50
ou:
DYNAMNBR=100
Não significa que o sistema abrirá imediatamente 20 datasets. É uma capacidade reservada para o ambiente.
Um valor insuficiente pode provocar falhas de alocação em execuções mais complexas.
7. A STEPLIB do Db2
//STEPLIB DD DSN=DSN910.SDSNLOAD,DISP=SHR
A STEPLIB informa as bibliotecas usadas na procura dos programas daquele step.
A biblioteca:
DSN910.SDSNLOAD
contém módulos relacionados ao Db2.
Entre eles podem existir componentes necessários para:
iniciar o command processor DSN;
usar o TSO Attachment Facility;
conectar-se ao subsistema;
carregar rotinas internas;
interagir com os serviços Db2.
O nome DSN910 pode indicar uma instalação antiga, uma versão ou apenas uma convenção local.
Não devemos presumir que o nome da biblioteca representa exatamente a versão atual do Db2. Muitas instalações mantêm nomes históricos para evitar alterar centenas de JCLs.
Contudo, é essencial que essa biblioteca seja compatível com o subsistema usado.
O subsistema do exemplo é:
DB9G
Se a SDSNLOAD não for a correta, podem surgir:
mensagens de conexão;
módulo não encontrado;
falhas no attachment;
abends;
incompatibilidade de nível.
8. DISP=SHR
Tanto a JOBLIB quanto a STEPLIB e o arquivo de entrada utilizam:
DISP=SHR
O parâmetro DISP descreve o estado e o tratamento do dataset.
SHR significa que o dataset já existe e pode ser compartilhado.
Exemplo:
//STEPLIB DD DSN=DSN910.SDSNLOAD,DISP=SHR
Essa biblioteca poderá ser usada simultaneamente por vários jobs.
Isso é normal para load libraries, pois dezenas ou centenas de aplicações podem carregar módulos da mesma biblioteca.
No arquivo de entrada:
//LISTCOPAC DD DSN=INFEF00.COPIA.MUNDO,DISP=SHR
o SHR indica leitura compartilhada.
Se o programa estivesse atualizando diretamente um dataset, talvez fosse necessário:
DISP=OLD
Mas para leitura QSAM, SHR é a escolha mais comum.
9. O DD LISTCOPAC
//LISTCOPAC DD DSN=INFEF00.COPIA.MUNDO,DISP=SHR
Essa linha liga um nome lógico a um dataset físico.
O nome lógico é:
LISTCOPAC
O dataset físico é:
INFEF00.COPIA.MUNDO
No programa COBOL provavelmente existe:
SELECT ARQUIVO-COPAC
ASSIGN TO LISTCOPAC
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-FILE-STATUS.
O COBOL conhece o arquivo pelo nome lógico. O JCL informa qual dataset real será usado.
Essa separação é poderosa.
O mesmo programa pode processar arquivos diferentes sem precisar ser recompilado.
O sistema não precisa necessariamente ler um registro físico por operação de disco.
Ele pode ler um bloco contendo vários registros:
BLKSIZE=27900
Nesse caso, um bloco pode conter 279 registros de 100 bytes.
O programa continua pedindo um registro por vez, mas o QSAM já trouxe vários registros para a memória.
Essa é a magia silenciosa do buffering.
11. Exemplo de definição COBOL
Um arquivo poderia ter esta estrutura:
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT ARQ-COPAC
ASSIGN TO LISTCOPAC
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-FS-COPAC.
DATA DIVISION.
FILE SECTION.
FD ARQ-COPAC
RECORDING MODE IS F.
01 REG-COPAC.
05 CP-CODIGO PIC 9(05).
05 CP-NOME PIC X(40).
05 CP-PAIS PIC X(30).
05 CP-POPULACAO PIC 9(11).
05 FILLER PIC X(14).
O tamanho total seria:
5 + 40 + 30 + 11 + 14 = 100 bytes
Logo, o dataset deveria ter:
RECFM=FB
LRECL=100
Se o arquivo tiver LRECL=80, a definição estará incompatível.
O resultado pode ser:
erro de abertura;
registros truncados;
campos deslocados;
dados inválidos;
abend;
inserções incorretas no banco.
12. File Status: o sensor do arquivo
Todo programa COBOL profissional deveria usar FILE STATUS.
Exemplo:
01 WS-FS-COPAC PIC XX.
Após o OPEN:
OPEN INPUT ARQ-COPAC
IF WS-FS-COPAC NOT = '00'
DISPLAY 'ERRO NO OPEN DO ARQUIVO: ' WS-FS-COPAC
MOVE 12 TO RETURN-CODE
GOBACK
END-IF
Alguns estados comuns:
00 = operação concluída
10 = fim de arquivo
35 = arquivo não encontrado
39 = conflito de atributos
41 = arquivo já aberto
42 = arquivo não aberto
46 = tentativa inválida de READ
O status 39 merece atenção especial.
Ele pode ocorrer quando a definição física do arquivo não combina com o que o programa espera.
É o mainframe dizendo:
“Padawan, o arquivo existe, mas sua descrição não corresponde à realidade.”
13. O DD SYSTSPRT
//SYSTSPRT DD SYSOUT=*
O SYSTSPRT recebe mensagens do TSO e do command processor DSN.
É uma das saídas mais importantes para análise.
Ali podem aparecer:
início do DSN;
conexão com o subsistema;
processamento do comando RUN;
mensagens sobre PLAN;
falha na localização do programa;
retorno do ambiente Db2;
encerramento do command processor.
Quando o job falhar antes de entrar no programa COBOL, o SYSTSPRT deve ser uma das primeiras saídas examinadas.
14. O significado de SYSOUT=*
DD SYSOUT=*
Isso não significa “um arquivo chamado SYSOUT”.
SYSOUT=* envia a saída ao spool, usando normalmente a classe de saída definida pelo job.
Exemplo:
//SYSTSPRT DD SYSOUT=*
As mensagens poderão ser vistas no SDSF.
O asterisco significa, em termos práticos:
“Use a classe de saída padrão associada ao job.”
Também seria possível especificar uma classe:
//SYSTSPRT DD SYSOUT=X
A classe depende das regras da instalação.
15. O problema dos DDs duplicados
Na imagem aparecem duas linhas:
//SYSOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
Esse é um provável erro.
Dentro do mesmo step, dois DD statements não devem possuir o mesmo DDNAME dessa maneira.
Se o programa precisa de duas saídas, use nomes diferentes:
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
Ou:
//RELATORI DD SYSOUT=*
//ERROS DD SYSOUT=*
Os nomes devem corresponder ao que o programa espera.
Exemplo no COBOL:
SELECT ARQ-RELATORIO
ASSIGN TO RELATORI.
SELECT ARQ-ERROS
ASSIGN TO ERROS.
Na execução, o load module e o PACKAGE precisam pertencer à mesma geração lógica.
21. O clássico SQLCODE -818
O -818 ocorre quando o programa executável e o DBRM ou PACKAGE não possuem o mesmo consistency token.
Em linguagem Bellacosa:
O sabre de luz e o cristal kyber vieram de treinamentos diferentes.
Isso acontece quando:
o programa é precompilado;
é gerado um novo DBRM;
o COBOL é compilado;
o load module é atualizado;
o PACKAGE antigo continua no Db2.
Ou o contrário:
um novo PACKAGE é criado;
o load module antigo continua na loadlib.
Resultado:
SQLCODE -818
A correção normalmente exige refazer o ciclo com os mesmos artefatos:
PRECOMPILE
COMPILE
LINK-EDIT
BIND PACKAGE
22. O SQLCODE -805
O -805 também é extremamente comum.
Ele indica que o Db2 não encontrou o PACKAGE necessário.
Possíveis causas:
PACKAGE não bindado;
collection errada;
PLAN não contém a collection;
nome do programa diferente;
ambiente errado;
PACKAGE removido;
load module promovido sem o BIND correspondente.
A mensagem geralmente fornece informações sobre:
localização;
collection;
package;
consistency token.
Esses dados devem ser analisados cuidadosamente.
23. A cláusula LIB
LIB('ADCD.Z112.USERLOAD')
A cláusula LIB informa a biblioteca onde o programa deve ser localizado.
Portanto:
RUN PROGRAM(COBDB501)
PLAN(HERP0001)
LIB('ADCD.Z112.USERLOAD')
significa:
Execute o programa COBDB501, utilizando o PLAN HERP0001, procurando o módulo na biblioteca ADCD.Z112.USERLOAD.
Essa instrução é importante porque a STEPLIB contém apenas a biblioteca Db2.
Sem a cláusula LIB, o programa da aplicação talvez não fosse encontrado.
Atenção à biblioteca antiga
A imagem também mostra:
//JOBLIB DD DSN=IBMUSER.CBL.LOADLIB,DISP=SHR
Temos então duas bibliotecas que podem conter o programa:
IBMUSER.CBL.LOADLIB
ADCD.Z112.USERLOAD
É importante confirmar onde está a versão correta.
Talvez exista:
IBMUSER.CBL.LOADLIB(COBDB501)
e também:
ADCD.Z112.USERLOAD(COBDB501)
Se a versão nova foi gravada na primeira biblioteca, mas o comando RUN aponta para a segunda, o job continuará executando o programa antigo.
Esse é um easter egg clássico do mainframe:
O código está correto, a compilação terminou com RC 0, mas o comportamento não mudou porque o job está carregando outra cópia do programa.
Para investigar, use ISPF 3.4 e compare:
data;
hora;
tamanho;
atributos;
usuário da última alteração.
24. O hífen de continuação
PLAN(HERP0001) -
O hífen informa que o comando continua na linha seguinte.
A continuação é:
LIB('ADCD.Z112.USERLOAD')
Sem o hífen, o DSN poderia tratar a primeira linha como um comando completo e a segunda como outro comando.
Uma versão bem formatada seria:
RUN PROGRAM(COBDB501) -
PLAN(HERP0001) -
LIB('ADCD.Z112.USERLOAD')
O estilo depende do padrão da empresa, mas a legibilidade melhora bastante.
25. O comando END
O JCL da imagem não apresenta explicitamente:
END
É recomendável encerrar a sessão DSN:
//SYSTSIN DD *
DSN SYSTEM(DB9G)
RUN PROGRAM(COBDB501) PLAN(HERP0001) -
LIB('ADCD.Z112.USERLOAD')
END
/*
O fim do arquivo de comandos pode encerrar o command processor, mas o END deixa a intenção explícita.
É uma boa prática.
26. Exemplo completo de JCL corrigido
//CATPGM1 JOB (ACCT),'CARGA COBOL DB2',
// CLASS=A,
// MSGCLASS=X,
// MSGLEVEL=(1,1),
// NOTIFY=&SYSUID
//*
//*-------------------------------------------------------------------*
//* PROGRAMA COBOL LE ARQUIVO QSAM E INSERE DADOS NO DB2
//*-------------------------------------------------------------------*
//EXECDB2 EXEC PGM=IKJEFT01,DYNAMNBR=20
//*
//* MODULOS DO DB2
//*
//STEPLIB DD DSN=DSN910.SDSNLOAD,DISP=SHR
//*
//* ARQUIVO SEQUENCIAL DE ENTRADA
//*
//LISTCOPAC DD DSN=INFEF00.COPIA.MUNDO,DISP=SHR
//*
//* SAIDAS DO AMBIENTE E DO PROGRAMA
//*
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
//*
//* COMANDOS TSO E DB2
//*
//SYSTSIN DD *
DSN SYSTEM(DB9G)
RUN PROGRAM(COBDB501) PLAN(HERP0001) -
LIB('ADCD.Z112.USERLOAD')
END
/*
//
27. Explicação do cartão JOB
//CATPGM1 JOB (ACCT),'CARGA COBOL DB2',
CATPGM1 é o nome do job.
(ACCT)
representa informações contábeis da instalação.
'CARGA COBOL DB2'
é uma descrição.
CLASS=A
CLASS=A
Define a classe de execução.
A classe pode determinar:
prioridade;
initiator;
limites;
ambiente;
políticas de scheduling.
O significado de A varia conforme a instalação.
MSGCLASS=X
MSGCLASS=X
Define a classe das mensagens de saída.
Ela influencia onde e como o spool será tratado.
MSGLEVEL=(1,1)
MSGLEVEL=(1,1)
Controla o nível de detalhes registrado no spool.
O primeiro valor controla a impressão das instruções JCL.
O segundo controla mensagens de alocação e execução.
NOTIFY=&SYSUID
NOTIFY=&SYSUID
Solicita que o usuário que submeteu o job seja notificado quando ele terminar.
&SYSUID é substituído pelo ID do usuário.
28. Exemplo de programa COBOL
IDENTIFICATION DIVISION.
PROGRAM-ID. COBDB501.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT ARQ-COPAC
ASSIGN TO LISTCOPAC
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-FS-COPAC.
DATA DIVISION.
FILE SECTION.
FD ARQ-COPAC
RECORDING MODE IS F.
01 REG-COPAC.
05 CP-CODIGO PIC 9(05).
05 CP-NOME PIC X(40).
05 CP-PAIS PIC X(30).
05 CP-POPULACAO PIC 9(11).
05 FILLER PIC X(14).
WORKING-STORAGE SECTION.
01 WS-FS-COPAC PIC XX.
01 WS-FIM-ARQUIVO PIC X VALUE 'N'.
88 FIM-ARQUIVO VALUE 'S'.
01 WS-CONTADORES.
05 WS-LIDOS PIC 9(09) COMP-3 VALUE ZERO.
05 WS-INSERIDOS PIC 9(09) COMP-3 VALUE ZERO.
05 WS-REJEITADOS PIC 9(09) COMP-3 VALUE ZERO.
05 WS-COMMIT PIC 9(05) COMP-3 VALUE ZERO.
01 WS-SQLCODE-AUX PIC -9(09).
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
0000-PRINCIPAL.
PERFORM 1000-INICIALIZAR
PERFORM 2000-PROCESSAR
UNTIL FIM-ARQUIVO
PERFORM 9000-FINALIZAR
GOBACK.
29. Inicialização do programa
1000-INICIALIZAR.
DISPLAY 'INICIO DO PROGRAMA COBDB501'
OPEN INPUT ARQ-COPAC
IF WS-FS-COPAC NOT = '00'
DISPLAY 'ERRO NO OPEN LISTCOPAC: ' WS-FS-COPAC
MOVE 12 TO RETURN-CODE
GOBACK
END-IF
PERFORM 2100-LER-ARQUIVO.
A primeira leitura é realizada na inicialização.
Esse padrão evita que o programa execute o processamento com um registro não carregado.
30. Leitura e processamento
2000-PROCESSAR.
ADD 1 TO WS-LIDOS
PERFORM 3000-VALIDAR-REGISTRO
IF CP-CODIGO IS NUMERIC
PERFORM 4000-INSERIR-DB2
ELSE
ADD 1 TO WS-REJEITADOS
DISPLAY 'CODIGO INVALIDO: ' CP-CODIGO
END-IF
PERFORM 2100-LER-ARQUIVO.
A leitura:
2100-LER-ARQUIVO.
READ ARQ-COPAC
AT END
SET FIM-ARQUIVO TO TRUE
NOT AT END
CONTINUE
END-READ
IF WS-FS-COPAC NOT = '00'
AND WS-FS-COPAC NOT = '10'
DISPLAY 'ERRO DE LEITURA: ' WS-FS-COPAC
PERFORM 8000-ROLLBACK
MOVE 12 TO RETURN-CODE
GOBACK
END-IF.
O status 10 representa fim de arquivo e não deve ser tratado como erro.
31. O INSERT Db2
4000-INSERIR-DB2.
EXEC SQL
INSERT INTO TB_COPAC
(
CODIGO,
NOME,
PAIS,
POPULACAO
)
VALUES
(
:CP-CODIGO,
:CP-NOME,
:CP-PAIS,
:CP-POPULACAO
)
END-EXEC
EVALUATE SQLCODE
WHEN ZERO
ADD 1 TO WS-INSERIDOS
ADD 1 TO WS-COMMIT
WHEN -803
ADD 1 TO WS-REJEITADOS
DISPLAY 'CHAVE DUPLICADA: ' CP-CODIGO
WHEN OTHER
MOVE SQLCODE TO WS-SQLCODE-AUX
DISPLAY 'ERRO SQL: ' WS-SQLCODE-AUX
DISPLAY 'REGISTRO: ' CP-CODIGO
PERFORM 8000-ROLLBACK
MOVE 12 TO RETURN-CODE
GOBACK
END-EVALUATE
IF WS-COMMIT >= 1000
PERFORM 7000-COMMIT
END-IF.
32. Por que não fazer apenas um COMMIT no final?
Imagine uma carga de dez milhões de registros.
Se o programa executar um único COMMIT, poderá manter durante horas:
locks;
espaço de log;
páginas modificadas;
recursos;
unidade de trabalho gigantesca.
Se ocorrer erro no registro 9.999.999, o rollback poderá desfazer tudo.
Uma estratégia mais segura é:
COMMIT a cada 1.000 registros
Ou:
COMMIT a cada 5.000 registros
O valor ideal depende do ambiente.
Não existe um número mágico.
É preciso considerar:
volume;
concorrência;
log;
índices;
tempo de recuperação;
SLA;
restart;
regras de negócio.
Rotina:
7000-COMMIT.
EXEC SQL
COMMIT
END-EXEC
IF SQLCODE NOT = ZERO
DISPLAY 'ERRO NO COMMIT: ' SQLCODE
MOVE 12 TO RETURN-CODE
GOBACK
END-IF
MOVE ZERO TO WS-COMMIT.
JES2
IKJEFT01
SDSNLOAD
TSO Attachment
Language Environment
QSAM
RACF
SDSF
Logs do Db2
Nada acontece isoladamente.
Conclusão: poucas linhas, muitas engrenagens
O JCL apresentado é um excelente exemplo da filosofia mainframe: comandos pequenos podem coordenar estruturas gigantescas.
Uma linha como:
RUN PROGRAM(COBDB501) PLAN(HERP0001)
carrega décadas de evolução tecnológica.
Ela conecta:
um executável COBOL;
um ambiente TSO batch;
um subsistema Db2;
um PLAN;
PACKAGES;
SQL estático;
um arquivo sequencial;
QSAM;
segurança;
logging;
controle transacional.
Para o programador COBOL padawan, a principal lição é não observar o JCL como uma simples receita de execução.
Cada DD representa um contrato.
LISTCOPAC → contrato com o arquivo
STEPLIB → contrato com as bibliotecas
SYSTSIN → contrato com o TSO
SYSTSPRT → contrato com as mensagens
PLAN → contrato com o Db2
LIB → contrato com o executável
COMMIT → contrato com a integridade
Quando esses contratos estão alinhados, milhões de registros podem ser processados com precisão.
Quando um deles está errado, o sistema pode responder com um JCL ERROR, um S806, um -805, um -818 ou um silencioso arquivo lido com layout incorreto.
O verdadeiro domínio do mainframe não vem apenas de decorar comandos.
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
