☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta ibm zOS. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ibm zOS. Mostrar todas as mensagens

sexta-feira, 13 de junho de 2025

☕💣 FUNÇÕES SEM SUBPROGRAMAS? O DIA EM QUE O COBOL APRENDEU A CRIAR SUAS PRÓPRIAS APIs — E QUASE NINGUÉM PERCEBEU

 

Bellacosa Mainframe apresenta as funçoes criadas em cobol modo api on

☕💣 FUNÇÕES SEM SUBPROGRAMAS? O DIA EM QUE O COBOL APRENDEU A CRIAR SUAS PRÓPRIAS APIs — E QUASE NINGUÉM PERCEBEU

Existe um momento na carreira de todo profissional de Mainframe em que ele descobre algo e pensa:

"Como ninguém me contou isso antes?"

Foi exatamente essa sensação que muitos desenvolvedores tiveram quando conheceram as User Defined Functions (UDFs) introduzidas nas versões modernas do COBOL Enterprise da IBM.

Durante décadas, quando precisávamos reutilizar lógica em COBOL, a solução era sempre a mesma:

  • CALL de subprograma

  • COPYBOOK

  • Macro

  • Módulos compartilhados

Funcionava.

Ainda funciona.

Mas o COBOL evoluiu.

E hoje o programador pode criar suas próprias funções, utilizá-las dentro de expressões e fazer chamadas tão elegantes quanto as funções nativas do compilador.

Sim.

Da mesma forma que você usa:

FUNCTION CURRENT-DATE

ou

FUNCTION UPPER-CASE(...)

você pode criar:

FUNCTION CALCULA-IR(...)

ou

FUNCTION VALIDA-CPF(...)

ou qualquer outra regra de negócio.

Para quem passou décadas trabalhando apenas com programas e subprogramas, isso parece quase magia.

Mas não é.

É apenas COBOL moderno.


Um Pouco de História

Nas versões clássicas do COBOL:

  • COBOL VS COBOL II

  • COBOL/370

  • COBOL for MVS

não existia conceito de função definida pelo usuário.

Tudo precisava ser feito através de:

CALL "ROTINA01"

O compilador não conhecia o conceito de retorno funcional.

Quando surgiram:

  • Enterprise COBOL V5

  • Enterprise COBOL V6

a IBM passou a suportar recursos alinhados ao padrão ISO COBOL moderno.

Entre eles:

User Defined Functions

ou simplesmente:

Funções Definidas pelo Usuário


O Que é Uma User Defined Function?

É um módulo COBOL especial que:

  • recebe parâmetros

  • processa dados

  • retorna um único valor

exatamente como uma função matemática.

Exemplo:

RESULTADO =
    FUNCTION DOBRO(VALOR)

Ao invés de:

CALL "DOBRO"

Quando Vale a Pena Utilizar?

Imagine uma regra utilizada em centenas de programas.

Por exemplo:

  • cálculo de imposto

  • cálculo de juros

  • validação de CPF

  • mascaramento de dados LGPD

  • formatação de código interno

Criar uma função centralizada reduz:

  • duplicação

  • manutenção

  • erros

e aumenta a legibilidade.


Estrutura de Uma Função COBOL

O segredo está na identificação.

Observe:

IDENTIFICATION DIVISION.

FUNCTION-ID. DOBRO.

Perceba:

Não usamos:

PROGRAM-ID

Usamos:

FUNCTION-ID

Isso transforma o módulo em uma função.


Exemplo Completo

Função DOBRO

       IDENTIFICATION DIVISION.
       FUNCTION-ID. DOBRO.

       DATA DIVISION.

       LINKAGE SECTION.

       01 LK-VALOR      PIC S9(9) COMP-5.

       01 RESULTADO     PIC S9(9) COMP-5.

       PROCEDURE DIVISION
            USING LK-VALOR
            RETURNING RESULTADO.

           COMPUTE RESULTADO =
                   LK-VALOR * 2

           GOBACK.

Simples.

Recebe:

LK-VALOR

Retorna:

RESULTADO

O RETURNING

A palavra-chave fundamental é:

RETURNING

Ela define o valor devolvido pela função.

Exemplo:

PROCEDURE DIVISION
    USING ENTRADA
    RETURNING SAIDA

Sem RETURNING não existe função.


Como Chamar a Função

