✨ 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 IMS literalmente conecta segmentos usando ponteiros físicos.
☕ Etapa 1 — Criando o DBD
O:
DBD
(Database Description)
define a estrutura do banco.
📦 DBD Básico
DBD NAME=ESCOLA,ACCESS=HIDAM
DATASET DD1=ESCOLADB
SEGM NAME=CURSO,BYTES=50,PARENT=0
FIELD NAME=(CODCURSO,SEQ,U),BYTES=5,START=1
SEGM NAME=ALUNO,BYTES=80,PARENT=CURSO
FIELD NAME=(MATRIC,SEQ,U),BYTES=6,START=1
SEGM NAME=NOTA,BYTES=20,PARENT=ALUNO
FIELD NAME=(IDNOTA,SEQ,U),BYTES=4,START=1
DBDGEN
FINISH
END
Bellacosa Mainframe uma overview do ims 360 ao ims 15
☕ Um Café no Bellacosa Mainframe
Do IMS/360 ao IMS 15 no IBM z16
A Evolução da Arquitetura que Inspirou os Sistemas Corporativos Modernos — Um Guia Definitivo para um Programador COBOL Padawan
Durante décadas, muita gente acreditou que os sistemas corporativos nasceram com Java, Oracle, APIs REST ou Kubernetes. Outros imaginam que microserviços, filas de mensagens, observabilidade e processamento distribuído são invenções da computação moderna.
A realidade é muito mais interessante.
Muito antes da internet existir, antes da Web, antes do Linux e até antes do banco de dados relacional se popularizar, engenheiros da IBM já haviam construído uma arquitetura extremamente sofisticada sobre o IBM System/360. Essa arquitetura possuía processamento online, banco de dados, recuperação automática, auditoria, processamento batch, filas de mensagens e milhares de usuários simultâneos.
O nome dela era simplesmente:
IMS – Information Management System
A imagem que analisamos nesta conversa é um excelente exemplo dessa arquitetura clássica. Embora o diagrama tenha sido desenhado há mais de cinquenta anos, praticamente todos os conceitos presentes nele continuam vivos no IBM Z moderno.
Hoje vamos desmontar essa arquitetura peça por peça e reconstruí-la utilizando a visão de um programador COBOL Padawan, entendendo não apenas "como funciona", mas também "por que continua funcionando".
O nascimento do IMS
Pouca gente conhece essa curiosidade.
O IMS não nasceu para bancos.
Nem para bancos financeiros.
Nem para seguradoras.
Ele nasceu por causa da NASA.
No final da década de 1960, a IBM precisava criar um sistema capaz de controlar milhões de componentes utilizados no Programa Apollo.
Imagine controlar parafusos.
Cabos.
Circuitos.
Motores.
Bombas.
Sensores.
Tudo precisava ser localizado em segundos.
Foi então que surgiu um banco de dados hierárquico extremamente rápido.
Esse projeto evoluiu e tornou-se o IMS.
Curiosamente, poucos anos depois, bancos, seguradoras, companhias aéreas e governos passaram a utilizá-lo.
Até hoje.
Bellacosa Mainframe e o workflow do ims dl/i
Entendendo o workflow
Observe a estrutura geral.
Ela é extremamente organizada.
Entradas
↓
Processamento Online
↓
Banco de Dados
↓
Batch
↓
Relatórios
Parece simples.
Mas escondia uma engenharia impressionante.
Cada bloco tinha uma responsabilidade específica.
Exatamente como fazemos hoje utilizando microserviços.
A diferença é que isso já existia décadas antes do termo "microservice" ser inventado.
Os Inputs
Na parte superior aparecem três caixas.
INPUT
INPUT
INPUT
Essas entradas podiam ser praticamente qualquer coisa.
Um terminal 3270.
Uma leitora de cartões.
Uma fita magnética.
Outro computador.
Uma aplicação externa.
Hoje poderíamos substituir essas caixas por:
API REST
IBM MQ
Kafka
Event Streams
Mobile App
Browser
Portal Web
IoT
O conceito continua exatamente igual.
Alguém envia uma informação.
O sistema precisa processá-la.
O verdadeiro cérebro: IMS Transaction Manager
No desenho original aparece:
IMS/360
Hoje ele seria:
IMS TM 15
Ele recebe transações.
Gerencia filas.
Controla sessões.
Executa programas COBOL.
Protege os dados.
Controla concorrência.
Garante integridade.
É praticamente um servidor de aplicações.
Muito antes do WebSphere existir.
Os famosos Message Processing Programs (MPP)
Na lateral aparece uma inscrição discreta.
Message Processing Programs
Esse pequeno detalhe representa uma das maiores ideias da computação corporativa.
O usuário envia uma mensagem.
O IMS coloca essa mensagem em uma fila.
Depois escolhe automaticamente qual programa COBOL deve executá-la.
Hoje isso lembra imediatamente:
Controller REST
Lambda
Azure Function
Cloud Function
Microserviço
Na prática é exatamente isso.
Só que rodando em um IBM Z.
O ciclo de uma transação
Imagine um operador alterando uma ordem de produção.
Mas centenas de mecanismos internos entram em ação.
Locks.
Recovery.
Logs.
Buffers.
Commit.
Checkpoint.
Tudo acontece automaticamente.
Os módulos internos
Dentro da aplicação aparecem vários nomes.
STATUS
CHANGE
SPLIT
INQUIRY
ADD
Não são apenas palavras.
Cada uma representa uma operação de negócio.
STATUS
Consulta.
CHANGE
Atualização.
ADD
Inclusão.
INQUIRY
Pesquisa.
SPLIT
Divisão de pedidos.
Perceba uma curiosidade.
Hoje chamaríamos isso de:
GET
POST
PUT
PATCH
As ideias mudaram de nome.
Não de essência.
Os bancos de dados
A aplicação conversa com três bancos.
Isso já demonstra uma preocupação enorme com organização.
Manufacturing Order Database
Banco principal.
Pedidos.
Clientes.
Produção.
Ordens.
Materiais.
Part Number Cross Reference
Uma base auxiliar.
Ela permite descobrir equivalências.
Imagine:
Parafuso antigo
↓
Parafuso novo
Ou
Fornecedor A
↓
Fornecedor B
Hoje chamaríamos isso de Master Data Management.
Manufacturing Planning Database
Aqui mora o planejamento.
Capacidade.
Estoque.
Cronograma.
Previsão.
Hoje esse banco conversa diretamente com sistemas ERP.
Easter Egg nº 1
Muita gente acredita que Data Warehouse nasceu nos anos 90.
Na verdade não.
Observe o bloco:
Unload and Select
Ele já fazia exatamente isso.
Extraía dados.
Selecionava informações.
Preparava estatísticas.
Produzia relatórios.
É praticamente um ETL primitivo.
O IMS LOG
Este talvez seja o componente mais importante de toda arquitetura.
Toda alteração gera um registro.
Nada acontece sem ser registrado.
É graças ao LOG que existem:
Recovery
Rollback
Auditoria
Sincronização
Checkpoint
Hoje fazemos exatamente isso.
Oracle.
Db2.
SQL Server.
PostgreSQL.
Todos utilizam o mesmo princípio.
Easter Egg nº 2
Se você já ouviu falar em WAL (Write Ahead Log) do PostgreSQL...
Parabéns.
Você já conhece o IMS LOG.
O conceito é praticamente idêntico.
IMS Utilities
Após registrar tudo no LOG entram as Utilities.
Elas realizam tarefas fundamentais.
Reorganização.
Validação.
Compressão.
Recovery.
Carga.
Descarga.
Verificação.
Sem Utilities, um ambiente IMS simplesmente não sobrevive.
O mundo Batch
Na parte inferior aparece outro universo.
Os Batch Programs.
Hoje muitos iniciantes imaginam que Batch significa tecnologia antiga.
Não.
Batch significa processamento em massa.
Todos os grandes bancos ainda executam milhares de jobs batch diariamente.
Mudaram apenas as ferramentas.
Report Writer
Responsável pelos relatórios.
No passado.
Impressoras
Papel contínuo
Listagens verdes
Hoje.
Power BI.
Cognos.
Grafana.
Excel.
PDF.
O objetivo continua igual.
Transformar dados em informação.
Selected Report Writer
Relatórios específicos.
Por exemplo.
Pedidos atrasados.
Pedidos acima de R$ 1 milhão.
Produção do turno noturno.
Database Statistics
Outro detalhe interessante.
O sistema produzia estatísticas do banco.
Quantidade de registros.
Espaço ocupado.
Fragmentação.
Performance.
Hoje isso lembra:
RUNSTATS
EXPLAIN
Catalog Statistics
SMF
RMF
OMEGAMON
POSR
No desenho aparece uma sigla curiosa.
POSR
Dependendo da instalação, poderia representar um sistema interno responsável pela consolidação de relatórios operacionais.
É praticamente um pequeno Data Mart.
Observe que ele recebe dados extraídos.
Processa.
Produz relatórios.
Hoje isso seria um pipeline analítico.
Atualizando para o IBM z16
Na versão moderna do diagrama acrescentamos diversos componentes.
Observe como tudo evoluiu.
Entradas
Agora temos.
3270
REST
JSON
MQ
Kafka
Mobile
Cloud
Eventos
Mas todos continuam convergindo para o mesmo lugar.
IMS TM.
Segurança
Hoje um ambiente corporativo possui:
RACF
TLS
AT-TLS
MFA
Criptografia
SMF
Auditoria
LGTO
Compliance
Zero Trust
No desenho antigo isso estava implícito.
Hoje tornou-se um bloco próprio.
DevOps
Outro componente inexistente no desenho original.
Agora encontramos.
Git
GitHub
GitLab
Jenkins
UrbanCode
DBB
Zowe CLI
Ansible
Terraform
Pipelines
Observe.
Nenhum deles substitui o IMS.
Eles apenas automatizam seu gerenciamento.
Observabilidade
Outro grande avanço.
Hoje monitoramos praticamente tudo.
OMEGAMON
Instana
Operations Analytics
SMF
RMF
Grafana
OpenTelemetry
Anomalias
Machine Learning
No IMS/360 isso era feito através de relatórios.
Hoje fazemos em tempo real.
Integração
Outro enorme salto.
O IMS moderno conversa naturalmente com:
Db2
MQ
IMS Connect
REST
SOAP
JSON
Cloud Pak for Data
Data Lake
IBM Cloud
AWS
Azure
Kafka
OpenShift
O IMS deixou de ser um ambiente isolado.
Hoje participa do ecossistema corporativo inteiro.
O maior equívoco sobre o Mainframe
Existe uma frase repetida há décadas.
"O Mainframe é um computador antigo."
Errado.
Na verdade.
O Mainframe é uma arquitetura extremamente moderna cuja origem é antiga.
É diferente.
O IBM z16 possui:
IA embarcada.
Criptografia por hardware.
Processadores especializados.
Linux.
Containers.
Kubernetes.
OpenShift.
APIs.
Cloud.
Mas continua executando IMS.
Porque a arquitetura foi bem projetada.
Easter Egg nº 3
Sabe o que mais impressiona?
Se um programador COBOL de 1985 voltasse hoje, ele provavelmente reconheceria a lógica de um sistema IMS em poucos minutos.
Agora imagine o contrário.
Um desenvolvedor moderno tentando entender um programa IMS de 1985.
Ele descobriria que quase tudo o que considera "novo" já existia em alguma forma:
filas de mensagens;
processamento orientado a eventos;
separação entre regras de negócio e acesso a dados;
auditoria transacional;
recuperação automática;
alta disponibilidade.
Os nomes mudaram. Os princípios permaneceram.
Passo a passo para um Padawan dominar o IMS
Não tente aprender tudo de uma vez. Construa conhecimento em camadas.
Nível 1 – Fundamentos
Entenda o que é o IBM Z e o z/OS.
Aprenda JCL, datasets e utilitários básicos.
Conheça a diferença entre processamento online e batch.
Nível 2 – IMS TM
Descubra o que é uma transação IMS.
Estude Message Processing Programs (MPP).
Aprenda o fluxo: entrada → fila → programa → resposta.
Nível 3 – IMS DB
Compreenda bancos de dados hierárquicos.
Estude segmentos, hierarquias e DBD/PSB.
Pratique navegação usando chamadas DL/I.
Nível 4 – Operação
Aprenda a interpretar logs.
Estude checkpoints e recovery.
Conheça as principais IMS Utilities.
Nível 5 – Modernização
Explore IMS Connect.
Publique APIs REST para aplicações IMS.
Integre com IBM MQ, Event Streams e microsserviços.
Curiosidades que quase ninguém conhece
O IMS é um dos softwares comerciais mais antigos ainda em desenvolvimento contínuo.
Milhões de transações financeiras diárias no mundo passam por aplicações IMS sem que o usuário perceba.
Bancos de dados hierárquicos continuam sendo extremamente eficientes para cargas transacionais previsíveis.
O IMS foi projetado quando memória e processamento eram recursos escassos, o que explica sua impressionante eficiência até hoje.
Muitas arquiteturas modernas de mensageria reproduzem conceitos que o IMS já implementava há décadas.
Conclusão
A imagem histórica que analisamos não é apenas um diagrama técnico; ela representa uma filosofia de engenharia. Ela mostra que sistemas corporativos robustos são construídos com responsabilidades bem definidas, processamento confiável, recuperação planejada e forte disciplina arquitetural.
Ao atualizarmos esse desenho para um ambiente IBM z16 com IMS 15, percebemos que a essência permanece intacta. Entradas continuam chegando ao Transaction Manager, programas COBOL continuam executando regras de negócio, bancos de dados continuam preservando a integridade das informações e processos batch continuam alimentando análises e relatórios. A diferença é que agora tudo isso convive com APIs REST, JSON, IBM MQ, Event Streams, DevOps, observabilidade em tempo real, OpenShift, inteligência artificial e integração com nuvens híbridas.
Essa é a maior lição para um programador COBOL Padawan: tecnologias vêm e vão, mas boas arquiteturas atravessam gerações. O IMS sobreviveu porque foi projetado com princípios sólidos. Entender esse legado não é estudar apenas o passado; é compreender os alicerces sobre os quais a computação corporativa moderna continua sendo construída.
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
