Translate

Mostrar mensagens com a etiqueta Transações CICS. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Transações CICS. Mostrar todas as mensagens

quinta-feira, 1 de maio de 2025

☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Bellacosa Mainframe introducao a modernizacao do cics mainframe seculo xxi


☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Durante décadas, muita gente repetiu a mesma profecia:

"O Mainframe vai acabar."

Enquanto isso, silenciosamente, o CICS continuou processando bilhões de transações por dia.

E aqui está a grande ironia tecnológica da nossa época:

As empresas que tentaram substituir completamente seus sistemas CICS descobriram que recriar 40 anos de regras de negócio é muito mais difícil do que parece.

Foi então que surgiu uma pergunta mais inteligente:

E se, em vez de substituir, nós modernizarmos?

É exatamente isso que o CICS moderno faz.


O PRIMEIRO ERRO: CONFUNDIR MODERNIZAÇÃO COM REESCRITA

Quando alguém fala em modernização, muitos imaginam:

COBOL -> Java
Mainframe -> Cloud
3270 -> Browser

Mas o CICS moderno propõe algo diferente:

COBOL + Java
Mainframe + Cloud
3270 + REST
VSAM + APIs

A IBM chama isso de:

Hybrid Cloud

Ou seja:

O sistema continua executando onde sempre funcionou, mas agora conversa com aplicações modernas.


PASSO 1 – ENTENDER O QUE VOCÊ POSSUI

Antes de modernizar qualquer aplicação CICS, faça um inventário.

Identifique:

  • Transações

  • Programas COBOL

  • Arquivos VSAM

  • DB2

  • COMMAREAs

  • Web Services existentes

  • Dependências

Perguntas importantes:

  • O sistema ainda usa 3270?

  • Existem APIs?

  • Existe documentação?

  • Existe código-fonte?

Acredite:

Nem sempre existe.

E sim...

Existem sistemas produtivos em que o fonte original desapareceu há décadas.


PASSO 2 – SEPARAR APRESENTAÇÃO E NEGÓCIO

A arquitetura clássica ensinada pela IBM possui:

Presentation Layer
Business Logic Layer
Data Services Layer

Exemplo clássico:

PAYPGM
    |
    v
PAYBUS
    |
    v
VSAM

O PAYPGM fala com o usuário.

O PAYBUS contém as regras de negócio.

Quando isso já existe, a modernização fica muito mais simples.


PASSO 3 – TRANSFORMAR O NEGÓCIO EM SERVIÇO

O erro mais comum é tentar modernizar a tela.

A tela não tem valor.

O valor está na regra de negócio.

Por isso o melhor caminho normalmente é:

Browser
    |
REST API
    |
PAYBUS
    |
VSAM

Observe:

O COBOL continua vivo.

Apenas ganhou uma nova interface.


PASSO 4 – APOSENTAR A COMMAREA

A COMMAREA foi uma revolução.

Mas ela possui um limite:

32767 bytes

Isso era enorme em 1975.

Hoje não é.

A solução moderna:

Channels
Containers

Antes:

EXEC CICS LINK
     COMMAREA(...)
END-EXEC

Depois:

EXEC CICS LINK
     CHANNEL('PAYROLL')
END-EXEC

Benefícios:

  • Sem limite prático

  • Dados organizados

  • Menos copybooks gigantes

  • Melhor integração


PASSO 5 – INTRODUZIR JAVA SEM TRAUMA

Aqui surge a pergunta que assombra muitos programadores COBOL:

"Precisamos reescrever tudo em Java?"

Não.

E provavelmente você não deveria.

O CICS permite executar Java dentro do próprio ambiente.

Arquitetura:

CICS
   |
JVM Server
   |
Liberty
   |
Java

Agora o cenário fica interessante:

COBOL
   |
LINK
   |
Java

e também:

Java
   |
LINK
   |
COBOL

Os dois mundos coexistem.


PASSO 6 – DESCOBRIR O PODER DO LINK TO LIBERTY

Este é um dos recursos mais elegantes do CICS moderno.

Um programa COBOL pode chamar um método Java.

Exemplo:

@CICSProgram("CUSTGET")

Agora o COBOL pode executar:

EXEC CICS LINK
     PROGRAM('CUSTGET')
END-EXEC

Sem HTTP.

Sem REST.

Sem MQ.

Sem gambiarra.

Tudo dentro do próprio CICS.


PASSO 7 – ADOTAR APIs REST

