Natural x CICS BMS para Desenvolvedores COBOL

 

Bellacosa Mainframe e uma breve comparação entre Natural e CICS BMS

☕ Um Café no Bellacosa Mainframe

Natural x CICS BMS para Desenvolvedores COBOL

Entendendo duas filosofias diferentes de construir aplicações Online no Mainframe

Salve jovem Padawan.

Uma das dúvidas mais comuns de quem começa no mundo Mainframe é:

Se eu sei desenvolver online em Natural, já sei desenvolver em CICS?

A resposta curta é:

Não.

A resposta longa é:

Você conhece o objetivo, mas não conhece o mecanismo.

Natural e CICS possuem filosofias completamente diferentes para construir aplicações online.

---

A grande diferença

Natural é uma plataforma completa.

CICS é um monitor transacional.

Podemos pensar da seguinte maneira:

Natural	CICS
Framework	Monitor Transacional
IDE integrada	Ferramentas separadas
Tela automática	BMS
Segurança integrada	RACF/CICS
Navegação nativa	Programada
Dicionário Predict	Copybooks
Estado mantido pelo Natural	COMMAREA
Desenvolvimento RAD	Desenvolvimento explícito

---

Arquitetura Natural

Em Natural normalmente temos:

Usuário

↓

Terminal 3270

↓

Natural Runtime

↓

Programa Natural

↓

Predict

↓

Adabas

Natural faz praticamente tudo.

O desenvolvedor apenas escreve:

INPUT

'CPF' CPF

'Nome' NOME


END-INPUT

Pronto.

Tela criada.

---

Arquitetura CICS

No CICS:

Usuário

↓

3270

↓

BMS

↓

MAPSET

↓

COBOL

↓

COMMAREA

↓

DB2

Tudo é responsabilidade do desenvolvedor.

---

Natural é quase um framework

Natural lembra.

Django

Rails

PowerBuilder

Oracle Forms

---

Exemplo Natural

INPUT USING MAP 'CLI001'

END-INPUT

Natural já sabe.

Mapa.

Campos.

Validação.

Cursor.

Ajuda.

PF Keys.

Tudo praticamente pronto.

---

CICS é uma caixa de ferramentas

CICS fornece:

SEND

RECEIVE

LINK

RETURN

HANDLE

Mas você constrói.

---

Exemplo

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.

Conversão do REAL um grande trabalho da informática mainframe

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.

#ibm #mainframe #real #urv #conversao #cobol #natural #jcl #pli #db2 #adabas #job #sistemas #dev #programador #sucesso

 

Road Map para Aprender Mainframe

Bellacosa Mainframe e o roadmap mainframe 

☕ Um Café no Bellacosa Mainframe

A Volta ao Mainframe em 80 Dias — O Road Map de Phileas Fogg para se Tornar um Mainframeiro

🎩🦖 80 dias, oito grandes escalas, COBOL, JCL, z/OS, TSO/ISPF, VSAM, Db2, CICS, RACF, Git, APIs e uma aposta aparentemente impossível: sair de Londres como turista e voltar como programador mainframe

Londres.

Reform Club.

Um cavalheiro inglês consulta seu relógio.

Phileas Fogg.

Metódico.

Pontual.

Imperturbável.

Um homem capaz de tomar café às 08:23 e provavelmente considerar uma execução às 08:24 um incidente de produção.

Sobre a mesa está o Daily Telegraph.

Mas existe uma notícia estranha:

“É possível aprender mainframe em apenas 80 dias?”

Os cavalheiros riem.

Um deles comenta:

— Mainframe? Meu caro Fogg, seriam necessários anos!

Outro acrescenta:

— COBOL possui DIVISIONs!

Um terceiro, claramente traumatizado:

— E existe JCL!

Fogg fecha o jornal.

Consulta o relógio.

— Oitenta dias.

Silêncio.

— Impossível!

Fogg responde:

“Então aposto vinte mil libras.”

Nesse exato momento, seu criado Passepartout percebe que provavelmente escolheu o pior dia da história para começar no emprego.

Pegam as malas.

Destino:

IBM Z.

E assim começa nossa...

🌍 VOLTA AO MAINFRAME EM 80 DIAS

---

🗺️ O mapa da expedição

Nossa viagem terá oito grandes escalas:

LONDRES
   ↓
z/OS + TSO/ISPF
   ↓
SUEZ
   ↓
JCL + JES2 + SDSF
   ↓
BOMBAIM
   ↓
COBOL
   ↓
CALCUTÁ
   ↓
VSAM + DATASETS
   ↓