Agora imagine um programa principal.

IDENTIFICATION DIVISION.
PROGRAM-ID. TESTE.

Working Storage

01 WS-NUMERO       PIC 9(4).
01 WS-RESULTADO    PIC 9(5).

Chamada

MOVE 10 TO WS-NUMERO

COMPUTE WS-RESULTADO =
        FUNCTION DOBRO(WS-NUMERO)

DISPLAY WS-RESULTADO

Resultado:

20

O Que o Compilador Faz?

Quando encontra:

FUNCTION DOBRO(...)

o compilador procura um módulo com:

FUNCTION-ID. DOBRO

e gera a ligação automaticamente.

É semelhante ao que acontece com:

FUNCTION CURRENT-DATE

Em Qual Biblioteca Deve Ser Gravado?

Aqui existe uma dúvida muito comum.

A função compilada gera um módulo objeto exatamente como qualquer outro programa COBOL.

Normalmente:

OBJETO

Vai para:

&&OBJ
SYSLIN

durante a compilação.


LOAD MODULE

Após o Link Edit:

LOADLIB

ou

STEPLIB

ou

USER.LOADLIB

dependendo dos padrões da empresa.

Exemplo:

PROD.COBOL.LOAD

ou

DEV.COBOL.LOAD

Que Tipo de Objeto é Criado?

Fisicamente o compilador gera:

Object Deck

OBJETO

e depois:

Program Object

ou

Load Module

dependendo da configuração do Binder.

Ou seja:

não existe um tipo especial de dataset para funções.

A função é armazenada como um módulo executável normal.

O diferencial está no:

FUNCTION-ID

Passo a Passo Completo

Passo 1

Criar o fonte.

Exemplo:

USER.COBOL(FDOBRO)

Passo 2

Codificar:

FUNCTION-ID. DOBRO.

Passo 3

Compilar.

Exemplo de JCL:

//COBOL EXEC IGYWCL

ou

//COB EXEC PROC=IGYWCLG

Dependendo do ambiente.


Passo 4

Gerar módulo em LOADLIB.

Exemplo:

USER.LOADLIB

Passo 5

Adicionar a LOADLIB na STEPLIB.

//STEPLIB DD DSN=USER.LOADLIB,

Passo 6

Compilar os programas consumidores.

O compilador localizará a função.


Funções Com Múltiplos Parâmetros

Exemplo:

FUNCTION-ID. SOMA2.

Linkage:

01 LK-N1 PIC S9(9).
01 LK-N2 PIC S9(9).

01 RETORNO PIC S9(9).

Procedure:

PROCEDURE DIVISION
    USING LK-N1 LK-N2
    RETURNING RETORNO.

    COMPUTE RETORNO =
        LK-N1 + LK-N2

    GOBACK.

Uso:

COMPUTE TOTAL =
        FUNCTION SOMA2(10,20)

Resultado:

30

Funções Podem Chamar Outras Funções

Sim.

Exemplo:

FUNCTION DOBRO(
    FUNCTION SOMA2(5,5))

Primeiro:

SOMA2 = 10

Depois:

DOBRO = 20

Muito parecido com linguagens modernas.


Funções Podem Ser Recursivas?

Sim.

Desde que o compilador permita:

RECURSIVE

e que a lógica esteja preparada.

Mas normalmente regras de negócio não exigem isso.


Diferença Entre CALL e FUNCTION

CALL

CALL "CALCULO"

Características:

  • múltiplos parâmetros

  • sem retorno obrigatório

  • paradigma tradicional


FUNCTION

FUNCTION CALCULO(...)

Características:

  • retorno explícito

  • pode participar de expressões

  • sintaxe mais elegante


Exemplo Real de Negócio

Imagine validar CPF.

Em vez de:

CALL "CPFVAL"

você pode escrever:

IF FUNCTION CPF-VALIDO(CPF)

Muito mais legível.

A regra passa a parecer uma instrução nativa da linguagem.


Opções de Compilação Recomendadas

Nas versões atuais do Enterprise COBOL V6.x é comum utilizar:

OPT(2)
ARCH(13)
RENT
LIST
MAP
XREF
SSRANGE

Em desenvolvimento:

SSRANGE

ajuda bastante na identificação de erros.

Em produção:

NOSSRANGE

para melhor desempenho.


Compatibilidade