Uma das formas mais comuns de modernização é expor programas COBOL como APIs REST.

Arquitetura:

Mobile App
     |
REST
     |
Java
     |
PAYBUS
     |
VSAM

O usuário nem imagina que existe COBOL por trás.

E isso é perfeitamente aceitável.

Aliás...

É exatamente o objetivo.


PASSO 8 – IMPLEMENTAR EVENT PROCESSING

Aqui está um superpoder pouco conhecido.

Imagine um sistema de apostas.

Toda vez que alguém aposta mais de R$ 50.000:

Evento

Mas você perdeu o fonte.

Como alterar o programa?

Você não altera.

O CICS observa eventos.

Exemplo:

EXEC CICS LINK

Ao detectar o comando:

Evento gerado

Sem modificar uma linha de COBOL.

Isso é Event Processing.


PASSO 9 – PROGRAMAÇÃO ASSÍNCRONA

Outro recurso poderoso.

Tradicional:

Programa A
espera B
espera C
espera D

Moderno:

Programa A

+---- B
|
+---- C
|
+---- D

Tudo executando simultaneamente.

Novas APIs:

RUN TRANSID
FETCH CHILD
FETCH ANY
FREE CHILD

Menos espera.

Mais throughput.

Mais escalabilidade.


PASSO 10 – ENTRAR NO MUNDO DEVOPS

Aqui muitos profissionais acreditam que existe:

DevOps Linux
DevOps Mainframe

Mas a IBM foi direta:

Existe apenas:

DevOps

Ferramentas modernas:

Git
VS Code
Zowe
Jenkins
DBB
Ansible
UrbanCode

O fluxo torna-se:

Git
 |
Build
 |
Test
 |
Deploy
 |
CICS

ERROS MAIS COMUNS

Erro 1

Tentar reescrever tudo.

Resultado:

Projeto de 5 anos.

Orçamento explode.

Sistema antigo continua rodando.


Erro 2

Modernizar a interface e esquecer a regra de negócio.

A regra é o patrimônio.

A tela é apenas um detalhe.


Erro 3

Ignorar testes.

Use:

ZUnit
JUnit
Mockito
Galasa

Erro 4

Não envolver o System Programmer.

Lembre-se:

Arquivos.

Recovery.

Resources.

Bundles.

JVM Servers.

Tudo isso depende dele.


SOLUÇÃO DE PROBLEMAS

EIBCALEN = 0

Primeira entrada da transação.


Programa novo não atualiza

Execute:

NEWCOPY

ou

REFRESH PROGRAM

COMMAREA truncada

Provavelmente ultrapassou:

32K

Migre para Containers.


LINK retornando erro

Verifique:

RESP
RESP2

Sempre.


CURIOSIDADE

Pouca gente sabe, mas o CICS nasceu em uma época em que muitos computadores ainda trabalhavam com cartões perfurados.

Hoje ele executa:

  • APIs REST

  • Java

  • JSON

  • Liberty

  • Cloud

  • DevOps

Sem abandonar sua essência transacional.

Isso talvez explique sua longevidade.


EASTER EGG MAINFRAME

Existe uma frase que quase todo profissional experiente de CICS aprende depois de alguns anos:

"O problema nunca está no CICS."

Primeiro você culpa:

  • CICS

  • VSAM

  • RACF

  • DB2

  • MQ

Depois de algumas horas investigando...

Descobre que esqueceu de fazer:

EXEC CICS RETURN
END-EXEC

ou

EXEC CICS HANDLE CONDITION
END-EXEC

ou simplesmente compilou o programa errado.

Acontece mais do que deveria.


CONCLUSÃO

☕💣🚀 PADAWAN, O MAIOR SEGREDO DA MODERNIZAÇÃO NÃO É TROCAR COBOL POR JAVA.

É entender que o verdadeiro valor está nas regras de negócio acumuladas durante décadas.

O CICS moderno permite adicionar:

  • REST

  • Java

  • Liberty

  • Eventos

  • APIs

  • DevOps

  • Cloud

sem destruir aquilo que já funciona.

E essa talvez seja a definição mais elegante de modernização:

Evoluir sem perder a confiança conquistada por milhões de transações executadas corretamente ao longo de décadas.

sábado, 8 de junho de 2019

O Mistério da Porta que Nunca se Abriu Novamente : Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

 

Bellacosa Mainframe e o misterio da porta que nunsa se abriu novamente

☕ Um Café no Bellacosa Mainframe

