✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe apresenta tabelas cobol subscript versus index
☕ Um Café no Bellacosa Mainframe
Subscript versus Index sem Mistérios para Programadores COBOL
Quando um Programador Descobre que o Maior Vírus Não Está no Data Center... Está em um Mito que Sobrevive Desde os Anos 1970
"Em um laboratório subterrâneo, um microscópio pode revelar um organismo invisível. Em um mainframe, um dump pode revelar um erro invisível. Em ambos os casos, a sobrevivência depende de entender detalhes que quase ninguém percebe."
Introdução – Bem-vindo ao Laboratório P4 do Mainframe
Imagine que você acaba de ser contratado para trabalhar em um dos maiores bancos do planeta.
São duas da manhã.
O processamento noturno começou.
Milhões de contas serão atualizadas.
Bilhões de registros serão lidos.
A folha de pagamento nacional será recalculada.
O sistema de cartões irá consolidar compras realizadas no mundo inteiro.
Tudo parece tranquilo...
Até que um batch começa a consumir CPU muito acima do esperado.
O monitor RMF mostra utilização elevada.
O WLM começa a redistribuir prioridades.
O operador do console observa o relógio.
O gerente pergunta:
— "O que mudou?"
Depois de algumas horas de investigação, alguém encontra uma rotina COBOL.
Ela percorre uma tabela centenas de milhões de vezes usando um método inadequado de acesso.
Não existe bug.
Não existe ABEND.
Não existe corrupção de dados.
Existe apenas uma pequena decisão tomada por um programador anos atrás.
Uma decisão aparentemente inocente.
Subscript ou Index?
É exatamente essa pequena diferença que vamos investigar hoje.
Assim como em The Andromeda Strain (1971), onde cientistas analisam um organismo microscópico para impedir uma catástrofe, nós vamos colocar o COBOL sob um microscópio e descobrir que existe muito mais acontecendo do que aparenta.
Vista seu jaleco.
O laboratório Bellacosa Mainframe está oficialmente aberto.
O paciente: OCCURS
Antes de falar sobre Subscript ou Index precisamos entender o verdadeiro protagonista.
A memória simplesmente possui cem blocos consecutivos.
A pergunta é:
Como chegar até o elemento número 57?
É aí que a investigação começa.
O primeiro suspeito: o Subscript
O Subscript é o método que praticamente todo iniciante aprende.
01 WS-I PIC 9(4).
Depois:
MOVE CLIENTE-NOME (WS-I)
Parece simples.
E realmente é.
Mas existe um detalhe invisível.
Toda vez que fazemos isso, o compilador precisa calcular onde está aquele elemento.
Imagine uma estante enorme.
Você diz:
"Quero o livro número 37."
O bibliotecário pensa:
37
menos
1
×
tamanho do livro
Só depois ele encontra a posição correta.
Em linguagem de máquina acontece algo parecido.
Base da tabela
+
(I-1)
×
Tamanho do registro
Essa conta acontece continuamente.
O segundo suspeito: o Index
Agora surge um personagem misterioso.
05 CLIENTE OCCURS 100 TIMES
INDEXED BY IDX-CLIENTE.
Observe uma coisa.
O Index não é declarado na Working-Storage.
Ele não possui PIC.
Não possui COMP.
Não possui tamanho conhecido.
Na verdade...
Você nunca sabe como ele realmente é.
Porque ele pertence ao compilador.
É um objeto especial.
O maior mito do COBOL
Durante décadas ouvimos:
"Index é uma variável COMP."
Não.
Isso nunca foi garantido pelo padrão COBOL.
O Enterprise COBOL pode implementá-lo da maneira que desejar.
Ele normalmente utiliza deslocamentos internos.
Mas isso faz parte da implementação do compilador.
Não do programa.
Por isso não podemos fazer:
ADD 1 TO IDX
O compilador simplesmente responde:
"Não."
Quem controla o Index é ele.
Não você.
O laboratório encontra uma pista
Imagine esta tabela.
Registro
34 bytes
O elemento 2 começa exatamente após 34 bytes.
O elemento 3 começa após 68.
O elemento 4 após 102.
O Index guarda justamente esse deslocamento.
Em vez de calcular tudo novamente...
Ele já sabe onde está.
É como um GPS.
Enquanto o Subscript pergunta:
"Qual rua?"
O Index responde:
"Já estou estacionado na frente da casa."
O verdadeiro funcionamento interno
Subscript
Base
+
(I × tamanho)
Index
Base
+
Offset
Essa diferença parece pequena.
Mas em milhões de repetições...
Ela cresce.
Muito.
Então o Index sempre vence?
Não.
Aqui entra um dos maiores avanços dos compiladores modernos.
Os primeiros compiladores COBOL surgiram quando processadores eram extremamente limitados.
Multiplicar números custava caro.
Hoje...
O Enterprise COBOL 6.x é absurdamente inteligente.
Ele reconhece padrões.
Remove cálculos repetidos.
Mantém valores em registradores.
Transforma multiplicações em deslocamentos.
Faz otimizações que simplesmente não existiam nos anos 70.
Em diversas situações...
Subscript e Index acabam gerando praticamente o mesmo código de máquina.
Sim.
Você leu corretamente.
O fantasma dos anos 1970
Por que então tantos livros dizem:
"Nunca use Subscript."
Porque eles estavam certos...
Na época deles.
Era uma realidade dos compiladores antigos.
Hoje a situação mudou.
Mas o mito permaneceu vivo.
É um daqueles vírus culturais que atravessam gerações.
Assim como em The Andromeda Strain, onde o verdadeiro perigo era um organismo microscópico desconhecido, aqui o verdadeiro "vírus" é uma recomendação antiga repetida sem contexto.
SEARCH: onde o Index reina absoluto
Existe um momento em que não há discussão.
SEARCH.
SEARCH CLIENTE
Ou
SEARCH ALL CLIENTE
Esses comandos exigem Index.
Por quê?
Porque o compilador controla o deslocamento automaticamente.
Ele move o ponteiro.
Avança.
Retrocede.
Calcula posições intermediárias.
Tudo sem intervenção do programador.
SEARCH ALL e a inteligência da busca binária
Imagine uma lista com um milhão de clientes.
Uma busca sequencial faria:
1
2
3
4
5
6
...
999999
SEARCH ALL faz algo muito diferente.
500000
↓
250000
↓
375000
↓
312500
Cada comparação elimina metade da tabela.
É o famoso algoritmo Binary Search.
Complexidade:
O(log n)
Enquanto uma busca sequencial é
O(n)
A diferença entre essas duas abordagens é gigantesca quando falamos em milhões de registros.
Um detalhe que poucos conhecem
Podemos copiar índices.
SET IDX-B TO IDX-A
Isso não copia um número.
Copia o deslocamento interno.
É extremamente eficiente.
Outra curiosidade
Você consegue escrever:
DISPLAY WS-I
Mas nunca faz:
DISPLAY IDX
Porque ele não representa um número lógico.
Ele representa uma posição interna conhecida apenas pelo compilador.
O que realmente acontece no processador IBM Z?
Agora entramos na sala limpa do laboratório.
Os processadores IBM Z atuais possuem instruções extremamente sofisticadas para cálculo de endereços.
O Enterprise COBOL conhece essas instruções.
Ele utiliza registradores.
Mantém offsets.
Evita recálculos.
Explora pipelines internos do processador.
Resultado?
Muito do trabalho pesado desaparece antes mesmo do programa executar.
É uma das razões pelas quais aplicações COBOL continuam processando milhões de transações por segundo.
Comparando com C
Quem conhece C entende rapidamente.
Subscript lembra:
array[i]
O compilador faz:
base
+
i
×
sizeof(item)
Já o Index funciona como um ponteiro controlado pelo compilador.
Embora tecnicamente não seja um ponteiro exposto ao programador.
Quando usar Subscript?
Excelente escolha para:
✔ programas didáticos
✔ tabelas pequenas
✔ processamento simples
✔ manutenção fácil
✔ código mais intuitivo
Quando usar Index?
Ideal para:
✔ SEARCH
✔ SEARCH ALL
✔ tabelas enormes
✔ processamento intensivo
✔ milhões de iterações
✔ rotinas críticas
Curiosidade histórica
Nos anos 1970, CPU era um recurso precioso.
Algumas empresas alugavam tempo de processamento por minuto.
Cada instrução economizada significava dinheiro.
Não era exagero.
Era sobrevivência.
Foi nesse ambiente que a preferência por Index nasceu.
Décadas depois, muitos programadores continuam repetindo a recomendação sem conhecer sua origem.
Easter Egg Bellacosa Mainframe 🥚
Se você assistir novamente The Andromeda Strain, perceberá que praticamente toda a tensão do filme vem da investigação meticulosa.
Ninguém sai correndo.
Ninguém explode prédios.
Ninguém derrota o problema com um discurso motivacional.
Os cientistas fazem algo muito mais difícil:
Eles observam.
Coletam evidências.
Eliminam hipóteses.
É exatamente assim que trabalham os melhores analistas de performance em mainframe.
Eles não começam alterando código.
Eles analisam:
RMF
SMF
CPU Time
EXCP
Cache
WLM
Explain
Dumps
Estatísticas do compilador
Performance não nasce de achismos.
Nasce de evidências.
Curiosidades que poucos iniciantes conhecem
☕ O comando SET IDX UP BY 1 não soma necessariamente o valor 1. Ele ajusta o deslocamento interno para o próximo elemento da tabela, independentemente do tamanho do registro.
☕ Um OCCURS DEPENDING ON cria tabelas de tamanho variável, exigindo atenção extra ao acessar elementos.
☕ SEARCH ALL só funciona corretamente quando a tabela está previamente ordenada pelo campo pesquisado. Muitos erros de produção surgem porque essa regra foi esquecida.
☕ O Enterprise COBOL pode eliminar cálculos redundantes durante a compilação, principalmente com níveis altos de otimização (OPTIMIZE).
☕ Em alguns casos, o gargalo não está no acesso à tabela, mas no I/O, em chamadas ao Db2, VSAM ou CICS. Otimizar Subscript versus Index sem medir o restante do programa pode não produzir ganho perceptível.
Passo a passo para escolher corretamente
A tabela é pequena? Use Subscript. A clareza do código geralmente vale mais.
Há busca frequente? Considere INDEXED BY e SEARCH.
A tabela está ordenada? Aproveite SEARCH ALL para busca binária.
O programa processa milhões de registros? Meça o desempenho antes de otimizar.
O compilador moderno já resolve o problema? Verifique o código gerado e os relatórios de otimização antes de assumir que existe vantagem.
Você está seguindo um mito ou uma evidência? Essa talvez seja a pergunta mais importante de todas.
Conclusão – O verdadeiro agente invisível
No fim da investigação, descobrimos que o verdadeiro inimigo não era o Subscript.
Nem o Index.
O verdadeiro agente invisível era o mito.
Durante décadas, frases como "Index sempre é mais rápido" foram repetidas como se fossem leis universais. A realidade é muito mais interessante: compiladores evoluíram, processadores IBM Z ficaram extraordinariamente eficientes e muitas otimizações passaram a acontecer automaticamente.
Isso não significa que Subscript e Index sejam iguais. Eles continuam sendo conceitos diferentes, com propósitos diferentes. O Index permanece essencial para SEARCH, SEARCH ALL e cenários de alto desempenho. O Subscript continua sendo simples, legível e perfeitamente adequado para inúmeras aplicações.
O programador COBOL que apenas memoriza regras continua preso aos manuais dos anos 1970. Já aquele que entende o funcionamento interno da linguagem, do compilador e da arquitetura IBM Z enxerga além dos mitos. Ele sabe quando confiar no compilador, quando medir desempenho e quando realmente vale a pena otimizar.
Como em The Andromeda Strain, o sucesso não pertence a quem faz mais barulho. Pertence a quem observa os detalhes invisíveis, testa hipóteses e toma decisões baseadas em evidências. No universo do mainframe, essa mentalidade é o que transforma um simples programador em um verdadeiro investigador dos sistemas críticos que sustentam bancos, governos e a economia mundial.
Bellacosa Mainframe da baixa para a alta plataforma a jornada do padawan a stack mainframe
☕ Um Café no Bellacosa Mainframe
Da Baixa Plataforma ao IBM Mainframe
O Guia Definitivo para Desenvolvedores que Desejam Migrar para o IBM Z
Você não está voltando ao passado. Está descobrindo onde a Engenharia de Software aprendeu a nunca falhar.
Há uma pergunta que recebo praticamente todas as semanas.
"Vale a pena aprender Mainframe em 2026?"
Minha resposta continua exatamente a mesma.
Sim. E talvez hoje faça ainda mais sentido do que há dez anos.
Enquanto novas linguagens surgem todos os anos, existe uma plataforma que continua processando boa parte da economia mundial com disponibilidade próxima de 100%.
Essa plataforma é o IBM Z.
Mas este artigo não é sobre máquinas.
É sobre pessoas.
Sobre desenvolvedores que dominam Java, Python, C#, Delphi, Go, Rust, Kotlin, C++, Visual Basic e outras tecnologias e desejam entender como esse conhecimento pode abrir as portas do universo Mainframe.
Pegue um café.
Vamos conversar.
Antes de tudo: esqueça os mitos
Existe uma enorme quantidade de desinformação sobre Mainframe.
Você provavelmente já ouviu alguma destas frases:
"Mainframe morreu."
"Só existem sistemas antigos."
"COBOL é uma linguagem ultrapassada."
"Ninguém mais aprende isso."
"Tudo foi para a nuvem."
Na prática, basta observar quem movimenta bilhões de transações diariamente:
bancos;
seguradoras;
bolsas de valores;
companhias aéreas;
operadoras de cartão;
governos;
empresas de logística.
Em muitos casos, o coração desses negócios continua sendo o IBM Z.
Não porque seja antigo.
Mas porque funciona extraordinariamente bem.
Você não está trocando de profissão
Quem vem da baixa plataforma costuma imaginar que precisará começar do zero.
Não precisa.
Você continua sendo desenvolvedor.
Continua resolvendo problemas.
Continua escrevendo software.
A diferença está na prioridade.
Na baixa plataforma normalmente pensamos em:
experiência do usuário;
frameworks;
componentes;
bibliotecas;
deploy contínuo;
microsserviços.
Na alta plataforma pensamos em:
continuidade do negócio;
disponibilidade;
integridade dos dados;
desempenho previsível;
recuperação de falhas;
processamento em larga escala.
O objetivo muda.
A engenharia evolui.
O IBM Z não compete com a nuvem
Um erro comum é imaginar que Cloud e Mainframe disputam espaço.
Na realidade eles trabalham juntos.
Hoje encontramos ambientes onde:
APIs REST expõem programas COBOL;
Java executa no z/OS;
Linux roda dentro do IBM Z;
Kubernetes conversa com aplicações corporativas;
OpenShift integra workloads;
IA analisa dados produzidos pelo Mainframe;
Git e VS Code fazem parte do dia a dia.
O IBM Z moderno é uma plataforma integrada ao restante da arquitetura corporativa.
Esqueça a pergunta "Qual linguagem é melhor?"
Essa pergunta perde completamente o sentido no mundo corporativo.
Cada tecnologia resolve problemas diferentes.
Python resolve problemas.
Java resolve problemas.
Rust resolve problemas.
COBOL resolve problemas.
A verdadeira pergunta é:
Qual tecnologia oferece menor risco para aquele negócio?
É exatamente aí que o Mainframe se destaca.
O que realmente muda?
Muito menos do que você imagina.
Você continuará trabalhando com:
variáveis;
estruturas condicionais;
repetições;
funções;
módulos;
arquivos;
bancos de dados;
APIs;
mensagens.
O que muda é a forma de organizar esses componentes.
As maiores mudanças de mentalidade
Disponibilidade
Na Web um servidor pode reiniciar.
Num banco isso pode significar milhões de reais.
Performance previsível
Não basta ser rápido.
É preciso manter o mesmo desempenho durante milhões de transações.
Integridade
Cada registro possui valor financeiro.
Cada atualização precisa ser consistente.
Auditoria
Tudo precisa ser rastreável.
Segurança
Segurança deixa de ser funcionalidade.
Passa a ser requisito básico.
O ecossistema IBM Z
Aprender apenas COBOL é conhecer apenas uma pequena parte da plataforma.
Você encontrará tecnologias como:
COBOL
JCL
CICS
Db2
IMS
VSAM
MQ
RACF
TSO/ISPF
SDSF
JES2
REXX
z/OS
z/OS Connect
Zowe
Git
VS Code
OpenShift
Ansible
Java
Python
É um ecossistema completo.
A melhor estratégia de aprendizagem
Não tente aprender tudo ao mesmo tempo.
Minha recomendação é:
Primeira etapa
Conceitos do Mainframe
z/OS
Dataset
Batch
Online
Segunda etapa
TSO/ISPF
JCL
SDSF
Terceira etapa
COBOL
Quarta etapa
Db2
VSAM
Quinta etapa
CICS
Depois disso você poderá seguir para:
APIs
MQ
DevOps
Git
Zowe
Java
Python
IA aplicada ao IBM Z
Escolha sua linguagem de origem
Preparei uma série mostrando como cada tecnologia conversa com o universo IBM Z.
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