HONG KONG
   ↓
Db2
   ↓
YOKOHAMA
   ↓
CICS
   ↓
SAN FRANCISCO
   ↓
RACF + USS + Zowe + Git + APIs
   ↓
NOVA YORK
   ↓
INTEGRAÇÃO + DEVOPS + TESTES
   ↓
LONDRES

80 dias.

Não para transformar alguém em especialista.

Isso seria picaretagem.

Mas para fazer algo perfeitamente possível:

construir um mapa mental sólido do ecossistema mainframe e conseguir desenvolver, executar, investigar e integrar uma aplicação simples.

Temos uma aposta.

O relógio começou.

---

🎩 DIAS 1–10 — LONDRES

Primeira escala: entender o monstro

Antes de programar mainframe precisamos cometer um ato revolucionário:

entender o que é um mainframe.

Não é:

“um computador velho.”

Também não é:

“um PC gigante.”

E definitivamente não é aquele monitor verde que Hollywood coloca em filmes quando alguém precisa invadir o Pentágono.

Precisamos compreender conceitos básicos:

IBM Z
   ↓
z/OS
   ↓
LPAR
   ↓
CPU / CP / zIIP
   ↓
MEMÓRIA
   ↓
STORAGE
   ↓
I/O

E principalmente:

por que essas máquinas existem?

Bancos.

Seguradoras.

Governos.

Companhias aéreas.

Cartões.

Grandes varejistas.

Ambientes que precisam processar volumes enormes com confiabilidade e previsibilidade.

---

🏛️ Dia 1 — Arquitetura

Aprenda:

IBM Z
LPAR
PR/SM
z/OS
JES
USS
STORAGE

Não tente decorar tudo.

Objetivo:

saber desenhar aproximadamente onde sua aplicação vive.

---

🖥️ Dias 2–4 — TSO e ISPF

Phileas Fogg entra pela primeira vez no terminal.

Tela:

---------------- ISPF PRIMARY OPTION MENU ----------------

0  Settings
1  View
2  Edit
3  Utilities
4  Foreground
5  Batch
6  Command

Passepartout pergunta:

— Monsieur, onde está o mouse?

Fogg:

— Não precisamos dele.

Passepartout começa a reconsiderar suas escolhas profissionais.

Aprenda:

TSO
ISPF
PF KEYS
COMMAND LINE
MEMBERS
LIBRARIES
EDIT
VIEW
BROWSE

E comandos fundamentais do editor:

I
D
R
C
M
A
B
CC
MM

Aqui começa a alfabetização mainframe.

---

📦 Dias 5–7 — Datasets

Antes de COBOL:

datasets.

Entenda:

PS
PDS
PDSE
MEMBER
RECFM
LRECL
BLKSIZE
DSORG
DISP

Você precisa conseguir olhar:

BELLACOSA.COBOL.SOURCE

e compreender que isso não é simplesmente uma “pasta”.

---

🧭 Dias 8–10 — Navegação

Pratique.

Crie datasets.

Crie members.

Edite.

Copie.

Renomeie.

Delete.

Liste.

Phileas Fogg olha para o relógio.

DAY 10
STATUS: ON SCHEDULE

Passepartout comemora.

Erro.

Ainda faltam 70 dias.

---

🚂 DIAS 11–20 — SUEZ

JCL: comprando a passagem do JOB

Agora precisamos fazer alguma coisa executar.

Entramos no território do:

JCL — Job Control Language

JCL não é exatamente uma linguagem de programação convencional.

É mais parecido com preencher documentos de imigração para convencer o z/OS a deixar seu programa trabalhar.

---

🎫 JOB

//FOGG80   JOB (ACCT),'AROUND WORLD',
//             CLASS=A,
//             MSGCLASS=X

Nosso passaporte.

---

🚂 EXEC

//STEP01 EXEC PGM=FOGGCOB

Nosso trem.

---

🧳 DD

//INPUT DD DSN=FOGG.WORLD.INPUT,DISP=SHR

Nossa bagagem.

Agora aprenda:

JOB
EXEC
DD
DSN
DISP
SPACE
DCB
SYSOUT
STEPLIB
SYSPRINT
SYSIN

---

🚦 JES2

O JOB é submetido.

SUBMIT

E desaparece.

Passepartout entra em pânico.

— Perdemos o programa!

Não.

Ele entrou no maravilhoso sistema ferroviário chamado:

JES2

Precisamos aprender:

INPUT
EXECUTION
OUTPUT
PURGE

E então:

SDSF

Aqui você aprende a investigar:

JOB STATUS
RC
SYSOUT
JESMSGLG
JESJCL
JESYSMSG

Primeira grande vitória:

MAXCC=0000

Fogg:

— Excelente.

Bellacosa:

— Calma.

Porque todo mainframeiro precisa aprender cedo:

MAXCC=0 significa que o JOB terminou; não significa que você fez a coisa certa.

---

🐘 DIAS 21–35 — BOMBAIM

COBOL: finalmente encontramos Grace Hopper no caminho

Chegamos à grande escala.

Quinze dias.

Agora COBOL.

Primeiro compreenda sua anatomia:

IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION

Não comece decorando comandos.

Entenda a arquitetura.

---

🪪 IDENTIFICATION DIVISION

IDENTIFICATION DIVISION.
PROGRAM-ID. FOGG80.

Quem sou eu?

---

🌍 ENVIRONMENT DIVISION

Onde vivo?

Com quais recursos trabalho?

---

📦 DATA DIVISION

Aqui está uma das grandes diferenças culturais do COBOL.

Dados são cidadãos de primeira classe.

Aprenda:

PIC X
PIC 9
PIC S9
V
COMP
COMP-3
88 LEVEL
REDEFINES
OCCURS
COPYBOOK

Exemplo:

01 WS-PASSENGER.
   05 WS-NAME       PIC X(30).
   05 WS-AGE        PIC 9(03).
   05 WS-BALANCE    PIC S9(9)V99 COMP-3.
   05 WS-STATUS     PIC X.
      88 ACTIVE     VALUE 'A'.

Não pule essa parte.

Quem não entende DATA DIVISION acaba passando metade da carreira perguntando por que tomou S0C7.

---

⚙️ PROCEDURE DIVISION

Agora fazemos coisas.

Aprenda:

MOVE
IF
EVALUATE
PERFORM
COMPUTE
ADD
SUBTRACT
MULTIPLY
DIVIDE
DISPLAY
STRING
UNSTRING
INSPECT

Depois:

OPEN
READ
WRITE
REWRITE
CLOSE

---

🔄 O coração do batch

Você precisa conseguir escrever sozinho algo parecido com:

OPEN
 ↓
READ
 ↓
VALIDATE
 ↓
PROCESS
 ↓
WRITE
 ↓
READ AGAIN
 ↓
CLOSE

Isso parece simples.

É simples.

E variações dessa arquitetura movimentaram quantidades absurdas de negócios durante décadas.

---

💥 Dias 31–35 — Aprenda a quebrar COBOL

Agora provoque erros.

Sim.

De propósito.

Crie situações que gerem problemas.

Investigue:

S0C7
S0C4
FILE STATUS
RETURN CODE

Use:

DISPLAY 'WS-VALUE=' WS-VALUE

Leia compile listing.

Entenda offsets.

Procure mensagens.

Porque aprender programação sem aprender debugging é como Phileas Fogg aprender a embarcar em navios sem aprender o que fazer quando o navio quebra.

---

🚢 DIAS 36–43 — CALCUTÁ

VSAM: os dados precisam morar em algum lugar

Agora entramos no universo dos arquivos corporativos.

Aprenda primeiro arquivos sequenciais.

Depois:

VSAM

Conceitos:

KSDS
ESDS
RRDS
LDS
VRRDS

Para começar, concentre-se principalmente no:

KSDS

Entenda:

KEY
RECORD
CI
CA
INDEX
DATA COMPONENT

Depois:

IDCAMS

Comandos:

DEFINE
DELETE
REPRO
LISTCAT

Agora seu COBOL começa a conversar com dados persistentes.

---

🛳️ DIAS 44–53 — HONG KONG

Db2: SQL entra na viagem

Chegamos ao banco relacional.

Aprenda SQL antes de complicar.

SELECT
INSERT
UPDATE
DELETE

Depois:

JOIN
GROUP BY
ORDER BY
SUBQUERY
INDEX
COMMIT
ROLLBACK

Agora coloque isso dentro de COBOL:

EXEC SQL
   SELECT BALANCE
     INTO :WS-BALANCE
     FROM CUSTOMER
    WHERE CUSTOMER_ID = :WS-ID
END-EXEC.

E imediatamente aprenda:

SQLCODE
SQLSTATE

Porque:

SQLCODE = 0

é maravilhoso.

SQLCODE = +100

conta outra história.

E:

SQLCODE < 0

é quando Passepartout começa a procurar o bote salva-vidas.

---

🧠 Entenda também

PLAN
PACKAGE
BIND
DBRM
HOST VARIABLE
CURSOR