O Mistério da Porta que Nunca se Abriu Novamente

Quando um Jovem Programador COBOL Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

"Existem portas que foram feitas para serem atravessadas duas vezes. Outras... apenas uma."

Era assim que começava um antigo manual não oficial que circulava entre programadores de CICS na década de 1980. Diziam que o autor nunca assinou seu nome. Apenas deixava um pequeno desenho de uma xícara de café ao lado das páginas.

Os veteranos chamavam aquele manuscrito de O Livro das Portas.

Hoje vamos descobrir por quê.

Pegue seu café.

Apague as luzes do escritório.

O letreiro verde do terminal 3270 acaba de acender.

O caso vai começar.


Capítulo 1 — O prédio onde programas conversam

Quem vem do COBOL Batch imagina que um programa vive sozinho.

Ele começa.

Processa.

Termina.

No CICS isso não existe.

Um sistema bancário raramente possui um programa gigante.

Na verdade ele parece uma pequena cidade.

Existe o programa do Login.

O Menu Principal.

Consulta de Saldo.

PIX.

Transferência.

Extrato.

Cartão.

Empréstimos.

Investimentos.

Cada um conhece apenas seu trabalho.

É exatamente como uma delegacia de polícia.

O investigador não faz exame pericial.

O perito não conduz interrogatórios.

O escrivão não prende criminosos.

Cada especialista executa apenas sua função.

No CICS acontece exatamente isso.

Cada programa é especialista em um assunto.

A pergunta é:

Como eles conversam?

A resposta possui apenas quatro letras.

LINK.

Ou...

XCTL.

E é aqui que começa nosso mistério.


Capítulo 2 — O telefone vermelho da IBM

Imagine um antigo escritório bancário dos anos 1950.

Sobre uma mesa existe um telefone vermelho.

Quando o gerente precisa de alguma informação ele liga para outro departamento.

— Preciso do saldo da conta.

O funcionário responde.

— Um instante.

Alguns segundos depois.

— Aqui está.

O gerente continua seu trabalho.

Isso é LINK.

O programa chama outro programa.

Espera.

Recebe a resposta.

Continua exatamente de onde havia parado.

Observe o fluxo.

Programa LOGIN

↓

LINK

↓

Programa CONSULTA

↓

RETURN

↓

LOGIN continua

Nada de mágico aconteceu.

Apenas uma conversa organizada.


A verdadeira mágica

O que ninguém vê é que o CICS precisa guardar tudo.

Enquanto o programa chamado trabalha, o programa chamador fica "congelado".

O CICS preserva:

✔ Registradores

✔ Contexto

✔ Área de memória

✔ Ponto de retorno

✔ COMMAREA

É quase como colocar um marcador dentro de um livro.

Você fecha.

Empresta para alguém.

Quando devolvem...

Você abre exatamente na mesma página.

Essa é a essência do LINK.


Capítulo 3 — A porta sem maçaneta

Agora imagine outra situação.

Você entrega a chave da empresa ao próximo gerente.

Vai embora.

Nunca mais volta.

Esse é o XCTL.

Programa LOGIN

↓

XCTL

↓

MENU

↓

Fim

O LOGIN morreu.

Sua missão terminou.

Ele não existe mais dentro daquela execução.

É uma transferência definitiva.

Os antigos programadores diziam:

"LINK conversa.

XCTL abdica."

Essa frase aparecia escrita em algumas apostilas da IBM nos anos 80.


A analogia da corrida

Imagine uma prova de revezamento.

No LINK...

Você entrega o bastão.

Espera.

Recebe de volta.

Continua correndo.

No XCTL...

Você entrega.

Sai da pista.

Vai tomar café.

Nunca mais participa daquela corrida.


O erro que denuncia um iniciante

Todo entrevistador gosta desta pergunta.

Veja:

EXEC CICS XCTL
     PROGRAM('MENU')
END-EXEC.

DISPLAY "CHEGUEI AQUI".

Pergunta:

Esse DISPLAY será executado?

Resposta:

Jamais.

Nunca.

Nem hoje.

Nem amanhã.

Nem daqui vinte anos.

Depois do XCTL o programa desapareceu.

Essa pequena pegadinha já eliminou centenas de candidatos em entrevistas.


Capítulo 4 — O elevador do edifício CICS

Imagine um prédio com cinquenta andares.

Cada andar possui um programa.

LINK funciona como um elevador.

Você sobe.

Resolve um assunto.

Desce.