As User Defined Functions fazem parte das versões modernas do COBOL Enterprise.

São suportadas nas famílias atuais:

  • Enterprise COBOL V5

  • Enterprise COBOL V6

  • z/OS modernos

Sempre confirme a versão instalada junto ao time de sistemas.


Ganho Arquitetural

O maior benefício não é técnico.

É arquitetural.

Você passa a criar uma verdadeira biblioteca corporativa de regras.

Imagine uma empresa com funções:

CALCULA-IR
CALCULA-IOF
VALIDA-CPF
VALIDA-CNPJ
FORMATA-CEP

Todas reutilizadas por centenas de programas.

O resultado é:

  • menos código duplicado

  • manutenção centralizada

  • maior padronização

  • menor risco operacional


A Grande Sacada

Durante quarenta anos aprendemos que reutilização em COBOL significava:

CALL

Mas o COBOL moderno adicionou uma camada muito mais elegante.

Hoje podemos construir verdadeiras APIs corporativas diretamente dentro da linguagem usando:

FUNCTION-ID

e consumi-las com:

FUNCTION nome-da-funcao(...)

Para o desenvolvedor que ainda programa como em 1995, isso parece um detalhe.

Para quem projeta sistemas corporativos gigantescos, isso é uma mudança de paradigma.

Porque, pela primeira vez, o COBOL permite encapsular regras de negócio reutilizáveis com a mesma simplicidade com que usamos CURRENT-DATE, UPPER-CASE ou LENGTH.

E é justamente aí que mora a ironia: milhares de profissionais continuam criando subprogramas para tudo, enquanto o compilador moderno já oferece uma forma muito mais elegante de transformar regras de negócio em funções reutilizáveis.

Em outras palavras, o COBOL não virou uma linguagem nova.

Mas aprendeu um truque que muitos veteranos ainda não descobriram. ☕💣🚀


segunda-feira, 22 de fevereiro de 2021

☕🔥 REDES NEURAIS EXPLICADAS PARA UM COBOLISTA SÊNIOR — “O DIA EM QUE O PROGRAMA COMEÇOU A APRENDER SOZINHO” 🔥💾

Bellacosa Mainframe e as redes neurais

 

☕🔥 REDES NEURAIS EXPLICADAS PARA UM COBOLISTA SÊNIOR — “O DIA EM QUE O PROGRAMA COMEÇOU A APRENDER SOZINHO” 🔥💾

Programador COBOL experiente normalmente pensa assim:

“Programa é regra.”
“Entrada → PROCESSAMENTO → Saída.”
“Se deu erro, existe uma condição mal tratada.”
“Toda lógica precisa ser explícita.”

E é exatamente aí que acontece o choque quando alguém vê IA moderna pela primeira vez.

Porque numa rede neural…

O programador NÃO escreve a regra final.

Ele escreve o mecanismo de aprendizado.

E isso muda absolutamente tudo.


☕ O QUE É UMA REDE NEURAL?

Pense assim…

No COBOL clássico você faz:

IF SALDO > 1000
MOVE "CLIENTE VIP" TO STATUS
END-IF

Você define a regra.

Já numa rede neural você mostra milhares de exemplos:

Cliente A -> VIP
Cliente B -> NORMAL
Cliente C -> VIP

A rede começa a “descobrir” padrões matemáticos sozinha.

Ela aprende probabilidades internas.


☕ A ORIGEM DAS REDES NEURAIS

A ideia nasceu tentando imitar o cérebro humano.

Lá nos anos 1940 começaram os estudos:

  • neurônio artificial
  • conexões
  • pesos
  • aprendizado

Mas faltava poder computacional.

Durante décadas isso ficou quase “acadêmico”.

A explosão veio quando apareceram:

  • GPUs
  • Big Data
  • Cloud
  • processamento paralelo
  • datasets gigantescos

Ou seja…

A IA moderna nasceu quando o hardware finalmente conseguiu executar aquilo que a teoria queria desde os anos 50.


☕ O QUE É UM “NEURÔNIO” NA PRÁTICA?

Imagine um mini-programa matemático.

Ele recebe entradas:

idade
salário
tempo_empresa

Faz contas internas:

entrada × peso

Soma tudo.

Depois passa numa “função de ativação”.

Resultado:

0.98 = quase certeza
0.02 = improvável

☕ VISÃO MAINFRAME DA REDE NEURAL