Não precisa dominar administração Db2.

Nosso objetivo é:

programador COBOL capaz de utilizar Db2 conscientemente.

---

🇯🇵 DIAS 54–61 — YOKOHAMA

CICS: saímos do batch e entramos no mundo online

Até agora:

JOB
 ↓
PROCESSA
 ↓
TERMINA

Agora:

USUÁRIO
 ↓
TRANSAÇÃO
 ↓
CICS
 ↓
COBOL
 ↓
RESPOSTA

Mudamos de planeta.

Aprenda:

TRANSACTION
PROGRAM
TASK
TERMINAL
COMMAREA
CHANNEL
CONTAINER

Comandos básicos:

EXEC CICS RECEIVE
EXEC CICS SEND
EXEC CICS READ
EXEC CICS WRITE
EXEC CICS LINK
EXEC CICS XCTL
EXEC CICS RETURN

E jamais esqueça:

RESP
RESP2

---

🖥️ BMS

Conheça:

MAP
MAPSET
SEND MAP
RECEIVE MAP

Você não precisa tornar-se arqueólogo de telas verdes.

Mas precisa entender como aplicações tradicionais online funcionam.

---

🚨 Entenda a arquitetura

Comece a reconhecer:

TOR
AOR
FOR

e conceitos como:

TSQ
TDQ
PPT
PCT

Agora Phileas Fogg consegue executar batch durante a madrugada e transações durante o dia.

Está ficando perigoso.

---

🚂 DIAS 62–69 — SAN FRANCISCO

Segurança, Unix e o mainframe que ninguém mostra nos filmes

Agora apresentamos:

RACF

Não precisa virar administrador de segurança.

Mas precisa compreender:

USER
GROUP
RESOURCE
PROFILE
ACCESS
READ
UPDATE
CONTROL
ALTER

E principalmente:

SAF

Comece a compreender que segurança em z/OS não é simplesmente “login e senha”.

---

🐧 USS

Surpresa.

Existe Unix dentro do z/OS.

Passepartout:

— Linux?

Não.

Unix System Services.

Aprenda:

PATH
FILE
DIRECTORY
PERMISSION
SHELL
PROCESS

Experimente comandos familiares:

ls
cd
cat
grep
chmod

Agora aquela divisão mental:

MAINFRAME | MUNDO MODERNO

começa a desmoronar.

Como deveria.

---

🔧 Zowe + Git

Chegamos ao século XXI.

Conheça:

Zowe
VS Code
IBM Z Open Editor
Git
GitHub / GitLab

Aprenda o básico:

clone
branch
commit
merge
push
pull

COBOL pode perfeitamente participar de workflows modernos.

Não precisamos sacrificar cartões perfurados numa noite de lua cheia para compilar programa.

---

🌉 z/OS Connect e APIs

Agora faça a ponte:

MOBILE
   ↓
REST API
   ↓
z/OS CONNECT
   ↓
CICS
   ↓
COBOL
   ↓
DB2

E finalmente compreenda uma coisa fundamental:

modernização não significa necessariamente reescrever.

Às vezes significa integrar.

---

🗽 DIAS 70–77 — NOVA YORK

DevOps: Phileas Fogg automatiza a viagem

Estamos quase voltando para Londres.

Agora precisamos transformar conhecimento isolado em pipeline.

Conheça:

CI/CD
BUILD
TEST
PACKAGE
DEPLOY

Ferramentas e conceitos possíveis:

DBB
zAppBuild
Jenkins
GitHub Actions
GitLab CI
UrbanCode
Ansible
Zowe
z/OSMF

Não tente aprender profundamente todas.

Entenda:

o fluxo.

SOURCE
   ↓
GIT
   ↓
BUILD
   ↓
COMPILE
   ↓
TEST
   ↓
PACKAGE
   ↓
DEPLOY

---

🧪 Testes

Aprenda a pensar em:

UNIT TEST
COMPONENT TEST
INTEGRATION TEST
E2E

Conheça:

ZUnit
COBOL Check
Galasa

Mais importante que decorar ferramentas:

faça código testável.

---

🤖 IA entra no trem

Naturalmente precisamos conversar sobre IA.

Use IA para:

EXPLICAR CÓDIGO
GERAR TESTES
DOCUMENTAR
ANALISAR ERROS
CRIAR HIPÓTESES
EXPLICAR JCL
ENTENDER COPYBOOKS
SUGERIR REFACTORING

Mas lembre:

IA
   ↓
HIPÓTESE

não:

IA
   ↓
VERDADE ABSOLUTA

