✨ 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
segunda-feira, 28 de fevereiro de 2022
Paz na Ucrânia
PAZ na UCRANIA
#BRIGADASINTERNACIONAIS #STOPWAR #ukraine #peace #paz #SOSUKraine #stopwarinukraine
domingo, 27 de fevereiro de 2022
Hacker e vilão.
sexta-feira, 25 de fevereiro de 2022
🚀 Quer Começar uma Carreira em IBM Mainframe? - Parte IIA
 |
| Bellacosa Mainframe inicio de uma jornada no mainframe parte IIA |
☕ Um Café no Bellacosa Mainframe
🚀 Quer Começar uma Carreira em IBM Mainframe?
Parte IIA — Conhecendo o Coração do IBM Z: COBOL, JCL, QSAM, VSAM, TSO/ISPF e z/OS
"Há uma diferença entre conhecer o caminho e percorrer o caminho."
— Adaptado da filosofia de Jornada nas Estrelas
Recapitulando a Missão
Na primeira parte desta jornada, conhecemos a Academia da Frota Estelar do universo IBM: o IBM Mainframe Skills Depot, o IBM Z Xplore, o curso Learning COBOL Programming with VS Code, o IBM SkillsBuild e outros recursos gratuitos que servem como ponto de partida para qualquer iniciante.
Agora chega a hora de abrir a porta da nave.
Imagine que você acaba de embarcar na USS Enterprise. Você já vestiu o uniforme, recebeu seu comunicador e conheceu a tripulação. Mas ainda não sabe como a nave funciona.
No universo IBM Z acontece exatamente a mesma coisa.
Antes de escrever grandes programas, você precisa entender os principais sistemas que mantêm essa "nave estelar corporativa" funcionando.
O IBM Z é uma Cidade, Não Apenas um Computador
Um erro muito comum entre iniciantes é imaginar que um Mainframe é apenas "um computador muito grande".
Na prática, ele se parece muito mais com uma cidade.
Pense assim:
O prédio principal é o hardware IBM Z.
As ruas são os canais de comunicação.
O sistema elétrico é o z/OS.
As bibliotecas são os bancos de dados.
Os correios transportam informações.
Os cidadãos são os programas.
Os policiais representam o RACF.
Os semáforos lembram o WLM, controlando prioridades.
E o prefeito? É o administrador do sistema.
Quando um programa COBOL é executado, ele não trabalha sozinho. Ele conversa com dezenas de componentes especializados.
Essa integração é uma das maiores forças do Mainframe.
z/OS: O Capitão Invisível da Nave
Se a Enterprise possui um capitão, o IBM Z possui o z/OS.
O z/OS é o sistema operacional do Mainframe. Ele coordena recursos, controla memória, processadores, dispositivos de armazenamento, segurança, redes e milhares de tarefas simultâneas.
Ele decide:
qual programa executa primeiro;
quem pode acessar arquivos;
quanto tempo de CPU cada aplicação recebe;
como compartilhar recursos entre milhares de usuários.
Sem ele, nada funciona.
É o cérebro operacional da plataforma.
Curiosidade Bellacosa ☕
Enquanto muitos sistemas operacionais modernos são pensados para atender alguns usuários ou servidores, o z/OS foi projetado para executar cargas gigantescas durante 24 horas por dia, sete dias por semana, com níveis de disponibilidade extremamente elevados.
COBOL: O Idioma Oficial da Federação Financeira
Chegamos ao protagonista da nossa história.
O COBOL nasceu em 1959 e continua sendo uma das linguagens mais importantes do mundo corporativo.
Seu nome significa:
COmmon Business Oriented Language
Ou seja:
"Linguagem Comum Orientada aos Negócios."
Enquanto linguagens como C foram criadas pensando em sistemas operacionais e Java em portabilidade, o COBOL foi concebido para representar regras de negócio de maneira clara e legível.
Por que COBOL ainda existe?
Porque funciona.
Um programa COBOL pode permanecer décadas em produção, recebendo melhorias sem perder estabilidade.
Imagine um banco que processa milhões de pagamentos por dia. Trocar todo esse sistema por outra linguagem apenas porque ela é "mais nova" seria um projeto de altíssimo risco.
Por isso, a evolução costuma ser gradual, preservando o que já é confiável.
Como um Programa COBOL se Organiza?
Tradicionalmente, um programa COBOL é dividido em quatro grandes áreas:
IDENTIFICATION DIVISION – informações gerais do programa.
ENVIRONMENT DIVISION – descrição do ambiente.
DATA DIVISION – definição das estruturas de dados.
PROCEDURE DIVISION – lógica de processamento.
Essa organização torna o código mais previsível e facilita a manutenção por diferentes equipes.
Dica Bellacosa
Não tente decorar comandos.
Entenda primeiro:
entrada;
processamento;
saída.
Se compreender esse fluxo, a sintaxe do COBOL será muito mais fácil de assimilar.
JCL: O Oficial de Logística
Se o COBOL é o engenheiro da Enterprise, o JCL (Job Control Language) é o oficial responsável por organizar as missões.
Ele não executa a lógica de negócio.
Sua função é preparar o ambiente para que os programas sejam executados corretamente.
O JCL informa:
qual programa será executado;
onde estão os arquivos;
quais bibliotecas utilizar;
quanto espaço em disco reservar;
quais utilitários serão chamados.
Sem JCL, muitos processos em lote simplesmente não aconteceriam.
Analogia com Star Trek
Imagine que Scotty recebeu a missão de reparar os motores de dobra.
Antes de iniciar o trabalho, ele precisa:
separar ferramentas;
reservar energia;
liberar acesso à sala de máquinas;
coordenar a equipe.
O JCL faz exatamente isso para os programas.
Batch: As Missões Automáticas
Grande parte dos programas Mainframe roda em modo Batch.
Em vez de responder imediatamente ao usuário, esses programas processam grandes volumes de dados de forma automatizada.
Exemplos:
folha de pagamento;
emissão de boletos;
faturamento;
fechamento bancário;
geração de relatórios;
processamento de cartões.
Essas rotinas costumam ser executadas em horários programados, quando a carga do sistema é mais adequada para esse tipo de processamento.
QSAM: O Arquivo Sequencial
Antes mesmo dos bancos de dados relacionais se popularizarem, o armazenamento em arquivos já era essencial.
O QSAM (Queued Sequential Access Method) é uma forma tradicional de acessar arquivos sequenciais.
Imagine uma fila de pessoas esperando para entrar em um cinema.
Você não escolhe quem será atendido primeiro.
A ordem é fixa.
O QSAM funciona assim.
Os registros são lidos um após o outro.
É simples.
É rápido para leituras sequenciais.
É eficiente quando o processamento acompanha a ordem natural dos dados.
Onde o QSAM ainda aparece?
relatórios;
importações;
exportações;
integração entre sistemas;
arquivos texto;
geração de documentos.
Mesmo em ambientes modernos, arquivos sequenciais continuam tendo seu espaço.
VSAM: O Grande Arquivista
Quando precisamos localizar um registro específico rapidamente, entra em cena o VSAM (Virtual Storage Access Method).
Ele oferece estruturas mais sofisticadas.
Entre elas:
KSDS
ESDS
RRDS
LDS
Cada uma atende necessidades diferentes.
A mais famosa é a KSDS, que utiliza chaves para permitir acesso rápido aos registros.
Analogia com uma Biblioteca
Imagine uma biblioteca.
Sem catálogo, você teria que olhar livro por livro.
Com um catálogo organizado por código, encontra o volume desejado em poucos instantes.
O VSAM faz algo semelhante.
Ele utiliza índices para facilitar a localização dos dados.
KSDS: O Mais Conhecido
A estrutura KSDS (Key Sequenced Data Set) funciona de maneira parecida com um índice de livro.
Você procura pela chave.
O sistema encontra rapidamente o registro correspondente.
Esse mecanismo é amplamente utilizado em aplicações de negócios que exigem acesso frequente a informações específicas.
ESDS: Ordem Cronológica
No ESDS, os registros são adicionados em sequência.
Não existe uma chave principal para pesquisa direta.
É muito útil quando a ordem de gravação é importante.
Um exemplo clássico seria um histórico de eventos.
RRDS
Aqui cada registro possui uma posição numérica fixa.
É como um grande prédio de apartamentos.
Se alguém mora no apartamento 305, você vai diretamente até ele.
LDS
O Linear Data Set é utilizado principalmente por componentes internos do sistema e por tecnologias como o Db2.
Embora um desenvolvedor COBOL nem sempre trabalhe diretamente com ele, vale a pena saber que existe.
TSO: Sua Porta de Entrada
Chegamos ao ambiente onde muitos profissionais passam boa parte do dia.
O TSO (Time Sharing Option) permite que vários usuários utilizem simultaneamente o Mainframe.
É como entrar na Enterprise utilizando seu crachá.
Depois da autenticação, você pode executar comandos, acessar datasets e iniciar ferramentas.
ISPF: O Painel de Controle
Se o TSO é a porta de entrada, o ISPF é o painel de controle.
Nele você:
edita programas;
cria datasets;
navega por bibliotecas;
executa utilitários;
envia Jobs;
consulta mensagens;
organiza projetos.
Durante muitos anos, essa foi a principal interface de desenvolvimento do IBM Z.
E continua sendo extremamente utilizada.
A Tela Verde Ainda Existe?
Sim.
E continua muito eficiente.
Embora IDEs modernas, como o VS Code e o IBM Developer for z/OS, tragam recursos avançados, a tradicional interface 3270 permanece valorizada por sua rapidez e produtividade em muitas tarefas administrativas e de desenvolvimento.
A Relação Entre Todos Esses Componentes
Agora observe como tudo começa a fazer sentido.
O desenvolvedor:
✔ escreve um programa COBOL.
Depois:
✔ cria um JCL.
O JCL:
✔ executa o programa.
O programa:
✔ lê arquivos QSAM ou VSAM.
Ou:
✔ acessa bancos Db2 (tema da Parte 2B).
Tudo isso ocorre sob o gerenciamento do z/OS.
E o acesso ao ambiente normalmente acontece pelo TSO/ISPF.
Percebe?
Nenhuma tecnologia trabalha isoladamente.
Cada uma possui um papel específico.
Erros Clássicos dos Iniciantes
Ao iniciar no Mainframe, é comum encontrar alguns equívocos:
Querer aprender apenas COBOL e ignorar o restante da plataforma.
Decorar comandos sem compreender o fluxo completo de execução.
Achar que a tela verde é um obstáculo, quando ela é apenas uma interface diferente.
Pensar que arquivos VSAM substituem bancos relacionais ou vice-versa, quando cada tecnologia possui seu propósito.
Esquecer que o Mainframe é um ecossistema integrado, e não apenas uma linguagem de programação.
Easter Egg da Semana 🖖
Na USS Enterprise, o computador central responde às solicitações da tripulação e coordena centenas de sistemas simultaneamente. No IBM Z, o z/OS exerce um papel semelhante, mantendo aplicações, armazenamento, segurança e processamento trabalhando em conjunto. A comparação não é perfeita, mas ajuda a visualizar como um sistema operacional corporativo atua como o "centro de comando" da plataforma.
Conclusão da Parte 2A
Nesta etapa da jornada, você conheceu os pilares que sustentam praticamente qualquer ambiente IBM Z: o z/OS como sistema operacional, o COBOL como linguagem de negócios, o JCL como orquestrador de tarefas, o QSAM e o VSAM como mecanismos de armazenamento e acesso a arquivos, além do TSO/ISPF como principal ambiente de interação com o Mainframe.
Mais do que decorar siglas, o importante é entender que cada tecnologia tem uma função específica e complementa as demais. Assim como em uma nave da Frota Estelar, o sucesso da missão depende da colaboração entre diferentes especialistas.
Na Parte 2B, entraremos na ponte de comando das aplicações corporativas para explorar Db2, SQL, CICS, IMS, RACF, APIs, DevOps, Git, Zowe, modernização e Inteligência Artificial no IBM Z, mostrando como esses componentes expandem o poder da plataforma e a conectam ao mundo moderno. Afinal, toda grande missão precisa de uma tripulação completa. 🖖
🚀 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.
quinta-feira, 24 de fevereiro de 2022
Da Compilação à Execução de um Programa COBOL — Parte II
 |
