✨ 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
SEND MAP
RECEIVE MAP
VALIDA
CONSULTA DB2
SEND
RETURN
Predict
Aqui está uma grande diferença.
Natural usa Predict.
Predict é um catálogo.
Um dicionário corporativo.
Armazena.
Campos
Programas
Mapas
Arquivos
Views
Documentação
Relacionamentos
Exemplo
CLIENTE
CPF
NOME
ENDERECO
LIMITE
Natural gera automaticamente.
Campos.
Mapas.
Views.
Documentação.
Exemplo
1 CPF
1 NOME
1 CIDADE
Tudo centralizado.
CICS não possui Predict
No CICS.
Criamos.
Copybooks.
Layouts.
BMS.
Manualmente.
Exemplo
COPY CLIENTE.
COPY CLIMAP.
Construção de Menus
Natural
Muito simples.
MENU
1 Consulta
2 Inclusao
3 Alteracao
CICS
Criamos.
MAPSET.
COBOL.
Fluxo.
PF Keys.
Exemplo
MENU01
1 Consultar
2 Incluir
3 Alterar
PF3
Hierarquia de programas
Natural
Quase sempre.
Programa chama programa.
MENU
↓
CLIENTE
↓
CONSULTA
↓
ALTERA
Natural controla.
No CICS.
Mais cuidado.
Podemos usar.
LINK
XCTL
START
LINK
Retorna.
EXEC CICS LINK
PROGRAM('CLI002')
END-EXEC
XCTL
Não retorna.
EXEC CICS XCTL
PROGRAM('MENU')
END-EXEC
Como segregar funções
Boa prática.
MENU
Só navegação.
CLIENTE
Negócio.
DBCLI
DB2.
TELA
BMS.
UTIL
Rotinas.
Exemplo
MENU0001
CLI0001
DBCLI01
UTILCPF
MSGERRO
Segurança
Natural
Muito integrada.
Natural Security.
NSC.
Predict.
Menus.
Perfis.
Exemplo
Usuário João.
Pode.
Consultar.
Não alterar.
Natural faz.
No CICS.
Usamos.
RACF.
Transação.
Programa.
Arquivo.
Fila.
TSQ.
TDQ.
Exemplo
CLI1
CONS
ALT1
ADM1
RACF controla.
Navegação
Natural
Automática.
ENTER.
PF3.
PF12.
Tudo tratado.
CICS.
Manual.
Precisamos verificar.
COPY DFHAID
EVALUATE EIBAID
WHEN DFHPF3
PERFORM SAIR
WHEN DFHPF5
PERFORM REFRESH
END-EVALUATE
BMS
Natural
Mapas do Natural.
CICS
BMS.
MAP
Tela.
MAPSET
Conjunto de telas.
Exemplo
LOGIN
MENU
CLIENTE
CONSULTA
HELP
Mapset.
DFHMSD
Tela.
DFHMDI
Campo.
DFHMDF
PF Keys
Muito importante.
PF1
Ajuda
PF3
Sair
PF5
Atualizar
PF7
Anterior
PF8
Próximo
PF12
Cancelar
No terminal 3270
Emuladores modernos.
PCOMM.
Rocket.
Vista.
x3270.
Teclas mapeadas.
Exemplo.
F3
PF3
F7
PF7
Shift+F12
PF24
Clear
PA1
Attention
PA2
SYSREQ
PA3
Comportamento curioso
No 3270.
ENTER.
Não é.
Carriage Return.
É um.
AID.
Attention Identifier.
CICS recebe.
EIBAID
Natural trata.
Automaticamente.
Uma analogia moderna
Natural é parecido com:
Oracle Forms
PowerBuilder
GeneXus
CICS é parecido com.
HTML
CSS
Javascript
Backend Java
Natural oferece produtividade.
CICS oferece controle.
O que é melhor?
Depende.
Natural é excelente para:
Desenvolvimento rápido.
CRUD.
Adabas.
CICS é excelente para:
Grandes volumes.
Flexibilidade.
Integração.
APIs.
DB2.
MQ.
Minha recomendação para um COBOL Júnior
Aprenda primeiro:
BMS
SEND/RECEIVE
DFHAID
COMMAREA
Pseudo-conversação
LINK/XCTL
TSQ
CEDF
Depois estude:
Natural
Predict
Adabas
Natural Security
Quando você conhecer os dois mundos, perceberá algo interessante:
Natural tenta esconder a complexidade do CICS.
CICS mostra explicitamente como as engrenagens funcionam.
E, para quem deseja realmente entender os bastidores das aplicações bancárias e seguradoras do IBM Z, estudar CICS/BMS costuma ser uma excelente forma de aprender como um sistema transacional corporativo é construído desde a fundação.
A resiliência e a tenacidade técnica dos Analistas de Sistemas Mainframe, que em quatro dias conseguiram virar a chave, convertendo sistemas críticos para a conversão de moeda, do URV para o REAL.
Feriado bancário na Sexta-feira, mas Segunda-feira estava tudo no ar, funcionando, quatro dias de loucura no Departamento de Informatica, muita pizza, companheirismo, horas-extra, mas sensação de dever cumprido.
Programas em COBOL, PLI e Natural em Sistemas Mainframe alterados para a conversão da Moeda, sem perdas ou prejuízos aos clientes e empresas. Sendo um Caso de Estudo de Sucesso, visto de perto pelas autoridades europeias, que passado 7 anos repetiram o processo na Conversão do Euro.
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
Bellacosa Mainframe e a compilaçao de um programa cobol
☕ Um Café no Bellacosa Mainframe
Da Compilação à Execução de um Programa COBOL
A jornada completa do código-fonte até a CPU do IBM Z
Para quem está começando no universo mainframe, compilar um programa COBOL pode parecer uma tarefa simples:
Escrever o código
Compilar
Executar
Mas, no IBM Z, existe uma verdadeira cadeia industrial entre a primeira linha do fonte e o momento em que uma CPU começa a executar as instruções do programa.
O código pode depender de copybooks, comandos CICS, instruções SQL, chamadas IMS, interfaces Adabas, arquivos QSAM, clusters VSAM, bibliotecas de carga, JCL, JES2, Language Environment, memória e vários componentes do z/OS.
Por isso, dizer que um programa foi apenas “compilado e executado” é como afirmar que um avião simplesmente saiu do papel e começou a voar.
Entre o projeto e o voo existem dezenas de etapas.
Esta série em quatro capítulos foi criada para mostrar essa jornada completa de maneira progressiva, sempre pensando no Programador COBOL Padawan que deseja compreender não apenas como escrever código, mas como o mainframe realmente pensa.
O grande mapa da jornada
Antes de conhecer cada capítulo, observe o fluxo completo:
Regra de negócio
↓
Código-fonte COBOL
↓
Copybooks
↓
Tradução CICS
↓
Processamento Db2
↓
Interfaces IMS e Adabas
↓
Compilação
↓
Código objeto
↓
Binder
↓
Load module
↓
Load library
↓
JCL ou transação
↓
JES2 ou subsistema online
↓
Loader
↓
Memória
↓
Dispatcher
↓
CPU
↓
Dados, relatórios e resultados
Cada etapa possui uma responsabilidade específica.
Quando uma delas falha, o problema pode aparecer como:
erro de compilação;
erro de linkedição;
package Db2 inválido;
programa não encontrado;
arquivo ausente;
FILE STATUS;
SQLCODE;
erro CICS;
status IMS;
response code Adabas;
return code;
abend.
A melhor forma de investigar qualquer problema é descobrir em qual parte dessa cadeia ele ocorreu.
Parte I — O nascimento do programa COBOL
Código-fonte, bibliotecas e copybooks
O primeiro capítulo apresenta o ponto de partida: o código-fonte COBOL.
É nele que o programador transforma uma regra de negócio em instruções como:
MOVE
COMPUTE
PERFORM
READ
WRITE
CALL
Porém, o programa raramente vive sozinho.
Muitas aplicações utilizam copybooks para compartilhar:
layouts de arquivos;
registros;
áreas de comunicação;
constantes;
códigos de retorno;
estruturas de mensagens;
campos de tabelas;
contratos entre programas.
Um programa pode conter:
COPY CPYCLI01.
Durante o processo de compilação, o conteúdo desse copybook é incorporado logicamente ao fonte.
O capítulo também explica uma diferença fundamental:
COPY inclui fonte.
CALL executa outro programa.
Essa distinção é importante porque um copybook não é um módulo executável.
Ele é uma estrutura reutilizável inserida no programa durante sua preparação.
Outro ponto central é que o copybook funciona como um contrato.
Se dois programas compartilham uma área de memória, ambos precisam interpretar exatamente o mesmo layout.
Uma alteração feita sem análise de impacto pode provocar:
campos deslocados;
valores incorretos;
erros numéricos;
corrupção de dados;
abends;
falhas silenciosas.
A primeira parte também mostra como o compilador localiza copybooks por meio de bibliotecas associadas a DD statements como SYSLIB.
A ordem dessas bibliotecas pode determinar qual versão do copybook será utilizada.
Isso significa que até mesmo uma compilação com retorno zero pode gerar um programa incorreto caso tenha utilizado uma versão inadequada de determinada estrutura.
A jornada de um programa COBOL começa muito antes da execução.
Ela nasce na regra de negócio.
Ganha forma no código-fonte.
Reutiliza estruturas por meio de copybooks.
Conversa com CICS, Db2, IMS e Adabas.
É analisada pelo compilador.
Transforma-se em código objeto.
É reunida pelo Binder.
Torna-se um módulo executável.
É armazenada em uma load library.
Depois, um JCL, uma transação ou um subsistema solicita sua execução.
O JES2 administra o job.
O initiator inicia os steps.
O loader coloca o programa em memória.
O z/OS gerencia recursos.
O WLM orienta prioridades.
O dispatcher entrega capacidade de processamento.
A CPU executa as instruções.
QSAM, VSAM, Db2, IMS, CICS e Adabas fornecem os dados e serviços necessários.
Por fim, o programa produz relatórios, atualizações, mensagens, arquivos e resultados de negócio.
Nada simplesmente “roda”.
Tudo é preparado, ligado, controlado, carregado, executado e registrado.
☕
“O Padawan observa o código-fonte. O especialista acompanha toda a jornada, desde o primeiro COPY até o último ciclo de CPU.”
Laboratório Forense Bellacosa Mainframe
CSI z/OS:
Da Compilação à Execução
de um Programa COBOL
Cinco arquivos de evidências revelam como o código-fonte COBOL
atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load
library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.
CASO: COBOL-2022-EXECEVIDÊNCIAS: 05 ARTIGOSAMBIENTE: IBM Z / z/OSSTATUS: ARQUIVO ABERTO
Esta investigação técnica apresenta o ciclo completo de um
programa COBOL no mainframe IBM Z. A série explica o
nascimento do código-fonte, o uso de copybooks, a preparação de comandos
CICS e SQL, a geração de código objeto, a atuação do Binder, o
armazenamento em load libraries e a execução por JCL, JES2, loader,
Language Environment, dispatcher e CPU. Selecione uma evidência abaixo
para ler o artigo correspondente dentro do visualizador.
Evidência selecionada
Parte I — Código-fonte, bibliotecas e copybooks
A primeira parte acompanha a transformação da regra de negócio em
código-fonte COBOL, explica o papel das bibliotecas e mostra por que
copybooks funcionam como contratos de dados compartilhados entre
programas.
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.
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.
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.
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 SQLCODE está sendo tratado?
O RESP CICS 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.
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