Compile.

Teste.

Valide.

---

🏁 DIAS 78–80 — ATLÂNTICO → LONDRES

A prova final

Phileas Fogg está voltando.

Passepartout olha para o calendário.

Três dias.

Agora não existe curso.

Não existe tutorial.

Não existe instrutor segurando sua mão.

Existe apenas uma especificação.

---

🎯 PROJETO FINAL — FOGG BANK

Construa uma pequena aplicação:

Cadastro e movimentação de clientes.

Ela deverá possuir:

COBOL
+
JCL
+
DATASET
+
VSAM ou Db2
+
CICS ou interface batch

Fluxo:

CLIENTE
   ↓
VALIDAÇÃO
   ↓
CONSULTA
   ↓
MOVIMENTAÇÃO
   ↓
ATUALIZAÇÃO
   ↓
RELATÓRIO

Depois coloque o source em Git.

Documente.

Teste.

Provoque erros.

Corrija.

Crie README.

Explique a arquitetura.

Se possível, exponha alguma funcionalidade como API.

Agora você possui algo muito mais importante que:

ASSISTI 80 HORAS DE CURSO

Você possui:

EU CONSTRUÍ ISTO.

---

🧭 O MAPA COMPLETO

Depois de 80 dias nossa viagem ficou assim:

                    🌍 MAINFRAME ROAD MAP

                         IBM Z
                           │
                         z/OS
                           │
              ┌────────────┴────────────┐
              │                         │
           TSO/ISPF                    USS
              │                         │
           DATASETS                  SHELL
              │
             JCL
              │
            JES2
              │
            SDSF
              │
            COBOL
        ┌──────┼───────┐
        │      │       │
      VSAM    Db2     CICS
        │      │       │
        └──────┼───────┘
               │
              RACF
               │
             APIs
               │
         z/OS Connect
               │
              Git
               │
            DevOps
               │
            Testing
               │
               IA

Agora existe uma coisa preciosa:

CONTEXTO.

---

🎓 O que você NÃO será depois de 80 dias

Vamos destruir uma promessa de marketing antes que ela nasça.

Depois de 80 dias você provavelmente não será:

SYSTEM PROGRAMMER
DBA DB2
CICS ADMIN
RACF SPECIALIST
STORAGE SPECIALIST
PERFORMANCE SPECIALIST
SMP/E WIZARD
ASSEMBLER JEDI

E está tudo bem.

Mainframe é um continente.

Não uma tecnologia.

Ninguém conhece tudo.

---

🧠 O que você PODE ser

Você pode conseguir olhar para:

JOB
 ↓
JCL
 ↓
COBOL
 ↓
CICS
 ↓
DB2

e compreender aproximadamente o caminho.

Pode receber:

S0C7

e não fugir pela janela.

Pode abrir SDSF.

Pode procurar o step.

Pode ler SYSOUT.

Pode compreender um programa COBOL.

Pode alterar.

Compilar.

Executar.

Investigar.

Testar.

E principalmente:

saber qual é a próxima pergunta.

Esse é um enorme avanço.

---

🎩 O relógio de Phileas Fogg

Londres.

Reform Club.

80º dia.

Os cavalheiros estão esperando.

Relógio:

20:44

Nenhum sinal.

20:45.

Porta fechada.

A aposta parece perdida.

Então:

20:45:57

A porta abre.

Phileas Fogg entra.

Passepartout atrás dele carrega um notebook.

Na tela:

FOGG80.COBOL
FOGG80.JCL
FOGG80.COPYLIB
FOGG80.TEST

Um cavalheiro pergunta:

— Então aprendeu mainframe?

Fogg responde:

— Não.

Silêncio.

— Como assim?

Ele coloca o chapéu sobre a mesa.

— Aprendi o suficiente para compreender o tamanho daquilo que ainda preciso aprender.

O velho mainframeiro no fundo da sala sorri.

Porque essa talvez seja a primeira evidência de que Phileas Fogg realmente aprendeu alguma coisa.

---

☕ Epílogo — A aposta

Passepartout aproxima-se do terminal.

Submete o projeto final.

SUBMIT 'FOGG80.JCL(MOONJOB)'

Não.

Arquivo errado.

Fogg olha para ele.

Passepartout:

— Desculpe, monsieur.

Agora:

SUBMIT 'FOGG80.JCL(FINALJOB)'

JES2 recebe.

$HASP100 FINALJOB ON READER

Executando.

$HASP373 FINALJOB STARTED

Todos aguardam.

SDSF atualiza.