Continua trabalhando.

XCTL funciona como mudança definitiva de escritório.

Você pega suas caixas.

Entrega sua sala.

Muda para outro andar.

Nunca mais volta.

Essa imagem ajuda muitos iniciantes.


O segredo escondido dentro do CICS

Muitos acreditam que LINK simplesmente chama outro programa.

Não.

Existe muito trabalho invisível.

Quando executamos:

EXEC CICS LINK

o CICS precisa:

Localizar o programa.

Carregar caso não esteja residente.

Criar ambiente.

Salvar contexto.

Preparar COMMAREA.

Transferir controle.

Esperar RETURN.

Restaurar contexto.

Continuar execução.

Existe um pequeno custo.

Pequeno.

Mas existe.


Já o XCTL...

Observe.

LOGIN

↓

MENU

Pronto.

Não existe necessidade de preservar retorno.

Não existe restauração.

O fluxo ficou linear.

Por isso muitos livros dizem que XCTL possui menor overhead.

Mas cuidado.

Não escolha XCTL apenas porque "é mais rápido".

Escolha porque faz sentido arquiteturalmente.

Essa diferença é importante.


Capítulo 5 — O caso do caixa eletrônico

Vamos imaginar um ATM.

Cliente digita cartão.

Senha.

Programa LOGIN.

Após validar usuário.

O sistema faz

XCTL MENU

Por quê?

Porque ninguém deseja voltar para a tela de login.

O LOGIN cumpriu sua missão.

Agora imagine outra opção.

O cliente escolhe:

Consultar saldo.

O MENU faz:

LINK SALDO

Programa SALDO consulta DB2.

Retorna.

O MENU continua vivo.

Cliente escolhe:

Extrato.

Outro LINK.

Cliente escolhe:

PIX.

Mais um LINK.

Perceba.

O MENU é o maestro.

As funções são músicos.

Cada músico toca.

Depois devolve o palco.


Curiosidade histórica

Nos primeiros grandes bancos brasileiros era comum encontrar verdadeiras árvores de LINK.

Algo semelhante a:

MENU

↓

LINK

CLIENTE

↓

LINK

ENDERECO

↓

LINK

CEP

↓

RETURN

↓

RETURN

↓

RETURN

Era perfeitamente normal encontrar cinco ou seis níveis de chamadas.

Hoje isso ainda existe, mas arquiteturas modernas procuram evitar profundidades excessivas para facilitar manutenção e depuração.


Capítulo 6 — A COMMAREA: o envelope secreto

Imagine um envelope lacrado.

Dentro existem informações importantes.

Cliente.

Conta.

Saldo.

Tipo de operação.

Senha criptografada.

Tudo isso viaja pela COMMAREA.

Ela é o "correio interno" entre programas CICS.

Exemplo:

Programa A

↓

COMMAREA

↓

Programa B

Nada vai para disco.

Nada vai para banco.

Tudo permanece na memória durante a transação.

É extremamente rápido.


Easter Egg Bellacosa ☕

Os veteranos costumavam brincar:

"Se a COMMAREA fosse um carteiro, ela seria o único funcionário dos Correios que nunca perde uma encomenda... desde que você informe o LENGTH corretamente."

E aí está uma das maiores armadilhas dos iniciantes.


O LENGTH que derruba sistemas

Veja:

EXEC CICS LINK
    PROGRAM('CLIENTE')
    COMMAREA(WS-COMMAREA)
    LENGTH(LENGTH OF WS-COMMAREA)
END-EXEC.

Por que informar LENGTH?

Porque o CICS precisa saber exatamente quantos bytes transportar.

Se enviar menos...

Dados truncados.

Se enviar mais...

Lixo de memória.

Em alguns casos...

ABEND.

Simples assim.


Capítulo 7 — LINK parece CALL?

Essa dúvida aparece todos os meses.

Resposta curta:

Não.

CALL pertence ao COBOL.

LINK pertence ao CICS.

CALL apenas transfere execução.

LINK conversa com toda a infraestrutura CICS.

Ele conhece:

Recuperação.

Transação.

Segurança.

Recursos.

Comunicação.

Monitoramento.

É muito mais sofisticado.


Comparando os três irmãos

ComandoRetornaAmbiente
CALLSimCOBOL
LINKSimCICS
XCTLNãoCICS

Capítulo 8 — A arquitetura elegante

Um projeto bem desenhado normalmente parece isto:

LOGIN

↓

XCTL

↓