Pense numa cadeia de SORT + IFs + cálculos + estatística.

Mas onde:

  • as regras mudam sozinhas
  • os pesos se ajustam
  • os parâmetros são recalculados automaticamente

Isso é o ponto mais importante.


☕ COMO UMA REDE APRENDE?

Aqui entra o “treinamento”.

Exemplo:

Você quer detectar fraude bancária.

Você alimenta:

Transação -> Fraude
Transação -> Normal

Milhões de vezes.

A rede:

  1. tenta prever
  2. erra
  3. mede o erro
  4. ajusta pesos
  5. tenta novamente

Isso se repete milhares de vezes.


☕ ISSO É O “LOOP DE APRENDIZADO”

Na cabeça do cobolista:

PERFORM UNTIL ERRO < LIMITE
CALCULA
AJUSTA-PESOS
END-PERFORM

A essência é essa.


☕ O QUE SÃO OS “PESOS”?

Os pesos são a “importância” das entradas.

Exemplo:

idade = peso 0.2
salário = peso 0.8

A rede aprende quais fatores importam mais.


☕ O QUE É BACKPROPAGATION?

Aqui mora a “mágica”.

A rede calcula o erro:

Esperado: 1
Obtido: 0.34

Depois ela volta ajustando os pesos internos.

É quase um:

ROLLBACK MATEMÁTICO

corrigindo tudo camada por camada.


☕ ESTRUTURA DE UMA REDE

Entrada

Dados chegam.

Camadas ocultas

Processamento matemático.

Saída

Resultado final.

Exemplo:

[ENTRADA]
idade
salário
histórico



[CAMADAS]



[SAÍDA]
fraude = 98%

☕ TIPOS DE REDES

Perceptron

A mais simples.

MLP

Rede multicamadas clássica.

CNN

Muito usada para imagens.

RNN

Sequências e texto.

Transformers

A arquitetura usada no ChatGPT.


☕ QUAL A LINGUAGEM MAIS USADA?

Hoje:

Python domina completamente.

Porque possui bibliotecas absurdamente prontas.


☕ PRINCIPAIS FRAMEWORKS

TensorFlow

Google.

PyTorch

Meta/Facebook.

Hoje PyTorch domina pesquisa e IA generativa.


☕ EXEMPLO SIMPLES EM PYTHON

from sklearn.neural_network import MLPClassifier

X = [[0,0], [0,1], [1,0], [1,1]]
y = [0,1,1,0]

rede = MLPClassifier(hidden_layer_sizes=(4,))
rede.fit(X, y)

print(rede.predict([[1,0]]))

Aqui ela aprende XOR.

Coisa que lógica linear simples não resolve.


☕ ANALOGIA MAINFRAME PERFEITA

Treinar uma rede neural é parecido com:

Rodar milhões de jobs batch

onde cada execução ajusta parâmetros internos até encontrar a melhor precisão estatística.

Só que tudo isso ocorre automaticamente.


☕ O QUE VOCÊ PRECISA APRENDER?

🔥 FASE 1 — BASE MATEMÁTICA

O maior erro dos iniciantes:

querer aprender IA sem matemática.

Você precisa:

Álgebra linear

  • vetores
  • matrizes

Estatística

  • média
  • variância
  • probabilidade

Cálculo

  • derivadas
  • gradientes

☕ PARA COBOLISTAS: A VERDADE DURA

A maior dificuldade NÃO é programação.

É matemática.

Programar IA é relativamente simples hoje.

Entender o que está acontecendo é outra história.


☕ FASE 2 — PYTHON

Aprender:

  • variáveis
  • listas
  • loops
  • funções
  • classes
  • pandas
  • numpy

Para um programador COBOL experiente:

Python é fácil.

O choque é a sintaxe minimalista.


☕ FASE 3 — MACHINE LEARNING

Aprender:

  • treino
  • validação
  • overfitting
  • underfitting
  • loss
  • acurácia

☕ O QUE É OVERFITTING?

A rede “decorou”.

Ela não aprendeu.

Isso é clássico.

Ela vai perfeita nos dados antigos…
e horrível nos novos.


☕ TESTES EM IA

Aqui muda tudo comparado ao COBOL.

No COBOL:

resultado certo ou errado

Na IA:

probabilidade

Você mede:

  • precisão
  • recall
  • F1-score
  • taxa de erro