STEP010   RC 0000
STEP020   RC 0000
STEP030   RC 0000
STEP040   RC 0000

Finalmente:

$HASP395 FINALJOB ENDED

Fogg olha para o relógio.

Ainda dentro dos 80 dias.

Passepartout grita:

MAXCC=0000!

Champanhe.

Aplausos.

A aposta está ganha.

Então o instrutor Bellacosa aproxima-se lentamente.

Olha o relatório.

Franze a testa.

Pergunta:

— Fogg...

— Sim?

— O total deveria ser £20.000.

Na tela:

TOTAL = £200.000

Silêncio absoluto.

Fogg tira o paletó.

Senta diante do terminal.

Abre o source.

Passepartout prepara café.

Porque Phileas Fogg acaba de descobrir a última e mais importante etapa do Road Map Mainframe:

DIA 81 — DEBUG.

🎩🌍🚂🚢☕🦖

E essa viagem...

meu caro Padawan...

não termina em 80 dias.

//WORLD80 JOB (COBOL),'PHILEAS FOGG'
//STEP01  EXEC PGM=LEARN
//SYSOUT  DD SYSOUT=*

LEARNING IN PROGRESS...
DESTINATION: MAINFRAME
RETURN CODE: NEVER STOP

https://eljefemidnightlunch.blogspot.com/2026/07/devops-no-mainframe-o-guia-definitivo.html

https://eljefemidnightlunch.blogspot.com/2014/05/o-manual-proibido-da-ia-pratica-machine.html

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

 

Da Compilação à Execução de um Programa COBOL

 

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.

Leia a Parte I

https://eljefemidnightlunch.blogspot.com/2022/01/da-compilacao-execucao-de-um-programa.html

---

Parte II — CICS, Db2, IMS e Adabas

O que acontece antes da compilação

O segundo capítulo mostra que nem tudo o que aparece dentro de um programa COBOL pertence diretamente à linguagem.

Comandos como:

           EXEC CICS
                READ FILE('CLIENTES')
           END-EXEC.

ou:

           EXEC SQL
                SELECT NOME
                  INTO :WS-NOME
                  FROM CLIENTES
           END-EXEC.

precisam ser processados por componentes especializados.

CICS

Os comandos EXEC CICS são interpretados pelo tradutor CICS.

O fluxo conceitual é:

Fonte COBOL com EXEC CICS
             ↓
Tradutor CICS
             ↓
Fonte COBOL preparado
             ↓
Compilador

O programa pede ao CICS que execute serviços como:

• leitura de arquivos;

• envio e recebimento de mapas;

• acesso a filas;

• chamada de programas;

• controle de transações;

• sincronização;

• gerenciamento de recursos.

O COBOL contém a regra de negócio.

O CICS administra o ambiente transacional.

Db2

Comandos EXEC SQL precisam ser processados pelo pré-compilador Db2 ou por um coprocessador integrado.

Esse processamento pode gerar:

Fonte COBOL preparado
DBRM

O fonte segue para o compilador.

O DBRM segue para o BIND do Db2.

Esse BIND cria um package com as instruções SQL preparadas.

O capítulo esclarece uma confusão frequente:

Binder do z/OS cria o executável.
BIND do Db2 cria o package SQL.

São processos diferentes.

IMS

Programas COBOL podem acessar bancos hierárquicos e mensagens IMS por meio de chamadas DL/I.

Entre as funções comuns estão:

GU
GN
GNP
ISRT
REPL
DLET

O ambiente também utiliza estruturas como:

• DBD;

• PSB;

• PCB;

• SSA;

• layouts de segmentos.

Adabas

O acesso ao Adabas pode envolver:

• control blocks;

• format buffers;

• record buffers;

• search buffers;

• value buffers;

• interfaces de chamada;

• response codes.

Apesar de suas diferenças, CICS, Db2, IMS e Adabas compartilham o mesmo princípio:

O programa COBOL executa a regra de negócio e solicita serviços a subsistemas especializados.

Leia a Parte II

https://eljefemidnightlunch.blogspot.com/2022/02/da-compilacao-execucao-de-um-programa.html

---

Parte III — Compilação, linkedição e load library

Como o fonte se transforma em executável

O terceiro capítulo entra no coração técnico da transformação.

Depois que o fonte foi preparado, o compilador COBOL entra em cena.

Seu trabalho não se limita a trocar comandos por instruções de máquina.

Ele também analisa:

• sintaxe;

• campos;

• tipos de dados;

• tamanhos;

• parágrafos;

• referências;

• opções;

• arquivos;

• copybooks;

• expressões;