MENU

↓

LINK

SALDO

↓

RETURN

↓

MENU

↓

LINK

PIX

↓

RETURN

↓

MENU

↓

LINK

EXTRATO

↓

RETURN

Observe como tudo faz sentido.

LOGIN nunca retorna.

MENU permanece vivo.

As funcionalidades entram.

Executam.

Saem.

Essa organização facilita testes, manutenção e reutilização.


Dicas de ouro para iniciantes

✔ Regra número um

Se precisa voltar...

Use LINK.


✔ Regra número dois

Se acabou seu trabalho...

Use XCTL.


✔ Regra número três

Nunca coloque código após XCTL esperando execução.


✔ Regra número quatro

Sempre valide o tamanho da COMMAREA.


✔ Regra número cinco

Evite criar "espaguete de LINK", onde programas chamam programas que chamam outros programas sem um desenho arquitetural claro. Quanto mais profunda a cadeia, mais difícil será depurar um problema às três da manhã.


Curiosidade que pouca gente conhece

Em algumas instalações antigas da IBM existia uma recomendação informal:

"Se um programa não precisa voltar, não o obrigue a voltar."

Essa filosofia influenciou muitos padrões de desenvolvimento CICS e explica por que tantos fluxos de navegação utilizam XCTL entre telas principais e LINK apenas para serviços reutilizáveis.


O Mistério do Detetive Bellacosa

Imagine um investigador chamado Arthur Bellacosa.

Ele recebe um caso.

Vai até o Arquivo Central.

Precisa consultar documentos.

Ele diz ao arquivista:

— Procure a ficha do cliente 458923.

O arquivista vai até o depósito.

Volta.

Entrega os documentos.

Arthur continua investigando.

Isso foi um LINK.

Agora imagine outro cenário.

Arthur resolve entregar todo o caso ao Departamento de Crimes Financeiros.

Entrega as pastas.

Entrega as chaves.

Entrega seu distintivo temporário.

Vai embora.

Nunca mais participa da investigação.

Isso foi um XCTL.

O caso continua.

Mas sem ele.


Perguntas clássicas de entrevista

Qual retorna ao programa chamador?

LINK.


Qual termina definitivamente o programa atual?

XCTL.


Qual é mais indicado para módulos reutilizáveis?

LINK.


Qual costuma ser usado após Login para Menu Principal?

XCTL.


Posso executar código após um XCTL?

Não.


LINK é igual a CALL?

Não. O conceito de retorno é semelhante, mas LINK opera dentro do ambiente gerenciado pelo CICS, com controle de transação, contexto e recursos.


O Cofre dos Programadores (Easter Egg)

Há uma velha lenda entre programadores de mainframe que diz existir uma região CICS esquecida em algum laboratório da IBM, apelidada de REGION-X.

Nela existiria um programa chamado FOREVER, que executou um XCTL em 1987 e nunca mais retornou.

Toda vez que um jovem programador pergunta:

— "Será que esse programa volta?"

Um veterano apenas sorri e responde:

— "Pergunte ao FOREVER..."

Claro, é apenas uma brincadeira de corredor. Mas ela resume perfeitamente o conceito: algumas transferências foram feitas para nunca olhar para trás.


Conclusão — A Porta Certa no Momento Certo

LINK e XCTL possuem a mesma missão: transferir o controle entre programas. No entanto, representam filosofias completamente diferentes de construção de aplicações.

LINK é colaboração. Um programa pede ajuda, recebe o resultado e continua sua jornada. Ele favorece reutilização, modularidade e organização.

XCTL é sucessão. O programa conclui sua missão, entrega o bastão e permite que outro assuma o restante da transação. O fluxo fica mais limpo e evita preservar um contexto que nunca mais será utilizado.

Em sistemas bancários, seguradoras, companhias aéreas e grandes ambientes corporativos, essa decisão acontece milhares — às vezes milhões — de vezes por dia. Um simples comando define se o programa permanece como protagonista da história ou se entrega definitivamente o palco ao próximo ator.

Da próxima vez que você vir um EXEC CICS LINK ou um EXEC CICS XCTL, lembre-se do velho edifício iluminado por terminais verdes. Algumas portas foram feitas para serem abertas, entrar, resolver um assunto e voltar. Outras se fecham atrás de você para sempre.

E, no silencioso universo do CICS, escolher a porta correta é uma das marcas que separam um programador iniciante de um verdadeiro arquiteto de aplicações mainframe.

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