| Bellacosa Mainframe e a compilação cobol parte II |
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL — Parte II
CICS, Db2, IMS e Adabas: O que Acontece com o Código Antes de o Compilador Entrar em Cena
Introdução
Na primeira parte desta jornada, conhecemos o nascimento de um programa COBOL.
Vimos que tudo começa com o código-fonte armazenado em uma biblioteca, geralmente um PDS ou PDSE, e que os copybooks funcionam como contratos reutilizáveis entre programas, arquivos, mensagens e sistemas.
Também descobrimos uma diferença essencial:
COPY inclui código-fonte.
CALL executa outro módulo.
Porém, quando abrimos um programa corporativo real, especialmente em um banco, seguradora, indústria ou grande empresa, encontramos instruções que parecem COBOL, mas que não pertencem diretamente à linguagem.
Por exemplo:
EXEC CICS
READ FILE('CLIENTE')
INTO(REGISTRO-CLIENTE)
RIDFLD(WS-CHAVE)
END-EXEC.
Ou:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Também podemos encontrar chamadas como:
CALL 'CBLTDLI'
USING GU-FUNCTION
PCB-MASK
AREA-SEGMENTO
SSA-CLIENTE.
Ou estruturas utilizadas na comunicação com Adabas.
O Programador COBOL Padawan olha para tudo isso e pode imaginar que o compilador entende todos esses comandos naturalmente.
Mas não é exatamente assim.
Antes que o compilador COBOL possa transformar o fonte em código objeto, outros componentes precisam preparar partes específicas do programa.
É como uma grande cozinha corporativa.
O compilador é o chef principal, mas alguns ingredientes precisam ser preparados por especialistas antes de chegar à bancada.
Nesta segunda parte, vamos entender:
o papel do tradutor CICS;
como o Db2 processa comandos
EXEC SQL;o que é um DBRM;
por que o BIND do Db2 não é linkedição;
como programas COBOL acessam IMS;
como ocorre a comunicação com Adabas;
o que todas essas tecnologias possuem em comum.
Prepare o café, abra o ISPF e venha descobrir o que realmente acontece com o código antes da compilação.
1. Nem tudo o que aparece no programa é COBOL puro
COBOL possui instruções próprias, como:
MOVE
ADD
SUBTRACT
MULTIPLY
DIVIDE
COMPUTE
IF
EVALUATE
PERFORM
READ
WRITE
REWRITE
DELETE
OPEN
CLOSE
CALL
Essas instruções fazem parte da linguagem e podem ser analisadas diretamente pelo compilador.
Porém, comandos como:
EXEC CICS
EXEC SQL
pertencem a ambientes externos.
Eles foram incorporados ao fonte por meio de uma sintaxe padronizada, mas precisam ser interpretados por componentes especializados.
Uma representação simples seria:
Programa COBOL
├── comandos COBOL
├── comandos CICS
├── comandos SQL
├── chamadas IMS
└── interfaces Adabas
O compilador entende plenamente a primeira parte.
As demais exigem preparação, tradução, bibliotecas ou interfaces específicas.
2. O que é o CICS?
CICS significa Customer Information Control System.
Na prática, ele é uma plataforma de processamento de transações online.
Quando um cliente consulta o saldo, realiza uma transferência, altera um endereço ou solicita uma segunda via de documento, existe uma grande possibilidade de algum componente CICS estar envolvido em ambientes tradicionais IBM Z.
O CICS gerencia elementos como:
transações;
programas;
terminais;
sessões;
arquivos;
filas;
segurança;
recuperação;
sincronização;
comunicação entre sistemas;
controle de recursos;
integração com Db2, MQ e outras tecnologias.
O programa COBOL contém a regra de negócio.
O CICS controla o ambiente transacional em que essa regra será executada.
Imagine uma transação chamada:
C001
Ela pode estar associada ao programa:
PGMCLI01
Quando o usuário informa C001, o CICS localiza o programa, cria uma task, verifica segurança, entrega o controle e acompanha sua execução.
3. Os comandos EXEC CICS
Um programa pode utilizar comandos como:
EXEC CICS
RECEIVE MAP('MAPCLI')
MAPSET('SETCLI')
INTO(AREA-MAPA)
END-EXEC.
Esse comando solicita o recebimento dos dados de uma tela.
Outro exemplo:
EXEC CICS
SEND MAP('MAPCLI')
MAPSET('SETCLI')
FROM(AREA-MAPA)
ERASE
END-EXEC.
Nesse caso, o programa solicita o envio de um mapa para o terminal.
Também podemos encontrar:
EXEC CICS
READ FILE('ARQCLI')
INTO(REGISTRO-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
END-EXEC.
Ou:
EXEC CICS
LINK PROGRAM('PGM002')
COMMAREA(AREA-COMUNICACAO)
LENGTH(WS-TAMANHO)
END-EXEC.
Esses comandos parecem fazer parte do COBOL porque estão misturados ao código.
Entretanto, o compilador COBOL puro não sabe implementar operações como:
enviar uma tela;
ler um arquivo controlado pelo CICS;
iniciar outra transação;
acessar uma fila temporária;
chamar outro programa por meio do CICS;
devolver o controle ao monitor transacional.
Por isso, entra em cena o tradutor CICS.
4. O tradutor CICS
O tradutor CICS analisa os comandos:
EXEC CICS
...
END-EXEC
e os transforma em estruturas que o compilador COBOL consegue processar.
O fluxo conceitual é:
Fonte COBOL com EXEC CICS
↓
Tradutor CICS
↓
Fonte COBOL traduzido
↓
Compilador COBOL
O tradutor não executa a transação.
Ele apenas prepara o fonte.
Imagine o seguinte comando:
EXEC CICS
WRITEQ TS
QUEUE('TEMP001')
FROM(WS-DADOS)
LENGTH(WS-TAMANHO)
END-EXEC.
O tradutor converte essa instrução em uma sequência de chamadas e estruturas internas utilizadas pela interface do CICS.
Depois dessa tradução, o compilador enxerga COBOL válido.
Durante a execução, o programa chama os serviços CICS correspondentes.
5. EXEC CICS é uma macro?
No cotidiano do mainframe, alguns profissionais chamam os comandos EXEC CICS de macros.
Essa forma de falar é compreensível, mas pode gerar confusão.
Uma macro, em outros contextos, costuma ser um trecho expandido diretamente durante a montagem ou compilação.
O comando EXEC CICS é melhor compreendido como uma instrução embutida que precisa ser traduzida por um processador específico.
Portanto, tecnicamente, é mais correto dizer:
EXEC CICSé um comando CICS embutido no programa COBOL.
A distinção pode parecer pequena, mas ajuda o iniciante a compreender que existe uma etapa especializada antes da compilação.
6. CICS controla o recurso, não o programa COBOL
Considere:
EXEC CICS
READ FILE('CLIENTES')
INTO(REG-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
END-EXEC.
O programa não abre diretamente o arquivo físico.
Ele pede ao CICS que realize a leitura.
O CICS pode cuidar de:
localização do recurso;
compartilhamento;
segurança;
recuperação;
bloqueios;
integridade;
controle transacional;
resposta de erro.
O programa recebe o resultado e continua a regra de negócio.
Esse modelo é poderoso porque separa responsabilidades.
Programa COBOL → lógica de negócio
CICS → controle transacional
7. O que é o Db2?
Db2 é o sistema gerenciador de banco de dados relacional da IBM amplamente utilizado no IBM Z.
Ele organiza informações em:
tabelas;
colunas;
linhas;
índices;
views;
tablespaces;
databases;
schemas;
packages;
plans;
collections.
O COBOL pode acessar dados Db2 por meio de SQL embutido.
Exemplo:
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Esse SQL está inserido dentro do fonte COBOL.
Porém, ele não pertence diretamente à linguagem COBOL.
Assim como ocorre com o CICS, o SQL precisa ser processado antes da compilação.
8. O pré-compilador Db2
Historicamente, programas COBOL com SQL passavam pelo pré-compilador Db2.
O fluxo clássico é:
Fonte COBOL com EXEC SQL
↓
Pré-compilador Db2
↓
Fonte COBOL modificado
+
DBRM
O pré-compilador realiza duas tarefas importantes.
Primeiro, ele substitui ou prepara os comandos SQL no fonte para que o compilador COBOL possa processá-los.
Segundo, ele gera o DBRM.
Em ambientes modernos, pode ser utilizado um coprocessador SQL integrado ao compilador.
Para o iniciante, o conceito fundamental permanece:
O SQL precisa ser analisado por uma tecnologia Db2 antes ou durante a compilação COBOL.
9. O que é o DBRM?
DBRM significa Database Request Module.
Ele contém informações extraídas dos comandos SQL presentes no programa.
Considere:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE AGENCIA = :WS-AGENCIA
AND CONTA = :WS-CONTA
END-EXEC.
O Db2 precisa conhecer essa instrução para preparar sua execução.
O DBRM representa as requisições SQL encontradas no programa.
Posteriormente, ele será utilizado em uma operação de BIND.
O fluxo é:
Programa com SQL
↓
DBRM
↓
BIND PACKAGE
↓
Package Db2
O package contém a preparação necessária para que o Db2 execute as instruções SQL.
10. O BIND do Db2
O BIND do Db2 transforma o DBRM em um package executável pelo subsistema.
Durante esse processo, o Db2 pode avaliar:
existência das tabelas;
existência das colunas;
existência dos índices;
autorizações;
estatísticas;
opções de isolamento;
caminhos de acesso;
versões;
collections;
parâmetros de execução.
O Db2 decide como determinada instrução poderá ser executada.
Por exemplo:
SELECT NOME
FROM CLIENTES
WHERE CODIGO = ?
O Db2 poderá utilizar:
um índice;
uma varredura de tabela;
um índice composto;
uma combinação de acessos;
alguma estratégia definida pelo otimizador.
O programa COBOL informa o que deseja.
O Db2 decide como localizar os dados.
11. BIND Db2 não é linkedição
Este é um dos pontos mais importantes deste capítulo.
No mainframe, a palavra “bind” pode aparecer em contextos diferentes.
Existe o Binder do z/OS, responsável pela criação do módulo executável.
E existe o BIND do Db2, responsável pela preparação do SQL.
Binder z/OS → cria load module ou program object
BIND Db2 → cria package
Portanto:
Compilação + linkedição ≠ BIND Db2
Um programa pode estar perfeitamente compilado e linkedidado, mas falhar porque:
o package não existe;
o package está inválido;
a collection está incorreta;
o usuário não possui autorização;
os objetos Db2 foram alterados;
a versão do package não corresponde ao programa.
12. As duas trilhas de um programa Db2
Um programa COBOL com Db2 segue duas trilhas paralelas.
Trilha COBOL
Fonte
↓
Compilador
↓
Código objeto
↓
Binder
↓
Módulo executável
Trilha Db2
EXEC SQL
↓
DBRM
↓
BIND
↓
Package
Na execução, as duas trilhas se encontram.
O módulo executável inicia a lógica COBOL.
Quando chega a um comando SQL, ele aciona a interface Db2, que utiliza o package correspondente.
O load module sozinho não é suficiente.
O package sozinho também não é suficiente.
Eles trabalham em conjunto.
13. Host variables
Campos COBOL utilizados dentro de instruções SQL são chamados de host variables.
Exemplo:
01 WS-CODIGO PIC 9(09).
01 WS-NOME PIC X(40).
No SQL:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Os dois-pontos indicam que os campos pertencem ao programa COBOL.
Sem essa indicação, o Db2 poderia interpretar o nome como uma coluna ou outro elemento SQL.
As host variables formam a ponte entre:
Memória COBOL ↔ Db2
14. A SQLCA
SQLCA significa SQL Communication Area.
Ela contém informações sobre a execução do último comando SQL.
Sua inclusão pode ser feita assim:
EXEC SQL
INCLUDE SQLCA
END-EXEC.
Depois de uma instrução SQL, o programa pode testar:
EVALUATE SQLCODE
WHEN 0
DISPLAY 'OPERACAO REALIZADA'
WHEN 100
DISPLAY 'REGISTRO NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO SQL: ' SQLCODE
END-EVALUATE.
O SQLCODE é um dos campos mais conhecidos.
Alguns resultados comuns são:
SQLCODE 0 → sucesso
SQLCODE 100 → nenhuma linha encontrada
SQLCODE negativo → erro
SQLCODE positivo → aviso ou situação específica
O programa precisa tratar esses resultados.
Ignorar o SQLCODE é como atravessar uma rodovia sem olhar os sinais.
15. Indicadores de nulo
No Db2, uma coluna pode aceitar valor nulo.
COBOL, porém, trabalha com campos que possuem conteúdo físico.
Para representar um nulo, é comum utilizar uma variável indicadora.
Exemplo:
01 WS-TELEFONE PIC X(15).
01 WS-IND-TELEFONE PIC S9(04) COMP.
No SQL:
EXEC SQL
SELECT TELEFONE
INTO :WS-TELEFONE
:WS-IND-TELEFONE
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
Se o indicador retornar valor negativo, a coluna estava nula.
Sem o indicador adequado, o programa pode receber erros ao tentar trabalhar com valores nulos.
16. Um programa CICS com Db2
Em sistemas online, é comum encontrar CICS e Db2 dentro do mesmo programa.
Exemplo:
EXEC CICS
RECEIVE MAP('MAPCLI')
MAPSET('SETCLI')
INTO(AREA-MAPA)
END-EXEC.
MOVE MAP-CODIGO TO WS-CODIGO.
EXEC SQL
SELECT NOME,
SALDO
INTO :WS-NOME,
:WS-SALDO
FROM CLIENTES
WHERE CODIGO = :WS-CODIGO
END-EXEC.
EXEC CICS
SEND MAP('MAPCLI')
MAPSET('SETCLI')
FROM(AREA-MAPA)
END-EXEC.
Nesse caso, o programa utiliza:
CICS para controlar a transação e a tela;
Db2 para acessar os dados;
COBOL para executar a regra de negócio.
O fluxo pode envolver:
Fonte com CICS e SQL
↓
Tradução CICS
↓
Processamento Db2
↓
Compilação COBOL
↓
Linkedição
↓
BIND do package Db2
A sequência exata pode variar conforme as ferramentas e versões.
Mas todos esses elementos precisam ser preparados.
17. O que é IMS?
IMS significa Information Management System.
É uma plataforma histórica e extremamente importante no ecossistema IBM Z.
Ela pode ser dividida em duas grandes áreas:
IMS DB → gerenciamento de banco de dados hierárquico
IMS TM → gerenciamento de transações e mensagens
Um banco IMS não organiza os dados exatamente como uma tabela relacional.
Ele utiliza uma estrutura hierárquica baseada em segmentos.
Podemos imaginar:
CLIENTE
├── CONTA
│ ├── MOVIMENTO
│ └── CARTAO
└── ENDERECO
O segmento CLIENTE pode ser o pai.
CONTA e ENDERECO podem ser filhos.
MOVIMENTO pode ser filho de CONTA.
Essa estrutura lembra uma árvore.
18. Chamadas DL/I
Programas COBOL acessam IMS por meio da interface DL/I.
DL/I significa Data Language/I.
Uma chamada conceitual pode ser:
CALL 'CBLTDLI'
USING GU-FUNCTION
PCB-MASK
SEGMENTO-CLIENTE
SSA-CLIENTE.
A função GU significa Get Unique.
Ela solicita a localização de um segmento específico.
Outras funções comuns incluem:
GU Get Unique
GN Get Next
GNP Get Next Within Parent
GHU Get Hold Unique
GHN Get Hold Next
ISRT Insert
REPL Replace
DLET Delete
O programa envia uma solicitação ao IMS.
O IMS navega pela estrutura hierárquica e retorna o segmento solicitado.
19. O PCB no IMS
PCB significa Program Communication Block.
Ele representa a comunicação entre o programa e um banco ou fila de mensagens IMS.
Após uma chamada DL/I, o programa pode verificar campos da PCB para descobrir:
status da operação;
nome do segmento;
nível hierárquico;
informações de processamento;
resultado da chamada.
É semelhante ao papel do FILE STATUS em arquivos ou do SQLCODE no Db2.
Cada tecnologia possui sua maneira de informar ao programa o resultado da operação.
QSAM/VSAM → FILE STATUS
Db2 → SQLCODE e SQLSTATE
IMS → status da PCB
CICS → RESP e RESP2
Adabas → response code
Um bom programador não ignora nenhum desses retornos.
20. O que são DBD e PSB?
O ambiente IMS utiliza definições importantes.
DBD
DBD significa Database Description.
Ele descreve a estrutura do banco IMS:
segmentos;
relacionamentos;
campos-chave;
organização;
métodos de acesso;
características físicas e lógicas.
PSB
PSB significa Program Specification Block.
Ele define quais recursos um programa pode acessar e como poderá acessá-los.
O PSB pode conter PCBs para:
bancos IMS;
filas de mensagens;
outros recursos.
Podemos imaginar:
DBD → descreve o banco
PSB → descreve a visão do programa
PCB → interface usada durante a execução
21. IMS Transaction Manager
O IMS TM controla transações baseadas em mensagens.
Um fluxo simplificado pode ser:
Terminal, API ou outro sistema
↓
Mensagem de entrada
↓
Fila IMS
↓
Código de transação
↓
Programa COBOL
↓
Processamento
↓
Mensagem de saída
O programa pode receber a mensagem por meio de uma PCB de entrada e produzir uma resposta.
Assim como o CICS, o IMS controla o ambiente transacional.
Mas sua arquitetura, seus conceitos e sua forma de programação são diferentes.
22. Regiões IMS
Programas IMS podem executar em diferentes tipos de regiões.
Entre elas:
MPP;
BMP;
batch DL/I;
regiões utilitárias;
ambientes controlados pelo IMS.
MPP
Message Processing Program.
Processa mensagens e transações IMS.
BMP
Batch Message Processing.
Executa processamento batch com acesso controlado a bancos IMS e, em certos casos, filas.
O programa COBOL continua sendo compilado e linkedidado.
Porém, sua execução depende do ambiente IMS e das definições corretas.
23. O que é Adabas?
Adabas é um sistema de gerenciamento de banco de dados criado pela Software AG.
Ele se tornou muito conhecido em ambientes que utilizam Natural, mas também pode ser acessado por programas COBOL.
O Adabas possui uma arquitetura própria e utiliza componentes como:
Nucleus;
arquivos Adabas;
control blocks;
buffers;
interfaces de chamada;
códigos de resposta.
O Nucleus é o componente central que processa as solicitações.
Uma representação simplificada seria:
Programa COBOL
↓
Interface Adabas
↓
Adabas Nucleus
↓
Arquivo Adabas
24. Control Block e buffers Adabas
Um programa pode utilizar um control block para informar:
comando;
arquivo;
identificadores;
opções;
códigos de resposta;
informações de navegação;
parâmetros da operação.
Também podem existir buffers como:
Format Buffer
Define os campos que serão lidos ou atualizados.
Record Buffer
Recebe ou envia os dados do registro.
Search Buffer
Descreve os critérios de pesquisa.
Value Buffer
Contém os valores utilizados na pesquisa.
ISN Buffer
Pode armazenar números internos de sequência de registros.
Essas estruturas são fornecidas à interface Adabas durante a chamada.
25. Response Code Adabas
Após uma operação, o programa precisa verificar o código de resposta.
Um retorno de sucesso indica que a solicitação foi processada.
Outros códigos podem indicar:
registro não encontrado;
arquivo indisponível;
comando inválido;
conflito;
erro de formato;
problema de segurança;
falha de comunicação;
inconsistência de parâmetros.
Assim como no Db2, IMS, CICS ou VSAM, nunca se deve presumir que uma operação foi bem-sucedida sem verificar o retorno.
26. Natural e Adabas
Muitos iniciantes associam Adabas exclusivamente à linguagem Natural.
Essa associação existe porque as duas tecnologias são frequentemente utilizadas juntas.
Porém:
Natural é uma linguagem e ambiente de desenvolvimento.
Adabas é um sistema gerenciador de banco de dados.
Um programa COBOL também pode acessar Adabas por meio de interfaces apropriadas.
Da mesma forma, um programa Natural pode acessar outros recursos.
Não confunda a linguagem com o banco de dados.
27. O padrão comum entre CICS, Db2, IMS e Adabas
Apesar das diferenças, existe um padrão arquitetural comum.
O programa COBOL não controla diretamente toda a infraestrutura.
Ele solicita serviços.
COBOL → descreve a regra de negócio
CICS → controla a transação
Db2 → gerencia dados relacionais
IMS → gerencia dados hierárquicos e mensagens
Adabas → gerencia dados em sua arquitetura
Cada ambiente fornece:
interfaces;
comandos;
códigos de retorno;
controle de recursos;
segurança;
recuperação;
mecanismos de diagnóstico.
O programa COBOL deve respeitar os contratos de cada um.
28. O código de retorno é parte da lógica
Considere um programador que escreve:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA = :WS-CONTA
END-EXEC.
DISPLAY 'OPERACAO REALIZADA'.
Esse programa exibe sucesso sem verificar o SQLCODE.
Se a conta não existir, o programa poderá informar uma operação que não aconteceu.
O correto seria:
EXEC SQL
UPDATE CONTAS
SET SALDO = SALDO - :WS-VALOR
WHERE CONTA = :WS-CONTA
END-EXEC.
EVALUATE SQLCODE
WHEN 0
DISPLAY 'OPERACAO REALIZADA'
WHEN 100
DISPLAY 'CONTA NAO ENCONTRADA'
WHEN OTHER
DISPLAY 'ERRO DB2: ' SQLCODE
END-EVALUATE.
O mesmo princípio vale para:
RESP CICS
FILE STATUS
PCB IMS
Response Code Adabas
No mainframe, tratar retorno não é uma recomendação opcional.
É parte da regra de negócio.
29. O perigo das opções implícitas
Alguns comandos utilizam tratamento automático de erro.
No CICS, por exemplo, certos erros podem transferir o controle para mecanismos padrão caso o programa não utilize opções como:
RESP
RESP2
NOHANDLE
HANDLE CONDITION
Em programas modernos, é comum preferir tratamento explícito por RESP e RESP2.
Exemplo:
EXEC CICS
READ FILE('ARQCLI')
INTO(REG-CLIENTE)
RIDFLD(WS-CODIGO)
RESP(WS-RESP)
RESP2(WS-RESP2)
END-EXEC.
EVALUATE WS-RESP
WHEN DFHRESP(NORMAL)
CONTINUE
WHEN DFHRESP(NOTFND)
DISPLAY 'CLIENTE NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO CICS: ' WS-RESP
END-EVALUATE.
O objetivo é impedir que falhas sejam tratadas de forma inesperada.
30. Copybooks especializados
Esses ambientes também utilizam copybooks.
No CICS, podem existir:
layouts de COMMAREA;
mapas BMS;
estruturas de mensagens;
áreas de resposta;
contratos entre programas.
No Db2, podem existir:
DCLGENs;
estruturas de tabelas;
SQLCA;
áreas de entrada e saída.
No IMS:
layouts de segmentos;
PCBs;
SSAs;
áreas de mensagens.
No Adabas:
control blocks;
buffers;
layouts de registros;
constantes e códigos.
Portanto, o copybook apresentado na primeira parte continua sendo fundamental.
Ele liga o programa às interfaces dos subsistemas.
31. DCLGEN no Db2
DCLGEN significa Declarations Generator.
Ele pode gerar estruturas COBOL compatíveis com colunas de uma tabela Db2.
Exemplo conceitual:
01 DCLCLIENTES.
10 CLIENTE-CODIGO PIC S9(9) COMP.
10 CLIENTE-NOME PIC X(40).
10 CLIENTE-SALDO PIC S9(11)V99 COMP-3.
O programa inclui essa estrutura por meio de um copybook ou processo equivalente.
Isso reduz a possibilidade de divergência entre os campos COBOL e as definições do banco.
Porém, a geração não elimina a necessidade de análise.
Tipos, precisão, nulos e conversões precisam ser compreendidos.
32. O programa ainda não é executável
Depois da tradução CICS, do processamento SQL e da preparação das interfaces IMS ou Adabas, o programa ainda não está pronto para executar.
Neste momento, temos algo semelhante a:
Fonte COBOL preparado
Copybooks expandidos ou localizados
Comandos CICS traduzidos
Comandos SQL processados
DBRM gerado
Interfaces disponíveis
O próximo passo será a compilação.
O compilador transformará o fonte em código objeto.
Depois, o Binder realizará a linkedição.
Somente então surgirá o módulo executável.
33. O fluxo completo desta etapa
Podemos representar a Parte II assim:
Fonte COBOL
↓
Identificação de comandos externos
↓
EXEC CICS → tradução CICS
↓
EXEC SQL → pré-compilação ou coprocessamento Db2
↓
Geração do DBRM
↓
Chamadas IMS → preparação das interfaces DL/I
↓
Chamadas Adabas → uso de control blocks e buffers
↓
Fonte preparado para compilação
Em paralelo:
DBRM
↓
BIND Db2
↓
Package
34. Erros típicos antes da compilação
Nesta fase, podem ocorrer problemas como:
CICS
comando
EXEC CICSinválido;opção incompatível;
copybook CICS ausente;
tamanho incorreto de COMMAREA;
referência a campo inexistente;
estrutura de mapa incorreta.
Db2
host variable não declarada;
SQLCA ausente;
sintaxe SQL inválida;
DCLGEN incompatível;
indicador de nulo inexistente;
DBRM não gerado.
IMS
PCB incompatível;
SSA incorreta;
função DL/I inválida;
layout de segmento divergente;
ordem incorreta dos parâmetros.
Adabas
control block incorreto;
buffer incompatível;
código de comando inválido;
tamanho inconsistente;
interface ausente.
O segredo é identificar em qual tecnologia o erro está ocorrendo.
35. O Padawan pergunta: quem executa primeiro?
A resposta depende do programa.
Um programa COBOL batch simples pode seguir diretamente para o compilador.
Um programa CICS pode precisar de tradução.
Um programa Db2 precisa de processamento SQL.
Um programa CICS Db2 precisa dos dois.
Um programa IMS ou Adabas precisa das interfaces corretas durante compilação, linkedição e execução.
Portanto:
Não existe um único fluxo universal.
Existe um fluxo-base que recebe etapas adicionais conforme as tecnologias utilizadas.
36. O verdadeiro papel do COBOL
O COBOL continua sendo o centro da regra de negócio.
Exemplo:
IF WS-SALDO >= WS-VALOR
PERFORM DEBITAR-CONTA
PERFORM REGISTRAR-MOVIMENTO
ELSE
MOVE 'SALDO INSUFICIENTE'
TO WS-MENSAGEM
END-IF.
Porém, as operações internas podem utilizar vários subsistemas.
DEBITAR-CONTA → Db2
REGISTRAR-MOVIMENTO → IMS
ENVIAR-MENSAGEM → CICS ou MQ
CONSULTAR-CADASTRO → Adabas
O COBOL orquestra a regra.
Os subsistemas fornecem capacidades especializadas.
37. Uma analogia com uma missão espacial
Imagine uma nave espacial.
O programa COBOL é o comandante da missão.
Ele decide:
qual objetivo deve ser atingido;
qual operação deve ser realizada;
o que fazer em caso de falha;
quando continuar;
quando interromper.
O CICS é o centro de controle de missões online.
O Db2 é o banco de dados científico organizado em tabelas.
O IMS é o sistema hierárquico de navegação e mensagens.
O Adabas é outro repositório especializado de dados.
O tradutor CICS e o pré-compilador Db2 são intérpretes que transformam os comandos do comandante em instruções compreensíveis por cada sistema.
O compilador, que veremos no próximo capítulo, será o engenheiro que converterá toda a missão em instruções executáveis pela máquina.
38. Conselhos do Mestre Bellacosa
Ao trabalhar com programas que utilizam CICS, Db2, IMS ou Adabas, sempre pergunte:
Quais processadores precisam preparar o fonte?
Existe tradução CICS?
Existe pré-compilação ou coprocessador Db2?
O DBRM foi gerado?
O package correto foi criado?
O programa utiliza a versão certa do DCLGEN?
As host variables estão compatíveis?
O
SQLCODEestá sendo tratado?O
RESPCICS está sendo validado?A PCB IMS corresponde ao PSB utilizado?
Os códigos de resposta Adabas são verificados?
Os copybooks estão na versão correta?
O ambiente de compilação utiliza as bibliotecas corretas?
O processo automatizado esconde quais etapas?
Essas perguntas transformam um iniciante em um profissional que entende arquitetura.
Conclusão
Um programa COBOL corporativo pode conter muito mais do que instruções COBOL tradicionais.
Comandos EXEC CICS precisam ser traduzidos para que o compilador possa processá-los.
Comandos EXEC SQL precisam ser analisados pelo pré-compilador ou coprocessador Db2, gerando um fonte preparado e um DBRM.
O DBRM será utilizado no BIND para criação de um package.
No IMS, o programa utiliza chamadas DL/I, PCBs, PSBs, DBDs e layouts hierárquicos.
No Adabas, o acesso ocorre por meio de interfaces, control blocks, buffers e códigos de resposta.
Apesar das diferenças, todos esses ambientes compartilham o mesmo princípio:
O programa COBOL descreve a regra de negócio e solicita serviços a subsistemas especializados.
O CICS controla transações.
O Db2 gerencia dados relacionais.
O IMS processa bancos hierárquicos e mensagens.
O Adabas administra dados por meio de sua própria arquitetura.
E o COBOL permanece no centro, coordenando decisões, cálculos, validações e fluxos empresariais.
Mas ainda falta uma etapa fundamental.
Até agora, o código foi apenas preparado.
Ele ainda não se tornou um módulo executável.
No próximo capítulo
Na Parte III — Compilação, Linkedição e Load Library, entraremos no coração da transformação.
Veremos passo a passo:
como o compilador analisa o programa;
como o fonte se transforma em código objeto;
por que o objeto ainda não é o executável final;
como funciona o Binder;
o que são chamadas estáticas e dinâmicas;
como nasce um load module;
onde o executável é armazenado;
como interpretar return codes e listagens.
Se nesta parte conhecemos os tradutores que preparam a mensagem, no próximo capítulo conheceremos a fábrica que transforma palavras em instruções de máquina.
Prepare outra xícara de café.
A verdadeira transformação do programa COBOL está prestes a começar.
☕
“O Padawan enxerga CICS, Db2, IMS e Adabas como comandos misturados ao COBOL. O especialista enxerga contratos entre arquiteturas, cada uma responsável por uma parte essencial do processamento corporativo.”
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.
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.
Processando evidência digital...
Laudo preliminar: o nascimento do programa
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.
COBOL
código-fonte
copybook
SYSLIB
IBM Z
Subscrever:
Mensagens (Atom)