☕ COMO CRIAR SUA PRIMEIRA REDE

PASSO 1

Instale Python.


PASSO 2

Instale bibliotecas.

pip install tensorflow

ou

pip install torch

PASSO 3

Pegue um dataset simples.

Exemplo:

  • fraude
  • spam
  • imagens
  • clientes

PASSO 4

Divida:

TREINO
TESTE

PASSO 5

Treine.

modelo.fit()

PASSO 6

Teste.

modelo.predict()

☕ ONDE UM COBOLISTA TEM VANTAGEM?

Muita vantagem.

Porque veteranos de mainframe entendem:

  • processamento massivo
  • batch
  • performance
  • consistência
  • lógica de negócio
  • dados corporativos

E IA corporativa depende MUITO disso.


☕ O ERRO DOS “AI GURUS DE INTERNET”

Muitos sabem:

  • chamar API
  • usar prompt

Mas não entendem:

  • arquitetura
  • dados
  • processamento
  • governança
  • sistemas corporativos

E aí o profissional mainframe entra forte.


☕ COMO MAINFRAME E IA ESTÃO SE UNINDO?

Hoje já existe:

  • IA em z/OS
  • inferência em LinuxONE
  • integração COBOL + APIs IA
  • Watsonx
  • z15 com aceleração IA

O mundo corporativo está conectando:

COBOL + IA

não substituindo.


☕ ROTEIRO REALISTA PARA COMEÇAR

Mês 1

Python básico.

Mês 2

Numpy + pandas.

Mês 3

Machine Learning clássico.

Mês 4

Primeira rede neural.

Mês 5

Deep Learning.

Mês 6

Projetos reais.


☕ MELHOR FORMA DE APRENDER

NÃO comece pelo ChatGPT.

Comece entendendo:

  • regressão
  • classificação
  • estatística
  • datasets

Depois redes neurais.

Depois IA generativa.


☕ FRASE QUE TODO COBOLISTA PRECISA OUVIR

“Rede neural não pensa.”

Ela ajusta pesos matemáticos tentando minimizar erro estatístico.

Isso muda completamente a forma de enxergar IA.


☕ O FUTURO DO PROFISSIONAL COBOL

O profissional COBOL que aprender IA terá um diferencial monstruoso.

Porque ele conhece:

  • o dado corporativo REAL
  • a regra bancária REAL
  • a transação REAL
  • o legado REAL

E é justamente isso que falta para muita IA moderna.


☕ RESUMO FINAL — VISÃO BELLACOSA MAINFRAME

Rede neural é:

Um gigantesco mecanismo matemático
de ajuste automático de parâmetros
baseado em erro estatístico.

Ou traduzindo para o dialeto do mainframe:

“É um batch matemático que reexecuta bilhões de vezes ajustando campos internos até reduzir o ABEND estatístico da previsão.” ☕💾🔥

 

sexta-feira, 13 de setembro de 2019

O Mistério da Tela Fantasma : Descobriu que o Verdadeiro Coração do CICS Não Estava no Código...

 

Bellacosa Mainframe e o misterio da tela fantasma

☕ Um Café no Bellacosa Mainframe

O Mistério da Tela Fantasma

Como um Jovem Programador COBOL Descobriu que o Verdadeiro Coração do CICS Não Estava no Código... Mas na Tela que Nunca Existiu

"Existem programas que processam milhões de reais por minuto. Existem programas que controlam companhias aéreas, hospitais, bolsas de valores e bancos inteiros. Mas poucos iniciantes percebem um detalhe curioso: nenhum desses programas conversa diretamente com as pessoas. Existe um intermediário silencioso. Invisível. Elegante. Antigo. Seu nome é BMS."


Capítulo 1 — A Sala Iluminada por Monitores Verdes

Era quase meia-noite.

As luzes do CPD permaneciam acesas como pequenas estrelas artificiais.

Os enormes armários IBM zSeries respiravam lentamente através do som constante dos ventiladores.

O jovem programador observava uma tela 3270.

Nenhum mouse.

Nenhuma janela.

Nenhum botão colorido.

Apenas caracteres verdes sobre um fundo escuro.

Mesmo assim...

milhões de pessoas dependiam daquela tela todos os dias.

Clientes sacavam dinheiro.

Passagens aéreas eram emitidas.