• compatibilidade;

• oportunidades de otimização.

O resultado principal é o código objeto.

Fonte COBOL
      ↓
Compilador
      ↓
Código objeto

Porém, o código objeto ainda pode possuir referências não resolvidas.

Um programa pode chamar:

           CALL 'PGMVALID'
                USING AREA-DADOS.

Se essa chamada precisar ser resolvida antecipadamente, será necessário localizar o módulo correspondente durante a linkedição.

O Binder

O Binder do z/OS reúne:

• código objeto;

• rotinas;

• interfaces;

• módulos externos;

• pontos de entrada;

• componentes de runtime.

O resultado é o módulo executável.

Código objeto
      +
Dependências
      ↓
Binder
      ↓
Load module ou program object

Esse executável é gravado em uma biblioteca como:

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

Chamadas estáticas e dinâmicas

O capítulo também explica a diferença entre chamadas estáticas e dinâmicas.

Estática

A dependência é resolvida durante a linkedição.

Dinâmica

O módulo é procurado durante a execução.

Essa escolha afeta:

• implantação;

• tamanho do executável;

• manutenção;

• versionamento;

• risco de programa não encontrado;

• necessidade de relinkedição.

Return codes

Compilador e Binder produzem mensagens e return codes.

Um RC=0 indica que a etapa terminou normalmente, mas não prova que a lógica está correta.

Um RC=4 pode conter warnings importantes.

Um erro de linkedição pode indicar:

• símbolo não resolvido;

• módulo ausente;

• biblioteca errada;

• ponto de entrada incorreto;

• interface incompatível.

O capítulo reforça uma lição essencial:

Programa compilado não significa programa testado.

Leia a Parte III

https://eljefemidnightlunch.blogspot.com/2022/03/da-compilacao-execucao-de-um-programa.html

---

Parte IV — Da load library à CPU

JCL, JES2, QSAM, VSAM, memória e processamento

O quarto capítulo acompanha o executável durante a execução real.

Depois da linkedição, o programa está pronto, mas ainda permanece parado em uma load library.

No ambiente batch, o JCL solicita sua execução:

//STEP01 EXEC PGM=PGMCLI01

Uma STEPLIB pode informar onde o módulo deve ser procurado:

//STEPLIB DD DISP=SHR,
//           DSN=EMPRESA.SISTEMA.LOADLIB

Se o módulo não for encontrado, pode ocorrer um erro como S806.

QSAM

Programas que acessam arquivos sequenciais podem utilizar QSAM.

No COBOL:

ASSIGN TO CLIENTES

No JCL:

//CLIENTES DD DISP=SHR,
//            DSN=EMPRESA.DADOS.CLIENTES

A ligação é:

Nome lógico COBOL
       ↓
DDNAME
       ↓
Dataset físico

VSAM

VSAM oferece organizações como:

• KSDS;

• ESDS;

• RRDS;

• LDS;

• VRRDS.

Um KSDS pode ser acessado por chave e também de forma sequencial.

O programa precisa verificar o FILE STATUS depois das operações.

Retornos como 00, 10, 22, 23, 35 e 39 possuem significados diferentes conforme a operação e o contexto.

JES2

O JES2 administra o fluxo batch.

Ele:

• recebe o job;

• mantém filas;

• utiliza o spool;

• organiza classes;

• administra saídas;

• acompanha o processamento.

O JES2 não executa diretamente as instruções COBOL.

O fluxo correto é mais próximo de:

JES2 administra o job
Initiator inicia o step
z/OS prepara o ambiente
Loader carrega o módulo
Dispatcher entrega processador
CPU executa as instruções

Memória e CPU

O programa é carregado em um address space.

O Language Environment prepara o runtime.

O dispatcher distribui capacidade de processamento.

O WLM ajuda a priorizar workloads conforme objetivos de serviço.

A CPU não executa comandos COBOL como:

MOVE
READ
PERFORM
COMPUTE

Ela executa as instruções de máquina produzidas pelo compilador.

O capítulo também explica a diferença entre:

Tempo de CPU
Tempo decorrido

Um job pode permanecer dez minutos em execução e consumir apenas alguns segundos de CPU.

O restante pode ser espera por:

• arquivos;

• Db2;

• IMS;

• Adabas;

• locks;

• filas;

• mensagens;

• armazenamento;

• rede.

Leia a Parte IV

https://eljefemidnightlunch.blogspot.com/2022/04/da-compilacao-execucao-de-um-programa.html

---

O que o Padawan aprende com a série

