✨ 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 usando o vs code para programar cobol numa ide moderna
☕ Um Café no Bellacosa Mainframe
Programando COBOL no GitHub com VS Code
Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.
"Todo Jedi começa treinando com um sabre de luz desligado. Todo desenvolvedor Mainframe também pode começar sem um z/OS."
Antes de começarmos...
Existe um mito enorme no mundo Mainframe.
"Para aprender COBOL preciso de um IBM Z."
Não.
Outro mito:
"Para editar programas COBOL preciso de um emulador."
Também não.
Outro:
"Preciso instalar um compilador."
Ainda não.
Hoje vamos aprender exatamente como milhares de desenvolvedores modernos trabalham quando estão estudando, revisando código ou preparando alterações para um projeto.
Você vai usar apenas:
GitHub
Visual Studio Code
IBM Z Open Editor
Git
Nada mais.
Nenhum z/OS.
Nenhum TSO.
Nenhum ISPF.
Nenhuma licença IBM.
E, ainda assim, estará utilizando praticamente o mesmo editor utilizado por desenvolvedores COBOL profissionais.
Pegue seu café.
Vamos montar nosso laboratório.
Bellacosa Mainframe passo a passo na instalacao
A grande mudança de mentalidade
Imagine um mecânico.
Ele não liga um caminhão para trocar o volante.
Primeiro ele trabalha na peça.
Depois instala.
No Mainframe acontece exatamente igual.
Você pode editar, estudar, revisar e versionar milhares de programas COBOL sem sequer possuir acesso ao IBM Z.
O Mainframe só entra quando chega a hora de:
compilar
executar
testar online
acessar DB2
acessar CICS
executar JCL
Até lá...
Tudo pode ser feito localmente.
Nossa arquitetura
Imagine esta jornada.
GitHub
│
git clone
│
VS Code
│
IBM Z Open Editor
│
Editar COBOL
│
Git Commit
│
Git Push
│
GitHub
Inclui validação do CPF
Corrige cálculo de juros
Refatora rotina de leitura VSAM
Atualiza documentação
Organização Bellacosa
COBOL
COPY
JCL
BMS
DBRM
SQL
DOCS
LABS
QUIZZES
Tudo separado.
Tudo fácil.
Markdown
Documente tudo.
README.
Arquitetura.
Fluxo.
Exemplos.
O VS Code possui preview fantástico.
Dica de Ouro
Ative:
Auto Save
Você nunca esquecerá de salvar.
Outra dica
Use:
Minimap.
Você enxerga programas COBOL gigantes.
Outra
Breadcrumbs.
Você sabe exatamente:
DIVISION
SECTION
PARAGRAPH
onde está.
Outra
Outline.
Clique:
CALCULA-TOTAL
Vai direto para o parágrafo.
Adeus Page Down.
Outra
CTRL+P
Digite:
cliente
Abre CLIENTE.CBL imediatamente.
Outra
CTRL+SHIFT+O
Lista todos os parágrafos.
Fantástico.
Outra
CTRL+SHIFT+F
Procura em TODOS os programas.
Imagine localizar:
EXEC SQL
em 12.000 fontes.
Leva segundos.
Easter Egg nº 1
Troque o tema.
Experimente:
IBM Carbon Theme
ou
One Dark Pro.
Seu COBOL fica lindíssimo.
Easter Egg nº 2
Instale Peacock.
Cada Workspace ganha uma cor.
Nunca mais confundirá produção e laboratório.
Easter Egg nº 3
Digite:
>Preferences: Open Keyboard Shortcuts
Personalize tudo.
Easter Egg nº 4
Use emojis nos commits.
✨ Novo programa
🐞 Corrige bug
📚 Atualiza documentação
♻ Refatoração
🚀 Nova funcionalidade
Easter Egg nº 5
Use Copilot apenas para sugerir código.
Nunca aceite sem entender.
O bom desenvolvedor continua pensando.
Quando chegar o Mainframe...
Nada muda.
Você apenas instala:
IBM Zowe Explorer.
Então passa a acessar:
PDS
PDSE
USS
JES
Jobs
Datasets
O editor continua exatamente o mesmo.
É como aprender a dirigir em um simulador e depois entrar no carro real: os comandos principais permanecem familiares.
O verdadeiro objetivo
Aprender COBOL nunca foi decorar comandos do ISPF.
O objetivo é entender:
lógica de negócio;
arquitetura de sistemas;
qualidade de código;
versionamento;
colaboração;
documentação.
Essas habilidades acompanham você em qualquer plataforma.
Conclusão
Durante décadas, muitos imaginaram que o desenvolvimento Mainframe dependia de telas verdes, terminais 3270 e comandos memorizados. Hoje, essa realidade mudou. O Visual Studio Code, aliado ao IBM Z Open Editor e ao GitHub, oferece uma experiência moderna, produtiva e acessível para estudar, revisar e evoluir programas COBOL sem a necessidade imediata de um ambiente z/OS.
Ao dominar Git, commits bem escritos, branches, documentação em Markdown e a organização de projetos, você desenvolve competências valorizadas em qualquer equipe de engenharia de software. Quando chegar o momento de conectar-se a um IBM Z com o Zowe Explorer, a curva de aprendizado será muito menor, pois o editor, os atalhos e o fluxo de trabalho continuarão praticamente os mesmos.
Você não está abandonando o Mainframe tradicional. Está adicionando ferramentas modernas à sua caixa de ferramentas. Como costumo dizer no Bellacosa Mainframe: o terminal pode mudar, mas a excelência em engenharia de software continua sendo a mesma. ☕
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.
Bem-vindo ao Laboratório Bellacosa Mainframe – CICS BMS para Padawans. Este conjunto de exercícios foi projetado para conduzir um desenvolvedor COBOL iniciante por uma jornada gradual de aprendizado, partindo da criação do primeiro MAPSET BMS até a construção de uma pequena aplicação pseudo-conversacional semelhante às encontradas em bancos, seguradoras e grandes empresas.
O objetivo não é apenas aprender a sintaxe das macros DFHMSD, DFHMDI e DFHMDF, mas desenvolver a forma de pensar utilizada por desenvolvedores CICS experientes.
Ao longo dos laboratórios, o aluno será estimulado a raciocinar em termos de interface, estado, fluxo de navegação, persistência temporária de informações e interação entre usuário e aplicação. Inicialmente, o foco será compreender como uma tela 3270 é construída, como os campos são definidos, protegidos ou liberados para edição e como o BMS abstrai as características do terminal.
Em seguida, serão introduzidos os conceitos de SEND MAP, RECEIVE MAP, EIBAID, DFHAID, posicionamento dinâmico de cursor e tratamento de teclas funcionais.
Nos desafios mais avançados, espera-se que o aluno seja capaz de projetar uma aplicação utilizando pseudo-conversação, COMMAREA, paginação, mensagens de erro e validações, adotando uma abordagem semelhante à empregada em sistemas corporativos reais.
Mais importante do que memorizar comandos é desenvolver o raciocínio arquitetural necessário para compreender como aplicações CICS foram concebidas, evoluíram ao longo das décadas e continuam sustentando milhões de transações críticas diariamente no ecossistema IBM Z.
==================================
CLIENTES
Codigo
Nome
CPF
PF3=Sair
PF5=Limpar
PF7=Anterior
PF8=Próximo
==================================
Desafio Extra
Implementar:
MAPFAIL
HANDLE CONDITION
HANDLE AID
FSET
FRSET
DATAONLY
MAPONLY
Gabarito Esperado
Ao final dos 10 labs o aluno deverá dominar:
✅ DFHMSD
✅ DFHMDI
✅ DFHMDF
✅ SEND MAP
✅ RECEIVE MAP
✅ DFHAID
✅ EIBAID
✅ CURSOR
✅ MDT
✅ FSET
✅ COMMAREA
✅ Pseudo-conversação
✅ CEDA
✅ CEMT
✅ INSTALL
✅ BMS Physical
✅ Symbolic Maps
🏆 Desafio Bellacosa Mainframe (Boss Fight)
Construa uma aplicação semelhante a um sistema bancário contendo:
Login
Menu Principal
Consulta Cliente
Inclusão
Alteração
Exclusão
Paginação PF7/PF8
Help PF1
Mensagens de erro
COMMAREA
TSQ para paginação
DB2 (simulado)
CEDF para debug
Se conseguir completar este laboratório, você estará muito próximo do nível esperado de um Desenvolvedor COBOL/CICS Júnior pronto para atuar em projetos corporativos IBM Z.
Bellacosa Mainframe como pagar dividas tecnicas em mainframe
☕💣📋 HOW TO PAY BACK TECHNICAL DEBT — O DIA EM QUE O PROGRAMADOR COBOL DESCOBRIU QUE ESTAVA PAGANDO JUROS POR UMA DECISÃO TOMADA EM 1998
Existe uma frase muito conhecida no mercado de tecnologia:
"Toda empresa tem dívida técnica. Algumas apenas ainda não receberam a cobrança."
Para um programador COBOL Mainframe júnior, a expressão "dívida técnica" parece algo moderno, criado por arquitetos ágeis, consultores de transformação digital ou gurus do DevOps.
Mas a verdade é muito mais divertida.
Muito antes de alguém inventar Scrum, Kanban, DevOps, GitHub ou Microservices, os programadores COBOL já acumulavam dívida técnica sem saber.
Toda vez que alguém dizia:
"Depois a gente arruma."
Nascia uma nova parcela.
E em muitos ambientes z/OS, ainda estamos pagando prestações de decisões tomadas há 20 ou 30 anos.
Pegue seu café porque hoje vamos entender como identificar, medir, controlar e pagar dívida técnica sem derrubar a produção.
O QUE É DÍVIDA TÉCNICA?
A definição mais simples é:
Dívida técnica é o custo futuro criado por uma decisão técnica tomada para resolver um problema rapidamente hoje.
Imagine um programa COBOL.
Você precisa entregar uma alteração urgente.
O correto seria:
Revisar arquitetura
Atualizar documentação
Criar testes
Refatorar módulos
Mas o prazo é amanhã.
Então alguém faz:
IF CLIENTE = '999999'
GO TO TRATAMENTO-ESPECIAL.
Entrega.
Produção funciona.
Cliente feliz.
Projeto encerrado.
Mas daqui a dois anos ninguém lembra por que aquele IF existe.
A dívida nasceu.
O MAIOR MITO DO MAINFRAME
Muita gente acredita que:
"Código antigo é dívida técnica."
Errado.
Código antigo pode ser excelente.
Existem programas COBOL escritos nos anos 80 que ainda hoje são exemplos de engenharia.
Por outro lado, existem programas escritos há seis meses que já nasceram endividados.
A idade do código não importa.
O que importa é:
Complexidade
Manutenibilidade
Clareza
Testabilidade
Documentação
COMO IDENTIFICAR DÍVIDA TÉCNICA
O primeiro passo é aprender a enxergá-la.
Alguns sintomas clássicos:
Programa que ninguém quer alterar
Quando uma demanda chega e todos falam:
"Tomara que não seja naquele programa..."
Existe dívida.
Alteração simples demora dias
Mudança:
Trocar 20 para 25.
Tempo gasto:
3 dias
Existe dívida.
Muitos abends
Se o mesmo módulo gera incidentes frequentemente:
S0C7
S0C4
SQLCODE negativos
Arquivos inconsistentes
Existe dívida.
Dependência de especialistas
Quando apenas uma pessoa entende o sistema.
Isso é uma dívida técnica humana.
Extremamente perigosa.
A METÁFORA DO CARTÃO DE CRÉDITO
A IBM utiliza uma analogia excelente.
Imagine um cartão.
Você compra algo hoje.
O benefício é imediato.
O pagamento fica para depois.
Dívida técnica funciona igual.
Benefício imediato:
Entreguei no prazo
Pagamento futuro:
Mais manutenção
Mais defeitos
Mais testes
Mais retrabalho
O problema não é usar o cartão.
O problema é esquecer da fatura.
COMO MAPEAR A DÍVIDA TÉCNICA
A primeira atividade prática é criar um inventário.
Monte uma planilha contendo:
Sistema
Problema
Impacto
Prioridade
Cadastro
GO TO excessivo
Médio
Média
Cobrança
Sem documentação
Alto
Alta
Faturamento
Alta complexidade
Alto
Alta
Você não consegue corrigir aquilo que não consegue enxergar.
MÉTRICA 1 – COMPLEXIDADE CICLOMÁTICA
Uma das métricas mais famosas.
Ela mede quantos caminhos lógicos existem em um programa.
Exemplo:
IF A
...
ELSE
...
END-IF
Pouca complexidade.
Agora imagine:
IF A
IF B
IF C
IF D
A complexidade explode.
Quanto maior a complexidade:
Mais difícil testar
Mais difícil manter
Maior risco de erro
Regra prática:
Valor
Situação
1 a 10
Boa
11 a 20
Atenção
Acima de 20
Risco
MÉTRICA 2 – TEMPO DE MANUTENÇÃO
Métrica simples.
Quanto tempo leva para implementar uma mudança?
Exemplo:
Alteração simples:
4 horas
Virou:
3 dias
A dívida está cobrando juros.
MÉTRICA 3 – QUANTIDADE DE INCIDENTES
Monitore:
Chamados
Tickets
Problemas recorrentes
Se determinado programa gera:
20% dos incidentes
Ele deve entrar imediatamente no backlog técnico.
MÉTRICA 4 – COBERTURA DE TESTES
Quanto do sistema possui testes?
Exemplo:
10%
Muito arriscado.
80%
Muito saudável.
No mundo COBOL isso pode envolver:
Unit Test
Testes automatizados
Batch Validation
MÉTRICA 5 – TEMPO MÉDIO DE RECUPERAÇÃO
MTTR
Mean Time To Recovery.
Quanto tempo leva para resolver um problema?
Exemplo:
10 minutos
Excelente.
8 horas
Existe forte dívida técnica.
A REGRA DOS 20%
Uma prática muito utilizada é reservar:
80% desenvolvimento
20% redução de dívida técnica
Isso impede que a dívida cresça infinitamente.
TÉCNICA 1 – REFATORAÇÃO CONTÍNUA
Refatorar significa melhorar sem alterar comportamento.
Exemplo:
Antes:
GO TO ERRO.
GO TO ERRO.
GO TO ERRO.
Depois:
PERFORM TRATA-ERRO.
Mesmo resultado.
Código mais limpo.
TÉCNICA 2 – MODULARIZAÇÃO
Programas gigantes são fábricas de dívida.
Já encontrei programas com:
80.000 linhas
Divida responsabilidades.
Crie módulos menores.
Mais simples de entender.
Mais simples de testar.
TÉCNICA 3 – DOCUMENTAÇÃO VIVA
Documentação morta é inútil.
Documentação viva é atualizada junto com o sistema.
Documente:
Fluxos
Arquivos
Tabelas
Regras de negócio
TÉCNICA 4 – ELIMINAÇÃO DE CÓDIGO MORTO
Existe um cemitério escondido em todo sistema.
Trechos como:
IF FLAG = 'X'
Que nunca mais executam.
Remover código morto reduz:
Complexidade
Risco
Tempo de manutenção
TÉCNICA 5 – BACKLOG TÉCNICO
Crie um backlog específico.
Exemplo:
Remover GO TO
Documentar módulo
Automatizar teste
Eliminar código morto
A dívida precisa aparecer oficialmente.
Caso contrário ela nunca será priorizada.
FERRAMENTAS ÚTEIS NO MUNDO MAINFRAME
IBM Application Discovery
Mapeia dependências.
Mostra:
Programas
Arquivos
CICS
DB2
Excelente para arqueologia de sistemas.
IBM ADDI
Application Discovery and Delivery Intelligence.
Permite visualizar relacionamentos invisíveis.
Muito útil para sistemas legados.
SonarQube
Mesmo para COBOL.
Detecta:
Complexidade
Duplicação
Código suspeito
IBM Developer for z/OS
Auxilia:
Navegação
Análise
Refatoração
Jira
Controle de backlog técnico.
Muitas empresas utilizam para registrar dívida técnica.
EASTER EGG MAINFRAME
Quer descobrir rapidamente onde existe dívida?
Procure:
GO TO
ALTER
NEXT SENTENCE
Ou:
STEP099
STEP100
STEP101
Sem documentação.
Você provavelmente encontrou um sítio arqueológico corporativo.
O ERRO MAIS COMUM DOS JUNIORES
Pensar:
"Vou reescrever tudo."
Não.
Esse é o caminho para o desastre.
A melhor estratégia quase sempre é:
Pequenas melhorias contínuas.
Todo dia.
Toda sprint.
Todo projeto.
Toda manutenção.
COMO EVOLUIR COMO PROFISSIONAL
Programadores experientes não são aqueles que escrevem mais código.
São aqueles que reduzem complexidade.
Quando você consegue olhar para um sistema e dizer:
"Esse trecho vai gerar problema daqui a dois anos."
Você começou a pensar como arquiteto.
O SEGREDO DOS MELHORES ANALISTAS DE SISTEMAS
Eles não combatem apenas bugs.
Eles combatem as causas dos bugs.
Essa é a diferença entre apagar incêndios e construir sistemas duradouros.
CONCLUSÃO
Dívida técnica não é um defeito.
Ela é uma ferramenta.
Em alguns momentos vale a pena assumir a dívida para entregar rapidamente.
O problema surge quando ninguém controla o saldo.
O programador COBOL júnior que aprender a:
Identificar dívida
Medir dívida
Priorizar dívida
Reduzir dívida
Monitorar dívida
Terá uma visão muito mais próxima de um arquiteto de sistemas do que de um simples codificador.
Porque no fim das contas, o maior segredo do Mainframe não é fazer programas funcionarem.
É garantir que eles continuem funcionando daqui a 30 anos sem que alguém precise vender a alma para entender por quê.
Bellacosa Mainframe e os datasets ps pds e pdse no z/os
Entendendo Mainframe Datasets (PS, PDS e PDSE)
Uma análise aprofundada para desenvolvedores COBOL Jr.
A imagem resume um dos conceitos mais importantes do ecossistema z/OS: datasets. Se você está iniciando em COBOL, JCL, DB2, CICS ou suporte Mainframe, compreender datasets não é apenas importante — é obrigatório.
Muitos iniciantes vêm do mundo Windows, Linux ou Cloud e tentam enxergar o Mainframe usando a lógica de diretórios, arquivos e pastas tradicionais. Esse é um dos primeiros erros.
No Mainframe, a unidade fundamental de armazenamento não é o arquivo ("file"), mas sim o dataset.
1. O que é um Dataset?
Um dataset é uma estrutura lógica utilizada para armazenar informações dentro do z/OS.
PDS utiliza diretório fixo e requer compressão periódica. PDSE possui gerenciamento automático de espaço, diretório dinâmico e não necessita compressão.
O que é um membro?
Resposta:
Uma subdivisão lógica dentro de um PDS ou PDSE.
Um PS possui membros?
Resposta:
Não.
Como referenciar um membro?
Resposta:
DSN(MEMBER)
Exemplo:
USER.COBOL(PROG001)
Onde ficam os fontes COBOL?
Resposta:
Normalmente:
PDS ou PDSE
25. Visão Arquitetural que Poucos Iniciantes Entendem
A maioria dos juniores pensa:
PS = ruim
PDS = melhor
PDSE = moderno
Mas isso é simplificação excessiva.
A verdade é:
Cada um resolve um problema diferente.
PS
Especialista em:
Grande volume sequencial
PDS
Especialista em:
Organização de membros
PDSE
Especialista em:
Organização moderna de membros
Portanto:
PS ≠ PDS
PDS ≠ PDSE
Eles não competem diretamente.
26. Como enxergar isso como um profissional Mainframe
Essa separação é um dos pilares da arquitetura Mainframe.
Conclusão
A imagem apresenta apenas a superfície do assunto. Para um desenvolvedor COBOL Jr., o entendimento profundo é que datasets são a espinha dorsal do z/OS. Quase tudo que você fará no Mainframe envolverá abrir, criar, catalogar, alocar, ler, gravar, copiar, compactar ou referenciar datasets.
Guarde a regra mental mais importante:
PS = Arquivo único (Single File)
PDS = Biblioteca com membros (Folder)
PDSE = Biblioteca inteligente (Smart Folder)
Quando você dominar datasets, começará a enxergar o Mainframe da forma correta: não como um "Linux antigo", mas como um sistema operacional projetado para processar bilhões de transações com confiabilidade, organização e desempenho que continuam sendo referência mundial décadas depois de sua criação.
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