Apólices de seguro eram consultadas.

Hospitais registravam pacientes.

Tudo acontecia ali.

O rapaz abriu seu editor COBOL esperando encontrar comandos que desenhassem caixas, títulos e campos de entrada.

Não encontrou absolutamente nada.

Nenhum comando para desenhar uma janela.

Nenhum botão.

Nenhuma caixa de texto.

Nenhum formulário.

Apenas...

EXEC CICS
SEND MAP('LOGIN')
END-EXEC.

Ele franziu a testa.

— Só isso?

Onde estava a tela?

Quem a desenhava?

Foi naquele instante que o velho administrador sorriu discretamente.

— Você acabou de encontrar o primeiro fantasma do CICS...


O Fantasma chamado BMS

O maior erro de quem começa a estudar CICS é imaginar que o COBOL cria a interface.

Não cria.

Na realidade, existe uma separação extremamente elegante.

O COBOL pensa.

O BMS mostra.

O CICS conversa.

Essa divisão parece óbvia hoje.

Mas quando foi criada, décadas atrás, representava uma revolução tecnológica.


Antes do BMS, existia o caos

Imagine tentar construir um aplicativo moderno sem HTML.

Sem CSS.

Sem formulários.

Sem componentes gráficos.

Agora imagine fazer isso nos anos 70.

Era exatamente essa a realidade.

Cada terminal possuía comandos próprios.

Cada fabricante tinha um protocolo diferente.

Cada modelo de equipamento exigia programação específica.

Um simples campo para digitar uma conta bancária podia exigir dezenas de comandos de baixo nível.

Os programadores gastavam mais tempo desenhando telas do que desenvolvendo regras de negócio.

Foi então que a IBM perguntou:

"E se a tela pudesse ser descrita em vez de programada?"

Assim nasceu o Basic Mapping Support.


O que realmente é um MAP?

A maioria dos iniciantes responde:

"É uma tela."

Não exatamente.

Essa resposta está incompleta.

Um MAP é muito mais parecido com uma planta arquitetônica.

Quando um arquiteto desenha uma casa, ele não constrói a casa.

Ele apenas descreve onde estarão:

  • paredes

  • portas

  • janelas

  • corredores

  • tomadas

  • iluminação

O pedreiro transforma aquela planta em realidade.

O BMS faz exatamente isso.

Ele descreve.

O CICS constrói.


Pense como um diretor de cinema

Imagine um estúdio de Hollywood dos anos 1950.

O diretor entrega um roteiro.

O cenógrafo monta o cenário.

Os atores entram em cena.

O público vê o resultado final.

Quem é quem?

O roteiro é o MAP.

O cenógrafo é o BMS.

Os atores são os usuários.

O diretor é o COBOL.

O teatro inteiro é o CICS.

Sem roteiro...

não existe cenário.

Sem cenário...

não existe espetáculo.


A Anatomia de uma Tela

Uma tela BMS pode parecer simples.

========================================

        BANCO BELLACOSA

Conta............. ___________

Senha............. ___________

Valor............. ___________

PF3 Voltar

ENTER Confirmar

========================================

Mas escondidos atrás dessa simplicidade existem dezenas de definições.

Cada elemento possui atributos próprios.


Campo de Entrada

Permite digitação.

__________

O usuário pode alterar.


Campo Protegido

Não aceita alterações.

Muito usado para:

  • títulos

  • mensagens

  • saldo

  • CPF

  • agência


Campo Oculto

Pode existir na memória sem aparecer ao usuário.

Muito utilizado para controle interno.


Campo Numérico

Aceita apenas números.

O próprio terminal ajuda na validação.


Campo de Senha

Os caracteres podem ser mascarados.

Algo comum em caixas eletrônicos.


A posição absoluta

Uma curiosidade fascinante.

O BMS trabalha em coordenadas.

Linha.

Coluna.

Exatamente como um tabuleiro de xadrez.

Por exemplo:

Linha 5
Coluna 20

Ali ficará o campo "Conta".

Não existe "arrastar componente".

Tudo é matemático.


O Grande Tradutor

Imagine dois países.

Um fala português.

Outro fala japonês.

Entre eles existe um tradutor.

Esse tradutor chama-se BMS.

O usuário fala:

"Minha conta é 12345."

O COBOL entende:

MOVE CONTAI TO WS-CONTA