Ao concluir os quatro capítulos, o iniciante passa a compreender que um programa COBOL não é apenas um membro dentro de uma biblioteca.

Ele faz parte de uma cadeia maior.

Fonte
Copybook
Tradutor
Pré-compilador
Compilador
Objeto
Binder
Load
Package
JCL
JES2
Spool
Loader
Memória
CPU
Dados
Resultado

Essa visão permite investigar problemas com muito mais precisão.

Em vez de dizer:

“O programa não funciona”,

o profissional começa a perguntar:

• O fonte correto foi compilado?

• O copybook correto foi utilizado?

• O CICS traduziu os comandos?

• O DBRM foi gerado?

• O package Db2 foi criado?

• O Binder resolveu todas as referências?

• O load foi gravado na biblioteca correta?

• A STEPLIB aponta para essa biblioteca?

• O DDNAME corresponde ao ASSIGN TO?

• O dataset existe?

• O FILE STATUS foi tratado?

• O SQLCODE foi verificado?

• O programa terminou com return code ou abend?

• O tempo foi gasto em CPU ou em espera?

Essas perguntas transformam uma investigação baseada em tentativa e erro em um diagnóstico técnico estruturado.

---

A diferença entre escrever COBOL e entender o mainframe

Escrever COBOL é uma habilidade importante.

Mas compreender o ciclo completo de construção e execução é o que permite ao profissional atuar com segurança em ambientes corporativos.

O programador que conhece apenas o fonte pode corrigir uma linha.

O profissional que conhece o ecossistema consegue compreender:

• por que uma alteração não chegou ao ambiente;

• por que o programa antigo continua executando;

• por que um package está incompatível;

• por que o arquivo não abriu;

• por que o job está aguardando;

• por que o tempo decorrido aumentou;

• por que a CPU não é a causa da lentidão;

• por que uma recompilação em massa foi necessária;

• por que um copybook deve ser tratado como contrato.

Esse é o verdadeiro objetivo da série.

Não ensinar apenas comandos.

Ensinar a enxergar o sistema completo.

---

Leia a série completa

Parte I

O Nascimento do Programa COBOL: Código-fonte e Copybooks

Parte II

CICS, Db2, IMS e Adabas: O Código Antes da Compilação

Parte III

Compilação, Linkedição e Load Library

Parte IV

Da Load Library à CPU: JCL, JES2, QSAM, VSAM e Execução

---

Conclusão

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-EXEC EVIDÊNCIAS: 05 ARTIGOS AMBIENTE: IBM Z / z/OS STATUS: 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.

Arquivos de evidências

↓ Consultar índice rastreável

Evidência selecionada Parte I — Código-fonte, bibliotecas e copybooks

Abrir original ↗

Processando evidência digital...

Laudo preliminar: o nascimento do programa

A primeira parte acompanha a transformação da regra de negócio em código-fonte COBOL, explica o papel das bibliotecas e mostra por que copybooks funcionam como contratos de dados compartilhados entre programas.

COBOL código-fonte copybook SYSLIB IBM Z

Índice completo do dossiê COBOL

Acesse diretamente cada artigo da série “Da Compilação à Execução de um Programa COBOL”. Os links abaixo são HTML convencionais, legíveis por leitores, navegadores, Google, Bing e outros mecanismos de busca.

PARTE I · JANEIRO DE 2022 O nascimento do programa COBOL: código-fonte e copybooks Bibliotecas de fontes, COPY, CALL, layouts compartilhados, contratos de dados e localização de copybooks por SYSLIB. PARTE II · FEVEREIRO DE 2022 CICS, Db2, IMS e Adabas: o código antes da compilação Tradução CICS, processamento de SQL, DBRM, package Db2, chamadas DL/I, control blocks e serviços de subsistemas. PARTE III · MARÇO DE 2022 Compilação, linkedição, Binder e load library Código objeto, referências externas, chamadas estáticas e dinâmicas, program objects, return codes e bibliotecas de carga. PARTE IV · ABRIL DE 2022 Da load library à CPU: JCL, JES2, QSAM e VSAM STEPLIB, DDNAME, datasets, FILE STATUS, spool, initiator, loader, address space, dispatcher, WLM e processamento na CPU. DOSSIÊ MESTRE · MAIO DE 2022 Da Compilação à Execução de um Programa COBOL — série completa Visão integrada da jornada: regra de negócio, fonte, copybooks, tradutores, compilador, Binder, load module, JCL, JES2, memória, CPU, arquivos, subsistemas e resultados.

Bellacosa Mainframe Forensic Lab · Nenhum byte é inocente até que os logs provem o contrário.