🔥 Different Types of RETURN Statements no CICS
☕ Midnight Lunch, ENTER pressionado e… RETURN errado
13h07.
Usuário pressiona ENTER.
A tela some.
Nada acontece.
No fundo da sala alguém pergunta, com medo:
“Esse RETURN tá certo… né?”
Hoje vamos falar de um comando pequeno na sintaxe, mas gigante no impacto:
o EXEC CICS RETURN e suas variações.
Porque no CICS, retornar errado é desaparecer da aplicação.
🏛️ História: o retorno como base do online
Desde o início do CICS, o RETURN é o ponto onde:
-
A task termina
-
O controle volta para o CICS
-
A transação decide se continua ou morre
Muito antes de frameworks web, o CICS já dominava o request/response.
📌 RETURN é o “commit emocional” da transação.
🧠 Conceito essencial (grave isso)
RETURN não é só sair do programa.
É decidir o destino da transação.
Cada tipo de RETURN muda o comportamento do sistema.
🔁 Tipos de RETURN no CICS
Vamos aos principais, sem enrolação.
1️⃣ RETURN simples – fim da linha
O que faz?
-
Encerra o programa
-
Finaliza a task
-
Nenhuma continuação
📌 Usado quando:
-
Processamento acabou
-
Nenhuma tela a exibir
-
Nenhuma navegação
⚠️ Usado errado → usuário perdido.
2️⃣ RETURN com TRANSID – chama outra transação
O que faz?
-
Finaliza a task atual
-
Inicia nova transação
-
Novo task number
📌 Ideal para:
-
Navegação controlada
-
Separação de fluxos
-
Segurança transacional
3️⃣ RETURN com COMMAREA – estado preservado
O que faz?
-
Finaliza a task
-
Preserva dados para a próxima
📌 Base do pseudo-conversacional.
4️⃣ RETURN com CHANNEL – o jeito moderno
O que faz?
-
Mesmo conceito da COMMAREA
-
Muito mais flexível
📌 Padrão moderno. Escalável. Elegante.
5️⃣ RETURN IMMEDIATE – sem passar pelo fluxo normal
O que faz?
-
Termina a task agora
-
Ignora pseudo-conversacional
📌 Use com cuidado:
-
Emergência
-
Erro crítico
-
Saída forçada
🥊 RETURN vs XCTL vs LINK (mini comparativo)
| Comando | Retorna? | Nova task? | Uso típico |
|---|---|---|---|
| RETURN | Não | Depende | Encerrar |
| XCTL | Não | Não | Troca de fluxo |
| LINK | Sim | Não | Sub-rotina |
📌 Confundir isso gera bug fantasma.
🛠️ Passo a passo Bellacosa (antes do RETURN)
1️⃣ O usuário precisa ver outra tela?
2️⃣ Preciso preservar estado?
3️⃣ Nova transação ou mesma?
4️⃣ COMMAREA ou CHANNEL?
5️⃣ Estou encerrando cedo demais?
📌 RETURN é decisão arquitetural.
⚠️ Erros clássicos (easter eggs)
🐣 RETURN sem TRANSID em fluxo pseudo-conversacional
🐣 COMMAREA com tamanho errado
🐣 RETURN antes de liberar lock
🐣 Misturar XCTL e RETURN sem lógica
🐣 Esquecer canal ativo
📌 Todo sumiço de tela começa aqui.
📚 Guia de estudo para mainframers
Para dominar RETURN:
-
Pseudo-conversational design
-
Program Control
-
COMMAREA vs CHANNEL
-
Transaction lifecycle
-
Error handling
📖 Manual essencial: CICS Application Programming Guide
🤓 Curiosidades de boteco mainframe
🍺 RETURN existe desde os primeiros CICS
🍺 RETURN IMMEDIATE já salvou produção quebrada
🍺 Muitos “bugs de tela” são RETURN errado
🍺 Web frameworks copiaram o modelo sem saber
💬 Comentário El Jefe Midnight Lunch
“No CICS, voltar é escolha.
Sumir é consequência.”
🚀 Aplicações reais hoje
-
Sistemas de atendimento
-
Core bancário
-
Sistemas governamentais
-
Aplicações híbridas CICS + API
🎯 Conclusão Bellacosa
O EXEC CICS RETURN parece simples.
Mas ele define:
-
Fluxo
-
Estado
-
Experiência do usuário
🔥 RETURN não é sair. É decidir o futuro.