Na volta acontece o contrário.

O COBOL produz:

MOVE WS-SALDO TO SALDOO

O usuário vê:

Saldo:

R$ 8.542,30

O BMS traduziu tudo.


SEND MAP

Este talvez seja o comando mais famoso do desenvolvimento CICS.

EXEC CICS
SEND MAP('MENU001')
MAPSET('BANCO')
END-EXEC.

Parece pequeno.

Mas acontece muita coisa.

O CICS:

✔ Localiza o MAP

✔ Monta o buffer

✔ Preenche atributos

✔ Define cursor

✔ Marca campos modificados

✔ Envia ao terminal

Tudo isso acontece em milissegundos.


RECEIVE MAP

Depois do ENTER...

EXEC CICS
RECEIVE MAP('MENU001')
MAPSET('BANCO')
END-EXEC.

Agora o processo é invertido.

O terminal envia apenas aquilo que mudou.

E aqui encontramos um dos segredos mais brilhantes do CICS.


O Mistério dos Campos Invisíveis

Você imaginaria que uma tela inteira fosse enviada de volta ao servidor.

Mas não.

O terminal IBM 3270 é muito mais inteligente.

Ele utiliza um mecanismo chamado:

MDT

Modified Data Tag

Esse pequeno atributo informa:

"Este campo foi alterado."

Então apenas ele é transmitido.

Imagine uma tela com 300 campos.

Você altera somente um.

Somente um atravessa a rede.

Na década de 1970 isso era quase magia.

Hoje chamamos isso de otimização.

Naquela época era pura engenharia de alto nível.


O Curioso Mundo dos Sufixos I e O

Todo iniciante estranha.

Por que aparecem nomes como:

CLIENTEI

CLIENTEO

VALORI

VALORO

A resposta é simples.

"I"

Input.

"O"

Output.

Entrada.

Saída.

O usuário escreve em:

VALORI

O programa responde usando:

VALORO

É uma convenção que sobrevive há décadas.


MAPSET

Imagine um shopping.

Cada loja é um MAP.

O shopping inteiro é o MAPSET.

Num banco podemos ter:

LOGIN

MENU

SALDO

PIX

EXTRATO

EMPRÉSTIMO

CARTÕES

Todos pertencem ao mesmo conjunto.

Isso facilita manutenção.


DFHMSD, DFHMDI e DFHMDF

Esses nomes assustam.

Mas são incrivelmente lógicos.

Imagine construir um prédio.

Primeiro:

DFHMSD

Define o condomínio.

Depois:

DFHMDI

Define um apartamento.

Depois:

DFHMDF

Define cada cômodo.

Ou seja:

MAPSET

MAP

FIELD

Nunca mais você esquecerá essa hierarquia.


O Copybook Fantasma

Existe um momento mágico durante a montagem do BMS.

O compilador gera automaticamente um COPY COBOL.

Algo parecido com:

COPY MAPA001.

O programador praticamente nunca escreve essa estrutura manualmente.

Ela nasce da definição BMS.

Isso garante sincronismo perfeito entre a tela e o programa.


O Ciclo Completo da Vida de uma Tela

Vamos acompanhar uma transação bancária.

Cliente coloca o cartão.

TOR recebe.

AOR executa.

Programa COBOL.

SEND MAP.

Terminal mostra.

Cliente digita.

ENTER.

RECEIVE MAP.

COBOL valida.

Db2 consulta.

VSAM registra.

MQ envia mensagem.

SYNCPOINT confirma.

SEND MAP novamente.

Resposta aparece.

Perceba algo interessante.

O usuário acredita que conversou com um programa.

Na verdade conversou com uma cadeia inteira de tecnologias.


Comparando com a Internet Moderna

Hoje usamos:

HTML

CSS

JavaScript

REST

JSON

React

Angular

Vue

No CICS clássico temos:

MAP

BMS

COBOL

CICS

3270

Os nomes mudaram.

A filosofia continua surpreendentemente parecida:

Separar apresentação da lógica.


Uma Analogia com Inteligência Artificial

Imagine esta conversa.

Você escreve:

"Qual meu saldo?"

A janela do ChatGPT seria o MAP.

O modelo de IA seria o COBOL.

O protocolo que envia sua pergunta e devolve minha resposta seria o BMS.

Curiosamente...

o conceito permanece praticamente o mesmo.


Curiosidades que Pouca Gente Conhece

☕ Curiosidade 1

Os terminais 3270 não enviam cada tecla digitada.

Eles armazenam tudo localmente.

Somente quando ENTER é pressionado ocorre a comunicação.

Isso reduz drasticamente o tráfego.


☕ Curiosidade 2

Um MAP não precisa ocupar a tela inteira.

É possível enviar apenas parte dela.


☕ Curiosidade 3

Os atributos de um campo (protegido, brilhante, oculto, piscante, cor, intensidade) não fazem parte do COBOL.

São controlados pelo BMS.


☕ Curiosidade 4

Em muitos bancos existem MAPS com mais de trinta anos ainda em produção.

Mudaram servidores.

Mudou o hardware.

Mudou o sistema operacional.

O MAP permaneceu.


☕ Curiosidade 5

Grande parte dos aplicativos web modernos acessa exatamente esses mesmos programas COBOL.

A diferença é que hoje existe uma API REST na frente.

O programa continua praticamente igual.


Dicas para Quem Está Começando

✔ Nunca tente desenhar telas no COBOL.

✔ Aprenda SEND e RECEIVE antes de estudar lógica complexa.

✔ Entenda bem Input e Output.

✔ Domine PF Keys.

✔ Estude MDT.

✔ Conheça os atributos dos campos.

✔ Aprenda a ler um MAP antes de programar.

✔ Entenda como o copybook é gerado.

✔ Memorize DFHMSD, DFHMDI e DFHMDF.

✔ Sempre pense na separação entre interface e negócio.


Perguntas Clássicas de Entrevista

O que é um MAP?

É a definição lógica de uma tela utilizada pelo CICS para interação com o usuário.


O que é BMS?

É o componente do CICS responsável por definir, gerenciar e traduzir as telas entre o terminal e o programa COBOL.


Quem desenha a tela?

O BMS.


Quem processa as regras?

O COBOL.


Quem controla a comunicação?

O CICS.


O COBOL conhece o terminal?

Não.

Ele conhece apenas as estruturas geradas pelo MAP.


Easter Egg ☕

Os veteranos costumam brincar que existe um "programador invisível" dentro do CICS.

Quando o iniciante vê apenas:

EXEC CICS SEND MAP
END-EXEC.

Ele pensa:

"Só isso?"

Mas, naquele exato instante, o CICS localiza o MAPSET, interpreta os atributos, monta o buffer 3270, posiciona o cursor, aplica cores, verifica campos protegidos, respeita o MDT, prepara o fluxo de comunicação e envia tudo ao terminal.

É como um mordomo impecável em um romance policial noir: ninguém o nota durante a festa, mas sem ele nada funcionaria.


O Último Mistério do Bellacosa Mainframe

Na manhã seguinte, o jovem programador voltou ao CPD convencido de que finalmente havia entendido como as telas eram criadas.

O velho administrador apenas sorriu e apontou para um monitor 3270.

— Agora você já sabe que a tela não mora dentro do COBOL.

O rapaz concordou.

— Sim... ela mora no BMS.

O veterano balançou a cabeça.

— Ainda não.

Ele caminhou lentamente entre os gabinetes do mainframe e disse:

— O BMS também não é a tela.

É apenas a descrição dela.

A verdadeira tela só existe por alguns milissegundos, quando o CICS interpreta o MAP, monta o fluxo de dados e o terminal a materializa diante dos olhos do usuário. Assim que a transação termina, ela desaparece novamente, como um fantasma que cumpriu sua missão.

O jovem permaneceu em silêncio.

Naquele instante compreendeu uma das maiores elegâncias da arquitetura CICS: o usuário jamais vê o BMS, nunca enxerga o copybook, não conhece o SEND MAP, ignora o RECEIVE MAP e nunca ouvirá falar de DFHMSD, DFHMDI ou DFHMDF. Ainda assim, toda interação depende deles.

É esse o encanto dos grandes sistemas corporativos. Quanto mais perfeita é a engenharia, mais invisível ela se torna.

E talvez este seja o maior segredo do Bellacosa Mainframe: por trás de cada tela aparentemente simples existe uma orquestra silenciosa de componentes trabalhando em perfeita harmonia, provando que, no universo dos mainframes, os verdadeiros heróis quase nunca aparecem em cena.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...